Compare commits
1 Commits
| Author | SHA1 | Date |
|---|---|---|
 shiz01
|
c9cd274b2b
|
|
|
@ -1,36 +0,0 @@
|
|||
FROM node:16-bullseye
|
||||
|
||||
WORKDIR /root
|
||||
|
||||
ADD ./docker/vitastor.gpg /etc/apt/trusted.gpg.d
|
||||
|
||||
RUN echo 'deb http://deb.debian.org/debian bullseye-backports main' >> /etc/apt/sources.list; \
|
||||
echo 'deb http://vitastor.io/debian bullseye main' >> /etc/apt/sources.list; \
|
||||
echo >> /etc/apt/preferences; \
|
||||
echo 'Package: *' >> /etc/apt/preferences; \
|
||||
echo 'Pin: release a=bullseye-backports' >> /etc/apt/preferences; \
|
||||
echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
|
||||
echo >> /etc/apt/preferences; \
|
||||
echo 'Package: *' >> /etc/apt/preferences; \
|
||||
echo 'Pin: origin "vitastor.io"' >> /etc/apt/preferences; \
|
||||
echo 'Pin-Priority: 1000' >> /etc/apt/preferences; \
|
||||
grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
|
||||
echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf; \
|
||||
echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
|
||||
|
||||
RUN apt-get update
|
||||
RUN apt-get -y install etcd qemu-system-x86 qemu-block-extra qemu-utils fio libasan5 \
|
||||
liburing1 liburing-dev libgoogle-perftools-dev devscripts libjerasure-dev cmake libibverbs-dev libisal-dev
|
||||
RUN apt-get -y build-dep fio qemu=`dpkg -s qemu-system-x86|grep ^Version:|awk '{print $2}'`
|
||||
RUN apt-get update && apt-get -y install jq lp-solve sudo nfs-common fdisk parted
|
||||
RUN apt-get --download-only source fio qemu=`dpkg -s qemu-system-x86|grep ^Version:|awk '{print $2}'`
|
||||
|
||||
RUN set -ex; \
|
||||
mkdir qemu-build; \
|
||||
cd qemu-build; \
|
||||
dpkg-source -x /root/qemu*.dsc; \
|
||||
cd qemu*/; \
|
||||
debian/rules configure-qemu || debian/rules b/configure-stamp; \
|
||||
cd b/qemu; \
|
||||
make -j8 config-poison.h || true; \
|
||||
make -j8 qapi/qapi-builtin-types.h
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
FROM git.yourcmc.ru/vitalif/vitastor/buildenv
|
||||
|
||||
ADD . /root/vitastor
|
||||
|
||||
RUN set -e -x; \
|
||||
mkdir -p /root/fio-build/; \
|
||||
cd /root/fio-build/; \
|
||||
dpkg-source -x /root/fio*.dsc; \
|
||||
cd /root/vitastor; \
|
||||
ln -s /root/fio-build/fio-*/ ./fio; \
|
||||
ln -s /root/qemu-build/qemu-*/ ./qemu; \
|
||||
ls /usr/include/linux/raw.h || cp ./debian/raw.h /usr/include/linux/raw.h; \
|
||||
cd mon; \
|
||||
npm install; \
|
||||
cd ..; \
|
||||
mkdir build; \
|
||||
cd build; \
|
||||
cmake .. -DWITH_ASAN=yes -DWITH_QEMU=yes; \
|
||||
make -j16
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,83 +0,0 @@
|
|||
#!/usr/bin/perl
|
||||
|
||||
use strict;
|
||||
|
||||
for my $line (<>)
|
||||
{
|
||||
if ($line =~ /\.\/(test_[^\.]+)/s)
|
||||
{
|
||||
chomp $line;
|
||||
my $base_name = $1;
|
||||
my $test_name = $base_name;
|
||||
my $timeout = 3;
|
||||
if ($test_name eq 'test_etcd_fail' || $test_name eq 'test_heal' || $test_name eq 'test_add_osd' ||
|
||||
$test_name eq 'test_interrupted_rebalance' || $test_name eq 'test_rebalance_verify')
|
||||
{
|
||||
$timeout = 10;
|
||||
}
|
||||
while ($line =~ /([^\s=]+)=(\S+)/gs)
|
||||
{
|
||||
if ($1 eq 'TEST_NAME')
|
||||
{
|
||||
$test_name = $base_name.'_'.$2;
|
||||
last;
|
||||
}
|
||||
elsif ($1 eq 'SCHEME' && $2 eq 'ec')
|
||||
{
|
||||
$test_name .= '_ec';
|
||||
}
|
||||
elsif ($1 eq 'SCHEME' && $2 eq 'xor')
|
||||
{
|
||||
$test_name .= '_xor';
|
||||
}
|
||||
elsif ($1 eq 'IMMEDIATE_COMMIT')
|
||||
{
|
||||
$test_name .= '_imm';
|
||||
}
|
||||
elsif ($1 eq 'ANTIETCD')
|
||||
{
|
||||
$test_name .= '_antietcd';
|
||||
}
|
||||
else
|
||||
{
|
||||
$test_name .= '_'.lc($1).'_'.$2;
|
||||
}
|
||||
}
|
||||
if ($test_name eq 'test_snapshot_chain_ec')
|
||||
{
|
||||
$timeout = 6;
|
||||
}
|
||||
$line =~ s!\./test_!/root/vitastor/tests/test_!;
|
||||
# Gitea CI doesn't support artifacts yet, lol
|
||||
#- name: Upload results
|
||||
# uses: actions/upload-artifact\@v3
|
||||
# if: always()
|
||||
# with:
|
||||
# name: ${test_name}_result
|
||||
# path: |
|
||||
# /root/vitastor/testdata
|
||||
# !/root/vitastor/testdata/*.bin
|
||||
# retention-days: 5
|
||||
print <<"EOF"
|
||||
$test_name:
|
||||
runs-on: ubuntu-latest
|
||||
needs: build
|
||||
container: \${{env.TEST_IMAGE}}:\${{github.sha}}
|
||||
steps:
|
||||
- name: Run test
|
||||
id: test
|
||||
timeout-minutes: $timeout
|
||||
run: $line
|
||||
- name: Print logs
|
||||
if: always() && steps.test.outcome == 'failure'
|
||||
run: |
|
||||
for i in /root/vitastor/testdata/*.log /root/vitastor/testdata/*.txt; do
|
||||
echo "-------- \$i --------"
|
||||
cat \$i
|
||||
echo ""
|
||||
done
|
||||
|
||||
EOF
|
||||
;
|
||||
}
|
||||
}
|
||||
|
|
@ -3,3 +3,16 @@
|
|||
package-lock.json
|
||||
fio
|
||||
qemu
|
||||
osd
|
||||
stub_osd
|
||||
stub_uring_osd
|
||||
stub_bench
|
||||
osd_test
|
||||
osd_peering_pg_test
|
||||
dump_journal
|
||||
nbd_proxy
|
||||
rm_inode
|
||||
test_allocator
|
||||
test_blockstore
|
||||
test_shit
|
||||
osd_rmw_test
|
||||
|
|
|
|||
115
CLA-en.md
115
CLA-en.md
|
|
@ -1,115 +0,0 @@
|
|||
## Contributor License Agreement
|
||||
|
||||
> This Agreement is made in the Russian and English languages. **The English
|
||||
text of Agreement is for informational purposes only** and is not binding
|
||||
for the Parties.
|
||||
>
|
||||
> In the event of a conflict between the provisions of the Russian and
|
||||
English versions of this Agreement, the **Russian version shall prevail**.
|
||||
>
|
||||
> Russian version is published at https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md
|
||||
|
||||
This document represents the offer of Filippov Vitaliy Vladimirovich
|
||||
("Author"), author and copyright holder of Vitastor software ("Program"),
|
||||
acknowledged by a certificate of Federal Service for Intellectual
|
||||
Property of Russian Federation (Rospatent) # 2021617829 dated 20 May 2021,
|
||||
to "Contributors" to conclude this license agreement as follows
|
||||
("Agreement" or "Offer").
|
||||
|
||||
In accordance with Art. 435, Art. 438 of the Civil Code of the Russian
|
||||
Federation, this Agreement is an offer and in case of acceptance of the
|
||||
offer, an agreement is considered concluded on the conditions specified
|
||||
in the offer.
|
||||
|
||||
1. Applicable Terms. \
|
||||
1.1. "Official Repository" shall mean the computer storage, operated by
|
||||
the Author, containing all prior and future versions of the Source
|
||||
Code of the Program, at Internet addresses https://git.yourcmc.ru/vitalif/vitastor/
|
||||
or https://github.com/vitalif/vitastor/. \
|
||||
1.2. "Contributions" shall mean results of intellectual activity
|
||||
(including, but not limited to, source code, libraries, components,
|
||||
texts, documentation) which can be software or elements of the software
|
||||
and which are provided by Contributors to the Author for inclusion
|
||||
in the Program. \
|
||||
1.3. "Contributor" shall mean a person who provides Contributions to
|
||||
the Author and agrees with all provisions of this Agreement.
|
||||
A Сontributor can be: 1) an individual; or 2) a legal entity or an
|
||||
individual entrepreneur in case when an individual provides Contributions
|
||||
on behalf of third parties, including on behalf of his employer.
|
||||
|
||||
2. Subject of the Agreement. \
|
||||
2.1. Subject of the Agreement shall be the Contributions sent to the Author by Contributors. \
|
||||
2.2. The Contributor grants to the Author the right to use Contributions at his own
|
||||
discretion and without any necessity to get a prior approval from Contributor or
|
||||
any other third party in any way, under a simple (non-exclusive), royalty-free,
|
||||
irrevocable license throughout the world by all means not contrary to law, in whole
|
||||
or as a part of the Program, or other open-source or closed-source computer programs,
|
||||
products or services (hereinafter -- the "License"), including, but not limited to: \
|
||||
2.2.1. to execute Contributions and use them for any tasks; \
|
||||
2.2.2. to publish and distribute Contributions in modified or unmodified form and/or to rent them; \
|
||||
2.2.3. to modify Contributions, add comments, illustrations or any explanations to Contributions while using them; \
|
||||
2.2.4. to create other results of intellectual activity based on Contributions, including derivative works and composite works; \
|
||||
2.2.5. to translate Contributions into other languages, including other programming languages; \
|
||||
2.2.6. to carry out rental and public display of Contributions; \
|
||||
2.2.7. to use Contributions under the trade name and/or any trademark or any other label, or without it, as the Author thinks fit; \
|
||||
2.3. The Contributor grants to the Author the right to sublicense any of the aforementioned
|
||||
rights to third parties on any terms at the Author's discretion. \
|
||||
2.4. The License is provided for the entire duration of Contributor's
|
||||
exclusive intellectual property rights to the Contributions. \
|
||||
2.5. The Contributor grants to the Author the right to decide how and where to mention,
|
||||
or to not mention at all, the fact of his authorship, name, nickname and/or company
|
||||
details when including Contributions into the Program or in any other computer
|
||||
programs, products or services.
|
||||
|
||||
3. Acceptance of the Offer \
|
||||
3.1. The Contributor may provide Contributions to the Author in the form of
|
||||
a "Pull Request" in an Official Repository of the Program or by any
|
||||
other electronic means of communication, including, but not limited to,
|
||||
E-mail or messenger applications. \
|
||||
3.2. The acceptance of the Offer shall be the fact of provision of Contributions
|
||||
to the Author by the Contributor by any means with the following remark:
|
||||
“I accept Vitastor CLA agreement: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md”
|
||||
or “Я принимаю соглашение Vitastor CLA: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md”. \
|
||||
3.3. Date of acceptance of the Offer shall be the date of such provision.
|
||||
|
||||
4. Rights and obligations of the parties. \
|
||||
4.1. The Contributor reserves the right to use Contributions by any lawful means
|
||||
not contrary to this Agreement. \
|
||||
4.2. The Author has the right to refuse to include Contributions into the Program
|
||||
at any moment with no explanation to the Contributor.
|
||||
|
||||
5. Representations and Warranties. \
|
||||
5.1. The person providing Contributions for the purpose of their inclusion
|
||||
in the Program represents and warrants that he is the Contributor
|
||||
or legally acts on the Contributor's behalf. Name or company details
|
||||
of the Contributor shall be provided with the Contribution at the moment
|
||||
of their provision to the Author. \
|
||||
5.2. The Contributor represents and warrants that he legally owns exclusive
|
||||
intellectual property rights to the Contributions. \
|
||||
5.3. The Contributor represents and warrants that any further use of
|
||||
Contributions by the Author as provided by Contributor under the terms
|
||||
of the Agreement does not infringe on intellectual and other rights and
|
||||
legitimate interests of third parties. \
|
||||
5.4. The Contributor represents and warrants that he has all rights and legal
|
||||
capacity needed to accept this Offer; \
|
||||
5.5. The Contributor represents and warrants that Contributions don't
|
||||
contain malware or any information considered illegal under the law
|
||||
of Russian Federation.
|
||||
|
||||
6. Termination of the Agreement \
|
||||
6.1. The Agreement may be terminated at will of both Author and Contributor,
|
||||
formalised in the written form or if the Agreement is terminated on
|
||||
reasons prescribed by the law of Russian Federation.
|
||||
|
||||
7. Final Clauses \
|
||||
7.1. The Contributor may optionally sign the Agreement in the written form. \
|
||||
7.2. The Agreement is deemed to become effective from the Date of signing of
|
||||
the Agreement and until the expiration of Contributor's exclusive
|
||||
intellectual property rights to the Contributions. \
|
||||
7.3. The Author may unilaterally alter the Agreement without informing Contributors.
|
||||
The new version of the document shall come into effect 3 (three) days after
|
||||
being published in the Official Repository of the Program at Internet address
|
||||
[https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md](https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md).
|
||||
Contributors should keep informed about the actual version of the Agreement themselves. \
|
||||
7.4. If the Author and the Contributor fail to agree on disputable issues,
|
||||
disputes shall be referred to the Moscow Arbitration court.
|
||||
108
CLA-ru.md
108
CLA-ru.md
|
|
@ -1,108 +0,0 @@
|
|||
## Лицензионное соглашение с участником
|
||||
|
||||
> Данная Оферта написана в Русской и Английской версиях. **Версия на английском
|
||||
языке предоставляется в информационных целях** и не связывает стороны договора.
|
||||
>
|
||||
> В случае несоответствий между положениями Русской и Английской версий Договора,
|
||||
**Русская версия имеет приоритет**.
|
||||
>
|
||||
> Английская версия опубликована по адресу https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md
|
||||
|
||||
Настоящий договор-оферта (далее по тексту – Оферта, Договор) адресована физическим
|
||||
и юридическим лицам (далее – Участникам) и является официальным публичным предложением
|
||||
Филиппова Виталия Владимировича (далее – Автора) программного обеспечения Vitastor,
|
||||
свидетельство Федеральной службы по интеллектуальной собственности (Роспатент) № 2021617829
|
||||
от 20 мая 2021 г. (далее – Программа) о нижеследующем:
|
||||
|
||||
1. Термины и определения \
|
||||
1.1. Репозиторий – электронное хранилище, содержащее исходный код Программы. \
|
||||
1.2. Доработка – результат интеллектуальной деятельности Участника, включающий
|
||||
в себя изменения или дополнения к исходному коду Программы, которые Участник
|
||||
желает включить в состав Программы для дальнейшего использования и распространения
|
||||
Автором и для этого направляет их Автору. \
|
||||
1.3. Участник – физическое или юридическое лицо, вносящее Доработки в код Программы. \
|
||||
1.4. ГК РФ – Гражданский кодекс Российской Федерации.
|
||||
|
||||
2. Предмет оферты \
|
||||
2.1. Предметом настоящей оферты являются Доработки, отправляемые Участником Автору. \
|
||||
2.2. Участник предоставляет Автору право использовать Доработки по собственному усмотрению
|
||||
и без необходимости предварительного согласования с Участником или иным третьим лицом
|
||||
на условиях простой (неисключительной) безвозмездной безотзывной лицензии, полностью
|
||||
или фрагментарно, в составе Программы или других программ, продуктов или сервисов
|
||||
как с открытым, так и с закрытым исходным кодом, любыми способами, не противоречащими
|
||||
закону, включая, но не ограничиваясь следующими: \
|
||||
2.2.1. Запускать и использовать Доработки для выполнения любых задач; \
|
||||
2.2.2. Распространять, импортировать и доводить Доработки до всеобщего сведения; \
|
||||
2.2.3. Вносить в Доработки изменения, сокращения и дополнения, снабжать Доработки
|
||||
при их использовании комментариями, иллюстрациями или пояснениями; \
|
||||
2.2.4. Создавать на основе Доработок иные результаты интеллектуальной деятельности,
|
||||
в том числе производные и составные произведения; \
|
||||
2.2.5. Переводить Доработки на другие языки, в том числе на другие языки программирования; \
|
||||
2.2.6. Осуществлять прокат и публичный показ Доработок; \
|
||||
2.2.7. Использовать Доработки под любым фирменным наименованием, товарным знаком
|
||||
(знаком обслуживания) или иным обозначением, или без такового. \
|
||||
2.3. Участник предоставляет Автору право сублицензировать полученные права на Доработки
|
||||
третьим лицам на любых условиях на усмотрение Автора. \
|
||||
2.4. Участник предоставляет Автору права на Доработки на территории всего мира. \
|
||||
2.5. Участник предоставляет Автору права на весь срок действия исключительного права
|
||||
Участника на Доработки. \
|
||||
2.6. Участник предоставляет Автору права на Доработки на безвозмездной основе. \
|
||||
2.7. Участник разрешает Автору самостоятельно определять порядок, способ и
|
||||
место указания его имени, реквизитов и/или псевдонима при включении
|
||||
Доработок в состав Программы или других программ, продуктов или сервисов.
|
||||
|
||||
3. Акцепт Оферты \
|
||||
3.1. Участник может передавать Доработки в адрес Автора через зеркала официального
|
||||
Репозитория Программы по адресам https://git.yourcmc.ru/vitalif/vitastor/ или
|
||||
https://github.com/vitalif/vitastor/ в виде “запроса на слияние” (pull request),
|
||||
либо в письменном виде или с помощью любых других электронных средств коммуникации,
|
||||
например, электронной почты или мессенджеров. \
|
||||
3.2. Факт передачи Участником Доработок в адрес Автора любым способом с одной из пометок
|
||||
“I accept Vitastor CLA agreement: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-en.md”
|
||||
или “Я принимаю соглашение Vitastor CLA: https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md”
|
||||
является полным и безоговорочным акцептом (принятием) Участником условий настоящей
|
||||
Оферты, т.е. Участник считается ознакомившимся с настоящим публичным договором и
|
||||
в соответствии с ГК РФ признается лицом, вступившим с Автором в договорные отношения
|
||||
на основании настоящей Оферты. \
|
||||
3.3. Датой акцептирования настоящей Оферты считается дата такой передачи.
|
||||
|
||||
4. Права и обязанности Сторон \
|
||||
4.1. Участник сохраняет за собой право использовать Доработки любым законным
|
||||
способом, не противоречащим настоящему Договору. \
|
||||
4.2. Автор вправе отказать Участнику во включении Доработок в состав
|
||||
Программы без объяснения причин в любой момент по своему усмотрению.
|
||||
|
||||
5. Гарантии и заверения \
|
||||
5.1. Лицо, направляющее Доработки для целей их включения в состав Программы,
|
||||
гарантирует, что является Участником или представителем Участника. Имя или реквизиты
|
||||
Участника должны быть указаны при их передаче в адрес Автора Программы. \
|
||||
5.2. Участник гарантирует, что является законным обладателем исключительных прав
|
||||
на Доработки. \
|
||||
5.3. Участник гарантирует, что на момент акцептирования настоящей Оферты ему
|
||||
ничего не известно (и не могло быть известно) о правах третьих лиц на
|
||||
передаваемые Автору Доработки или их часть, которые могут быть нарушены
|
||||
в связи с передачей Доработок по настоящему Договору. \
|
||||
5.4. Участник гарантирует, что является дееспособным лицом и обладает всеми
|
||||
необходимыми правами для заключения Договора. \
|
||||
5.5. Участник гарантирует, что Доработки не содержат вредоносного ПО, а также
|
||||
любой другой информации, запрещённой к распространению по законам Российской
|
||||
Федерации.
|
||||
|
||||
6. Прекращение действия оферты \
|
||||
6.1. Действие настоящего договора может быть прекращено по соглашению сторон,
|
||||
оформленному в письменном виде, а также вследствие его расторжения по основаниям,
|
||||
предусмотренным законом.
|
||||
|
||||
7. Заключительные положения \
|
||||
7.1. Участник вправе по желанию подписать настоящий Договор в письменном виде. \
|
||||
7.2. Настоящий договор действует с момента его заключения и до истечения срока
|
||||
действия исключительных прав Участника на Доработки. \
|
||||
7.3. Автор имеет право в одностороннем порядке вносить изменения и дополнения в договор
|
||||
без специального уведомления об этом Участников. Новая редакция документа вступает
|
||||
в силу через 3 (Три) календарных дня со дня опубликования в официальном Репозитории
|
||||
Программы по адресу в сети Интернет
|
||||
[https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md](https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/CLA-ru.md).
|
||||
Участники самостоятельно отслеживают действующие условия Оферты. \
|
||||
7.4. Все споры, возникающие между сторонами в процессе их взаимодействия по настоящему
|
||||
договору, решаются путём переговоров. В случае невозможности урегулирования споров
|
||||
переговорным порядком стороны разрешают их в Арбитражном суде г.Москвы.
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
cmake_minimum_required(VERSION 2.8.12)
|
||||
cmake_minimum_required(VERSION 2.8)
|
||||
|
||||
project(vitastor)
|
||||
|
||||
set(VITASTOR_VERSION "1.10.0")
|
||||
set(VERSION "0.6.17")
|
||||
|
||||
add_subdirectory(src)
|
||||
|
|
|
|||
23
README-ru.md
23
README-ru.md
|
|
@ -1,4 +1,4 @@
|
|||
# Vitastor
|
||||
## Vitastor
|
||||
|
||||
[Read English version](README.md)
|
||||
|
||||
|
|
@ -6,8 +6,8 @@
|
|||
|
||||
Вернём былую скорость кластерному блочному хранилищу!
|
||||
|
||||
Vitastor - распределённая блочная и файловая SDS (программная СХД), прямой аналог Ceph RBD и CephFS,
|
||||
а также внутренних СХД популярных облачных провайдеров. Однако, в отличие от них, Vitastor
|
||||
Vitastor - распределённая блочная SDS (программная СХД), прямой аналог Ceph RBD и
|
||||
внутренних СХД популярных облачных провайдеров. Однако, в отличие от них, Vitastor
|
||||
быстрый и при этом простой. Только пока маленький :-).
|
||||
|
||||
Vitastor архитектурно похож на Ceph, что означает атомарность и строгую консистентность,
|
||||
|
|
@ -15,14 +15,14 @@ Vitastor архитектурно похож на Ceph, что означает
|
|||
и автоматическое распределение данных по любому числу дисков любого размера с настраиваемыми схемами
|
||||
избыточности - репликацией или с произвольными кодами коррекции ошибок.
|
||||
|
||||
Vitastor нацелен в первую очередь на SSD и SSD+HDD кластеры с как минимум 10 Гбит/с сетью, поддерживает
|
||||
Vitastor нацелен на SSD и SSD+HDD кластеры с как минимум 10 Гбит/с сетью, поддерживает
|
||||
TCP и RDMA и на хорошем железе может достигать задержки 4 КБ чтения и записи на уровне ~0.1 мс,
|
||||
что примерно в 10 раз быстрее, чем Ceph и другие популярные программные СХД.
|
||||
|
||||
Vitastor поддерживает QEMU-драйвер, протоколы NBD и NFS, драйверы OpenStack, OpenNebula, Proxmox, Kubernetes.
|
||||
Vitastor поддерживает QEMU-драйвер, протоколы NBD и NFS, драйверы OpenStack, Proxmox, Kubernetes.
|
||||
Другие драйверы могут также быть легко реализованы.
|
||||
|
||||
Подробности смотрите в документации по ссылкам. Можете начать отсюда: [Быстрый старт](docs/intro/quickstart.ru.md).
|
||||
Подробности смотрите в документации по ссылкам ниже.
|
||||
|
||||
## Презентации и записи докладов
|
||||
|
||||
|
|
@ -42,7 +42,6 @@ Vitastor поддерживает QEMU-драйвер, протоколы NBD и
|
|||
- Установка
|
||||
- [Пакеты](docs/installation/packages.ru.md)
|
||||
- [Proxmox](docs/installation/proxmox.ru.md)
|
||||
- [OpenNebula](docs/installation/opennebula.ru.md)
|
||||
- [OpenStack](docs/installation/openstack.ru.md)
|
||||
- [Kubernetes CSI](docs/installation/kubernetes.ru.md)
|
||||
- [Сборка из исходных кодов](docs/installation/source.ru.md)
|
||||
|
|
@ -51,7 +50,6 @@ Vitastor поддерживает QEMU-драйвер, протоколы NBD и
|
|||
- Параметры
|
||||
- [Общие](docs/config/common.ru.md)
|
||||
- [Сетевые](docs/config/network.ru.md)
|
||||
- [Клиентский код](docs/config/client.ru.md)
|
||||
- [Глобальные дисковые параметры](docs/config/layout-cluster.ru.md)
|
||||
- [Дисковые параметры OSD](docs/config/layout-osd.ru.md)
|
||||
- [Прочие параметры OSD](docs/config/osd.ru.md)
|
||||
|
|
@ -60,17 +58,14 @@ Vitastor поддерживает QEMU-драйвер, протоколы NBD и
|
|||
- [Метаданные образов в etcd](docs/config/inode.ru.md)
|
||||
- Использование
|
||||
- [vitastor-cli](docs/usage/cli.ru.md) (консольный интерфейс)
|
||||
- [vitastor-disk](docs/usage/disk.ru.md) (управление дисками)
|
||||
- [fio](docs/usage/fio.ru.md) для тестов производительности
|
||||
- [NBD](docs/usage/nbd.ru.md) для монтирования ядром
|
||||
- [QEMU и qemu-img](docs/usage/qemu.ru.md)
|
||||
- [NFS](docs/usage/nfs.ru.md) кластерная файловая система и псевдо-ФС прокси
|
||||
- [Администрирование](docs/usage/admin.ru.md)
|
||||
- [NFS](docs/usage/nfs.ru.md)-прокси для VMWare и подобных
|
||||
- Производительность
|
||||
- [Понимание сути производительности](docs/performance/understanding.ru.md)
|
||||
- [Теоретический максимум](docs/performance/theoretical.ru.md)
|
||||
- [Пример сравнения с Ceph](docs/performance/comparison1.ru.md)
|
||||
- [Более новый тест Vitastor 1.3.1](docs/performance/bench2.ru.md)
|
||||
|
||||
## Автор и лицензия
|
||||
|
||||
|
|
@ -101,5 +96,5 @@ Vitastor Network Public License 1.1, основанная на GNU GPL 3.0 с д
|
|||
и также на условиях GNU GPL 2.0 или более поздней версии. Так сделано в целях
|
||||
совместимости с таким ПО, как QEMU и fio.
|
||||
|
||||
Вы можете найти полный текст VNPL 1.1 на английском языке в файле [VNPL-1.1.txt](VNPL-1.1.txt),
|
||||
VNPL 1.1 на русском языке в файле [VNPL-1.1-RU.txt](VNPL-1.1-RU.txt), а GPL 2.0 в файле [GPL-2.0.txt](GPL-2.0.txt).
|
||||
Вы можете найти полный текст VNPL 1.1 в файле [VNPL-1.1.txt](VNPL-1.1.txt),
|
||||
а GPL 2.0 в файле [GPL-2.0.txt](GPL-2.0.txt).
|
||||
|
|
|
|||
21
README.md
21
README.md
|
|
@ -6,23 +6,23 @@
|
|||
|
||||
Make Clustered Block Storage Fast Again.
|
||||
|
||||
Vitastor is a distributed block and file SDS, direct replacement of Ceph RBD and CephFS,
|
||||
and also internal SDS's of public clouds. However, in contrast to them, Vitastor is fast
|
||||
and simple at the same time. The only thing is it's slightly young :-).
|
||||
Vitastor is a distributed block SDS, direct replacement of Ceph RBD and internal SDS's
|
||||
of public clouds. However, in contrast to them, Vitastor is fast and simple at the same time.
|
||||
The only thing is it's slightly young :-).
|
||||
|
||||
Vitastor is architecturally similar to Ceph which means strong consistency,
|
||||
primary-replication, symmetric clustering and automatic data distribution over any
|
||||
number of drives of any size with configurable redundancy (replication or erasure codes/XOR).
|
||||
|
||||
Vitastor targets primarily SSD and SSD+HDD clusters with at least 10 Gbit/s network,
|
||||
supports TCP and RDMA and may achieve 4 KB read and write latency as low as ~0.1 ms
|
||||
Vitastor targets SSD and SSD+HDD clusters with at least 10 Gbit/s network, supports
|
||||
TCP and RDMA and may achieve 4 KB read and write latency as low as ~0.1 ms
|
||||
with proper hardware which is ~10 times faster than other popular SDS's like Ceph
|
||||
or internal systems of public clouds.
|
||||
|
||||
Vitastor supports QEMU, NBD, NFS protocols, OpenStack, OpenNebula, Proxmox, Kubernetes drivers.
|
||||
Vitastor supports QEMU, NBD, NFS protocols, OpenStack, Proxmox, Kubernetes drivers.
|
||||
More drivers may be created easily.
|
||||
|
||||
Read more details in the documentation. You can start from here: [Quick Start](docs/intro/quickstart.en.md).
|
||||
Read more details below in the documentation.
|
||||
|
||||
## Talks and presentations
|
||||
|
||||
|
|
@ -42,7 +42,6 @@ Read more details in the documentation. You can start from here: [Quick Start](d
|
|||
- Installation
|
||||
- [Packages](docs/installation/packages.en.md)
|
||||
- [Proxmox](docs/installation/proxmox.en.md)
|
||||
- [OpenNebula](docs/installation/opennebula.en.md)
|
||||
- [OpenStack](docs/installation/openstack.en.md)
|
||||
- [Kubernetes CSI](docs/installation/kubernetes.en.md)
|
||||
- [Building from Source](docs/installation/source.en.md)
|
||||
|
|
@ -51,7 +50,6 @@ Read more details in the documentation. You can start from here: [Quick Start](d
|
|||
- Parameter Reference
|
||||
- [Common](docs/config/common.en.md)
|
||||
- [Network](docs/config/network.en.md)
|
||||
- [Client](docs/config/client.en.md)
|
||||
- [Global Disk Layout](docs/config/layout-cluster.en.md)
|
||||
- [OSD Disk Layout](docs/config/layout-osd.en.md)
|
||||
- [OSD Runtime Parameters](docs/config/osd.en.md)
|
||||
|
|
@ -60,17 +58,14 @@ Read more details in the documentation. You can start from here: [Quick Start](d
|
|||
- [Image metadata in etcd](docs/config/inode.en.md)
|
||||
- Usage
|
||||
- [vitastor-cli](docs/usage/cli.en.md) (command-line interface)
|
||||
- [vitastor-disk](docs/usage/disk.en.md) (disk management tool)
|
||||
- [fio](docs/usage/fio.en.md) for benchmarks
|
||||
- [NBD](docs/usage/nbd.en.md) for kernel mounts
|
||||
- [QEMU and qemu-img](docs/usage/qemu.en.md)
|
||||
- [NFS](docs/usage/nfs.en.md) clustered file system and pseudo-FS proxy
|
||||
- [Administration](docs/usage/admin.en.md)
|
||||
- [NFS](docs/usage/nfs.en.md) emulator for VMWare and similar
|
||||
- Performance
|
||||
- [Understanding storage performance](docs/performance/understanding.en.md)
|
||||
- [Theoretical performance](docs/performance/theoretical.en.md)
|
||||
- [Example comparison with Ceph](docs/performance/comparison1.en.md)
|
||||
- [Newer benchmark of Vitastor 1.3.1](docs/performance/bench2.en.md)
|
||||
|
||||
## Author and License
|
||||
|
||||
|
|
|
|||
680
VNPL-1.1-RU.txt
680
VNPL-1.1-RU.txt
|
|
@ -1,680 +0,0 @@
|
|||
СЕТЕВАЯ ПУБЛИЧНАЯ ЛИЦЕНЗИЯ VITASTOR
|
||||
VITASTOR NETWORK PUBLIC LICENSE
|
||||
Версия 1.1, от 6 февраля 2021
|
||||
|
||||
Автор лицензии: Виталий Филиппов <vitalif@yourcmc.ru>, 2021 год
|
||||
Каждый имеет право копировать и распространять точные копии этой
|
||||
лицензии, но без внесения изменений.
|
||||
|
||||
ПРЕАМБУЛА
|
||||
|
||||
Сетевая Публичная Лицензия Vitastor - это свободная "копилефт" лицензия для
|
||||
для программного обеспечения (ПО) и других видов произведений, специально
|
||||
разработанная, чтобы гарантировать кооперацию с сообществом при разработке
|
||||
сетевых приложений.
|
||||
|
||||
Большинство лицензий на программное обеспечение и другие произведения
|
||||
спроектированы так, чтобы лишить Вас свободы делиться ими и изменять их.
|
||||
Сетевая Публичная Лицензия Vitastor, напротив, разработана с целью
|
||||
гарантировать Ваше право распространять и вносить изменения во все версии
|
||||
программного обеспечения -- для уверенности, что ПО останется свободным для
|
||||
всех пользователей.
|
||||
|
||||
Когда мы говорим о свободном ПО, мы имеем в виду свободу использования, а не
|
||||
бесплатность. Свободные лицензии, такие, как Сетевая Публичная Лицензия
|
||||
Vitastor, составлены для того, чтобы убедиться, что у Вас есть право
|
||||
распространять копии свободного ПО (и взимать плату за них, если Вы хотите),
|
||||
что Вы получаете исходные тексты или можете получить их, если захотите, что Вы
|
||||
можете изменять программное обеспечение или использовать его части в новых
|
||||
свободных программах, и что Вы знаете о своем праве делать всё это.
|
||||
|
||||
Разработчики, использующие Сетевую Публичную Лицензию Vitastor, гарантируют
|
||||
Ваши права при помощи следующих мер: (1) закрепляют авторское право на
|
||||
программное обеспечение, и (2) предлагают Вам принять условия настоящей
|
||||
Лицензии, закрепляющей Ваше право на создание копий, распространение и (или)
|
||||
модификацию программного обеспечения.
|
||||
|
||||
Еще одно преимущество защиты свободы всех пользователей заключается в том,
|
||||
что улучшения, сделанные в разных версиях программы, при их широком
|
||||
распространении становятся доступными для использования другими разработчиками.
|
||||
Многие разработчики программного обеспечения воодушевляются этим
|
||||
сотрудничеством и пользуются его преимуществами. Однако, если программное
|
||||
обеспечение используется на сетевых серверах, данный результат не всегда
|
||||
достигается. Генеральная публичная лицензия GNU разрешает создание измененных
|
||||
версий и предоставление неограниченного доступа к ним, не делая общедоступным
|
||||
их исходный текст. Даже генеральная публичная лицензия GNU Affero разрешает
|
||||
использование модифицированной версии свободной программы в закрытой среде, где
|
||||
внешние пользователи взаимодействуют с ней только через закрытый промежуточный
|
||||
интерфейс (прокси), опять же, без открытия в свободный публичный доступ как
|
||||
самой программы, так и прокси.
|
||||
|
||||
Сетевая Публичная Лицензия Vitastor разработана специально, чтобы
|
||||
гарантировать, что в таких случаях и модифицированная версия программы, и
|
||||
прокси останутся доступными сообществу. Для этого лицензия требует от
|
||||
операторов сетевых серверов предоставлять исходный код оригинальной программы,
|
||||
а также всех других программ, взаимодействующих с ней на их серверах,
|
||||
пользователям этих серверов, на условиях свободных лицензий. Таким образом,
|
||||
публичное использование изменённой версии ПО на сервере, прямо или косвенно
|
||||
доступном пользователям, даёт пользователям доступ к исходным кодам изменённой
|
||||
версии.
|
||||
|
||||
Детальные определения используемых терминов и описание условий копирования,
|
||||
распространения и внесения изменений приведены ниже.
|
||||
|
||||
ТЕРМИНЫ И УСЛОВИЯ
|
||||
|
||||
0. Определения.
|
||||
|
||||
"Настоящая Лицензия" -- версия 1.1 Сетевой Публичной Лицензии Vitastor.
|
||||
|
||||
Под "Авторским правом" понимаются все законы, сходные с авторско-правовыми,
|
||||
которые применяются к любым видам работ, например, к топологиям микросхем.
|
||||
|
||||
Термином "Программа" обозначается любое охраноспособное произведение,
|
||||
используемое в соответствии с настоящей Лицензией. Лицензиат именуется "Вы".
|
||||
"Лицензиаты" и "получатели" могут быть как физическими лицами, так и
|
||||
организациями.
|
||||
|
||||
"Внесение изменений" в произведение означает копирование или адаптацию
|
||||
произведения целиком или в части, способом, требующим разрешения
|
||||
правообладателя, за исключением изготовления его точной копии. Получившееся
|
||||
произведение называется "измененной версией" предыдущего произведения или
|
||||
произведением, "основанным на" более ранней работе.
|
||||
|
||||
Термином "Лицензионное произведение" обозначается неизмененная Программа или
|
||||
произведение, основанное на Программе.
|
||||
|
||||
"Распространение" произведения означает совершение с ним действий, которые
|
||||
при отсутствии разрешения сделают Вас прямо или косвенно ответственным за
|
||||
нарушение действующего закона об авторском праве, за исключением запуска на
|
||||
компьютере или изменения копии, созданной в личных целях. Распространение
|
||||
включает в себя копирование, раздачу копий (с изменениями или без них),
|
||||
доведение до всеобщего сведения, а в некоторых странах -- и другие действия.
|
||||
|
||||
"Передача" произведения означает любой вид распространения, который позволяет
|
||||
другим лицам создавать или получать копии произведения. Обычное взаимодействие
|
||||
с пользователем через компьютерную сеть без создания копии передачей не
|
||||
является.
|
||||
|
||||
Интерактивный интерфейс пользователя должен отображать "Информация об
|
||||
авторском праве", достаточную для того, чтобы (1) обеспечить отображение
|
||||
соответствующего уведомления об авторских правах и (2) сообщить пользователю
|
||||
о том, что ему не предоставляются никакие гарантии на произведение (за
|
||||
исключением явным образом предоставленных гарантий), о том, что лицензиаты
|
||||
могут передавать произведение на условиях, описанных в настоящей Лицензии,
|
||||
а также о том, как ознакомиться с текстом настоящей Лицензии. Если интерфейс
|
||||
предоставляет собой список пользовательских команд или настроек, наподобие
|
||||
меню, это требование считается выполненным при наличии явно выделенного
|
||||
пункта в таком меню.
|
||||
|
||||
1. Исходный текст.
|
||||
|
||||
Под "Исходным текстом" понимается произведение в форме, которая более всего
|
||||
подходит для внесения в него изменений. "Объектным кодом" называется
|
||||
произведение в любой иной форме.
|
||||
|
||||
"Стандартный интерфейс" -- интерфейс, который либо является общепринятым
|
||||
стандартом, введенным общепризнанным органом по стандартизации, либо, в случае
|
||||
интерфейсов, характерных для конкретного языка программирования -- тот,
|
||||
который широко используется разработчиками, пишущими программы на этом языке.
|
||||
|
||||
"Системные библиотеки" исполняемого произведения включают в себя то, что не
|
||||
относится к произведению в целом и при этом (a) входит в обычный комплект
|
||||
Основного компонента, но при этом не является его частью и (b) служит только
|
||||
для обеспечения работы с этим Основным компонентом или для реализации
|
||||
Стандартного интерфейса, для которого существует общедоступная реализация,
|
||||
опубликованная в виде исходного текста. "Основным компонентом" в данном
|
||||
контексте назван главный существенный компонент (ядро, оконная система и т.д.)
|
||||
определенной операционной системы (если она используется), под управлением
|
||||
которой функционирует исполняемое произведение, либо компилятор, используемый
|
||||
для создания произведения или интерпретатор объектного кода, используемый для
|
||||
его запуска.
|
||||
|
||||
"Полный исходный текст" для произведения в форме объектного кода -- весь
|
||||
исходный текст, необходимый для создания, установки и (для исполняемого
|
||||
произведения) функционирования объектного кода, а также модификации
|
||||
произведения, включая сценарии, контролирующие эти действия. Однако он не
|
||||
включает в себя Системные библиотеки, необходимые для функционирования
|
||||
произведения, инструменты общего назначения или общедоступные свободные
|
||||
программы, которые используются в неизменном виде для выполнения этих
|
||||
действий, но не являются частью произведения. Полный исходный текст включает
|
||||
в себя, например, файлы описания интерфейса, прилагаемые к файлам исходного
|
||||
текста произведения, а также исходные тексты общих библиотек и динамически
|
||||
связанных подпрограмм, которые требуются для функционирования произведения
|
||||
и разработаны специально для этого, например, для прямой передачи данных
|
||||
или управления потоками между этими подпрограммами и другими частями
|
||||
произведения. Полный исходный текст не включает в себя то, что пользователи
|
||||
могут сгенерировать автоматически из других частей Полного исходного текста.
|
||||
Полным исходным текстом для произведения в форме исходных текстов является
|
||||
само это произведение.
|
||||
|
||||
2. Основные права.
|
||||
|
||||
Все права, предоставленные на основании настоящей Лицензии, действуют в
|
||||
течение срока действия авторских прав на Программу и не могут быть отозваны
|
||||
при условии, что сформулированные в ней условия соблюдены. Настоящая Лицензия
|
||||
однозначно подтверждает Ваши неограниченные права на запуск неизмененной
|
||||
Программы. Настоящая Лицензия распространяется на результаты функционирования
|
||||
Лицензионного произведения только в том случае, если они, учитывая их
|
||||
содержание, сами являются частью Лицензионного произведения. Настоящая
|
||||
Лицензия подтверждает Ваши права на свободное использование произведения
|
||||
или другие аналогичные полномочия, предусмотренные действующим
|
||||
законодательством об авторском праве.
|
||||
|
||||
Если Вы не осуществляете обычную передачу Лицензионного произведения, то
|
||||
можете как угодно создавать, запускать и распространять его копии до тех пор,
|
||||
пока ваша Лицензия сохраняет силу. Вы можете передавать Лицензионные
|
||||
произведения третьим лицам исключительно для того, чтобы они внесли в них
|
||||
изменения для Вас или предоставили Вам возможность их запуска, при условии,
|
||||
что Вы соглашаетесь с условиями настоящей Лицензии при передаче всех
|
||||
материалов, авторскими правами на которые Вы не обладаете. Лица, создающие
|
||||
или запускающие Лицензионные произведения для Вас, должны делать это
|
||||
исключительно от Вашего имени, под Вашим руководством и контролем, на
|
||||
условиях, которые запрещают им создание без Вашей санкции каких-либо копий
|
||||
материалов, на которые Вы обладаете авторским правом.
|
||||
|
||||
Любая другая передача разрешается исключительно при соблюдении описанных
|
||||
ниже условий. Сублицензирование не допускается; раздел 10 делает его не нужным.
|
||||
|
||||
3. Защита прав пользователей от законов, запрещающих обход технических средств.
|
||||
|
||||
Ни одно Лицензионное произведение не должно считаться содержащим эффективные
|
||||
технические средства, удовлетворяющие требованиям любого действующего закона,
|
||||
принятого для исполнения обязательств, предусмотренных статьей 11 Договора ВОИС
|
||||
по авторскому праву от 20 декабря 1996 года или аналогичных законов,
|
||||
запрещающих или ограничивающих обход таких технических средств.
|
||||
|
||||
При передаче Лицензионного произведения Вы отказываетесь от всех
|
||||
предоставляемых законом полномочий по запрету обхода технических средств,
|
||||
используемых авторами в связи с осуществлением их прав, признавая, что такой
|
||||
обход находится в рамках осуществления прав на использование Лицензионного
|
||||
произведения, предоставленных настоящей Лицензией; также Вы отказываетесь
|
||||
от любых попыток ограничить функционирование произведения или внесение в него
|
||||
изменений, направленных на реализацию предоставленных Вам законом прав на
|
||||
запрет пользователю обхода технических средств.
|
||||
|
||||
4. Передача неизмененных копий.
|
||||
|
||||
Вы можете передавать точные копии исходных текстов Программы в том виде,
|
||||
в котором Вы их получили, на любом носителе, при условии, что Вы прилагаете
|
||||
к каждой копии соответствующее уведомление об авторских правах способом,
|
||||
обеспечивающим ознакомление с ним пользователя; сохраняете все уведомления
|
||||
о том, что к тексту применима настоящая Лицензия и любые ограничения,
|
||||
добавленные в соответствии с разделом 7; сохраняете все уведомления об
|
||||
отсутствии каких-либо гарантий; предоставляете всем получателям вместе с
|
||||
Программой копию настоящей Лицензии.
|
||||
|
||||
Вы можете установить любую цену за каждую копию, которую Вы передаете,
|
||||
или распространять копии бесплатно; также Вы можете предложить поддержку
|
||||
или гарантию за отдельную плату.
|
||||
|
||||
5. Передача измененных исходных текстов.
|
||||
|
||||
Вы можете передавать исходный текст произведения, основанного на Программе,
|
||||
или изменений, необходимых для того, чтобы получить его из Программы, на
|
||||
условиях, описанных в разделе 4, при соблюдении следующих условий:
|
||||
|
||||
а) Произведение должно содержать уведомления о произведенных Вами
|
||||
изменениях с указанием их даты, сделанные способом, обеспечивающим
|
||||
ознакомление с ними пользователя.
|
||||
|
||||
b) Произведение должно содержать уведомление о том, что оно
|
||||
распространяется на условиях настоящей Лицензии, а также об условиях,
|
||||
добавленных в соответствии с разделом 7, сделанное способом,
|
||||
обеспечивающим ознакомление с ним пользователя. Данное требование имеет
|
||||
приоритет над требованиями раздела 4 "оставлять нетронутыми все
|
||||
уведомления".
|
||||
|
||||
c) Вы должны передать на условиях настоящей Лицензии всю работу целиком
|
||||
любому лицу, которое приобретает копию. Таким образом, настоящая Лицензия
|
||||
вместе с любыми применимыми условиями раздела 7 будет применяться к
|
||||
произведению в целом и всем его частям, независимо от их комплектности.
|
||||
Настоящая Лицензия не дает права на лицензирование произведения на любых
|
||||
других условиях, но это не лишает законной силы такое разрешение, если Вы
|
||||
получили его отдельно.
|
||||
|
||||
d) Если произведение имеет интерактивные пользовательские интерфейсы,
|
||||
каждый из них должен отображать Информацию об авторском праве; однако,
|
||||
если Программа имеет пользовательские интерфейсы, которые не отображают
|
||||
информацию об авторском праве, от Вашего произведения этого также не
|
||||
требуется.
|
||||
|
||||
Включение Лицензионного произведения в подборку на разделе хранения данных
|
||||
или на носителе, на котором распространяется произведение, вместе с другими
|
||||
отдельными самостоятельными произведениями, которые по своей природе не
|
||||
являются переработкой Лицензионного произведения и не объединены с ним,
|
||||
например, в программный комплекс, называется "набором", если авторские права
|
||||
на подборку не используются для ограничения доступа к ней или законных прав
|
||||
её пользователей сверх того, что предусматривают лицензии на отдельные
|
||||
произведения. Включение Лицензионного произведения в набор не влечет применения
|
||||
положений настоящей Лицензии к остальным его частям.
|
||||
|
||||
6. Передача произведения в формах, не относящихся к исходному тексту.
|
||||
|
||||
Вы можете передавать Лицензионное произведение в виде объектного кода в
|
||||
соответствии с положениями разделов 4 и 5, при условии, что Вы также передаете
|
||||
машиночитаемый Полный исходный текст в соответствии с условиями настоящей
|
||||
Лицензии, одним из следующих способов:
|
||||
|
||||
а) Передавая объектный код или содержащий его материальный продукт (включая
|
||||
распределенный материальный носитель), с приложением Полного исходного
|
||||
текста наматериальном носителе, обычно используемом для обмена программным
|
||||
обеспечением.
|
||||
|
||||
b) Передавая объектный код или содержащий его материальный продукт (включая
|
||||
носитель, на котором распространяется произведение), с письменным
|
||||
предложением, действительным в течение не менее трех лет либо до тех пор,
|
||||
пока Вы предоставляете запасные части или поддержку для данного продукта,
|
||||
о передаче любому обладателю объектного кода (1) копии Полного исходного
|
||||
текста для всего программного обеспечения, содержащегося в продукте, на
|
||||
которое распространяется действие настоящей Лицензии, на физическом
|
||||
носителе, обычно используемом для обмена программным обеспечением, по цене,
|
||||
не превышающей разумных затрат на передачу копии, или (2) доступа к Полному
|
||||
исходному тексту с возможностью его копирования с сетевого сервера без
|
||||
взимания платы.
|
||||
|
||||
с) Передавая отдельные копии объектного кода с письменной копией предложения
|
||||
о предоставлении Полного исходного текста. Этот вариант допускается только
|
||||
в отдельных случаях при распространении без извлечения прибыли, и только
|
||||
если Вы получили объектный код с таким предложением в соответствии
|
||||
с пунктом 6b.
|
||||
|
||||
d) Передавая объектный код посредством предоставления доступа к нему по
|
||||
определенному адресу (бесплатно или за дополнительную плату), и предлагая
|
||||
эквивалентный доступ к Полному исходному тексту таким же способом по тому же
|
||||
адресу без какой-либо дополнительной оплаты. От Вас не требуется принуждать
|
||||
получателей копировать Полный исходный текст вместе с объектным кодом. Если
|
||||
объектный код размещен на сетевом сервере, Полный исходный текст может
|
||||
находиться на другом сервере (управляемом Вами или третьим лицом), который
|
||||
предоставляет аналогичную возможность копирования; при этом Вы должны четко
|
||||
указать рядом с объектным кодом способ получения Полного исходного текста.
|
||||
Независимо от того, на каком сервере расположен Полный исходный текст, Вы
|
||||
обязаны убедиться в том, что он будет распространяться в течение времени,
|
||||
необходимого для соблюдения этих требований.
|
||||
|
||||
e) Передавая объектный код с использованием одноранговой (пиринговой) сети,
|
||||
при условии информирования других пользователей сети о том, где можно
|
||||
бесплатно получить объектный код и Полный исходный текст произведения
|
||||
способом, описанным в пункте 6d.
|
||||
|
||||
Не нужно включать в передаваемый объектный код его отделимые части, исходные
|
||||
тексты которых не входят в состав Полного исходного текста, такие как Системные
|
||||
библиотеки.
|
||||
|
||||
"Потребительский товар" это либо (1) "товар, предназначенный для личных нужд",
|
||||
под которым понимается любое материальное личное имущество, которое обычно
|
||||
используется для личных, семейных или домашних целей, или (2) что-либо
|
||||
спроектированное или продающееся для использования в жилище. При определении
|
||||
того, предназначен ли товар для личных нужд, сомнения должны толковаться в
|
||||
пользу положительного ответа на этот вопрос. Применительно к конкретному
|
||||
товару, используемому конкретным пользователем, под выражением "обычно
|
||||
используется" имеется в виду способ, которым данный вид товаров преимущественно
|
||||
или как правило используется, независимо от статуса конкретного пользователя
|
||||
или способа, которым конкретный пользователь использует, предполагает или
|
||||
будет использовать товар. Товар относится к предназначенным для личных нужд
|
||||
независимо от того, насколько часто он используется в коммерческой
|
||||
деятельности, промышленности или иной сфере, не относящейся к личным нуждам,
|
||||
за исключением случая, когда использование в этой сфере представляет собой
|
||||
единственный основной способ использования такого товара.
|
||||
|
||||
"Информация, необходимая для установки" Потребительского товара -- любые
|
||||
методы, процедуры, сведения, необходимые для авторизации, или другая
|
||||
информация, необходимая для установки и запуска в Потребительском товаре
|
||||
измененных версий Лицензионного произведения, полученных при изменении
|
||||
Полного исходного текста. Данная информация должна быть достаточной для
|
||||
того, чтобы обеспечить возможность внесения в исходный текст изменений,
|
||||
не приводящих к ограничению или нарушению его дальнейшей работоспособности.
|
||||
|
||||
Если вместе с Потребительским товаром или специально для использования
|
||||
в нём Вы передаете произведение в виде объектного кода на условиях, описанных
|
||||
в данном разделе, и такая передача является частью сделки, по которой право
|
||||
владения и пользования Потребительским товаром переходит к получателю
|
||||
пожизненно или на определенный срок (независимо от признаков сделки), Полный
|
||||
исходный текст, передаваемый согласно данному разделу, должен сопровождаться
|
||||
Информацией, необходимой для установки. Но это требование не применяется,
|
||||
если ни Вы, ни какое-либо третье лицо не сохраняет за собой возможности
|
||||
установки измененного объектного кода на Потребительский товар (например,
|
||||
произведение было установлено в постоянную память).
|
||||
|
||||
Требование о предоставлении Информации, необходимой для установки, не
|
||||
включает в себя требование продолжения оказания услуг по поддержке,
|
||||
предоставления гарантии или обновлений для произведения, которое было изменено
|
||||
или установлено получателем, либо для Потребительского товара, в котором оно
|
||||
было изменено или на который оно было установлено. В доступе к сети может быть
|
||||
отказано, если само внесение изменений существенно и негативно влияет на
|
||||
работу сети, нарушает правила обмена данными или не поддерживает протоколы для
|
||||
обмена данными по сети.
|
||||
|
||||
Передаваемый в соответствии с данным разделом Полный исходный текст и
|
||||
предоставленная Информация, необходимая для установки, должны быть записаны в
|
||||
формате, который имеет общедоступное описание (и общедоступную реализацию,
|
||||
опубликованную в форме исходного текста) и не должны требовать никаких
|
||||
специальных паролей или ключей для распаковки, чтения или копирования.
|
||||
|
||||
7. Дополнительные условия.
|
||||
|
||||
"Дополнительными разрешениями" называются условия, которые дополняют условия
|
||||
настоящей Лицензии, делая исключения из одного или нескольких её положений.
|
||||
Дополнительные разрешения, которые применимы ко всей Программе, должны
|
||||
рассматриваться как часть настоящей Лицензии, в той степени, в которой они
|
||||
соответствуют действующему законодательству. Если дополнительные разрешения
|
||||
применяются только к части Программы, эта часть может быть использована отдельно
|
||||
на измененных условиях, но вся Программа продолжает использоваться на условиях
|
||||
настоящей Лицензии без учета дополнительных разрешений.
|
||||
|
||||
Когда Вы передаете копию Лицензионного произведения, Вы можете по своему
|
||||
усмотрению исключить любые дополнительные разрешения, примененные к этой копии
|
||||
или к любой её части. (Для дополнительных разрешений может быть заявлено
|
||||
требование об их удалении в определенных случаях, когда Вы вносите изменения в
|
||||
произведение.) Вы можете добавлять дополнительные разрешения к добавленным Вами
|
||||
в Лицензионное произведение материалам, на которые Вы обладаете авторскими
|
||||
правами или правом выдачи соответствующего разрешения.
|
||||
|
||||
Независимо от любых других положений настоящей Лицензии, Вы можете дополнить
|
||||
следующими условиями положения настоящей Лицензии в отношении материала,
|
||||
добавленного к Лицензионному произведению (если это разрешено обладателями
|
||||
авторских прав на материал):
|
||||
|
||||
a) отказом от гарантий или ограничением ответственности, отличающимися от
|
||||
тех, что описаны в разделах 15 и 16 настоящей Лицензии; либо
|
||||
|
||||
b) требованием сохранения соответствующей информации о правах или об
|
||||
авторстве материала, или включения её в Информацию об авторском праве,
|
||||
отображаемую содержащим его произведением; либо
|
||||
|
||||
c) запретом на искажение информации об источнике происхождения материала
|
||||
или требованием того, чтобы измененные версии такого материала содержали
|
||||
корректную отметку об отличиях от исходной версии; либо
|
||||
|
||||
d) ограничением использования в целях рекламы имен лицензиаров или авторов
|
||||
материала; либо
|
||||
|
||||
e) отказом от предоставления прав на использование в качестве товарных
|
||||
знаков некоторых торговых наименований, товарных знаков или знаков
|
||||
обслуживания; либо
|
||||
|
||||
f) требованием от каждого, кто по договору передает материал (или его
|
||||
измененные версии), предоставления компенсации лицензиарам и авторам
|
||||
материала в виде принятия на себя любой ответственности, которую этот
|
||||
договор налагает на лицензиаров и авторов.
|
||||
|
||||
Все остальные ограничительные дополнительные условия считаются "дополнительными
|
||||
запретами" по смыслу раздела 10. Если программа, которую Вы получили, или любая
|
||||
её часть содержит уведомление о том, что наряду с настоящей Лицензией её
|
||||
использование регулируется условием, относящимся к дополнительным запретам, Вы
|
||||
можете удалить такое условие. Если лицензия содержит дополнительный запрет, но
|
||||
допускает лицензирование на измененных условиях или передачу в соответствии с
|
||||
настоящей Лицензией, Вы можете добавить к Лицензионному произведению материал,
|
||||
используемый на условиях такой лицензии, в том случае, если дополнительный
|
||||
запрет не сохраняется при таком изменении условий лицензии или передаче.
|
||||
|
||||
Если Вы добавляете условия для использования Лицензионного произведения в
|
||||
соответствии с настоящим разделом, Вы должны поместить в соответствующих файлах
|
||||
исходного текста уведомление о том, что к этим файлам применяются дополнительные
|
||||
условия, или указание на то, как ознакомиться с соответствующими условиями.
|
||||
|
||||
Дополнительные разрешающие или ограничивающие условия могут быть сформулированы
|
||||
в виде отдельной лицензии или зафиксированы как исключения; вышеуказанные
|
||||
требования применяются в любом случае.
|
||||
|
||||
8. Прекращение действия.
|
||||
|
||||
Вы не можете распространять Лицензионное произведение или вносить в него
|
||||
изменения на условиях, отличающихся от явно оговоренных в настоящей Лицензии.
|
||||
Любая попытка распространения или внесения изменений на иных условиях является
|
||||
ничтожной и автоматически прекращает Ваши права, полученные по настоящей
|
||||
Лицензии (включая лицензию на любые патенты, предоставленные согласно третьему
|
||||
пункту раздела 11).
|
||||
|
||||
Тем не менее если Вы прекращаете нарушение настоящей Лицензии, Ваши права,
|
||||
полученные от конкретного правообладателя, восстанавливаются (а) временно, до
|
||||
тех пор пока правообладатель явно и окончательно не прекратит действие Ваших
|
||||
прав, и (б) навсегда, если правообладатель не уведомит Вас о нарушении с помощью
|
||||
надлежащих средств в течение 60 дней после прекращения нарушений.
|
||||
|
||||
Кроме того, Ваши права, полученные от конкретного правообладателя,
|
||||
восстанавливаются навсегда, если правообладатель впервые любым подходящим
|
||||
способом уведомляет Вас о нарушении настоящей Лицензии на свое произведение (для
|
||||
любого произведения) и Вы устраняете нарушение в течение 30 дней после получения
|
||||
уведомления.
|
||||
|
||||
Прекращение Ваших прав, описанное в настоящем разделе, не прекращает действие
|
||||
лицензий лиц, которые получили от Вас копии произведения или права,
|
||||
предоставляемые настоящей Лицензией. Если Ваши права были прекращены навсегда и
|
||||
не восстановлены, Вы не можете вновь получить право на тот же материал на
|
||||
условиях, описанных в разделе 10.
|
||||
|
||||
9. Акцепт не требуется для получения копий.
|
||||
|
||||
Вы не обязаны принимать условия настоящей Лицензии для того, чтобы получить или
|
||||
запустить копию Программы. Случайное распространение Лицензионного произведения,
|
||||
происходящее вследствие использования одноранговой (пиринговой) сети для
|
||||
получения его копии, также не требует принятия этих условий. Тем не менее только
|
||||
настоящая Лицензия дает Вам право распространять или изменять любое Лицензионное
|
||||
произведение. Если Вы не приняли условия настоящей Лицензии, такие действия
|
||||
будут нарушением авторского права. Поэтому изменяя или распространяя
|
||||
Лицензионное произведение, Вы выражаете согласие с условиями настоящей Лицензии.
|
||||
|
||||
10. Автоматическое получение прав последующими получателями.
|
||||
|
||||
Каждый раз, когда Вы передаете Лицензионное произведение, получатель
|
||||
автоматически получает от его лицензиара право запускать, изменять и
|
||||
распространять это произведение при условии соблюдения настоящей Лицензии. Вы не
|
||||
несете ответственности за соблюдение третьими лицами условий настоящей Лицензии.
|
||||
|
||||
"Реорганизацией" называются действия, в результате которых передается управление
|
||||
организацией или значительная часть её активов, а также происходит разделение
|
||||
или слияние организаций. Если распространение Лицензионного произведения
|
||||
является результатом реорганизации, каждая из сторон сделки, получающая копию
|
||||
произведения, также получает все права на произведение, которые предшествующее
|
||||
юридическое лицо имело или могло предоставить согласно предыдущему абзацу, а
|
||||
также право на владение Полным исходным текстом произведения от предшественника,
|
||||
осуществляемое в его интересах, если предшественник владеет им или может
|
||||
получить его при разумных усилиях.
|
||||
|
||||
Вы не можете налагать каких-либо дополнительных ограничений на осуществление
|
||||
прав, предоставленных или подтвержденных в соответствии с настоящей Лицензией.
|
||||
Например, Вы не можете ставить осуществление прав, предоставленных по настоящей
|
||||
Лицензии, в зависимость от оплаты отчислений, роялти или других сборов; также Вы
|
||||
не можете инициировать судебный процесс (включая встречный иск или заявление
|
||||
встречного требования в судебном процессе) о нарушении любых патентных прав при
|
||||
создании, использовании, продаже, предложении продажи, импорте Программы или
|
||||
любой её части.
|
||||
|
||||
11. Патенты.
|
||||
|
||||
"Инвестором" называется правообладатель, разрешающий использование Программы
|
||||
либо произведения, на котором основана Программа, на условиях настоящей
|
||||
Лицензии. Произведение, лицензированное таким образом, называется "версией со
|
||||
вкладом" инвестора.
|
||||
|
||||
"Неотъемлемые патентные претензии" инвестора -- все патентные права,
|
||||
принадлежащие инвестору или контролируемые им в настоящее время либо
|
||||
приобретенные в будущем, которые могут быть нарушены созданием, использованием
|
||||
или продажей версии со вкладом, допускаемыми настоящей Лицензией; они не
|
||||
включают в себя права, которые будут нарушены исключительно вследствие будущих
|
||||
изменений версии со вкладом. Для целей данного определения под "контролем"
|
||||
понимается право выдавать патентные сублицензии способами, не нарушающими
|
||||
требований настоящей Лицензии.
|
||||
|
||||
Каждый инвестор предоставляет Вам неисключительную безвозмездную лицензию на
|
||||
патент, действующую во всем мире, соответствующую неотъемлемым патентным
|
||||
претензиям инвестора, на создание, использование, продажу, предложение для
|
||||
продажи, импорт, а также запуск, внесение изменений и распространение всего, что
|
||||
входит в состав версии со вкладом.
|
||||
|
||||
В следующих трех абзацах "лицензией на патент" называется любое явно выраженное
|
||||
вовне согласие или обязательство не применять патент (например, выдача
|
||||
разрешения на использование запатентованного объекта или обещание не подавать в
|
||||
суд за нарушение патента). "Выдать" кому-то такую лицензию на патент означает
|
||||
заключить такое соглашение или обязаться не применять патент против него.
|
||||
|
||||
Если Вы передаете Лицензионное произведение, сознательно основываясь на лицензии
|
||||
на патент, в то время как Полный исходный текст произведения невозможно
|
||||
бесплатно скопировать с общедоступного сервера или другим не вызывающим
|
||||
затруднений способом, Вы должны либо (1) обеспечить возможность такого доступа к
|
||||
Полному исходному тексту, либо (2) отказаться от прав, предоставленных по
|
||||
лицензии на патент для данного произведения, либо (3) принять меры по передаче
|
||||
лицензии на патент последующим получателям произведения, в соответствии с
|
||||
требованиями настоящей Лицензии. "Сознательно основываясь" означает, что Вы
|
||||
знаете, что при отсутствии лицензии на патент передача Вами Лицензионного
|
||||
произведения в определенной стране или использование получателем переданного ему
|
||||
Вами Лицензионного произведения в этой стране нарушит один или несколько
|
||||
определенных патентов этой страны, срок действия которых не истек.
|
||||
|
||||
Если в соответствии или в связи с единичной сделкой либо соглашением Вы
|
||||
передаете или делаете заказ на распространение Лицензионного произведения, и
|
||||
предоставляете определенным лицам, получающим Лицензионное произведение,
|
||||
лицензию на патент, разрешающую им использовать, распространять, вносить
|
||||
изменения или передавать конкретные экземпляры Лицензионного произведения,
|
||||
права, которые Вы предоставляете по лицензии на патент, автоматически переходят
|
||||
ко всем получателям Лицензионного произведения и произведений, созданных на его
|
||||
основе.
|
||||
|
||||
Патентная лицензия называется "дискриминирующей", если она не покрывает,
|
||||
запрещает осуществление или содержит в качестве условия отказ от применения
|
||||
одного или нескольких прав, предоставленных настоящей Лицензией. Вы не можете
|
||||
передавать Лицензионное произведение, если Вы являетесь участником договора с
|
||||
третьим лицом, осуществляющим распространение программного обеспечения, в
|
||||
соответствии с которым Вы делаете в пользу третьего лица выплаты, размер которых
|
||||
зависит от масштабов Вашей деятельности по передаче произведения, и в
|
||||
соответствии с которым любое третье лицо, получающее от Вас Лицензионное
|
||||
произведение, делает это на условиях дискриминирующей патентной лицензии (а)
|
||||
которая зависит от количества копий Лицензионного произведения, переданных Вами
|
||||
(или копий, сделанных с этих копий), или (b) которая используется
|
||||
преимущественно в конкретных товарах или подборках, содержащих Лицензионное
|
||||
произведение, или в связи с ними, в том случае, если Вы заключили данный договор
|
||||
или получили лицензию на патент после 28 марта 2007 года.
|
||||
|
||||
Ничто в настоящей Лицензии не должно толковаться как исключение или ограничение
|
||||
любого предполагаемого права или других способов противодействия нарушениям,
|
||||
которые во всем остальном могут быть доступны для Вас в соответствии с
|
||||
применимым патентным правом.
|
||||
|
||||
12. Запрет отказывать в свободе другим.
|
||||
|
||||
Если на Вас наложены обязанности (будь то по решению суда, договору или иным
|
||||
способом), которые противоречат условиям настоящей Лицензии, это не освобождает
|
||||
Вас от соблюдения её условий. Если Вы не можете передать Лицензионное
|
||||
произведение так, чтобы одновременно выполнять Ваши обязательства по настоящей
|
||||
Лицензии и любые другие относящиеся к делу обязательства, то Вы не можете
|
||||
передавать его вообще. Например, если Вы согласны с условием, обязывающими Вас
|
||||
производить сбор отчислений за дальнейшую передачу от тех, кому Вы передаете
|
||||
Программу, то для того, чтобы соблюсти это условие и выполнить требования
|
||||
настоящей Лицензии, Вы должны полностью воздержаться от передачи Программы.
|
||||
|
||||
13. Удаленное сетевое взаимодействие.
|
||||
|
||||
Под "Прокси-программой" понимается отдельная программа, специально
|
||||
разработанная для использования совместно с Лицензионным произведением,
|
||||
и взаимодействующая с ним прямо или косвенно через любой вид программного
|
||||
интерфейса, компьютерную сеть, имитацию такой сети, или, в свою очередь,
|
||||
через другую Прокси-программу.
|
||||
|
||||
Независимо от любых других положений настоящей Лицензии, если вы
|
||||
предоставляете любому пользователю возможность взаимодействовать с Лицензионным
|
||||
произведением через компьютерную сеть, имитацию такой сети, или через любое
|
||||
количество "Прокси-программ", вы должны в явной форме предложить этому
|
||||
пользователю возможность получить Полный исходный текст Лицензионного
|
||||
произведения и всех Прокси-программ путём предоставления доступа к нему
|
||||
с сетевого сервера без взимания платы, посредством стандартных или
|
||||
традиционных способов, используемых для копирования программного обеспечения.
|
||||
Полный исходный текст Лицензионного произведения должен предоставляться
|
||||
пользователю на условиях настоящей Лицензии, а Полный исходный текст
|
||||
Прокси-программ должен предоставляться пользователю либо на условиях настоящей
|
||||
Лицензии, либо на условиях одной из свободных лицензий, совместимых с
|
||||
Генеральной публичной Лицензией GNU, перечисленных Фондом Свободного
|
||||
Программного Обеспечения в списке под названием "Лицензии свободных программ,
|
||||
совместимые с GPL".
|
||||
|
||||
14. Пересмотренные редакции настоящей Лицензии.
|
||||
|
||||
Автор настоящей Лицензии время от времени может публиковать пересмотренные
|
||||
и (или) новые редакции Сетевой Публичной Лицензии Vitastor. Они будут аналогичны
|
||||
по смыслу настоящей редакции, но могут отличаться от нее в деталях, направленных
|
||||
на решение новых проблем или регулирование новых отношений.
|
||||
|
||||
Каждой редакции присваивается собственный номер. Если для Программы указано,
|
||||
что к ней применима определенная редакция Сетевой Публичной Лицензии Vitastor
|
||||
"или любая более поздняя редакция", у Вас есть возможность использовать термины
|
||||
и условия, содержащиеся в редакции с указанным номером или любой более поздней
|
||||
редакции, опубликованной автором настоящей Лицензии. Если для Программы не
|
||||
указан номер редакции Сетевой Публичной Лицензии Vitastor, Вы можете выбрать
|
||||
любую редакцию, опубликованную автором настоящей Лицензии.
|
||||
|
||||
Более поздние редакции Лицензии могут дать Вам дополнительные или принципиально
|
||||
иные права. Тем не менее в результате Вашего выбора более поздней редакции на
|
||||
автора или правообладателя не возлагается никаких дополнительных обязанностей.
|
||||
|
||||
15. Отказ от гарантий.
|
||||
|
||||
НА ПРОГРАММУ НЕ ПРЕДОСТАВЛЯЕТСЯ НИКАКИХ ГАРАНТИЙ ЗА ИСКЛЮЧЕНИЕМ ПРЕДУСМОТРЕННЫХ
|
||||
ДЕЙСТВУЮЩИМ ЗАКОНОДАТЕЛЬСТВОМ. ЕСЛИ ИНОЕ НЕ УКАЗАНО В ПИСЬМЕННОЙ ФОРМЕ,
|
||||
ПРАВООБЛАДАТЕЛИ И (ИЛИ) ТРЕТЬИ ЛИЦА ПРЕДОСТАВЛЯЮТ ПРОГРАММУ "КАК ЕСТЬ", БЕЗ
|
||||
КАКИХ-ЛИБО ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ
|
||||
КОНКРЕТНЫХ ЦЕЛЕЙ, НО НЕ ОГРАНИЧИВАЯСЬ ИМИ. ВЕСЬ РИСК, СВЯЗАННЫЙ С КАЧЕСТВОМ И
|
||||
ПРОИЗВОДИТЕЛЬНОСТЬЮ ПРОГРАММЫ, ВОЗЛАГАЕТСЯ НА ВАС. ЕСЛИ В ПРОГРАММЕ БУДУТ
|
||||
ВЫЯВЛЕНЫ НЕДОСТАТКИ, ВЫ ПРИНИМАЕТЕ НА СЕБЯ СТОИМОСТЬ ВСЕГО НЕОБХОДИМОГО
|
||||
ОБСЛУЖИВАНИЯ, РЕМОНТА ИЛИ ИСПРАВЛЕНИЯ.
|
||||
|
||||
16. Ограничение ответственности.
|
||||
|
||||
ЕСЛИ ИНОЕ НЕ ПРЕДУСМОТРЕНО ДЕЙСТВУЮЩИМ ЗАКОНОДАТЕЛЬСТВОМ ИЛИ СОГЛАШЕНИЕМ СТОРОН,
|
||||
ЗАКЛЮЧЕННЫМ В ПИСЬМЕННОЙ ФОРМЕ, ПРАВООБЛАДАТЕЛЬ ИЛИ ИНОЕ ЛИЦО, КОТОРОЕ ВНОСИТ
|
||||
ИЗМЕНЕНИЯ В ПРОГРАММУ И (ИЛИ) ПЕРЕДАЕТ ЕЁ НА УСЛОВИЯХ, СФОРМУЛИРОВАННЫХ ВЫШЕ, НЕ
|
||||
МОЖЕТ НЕСТИ ОТВЕТСТВЕННОСТЬ ПЕРЕД ВАМИ ЗА ПРИЧИНЕННЫЙ УЩЕРБ, ВКЛЮЧАЯ УЩЕРБ
|
||||
ОБЩЕГО ЛИБО КОНКРЕТНОГО ХАРАКТЕРА, ПРИЧИНЕННЫЙ СЛУЧАЙНО ИЛИ ЯВЛЯЮЩИЙСЯ
|
||||
СЛЕДСТВИЕМ ИСПОЛЬЗОВАНИЯ ПРОГРАММЫ ЛИБО НЕВОЗМОЖНОСТИ ЕЁ ИСПОЛЬЗОВАНИЯ (В ТОМ
|
||||
ЧИСЛЕ ЗА УНИЧТОЖЕНИЕ ИЛИ МОДИФИКАЦИЮ ИНФОРМАЦИИ, ЛИБО УБЫТКИ, ПОНЕСЕННЫЕ ВАМИ
|
||||
ИЛИ ТРЕТЬИМИ ЛИЦАМИ, ЛИБО СБОИ ПРОГРАММЫ ПРИ ВЗАИМОДЕЙСТВИИ С ДРУГИМ ПРОГРАММНЫМ
|
||||
ОБЕСПЕЧЕНИЕМ), В ТОМ ЧИСЛЕ И В СЛУЧАЯХ, КОГДА ПРАВООБЛАДАТЕЛЬ ИЛИ ТРЕТЬЕ ЛИЦО
|
||||
ПРЕДУПРЕЖДЕНЫ О ВОЗМОЖНОСТИ ПРИЧИНЕНИЯ ТАКИХ УБЫТКОВ.
|
||||
|
||||
17. Толкование разделов 15 и 16.
|
||||
|
||||
Если отказ от гарантии и ограничение ответственности, представленные выше, по
|
||||
закону не могут быть применены в соответствии с их условиями, суды,
|
||||
рассматривающие спор, должны применить действующий закон, который в наибольшей
|
||||
степени предусматривает абсолютный отказ от всей гражданской ответственности в
|
||||
связи с Программой, за исключением случаев, когда гарантия или принятие на себя
|
||||
ответственности за копию программы предоставляется за плату.
|
||||
|
||||
КОНЕЦ ОПРЕДЕЛЕНИЙ И УСЛОВИЙ
|
||||
|
||||
Порядок применения условий Лицензии к Вашим программам
|
||||
|
||||
Если Вы разрабатываете новую программу и хотите, чтобы её использование принесло
|
||||
максимальную пользу обществу, наилучший способ достичь этого -- сделать её
|
||||
свободной, чтобы все могли распространять и изменять её на условиях настоящей
|
||||
Лицензии.
|
||||
|
||||
Для этого сделайте так, чтобы программа содержала в себе описанные ниже
|
||||
уведомления. Самым надежным способом это сделать является включение их в начало
|
||||
каждого файла исходного текста, чтобы наиболее эффективным образом сообщить об
|
||||
отсутствии гарантий; каждый файл должен иметь по меньшей мере одну строку с
|
||||
оповещением об авторских правах и указанием на то, где находится полный текст
|
||||
уведомлений.
|
||||
|
||||
<Строка с названием Программы и информацией о её назначении.>
|
||||
Copyright © <год выпуска программы в свет> <имя автора>
|
||||
|
||||
Эта программа является свободным программным обеспечением: Вы можете
|
||||
распространять её и (или) изменять, соблюдая условия Сетевой Публичной
|
||||
Лицензии Vitastor, опубликованной автором Vitastor, либо редакции 1.1
|
||||
Лицензии, либо (на Ваше усмотрение) любой редакции, выпущенной позже.
|
||||
|
||||
Эта программа распространяется в расчете на то, что она окажется полезной,
|
||||
но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ, включая подразумеваемую гарантию КАЧЕСТВА либо
|
||||
ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННЫХ ЦЕЛЕЙ. Ознакомьтесь с Сетевой Публичной
|
||||
Лицензией Vitastor для получения более подробной информации.
|
||||
|
||||
Также добавьте информацию о том, как связаться с Вами посредством электронной
|
||||
или обычной почты.
|
||||
|
||||
Если ваша программа взаимодействует с пользователями удаленно через
|
||||
компьютерную сеть, Вы также должны убедиться, что обеспечили её пользователям
|
||||
возможность получить её исходные тексты. Например, если Ваша программа является
|
||||
веб-приложением, её интерфейс может отображать ссылку "Исходные коды", которая
|
||||
указывает на архив с текстом. Существует много способов, которыми Вы можете
|
||||
распространять исходные тексты, для разных программ подходят разные решения;
|
||||
ознакомьтесь с разделом 13 для того, чтобы узнать конкретные требования.
|
||||
|
|
@ -61,7 +61,7 @@ modification follow.
|
|||
|
||||
0. Definitions.
|
||||
|
||||
"This License" refers to version 1.1 of the Vitastor Network Public License.
|
||||
"This License" refers to version 1 of the Vitastor Network Public License.
|
||||
|
||||
"Copyright" also means copyright-like laws that apply to other kinds of
|
||||
works, such as semiconductor masks.
|
||||
|
|
@ -629,7 +629,7 @@ the "copyright" line and a pointer to where the full notice is found.
|
|||
|
||||
This program is free software: you can redistribute it and/or modify
|
||||
it under the terms of the Vitastor Network Public License as published by
|
||||
the Vitastor Author, either version 1.1 of the License, or
|
||||
the Vitastor Author, either version 1 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
#!/bin/bash
|
||||
|
||||
gcc -I. -E -o fio_headers.i src/util/fio_headers.h
|
||||
gcc -I. -E -o fio_headers.i src/fio_headers.h
|
||||
|
||||
rm -rf fio-copy
|
||||
for i in `grep -Po 'fio/[^"]+' fio_headers.i | sort | uniq`; do
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
#cd b/qemu; make qapi
|
||||
|
||||
gcc -I qemu/b/qemu `pkg-config glib-2.0 --cflags` \
|
||||
-I qemu/include -E -o qemu_driver.i src/client/qemu_driver.c
|
||||
-I qemu/include -E -o qemu_driver.i src/qemu_driver.c
|
||||
|
||||
rm -rf qemu-copy
|
||||
for i in `grep -Po 'qemu/[^"]+' qemu_driver.i | sort | uniq`; do
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
Subproject commit 8de8b467acbca50cfd8835c20e0e379110f3b32b
|
||||
Subproject commit 45e6d1f13196a0824e2089a586c53b9de0283f17
|
||||
|
|
@ -1,15 +1,14 @@
|
|||
# Compile stage
|
||||
FROM golang:bookworm AS build
|
||||
FROM golang:buster AS build
|
||||
|
||||
ADD go.sum go.mod /app/
|
||||
RUN cd /app; CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go mod download -x
|
||||
ADD . /app
|
||||
RUN perl -i -e '$/ = undef; while(<>) { s/\n\s*(\{\s*\n)/$1\n/g; s/\}(\s*\n\s*)else\b/$1} else/g; print; }' `find /app -name '*.go'` && \
|
||||
cd /app && \
|
||||
CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o vitastor-csi
|
||||
RUN perl -i -e '$/ = undef; while(<>) { s/\n\s*(\{\s*\n)/$1\n/g; s/\}(\s*\n\s*)else\b/$1} else/g; print; }' `find /app -name '*.go'`
|
||||
RUN cd /app; CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o vitastor-csi
|
||||
|
||||
# Final stage
|
||||
FROM debian:bookworm
|
||||
FROM debian:buster
|
||||
|
||||
LABEL maintainers="Vitaliy Filippov <vitalif@yourcmc.ru>"
|
||||
LABEL description="Vitastor CSI Driver"
|
||||
|
|
@ -19,32 +18,15 @@ ENV CSI_ENDPOINT=""
|
|||
|
||||
RUN apt-get update && \
|
||||
apt-get install -y wget && \
|
||||
wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg && \
|
||||
(echo deb http://vitastor.io/debian buster main > /etc/apt/sources.list.d/vitastor.list) && \
|
||||
(echo deb http://deb.debian.org/debian buster-backports main > /etc/apt/sources.list.d/backports.list) && \
|
||||
(echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
|
||||
apt-get update && \
|
||||
apt-get install -y e2fsprogs xfsprogs kmod iproute2 \
|
||||
# NFS mount dependencies
|
||||
nfs-common netbase \
|
||||
# dependencies of qemu-storage-daemon
|
||||
libnuma1 liburing2 libglib2.0-0 libfuse3-3 libaio1 libzstd1 libnettle8 \
|
||||
libgmp10 libhogweed6 libp11-kit0 libidn2-0 libunistring2 libtasn1-6 libpcre2-8-0 libffi8 && \
|
||||
apt-get install -y e2fsprogs xfsprogs vitastor kmod && \
|
||||
apt-get clean && \
|
||||
(echo options nbd nbds_max=128 > /etc/modprobe.d/nbd.conf)
|
||||
|
||||
COPY --from=build /app/vitastor-csi /bin/
|
||||
|
||||
RUN (echo deb http://vitastor.io/debian bookworm main > /etc/apt/sources.list.d/vitastor.list) && \
|
||||
((echo 'Package: *'; echo 'Pin: origin "vitastor.io"'; echo 'Pin-Priority: 1000') > /etc/apt/preferences.d/vitastor.pref) && \
|
||||
wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg && \
|
||||
apt-get update && \
|
||||
apt-get install -y vitastor-client && \
|
||||
wget https://vitastor.io/archive/qemu/qemu-bookworm-8.1.2%2Bds-1%2Bvitastor1/qemu-utils_8.1.2%2Bds-1%2Bvitastor1_amd64.deb && \
|
||||
wget https://vitastor.io/archive/qemu/qemu-bookworm-8.1.2%2Bds-1%2Bvitastor1/qemu-block-extra_8.1.2%2Bds-1%2Bvitastor1_amd64.deb && \
|
||||
dpkg -x qemu-utils*.deb tmp1 && \
|
||||
dpkg -x qemu-block-extra*.deb tmp1 && \
|
||||
cp -a tmp1/usr/bin/qemu-storage-daemon /usr/bin/ && \
|
||||
mkdir -p /usr/lib/x86_64-linux-gnu/qemu && \
|
||||
cp -a tmp1/usr/lib/x86_64-linux-gnu/qemu/block-vitastor.so /usr/lib/x86_64-linux-gnu/qemu/ && \
|
||||
rm -rf tmp1 *.deb && \
|
||||
apt-get clean
|
||||
|
||||
ENTRYPOINT ["/bin/vitastor-csi"]
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
VITASTOR_VERSION ?= v1.10.0
|
||||
VERSION ?= v0.6.17
|
||||
|
||||
all: build push
|
||||
|
||||
build:
|
||||
@docker build --rm -t vitalif/vitastor-csi:$(VITASTOR_VERSION) .
|
||||
@docker build --rm -t vitalif/vitastor-csi:$(VERSION) .
|
||||
|
||||
push:
|
||||
@docker push vitalif/vitastor-csi:$(VITASTOR_VERSION)
|
||||
@docker push vitalif/vitastor-csi:$(VERSION)
|
||||
|
|
|
|||
|
|
@ -2,7 +2,6 @@
|
|||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
data:
|
||||
# You can add multiple configuration files here to use a multi-cluster setup
|
||||
vitastor.conf: |-
|
||||
{"etcd_address":"http://192.168.7.2:2379","etcd_prefix":"/vitastor"}
|
||||
metadata:
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ spec:
|
|||
capabilities:
|
||||
add: ["SYS_ADMIN"]
|
||||
allowPrivilegeEscalation: true
|
||||
image: vitalif/vitastor-csi:v1.10.0
|
||||
image: vitalif/vitastor-csi:v0.6.17
|
||||
args:
|
||||
- "--node=$(NODE_ID)"
|
||||
- "--endpoint=$(CSI_ENDPOINT)"
|
||||
|
|
@ -82,8 +82,6 @@ spec:
|
|||
name: host-sys
|
||||
- mountPath: /run/mount
|
||||
name: host-mount
|
||||
- mountPath: /run/vitastor-csi
|
||||
name: run-vitastor-csi
|
||||
- mountPath: /lib/modules
|
||||
name: lib-modules
|
||||
readOnly: true
|
||||
|
|
@ -104,7 +102,7 @@ spec:
|
|||
- "--health-port=9898"
|
||||
env:
|
||||
- name: CSI_ENDPOINT
|
||||
value: unix:///csi/csi.sock
|
||||
value: unix://csi/csi.sock
|
||||
volumeMounts:
|
||||
- mountPath: /csi
|
||||
name: socket-dir
|
||||
|
|
@ -134,9 +132,6 @@ spec:
|
|||
- name: host-mount
|
||||
hostPath:
|
||||
path: /run/mount
|
||||
- name: run-vitastor-csi
|
||||
hostPath:
|
||||
path: /run/vitastor-csi
|
||||
- name: lib-modules
|
||||
hostPath:
|
||||
path: /lib/modules
|
||||
|
|
|
|||
|
|
@ -35,13 +35,10 @@ rules:
|
|||
verbs: ["get", "list", "watch"]
|
||||
- apiGroups: ["snapshot.storage.k8s.io"]
|
||||
resources: ["volumesnapshots"]
|
||||
verbs: ["get", "list", "patch"]
|
||||
- apiGroups: ["snapshot.storage.k8s.io"]
|
||||
resources: ["volumesnapshots/status"]
|
||||
verbs: ["get", "list", "patch"]
|
||||
verbs: ["get", "list"]
|
||||
- apiGroups: ["snapshot.storage.k8s.io"]
|
||||
resources: ["volumesnapshotcontents"]
|
||||
verbs: ["create", "get", "list", "watch", "update", "delete", "patch"]
|
||||
verbs: ["create", "get", "list", "watch", "update", "delete"]
|
||||
- apiGroups: ["snapshot.storage.k8s.io"]
|
||||
resources: ["volumesnapshotclasses"]
|
||||
verbs: ["get", "list", "watch"]
|
||||
|
|
@ -56,7 +53,7 @@ rules:
|
|||
verbs: ["get", "list", "watch"]
|
||||
- apiGroups: ["snapshot.storage.k8s.io"]
|
||||
resources: ["volumesnapshotcontents/status"]
|
||||
verbs: ["update", "patch"]
|
||||
verbs: ["update"]
|
||||
- apiGroups: [""]
|
||||
resources: ["configmaps"]
|
||||
verbs: ["get"]
|
||||
|
|
|
|||
|
|
@ -23,11 +23,6 @@ metadata:
|
|||
name: csi-vitastor-provisioner
|
||||
spec:
|
||||
replicas: 3
|
||||
strategy:
|
||||
type: RollingUpdate
|
||||
rollingUpdate:
|
||||
maxUnavailable: 1
|
||||
maxSurge: 0
|
||||
selector:
|
||||
matchLabels:
|
||||
app: csi-vitastor-provisioner
|
||||
|
|
@ -51,7 +46,7 @@ spec:
|
|||
priorityClassName: system-cluster-critical
|
||||
containers:
|
||||
- name: csi-provisioner
|
||||
image: k8s.gcr.io/sig-storage/csi-provisioner:v3.0.0
|
||||
image: k8s.gcr.io/sig-storage/csi-provisioner:v2.2.0
|
||||
args:
|
||||
- "--csi-address=$(ADDRESS)"
|
||||
- "--v=5"
|
||||
|
|
@ -121,7 +116,7 @@ spec:
|
|||
privileged: true
|
||||
capabilities:
|
||||
add: ["SYS_ADMIN"]
|
||||
image: vitalif/vitastor-csi:v1.10.0
|
||||
image: vitalif/vitastor-csi:v0.6.17
|
||||
args:
|
||||
- "--node=$(NODE_ID)"
|
||||
- "--endpoint=$(CSI_ENDPOINT)"
|
||||
|
|
|
|||
|
|
@ -9,17 +9,11 @@ metadata:
|
|||
provisioner: csi.vitastor.io
|
||||
volumeBindingMode: Immediate
|
||||
parameters:
|
||||
# CSI driver can create block-based volumes and VitastorFS-based volumes
|
||||
# only VitastorFS-based volumes and raw block volumes (without FS) support ReadWriteMany mode
|
||||
# set this parameter to VitastorFS metadata volume name to use VitastorFS
|
||||
# if unset, block-based volumes will be created
|
||||
vitastorfs: ""
|
||||
# for block-based storage classes, pool ID may be either a string (name) or a number (ID)
|
||||
# for vitastorFS-based storage classes it must be a string - name of the default pool for FS data
|
||||
poolId: "testpool"
|
||||
# volume name prefix for block-based storage classes or NFS subdirectory (including /) for FS-based volumes
|
||||
volumePrefix: ""
|
||||
etcdVolumePrefix: ""
|
||||
poolId: "1"
|
||||
# you can choose other configuration file if you have it in the config map
|
||||
# different etcd URLs and prefixes should also be put in the config
|
||||
#configPath: "/etc/vitastor/vitastor.conf"
|
||||
allowVolumeExpansion: true
|
||||
# you can also specify etcdUrl here, maybe to connect to another Vitastor cluster
|
||||
# multiple etcdUrls may be specified, delimited by comma
|
||||
#etcdUrl: "http://192.168.7.2:2379"
|
||||
#etcdPrefix: "/vitastor"
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
apiVersion: snapshot.storage.k8s.io/v1
|
||||
kind: VolumeSnapshotClass
|
||||
metadata:
|
||||
name: vitastor-snapclass
|
||||
driver: csi.vitastor.io
|
||||
deletionPolicy: Delete
|
||||
parameters:
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
---
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: test-vitastor-clone
|
||||
spec:
|
||||
storageClassName: vitastor
|
||||
dataSource:
|
||||
name: snap1
|
||||
kind: VolumeSnapshot
|
||||
apiGroup: snapshot.storage.k8s.io
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 10Gi
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
apiVersion: snapshot.storage.k8s.io/v1
|
||||
kind: VolumeSnapshot
|
||||
metadata:
|
||||
name: snap1
|
||||
spec:
|
||||
volumeSnapshotClassName: vitastor-snapclass
|
||||
source:
|
||||
persistentVolumeClaimName: test-vitastor-pvc
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
---
|
||||
apiVersion: storage.k8s.io/v1
|
||||
kind: StorageClass
|
||||
metadata:
|
||||
namespace: vitastor-system
|
||||
name: vitastor
|
||||
annotations:
|
||||
storageclass.kubernetes.io/is-default-class: "true"
|
||||
provisioner: csi.vitastor.io
|
||||
volumeBindingMode: Immediate
|
||||
parameters:
|
||||
# CSI driver can create block-based volumes and VitastorFS-based volumes
|
||||
# only VitastorFS-based volumes and raw block volumes (without FS) support ReadWriteMany mode
|
||||
# set this parameter to VitastorFS metadata volume name to use VitastorFS
|
||||
# if unset, block-based volumes will be created
|
||||
vitastorfs: "testfs"
|
||||
# for block-based storage classes, pool ID may be either a string (name) or a number (ID)
|
||||
# for vitastorFS-based storage classes it must be a string - name of the default pool for FS data
|
||||
poolId: "testpool"
|
||||
# volume name prefix for block-based storage classes or NFS subdirectory (including /) for FS-based volumes
|
||||
volumePrefix: "k8s/"
|
||||
# you can choose other configuration file if you have it in the config map
|
||||
# different etcd URLs and prefixes should also be put in the config
|
||||
#configPath: "/etc/vitastor/vitastor.conf"
|
||||
allowVolumeExpansion: true
|
||||
22
csi/go.mod
22
csi/go.mod
|
|
@ -3,13 +3,27 @@ module vitastor.io/csi
|
|||
go 1.15
|
||||
|
||||
require (
|
||||
github.com/container-storage-interface/spec v1.8.0
|
||||
github.com/container-storage-interface/spec v1.4.0
|
||||
github.com/coreos/bbolt v0.0.0-00010101000000-000000000000 // indirect
|
||||
github.com/coreos/etcd v3.3.25+incompatible // indirect
|
||||
github.com/coreos/go-semver v0.3.0 // indirect
|
||||
github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf // indirect
|
||||
github.com/coreos/pkg v0.0.0-20180928190104-399ea9e2e55f // indirect
|
||||
github.com/dustin/go-humanize v1.0.0 // indirect
|
||||
github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b
|
||||
github.com/gorilla/websocket v1.4.2 // indirect
|
||||
github.com/grpc-ecosystem/go-grpc-middleware v1.3.0 // indirect
|
||||
github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0 // indirect
|
||||
github.com/grpc-ecosystem/grpc-gateway v1.16.0 // indirect
|
||||
github.com/jonboulle/clockwork v0.2.2 // indirect
|
||||
github.com/kubernetes-csi/csi-lib-utils v0.9.1
|
||||
golang.org/x/net v0.7.0
|
||||
golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 // indirect
|
||||
github.com/soheilhy/cmux v0.1.5 // indirect
|
||||
github.com/tmc/grpc-websocket-proxy v0.0.0-20201229170055-e5319fda7802 // indirect
|
||||
github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2 // indirect
|
||||
go.etcd.io/bbolt v0.0.0-00010101000000-000000000000 // indirect
|
||||
go.etcd.io/etcd v3.3.25+incompatible
|
||||
golang.org/x/net v0.0.0-20201202161906-c7110b5ffcbb
|
||||
google.golang.org/grpc v1.33.1
|
||||
google.golang.org/protobuf v1.24.0
|
||||
k8s.io/klog v1.0.0
|
||||
k8s.io/utils v0.0.0-20210305010621-2afb4311ab10
|
||||
)
|
||||
|
|
|
|||
111
csi/go.sum
111
csi/go.sum
|
|
@ -31,24 +31,40 @@ github.com/alecthomas/template v0.0.0-20160405071501-a0175ee3bccc/go.mod h1:LOuy
|
|||
github.com/alecthomas/template v0.0.0-20190718012654-fb15b899a751/go.mod h1:LOuyumcjzFXgccqObfd/Ljyb9UuFJ6TxHnclSeseNhc=
|
||||
github.com/alecthomas/units v0.0.0-20151022065526-2efee857e7cf/go.mod h1:ybxpYRFXyAe+OPACYpWeL0wqObRcbAqCMya13uyzqw0=
|
||||
github.com/alecthomas/units v0.0.0-20190717042225-c3de453c63f4/go.mod h1:ybxpYRFXyAe+OPACYpWeL0wqObRcbAqCMya13uyzqw0=
|
||||
github.com/antihax/optional v1.0.0/go.mod h1:uupD/76wgC+ih3iEmQUL+0Ugr19nfwCT1kdvxnR2qWY=
|
||||
github.com/beorn7/perks v0.0.0-20180321164747-3a771d992973/go.mod h1:Dwedo/Wpr24TaqPxmxbtue+5NUziq4I4S80YR8gNf3Q=
|
||||
github.com/beorn7/perks v1.0.0/go.mod h1:KWe93zE9D1o94FZ5RNwFwVgaQK1VOXiVxmqh+CedLV8=
|
||||
github.com/beorn7/perks v1.0.1 h1:VlbKKnNfV8bJzeqoa4cOKqO6bYr3WgKZxO8Z16+hsOM=
|
||||
github.com/beorn7/perks v1.0.1/go.mod h1:G2ZrVWU2WbWT9wwq4/hrbKbnv/1ERSJQ0ibhJ6rlkpw=
|
||||
github.com/blang/semver v3.5.0+incompatible/go.mod h1:kRBLl5iJ+tD4TcOOxsy/0fnwebNt5EWlYSAyrTnjyyk=
|
||||
github.com/census-instrumentation/opencensus-proto v0.2.1/go.mod h1:f6KPmirojxKA12rnyqOA5BBL4O983OfeGPqjHWSTneU=
|
||||
github.com/cespare/xxhash/v2 v2.1.1 h1:6MnRN8NT7+YBpUIWxHtefFZOKTAPgGjpQSxqLNn0+qY=
|
||||
github.com/cespare/xxhash/v2 v2.1.1/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs=
|
||||
github.com/chzyer/logex v1.1.10/go.mod h1:+Ywpsq7O8HXn0nuIou7OrIPyXbp3wmkHB+jjWRnGsAI=
|
||||
github.com/chzyer/readline v0.0.0-20180603132655-2972be24d48e/go.mod h1:nSuG5e5PlCu98SY8svDHJxuZscDgtXS6KTTbou5AhLI=
|
||||
github.com/chzyer/test v0.0.0-20180213035817-a1ea475d72b1/go.mod h1:Q3SI9o4m/ZMnBNeIyt5eFwwo7qiLfzFZmjNmxjkiQlU=
|
||||
github.com/container-storage-interface/spec v1.2.0/go.mod h1:6URME8mwIBbpVyZV93Ce5St17xBiQJQY67NDsuohiy4=
|
||||
github.com/container-storage-interface/spec v1.8.0 h1:D0vhF3PLIZwlwZEf2eNbpujGCNwspwTYf2idJRJx4xI=
|
||||
github.com/container-storage-interface/spec v1.8.0/go.mod h1:ROLik+GhPslwwWRNFF1KasPzroNARibH2rfz1rkg4H0=
|
||||
github.com/container-storage-interface/spec v1.4.0 h1:ozAshSKxpJnYUfmkpZCTYyF/4MYeYlhdXbAvPvfGmkg=
|
||||
github.com/container-storage-interface/spec v1.4.0/go.mod h1:6URME8mwIBbpVyZV93Ce5St17xBiQJQY67NDsuohiy4=
|
||||
github.com/coreos/bbolt v1.3.5 h1:XFv7xaq7701j8ZSEzR28VohFYSlyakMyqNMU5FQH6Ac=
|
||||
github.com/coreos/bbolt v1.3.5/go.mod h1:G5EMThwa9y8QZGBClrRx5EY+Yw9kAhnjy3bSjsnlVTQ=
|
||||
github.com/coreos/etcd v3.3.25+incompatible h1:0GQEw6h3YnuOVdtwygkIfJ+Omx0tZ8/QkVyXI4LkbeY=
|
||||
github.com/coreos/etcd v3.3.25+incompatible/go.mod h1:uF7uidLiAD3TWHmW31ZFd/JWoc32PjwdhPthX9715RE=
|
||||
github.com/coreos/go-semver v0.3.0 h1:wkHLiw0WNATZnSG7epLsujiMCgPAc9xhjJ4tgnAxmfM=
|
||||
github.com/coreos/go-semver v0.3.0/go.mod h1:nnelYz7RCh+5ahJtPPxZlU+153eP4D4r3EedlOD2RNk=
|
||||
github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf h1:iW4rZ826su+pqaw19uhpSCzhj44qo35pNgKFGqzDKkU=
|
||||
github.com/coreos/go-systemd v0.0.0-20191104093116-d3cd4ed1dbcf/go.mod h1:F5haX7vjVVG0kc13fIWeqUViNPyEJxv/OmvnBo0Yme4=
|
||||
github.com/coreos/pkg v0.0.0-20180928190104-399ea9e2e55f h1:lBNOc5arjvs8E5mO2tbpBpLoyyu8B6e44T7hJy6potg=
|
||||
github.com/coreos/pkg v0.0.0-20180928190104-399ea9e2e55f/go.mod h1:E3G3o1h8I7cfcXa63jLwjI0eiQQMgzzUDFVpN/nH/eA=
|
||||
github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
|
||||
github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c=
|
||||
github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38=
|
||||
github.com/dgrijalva/jwt-go v3.2.0+incompatible h1:7qlOGliEKZXTDg6OTjfoBKDXWrumCAMpl/TFQ4/5kLM=
|
||||
github.com/dgrijalva/jwt-go v3.2.0+incompatible/go.mod h1:E3ru+11k8xSBh+hMPgOLZmtrrCbhqsmaPHjLKYnJCaQ=
|
||||
github.com/docker/spdystream v0.0.0-20160310174837-449fdfce4d96/go.mod h1:Qh8CwZgvJUkLughtfhJv5dyTYa91l1fOUCrgjqmcifM=
|
||||
github.com/docopt/docopt-go v0.0.0-20180111231733-ee0de3bc6815/go.mod h1:WwZ+bS3ebgob9U8Nd0kOddGdZWjyMGR8Wziv+TBNwSE=
|
||||
github.com/dustin/go-humanize v1.0.0 h1:VSnTsYCnlFHaM2/igO1h6X3HA71jcobQuxemgkq4zYo=
|
||||
github.com/dustin/go-humanize v1.0.0/go.mod h1:HtrtbFcZ19U5GC7JDqmcUSB87Iq5E25KnS6fMYU6eOk=
|
||||
github.com/elazarl/goproxy v0.0.0-20180725130230-947c36da3153/go.mod h1:/Zj4wYkgs4iZTTu3o/KG3Itv/qCCa8VVMlb3i9OVuzc=
|
||||
github.com/emicklei/go-restful v0.0.0-20170410110728-ff4f55a20633/go.mod h1:otzb+WCGbkyDHkqmQmT5YD2WR4BBwUdeQoFo8l/7tVs=
|
||||
github.com/envoyproxy/go-control-plane v0.9.0/go.mod h1:YTl/9mNaCwkRvm6d1a2C3ymFceY/DCBVvsKhRF0iEA4=
|
||||
|
|
@ -57,6 +73,7 @@ github.com/evanphx/json-patch v4.9.0+incompatible/go.mod h1:50XU6AFN0ol/bzJsmQLi
|
|||
github.com/fsnotify/fsnotify v1.4.7/go.mod h1:jwhsz4b93w/PPRr/qN1Yymfu8t87LnFCMoQvtojpjFo=
|
||||
github.com/fsnotify/fsnotify v1.4.9/go.mod h1:znqG4EE+3YCdAaPaxE2ZRY/06pZUdp0tY4IgpuI1SZQ=
|
||||
github.com/ghodss/yaml v0.0.0-20150909031657-73d445a93680/go.mod h1:4dBDuWmgqj2HViK6kFavaiC9ZROes6MMH2rRYeMEF04=
|
||||
github.com/ghodss/yaml v1.0.0/go.mod h1:4dBDuWmgqj2HViK6kFavaiC9ZROes6MMH2rRYeMEF04=
|
||||
github.com/go-gl/glfw/v3.3/glfw v0.0.0-20191125211704-12ad95a8df72/go.mod h1:tQ2UAYgL5IevRw8kRxooKSPJfGvJ9fJQFa0TUsXzTg8=
|
||||
github.com/go-kit/kit v0.8.0/go.mod h1:xBxKIO96dXMWWy0MnWVtmwkA9/13aqxPnvrjFYMA2as=
|
||||
github.com/go-kit/kit v0.9.0/go.mod h1:xBxKIO96dXMWWy0MnWVtmwkA9/13aqxPnvrjFYMA2as=
|
||||
|
|
@ -71,10 +88,14 @@ github.com/go-openapi/spec v0.0.0-20160808142527-6aced65f8501/go.mod h1:J8+jY1nA
|
|||
github.com/go-openapi/swag v0.0.0-20160704191624-1d0bd113de87/go.mod h1:DXUve3Dpr1UfpPtxFw+EFuQ41HhCWZfha5jSVRG7C7I=
|
||||
github.com/go-stack/stack v1.8.0/go.mod h1:v0f6uXyyMGvRgIKkXu+yp6POWl0qKG85gN/melR3HDY=
|
||||
github.com/gogo/protobuf v1.1.1/go.mod h1:r8qH/GZQm5c6nD/R0oafs1akxWv10x8SbQlK7atdtwQ=
|
||||
github.com/gogo/protobuf v1.3.1 h1:DqDEcV5aeaTmdFBePNpYsp3FlcVH/2ISVVM9Qf8PSls=
|
||||
github.com/gogo/protobuf v1.3.1/go.mod h1:SlYgWuQ5SjCEi6WLHjHCa1yvBfUnHcTbrrZtXPKa29o=
|
||||
github.com/gogo/protobuf v1.3.2 h1:Ov1cvc58UF3b5XjBnZv7+opcTcQFZebYjWzi34vdm4Q=
|
||||
github.com/gogo/protobuf v1.3.2/go.mod h1:P1XiOD3dCwIKUDQYPy72D8LYyHL2YPYrpS2s69NZV8Q=
|
||||
github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b h1:VKtxabqXZkF25pY9ekfRL6a582T4P37/31XEstQ5p58=
|
||||
github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b/go.mod h1:SBH7ygxi8pfUlaOkMMuAQtPIUF8ecWP5IEl/CR7VP2Q=
|
||||
github.com/golang/groupcache v0.0.0-20190702054246-869f871628b6/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc=
|
||||
github.com/golang/groupcache v0.0.0-20191227052852-215e87163ea7 h1:5ZkaAPbicIKTF2I64qf5Fh8Aa83Q/dnOafMYV0OMwjA=
|
||||
github.com/golang/groupcache v0.0.0-20191227052852-215e87163ea7/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc=
|
||||
github.com/golang/mock v1.1.1/go.mod h1:oTYuIxOrZwtPieC+H1uAHpcLFnEyAGVDL/k47Jfbm0A=
|
||||
github.com/golang/mock v1.2.0/go.mod h1:oTYuIxOrZwtPieC+H1uAHpcLFnEyAGVDL/k47Jfbm0A=
|
||||
|
|
@ -92,6 +113,7 @@ github.com/golang/protobuf v1.4.1/go.mod h1:U8fpvMrcmy5pZrNK1lt4xCsGvpyWQ/VVv6QD
|
|||
github.com/golang/protobuf v1.4.2 h1:+Z5KGCizgyZCbGh1KZqA0fcLLkwbsjIzS4aV2v7wJX0=
|
||||
github.com/golang/protobuf v1.4.2/go.mod h1:oDoupMAO8OvCJWAcko0GGGIgR6R6ocIYbsSw735rRwI=
|
||||
github.com/google/btree v0.0.0-20180813153112-4030bb1f1f0c/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ=
|
||||
github.com/google/btree v1.0.0 h1:0udJVsspx3VBr5FwtLhQQtuAsVc79tTq0ocGIPAU6qo=
|
||||
github.com/google/btree v1.0.0/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ=
|
||||
github.com/google/go-cmp v0.2.0/go.mod h1:oXzfMopK8JAjlY9xF4vHSVASa0yLyX7SntLO5aqRK0M=
|
||||
github.com/google/go-cmp v0.3.0/go.mod h1:8QqcDgzrUqlUb/G2PQTWiueGozuR1884gddMywk6iLU=
|
||||
|
|
@ -105,24 +127,38 @@ github.com/google/pprof v0.0.0-20181206194817-3ea8567a2e57/go.mod h1:zfwlbNMJ+OI
|
|||
github.com/google/pprof v0.0.0-20190515194954-54271f7e092f/go.mod h1:zfwlbNMJ+OItoe0UupaVj+oy1omPYYDuagoSzA8v9mc=
|
||||
github.com/google/pprof v0.0.0-20191218002539-d4f498aebedc/go.mod h1:ZgVRPoUq/hfqzAqh7sHMqb3I9Rq5C59dIz2SbBwJ4eM=
|
||||
github.com/google/renameio v0.1.0/go.mod h1:KWCgfxg9yswjAJkECMjeO8J8rahYeXnNhOm40UhjYkI=
|
||||
github.com/google/uuid v1.1.1 h1:Gkbcsh/GbpXz7lPftLA3P6TYMwjCLYm83jiFQZF/3gY=
|
||||
github.com/google/uuid v1.1.1/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo=
|
||||
github.com/googleapis/gax-go/v2 v2.0.4/go.mod h1:0Wqv26UfaUD9n4G6kQubkQ+KchISgw+vpHVxEJEs9eg=
|
||||
github.com/googleapis/gax-go/v2 v2.0.5/go.mod h1:DWXyrwAJ9X0FpwwEdw+IPEYBICEFu5mhpdKc/us6bOk=
|
||||
github.com/googleapis/gnostic v0.4.1/go.mod h1:LRhVm6pbyptWbWbuZ38d1eyptfvIytN3ir6b65WBswg=
|
||||
github.com/gorilla/websocket v1.4.2 h1:+/TMaTYc4QFitKJxsQ7Yye35DkWvkdLcvGKqM+x0Ufc=
|
||||
github.com/gorilla/websocket v1.4.2/go.mod h1:YR8l580nyteQvAITg2hZ9XVh4b55+EU/adAjf1fMHhE=
|
||||
github.com/gregjones/httpcache v0.0.0-20180305231024-9cad4c3443a7/go.mod h1:FecbI9+v66THATjSRHfNgh1IVFe/9kFxbXtjV0ctIMA=
|
||||
github.com/grpc-ecosystem/go-grpc-middleware v1.3.0 h1:+9834+KizmvFV7pXQGSXQTsaWhq2GjuNUt0aUU0YBYw=
|
||||
github.com/grpc-ecosystem/go-grpc-middleware v1.3.0/go.mod h1:z0ButlSOZa5vEBq9m2m2hlwIgKw+rp3sdCBRoJY+30Y=
|
||||
github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0 h1:Ovs26xHkKqVztRpIrF/92BcuyuQ/YW4NSIpoGtfXNho=
|
||||
github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0/go.mod h1:8NvIoxWQoOIhqOTXgfV/d3M/q6VIi02HzZEHgUlZvzk=
|
||||
github.com/grpc-ecosystem/grpc-gateway v1.16.0 h1:gmcG1KaJ57LophUzW0Hy8NmPhnMZb4M0+kPpLofRdBo=
|
||||
github.com/grpc-ecosystem/grpc-gateway v1.16.0/go.mod h1:BDjrQk3hbvj6Nolgz8mAMFbcEtjT1g+wF4CSlocrBnw=
|
||||
github.com/hashicorp/golang-lru v0.5.0/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
|
||||
github.com/hashicorp/golang-lru v0.5.1/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8=
|
||||
github.com/hpcloud/tail v1.0.0/go.mod h1:ab1qPbhIpdTxEkNHXyeSf5vhxWSCs/tWer42PpOxQnU=
|
||||
github.com/ianlancetaylor/demangle v0.0.0-20181102032728-5e5cf60278f6/go.mod h1:aSSvb/t6k1mPoxDqO4vJh6VOCGPwU4O0C2/Eqndh1Sc=
|
||||
github.com/imdario/mergo v0.3.5/go.mod h1:2EnlNZ0deacrJVfApfmtdGgDfMuh/nq6Ok1EcJh5FfA=
|
||||
github.com/jonboulle/clockwork v0.2.2 h1:UOGuzwb1PwsrDAObMuhUnj0p5ULPj8V/xJ7Kx9qUBdQ=
|
||||
github.com/jonboulle/clockwork v0.2.2/go.mod h1:Pkfl5aHPm1nk2H9h0bjmnJD/BcgbGXUBGnn1kMkgxc8=
|
||||
github.com/json-iterator/go v1.1.6/go.mod h1:+SdeFBvtyEkXs7REEP0seUULqWtbJapLOCVDaaPEHmU=
|
||||
github.com/json-iterator/go v1.1.10 h1:Kz6Cvnvv2wGdaG/V8yMvfkmNiXq9Ya2KUv4rouJJr68=
|
||||
github.com/json-iterator/go v1.1.10/go.mod h1:KdQUCv79m/52Kvf8AW2vK1V8akMuk1QjK/uOdHXbAo4=
|
||||
github.com/jstemmer/go-junit-report v0.0.0-20190106144839-af01ea7f8024/go.mod h1:6v2b51hI/fHJwM22ozAgKL4VKDeJcHhJFhtBdhmNjmU=
|
||||
github.com/jstemmer/go-junit-report v0.9.1/go.mod h1:Brl9GWCQeLvo8nXZwPNNblvFj/XSXhF0NWZEnDohbsk=
|
||||
github.com/julienschmidt/httprouter v1.2.0/go.mod h1:SYymIcj16QtmaHHD7aYtjjsJG7VTCxuUUipMqKk8s4w=
|
||||
github.com/kisielk/errcheck v1.2.0/go.mod h1:/BMXB+zMLi60iA8Vv6Ksmxu/1UDYcXs4uQLJ+jE2L00=
|
||||
github.com/kisielk/errcheck v1.5.0/go.mod h1:pFxgyoBC7bSaBwPgfKdkLd5X25qrDl4LWUI2bnpBCr8=
|
||||
github.com/kisielk/gotool v1.0.0/go.mod h1:XhKaO+MFFWcvkIS/tQcRk01m1F5IRFswLeQ+oQHNcck=
|
||||
github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
|
||||
github.com/konsorten/go-windows-terminal-sequences v1.0.3 h1:CE8S1cTafDpPvMhIxNJKvHsGVBgn1xWYf1NbHQhywc8=
|
||||
github.com/konsorten/go-windows-terminal-sequences v1.0.3/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ=
|
||||
github.com/kr/logfmt v0.0.0-20140226030751-b84e30acd515/go.mod h1:+0opPa2QZZtGFBFZlji/RkVcI2GknAs/DXo4wKdlNEc=
|
||||
github.com/kr/pretty v0.1.0/go.mod h1:dAy3ld7l9f0ibDNOQOHHMYYIIbhfbHSm3C4ZsoJORNo=
|
||||
|
|
@ -135,11 +171,14 @@ github.com/kubernetes-csi/csi-lib-utils v0.9.1 h1:sGq6ifVujfMSkfTsMZip44Ttv8SDXv
|
|||
github.com/kubernetes-csi/csi-lib-utils v0.9.1/go.mod h1:8E2jVUX9j3QgspwHXa6LwyN7IHQDjW9jX3kwoWnSC+M=
|
||||
github.com/mailru/easyjson v0.0.0-20160728113105-d5b7844b561a/go.mod h1:C1wdFJiN94OJF2b5HbByQZoLdCWB1Yqtg26g4irojpc=
|
||||
github.com/matttproud/golang_protobuf_extensions v1.0.1/go.mod h1:D8He9yQNgCq6Z5Ld7szi9bcBfOoFv/3dc6xSMkL2PC0=
|
||||
github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369 h1:I0XW9+e1XWDxdcEniV4rQAIOPUGDq67JSCiRCgGCZLI=
|
||||
github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369/go.mod h1:BSXmuO+STAnVfrANrmjBb36TMTDstsz7MSK+HVaYKv4=
|
||||
github.com/moby/term v0.0.0-20200312100748-672ec06f55cd/go.mod h1:DdlQx2hp0Ss5/fLikoLlEeIYiATotOjgB//nb973jeo=
|
||||
github.com/modern-go/concurrent v0.0.0-20180228061459-e0a39a4cb421/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q=
|
||||
github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd h1:TRLaZ9cD/w8PVh93nsPXa1VrQ6jlwL5oN8l14QlcNfg=
|
||||
github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q=
|
||||
github.com/modern-go/reflect2 v0.0.0-20180701023420-4b7aa43c6742/go.mod h1:bx2lNnkwVCuqBIxFjflWJWanXIb3RllmbCylyMrvgv0=
|
||||
github.com/modern-go/reflect2 v1.0.1 h1:9f412s+6RmYXLWZSEzVVgPGK7C2PphHj5RJrvfx9AWI=
|
||||
github.com/modern-go/reflect2 v1.0.1/go.mod h1:bx2lNnkwVCuqBIxFjflWJWanXIb3RllmbCylyMrvgv0=
|
||||
github.com/munnerz/goautoneg v0.0.0-20120707110453-a547fc61f48d/go.mod h1:+n7T8mK8HuQTcFwEeznm/DIxMOiR9yIdICNftLE1DvQ=
|
||||
github.com/mwitkow/go-conntrack v0.0.0-20161129095857-cc309e4a2223/go.mod h1:qRWi+5nqEBWmkhHvq77mSJWrCKwh8bxhgT7d/eI7P4U=
|
||||
|
|
@ -149,28 +188,38 @@ github.com/onsi/ginkgo v1.6.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+W
|
|||
github.com/onsi/ginkgo v1.11.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE=
|
||||
github.com/onsi/gomega v0.0.0-20170829124025-dcabb60a477c/go.mod h1:C1qb7wdrVGGVU+Z6iS04AVkA3Q65CEZX59MT0QO5uiA=
|
||||
github.com/onsi/gomega v1.7.0/go.mod h1:ex+gbHU/CVuBBDIJjb2X0qEXbFg53c61hWP/1CpauHY=
|
||||
github.com/opentracing/opentracing-go v1.1.0/go.mod h1:UkNAQd3GIcIGf0SeVgPpRdFStlNbqXla1AfSYxPUl2o=
|
||||
github.com/peterbourgon/diskv v2.0.1+incompatible/go.mod h1:uqqh8zWWbv1HBMNONnaR/tNboyR3/BZd58JJSHlUSCU=
|
||||
github.com/pkg/errors v0.8.0/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
|
||||
github.com/pkg/errors v0.8.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
|
||||
github.com/pkg/errors v0.9.1 h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4=
|
||||
github.com/pkg/errors v0.9.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=
|
||||
github.com/pmezard/go-difflib v1.0.0 h1:4DBwDE0NGyQoBHbLQYPwSUPoCMWR5BEzIk/f1lZbAQM=
|
||||
github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4=
|
||||
github.com/prometheus/client_golang v0.9.1/go.mod h1:7SWBe2y4D6OKWSNQJUaRYU/AaXPKyh/dDVn+NZz0KFw=
|
||||
github.com/prometheus/client_golang v1.0.0/go.mod h1:db9x61etRT2tGnBNRi70OPL5FsnadC4Ky3P0J6CfImo=
|
||||
github.com/prometheus/client_golang v1.7.1 h1:NTGy1Ja9pByO+xAeH/qiWnLrKtr3hJPNjaVUwnjpdpA=
|
||||
github.com/prometheus/client_golang v1.7.1/go.mod h1:PY5Wy2awLA44sXw4AOSfFBetzPP4j5+D6mVACh+pe2M=
|
||||
github.com/prometheus/client_model v0.0.0-20180712105110-5c3871d89910/go.mod h1:MbSGuTsp3dbXC40dX6PRTWyKYBIrTGTE9sqQNg2J8bo=
|
||||
github.com/prometheus/client_model v0.0.0-20190129233127-fd36f4220a90/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
|
||||
github.com/prometheus/client_model v0.0.0-20190812154241-14fe0d1b01d4/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
|
||||
github.com/prometheus/client_model v0.2.0 h1:uq5h0d+GuxiXLJLNABMgp2qUWDPiLvgCzz2dUR+/W/M=
|
||||
github.com/prometheus/client_model v0.2.0/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA=
|
||||
github.com/prometheus/common v0.4.1/go.mod h1:TNfzLD0ON7rHzMJeJkieUDPYmFC7Snx/y86RQel1bk4=
|
||||
github.com/prometheus/common v0.10.0 h1:RyRA7RzGXQZiW+tGMr7sxa85G1z0yOpM1qq5c8lNawc=
|
||||
github.com/prometheus/common v0.10.0/go.mod h1:Tlit/dnDKsSWFlCLTWaA1cyBgKHSMdTB80sz/V91rCo=
|
||||
github.com/prometheus/procfs v0.0.0-20181005140218-185b4288413d/go.mod h1:c3At6R/oaqEKCNdg8wHV1ftS6bRYblBhIjjI8uT2IGk=
|
||||
github.com/prometheus/procfs v0.0.2/go.mod h1:TjEm7ze935MbeOT/UhFTIMYKhuLP4wbCsTZCD3I8kEA=
|
||||
github.com/prometheus/procfs v0.1.3 h1:F0+tqvhOksq22sc6iCHF5WGlWjdwj92p0udFh1VFBS8=
|
||||
github.com/prometheus/procfs v0.1.3/go.mod h1:lV6e/gmhEcM9IjHGsFOCxxuZ+z1YqCvr4OA4YeYWdaU=
|
||||
github.com/rogpeppe/fastuuid v1.2.0/go.mod h1:jVj6XXZzXRy/MSR5jhDC/2q6DgLz+nrA6LYCDYWNEvQ=
|
||||
github.com/rogpeppe/go-internal v1.3.0/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4=
|
||||
github.com/sirupsen/logrus v1.2.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPxbbu5VWo=
|
||||
github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE=
|
||||
github.com/sirupsen/logrus v1.6.0 h1:UBcNElsrwanuuMsnGSlYmtmgbb23qDR5dG+6X6Oo89I=
|
||||
github.com/sirupsen/logrus v1.6.0/go.mod h1:7uNnSEd1DgxDLC74fIahvMZmmYsHGZGEOFrfsX/uA88=
|
||||
github.com/soheilhy/cmux v0.1.5 h1:jjzc5WVemNEDTLwv9tlmemhC73tI08BNOIGwBOo10Js=
|
||||
github.com/soheilhy/cmux v0.1.5/go.mod h1:T7TcVDs9LWfQgPlPsdngu6I6QIoyIFZDDC6sNE1GqG0=
|
||||
github.com/spf13/afero v1.2.2/go.mod h1:9ZxEEn6pIJ8Rxe320qSDBk6AsU0r9pR7Q4OcevTdifk=
|
||||
github.com/spf13/pflag v0.0.0-20170130214245-9ff6c6923cff/go.mod h1:DYY7MBk1bdzusC3SYhjObp+wFpr4gzcvqqNjLnInEg4=
|
||||
github.com/spf13/pflag v1.0.3/go.mod h1:DYY7MBk1bdzusC3SYhjObp+wFpr4gzcvqqNjLnInEg4=
|
||||
|
|
@ -182,12 +231,24 @@ github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UV
|
|||
github.com/stretchr/testify v1.4.0/go.mod h1:j7eGeouHqKxXV5pUuKE4zz7dFj8WfuZ+81PSLYec5m4=
|
||||
github.com/stretchr/testify v1.5.1 h1:nOGnQDM7FYENwehXlg/kFVnos3rEvtKTjRvOWSzb6H4=
|
||||
github.com/stretchr/testify v1.5.1/go.mod h1:5W2xD1RspED5o8YsWQXVCued0rvSQ+mT+I5cxcmMvtA=
|
||||
github.com/yuin/goldmark v1.4.13/go.mod h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY=
|
||||
github.com/tmc/grpc-websocket-proxy v0.0.0-20201229170055-e5319fda7802 h1:uruHq4dN7GR16kFc5fp3d1RIYzJW5onx8Ybykw2YQFA=
|
||||
github.com/tmc/grpc-websocket-proxy v0.0.0-20201229170055-e5319fda7802/go.mod h1:ncp9v5uamzpCO7NfCPTXjqaC+bZgJeR0sMTm6dMHP7U=
|
||||
github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2 h1:eY9dn8+vbi4tKz5Qo6v2eYzo7kUS51QINcR5jNpbZS8=
|
||||
github.com/xiang90/probing v0.0.0-20190116061207-43a291ad63a2/go.mod h1:UETIi67q53MR2AWcXfiuqkDkRtnGDLqkBTpCHuJHxtU=
|
||||
github.com/yuin/goldmark v1.1.27/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=
|
||||
github.com/yuin/goldmark v1.2.1/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74=
|
||||
go.etcd.io/bbolt v1.3.5 h1:XAzx9gjCb0Rxj7EoqcClPD1d5ZBxZJk0jbuoPHenBt0=
|
||||
go.etcd.io/bbolt v1.3.5/go.mod h1:G5EMThwa9y8QZGBClrRx5EY+Yw9kAhnjy3bSjsnlVTQ=
|
||||
go.etcd.io/etcd v3.3.25+incompatible h1:V1RzkZJj9LqsJRy+TUBgpWSbZXITLB819lstuTFoZOY=
|
||||
go.etcd.io/etcd v3.3.25+incompatible/go.mod h1:yaeTdrJi5lOmYerz05bd8+V7KubZs8YSFZfzsF9A6aI=
|
||||
go.opencensus.io v0.21.0/go.mod h1:mSImk1erAIZhrmZN+AvHh14ztQfjbGwt4TtuofqLduU=
|
||||
go.opencensus.io v0.22.0/go.mod h1:+kGneAE2xo2IficOXnaByMWTGM9T73dGwxeWcUqIpI8=
|
||||
go.opencensus.io v0.22.2/go.mod h1:yxeiOL68Rb0Xd1ddK5vPZ/oVn4vY4Ynel7k9FzqtOIw=
|
||||
go.uber.org/atomic v1.4.0 h1:cxzIVoETapQEqDhQu3QfnvXAV4AlzcvUCxkVUFw3+EU=
|
||||
go.uber.org/atomic v1.4.0/go.mod h1:gD2HeocX3+yG+ygLZcrzQJaqmWj9AIm7n08wl/qW/PE=
|
||||
go.uber.org/multierr v1.1.0 h1:HoEmRHQPVSqub6w2z2d2EOVs2fjyFRGyofhKuyDq0QI=
|
||||
go.uber.org/multierr v1.1.0/go.mod h1:wR5kodmAFQ0UK8QlbwjlSNy0Z68gJhDJUG5sjR94q/0=
|
||||
go.uber.org/zap v1.10.0 h1:ORx85nbTijNz8ljznvCMR1ZBIPKFn3jQrag10X2AsuM=
|
||||
go.uber.org/zap v1.10.0/go.mod h1:vwi/ZaCAaUcBkycHslxD9B2zi4UTXhF60s6SWpuDF0Q=
|
||||
golang.org/x/crypto v0.0.0-20180904163835-0709b304e793/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4=
|
||||
golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w=
|
||||
|
|
@ -195,8 +256,8 @@ golang.org/x/crypto v0.0.0-20190510104115-cbcb75029529/go.mod h1:yigFU9vqHzYiE8U
|
|||
golang.org/x/crypto v0.0.0-20190605123033-f99c8df09eb5/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
|
||||
golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
|
||||
golang.org/x/crypto v0.0.0-20191206172530-e9b2fee46413/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
|
||||
golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9 h1:psW17arqaxU48Z5kZ0CQnkZWQJsqcURM6tKiBApRjXI=
|
||||
golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto=
|
||||
golang.org/x/crypto v0.0.0-20210921155107-089bfa567519/go.mod h1:GvvjBRRGRdwPK5ydBHafDWAxML/pGHZbMvKqRZ5+Abc=
|
||||
golang.org/x/exp v0.0.0-20190121172915-509febef88a4/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
|
||||
golang.org/x/exp v0.0.0-20190306152737-a1d7652674e8/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA=
|
||||
golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522/go.mod h1:ZjyILWgesfNpC6sMxTJOJm9Kp84zZh5NQWvqDGG3Qr8=
|
||||
|
|
@ -215,7 +276,8 @@ golang.org/x/mobile v0.0.0-20190719004257-d2bd2a29d028/go.mod h1:E/iHnbuqvinMTCc
|
|||
golang.org/x/mod v0.0.0-20190513183733-4bf6d317e70e/go.mod h1:mXi4GBBbnImb6dmsKGUJ2LatrhH/nqhxcFungHvyanc=
|
||||
golang.org/x/mod v0.1.0/go.mod h1:0QHyrYULN0/3qlju5TqG8bIK38QM8yzMo5ekMj3DlcY=
|
||||
golang.org/x/mod v0.1.1-0.20191105210325-c90efee705ee/go.mod h1:QqPTAvyqsEbceGzBzNggFXnrqF1CaUcvgkdR5Ot7KZg=
|
||||
golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4/go.mod h1:jJ57K6gSWd91VN4djpZkiMVwK6gcyfeH4XE8wZrZaV4=
|
||||
golang.org/x/mod v0.2.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=
|
||||
golang.org/x/mod v0.3.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA=
|
||||
golang.org/x/net v0.0.0-20180724234803-3673e40ba225/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
|
||||
golang.org/x/net v0.0.0-20180906233101-161cd47e91fd/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
|
||||
golang.org/x/net v0.0.0-20181114220301-adae6a3d119a/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
|
||||
|
|
@ -229,23 +291,26 @@ golang.org/x/net v0.0.0-20190603091049-60506f45cf65/go.mod h1:HSz+uSET+XFnRR8LxR
|
|||
golang.org/x/net v0.0.0-20190613194153-d28f0bde5980/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
|
||||
golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
|
||||
golang.org/x/net v0.0.0-20191209160850-c0dbc17a3553/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
|
||||
golang.org/x/net v0.0.0-20200226121028-0de0cce0169b/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s=
|
||||
golang.org/x/net v0.0.0-20200324143707-d3edc9973b7e/go.mod h1:qpuaurCH72eLCgpAm/N6yyVIVM9cpaDIP3A8BGJEC5A=
|
||||
golang.org/x/net v0.0.0-20200707034311-ab3426394381 h1:VXak5I6aEWmAXeQjA+QSZzlgNrpq9mjcfDemuexIKsU=
|
||||
golang.org/x/net v0.0.0-20200707034311-ab3426394381/go.mod h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA=
|
||||
golang.org/x/net v0.0.0-20210226172049-e18ecbb05110/go.mod h1:m0MpNAwzfU5UDzcl9v0D8zg8gWTRqZa9RBIspLL5mdg=
|
||||
golang.org/x/net v0.0.0-20220722155237-a158d28d115b/go.mod h1:XRhObCWvk6IyKnWLug+ECip1KBveYUHfp+8e9klMJ9c=
|
||||
golang.org/x/net v0.7.0 h1:rJrUqqhjsgNp7KqAIc25s9pZnjU7TUcSY7HcVZjdn1g=
|
||||
golang.org/x/net v0.7.0/go.mod h1:2Tu9+aMcznHK/AK1HMvgo6xiTLG5rD5rZLDS+rp2Bjs=
|
||||
golang.org/x/net v0.0.0-20200822124328-c89045814202/go.mod h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA=
|
||||
golang.org/x/net v0.0.0-20201021035429-f5854403a974/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU=
|
||||
golang.org/x/net v0.0.0-20201202161906-c7110b5ffcbb h1:eBmm0M9fYhWpKZLjQUUKka/LtIxf46G4fxeEz5KJr9U=
|
||||
golang.org/x/net v0.0.0-20201202161906-c7110b5ffcbb/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU=
|
||||
golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U=
|
||||
golang.org/x/oauth2 v0.0.0-20190226205417-e64efc72b421/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
|
||||
golang.org/x/oauth2 v0.0.0-20190604053449-0f29369cfe45/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
|
||||
golang.org/x/oauth2 v0.0.0-20191202225959-858c2ad4c8b6/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
|
||||
golang.org/x/oauth2 v0.0.0-20200107190931-bf48bf16ab8d/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw=
|
||||
golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
|
||||
golang.org/x/sync v0.0.0-20181108010431-42b317875d0f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
|
||||
golang.org/x/sync v0.0.0-20181221193216-37e7f081c4d4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
|
||||
golang.org/x/sync v0.0.0-20190227155943-e225da77a7e6/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
|
||||
golang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
|
||||
golang.org/x/sync v0.0.0-20190911185100-cd5d95a43a6e/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
|
||||
golang.org/x/sync v0.0.0-20220722155255-886fb9371eb4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
|
||||
golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
|
||||
golang.org/x/sys v0.0.0-20180905080454-ebe1bf3edb33/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
|
||||
golang.org/x/sys v0.0.0-20180909124046-d0be0721c37e/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
|
||||
golang.org/x/sys v0.0.0-20181116152217-5ac8a444bdc5/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
|
||||
|
|
@ -261,28 +326,22 @@ golang.org/x/sys v0.0.0-20191005200804-aed5e4c7ecf9/go.mod h1:h1NjWce9XRLGQEsW7w
|
|||
golang.org/x/sys v0.0.0-20191204072324-ce4227a45e2e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
||||
golang.org/x/sys v0.0.0-20191228213918-04cbcbbfeed8/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
||||
golang.org/x/sys v0.0.0-20200106162015-b016eb3dc98e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
||||
golang.org/x/sys v0.0.0-20200202164722-d101bd2416d5/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
||||
golang.org/x/sys v0.0.0-20200302150141-5c8b2ff67527/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
||||
golang.org/x/sys v0.0.0-20200323222414-85ca7c5b95cd/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
||||
golang.org/x/sys v0.0.0-20200615200032-f1bc736245b1/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
||||
golang.org/x/sys v0.0.0-20200622214017-ed371f2e16b4 h1:5/PjkGUjvEU5Gl6BxmvKRPpqo2uNMv4rcHBMwzk/st8=
|
||||
golang.org/x/sys v0.0.0-20200622214017-ed371f2e16b4/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
||||
golang.org/x/sys v0.0.0-20201119102817-f84b799fce68/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
||||
golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
|
||||
golang.org/x/sys v0.0.0-20220520151302-bc2c85ada10a/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
|
||||
golang.org/x/sys v0.0.0-20220722155257-8c9f86f7a55f/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
|
||||
golang.org/x/sys v0.5.0 h1:MUK/U/4lj1t1oPg0HfuXDN/Z1wv31ZJ/YcPiGccS4DU=
|
||||
golang.org/x/sys v0.5.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
|
||||
golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
|
||||
golang.org/x/term v0.0.0-20210927222741-03fcf44c2211/go.mod h1:jbD1KX2456YbFQfuXm/mYQcufACuNUgVhRMnK/tPxf8=
|
||||
golang.org/x/term v0.5.0/go.mod h1:jMB1sMXY+tzblOD4FWmEbocvup2/aLOaQEp7JmGp78k=
|
||||
golang.org/x/sys v0.0.0-20200930185726-fdedc70b468f h1:+Nyd8tzPX9R7BWHguqsrbFdRx3WQ/1ib8I44HXV5yTA=
|
||||
golang.org/x/sys v0.0.0-20200930185726-fdedc70b468f/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
||||
golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
|
||||
golang.org/x/text v0.3.1-0.20180807135948-17ff2d5776d2/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ=
|
||||
golang.org/x/text v0.3.2/go.mod h1:bEr9sfX3Q8Zfm5fL9x+3itogRgK3+ptLWKqgva+5dAk=
|
||||
golang.org/x/text v0.3.3 h1:cokOdA+Jmi5PJGXLlLllQSgYigAEfHXJAERHVMaCc2k=
|
||||
golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
|
||||
golang.org/x/text v0.3.7/go.mod h1:u+2+/6zg+i71rQMx5EYifcz6MCKuco9NR6JIITiCfzQ=
|
||||
golang.org/x/text v0.7.0 h1:4BRB4x83lYWy72KwLD/qYDuTu7q9PjSagHvijDw7cLo=
|
||||
golang.org/x/text v0.7.0/go.mod h1:mrYo+phRRbMaCq/xk9113O4dZlRixOauAjOtrjsXDZ8=
|
||||
golang.org/x/time v0.0.0-20181108054448-85acf8d2951c/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
|
||||
golang.org/x/time v0.0.0-20190308202827-9d24e82272b4/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
|
||||
golang.org/x/time v0.0.0-20191024005414-555d28b269f0 h1:/5xXl8Y5W96D+TtHSlonuFqGHIWVuyCkGJLwGh9JJFs=
|
||||
golang.org/x/time v0.0.0-20191024005414-555d28b269f0/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ=
|
||||
golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
|
||||
golang.org/x/tools v0.0.0-20181011042414-1f849cf54d09/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
|
||||
|
|
@ -304,9 +363,11 @@ golang.org/x/tools v0.0.0-20191012152004-8de300cfc20a/go.mod h1:b+2E5dAYhXwXZwtn
|
|||
golang.org/x/tools v0.0.0-20191119224855-298f0cb1881e/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
|
||||
golang.org/x/tools v0.0.0-20191125144606-a911d9008d1f/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
|
||||
golang.org/x/tools v0.0.0-20191227053925-7b8e75db28f4/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28=
|
||||
golang.org/x/tools v0.1.12/go.mod h1:hNGJHUnrk76NpqgfD5Aqm5Crs+Hm0VOH/i9J2+nxYbc=
|
||||
golang.org/x/tools v0.0.0-20200619180055-7c47624df98f/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE=
|
||||
golang.org/x/tools v0.0.0-20210106214847-113979e3529a/go.mod h1:emZCQorbCU4vsT4fOWvOPXz4eW1wZW4PmDk9uLelYpA=
|
||||
golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
|
||||
golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
|
||||
golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543 h1:E7g+9GITq07hpfrRu66IVDexMakfv52eLZ2CXBWiKr4=
|
||||
golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
|
||||
golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
|
||||
golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0=
|
||||
|
|
@ -327,6 +388,8 @@ google.golang.org/genproto v0.0.0-20190801165951-fa694d86fc64/go.mod h1:DMBHOl98
|
|||
google.golang.org/genproto v0.0.0-20190819201941-24fa4b261c55/go.mod h1:DMBHOl98Agz4BDEuKkezgsaosCRResVns1a3J2ZsMNc=
|
||||
google.golang.org/genproto v0.0.0-20190911173649-1774047e7e51/go.mod h1:IbNlFCBrqXvoKpeg0TB2l7cyZUmoaFKYIwrEpbDKLA8=
|
||||
google.golang.org/genproto v0.0.0-20191230161307-f3c370f40bfb/go.mod h1:n3cpQtvxv34hfy77yVDNjmbRyujviMdxYliBSkLhpCc=
|
||||
google.golang.org/genproto v0.0.0-20200423170343-7949de9c1215/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c=
|
||||
google.golang.org/genproto v0.0.0-20200513103714-09dca8ec2884/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c=
|
||||
google.golang.org/genproto v0.0.0-20200526211855-cb27e3aa2013 h1:+kGHl1aib/qcwaRi1CbqBZ1rk19r85MNUf8HaBghugY=
|
||||
google.golang.org/genproto v0.0.0-20200526211855-cb27e3aa2013/go.mod h1:NbSheEEYHJ7i3ixzK3sjbqSGDJWnxyFXZblF3eUsNvo=
|
||||
google.golang.org/grpc v1.25.1 h1:wdKvqQk7IttEw92GoRyKG2IDrUIpgpj6H6m81yfeMW0=
|
||||
|
|
@ -352,6 +415,7 @@ gopkg.in/inf.v0 v0.9.1/go.mod h1:cWUDdTG/fYaXco+Dcufb5Vnc6Gp2YChqWtbxRZE0mXw=
|
|||
gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7/go.mod h1:dt/ZhP58zS4L8KSrWDmTeBkI65Dw0HsyUHuEVlX15mw=
|
||||
gopkg.in/yaml.v2 v2.2.1/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
|
||||
gopkg.in/yaml.v2 v2.2.2/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
|
||||
gopkg.in/yaml.v2 v2.2.3/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
|
||||
gopkg.in/yaml.v2 v2.2.4/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
|
||||
gopkg.in/yaml.v2 v2.2.5/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
|
||||
gopkg.in/yaml.v2 v2.2.8 h1:obN1ZagJSUGI0Ek/LBmuj4SNLPfIny3KsKFopxRdj10=
|
||||
|
|
@ -380,4 +444,5 @@ k8s.io/utils v0.0.0-20210305010621-2afb4311ab10/go.mod h1:jPW/WVKK9YHAvNhRxK0md/
|
|||
rsc.io/binaryregexp v0.2.0/go.mod h1:qTv7/COck+e2FymRvadv62gMdZztPaShugOCi3I+8D8=
|
||||
sigs.k8s.io/structured-merge-diff/v4 v4.0.1/go.mod h1:bJZC9H9iH24zzfZ/41RGcq60oK1F7G282QMXDPYydCw=
|
||||
sigs.k8s.io/yaml v1.1.0/go.mod h1:UJmg0vDUVViEyp3mgSv9WPwZCDxu4rQW1olrI1uml+o=
|
||||
sigs.k8s.io/yaml v1.2.0 h1:kr/MCeFWJWTwyaHoR9c8EjH9OumOmoF9YGiZd7lFm/Q=
|
||||
sigs.k8s.io/yaml v1.2.0/go.mod h1:yfXDCHCao9+ENCvLSE62v9VSji2MKu5jeNfTrofGhJc=
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ package vitastor
|
|||
|
||||
const (
|
||||
vitastorCSIDriverName = "csi.vitastor.io"
|
||||
vitastorCSIDriverVersion = "1.10.0"
|
||||
vitastorCSIDriverVersion = "0.6.17"
|
||||
)
|
||||
|
||||
// Config struct fills the parameters of request or user input
|
||||
|
|
|
|||
|
|
@ -6,10 +6,13 @@ package vitastor
|
|||
import (
|
||||
"context"
|
||||
"encoding/json"
|
||||
"fmt"
|
||||
"strings"
|
||||
"bytes"
|
||||
"strconv"
|
||||
"time"
|
||||
"fmt"
|
||||
"os"
|
||||
"os/exec"
|
||||
"io/ioutil"
|
||||
|
||||
"github.com/kubernetes-csi/csi-lib-utils/protosanitizer"
|
||||
|
|
@ -17,7 +20,8 @@ import (
|
|||
|
||||
"google.golang.org/grpc/codes"
|
||||
"google.golang.org/grpc/status"
|
||||
"google.golang.org/protobuf/types/known/timestamppb"
|
||||
|
||||
"go.etcd.io/etcd/clientv3"
|
||||
|
||||
"github.com/container-storage-interface/spec/lib/go/csi"
|
||||
)
|
||||
|
|
@ -43,7 +47,6 @@ type InodeConfig struct
|
|||
ParentPool uint64 `json:"parent_pool,omitempty"`
|
||||
ParentId uint64 `json:"parent_id,omitempty"`
|
||||
Readonly bool `json:"readonly,omitempty"`
|
||||
CreateTs uint64 `json:"create_ts,omitempty"`
|
||||
}
|
||||
|
||||
type ControllerServer struct
|
||||
|
|
@ -59,7 +62,7 @@ func NewControllerServer(driver *Driver) *ControllerServer
|
|||
}
|
||||
}
|
||||
|
||||
func GetConnectionParams(params map[string]string) (map[string]string, error)
|
||||
func GetConnectionParams(params map[string]string) (map[string]string, []string, string)
|
||||
{
|
||||
ctxVars := make(map[string]string)
|
||||
configPath := params["configPath"]
|
||||
|
|
@ -67,59 +70,48 @@ func GetConnectionParams(params map[string]string) (map[string]string, error)
|
|||
{
|
||||
configPath = "/etc/vitastor/vitastor.conf"
|
||||
}
|
||||
ctxVars["configPath"] = configPath
|
||||
if (params["vitastorfs"] != "")
|
||||
else
|
||||
{
|
||||
ctxVars["vitastorfs"] = params["vitastorfs"]
|
||||
ctxVars["configPath"] = configPath
|
||||
}
|
||||
config := make(map[string]interface{})
|
||||
configFD, err := os.Open(configPath)
|
||||
if (err != nil)
|
||||
if configFD, err := os.Open(configPath); err == nil
|
||||
{
|
||||
return nil, err
|
||||
defer configFD.Close()
|
||||
data, _ := ioutil.ReadAll(configFD)
|
||||
json.Unmarshal(data, &config)
|
||||
}
|
||||
defer configFD.Close()
|
||||
data, _ := ioutil.ReadAll(configFD)
|
||||
json.Unmarshal(data, &config)
|
||||
// Check etcd URL in the config, but do not use the explicit etcdUrl
|
||||
// parameter for CLI calls, otherwise users won't be able to later
|
||||
// change them - storage class parameters are saved in volume IDs
|
||||
// Try to load prefix & etcd URL from the config
|
||||
var etcdUrl []string
|
||||
switch config["etcd_address"].(type)
|
||||
if (params["etcdUrl"] != "")
|
||||
{
|
||||
case string:
|
||||
url := strings.TrimSpace(config["etcd_address"].(string))
|
||||
if (url != "")
|
||||
{
|
||||
etcdUrl = strings.Split(url, ",")
|
||||
}
|
||||
case []string:
|
||||
etcdUrl = config["etcd_address"].([]string)
|
||||
case []interface{}:
|
||||
for _, url := range config["etcd_address"].([]interface{})
|
||||
{
|
||||
s, ok := url.(string)
|
||||
if (ok)
|
||||
{
|
||||
etcdUrl = append(etcdUrl, s)
|
||||
}
|
||||
}
|
||||
ctxVars["etcdUrl"] = params["etcdUrl"]
|
||||
etcdUrl = strings.Split(params["etcdUrl"], ",")
|
||||
}
|
||||
if (len(etcdUrl) == 0)
|
||||
{
|
||||
return nil, status.Error(codes.InvalidArgument, "etcd_address is missing in "+configPath)
|
||||
switch config["etcd_address"].(type)
|
||||
{
|
||||
case string:
|
||||
etcdUrl = strings.Split(config["etcd_address"].(string), ",")
|
||||
case []string:
|
||||
etcdUrl = config["etcd_address"].([]string)
|
||||
}
|
||||
}
|
||||
return ctxVars, nil
|
||||
}
|
||||
|
||||
func invokeCLI(ctxVars map[string]string, args []string) ([]byte, error)
|
||||
{
|
||||
if (ctxVars["configPath"] != "")
|
||||
etcdPrefix := params["etcdPrefix"]
|
||||
if (etcdPrefix == "")
|
||||
{
|
||||
args = append(args, "--config_path", ctxVars["configPath"])
|
||||
etcdPrefix, _ = config["etcd_prefix"].(string)
|
||||
if (etcdPrefix == "")
|
||||
{
|
||||
etcdPrefix = "/vitastor"
|
||||
}
|
||||
}
|
||||
stdout, _, err := system("/usr/bin/vitastor-cli", args...)
|
||||
return stdout, err
|
||||
else
|
||||
{
|
||||
ctxVars["etcdPrefix"] = etcdPrefix
|
||||
}
|
||||
return ctxVars, etcdUrl, etcdPrefix
|
||||
}
|
||||
|
||||
// Create the volume
|
||||
|
|
@ -140,101 +132,142 @@ func (cs *ControllerServer) CreateVolume(ctx context.Context, req *csi.CreateVol
|
|||
return nil, status.Error(codes.InvalidArgument, "volume capabilities is a required field")
|
||||
}
|
||||
|
||||
ctxVars, err := GetConnectionParams(req.Parameters)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
|
||||
err = cs.checkCaps(volumeCapabilities, ctxVars["vitastorfs"] != "")
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
|
||||
pool := req.Parameters["poolId"]
|
||||
if (pool == "")
|
||||
etcdVolumePrefix := req.Parameters["etcdVolumePrefix"]
|
||||
poolId, _ := strconv.ParseUint(req.Parameters["poolId"], 10, 64)
|
||||
if (poolId == 0)
|
||||
{
|
||||
return nil, status.Error(codes.InvalidArgument, "poolId is missing in storage class configuration")
|
||||
}
|
||||
volumePrefix := req.Parameters["volumePrefix"]
|
||||
if (volumePrefix == "")
|
||||
{
|
||||
// Old name
|
||||
volumePrefix = req.Parameters["etcdVolumePrefix"]
|
||||
}
|
||||
volName := volumePrefix + req.GetName()
|
||||
|
||||
volName := etcdVolumePrefix + req.GetName()
|
||||
volSize := 1 * GB
|
||||
if capRange := req.GetCapacityRange(); capRange != nil
|
||||
{
|
||||
volSize = ((capRange.GetRequiredBytes() + MB - 1) / MB) * MB
|
||||
}
|
||||
|
||||
if (ctxVars["vitastorfs"] != "")
|
||||
// FIXME: The following should PROBABLY be implemented externally in a management tool
|
||||
|
||||
ctxVars, etcdUrl, etcdPrefix := GetConnectionParams(req.Parameters)
|
||||
if (len(etcdUrl) == 0)
|
||||
{
|
||||
// Nothing to create, subdirectories are created during mounting
|
||||
// FIXME: It would be cool to support quotas some day and set it here
|
||||
if (req.VolumeContentSource.GetSnapshot() != nil)
|
||||
{
|
||||
return nil, status.Error(codes.InvalidArgument, "VitastorFS doesn't support snapshots")
|
||||
}
|
||||
ctxVars["name"] = volName
|
||||
ctxVars["pool"] = pool
|
||||
volumeIdJson, _ := json.Marshal(ctxVars)
|
||||
return &csi.CreateVolumeResponse{
|
||||
Volume: &csi.Volume{
|
||||
// Ugly, but VolumeContext isn't passed to DeleteVolume :-(
|
||||
VolumeId: string(volumeIdJson),
|
||||
CapacityBytes: volSize,
|
||||
},
|
||||
}, nil
|
||||
return nil, status.Error(codes.InvalidArgument, "no etcdUrl in storage class configuration and no etcd_address in vitastor.conf")
|
||||
}
|
||||
|
||||
args := []string{ "create", volName, "-s", fmt.Sprintf("%v", volSize), "--pool", pool }
|
||||
|
||||
// Support creation from snapshot
|
||||
var src *csi.VolumeContentSource
|
||||
if (req.VolumeContentSource.GetSnapshot() != nil)
|
||||
{
|
||||
snapId := req.VolumeContentSource.GetSnapshot().GetSnapshotId()
|
||||
if (snapId != "")
|
||||
{
|
||||
snapVars := make(map[string]string)
|
||||
err := json.Unmarshal([]byte(snapId), &snapVars)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "volume ID not in JSON format")
|
||||
}
|
||||
args = append(args, "--parent", snapVars["name"]+"@"+snapVars["snapshot"])
|
||||
src = &csi.VolumeContentSource{
|
||||
Type: &csi.VolumeContentSource_Snapshot{
|
||||
Snapshot: &csi.VolumeContentSource_SnapshotSource{
|
||||
SnapshotId: snapId,
|
||||
},
|
||||
},
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Create image using vitastor-cli
|
||||
_, err = invokeCLI(ctxVars, args)
|
||||
// Connect to etcd
|
||||
cli, err := clientv3.New(clientv3.Config{
|
||||
DialTimeout: ETCD_TIMEOUT,
|
||||
Endpoints: etcdUrl,
|
||||
})
|
||||
if (err != nil)
|
||||
{
|
||||
if (strings.Index(err.Error(), "already exists") > 0)
|
||||
return nil, status.Error(codes.Internal, "failed to connect to etcd at "+strings.Join(etcdUrl, ",")+": "+err.Error())
|
||||
}
|
||||
defer cli.Close()
|
||||
|
||||
var imageId uint64 = 0
|
||||
for
|
||||
{
|
||||
// Check if the image exists
|
||||
ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
|
||||
resp, err := cli.Get(ctx, etcdPrefix+"/index/image/"+volName)
|
||||
cancel()
|
||||
if (err != nil)
|
||||
{
|
||||
inodeCfg, err := invokeList(ctxVars, volName, true)
|
||||
return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
|
||||
}
|
||||
if (len(resp.Kvs) > 0)
|
||||
{
|
||||
kv := resp.Kvs[0]
|
||||
var v InodeIndex
|
||||
err := json.Unmarshal(kv.Value, &v)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
return nil, status.Error(codes.Internal, "invalid /index/image/"+volName+" key in etcd: "+err.Error())
|
||||
}
|
||||
if (inodeCfg[0].Size < uint64(volSize))
|
||||
poolId = v.PoolId
|
||||
imageId = v.Id
|
||||
inodeCfgKey := fmt.Sprintf("/config/inode/%d/%d", poolId, imageId)
|
||||
ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
|
||||
resp, err := cli.Get(ctx, etcdPrefix+inodeCfgKey)
|
||||
cancel()
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
|
||||
}
|
||||
if (len(resp.Kvs) == 0)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "missing "+inodeCfgKey+" key in etcd")
|
||||
}
|
||||
var inodeCfg InodeConfig
|
||||
err = json.Unmarshal(resp.Kvs[0].Value, &inodeCfg)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "invalid "+inodeCfgKey+" key in etcd: "+err.Error())
|
||||
}
|
||||
if (inodeCfg.Size < uint64(volSize))
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "image "+volName+" is already created, but size is less than expected")
|
||||
}
|
||||
}
|
||||
else
|
||||
{
|
||||
return nil, err
|
||||
// Find a free ID
|
||||
// Create image metadata in a transaction verifying that the image doesn't exist yet AND ID is still free
|
||||
maxIdKey := fmt.Sprintf("%s/index/maxid/%d", etcdPrefix, poolId)
|
||||
ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
|
||||
resp, err := cli.Get(ctx, maxIdKey)
|
||||
cancel()
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
|
||||
}
|
||||
var modRev int64
|
||||
var nextId uint64
|
||||
if (len(resp.Kvs) > 0)
|
||||
{
|
||||
var err error
|
||||
nextId, err = strconv.ParseUint(string(resp.Kvs[0].Value), 10, 64)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, maxIdKey+" contains invalid ID")
|
||||
}
|
||||
modRev = resp.Kvs[0].ModRevision
|
||||
nextId++
|
||||
}
|
||||
else
|
||||
{
|
||||
nextId = 1
|
||||
}
|
||||
inodeIdxJson, _ := json.Marshal(InodeIndex{
|
||||
Id: nextId,
|
||||
PoolId: poolId,
|
||||
})
|
||||
inodeCfgJson, _ := json.Marshal(InodeConfig{
|
||||
Name: volName,
|
||||
Size: uint64(volSize),
|
||||
})
|
||||
ctx, cancel = context.WithTimeout(context.Background(), ETCD_TIMEOUT)
|
||||
txnResp, err := cli.Txn(ctx).If(
|
||||
clientv3.Compare(clientv3.ModRevision(fmt.Sprintf("%s/index/maxid/%d", etcdPrefix, poolId)), "=", modRev),
|
||||
clientv3.Compare(clientv3.CreateRevision(fmt.Sprintf("%s/index/image/%s", etcdPrefix, volName)), "=", 0),
|
||||
clientv3.Compare(clientv3.CreateRevision(fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, poolId, nextId)), "=", 0),
|
||||
).Then(
|
||||
clientv3.OpPut(fmt.Sprintf("%s/index/maxid/%d", etcdPrefix, poolId), fmt.Sprintf("%d", nextId)),
|
||||
clientv3.OpPut(fmt.Sprintf("%s/index/image/%s", etcdPrefix, volName), string(inodeIdxJson)),
|
||||
clientv3.OpPut(fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, poolId, nextId), string(inodeCfgJson)),
|
||||
).Commit()
|
||||
cancel()
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "failed to commit transaction in etcd: "+err.Error())
|
||||
}
|
||||
if (txnResp.Succeeded)
|
||||
{
|
||||
imageId = nextId
|
||||
break
|
||||
}
|
||||
// Start over if the transaction fails
|
||||
}
|
||||
}
|
||||
|
||||
|
|
@ -245,7 +278,6 @@ func (cs *ControllerServer) CreateVolume(ctx context.Context, req *csi.CreateVol
|
|||
// Ugly, but VolumeContext isn't passed to DeleteVolume :-(
|
||||
VolumeId: string(volumeIdJson),
|
||||
CapacityBytes: volSize,
|
||||
ContentSource: src,
|
||||
},
|
||||
}, nil
|
||||
}
|
||||
|
|
@ -259,30 +291,105 @@ func (cs *ControllerServer) DeleteVolume(ctx context.Context, req *csi.DeleteVol
|
|||
return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
|
||||
}
|
||||
|
||||
volVars := make(map[string]string)
|
||||
err := json.Unmarshal([]byte(req.VolumeId), &volVars)
|
||||
ctxVars := make(map[string]string)
|
||||
err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "volume ID not in JSON format")
|
||||
}
|
||||
volName := volVars["name"]
|
||||
volName := ctxVars["name"]
|
||||
|
||||
ctxVars, err := GetConnectionParams(volVars)
|
||||
if (err != nil)
|
||||
_, etcdUrl, etcdPrefix := GetConnectionParams(ctxVars)
|
||||
if (len(etcdUrl) == 0)
|
||||
{
|
||||
return nil, err
|
||||
return nil, status.Error(codes.InvalidArgument, "no etcdUrl in storage class configuration and no etcd_address in vitastor.conf")
|
||||
}
|
||||
|
||||
if (ctxVars["vitastorfs"] != "")
|
||||
{
|
||||
// FIXME: Delete FS subdirectory
|
||||
return &csi.DeleteVolumeResponse{}, nil
|
||||
}
|
||||
|
||||
_, err = invokeCLI(ctxVars, []string{ "rm", volName })
|
||||
cli, err := clientv3.New(clientv3.Config{
|
||||
DialTimeout: ETCD_TIMEOUT,
|
||||
Endpoints: etcdUrl,
|
||||
})
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
return nil, status.Error(codes.Internal, "failed to connect to etcd at "+strings.Join(etcdUrl, ",")+": "+err.Error())
|
||||
}
|
||||
defer cli.Close()
|
||||
|
||||
// Find inode by name
|
||||
ctx, cancel := context.WithTimeout(context.Background(), ETCD_TIMEOUT)
|
||||
resp, err := cli.Get(ctx, etcdPrefix+"/index/image/"+volName)
|
||||
cancel()
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
|
||||
}
|
||||
if (len(resp.Kvs) == 0)
|
||||
{
|
||||
return nil, status.Error(codes.NotFound, "volume "+volName+" does not exist")
|
||||
}
|
||||
var idx InodeIndex
|
||||
err = json.Unmarshal(resp.Kvs[0].Value, &idx)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "invalid /index/image/"+volName+" key in etcd: "+err.Error())
|
||||
}
|
||||
|
||||
// Get inode config
|
||||
inodeCfgKey := fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, idx.PoolId, idx.Id)
|
||||
ctx, cancel = context.WithTimeout(context.Background(), ETCD_TIMEOUT)
|
||||
resp, err = cli.Get(ctx, inodeCfgKey)
|
||||
cancel()
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "failed to read key from etcd: "+err.Error())
|
||||
}
|
||||
if (len(resp.Kvs) == 0)
|
||||
{
|
||||
return nil, status.Error(codes.NotFound, "volume "+volName+" does not exist")
|
||||
}
|
||||
var inodeCfg InodeConfig
|
||||
err = json.Unmarshal(resp.Kvs[0].Value, &inodeCfg)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "invalid "+inodeCfgKey+" key in etcd: "+err.Error())
|
||||
}
|
||||
|
||||
// Delete inode data by invoking vitastor-cli
|
||||
args := []string{
|
||||
"rm-data", "--etcd_address", strings.Join(etcdUrl, ","),
|
||||
"--pool", fmt.Sprintf("%d", idx.PoolId),
|
||||
"--inode", fmt.Sprintf("%d", idx.Id),
|
||||
}
|
||||
if (ctxVars["configPath"] != "")
|
||||
{
|
||||
args = append(args, "--config_path", ctxVars["configPath"])
|
||||
}
|
||||
c := exec.Command("/usr/bin/vitastor-cli", args...)
|
||||
var stderr bytes.Buffer
|
||||
c.Stdout = nil
|
||||
c.Stderr = &stderr
|
||||
err = c.Run()
|
||||
stderrStr := string(stderr.Bytes())
|
||||
if (err != nil)
|
||||
{
|
||||
klog.Errorf("vitastor-cli rm-data failed: %s, status %s\n", stderrStr, err)
|
||||
return nil, status.Error(codes.Internal, stderrStr+" (status "+err.Error()+")")
|
||||
}
|
||||
|
||||
// Delete inode config in etcd
|
||||
ctx, cancel = context.WithTimeout(context.Background(), ETCD_TIMEOUT)
|
||||
txnResp, err := cli.Txn(ctx).Then(
|
||||
clientv3.OpDelete(fmt.Sprintf("%s/index/image/%s", etcdPrefix, volName)),
|
||||
clientv3.OpDelete(fmt.Sprintf("%s/config/inode/%d/%d", etcdPrefix, idx.PoolId, idx.Id)),
|
||||
).Commit()
|
||||
cancel()
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "failed to delete keys in etcd: "+err.Error())
|
||||
}
|
||||
if (!txnResp.Succeeded)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "failed to delete keys in etcd: transaction failed")
|
||||
}
|
||||
|
||||
return &csi.DeleteVolumeResponse{}, nil
|
||||
|
|
@ -313,72 +420,19 @@ func (cs *ControllerServer) ValidateVolumeCapabilities(ctx context.Context, req
|
|||
{
|
||||
return nil, status.Error(codes.InvalidArgument, "volumeId is nil")
|
||||
}
|
||||
volVars := make(map[string]string)
|
||||
err := json.Unmarshal([]byte(volumeID), &volVars)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "volume ID not in JSON format")
|
||||
}
|
||||
ctxVars, err := GetConnectionParams(volVars)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
|
||||
volumeCapabilities := req.GetVolumeCapabilities()
|
||||
if (volumeCapabilities == nil)
|
||||
{
|
||||
return nil, status.Error(codes.InvalidArgument, "volumeCapabilities is nil")
|
||||
}
|
||||
|
||||
err = cs.checkCaps(volumeCapabilities, ctxVars["vitastorfs"] != "")
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
|
||||
return &csi.ValidateVolumeCapabilitiesResponse{
|
||||
Confirmed: &csi.ValidateVolumeCapabilitiesResponse_Confirmed{
|
||||
VolumeCapabilities: req.VolumeCapabilities,
|
||||
},
|
||||
}, nil
|
||||
}
|
||||
|
||||
func (cs *ControllerServer) checkCaps(volumeCapabilities []*csi.VolumeCapability, fs bool) error
|
||||
{
|
||||
var volumeCapabilityAccessModes []*csi.VolumeCapability_AccessMode
|
||||
for _, mode := range []csi.VolumeCapability_AccessMode_Mode{
|
||||
csi.VolumeCapability_AccessMode_SINGLE_NODE_WRITER,
|
||||
csi.VolumeCapability_AccessMode_SINGLE_NODE_READER_ONLY,
|
||||
csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY,
|
||||
csi.VolumeCapability_AccessMode_SINGLE_NODE_SINGLE_WRITER,
|
||||
csi.VolumeCapability_AccessMode_SINGLE_NODE_MULTI_WRITER,
|
||||
csi.VolumeCapability_AccessMode_MULTI_NODE_MULTI_WRITER,
|
||||
} {
|
||||
volumeCapabilityAccessModes = append(volumeCapabilityAccessModes, &csi.VolumeCapability_AccessMode{Mode: mode})
|
||||
}
|
||||
for _, capability := range volumeCapabilities
|
||||
{
|
||||
if (capability.GetBlock() != nil)
|
||||
{
|
||||
if (fs)
|
||||
{
|
||||
return status.Errorf(codes.InvalidArgument, "%v not supported with FS-based volumes", capability)
|
||||
}
|
||||
for _, mode := range []csi.VolumeCapability_AccessMode_Mode{
|
||||
csi.VolumeCapability_AccessMode_MULTI_NODE_SINGLE_WRITER,
|
||||
csi.VolumeCapability_AccessMode_MULTI_NODE_MULTI_WRITER,
|
||||
} {
|
||||
volumeCapabilityAccessModes = append(volumeCapabilityAccessModes, &csi.VolumeCapability_AccessMode{Mode: mode})
|
||||
}
|
||||
break
|
||||
}
|
||||
}
|
||||
|
||||
if (fs)
|
||||
{
|
||||
// All access modes including RWX are supported with FS-based volumes
|
||||
return nil
|
||||
}
|
||||
|
||||
capabilitySupport := false
|
||||
for _, capability := range volumeCapabilities
|
||||
|
|
@ -394,10 +448,14 @@ func (cs *ControllerServer) checkCaps(volumeCapabilities []*csi.VolumeCapability
|
|||
|
||||
if (!capabilitySupport)
|
||||
{
|
||||
return status.Errorf(codes.InvalidArgument, "%v not supported", volumeCapabilities)
|
||||
return nil, status.Errorf(codes.NotFound, "%v not supported", req.GetVolumeCapabilities())
|
||||
}
|
||||
|
||||
return nil
|
||||
return &csi.ValidateVolumeCapabilitiesResponse{
|
||||
Confirmed: &csi.ValidateVolumeCapabilitiesResponse_Confirmed{
|
||||
VolumeCapabilities: req.VolumeCapabilities,
|
||||
},
|
||||
}, nil
|
||||
}
|
||||
|
||||
// ListVolumes returns a list of volumes
|
||||
|
|
@ -432,8 +490,6 @@ func (cs *ControllerServer) ControllerGetCapabilities(ctx context.Context, req *
|
|||
csi.ControllerServiceCapability_RPC_LIST_VOLUMES,
|
||||
csi.ControllerServiceCapability_RPC_EXPAND_VOLUME,
|
||||
csi.ControllerServiceCapability_RPC_CREATE_DELETE_SNAPSHOT,
|
||||
csi.ControllerServiceCapability_RPC_LIST_SNAPSHOTS,
|
||||
// TODO: csi.ControllerServiceCapability_RPC_CLONE_VOLUME,
|
||||
} {
|
||||
controllerServerCapabilities = append(controllerServerCapabilities, functionControllerServerCapabilities(capability))
|
||||
}
|
||||
|
|
@ -443,252 +499,28 @@ func (cs *ControllerServer) ControllerGetCapabilities(ctx context.Context, req *
|
|||
}, nil
|
||||
}
|
||||
|
||||
func invokeList(ctxVars map[string]string, pattern string, expectExist bool) ([]InodeConfig, error)
|
||||
{
|
||||
stat, err := invokeCLI(ctxVars, []string{ "ls", "--json", pattern })
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
var inodeCfg []InodeConfig
|
||||
err = json.Unmarshal(stat, &inodeCfg)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "Invalid JSON in vitastor-cli ls: "+err.Error())
|
||||
}
|
||||
if (expectExist && len(inodeCfg) == 0)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "Can't find expected image "+pattern+" via vitastor-cli ls")
|
||||
}
|
||||
return inodeCfg, nil
|
||||
}
|
||||
|
||||
// CreateSnapshot create snapshot of an existing PV
|
||||
func (cs *ControllerServer) CreateSnapshot(ctx context.Context, req *csi.CreateSnapshotRequest) (*csi.CreateSnapshotResponse, error)
|
||||
{
|
||||
klog.Infof("received controller create snapshot request %+v", protosanitizer.StripSecrets(req))
|
||||
if (req == nil)
|
||||
{
|
||||
return nil, status.Errorf(codes.InvalidArgument, "request cannot be empty")
|
||||
}
|
||||
if (req.SourceVolumeId == "" || req.Name == "")
|
||||
{
|
||||
return nil, status.Error(codes.InvalidArgument, "source volume ID and snapshot name are required fields")
|
||||
}
|
||||
|
||||
// snapshot name
|
||||
snapName := req.Name
|
||||
|
||||
// req.VolumeId is an ugly json string in our case :)
|
||||
ctxVars := make(map[string]string)
|
||||
err := json.Unmarshal([]byte(req.SourceVolumeId), &ctxVars)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "volume ID not in JSON format")
|
||||
}
|
||||
|
||||
if (ctxVars["vitastorfs"] != "")
|
||||
{
|
||||
return nil, status.Error(codes.InvalidArgument, "VitastorFS doesn't support snapshots")
|
||||
}
|
||||
|
||||
volName := ctxVars["name"]
|
||||
|
||||
// Create image using vitastor-cli
|
||||
_, err = invokeCLI(ctxVars, []string{ "create", "--snapshot", snapName, volName })
|
||||
if (err != nil && strings.Index(err.Error(), "already exists") <= 0)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
|
||||
// Check created snapshot
|
||||
inodeCfg, err := invokeList(ctxVars, volName+"@"+snapName, true)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
|
||||
// Use ugly JSON snapshot ID again, DeleteSnapshot doesn't have context :-(
|
||||
ctxVars["snapshot"] = snapName
|
||||
snapIdJson, _ := json.Marshal(ctxVars)
|
||||
return &csi.CreateSnapshotResponse{
|
||||
Snapshot: &csi.Snapshot{
|
||||
SizeBytes: int64(inodeCfg[0].Size),
|
||||
SnapshotId: string(snapIdJson),
|
||||
SourceVolumeId: req.SourceVolumeId,
|
||||
CreationTime: ×tamppb.Timestamp{ Seconds: int64(inodeCfg[0].CreateTs) },
|
||||
ReadyToUse: true,
|
||||
},
|
||||
}, nil
|
||||
return nil, status.Error(codes.Unimplemented, "")
|
||||
}
|
||||
|
||||
// DeleteSnapshot delete provided snapshot of a PV
|
||||
func (cs *ControllerServer) DeleteSnapshot(ctx context.Context, req *csi.DeleteSnapshotRequest) (*csi.DeleteSnapshotResponse, error)
|
||||
{
|
||||
klog.Infof("received controller delete snapshot request %+v", protosanitizer.StripSecrets(req))
|
||||
if (req == nil)
|
||||
{
|
||||
return nil, status.Errorf(codes.InvalidArgument, "request cannot be empty")
|
||||
}
|
||||
if (req.SnapshotId == "")
|
||||
{
|
||||
return nil, status.Error(codes.InvalidArgument, "snapshot ID is a required field")
|
||||
}
|
||||
|
||||
volVars := make(map[string]string)
|
||||
err := json.Unmarshal([]byte(req.SnapshotId), &volVars)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "snapshot ID not in JSON format")
|
||||
}
|
||||
volName := volVars["name"]
|
||||
snapName := volVars["snapshot"]
|
||||
|
||||
ctxVars, err := GetConnectionParams(volVars)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
|
||||
if (ctxVars["vitastorfs"] != "")
|
||||
{
|
||||
return nil, status.Error(codes.InvalidArgument, "VitastorFS doesn't support snapshots")
|
||||
}
|
||||
|
||||
_, err = invokeCLI(ctxVars, []string{ "rm", volName+"@"+snapName })
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
|
||||
return &csi.DeleteSnapshotResponse{}, nil
|
||||
return nil, status.Error(codes.Unimplemented, "")
|
||||
}
|
||||
|
||||
// ListSnapshots list the snapshots of a PV
|
||||
func (cs *ControllerServer) ListSnapshots(ctx context.Context, req *csi.ListSnapshotsRequest) (*csi.ListSnapshotsResponse, error)
|
||||
{
|
||||
klog.Infof("received controller list snapshots request %+v", protosanitizer.StripSecrets(req))
|
||||
if (req == nil)
|
||||
{
|
||||
return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
|
||||
}
|
||||
|
||||
volVars := make(map[string]string)
|
||||
err := json.Unmarshal([]byte(req.SourceVolumeId), &volVars)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "volume ID not in JSON format")
|
||||
}
|
||||
volName := volVars["name"]
|
||||
ctxVars, err := GetConnectionParams(volVars)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
|
||||
if (ctxVars["vitastorfs"] != "")
|
||||
{
|
||||
return nil, status.Error(codes.InvalidArgument, "VitastorFS doesn't support snapshots")
|
||||
}
|
||||
|
||||
inodeCfg, err := invokeList(ctxVars, volName+"@*", false)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
|
||||
resp := &csi.ListSnapshotsResponse{}
|
||||
for _, ino := range inodeCfg
|
||||
{
|
||||
snapName := ino.Name[len(volName)+1:]
|
||||
if (len(req.StartingToken) > 0 && snapName < req.StartingToken)
|
||||
{
|
||||
}
|
||||
else if (req.MaxEntries == 0 || len(resp.Entries) < int(req.MaxEntries))
|
||||
{
|
||||
volVars["snapshot"] = snapName
|
||||
snapIdJson, _ := json.Marshal(volVars)
|
||||
resp.Entries = append(resp.Entries, &csi.ListSnapshotsResponse_Entry{
|
||||
Snapshot: &csi.Snapshot{
|
||||
SizeBytes: int64(ino.Size),
|
||||
SnapshotId: string(snapIdJson),
|
||||
SourceVolumeId: req.SourceVolumeId,
|
||||
CreationTime: ×tamppb.Timestamp{ Seconds: int64(ino.CreateTs) },
|
||||
ReadyToUse: true,
|
||||
},
|
||||
})
|
||||
}
|
||||
else
|
||||
{
|
||||
resp.NextToken = snapName
|
||||
break
|
||||
}
|
||||
}
|
||||
|
||||
return resp, nil
|
||||
return nil, status.Error(codes.Unimplemented, "")
|
||||
}
|
||||
|
||||
// ControllerExpandVolume increases the size of a volume
|
||||
// ControllerExpandVolume resizes a volume
|
||||
func (cs *ControllerServer) ControllerExpandVolume(ctx context.Context, req *csi.ControllerExpandVolumeRequest) (*csi.ControllerExpandVolumeResponse, error)
|
||||
{
|
||||
klog.Infof("received controller expand volume request %+v", protosanitizer.StripSecrets(req))
|
||||
if (req == nil)
|
||||
{
|
||||
return nil, status.Error(codes.InvalidArgument, "request cannot be empty")
|
||||
}
|
||||
if (req.VolumeId == "" || req.CapacityRange == nil || req.CapacityRange.RequiredBytes == 0)
|
||||
{
|
||||
return nil, status.Error(codes.InvalidArgument, "VolumeId, CapacityRange and RequiredBytes are required fields")
|
||||
}
|
||||
|
||||
volVars := make(map[string]string)
|
||||
err := json.Unmarshal([]byte(req.VolumeId), &volVars)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, status.Error(codes.Internal, "volume ID not in JSON format")
|
||||
}
|
||||
volName := volVars["name"]
|
||||
ctxVars, err := GetConnectionParams(volVars)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
|
||||
if (ctxVars["vitastorfs"] != "")
|
||||
{
|
||||
// Nothing to change
|
||||
// FIXME: Support quotas and change quota here
|
||||
return &csi.ControllerExpandVolumeResponse{
|
||||
CapacityBytes: req.CapacityRange.RequiredBytes,
|
||||
NodeExpansionRequired: false,
|
||||
}, nil
|
||||
}
|
||||
|
||||
inodeCfg, err := invokeList(ctxVars, volName, true)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
|
||||
if (req.CapacityRange.RequiredBytes > 0 && inodeCfg[0].Size < uint64(req.CapacityRange.RequiredBytes))
|
||||
{
|
||||
sz := ((req.CapacityRange.RequiredBytes+4095)/4096)*4096
|
||||
_, err := invokeCLI(ctxVars, []string{ "modify", "--inc_size", "1", "--resize", fmt.Sprintf("%d", sz), volName })
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
inodeCfg, err = invokeList(ctxVars, volName, true)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
}
|
||||
|
||||
return &csi.ControllerExpandVolumeResponse{
|
||||
CapacityBytes: int64(inodeCfg[0].Size),
|
||||
NodeExpansionRequired: false,
|
||||
}, nil
|
||||
return nil, status.Error(codes.Unimplemented, "")
|
||||
}
|
||||
|
||||
// ControllerGetVolume get volume info
|
||||
|
|
|
|||
|
|
@ -49,13 +49,6 @@ func (is *IdentityServer) GetPluginCapabilities(ctx context.Context, req *csi.Ge
|
|||
},
|
||||
},
|
||||
},
|
||||
{
|
||||
Type: &csi.PluginCapability_VolumeExpansion_{
|
||||
VolumeExpansion: &csi.PluginCapability_VolumeExpansion{
|
||||
Type: csi.PluginCapability_VolumeExpansion_OFFLINE,
|
||||
},
|
||||
},
|
||||
},
|
||||
},
|
||||
}, nil
|
||||
}
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
342
csi/src/utils.go
342
csi/src/utils.go
|
|
@ -1,342 +0,0 @@
|
|||
// Copyright (c) Vitaliy Filippov, 2019+
|
||||
// License: VNPL-1.1 or GNU GPL-2.0+ (see README.md for details)
|
||||
|
||||
package vitastor
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"errors"
|
||||
"encoding/json"
|
||||
"fmt"
|
||||
"os"
|
||||
"os/exec"
|
||||
"path/filepath"
|
||||
"strconv"
|
||||
"strings"
|
||||
"syscall"
|
||||
|
||||
"k8s.io/klog"
|
||||
"google.golang.org/grpc/codes"
|
||||
"google.golang.org/grpc/status"
|
||||
)
|
||||
|
||||
func Contains(list []string, s string) bool
|
||||
{
|
||||
for i := 0; i < len(list); i++
|
||||
{
|
||||
if (list[i] == s)
|
||||
{
|
||||
return true
|
||||
}
|
||||
}
|
||||
return false
|
||||
}
|
||||
|
||||
func checkVduseSupport() bool
|
||||
{
|
||||
// Check VDUSE support (vdpa, vduse, virtio-vdpa kernel modules)
|
||||
vduse := true
|
||||
for _, mod := range []string{"vdpa", "vduse", "virtio-vdpa"}
|
||||
{
|
||||
_, err := os.Stat("/sys/module/"+mod)
|
||||
if (err != nil)
|
||||
{
|
||||
if (!errors.Is(err, os.ErrNotExist))
|
||||
{
|
||||
klog.Errorf("failed to check /sys/module/%s: %v", mod, err)
|
||||
}
|
||||
c := exec.Command("/sbin/modprobe", mod)
|
||||
c.Stdout = os.Stderr
|
||||
c.Stderr = os.Stderr
|
||||
err := c.Run()
|
||||
if (err != nil)
|
||||
{
|
||||
klog.Errorf("/sbin/modprobe %s failed: %v", mod, err)
|
||||
vduse = false
|
||||
break
|
||||
}
|
||||
}
|
||||
}
|
||||
// Check that vdpa tool functions
|
||||
if (vduse)
|
||||
{
|
||||
c := exec.Command("/sbin/vdpa", "-j", "dev")
|
||||
c.Stderr = os.Stderr
|
||||
err := c.Run()
|
||||
if (err != nil)
|
||||
{
|
||||
klog.Errorf("/sbin/vdpa -j dev failed: %v", err)
|
||||
vduse = false
|
||||
}
|
||||
}
|
||||
if (!vduse)
|
||||
{
|
||||
klog.Errorf(
|
||||
"Your host apparently has no VDUSE support. VDUSE support disabled, NBD will be used to map devices."+
|
||||
" For VDUSE you need at least Linux 5.15 and the following kernel modules: vdpa, virtio-vdpa, vduse.",
|
||||
)
|
||||
}
|
||||
else
|
||||
{
|
||||
klog.Infof("VDUSE support enabled successfully")
|
||||
}
|
||||
return vduse
|
||||
}
|
||||
|
||||
func mapNbd(volName string, ctxVars map[string]string, readonly bool) (string, error)
|
||||
{
|
||||
// Map NBD device
|
||||
// FIXME: Check if already mapped
|
||||
args := []string{
|
||||
"map", "--image", volName,
|
||||
}
|
||||
if (ctxVars["configPath"] != "")
|
||||
{
|
||||
args = append(args, "--config_path", ctxVars["configPath"])
|
||||
}
|
||||
if (readonly)
|
||||
{
|
||||
args = append(args, "--readonly", "1")
|
||||
}
|
||||
stdout, stderr, err := system("/usr/bin/vitastor-nbd", args...)
|
||||
dev := strings.TrimSpace(string(stdout))
|
||||
if (dev == "")
|
||||
{
|
||||
return "", fmt.Errorf("vitastor-nbd did not return the name of NBD device. output: %s", stderr)
|
||||
}
|
||||
klog.Infof("Attached volume %s via NBD as %s", volName, dev)
|
||||
return dev, err
|
||||
}
|
||||
|
||||
func unmapNbd(devicePath string)
|
||||
{
|
||||
// unmap NBD device
|
||||
unmapOut, unmapErr := exec.Command("/usr/bin/vitastor-nbd", "unmap", devicePath).CombinedOutput()
|
||||
if (unmapErr != nil)
|
||||
{
|
||||
klog.Errorf("failed to unmap NBD device %s: %s, error: %v", devicePath, unmapOut, unmapErr)
|
||||
}
|
||||
}
|
||||
|
||||
func findByPidFile(pidFile string) (*os.Process, error)
|
||||
{
|
||||
pidBuf, err := os.ReadFile(pidFile)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
pid, err := strconv.ParseInt(strings.TrimSpace(string(pidBuf)), 0, 64)
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
proc, err := os.FindProcess(int(pid))
|
||||
if (err != nil)
|
||||
{
|
||||
return nil, err
|
||||
}
|
||||
return proc, nil
|
||||
}
|
||||
|
||||
func killByPidFile(pidFile string) error
|
||||
{
|
||||
klog.Infof("killing process with PID from file %s", pidFile)
|
||||
proc, err := findByPidFile(pidFile)
|
||||
if (err != nil)
|
||||
{
|
||||
return err
|
||||
}
|
||||
return proc.Signal(syscall.SIGTERM)
|
||||
}
|
||||
|
||||
func startStorageDaemon(vdpaId, volName, pidFile, configPath string, readonly bool) error
|
||||
{
|
||||
// Start qemu-storage-daemon
|
||||
blockSpec := map[string]interface{}{
|
||||
"node-name": "disk1",
|
||||
"driver": "vitastor",
|
||||
"image": volName,
|
||||
"cache": map[string]bool{
|
||||
"direct": true,
|
||||
"no-flush": false,
|
||||
},
|
||||
"discard": "unmap",
|
||||
}
|
||||
if (configPath != "")
|
||||
{
|
||||
blockSpec["config-path"] = configPath
|
||||
}
|
||||
blockSpecJson, _ := json.Marshal(blockSpec)
|
||||
writable := "true"
|
||||
if (readonly)
|
||||
{
|
||||
writable = "false"
|
||||
}
|
||||
_, _, err := system(
|
||||
"/usr/bin/qemu-storage-daemon", "--daemonize", "--pidfile", pidFile, "--blockdev", string(blockSpecJson),
|
||||
"--export", "vduse-blk,id="+vdpaId+",node-name=disk1,name="+vdpaId+",num-queues=16,queue-size=128,writable="+writable,
|
||||
)
|
||||
return err
|
||||
}
|
||||
|
||||
func mapVduse(stateDir string, volName string, ctxVars map[string]string, readonly bool) (string, string, error)
|
||||
{
|
||||
// Generate state file
|
||||
stateFd, err := os.CreateTemp(stateDir, "vitastor-vduse-*.json")
|
||||
if (err != nil)
|
||||
{
|
||||
return "", "", err
|
||||
}
|
||||
stateFile := stateFd.Name()
|
||||
stateFd.Close()
|
||||
vdpaId := filepath.Base(stateFile)
|
||||
vdpaId = vdpaId[0:len(vdpaId)-5] // remove ".json"
|
||||
pidFile := stateDir + vdpaId + ".pid"
|
||||
// Map VDUSE device via qemu-storage-daemon
|
||||
err = startStorageDaemon(vdpaId, volName, pidFile, ctxVars["configPath"], readonly)
|
||||
if (err == nil)
|
||||
{
|
||||
// Add device to VDPA bus
|
||||
_, _, err = system("/sbin/vdpa", "-j", "dev", "add", "name", vdpaId, "mgmtdev", "vduse")
|
||||
if (err == nil)
|
||||
{
|
||||
// Find block device name
|
||||
var matches []string
|
||||
matches, err = filepath.Glob("/sys/bus/vdpa/devices/"+vdpaId+"/virtio*/block/*")
|
||||
if (err == nil && len(matches) == 0)
|
||||
{
|
||||
err = errors.New("/sys/bus/vdpa/devices/"+vdpaId+"/virtio*/block/* is not found")
|
||||
}
|
||||
if (err == nil)
|
||||
{
|
||||
blockdev := "/dev/"+filepath.Base(matches[0])
|
||||
_, err = os.Stat(blockdev)
|
||||
if (err == nil)
|
||||
{
|
||||
// Generate state file
|
||||
stateJSON, _ := json.Marshal(&DeviceState{
|
||||
ConfigPath: ctxVars["configPath"],
|
||||
VdpaId: vdpaId,
|
||||
Image: volName,
|
||||
Blockdev: blockdev,
|
||||
Readonly: readonly,
|
||||
PidFile: pidFile,
|
||||
})
|
||||
err = os.WriteFile(stateFile, stateJSON, 0600)
|
||||
if (err == nil)
|
||||
{
|
||||
klog.Infof("Attached volume %s via VDUSE as %s (VDPA ID %s)", volName, blockdev, vdpaId)
|
||||
return blockdev, vdpaId, nil
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
killErr := killByPidFile(pidFile)
|
||||
if (killErr != nil)
|
||||
{
|
||||
klog.Errorf("Failed to kill started qemu-storage-daemon: %v", killErr)
|
||||
}
|
||||
os.Remove(stateFile)
|
||||
os.Remove(pidFile)
|
||||
}
|
||||
return "", "", err
|
||||
}
|
||||
|
||||
func unmapVduse(stateDir, devicePath string)
|
||||
{
|
||||
if (len(devicePath) < 6 || devicePath[0:6] != "/dev/v")
|
||||
{
|
||||
klog.Errorf("%s does not start with /dev/v", devicePath)
|
||||
return
|
||||
}
|
||||
vduseDev, err := os.Readlink("/sys/block/"+devicePath[5:])
|
||||
if (err != nil)
|
||||
{
|
||||
klog.Errorf("%s is not a symbolic link to VDUSE device (../devices/virtual/vduse/xxx): %v", devicePath, err)
|
||||
return
|
||||
}
|
||||
vdpaId := ""
|
||||
p := strings.Index(vduseDev, "/vduse/")
|
||||
if (p >= 0)
|
||||
{
|
||||
vduseDev = vduseDev[p+7:]
|
||||
p = strings.Index(vduseDev, "/")
|
||||
if (p >= 0)
|
||||
{
|
||||
vdpaId = vduseDev[0:p]
|
||||
}
|
||||
}
|
||||
if (vdpaId == "")
|
||||
{
|
||||
klog.Errorf("%s is not a symbolic link to VDUSE device (../devices/virtual/vduse/xxx), but is %v", devicePath, vduseDev)
|
||||
return
|
||||
}
|
||||
unmapVduseById(stateDir, vdpaId)
|
||||
}
|
||||
|
||||
func unmapVduseById(stateDir, vdpaId string)
|
||||
{
|
||||
_, err := os.Stat("/sys/bus/vdpa/devices/"+vdpaId)
|
||||
if (err != nil)
|
||||
{
|
||||
klog.Errorf("failed to stat /sys/bus/vdpa/devices/"+vdpaId+": %v", err)
|
||||
}
|
||||
else
|
||||
{
|
||||
_, _, _ = system("/sbin/vdpa", "-j", "dev", "del", vdpaId)
|
||||
}
|
||||
stateFile := stateDir + vdpaId + ".json"
|
||||
os.Remove(stateFile)
|
||||
pidFile := stateDir + vdpaId + ".pid"
|
||||
_, err = os.Stat(pidFile)
|
||||
if (os.IsNotExist(err))
|
||||
{
|
||||
// ok, already killed
|
||||
}
|
||||
else if (err != nil)
|
||||
{
|
||||
klog.Errorf("Failed to stat %v: %v", pidFile, err)
|
||||
return
|
||||
}
|
||||
else
|
||||
{
|
||||
err = killByPidFile(pidFile)
|
||||
if (err != nil)
|
||||
{
|
||||
klog.Errorf("Failed to kill started qemu-storage-daemon: %v", err)
|
||||
}
|
||||
os.Remove(pidFile)
|
||||
}
|
||||
}
|
||||
|
||||
func system(program string, args ...string) ([]byte, []byte, error)
|
||||
{
|
||||
klog.Infof("Running "+program+" "+strings.Join(args, " "))
|
||||
c := exec.Command(program, args...)
|
||||
var stdout, stderr bytes.Buffer
|
||||
c.Stdout, c.Stderr = &stdout, &stderr
|
||||
err := c.Run()
|
||||
if (err != nil)
|
||||
{
|
||||
stdoutStr, stderrStr := string(stdout.Bytes()), string(stderr.Bytes())
|
||||
klog.Errorf(program+" "+strings.Join(args, " ")+" failed: %s\nOutput:\n%s", err, stdoutStr+stderrStr)
|
||||
return nil, nil, status.Error(codes.Internal, stdoutStr+stderrStr+" (status "+err.Error()+")")
|
||||
}
|
||||
return stdout.Bytes(), stderr.Bytes(), nil
|
||||
}
|
||||
|
||||
func systemCombined(program string, args ...string) ([]byte, error)
|
||||
{
|
||||
klog.Infof("Running "+program+" "+strings.Join(args, " "))
|
||||
c := exec.Command(program, args...)
|
||||
var out bytes.Buffer
|
||||
c.Stdout, c.Stderr = &out, &out
|
||||
err := c.Run()
|
||||
if (err != nil)
|
||||
{
|
||||
outStr := string(out.Bytes())
|
||||
klog.Errorf(program+" "+strings.Join(args, " ")+" failed: %s, status %s\n", outStr, err)
|
||||
return nil, status.Error(codes.Internal, outStr+" (status "+err.Error()+")")
|
||||
}
|
||||
return out.Bytes(), nil
|
||||
}
|
||||
|
|
@ -1,58 +0,0 @@
|
|||
exit
|
||||
|
||||
git clone https://git.yourcmc.ru/vitalif/pve-qemu .
|
||||
|
||||
# bookworm
|
||||
|
||||
docker run -it -v `pwd`/pve-qemu:/root/pve-qemu --name pve-qemu-bullseye debian:bullseye bash
|
||||
|
||||
perl -i -pe 's/Types: deb$/Types: deb deb-src/' /etc/apt/sources.list.d/debian.sources
|
||||
echo 'deb [arch=amd64] http://download.proxmox.com/debian/pve bookworm pve-no-subscription' >> /etc/apt/sources.list
|
||||
echo 'deb https://vitastor.io/debian bookworm main' >> /etc/apt/sources.list
|
||||
echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf
|
||||
echo 'ru_RU UTF-8' >> /etc/locale.gen
|
||||
echo 'en_US UTF-8' >> /etc/locale.gen
|
||||
apt-get update
|
||||
apt-get install wget ca-certificates
|
||||
wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
|
||||
wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg
|
||||
apt-get update
|
||||
apt-get install git devscripts equivs wget mc libjemalloc-dev vitastor-client-dev lintian locales
|
||||
mk-build-deps --install ./control
|
||||
|
||||
# bullseye
|
||||
|
||||
docker run -it -v `pwd`/pve-qemu:/root/pve-qemu --name pve-qemu-bullseye debian:bullseye bash
|
||||
|
||||
grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb /deb-src /' >> /etc/apt/sources.list
|
||||
echo 'deb [arch=amd64] http://download.proxmox.com/debian/pve bullseye pve-no-subscription' >> /etc/apt/sources.list
|
||||
echo 'deb https://vitastor.io/debian bullseye main' >> /etc/apt/sources.list
|
||||
echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf
|
||||
echo 'ru_RU UTF-8' >> /etc/locale.gen
|
||||
echo 'en_US UTF-8' >> /etc/locale.gen
|
||||
apt-get update
|
||||
apt-get install wget
|
||||
wget https://enterprise.proxmox.com/debian/proxmox-release-bullseye.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bullseye.gpg
|
||||
wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg
|
||||
apt-get update
|
||||
apt-get install git devscripts equivs wget mc libjemalloc-dev vitastor-client-dev lintian locales
|
||||
mk-build-deps --install ./control
|
||||
|
||||
# buster
|
||||
|
||||
docker run -it -v `pwd`/pve-qemu:/root/pve-qemu --name pve-qemu-buster debian:buster bash
|
||||
|
||||
grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb /deb-src /' >> /etc/apt/sources.list
|
||||
echo 'deb [arch=amd64] http://download.proxmox.com/debian/pve buster pve-no-subscription' >> /etc/apt/sources.list
|
||||
echo 'deb https://vitastor.io/debian buster main' >> /etc/apt/sources.list
|
||||
echo 'deb http://deb.debian.org/debian buster-backports main' >> /etc/apt/sources.list
|
||||
echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf
|
||||
echo 'ru_RU UTF-8' >> /etc/locale.gen
|
||||
echo 'en_US UTF-8' >> /etc/locale.gen
|
||||
apt-get update
|
||||
apt-get install wget ca-certificates
|
||||
wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
|
||||
wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg
|
||||
apt-get update
|
||||
apt-get install git devscripts equivs wget mc libjemalloc-dev vitastor-client-dev lintian locales
|
||||
mk-build-deps --install ./control
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
#!/bin/bash
|
||||
|
||||
cat < vitastor.Dockerfile > ../Dockerfile
|
||||
cd ..
|
||||
mkdir -p packages
|
||||
sudo podman build --build-arg DISTRO=debian --build-arg REL=bookworm -v `pwd`/packages:/root/packages -f Dockerfile .
|
||||
rm Dockerfile
|
||||
|
|
@ -3,5 +3,5 @@
|
|||
cat < vitastor.Dockerfile > ../Dockerfile
|
||||
cd ..
|
||||
mkdir -p packages
|
||||
sudo podman build --build-arg DISTRO=debian --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f Dockerfile .
|
||||
sudo podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f Dockerfile .
|
||||
rm Dockerfile
|
||||
|
|
|
|||
|
|
@ -3,5 +3,5 @@
|
|||
cat < vitastor.Dockerfile > ../Dockerfile
|
||||
cd ..
|
||||
mkdir -p packages
|
||||
sudo podman build --build-arg DISTRO=debian --build-arg REL=buster -v `pwd`/packages:/root/packages -f Dockerfile .
|
||||
sudo podman build --build-arg REL=buster -v `pwd`/packages:/root/packages -f Dockerfile .
|
||||
rm Dockerfile
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
#!/bin/bash
|
||||
|
||||
cat < vitastor.Dockerfile > ../Dockerfile
|
||||
cd ..
|
||||
mkdir -p packages
|
||||
sudo podman build --build-arg DISTRO=ubuntu --build-arg REL=jammy -v `pwd`/packages:/root/packages -f Dockerfile .
|
||||
rm Dockerfile
|
||||
|
|
@ -1,18 +1,4 @@
|
|||
vitastor (1.10.0-1) unstable; urgency=medium
|
||||
|
||||
* Bugfixes
|
||||
|
||||
-- Vitaliy Filippov <vitalif@yourcmc.ru> Fri, 03 Jun 2022 02:09:44 +0300
|
||||
|
||||
vitastor (0.7.0-1) unstable; urgency=medium
|
||||
|
||||
* Implement NFS proxy
|
||||
* Add documentation
|
||||
* Bugfixes
|
||||
|
||||
-- Vitaliy Filippov <vitalif@yourcmc.ru> Sun, 29 May 2022 23:39:13 +0300
|
||||
|
||||
vitastor (0.6.3-1) unstable; urgency=medium
|
||||
vitastor (0.6.17-1) unstable; urgency=medium
|
||||
|
||||
* RDMA support
|
||||
* Bugfixes
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Source: vitastor
|
|||
Section: admin
|
||||
Priority: optional
|
||||
Maintainer: Vitaliy Filippov <vitalif@yourcmc.ru>
|
||||
Build-Depends: debhelper, liburing-dev (>= 0.6), g++ (>= 8), libstdc++6 (>= 8), linux-libc-dev, libgoogle-perftools-dev, libjerasure-dev, libgf-complete-dev, libibverbs-dev, libisal-dev, cmake, pkg-config, libnl-3-dev, libnl-genl-3-dev
|
||||
Build-Depends: debhelper, liburing-dev (>= 0.6), g++ (>= 8), libstdc++6 (>= 8), linux-libc-dev, libgoogle-perftools-dev, libjerasure-dev, libgf-complete-dev, libibverbs-dev
|
||||
Standards-Version: 4.5.0
|
||||
Homepage: https://vitastor.io/
|
||||
Rules-Requires-Root: no
|
||||
|
|
@ -18,7 +18,7 @@ Description: Vitastor, a fast software-defined clustered block storage
|
|||
|
||||
Package: vitastor-osd
|
||||
Architecture: amd64
|
||||
Depends: ${shlibs:Depends}, ${misc:Depends}, vitastor-client (= ${binary:Version}), fdisk, util-linux, parted
|
||||
Depends: ${shlibs:Depends}, ${misc:Depends}, vitastor-client (= ${binary:Version})
|
||||
Description: Vitastor, a fast software-defined clustered block storage - object storage daemon
|
||||
Vitastor object storage daemon, i.e. server program that stores data.
|
||||
|
||||
|
|
@ -53,9 +53,3 @@ Architecture: amd64
|
|||
Depends: ${shlibs:Depends}, ${misc:Depends}, vitastor-client (= ${binary:Version})
|
||||
Description: Vitastor Proxmox Virtual Environment storage plugin
|
||||
Vitastor storage plugin for Proxmox Virtual Environment.
|
||||
|
||||
Package: vitastor-opennebula
|
||||
Architecture: amd64
|
||||
Depends: ${shlibs:Depends}, ${misc:Depends}, vitastor-client, patch, python3, jq
|
||||
Description: Vitastor OpenNebula storage plugin
|
||||
Vitastor storage plugin for OpenNebula.
|
||||
|
|
|
|||
|
|
@ -1,11 +0,0 @@
|
|||
prefix=/usr
|
||||
exec_prefix=${prefix}
|
||||
libdir=${prefix}/lib/x86_64-linux-gnu
|
||||
includedir=${prefix}/include
|
||||
|
||||
Name: libisal
|
||||
Description: Library for storage systems
|
||||
Version: 2.30.0
|
||||
Libs: -L${libdir} -lisal
|
||||
Libs.private:
|
||||
Cflags: -I${includedir}
|
||||
|
|
@ -1,14 +1,13 @@
|
|||
# Build patched libvirt for Debian Buster or Bullseye/Sid inside a container
|
||||
# cd ..; podman build --build-arg DISTRO=debian --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/libvirt.Dockerfile .
|
||||
# cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/libvirt.Dockerfile .
|
||||
|
||||
ARG DISTRO=
|
||||
ARG REL=
|
||||
FROM $DISTRO:$REL
|
||||
FROM debian:$REL
|
||||
ARG REL=
|
||||
|
||||
WORKDIR /root
|
||||
|
||||
RUN if ([ "${DISTRO}" = "debian" ]) && ( [ "${REL}" = "buster" -o "${REL}" = "bullseye" ] ); then \
|
||||
RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
|
||||
echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
|
||||
echo >> /etc/apt/preferences; \
|
||||
echo 'Package: *' >> /etc/apt/preferences; \
|
||||
|
|
@ -24,7 +23,7 @@ RUN apt-get -y build-dep libvirt0
|
|||
RUN apt-get -y install libglusterfs-dev
|
||||
RUN apt-get --download-only source libvirt
|
||||
|
||||
ADD patches/libvirt-5.0-vitastor.diff patches/libvirt-7.0-vitastor.diff patches/libvirt-7.5-vitastor.diff patches/libvirt-7.6-vitastor.diff patches/libvirt-8.0-vitastor.diff /root
|
||||
ADD patches/libvirt-5.0-vitastor.diff patches/libvirt-7.0-vitastor.diff patches/libvirt-7.5-vitastor.diff patches/libvirt-7.6-vitastor.diff /root
|
||||
RUN set -e; \
|
||||
mkdir -p /root/packages/libvirt-$REL; \
|
||||
rm -rf /root/packages/libvirt-$REL/*; \
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Build patched QEMU for Debian inside a container
|
||||
# Build patched QEMU for Debian Buster or Bullseye/Sid inside a container
|
||||
# cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/patched-qemu.Dockerfile .
|
||||
|
||||
ARG REL=
|
||||
|
|
@ -7,7 +7,7 @@ ARG REL=
|
|||
|
||||
WORKDIR /root
|
||||
|
||||
RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" -o "$REL" = "bookworm" ]; then \
|
||||
RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
|
||||
echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
|
||||
echo >> /etc/apt/preferences; \
|
||||
echo 'Package: *' >> /etc/apt/preferences; \
|
||||
|
|
@ -15,47 +15,47 @@ RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" -o "$REL" = "bookworm" ]; then
|
|||
echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
|
||||
fi; \
|
||||
grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
|
||||
perl -i -pe 's/Types: deb$/Types: deb deb-src/' /etc/apt/sources.list.d/debian.sources || true; \
|
||||
echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf; \
|
||||
echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
|
||||
|
||||
RUN apt-get update
|
||||
RUN apt-get -y install fio liburing-dev libgoogle-perftools-dev devscripts
|
||||
RUN apt-get -y install qemu fio liburing1 liburing-dev libgoogle-perftools-dev devscripts
|
||||
RUN apt-get -y build-dep qemu
|
||||
# To build a custom version
|
||||
#RUN cp /root/packages/qemu-orig/* /root
|
||||
RUN apt-get --download-only source qemu
|
||||
|
||||
ADD patches /root/vitastor/patches
|
||||
ADD src/client/qemu_driver.c /root/qemu_driver.c
|
||||
|
||||
#RUN set -e; \
|
||||
# apt-get install -y wget; \
|
||||
# wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg; \
|
||||
# (echo deb http://vitastor.io/debian $REL main > /etc/apt/sources.list.d/vitastor.list); \
|
||||
# (echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
|
||||
# apt-get update; \
|
||||
# apt-get install -y vitastor-client vitastor-client-dev quilt
|
||||
|
||||
ADD patches/qemu-5.0-vitastor.patch patches/qemu-5.1-vitastor.patch patches/qemu-6.1-vitastor.patch src/qemu_driver.c /root/vitastor/patches/
|
||||
RUN set -e; \
|
||||
dpkg -i /root/packages/vitastor-$REL/vitastor-client_*.deb /root/packages/vitastor-$REL/vitastor-client-dev_*.deb; \
|
||||
apt-get install -y wget; \
|
||||
wget -q -O /etc/apt/trusted.gpg.d/vitastor.gpg https://vitastor.io/debian/pubkey.gpg; \
|
||||
(echo deb http://vitastor.io/debian $REL main > /etc/apt/sources.list.d/vitastor.list); \
|
||||
(echo "APT::Install-Recommends false;" > /etc/apt/apt.conf) && \
|
||||
apt-get update; \
|
||||
apt-get install -y quilt; \
|
||||
apt-get install -y vitastor-client vitastor-client-dev quilt; \
|
||||
mkdir -p /root/packages/qemu-$REL; \
|
||||
rm -rf /root/packages/qemu-$REL/*; \
|
||||
cd /root/packages/qemu-$REL; \
|
||||
dpkg-source -x /root/qemu*.dsc; \
|
||||
QEMU_VER=$(ls -d qemu*/ | perl -pe 's!^.*?(\d+\.\d+).*!$1!'); \
|
||||
D=$(ls -d qemu*/); \
|
||||
cp /root/vitastor/patches/qemu-$QEMU_VER-vitastor.patch ./qemu-*/debian/patches; \
|
||||
echo qemu-$QEMU_VER-vitastor.patch >> $D/debian/patches/series; \
|
||||
if ls -d /root/packages/qemu-$REL/qemu-5.0*; then \
|
||||
D=$(ls -d /root/packages/qemu-$REL/qemu-5.0*); \
|
||||
cp /root/vitastor/patches/qemu-5.0-vitastor.patch $D/debian/patches; \
|
||||
echo qemu-5.0-vitastor.patch >> $D/debian/patches/series; \
|
||||
elif ls /root/packages/qemu-$REL/qemu-6.1*; then \
|
||||
D=$(ls -d /root/packages/qemu-$REL/qemu-6.1*); \
|
||||
cp /root/vitastor/patches/qemu-6.1-vitastor.patch $D/debian/patches; \
|
||||
echo qemu-6.1-vitastor.patch >> $D/debian/patches/series; \
|
||||
else \
|
||||
cp /root/vitastor/patches/qemu-5.1-vitastor.patch /root/packages/qemu-$REL/qemu-*/debian/patches; \
|
||||
P=`ls -d /root/packages/qemu-$REL/qemu-*/debian/patches`; \
|
||||
echo qemu-5.1-vitastor.patch >> $P/series; \
|
||||
fi; \
|
||||
cd /root/packages/qemu-$REL/qemu-*/; \
|
||||
quilt push -a; \
|
||||
quilt add block/vitastor.c; \
|
||||
cp /root/qemu_driver.c block/vitastor.c; \
|
||||
cp /root/vitastor/patches/qemu_driver.c block/vitastor.c; \
|
||||
quilt refresh; \
|
||||
V=$(head -n1 debian/changelog | perl -pe 's/5\.2\+dfsg-9/5.2+dfsg-11/; s/^.*\((.*?)(~bpo[\d\+]*)?\).*$/$1/')+vitastor4; \
|
||||
if [ "$REL" = bullseye ]; then V=${V}bullseye; fi; \
|
||||
V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)(~bpo[\d\+]*)?\).*$/$1/')+vitastor1; \
|
||||
DEBEMAIL="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v $V 'Plug Vitastor block driver'; \
|
||||
DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
|
||||
rm -rf /root/packages/qemu-$REL/qemu-*/
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
patches/VitastorPlugin.pm usr/share/perl5/PVE/Storage/Custom/
|
||||
patches/PVE_VitastorPlugin.pm usr/share/perl5/PVE/Storage/Custom/VitastorPlugin.pm
|
||||
|
|
|
|||
|
|
@ -3,6 +3,5 @@ usr/bin/vitastor-cli
|
|||
usr/bin/vitastor-rm
|
||||
usr/bin/vitastor-nbd
|
||||
usr/bin/vitastor-nfs
|
||||
usr/bin/vitastor-kv
|
||||
usr/bin/vitastor-kv-stress
|
||||
usr/lib/*/libvitastor*.so*
|
||||
mon/make-osd.sh /usr/lib/vitastor
|
||||
|
|
|
|||
|
|
@ -1,3 +1 @@
|
|||
mon usr/lib/vitastor/
|
||||
mon/scripts/make-etcd usr/lib/vitastor/mon
|
||||
mon/scripts/vitastor-mon.service /lib/systemd/system
|
||||
mon usr/lib/vitastor
|
||||
|
|
|
|||
|
|
@ -1,11 +0,0 @@
|
|||
#!/bin/sh
|
||||
|
||||
set -e
|
||||
|
||||
if [ "$1" = "configure" ]; then
|
||||
addgroup --system --quiet vitastor
|
||||
adduser --system --quiet --ingroup vitastor --no-create-home --home /nonexistent vitastor
|
||||
mkdir -p /etc/vitastor
|
||||
mkdir -p /var/lib/vitastor
|
||||
chown vitastor:vitastor /var/lib/vitastor
|
||||
fi
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
opennebula/remotes var/lib/one/
|
||||
opennebula/sudoers.d etc/
|
||||
opennebula/install.sh var/lib/one/remotes/datastore/vitastor/
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
#!/bin/sh
|
||||
|
||||
set -e
|
||||
|
||||
if [ "$1" = "configure" ]; then
|
||||
/var/lib/one/remotes/datastore/vitastor/install.sh
|
||||
fi
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
interest /var/lib/one/remotes/datastore/downloader.sh
|
||||
interest /etc/one/oned.conf
|
||||
interest /etc/one/vmm_exec/vmm_execrc
|
||||
interest /etc/apparmor.d/local/abstractions/libvirt-qemu
|
||||
|
|
@ -1,6 +1,2 @@
|
|||
usr/bin/vitastor-osd
|
||||
usr/bin/vitastor-disk
|
||||
usr/bin/vitastor-dump-journal
|
||||
mon/scripts/vitastor-osd@.service /lib/systemd/system
|
||||
mon/scripts/vitastor.target /lib/systemd/system
|
||||
mon/scripts/90-vitastor.rules /lib/udev/rules.d
|
||||
|
|
|
|||
|
|
@ -1,10 +0,0 @@
|
|||
#!/bin/sh
|
||||
|
||||
set -e
|
||||
|
||||
if [ "$1" = "configure" ]; then
|
||||
addgroup --system --quiet vitastor
|
||||
adduser --system --quiet --ingroup vitastor --no-create-home --home /nonexistent vitastor
|
||||
install -o vitastor -g vitastor -d /var/log/vitastor
|
||||
mkdir -p /etc/vitastor
|
||||
fi
|
||||
|
|
@ -1,34 +1,31 @@
|
|||
# Build Vitastor packages for Debian inside a container
|
||||
# cd ..; podman build --build-arg DISTRO=debian --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/vitastor.Dockerfile .
|
||||
# Build Vitastor packages for Debian Buster or Bullseye/Sid inside a container
|
||||
# cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/vitastor.Dockerfile .
|
||||
|
||||
ARG DISTRO=debian
|
||||
ARG REL=
|
||||
FROM $DISTRO:$REL
|
||||
ARG DISTRO=debian
|
||||
FROM debian:$REL
|
||||
ARG REL=
|
||||
|
||||
WORKDIR /root
|
||||
|
||||
RUN set -e -x; \
|
||||
if [ "$REL" = "buster" ]; then \
|
||||
apt-get update; \
|
||||
apt-get -y install wget; \
|
||||
wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg; \
|
||||
echo "deb https://vitastor.io/debian $REL main" >> /etc/apt/sources.list; \
|
||||
RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
|
||||
echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
|
||||
echo >> /etc/apt/preferences; \
|
||||
echo 'Package: *' >> /etc/apt/preferences; \
|
||||
echo "Pin: release a=$REL-backports" >> /etc/apt/preferences; \
|
||||
echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
|
||||
fi; \
|
||||
grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
|
||||
perl -i -pe 's/Types: deb$/Types: deb deb-src/' /etc/apt/sources.list.d/debian.sources || true; \
|
||||
echo 'APT::Install-Recommends false;' >> /etc/apt/apt.conf; \
|
||||
echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
|
||||
|
||||
RUN apt-get update && \
|
||||
apt-get -y install fio liburing-dev libgoogle-perftools-dev devscripts libjerasure-dev cmake libibverbs-dev librdmacm-dev libisal-dev libnl-3-dev libnl-genl-3-dev curl && \
|
||||
apt-get -y build-dep fio && \
|
||||
apt-get --download-only source fio
|
||||
RUN apt-get update
|
||||
RUN apt-get -y install fio liburing1 liburing-dev libgoogle-perftools-dev devscripts
|
||||
RUN apt-get -y build-dep fio
|
||||
RUN apt-get --download-only source fio
|
||||
RUN apt-get update && apt-get -y install libjerasure-dev cmake libibverbs-dev
|
||||
|
||||
ADD . /root/vitastor
|
||||
RUN set -e -x; \
|
||||
[ -e /usr/lib/x86_64-linux-gnu/pkgconfig/libisal.pc ] || cp /root/vitastor/debian/libisal.pc /usr/lib/x86_64-linux-gnu/pkgconfig; \
|
||||
mkdir -p /root/fio-build/; \
|
||||
cd /root/fio-build/; \
|
||||
rm -rf /root/fio-build/*; \
|
||||
|
|
@ -36,10 +33,8 @@ RUN set -e -x; \
|
|||
mkdir -p /root/packages/vitastor-$REL; \
|
||||
rm -rf /root/packages/vitastor-$REL/*; \
|
||||
cd /root/packages/vitastor-$REL; \
|
||||
FULLVER=$(head -n1 /root/vitastor/debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
|
||||
VER=${FULLVER%%-*}; \
|
||||
cp -r /root/vitastor vitastor-$VER; \
|
||||
cd vitastor-$VER; \
|
||||
cp -r /root/vitastor vitastor-0.6.17; \
|
||||
cd vitastor-0.6.17; \
|
||||
ln -s /root/fio-build/fio-*/ ./fio; \
|
||||
FIO=$(head -n1 fio/debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
|
||||
ls /usr/include/linux/raw.h || cp ./debian/raw.h /usr/include/linux/raw.h; \
|
||||
|
|
@ -51,14 +46,10 @@ RUN set -e -x; \
|
|||
echo fio-headers.patch >> debian/patches/series; \
|
||||
rm -rf a b; \
|
||||
echo "dep:fio=$FIO" > debian/fio_version; \
|
||||
cd /root/packages/vitastor-$REL/vitastor-$VER; \
|
||||
mkdir mon/node_modules; \
|
||||
cd mon/node_modules; \
|
||||
curl -s https://git.yourcmc.ru/vitalif/antietcd/archive/master.tar.gz | tar -zx; \
|
||||
curl -s https://git.yourcmc.ru/vitalif/tinyraft/archive/master.tar.gz | tar -zx; \
|
||||
cd /root/packages/vitastor-$REL; \
|
||||
tar --sort=name --mtime='2020-01-01' --owner=0 --group=0 --exclude=debian -cJf vitastor_$VER.orig.tar.xz vitastor-$VER; \
|
||||
cd vitastor-$VER; \
|
||||
DEBFULLNAME="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v "$FULLVER""$REL" "Rebuild for $REL"; \
|
||||
tar --sort=name --mtime='2020-01-01' --owner=0 --group=0 --exclude=debian -cJf vitastor_0.6.17.orig.tar.xz vitastor-0.6.17; \
|
||||
cd vitastor-0.6.17; \
|
||||
V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
|
||||
DEBFULLNAME="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v "$V""$REL" "Rebuild for $REL"; \
|
||||
DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
|
||||
rm -rf /root/packages/vitastor-$REL/vitastor-*/
|
||||
|
|
|
|||
Binary file not shown.
|
|
@ -17,23 +17,20 @@ Configuration parameters can be set in 3 places:
|
|||
- Configuration file (`/etc/vitastor/vitastor.conf` or other path)
|
||||
- etcd key `/vitastor/config/global`. Most variables can be set there, but etcd
|
||||
connection parameters should obviously be set in the configuration file.
|
||||
- Command line of Vitastor components: OSD (when you run it without vitastor-disk),
|
||||
mon, fio and QEMU options, OpenStack/Proxmox/etc configuration. The latter
|
||||
doesn't allow to set all variables directly, but it allows to override the
|
||||
configuration file and set everything you need inside it.
|
||||
- OSD superblocks created by [vitastor-disk](usage/disk.en.md) contain
|
||||
primarily disk layout parameters of specific OSDs. In fact, these parameters
|
||||
are automatically passed into the command line of vitastor-osd process, so
|
||||
they have the same "status" as command-line parameters.
|
||||
- Command line of Vitastor components: OSD, mon, fio and QEMU options,
|
||||
OpenStack/Proxmox/etc configuration. The latter doesn't allow to set all
|
||||
variables directly, but it allows to override the configuration file and
|
||||
set everything you need inside it.
|
||||
|
||||
In the future, additional configuration methods may be added:
|
||||
- OSD superblock which will, by design, contain parameters related to the disk
|
||||
layout and to one specific OSD.
|
||||
- OSD-specific keys in etcd like `/vitastor/config/osd/<number>`.
|
||||
|
||||
## Parameter Reference
|
||||
|
||||
- [Common](config/common.en.md)
|
||||
- [Network](config/network.en.md)
|
||||
- [Client](config/client.en.md)
|
||||
- [Global Disk Layout](config/layout-cluster.en.md)
|
||||
- [OSD Disk Layout](config/layout-osd.en.md)
|
||||
- [OSD Runtime Parameters](config/osd.en.md)
|
||||
|
|
|
|||
|
|
@ -19,24 +19,20 @@
|
|||
- Ключе в etcd `/vitastor/config/global`. Большая часть параметров может
|
||||
задаваться там, кроме, естественно, самих параметров соединения с etcd,
|
||||
которые должны задаваться в файле конфигурации
|
||||
- В командной строке компонентов Vitastor: OSD (при ручном запуске без vitastor-disk),
|
||||
монитора, опциях fio и QEMU, настроек OpenStack, Proxmox и т.п. Последние,
|
||||
как правило, не включают полный набор параметров напрямую, но позволяют
|
||||
определить путь к файлу конфигурации и задать любые параметры в нём.
|
||||
- В суперблоке OSD, записываемом [vitastor-disk](usage/disk.ru.md) - параметры,
|
||||
связанные с дисковым форматом и с этим конкретным OSD. На самом деле,
|
||||
при запуске OSD эти параметры автоматически передаются в командную строку
|
||||
процесса vitastor-osd, то есть по "статусу" они эквивалентны параметрам
|
||||
командной строки OSD.
|
||||
- В командной строке компонентов Vitastor: OSD, монитора, опциях fio и QEMU,
|
||||
настроек OpenStack, Proxmox и т.п. Последние, как правило, не включают полный
|
||||
набор параметров напрямую, но разрешают определить путь к файлу конфигурации
|
||||
и задать любые параметры в нём.
|
||||
|
||||
В будущем также могут быть добавлены другие способы конфигурации:
|
||||
- Суперблок OSD, в котором будут храниться параметры OSD, связанные с дисковым
|
||||
форматом и с этим конкретным OSD.
|
||||
- OSD-специфичные ключи в etcd типа `/vitastor/config/osd/<номер>`.
|
||||
|
||||
## Список параметров
|
||||
|
||||
- [Общие](config/common.ru.md)
|
||||
- [Сеть](config/network.ru.md)
|
||||
- [Клиентский код](config/client.ru.md)
|
||||
- [Глобальные дисковые параметры](config/layout-cluster.ru.md)
|
||||
- [Дисковые параметры OSD](config/layout-osd.ru.md)
|
||||
- [Прочие параметры OSD](config/osd.ru.md)
|
||||
|
|
|
|||
|
|
@ -1,203 +0,0 @@
|
|||
[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Client Parameters
|
||||
|
||||
-----
|
||||
|
||||
[Читать на русском](client.ru.md)
|
||||
|
||||
# Client Parameters
|
||||
|
||||
These parameters apply only to Vitastor clients (QEMU, fio, NBD and so on) and
|
||||
affect their interaction with the cluster.
|
||||
|
||||
- [client_iothread_count](#client_iothread_count)
|
||||
- [client_retry_interval](#client_retry_interval)
|
||||
- [client_eio_retry_interval](#client_eio_retry_interval)
|
||||
- [client_retry_enospc](#client_retry_enospc)
|
||||
- [client_max_dirty_bytes](#client_max_dirty_bytes)
|
||||
- [client_max_dirty_ops](#client_max_dirty_ops)
|
||||
- [client_enable_writeback](#client_enable_writeback)
|
||||
- [client_max_buffered_bytes](#client_max_buffered_bytes)
|
||||
- [client_max_buffered_ops](#client_max_buffered_ops)
|
||||
- [client_max_writeback_iodepth](#client_max_writeback_iodepth)
|
||||
- [nbd_timeout](#nbd_timeout)
|
||||
- [nbd_max_devices](#nbd_max_devices)
|
||||
- [nbd_max_part](#nbd_max_part)
|
||||
- [osd_nearfull_ratio](#osd_nearfull_ratio)
|
||||
|
||||
## client_iothread_count
|
||||
|
||||
- Type: integer
|
||||
- Default: 0
|
||||
|
||||
Number of separate threads for handling TCP network I/O at client library
|
||||
side. Enabling 4 threads usually allows to increase peak performance of each
|
||||
client from approx. 2-3 to 7-8 GByte/s linear read/write and from approx.
|
||||
100-150 to 400 thousand iops, but at the same time it increases latency.
|
||||
Latency increase depends on CPU: with CPU power saving disabled latency
|
||||
only increases by ~10 us (equivalent to Q=1 iops decrease from 10500 to 9500),
|
||||
with CPU power saving enabled it may be as high as 500 us (equivalent to Q=1
|
||||
iops decrease from 2000 to 1000). RDMA isn't affected by this option.
|
||||
|
||||
It's recommended to enable client I/O threads if you don't use RDMA and want
|
||||
to increase peak client performance.
|
||||
|
||||
## client_retry_interval
|
||||
|
||||
- Type: milliseconds
|
||||
- Default: 50
|
||||
- Minimum: 10
|
||||
- Can be changed online: yes
|
||||
|
||||
Retry time for I/O requests failed due to inactive PGs or network
|
||||
connectivity errors.
|
||||
|
||||
## client_eio_retry_interval
|
||||
|
||||
- Type: milliseconds
|
||||
- Default: 1000
|
||||
- Can be changed online: yes
|
||||
|
||||
Retry time for I/O requests failed due to data corruption or unfinished
|
||||
EC object deletions (has_incomplete PG state). 0 disables such retries
|
||||
and clients are not blocked and just get EIO error code instead.
|
||||
|
||||
## client_retry_enospc
|
||||
|
||||
- Type: boolean
|
||||
- Default: true
|
||||
- Can be changed online: yes
|
||||
|
||||
Retry writes on out of space errors to wait until some space is freed on
|
||||
OSDs.
|
||||
|
||||
## client_max_dirty_bytes
|
||||
|
||||
- Type: integer
|
||||
- Default: 33554432
|
||||
- Can be changed online: yes
|
||||
|
||||
Without [immediate_commit](layout-cluster.en.md#immediate_commit)=all this parameter sets the limit of "dirty"
|
||||
(not committed by fsync) data allowed by the client before forcing an
|
||||
additional fsync and committing the data. Also note that the client always
|
||||
holds a copy of uncommitted data in memory so this setting also affects
|
||||
RAM usage of clients.
|
||||
|
||||
## client_max_dirty_ops
|
||||
|
||||
- Type: integer
|
||||
- Default: 1024
|
||||
- Can be changed online: yes
|
||||
|
||||
Same as client_max_dirty_bytes, but instead of total size, limits the number
|
||||
of uncommitted write operations.
|
||||
|
||||
## client_enable_writeback
|
||||
|
||||
- Type: boolean
|
||||
- Default: false
|
||||
- Can be changed online: yes
|
||||
|
||||
This parameter enables client-side write buffering. This means that write
|
||||
requests are accumulated in memory for a short time before being sent to
|
||||
a Vitastor cluster which allows to send them in parallel and increase
|
||||
performance of some applications. Writes are buffered until client forces
|
||||
a flush with fsync() or until the amount of buffered writes exceeds the
|
||||
limit.
|
||||
|
||||
Write buffering significantly increases performance of some applications,
|
||||
for example, CrystalDiskMark under Windows (LOL :-D), but also any other
|
||||
applications if they do writes in one of two non-optimal ways: either if
|
||||
they do a lot of small (4 kb or so) sequential writes, or if they do a lot
|
||||
of small random writes, but without any parallelism or asynchrony, and also
|
||||
without calling fsync().
|
||||
|
||||
With write buffering enabled, you can expect around 22000 T1Q1 random write
|
||||
iops in QEMU more or less regardless of the quality of your SSDs, and this
|
||||
number is in fact bound by QEMU itself rather than Vitastor (check it
|
||||
yourself by adding a "driver=null-co" disk in QEMU). Without write
|
||||
buffering, the current record is 9900 iops, but the number is usually
|
||||
even lower with non-ideal hardware, for example, it may be 5000 iops.
|
||||
|
||||
Even when this parameter is enabled, write buffering isn't enabled until
|
||||
the client explicitly allows it, because enabling it without the client
|
||||
being aware of the fact that his writes may be buffered may lead to data
|
||||
loss. Because of this, older versions of clients don't support write
|
||||
buffering at all, newer versions of the QEMU driver allow write buffering
|
||||
only if it's enabled in disk settings with `-blockdev cache.direct=false`,
|
||||
and newer versions of FIO only allow write buffering if you don't specify
|
||||
`-direct=1`. NBD and NFS drivers allow write buffering by default.
|
||||
|
||||
You can overcome this restriction too with the `client_writeback_allowed`
|
||||
parameter, but you shouldn't do that unless you **really** know what you
|
||||
are doing.
|
||||
|
||||
## client_max_buffered_bytes
|
||||
|
||||
- Type: integer
|
||||
- Default: 33554432
|
||||
- Can be changed online: yes
|
||||
|
||||
Maximum total size of buffered writes which triggers write-back when reached.
|
||||
|
||||
## client_max_buffered_ops
|
||||
|
||||
- Type: integer
|
||||
- Default: 1024
|
||||
- Can be changed online: yes
|
||||
|
||||
Maximum number of buffered writes which triggers write-back when reached.
|
||||
Multiple consecutive modified data regions are counted as 1 write here.
|
||||
|
||||
## client_max_writeback_iodepth
|
||||
|
||||
- Type: integer
|
||||
- Default: 256
|
||||
- Can be changed online: yes
|
||||
|
||||
Maximum number of parallel writes when flushing buffered data to the server.
|
||||
|
||||
## nbd_timeout
|
||||
|
||||
- Type: seconds
|
||||
- Default: 300
|
||||
|
||||
Timeout for I/O operations for [NBD](../usage/nbd.en.md). If an operation
|
||||
executes for longer than this timeout, including when your cluster is just
|
||||
temporarily down for more than timeout, the NBD device will detach by itself
|
||||
(and possibly break the mounted file system).
|
||||
|
||||
You can set timeout to 0 to never detach, but in that case you won't be
|
||||
able to remove the kernel device at all if the NBD process dies - you'll have
|
||||
to reboot the host.
|
||||
|
||||
## nbd_max_devices
|
||||
|
||||
- Type: integer
|
||||
- Default: 64
|
||||
|
||||
Maximum number of NBD devices in the system. This value is passed as
|
||||
`nbds_max` parameter for the nbd kernel module when vitastor-nbd autoloads it.
|
||||
|
||||
## nbd_max_part
|
||||
|
||||
- Type: integer
|
||||
- Default: 3
|
||||
|
||||
Maximum number of partitions per NBD device. This value is passed as
|
||||
`max_part` parameter for the nbd kernel module when vitastor-nbd autoloads it.
|
||||
Note that (nbds_max)*(1+max_part) usually can't exceed 256.
|
||||
|
||||
## osd_nearfull_ratio
|
||||
|
||||
- Type: number
|
||||
- Default: 0.95
|
||||
- Can be changed online: yes
|
||||
|
||||
Ratio of used space on OSD to treat it as "almost full" in vitastor-cli status output.
|
||||
|
||||
Remember that some client writes may hang or complete with an error if even
|
||||
just one OSD becomes 100 % full!
|
||||
|
||||
However, unlike in Ceph, 100 % full Vitastor OSDs don't crash (in Ceph they're
|
||||
unable to start at all), so you'll be able to recover from "out of space" errors
|
||||
without destroying and recreating OSDs.
|
||||
|
|
@ -1,207 +0,0 @@
|
|||
[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Параметры клиентского кода
|
||||
|
||||
-----
|
||||
|
||||
[Read in English](client.en.md)
|
||||
|
||||
# Параметры клиентского кода
|
||||
|
||||
Данные параметры применяются только к клиентам Vitastor (QEMU, fio, NBD и т.п.) и
|
||||
затрагивают логику их работы с кластером.
|
||||
|
||||
- [client_iothread_count](#client_iothread_count)
|
||||
- [client_retry_interval](#client_retry_interval)
|
||||
- [client_eio_retry_interval](#client_eio_retry_interval)
|
||||
- [client_retry_enospc](#client_retry_enospc)
|
||||
- [client_max_dirty_bytes](#client_max_dirty_bytes)
|
||||
- [client_max_dirty_ops](#client_max_dirty_ops)
|
||||
- [client_enable_writeback](#client_enable_writeback)
|
||||
- [client_max_buffered_bytes](#client_max_buffered_bytes)
|
||||
- [client_max_buffered_ops](#client_max_buffered_ops)
|
||||
- [client_max_writeback_iodepth](#client_max_writeback_iodepth)
|
||||
- [nbd_timeout](#nbd_timeout)
|
||||
- [nbd_max_devices](#nbd_max_devices)
|
||||
- [nbd_max_part](#nbd_max_part)
|
||||
- [osd_nearfull_ratio](#osd_nearfull_ratio)
|
||||
|
||||
## client_iothread_count
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 0
|
||||
|
||||
Число отдельных потоков для обработки ввода-вывода через TCP сеть на стороне
|
||||
клиентской библиотеки. Включение 4 потоков обычно позволяет поднять пиковую
|
||||
производительность каждого клиента примерно с 2-3 до 7-8 Гбайт/с линейного
|
||||
чтения/записи и примерно с 100-150 до 400 тысяч операций ввода-вывода в
|
||||
секунду, но ухудшает задержку. Увеличение задержки зависит от процессора:
|
||||
при отключённом энергосбережении CPU это всего ~10 микросекунд (равносильно
|
||||
падению iops с Q=1 с 10500 до 9500), а при включённом это может быть
|
||||
и 500 микросекунд (равносильно падению iops с Q=1 с 2000 до 1000). На работу
|
||||
RDMA данная опция не влияет.
|
||||
|
||||
Рекомендуется включать клиентские потоки ввода-вывода, если вы не используете
|
||||
RDMA и хотите повысить пиковую производительность клиентов.
|
||||
|
||||
## client_retry_interval
|
||||
|
||||
- Тип: миллисекунды
|
||||
- Значение по умолчанию: 50
|
||||
- Минимальное значение: 10
|
||||
- Можно менять на лету: да
|
||||
|
||||
Время повтора запросов ввода-вывода, неудачных из-за неактивных PG или
|
||||
ошибок сети.
|
||||
|
||||
## client_eio_retry_interval
|
||||
|
||||
- Тип: миллисекунды
|
||||
- Значение по умолчанию: 1000
|
||||
- Можно менять на лету: да
|
||||
|
||||
Время повтора запросов ввода-вывода, неудачных из-за повреждения данных
|
||||
или незавершённых удалений EC-объектов (состояния PG has_incomplete).
|
||||
0 отключает повторы таких запросов и клиенты не блокируются, а вместо
|
||||
этого просто получают код ошибки EIO.
|
||||
|
||||
## client_retry_enospc
|
||||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: true
|
||||
- Можно менять на лету: да
|
||||
|
||||
Повторять запросы записи, завершившиеся с ошибками нехватки места, т.е.
|
||||
ожидать, пока на OSD не освободится место.
|
||||
|
||||
## client_max_dirty_bytes
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 33554432
|
||||
- Можно менять на лету: да
|
||||
|
||||
При работе без [immediate_commit](layout-cluster.ru.md#immediate_commit)=all - это лимит объёма "грязных" (не
|
||||
зафиксированных fsync-ом) данных, при достижении которого клиент будет
|
||||
принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
|
||||
что в этом случае до момента fsync клиент хранит копию незафиксированных
|
||||
данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
|
||||
|
||||
## client_max_dirty_ops
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 1024
|
||||
- Можно менять на лету: да
|
||||
|
||||
Аналогично client_max_dirty_bytes, но ограничивает количество
|
||||
незафиксированных операций записи вместо их общего объёма.
|
||||
|
||||
## client_enable_writeback
|
||||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
- Можно менять на лету: да
|
||||
|
||||
Данный параметр разрешает включать буферизацию записи в памяти. Буферизация
|
||||
означает, что операции записи отправляются на кластер Vitastor не сразу, а
|
||||
могут небольшое время накапливаться в памяти и сбрасываться сразу пакетами,
|
||||
до тех пор, пока либо не будет превышен лимит неотправленных записей, либо
|
||||
пока клиент не вызовет fsync.
|
||||
|
||||
Буферизация значительно повышает производительность некоторых приложений,
|
||||
например, CrystalDiskMark в Windows (ха-ха :-D), но также и любых других,
|
||||
которые пишут на диск неоптимально: либо последовательно, но мелкими блоками
|
||||
(например, по 4 кб), либо случайно, но без параллелизма и без fsync - то
|
||||
есть, например, отправляя 128 операций записи в разные места диска, но не
|
||||
все сразу с помощью асинхронного I/O, а по одной.
|
||||
|
||||
В QEMU с буферизацией записи можно ожидать показателя примерно 22000
|
||||
операций случайной записи в секунду в 1 поток и с глубиной очереди 1 (T1Q1)
|
||||
без fsync, почти вне зависимости от того, насколько хороши ваши диски - эта
|
||||
цифра упирается в сам QEMU. Без буферизации рекорд пока что - 9900 операций
|
||||
в секунду, но на железе похуже может быть и поменьше, например, 5000 операций
|
||||
в секунду.
|
||||
|
||||
При этом, даже если данный параметр включён, буферизация не включается, если
|
||||
явно не разрешена клиентом, т.к. если клиент не знает, что запросы записи
|
||||
буферизуются, это может приводить к потере данных. Поэтому в старых версиях
|
||||
клиентских драйверов буферизация записи не включается вообще, в новых
|
||||
версиях QEMU-драйвера включается, только если разрешена опцией диска
|
||||
`-blockdev cache.direct=false`, а в fio - только если нет опции `-direct=1`.
|
||||
В NBD и NFS драйверах буферизация записи разрешена по умолчанию.
|
||||
|
||||
Можно обойти и это ограничение с помощью параметра `client_writeback_allowed`,
|
||||
но делать так не надо, если только вы не уверены в том, что делаете, на все
|
||||
100%. :-)
|
||||
|
||||
## client_max_buffered_bytes
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 33554432
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальный общий размер буферизованных записей, при достижении которого
|
||||
начинается процесс сброса данных на сервер.
|
||||
|
||||
## client_max_buffered_ops
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 1024
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальное количество буферизованных записей, при достижении которого
|
||||
начинается процесс сброса данных на сервер. При этом несколько
|
||||
последовательных изменённых областей здесь считаются 1 записью.
|
||||
|
||||
## client_max_writeback_iodepth
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 256
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальное число параллельных операций записи при сбросе буферов на сервер.
|
||||
|
||||
## nbd_timeout
|
||||
|
||||
- Тип: секунды
|
||||
- Значение по умолчанию: 300
|
||||
|
||||
Таймаут для операций чтения/записи через [NBD](../usage/nbd.ru.md). Если
|
||||
операция выполняется дольше таймаута, включая временную недоступность
|
||||
кластера на время, большее таймаута, NBD-устройство отключится само собой
|
||||
(и, возможно, сломает примонтированную ФС).
|
||||
|
||||
Вы можете установить таймаут в 0, чтобы никогда не отключать устройство по
|
||||
таймауту, но в этом случае вы вообще не сможете удалить устройство, если
|
||||
процесс NBD умрёт - вам придётся перезагружать сервер.
|
||||
|
||||
## nbd_max_devices
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 64
|
||||
|
||||
Максимальное число NBD-устройств в системе. Данное значение передаётся
|
||||
модулю ядра nbd как параметр `nbds_max`, когда его загружает vitastor-nbd.
|
||||
|
||||
## nbd_max_part
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 3
|
||||
|
||||
Максимальное число разделов на одном NBD-устройстве. Данное значение передаётся
|
||||
модулю ядра nbd как параметр `max_part`, когда его загружает vitastor-nbd.
|
||||
Имейте в виду, что (nbds_max)*(1+max_part) обычно не может превышать 256.
|
||||
|
||||
## osd_nearfull_ratio
|
||||
|
||||
- Тип: число
|
||||
- Значение по умолчанию: 0.95
|
||||
- Можно менять на лету: да
|
||||
|
||||
Доля занятого места на OSD, начиная с которой он считается "почти заполненным" в
|
||||
выводе vitastor-cli status.
|
||||
|
||||
Помните, что часть клиентских запросов может зависнуть или завершиться с ошибкой,
|
||||
если на 100 % заполнится хотя бы 1 OSD!
|
||||
|
||||
Однако, в отличие от Ceph, заполненные на 100 % OSD Vitastor не падают (в Ceph
|
||||
заполненные на 100% OSD вообще не могут стартовать), так что вы сможете
|
||||
восстановить работу кластера после ошибок отсутствия свободного места
|
||||
без уничтожения и пересоздания OSD.
|
||||
|
|
@ -25,16 +25,11 @@ running if required parameters are specified.
|
|||
## etcd_address
|
||||
|
||||
- Type: string or array of strings
|
||||
- Can be changed online: yes
|
||||
|
||||
etcd connection endpoint(s). Multiple endpoints may be delimited by "," or
|
||||
specified in a JSON array `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
|
||||
Note that https is not supported for etcd connections yet.
|
||||
|
||||
etcd connection endpoints can be changed online by updating global
|
||||
configuration in etcd itself - this allows to switch the cluster to new
|
||||
etcd addresses without downtime.
|
||||
|
||||
## etcd_prefix
|
||||
|
||||
- Type: string
|
||||
|
|
@ -47,6 +42,5 @@ example, use a single etcd cluster for multiple Vitastor clusters.
|
|||
|
||||
- Type: integer
|
||||
- Default: 0
|
||||
- Can be changed online: yes
|
||||
|
||||
Log level. Raise if you want more verbose output.
|
||||
|
|
|
|||
|
|
@ -24,14 +24,10 @@
|
|||
## etcd_address
|
||||
|
||||
- Тип: строка или массив строк
|
||||
- Можно менять на лету: да
|
||||
|
||||
Адрес(а) подключения к etcd. Несколько адресов могут разделяться запятой
|
||||
или указываться в виде JSON-массива `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
|
||||
|
||||
Адреса подключения к etcd можно поменять на лету, обновив конфигурацию в
|
||||
самом etcd - это позволяет переключить кластер на новые etcd без остановки.
|
||||
|
||||
## etcd_prefix
|
||||
|
||||
- Тип: строка
|
||||
|
|
@ -45,6 +41,5 @@
|
|||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 0
|
||||
- Можно менять на лету: да
|
||||
|
||||
Уровень логгирования. Повысьте, если хотите более подробный вывод.
|
||||
|
|
|
|||
|
|
@ -9,37 +9,36 @@
|
|||
These parameters apply to clients and OSDs, are fixed at the moment of OSD drive
|
||||
initialization and can't be changed after it without losing data.
|
||||
|
||||
OSDs with different values of these parameters (for example, SSD and SSD+HDD
|
||||
OSDs) can coexist in one Vitastor cluster within different pools. Each pool can
|
||||
only include OSDs with identical settings of these parameters.
|
||||
|
||||
These parameters, when set to a non-default value, must also be specified in
|
||||
etcd for clients to be aware of their values, either in /vitastor/config/global
|
||||
or in pool configuration. Pool configuration overrides the global setting.
|
||||
If the value for a pool in etcd doesn't match on-disk OSD configuration, the
|
||||
OSD will refuse to start PGs of that pool.
|
||||
|
||||
- [block_size](#block_size)
|
||||
- [bitmap_granularity](#bitmap_granularity)
|
||||
- [immediate_commit](#immediate_commit)
|
||||
- [client_dirty_limit](#client_dirty_limit)
|
||||
|
||||
## block_size
|
||||
|
||||
- Type: integer
|
||||
- Default: 131072
|
||||
|
||||
Size of objects (data blocks) into which all physical and virtual drives
|
||||
(within a pool) are subdivided in Vitastor. One of current main settings
|
||||
in Vitastor, affects memory usage, write amplification and I/O load
|
||||
distribution effectiveness.
|
||||
Size of objects (data blocks) into which all physical and virtual drives are
|
||||
subdivided in Vitastor. One of current main settings in Vitastor, affects
|
||||
memory usage, write amplification and I/O load distribution effectiveness.
|
||||
|
||||
Recommended default block size is 128 KB for SSD and 1 MB for HDD. In fact,
|
||||
it's possible to use 1 MB for SSD too - it will lower memory usage, but
|
||||
Recommended default block size is 128 KB for SSD and 4 MB for HDD. In fact,
|
||||
it's possible to use 4 MB for SSD too - it will lower memory usage, but
|
||||
may increase average WA and reduce linear performance.
|
||||
|
||||
OSDs with different block sizes (for example, SSD and SSD+HDD OSDs) can
|
||||
currently coexist in one etcd instance only within separate Vitastor
|
||||
clusters with different etcd_prefix'es.
|
||||
|
||||
Also block size can't be changed after OSD initialization without losing
|
||||
data.
|
||||
|
||||
You must always specify block_size in etcd in /vitastor/config/global if
|
||||
you change it so all clients can know about it.
|
||||
|
||||
OSD memory usage is roughly (SIZE / BLOCK * 68 bytes) which is roughly
|
||||
544 MB per 1 TB of used disk space with the default 128 KB block size.
|
||||
With 1 MB it's 8 times lower.
|
||||
|
||||
## bitmap_granularity
|
||||
|
||||
|
|
@ -51,29 +50,24 @@ of disk_alignment. It's called bitmap granularity because Vitastor tracks
|
|||
an allocation bitmap for each object containing 2 bits per each
|
||||
(bitmap_granularity) bytes.
|
||||
|
||||
Can't be smaller than the OSD data device sector.
|
||||
This parameter can't be changed after OSD initialization without losing
|
||||
data. Also it's fixed for the whole Vitastor cluster i.e. two different
|
||||
values can't be used in a single Vitastor cluster.
|
||||
|
||||
Clients MUST be aware of this parameter value, so put it into etcd key
|
||||
/vitastor/config/global if you change it for any reason.
|
||||
|
||||
## immediate_commit
|
||||
|
||||
- Type: string
|
||||
- Default: all
|
||||
- Default: false
|
||||
|
||||
One of "none", "all" or "small". Global value, may be overriden [at pool level](pool.en.md#immediate_commit).
|
||||
|
||||
This parameter is also really important for performance.
|
||||
|
||||
TLDR: default "all" is optimal for server-grade SSDs with supercapacitor-based
|
||||
power loss protection (nonvolatile write-through cache) and also for most HDDs.
|
||||
"none" or "small" should be only selected if you use desktop SSDs without
|
||||
capacitors or drives with slow write-back cache that can't be disabled. Check
|
||||
immediate_commit of your OSDs in [ls-osd](../usage/cli.en.md#ls-osd).
|
||||
|
||||
Detailed explanation:
|
||||
Another parameter which is really important for performance.
|
||||
|
||||
Desktop SSDs are very fast (100000+ iops) for simple random writes
|
||||
without cache flush. However, they are really slow (only around 1000 iops)
|
||||
if you try to fsync() each write, that is, if you want to guarantee that
|
||||
each change gets actually persisted to the physical media.
|
||||
if you try to fsync() each write, that is, when you want to guarantee that
|
||||
each change gets immediately persisted to the physical media.
|
||||
|
||||
Server-grade SSDs with "Advanced/Enhanced Power Loss Protection" or with
|
||||
"Supercapacitor-based Power Loss Protection", on the other hand, are equally
|
||||
|
|
@ -85,8 +79,8 @@ really slow when used with desktop SSDs. Vitastor, however, can also
|
|||
efficiently utilize desktop SSDs by postponing fsync until the client calls
|
||||
it explicitly.
|
||||
|
||||
This is what this parameter regulates. When it's set to "all" Vitastor
|
||||
cluster commits each change to disks immediately and clients just
|
||||
This is what this parameter regulates. When it's set to "all" the whole
|
||||
Vitastor cluster commits each change to disks immediately and clients just
|
||||
ignore fsyncs because they know for sure that they're unneeded. This reduces
|
||||
the amount of network roundtrips performed by clients and improves
|
||||
performance. So it's always better to use server grade SSDs with
|
||||
|
|
@ -105,9 +99,26 @@ unsafe to change by hand). The same may apply to newer HDDs with internal
|
|||
SSD cache or "media-cache" - for example, a lot of Seagate EXOS drives have
|
||||
it (they have internal SSD cache even though it's not stated in datasheets).
|
||||
|
||||
Setting this parameter to "all" or "small" in OSD parameters requires enabling
|
||||
[disable_journal_fsync](layout-osd.en.md#disable_journal_fsync) and
|
||||
[disable_meta_fsync](layout-osd.en.md#disable_meta_fsync), setting it to
|
||||
"all" also requires enabling [disable_data_fsync](layout-osd.en.md#disable_data_fsync).
|
||||
vitastor-disk tried to do that by default, first checking/disabling drive cache.
|
||||
If it can't disable drive cache, OSD get initialized with "none".
|
||||
This parameter must be set both in etcd in /vitastor/config/global and in
|
||||
OSD command line or configuration. Setting it to "all" or "small" requires
|
||||
enabling disable_journal_fsync and disable_meta_fsync, setting it to "all"
|
||||
also requires enabling disable_data_fsync.
|
||||
|
||||
TLDR: For optimal performance, set immediate_commit to "all" if you only use
|
||||
SSDs with supercapacitor-based power loss protection (nonvolatile
|
||||
write-through cache) for both data and journals in the whole Vitastor
|
||||
cluster. Set it to "small" if you only use such SSDs for journals. Leave
|
||||
empty if your drives have write-back cache.
|
||||
|
||||
## client_dirty_limit
|
||||
|
||||
- Type: integer
|
||||
- Default: 33554432
|
||||
|
||||
Without immediate_commit=all this parameter sets the limit of "dirty"
|
||||
(not committed by fsync) data allowed by the client before forcing an
|
||||
additional fsync and committing the data. Also note that the client always
|
||||
holds a copy of uncommitted data in memory so this setting also affects
|
||||
RAM usage of clients.
|
||||
|
||||
This parameter doesn't affect OSDs themselves.
|
||||
|
|
|
|||
|
|
@ -9,19 +9,10 @@
|
|||
Данные параметры используются клиентами и OSD, задаются в момент инициализации
|
||||
диска OSD и не могут быть изменены после этого без потери данных.
|
||||
|
||||
OSD с разными значениями данных параметров (например, SSD и гибридные SSD+HDD
|
||||
OSD) могут сосуществовать в одном кластере Vitastor в разных пулах. Один пул
|
||||
может включать только OSD с одинаковыми настройками этих параметров.
|
||||
|
||||
Данные параметры, отличаясь от значения по умолчанию, должны также быть заданы
|
||||
в etcd, чтобы клиенты могли узнать их значение, либо в глобальной конфигурации
|
||||
/vitastor/config/global, либо в настройках пулов. Настройки пула переопределяют
|
||||
глобальное значение. Если значение в настройках пула не будет соответствовать
|
||||
конфигурации OSD, OSD откажется запускать PG данного пула.
|
||||
|
||||
- [block_size](#block_size)
|
||||
- [bitmap_granularity](#bitmap_granularity)
|
||||
- [immediate_commit](#immediate_commit)
|
||||
- [client_dirty_limit](#client_dirty_limit)
|
||||
|
||||
## block_size
|
||||
|
||||
|
|
@ -29,18 +20,27 @@ OSD) могут сосуществовать в одном кластере Vita
|
|||
- Значение по умолчанию: 131072
|
||||
|
||||
Размер объектов (блоков данных), на которые делятся физические и виртуальные
|
||||
диски в Vitastor (в рамках каждого пула). Одна из ключевых на данный момент
|
||||
настроек, влияет на потребление памяти, объём избыточной записи (write
|
||||
amplification) и эффективность распределения нагрузки по OSD.
|
||||
диски в Vitastor. Одна из ключевых на данный момент настроек, влияет на
|
||||
потребление памяти, объём избыточной записи (write amplification) и
|
||||
эффективность распределения нагрузки по OSD.
|
||||
|
||||
Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 1 мегабайт
|
||||
для HDD. В принципе, для SSD можно тоже использовать блок размером 1 мегабайт,
|
||||
Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 4
|
||||
мегабайта для HDD. В принципе, для SSD можно тоже использовать 4 мегабайта,
|
||||
это понизит использование памяти, но ухудшит распределение нагрузки и в
|
||||
среднем увеличит WA.
|
||||
|
||||
OSD с разными размерами блока (например, SSD и SSD+HDD OSD) на данный
|
||||
момент могут сосуществовать в рамках одного etcd только в виде двух независимых
|
||||
кластеров Vitastor с разными etcd_prefix.
|
||||
|
||||
Также размер блока нельзя менять после инициализации OSD без потери данных.
|
||||
|
||||
Если вы меняете размер блока, обязательно прописывайте его в etcd в
|
||||
/vitastor/config/global, дабы все клиенты его знали.
|
||||
|
||||
Потребление памяти OSD составляет примерно (РАЗМЕР / БЛОК * 68 байт),
|
||||
т.е. примерно 544 МБ памяти на 1 ТБ занятого места на диске при
|
||||
стандартном 128 КБ блоке. При 1 МБ блоке памяти нужно в 8 раз меньше.
|
||||
стандартном 128 КБ блоке.
|
||||
|
||||
## bitmap_granularity
|
||||
|
||||
|
|
@ -52,23 +52,20 @@ amplification) и эффективность распределения нагр
|
|||
потому, что Vitastor хранит битовую карту для каждого объекта, содержащую
|
||||
по 2 бита на каждые (bitmap_granularity) байт.
|
||||
|
||||
Не может быть меньше размера сектора дисков данных OSD.
|
||||
Данный параметр нельзя менять после инициализации OSD без потери данных.
|
||||
Также он фиксирован для всего кластера Vitastor, т.е. разные значения
|
||||
не могут сосуществовать в одном кластере.
|
||||
|
||||
Клиенты ДОЛЖНЫ знать правильное значение этого параметра, так что если вы
|
||||
его меняете, обязательно прописывайте изменённое значение в etcd в ключ
|
||||
/vitastor/config/global.
|
||||
|
||||
## immediate_commit
|
||||
|
||||
- Тип: строка
|
||||
- Значение по умолчанию: all
|
||||
- Значение по умолчанию: false
|
||||
|
||||
Одно из значений "none", "small" или "all". Глобальное значение, может быть
|
||||
переопределено [на уровне пула](pool.ru.md#immediate_commit).
|
||||
|
||||
Данный параметр тоже важен для производительности.
|
||||
|
||||
Вкратце: значение по умолчанию "all" оптимально для всех серверных SSD с
|
||||
суперконденсаторами и также для большинства HDD. "none" и "small" имеет смысл
|
||||
устанавливать только при использовании SSD настольного класса без
|
||||
суперконденсаторов или дисков с медленным неотключаемым кэшем записи.
|
||||
Проверьте настройку immediate_commit своих OSD в выводе команды [ls-osd](../usage/cli.ru.md#ls-osd).
|
||||
Ещё один важный для производительности параметр.
|
||||
|
||||
Модели SSD для настольных компьютеров очень быстрые (100000+ операций в
|
||||
секунду) при простой случайной записи без сбросов кэша. Однако они очень
|
||||
|
|
@ -89,7 +86,7 @@ Power Loss Protection" - одинаково быстрые и со сбросо
|
|||
эффективно утилизировать настольные SSD.
|
||||
|
||||
Данный параметр влияет как раз на это. Когда он установлен в значение "all",
|
||||
кластер Vitastor мгновенно фиксирует каждое изменение на физические
|
||||
весь кластер Vitastor мгновенно фиксирует каждое изменение на физические
|
||||
носители и клиенты могут просто игнорировать запросы fsync, т.к. они точно
|
||||
знают, что fsync-и не нужны. Это уменьшает число необходимых обращений к OSD
|
||||
по сети и улучшает производительность. Поэтому даже с Vitastor лучше всегда
|
||||
|
|
@ -111,7 +108,27 @@ HDD-дисках с внутренним SSD или "медиа" кэшем - н
|
|||
многих дисках Seagate EXOS (у них есть внутренний SSD-кэш, хотя это и не
|
||||
указано в спецификациях).
|
||||
|
||||
Указание "all" или "small" в настройках / командной строке OSD требует
|
||||
включения [disable_journal_fsync](layout-osd.ru.md#disable_journal_fsync) и
|
||||
[disable_meta_fsync](layout-osd.ru.md#disable_meta_fsync), значение "all"
|
||||
также требует включения [disable_data_fsync](layout-osd.ru.md#disable_data_fsync).
|
||||
Данный параметр нужно указывать и в etcd в /vitastor/config/global, и в
|
||||
командной строке или конфигурации OSD. Значения "all" и "small" требуют
|
||||
включения disable_journal_fsync и disable_meta_fsync, значение "all" также
|
||||
требует включения disable_data_fsync.
|
||||
|
||||
Итого, вкратце: для оптимальной производительности установите
|
||||
immediate_commit в значение "all", если вы используете в кластере только SSD
|
||||
с суперконденсаторами и для данных, и для журналов. Если вы используете
|
||||
такие SSD для всех журналов, но не для данных - можете установить параметр
|
||||
в "small". Если и какие-то из дисков журналов имеют волатильный кэш записи -
|
||||
оставьте параметр пустым.
|
||||
|
||||
## client_dirty_limit
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 33554432
|
||||
|
||||
При работе без immediate_commit=all - это лимит объёма "грязных" (не
|
||||
зафиксированных fsync-ом) данных, при достижении которого клиент будет
|
||||
принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
|
||||
что в этом случае до момента fsync клиент хранит копию незафиксированных
|
||||
данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
|
||||
|
||||
Параметр не влияет на сами OSD.
|
||||
|
|
|
|||
|
|
@ -24,8 +24,6 @@ initialization and can't be changed after it without losing data.
|
|||
- [disable_journal_fsync](#disable_journal_fsync)
|
||||
- [disable_device_lock](#disable_device_lock)
|
||||
- [disk_alignment](#disk_alignment)
|
||||
- [data_csum_type](#data_csum_type)
|
||||
- [csum_block_size](#csum_block_size)
|
||||
|
||||
## data_device
|
||||
|
||||
|
|
@ -118,13 +116,12 @@ Physical block size of the journal device. Must be a multiple of
|
|||
- Type: boolean
|
||||
- Default: false
|
||||
|
||||
Do not issue fsyncs to the data device, i.e. do not force it to flush cache.
|
||||
Safe ONLY if your data device has write-through cache or if write-back
|
||||
cache is disabled. If you disable drive cache manually with `hdparm` or
|
||||
writing to `/sys/.../scsi_disk/cache_type` then make sure that you do it
|
||||
every time before starting Vitastor OSD (vitastor-disk does it automatically).
|
||||
See also [immediate_commit](layout-cluster.en.md#immediate_commit)
|
||||
for information about how to benefit from disabled cache.
|
||||
Do not issue fsyncs to the data device, i.e. do not flush its cache.
|
||||
Safe ONLY if your data device has write-through cache. If you disable
|
||||
the cache yourself using `hdparm` or `scsi_disk/cache_type` then make sure
|
||||
that the cache disable command is run every time before starting Vitastor
|
||||
OSD, for example, in the systemd unit. See also `immediate_commit` option
|
||||
for the instructions to disable cache and how to benefit from it.
|
||||
|
||||
## disable_meta_fsync
|
||||
|
||||
|
|
@ -172,47 +169,8 @@ size, it actually has to write the whole 4 KB sector.
|
|||
|
||||
Because of this it can actually be beneficial to use SSDs which work well
|
||||
with 512 byte sectors and use 512 byte disk_alignment, journal_block_size
|
||||
and meta_block_size. But at the moment, no such SSDs are known...
|
||||
and meta_block_size. But the only SSD that may fit into this category is
|
||||
Intel Optane (probably, not tested yet).
|
||||
|
||||
Clients don't need to be aware of disk_alignment, so it's not required to
|
||||
put a modified value into etcd key /vitastor/config/global.
|
||||
|
||||
## data_csum_type
|
||||
|
||||
- Type: string
|
||||
- Default: none
|
||||
|
||||
Data checksum type to use. May be "crc32c" or "none". Set to "crc32c" to
|
||||
enable data checksums.
|
||||
|
||||
## csum_block_size
|
||||
|
||||
- Type: integer
|
||||
- Default: 4096
|
||||
|
||||
Checksum calculation block size.
|
||||
|
||||
Must be equal or a multiple of [bitmap_granularity](layout-cluster.en.md#bitmap_granularity)
|
||||
(which is usually 4 KB).
|
||||
|
||||
Checksums increase metadata size by 4 bytes per each csum_block_size of data.
|
||||
|
||||
Checksums are always a tradeoff:
|
||||
1. You either sacrifice +1 GB RAM per 1 TB of data
|
||||
2. Or you raise csum_block_size, for example, to 32k and sacrifice
|
||||
50% random write iops due to checksum read-modify-write
|
||||
3. Or you turn off [inmemory_metadata](osd.en.md#inmemory_metadata) and
|
||||
sacrifice 50% random read iops due to checksum reads
|
||||
|
||||
All-flash clusters usually have enough RAM to use default csum_block_size,
|
||||
which uses 1 GB RAM per 1 TB of data. HDD clusters usually don't.
|
||||
|
||||
Thus, recommended setups are:
|
||||
1. All-flash, 1 GB RAM per 1 TB data: default (csum_block_size=4k)
|
||||
2. All-flash, less RAM: csum_block_size=4k + inmemory_metadata=false
|
||||
3. Hybrid HDD+SSD: csum_block_size=4k + inmemory_metadata=false
|
||||
4. HDD-only, faster random read: csum_block_size=32k
|
||||
5. HDD-only, faster random write: csum_block_size=4k +
|
||||
inmemory_metadata=false + meta_io=cached
|
||||
|
||||
See also [meta_io](osd.en.md#meta_io).
|
||||
|
|
|
|||
|
|
@ -25,8 +25,6 @@
|
|||
- [disable_journal_fsync](#disable_journal_fsync)
|
||||
- [disable_device_lock](#disable_device_lock)
|
||||
- [disk_alignment](#disk_alignment)
|
||||
- [data_csum_type](#data_csum_type)
|
||||
- [csum_block_size](#csum_block_size)
|
||||
|
||||
## data_device
|
||||
|
||||
|
|
@ -122,14 +120,13 @@ SSD-диске, иначе производительность пострада
|
|||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
|
||||
Не отправлять fsync-и устройству данных, т.е. не заставлять его сбрасывать кэш.
|
||||
Не отправлять fsync-и устройству данных, т.е. не сбрасывать его кэш.
|
||||
Безопасно, ТОЛЬКО если ваше устройство данных имеет кэш со сквозной
|
||||
записью (write-through) или если кэш с отложенной записью (write-back) отключён.
|
||||
Если вы отключаете кэш вручную через `hdparm` или запись в `/sys/.../scsi_disk/cache_type`,
|
||||
то удостоверьтесь, что вы делаете это каждый раз перед запуском Vitastor OSD
|
||||
(vitastor-disk делает это автоматически). Смотрите также опцию
|
||||
[immediate_commit](layout-cluster.ru.md#immediate_commit) для информации о том,
|
||||
как извлечь выгоду из отключённого кэша.
|
||||
записью (write-through). Если вы отключаете кэш через `hdparm` или
|
||||
`scsi_disk/cache_type`, то удостоверьтесь, что команда отключения кэша
|
||||
выполняется перед каждым запуском Vitastor OSD, например, в systemd unit-е.
|
||||
Смотрите также опцию `immediate_commit` для инструкций по отключению кэша
|
||||
и о том, как из этого извлечь выгоду.
|
||||
|
||||
## disable_meta_fsync
|
||||
|
||||
|
|
@ -180,52 +177,9 @@ SSD и HDD диски используют 4 КБ физические сект
|
|||
|
||||
Поэтому, на самом деле, может быть выгодно найти SSD, хорошо работающие с
|
||||
меньшими, 512-байтными, блоками и использовать 512-байтные disk_alignment,
|
||||
journal_block_size и meta_block_size. Однако на данный момент такие SSD
|
||||
не известны...
|
||||
journal_block_size и meta_block_size. Однако единственные SSD, которые
|
||||
теоретически могут попасть в эту категорию - это Intel Optane (но и это
|
||||
пока не проверялось автором).
|
||||
|
||||
Клиентам не обязательно знать про disk_alignment, так что помещать значение
|
||||
этого параметра в etcd в /vitastor/config/global не нужно.
|
||||
|
||||
## data_csum_type
|
||||
|
||||
- Тип: строка
|
||||
- Значение по умолчанию: none
|
||||
|
||||
Тип используемых OSD контрольных сумм данных. Может быть "crc32c" или "none".
|
||||
Установите в "crc32c", чтобы включить расчёт и проверку контрольных сумм данных.
|
||||
|
||||
Следует понимать, что контрольные суммы в зависимости от размера блока их
|
||||
расчёта либо увеличивают потребление памяти, либо снижают производительность.
|
||||
Подробнее смотрите в описании параметра [csum_block_size](#csum_block_size).
|
||||
|
||||
## csum_block_size
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 4096
|
||||
|
||||
Размер блока расчёта контрольных сумм.
|
||||
|
||||
Должен быть равен или кратен [bitmap_granularity](layout-cluster.ru.md#bitmap_granularity)
|
||||
(который обычно равен 4 КБ).
|
||||
|
||||
Контрольные суммы увеличивают размер метаданных на 4 байта на каждые
|
||||
csum_block_size данных.
|
||||
|
||||
Контрольные суммы - это всегда компромисс:
|
||||
1. Вы либо жертвуете потреблением +1 ГБ памяти на 1 ТБ дискового пространства
|
||||
2. Либо вы повышаете csum_block_size до, скажем, 32k и жертвуете 50%
|
||||
скорости случайной записи из-за цикла чтения-изменения-записи для расчёта
|
||||
новых контрольных сумм
|
||||
3. Либо вы отключаете [inmemory_metadata](osd.ru.md#inmemory_metadata) и
|
||||
жертвуете 50% скорости случайного чтения из-за чтения контрольных сумм
|
||||
с диска
|
||||
|
||||
Таким образом, рекомендуются следующие варианты настроек:
|
||||
1. All-flash, 1 ГБ памяти на 1 ТБ данных: по умолчанию (csum_block_size=4k)
|
||||
2. All-flash, меньше памяти: csum_block_size=4k + inmemory_metadata=false
|
||||
3. Гибридные HDD+SSD: csum_block_size=4k + inmemory_metadata=false
|
||||
4. Только HDD, быстрее случайное чтение: csum_block_size=32k
|
||||
5. Только HDD, быстрее случайная запись: csum_block_size=4k +
|
||||
inmemory_metadata=false + meta_io=cached
|
||||
|
||||
Смотрите также [meta_io](osd.ru.md#meta_io).
|
||||
|
|
|
|||
|
|
@ -8,14 +8,6 @@
|
|||
|
||||
These parameters only apply to Monitors.
|
||||
|
||||
- [use_antietcd](#use_antietcd)
|
||||
- [enable_prometheus](#enable_prometheus)
|
||||
- [mon_http_port](#mon_http_port)
|
||||
- [mon_http_ip](#mon_http_ip)
|
||||
- [mon_https_cert](#mon_https_cert)
|
||||
- [mon_https_key](#mon_https_key)
|
||||
- [mon_https_client_auth](#mon_https_client_auth)
|
||||
- [mon_https_ca](#mon_https_ca)
|
||||
- [etcd_mon_ttl](#etcd_mon_ttl)
|
||||
- [etcd_mon_timeout](#etcd_mon_timeout)
|
||||
- [etcd_mon_retries](#etcd_mon_retries)
|
||||
|
|
@ -23,95 +15,12 @@ These parameters only apply to Monitors.
|
|||
- [mon_stats_timeout](#mon_stats_timeout)
|
||||
- [osd_out_time](#osd_out_time)
|
||||
- [placement_levels](#placement_levels)
|
||||
- [use_old_pg_combinator](#use_old_pg_combinator)
|
||||
- [osd_backfillfull_ratio](#osd_backfillfull_ratio)
|
||||
|
||||
## use_antietcd
|
||||
|
||||
- Type: boolean
|
||||
- Default: false
|
||||
|
||||
Enable experimental built-in etcd replacement (clustered key-value database):
|
||||
[antietcd](https://git.yourcmc.ru/vitalif/antietcd/).
|
||||
|
||||
When set to true, monitor runs internal antietcd automatically if it finds
|
||||
a network interface with an IP address matching one of addresses in the
|
||||
`etcd_address` configuration option (in `/etc/vitastor/vitastor.conf` or in
|
||||
the monitor command line). If there are multiple matching addresses, it also
|
||||
checks `antietcd_port` and antietcd is started for address with matching port.
|
||||
By default, antietcd accepts connection on the selected IP address, but it
|
||||
can also be overridden manually in the `antietcd_ip` option.
|
||||
|
||||
When antietcd is started, monitor stores cluster metadata itself and exposes
|
||||
a etcd-compatible REST API. On disk, these metadata are stored in
|
||||
`/var/lib/vitastor/mon_2379.json.gz` (can be overridden in antietcd_data_file
|
||||
or antietcd_data_dir options). All other antietcd parameters
|
||||
(see [here](https://git.yourcmc.ru/vitalif/antietcd/)) except node_id,
|
||||
cluster, cluster_key, persist_filter, stale_read can also be set in
|
||||
Vitastor configuration with `antietcd_` prefix.
|
||||
|
||||
You can dump/load data to or from antietcd using Antietcd `anticli` tool:
|
||||
|
||||
```
|
||||
npm exec anticli -e http://etcd:2379/v3 get --prefix '' --no-temp > dump.json
|
||||
npm exec anticli -e http://antietcd:2379/v3 load < dump.json
|
||||
```
|
||||
|
||||
## enable_prometheus
|
||||
|
||||
- Type: boolean
|
||||
- Default: true
|
||||
|
||||
Enable built-in Prometheus metrics exporter at mon_http_port (8060 by default).
|
||||
|
||||
Note that only the active (master) monitor exposes metrics, others return
|
||||
HTTP 503. So you should add all monitor URLs to your Prometheus job configuration.
|
||||
|
||||
Grafana dashboard suitable for this exporter is here: [Vitastor-Grafana-6+.json](../../mon/scripts/Vitastor-Grafana-6+.json).
|
||||
|
||||
## mon_http_port
|
||||
|
||||
- Type: integer
|
||||
- Default: 8060
|
||||
|
||||
HTTP port for monitors to listen on (including metrics exporter)
|
||||
|
||||
## mon_http_ip
|
||||
|
||||
- Type: string
|
||||
|
||||
IP address for monitors to listen on (all addresses by default)
|
||||
|
||||
## mon_https_cert
|
||||
|
||||
- Type: string
|
||||
|
||||
Path to PEM SSL certificate file for monitor to listen using HTTPS
|
||||
|
||||
## mon_https_key
|
||||
|
||||
- Type: string
|
||||
|
||||
Path to PEM SSL private key file for monitor to listen using HTTPS
|
||||
|
||||
## mon_https_client_auth
|
||||
|
||||
- Type: boolean
|
||||
- Default: false
|
||||
|
||||
Enable HTTPS client certificate-based authorization for monitor connections
|
||||
|
||||
## mon_https_ca
|
||||
|
||||
- Type: string
|
||||
|
||||
Path to CA certificate for client HTTPS authorization
|
||||
|
||||
## etcd_mon_ttl
|
||||
|
||||
- Type: seconds
|
||||
- Default: 1
|
||||
- Minimum: 5
|
||||
- Default: 30
|
||||
- Minimum: 10
|
||||
|
||||
Monitor etcd lease refresh interval in seconds
|
||||
|
||||
|
|
@ -168,26 +77,3 @@ values. Smaller priority means higher level in tree. For example,
|
|||
levels are always predefined and can't be removed. If one of them is not
|
||||
present in the configuration, then it is defined with the default priority
|
||||
(100 for "host", 101 for "osd").
|
||||
|
||||
## use_old_pg_combinator
|
||||
|
||||
- Type: boolean
|
||||
- Default: false
|
||||
|
||||
Use the old PG combination generator which doesn't support [level_placement](pool.en.md#level_placement)
|
||||
and [raw_placement](pool.en.md#raw_placement) for pools which don't use this features.
|
||||
|
||||
## osd_backfillfull_ratio
|
||||
|
||||
- Type: number
|
||||
- Default: 0.99
|
||||
|
||||
Monitors try to prevent OSDs becoming 100% full during rebalance or recovery by
|
||||
calculating how much space will be occupied on every OSD after all rebalance
|
||||
and recovery operations finish, and pausing rebalance and recovery if that
|
||||
amount of space exceeds OSD capacity multiplied by the value of this
|
||||
configuration parameter.
|
||||
|
||||
Future used space is calculated by summing space used by all user data blocks
|
||||
(objects) in all PGs placed on a specific OSD, even if some of these objects
|
||||
currently reside on a different set of OSDs.
|
||||
|
|
|
|||
|
|
@ -8,14 +8,6 @@
|
|||
|
||||
Данные параметры используются только мониторами Vitastor.
|
||||
|
||||
- [use_antietcd](#use_antietcd)
|
||||
- [enable_prometheus](#enable_prometheus)
|
||||
- [mon_http_port](#mon_http_port)
|
||||
- [mon_http_ip](#mon_http_ip)
|
||||
- [mon_https_cert](#mon_https_cert)
|
||||
- [mon_https_key](#mon_https_key)
|
||||
- [mon_https_client_auth](#mon_https_client_auth)
|
||||
- [mon_https_ca](#mon_https_ca)
|
||||
- [etcd_mon_ttl](#etcd_mon_ttl)
|
||||
- [etcd_mon_timeout](#etcd_mon_timeout)
|
||||
- [etcd_mon_retries](#etcd_mon_retries)
|
||||
|
|
@ -23,97 +15,12 @@
|
|||
- [mon_stats_timeout](#mon_stats_timeout)
|
||||
- [osd_out_time](#osd_out_time)
|
||||
- [placement_levels](#placement_levels)
|
||||
- [use_old_pg_combinator](#use_old_pg_combinator)
|
||||
- [osd_backfillfull_ratio](#osd_backfillfull_ratio)
|
||||
|
||||
## use_antietcd
|
||||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
|
||||
Включить экспериментальный встроенный заменитель etcd (кластерную БД ключ-значение):
|
||||
[antietcd](https://git.yourcmc.ru/vitalif/antietcd/).
|
||||
|
||||
Если параметр установлен в true, монитор запускает antietcd автоматически,
|
||||
если обнаруживает сетевой интерфейс с одним из адресов, указанных в опции
|
||||
конфигурации `etcd_address` (в `/etc/vitastor/vitastor.conf` или в опциях
|
||||
командной строки монитора). Если таких адресов несколько, также проверяется
|
||||
опция `antietcd_port` и antietcd запускается для адреса с соответствующим
|
||||
портом. По умолчанию antietcd принимает подключения по выбранному совпадающему
|
||||
IP, но его также можно определить вручную опцией `antietcd_ip`.
|
||||
|
||||
При запуске antietcd монитор сам хранит центральные метаданные кластера и
|
||||
выставляет etcd-совместимое REST API. На диске эти метаданные хранятся в файле
|
||||
`/var/lib/vitastor/mon_2379.json.gz` (можно переопределить параметрами
|
||||
antietcd_data_file или antietcd_data_dir). Все остальные параметры antietcd
|
||||
(смотрите [по ссылке](https://git.yourcmc.ru/vitalif/antietcd/)), за исключением
|
||||
node_id, cluster, cluster_key, persist_filter, stale_read также можно задавать
|
||||
в конфигурации Vitastor с префиксом `antietcd_`.
|
||||
|
||||
Вы можете выгружать/загружать данные в или из antietcd с помощью его инструмента
|
||||
`anticli`:
|
||||
|
||||
```
|
||||
npm exec anticli -e http://etcd:2379/v3 get --prefix '' --no-temp > dump.json
|
||||
npm exec anticli -e http://antietcd:2379/v3 load < dump.json
|
||||
```
|
||||
|
||||
## enable_prometheus
|
||||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: true
|
||||
|
||||
Включить встроенный Prometheus-экспортер метрик на порту mon_http_port (по умолчанию 8060).
|
||||
|
||||
Обратите внимание, что метрики выставляет только активный (главный) монитор, остальные
|
||||
возвращают статус HTTP 503, поэтому вам следует добавлять адреса всех мониторов
|
||||
в задание по сбору метрик Prometheus.
|
||||
|
||||
Дашборд для Grafana, подходящий для этого экспортера: [Vitastor-Grafana-6+.json](../../mon/scripts/Vitastor-Grafana-6+.json).
|
||||
|
||||
## mon_http_port
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 8060
|
||||
|
||||
Порт, на котором мониторы принимают HTTP-соединения (в том числе для отдачи метрик)
|
||||
|
||||
## mon_http_ip
|
||||
|
||||
- Тип: строка
|
||||
|
||||
IP-адрес, на котором мониторы принимают HTTP-соединения (по умолчанию все адреса)
|
||||
|
||||
## mon_https_cert
|
||||
|
||||
- Тип: строка
|
||||
|
||||
Путь к PEM-файлу SSL-сертификата для монитора, чтобы принимать соединения через HTTPS
|
||||
|
||||
## mon_https_key
|
||||
|
||||
- Тип: строка
|
||||
|
||||
Путь к PEM-файлу секретного SSL-ключа для монитора, чтобы принимать соединения через HTTPS
|
||||
|
||||
## mon_https_client_auth
|
||||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
|
||||
Включить в HTTPS-сервере монитора авторизацию по клиентским сертификатам
|
||||
|
||||
## mon_https_ca
|
||||
|
||||
- Тип: строка
|
||||
|
||||
Путь к удостоверяющему сертификату для авторизации клиентских HTTPS соединений
|
||||
|
||||
## etcd_mon_ttl
|
||||
|
||||
- Тип: секунды
|
||||
- Значение по умолчанию: 1
|
||||
- Минимальное значение: 5
|
||||
- Значение по умолчанию: 30
|
||||
- Минимальное значение: 10
|
||||
|
||||
Интервал обновления etcd резервации (lease) монитором
|
||||
|
||||
|
|
@ -171,27 +78,3 @@ OSD перед обновлением агрегированной статис
|
|||
"host" и "osd" являются предопределёнными и не могут быть удалены. Если
|
||||
один из них отсутствует в конфигурации, он доопределяется с приоритетом по
|
||||
умолчанию (100 для уровня "host", 101 для "osd").
|
||||
|
||||
## use_old_pg_combinator
|
||||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
|
||||
Использовать старый генератор комбинаций PG, не поддерживающий [level_placement](pool.ru.md#level_placement)
|
||||
и [raw_placement](pool.ru.md#raw_placement) для пулов, которые не используют данные функции.
|
||||
|
||||
## osd_backfillfull_ratio
|
||||
|
||||
- Тип: число
|
||||
- Значение по умолчанию: 0.99
|
||||
|
||||
Мониторы стараются предотвратить 100% заполнение OSD в процессе ребаланса
|
||||
или восстановления, рассчитывая, сколько места будет занято на каждом OSD после
|
||||
завершения всех операций ребаланса и восстановления, и приостанавливая
|
||||
ребаланс и восстановление, если рассчитанный объём превышает ёмкость OSD,
|
||||
умноженную на значение данного параметра.
|
||||
|
||||
Будущее занятое место рассчитывается сложением места, занятого всеми
|
||||
пользовательскими блоками данных (объектами) во всех PG, расположенных
|
||||
на конкретном OSD, даже если часть этих объектов в данный момент находится
|
||||
на другом наборе OSD.
|
||||
|
|
|
|||
|
|
@ -19,17 +19,16 @@ between clients, OSDs and etcd.
|
|||
- [rdma_max_sge](#rdma_max_sge)
|
||||
- [rdma_max_msg](#rdma_max_msg)
|
||||
- [rdma_max_recv](#rdma_max_recv)
|
||||
- [rdma_max_send](#rdma_max_send)
|
||||
- [rdma_odp](#rdma_odp)
|
||||
- [peer_connect_interval](#peer_connect_interval)
|
||||
- [peer_connect_timeout](#peer_connect_timeout)
|
||||
- [osd_idle_timeout](#osd_idle_timeout)
|
||||
- [osd_ping_timeout](#osd_ping_timeout)
|
||||
- [up_wait_retry_interval](#up_wait_retry_interval)
|
||||
- [max_etcd_attempts](#max_etcd_attempts)
|
||||
- [etcd_quick_timeout](#etcd_quick_timeout)
|
||||
- [etcd_slow_timeout](#etcd_slow_timeout)
|
||||
- [etcd_keepalive_timeout](#etcd_keepalive_timeout)
|
||||
- [etcd_ws_keepalive_interval](#etcd_ws_keepalive_interval)
|
||||
- [etcd_ws_keepalive_timeout](#etcd_ws_keepalive_timeout)
|
||||
|
||||
## tcp_header_buffer_size
|
||||
|
||||
|
|
@ -68,26 +67,11 @@ but they are not connected to the cluster.
|
|||
- Type: string
|
||||
|
||||
RDMA device name to use for Vitastor OSD communications (for example,
|
||||
"rocep5s0f0"). If not specified, Vitastor will try to find an RoCE
|
||||
device matching [osd_network](osd.en.md#osd_network), preferring RoCEv2,
|
||||
or choose the first available RDMA device if no RoCE devices are
|
||||
found or if `osd_network` is not specified. Auto-selection is also
|
||||
unsupported with old libibverbs < v32, like in Debian 10 Buster or
|
||||
CentOS 7.
|
||||
|
||||
Vitastor supports all adapters, even ones without ODP support, like
|
||||
Mellanox ConnectX-3 and non-Mellanox cards. Versions up to Vitastor
|
||||
1.2.0 required ODP which is only present in Mellanox ConnectX >= 4.
|
||||
See also [rdma_odp](#rdma_odp).
|
||||
|
||||
Run `ibv_devinfo -v` as root to list available RDMA devices and their
|
||||
features.
|
||||
|
||||
Remember that you also have to configure your network switches if you use
|
||||
RoCE/RoCEv2, otherwise you may experience unstable performance. Refer to
|
||||
the manual of your network vendor for details about setting up the switch
|
||||
for RoCEv2 correctly. Usually it means setting up Lossless Ethernet with
|
||||
PFC (Priority Flow Control) and ECN (Explicit Congestion Notification).
|
||||
"rocep5s0f0"). Please note that Vitastor RDMA requires Implicit On-Demand
|
||||
Paging (Implicit ODP) and Scatter/Gather (SG) support from the RDMA device
|
||||
to work. For example, Mellanox ConnectX-3 and older adapters don't have
|
||||
Implicit ODP, so they're unsupported by Vitastor. Run `ibv_devinfo -v` as
|
||||
root to list available RDMA devices and their features.
|
||||
|
||||
## rdma_port_num
|
||||
|
||||
|
|
@ -101,17 +85,15 @@ your device has.
|
|||
## rdma_gid_index
|
||||
|
||||
- Type: integer
|
||||
- Default: 0
|
||||
|
||||
Global address identifier index of the RDMA device to use. Different GID
|
||||
indexes may correspond to different protocols like RoCEv1, RoCEv2 and iWARP.
|
||||
Search for "GID" in `ibv_devinfo -v` output to determine which GID index
|
||||
you need.
|
||||
|
||||
If not specified, Vitastor will try to auto-select a RoCEv2 IPv4 GID, then
|
||||
RoCEv2 IPv6 GID, then RoCEv1 IPv4 GID, then RoCEv1 IPv6 GID, then IB GID.
|
||||
GID auto-selection is unsupported with libibverbs < v32.
|
||||
|
||||
A correct rdma_gid_index for RoCEv2 is usually 1 (IPv6) or 3 (IPv4).
|
||||
**IMPORTANT:** If you want to use RoCEv2 (as recommended) then the correct
|
||||
rdma_gid_index is usually 1 (IPv6) or 3 (IPv4).
|
||||
|
||||
## rdma_mtu
|
||||
|
||||
|
|
@ -133,59 +115,26 @@ required to change this parameter.
|
|||
## rdma_max_msg
|
||||
|
||||
- Type: integer
|
||||
- Default: 132096
|
||||
- Default: 1048576
|
||||
|
||||
Maximum size of a single RDMA send or receive operation in bytes.
|
||||
|
||||
## rdma_max_recv
|
||||
|
||||
- Type: integer
|
||||
- Default: 16
|
||||
|
||||
Maximum number of RDMA receive buffers per connection (RDMA requires
|
||||
preallocated buffers to receive data). Each buffer is `rdma_max_msg` bytes
|
||||
in size. So this setting directly affects memory usage: a single Vitastor
|
||||
RDMA client uses `rdma_max_recv * rdma_max_msg * OSD_COUNT` bytes of memory.
|
||||
Default is roughly 2 MB * number of OSDs.
|
||||
|
||||
## rdma_max_send
|
||||
|
||||
- Type: integer
|
||||
- Default: 8
|
||||
|
||||
Maximum number of outstanding RDMA send operations per connection. Should be
|
||||
less than `rdma_max_recv` so the receiving side doesn't run out of buffers.
|
||||
Doesn't affect memory usage - additional memory isn't allocated for send
|
||||
operations.
|
||||
|
||||
## rdma_odp
|
||||
|
||||
- Type: boolean
|
||||
- Default: false
|
||||
|
||||
Use RDMA with On-Demand Paging. ODP is currently only available on Mellanox
|
||||
ConnectX-4 and newer adapters. ODP allows to not register memory explicitly
|
||||
for RDMA adapter to be able to use it. This, in turn, allows to skip memory
|
||||
copying during sending. One would think this should improve performance, but
|
||||
**in reality** RDMA performance with ODP is **drastically** worse. Example
|
||||
3-node cluster with 8 NVMe in each node and 2*25 GBit/s ConnectX-6 RDMA network
|
||||
without ODP pushes 3950000 read iops, but only 239000 iops with ODP...
|
||||
|
||||
This happens because Mellanox ODP implementation seems to be based on
|
||||
message retransmissions when the adapter doesn't know about the buffer yet -
|
||||
it likely uses standard "RNR retransmissions" (RNR = receiver not ready)
|
||||
which is generally slow in RDMA/RoCE networks. Here's a presentation about
|
||||
it from ISPASS-2021 conference: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
|
||||
|
||||
ODP support is retained in the code just in case a good ODP implementation
|
||||
appears one day.
|
||||
Maximum number of parallel RDMA receive operations. Note that this number
|
||||
of receive buffers `rdma_max_msg` in size are allocated for each client,
|
||||
so this setting actually affects memory usage. This is because RDMA receive
|
||||
operations are (sadly) still not zero-copy in Vitastor. It may be fixed in
|
||||
later versions.
|
||||
|
||||
## peer_connect_interval
|
||||
|
||||
- Type: seconds
|
||||
- Default: 5
|
||||
- Minimum: 1
|
||||
- Can be changed online: yes
|
||||
|
||||
Interval before attempting to reconnect to an unavailable OSD.
|
||||
|
||||
|
|
@ -194,7 +143,6 @@ Interval before attempting to reconnect to an unavailable OSD.
|
|||
- Type: seconds
|
||||
- Default: 5
|
||||
- Minimum: 1
|
||||
- Can be changed online: yes
|
||||
|
||||
Timeout for OSD connection attempts.
|
||||
|
||||
|
|
@ -203,7 +151,6 @@ Timeout for OSD connection attempts.
|
|||
- Type: seconds
|
||||
- Default: 5
|
||||
- Minimum: 1
|
||||
- Can be changed online: yes
|
||||
|
||||
OSD connection inactivity time after which clients and other OSDs send
|
||||
keepalive requests to check state of the connection.
|
||||
|
|
@ -213,17 +160,25 @@ keepalive requests to check state of the connection.
|
|||
- Type: seconds
|
||||
- Default: 5
|
||||
- Minimum: 1
|
||||
- Can be changed online: yes
|
||||
|
||||
Maximum time to wait for OSD keepalive responses. If an OSD doesn't respond
|
||||
within this time, the connection to it is dropped and a reconnection attempt
|
||||
is scheduled.
|
||||
|
||||
## up_wait_retry_interval
|
||||
|
||||
- Type: milliseconds
|
||||
- Default: 500
|
||||
- Minimum: 50
|
||||
|
||||
OSDs respond to clients with a special error code when they receive I/O
|
||||
requests for a PG that's not synchronized and started. This parameter sets
|
||||
the time for the clients to wait before re-attempting such I/O requests.
|
||||
|
||||
## max_etcd_attempts
|
||||
|
||||
- Type: integer
|
||||
- Default: 5
|
||||
- Can be changed online: yes
|
||||
|
||||
Maximum number of attempts for etcd requests which can't be retried
|
||||
indefinitely.
|
||||
|
|
@ -232,7 +187,6 @@ indefinitely.
|
|||
|
||||
- Type: milliseconds
|
||||
- Default: 1000
|
||||
- Can be changed online: yes
|
||||
|
||||
Timeout for etcd requests which should complete quickly, like lease refresh.
|
||||
|
||||
|
|
@ -240,7 +194,6 @@ Timeout for etcd requests which should complete quickly, like lease refresh.
|
|||
|
||||
- Type: milliseconds
|
||||
- Default: 5000
|
||||
- Can be changed online: yes
|
||||
|
||||
Timeout for etcd requests which are allowed to wait for some time.
|
||||
|
||||
|
|
@ -248,16 +201,14 @@ Timeout for etcd requests which are allowed to wait for some time.
|
|||
|
||||
- Type: seconds
|
||||
- Default: max(30, etcd_report_interval*2)
|
||||
- Can be changed online: yes
|
||||
|
||||
Timeout for etcd connection HTTP Keep-Alive. Should be higher than
|
||||
etcd_report_interval to guarantee that keepalive actually works.
|
||||
|
||||
## etcd_ws_keepalive_interval
|
||||
## etcd_ws_keepalive_timeout
|
||||
|
||||
- Type: seconds
|
||||
- Default: 5
|
||||
- Can be changed online: yes
|
||||
- Default: 30
|
||||
|
||||
etcd websocket ping interval required to keep the connection alive and
|
||||
detect disconnections quickly.
|
||||
|
|
|
|||
|
|
@ -19,17 +19,16 @@
|
|||
- [rdma_max_sge](#rdma_max_sge)
|
||||
- [rdma_max_msg](#rdma_max_msg)
|
||||
- [rdma_max_recv](#rdma_max_recv)
|
||||
- [rdma_max_send](#rdma_max_send)
|
||||
- [rdma_odp](#rdma_odp)
|
||||
- [peer_connect_interval](#peer_connect_interval)
|
||||
- [peer_connect_timeout](#peer_connect_timeout)
|
||||
- [osd_idle_timeout](#osd_idle_timeout)
|
||||
- [osd_ping_timeout](#osd_ping_timeout)
|
||||
- [up_wait_retry_interval](#up_wait_retry_interval)
|
||||
- [max_etcd_attempts](#max_etcd_attempts)
|
||||
- [etcd_quick_timeout](#etcd_quick_timeout)
|
||||
- [etcd_slow_timeout](#etcd_slow_timeout)
|
||||
- [etcd_keepalive_timeout](#etcd_keepalive_timeout)
|
||||
- [etcd_ws_keepalive_interval](#etcd_ws_keepalive_interval)
|
||||
- [etcd_ws_keepalive_timeout](#etcd_ws_keepalive_timeout)
|
||||
|
||||
## tcp_header_buffer_size
|
||||
|
||||
|
|
@ -71,27 +70,12 @@ RDMA может быть нужно только если у клиентов е
|
|||
- Тип: строка
|
||||
|
||||
Название RDMA-устройства для связи с Vitastor OSD (например, "rocep5s0f0").
|
||||
Если не указано, Vitastor попробует найти RoCE-устройство, соответствующее
|
||||
[osd_network](osd.en.md#osd_network), предпочитая RoCEv2, или выбрать первое
|
||||
попавшееся RDMA-устройство, если RoCE-устройств нет или если сеть `osd_network`
|
||||
не задана. Также автовыбор не поддерживается со старыми версиями библиотеки
|
||||
libibverbs < v32, например в Debian 10 Buster или CentOS 7.
|
||||
|
||||
Vitastor поддерживает все модели адаптеров, включая те, у которых
|
||||
нет поддержки ODP, то есть вы можете использовать RDMA с ConnectX-3 и
|
||||
картами производства не Mellanox. Версии Vitastor до 1.2.0 включительно
|
||||
требовали ODP, который есть только на Mellanox ConnectX 4 и более новых.
|
||||
См. также [rdma_odp](#rdma_odp).
|
||||
|
||||
Запустите `ibv_devinfo -v` от имени суперпользователя, чтобы посмотреть
|
||||
список доступных RDMA-устройств, их параметры и возможности.
|
||||
|
||||
Обратите внимание, что если вы используете RoCE/RoCEv2, вам также необходимо
|
||||
правильно настроить для него коммутаторы, иначе вы можете столкнуться с
|
||||
нестабильной производительностью. Подробную информацию о настройке
|
||||
коммутатора для RoCEv2 ищите в документации производителя. Обычно это
|
||||
подразумевает настройку сети без потерь на основе PFC (Priority Flow
|
||||
Control) и ECN (Explicit Congestion Notification).
|
||||
Имейте в виду, что поддержка RDMA в Vitastor требует функций устройства
|
||||
Implicit On-Demand Paging (Implicit ODP) и Scatter/Gather (SG). Например,
|
||||
адаптеры Mellanox ConnectX-3 и более старые не поддерживают Implicit ODP и
|
||||
потому не поддерживаются в Vitastor. Запустите `ibv_devinfo -v` от имени
|
||||
суперпользователя, чтобы посмотреть список доступных RDMA-устройств, их
|
||||
параметры и возможности.
|
||||
|
||||
## rdma_port_num
|
||||
|
||||
|
|
@ -106,18 +90,15 @@ Control) и ECN (Explicit Congestion Notification).
|
|||
## rdma_gid_index
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 0
|
||||
|
||||
Номер глобального идентификатора адреса RDMA-устройства, который следует
|
||||
использовать. Разным gid_index могут соответствовать разные протоколы связи:
|
||||
RoCEv1, RoCEv2, iWARP. Чтобы понять, какой нужен вам - смотрите строчки со
|
||||
словом "GID" в выводе команды `ibv_devinfo -v`.
|
||||
|
||||
Если не указан, Vitastor попробует автоматически выбрать сначала GID,
|
||||
соответствующий RoCEv2 IPv4, потом RoCEv2 IPv6, потом RoCEv1 IPv4, потом
|
||||
RoCEv1 IPv6, потом IB. Авто-выбор GID не поддерживается со старыми версиями
|
||||
libibverbs < v32.
|
||||
|
||||
Правильный rdma_gid_index для RoCEv2, как правило, 1 (IPv6) или 3 (IPv4).
|
||||
**ВАЖНО:** Если вы хотите использовать RoCEv2 (как мы и рекомендуем), то
|
||||
правильный rdma_gid_index, как правило, 1 (IPv6) или 3 (IPv4).
|
||||
|
||||
## rdma_mtu
|
||||
|
||||
|
|
@ -139,62 +120,28 @@ OSD в любом случае согласовывают реальное зн
|
|||
## rdma_max_msg
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 132096
|
||||
- Значение по умолчанию: 1048576
|
||||
|
||||
Максимальный размер одной RDMA-операции отправки или приёма.
|
||||
|
||||
## rdma_max_recv
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 16
|
||||
|
||||
Максимальное число буферов для RDMA-приёма данных на одно соединение
|
||||
(RDMA требует заранее выделенных буферов для приёма данных). Каждый буфер
|
||||
имеет размер `rdma_max_msg` байт. Таким образом, настройка прямо влияет на
|
||||
потребление памяти - один Vitastor-клиент с RDMA использует
|
||||
`rdma_max_recv * rdma_max_msg * ЧИСЛО_OSD` байт памяти, по умолчанию -
|
||||
примерно 2 МБ * число OSD.
|
||||
|
||||
## rdma_max_send
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 8
|
||||
|
||||
Максимальное число RDMA-операций отправки, отправляемых в очередь одного
|
||||
соединения. Желательно, чтобы оно было меньше `rdma_max_recv`, чтобы
|
||||
у принимающей стороны в процессе работы не заканчивались буферы на приём.
|
||||
Не влияет на потребление памяти - дополнительная память на операции отправки
|
||||
не выделяется.
|
||||
|
||||
## rdma_odp
|
||||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
|
||||
Использовать RDMA с On-Demand Paging. ODP - функция, доступная пока что
|
||||
исключительно на адаптерах Mellanox ConnectX-4 и более новых. ODP позволяет
|
||||
не регистрировать память для её использования RDMA-картой. Благодаря этому
|
||||
можно не копировать данные при отправке их в сеть и, казалось бы, это должно
|
||||
улучшать производительность - но **по факту** получается так, что
|
||||
производительность только ухудшается, причём сильно. Пример - на 3-узловом
|
||||
кластере с 8 NVMe в каждом узле и сетью 2*25 Гбит/с на чтение с RDMA без ODP
|
||||
удаётся снять 3950000 iops, а с ODP - всего 239000 iops...
|
||||
|
||||
Это происходит из-за того, что реализация ODP у Mellanox неоптимальная и
|
||||
основана на повторной передаче сообщений, когда карте не известен буфер -
|
||||
вероятно, на стандартных "RNR retransmission" (RNR = receiver not ready).
|
||||
А данные повторные передачи в RDMA/RoCE - всегда очень медленная штука.
|
||||
Презентация на эту тему с конференции ISPASS-2021: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
|
||||
|
||||
Возможность использования ODP сохранена в коде на случай, если вдруг в один
|
||||
прекрасный день появится хорошая реализация ODP.
|
||||
Максимальное число параллельных RDMA-операций получения данных. Следует
|
||||
иметь в виду, что данное число буферов размером `rdma_max_msg` выделяется
|
||||
для каждого подключённого клиентского соединения, так что данная настройка
|
||||
влияет на потребление памяти. Это так потому, что RDMA-приём данных в
|
||||
Vitastor, увы, всё равно не является zero-copy, т.е. всё равно 1 раз
|
||||
копирует данные в памяти. Данная особенность, возможно, будет исправлена в
|
||||
более новых версиях Vitastor.
|
||||
|
||||
## peer_connect_interval
|
||||
|
||||
- Тип: секунды
|
||||
- Значение по умолчанию: 5
|
||||
- Минимальное значение: 1
|
||||
- Можно менять на лету: да
|
||||
|
||||
Время ожидания перед повторной попыткой соединиться с недоступным OSD.
|
||||
|
||||
|
|
@ -203,7 +150,6 @@ OSD в любом случае согласовывают реальное зн
|
|||
- Тип: секунды
|
||||
- Значение по умолчанию: 5
|
||||
- Минимальное значение: 1
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальное время ожидания попытки соединения с OSD.
|
||||
|
||||
|
|
@ -212,7 +158,6 @@ OSD в любом случае согласовывают реальное зн
|
|||
- Тип: секунды
|
||||
- Значение по умолчанию: 5
|
||||
- Минимальное значение: 1
|
||||
- Можно менять на лету: да
|
||||
|
||||
Время неактивности соединения с OSD, после которого клиенты или другие OSD
|
||||
посылают запрос проверки состояния соединения.
|
||||
|
|
@ -222,17 +167,27 @@ OSD в любом случае согласовывают реальное зн
|
|||
- Тип: секунды
|
||||
- Значение по умолчанию: 5
|
||||
- Минимальное значение: 1
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальное время ожидания ответа на запрос проверки состояния соединения.
|
||||
Если OSD не отвечает за это время, соединение отключается и производится
|
||||
повторная попытка соединения.
|
||||
|
||||
## up_wait_retry_interval
|
||||
|
||||
- Тип: миллисекунды
|
||||
- Значение по умолчанию: 500
|
||||
- Минимальное значение: 50
|
||||
|
||||
Когда OSD получают от клиентов запросы ввода-вывода, относящиеся к не
|
||||
поднятым на данный момент на них PG, либо к PG в процессе синхронизации,
|
||||
они отвечают клиентам специальным кодом ошибки, означающим, что клиент
|
||||
должен некоторое время подождать перед повторением запроса. Именно это время
|
||||
ожидания задаёт данный параметр.
|
||||
|
||||
## max_etcd_attempts
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 5
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальное число попыток выполнения запросов к etcd для тех запросов,
|
||||
которые нельзя повторять бесконечно.
|
||||
|
|
@ -241,7 +196,6 @@ OSD в любом случае согласовывают реальное зн
|
|||
|
||||
- Тип: миллисекунды
|
||||
- Значение по умолчанию: 1000
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальное время выполнения запросов к etcd, которые должны завершаться
|
||||
быстро, таких, как обновление резервации (lease).
|
||||
|
|
@ -250,7 +204,6 @@ OSD в любом случае согласовывают реальное зн
|
|||
|
||||
- Тип: миллисекунды
|
||||
- Значение по умолчанию: 5000
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальное время выполнения запросов к etcd, для которых не обязательно
|
||||
гарантировать быстрое выполнение.
|
||||
|
|
@ -259,15 +212,13 @@ OSD в любом случае согласовывают реальное зн
|
|||
|
||||
- Тип: секунды
|
||||
- Значение по умолчанию: max(30, etcd_report_interval*2)
|
||||
- Можно менять на лету: да
|
||||
|
||||
Таймаут для HTTP Keep-Alive в соединениях к etcd. Должен быть больше, чем
|
||||
etcd_report_interval, чтобы keepalive гарантированно работал.
|
||||
|
||||
## etcd_ws_keepalive_interval
|
||||
## etcd_ws_keepalive_timeout
|
||||
|
||||
- Тип: секунды
|
||||
- Значение по умолчанию: 5
|
||||
- Можно менять на лету: да
|
||||
- Значение по умолчанию: 30
|
||||
|
||||
Интервал проверки живости вебсокет-подключений к etcd.
|
||||
|
|
|
|||
|
|
@ -7,12 +7,9 @@
|
|||
# Runtime OSD Parameters
|
||||
|
||||
These parameters only apply to OSDs, are not fixed at the moment of OSD drive
|
||||
initialization and can be changed - either with an OSD restart or, for some of
|
||||
them, even without restarting by updating configuration in etcd.
|
||||
initialization and can be changed with an OSD restart.
|
||||
|
||||
- [osd_iothread_count](#osd_iothread_count)
|
||||
- [etcd_report_interval](#etcd_report_interval)
|
||||
- [etcd_stats_interval](#etcd_stats_interval)
|
||||
- [run_primary](#run_primary)
|
||||
- [osd_network](#osd_network)
|
||||
- [bind_address](#bind_address)
|
||||
|
|
@ -20,23 +17,17 @@ them, even without restarting by updating configuration in etcd.
|
|||
- [autosync_interval](#autosync_interval)
|
||||
- [autosync_writes](#autosync_writes)
|
||||
- [recovery_queue_depth](#recovery_queue_depth)
|
||||
- [recovery_sleep_us](#recovery_sleep_us)
|
||||
- [recovery_pg_switch](#recovery_pg_switch)
|
||||
- [recovery_sync_batch](#recovery_sync_batch)
|
||||
- [readonly](#readonly)
|
||||
- [no_recovery](#no_recovery)
|
||||
- [no_rebalance](#no_rebalance)
|
||||
- [print_stats_interval](#print_stats_interval)
|
||||
- [slow_log_interval](#slow_log_interval)
|
||||
- [inode_vanish_time](#inode_vanish_time)
|
||||
- [max_write_iodepth](#max_write_iodepth)
|
||||
- [min_flusher_count](#min_flusher_count)
|
||||
- [max_flusher_count](#max_flusher_count)
|
||||
- [inmemory_metadata](#inmemory_metadata)
|
||||
- [inmemory_journal](#inmemory_journal)
|
||||
- [data_io](#data_io)
|
||||
- [meta_io](#meta_io)
|
||||
- [journal_io](#journal_io)
|
||||
- [journal_sector_buffer_count](#journal_sector_buffer_count)
|
||||
- [journal_no_same_sector_overwrites](#journal_no_same_sector_overwrites)
|
||||
- [throttle_small_writes](#throttle_small_writes)
|
||||
|
|
@ -45,55 +36,17 @@ them, even without restarting by updating configuration in etcd.
|
|||
- [throttle_target_parallelism](#throttle_target_parallelism)
|
||||
- [throttle_threshold_us](#throttle_threshold_us)
|
||||
- [osd_memlock](#osd_memlock)
|
||||
- [auto_scrub](#auto_scrub)
|
||||
- [no_scrub](#no_scrub)
|
||||
- [scrub_interval](#scrub_interval)
|
||||
- [scrub_queue_depth](#scrub_queue_depth)
|
||||
- [scrub_sleep](#scrub_sleep)
|
||||
- [scrub_list_limit](#scrub_list_limit)
|
||||
- [scrub_find_best](#scrub_find_best)
|
||||
- [scrub_ec_max_bruteforce](#scrub_ec_max_bruteforce)
|
||||
- [recovery_tune_interval](#recovery_tune_interval)
|
||||
- [recovery_tune_util_low](#recovery_tune_util_low)
|
||||
- [recovery_tune_util_high](#recovery_tune_util_high)
|
||||
- [recovery_tune_client_util_low](#recovery_tune_client_util_low)
|
||||
- [recovery_tune_client_util_high](#recovery_tune_client_util_high)
|
||||
- [recovery_tune_agg_interval](#recovery_tune_agg_interval)
|
||||
- [recovery_tune_sleep_min_us](#recovery_tune_sleep_min_us)
|
||||
- [recovery_tune_sleep_cutoff_us](#recovery_tune_sleep_cutoff_us)
|
||||
|
||||
## osd_iothread_count
|
||||
|
||||
- Type: integer
|
||||
- Default: 0
|
||||
|
||||
TCP network I/O thread count for OSD. When non-zero, a single OSD process
|
||||
may handle more TCP I/O, but at a cost of increased latency because thread
|
||||
switching overhead occurs. RDMA isn't affected by this option.
|
||||
|
||||
Because of latency, instead of enabling OSD I/O threads it's recommended to
|
||||
just create multiple OSDs per disk, or use RDMA.
|
||||
|
||||
## etcd_report_interval
|
||||
|
||||
- Type: seconds
|
||||
- Default: 5
|
||||
|
||||
Interval at which OSDs report their liveness to etcd. Affects OSD lease time
|
||||
Interval at which OSDs report their state to etcd. Affects OSD lease time
|
||||
and thus the failover speed. Lease time is equal to this parameter value
|
||||
plus max_etcd_attempts * etcd_quick_timeout because it should be guaranteed
|
||||
that every OSD always refreshes its lease in time.
|
||||
|
||||
## etcd_stats_interval
|
||||
|
||||
- Type: seconds
|
||||
- Default: 30
|
||||
|
||||
Interval at which OSDs report their statistics to etcd. Highly affects the
|
||||
imposed load on etcd, because statistics include a key for every OSD and
|
||||
for every PG. At the same time, low statistic intervals make `vitastor-cli`
|
||||
statistics more responsive.
|
||||
|
||||
## run_primary
|
||||
|
||||
- Type: boolean
|
||||
|
|
@ -136,7 +89,6 @@ OSD by hand.
|
|||
|
||||
- Type: seconds
|
||||
- Default: 5
|
||||
- Can be changed online: yes
|
||||
|
||||
Time interval at which automatic fsyncs/flushes are issued by each OSD when
|
||||
the immediate_commit mode if disabled. fsyncs are required because without
|
||||
|
|
@ -149,7 +101,6 @@ issue fsyncs at all.
|
|||
|
||||
- Type: integer
|
||||
- Default: 128
|
||||
- Can be changed online: yes
|
||||
|
||||
Same as autosync_interval, but sets the maximum number of uncommitted write
|
||||
operations before issuing an fsync operation internally.
|
||||
|
|
@ -157,41 +108,16 @@ operations before issuing an fsync operation internally.
|
|||
## recovery_queue_depth
|
||||
|
||||
- Type: integer
|
||||
- Default: 1
|
||||
- Can be changed online: yes
|
||||
- Default: 4
|
||||
|
||||
Maximum recovery and rebalance operations initiated by each OSD in parallel.
|
||||
Note that each OSD talks to a lot of other OSDs so actual number of parallel
|
||||
recovery operations per each OSD is greater than just recovery_queue_depth.
|
||||
Increasing this parameter can speedup recovery if [auto-tuning](#recovery_tune_interval)
|
||||
allows it or if it is disabled.
|
||||
|
||||
## recovery_sleep_us
|
||||
|
||||
- Type: microseconds
|
||||
- Default: 0
|
||||
- Can be changed online: yes
|
||||
|
||||
Delay for all recovery- and rebalance- related operations. If non-zero,
|
||||
such operations are artificially slowed down to reduce the impact on
|
||||
client I/O.
|
||||
|
||||
## recovery_pg_switch
|
||||
|
||||
- Type: integer
|
||||
- Default: 128
|
||||
- Can be changed online: yes
|
||||
|
||||
Number of recovery operations before switching to recovery of the next PG.
|
||||
The idea is to mix all PGs during recovery for more even space and load
|
||||
distribution but still benefit from recovery queue depth greater than 1.
|
||||
Degraded PGs are anyway scanned first.
|
||||
Maximum recovery operations per one primary OSD at any given moment of time.
|
||||
Currently it's the only parameter available to tune the speed or recovery
|
||||
and rebalancing, but it's planned to implement more.
|
||||
|
||||
## recovery_sync_batch
|
||||
|
||||
- Type: integer
|
||||
- Default: 16
|
||||
- Can be changed online: yes
|
||||
|
||||
Maximum number of recovery operations before issuing an additional fsync.
|
||||
|
||||
|
|
@ -207,7 +133,6 @@ the underlying device. This may be useful for recovery purposes.
|
|||
|
||||
- Type: boolean
|
||||
- Default: false
|
||||
- Can be changed online: yes
|
||||
|
||||
Disable automatic background recovery of objects. Note that it doesn't
|
||||
affect implicit recovery of objects happening during writes - a write is
|
||||
|
|
@ -217,7 +142,6 @@ always made to a full set of at least pg_minsize OSDs.
|
|||
|
||||
- Type: boolean
|
||||
- Default: false
|
||||
- Can be changed online: yes
|
||||
|
||||
Disable background movement of data between different OSDs. Disabling it
|
||||
means that PGs in the `has_misplaced` state will be left in it indefinitely.
|
||||
|
|
@ -226,7 +150,6 @@ means that PGs in the `has_misplaced` state will be left in it indefinitely.
|
|||
|
||||
- Type: seconds
|
||||
- Default: 3
|
||||
- Can be changed online: yes
|
||||
|
||||
Time interval at which OSDs print simple human-readable operation
|
||||
statistics on stdout.
|
||||
|
|
@ -235,25 +158,15 @@ statistics on stdout.
|
|||
|
||||
- Type: seconds
|
||||
- Default: 10
|
||||
- Can be changed online: yes
|
||||
|
||||
Time interval at which OSDs dump slow or stuck operations on stdout, if
|
||||
they're any. Also it's the time after which an operation is considered
|
||||
"slow".
|
||||
|
||||
## inode_vanish_time
|
||||
|
||||
- Type: seconds
|
||||
- Default: 60
|
||||
- Can be changed online: yes
|
||||
|
||||
Number of seconds after which a deleted inode is removed from OSD statistics.
|
||||
|
||||
## max_write_iodepth
|
||||
|
||||
- Type: integer
|
||||
- Default: 128
|
||||
- Can be changed online: yes
|
||||
|
||||
Parallel client write operation limit per one OSD. Operations that exceed
|
||||
this limit are pushed to a temporary queue instead of being executed
|
||||
|
|
@ -263,7 +176,6 @@ immediately.
|
|||
|
||||
- Type: integer
|
||||
- Default: 1
|
||||
- Can be changed online: yes
|
||||
|
||||
Flusher is a micro-thread that moves data from the journal to the data
|
||||
area of the device. Their number is auto-tuned between minimum and maximum.
|
||||
|
|
@ -273,7 +185,6 @@ Minimum number is set by this parameter.
|
|||
|
||||
- Type: integer
|
||||
- Default: 256
|
||||
- Can be changed online: yes
|
||||
|
||||
Maximum number of journal flushers (see above min_flusher_count).
|
||||
|
||||
|
|
@ -303,60 +214,6 @@ is typically very small because it's sufficient to have 16-32 MB journal
|
|||
for SSD OSDs. However, in theory it's possible that you'll want to turn it
|
||||
off for hybrid (HDD+SSD) OSDs with large journals on quick devices.
|
||||
|
||||
## data_io
|
||||
|
||||
- Type: string
|
||||
- Default: direct
|
||||
|
||||
I/O mode for *data*. One of "direct", "cached" or "directsync". Corresponds
|
||||
to O_DIRECT, O_SYNC and O_DIRECT|O_SYNC, respectively.
|
||||
|
||||
Choose "cached" to use Linux page cache. This may improve read performance
|
||||
for hot data and slower disks - HDDs and maybe SATA SSDs - but will slightly
|
||||
decrease write performance for fast disks because page cache is an overhead
|
||||
itself.
|
||||
|
||||
Choose "directsync" to use [immediate_commit](layout-cluster.ru.md#immediate_commit)
|
||||
(which requires disable_data_fsync) with drives having write-back cache
|
||||
which can't be turned off, for example, Intel Optane. Also note that *some*
|
||||
desktop SSDs (for example, HP EX950) may ignore O_SYNC thus making
|
||||
disable_data_fsync unsafe even with "directsync".
|
||||
|
||||
## meta_io
|
||||
|
||||
- Type: string
|
||||
- Default: direct
|
||||
|
||||
I/O mode for *metadata*. One of "direct", "cached" or "directsync".
|
||||
|
||||
"cached" may improve read performance, but only under the following conditions:
|
||||
1. your drives are relatively slow (HDD, SATA SSD), and
|
||||
2. checksums are enabled, and
|
||||
3. [inmemory_metadata](#inmemory_metadata) is disabled.
|
||||
Under all these conditions, metadata blocks are read from disk on every
|
||||
read request to verify checksums and caching them may reduce this extra
|
||||
read load. Without (3) metadata is never read from the disk after starting,
|
||||
and without (2) metadata blocks are read from disk only during journal
|
||||
flushing.
|
||||
|
||||
"directsync" is the same as above.
|
||||
|
||||
If the same device is used for data and metadata, meta_io by default is set
|
||||
to the same value as [data_io](#data_io).
|
||||
|
||||
## journal_io
|
||||
|
||||
- Type: string
|
||||
- Default: direct
|
||||
|
||||
I/O mode for *journal*. One of "direct", "cached" or "directsync".
|
||||
|
||||
Here, "cached" may only improve read performance for recent writes and
|
||||
only if [inmemory_journal](#inmemory_journal) is turned off.
|
||||
|
||||
If the same device is used for metadata and journal, journal_io by default
|
||||
is set to the same value as [meta_io](#meta_io).
|
||||
|
||||
## journal_sector_buffer_count
|
||||
|
||||
- Type: integer
|
||||
|
|
@ -384,7 +241,6 @@ Most (99%) other SSDs don't need this option.
|
|||
|
||||
- Type: boolean
|
||||
- Default: false
|
||||
- Can be changed online: yes
|
||||
|
||||
Enable soft throttling of small journaled writes. Useful for hybrid OSDs
|
||||
with fast journal/metadata devices and slow data devices. The idea is that
|
||||
|
|
@ -402,7 +258,6 @@ fills up.
|
|||
|
||||
- Type: integer
|
||||
- Default: 100
|
||||
- Can be changed online: yes
|
||||
|
||||
Target maximum number of throttled operations per second under the condition
|
||||
of full journal. Set it to approximate random write iops of your data devices
|
||||
|
|
@ -412,7 +267,6 @@ of full journal. Set it to approximate random write iops of your data devices
|
|||
|
||||
- Type: integer
|
||||
- Default: 100
|
||||
- Can be changed online: yes
|
||||
|
||||
Target maximum bandwidth in MB/s of throttled operations per second under
|
||||
the condition of full journal. Set it to approximate linear write
|
||||
|
|
@ -422,7 +276,6 @@ performance of your data devices (HDDs).
|
|||
|
||||
- Type: integer
|
||||
- Default: 1
|
||||
- Can be changed online: yes
|
||||
|
||||
Target maximum parallelism of throttled operations under the condition of
|
||||
full journal. Set it to approximate internal parallelism of your data
|
||||
|
|
@ -432,7 +285,6 @@ devices (1 for HDDs, 4-8 for SSDs).
|
|||
|
||||
- Type: microseconds
|
||||
- Default: 50
|
||||
- Can be changed online: yes
|
||||
|
||||
Minimal computed delay to be applied to throttled operations. Usually
|
||||
doesn't need to be changed.
|
||||
|
|
@ -442,190 +294,4 @@ doesn't need to be changed.
|
|||
- Type: boolean
|
||||
- Default: false
|
||||
|
||||
Lock all OSD memory to prevent it from being unloaded into swap with
|
||||
mlockall(). Requires sufficient ulimit -l (max locked memory).
|
||||
|
||||
## auto_scrub
|
||||
|
||||
- Type: boolean
|
||||
- Default: false
|
||||
- Can be changed online: yes
|
||||
|
||||
Data scrubbing is the process of background verification of copies to find
|
||||
and repair corrupted blocks. It's not run automatically by default since
|
||||
it's a new feature. Set this parameter to true to enable automatic scrubs.
|
||||
|
||||
This parameter makes OSDs automatically schedule data scrubbing of clean PGs
|
||||
every `scrub_interval` (see below). You can also start/schedule scrubbing
|
||||
manually by setting `next_scrub` JSON key to the desired UNIX time of the
|
||||
next scrub in `/pg/history/...` values in etcd.
|
||||
|
||||
## no_scrub
|
||||
|
||||
- Type: boolean
|
||||
- Default: false
|
||||
- Can be changed online: yes
|
||||
|
||||
Temporarily disable scrubbing and stop running scrubs.
|
||||
|
||||
## scrub_interval
|
||||
|
||||
- Type: string
|
||||
- Default: 30d
|
||||
- Can be changed online: yes
|
||||
|
||||
Default automatic scrubbing interval for all pools. Numbers without suffix
|
||||
are treated as seconds, possible unit suffixes include 's' (seconds),
|
||||
'm' (minutes), 'h' (hours), 'd' (days), 'M' (months) and 'y' (years).
|
||||
|
||||
## scrub_queue_depth
|
||||
|
||||
- Type: integer
|
||||
- Default: 1
|
||||
- Can be changed online: yes
|
||||
|
||||
Number of parallel scrubbing operations per one OSD.
|
||||
|
||||
## scrub_sleep
|
||||
|
||||
- Type: milliseconds
|
||||
- Default: 0
|
||||
- Can be changed online: yes
|
||||
|
||||
Additional interval between two consecutive scrubbing operations on one OSD.
|
||||
Can be used to slow down scrubbing if it affects user load too much.
|
||||
|
||||
## scrub_list_limit
|
||||
|
||||
- Type: integer
|
||||
- Default: 1000
|
||||
- Can be changed online: yes
|
||||
|
||||
Number of objects to list in one listing operation during scrub.
|
||||
|
||||
## scrub_find_best
|
||||
|
||||
- Type: boolean
|
||||
- Default: true
|
||||
- Can be changed online: yes
|
||||
|
||||
Find and automatically restore best versions of objects with unmatched
|
||||
copies. In replicated setups, the best version is the version with most
|
||||
matching replicas. In EC setups, the best version is the subset of data
|
||||
and parity chunks without mismatches.
|
||||
|
||||
The hypothetical situation where you might want to disable it is when
|
||||
you have 3 replicas and you are paranoid that 2 HDDs out of 3 may silently
|
||||
corrupt an object in the same way (for example, zero it out) and only
|
||||
1 HDD will remain good. In this case disabling scrub_find_best may help
|
||||
you to recover the data! See also scrub_ec_max_bruteforce below.
|
||||
|
||||
## scrub_ec_max_bruteforce
|
||||
|
||||
- Type: integer
|
||||
- Default: 100
|
||||
- Can be changed online: yes
|
||||
|
||||
Vitastor can locate corrupted chunks in EC setups with more than 1 parity
|
||||
chunk by brute-forcing all possible error locations. This configuration
|
||||
value limits the maximum number of checked combinations. You can try to
|
||||
increase it if you have EC N+K setup with N and K large enough for
|
||||
combination count `C(N+K-1, K-1) = (N+K-1)! / (K-1)! / N!` to be greater
|
||||
than the default 100.
|
||||
|
||||
If there are too many possible combinations or if multiple combinations give
|
||||
correct results then objects are marked inconsistent and aren't recovered
|
||||
automatically.
|
||||
|
||||
In replicated setups bruteforcing isn't needed, Vitastor just assumes that
|
||||
the variant with most available equal copies is correct. For example, if
|
||||
you have 3 replicas and 1 of them differs, this one is considered to be
|
||||
corrupted. But if there is no "best" version with more copies than all
|
||||
others have then the object is also marked as inconsistent.
|
||||
|
||||
## recovery_tune_interval
|
||||
|
||||
- Type: seconds
|
||||
- Default: 1
|
||||
- Can be changed online: yes
|
||||
|
||||
Interval at which OSD re-considers client and recovery load and automatically
|
||||
adjusts [recovery_sleep_us](#recovery_sleep_us). Recovery auto-tuning is
|
||||
disabled if recovery_tune_interval is set to 0.
|
||||
|
||||
Auto-tuning targets utilization. Utilization is a measure of load and is
|
||||
equal to the product of iops and average latency (so it may be greater
|
||||
than 1). You set "low" and "high" client utilization thresholds and two
|
||||
corresponding target recovery utilization levels. OSD calculates desired
|
||||
recovery utilization from client utilization using linear interpolation
|
||||
and auto-tunes recovery operation delay to make actual recovery utilization
|
||||
match desired.
|
||||
|
||||
This allows to reduce recovery/rebalance impact on client operations. It is
|
||||
of course impossible to remove it completely, but it should become adequate.
|
||||
In some tests rebalance could earlier drop client write speed from 1.5 GB/s
|
||||
to 50-100 MB/s, with default auto-tuning settings it now only reduces
|
||||
to ~1 GB/s.
|
||||
|
||||
## recovery_tune_util_low
|
||||
|
||||
- Type: number
|
||||
- Default: 0.1
|
||||
- Can be changed online: yes
|
||||
|
||||
Desired recovery/rebalance utilization when client load is high, i.e. when
|
||||
it is at or above recovery_tune_client_util_high.
|
||||
|
||||
## recovery_tune_util_high
|
||||
|
||||
- Type: number
|
||||
- Default: 1
|
||||
- Can be changed online: yes
|
||||
|
||||
Desired recovery/rebalance utilization when client load is low, i.e. when
|
||||
it is at or below recovery_tune_client_util_low.
|
||||
|
||||
## recovery_tune_client_util_low
|
||||
|
||||
- Type: number
|
||||
- Default: 0
|
||||
- Can be changed online: yes
|
||||
|
||||
Client utilization considered "low".
|
||||
|
||||
## recovery_tune_client_util_high
|
||||
|
||||
- Type: number
|
||||
- Default: 0.5
|
||||
- Can be changed online: yes
|
||||
|
||||
Client utilization considered "high".
|
||||
|
||||
## recovery_tune_agg_interval
|
||||
|
||||
- Type: integer
|
||||
- Default: 10
|
||||
- Can be changed online: yes
|
||||
|
||||
The number of last auto-tuning iterations to use for calculating the
|
||||
delay as average. Lower values result in quicker response to client
|
||||
load change, higher values result in more stable delay. Default value of 10
|
||||
is usually fine.
|
||||
|
||||
## recovery_tune_sleep_min_us
|
||||
|
||||
- Type: microseconds
|
||||
- Default: 10
|
||||
- Can be changed online: yes
|
||||
|
||||
Minimum possible value for auto-tuned recovery_sleep_us. Lower values
|
||||
are changed to 0.
|
||||
|
||||
## recovery_tune_sleep_cutoff_us
|
||||
|
||||
- Type: microseconds
|
||||
- Default: 10000000
|
||||
- Can be changed online: yes
|
||||
|
||||
Maximum possible value for auto-tuned recovery_sleep_us. Higher values
|
||||
are treated as outliers and ignored in aggregation.
|
||||
Lock all OSD memory to prevent it from being unloaded into swap with mlockall(). Requires sufficient ulimit -l (max locked memory).
|
||||
|
|
|
|||
|
|
@ -8,12 +8,9 @@
|
|||
|
||||
Данные параметры используются только OSD, но, в отличие от дисковых параметров,
|
||||
не фиксируются в момент инициализации дисков OSD и могут быть изменены в любой
|
||||
момент с помощью перезапуска OSD, а некоторые и без перезапуска, с помощью
|
||||
изменения конфигурации в etcd.
|
||||
момент с перезапуском OSD.
|
||||
|
||||
- [osd_iothread_count](#osd_iothread_count)
|
||||
- [etcd_report_interval](#etcd_report_interval)
|
||||
- [etcd_stats_interval](#etcd_stats_interval)
|
||||
- [run_primary](#run_primary)
|
||||
- [osd_network](#osd_network)
|
||||
- [bind_address](#bind_address)
|
||||
|
|
@ -21,23 +18,17 @@
|
|||
- [autosync_interval](#autosync_interval)
|
||||
- [autosync_writes](#autosync_writes)
|
||||
- [recovery_queue_depth](#recovery_queue_depth)
|
||||
- [recovery_sleep_us](#recovery_sleep_us)
|
||||
- [recovery_pg_switch](#recovery_pg_switch)
|
||||
- [recovery_sync_batch](#recovery_sync_batch)
|
||||
- [readonly](#readonly)
|
||||
- [no_recovery](#no_recovery)
|
||||
- [no_rebalance](#no_rebalance)
|
||||
- [print_stats_interval](#print_stats_interval)
|
||||
- [slow_log_interval](#slow_log_interval)
|
||||
- [inode_vanish_time](#inode_vanish_time)
|
||||
- [max_write_iodepth](#max_write_iodepth)
|
||||
- [min_flusher_count](#min_flusher_count)
|
||||
- [max_flusher_count](#max_flusher_count)
|
||||
- [inmemory_metadata](#inmemory_metadata)
|
||||
- [inmemory_journal](#inmemory_journal)
|
||||
- [data_io](#data_io)
|
||||
- [meta_io](#meta_io)
|
||||
- [journal_io](#journal_io)
|
||||
- [journal_sector_buffer_count](#journal_sector_buffer_count)
|
||||
- [journal_no_same_sector_overwrites](#journal_no_same_sector_overwrites)
|
||||
- [throttle_small_writes](#throttle_small_writes)
|
||||
|
|
@ -46,56 +37,17 @@
|
|||
- [throttle_target_parallelism](#throttle_target_parallelism)
|
||||
- [throttle_threshold_us](#throttle_threshold_us)
|
||||
- [osd_memlock](#osd_memlock)
|
||||
- [auto_scrub](#auto_scrub)
|
||||
- [no_scrub](#no_scrub)
|
||||
- [scrub_interval](#scrub_interval)
|
||||
- [scrub_queue_depth](#scrub_queue_depth)
|
||||
- [scrub_sleep](#scrub_sleep)
|
||||
- [scrub_list_limit](#scrub_list_limit)
|
||||
- [scrub_find_best](#scrub_find_best)
|
||||
- [scrub_ec_max_bruteforce](#scrub_ec_max_bruteforce)
|
||||
- [recovery_tune_interval](#recovery_tune_interval)
|
||||
- [recovery_tune_util_low](#recovery_tune_util_low)
|
||||
- [recovery_tune_util_high](#recovery_tune_util_high)
|
||||
- [recovery_tune_client_util_low](#recovery_tune_client_util_low)
|
||||
- [recovery_tune_client_util_high](#recovery_tune_client_util_high)
|
||||
- [recovery_tune_agg_interval](#recovery_tune_agg_interval)
|
||||
- [recovery_tune_sleep_min_us](#recovery_tune_sleep_min_us)
|
||||
- [recovery_tune_sleep_cutoff_us](#recovery_tune_sleep_cutoff_us)
|
||||
|
||||
## osd_iothread_count
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 0
|
||||
|
||||
Число отдельных потоков для обработки ввода-вывода через TCP-сеть на
|
||||
стороне OSD. Включение опции позволяет каждому отдельному OSD передавать
|
||||
по сети больше данных, но ухудшает задержку из-за накладных расходов
|
||||
переключения потоков. На работу RDMA опция не влияет.
|
||||
|
||||
Из-за задержек вместо включения потоков ввода-вывода OSD рекомендуется
|
||||
просто создавать по несколько OSD на каждом диске, или использовать RDMA.
|
||||
|
||||
## etcd_report_interval
|
||||
|
||||
- Тип: секунды
|
||||
- Значение по умолчанию: 5
|
||||
|
||||
Интервал, с которым OSD сообщает о том, что жив, в etcd. Значение параметра
|
||||
влияет на время резервации (lease) OSD и поэтому - на скорость переключения
|
||||
Интервал, с которым OSD обновляет своё состояние в etcd. Значение параметра
|
||||
влияет на время резервации (lease) OSD и поэтому на скорость переключения
|
||||
при падении OSD. Время lease равняется значению этого параметра плюс
|
||||
max_etcd_attempts * etcd_quick_timeout.
|
||||
|
||||
## etcd_stats_interval
|
||||
|
||||
- Тип: секунды
|
||||
- Значение по умолчанию: 30
|
||||
|
||||
Интервал, с которым OSD обновляет свою статистику в etcd. Сильно влияет на
|
||||
создаваемую нагрузку на etcd, потому что статистика содержит по ключу на
|
||||
каждый OSD и на каждую PG. В то же время низкий интервал делает
|
||||
статистику, печатаемую `vitastor-cli`, отзывчивей.
|
||||
|
||||
## run_primary
|
||||
|
||||
- Тип: булево (да/нет)
|
||||
|
|
@ -139,7 +91,6 @@ RUNNING), подходящий под заданную маску. Также н
|
|||
|
||||
- Тип: секунды
|
||||
- Значение по умолчанию: 5
|
||||
- Можно менять на лету: да
|
||||
|
||||
Временной интервал отправки автоматических fsync-ов (операций очистки кэша)
|
||||
каждым OSD для случая, когда режим immediate_commit отключён. fsync-и нужны
|
||||
|
|
@ -152,7 +103,6 @@ OSD, чтобы успевать очищать журнал - без них OSD
|
|||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 128
|
||||
- Можно менять на лету: да
|
||||
|
||||
Аналогично autosync_interval, но задаёт не временной интервал, а
|
||||
максимальное количество незафиксированных операций записи перед
|
||||
|
|
@ -161,43 +111,17 @@ OSD, чтобы успевать очищать журнал - без них OSD
|
|||
## recovery_queue_depth
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 1
|
||||
- Можно менять на лету: да
|
||||
- Значение по умолчанию: 4
|
||||
|
||||
Максимальное число параллельных операций восстановления, инициируемых одним
|
||||
OSD в любой момент времени. Имейте в виду, что каждый OSD обычно работает с
|
||||
многими другими OSD, так что на практике параллелизм восстановления больше,
|
||||
чем просто recovery_queue_depth. Увеличение значения этого параметра может
|
||||
ускорить восстановление если [автотюнинг скорости](#recovery_tune_interval)
|
||||
разрешает это или если он отключён.
|
||||
|
||||
## recovery_sleep_us
|
||||
|
||||
- Тип: микросекунды
|
||||
- Значение по умолчанию: 0
|
||||
- Можно менять на лету: да
|
||||
|
||||
Delay for all recovery- and rebalance- related operations. If non-zero,
|
||||
such operations are artificially slowed down to reduce the impact on
|
||||
client I/O.
|
||||
|
||||
## recovery_pg_switch
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 128
|
||||
- Можно менять на лету: да
|
||||
|
||||
Число операций восстановления перед переключением на восстановление другой PG.
|
||||
Идея заключается в том, чтобы восстанавливать все PG одновременно для более
|
||||
равномерного распределения места и нагрузки, но при этом всё равно выигрывать
|
||||
от глубины очереди восстановления, большей, чем 1. Деградированные PG в любом
|
||||
случае сканируются первыми.
|
||||
Максимальное число операций восстановления на одном первичном OSD в любой
|
||||
момент времени. На данный момент единственный параметр, который можно менять
|
||||
для ускорения или замедления восстановления и перебалансировки данных, но
|
||||
в планах реализация других параметров.
|
||||
|
||||
## recovery_sync_batch
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 16
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальное число операций восстановления перед дополнительным fsync.
|
||||
|
||||
|
|
@ -213,7 +137,6 @@ client I/O.
|
|||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
- Можно менять на лету: да
|
||||
|
||||
Отключить автоматическое фоновое восстановление объектов. Обратите внимание,
|
||||
что эта опция не отключает восстановление объектов, происходящее при
|
||||
|
|
@ -224,7 +147,6 @@ OSD.
|
|||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
- Можно менять на лету: да
|
||||
|
||||
Отключить фоновое перемещение объектов между разными OSD. Отключение
|
||||
означает, что PG, находящиеся в состоянии `has_misplaced`, будут оставлены
|
||||
|
|
@ -234,7 +156,6 @@ OSD.
|
|||
|
||||
- Тип: секунды
|
||||
- Значение по умолчанию: 3
|
||||
- Можно менять на лету: да
|
||||
|
||||
Временной интервал, с которым OSD печатают простую человекочитаемую
|
||||
статистику выполнения операций в стандартный вывод.
|
||||
|
|
@ -243,25 +164,15 @@ OSD.
|
|||
|
||||
- Тип: секунды
|
||||
- Значение по умолчанию: 10
|
||||
- Можно менять на лету: да
|
||||
|
||||
Временной интервал, с которым OSD выводят в стандартный вывод список
|
||||
медленных или зависших операций, если таковые имеются. Также время, при
|
||||
превышении которого операция считается "медленной".
|
||||
|
||||
## inode_vanish_time
|
||||
|
||||
- Тип: секунды
|
||||
- Значение по умолчанию: 60
|
||||
- Можно менять на лету: да
|
||||
|
||||
Число секунд, через которое удалённые инод удаляется и из статистики OSD.
|
||||
|
||||
## max_write_iodepth
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 128
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальное число одновременных клиентских операций записи на один OSD.
|
||||
Операции, превышающие этот лимит, не исполняются сразу, а сохраняются во
|
||||
|
|
@ -271,7 +182,6 @@ OSD.
|
|||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 1
|
||||
- Можно менять на лету: да
|
||||
|
||||
Flusher - это микро-поток (корутина), которая копирует данные из журнала в
|
||||
основную область устройства данных. Их число настраивается динамически между
|
||||
|
|
@ -281,7 +191,6 @@ Flusher - это микро-поток (корутина), которая коп
|
|||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 256
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальное число микро-потоков очистки журнала (см. выше min_flusher_count).
|
||||
|
||||
|
|
@ -312,63 +221,6 @@ Flusher - это микро-поток (корутина), которая коп
|
|||
параметра может оказаться полезным для гибридных OSD (HDD+SSD) с большими
|
||||
журналами, расположенными на быстром по сравнению с HDD устройстве.
|
||||
|
||||
## data_io
|
||||
|
||||
- Тип: строка
|
||||
- Значение по умолчанию: direct
|
||||
|
||||
Режим ввода-вывода для *данных*. Одно из значений "direct", "cached" или
|
||||
"directsync", означающих O_DIRECT, O_SYNC и O_DIRECT|O_SYNC, соответственно.
|
||||
|
||||
Выберите "cached", чтобы использовать системный кэш Linux (page cache) при
|
||||
чтении и записи. Это может улучшить скорость чтения горячих данных с
|
||||
относительно медленных дисков - HDD и, возможно, SATA SSD - но немного
|
||||
снижает производительность записи для быстрых дисков, так как кэш сам по
|
||||
себе тоже добавляет накладные расходы.
|
||||
|
||||
Выберите "directsync", если хотите задействовать
|
||||
[immediate_commit](layout-cluster.ru.md#immediate_commit) (требующий
|
||||
включенияd disable_data_fsync) на дисках с неотключаемым кэшем. Пример таких
|
||||
дисков - Intel Optane. При этом также стоит иметь в виду, что *некоторые*
|
||||
настольные SSD (например, HP EX950) игнорируют флаг O_SYNC, делая отключение
|
||||
fsync небезопасным даже с режимом "directsync".
|
||||
|
||||
## meta_io
|
||||
|
||||
- Тип: строка
|
||||
- Значение по умолчанию: direct
|
||||
|
||||
Режим ввода-вывода для *метаданных*. Одно из значений "direct", "cached" или
|
||||
"directsync".
|
||||
|
||||
"cached" может улучшить скорость чтения, если:
|
||||
1. у вас медленные диски (HDD, SATA SSD)
|
||||
2. контрольные суммы включены
|
||||
3. параметр [inmemory_metadata](#inmemory_metadata) отключён.
|
||||
При этих условиях блоки метаданных читаются с диска при каждом запросе чтения
|
||||
для проверки контрольных сумм и их кэширование может снизить дополнительную
|
||||
нагрузку на диск. Без (3) метаданные никогда не читаются с диска после
|
||||
запуска OSD, а без (2) блоки метаданных читаются только при сбросе журнала.
|
||||
|
||||
Если одно и то же устройство используется для данных и метаданных, режим
|
||||
ввода-вывода метаданных по умолчанию устанавливается равным [data_io](#data_io).
|
||||
|
||||
## journal_io
|
||||
|
||||
- Тип: строка
|
||||
- Значение по умолчанию: direct
|
||||
|
||||
Режим ввода-вывода для *журнала*. Одно из значений "direct", "cached" или
|
||||
"directsync".
|
||||
|
||||
Здесь "cached" может улучшить скорость чтения только недавно записанных
|
||||
данных и только если параметр [inmemory_journal](#inmemory_journal)
|
||||
отключён.
|
||||
|
||||
Если одно и то же устройство используется для метаданных и журнала,
|
||||
режим ввода-вывода журнала по умолчанию устанавливается равным
|
||||
[meta_io](#meta_io).
|
||||
|
||||
## journal_sector_buffer_count
|
||||
|
||||
- Тип: целое число
|
||||
|
|
@ -398,7 +250,6 @@ fsync небезопасным даже с режимом "directsync".
|
|||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
- Можно менять на лету: да
|
||||
|
||||
Разрешить мягкое ограничение скорости журналируемой записи. Полезно для
|
||||
гибридных OSD с быстрыми устройствами метаданных и медленными устройствами
|
||||
|
|
@ -417,7 +268,6 @@ fsync небезопасным даже с режимом "directsync".
|
|||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 100
|
||||
- Можно менять на лету: да
|
||||
|
||||
Расчётное максимальное число ограничиваемых операций в секунду при условии
|
||||
отсутствия свободного места в журнале. Устанавливайте приблизительно равным
|
||||
|
|
@ -428,7 +278,6 @@ fsync небезопасным даже с режимом "directsync".
|
|||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 100
|
||||
- Можно менять на лету: да
|
||||
|
||||
Расчётный максимальный размер в МБ/с ограничиваемых операций в секунду при
|
||||
условии отсутствия свободного места в журнале. Устанавливайте приблизительно
|
||||
|
|
@ -439,7 +288,6 @@ fsync небезопасным даже с режимом "directsync".
|
|||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 1
|
||||
- Можно менять на лету: да
|
||||
|
||||
Расчётный максимальный параллелизм ограничиваемых операций в секунду при
|
||||
условии отсутствия свободного места в журнале. Устанавливайте приблизительно
|
||||
|
|
@ -450,7 +298,6 @@ fsync небезопасным даже с режимом "directsync".
|
|||
|
||||
- Тип: микросекунды
|
||||
- Значение по умолчанию: 50
|
||||
- Можно менять на лету: да
|
||||
|
||||
Минимальная применимая к ограничиваемым операциям задержка. Обычно не
|
||||
требует изменений.
|
||||
|
|
@ -460,203 +307,4 @@ fsync небезопасным даже с режимом "directsync".
|
|||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
|
||||
Блокировать всю память OSD с помощью mlockall, чтобы запретить её выгрузку
|
||||
в пространство подкачки. Требует достаточного значения ulimit -l (лимита
|
||||
заблокированной памяти).
|
||||
|
||||
## auto_scrub
|
||||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
- Можно менять на лету: да
|
||||
|
||||
Скраб - процесс фоновой проверки копий данных, предназначенный, чтобы
|
||||
находить и исправлять повреждённые блоки. По умолчанию эти проверки ещё не
|
||||
запускаются автоматически, так как являются новой функцией. Чтобы включить
|
||||
автоматическое планирование скрабов, установите данный параметр в true.
|
||||
|
||||
Включённый параметр заставляет OSD автоматически планировать фоновую
|
||||
проверку чистых PG раз в `scrub_interval` (см. ниже). Вы также можете
|
||||
запустить или запланировать проверку вручную, установив значение ключа JSON
|
||||
`next_scrub` внутри ключей etcd `/pg/history/...` в UNIX-время следующей
|
||||
желаемой проверки.
|
||||
|
||||
## no_scrub
|
||||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
- Можно менять на лету: да
|
||||
|
||||
Временно отключить и остановить запущенные скрабы.
|
||||
|
||||
## scrub_interval
|
||||
|
||||
- Тип: строка
|
||||
- Значение по умолчанию: 30d
|
||||
- Можно менять на лету: да
|
||||
|
||||
Интервал автоматической фоновой проверки по умолчанию для всех пулов.
|
||||
Значения без указанной единицы измерения считаются в секундах, допустимые
|
||||
символы единиц измерения в конце: 's' (секунды),
|
||||
'm' (минуты), 'h' (часы), 'd' (дни), 'M' (месяца) или 'y' (годы).
|
||||
|
||||
## scrub_queue_depth
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 1
|
||||
- Можно менять на лету: да
|
||||
|
||||
Число параллельных операций фоновой проверки на один OSD.
|
||||
|
||||
## scrub_sleep
|
||||
|
||||
- Тип: миллисекунды
|
||||
- Значение по умолчанию: 0
|
||||
- Можно менять на лету: да
|
||||
|
||||
Дополнительный интервал ожидания после фоновой проверки каждого объекта на
|
||||
одном OSD. Может использоваться для замедления скраба, если он слишком
|
||||
сильно влияет на пользовательскую нагрузку.
|
||||
|
||||
## scrub_list_limit
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 1000
|
||||
- Можно менять на лету: да
|
||||
|
||||
Размер загружаемых за одну операцию списков объектов в процессе фоновой
|
||||
проверки.
|
||||
|
||||
## scrub_find_best
|
||||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: true
|
||||
- Можно менять на лету: да
|
||||
|
||||
Находить и автоматически восстанавливать "лучшие версии" объектов с
|
||||
несовпадающими копиями/частями. При использовании репликации "лучшая"
|
||||
версия - версия, доступная в большем числе экземпляров, чем другие. При
|
||||
использовании кодов коррекции ошибок "лучшая" версия - это подмножество
|
||||
частей данных и чётности, полностью соответствующих друг другу.
|
||||
|
||||
Гипотетическая ситуация, в которой вы можете захотеть отключить этот
|
||||
поиск - это если у вас 3 реплики и вы боитесь, что 2 диска из 3 могут
|
||||
незаметно и одинаково повредить данные одного и того же объекта, например,
|
||||
занулив его, и только 1 диск останется неповреждённым. В этой ситуации
|
||||
отключение этого параметра поможет вам восстановить данные! Смотрите также
|
||||
описание следующего параметра - scrub_ec_max_bruteforce.
|
||||
|
||||
## scrub_ec_max_bruteforce
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 100
|
||||
- Можно менять на лету: да
|
||||
|
||||
Vitastor старается определить повреждённые части объектов при использовании
|
||||
EC (кодов коррекции ошибок) с более, чем 1 диском чётности, путём перебора
|
||||
всех возможных комбинаций ошибочных частей. Данное значение конфигурации
|
||||
ограничивает число перебираемых комбинаций. Вы можете попробовать поднять
|
||||
его, если используете схему кодирования EC N+K с N и K, достаточно большими
|
||||
для того, чтобы число сочетаний `C(N+K-1, K-1) = (N+K-1)! / (K-1)! / N!`
|
||||
было больше, чем стандартное значение 100.
|
||||
|
||||
Если возможных комбинаций слишком много или если корректная комбинаций не
|
||||
определяется однозначно, объекты помечаются неконсистентными (inconsistent)
|
||||
и не восстанавливаются автоматически.
|
||||
|
||||
При использовании репликации перебор не нужен, Vitastor просто предполагает,
|
||||
что вариант объекта с наибольшим количеством одинаковых копий корректен.
|
||||
Например, если вы используете 3 реплики и 1 из них отличается, эта 1 копия
|
||||
считается некорректной. Однако, если "лучшую" версию с числом доступных
|
||||
копий большим, чем у всех других версий, найти невозможно, то объект тоже
|
||||
маркируется неконсистентным.
|
||||
|
||||
## recovery_tune_interval
|
||||
|
||||
- Тип: секунды
|
||||
- Значение по умолчанию: 1
|
||||
- Можно менять на лету: да
|
||||
|
||||
Интервал, с которым OSD пересматривает клиентскую нагрузку и нагрузку
|
||||
восстановления и автоматически подстраивает [recovery_sleep_us](#recovery_sleep_us).
|
||||
Автотюнинг (автоподстройка) отключается, если recovery_tune_interval
|
||||
устанавливается в значение 0.
|
||||
|
||||
Автотюнинг регулирует утилизацию. Утилизация является мерой нагрузки
|
||||
и равна произведению числа операций в секунду и средней задержки
|
||||
(то есть, она может быть выше 1). Вы задаёте два уровня клиентской
|
||||
утилизации - "низкий" и "высокий" (low и high) и два соответствующих
|
||||
целевых уровня утилизации операциями восстановления. OSD рассчитывает
|
||||
желаемый уровень утилизации восстановления линейной интерполяцией от
|
||||
клиентской утилизации и подстраивает задержку операций восстановления
|
||||
так, чтобы фактическая утилизация восстановления совпадала с желаемой.
|
||||
|
||||
Это позволяет снизить влияние восстановления и ребаланса на клиентские
|
||||
операции. Конечно, невозможно исключить такое влияние полностью, но оно
|
||||
должно становиться адекватнее. В некоторых тестах перебалансировка могла
|
||||
снижать клиентскую скорость записи с 1.5 ГБ/с до 50-100 МБ/с, а теперь, с
|
||||
настройками автотюнинга по умолчанию, она снижается только до ~1 ГБ/с.
|
||||
|
||||
## recovery_tune_util_low
|
||||
|
||||
- Тип: число
|
||||
- Значение по умолчанию: 0.1
|
||||
- Можно менять на лету: да
|
||||
|
||||
Желаемая утилизация восстановления в моменты, когда клиентская нагрузка
|
||||
высокая, то есть, находится на уровне или выше recovery_tune_client_util_high.
|
||||
|
||||
## recovery_tune_util_high
|
||||
|
||||
- Тип: число
|
||||
- Значение по умолчанию: 1
|
||||
- Можно менять на лету: да
|
||||
|
||||
Желаемая утилизация восстановления в моменты, когда клиентская нагрузка
|
||||
низкая, то есть, находится на уровне или ниже recovery_tune_client_util_low.
|
||||
|
||||
## recovery_tune_client_util_low
|
||||
|
||||
- Тип: число
|
||||
- Значение по умолчанию: 0
|
||||
- Можно менять на лету: да
|
||||
|
||||
Клиентская утилизация, которая считается "низкой".
|
||||
|
||||
## recovery_tune_client_util_high
|
||||
|
||||
- Тип: число
|
||||
- Значение по умолчанию: 0.5
|
||||
- Можно менять на лету: да
|
||||
|
||||
Клиентская утилизация, которая считается "высокой".
|
||||
|
||||
## recovery_tune_agg_interval
|
||||
|
||||
- Тип: целое число
|
||||
- Значение по умолчанию: 10
|
||||
- Можно менять на лету: да
|
||||
|
||||
Число последних итераций автоподстройки для расчёта задержки как среднего
|
||||
значения. Меньшие значения параметра ускоряют отклик на изменение нагрузки,
|
||||
большие значения делают задержку стабильнее. Значение по умолчанию 10
|
||||
обычно нормальное и не требует изменений.
|
||||
|
||||
## recovery_tune_sleep_min_us
|
||||
|
||||
- Тип: микросекунды
|
||||
- Значение по умолчанию: 10
|
||||
- Можно менять на лету: да
|
||||
|
||||
Минимальное возможное значение авто-подстроенного recovery_sleep_us.
|
||||
Меньшие значения заменяются на 0.
|
||||
|
||||
## recovery_tune_sleep_cutoff_us
|
||||
|
||||
- Тип: микросекунды
|
||||
- Значение по умолчанию: 10000000
|
||||
- Можно менять на лету: да
|
||||
|
||||
Максимальное возможное значение авто-подстроенного recovery_sleep_us.
|
||||
Большие значения считаются случайными выбросами и игнорируются в
|
||||
усреднении.
|
||||
Блокировать всю память OSD с помощью mlockall, чтобы запретить её выгрузку в пространство подкачки. Требует достаточного значения ulimit -l (лимита заблокированной памяти).
|
||||
|
|
|
|||
|
|
@ -32,18 +32,11 @@ Parameters:
|
|||
- [pg_minsize](#pg_minsize)
|
||||
- [pg_count](#pg_count)
|
||||
- [failure_domain](#failure_domain)
|
||||
- [level_placement](#level_placement)
|
||||
- [raw_placement](#raw_placement)
|
||||
- [max_osd_combinations](#max_osd_combinations)
|
||||
- [block_size](#block_size)
|
||||
- [bitmap_granularity](#bitmap_granularity)
|
||||
- [immediate_commit](#immediate_commit)
|
||||
- [pg_stripe_size](#pg_stripe_size)
|
||||
- [root_node](#root_node)
|
||||
- [osd_tags](#osd_tags)
|
||||
- [primary_affinity_tags](#primary_affinity_tags)
|
||||
- [scrub_interval](#scrub_interval)
|
||||
- [used_for_fs](#used_for_fs)
|
||||
|
||||
Examples:
|
||||
|
||||
|
|
@ -55,7 +48,7 @@ Examples:
|
|||
OSD placement tree is set in a separate etcd key `/vitastor/config/node_placement`
|
||||
in the following JSON format:
|
||||
|
||||
```
|
||||
`
|
||||
{
|
||||
"<node name or OSD number>": {
|
||||
"level": "<level>",
|
||||
|
|
@ -63,7 +56,7 @@ in the following JSON format:
|
|||
},
|
||||
...
|
||||
}
|
||||
```
|
||||
`
|
||||
|
||||
Here, if a node name is a number then it is assumed to refer to an OSD.
|
||||
Level of the OSD is always "osd" and cannot be overriden. You may only
|
||||
|
|
@ -86,11 +79,7 @@ Parent node reference is required for intermediate tree nodes.
|
|||
Separate OSD settings are set in etc keys `/vitastor/config/osd/<number>`
|
||||
in JSON format `{"<key>":<value>}`.
|
||||
|
||||
As of now, the following settings are supported:
|
||||
|
||||
- [reweight](#reweight)
|
||||
- [tags](#tags)
|
||||
- [noout](#noout)
|
||||
As of now, there is only one setting:
|
||||
|
||||
## reweight
|
||||
|
||||
|
|
@ -104,23 +93,6 @@ This means an OSD configured with reweight lower than 1 receives less PGs than
|
|||
it normally would. An OSD with reweight = 0 won't store any data. You can set
|
||||
reweight to 0 to trigger rebalance and remove all data from an OSD.
|
||||
|
||||
## tags
|
||||
|
||||
- Type: string or array of strings
|
||||
|
||||
Sets tag or multiple tags for this OSD. Tags can be used to group OSDs into
|
||||
subsets and then use a specific subset for pool instead of all OSDs.
|
||||
For example you can mark SSD OSDs with tag "ssd" and HDD OSDs with "hdd" and
|
||||
such tags will work as device classes.
|
||||
|
||||
## noout
|
||||
|
||||
- Type: boolean
|
||||
- Default: false
|
||||
|
||||
If set to true, [osd_out_time](monitor.en.md#osd_out_time) is ignored for this
|
||||
OSD and it's never removed from data distribution by the monitor.
|
||||
|
||||
# Pool parameters
|
||||
|
||||
## name
|
||||
|
|
@ -134,12 +106,9 @@ Pool name.
|
|||
|
||||
- Type: string
|
||||
- Required
|
||||
- One of: "replicated", "xor", "ec" or "jerasure"
|
||||
- One of: "replicated", "xor" or "jerasure"
|
||||
|
||||
Redundancy scheme used for data in this pool. "jerasure" is an alias for "ec",
|
||||
both use Reed-Solomon-Vandermonde codes based on ISA-L or jerasure libraries.
|
||||
Fast ISA-L based implementation is used automatically when it's available,
|
||||
slower jerasure version is used otherwise.
|
||||
Redundancy scheme used for data in this pool.
|
||||
|
||||
## pg_size
|
||||
|
||||
|
|
@ -169,26 +138,6 @@ That is, if it becomes impossible to place PG data on at least (pg_minsize)
|
|||
OSDs, PG is deactivated for both read and write. So you know that a fresh
|
||||
write always goes to at least (pg_minsize) OSDs (disks).
|
||||
|
||||
For example, the difference between pg_minsize 2 and 1 in a 3-way replicated
|
||||
pool (pg_size=3) is:
|
||||
- If 2 hosts go down with pg_minsize=2, the pool becomes inactive and remains
|
||||
inactive for [osd_out_time](monitor.en.md#osd_out_time) (10 minutes). After
|
||||
this timeout, the monitor selects replacement hosts/OSDs and the pool comes
|
||||
up and starts to heal. Therefore, if you don't have replacement OSDs, i.e.
|
||||
if you only have 3 hosts with OSDs and 2 of them are down, the pool remains
|
||||
inactive until you add or return at least 1 host (or change failure_domain
|
||||
to "osd").
|
||||
- If 2 hosts go down with pg_minsize=1, the pool only experiences a short
|
||||
I/O pause until the monitor notices that OSDs are down (5-10 seconds with
|
||||
the default [etcd_report_interval](osd.en.md#etcd_report_interval)). After
|
||||
this pause, I/O resumes, but new data is temporarily written in only 1 copy.
|
||||
Then, after osd_out_time, the monitor also selects replacement OSDs and the
|
||||
pool starts to heal.
|
||||
|
||||
So, pg_minsize regulates the number of failures that a pool can tolerate
|
||||
without temporary downtime for [osd_out_time](monitor.en.md#osd_out_time),
|
||||
but at a cost of slightly reduced storage reliability.
|
||||
|
||||
FIXME: pg_minsize behaviour may be changed in the future to only make PGs
|
||||
read-only instead of deactivating them.
|
||||
|
||||
|
|
@ -200,8 +149,8 @@ read-only instead of deactivating them.
|
|||
Number of PGs for this pool. The value should be big enough for the monitor /
|
||||
LP solver to be able to optimize data placement.
|
||||
|
||||
"Enough" is usually around 10-100 PGs per OSD, i.e. you set pg_count for pool
|
||||
to (total OSD count * 10 / pg_size). You can round it to the closest power of 2,
|
||||
"Enough" is usually around 64-128 PGs per OSD, i.e. you set pg_count for pool
|
||||
to (total OSD count * 100 / pg_size). You can round it to the closest power of 2,
|
||||
because it makes it easier to reduce or increase PG count later by dividing or
|
||||
multiplying it by 2.
|
||||
|
||||
|
|
@ -223,69 +172,6 @@ never put on OSDs in the same failure domain (for example, on the same host).
|
|||
So failure domain specifies the unit which failure you are protecting yourself
|
||||
from.
|
||||
|
||||
## level_placement
|
||||
|
||||
- Type: string
|
||||
|
||||
Additional failure domain rules, applied in conjuction with failure_domain.
|
||||
Must be specified in the following form:
|
||||
|
||||
`<placement level>=<sequence of characters>, <level2>=<sequence2>, ...`
|
||||
|
||||
Sequence should be exactly [pg_size](#pg_size) character long. Each character
|
||||
corresponds to an OSD in the PG of this pool. Equal characters mean that
|
||||
corresponding items of the PG should be placed into the same placement tree
|
||||
item at this level. Different characters mean that items should be placed into
|
||||
different items.
|
||||
|
||||
For example, if you want a EC 4+2 pool and you want every 2 chunks to be stored
|
||||
in its own datacenter and you also want each chunk to be stored on a different
|
||||
host, you should set `level_placement` to `dc=112233 host=123456`.
|
||||
|
||||
Or you can set `level_placement` to `dc=112233` and leave `failure_domain` empty,
|
||||
because `host` is the default `failure_domain` and it will be applied anyway.
|
||||
|
||||
Without this rule, it may happen that 3 chunks will be stored on OSDs in the
|
||||
same datacenter, and the data will become inaccessibly if that datacenter goes
|
||||
down in this case.
|
||||
|
||||
Of course, you should group your hosts into datacenters before applying the rule
|
||||
by setting [placement_levels](monitor.en.md#placement_levels) to something like
|
||||
`{"dc":90,"host":100,"osd":110}` and add DCs to [node_placement](#placement-tree),
|
||||
like `{"dc1":{"level":"dc"},"host1":{"parent":"dc1"},...}`.
|
||||
|
||||
## raw_placement
|
||||
|
||||
- Type: string
|
||||
|
||||
Raw PG placement rules, specified in the form of a DSL (domain-specific language).
|
||||
Use only if you really know what you're doing :)
|
||||
|
||||
DSL specification:
|
||||
|
||||
```
|
||||
dsl := item | item ("\n" | ",") items
|
||||
item := "any" | rules
|
||||
rules := rule | rule rules
|
||||
rule := level operator arg
|
||||
level := /\w+/
|
||||
operator := "!=" | "=" | ">" | "?="
|
||||
arg := value | "(" values ")"
|
||||
values := value | value "," values
|
||||
value := item_ref | constant_id
|
||||
item_ref := /\d+/
|
||||
constant_id := /"([^"]+)"/
|
||||
```
|
||||
|
||||
"?=" operator means "preferred". I.e. `dc ?= "meow"` means "prefer datacenter meow
|
||||
for this chunk, but put into another dc if it's unavailable".
|
||||
|
||||
Examples:
|
||||
|
||||
- Simple 3 replicas with failure_domain=host: `any, host!=1, host!=(1,2)`
|
||||
- EC 4+2 in 3 DC: `any, dc=1 host!=1, dc!=1, dc=3 host!=3, dc!=(1,3), dc=5 host!=5`
|
||||
- 1 replica in fixed DC + 2 in random DCs: `dc?=meow, dc!=1, dc!=(1,2)`
|
||||
|
||||
## max_osd_combinations
|
||||
|
||||
- Type: integer
|
||||
|
|
@ -297,42 +183,6 @@ number of combinations to generate when optimising PG placement.
|
|||
|
||||
This parameter usually doesn't require to be changed.
|
||||
|
||||
## block_size
|
||||
|
||||
- Type: integer
|
||||
- Default: 131072
|
||||
|
||||
Block size for this pool. The value from /vitastor/config/global is used when
|
||||
unspecified. Only OSDs with matching block_size are used for each pool. If you
|
||||
want to further restrict OSDs for the pool, use [osd_tags](#osd_tags).
|
||||
|
||||
Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-cluster.en.md#block_size).
|
||||
|
||||
## bitmap_granularity
|
||||
|
||||
- Type: integer
|
||||
- Default: 4096
|
||||
|
||||
"Sector" size of virtual disks in this pool. The value from /vitastor/config/global
|
||||
is used when unspecified. Similarly to block_size, only OSDs with matching
|
||||
bitmap_granularity are used for each pool.
|
||||
|
||||
Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-cluster.en.md#bitmap_granularity).
|
||||
|
||||
## immediate_commit
|
||||
|
||||
- Type: string, one of "all", "small" and "none"
|
||||
- Default: none
|
||||
|
||||
Immediate commit setting for this pool. The value from /vitastor/config/global
|
||||
is used when unspecified. Similarly to block_size, only OSDs with compatible
|
||||
bitmap_granularity are used for each pool. "Compatible" means that a pool with
|
||||
non-immediate commit will use OSDs with immediate commit enabled, but not vice
|
||||
versa. I.e., pools with "none" use all OSDs, pools with "small" only use OSDs
|
||||
with "all" or "small", and pools with "all" only use OSDs with "all".
|
||||
|
||||
Read more about this parameter in [Cluster-Wide Disk Layout Parameters](layout-cluster.en.md#immediate_commit).
|
||||
|
||||
## pg_stripe_size
|
||||
|
||||
- Type: integer
|
||||
|
|
@ -370,32 +220,6 @@ Specifies OSD tags to prefer putting primary OSDs in this pool to.
|
|||
Note that for EC/XOR pools Vitastor always prefers to put primary OSD on one
|
||||
of the OSDs containing a data chunk for a PG.
|
||||
|
||||
## scrub_interval
|
||||
|
||||
- Type: time interval (number + unit s/m/h/d/M/y)
|
||||
|
||||
Automatic scrubbing interval for this pool. Overrides
|
||||
[global scrub_interval setting](osd.en.md#scrub_interval).
|
||||
|
||||
## used_for_fs
|
||||
|
||||
- Type: string
|
||||
|
||||
If non-empty, the pool is marked as used for VitastorFS with metadata stored
|
||||
in block image (regular Vitastor volume) named as the value of this pool parameter.
|
||||
|
||||
When a pool is marked as used for VitastorFS, regular block volume creation in it
|
||||
is disabled (vitastor-cli refuses to create images without --force) to protect
|
||||
the user from block volume and FS file ID collisions and data loss.
|
||||
|
||||
[vitastor-nfs](../usage/nfs.ru.md), in its turn, refuses to use pools not marked
|
||||
for the corresponding FS when starting. This also implies that you can use one
|
||||
pool only for one VitastorFS.
|
||||
|
||||
The second thing that is disabled for VitastorFS pools is reporting per-inode space
|
||||
usage statistics in etcd because a FS pool may store a very large number of files
|
||||
and statistics for them all would take a lot of space in etcd.
|
||||
|
||||
# Examples
|
||||
|
||||
## Replicated pool
|
||||
|
|
@ -419,7 +243,7 @@ and statistics for them all would take a lot of space in etcd.
|
|||
{
|
||||
"2": {
|
||||
"name":"ecpool",
|
||||
"scheme":"ec",
|
||||
"scheme":"jerasure",
|
||||
"pg_size":3,
|
||||
"parity_chunks":1,
|
||||
"pg_minsize":2,
|
||||
|
|
|
|||
|
|
@ -31,18 +31,11 @@
|
|||
- [pg_minsize](#pg_minsize)
|
||||
- [pg_count](#pg_count)
|
||||
- [failure_domain](#failure_domain)
|
||||
- [level_placement](#level_placement)
|
||||
- [raw_placement](#raw_placement)
|
||||
- [max_osd_combinations](#max_osd_combinations)
|
||||
- [block_size](#block_size)
|
||||
- [bitmap_granularity](#bitmap_granularity)
|
||||
- [immediate_commit](#immediate_commit)
|
||||
- [pg_stripe_size](#pg_stripe_size)
|
||||
- [root_node](#root_node)
|
||||
- [osd_tags](#osd_tags)
|
||||
- [primary_affinity_tags](#primary_affinity_tags)
|
||||
- [scrub_interval](#scrub_interval)
|
||||
- [used_for_fs](#used_for_fs)
|
||||
|
||||
Примеры:
|
||||
|
||||
|
|
@ -54,7 +47,7 @@
|
|||
Дерево размещения OSD задаётся в отдельном ключе etcd `/vitastor/config/node_placement`
|
||||
в следующем JSON-формате:
|
||||
|
||||
```
|
||||
`
|
||||
{
|
||||
"<имя узла или номер OSD>": {
|
||||
"level": "<уровень>",
|
||||
|
|
@ -62,7 +55,7 @@
|
|||
},
|
||||
...
|
||||
}
|
||||
```
|
||||
`
|
||||
|
||||
Здесь, если название узла - число, считается, что это OSD. Уровень OSD
|
||||
всегда равен "osd" и не может быть переопределён. Для OSD вы можете только
|
||||
|
|
@ -85,11 +78,7 @@
|
|||
Настройки отдельных OSD задаются в ключах etcd `/vitastor/config/osd/<number>`
|
||||
в JSON-формате `{"<key>":<value>}`.
|
||||
|
||||
На данный момент поддерживаются следующие настройки:
|
||||
|
||||
- [reweight](#reweight)
|
||||
- [tags](#tags)
|
||||
- [noout](#noout)
|
||||
На данный момент поддерживается одна настройка:
|
||||
|
||||
## reweight
|
||||
|
||||
|
|
@ -104,23 +93,6 @@
|
|||
хранении данных вообще. Вы можете установить reweight в 0, чтобы убрать
|
||||
все данные с OSD.
|
||||
|
||||
## tags
|
||||
|
||||
- Тип: строка или массив строк
|
||||
|
||||
Задаёт тег или набор тегов для данного OSD. Теги можно использовать, чтобы
|
||||
делить OSD на множества и потом размещать пул только на части OSD, а не на
|
||||
всех. Можно, например, пометить SSD OSD тегом "ssd", а HDD тегом "hdd", в
|
||||
этом смысле теги работают аналогично классам устройств.
|
||||
|
||||
## noout
|
||||
|
||||
- Тип: булево (да/нет)
|
||||
- Значение по умолчанию: false
|
||||
|
||||
Если установлено в true, то [osd_out_time](monitor.ru.md#osd_out_time) для этого
|
||||
OSD игнорируется и OSD не удаляется из распределения данных монитором.
|
||||
|
||||
# Параметры
|
||||
|
||||
## name
|
||||
|
|
@ -134,13 +106,9 @@ OSD игнорируется и OSD не удаляется из распред
|
|||
|
||||
- Тип: строка
|
||||
- Обязательный
|
||||
- Возможные значения: "replicated", "xor", "ec" или "jerasure"
|
||||
- Возможные значения: "replicated", "xor" или "jerasure"
|
||||
|
||||
Схема избыточности, используемая в данном пуле. "jerasure" - синоним для "ec",
|
||||
в обеих схемах используются коды Рида-Соломона-Вандермонда, реализованные на
|
||||
основе библиотек ISA-L или jerasure. Быстрая реализация на основе ISA-L
|
||||
используется автоматически, когда доступна, в противном случае используется
|
||||
более медленная jerasure-версия.
|
||||
Схема избыточности, используемая в данном пуле.
|
||||
|
||||
## pg_size
|
||||
|
||||
|
|
@ -169,26 +137,6 @@ OSD игнорируется и OSD не удаляется из распред
|
|||
OSD, PG деактивируется на чтение и запись. Иными словами, всегда известно,
|
||||
что новые блоки данных всегда записываются как минимум на pg_minsize дисков.
|
||||
|
||||
Для примера, разница между pg_minsize 2 и 1 в реплицированном пуле с 3 копиями
|
||||
данных (pg_size=3), проявляется следующим образом:
|
||||
- Если 2 сервера отключаются при pg_minsize=2, пул становится неактивным и
|
||||
остаётся неактивным в течение [osd_out_time](monitor.ru.md#osd_out_time)
|
||||
(10 минут), после чего монитор назначает другие OSD/серверы на замену, пул
|
||||
поднимается и начинает восстанавливать недостающие копии данных. Соответственно,
|
||||
если OSD на замену нет - то есть, если у вас всего 3 сервера с OSD и 2 из них
|
||||
недоступны - пул так и остаётся недоступным до тех пор, пока вы не вернёте
|
||||
или не добавите хотя бы 1 сервер (или не переключите failure_domain на "osd").
|
||||
- Если 2 сервера отключаются при pg_minsize=1, ввод-вывод лишь приостанавливается
|
||||
на короткое время, до тех пор, пока монитор не поймёт, что OSD отключены
|
||||
(что занимает 5-10 секунд при стандартном [etcd_report_interval](osd.ru.md#etcd_report_interval)).
|
||||
После этого ввод-вывод восстанавливается, но новые данные временно пишутся
|
||||
всего в 1 копии. Когда же проходит osd_out_time, монитор точно так же назначает
|
||||
другие OSD на замену выбывшим и пул начинает восстанавливать копии данных.
|
||||
|
||||
То есть, pg_minsize регулирует число отказов, которые пул может пережить без
|
||||
временной остановки обслуживания на [osd_out_time](monitor.ru.md#osd_out_time),
|
||||
но ценой немного пониженных гарантий надёжности.
|
||||
|
||||
FIXME: Поведение pg_minsize может быть изменено в будущем с полной деактивации
|
||||
PG на перевод их в режим только для чтения.
|
||||
|
||||
|
|
@ -200,8 +148,8 @@ PG на перевод их в режим только для чтения.
|
|||
Число PG для данного пула. Число должно быть достаточно большим, чтобы монитор
|
||||
мог равномерно распределить по ним данные.
|
||||
|
||||
Обычно это означает примерно 10-100 PG на 1 OSD, т.е. pg_count можно устанавливать
|
||||
равным (общему числу OSD * 10 / pg_size). Значение можно округлить до ближайшей
|
||||
Обычно это означает примерно 64-128 PG на 1 OSD, т.е. pg_count можно устанавливать
|
||||
равным (общему числу OSD * 100 / pg_size). Значение можно округлить до ближайшей
|
||||
степени 2, чтобы потом было легче уменьшать или увеличивать число PG, умножая
|
||||
или деля его на 2.
|
||||
|
||||
|
|
@ -222,71 +170,6 @@ PG в Vitastor эферемерны, то есть вы можете менят
|
|||
Иными словами, домен отказа - это то, от отказа чего вы защищаете себя избыточным
|
||||
хранением.
|
||||
|
||||
## level_placement
|
||||
|
||||
- Тип: строка
|
||||
|
||||
Правила дополнительных доменов отказа, применяемые вместе с failure_domain.
|
||||
Должны задаваться в следующем виде:
|
||||
|
||||
`<уровень>=<последовательность символов>, <уровень2>=<последовательность2>, ...`
|
||||
|
||||
Каждая `<последовательность>` должна состоять ровно из [pg_size](#pg_size) символов.
|
||||
Каждый символ соответствует одному OSD (размещению одной части PG) этого пула.
|
||||
Одинаковые символы означают, что соответствующие части размещаются в один и тот же
|
||||
узел дерева OSD на заданном `<уровне>`. Разные символы означают, что части
|
||||
размещаются в разные узлы.
|
||||
|
||||
Например, если вы хотите сделать пул EC 4+2 и хотите поместить каждые 2 части
|
||||
данных в свой датацентр, и также вы хотите, чтобы каждая часть размещалась на
|
||||
другом хосте, то вы должны задать `level_placement` равным `dc=112233 host=123456`.
|
||||
|
||||
Либо вы просто можете задать `level_placement` равным `dc=112233` и оставить
|
||||
`failure_domain` пустым, т.к. `host` это его значение по умолчанию и оно также
|
||||
применится автоматически.
|
||||
|
||||
Без этого правила может получиться так, что в одном из датацентров окажется
|
||||
3 части данных одной PG и данные окажутся недоступными при временном отключении
|
||||
этого датацентра.
|
||||
|
||||
Естественно, перед установкой правила вам нужно сгруппировать ваши хосты в
|
||||
датацентры, установив [placement_levels](monitor.ru.md#placement_levels) во что-то
|
||||
типа `{"dc":90,"host":100,"osd":110}` и добавив датацентры в [node_placement](#дерево-размещения),
|
||||
примерно так: `{"dc1":{"level":"dc"},"host1":{"parent":"dc1"},...}`.
|
||||
|
||||
## raw_placement
|
||||
|
||||
- Type: string
|
||||
|
||||
Низкоуровневые правила генерации PG в форме DSL (доменно-специфичного языка).
|
||||
Используйте, только если действительно знаете, зачем вам это надо :)
|
||||
|
||||
Спецификация DSL:
|
||||
|
||||
```
|
||||
dsl := item | item ("\n" | ",") items
|
||||
item := "any" | rules
|
||||
rules := rule | rule rules
|
||||
rule := level operator arg
|
||||
level := /\w+/
|
||||
operator := "!=" | "=" | ">" | "?="
|
||||
arg := value | "(" values ")"
|
||||
values := value | value "," values
|
||||
value := item_ref | constant_id
|
||||
item_ref := /\d+/
|
||||
constant_id := /"([^"]+)"/
|
||||
```
|
||||
|
||||
Оператор "?=" означает "предпочитаемый". Т.е. `dc ?= "meow"` означает "предпочитать
|
||||
датацентр meow для этой части данных, но разместить её в другом датацентре, если
|
||||
meow недоступен".
|
||||
|
||||
Примеры:
|
||||
|
||||
- Простые 3 реплики с failure_domain=host: `any, host!=1, host!=(1,2)`
|
||||
- EC 4+2 в 3 датацентрах: `any, dc=1 host!=1, dc!=1, dc=3 host!=3, dc!=(1,3), dc=5 host!=5`
|
||||
- 1 копия в фиксированном ДЦ + 2 в других ДЦ: `dc?=meow, dc!=1, dc!=(1,2)`
|
||||
|
||||
## max_osd_combinations
|
||||
|
||||
- Тип: целое число
|
||||
|
|
@ -298,53 +181,13 @@ meow недоступен".
|
|||
|
||||
Обычно данный параметр не требует изменений.
|
||||
|
||||
## block_size
|
||||
|
||||
- Тип: целое число
|
||||
- По умолчанию: 131072
|
||||
|
||||
Размер блока для данного пула. Если не задан, используется значение из
|
||||
/vitastor/config/global. Если в вашем кластере есть OSD с разными размерами
|
||||
блока, пул будет использовать только OSD с размером блока, равным размеру блока
|
||||
пула. Если вы хотите сильнее ограничить набор используемых для пула OSD -
|
||||
используйте [osd_tags](#osd_tags).
|
||||
|
||||
О самом параметре читайте в разделе [Дисковые параметры уровня кластера](layout-cluster.ru.md#block_size).
|
||||
|
||||
## bitmap_granularity
|
||||
|
||||
- Тип: целое число
|
||||
- По умолчанию: 4096
|
||||
|
||||
Размер "сектора" виртуальных дисков в данном пуле. Если не задан, используется
|
||||
значение из /vitastor/config/global. Аналогично block_size, каждый пул будет
|
||||
использовать только OSD с совпадающей с пулом настройкой bitmap_granularity.
|
||||
|
||||
О самом параметре читайте в разделе [Дисковые параметры уровня кластера](layout-cluster.ru.md#bitmap_granularity).
|
||||
|
||||
## immediate_commit
|
||||
|
||||
- Тип: строка "all", "small" или "none"
|
||||
- По умолчанию: none
|
||||
|
||||
Настройка мгновенного коммита для данного пула. Если не задана, используется
|
||||
значение из /vitastor/config/global. Аналогично block_size, каждый пул будет
|
||||
использовать только OSD с *совместимыми* настройками immediate_commit.
|
||||
"Совместимыми" означает, что пул с отключенным мгновенным коммитом будет
|
||||
использовать OSD с включённым мгновенным коммитом, но не наоборот. То есть,
|
||||
пул со значением "none" будет использовать все OSD, пул со "small" будет
|
||||
использовать OSD с "all" или "small", а пул с "all" будет использовать только
|
||||
OSD с "all".
|
||||
|
||||
О самом параметре читайте в разделе [Дисковые параметры уровня кластера](layout-cluster.ru.md#immediate_commit).
|
||||
|
||||
## pg_stripe_size
|
||||
|
||||
- Тип: целое число
|
||||
- По умолчанию: 0
|
||||
|
||||
Данный параметр задаёт размер полосы "нарезки" образов на PG. Размер полосы не может
|
||||
быть меньше, чем [block_size](#block_size), умноженный на
|
||||
быть меньше, чем [block_size](layout-cluster.ru.md#block_size), умноженный на
|
||||
(pg_size - parity_chunks) для EC-пулов или 1 для реплицированных пулов. То же
|
||||
значение используется по умолчанию.
|
||||
|
||||
|
|
@ -376,34 +219,6 @@ OSD с "all".
|
|||
для PG этого пула. Имейте в виду, что для EC-пулов Vitastor также всегда
|
||||
предпочитает помещать первичный OSD на один из OSD с данными, а не с чётностью.
|
||||
|
||||
## scrub_interval
|
||||
|
||||
- Тип: временной интервал (число + единица измерения s/m/h/d/M/y)
|
||||
|
||||
Интервал скраба, то есть, автоматической фоновой проверки данных для данного пула.
|
||||
Переопределяет [глобальную настройку scrub_interval](osd.ru.md#scrub_interval).
|
||||
|
||||
## used_for_fs
|
||||
|
||||
- Type: string
|
||||
|
||||
Если непусто, пул помечается как используемый для файловой системы VitastorFS с
|
||||
метаданными, хранимыми в блочном образе Vitastor с именем, равным значению
|
||||
этого параметра.
|
||||
|
||||
Когда пул помечается как используемый для VitastorFS, создание обычных блочных
|
||||
образов в нём отключается (vitastor-cli отказывается создавать образы без --force),
|
||||
чтобы защитить пользователя от коллизий ID файлов и блочных образов и, таким
|
||||
образом, от потери данных.
|
||||
|
||||
[vitastor-nfs](../usage/nfs.ru.md), в свою очередь, при запуске отказывается
|
||||
использовать для ФС пулы, не выделенные для неё. Это также означает, что один
|
||||
пул может использоваться только для одной VitastorFS.
|
||||
|
||||
Также для ФС-пулов отключается передача статистики в etcd по отдельным инодам,
|
||||
так как ФС-пул может содержать очень много файлов и статистика по ним всем
|
||||
заняла бы очень много места в etcd.
|
||||
|
||||
# Примеры
|
||||
|
||||
## Реплицированный пул
|
||||
|
|
@ -427,7 +242,7 @@ OSD с "all".
|
|||
{
|
||||
"2": {
|
||||
"name":"ecpool",
|
||||
"scheme":"ec",
|
||||
"scheme":"jerasure",
|
||||
"pg_size":3,
|
||||
"parity_chunks":1,
|
||||
"pg_minsize":2,
|
||||
|
|
|
|||
|
|
@ -1,4 +0,0 @@
|
|||
# Client Parameters
|
||||
|
||||
These parameters apply only to Vitastor clients (QEMU, fio, NBD and so on) and
|
||||
affect their interaction with the cluster.
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
# Параметры клиентского кода
|
||||
|
||||
Данные параметры применяются только к клиентам Vitastor (QEMU, fio, NBD и т.п.) и
|
||||
затрагивают логику их работы с кластером.
|
||||
|
|
@ -1,255 +0,0 @@
|
|||
- name: client_iothread_count
|
||||
type: int
|
||||
default: 0
|
||||
online: false
|
||||
info: |
|
||||
Number of separate threads for handling TCP network I/O at client library
|
||||
side. Enabling 4 threads usually allows to increase peak performance of each
|
||||
client from approx. 2-3 to 7-8 GByte/s linear read/write and from approx.
|
||||
100-150 to 400 thousand iops, but at the same time it increases latency.
|
||||
Latency increase depends on CPU: with CPU power saving disabled latency
|
||||
only increases by ~10 us (equivalent to Q=1 iops decrease from 10500 to 9500),
|
||||
with CPU power saving enabled it may be as high as 500 us (equivalent to Q=1
|
||||
iops decrease from 2000 to 1000). RDMA isn't affected by this option.
|
||||
|
||||
It's recommended to enable client I/O threads if you don't use RDMA and want
|
||||
to increase peak client performance.
|
||||
info_ru: |
|
||||
Число отдельных потоков для обработки ввода-вывода через TCP сеть на стороне
|
||||
клиентской библиотеки. Включение 4 потоков обычно позволяет поднять пиковую
|
||||
производительность каждого клиента примерно с 2-3 до 7-8 Гбайт/с линейного
|
||||
чтения/записи и примерно с 100-150 до 400 тысяч операций ввода-вывода в
|
||||
секунду, но ухудшает задержку. Увеличение задержки зависит от процессора:
|
||||
при отключённом энергосбережении CPU это всего ~10 микросекунд (равносильно
|
||||
падению iops с Q=1 с 10500 до 9500), а при включённом это может быть
|
||||
и 500 микросекунд (равносильно падению iops с Q=1 с 2000 до 1000). На работу
|
||||
RDMA данная опция не влияет.
|
||||
|
||||
Рекомендуется включать клиентские потоки ввода-вывода, если вы не используете
|
||||
RDMA и хотите повысить пиковую производительность клиентов.
|
||||
- name: client_retry_interval
|
||||
type: ms
|
||||
min: 10
|
||||
default: 50
|
||||
online: true
|
||||
info: |
|
||||
Retry time for I/O requests failed due to inactive PGs or network
|
||||
connectivity errors.
|
||||
info_ru: |
|
||||
Время повтора запросов ввода-вывода, неудачных из-за неактивных PG или
|
||||
ошибок сети.
|
||||
- name: client_eio_retry_interval
|
||||
type: ms
|
||||
default: 1000
|
||||
online: true
|
||||
info: |
|
||||
Retry time for I/O requests failed due to data corruption or unfinished
|
||||
EC object deletions (has_incomplete PG state). 0 disables such retries
|
||||
and clients are not blocked and just get EIO error code instead.
|
||||
info_ru: |
|
||||
Время повтора запросов ввода-вывода, неудачных из-за повреждения данных
|
||||
или незавершённых удалений EC-объектов (состояния PG has_incomplete).
|
||||
0 отключает повторы таких запросов и клиенты не блокируются, а вместо
|
||||
этого просто получают код ошибки EIO.
|
||||
- name: client_retry_enospc
|
||||
type: bool
|
||||
default: true
|
||||
online: true
|
||||
info: |
|
||||
Retry writes on out of space errors to wait until some space is freed on
|
||||
OSDs.
|
||||
info_ru: |
|
||||
Повторять запросы записи, завершившиеся с ошибками нехватки места, т.е.
|
||||
ожидать, пока на OSD не освободится место.
|
||||
- name: client_max_dirty_bytes
|
||||
type: int
|
||||
default: 33554432
|
||||
online: true
|
||||
info: |
|
||||
Without [immediate_commit](layout-cluster.en.md#immediate_commit)=all this parameter sets the limit of "dirty"
|
||||
(not committed by fsync) data allowed by the client before forcing an
|
||||
additional fsync and committing the data. Also note that the client always
|
||||
holds a copy of uncommitted data in memory so this setting also affects
|
||||
RAM usage of clients.
|
||||
info_ru: |
|
||||
При работе без [immediate_commit](layout-cluster.ru.md#immediate_commit)=all - это лимит объёма "грязных" (не
|
||||
зафиксированных fsync-ом) данных, при достижении которого клиент будет
|
||||
принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
|
||||
что в этом случае до момента fsync клиент хранит копию незафиксированных
|
||||
данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
|
||||
- name: client_max_dirty_ops
|
||||
type: int
|
||||
default: 1024
|
||||
online: true
|
||||
info: |
|
||||
Same as client_max_dirty_bytes, but instead of total size, limits the number
|
||||
of uncommitted write operations.
|
||||
info_ru: |
|
||||
Аналогично client_max_dirty_bytes, но ограничивает количество
|
||||
незафиксированных операций записи вместо их общего объёма.
|
||||
- name: client_enable_writeback
|
||||
type: bool
|
||||
default: false
|
||||
online: true
|
||||
info: |
|
||||
This parameter enables client-side write buffering. This means that write
|
||||
requests are accumulated in memory for a short time before being sent to
|
||||
a Vitastor cluster which allows to send them in parallel and increase
|
||||
performance of some applications. Writes are buffered until client forces
|
||||
a flush with fsync() or until the amount of buffered writes exceeds the
|
||||
limit.
|
||||
|
||||
Write buffering significantly increases performance of some applications,
|
||||
for example, CrystalDiskMark under Windows (LOL :-D), but also any other
|
||||
applications if they do writes in one of two non-optimal ways: either if
|
||||
they do a lot of small (4 kb or so) sequential writes, or if they do a lot
|
||||
of small random writes, but without any parallelism or asynchrony, and also
|
||||
without calling fsync().
|
||||
|
||||
With write buffering enabled, you can expect around 22000 T1Q1 random write
|
||||
iops in QEMU more or less regardless of the quality of your SSDs, and this
|
||||
number is in fact bound by QEMU itself rather than Vitastor (check it
|
||||
yourself by adding a "driver=null-co" disk in QEMU). Without write
|
||||
buffering, the current record is 9900 iops, but the number is usually
|
||||
even lower with non-ideal hardware, for example, it may be 5000 iops.
|
||||
|
||||
Even when this parameter is enabled, write buffering isn't enabled until
|
||||
the client explicitly allows it, because enabling it without the client
|
||||
being aware of the fact that his writes may be buffered may lead to data
|
||||
loss. Because of this, older versions of clients don't support write
|
||||
buffering at all, newer versions of the QEMU driver allow write buffering
|
||||
only if it's enabled in disk settings with `-blockdev cache.direct=false`,
|
||||
and newer versions of FIO only allow write buffering if you don't specify
|
||||
`-direct=1`. NBD and NFS drivers allow write buffering by default.
|
||||
|
||||
You can overcome this restriction too with the `client_writeback_allowed`
|
||||
parameter, but you shouldn't do that unless you **really** know what you
|
||||
are doing.
|
||||
info_ru: |
|
||||
Данный параметр разрешает включать буферизацию записи в памяти. Буферизация
|
||||
означает, что операции записи отправляются на кластер Vitastor не сразу, а
|
||||
могут небольшое время накапливаться в памяти и сбрасываться сразу пакетами,
|
||||
до тех пор, пока либо не будет превышен лимит неотправленных записей, либо
|
||||
пока клиент не вызовет fsync.
|
||||
|
||||
Буферизация значительно повышает производительность некоторых приложений,
|
||||
например, CrystalDiskMark в Windows (ха-ха :-D), но также и любых других,
|
||||
которые пишут на диск неоптимально: либо последовательно, но мелкими блоками
|
||||
(например, по 4 кб), либо случайно, но без параллелизма и без fsync - то
|
||||
есть, например, отправляя 128 операций записи в разные места диска, но не
|
||||
все сразу с помощью асинхронного I/O, а по одной.
|
||||
|
||||
В QEMU с буферизацией записи можно ожидать показателя примерно 22000
|
||||
операций случайной записи в секунду в 1 поток и с глубиной очереди 1 (T1Q1)
|
||||
без fsync, почти вне зависимости от того, насколько хороши ваши диски - эта
|
||||
цифра упирается в сам QEMU. Без буферизации рекорд пока что - 9900 операций
|
||||
в секунду, но на железе похуже может быть и поменьше, например, 5000 операций
|
||||
в секунду.
|
||||
|
||||
При этом, даже если данный параметр включён, буферизация не включается, если
|
||||
явно не разрешена клиентом, т.к. если клиент не знает, что запросы записи
|
||||
буферизуются, это может приводить к потере данных. Поэтому в старых версиях
|
||||
клиентских драйверов буферизация записи не включается вообще, в новых
|
||||
версиях QEMU-драйвера включается, только если разрешена опцией диска
|
||||
`-blockdev cache.direct=false`, а в fio - только если нет опции `-direct=1`.
|
||||
В NBD и NFS драйверах буферизация записи разрешена по умолчанию.
|
||||
|
||||
Можно обойти и это ограничение с помощью параметра `client_writeback_allowed`,
|
||||
но делать так не надо, если только вы не уверены в том, что делаете, на все
|
||||
100%. :-)
|
||||
- name: client_max_buffered_bytes
|
||||
type: int
|
||||
default: 33554432
|
||||
online: true
|
||||
info: |
|
||||
Maximum total size of buffered writes which triggers write-back when reached.
|
||||
info_ru: |
|
||||
Максимальный общий размер буферизованных записей, при достижении которого
|
||||
начинается процесс сброса данных на сервер.
|
||||
- name: client_max_buffered_ops
|
||||
type: int
|
||||
default: 1024
|
||||
online: true
|
||||
info: |
|
||||
Maximum number of buffered writes which triggers write-back when reached.
|
||||
Multiple consecutive modified data regions are counted as 1 write here.
|
||||
info_ru: |
|
||||
Максимальное количество буферизованных записей, при достижении которого
|
||||
начинается процесс сброса данных на сервер. При этом несколько
|
||||
последовательных изменённых областей здесь считаются 1 записью.
|
||||
- name: client_max_writeback_iodepth
|
||||
type: int
|
||||
default: 256
|
||||
online: true
|
||||
info: |
|
||||
Maximum number of parallel writes when flushing buffered data to the server.
|
||||
info_ru: |
|
||||
Максимальное число параллельных операций записи при сбросе буферов на сервер.
|
||||
- name: nbd_timeout
|
||||
type: sec
|
||||
default: 300
|
||||
online: false
|
||||
info: |
|
||||
Timeout for I/O operations for [NBD](../usage/nbd.en.md). If an operation
|
||||
executes for longer than this timeout, including when your cluster is just
|
||||
temporarily down for more than timeout, the NBD device will detach by itself
|
||||
(and possibly break the mounted file system).
|
||||
|
||||
You can set timeout to 0 to never detach, but in that case you won't be
|
||||
able to remove the kernel device at all if the NBD process dies - you'll have
|
||||
to reboot the host.
|
||||
info_ru: |
|
||||
Таймаут для операций чтения/записи через [NBD](../usage/nbd.ru.md). Если
|
||||
операция выполняется дольше таймаута, включая временную недоступность
|
||||
кластера на время, большее таймаута, NBD-устройство отключится само собой
|
||||
(и, возможно, сломает примонтированную ФС).
|
||||
|
||||
Вы можете установить таймаут в 0, чтобы никогда не отключать устройство по
|
||||
таймауту, но в этом случае вы вообще не сможете удалить устройство, если
|
||||
процесс NBD умрёт - вам придётся перезагружать сервер.
|
||||
- name: nbd_max_devices
|
||||
type: int
|
||||
default: 64
|
||||
online: false
|
||||
info: |
|
||||
Maximum number of NBD devices in the system. This value is passed as
|
||||
`nbds_max` parameter for the nbd kernel module when vitastor-nbd autoloads it.
|
||||
info_ru: |
|
||||
Максимальное число NBD-устройств в системе. Данное значение передаётся
|
||||
модулю ядра nbd как параметр `nbds_max`, когда его загружает vitastor-nbd.
|
||||
- name: nbd_max_part
|
||||
type: int
|
||||
default: 3
|
||||
online: false
|
||||
info: |
|
||||
Maximum number of partitions per NBD device. This value is passed as
|
||||
`max_part` parameter for the nbd kernel module when vitastor-nbd autoloads it.
|
||||
Note that (nbds_max)*(1+max_part) usually can't exceed 256.
|
||||
info_ru: |
|
||||
Максимальное число разделов на одном NBD-устройстве. Данное значение передаётся
|
||||
модулю ядра nbd как параметр `max_part`, когда его загружает vitastor-nbd.
|
||||
Имейте в виду, что (nbds_max)*(1+max_part) обычно не может превышать 256.
|
||||
- name: osd_nearfull_ratio
|
||||
type: float
|
||||
default: 0.95
|
||||
online: true
|
||||
info: |
|
||||
Ratio of used space on OSD to treat it as "almost full" in vitastor-cli status output.
|
||||
|
||||
Remember that some client writes may hang or complete with an error if even
|
||||
just one OSD becomes 100 % full!
|
||||
|
||||
However, unlike in Ceph, 100 % full Vitastor OSDs don't crash (in Ceph they're
|
||||
unable to start at all), so you'll be able to recover from "out of space" errors
|
||||
without destroying and recreating OSDs.
|
||||
info_ru: |
|
||||
Доля занятого места на OSD, начиная с которой он считается "почти заполненным" в
|
||||
выводе vitastor-cli status.
|
||||
|
||||
Помните, что часть клиентских запросов может зависнуть или завершиться с ошибкой,
|
||||
если на 100 % заполнится хотя бы 1 OSD!
|
||||
|
||||
Однако, в отличие от Ceph, заполненные на 100 % OSD Vitastor не падают (в Ceph
|
||||
заполненные на 100% OSD вообще не могут стартовать), так что вы сможете
|
||||
восстановить работу кластера после ошибок отсутствия свободного места
|
||||
без уничтожения и пересоздания OSD.
|
||||
|
|
@ -11,21 +11,13 @@
|
|||
- name: etcd_address
|
||||
type: string or array of strings
|
||||
type_ru: строка или массив строк
|
||||
online: true
|
||||
info: |
|
||||
etcd connection endpoint(s). Multiple endpoints may be delimited by "," or
|
||||
specified in a JSON array `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
|
||||
Note that https is not supported for etcd connections yet.
|
||||
|
||||
etcd connection endpoints can be changed online by updating global
|
||||
configuration in etcd itself - this allows to switch the cluster to new
|
||||
etcd addresses without downtime.
|
||||
info_ru: |
|
||||
Адрес(а) подключения к etcd. Несколько адресов могут разделяться запятой
|
||||
или указываться в виде JSON-массива `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
|
||||
|
||||
Адреса подключения к etcd можно поменять на лету, обновив конфигурацию в
|
||||
самом etcd - это позволяет переключить кластер на новые etcd без остановки.
|
||||
- name: etcd_prefix
|
||||
type: string
|
||||
default: "/vitastor"
|
||||
|
|
@ -39,6 +31,5 @@
|
|||
- name: log_level
|
||||
type: int
|
||||
default: 0
|
||||
online: true
|
||||
info: Log level. Raise if you want more verbose output.
|
||||
info_ru: Уровень логгирования. Повысьте, если хотите более подробный вывод.
|
||||
|
|
|
|||
|
|
@ -1,145 +0,0 @@
|
|||
#!/usr/bin/nodejs
|
||||
|
||||
const fsp = require('fs').promises;
|
||||
|
||||
run(process.argv).catch(console.error);
|
||||
|
||||
async function run(argv)
|
||||
{
|
||||
if (argv.length < 3)
|
||||
{
|
||||
console.log('Markdown preprocessor\nUSAGE: ./include.js file.md');
|
||||
return;
|
||||
}
|
||||
const index_file = await fsp.realpath(argv[2]);
|
||||
const re = /(\{\{[\s\S]*?\}\}|\[[^\]]+\]\([^\)]+\)|(?:^|\n)#[^\n]+)/;
|
||||
let text = await fsp.readFile(index_file, { encoding: 'utf-8' });
|
||||
text = text.split(re);
|
||||
let included = {};
|
||||
let heading = 0, heading_name = '', m;
|
||||
for (let i = 0; i < text.length; i++)
|
||||
{
|
||||
if (text[i].substr(0, 2) == '{{')
|
||||
{
|
||||
// Inclusion
|
||||
let incfile = text[i].substr(2, text[i].length-4);
|
||||
let section = null;
|
||||
let indent = heading;
|
||||
incfile = incfile.replace(/\s*\|\s*indent\s*=\s*(-?\d+)\s*$/, (m, m1) => { indent = parseInt(m1); return ''; });
|
||||
incfile = incfile.replace(/\s*#\s*([^#]+)$/, (m, m1) => { section = m1; return ''; });
|
||||
let inc_heading = section;
|
||||
incfile = rel2abs(index_file, incfile);
|
||||
let inc = await fsp.readFile(incfile, { encoding: 'utf-8' });
|
||||
inc = inc.trim().replace(/^[\s\S]+?\n#/, '#'); // remove until the first header
|
||||
inc = inc.split(re);
|
||||
const indent_str = new Array(indent+1).join('#');
|
||||
let section_start = -1, section_end = -1;
|
||||
for (let j = 0; j < inc.length; j++)
|
||||
{
|
||||
if ((m = /^(\n?)(#+\s*)([\s\S]+)$/.exec(inc[j])))
|
||||
{
|
||||
if (!inc_heading)
|
||||
{
|
||||
inc_heading = m[3].trim();
|
||||
}
|
||||
if (section)
|
||||
{
|
||||
if (m[3].trim() == section)
|
||||
section_start = j;
|
||||
else if (section_start >= 0)
|
||||
{
|
||||
section_end = j;
|
||||
break;
|
||||
}
|
||||
}
|
||||
inc[j] = m[1] + indent_str + m[2] + m[3];
|
||||
}
|
||||
else if ((m = /^(\[[^\]]+\]\()([^\)]+)(\))$/.exec(inc[j])) && !/^https?:(\/\/)|^#/.exec(m[2]))
|
||||
{
|
||||
const abs_m2 = rel2abs(incfile, m[2]);
|
||||
const rel_m = abs2rel(__filename, abs_m2);
|
||||
if (rel_m.substr(0, 9) == '../../../') // outside docs
|
||||
inc[j] = m[1] + 'https://git.yourcmc.ru/vitalif/vitastor/src/branch/master/'+rel2abs('docs/config/src/include.js', rel_m) + m[3];
|
||||
else
|
||||
inc[j] = m[1] + abs_m2 + m[3];
|
||||
}
|
||||
}
|
||||
if (section)
|
||||
{
|
||||
inc = section_start >= 0 ? inc.slice(section_start, section_end < 0 ? inc.length : section_end) : [];
|
||||
}
|
||||
if (inc.length)
|
||||
{
|
||||
if (!inc_heading)
|
||||
inc_heading = heading_name||'';
|
||||
included[incfile+(section ? '#'+section : '')] = '#'+inc_heading.toLowerCase().replace(/\P{L}+/ug, '-').replace(/^-|-$/g, '');
|
||||
inc[0] = inc[0].replace(/^\s+/, '');
|
||||
inc[inc.length-1] = inc[inc.length-1].replace(/\s+$/, '');
|
||||
}
|
||||
text.splice(i, 1, ...inc);
|
||||
i = i + inc.length - 1;
|
||||
}
|
||||
else if ((m = /^\n?(#+)\s*([\s\S]+)$/.exec(text[i])))
|
||||
{
|
||||
// Heading
|
||||
heading = m[1].length;
|
||||
heading_name = m[2].trim();
|
||||
}
|
||||
}
|
||||
for (let i = 0; i < text.length; i++)
|
||||
{
|
||||
if ((m = /^(\[[^\]]+\]\()([^\)]+)(\))$/.exec(text[i])) && !/^https?:(\/\/)|^#/.exec(m[2]))
|
||||
{
|
||||
const p = m[2].indexOf('#');
|
||||
if (included[m[2]])
|
||||
{
|
||||
text[i] = m[1]+included[m[2]]+m[3];
|
||||
}
|
||||
else if (p >= 0 && included[m[2].substr(0, p)])
|
||||
{
|
||||
text[i] = m[1]+m[2].substr(p)+m[3];
|
||||
}
|
||||
}
|
||||
}
|
||||
console.log(text.join(''));
|
||||
}
|
||||
|
||||
function rel2abs(ref, rel)
|
||||
{
|
||||
rel = [ ...ref.replace(/^(.*)\/[^\/]+$/, '$1').split(/\/+/), ...rel.split(/\/+/) ];
|
||||
return killdots(rel).join('/');
|
||||
}
|
||||
|
||||
function abs2rel(ref, abs)
|
||||
{
|
||||
ref = ref.split(/\/+/);
|
||||
abs = abs.split(/\/+/);
|
||||
while (ref.length > 1 && ref[0] == abs[0])
|
||||
{
|
||||
ref.shift();
|
||||
abs.shift();
|
||||
}
|
||||
for (let i = 1; i < ref.length; i++)
|
||||
{
|
||||
abs.unshift('..');
|
||||
}
|
||||
return killdots(abs).join('/');
|
||||
}
|
||||
|
||||
function killdots(rel)
|
||||
{
|
||||
for (let i = 0; i < rel.length; i++)
|
||||
{
|
||||
if (rel[i] == '.')
|
||||
{
|
||||
rel.splice(i, 1);
|
||||
i--;
|
||||
}
|
||||
else if (i >= 1 && rel[i] == '..' && rel[i-1] != '..')
|
||||
{
|
||||
rel.splice(i-1, 2);
|
||||
i -= 2;
|
||||
}
|
||||
}
|
||||
return rel;
|
||||
}
|
||||
|
|
@ -1,71 +0,0 @@
|
|||
# Vitastor
|
||||
|
||||
{{../../../README.md#The Idea}}
|
||||
|
||||
{{../../../README.md#Talks and presentations}}
|
||||
|
||||
{{../../intro/features.en.md}}
|
||||
|
||||
{{../../intro/quickstart.en.md}}
|
||||
|
||||
{{../../intro/architecture.en.md}}
|
||||
|
||||
## Installation
|
||||
|
||||
{{../../installation/packages.en.md}}
|
||||
|
||||
{{../../installation/proxmox.en.md}}
|
||||
|
||||
{{../../installation/openstack.en.md}}
|
||||
|
||||
{{../../installation/kubernetes.en.md}}
|
||||
|
||||
{{../../installation/source.en.md}}
|
||||
|
||||
{{../../config.en.md|indent=1}}
|
||||
|
||||
{{../../config/common.en.md|indent=2}}
|
||||
|
||||
{{../../config/network.en.md|indent=2}}
|
||||
|
||||
{{../../config/client.en.md|indent=2}}
|
||||
|
||||
{{../../config/layout-cluster.en.md|indent=2}}
|
||||
|
||||
{{../../config/layout-osd.en.md|indent=2}}
|
||||
|
||||
{{../../config/osd.en.md|indent=2}}
|
||||
|
||||
{{../../config/monitor.en.md|indent=2}}
|
||||
|
||||
{{../../config/pool.en.md|indent=2}}
|
||||
|
||||
{{../../config/inode.en.md|indent=2}}
|
||||
|
||||
## Usage
|
||||
|
||||
{{../../usage/cli.en.md}}
|
||||
|
||||
{{../../usage/disk.en.md}}
|
||||
|
||||
{{../../usage/fio.en.md}}
|
||||
|
||||
{{../../usage/nbd.en.md}}
|
||||
|
||||
{{../../usage/qemu.en.md}}
|
||||
|
||||
{{../../usage/nfs.en.md}}
|
||||
|
||||
{{../../usage/admin.en.md}}
|
||||
|
||||
## Performance
|
||||
|
||||
{{../../performance/understanding.en.md}}
|
||||
|
||||
{{../../performance/theoretical.en.md}}
|
||||
|
||||
{{../../performance/comparison1.en.md}}
|
||||
|
||||
{{../../performance/bench2.en.md}}
|
||||
|
||||
{{../../intro/author.en.md|indent=1}}
|
||||
|
|
@ -1,71 +0,0 @@
|
|||
# Vitastor
|
||||
|
||||
{{../../../README-ru.md#Идея|indent=0}}
|
||||
|
||||
{{../../../README-ru.md#Презентации и записи докладов|indent=0}}
|
||||
|
||||
{{../../intro/features.ru.md}}
|
||||
|
||||
{{../../intro/quickstart.ru.md}}
|
||||
|
||||
{{../../intro/architecture.ru.md}}
|
||||
|
||||
## Установка
|
||||
|
||||
{{../../installation/packages.ru.md}}
|
||||
|
||||
{{../../installation/proxmox.ru.md}}
|
||||
|
||||
{{../../installation/openstack.ru.md}}
|
||||
|
||||
{{../../installation/kubernetes.ru.md}}
|
||||
|
||||
{{../../installation/source.ru.md}}
|
||||
|
||||
{{../../config.ru.md|indent=1}}
|
||||
|
||||
{{../../config/common.ru.md|indent=2}}
|
||||
|
||||
{{../../config/network.ru.md|indent=2}}
|
||||
|
||||
{{../../config/client.ru.md|indent=2}}
|
||||
|
||||
{{../../config/layout-cluster.ru.md|indent=2}}
|
||||
|
||||
{{../../config/layout-osd.ru.md|indent=2}}
|
||||
|
||||
{{../../config/osd.ru.md|indent=2}}
|
||||
|
||||
{{../../config/monitor.ru.md|indent=2}}
|
||||
|
||||
{{../../config/pool.ru.md|indent=2}}
|
||||
|
||||
{{../../config/inode.ru.md|indent=2}}
|
||||
|
||||
## Использование
|
||||
|
||||
{{../../usage/cli.ru.md}}
|
||||
|
||||
{{../../usage/disk.ru.md}}
|
||||
|
||||
{{../../usage/fio.ru.md}}
|
||||
|
||||
{{../../usage/nbd.ru.md}}
|
||||
|
||||
{{../../usage/qemu.ru.md}}
|
||||
|
||||
{{../../usage/nfs.ru.md}}
|
||||
|
||||
{{../../usage/admin.ru.md}}
|
||||
|
||||
## Производительность
|
||||
|
||||
{{../../performance/understanding.ru.md}}
|
||||
|
||||
{{../../performance/theoretical.ru.md}}
|
||||
|
||||
{{../../performance/comparison1.ru.md}}
|
||||
|
||||
{{../../performance/bench2.ru.md}}
|
||||
|
||||
{{../../intro/author.ru.md|indent=1}}
|
||||
|
|
@ -2,13 +2,3 @@
|
|||
|
||||
These parameters apply to clients and OSDs, are fixed at the moment of OSD drive
|
||||
initialization and can't be changed after it without losing data.
|
||||
|
||||
OSDs with different values of these parameters (for example, SSD and SSD+HDD
|
||||
OSDs) can coexist in one Vitastor cluster within different pools. Each pool can
|
||||
only include OSDs with identical settings of these parameters.
|
||||
|
||||
These parameters, when set to a non-default value, must also be specified in
|
||||
etcd for clients to be aware of their values, either in /vitastor/config/global
|
||||
or in pool configuration. Pool configuration overrides the global setting.
|
||||
If the value for a pool in etcd doesn't match on-disk OSD configuration, the
|
||||
OSD will refuse to start PGs of that pool.
|
||||
|
|
|
|||
|
|
@ -2,13 +2,3 @@
|
|||
|
||||
Данные параметры используются клиентами и OSD, задаются в момент инициализации
|
||||
диска OSD и не могут быть изменены после этого без потери данных.
|
||||
|
||||
OSD с разными значениями данных параметров (например, SSD и гибридные SSD+HDD
|
||||
OSD) могут сосуществовать в одном кластере Vitastor в разных пулах. Один пул
|
||||
может включать только OSD с одинаковыми настройками этих параметров.
|
||||
|
||||
Данные параметры, отличаясь от значения по умолчанию, должны также быть заданы
|
||||
в etcd, чтобы клиенты могли узнать их значение, либо в глобальной конфигурации
|
||||
/vitastor/config/global, либо в настройках пулов. Настройки пула переопределяют
|
||||
глобальное значение. Если значение в настройках пула не будет соответствовать
|
||||
конфигурации OSD, OSD откажется запускать PG данного пула.
|
||||
|
|
|
|||
|
|
@ -2,32 +2,49 @@
|
|||
type: int
|
||||
default: 131072
|
||||
info: |
|
||||
Size of objects (data blocks) into which all physical and virtual drives
|
||||
(within a pool) are subdivided in Vitastor. One of current main settings
|
||||
in Vitastor, affects memory usage, write amplification and I/O load
|
||||
distribution effectiveness.
|
||||
Size of objects (data blocks) into which all physical and virtual drives are
|
||||
subdivided in Vitastor. One of current main settings in Vitastor, affects
|
||||
memory usage, write amplification and I/O load distribution effectiveness.
|
||||
|
||||
Recommended default block size is 128 KB for SSD and 1 MB for HDD. In fact,
|
||||
it's possible to use 1 MB for SSD too - it will lower memory usage, but
|
||||
Recommended default block size is 128 KB for SSD and 4 MB for HDD. In fact,
|
||||
it's possible to use 4 MB for SSD too - it will lower memory usage, but
|
||||
may increase average WA and reduce linear performance.
|
||||
|
||||
OSDs with different block sizes (for example, SSD and SSD+HDD OSDs) can
|
||||
currently coexist in one etcd instance only within separate Vitastor
|
||||
clusters with different etcd_prefix'es.
|
||||
|
||||
Also block size can't be changed after OSD initialization without losing
|
||||
data.
|
||||
|
||||
You must always specify block_size in etcd in /vitastor/config/global if
|
||||
you change it so all clients can know about it.
|
||||
|
||||
OSD memory usage is roughly (SIZE / BLOCK * 68 bytes) which is roughly
|
||||
544 MB per 1 TB of used disk space with the default 128 KB block size.
|
||||
With 1 MB it's 8 times lower.
|
||||
info_ru: |
|
||||
Размер объектов (блоков данных), на которые делятся физические и виртуальные
|
||||
диски в Vitastor (в рамках каждого пула). Одна из ключевых на данный момент
|
||||
настроек, влияет на потребление памяти, объём избыточной записи (write
|
||||
amplification) и эффективность распределения нагрузки по OSD.
|
||||
диски в Vitastor. Одна из ключевых на данный момент настроек, влияет на
|
||||
потребление памяти, объём избыточной записи (write amplification) и
|
||||
эффективность распределения нагрузки по OSD.
|
||||
|
||||
Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 1 мегабайт
|
||||
для HDD. В принципе, для SSD можно тоже использовать блок размером 1 мегабайт,
|
||||
Рекомендуемые по умолчанию размеры блока - 128 килобайт для SSD и 4
|
||||
мегабайта для HDD. В принципе, для SSD можно тоже использовать 4 мегабайта,
|
||||
это понизит использование памяти, но ухудшит распределение нагрузки и в
|
||||
среднем увеличит WA.
|
||||
|
||||
OSD с разными размерами блока (например, SSD и SSD+HDD OSD) на данный
|
||||
момент могут сосуществовать в рамках одного etcd только в виде двух независимых
|
||||
кластеров Vitastor с разными etcd_prefix.
|
||||
|
||||
Также размер блока нельзя менять после инициализации OSD без потери данных.
|
||||
|
||||
Если вы меняете размер блока, обязательно прописывайте его в etcd в
|
||||
/vitastor/config/global, дабы все клиенты его знали.
|
||||
|
||||
Потребление памяти OSD составляет примерно (РАЗМЕР / БЛОК * 68 байт),
|
||||
т.е. примерно 544 МБ памяти на 1 ТБ занятого места на диске при
|
||||
стандартном 128 КБ блоке. При 1 МБ блоке памяти нужно в 8 раз меньше.
|
||||
стандартном 128 КБ блоке.
|
||||
- name: bitmap_granularity
|
||||
type: int
|
||||
default: 4096
|
||||
|
|
@ -37,34 +54,35 @@
|
|||
an allocation bitmap for each object containing 2 bits per each
|
||||
(bitmap_granularity) bytes.
|
||||
|
||||
Can't be smaller than the OSD data device sector.
|
||||
This parameter can't be changed after OSD initialization without losing
|
||||
data. Also it's fixed for the whole Vitastor cluster i.e. two different
|
||||
values can't be used in a single Vitastor cluster.
|
||||
|
||||
Clients MUST be aware of this parameter value, so put it into etcd key
|
||||
/vitastor/config/global if you change it for any reason.
|
||||
info_ru: |
|
||||
Требуемое выравнивание записи на виртуальные диски (размер их "сектора").
|
||||
Должен быть кратен disk_alignment. Называется гранулярностью битовой карты
|
||||
потому, что Vitastor хранит битовую карту для каждого объекта, содержащую
|
||||
по 2 бита на каждые (bitmap_granularity) байт.
|
||||
|
||||
Не может быть меньше размера сектора дисков данных OSD.
|
||||
Данный параметр нельзя менять после инициализации OSD без потери данных.
|
||||
Также он фиксирован для всего кластера Vitastor, т.е. разные значения
|
||||
не могут сосуществовать в одном кластере.
|
||||
|
||||
Клиенты ДОЛЖНЫ знать правильное значение этого параметра, так что если вы
|
||||
его меняете, обязательно прописывайте изменённое значение в etcd в ключ
|
||||
/vitastor/config/global.
|
||||
- name: immediate_commit
|
||||
type: string
|
||||
default: all
|
||||
default: false
|
||||
info: |
|
||||
One of "none", "all" or "small". Global value, may be overriden [at pool level](pool.en.md#immediate_commit).
|
||||
|
||||
This parameter is also really important for performance.
|
||||
|
||||
TLDR: default "all" is optimal for server-grade SSDs with supercapacitor-based
|
||||
power loss protection (nonvolatile write-through cache) and also for most HDDs.
|
||||
"none" or "small" should be only selected if you use desktop SSDs without
|
||||
capacitors or drives with slow write-back cache that can't be disabled. Check
|
||||
immediate_commit of your OSDs in [ls-osd](../usage/cli.en.md#ls-osd).
|
||||
|
||||
Detailed explanation:
|
||||
Another parameter which is really important for performance.
|
||||
|
||||
Desktop SSDs are very fast (100000+ iops) for simple random writes
|
||||
without cache flush. However, they are really slow (only around 1000 iops)
|
||||
if you try to fsync() each write, that is, if you want to guarantee that
|
||||
each change gets actually persisted to the physical media.
|
||||
if you try to fsync() each write, that is, when you want to guarantee that
|
||||
each change gets immediately persisted to the physical media.
|
||||
|
||||
Server-grade SSDs with "Advanced/Enhanced Power Loss Protection" or with
|
||||
"Supercapacitor-based Power Loss Protection", on the other hand, are equally
|
||||
|
|
@ -76,8 +94,8 @@
|
|||
efficiently utilize desktop SSDs by postponing fsync until the client calls
|
||||
it explicitly.
|
||||
|
||||
This is what this parameter regulates. When it's set to "all" Vitastor
|
||||
cluster commits each change to disks immediately and clients just
|
||||
This is what this parameter regulates. When it's set to "all" the whole
|
||||
Vitastor cluster commits each change to disks immediately and clients just
|
||||
ignore fsyncs because they know for sure that they're unneeded. This reduces
|
||||
the amount of network roundtrips performed by clients and improves
|
||||
performance. So it's always better to use server grade SSDs with
|
||||
|
|
@ -96,23 +114,18 @@
|
|||
SSD cache or "media-cache" - for example, a lot of Seagate EXOS drives have
|
||||
it (they have internal SSD cache even though it's not stated in datasheets).
|
||||
|
||||
Setting this parameter to "all" or "small" in OSD parameters requires enabling
|
||||
[disable_journal_fsync](layout-osd.en.md#disable_journal_fsync) and
|
||||
[disable_meta_fsync](layout-osd.en.md#disable_meta_fsync), setting it to
|
||||
"all" also requires enabling [disable_data_fsync](layout-osd.en.md#disable_data_fsync).
|
||||
vitastor-disk tried to do that by default, first checking/disabling drive cache.
|
||||
If it can't disable drive cache, OSD get initialized with "none".
|
||||
This parameter must be set both in etcd in /vitastor/config/global and in
|
||||
OSD command line or configuration. Setting it to "all" or "small" requires
|
||||
enabling disable_journal_fsync and disable_meta_fsync, setting it to "all"
|
||||
also requires enabling disable_data_fsync.
|
||||
|
||||
TLDR: For optimal performance, set immediate_commit to "all" if you only use
|
||||
SSDs with supercapacitor-based power loss protection (nonvolatile
|
||||
write-through cache) for both data and journals in the whole Vitastor
|
||||
cluster. Set it to "small" if you only use such SSDs for journals. Leave
|
||||
empty if your drives have write-back cache.
|
||||
info_ru: |
|
||||
Одно из значений "none", "small" или "all". Глобальное значение, может быть
|
||||
переопределено [на уровне пула](pool.ru.md#immediate_commit).
|
||||
|
||||
Данный параметр тоже важен для производительности.
|
||||
|
||||
Вкратце: значение по умолчанию "all" оптимально для всех серверных SSD с
|
||||
суперконденсаторами и также для большинства HDD. "none" и "small" имеет смысл
|
||||
устанавливать только при использовании SSD настольного класса без
|
||||
суперконденсаторов или дисков с медленным неотключаемым кэшем записи.
|
||||
Проверьте настройку immediate_commit своих OSD в выводе команды [ls-osd](../usage/cli.ru.md#ls-osd).
|
||||
Ещё один важный для производительности параметр.
|
||||
|
||||
Модели SSD для настольных компьютеров очень быстрые (100000+ операций в
|
||||
секунду) при простой случайной записи без сбросов кэша. Однако они очень
|
||||
|
|
@ -133,7 +146,7 @@
|
|||
эффективно утилизировать настольные SSD.
|
||||
|
||||
Данный параметр влияет как раз на это. Когда он установлен в значение "all",
|
||||
кластер Vitastor мгновенно фиксирует каждое изменение на физические
|
||||
весь кластер Vitastor мгновенно фиксирует каждое изменение на физические
|
||||
носители и клиенты могут просто игнорировать запросы fsync, т.к. они точно
|
||||
знают, что fsync-и не нужны. Это уменьшает число необходимых обращений к OSD
|
||||
по сети и улучшает производительность. Поэтому даже с Vitastor лучше всегда
|
||||
|
|
@ -155,7 +168,33 @@
|
|||
многих дисках Seagate EXOS (у них есть внутренний SSD-кэш, хотя это и не
|
||||
указано в спецификациях).
|
||||
|
||||
Указание "all" или "small" в настройках / командной строке OSD требует
|
||||
включения [disable_journal_fsync](layout-osd.ru.md#disable_journal_fsync) и
|
||||
[disable_meta_fsync](layout-osd.ru.md#disable_meta_fsync), значение "all"
|
||||
также требует включения [disable_data_fsync](layout-osd.ru.md#disable_data_fsync).
|
||||
Данный параметр нужно указывать и в etcd в /vitastor/config/global, и в
|
||||
командной строке или конфигурации OSD. Значения "all" и "small" требуют
|
||||
включения disable_journal_fsync и disable_meta_fsync, значение "all" также
|
||||
требует включения disable_data_fsync.
|
||||
|
||||
Итого, вкратце: для оптимальной производительности установите
|
||||
immediate_commit в значение "all", если вы используете в кластере только SSD
|
||||
с суперконденсаторами и для данных, и для журналов. Если вы используете
|
||||
такие SSD для всех журналов, но не для данных - можете установить параметр
|
||||
в "small". Если и какие-то из дисков журналов имеют волатильный кэш записи -
|
||||
оставьте параметр пустым.
|
||||
- name: client_dirty_limit
|
||||
type: int
|
||||
default: 33554432
|
||||
info: |
|
||||
Without immediate_commit=all this parameter sets the limit of "dirty"
|
||||
(not committed by fsync) data allowed by the client before forcing an
|
||||
additional fsync and committing the data. Also note that the client always
|
||||
holds a copy of uncommitted data in memory so this setting also affects
|
||||
RAM usage of clients.
|
||||
|
||||
This parameter doesn't affect OSDs themselves.
|
||||
info_ru: |
|
||||
При работе без immediate_commit=all - это лимит объёма "грязных" (не
|
||||
зафиксированных fsync-ом) данных, при достижении которого клиент будет
|
||||
принудительно вызывать fsync и фиксировать данные. Также стоит иметь в виду,
|
||||
что в этом случае до момента fsync клиент хранит копию незафиксированных
|
||||
данных в памяти, то есть, настройка влияет на потребление памяти клиентами.
|
||||
|
||||
Параметр не влияет на сами OSD.
|
||||
|
|
|
|||
|
|
@ -110,22 +110,20 @@
|
|||
type: bool
|
||||
default: false
|
||||
info: |
|
||||
Do not issue fsyncs to the data device, i.e. do not force it to flush cache.
|
||||
Safe ONLY if your data device has write-through cache or if write-back
|
||||
cache is disabled. If you disable drive cache manually with `hdparm` or
|
||||
writing to `/sys/.../scsi_disk/cache_type` then make sure that you do it
|
||||
every time before starting Vitastor OSD (vitastor-disk does it automatically).
|
||||
See also [immediate_commit](layout-cluster.en.md#immediate_commit)
|
||||
for information about how to benefit from disabled cache.
|
||||
Do not issue fsyncs to the data device, i.e. do not flush its cache.
|
||||
Safe ONLY if your data device has write-through cache. If you disable
|
||||
the cache yourself using `hdparm` or `scsi_disk/cache_type` then make sure
|
||||
that the cache disable command is run every time before starting Vitastor
|
||||
OSD, for example, in the systemd unit. See also `immediate_commit` option
|
||||
for the instructions to disable cache and how to benefit from it.
|
||||
info_ru: |
|
||||
Не отправлять fsync-и устройству данных, т.е. не заставлять его сбрасывать кэш.
|
||||
Не отправлять fsync-и устройству данных, т.е. не сбрасывать его кэш.
|
||||
Безопасно, ТОЛЬКО если ваше устройство данных имеет кэш со сквозной
|
||||
записью (write-through) или если кэш с отложенной записью (write-back) отключён.
|
||||
Если вы отключаете кэш вручную через `hdparm` или запись в `/sys/.../scsi_disk/cache_type`,
|
||||
то удостоверьтесь, что вы делаете это каждый раз перед запуском Vitastor OSD
|
||||
(vitastor-disk делает это автоматически). Смотрите также опцию
|
||||
[immediate_commit](layout-cluster.ru.md#immediate_commit) для информации о том,
|
||||
как извлечь выгоду из отключённого кэша.
|
||||
записью (write-through). Если вы отключаете кэш через `hdparm` или
|
||||
`scsi_disk/cache_type`, то удостоверьтесь, что команда отключения кэша
|
||||
выполняется перед каждым запуском Vitastor OSD, например, в systemd unit-е.
|
||||
Смотрите также опцию `immediate_commit` для инструкций по отключению кэша
|
||||
и о том, как из этого извлечь выгоду.
|
||||
- name: disable_meta_fsync
|
||||
type: bool
|
||||
default: false
|
||||
|
|
@ -181,7 +179,8 @@
|
|||
|
||||
Because of this it can actually be beneficial to use SSDs which work well
|
||||
with 512 byte sectors and use 512 byte disk_alignment, journal_block_size
|
||||
and meta_block_size. But at the moment, no such SSDs are known...
|
||||
and meta_block_size. But the only SSD that may fit into this category is
|
||||
Intel Optane (probably, not tested yet).
|
||||
|
||||
Clients don't need to be aware of disk_alignment, so it's not required to
|
||||
put a modified value into etcd key /vitastor/config/global.
|
||||
|
|
@ -199,78 +198,9 @@
|
|||
|
||||
Поэтому, на самом деле, может быть выгодно найти SSD, хорошо работающие с
|
||||
меньшими, 512-байтными, блоками и использовать 512-байтные disk_alignment,
|
||||
journal_block_size и meta_block_size. Однако на данный момент такие SSD
|
||||
не известны...
|
||||
journal_block_size и meta_block_size. Однако единственные SSD, которые
|
||||
теоретически могут попасть в эту категорию - это Intel Optane (но и это
|
||||
пока не проверялось автором).
|
||||
|
||||
Клиентам не обязательно знать про disk_alignment, так что помещать значение
|
||||
этого параметра в etcd в /vitastor/config/global не нужно.
|
||||
- name: data_csum_type
|
||||
type: string
|
||||
default: none
|
||||
info: |
|
||||
Data checksum type to use. May be "crc32c" or "none". Set to "crc32c" to
|
||||
enable data checksums.
|
||||
info_ru: |
|
||||
Тип используемых OSD контрольных сумм данных. Может быть "crc32c" или "none".
|
||||
Установите в "crc32c", чтобы включить расчёт и проверку контрольных сумм данных.
|
||||
|
||||
Следует понимать, что контрольные суммы в зависимости от размера блока их
|
||||
расчёта либо увеличивают потребление памяти, либо снижают производительность.
|
||||
Подробнее смотрите в описании параметра [csum_block_size](#csum_block_size).
|
||||
- name: csum_block_size
|
||||
type: int
|
||||
default: 4096
|
||||
info: |
|
||||
Checksum calculation block size.
|
||||
|
||||
Must be equal or a multiple of [bitmap_granularity](layout-cluster.en.md#bitmap_granularity)
|
||||
(which is usually 4 KB).
|
||||
|
||||
Checksums increase metadata size by 4 bytes per each csum_block_size of data.
|
||||
|
||||
Checksums are always a tradeoff:
|
||||
1. You either sacrifice +1 GB RAM per 1 TB of data
|
||||
2. Or you raise csum_block_size, for example, to 32k and sacrifice
|
||||
50% random write iops due to checksum read-modify-write
|
||||
3. Or you turn off [inmemory_metadata](osd.en.md#inmemory_metadata) and
|
||||
sacrifice 50% random read iops due to checksum reads
|
||||
|
||||
All-flash clusters usually have enough RAM to use default csum_block_size,
|
||||
which uses 1 GB RAM per 1 TB of data. HDD clusters usually don't.
|
||||
|
||||
Thus, recommended setups are:
|
||||
1. All-flash, 1 GB RAM per 1 TB data: default (csum_block_size=4k)
|
||||
2. All-flash, less RAM: csum_block_size=4k + inmemory_metadata=false
|
||||
3. Hybrid HDD+SSD: csum_block_size=4k + inmemory_metadata=false
|
||||
4. HDD-only, faster random read: csum_block_size=32k
|
||||
5. HDD-only, faster random write: csum_block_size=4k +
|
||||
inmemory_metadata=false + meta_io=cached
|
||||
|
||||
See also [meta_io](osd.en.md#meta_io).
|
||||
info_ru: |
|
||||
Размер блока расчёта контрольных сумм.
|
||||
|
||||
Должен быть равен или кратен [bitmap_granularity](layout-cluster.ru.md#bitmap_granularity)
|
||||
(который обычно равен 4 КБ).
|
||||
|
||||
Контрольные суммы увеличивают размер метаданных на 4 байта на каждые
|
||||
csum_block_size данных.
|
||||
|
||||
Контрольные суммы - это всегда компромисс:
|
||||
1. Вы либо жертвуете потреблением +1 ГБ памяти на 1 ТБ дискового пространства
|
||||
2. Либо вы повышаете csum_block_size до, скажем, 32k и жертвуете 50%
|
||||
скорости случайной записи из-за цикла чтения-изменения-записи для расчёта
|
||||
новых контрольных сумм
|
||||
3. Либо вы отключаете [inmemory_metadata](osd.ru.md#inmemory_metadata) и
|
||||
жертвуете 50% скорости случайного чтения из-за чтения контрольных сумм
|
||||
с диска
|
||||
|
||||
Таким образом, рекомендуются следующие варианты настроек:
|
||||
1. All-flash, 1 ГБ памяти на 1 ТБ данных: по умолчанию (csum_block_size=4k)
|
||||
2. All-flash, меньше памяти: csum_block_size=4k + inmemory_metadata=false
|
||||
3. Гибридные HDD+SSD: csum_block_size=4k + inmemory_metadata=false
|
||||
4. Только HDD, быстрее случайное чтение: csum_block_size=32k
|
||||
5. Только HDD, быстрее случайная запись: csum_block_size=4k +
|
||||
inmemory_metadata=false + meta_io=cached
|
||||
|
||||
Смотрите также [meta_io](osd.ru.md#meta_io).
|
||||
|
|
|
|||
|
|
@ -14,7 +14,6 @@ const L = {
|
|||
toc_config: '[Configuration](../config.en.md)',
|
||||
toc_usage: 'Usage',
|
||||
toc_performance: 'Performance',
|
||||
online: 'Can be changed online: yes',
|
||||
},
|
||||
ru: {
|
||||
Documentation: 'Документация',
|
||||
|
|
@ -29,7 +28,6 @@ const L = {
|
|||
toc_config: '[Конфигурация](../config.ru.md)',
|
||||
toc_usage: 'Использование',
|
||||
toc_performance: 'Производительность',
|
||||
online: 'Можно менять на лету: да',
|
||||
},
|
||||
};
|
||||
const types = {
|
||||
|
|
@ -38,7 +36,6 @@ const types = {
|
|||
bool: 'boolean',
|
||||
int: 'integer',
|
||||
sec: 'seconds',
|
||||
float: 'number',
|
||||
ms: 'milliseconds',
|
||||
us: 'microseconds',
|
||||
},
|
||||
|
|
@ -47,7 +44,6 @@ const types = {
|
|||
bool: 'булево (да/нет)',
|
||||
int: 'целое число',
|
||||
sec: 'секунды',
|
||||
float: 'число',
|
||||
ms: 'миллисекунды',
|
||||
us: 'микросекунды',
|
||||
},
|
||||
|
|
@ -74,8 +70,6 @@ for (const file of params_files)
|
|||
out += `- ${L[lang]['Default'] || 'Default'}: ${c.default}\n`;
|
||||
if (c.min !== undefined)
|
||||
out += `- ${L[lang]['Minimum'] || 'Minimum'}: ${c.min}\n`;
|
||||
if (c.online)
|
||||
out += `- ${L[lang]['online'] || 'Can be changed online: yes'}\n`;
|
||||
out += `\n`+(c["info_"+lang] || c["info"]).replace(/\s+$/, '');
|
||||
}
|
||||
const head = fs.readFileSync(__dirname+'/'+file+'.'+lang+'.md', { encoding: 'utf-8' });
|
||||
|
|
|
|||
|
|
@ -1,107 +1,7 @@
|
|||
- name: use_antietcd
|
||||
type: bool
|
||||
default: false
|
||||
info: |
|
||||
Enable experimental built-in etcd replacement (clustered key-value database):
|
||||
[antietcd](https://git.yourcmc.ru/vitalif/antietcd/).
|
||||
|
||||
When set to true, monitor runs internal antietcd automatically if it finds
|
||||
a network interface with an IP address matching one of addresses in the
|
||||
`etcd_address` configuration option (in `/etc/vitastor/vitastor.conf` or in
|
||||
the monitor command line). If there are multiple matching addresses, it also
|
||||
checks `antietcd_port` and antietcd is started for address with matching port.
|
||||
By default, antietcd accepts connection on the selected IP address, but it
|
||||
can also be overridden manually in the `antietcd_ip` option.
|
||||
|
||||
When antietcd is started, monitor stores cluster metadata itself and exposes
|
||||
a etcd-compatible REST API. On disk, these metadata are stored in
|
||||
`/var/lib/vitastor/mon_2379.json.gz` (can be overridden in antietcd_data_file
|
||||
or antietcd_data_dir options). All other antietcd parameters
|
||||
(see [here](https://git.yourcmc.ru/vitalif/antietcd/)) except node_id,
|
||||
cluster, cluster_key, persist_filter, stale_read can also be set in
|
||||
Vitastor configuration with `antietcd_` prefix.
|
||||
|
||||
You can dump/load data to or from antietcd using Antietcd `anticli` tool:
|
||||
|
||||
```
|
||||
npm exec anticli -e http://etcd:2379/v3 get --prefix '' --no-temp > dump.json
|
||||
npm exec anticli -e http://antietcd:2379/v3 load < dump.json
|
||||
```
|
||||
info_ru: |
|
||||
Включить экспериментальный встроенный заменитель etcd (кластерную БД ключ-значение):
|
||||
[antietcd](https://git.yourcmc.ru/vitalif/antietcd/).
|
||||
|
||||
Если параметр установлен в true, монитор запускает antietcd автоматически,
|
||||
если обнаруживает сетевой интерфейс с одним из адресов, указанных в опции
|
||||
конфигурации `etcd_address` (в `/etc/vitastor/vitastor.conf` или в опциях
|
||||
командной строки монитора). Если таких адресов несколько, также проверяется
|
||||
опция `antietcd_port` и antietcd запускается для адреса с соответствующим
|
||||
портом. По умолчанию antietcd принимает подключения по выбранному совпадающему
|
||||
IP, но его также можно определить вручную опцией `antietcd_ip`.
|
||||
|
||||
При запуске antietcd монитор сам хранит центральные метаданные кластера и
|
||||
выставляет etcd-совместимое REST API. На диске эти метаданные хранятся в файле
|
||||
`/var/lib/vitastor/mon_2379.json.gz` (можно переопределить параметрами
|
||||
antietcd_data_file или antietcd_data_dir). Все остальные параметры antietcd
|
||||
(смотрите [по ссылке](https://git.yourcmc.ru/vitalif/antietcd/)), за исключением
|
||||
node_id, cluster, cluster_key, persist_filter, stale_read также можно задавать
|
||||
в конфигурации Vitastor с префиксом `antietcd_`.
|
||||
|
||||
Вы можете выгружать/загружать данные в или из antietcd с помощью его инструмента
|
||||
`anticli`:
|
||||
|
||||
```
|
||||
npm exec anticli -e http://etcd:2379/v3 get --prefix '' --no-temp > dump.json
|
||||
npm exec anticli -e http://antietcd:2379/v3 load < dump.json
|
||||
```
|
||||
- name: enable_prometheus
|
||||
type: bool
|
||||
default: true
|
||||
info: |
|
||||
Enable built-in Prometheus metrics exporter at mon_http_port (8060 by default).
|
||||
|
||||
Note that only the active (master) monitor exposes metrics, others return
|
||||
HTTP 503. So you should add all monitor URLs to your Prometheus job configuration.
|
||||
|
||||
Grafana dashboard suitable for this exporter is here: [Vitastor-Grafana-6+.json](../../mon/scripts/Vitastor-Grafana-6+.json).
|
||||
info_ru: |
|
||||
Включить встроенный Prometheus-экспортер метрик на порту mon_http_port (по умолчанию 8060).
|
||||
|
||||
Обратите внимание, что метрики выставляет только активный (главный) монитор, остальные
|
||||
возвращают статус HTTP 503, поэтому вам следует добавлять адреса всех мониторов
|
||||
в задание по сбору метрик Prometheus.
|
||||
|
||||
Дашборд для Grafana, подходящий для этого экспортера: [Vitastor-Grafana-6+.json](../../mon/scripts/Vitastor-Grafana-6+.json).
|
||||
- name: mon_http_port
|
||||
type: int
|
||||
default: 8060
|
||||
info: HTTP port for monitors to listen on (including metrics exporter)
|
||||
info_ru: Порт, на котором мониторы принимают HTTP-соединения (в том числе для отдачи метрик)
|
||||
- name: mon_http_ip
|
||||
type: string
|
||||
info: IP address for monitors to listen on (all addresses by default)
|
||||
info_ru: IP-адрес, на котором мониторы принимают HTTP-соединения (по умолчанию все адреса)
|
||||
- name: mon_https_cert
|
||||
type: string
|
||||
info: Path to PEM SSL certificate file for monitor to listen using HTTPS
|
||||
info_ru: Путь к PEM-файлу SSL-сертификата для монитора, чтобы принимать соединения через HTTPS
|
||||
- name: mon_https_key
|
||||
type: string
|
||||
info: Path to PEM SSL private key file for monitor to listen using HTTPS
|
||||
info_ru: Путь к PEM-файлу секретного SSL-ключа для монитора, чтобы принимать соединения через HTTPS
|
||||
- name: mon_https_client_auth
|
||||
type: bool
|
||||
default: false
|
||||
info: Enable HTTPS client certificate-based authorization for monitor connections
|
||||
info_ru: Включить в HTTPS-сервере монитора авторизацию по клиентским сертификатам
|
||||
- name: mon_https_ca
|
||||
type: string
|
||||
info: Path to CA certificate for client HTTPS authorization
|
||||
info_ru: Путь к удостоверяющему сертификату для авторизации клиентских HTTPS соединений
|
||||
- name: etcd_mon_ttl
|
||||
type: sec
|
||||
min: 5
|
||||
default: 1
|
||||
min: 10
|
||||
default: 30
|
||||
info: Monitor etcd lease refresh interval in seconds
|
||||
info_ru: Интервал обновления etcd резервации (lease) монитором
|
||||
- name: etcd_mon_timeout
|
||||
|
|
@ -163,36 +63,3 @@
|
|||
"host" и "osd" являются предопределёнными и не могут быть удалены. Если
|
||||
один из них отсутствует в конфигурации, он доопределяется с приоритетом по
|
||||
умолчанию (100 для уровня "host", 101 для "osd").
|
||||
- name: use_old_pg_combinator
|
||||
type: bool
|
||||
default: false
|
||||
info: |
|
||||
Use the old PG combination generator which doesn't support [level_placement](pool.en.md#level_placement)
|
||||
and [raw_placement](pool.en.md#raw_placement) for pools which don't use this features.
|
||||
info_ru: |
|
||||
Использовать старый генератор комбинаций PG, не поддерживающий [level_placement](pool.ru.md#level_placement)
|
||||
и [raw_placement](pool.ru.md#raw_placement) для пулов, которые не используют данные функции.
|
||||
- name: osd_backfillfull_ratio
|
||||
type: float
|
||||
default: 0.99
|
||||
info: |
|
||||
Monitors try to prevent OSDs becoming 100% full during rebalance or recovery by
|
||||
calculating how much space will be occupied on every OSD after all rebalance
|
||||
and recovery operations finish, and pausing rebalance and recovery if that
|
||||
amount of space exceeds OSD capacity multiplied by the value of this
|
||||
configuration parameter.
|
||||
|
||||
Future used space is calculated by summing space used by all user data blocks
|
||||
(objects) in all PGs placed on a specific OSD, even if some of these objects
|
||||
currently reside on a different set of OSDs.
|
||||
info_ru: |
|
||||
Мониторы стараются предотвратить 100% заполнение OSD в процессе ребаланса
|
||||
или восстановления, рассчитывая, сколько места будет занято на каждом OSD после
|
||||
завершения всех операций ребаланса и восстановления, и приостанавливая
|
||||
ребаланс и восстановление, если рассчитанный объём превышает ёмкость OSD,
|
||||
умноженную на значение данного параметра.
|
||||
|
||||
Будущее занятое место рассчитывается сложением места, занятого всеми
|
||||
пользовательскими блоками данных (объектами) во всех PG, расположенных
|
||||
на конкретном OSD, даже если часть этих объектов в данный момент находится
|
||||
на другом наборе OSD.
|
||||
|
|
|
|||
|
|
@ -48,49 +48,19 @@
|
|||
type: string
|
||||
info: |
|
||||
RDMA device name to use for Vitastor OSD communications (for example,
|
||||
"rocep5s0f0"). If not specified, Vitastor will try to find an RoCE
|
||||
device matching [osd_network](osd.en.md#osd_network), preferring RoCEv2,
|
||||
or choose the first available RDMA device if no RoCE devices are
|
||||
found or if `osd_network` is not specified. Auto-selection is also
|
||||
unsupported with old libibverbs < v32, like in Debian 10 Buster or
|
||||
CentOS 7.
|
||||
|
||||
Vitastor supports all adapters, even ones without ODP support, like
|
||||
Mellanox ConnectX-3 and non-Mellanox cards. Versions up to Vitastor
|
||||
1.2.0 required ODP which is only present in Mellanox ConnectX >= 4.
|
||||
See also [rdma_odp](#rdma_odp).
|
||||
|
||||
Run `ibv_devinfo -v` as root to list available RDMA devices and their
|
||||
features.
|
||||
|
||||
Remember that you also have to configure your network switches if you use
|
||||
RoCE/RoCEv2, otherwise you may experience unstable performance. Refer to
|
||||
the manual of your network vendor for details about setting up the switch
|
||||
for RoCEv2 correctly. Usually it means setting up Lossless Ethernet with
|
||||
PFC (Priority Flow Control) and ECN (Explicit Congestion Notification).
|
||||
"rocep5s0f0"). Please note that Vitastor RDMA requires Implicit On-Demand
|
||||
Paging (Implicit ODP) and Scatter/Gather (SG) support from the RDMA device
|
||||
to work. For example, Mellanox ConnectX-3 and older adapters don't have
|
||||
Implicit ODP, so they're unsupported by Vitastor. Run `ibv_devinfo -v` as
|
||||
root to list available RDMA devices and their features.
|
||||
info_ru: |
|
||||
Название RDMA-устройства для связи с Vitastor OSD (например, "rocep5s0f0").
|
||||
Если не указано, Vitastor попробует найти RoCE-устройство, соответствующее
|
||||
[osd_network](osd.en.md#osd_network), предпочитая RoCEv2, или выбрать первое
|
||||
попавшееся RDMA-устройство, если RoCE-устройств нет или если сеть `osd_network`
|
||||
не задана. Также автовыбор не поддерживается со старыми версиями библиотеки
|
||||
libibverbs < v32, например в Debian 10 Buster или CentOS 7.
|
||||
|
||||
Vitastor поддерживает все модели адаптеров, включая те, у которых
|
||||
нет поддержки ODP, то есть вы можете использовать RDMA с ConnectX-3 и
|
||||
картами производства не Mellanox. Версии Vitastor до 1.2.0 включительно
|
||||
требовали ODP, который есть только на Mellanox ConnectX 4 и более новых.
|
||||
См. также [rdma_odp](#rdma_odp).
|
||||
|
||||
Запустите `ibv_devinfo -v` от имени суперпользователя, чтобы посмотреть
|
||||
список доступных RDMA-устройств, их параметры и возможности.
|
||||
|
||||
Обратите внимание, что если вы используете RoCE/RoCEv2, вам также необходимо
|
||||
правильно настроить для него коммутаторы, иначе вы можете столкнуться с
|
||||
нестабильной производительностью. Подробную информацию о настройке
|
||||
коммутатора для RoCEv2 ищите в документации производителя. Обычно это
|
||||
подразумевает настройку сети без потерь на основе PFC (Priority Flow
|
||||
Control) и ECN (Explicit Congestion Notification).
|
||||
Имейте в виду, что поддержка RDMA в Vitastor требует функций устройства
|
||||
Implicit On-Demand Paging (Implicit ODP) и Scatter/Gather (SG). Например,
|
||||
адаптеры Mellanox ConnectX-3 и более старые не поддерживают Implicit ODP и
|
||||
потому не поддерживаются в Vitastor. Запустите `ibv_devinfo -v` от имени
|
||||
суперпользователя, чтобы посмотреть список доступных RDMA-устройств, их
|
||||
параметры и возможности.
|
||||
- name: rdma_port_num
|
||||
type: int
|
||||
default: 1
|
||||
|
|
@ -105,29 +75,23 @@
|
|||
`ibv_devinfo -v`.
|
||||
- name: rdma_gid_index
|
||||
type: int
|
||||
default: 0
|
||||
info: |
|
||||
Global address identifier index of the RDMA device to use. Different GID
|
||||
indexes may correspond to different protocols like RoCEv1, RoCEv2 and iWARP.
|
||||
Search for "GID" in `ibv_devinfo -v` output to determine which GID index
|
||||
you need.
|
||||
|
||||
If not specified, Vitastor will try to auto-select a RoCEv2 IPv4 GID, then
|
||||
RoCEv2 IPv6 GID, then RoCEv1 IPv4 GID, then RoCEv1 IPv6 GID, then IB GID.
|
||||
GID auto-selection is unsupported with libibverbs < v32.
|
||||
|
||||
A correct rdma_gid_index for RoCEv2 is usually 1 (IPv6) or 3 (IPv4).
|
||||
**IMPORTANT:** If you want to use RoCEv2 (as recommended) then the correct
|
||||
rdma_gid_index is usually 1 (IPv6) or 3 (IPv4).
|
||||
info_ru: |
|
||||
Номер глобального идентификатора адреса RDMA-устройства, который следует
|
||||
использовать. Разным gid_index могут соответствовать разные протоколы связи:
|
||||
RoCEv1, RoCEv2, iWARP. Чтобы понять, какой нужен вам - смотрите строчки со
|
||||
словом "GID" в выводе команды `ibv_devinfo -v`.
|
||||
|
||||
Если не указан, Vitastor попробует автоматически выбрать сначала GID,
|
||||
соответствующий RoCEv2 IPv4, потом RoCEv2 IPv6, потом RoCEv1 IPv4, потом
|
||||
RoCEv1 IPv6, потом IB. Авто-выбор GID не поддерживается со старыми версиями
|
||||
libibverbs < v32.
|
||||
|
||||
Правильный rdma_gid_index для RoCEv2, как правило, 1 (IPv6) или 3 (IPv4).
|
||||
**ВАЖНО:** Если вы хотите использовать RoCEv2 (как мы и рекомендуем), то
|
||||
правильный rdma_gid_index, как правило, 1 (IPv6) или 3 (IPv4).
|
||||
- name: rdma_mtu
|
||||
type: int
|
||||
default: 4096
|
||||
|
|
@ -150,97 +114,42 @@
|
|||
так что менять этот параметр обычно не нужно.
|
||||
- name: rdma_max_msg
|
||||
type: int
|
||||
default: 132096
|
||||
default: 1048576
|
||||
info: Maximum size of a single RDMA send or receive operation in bytes.
|
||||
info_ru: Максимальный размер одной RDMA-операции отправки или приёма.
|
||||
- name: rdma_max_recv
|
||||
type: int
|
||||
default: 16
|
||||
info: |
|
||||
Maximum number of RDMA receive buffers per connection (RDMA requires
|
||||
preallocated buffers to receive data). Each buffer is `rdma_max_msg` bytes
|
||||
in size. So this setting directly affects memory usage: a single Vitastor
|
||||
RDMA client uses `rdma_max_recv * rdma_max_msg * OSD_COUNT` bytes of memory.
|
||||
Default is roughly 2 MB * number of OSDs.
|
||||
info_ru: |
|
||||
Максимальное число буферов для RDMA-приёма данных на одно соединение
|
||||
(RDMA требует заранее выделенных буферов для приёма данных). Каждый буфер
|
||||
имеет размер `rdma_max_msg` байт. Таким образом, настройка прямо влияет на
|
||||
потребление памяти - один Vitastor-клиент с RDMA использует
|
||||
`rdma_max_recv * rdma_max_msg * ЧИСЛО_OSD` байт памяти, по умолчанию -
|
||||
примерно 2 МБ * число OSD.
|
||||
- name: rdma_max_send
|
||||
type: int
|
||||
default: 8
|
||||
info: |
|
||||
Maximum number of outstanding RDMA send operations per connection. Should be
|
||||
less than `rdma_max_recv` so the receiving side doesn't run out of buffers.
|
||||
Doesn't affect memory usage - additional memory isn't allocated for send
|
||||
operations.
|
||||
Maximum number of parallel RDMA receive operations. Note that this number
|
||||
of receive buffers `rdma_max_msg` in size are allocated for each client,
|
||||
so this setting actually affects memory usage. This is because RDMA receive
|
||||
operations are (sadly) still not zero-copy in Vitastor. It may be fixed in
|
||||
later versions.
|
||||
info_ru: |
|
||||
Максимальное число RDMA-операций отправки, отправляемых в очередь одного
|
||||
соединения. Желательно, чтобы оно было меньше `rdma_max_recv`, чтобы
|
||||
у принимающей стороны в процессе работы не заканчивались буферы на приём.
|
||||
Не влияет на потребление памяти - дополнительная память на операции отправки
|
||||
не выделяется.
|
||||
- name: rdma_odp
|
||||
type: bool
|
||||
default: false
|
||||
online: false
|
||||
info: |
|
||||
Use RDMA with On-Demand Paging. ODP is currently only available on Mellanox
|
||||
ConnectX-4 and newer adapters. ODP allows to not register memory explicitly
|
||||
for RDMA adapter to be able to use it. This, in turn, allows to skip memory
|
||||
copying during sending. One would think this should improve performance, but
|
||||
**in reality** RDMA performance with ODP is **drastically** worse. Example
|
||||
3-node cluster with 8 NVMe in each node and 2*25 GBit/s ConnectX-6 RDMA network
|
||||
without ODP pushes 3950000 read iops, but only 239000 iops with ODP...
|
||||
|
||||
This happens because Mellanox ODP implementation seems to be based on
|
||||
message retransmissions when the adapter doesn't know about the buffer yet -
|
||||
it likely uses standard "RNR retransmissions" (RNR = receiver not ready)
|
||||
which is generally slow in RDMA/RoCE networks. Here's a presentation about
|
||||
it from ISPASS-2021 conference: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
|
||||
|
||||
ODP support is retained in the code just in case a good ODP implementation
|
||||
appears one day.
|
||||
info_ru: |
|
||||
Использовать RDMA с On-Demand Paging. ODP - функция, доступная пока что
|
||||
исключительно на адаптерах Mellanox ConnectX-4 и более новых. ODP позволяет
|
||||
не регистрировать память для её использования RDMA-картой. Благодаря этому
|
||||
можно не копировать данные при отправке их в сеть и, казалось бы, это должно
|
||||
улучшать производительность - но **по факту** получается так, что
|
||||
производительность только ухудшается, причём сильно. Пример - на 3-узловом
|
||||
кластере с 8 NVMe в каждом узле и сетью 2*25 Гбит/с на чтение с RDMA без ODP
|
||||
удаётся снять 3950000 iops, а с ODP - всего 239000 iops...
|
||||
|
||||
Это происходит из-за того, что реализация ODP у Mellanox неоптимальная и
|
||||
основана на повторной передаче сообщений, когда карте не известен буфер -
|
||||
вероятно, на стандартных "RNR retransmission" (RNR = receiver not ready).
|
||||
А данные повторные передачи в RDMA/RoCE - всегда очень медленная штука.
|
||||
Презентация на эту тему с конференции ISPASS-2021: https://tkygtr6.github.io/pub/ISPASS21_slides.pdf
|
||||
|
||||
Возможность использования ODP сохранена в коде на случай, если вдруг в один
|
||||
прекрасный день появится хорошая реализация ODP.
|
||||
Максимальное число параллельных RDMA-операций получения данных. Следует
|
||||
иметь в виду, что данное число буферов размером `rdma_max_msg` выделяется
|
||||
для каждого подключённого клиентского соединения, так что данная настройка
|
||||
влияет на потребление памяти. Это так потому, что RDMA-приём данных в
|
||||
Vitastor, увы, всё равно не является zero-copy, т.е. всё равно 1 раз
|
||||
копирует данные в памяти. Данная особенность, возможно, будет исправлена в
|
||||
более новых версиях Vitastor.
|
||||
- name: peer_connect_interval
|
||||
type: sec
|
||||
min: 1
|
||||
default: 5
|
||||
online: true
|
||||
info: Interval before attempting to reconnect to an unavailable OSD.
|
||||
info_ru: Время ожидания перед повторной попыткой соединиться с недоступным OSD.
|
||||
- name: peer_connect_timeout
|
||||
type: sec
|
||||
min: 1
|
||||
default: 5
|
||||
online: true
|
||||
info: Timeout for OSD connection attempts.
|
||||
info_ru: Максимальное время ожидания попытки соединения с OSD.
|
||||
- name: osd_idle_timeout
|
||||
type: sec
|
||||
min: 1
|
||||
default: 5
|
||||
online: true
|
||||
info: |
|
||||
OSD connection inactivity time after which clients and other OSDs send
|
||||
keepalive requests to check state of the connection.
|
||||
|
|
@ -251,7 +160,6 @@
|
|||
type: sec
|
||||
min: 1
|
||||
default: 5
|
||||
online: true
|
||||
info: |
|
||||
Maximum time to wait for OSD keepalive responses. If an OSD doesn't respond
|
||||
within this time, the connection to it is dropped and a reconnection attempt
|
||||
|
|
@ -260,10 +168,23 @@
|
|||
Максимальное время ожидания ответа на запрос проверки состояния соединения.
|
||||
Если OSD не отвечает за это время, соединение отключается и производится
|
||||
повторная попытка соединения.
|
||||
- name: up_wait_retry_interval
|
||||
type: ms
|
||||
min: 50
|
||||
default: 500
|
||||
info: |
|
||||
OSDs respond to clients with a special error code when they receive I/O
|
||||
requests for a PG that's not synchronized and started. This parameter sets
|
||||
the time for the clients to wait before re-attempting such I/O requests.
|
||||
info_ru: |
|
||||
Когда OSD получают от клиентов запросы ввода-вывода, относящиеся к не
|
||||
поднятым на данный момент на них PG, либо к PG в процессе синхронизации,
|
||||
они отвечают клиентам специальным кодом ошибки, означающим, что клиент
|
||||
должен некоторое время подождать перед повторением запроса. Именно это время
|
||||
ожидания задаёт данный параметр.
|
||||
- name: max_etcd_attempts
|
||||
type: int
|
||||
default: 5
|
||||
online: true
|
||||
info: |
|
||||
Maximum number of attempts for etcd requests which can't be retried
|
||||
indefinitely.
|
||||
|
|
@ -273,7 +194,6 @@
|
|||
- name: etcd_quick_timeout
|
||||
type: ms
|
||||
default: 1000
|
||||
online: true
|
||||
info: |
|
||||
Timeout for etcd requests which should complete quickly, like lease refresh.
|
||||
info_ru: |
|
||||
|
|
@ -282,7 +202,6 @@
|
|||
- name: etcd_slow_timeout
|
||||
type: ms
|
||||
default: 5000
|
||||
online: true
|
||||
info: Timeout for etcd requests which are allowed to wait for some time.
|
||||
info_ru: |
|
||||
Максимальное время выполнения запросов к etcd, для которых не обязательно
|
||||
|
|
@ -290,17 +209,15 @@
|
|||
- name: etcd_keepalive_timeout
|
||||
type: sec
|
||||
default: max(30, etcd_report_interval*2)
|
||||
online: true
|
||||
info: |
|
||||
Timeout for etcd connection HTTP Keep-Alive. Should be higher than
|
||||
etcd_report_interval to guarantee that keepalive actually works.
|
||||
info_ru: |
|
||||
Таймаут для HTTP Keep-Alive в соединениях к etcd. Должен быть больше, чем
|
||||
etcd_report_interval, чтобы keepalive гарантированно работал.
|
||||
- name: etcd_ws_keepalive_interval
|
||||
- name: etcd_ws_keepalive_timeout
|
||||
type: sec
|
||||
default: 5
|
||||
online: true
|
||||
default: 30
|
||||
info: |
|
||||
etcd websocket ping interval required to keep the connection alive and
|
||||
detect disconnections quickly.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
# Runtime OSD Parameters
|
||||
|
||||
These parameters only apply to OSDs, are not fixed at the moment of OSD drive
|
||||
initialization and can be changed - either with an OSD restart or, for some of
|
||||
them, even without restarting by updating configuration in etcd.
|
||||
initialization and can be changed with an OSD restart.
|
||||
|
|
|
|||
|
|
@ -2,5 +2,4 @@
|
|||
|
||||
Данные параметры используются только OSD, но, в отличие от дисковых параметров,
|
||||
не фиксируются в момент инициализации дисков OSD и могут быть изменены в любой
|
||||
момент с помощью перезапуска OSD, а некоторые и без перезапуска, с помощью
|
||||
изменения конфигурации в etcd.
|
||||
момент с перезапуском OSD.
|
||||
|
|
|
|||
|
|
@ -1,47 +1,16 @@
|
|||
- name: osd_iothread_count
|
||||
type: int
|
||||
default: 0
|
||||
info: |
|
||||
TCP network I/O thread count for OSD. When non-zero, a single OSD process
|
||||
may handle more TCP I/O, but at a cost of increased latency because thread
|
||||
switching overhead occurs. RDMA isn't affected by this option.
|
||||
|
||||
Because of latency, instead of enabling OSD I/O threads it's recommended to
|
||||
just create multiple OSDs per disk, or use RDMA.
|
||||
info_ru: |
|
||||
Число отдельных потоков для обработки ввода-вывода через TCP-сеть на
|
||||
стороне OSD. Включение опции позволяет каждому отдельному OSD передавать
|
||||
по сети больше данных, но ухудшает задержку из-за накладных расходов
|
||||
переключения потоков. На работу RDMA опция не влияет.
|
||||
|
||||
Из-за задержек вместо включения потоков ввода-вывода OSD рекомендуется
|
||||
просто создавать по несколько OSD на каждом диске, или использовать RDMA.
|
||||
- name: etcd_report_interval
|
||||
type: sec
|
||||
default: 5
|
||||
info: |
|
||||
Interval at which OSDs report their liveness to etcd. Affects OSD lease time
|
||||
Interval at which OSDs report their state to etcd. Affects OSD lease time
|
||||
and thus the failover speed. Lease time is equal to this parameter value
|
||||
plus max_etcd_attempts * etcd_quick_timeout because it should be guaranteed
|
||||
that every OSD always refreshes its lease in time.
|
||||
info_ru: |
|
||||
Интервал, с которым OSD сообщает о том, что жив, в etcd. Значение параметра
|
||||
влияет на время резервации (lease) OSD и поэтому - на скорость переключения
|
||||
Интервал, с которым OSD обновляет своё состояние в etcd. Значение параметра
|
||||
влияет на время резервации (lease) OSD и поэтому на скорость переключения
|
||||
при падении OSD. Время lease равняется значению этого параметра плюс
|
||||
max_etcd_attempts * etcd_quick_timeout.
|
||||
- name: etcd_stats_interval
|
||||
type: sec
|
||||
default: 30
|
||||
info: |
|
||||
Interval at which OSDs report their statistics to etcd. Highly affects the
|
||||
imposed load on etcd, because statistics include a key for every OSD and
|
||||
for every PG. At the same time, low statistic intervals make `vitastor-cli`
|
||||
statistics more responsive.
|
||||
info_ru: |
|
||||
Интервал, с которым OSD обновляет свою статистику в etcd. Сильно влияет на
|
||||
создаваемую нагрузку на etcd, потому что статистика содержит по ключу на
|
||||
каждый OSD и на каждую PG. В то же время низкий интервал делает
|
||||
статистику, печатаемую `vitastor-cli`, отзывчивей.
|
||||
- name: run_primary
|
||||
type: bool
|
||||
default: true
|
||||
|
|
@ -97,7 +66,6 @@
|
|||
- name: autosync_interval
|
||||
type: sec
|
||||
default: 5
|
||||
online: true
|
||||
info: |
|
||||
Time interval at which automatic fsyncs/flushes are issued by each OSD when
|
||||
the immediate_commit mode if disabled. fsyncs are required because without
|
||||
|
|
@ -115,7 +83,6 @@
|
|||
- name: autosync_writes
|
||||
type: int
|
||||
default: 128
|
||||
online: true
|
||||
info: |
|
||||
Same as autosync_interval, but sets the maximum number of uncommitted write
|
||||
operations before issuing an fsync operation internally.
|
||||
|
|
@ -125,48 +92,19 @@
|
|||
принудительной отправкой fsync-а.
|
||||
- name: recovery_queue_depth
|
||||
type: int
|
||||
default: 1
|
||||
online: true
|
||||
default: 4
|
||||
info: |
|
||||
Maximum recovery and rebalance operations initiated by each OSD in parallel.
|
||||
Note that each OSD talks to a lot of other OSDs so actual number of parallel
|
||||
recovery operations per each OSD is greater than just recovery_queue_depth.
|
||||
Increasing this parameter can speedup recovery if [auto-tuning](#recovery_tune_interval)
|
||||
allows it or if it is disabled.
|
||||
Maximum recovery operations per one primary OSD at any given moment of time.
|
||||
Currently it's the only parameter available to tune the speed or recovery
|
||||
and rebalancing, but it's planned to implement more.
|
||||
info_ru: |
|
||||
Максимальное число параллельных операций восстановления, инициируемых одним
|
||||
OSD в любой момент времени. Имейте в виду, что каждый OSD обычно работает с
|
||||
многими другими OSD, так что на практике параллелизм восстановления больше,
|
||||
чем просто recovery_queue_depth. Увеличение значения этого параметра может
|
||||
ускорить восстановление если [автотюнинг скорости](#recovery_tune_interval)
|
||||
разрешает это или если он отключён.
|
||||
- name: recovery_sleep_us
|
||||
type: us
|
||||
default: 0
|
||||
online: true
|
||||
info: |
|
||||
Delay for all recovery- and rebalance- related operations. If non-zero,
|
||||
such operations are artificially slowed down to reduce the impact on
|
||||
client I/O.
|
||||
- name: recovery_pg_switch
|
||||
type: int
|
||||
default: 128
|
||||
online: true
|
||||
info: |
|
||||
Number of recovery operations before switching to recovery of the next PG.
|
||||
The idea is to mix all PGs during recovery for more even space and load
|
||||
distribution but still benefit from recovery queue depth greater than 1.
|
||||
Degraded PGs are anyway scanned first.
|
||||
info_ru: |
|
||||
Число операций восстановления перед переключением на восстановление другой PG.
|
||||
Идея заключается в том, чтобы восстанавливать все PG одновременно для более
|
||||
равномерного распределения места и нагрузки, но при этом всё равно выигрывать
|
||||
от глубины очереди восстановления, большей, чем 1. Деградированные PG в любом
|
||||
случае сканируются первыми.
|
||||
Максимальное число операций восстановления на одном первичном OSD в любой
|
||||
момент времени. На данный момент единственный параметр, который можно менять
|
||||
для ускорения или замедления восстановления и перебалансировки данных, но
|
||||
в планах реализация других параметров.
|
||||
- name: recovery_sync_batch
|
||||
type: int
|
||||
default: 16
|
||||
online: true
|
||||
info: Maximum number of recovery operations before issuing an additional fsync.
|
||||
info_ru: Максимальное число операций восстановления перед дополнительным fsync.
|
||||
- name: readonly
|
||||
|
|
@ -181,7 +119,6 @@
|
|||
- name: no_recovery
|
||||
type: bool
|
||||
default: false
|
||||
online: true
|
||||
info: |
|
||||
Disable automatic background recovery of objects. Note that it doesn't
|
||||
affect implicit recovery of objects happening during writes - a write is
|
||||
|
|
@ -194,7 +131,6 @@
|
|||
- name: no_rebalance
|
||||
type: bool
|
||||
default: false
|
||||
online: true
|
||||
info: |
|
||||
Disable background movement of data between different OSDs. Disabling it
|
||||
means that PGs in the `has_misplaced` state will be left in it indefinitely.
|
||||
|
|
@ -205,7 +141,6 @@
|
|||
- name: print_stats_interval
|
||||
type: sec
|
||||
default: 3
|
||||
online: true
|
||||
info: |
|
||||
Time interval at which OSDs print simple human-readable operation
|
||||
statistics on stdout.
|
||||
|
|
@ -215,7 +150,6 @@
|
|||
- name: slow_log_interval
|
||||
type: sec
|
||||
default: 10
|
||||
online: true
|
||||
info: |
|
||||
Time interval at which OSDs dump slow or stuck operations on stdout, if
|
||||
they're any. Also it's the time after which an operation is considered
|
||||
|
|
@ -224,18 +158,9 @@
|
|||
Временной интервал, с которым OSD выводят в стандартный вывод список
|
||||
медленных или зависших операций, если таковые имеются. Также время, при
|
||||
превышении которого операция считается "медленной".
|
||||
- name: inode_vanish_time
|
||||
type: sec
|
||||
default: 60
|
||||
online: true
|
||||
info: |
|
||||
Number of seconds after which a deleted inode is removed from OSD statistics.
|
||||
info_ru: |
|
||||
Число секунд, через которое удалённые инод удаляется и из статистики OSD.
|
||||
- name: max_write_iodepth
|
||||
type: int
|
||||
default: 128
|
||||
online: true
|
||||
info: |
|
||||
Parallel client write operation limit per one OSD. Operations that exceed
|
||||
this limit are pushed to a temporary queue instead of being executed
|
||||
|
|
@ -247,7 +172,6 @@
|
|||
- name: min_flusher_count
|
||||
type: int
|
||||
default: 1
|
||||
online: true
|
||||
info: |
|
||||
Flusher is a micro-thread that moves data from the journal to the data
|
||||
area of the device. Their number is auto-tuned between minimum and maximum.
|
||||
|
|
@ -259,7 +183,6 @@
|
|||
- name: max_flusher_count
|
||||
type: int
|
||||
default: 256
|
||||
online: true
|
||||
info: |
|
||||
Maximum number of journal flushers (see above min_flusher_count).
|
||||
info_ru: |
|
||||
|
|
@ -303,96 +226,6 @@
|
|||
достаточно 16- или 32-мегабайтного журнала. Однако в теории отключение
|
||||
параметра может оказаться полезным для гибридных OSD (HDD+SSD) с большими
|
||||
журналами, расположенными на быстром по сравнению с HDD устройстве.
|
||||
- name: data_io
|
||||
type: string
|
||||
default: direct
|
||||
info: |
|
||||
I/O mode for *data*. One of "direct", "cached" or "directsync". Corresponds
|
||||
to O_DIRECT, O_SYNC and O_DIRECT|O_SYNC, respectively.
|
||||
|
||||
Choose "cached" to use Linux page cache. This may improve read performance
|
||||
for hot data and slower disks - HDDs and maybe SATA SSDs - but will slightly
|
||||
decrease write performance for fast disks because page cache is an overhead
|
||||
itself.
|
||||
|
||||
Choose "directsync" to use [immediate_commit](layout-cluster.ru.md#immediate_commit)
|
||||
(which requires disable_data_fsync) with drives having write-back cache
|
||||
which can't be turned off, for example, Intel Optane. Also note that *some*
|
||||
desktop SSDs (for example, HP EX950) may ignore O_SYNC thus making
|
||||
disable_data_fsync unsafe even with "directsync".
|
||||
info_ru: |
|
||||
Режим ввода-вывода для *данных*. Одно из значений "direct", "cached" или
|
||||
"directsync", означающих O_DIRECT, O_SYNC и O_DIRECT|O_SYNC, соответственно.
|
||||
|
||||
Выберите "cached", чтобы использовать системный кэш Linux (page cache) при
|
||||
чтении и записи. Это может улучшить скорость чтения горячих данных с
|
||||
относительно медленных дисков - HDD и, возможно, SATA SSD - но немного
|
||||
снижает производительность записи для быстрых дисков, так как кэш сам по
|
||||
себе тоже добавляет накладные расходы.
|
||||
|
||||
Выберите "directsync", если хотите задействовать
|
||||
[immediate_commit](layout-cluster.ru.md#immediate_commit) (требующий
|
||||
включенияd disable_data_fsync) на дисках с неотключаемым кэшем. Пример таких
|
||||
дисков - Intel Optane. При этом также стоит иметь в виду, что *некоторые*
|
||||
настольные SSD (например, HP EX950) игнорируют флаг O_SYNC, делая отключение
|
||||
fsync небезопасным даже с режимом "directsync".
|
||||
- name: meta_io
|
||||
type: string
|
||||
default: direct
|
||||
info: |
|
||||
I/O mode for *metadata*. One of "direct", "cached" or "directsync".
|
||||
|
||||
"cached" may improve read performance, but only under the following conditions:
|
||||
1. your drives are relatively slow (HDD, SATA SSD), and
|
||||
2. checksums are enabled, and
|
||||
3. [inmemory_metadata](#inmemory_metadata) is disabled.
|
||||
Under all these conditions, metadata blocks are read from disk on every
|
||||
read request to verify checksums and caching them may reduce this extra
|
||||
read load. Without (3) metadata is never read from the disk after starting,
|
||||
and without (2) metadata blocks are read from disk only during journal
|
||||
flushing.
|
||||
|
||||
"directsync" is the same as above.
|
||||
|
||||
If the same device is used for data and metadata, meta_io by default is set
|
||||
to the same value as [data_io](#data_io).
|
||||
info_ru: |
|
||||
Режим ввода-вывода для *метаданных*. Одно из значений "direct", "cached" или
|
||||
"directsync".
|
||||
|
||||
"cached" может улучшить скорость чтения, если:
|
||||
1. у вас медленные диски (HDD, SATA SSD)
|
||||
2. контрольные суммы включены
|
||||
3. параметр [inmemory_metadata](#inmemory_metadata) отключён.
|
||||
При этих условиях блоки метаданных читаются с диска при каждом запросе чтения
|
||||
для проверки контрольных сумм и их кэширование может снизить дополнительную
|
||||
нагрузку на диск. Без (3) метаданные никогда не читаются с диска после
|
||||
запуска OSD, а без (2) блоки метаданных читаются только при сбросе журнала.
|
||||
|
||||
Если одно и то же устройство используется для данных и метаданных, режим
|
||||
ввода-вывода метаданных по умолчанию устанавливается равным [data_io](#data_io).
|
||||
- name: journal_io
|
||||
type: string
|
||||
default: direct
|
||||
info: |
|
||||
I/O mode for *journal*. One of "direct", "cached" or "directsync".
|
||||
|
||||
Here, "cached" may only improve read performance for recent writes and
|
||||
only if [inmemory_journal](#inmemory_journal) is turned off.
|
||||
|
||||
If the same device is used for metadata and journal, journal_io by default
|
||||
is set to the same value as [meta_io](#meta_io).
|
||||
info_ru: |
|
||||
Режим ввода-вывода для *журнала*. Одно из значений "direct", "cached" или
|
||||
"directsync".
|
||||
|
||||
Здесь "cached" может улучшить скорость чтения только недавно записанных
|
||||
данных и только если параметр [inmemory_journal](#inmemory_journal)
|
||||
отключён.
|
||||
|
||||
Если одно и то же устройство используется для метаданных и журнала,
|
||||
режим ввода-вывода журнала по умолчанию устанавливается равным
|
||||
[meta_io](#meta_io).
|
||||
- name: journal_sector_buffer_count
|
||||
type: int
|
||||
default: 32
|
||||
|
|
@ -430,7 +263,6 @@
|
|||
- name: throttle_small_writes
|
||||
type: bool
|
||||
default: false
|
||||
online: true
|
||||
info: |
|
||||
Enable soft throttling of small journaled writes. Useful for hybrid OSDs
|
||||
with fast journal/metadata devices and slow data devices. The idea is that
|
||||
|
|
@ -459,7 +291,6 @@
|
|||
- name: throttle_target_iops
|
||||
type: int
|
||||
default: 100
|
||||
online: true
|
||||
info: |
|
||||
Target maximum number of throttled operations per second under the condition
|
||||
of full journal. Set it to approximate random write iops of your data devices
|
||||
|
|
@ -472,7 +303,6 @@
|
|||
- name: throttle_target_mbs
|
||||
type: int
|
||||
default: 100
|
||||
online: true
|
||||
info: |
|
||||
Target maximum bandwidth in MB/s of throttled operations per second under
|
||||
the condition of full journal. Set it to approximate linear write
|
||||
|
|
@ -485,7 +315,6 @@
|
|||
- name: throttle_target_parallelism
|
||||
type: int
|
||||
default: 1
|
||||
online: true
|
||||
info: |
|
||||
Target maximum parallelism of throttled operations under the condition of
|
||||
full journal. Set it to approximate internal parallelism of your data
|
||||
|
|
@ -498,7 +327,6 @@
|
|||
- name: throttle_threshold_us
|
||||
type: us
|
||||
default: 50
|
||||
online: true
|
||||
info: |
|
||||
Minimal computed delay to be applied to throttled operations. Usually
|
||||
doesn't need to be changed.
|
||||
|
|
@ -508,260 +336,10 @@
|
|||
- name: osd_memlock
|
||||
type: bool
|
||||
default: false
|
||||
info: |
|
||||
info: >
|
||||
Lock all OSD memory to prevent it from being unloaded into swap with
|
||||
mlockall(). Requires sufficient ulimit -l (max locked memory).
|
||||
info_ru: |
|
||||
info_ru: >
|
||||
Блокировать всю память OSD с помощью mlockall, чтобы запретить её выгрузку
|
||||
в пространство подкачки. Требует достаточного значения ulimit -l (лимита
|
||||
заблокированной памяти).
|
||||
- name: auto_scrub
|
||||
type: bool
|
||||
default: false
|
||||
online: true
|
||||
info: |
|
||||
Data scrubbing is the process of background verification of copies to find
|
||||
and repair corrupted blocks. It's not run automatically by default since
|
||||
it's a new feature. Set this parameter to true to enable automatic scrubs.
|
||||
|
||||
This parameter makes OSDs automatically schedule data scrubbing of clean PGs
|
||||
every `scrub_interval` (see below). You can also start/schedule scrubbing
|
||||
manually by setting `next_scrub` JSON key to the desired UNIX time of the
|
||||
next scrub in `/pg/history/...` values in etcd.
|
||||
info_ru: |
|
||||
Скраб - процесс фоновой проверки копий данных, предназначенный, чтобы
|
||||
находить и исправлять повреждённые блоки. По умолчанию эти проверки ещё не
|
||||
запускаются автоматически, так как являются новой функцией. Чтобы включить
|
||||
автоматическое планирование скрабов, установите данный параметр в true.
|
||||
|
||||
Включённый параметр заставляет OSD автоматически планировать фоновую
|
||||
проверку чистых PG раз в `scrub_interval` (см. ниже). Вы также можете
|
||||
запустить или запланировать проверку вручную, установив значение ключа JSON
|
||||
`next_scrub` внутри ключей etcd `/pg/history/...` в UNIX-время следующей
|
||||
желаемой проверки.
|
||||
- name: no_scrub
|
||||
type: bool
|
||||
default: false
|
||||
online: true
|
||||
info: |
|
||||
Temporarily disable scrubbing and stop running scrubs.
|
||||
info_ru: |
|
||||
Временно отключить и остановить запущенные скрабы.
|
||||
- name: scrub_interval
|
||||
type: string
|
||||
default: 30d
|
||||
online: true
|
||||
info: |
|
||||
Default automatic scrubbing interval for all pools. Numbers without suffix
|
||||
are treated as seconds, possible unit suffixes include 's' (seconds),
|
||||
'm' (minutes), 'h' (hours), 'd' (days), 'M' (months) and 'y' (years).
|
||||
info_ru: |
|
||||
Интервал автоматической фоновой проверки по умолчанию для всех пулов.
|
||||
Значения без указанной единицы измерения считаются в секундах, допустимые
|
||||
символы единиц измерения в конце: 's' (секунды),
|
||||
'm' (минуты), 'h' (часы), 'd' (дни), 'M' (месяца) или 'y' (годы).
|
||||
- name: scrub_queue_depth
|
||||
type: int
|
||||
default: 1
|
||||
online: true
|
||||
info: |
|
||||
Number of parallel scrubbing operations per one OSD.
|
||||
info_ru: |
|
||||
Число параллельных операций фоновой проверки на один OSD.
|
||||
- name: scrub_sleep
|
||||
type: ms
|
||||
default: 0
|
||||
online: true
|
||||
info: |
|
||||
Additional interval between two consecutive scrubbing operations on one OSD.
|
||||
Can be used to slow down scrubbing if it affects user load too much.
|
||||
info_ru: |
|
||||
Дополнительный интервал ожидания после фоновой проверки каждого объекта на
|
||||
одном OSD. Может использоваться для замедления скраба, если он слишком
|
||||
сильно влияет на пользовательскую нагрузку.
|
||||
- name: scrub_list_limit
|
||||
type: int
|
||||
default: 1000
|
||||
online: true
|
||||
info: |
|
||||
Number of objects to list in one listing operation during scrub.
|
||||
info_ru: |
|
||||
Размер загружаемых за одну операцию списков объектов в процессе фоновой
|
||||
проверки.
|
||||
- name: scrub_find_best
|
||||
type: bool
|
||||
default: true
|
||||
online: true
|
||||
info: |
|
||||
Find and automatically restore best versions of objects with unmatched
|
||||
copies. In replicated setups, the best version is the version with most
|
||||
matching replicas. In EC setups, the best version is the subset of data
|
||||
and parity chunks without mismatches.
|
||||
|
||||
The hypothetical situation where you might want to disable it is when
|
||||
you have 3 replicas and you are paranoid that 2 HDDs out of 3 may silently
|
||||
corrupt an object in the same way (for example, zero it out) and only
|
||||
1 HDD will remain good. In this case disabling scrub_find_best may help
|
||||
you to recover the data! See also scrub_ec_max_bruteforce below.
|
||||
info_ru: |
|
||||
Находить и автоматически восстанавливать "лучшие версии" объектов с
|
||||
несовпадающими копиями/частями. При использовании репликации "лучшая"
|
||||
версия - версия, доступная в большем числе экземпляров, чем другие. При
|
||||
использовании кодов коррекции ошибок "лучшая" версия - это подмножество
|
||||
частей данных и чётности, полностью соответствующих друг другу.
|
||||
|
||||
Гипотетическая ситуация, в которой вы можете захотеть отключить этот
|
||||
поиск - это если у вас 3 реплики и вы боитесь, что 2 диска из 3 могут
|
||||
незаметно и одинаково повредить данные одного и того же объекта, например,
|
||||
занулив его, и только 1 диск останется неповреждённым. В этой ситуации
|
||||
отключение этого параметра поможет вам восстановить данные! Смотрите также
|
||||
описание следующего параметра - scrub_ec_max_bruteforce.
|
||||
- name: scrub_ec_max_bruteforce
|
||||
type: int
|
||||
default: 100
|
||||
online: true
|
||||
info: |
|
||||
Vitastor can locate corrupted chunks in EC setups with more than 1 parity
|
||||
chunk by brute-forcing all possible error locations. This configuration
|
||||
value limits the maximum number of checked combinations. You can try to
|
||||
increase it if you have EC N+K setup with N and K large enough for
|
||||
combination count `C(N+K-1, K-1) = (N+K-1)! / (K-1)! / N!` to be greater
|
||||
than the default 100.
|
||||
|
||||
If there are too many possible combinations or if multiple combinations give
|
||||
correct results then objects are marked inconsistent and aren't recovered
|
||||
automatically.
|
||||
|
||||
In replicated setups bruteforcing isn't needed, Vitastor just assumes that
|
||||
the variant with most available equal copies is correct. For example, if
|
||||
you have 3 replicas and 1 of them differs, this one is considered to be
|
||||
corrupted. But if there is no "best" version with more copies than all
|
||||
others have then the object is also marked as inconsistent.
|
||||
info_ru: |
|
||||
Vitastor старается определить повреждённые части объектов при использовании
|
||||
EC (кодов коррекции ошибок) с более, чем 1 диском чётности, путём перебора
|
||||
всех возможных комбинаций ошибочных частей. Данное значение конфигурации
|
||||
ограничивает число перебираемых комбинаций. Вы можете попробовать поднять
|
||||
его, если используете схему кодирования EC N+K с N и K, достаточно большими
|
||||
для того, чтобы число сочетаний `C(N+K-1, K-1) = (N+K-1)! / (K-1)! / N!`
|
||||
было больше, чем стандартное значение 100.
|
||||
|
||||
Если возможных комбинаций слишком много или если корректная комбинаций не
|
||||
определяется однозначно, объекты помечаются неконсистентными (inconsistent)
|
||||
и не восстанавливаются автоматически.
|
||||
|
||||
При использовании репликации перебор не нужен, Vitastor просто предполагает,
|
||||
что вариант объекта с наибольшим количеством одинаковых копий корректен.
|
||||
Например, если вы используете 3 реплики и 1 из них отличается, эта 1 копия
|
||||
считается некорректной. Однако, если "лучшую" версию с числом доступных
|
||||
копий большим, чем у всех других версий, найти невозможно, то объект тоже
|
||||
маркируется неконсистентным.
|
||||
- name: recovery_tune_interval
|
||||
type: sec
|
||||
default: 1
|
||||
online: true
|
||||
info: |
|
||||
Interval at which OSD re-considers client and recovery load and automatically
|
||||
adjusts [recovery_sleep_us](#recovery_sleep_us). Recovery auto-tuning is
|
||||
disabled if recovery_tune_interval is set to 0.
|
||||
|
||||
Auto-tuning targets utilization. Utilization is a measure of load and is
|
||||
equal to the product of iops and average latency (so it may be greater
|
||||
than 1). You set "low" and "high" client utilization thresholds and two
|
||||
corresponding target recovery utilization levels. OSD calculates desired
|
||||
recovery utilization from client utilization using linear interpolation
|
||||
and auto-tunes recovery operation delay to make actual recovery utilization
|
||||
match desired.
|
||||
|
||||
This allows to reduce recovery/rebalance impact on client operations. It is
|
||||
of course impossible to remove it completely, but it should become adequate.
|
||||
In some tests rebalance could earlier drop client write speed from 1.5 GB/s
|
||||
to 50-100 MB/s, with default auto-tuning settings it now only reduces
|
||||
to ~1 GB/s.
|
||||
info_ru: |
|
||||
Интервал, с которым OSD пересматривает клиентскую нагрузку и нагрузку
|
||||
восстановления и автоматически подстраивает [recovery_sleep_us](#recovery_sleep_us).
|
||||
Автотюнинг (автоподстройка) отключается, если recovery_tune_interval
|
||||
устанавливается в значение 0.
|
||||
|
||||
Автотюнинг регулирует утилизацию. Утилизация является мерой нагрузки
|
||||
и равна произведению числа операций в секунду и средней задержки
|
||||
(то есть, она может быть выше 1). Вы задаёте два уровня клиентской
|
||||
утилизации - "низкий" и "высокий" (low и high) и два соответствующих
|
||||
целевых уровня утилизации операциями восстановления. OSD рассчитывает
|
||||
желаемый уровень утилизации восстановления линейной интерполяцией от
|
||||
клиентской утилизации и подстраивает задержку операций восстановления
|
||||
так, чтобы фактическая утилизация восстановления совпадала с желаемой.
|
||||
|
||||
Это позволяет снизить влияние восстановления и ребаланса на клиентские
|
||||
операции. Конечно, невозможно исключить такое влияние полностью, но оно
|
||||
должно становиться адекватнее. В некоторых тестах перебалансировка могла
|
||||
снижать клиентскую скорость записи с 1.5 ГБ/с до 50-100 МБ/с, а теперь, с
|
||||
настройками автотюнинга по умолчанию, она снижается только до ~1 ГБ/с.
|
||||
- name: recovery_tune_util_low
|
||||
type: float
|
||||
default: 0.1
|
||||
online: true
|
||||
info: |
|
||||
Desired recovery/rebalance utilization when client load is high, i.e. when
|
||||
it is at or above recovery_tune_client_util_high.
|
||||
info_ru: |
|
||||
Желаемая утилизация восстановления в моменты, когда клиентская нагрузка
|
||||
высокая, то есть, находится на уровне или выше recovery_tune_client_util_high.
|
||||
- name: recovery_tune_util_high
|
||||
type: float
|
||||
default: 1
|
||||
online: true
|
||||
info: |
|
||||
Desired recovery/rebalance utilization when client load is low, i.e. when
|
||||
it is at or below recovery_tune_client_util_low.
|
||||
info_ru: |
|
||||
Желаемая утилизация восстановления в моменты, когда клиентская нагрузка
|
||||
низкая, то есть, находится на уровне или ниже recovery_tune_client_util_low.
|
||||
- name: recovery_tune_client_util_low
|
||||
type: float
|
||||
default: 0
|
||||
online: true
|
||||
info: Client utilization considered "low".
|
||||
info_ru: Клиентская утилизация, которая считается "низкой".
|
||||
- name: recovery_tune_client_util_high
|
||||
type: float
|
||||
default: 0.5
|
||||
online: true
|
||||
info: Client utilization considered "high".
|
||||
info_ru: Клиентская утилизация, которая считается "высокой".
|
||||
- name: recovery_tune_agg_interval
|
||||
type: int
|
||||
default: 10
|
||||
online: true
|
||||
info: |
|
||||
The number of last auto-tuning iterations to use for calculating the
|
||||
delay as average. Lower values result in quicker response to client
|
||||
load change, higher values result in more stable delay. Default value of 10
|
||||
is usually fine.
|
||||
info_ru: |
|
||||
Число последних итераций автоподстройки для расчёта задержки как среднего
|
||||
значения. Меньшие значения параметра ускоряют отклик на изменение нагрузки,
|
||||
большие значения делают задержку стабильнее. Значение по умолчанию 10
|
||||
обычно нормальное и не требует изменений.
|
||||
- name: recovery_tune_sleep_min_us
|
||||
type: us
|
||||
default: 10
|
||||
online: true
|
||||
info: |
|
||||
Minimum possible value for auto-tuned recovery_sleep_us. Lower values
|
||||
are changed to 0.
|
||||
info_ru: |
|
||||
Минимальное возможное значение авто-подстроенного recovery_sleep_us.
|
||||
Меньшие значения заменяются на 0.
|
||||
- name: recovery_tune_sleep_cutoff_us
|
||||
type: us
|
||||
default: 10000000
|
||||
online: true
|
||||
info: |
|
||||
Maximum possible value for auto-tuned recovery_sleep_us. Higher values
|
||||
are treated as outliers and ignored in aggregation.
|
||||
info_ru: |
|
||||
Максимальное возможное значение авто-подстроенного recovery_sleep_us.
|
||||
Большие значения считаются случайными выбросами и игнорируются в
|
||||
усреднении.
|
||||
|
|
|
|||
|
|
@ -6,18 +6,9 @@
|
|||
|
||||
# Kubernetes CSI
|
||||
|
||||
Vitastor has a CSI plugin for Kubernetes which supports block-based and VitastorFS-based volumes.
|
||||
Vitastor has a CSI plugin for Kubernetes which supports RWO (and block RWX) volumes.
|
||||
|
||||
Block-based volumes may be formatted and mounted with a normal FS (ext4 or xfs). Such volumes
|
||||
only support RWO (ReadWriteOnce) mode.
|
||||
|
||||
Block-based volumes may also be left without FS and attached into the container as a block
|
||||
device. Such volumes also support RWX (ReadWriteMany) mode.
|
||||
|
||||
VitastorFS-based volumes use a clustered file system and support FS-based RWX (ReadWriteMany)
|
||||
mode. However, such volumes don't support quotas and snapshots.
|
||||
|
||||
To deploy the CSI plugin, take manifests from [csi/deploy/](../../csi/deploy/) directory, put your
|
||||
To deploy it, take manifests from [csi/deploy/](../../csi/deploy/) directory, put your
|
||||
Vitastor configuration in [001-csi-config-map.yaml](../../csi/deploy/001-csi-config-map.yaml),
|
||||
configure storage class in [009-storage-class.yaml](../../csi/deploy/009-storage-class.yaml)
|
||||
and apply all `NNN-*.yaml` manifests to your Kubernetes installation:
|
||||
|
|
@ -26,27 +17,4 @@ and apply all `NNN-*.yaml` manifests to your Kubernetes installation:
|
|||
for i in ./???-*.yaml; do kubectl apply -f $i; done
|
||||
```
|
||||
|
||||
After that you'll be able to create PersistentVolumes.
|
||||
|
||||
**Important:** For best experience, use Linux kernel at least 5.15 with [VDUSE](../usage/qemu.en.md#vduse)
|
||||
kernel modules enabled (vdpa, vduse, virtio-vdpa). If your distribution doesn't
|
||||
have them pre-built - build them yourself ([instructions](../usage/qemu.en.md#vduse)),
|
||||
I promise it's worth it :-). When VDUSE is unavailable, CSI driver uses [NBD](../usage/nbd.en.md)
|
||||
to map Vitastor devices. NBD is slower and, with kernels older than 5.19, unmountable
|
||||
if the cluster becomes unresponsible.
|
||||
|
||||
## Features
|
||||
|
||||
Vitastor CSI supports:
|
||||
- Kubernetes starting with 1.20 (or 1.17 for older vitastor-csi <= 1.1.0)
|
||||
- Block-based FS-formatted RWO (ReadWriteOnce) volumes. Example: [PVC](../../csi/deploy/example-pvc.yaml), [pod](../../csi/deploy/example-test-pod.yaml)
|
||||
- Raw block RWX (ReadWriteMany) volumes. Example: [PVC](../../csi/deploy/example-pvc-block.yaml), [pod](../../csi/deploy/example-test-pod-block.yaml)
|
||||
- VitastorFS-based volumes RWX (ReadWriteMany) volumes. Example: [storage class](../../csi/deploy/example-storage-class-fs.yaml)
|
||||
- Volume expansion
|
||||
- Volume snapshots. Example: [snapshot class](../../csi/deploy/example-snapshot-class.yaml), [snapshot](../../csi/deploy/example-snapshot.yaml), [clone](../../csi/deploy/example-snapshot-clone.yaml)
|
||||
- [VDUSE](../usage/qemu.en.md#vduse) (preferred) and [NBD](../usage/nbd.en.md) device mapping methods
|
||||
- Upgrades with VDUSE - new handler processes are restarted when CSI pods are restarted themselves
|
||||
- VDUSE daemon auto-restart - handler processes are automatically restarted if they crash due to a bug in Vitastor client code
|
||||
- Multiple clusters by using multiple configuration files in ConfigMap.
|
||||
|
||||
Remember that to use snapshots with CSI you also have to install [Snapshot Controller and CRDs](https://kubernetes-csi.github.io/docs/snapshot-controller.html#deployment).
|
||||
After that you'll be able to create PersistentVolumes. See example in [csi/deploy/example-pvc.yaml](../../csi/deploy/example-pvc.yaml).
|
||||
|
|
|
|||
|
|
@ -6,49 +6,15 @@
|
|||
|
||||
# Kubernetes CSI
|
||||
|
||||
У Vitastor есть CSI-плагин для Kubernetes, поддерживающий блочные тома и тома на основе
|
||||
кластерной ФС VitastorFS.
|
||||
У Vitastor есть CSI-плагин для Kubernetes, поддерживающий RWO, а также блочные RWX, тома.
|
||||
|
||||
Блочные тома могут быть отформатированы и примонтированы со стандартной ФС (ext4 или xfs).
|
||||
Такие тома поддерживают только режим RWO (ReadWriteOnce, одновременный доступ с одного узла).
|
||||
|
||||
Блочные тома также могут не форматироваться и подключаться в контейнер в виде блочного устройства.
|
||||
В таком случае их можно подключать в режиме RWX (ReadWriteMany, одновременный доступ с многих узлов).
|
||||
|
||||
Тома на основе VitastorFS используют кластерную ФС и поэтому также поддерживают режим RWX
|
||||
(ReadWriteMany). Однако, такие тома не поддерживают ограничение размера и снимки.
|
||||
|
||||
Для установки возьмите манифесты из директории [csi/deploy/](../../csi/deploy/), поместите
|
||||
вашу конфигурацию подключения к Vitastor в [csi/deploy/001-csi-config-map.yaml](../../csi/deploy/001-csi-config-map.yaml),
|
||||
настройте StorageClass в [csi/deploy/009-storage-class.yaml](../../csi/deploy/009-storage-class.yaml)
|
||||
Для установки возьмите манифесты из директории [csi/deploy/](../csi/deploy/), поместите
|
||||
вашу конфигурацию подключения к Vitastor в [csi/deploy/001-csi-config-map.yaml](../csi/deploy/001-csi-config-map.yaml),
|
||||
настройте StorageClass в [csi/deploy/009-storage-class.yaml](../csi/deploy/009-storage-class.yaml)
|
||||
и примените все `NNN-*.yaml` к вашей инсталляции Kubernetes.
|
||||
|
||||
```
|
||||
for i in ./???-*.yaml; do kubectl apply -f $i; done
|
||||
```
|
||||
|
||||
После этого вы сможете создавать PersistentVolume.
|
||||
|
||||
**Важно:** Лучше всего использовать ядро Linux версии не менее 5.15 с включёнными модулями
|
||||
[VDUSE](../usage/qemu.ru.md#vduse) (vdpa, vduse, virtio-vdpa). Если в вашем дистрибутиве
|
||||
они не собраны из коробки - соберите их сами, обещаю, что это стоит того ([инструкция](../usage/qemu.ru.md#vduse)) :-).
|
||||
Когда VDUSE недоступно, CSI-плагин использует [NBD](../usage/nbd.ru.md) для подключения
|
||||
дисков, а NBD медленнее и имеет проблему таймаута - если кластер остаётся недоступным
|
||||
дольше, чем [nbd_timeout](../config/client.ru.md#nbd_timeout), NBD-устройство отключается
|
||||
и ломает поды, использующие его.
|
||||
|
||||
## Возможности
|
||||
|
||||
CSI-плагин Vitastor поддерживает:
|
||||
- Версии Kubernetes, начиная с 1.20 (или с 1.17 для более старых vitastor-csi <= 1.1.0)
|
||||
- Файловые RWO (ReadWriteOnce) тома. Пример: [PVC](../../csi/deploy/example-pvc.yaml), [под](../../csi/deploy/example-test-pod.yaml)
|
||||
- Сырые блочные RWX (ReadWriteMany) тома. Пример: [PVC](../../csi/deploy/example-pvc-block.yaml), [под](../../csi/deploy/example-test-pod-block.yaml)
|
||||
- Основанные на VitastorFS RWX (ReadWriteMany) тома. Пример: [класс хранения](../../csi/deploy/example-storage-class-fs.yaml)
|
||||
- Расширение размера томов
|
||||
- Снимки томов. Пример: [класс снимков](../../csi/deploy/example-snapshot-class.yaml), [снимок](../../csi/deploy/example-snapshot.yaml), [клон снимка](../../csi/deploy/example-snapshot-clone.yaml)
|
||||
- Способы подключения устройств [VDUSE](../usage/qemu.ru.md#vduse) (предпочитаемый) и [NBD](../usage/nbd.ru.md)
|
||||
- Обновление при использовании VDUSE - новые процессы-обработчики устройств успешно перезапускаются вместе с самими подами CSI
|
||||
- Автоперезауск демонов VDUSE - процесс-обработчик автоматически перезапустится, если он внезапно упадёт из-за бага в коде клиента Vitastor
|
||||
- Несколько кластеров через задание нескольких файлов конфигурации в ConfigMap.
|
||||
|
||||
Не забывайте, что для использования снимков нужно сначала установить [контроллер снимков и CRD](https://kubernetes-csi.github.io/docs/snapshot-controller.html#deployment).
|
||||
После этого вы сможете создавать PersistentVolume. Пример смотрите в файле [csi/deploy/example-pvc.yaml](../csi/deploy/example-pvc.yaml).
|
||||
|
|
|
|||
|
|
@ -1,186 +0,0 @@
|
|||
[Documentation](../../README.md#documentation) → Installation → OpenNebula
|
||||
|
||||
-----
|
||||
|
||||
[Читать на русском](opennebula.ru.md)
|
||||
|
||||
# OpenNebula
|
||||
|
||||
## Automatic Installation
|
||||
|
||||
OpenNebula plugin is packaged as `vitastor-opennebula` Debian and RPM package since Vitastor 1.9.0. So:
|
||||
|
||||
- Run `apt-get install vitastor-opennebula` or `yum install vitastor-opennebula` after installing OpenNebula on all nodes
|
||||
- Check that it prints "OK, Vitastor OpenNebula patches successfully applied" or "OK, Vitastor OpenNebula patches are already applied"
|
||||
- If it does not, refer to [Manual Installation](#manual-installation) and apply configuration file changes manually
|
||||
- Make sure that Vitastor patched versions of QEMU and libvirt are installed
|
||||
(`dpkg -l qemu-system-x86`, `dpkg -l | grep libvirt`, `rpm -qa | grep qemu`, `rpm -qa | grep qemu`, `rpm -qa | grep libvirt-libs` should show "vitastor" in version names)
|
||||
- [Block VM access to Vitastor cluster](#block-vm-access-to-vitastor-cluster)
|
||||
|
||||
## Manual Installation
|
||||
|
||||
Install OpenNebula. Then, on each node:
|
||||
|
||||
- Copy [opennebula/remotes](../../opennebula/remotes) into `/var/lib/one` recursively: `cp -r opennebula/remotes /var/lib/one/`
|
||||
- Copy [opennebula/sudoers.d](../../opennebula/sudoers.d) to `/etc`: `cp -r opennebula/sudoers.d /etc/`
|
||||
- Apply [downloader-vitastor.sh.diff](../../opennebula/remotes/datastore/vitastor/downloader-vitastor.sh.diff) to `/var/lib/one/remotes/datastore/downloader.sh`:
|
||||
`patch /var/lib/one/remotes/datastore/downloader.sh < opennebula/remotes/datastore/vitastor/downloader-vitastor.sh.diff` - or read the patch and apply the same change manually
|
||||
- Add `kvm-vitastor` to `LIVE_DISK_SNAPSHOTS` in `/etc/one/vmm_exec/vmm_execrc`
|
||||
- If on Debian or Ubuntu (and AppArmor is used), add Vitastor config file path(s) to `/etc/apparmor.d/local/abstractions/libvirt-qemu`: for example,
|
||||
`echo ' "/etc/vitastor/vitastor.conf" r,' >> /etc/apparmor.d/local/abstractions/libvirt-qemu`
|
||||
- Apply changes to `/etc/one/oned.conf`
|
||||
|
||||
### oned.conf changes
|
||||
|
||||
1. Add deploy script override in kvm VM_MAD: add `-l deploy.vitastor` to ARGUMENTS.
|
||||
|
||||
```diff
|
||||
VM_MAD = [
|
||||
NAME = "kvm",
|
||||
SUNSTONE_NAME = "KVM",
|
||||
EXECUTABLE = "one_vmm_exec",
|
||||
- ARGUMENTS = "-t 15 -r 0 kvm -p",
|
||||
+ ARGUMENTS = "-t 15 -r 0 kvm -p -l deploy=deploy.vitastor",
|
||||
DEFAULT = "vmm_exec/vmm_exec_kvm.conf",
|
||||
TYPE = "kvm",
|
||||
KEEP_SNAPSHOTS = "yes",
|
||||
LIVE_RESIZE = "yes",
|
||||
SUPPORT_SHAREABLE = "yes",
|
||||
IMPORTED_VMS_ACTIONS = "terminate, terminate-hard, hold, release, suspend,
|
||||
resume, delete, reboot, reboot-hard, resched, unresched, disk-attach,
|
||||
disk-detach, nic-attach, nic-detach, snapshot-create, snapshot-delete,
|
||||
resize, updateconf, update"
|
||||
]
|
||||
```
|
||||
|
||||
Optional: if you also want to save VM RAM checkpoints to Vitastor, use
|
||||
`-l deploy=deploy.vitastor,save=save.vitastor,restore=restore.vitastor`
|
||||
instead of just `-l deploy=deploy.vitastor`.
|
||||
|
||||
2. Add `vitastor` to TM_MAD.ARGUMENTS and DATASTORE_MAD.ARGUMENTS:
|
||||
|
||||
```diff
|
||||
TM_MAD = [
|
||||
EXECUTABLE = "one_tm",
|
||||
- ARGUMENTS = "-t 15 -d dummy,lvm,shared,fs_lvm,fs_lvm_ssh,qcow2,ssh,ceph,dev,vcenter,iscsi_libvirt"
|
||||
+ ARGUMENTS = "-t 15 -d dummy,lvm,shared,fs_lvm,fs_lvm_ssh,qcow2,ssh,ceph,vitastor,dev,vcenter,iscsi_libvirt"
|
||||
]
|
||||
|
||||
DATASTORE_MAD = [
|
||||
EXECUTABLE = "one_datastore",
|
||||
- ARGUMENTS = "-t 15 -d dummy,fs,lvm,ceph,dev,iscsi_libvirt,vcenter,restic,rsync -s shared,ssh,ceph,fs_lvm,fs_lvm_ssh,qcow2,vcenter"
|
||||
+ ARGUMENTS = "-t 15 -d dummy,fs,lvm,ceph,vitastor,dev,iscsi_libvirt,vcenter,restic,rsync -s shared,ssh,ceph,vitastor,fs_lvm,fs_lvm_ssh,qcow2,vcenter"
|
||||
]
|
||||
```
|
||||
|
||||
3. Add INHERIT_DATASTORE_ATTR for two Vitastor attributes:
|
||||
|
||||
```
|
||||
INHERIT_DATASTORE_ATTR = "VITASTOR_CONF"
|
||||
INHERIT_DATASTORE_ATTR = "IMAGE_PREFIX"
|
||||
```
|
||||
|
||||
4. Add TM_MAD_CONF and DS_MAD_CONF for Vitastor:
|
||||
|
||||
```
|
||||
TM_MAD_CONF = [
|
||||
NAME = "vitastor", LN_TARGET = "NONE", CLONE_TARGET = "SELF", SHARED = "YES",
|
||||
DS_MIGRATE = "NO", DRIVER = "raw", ALLOW_ORPHANS="format",
|
||||
TM_MAD_SYSTEM = "ssh,shared", LN_TARGET_SSH = "SYSTEM", CLONE_TARGET_SSH = "SYSTEM",
|
||||
DISK_TYPE_SSH = "FILE", LN_TARGET_SHARED = "NONE",
|
||||
CLONE_TARGET_SHARED = "SELF", DISK_TYPE_SHARED = "FILE"
|
||||
]
|
||||
|
||||
DS_MAD_CONF = [
|
||||
NAME = "vitastor",
|
||||
REQUIRED_ATTRS = "DISK_TYPE,BRIDGE_LIST",
|
||||
PERSISTENT_ONLY = "NO",
|
||||
MARKETPLACE_ACTIONS = "export"
|
||||
]
|
||||
```
|
||||
|
||||
## Create Datastores
|
||||
|
||||
Example Image and System Datastore definitions:
|
||||
[opennebula/vitastor-imageds.conf](../../opennebula/vitastor-imageds.conf) and
|
||||
[opennebula/vitastor-systemds.conf](../../opennebula/vitastor-systemds.conf).
|
||||
|
||||
Change parameters to your will:
|
||||
|
||||
- POOL_NAME is Vitastor pool name to store images.
|
||||
- IMAGE_PREFIX is a string prepended to all Vitastor image names.
|
||||
- BRIDGE_LIST is a list of hosts with access to Vitastor cluster, mostly used for image (not system) datastore operations.
|
||||
- VITASTOR_CONF is the path to cluster configuration. Note that it should be also added to `/etc/apparmor.d/local/abstractions/libvirt-qemu` if you use AppArmor.
|
||||
- STAGING_DIR is a temporary directory used when importing external images. Should have free space sufficient for downloading external images.
|
||||
|
||||
Then create datastores using `onedatastore create vitastor-imageds.conf` and `onedatastore create vitastor-systemds.conf` (or use UI).
|
||||
|
||||
## Block VM access to Vitastor cluster
|
||||
|
||||
Vitastor doesn't support any authentication yet, so you MUST block VM guest access to the Vitastor cluster at the network level.
|
||||
|
||||
If you use VLAN networking for VMs - make sure you use different VLANs for VMs and hypervisor/storage network and
|
||||
block access between them using your firewall/switch configuration.
|
||||
|
||||
If you use something more stupid like bridged networking, you probably have to use manual firewall/iptables setup
|
||||
to only allow access to Vitastor from hypervisor IPs.
|
||||
|
||||
Also you need to switch network to "Bridged & Security Groups" and enable IP spoofing filters in OpenNebula.
|
||||
Problem is that OpenNebula's IP spoofing filter doesn't affect local interfaces of the hypervisor i.e. when
|
||||
it's enabled a VM can't talk to other VMs or to the outer world using a spoofed IP, but it CAN talk to the
|
||||
hypervisor if it takes an IP from its subnet. To fix that you also need some more iptables.
|
||||
|
||||
So the complete "stupid" bridged network filter setup could look like the following
|
||||
(here `10.0.3.0/24` is the VM subnet and `10.0.2.0/24` is the hypervisor subnet):
|
||||
|
||||
```
|
||||
# Allow incoming traffic from physical device
|
||||
iptables -A INPUT -m physdev --physdev-in eth0 -j ACCEPT
|
||||
# Do not allow incoming traffic from VMs, but not from VM subnet
|
||||
iptables -A INPUT ! -s 10.0.3.0/24 -i onebr0 -j DROP
|
||||
# Drop traffic from VMs to hypervisor/storage subnet
|
||||
iptables -I FORWARD 1 -s 10.0.3.0/24 -d 10.0.2.0/24 -j DROP
|
||||
```
|
||||
|
||||
## Testing
|
||||
|
||||
The OpenNebula plugin includes quite a bit of bash scripts, so here's their description to get an idea about what they actually do.
|
||||
|
||||
| Script | Action | How to Test |
|
||||
| ----------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------ |
|
||||
| vmm/kvm/deploy.vitastor | Start a VM | Create and start a VM with Vitastor disk(s): persistent / non-persistent / volatile. |
|
||||
| vmm/kvm/save.vitastor | Save VM memory checkpoint | Stop a VM using "Stop" command. |
|
||||
| vmm/kvm/restore.vitastor| Restore VM memory checkpoint | Start a VM back after stopping it. |
|
||||
| datastore/clone | Copy an image as persistent | Create a VM template and instantiate it as persistent. |
|
||||
| datastore/cp | Import an external image | Import a VM template with images from Marketplace. |
|
||||
| datastore/export | Export an image as URL | Probably: export a VM template with images to Marketplace. |
|
||||
| datastore/mkfs | Create an image with FS | Storage → Images → Create → Type: Datablock, Location: Empty disk image, Filesystem: Not empty. |
|
||||
| datastore/monitor | Monitor used space in image datastore | Check reported used/free space in image datastore list. |
|
||||
| datastore/rm | Remove a persistent image | Storage → Images → Select an image → Delete. |
|
||||
| datastore/snap_delete | Delete a snapshot of a persistent image | Storage → Images → Select an image → Select a snapshot → Delete; <br> To create an image with snapshot: attach a persistent image to a VM; create a snapshot; detach the image. |
|
||||
| datastore/snap_flatten | Revert an image to snapshot and delete other snapshots | Storage → Images → Select an image → Select a snapshot → Flatten. |
|
||||
| datastore/snap_revert | Revert an image to snapshot | Storage → Images → Select an image → Select a snapshot → Revert. |
|
||||
| datastore/stat | Get virtual size of an image in MB | No idea. Seems to be unused both in Vitastor and Ceph datastores. |
|
||||
| tm/clone | Clone a non-persistent image to a VM disk | Attach a non-persistent image to a VM. |
|
||||
| tm/context | Generate a contextualisation VM disk | Create a VM with enabled contextualisation (default). Common host FS-based version is used in Vitastor and Ceph datastores. |
|
||||
| tm/cpds | Copy a VM disk / its snapshot to an image | Select a VM → Select a disk → Optionally select a snapshot → Save as. |
|
||||
| tm/delete | Delete a cloned or volatile VM disk | Detach a volatile disk or a non-persistent image from a VM. |
|
||||
| tm/failmigrate | Handle live migration failure | No action. Script is empty in Vitastor and Ceph. In other datastores, should roll back actions done by tm/premigrate. |
|
||||
| tm/ln | Attach a persistent image to a VM | No action. Script is empty in Vitastor and Ceph. |
|
||||
| tm/mkimage | Create a volatile disk, maybe with FS | Attach a volatile disk to a VM, with or without file system. |
|
||||
| tm/mkswap | Create a volatile swap disk | Attach a volatile disk to a VM, formatted as swap. |
|
||||
| tm/monitor | Monitor used space in system datastore | Check reported used/free space in system datastore list. |
|
||||
| tm/mv | Move a migrated VM disk between hosts | Migrate a VM between hosts. In Vitastor and Ceph datastores, doesn't do any storage action. |
|
||||
| tm/mvds | Detach a persistent image from a VM | No action. The opposite of tm/ln. Script is empty in Vitastor and Ceph. In other datastores, script may copy the image from VM host back to the datastore. |
|
||||
| tm/postbackup | Executed after backup | Seems that the script just removes temporary files after backup. Perform a VM backup and check that temporary files are cleaned up. |
|
||||
| tm/postbackup_live | Executed after backup of a running VM | Same as tm/postbackup, but for a running VM. |
|
||||
| tm/postmigrate | Executed after VM live migration | No action. Only executed for system datastore, so the script tries to call other TMs for other disks. Except that, the script does nothing in Vitastor and Ceph datastores. |
|
||||
| tm/prebackup | Actual backup script: backup VM disks | Set up "rsync" backup datastore → Backup a VM to it. |
|
||||
| tm/prebackup_live | Backup VM disks of a running VM | Same as tm/prebackup, but also does fsfreeze/thaw. So perform a live backup, restore it and check that disks are consistent. |
|
||||
| tm/premigrate | Executed before live migration | No action. Only executed for system datastore, so the script tries to call other TMs for other disks. Except that, the script does nothing in Vitastor and Ceph datastores. |
|
||||
| tm/resize | Resize a VM disk | Select a VM → Select a non-persistent disk → Resize. |
|
||||
| tm/restore | Restore VM disks from backup | Set up "rsync" backup datastore → Backup a VM to it → Restore it back. |
|
||||
| tm/snap_create | Create a VM disk snapshot | Select a VM → Select a disk → Create snapshot. |
|
||||
| tm/snap_create_live | Create a VM disk snapshot for a live VM | Select a running VM → Select a disk → Create snapshot. |
|
||||
| tm/snap_delete | Delete a VM disk snapshot | Select a VM → Select a disk → Select a snapshot → Delete. |
|
||||
| tm/snap_revert | Revert a VM disk to a snapshot | Select a VM → Select a disk → Select a snapshot → Revert. |
|
||||
|
|
@ -1,189 +0,0 @@
|
|||
[Документация](../../README-ru.md#документация) → Установка → OpenNebula
|
||||
|
||||
-----
|
||||
|
||||
[Read in English](opennebula.en.md)
|
||||
|
||||
# OpenNebula
|
||||
|
||||
## Автоматическая установка
|
||||
|
||||
Плагин OpenNebula Vitastor распространяется как Debian и RPM пакет `vitastor-opennebula`, начиная с версии Vitastor 1.9.0. Так что:
|
||||
|
||||
- Запустите `apt-get install vitastor-opennebula` или `yum install vitastor-opennebula` после установки OpenNebula на всех серверах
|
||||
- Проверьте, что он выводит "OK, Vitastor OpenNebula patches successfully applied" или "OK, Vitastor OpenNebula patches are already applied" в процессе установки
|
||||
- Если сообщение не выведено, пройдите по шагам инструкцию [Ручная установка](#ручная-установка) и примените правки файлов конфигурации вручную
|
||||
- Удостоверьтесь, что установлены версии QEMU и libvirt с изменениями Vitastor
|
||||
(`dpkg -l qemu-system-x86`, `dpkg -l | grep libvirt`, `rpm -qa | grep qemu`, `rpm -qa | grep qemu`, `rpm -qa | grep libvirt-libs` должны показывать "vitastor" в номере версии)
|
||||
- [Заблокируйте доступ виртуальных машин в Vitastor](#блокировка-доступа-вм-в-vitastor)
|
||||
|
||||
## Ручная установка
|
||||
|
||||
Сначала установите саму OpenNebula. После этого, на каждом сервере:
|
||||
|
||||
- Скопируйте директорию [opennebula/remotes](../../opennebula/remotes) в `/var/lib/one`: `cp -r opennebula/remotes /var/lib/one/`
|
||||
- Скопируйте директорию [opennebula/sudoers.d](../../opennebula/sudoers.d) в `/etc`: `cp -r opennebula/sudoers.d /etc/`
|
||||
- Примените патч [downloader-vitastor.sh.diff](../../opennebula/remotes/datastore/vitastor/downloader-vitastor.sh.diff) к `/var/lib/one/remotes/datastore/downloader.sh`:
|
||||
`patch /var/lib/one/remotes/datastore/downloader.sh < opennebula/remotes/datastore/vitastor/downloader-vitastor.sh.diff` - либо прочитайте патч и примените изменение вручную
|
||||
- Добавьте `kvm-vitastor` в список `LIVE_DISK_SNAPSHOTS` в файле `/etc/one/vmm_exec/vmm_execrc`
|
||||
- Если вы используете Debian или Ubuntu (и AppArmor), добавьте пути к файлу(ам) конфигурации Vitastor в файл `/etc/apparmor.d/local/abstractions/libvirt-qemu`: например,
|
||||
`echo ' "/etc/vitastor/vitastor.conf" r,' >> /etc/apparmor.d/local/abstractions/libvirt-qemu`
|
||||
- Примените изменения `/etc/one/oned.conf`
|
||||
|
||||
### Изменения oned.conf
|
||||
|
||||
1. Добавьте переопределение скрипта deploy в VM_MAD kvm, добавив `-l deploy.vitastor` в `ARGUMENTS`:
|
||||
|
||||
```diff
|
||||
VM_MAD = [
|
||||
NAME = "kvm",
|
||||
SUNSTONE_NAME = "KVM",
|
||||
EXECUTABLE = "one_vmm_exec",
|
||||
- ARGUMENTS = "-t 15 -r 0 kvm -p",
|
||||
+ ARGUMENTS = "-t 15 -r 0 kvm -p -l deploy=deploy.vitastor",
|
||||
DEFAULT = "vmm_exec/vmm_exec_kvm.conf",
|
||||
TYPE = "kvm",
|
||||
KEEP_SNAPSHOTS = "yes",
|
||||
LIVE_RESIZE = "yes",
|
||||
SUPPORT_SHAREABLE = "yes",
|
||||
IMPORTED_VMS_ACTIONS = "terminate, terminate-hard, hold, release, suspend,
|
||||
resume, delete, reboot, reboot-hard, resched, unresched, disk-attach,
|
||||
disk-detach, nic-attach, nic-detach, snapshot-create, snapshot-delete,
|
||||
resize, updateconf, update"
|
||||
]
|
||||
```
|
||||
|
||||
Опционально: если вы хотите также сохранять снимки памяти ВМ в Vitastor, добавьте
|
||||
`-l deploy=deploy.vitastor,save=save.vitastor,restore=restore.vitastor`
|
||||
вместо просто `-l deploy=deploy.vitastor`.
|
||||
|
||||
2. Добавьте `vitastor` в значения TM_MAD.ARGUMENTS и DATASTORE_MAD.ARGUMENTS:
|
||||
|
||||
```diff
|
||||
TM_MAD = [
|
||||
EXECUTABLE = "one_tm",
|
||||
- ARGUMENTS = "-t 15 -d dummy,lvm,shared,fs_lvm,fs_lvm_ssh,qcow2,ssh,ceph,dev,vcenter,iscsi_libvirt"
|
||||
+ ARGUMENTS = "-t 15 -d dummy,lvm,shared,fs_lvm,fs_lvm_ssh,qcow2,ssh,ceph,vitastor,dev,vcenter,iscsi_libvirt"
|
||||
]
|
||||
|
||||
DATASTORE_MAD = [
|
||||
EXECUTABLE = "one_datastore",
|
||||
- ARGUMENTS = "-t 15 -d dummy,fs,lvm,ceph,dev,iscsi_libvirt,vcenter,restic,rsync -s shared,ssh,ceph,fs_lvm,fs_lvm_ssh,qcow2,vcenter"
|
||||
+ ARGUMENTS = "-t 15 -d dummy,fs,lvm,ceph,vitastor,dev,iscsi_libvirt,vcenter,restic,rsync -s shared,ssh,ceph,vitastor,fs_lvm,fs_lvm_ssh,qcow2,vcenter"
|
||||
]
|
||||
```
|
||||
|
||||
3. Добавьте строчки с INHERIT_DATASTORE_ATTR для двух атрибутов Vitastor-хранилищ:
|
||||
|
||||
```
|
||||
INHERIT_DATASTORE_ATTR = "VITASTOR_CONF"
|
||||
INHERIT_DATASTORE_ATTR = "IMAGE_PREFIX"
|
||||
```
|
||||
|
||||
4. Добавьте TM_MAD_CONF и DS_MAD_CONF для Vitastor:
|
||||
|
||||
```
|
||||
TM_MAD_CONF = [
|
||||
NAME = "vitastor", LN_TARGET = "NONE", CLONE_TARGET = "SELF", SHARED = "YES",
|
||||
DS_MIGRATE = "NO", DRIVER = "raw", ALLOW_ORPHANS="format",
|
||||
TM_MAD_SYSTEM = "ssh,shared", LN_TARGET_SSH = "SYSTEM", CLONE_TARGET_SSH = "SYSTEM",
|
||||
DISK_TYPE_SSH = "FILE", LN_TARGET_SHARED = "NONE",
|
||||
CLONE_TARGET_SHARED = "SELF", DISK_TYPE_SHARED = "FILE"
|
||||
]
|
||||
|
||||
DS_MAD_CONF = [
|
||||
NAME = "vitastor",
|
||||
REQUIRED_ATTRS = "DISK_TYPE,BRIDGE_LIST",
|
||||
PERSISTENT_ONLY = "NO",
|
||||
MARKETPLACE_ACTIONS = "export"
|
||||
]
|
||||
```
|
||||
|
||||
## Создайте хранилища
|
||||
|
||||
Примеры настроек хранилищ образов (image) и дисков ВМ (system):
|
||||
[opennebula/vitastor-imageds.conf](../../opennebula/vitastor-imageds.conf) и
|
||||
[opennebula/vitastor-systemds.conf](../../opennebula/vitastor-systemds.conf).
|
||||
|
||||
Скопируйте настройки и поменяйте следующие параметры так, как вам необходимо:
|
||||
|
||||
- POOL_NAME - имя пула Vitastor для сохранения образов дисков.
|
||||
- IMAGE_PREFIX - строка, добавляемая в начало имён образов дисков.
|
||||
- BRIDGE_LIST - список серверов с доступом к кластеру Vitastor, используемых для операций с хранилищем образов (image, не system).
|
||||
- VITASTOR_CONF - путь к конфигурации Vitastor. Имейте в виду, что этот путь также надо добавить в `/etc/apparmor.d/local/abstractions/libvirt-qemu`, если вы используете AppArmor.
|
||||
- STAGING_DIR - путь к временному каталогу, используемому при импорте внешних образов. Должен иметь достаточно свободного места, чтобы вмещать скачанные образы.
|
||||
|
||||
После этого создайте хранилища с помощью команд `onedatastore create vitastor-imageds.conf` и `onedatastore create vitastor-systemds.conf` (либо через UI).
|
||||
|
||||
## Блокировка доступа ВМ в Vitastor
|
||||
|
||||
Vitastor пока не поддерживает никакую аутентификацию, так что вы ДОЛЖНЫ заблокировать доступ гостевых ВМ
|
||||
в кластер Vitastor на сетевом уровне.
|
||||
|
||||
Если вы используете VLAN-сети для ВМ - удостоверьтесь, что ВМ и гипервизор/сеть хранения помещены в разные
|
||||
изолированные друг от друга VLAN-ы.
|
||||
|
||||
Если вы используете что-то более примитивное, например, мосты (bridge), вам, скорее всего, придётся вручную
|
||||
настроить iptables / межсетевой экран, чтобы разрешить доступ к Vitastor только с IP гипервизоров.
|
||||
|
||||
Также в этом случае нужно будет переключить обычные мосты на "Bridged & Security Groups" и включить фильтр
|
||||
спуфинга IP в OpenNebula. Правда, реализация этого фильтра пока не полная, и она не блокирует доступ к
|
||||
локальным интерфейсам гипервизора. То есть, включённый фильтр спуфинга IP запрещает ВМ отправлять трафик
|
||||
с чужими IP к другим ВМ или во внешний мир, но не запрещает отправлять его напрямую гипервизору. Чтобы
|
||||
исправить это, тоже нужны дополнительные правила iptables.
|
||||
|
||||
Таким образом, более-менее полная блокировка при использовании простой сети на сетевых мостах может
|
||||
выглядеть так (здесь `10.0.3.0/24` - подсеть ВМ, `10.0.2.0/24` - подсеть гипервизора):
|
||||
|
||||
```
|
||||
# Разрешаем входящий трафик с физического устройства
|
||||
iptables -A INPUT -m physdev --physdev-in eth0 -j ACCEPT
|
||||
# Запрещаем трафик со всех ВМ, но с IP не из подсети ВМ
|
||||
iptables -A INPUT ! -s 10.0.3.0/24 -i onebr0 -j DROP
|
||||
# Запрещаем трафик от ВМ к сети гипервизора
|
||||
iptables -I FORWARD 1 -s 10.0.3.0/24 -d 10.0.2.0/24 -j DROP
|
||||
```
|
||||
|
||||
## Тестирование
|
||||
|
||||
Плагин OpenNebula по большей части состоит из bash-скриптов, и чтобы было понятнее, что они
|
||||
вообще делают - ниже приведены описания процедур, которыми можно протестировать каждый из них.
|
||||
|
||||
| Скрипт | Описание | Как протестировать |
|
||||
| ----------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------ |
|
||||
| vmm/kvm/deploy.vitastor | Запустить виртуальную машину | Создайте и запустите виртуальную машину с дисками Vitastor: постоянным / непостоянным / волатильным (временным). |
|
||||
| vmm/kvm/save.vitastor | Сохранить снимок памяти ВМ | Остановите виртуальную машину командой "Остановить". |
|
||||
| vmm/kvm/restore.vitastor| Восстановить снимок памяти ВМ | Запустите ВМ после остановки обратно. |
|
||||
| datastore/clone | Скопировать образ как "постоянный" | Создайте шаблон ВМ и создайте из него постоянную ВМ. |
|
||||
| datastore/cp | Импортировать внешний образ | Импортируйте шаблон ВМ с образами дисков из Магазина OpenNebula. |
|
||||
| datastore/export | Экспортировать образ как URL | Вероятно: экспортируйте шаблон ВМ с образами в Магазин. |
|
||||
| datastore/mkfs | Создать образ с файловой системой | Хранилище → Образы → Создать → Тип: базовый блок данных, Расположение: пустой образ диска, Файловая система: любая непустая. |
|
||||
| datastore/monitor | Вывод статистики места в хранилище образов | Проверьте статистику свободного/занятого места в списке хранилищ образов. |
|
||||
| datastore/rm | Удалить "постоянный" образ | Хранилище → Образы → Выберите образ → Удалить. |
|
||||
| datastore/snap_delete | Удалить снимок "постоянного" образа | Хранилище → Образы → Выберите образ → Выберите снимок → Удалить; <br> Чтобы создать образ со снимком: подключите постоянный образ к ВМ, создайте снимок, отключите образ. |
|
||||
| datastore/snap_flatten | Откатить образ к снимку, удалив другие снимки | Хранилище → Образы → Выберите образ → Выберите снимок → "Выровнять" (flatten). |
|
||||
| datastore/snap_revert | Откатить образ к снимку | Хранилище → Образы → Выберите образ → Выберите снимок → Откатить. |
|
||||
| datastore/stat | Показать виртуальный размер образа в МБ | Неизвестно. По-видимому, в плагинах Vitastor и Ceph не используется. |
|
||||
| tm/clone | Клонировать "непостоянный" образ в диск ВМ | Подключите "непостоянный" образ к ВМ. |
|
||||
| tm/context | Создать диск контекстуализации ВМ | Создайте ВМ с контекстуализацией, как обычно. Но тестировать особенно нечего: в плагинах Vitastor и Ceph образ контекста хранится в локальной ФС гипервизора. |
|
||||
| tm/cpds | Копировать диск ВМ/его снимок в новый образ | Выберите ВМ → Выберите диск → Опционально выберите снимок → "Сохранить как". |
|
||||
| tm/delete | Удалить диск-клон или волатильный диск ВМ | Отключите волатильный или не-постоянный диск от ВМ. |
|
||||
| tm/failmigrate | Обработать неудачную миграцию | Тестировать нечего. Скрипт пуст в плагинах Vitastor и Ceph. В других плагинах скрипт должен откатывать действия tm/premigrate. |
|
||||
| tm/ln | Подключить "постоянный" образ к ВМ | Тестировать нечего. Скрипт пуст в плагинах Vitastor и Ceph. |
|
||||
| tm/mkimage | Создать волатильный диск, без или с ФС | Подключите волатильный диск к ВМ, с или без файловой системы. |
|
||||
| tm/mkswap | Создать волатильный диск подкачки | Подключите волатильный диск к ВМ, форматированный как диск подкачки (swap). |
|
||||
| tm/monitor | Вывод статистики места в хранилище дисков ВМ | Проверьте статистику свободного/занятого места в списке хранилищ дисков ВМ. |
|
||||
| tm/mv | Мигрировать диск ВМ между хостами | Мигрируйте ВМ между серверами. Правда, с точки зрения хранилища в плагинах Vitastor и Ceph этот скрипт ничего не делает. |
|
||||
| tm/mvds | Отключить "постоянный" образ от ВМ | Тестировать нечего. Скрипт пуст в плагинах Vitastor и Ceph. В целом же скрипт обратный к tm/ln и в других хранилищах он может, например, копировать образ ВМ с диска гипервизора обратно в хранилище. |
|
||||
| tm/postbackup | Выполняется после бэкапа | По-видимому, скрипт просто удаляет временные файлы после резервного копирования. Так что можно провести его и проверить, что на серверах не осталось временных файлов. |
|
||||
| tm/postbackup_live | Выполняется после бэкапа запущенной ВМ | То же, что tm/postbackup, но для запущенной ВМ. |
|
||||
| tm/postmigrate | Выполняется после миграции ВМ | Тестировать нечего. Однако, OpenNebula запускает скрипт только для системного хранилища, поэтому он вызывает аналогичные скрипты для хранилищ других дисков той же ВМ. Помимо этого в плагинах Vitastor и Ceph скрипт ничего не делает. |
|
||||
| tm/prebackup | Выполнить резервное копирование дисков ВМ | Создайте хранилище резервных копий типа "rsync" → Забэкапьте в него ВМ. |
|
||||
| tm/prebackup_live | То же самое для запущенной ВМ | То же, что tm/prebackup, но запускает fsfreeze/thaw (остановку доступа к дискам). Так что смысл теста - проведите резервное копирование и проверьте, что данные скопировались консистентно. |
|
||||
| tm/premigrate | Выполняется перед миграцией ВМ | Тестировать нечего. Аналогично tm/postmigrate запускается только для системного хранилища. |
|
||||
| tm/resize | Изменить размер диска ВМ | Выберите ВМ → Выберите непостоянный диск → Измените его размер. |
|
||||
| tm/restore | Восстановить диски ВМ из бэкапа | Создайте хранилище резервных копий → Забэкапьте в него ВМ → Восстановите её обратно. |
|
||||
| tm/snap_create | Создать снимок диска ВМ | Выберите ВМ → Выберите диск → Создайте снимок. |
|
||||
| tm/snap_create_live | Создать снимок диска запущенной ВМ | Выберите запущенную ВМ → Выберите диск → Создайте снимок. |
|
||||
| tm/snap_delete | Удалить снимок диска ВМ | Выберите ВМ → Выберите диск → Выберите снимок → Удалить. |
|
||||
| tm/snap_revert | Откатить диск ВМ к снимку | Выберите ВМ → Выберите диск → Выберите снимок → Откатить. |
|
||||
|
|
@ -36,5 +36,5 @@ vitastor_pool_id = 1
|
|||
image_upload_use_cinder_backend = True
|
||||
```
|
||||
|
||||
To put Glance images in Vitastor, use [volume-backed images](https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html),
|
||||
To put Glance images in Vitastor, use [https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html](volume-backed images),
|
||||
although the support has not been verified yet.
|
||||
|
|
|
|||
|
|
@ -36,5 +36,5 @@ image_upload_use_cinder_backend = True
|
|||
```
|
||||
|
||||
Чтобы помещать в Vitastor Glance-образы, нужно использовать
|
||||
[образы на основе томов Cinder](https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html),
|
||||
[https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html](образы на основе томов Cinder),
|
||||
однако, поддержка этой функции ещё не проверялась.
|
||||
|
|
|
|||
|
|
@ -9,30 +9,26 @@
|
|||
## Debian
|
||||
|
||||
- Trust Vitastor package signing key:
|
||||
`wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg`
|
||||
`wget -q -O - https://vitastor.io/debian/pubkey | sudo apt-key add -`
|
||||
- Add Vitastor package repository to your /etc/apt/sources.list:
|
||||
- Debian 12 (Bookworm/Sid): `deb https://vitastor.io/debian bookworm main`
|
||||
- Debian 11 (Bullseye): `deb https://vitastor.io/debian bullseye main`
|
||||
- Debian 11 (Bullseye/Sid): `deb https://vitastor.io/debian bullseye main`
|
||||
- Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
|
||||
- Add `-oldstable` to bookworm/bullseye/buster in this line to install the last
|
||||
stable version from 0.9.x branch instead of 1.x
|
||||
- Install packages: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu-system-x86`
|
||||
- For Debian 10 (Buster) also enable backports repository:
|
||||
`deb http://deb.debian.org/debian buster-backports main`
|
||||
- Install packages: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu`
|
||||
|
||||
## CentOS
|
||||
|
||||
- Add Vitastor package repository:
|
||||
- CentOS 7: `yum install https://vitastor.io/rpms/centos/7/vitastor-release.rpm`
|
||||
- CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release.rpm`
|
||||
- AlmaLinux 9 and other RHEL 9 clones (Rocky, Oracle...): `dnf install https://vitastor.io/rpms/centos/9/vitastor-release.rpm`
|
||||
- CentOS 7: `yum install https://vitastor.io/rpms/centos/7/vitastor-release-1.0-1.el7.noarch.rpm`
|
||||
- CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release-1.0-1.el8.noarch.rpm`
|
||||
- Enable EPEL: `yum/dnf install epel-release`
|
||||
- Enable additional CentOS repositories:
|
||||
- CentOS 7: `yum install centos-release-scl`
|
||||
- CentOS 8: `dnf install centos-release-advanced-virtualization`
|
||||
- RHEL 9 clones: not required
|
||||
- Enable elrepo-kernel:
|
||||
- CentOS 7: `yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm`
|
||||
- CentOS 8: `dnf install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm`
|
||||
- RHEL 9 clones: `dnf install https://www.elrepo.org/elrepo-release-9.el9.elrepo.noarch.rpm`
|
||||
- Install packages: `yum/dnf install vitastor lpsolve etcd kernel-ml qemu-kvm`
|
||||
|
||||
## Installation requirements
|
||||
|
|
@ -46,10 +42,3 @@
|
|||
- etcd 3.4.15 or newer. Earlier versions won't work because of various bugs,
|
||||
for example [#12402](https://github.com/etcd-io/etcd/pull/12402).
|
||||
- node.js 10 or newer
|
||||
|
||||
## Version archive
|
||||
|
||||
All previous Vitastor and other components (QEMU, etcd...) package builds
|
||||
can be found here:
|
||||
|
||||
https://vitastor.io/archive/
|
||||
|
|
|
|||
|
|
@ -9,30 +9,26 @@
|
|||
## Debian
|
||||
|
||||
- Добавьте ключ репозитория Vitastor:
|
||||
`wget https://vitastor.io/debian/pubkey.gpg -O /etc/apt/trusted.gpg.d/vitastor.gpg`
|
||||
`wget -q -O - https://vitastor.io/debian/pubkey | sudo apt-key add -`
|
||||
- Добавьте репозиторий Vitastor в /etc/apt/sources.list:
|
||||
- Debian 12 (Bookworm/Sid): `deb https://vitastor.io/debian bookworm main`
|
||||
- Debian 11 (Bullseye): `deb https://vitastor.io/debian bullseye main`
|
||||
- Debian 11 (Bullseye/Sid): `deb https://vitastor.io/debian bullseye main`
|
||||
- Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
|
||||
- Добавьте `-oldstable` к слову bookworm/bullseye/buster в этой строке, чтобы
|
||||
установить последнюю стабильную версию из ветки 0.9.x вместо 1.x
|
||||
- Установите пакеты: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu-system-x86`
|
||||
- Для Debian 10 (Buster) также включите репозиторий backports:
|
||||
`deb http://deb.debian.org/debian buster-backports main`
|
||||
- Установите пакеты: `apt update; apt install vitastor lp-solve etcd linux-image-amd64 qemu`
|
||||
|
||||
## CentOS
|
||||
|
||||
- Добавьте в систему репозиторий Vitastor:
|
||||
- CentOS 7: `yum install https://vitastor.io/rpms/centos/7/vitastor-release.rpm`
|
||||
- CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release.rpm`
|
||||
- AlmaLinux 9 и другие клоны RHEL 9 (Rocky, Oracle...): `dnf install https://vitastor.io/rpms/centos/9/vitastor-release.rpm`
|
||||
- CentOS 7: `yum install https://vitastor.io/rpms/centos/7/vitastor-release-1.0-1.el7.noarch.rpm`
|
||||
- CentOS 8: `dnf install https://vitastor.io/rpms/centos/8/vitastor-release-1.0-1.el8.noarch.rpm`
|
||||
- Включите EPEL: `yum/dnf install epel-release`
|
||||
- Включите дополнительные репозитории CentOS:
|
||||
- CentOS 7: `yum install centos-release-scl`
|
||||
- CentOS 8: `dnf install centos-release-advanced-virtualization`
|
||||
- Клоны RHEL 9: не нужно
|
||||
- Включите elrepo-kernel:
|
||||
- CentOS 7: `yum install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm`
|
||||
- CentOS 8: `dnf install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm`
|
||||
- Клоны RHEL 9: `dnf install https://www.elrepo.org/elrepo-release-9.el9.elrepo.noarch.rpm`
|
||||
- Установите пакеты: `yum/dnf install vitastor lpsolve etcd kernel-ml qemu-kvm`
|
||||
|
||||
## Установочные требования
|
||||
|
|
@ -45,10 +41,3 @@
|
|||
- etcd 3.4.15 или новее. Более старые версии не будут работать из-за разных багов,
|
||||
например, [#12402](https://github.com/etcd-io/etcd/pull/12402).
|
||||
- node.js 10 или новее
|
||||
|
||||
## Архив предыдущих версий
|
||||
|
||||
Все предыдущие сборки пакетов Vitastor и других компонентов, таких, как QEMU
|
||||
и etcd, можно скачать по следующей ссылке:
|
||||
|
||||
https://vitastor.io/archive/
|
||||
|
|
|
|||
|
|
@ -6,10 +6,10 @@
|
|||
|
||||
# Proxmox VE
|
||||
|
||||
To enable Vitastor support in Proxmox Virtual Environment (6.4-8.1 are supported):
|
||||
To enable Vitastor support in Proxmox Virtual Environment (6.4 and 7.1 are supported):
|
||||
|
||||
- Add the corresponding Vitastor Debian repository into sources.list on Proxmox hosts:
|
||||
bookworm for 8.1, pve8.0 for 8.0, bullseye for 7.4, pve7.3 for 7.3, pve7.2 for 7.2, pve7.1 for 7.1, buster for 6.4
|
||||
- Add the corresponding Vitastor Debian repository into sources.list on Proxmox hosts
|
||||
(buster for 6.4, bullseye for 7.1)
|
||||
- Install vitastor-client, pve-qemu-kvm, pve-storage-vitastor (* or see note) packages from Vitastor repository
|
||||
- Define storage in `/etc/pve/storage.cfg` (see below)
|
||||
- Block network access from VMs to Vitastor network (to OSDs and etcd),
|
||||
|
|
@ -17,15 +17,15 @@ To enable Vitastor support in Proxmox Virtual Environment (6.4-8.1 are supported
|
|||
- Restart pvedaemon: `systemctl restart pvedaemon`
|
||||
|
||||
`/etc/pve/storage.cfg` example (the only required option is vitastor_pool, all others
|
||||
are listed below with their default values; `vitastor_ssd` is Proxmox storage pool id):
|
||||
are listed below with their default values):
|
||||
|
||||
```
|
||||
vitastor: vitastor_ssd
|
||||
vitastor: vitastor
|
||||
# pool to put new images into
|
||||
vitastor_pool testpool
|
||||
# path to the configuration file
|
||||
vitastor_config_path /etc/vitastor/vitastor.conf
|
||||
# etcd address(es), OPTIONAL, required only if missing in the configuration file
|
||||
# etcd address(es), required only if missing in the configuration file
|
||||
vitastor_etcd_address 192.168.7.2:2379/v3
|
||||
# prefix for keys in etcd
|
||||
vitastor_etcd_prefix /vitastor
|
||||
|
|
@ -35,5 +35,5 @@ vitastor: vitastor_ssd
|
|||
vitastor_nbd 0
|
||||
```
|
||||
|
||||
\* Note: you can also manually copy [patches/VitastorPlugin.pm](../../patches/VitastorPlugin.pm) to Proxmox hosts
|
||||
\* Note: you can also manually copy [patches/PVE_VitastorPlugin.pm](patches/PVE_VitastorPlugin.pm) to Proxmox hosts
|
||||
as `/usr/share/perl5/PVE/Storage/Custom/VitastorPlugin.pm` instead of installing pve-storage-vitastor.
|
||||
|
|
|
|||
|
|
@ -1,30 +1,30 @@
|
|||
[Документация](../../README-ru.md#документация) → Установка → Proxmox VE
|
||||
[Документация](../../README-ru.md#документация) → Установка → Proxmox
|
||||
|
||||
-----
|
||||
|
||||
[Read in English](proxmox.en.md)
|
||||
|
||||
# Proxmox VE
|
||||
# Proxmox
|
||||
|
||||
Чтобы подключить Vitastor к Proxmox Virtual Environment (поддерживаются версии 6.4-8.1):
|
||||
Чтобы подключить Vitastor к Proxmox Virtual Environment (поддерживаются версии 6.4 и 7.1):
|
||||
|
||||
- Добавьте соответствующий Debian-репозиторий Vitastor в sources.list на хостах Proxmox:
|
||||
bookworm для 8.1, pve8.0 для 8.0, bullseye для 7.4, pve7.3 для 7.3, pve7.2 для 7.2, pve7.1 для 7.1, buster для 6.4
|
||||
- Добавьте соответствующий Debian-репозиторий Vitastor в sources.list на хостах Proxmox
|
||||
(buster для 6.4, bullseye для 7.1)
|
||||
- Установите пакеты vitastor-client, pve-qemu-kvm, pve-storage-vitastor (* или см. сноску) из репозитория Vitastor
|
||||
- Определите тип хранилища в `/etc/pve/storage.cfg` (см. ниже)
|
||||
- Обязательно заблокируйте доступ от виртуальных машин к сети Vitastor (OSD и etcd), т.к. Vitastor (пока) не поддерживает аутентификацию
|
||||
- Перезапустите демон Proxmox: `systemctl restart pvedaemon`
|
||||
|
||||
Пример `/etc/pve/storage.cfg` (единственная обязательная опция - vitastor_pool, все остальные
|
||||
перечислены внизу для понимания значений по умолчанию; `vitastor_ssd` - имя хранилища в Proxmox):
|
||||
перечислены внизу для понимания значений по умолчанию):
|
||||
|
||||
```
|
||||
vitastor: vitastor_ssd
|
||||
vitastor: vitastor
|
||||
# Пул, в который будут помещаться образы дисков
|
||||
vitastor_pool testpool
|
||||
# Путь к файлу конфигурации
|
||||
vitastor_config_path /etc/vitastor/vitastor.conf
|
||||
# Адрес(а) etcd, ОПЦИОНАЛЬНЫ, нужны, только если не указаны в vitastor.conf
|
||||
# Адрес(а) etcd, нужны, только если не указаны в vitastor.conf
|
||||
vitastor_etcd_address 192.168.7.2:2379/v3
|
||||
# Префикс ключей метаданных в etcd
|
||||
vitastor_etcd_prefix /vitastor
|
||||
|
|
@ -35,5 +35,5 @@ vitastor: vitastor_ssd
|
|||
```
|
||||
|
||||
\* Примечание: вместо установки пакета pve-storage-vitastor вы можете вручную скопировать файл
|
||||
[patches/VitastorPlugin.pm](../../patches/VitastorPlugin.pm) на хосты Proxmox как
|
||||
[patches/PVE_VitastorPlugin.pm](patches/PVE_VitastorPlugin.pm) на хосты Proxmox как
|
||||
`/usr/share/perl5/PVE/Storage/Custom/VitastorPlugin.pm`.
|
||||
|
|
|
|||
|
|
@ -15,13 +15,12 @@
|
|||
- gcc and g++ 8 or newer, clang 10 or newer, or other compiler with C++11 plus
|
||||
designated initializers support from C++20
|
||||
- CMake
|
||||
- liburing, jerasure headers and libraries
|
||||
- ISA-L, libibverbs headers and libraries (optional)
|
||||
- liburing, jerasure headers
|
||||
- tcmalloc (google-perftools-dev)
|
||||
|
||||
## Basic instructions
|
||||
|
||||
Download source, for example using git: `git clone --recurse-submodules https://git.yourcmc.ru/vitalif/vitastor/`
|
||||
Download source, for example using git: `git clone --recurse-submodules https://yourcmc.ru/git/vitalif/vitastor/`
|
||||
|
||||
Get `fio` source and symlink it into `<vitastor>/fio`. If you don't want to build fio engine,
|
||||
you can disable it by passing `-DWITH_FIO=no` to cmake.
|
||||
|
|
@ -41,7 +40,7 @@ It's recommended to build the QEMU driver (qemu_driver.c) in-tree, as a part of
|
|||
QEMU build process. To do that:
|
||||
- Install vitastor client library headers (from source or from vitastor-client-dev package)
|
||||
- Take a corresponding patch from `patches/qemu-*-vitastor.patch` and apply it to QEMU source
|
||||
- Copy `src/client/qemu_driver.c` to QEMU source directory as `block/vitastor.c`
|
||||
- Copy `src/qemu_driver.c` to QEMU source directory as `block/block-vitastor.c`
|
||||
- Build QEMU as usual
|
||||
|
||||
But it is also possible to build it out-of-tree. To do that:
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue