Compare commits
1 Commits
Author | SHA1 | Date |
---|---|---|
Vitaliy Filippov | 83939f5a22 |
|
@ -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 -y install jq lp-solve sudo nfs-common
|
||||
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.9.2")
|
||||
set(VERSION "0.6.11")
|
||||
|
||||
add_subdirectory(src)
|
||||
|
|
671
README-ru.md
671
README-ru.md
|
@ -1,76 +1,631 @@
|
|||
# Vitastor
|
||||
## Vitastor
|
||||
|
||||
[Read English version](README.md)
|
||||
|
||||
## Идея
|
||||
|
||||
Вернём былую скорость кластерному блочному хранилищу!
|
||||
Я всего лишь хочу сделать качественную блочную SDS!
|
||||
|
||||
Vitastor - распределённая блочная и файловая SDS (программная СХД), прямой аналог Ceph RBD и CephFS,
|
||||
а также внутренних СХД популярных облачных провайдеров. Однако, в отличие от них, Vitastor
|
||||
быстрый и при этом простой. Только пока маленький :-).
|
||||
Vitastor - распределённая блочная SDS, прямой аналог Ceph RBD и внутренних СХД популярных
|
||||
облачных провайдеров. Однако, в отличие от них, Vitastor быстрый и при этом простой.
|
||||
Только пока маленький :-).
|
||||
|
||||
Vitastor архитектурно похож на Ceph, что означает атомарность и строгую консистентность,
|
||||
Архитектурная схожесть с Ceph означает заложенную на уровне алгоритмов записи строгую консистентность,
|
||||
репликацию через первичный OSD, симметричную кластеризацию без единой точки отказа
|
||||
и автоматическое распределение данных по любому числу дисков любого размера с настраиваемыми схемами
|
||||
избыточности - репликацией или с произвольными кодами коррекции ошибок.
|
||||
|
||||
Vitastor нацелен в первую очередь на SSD и SSD+HDD кластеры с как минимум 10 Гбит/с сетью, поддерживает
|
||||
TCP и RDMA и на хорошем железе может достигать задержки 4 КБ чтения и записи на уровне ~0.1 мс,
|
||||
что примерно в 10 раз быстрее, чем Ceph и другие популярные программные СХД.
|
||||
## Возможности
|
||||
|
||||
Vitastor поддерживает QEMU-драйвер, протоколы NBD и NFS, драйверы OpenStack, OpenNebula, Proxmox, Kubernetes.
|
||||
Другие драйверы могут также быть легко реализованы.
|
||||
Vitastor на данный момент находится в статусе предварительного выпуска, расширенные
|
||||
возможности пока отсутствуют, а в будущих версиях вероятны "ломающие" изменения.
|
||||
|
||||
Подробности смотрите в документации по ссылкам. Можете начать отсюда: [Быстрый старт](docs/intro/quickstart.ru.md).
|
||||
Однако следующее уже реализовано:
|
||||
|
||||
## Презентации и записи докладов
|
||||
- Базовая часть - надёжное кластерное блочное хранилище без единой точки отказа
|
||||
- Производительность ;-D
|
||||
- Несколько схем отказоустойчивости: репликация, XOR n+1 (1 диск чётности), коды коррекции ошибок
|
||||
Рида-Соломона на основе библиотеки jerasure с любым числом дисков данных и чётности в группе
|
||||
- Конфигурация через простые человекочитаемые JSON-структуры в etcd
|
||||
- Автоматическое распределение данных по OSD, с поддержкой:
|
||||
- Математической оптимизации для лучшей равномерности распределения и минимизации перемещений данных
|
||||
- Нескольких пулов с разными схемами избыточности
|
||||
- Дерева распределения, выбора OSD по тегам / классам устройств (только SSD, только HDD) и по поддереву
|
||||
- Настраиваемых доменов отказа (диск/сервер/стойка и т.п.)
|
||||
- Восстановление деградированных блоков
|
||||
- Ребаланс, то есть перемещение данных между OSD (дисками)
|
||||
- Поддержка "ленивого" fsync (fsync не на каждую операцию)
|
||||
- Сбор статистики ввода/вывода в etcd
|
||||
- Клиентская библиотека режима пользователя для ввода/вывода
|
||||
- Драйвер диска для QEMU (собирается вне дерева исходников QEMU)
|
||||
- Драйвер диска для утилиты тестирования производительности fio (также собирается вне дерева исходников fio)
|
||||
- NBD-прокси для монтирования образов ядром ("блочное устройство в режиме пользователя")
|
||||
- Утилита для удаления образов/инодов (vitastor-cli rm-data)
|
||||
- Пакеты для Debian и CentOS
|
||||
- Статистика операций ввода/вывода и занятого места в разрезе инодов
|
||||
- Именование инодов через хранение их метаданных в etcd
|
||||
- Снапшоты и copy-on-write клоны
|
||||
- Сглаживание производительности случайной записи в SSD+HDD конфигурациях
|
||||
- Поддержка RDMA/RoCEv2 через libibverbs
|
||||
- CSI-плагин для Kubernetes
|
||||
- Базовая поддержка OpenStack: драйвер Cinder, патчи для Nova и libvirt
|
||||
- Слияние снапшотов (vitastor-cli {snap-rm,flatten,merge})
|
||||
- Консольный интерфейс для управления образами (vitastor-cli {ls,create,modify})
|
||||
- Плагин для Proxmox
|
||||
|
||||
- DevOpsConf'2021: презентация ([на русском](https://vitastor.io/presentation/devopsconf/devopsconf.html),
|
||||
[на английском](https://vitastor.io/presentation/devopsconf/devopsconf_en.html)),
|
||||
[видео](https://vitastor.io/presentation/devopsconf/talk.webm)
|
||||
- Highload'2022: презентация ([на русском](https://vitastor.io/presentation/highload/highload.html)),
|
||||
[видео](https://vitastor.io/presentation/highload/talk.webm)
|
||||
## Планы развития
|
||||
|
||||
## Документация
|
||||
- Поддержка удаления снапшотов (слияния слоёв)
|
||||
- Более корректные скрипты разметки дисков и автоматического запуска OSD
|
||||
- Другие инструменты администрирования
|
||||
- Плагины для OpenNebula и других облачных систем
|
||||
- iSCSI-прокси
|
||||
- Более быстрое переключение при отказах
|
||||
- Фоновая проверка целостности без контрольных сумм (сверка реплик)
|
||||
- Контрольные суммы
|
||||
- Поддержка SSD-кэширования (tiered storage)
|
||||
- Поддержка NVDIMM
|
||||
- Web-интерфейс
|
||||
- Возможно, сжатие
|
||||
- Возможно, поддержка кэширования данных через системный page cache
|
||||
|
||||
- Введение
|
||||
- [Быстрый старт](docs/intro/quickstart.ru.md)
|
||||
- [Возможности](docs/intro/features.ru.md)
|
||||
- [Архитектура](docs/intro/architecture.ru.md)
|
||||
- [Автор и лицензия](docs/intro/author.ru.md)
|
||||
- Установка
|
||||
- [Пакеты](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)
|
||||
- Конфигурация
|
||||
- [Обзор](docs/config.ru.md)
|
||||
- Параметры
|
||||
- [Общие](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)
|
||||
- [Параметры мониторов](docs/config/monitor.ru.md)
|
||||
- [Настройки пулов](docs/config/pool.ru.md)
|
||||
- [Метаданные образов в 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)
|
||||
- Производительность
|
||||
- [Понимание сути производительности](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)
|
||||
## Архитектура
|
||||
|
||||
Так же, как и в Ceph, в Vitastor:
|
||||
|
||||
- Есть пулы (pools), PG, OSD, мониторы, домены отказа, дерево распределения (аналог crush-дерева).
|
||||
- Образы делятся на блоки фиксированного размера (объекты), и эти объекты распределяются по OSD.
|
||||
- У OSD есть журнал и метаданные и они тоже могут размещаться на отдельных быстрых дисках.
|
||||
- Все операции записи тоже транзакционны. В Vitastor, правда, есть режим отложенного/ленивого fsync
|
||||
(коммита), в котором fsync не вызывается на каждую операцию записи, что делает его более
|
||||
пригодным для использования на "плохих" (десктопных) SSD. Однако все операции записи
|
||||
в любом случае атомарны.
|
||||
- Клиентская библиотека тоже старается ждать восстановления после любого отказа кластера, то есть,
|
||||
вы тоже можете перезагрузить хоть весь кластер разом, и клиенты только на время зависнут,
|
||||
но не отключатся.
|
||||
|
||||
Некоторые базовые термины для тех, кто не знаком с Ceph:
|
||||
|
||||
- OSD (Object Storage Daemon) - процесс, который хранит данные на одном диске и обрабатывает
|
||||
запросы чтения/записи от клиентов.
|
||||
- Пул (Pool) - контейнер для данных, имеющих одну и ту же схему избыточности и правила распределения по OSD.
|
||||
- PG (Placement Group) - группа объектов, хранимых на одном и том же наборе реплик (OSD).
|
||||
Несколько PG могут храниться на одном и том же наборе реплик, но объекты одной PG
|
||||
в норме не хранятся на разных наборах OSD.
|
||||
- Монитор - демон, хранящий состояние кластера.
|
||||
- Домен отказа (Failure Domain) - группа OSD, которым вы разрешаете "упасть" всем вместе.
|
||||
Иными словами, это группа OSD, в которые СХД не помещает разные копии одного и того же
|
||||
блока данных. Например, если домен отказа - сервер, то на двух дисках одного сервера
|
||||
никогда не окажется 2 и более копий одного и того же блока данных, а значит, даже
|
||||
если в этом сервере откажут все диски, это будет равносильно потере только 1 копии
|
||||
любого блока данных.
|
||||
- Дерево распределения (Placement Tree / CRUSH Tree) - иерархическая группировка OSD
|
||||
в узлы, которые далее можно использовать как домены отказа. То есть, диск (OSD) входит в
|
||||
сервер, сервер входит в стойку, стойка входит в ряд, ряд в датацентр и т.п.
|
||||
|
||||
Чем Vitastor отличается от Ceph:
|
||||
|
||||
- Vitastor в первую очередь сфокусирован на SSD. Также Vitastor, вероятно, должен неплохо работать
|
||||
с комбинацией SSD и HDD через bcache, а в будущем, возможно, будут добавлены и нативные способы
|
||||
оптимизации под SSD+HDD. Однако хранилище на основе одних лишь жёстких дисков, вообще без SSD,
|
||||
не в приоритете, поэтому оптимизации под этот кейс могут вообще не состояться.
|
||||
- OSD Vitastor однопоточный и всегда таким останется, так как это самый оптимальный способ работы.
|
||||
Если вам не хватает 1 ядра на 1 диск, просто делите диск на разделы и запускайте на нём несколько OSD.
|
||||
Но, скорее всего, вам хватит и 1 ядра - Vitastor не так прожорлив к ресурсам CPU, как Ceph.
|
||||
- Журнал и метаданные всегда размещаются в памяти, благодаря чему никогда не тратится лишнее время
|
||||
на чтение метаданных с диска. Размер метаданных линейно зависит от размера диска и блока данных,
|
||||
который задаётся в конфигурации кластера и по умолчанию составляет 128 КБ. С блоком 128 КБ метаданные
|
||||
занимают примерно 512 МБ памяти на 1 ТБ дискового пространства (и это всё равно меньше, чем нужно Ceph-у).
|
||||
Журнал вообще не должен быть большим, например, тесты производительности в данном документе проводились
|
||||
с журналом размером всего 16 МБ. Большой журнал, вероятно, даже вреден, т.к. "грязные" записи (записи,
|
||||
не сброшенные из журнала) тоже занимают память и могут немного замедлять работу.
|
||||
- В Vitastor нет внутреннего copy-on-write. Я считаю, что реализация CoW-хранилища гораздо сложнее,
|
||||
поэтому сложнее добиться устойчиво хороших результатов. Возможно, в один прекрасный день
|
||||
я придумаю красивый алгоритм для CoW-хранилища, но пока нет - внутреннего CoW в Vitastor не будет.
|
||||
Всё это не относится к "внешнему" CoW (снапшотам и клонам).
|
||||
- Базовый слой Vitastor - простое блочное хранилище с блоками фиксированного размера, а не сложное
|
||||
объектное хранилище с расширенными возможностями, как в Ceph (RADOS).
|
||||
- В Vitastor есть режим "ленивых fsync", в котором OSD группирует запросы записи перед сбросом их
|
||||
на диск, что позволяет получить лучшую производительность с дешёвыми настольными SSD без конденсаторов
|
||||
("Advanced Power Loss Protection" / "Capacitor-Based Power Loss Protection").
|
||||
Тем не менее, такой режим всё равно медленнее использования нормальных серверных SSD и мгновенного
|
||||
fsync, так как приводит к дополнительным операциям передачи данных по сети, поэтому рекомендуется
|
||||
всё-таки использовать хорошие серверные диски, тем более, стоят они почти так же, как десктопные.
|
||||
- PG эфемерны. Это означает, что они не хранятся на дисках и существуют только в памяти работающих OSD.
|
||||
- Процессы восстановления оперируют отдельными объектами, а не целыми PG.
|
||||
- PGLOG-ов нет.
|
||||
- "Мониторы" не хранят данные. Конфигурация и состояние кластера хранятся в etcd в простых человекочитаемых
|
||||
JSON-структурах. Мониторы Vitastor только следят за состоянием кластера и управляют перемещением данных.
|
||||
В этом смысле монитор Vitastor не является критичным компонентом системы и больше похож на Ceph-овский
|
||||
менеджер (MGR). Монитор Vitastor написан на node.js.
|
||||
- Распределение PG не основано на консистентных хешах. Вместо этого все маппинги PG хранятся прямо в etcd
|
||||
(ибо нет никакой проблемы сохранить несколько сотен-тысяч записей в памяти, а не считать каждый раз хеши).
|
||||
Перераспределение PG по OSD выполняется через математическую оптимизацию,
|
||||
а конкретно, сведение задачи к ЛП (задаче линейного программирования) и решение оной с помощью утилиты
|
||||
lp_solve. Такой подход позволяет обычно выравнивать распределение места почти идеально - равномерность
|
||||
обычно составляет 96-99%, в отличие от Ceph, где на голом CRUSH-е без балансировщика обычно выходит 80-90%.
|
||||
Также это позволяет минимизировать объём перемещения данных и случайность связей между OSD, а также менять
|
||||
распределение вручную, не боясь сломать логику перебалансировки. В таком подходе есть и потенциальный
|
||||
недостаток - есть предположение, что в очень большом кластере он может сломаться - однако вплоть до
|
||||
нескольких сотен OSD подход точно работает нормально. Ну и, собственно, при необходимости легко
|
||||
реализовать и консистентные хеши.
|
||||
- Отдельный слой, подобный слою "CRUSH-правил", отсутствует. Вы настраиваете схемы отказоустойчивости,
|
||||
домены отказа и правила выбора OSD напрямую в конфигурации пулов.
|
||||
|
||||
## Понимание сути производительности систем хранения
|
||||
|
||||
Вкратце: для быстрой хранилки задержки важнее, чем пиковые iops-ы.
|
||||
|
||||
Лучшая возможная задержка достигается при тестировании в 1 поток с глубиной очереди 1,
|
||||
что приблизительно означает минимально нагруженное состояние кластера. В данном случае
|
||||
IOPS = 1/задержка. Ни числом серверов, ни дисков, ни серверных процессов/потоков
|
||||
задержка не масштабируется... Она зависит только от того, насколько быстро один
|
||||
серверный процесс (и клиент) обрабатывают одну операцию.
|
||||
|
||||
Почему задержки важны? Потому, что некоторые приложения *не могут* использовать глубину
|
||||
очереди больше 1, ибо их задача не параллелизуется. Важный пример - это все СУБД
|
||||
с поддержкой консистентности (ACID), потому что все они обеспечивают её через
|
||||
журналирование, а журналы пишутся последовательно и с fsync() после каждой операции.
|
||||
|
||||
fsync, кстати - это ещё одна очень важная вещь, про которую почти всегда забывают в тестах.
|
||||
Смысл в том, что все современные диски имеют кэши/буферы записи и не гарантируют, что
|
||||
данные реально физически записываются на носитель до того, как вы делаете fsync(),
|
||||
который транслируется в команду сброса кэша операционной системой.
|
||||
|
||||
Дешёвые SSD для настольных ПК и ноутбуков очень быстрые без fsync - NVMe диски, например,
|
||||
могут обработать порядка 80000 операций записи в секунду с глубиной очереди 1 без fsync.
|
||||
Однако с fsync, когда они реально вынуждены писать каждый блок данных во флеш-память,
|
||||
они выжимают лишь 1000-2000 операций записи в секунду (число практически постоянное
|
||||
для всех моделей SSD).
|
||||
|
||||
Серверные SSD часто имеют суперконденсаторы, работающие как встроенный источник
|
||||
бесперебойного питания и дающие дискам успеть сбросить их DRAM-кэш в постоянную
|
||||
флеш-память при отключении питания. Благодаря этому диски с чистой совестью
|
||||
*игнорируют fsync*, так как точно знают, что данные из кэша доедут до постоянной
|
||||
памяти.
|
||||
|
||||
Все наиболее известные программные СХД, например, Ceph и внутренние СХД, используемые
|
||||
такими облачными провайдерами, как Amazon, Google, Яндекс, медленные в смысле задержки.
|
||||
В лучшем случае они дают задержки от 0.3мс на чтение и 0.6мс на запись 4 КБ блоками
|
||||
даже при условии использования наилучшего возможного железа.
|
||||
|
||||
И это в эпоху SSD, когда вы можете пойти на рынок и купить там SSD, задержка которого
|
||||
на чтение будет 0.1мс, а на запись - 0.04мс, за 100$ или даже дешевле.
|
||||
|
||||
Когда мне нужно быстро протестировать производительность дисковой подсистемы, я
|
||||
использую следующие 6 команд, с небольшими вариациями:
|
||||
|
||||
- Линейная запись:
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=write -runtime=60 -filename=/dev/sdX`
|
||||
- Линейное чтение:
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=read -runtime=60 -filename=/dev/sdX`
|
||||
- Запись в 1 поток (T1Q1):
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -fsync=1 -rw=randwrite -runtime=60 -filename=/dev/sdX`
|
||||
- Чтение в 1 поток (T1Q1):
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randread -runtime=60 -filename=/dev/sdX`
|
||||
- Параллельная запись (numjobs используется, когда 1 ядро CPU не может насытить диск):
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 [-numjobs=4 -group_reporting] -rw=randwrite -runtime=60 -filename=/dev/sdX`
|
||||
- Параллельное чтение (numjobs - аналогично):
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 [-numjobs=4 -group_reporting] -rw=randread -runtime=60 -filename=/dev/sdX`
|
||||
|
||||
## Теоретическая максимальная производительность Vitastor
|
||||
|
||||
При использовании репликации:
|
||||
- Задержка чтения в 1 поток (T1Q1): 1 сетевой RTT + 1 чтение с диска.
|
||||
- Запись+fsync в 1 поток:
|
||||
- С мгновенным сбросом: 2 RTT + 1 запись.
|
||||
- С отложенным ("ленивым") сбросом: 4 RTT + 1 запись + 1 fsync.
|
||||
- Параллельное чтение: сумма IOPS всех дисков либо производительность сети, если в сеть упрётся раньше.
|
||||
- Параллельная запись: сумма IOPS всех дисков / число реплик / WA либо производительность сети, если в сеть упрётся раньше.
|
||||
|
||||
При использовании кодов коррекции ошибок (EC):
|
||||
- Задержка чтения в 1 поток (T1Q1): 1.5 RTT + 1 чтение.
|
||||
- Запись+fsync в 1 поток:
|
||||
- С мгновенным сбросом: 3.5 RTT + 1 чтение + 2 записи.
|
||||
- С отложенным ("ленивым") сбросом: 5.5 RTT + 1 чтение + 2 записи + 2 fsync.
|
||||
- Под 0.5 на самом деле подразумевается (k-1)/k, где k - число дисков данных,
|
||||
что означает, что дополнительное обращение по сети не нужно, когда операция
|
||||
чтения обслуживается локально.
|
||||
- Параллельное чтение: сумма IOPS всех дисков либо производительность сети, если в сеть упрётся раньше.
|
||||
- Параллельная запись: сумма IOPS всех дисков / общее число дисков данных и чётности / WA либо производительность сети, если в сеть упрётся раньше.
|
||||
Примечание: IOPS дисков в данном случае надо брать в смешанном режиме чтения/записи в пропорции, аналогичной формулам выше.
|
||||
|
||||
WA (мультипликатор записи) для 4 КБ блоков в Vitastor обычно составляет 3-5:
|
||||
1. Запись метаданных в журнал
|
||||
2. Запись блока данных в журнал
|
||||
3. Запись метаданных в БД
|
||||
4. Ещё одна запись метаданных в журнал при использовании EC
|
||||
5. Запись блока данных на диск данных
|
||||
|
||||
Если вы найдёте SSD, хорошо работающий с 512-байтными блоками данных (Optane?),
|
||||
то 1, 3 и 4 можно снизить до 512 байт (1/8 от размера данных) и получить WA всего 2.375.
|
||||
|
||||
Кроме того, WA снижается при использовании отложенного/ленивого сброса при параллельной
|
||||
нагрузке, т.к. блоки журнала записываются на диск только когда они заполняются или явным
|
||||
образом запрашивается fsync.
|
||||
|
||||
## Пример сравнения с Ceph
|
||||
|
||||
Железо - 4 сервера, в каждом:
|
||||
- 6x SATA SSD Intel D3-4510 3.84 TB
|
||||
- 2x Xeon Gold 6242 (16 cores @ 2.8 GHz)
|
||||
- 384 GB RAM
|
||||
- 1x 25 GbE сетевая карта (Mellanox ConnectX-4 LX), подключённая к свитчу Juniper QFX5200
|
||||
|
||||
Экономия энергии CPU отключена. В тестах и Vitastor, и Ceph развёрнуто по 2 OSD на 1 SSD.
|
||||
|
||||
Все результаты ниже относятся к случайной нагрузке 4 КБ блоками (если явно не указано обратное).
|
||||
|
||||
Производительность голых дисков:
|
||||
- T1Q1 запись ~27000 iops (задержка ~0.037ms)
|
||||
- T1Q1 чтение ~9800 iops (задержка ~0.101ms)
|
||||
- T1Q32 запись ~60000 iops
|
||||
- T1Q32 чтение ~81700 iops
|
||||
|
||||
Ceph 15.2.4 (Bluestore):
|
||||
- T1Q1 запись ~1000 iops (задержка ~1ms)
|
||||
- T1Q1 чтение ~1750 iops (задержка ~0.57ms)
|
||||
- T8Q64 запись ~100000 iops, потребление CPU процессами OSD около 40 ядер на каждом сервере
|
||||
- T8Q64 чтение ~480000 iops, потребление CPU процессами OSD около 40 ядер на каждом сервере
|
||||
|
||||
Тесты в 8 потоков проводились на 8 400GB RBD образах со всех хостов (с каждого хоста запускалось 2 процесса fio).
|
||||
Это нужно потому, что в Ceph несколько RBD-клиентов, пишущих в 1 образ, очень сильно замедляются.
|
||||
|
||||
Настройки RocksDB и Bluestore в Ceph не менялись, единственным изменением было отключение cephx_sign_messages.
|
||||
|
||||
На самом деле, результаты теста не такие уж и плохие для Ceph (могло быть хуже).
|
||||
Собственно говоря, эти серверы как раз хорошо сбалансированы для Ceph - 6 SATA SSD как раз
|
||||
утилизируют 25-гигабитную сеть, а без 2 мощных процессоров Ceph-у бы не хватило ядер,
|
||||
чтобы выдать пристойный результат. Собственно, что и показывает жор 40 ядер в процессе
|
||||
параллельного теста.
|
||||
|
||||
Vitastor:
|
||||
- T1Q1 запись: 7087 iops (задержка 0.14ms)
|
||||
- T1Q1 чтение: 6838 iops (задержка 0.145ms)
|
||||
- T2Q64 запись: 162000 iops, потребление CPU - 3 ядра на каждом сервере
|
||||
- T8Q64 чтение: 895000 iops, потребление CPU - 4 ядра на каждом сервере
|
||||
- Линейная запись (4M T1Q32): 2800 МБ/с
|
||||
- Линейное чтение (4M T1Q32): 1500 МБ/с
|
||||
|
||||
Тест на чтение в 8 потоков проводился на 1 большом образе (3.2 ТБ) со всех хостов (опять же, по 2 fio с каждого).
|
||||
В Vitastor никакой разницы между 1 образом и 8-ю нет. Естественно, примерно 1/4 запросов чтения
|
||||
в такой конфигурации, как и в тестах Ceph выше, обслуживалась с локальной машины. Если проводить
|
||||
тест так, чтобы все операции всегда обращались к первичным OSD по сети - тест сильнее упирался
|
||||
в сеть и результат составлял примерно 689000 iops.
|
||||
|
||||
Настройки Vitastor: `--disable_data_fsync true --immediate_commit all --flusher_count 8
|
||||
--disk_alignment 4096 --journal_block_size 4096 --meta_block_size 4096
|
||||
--journal_no_same_sector_overwrites true --journal_sector_buffer_count 1024
|
||||
--journal_size 16777216`.
|
||||
|
||||
### EC/XOR 2+1
|
||||
|
||||
Vitastor:
|
||||
- T1Q1 запись: 2808 iops (задержка ~0.355ms)
|
||||
- T1Q1 чтение: 6190 iops (задержка ~0.16ms)
|
||||
- T2Q64 запись: 85500 iops, потребление CPU - 3.4 ядра на каждом сервере
|
||||
- T8Q64 чтение: 812000 iops, потребление CPU - 4.7 ядра на каждом сервере
|
||||
- Линейная запись (4M T1Q32): 3200 МБ/с
|
||||
- Линейное чтение (4M T1Q32): 1800 МБ/с
|
||||
|
||||
Ceph:
|
||||
- T1Q1 запись: 730 iops (задержка ~1.37ms latency)
|
||||
- T1Q1 чтение: 1500 iops с холодным кэшем метаданных (задержка ~0.66ms), 2300 iops через 2 минуты прогрева (задержка ~0.435ms)
|
||||
- T4Q128 запись (4 RBD images): 45300 iops, потребление CPU - 30 ядер на каждом сервере
|
||||
- T8Q64 чтение (4 RBD images): 278600 iops, потребление CPU - 40 ядер на каждом сервере
|
||||
- Линейная запись (4M T1Q32): 1950 МБ/с в пустой образ, 2500 МБ/с в заполненный образ
|
||||
- Линейное чтение (4M T1Q32): 2400 МБ/с
|
||||
|
||||
### NBD
|
||||
|
||||
NBD расшифровывается как "сетевое блочное устройство", но на самом деле оно также
|
||||
работает просто как аналог FUSE для блочных устройств, то есть, представляет собой
|
||||
"блочное устройство в пространстве пользователя".
|
||||
|
||||
NBD - на данный момент единственный способ монтировать Vitastor ядром Linux.
|
||||
NBD немного снижает производительность, так как приводит к дополнительным копированиям
|
||||
данных между ядром и пространством пользователя. Тем не менее, способ достаточно оптимален,
|
||||
а производительность случайного доступа вообще затрагивается слабо.
|
||||
|
||||
Vitastor с однопоточной NBD прокси на том же стенде:
|
||||
- T1Q1 запись: 6000 iops (задержка 0.166ms)
|
||||
- T1Q1 чтение: 5518 iops (задержка 0.18ms)
|
||||
- T1Q128 запись: 94400 iops
|
||||
- T1Q128 чтение: 103000 iops
|
||||
- Линейная запись (4M T1Q128): 1266 МБ/с (в сравнении с 2800 МБ/с через fio)
|
||||
- Линейное чтение (4M T1Q128): 975 МБ/с (в сравнении с 1500 МБ/с через fio)
|
||||
|
||||
## Установка
|
||||
|
||||
### Debian
|
||||
|
||||
- Добавьте ключ репозитория Vitastor:
|
||||
`wget -q -O - https://vitastor.io/debian/pubkey | sudo apt-key add -`
|
||||
- Добавьте репозиторий Vitastor в /etc/apt/sources.list:
|
||||
- Debian 11 (Bullseye/Sid): `deb https://vitastor.io/debian bullseye main`
|
||||
- Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
|
||||
- Для 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-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`
|
||||
- Включите 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`
|
||||
- Установите пакеты: `yum/dnf install vitastor lpsolve etcd kernel-ml qemu-kvm`
|
||||
|
||||
### Установка из исходников
|
||||
|
||||
- Установите ядро 5.4 или более новое, для поддержки io_uring. Желательно 5.8 или даже новее,
|
||||
так как в 5.4 есть как минимум 1 известный баг, ведущий к зависанию с io_uring и контроллером HP SmartArray.
|
||||
- Установите liburing 0.4 или более новый и его заголовки.
|
||||
- Установите lp_solve.
|
||||
- Установите etcd, версии не ниже 3.4.15. Более ранние версии работать не будут из-за различных багов,
|
||||
например [#12402](https://github.com/etcd-io/etcd/pull/12402). Также вы можете взять версию 3.4.13 с
|
||||
этим конкретным исправлением из ветки release-3.4 репозитория https://github.com/vitalif/etcd/.
|
||||
- Установите node.js 10 или новее.
|
||||
- Установите gcc и g++ 8.x или новее.
|
||||
- Склонируйте данный репозиторий с подмодулями: `git clone https://yourcmc.ru/git/vitalif/vitastor/`.
|
||||
- Желательно пересобрать QEMU с патчем, который делает необязательным запуск через LD_PRELOAD.
|
||||
См `patches/qemu-*.*-vitastor.patch` - выберите версию, наиболее близкую вашей версии QEMU.
|
||||
- Установите QEMU 3.0 или новее, возьмите исходные коды установленного пакета, начните его пересборку,
|
||||
через некоторое время остановите её и скопируйте следующие заголовки:
|
||||
- `<qemu>/include` → `<vitastor>/qemu/include`
|
||||
- Debian:
|
||||
* Берите qemu из основного репозитория
|
||||
* `<qemu>/b/qemu/config-host.h` → `<vitastor>/qemu/b/qemu/config-host.h`
|
||||
* `<qemu>/b/qemu/qapi` → `<vitastor>/qemu/b/qemu/qapi`
|
||||
- CentOS 8:
|
||||
* Берите qemu из репозитория Advanced-Virtualization. Чтобы включить его, запустите
|
||||
`yum install centos-release-advanced-virtualization.noarch` и далее `yum install qemu`
|
||||
* `<qemu>/config-host.h` → `<vitastor>/qemu/b/qemu/config-host.h`
|
||||
* Для QEMU 3.0+: `<qemu>/qapi` → `<vitastor>/qemu/b/qemu/qapi`
|
||||
* Для QEMU 2.0+: `<qemu>/qapi-types.h` → `<vitastor>/qemu/b/qemu/qapi-types.h`
|
||||
- `config-host.h` и `qapi` нужны, т.к. в них содержатся автогенерируемые заголовки
|
||||
- Установите fio 3.7 или новее, возьмите исходники пакета и сделайте на них симлинк с `<vitastor>/fio`.
|
||||
- Соберите и установите Vitastor командой `mkdir build && cd build && cmake .. && make -j8 && make install`.
|
||||
Обратите внимание на переменную cmake `QEMU_PLUGINDIR` - под RHEL её нужно установить равной `qemu-kvm`.
|
||||
|
||||
## Запуск
|
||||
|
||||
Внимание: процедура пока что достаточно нетривиальная, задавать конфигурацию и смещения
|
||||
на диске нужно почти вручную. Это будет исправлено в ближайшем будущем.
|
||||
|
||||
- Желательны SATA SSD или NVMe диски с конденсаторами (серверные SSD). Можно использовать и
|
||||
десктопные SSD, включив режим отложенного fsync, но производительность однопоточной записи
|
||||
в этом случае пострадает.
|
||||
- Быстрая сеть, минимум 10 гбит/с
|
||||
- Для наилучшей производительности нужно отключить энергосбережение CPU: `cpupower idle-set -D 0 && cpupower frequency-set -g performance`.
|
||||
- На хостах мониторов:
|
||||
- Пропишите нужные вам значения в файле `/usr/lib/vitastor/mon/make-units.sh`
|
||||
- Создайте юниты systemd для etcd и мониторов: `/usr/lib/vitastor/mon/make-units.sh`
|
||||
- Пропишите etcd_address и osd_network в `/etc/vitastor/vitastor.conf`. Например:
|
||||
```
|
||||
{
|
||||
"etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"],
|
||||
"osd_network": "10.200.1.0/24"
|
||||
}
|
||||
```
|
||||
- Создайте юниты systemd для OSD: `/usr/lib/vitastor/make-osd.sh /dev/disk/by-partuuid/XXX [/dev/disk/by-partuuid/YYY ...]`
|
||||
- Вы можете менять параметры OSD в юнитах systemd или в `vitastor.conf`. Смысл некоторых параметров:
|
||||
- `disable_data_fsync 1` - отключает fsync, используется с SSD с конденсаторами.
|
||||
- `immediate_commit all` - используется с SSD с конденсаторами.
|
||||
Внимание: если установлено, также нужно установить его в то же значение в etcd в /vitastor/config/global
|
||||
- `disable_device_lock 1` - отключает блокировку файла устройства, нужно, только если вы запускаете
|
||||
несколько OSD на одном блочном устройстве.
|
||||
- `flusher_count 256` - "flusher" - микропоток, удаляющий старые данные из журнала.
|
||||
Не волнуйтесь об этой настройке, 256 теперь достаточно практически всегда.
|
||||
- `disk_alignment`, `journal_block_size`, `meta_block_size` следует установить равными размеру
|
||||
внутреннего блока SSD. Это почти всегда 4096.
|
||||
- `journal_no_same_sector_overwrites true` запрещает перезапись одного и того же сектора журнала подряд
|
||||
много раз в процессе записи. Большинство (99%) SSD не нуждаются в данной опции. Однако выяснилось, что
|
||||
диски, используемые на одном из тестовых стендов - Intel D3-S4510 - очень сильно не любят такую
|
||||
перезапись, и для них была добавлена эта опция. Когда данный режим включён, также нужно поднимать
|
||||
значение `journal_sector_buffer_count`, так как иначе Vitastor не хватит буферов для записи в журнал.
|
||||
- Запустите все etcd: `systemctl start etcd`
|
||||
- Создайте глобальную конфигурацию в etcd: `etcdctl --endpoints=... put /vitastor/config/global '{"immediate_commit":"all"}'`
|
||||
(если все ваши диски - серверные с конденсаторами).
|
||||
- Создайте пулы: `etcdctl --endpoints=... put /vitastor/config/pools '{"1":{"name":"testpool","scheme":"replicated","pg_size":2,"pg_minsize":1,"pg_count":256,"failure_domain":"host"}}'`.
|
||||
Для jerasure EC-пулов конфигурация должна выглядеть так: `2:{"name":"ecpool","scheme":"jerasure","pg_size":4,"parity_chunks":2,"pg_minsize":2,"pg_count":256,"failure_domain":"host"}`.
|
||||
- Запустите все OSD: `systemctl start vitastor.target`
|
||||
- Ваш кластер должен быть готов - один из мониторов должен уже сконфигурировать PG, а OSD должны запустить их.
|
||||
- Вы можете проверить состояние PG прямо в etcd: `etcdctl --endpoints=... get --prefix /vitastor/pg/state`. Все PG должны быть 'active'.
|
||||
|
||||
### Задать имя образу
|
||||
|
||||
```
|
||||
etcdctl --endpoints=<etcd> put /vitastor/config/inode/<pool>/<inode> '{"name":"<name>","size":<size>[,"parent_id":<parent_inode_number>][,"readonly":true]}'
|
||||
```
|
||||
|
||||
Например:
|
||||
|
||||
```
|
||||
etcdctl --endpoints=http://10.115.0.10:2379/v3 put /vitastor/config/inode/1/1 '{"name":"testimg","size":2147483648}'
|
||||
```
|
||||
|
||||
Если вы зададите parent_id, то образ станет CoW-клоном, т.е. все новые запросы записи пойдут в новый инод, а запросы
|
||||
чтения будут проверять сначала его, а потом родительские слои по цепочке вверх. Чтобы случайно не перезаписать данные
|
||||
в родительском слое, вы можете переключить его в режим "только чтение", добавив флаг `"readonly":true` в его запись
|
||||
метаданных. В таком случае родительский образ становится просто снапшотом.
|
||||
|
||||
Таким образом, для создания снапшота вам нужно просто переименовать предыдущий inode (например, из testimg в testimg@0),
|
||||
сделать его readonly и создать новый слой с исходным именем образа (testimg), ссылающийся на только что переименованный
|
||||
в качестве родительского.
|
||||
|
||||
### Запуск тестов с fio
|
||||
|
||||
Пример команды для запуска тестов:
|
||||
|
||||
```
|
||||
fio -thread -ioengine=libfio_vitastor.so -name=test -bs=4M -direct=1 -iodepth=16 -rw=write -etcd=10.115.0.10:2379/v3 -image=testimg
|
||||
```
|
||||
|
||||
Если вы не хотите обращаться к образу по имени, вместо `-image=testimg` можно указать номер пула, номер инода и размер:
|
||||
`-pool=1 -inode=1 -size=400G`.
|
||||
|
||||
### Загрузить образ диска ВМ в/из Vitastor
|
||||
|
||||
Используйте qemu-img и строку `vitastor:etcd_host=<HOST>:image=<IMAGE>` в качестве имени файла диска. Например:
|
||||
|
||||
```
|
||||
qemu-img convert -f qcow2 debian10.qcow2 -p -O raw 'vitastor:etcd_host=10.115.0.10\:2379/v3:image=testimg'
|
||||
```
|
||||
|
||||
Обратите внимание, что если вы используете немодифицированный QEMU, потребуется установить переменную окружения
|
||||
`LD_PRELOAD=/usr/lib/x86_64-linux-gnu/qemu/block-vitastor.so`.
|
||||
|
||||
Если вы не хотите обращаться к образу по имени, вместо `:image=<IMAGE>` можно указать номер пула, номер инода и размер:
|
||||
`:pool=<POOL>:inode=<INODE>:size=<SIZE>`.
|
||||
|
||||
### Запустить ВМ
|
||||
|
||||
Для запуска QEMU используйте опцию `-drive file=vitastor:etcd_host=<HOST>:image=<IMAGE>` (аналогично qemu-img)
|
||||
и физический размер блока 4 KB.
|
||||
|
||||
Например:
|
||||
|
||||
```
|
||||
qemu-system-x86_64 -enable-kvm -m 1024
|
||||
-drive 'file=vitastor:etcd_host=10.115.0.10\:2379/v3:image=testimg',format=raw,if=none,id=drive-virtio-disk0,cache=none
|
||||
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=off,physical_block_size=4096,logical_block_size=512
|
||||
-vnc 0.0.0.0:0
|
||||
```
|
||||
|
||||
Обращение по номерам (`:pool=<POOL>:inode=<INODE>:size=<SIZE>` вместо `:image=<IMAGE>`) работает аналогично qemu-img.
|
||||
|
||||
### Удалить образ
|
||||
|
||||
Используйте утилиту vitastor-cli rm-data. Например:
|
||||
|
||||
```
|
||||
vitastor-cli rm-data --etcd_address 10.115.0.10:2379/v3 --pool 1 --inode 1 --parallel_osds 16 --iodepth 32
|
||||
```
|
||||
|
||||
### NBD
|
||||
|
||||
Чтобы создать локальное блочное устройство, используйте NBD. Например:
|
||||
|
||||
```
|
||||
vitastor-nbd map --etcd_address 10.115.0.10:2379/v3 --image testimg
|
||||
```
|
||||
|
||||
Команда напечатает название устройства вида /dev/nbd0, которое потом можно будет форматировать
|
||||
и использовать как обычное блочное устройство.
|
||||
|
||||
Для обращения по номеру инода, аналогично другим командам, можно использовать опции
|
||||
`--pool <POOL> --inode <INODE> --size <SIZE>` вместо `--image testimg`.
|
||||
|
||||
### Kubernetes
|
||||
|
||||
У Vitastor есть CSI-плагин для Kubernetes, поддерживающий RWO-тома.
|
||||
|
||||
Для установки возьмите манифесты из директории [csi/deploy/](csi/deploy/), поместите
|
||||
вашу конфигурацию подключения к Vitastor в [csi/deploy/001-csi-config-map.yaml](001-csi-config-map.yaml),
|
||||
настройте StorageClass в [csi/deploy/009-storage-class.yaml](009-storage-class.yaml)
|
||||
и примените все `NNN-*.yaml` к вашей инсталляции Kubernetes.
|
||||
|
||||
```
|
||||
for i in ./???-*.yaml; do kubectl apply -f $i; done
|
||||
```
|
||||
|
||||
После этого вы сможете создавать PersistentVolume. Пример смотрите в файле [csi/deploy/example-pvc.yaml](csi/deploy/example-pvc.yaml).
|
||||
|
||||
### OpenStack
|
||||
|
||||
Чтобы подключить Vitastor к OpenStack:
|
||||
|
||||
- Установите пакеты vitastor-client, libvirt и QEMU из DEB или RPM репозитория Vitastor
|
||||
- Примените патч `patches/nova-21.diff` или `patches/nova-23.diff` к вашей инсталляции Nova.
|
||||
nova-21.diff подходит для Nova 21-22, nova-23.diff подходит для Nova 23-24.
|
||||
- Скопируйте `patches/cinder-vitastor.py` в инсталляцию Cinder как `cinder/volume/drivers/vitastor.py`
|
||||
- Создайте тип томов в cinder.conf (см. ниже)
|
||||
- Обязательно заблокируйте доступ от виртуальных машин к сети Vitastor (OSD и etcd), т.к. Vitastor (пока) не поддерживает аутентификацию
|
||||
- Перезапустите Cinder и Nova
|
||||
|
||||
Пример конфигурации Cinder:
|
||||
|
||||
```
|
||||
[DEFAULT]
|
||||
enabled_backends = lvmdriver-1, vitastor-testcluster
|
||||
# ...
|
||||
|
||||
[vitastor-testcluster]
|
||||
volume_driver = cinder.volume.drivers.vitastor.VitastorDriver
|
||||
volume_backend_name = vitastor-testcluster
|
||||
image_volume_cache_enabled = True
|
||||
volume_clear = none
|
||||
vitastor_etcd_address = 192.168.7.2:2379
|
||||
vitastor_etcd_prefix =
|
||||
vitastor_config_path = /etc/vitastor/vitastor.conf
|
||||
vitastor_pool_id = 1
|
||||
image_upload_use_cinder_backend = True
|
||||
```
|
||||
|
||||
Чтобы помещать в Vitastor Glance-образы, нужно использовать
|
||||
[https://docs.openstack.org/cinder/pike/admin/blockstorage-volume-backed-image.html](образы на основе томов Cinder),
|
||||
однако, поддержка этой функции ещё не проверялась.
|
||||
|
||||
### Proxmox
|
||||
|
||||
Чтобы подключить Vitastor к Proxmox Virtual Environment (поддерживаются версии 6.4 и 7.1):
|
||||
|
||||
- Добавьте соответствующий 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: vitastor
|
||||
# Пул, в который будут помещаться образы дисков
|
||||
vitastor_pool testpool
|
||||
# Путь к файлу конфигурации
|
||||
vitastor_config_path /etc/vitastor/vitastor.conf
|
||||
# Адрес(а) etcd, нужны, только если не указаны в vitastor.conf
|
||||
vitastor_etcd_address 192.168.7.2:2379/v3
|
||||
# Префикс ключей метаданных в etcd
|
||||
vitastor_etcd_prefix /vitastor
|
||||
# Префикс имён образов
|
||||
vitastor_prefix pve/
|
||||
# Монтировать образы через NBD прокси, через ядро (нужно только для контейнеров)
|
||||
vitastor_nbd 0
|
||||
```
|
||||
|
||||
\* Примечание: вместо установки пакета pve-storage-vitastor вы можете вручную скопировать файл
|
||||
[patches/PVE_VitastorPlugin.pm](patches/PVE_VitastorPlugin.pm) на хосты Proxmox как
|
||||
`/usr/share/perl5/PVE/Storage/Custom/VitastorPlugin.pm`.
|
||||
|
||||
## Известные проблемы
|
||||
|
||||
- Запросы удаления объектов могут в данный момент приводить к "неполным" объектам в EC-пулах,
|
||||
если в процессе удаления произойдут отказы OSD или серверов, потому что правильная обработка
|
||||
запросов удаления в кластере должна быть "трёхфазной", а это пока не реализовано. Если вы
|
||||
столкнётесь с такой ситуацией, просто повторите запрос удаления.
|
||||
|
||||
## Принципы реализации
|
||||
|
||||
- Я люблю архитектурно простые решения. Vitastor проектируется именно так и я намерен
|
||||
и далее следовать данному принципу.
|
||||
- Если вы пришли сюда за идеальным кодом на C++, вы, вероятно, не по адресу. "Общепринятые"
|
||||
практики написания C++ кода меня не очень волнуют, так как зачастую, опять-таки, ведут к
|
||||
излишним усложнениям и код получается красивый... но медленный.
|
||||
- По той же причине в коде иногда можно встретить велосипеды типа собственного упрощённого
|
||||
HTTP-клиента для работы с etcd. Зато эти велосипеды маленькие и компактные и не требуют
|
||||
использования десятка внешних библиотек.
|
||||
- node.js для монитора - не случайный выбор. Он очень быстрый, имеет встроенную событийную
|
||||
машину, приятный нейтральный C-подобный язык программирования и развитую инфраструктуру.
|
||||
|
||||
## Автор и лицензия
|
||||
|
||||
|
@ -101,5 +656,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).
|
||||
|
|
621
README.md
621
README.md
|
@ -1,76 +1,579 @@
|
|||
# Vitastor
|
||||
## Vitastor
|
||||
|
||||
[Читать на русском](README-ru.md)
|
||||
|
||||
## The Idea
|
||||
|
||||
Make Clustered Block Storage Fast Again.
|
||||
Make Software-Defined Block Storage Great 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 small, simple and fast clustered block storage (storage for VM drives),
|
||||
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 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).
|
||||
## Features
|
||||
|
||||
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
|
||||
with proper hardware which is ~10 times faster than other popular SDS's like Ceph
|
||||
or internal systems of public clouds.
|
||||
Vitastor is currently a pre-release, a lot of features are missing and you can still expect
|
||||
breaking changes in the future. However, the following is implemented:
|
||||
|
||||
Vitastor supports QEMU, NBD, NFS protocols, OpenStack, OpenNebula, Proxmox, Kubernetes drivers.
|
||||
More drivers may be created easily.
|
||||
- Basic part: highly-available block storage with symmetric clustering and no SPOF
|
||||
- Performance ;-D
|
||||
- Multiple redundancy schemes: Replication, XOR n+1, Reed-Solomon erasure codes
|
||||
based on jerasure library with any number of data and parity drives in a group
|
||||
- Configuration via simple JSON data structures in etcd
|
||||
- Automatic data distribution over OSDs, with support for:
|
||||
- Mathematical optimization for better uniformity and less data movement
|
||||
- Multiple pools
|
||||
- Placement tree, OSD selection by tags (device classes) and placement root
|
||||
- Configurable failure domains
|
||||
- Recovery of degraded blocks
|
||||
- Rebalancing (data movement between OSDs)
|
||||
- Lazy fsync support
|
||||
- I/O statistics reporting to etcd
|
||||
- Generic user-space client library
|
||||
- QEMU driver (built out-of-tree)
|
||||
- Loadable fio engine for benchmarks (also built out-of-tree)
|
||||
- NBD proxy for kernel mounts
|
||||
- Inode removal tool (vitastor-cli rm-data)
|
||||
- Packaging for Debian and CentOS
|
||||
- Per-inode I/O and space usage statistics
|
||||
- Inode metadata storage in etcd
|
||||
- Snapshots and copy-on-write image clones
|
||||
- Write throttling to smooth random write workloads in SSD+HDD configurations
|
||||
- RDMA/RoCEv2 support via libibverbs
|
||||
- CSI plugin for Kubernetes
|
||||
- Basic OpenStack support: Cinder driver, Nova and libvirt patches
|
||||
- Snapshot merge tool (vitastor-cli {snap-rm,flatten,merge})
|
||||
- Image management CLI (vitastor-cli {ls,create,modify})
|
||||
- Proxmox storage plugin
|
||||
|
||||
Read more details in the documentation. You can start from here: [Quick Start](docs/intro/quickstart.en.md).
|
||||
## Roadmap
|
||||
|
||||
## Talks and presentations
|
||||
- Snapshot deletion (layer merge) support
|
||||
- Better OSD creation and auto-start tools
|
||||
- Other administrative tools
|
||||
- Plugins for OpenNebula, Proxmox and other cloud systems
|
||||
- iSCSI proxy
|
||||
- Faster failover
|
||||
- Scrubbing without checksums (verification of replicas)
|
||||
- Checksums
|
||||
- Tiered storage
|
||||
- NVDIMM support
|
||||
- Web GUI
|
||||
- Compression (possibly)
|
||||
- Read caching using system page cache (possibly)
|
||||
|
||||
- DevOpsConf'2021: presentation ([in Russian](https://vitastor.io/presentation/devopsconf/devopsconf.html),
|
||||
[in English](https://vitastor.io/presentation/devopsconf/devopsconf_en.html)),
|
||||
[video](https://vitastor.io/presentation/devopsconf/talk.webm)
|
||||
- Highload'2022: presentation ([in Russian](https://vitastor.io/presentation/highload/highload.html)),
|
||||
[video](https://vitastor.io/presentation/highload/talk.webm)
|
||||
## Architecture
|
||||
|
||||
## Documentation
|
||||
Similarities:
|
||||
|
||||
- Introduction
|
||||
- [Quick Start](docs/intro/quickstart.en.md)
|
||||
- [Features](docs/intro/features.en.md)
|
||||
- [Architecture](docs/intro/architecture.en.md)
|
||||
- [Author and license](docs/intro/author.en.md)
|
||||
- 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)
|
||||
- Configuration
|
||||
- [Overview](docs/config.en.md)
|
||||
- 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)
|
||||
- [Monitor](docs/config/monitor.en.md)
|
||||
- [Pool configuration](docs/config/pool.en.md)
|
||||
- [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)
|
||||
- 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)
|
||||
- Just like Ceph, Vitastor has Pools, PGs, OSDs, Monitors, Failure Domains, Placement Tree.
|
||||
- Just like Ceph, Vitastor is transactional (even though there's a "lazy fsync mode" which
|
||||
doesn't implicitly flush every operation to disks).
|
||||
- OSDs also have journal and metadata and they can also be put on separate drives.
|
||||
- Just like in Ceph, client library attempts to recover from any cluster failure so
|
||||
you can basically reboot the whole cluster and only pause, but not crash, your clients
|
||||
(I consider this a bug if the client crashes in that case).
|
||||
|
||||
Some basic terms for people not familiar with Ceph:
|
||||
|
||||
- OSD (Object Storage Daemon) is a process that stores data and serves read/write requests.
|
||||
- PG (Placement Group) is a container for data that (normally) shares the same replicas.
|
||||
- Pool is a container for data that has the same redundancy scheme and placement rules.
|
||||
- Monitor is a separate daemon that watches cluster state and handles failures.
|
||||
- Failure Domain is a group of OSDs that you allow to fail. It's "host" by default.
|
||||
- Placement Tree groups OSDs in a hierarchy to later split them into Failure Domains.
|
||||
|
||||
Architectural differences from Ceph:
|
||||
|
||||
- Vitastor's primary focus is on SSDs. Proper SSD+HDD optimizations may be added in the future, though.
|
||||
- Vitastor OSD is (and will always be) single-threaded. If you want to dedicate more than 1 core
|
||||
per drive you should run multiple OSDs each on a different partition of the drive.
|
||||
Vitastor isn't CPU-hungry though (as opposed to Ceph), so 1 core is sufficient in a lot of cases.
|
||||
- Metadata and journal are always kept in memory. Metadata size depends linearly on drive capacity
|
||||
and data store block size which is 128 KB by default. With 128 KB blocks metadata should occupy
|
||||
around 512 MB per 1 TB (which is still less than Ceph wants). Journal doesn't have to be big,
|
||||
the example test below was conducted with only 16 MB journal. A big journal is probably even
|
||||
harmful as dirty write metadata also take some memory.
|
||||
- Vitastor storage layer doesn't have internal copy-on-write or redirect-write. I know that maybe
|
||||
it's possible to create a good copy-on-write storage, but it's much harder and makes performance
|
||||
less deterministic, so CoW isn't used in Vitastor.
|
||||
- The basic layer of Vitastor is block storage with fixed-size blocks, not object storage with
|
||||
rich semantics like in Ceph (RADOS).
|
||||
- There's a "lazy fsync" mode which allows to batch writes before flushing them to the disk.
|
||||
This allows to use Vitastor with desktop SSDs, but still lowers performance due to additional
|
||||
network roundtrips, so use server SSDs with capacitor-based power loss protection
|
||||
("Advanced Power Loss Protection") for best performance.
|
||||
- PGs are ephemeral. This means that they aren't stored on data disks and only exist in memory
|
||||
while OSDs are running.
|
||||
- Recovery process is per-object (per-block), not per-PG. Also there are no PGLOGs.
|
||||
- Monitors don't store data. Cluster configuration and state is stored in etcd in simple human-readable
|
||||
JSON structures. Monitors only watch cluster state and handle data movement.
|
||||
Thus Vitastor's Monitor isn't a critical component of the system and is more similar to Ceph's Manager.
|
||||
Vitastor's Monitor is implemented in node.js.
|
||||
- PG distribution isn't based on consistent hashes. All PG mappings are stored in etcd.
|
||||
Rebalancing PGs between OSDs is done by mathematical optimization - data distribution problem
|
||||
is reduced to a linear programming problem and solved by lp_solve. This allows for almost
|
||||
perfect (96-99% uniformity compared to Ceph's 80-90%) data distribution in most cases, ability
|
||||
to map PGs by hand without breaking rebalancing logic, reduced OSD peer-to-peer communication
|
||||
(on average, OSDs have fewer peers) and less data movement. It also probably has a drawback -
|
||||
this method may fail in very large clusters, but up to several hundreds of OSDs it's perfectly fine.
|
||||
It's also easy to add consistent hashes in the future if something proves their necessity.
|
||||
- There's no separate CRUSH layer. You select pool redundancy scheme, placement root, failure domain
|
||||
and so on directly in pool configuration.
|
||||
|
||||
## Understanding Storage Performance
|
||||
|
||||
The most important thing for fast storage is latency, not parallel iops.
|
||||
|
||||
The best possible latency is achieved with one thread and queue depth of 1 which basically means
|
||||
"client load as low as possible". In this case IOPS = 1/latency, and this number doesn't
|
||||
scale with number of servers, drives, server processes or threads and so on.
|
||||
Single-threaded IOPS and latency numbers only depend on *how fast a single daemon is*.
|
||||
|
||||
Why is it important? It's important because some of the applications *can't* use
|
||||
queue depth greater than 1 because their task isn't parallelizable. A notable example
|
||||
is any ACID DBMS because all of them write their WALs sequentially with fsync()s.
|
||||
|
||||
fsync, by the way, is another important thing often missing in benchmarks. The point is
|
||||
that drives have cache buffers and don't guarantee that your data is actually persisted
|
||||
until you call fsync() which is translated to a FLUSH CACHE command by the OS.
|
||||
|
||||
Desktop SSDs are very fast without fsync - NVMes, for example, can process ~80000 write
|
||||
operations per second with queue depth of 1 without fsync - but they're really slow with
|
||||
fsync because they have to actually write data to flash chips when you call fsync. Typical
|
||||
number is around 1000-2000 iops with fsync.
|
||||
|
||||
Server SSDs often have supercapacitors that act as a built-in UPS and allow the drive
|
||||
to flush its DRAM cache to the persistent flash storage when a power loss occurs.
|
||||
This makes them perform equally well with and without fsync. This feature is called
|
||||
"Advanced Power Loss Protection" by Intel; other vendors either call it similarly
|
||||
or directly as "Full Capacitor-Based Power Loss Protection".
|
||||
|
||||
All software-defined storages that I currently know are slow in terms of latency.
|
||||
Notable examples are Ceph and internal SDSes used by cloud providers like Amazon, Google,
|
||||
Yandex and so on. They're all slow and can only reach ~0.3ms read and ~0.6ms 4 KB write latency
|
||||
with best-in-slot hardware.
|
||||
|
||||
And that's in the SSD era when you can buy an SSD that has ~0.04ms latency for 100 $.
|
||||
|
||||
I use the following 6 commands with small variations to benchmark any storage:
|
||||
|
||||
- Linear write:
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=write -runtime=60 -filename=/dev/sdX`
|
||||
- Linear read:
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=read -runtime=60 -filename=/dev/sdX`
|
||||
- Random write latency (T1Q1, this hurts storages the most):
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -fsync=1 -rw=randwrite -runtime=60 -filename=/dev/sdX`
|
||||
- Random read latency (T1Q1):
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randread -runtime=60 -filename=/dev/sdX`
|
||||
- Parallel write iops (use numjobs if a single CPU core is insufficient to saturate the load):
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 [-numjobs=4 -group_reporting] -rw=randwrite -runtime=60 -filename=/dev/sdX`
|
||||
- Parallel read iops (use numjobs if a single CPU core is insufficient to saturate the load):
|
||||
`fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 [-numjobs=4 -group_reporting] -rw=randread -runtime=60 -filename=/dev/sdX`
|
||||
|
||||
## Vitastor's Theoretical Maximum Random Access Performance
|
||||
|
||||
Replicated setups:
|
||||
- Single-threaded (T1Q1) read latency: 1 network roundtrip + 1 disk read.
|
||||
- Single-threaded write+fsync latency:
|
||||
- With immediate commit: 2 network roundtrips + 1 disk write.
|
||||
- With lazy commit: 4 network roundtrips + 1 disk write + 1 disk flush.
|
||||
- Saturated parallel read iops: min(network bandwidth, sum(disk read iops)).
|
||||
- Saturated parallel write iops: min(network bandwidth, sum(disk write iops / number of replicas / write amplification)).
|
||||
|
||||
EC/XOR setups:
|
||||
- Single-threaded (T1Q1) read latency: 1.5 network roundtrips + 1 disk read.
|
||||
- Single-threaded write+fsync latency:
|
||||
- With immediate commit: 3.5 network roundtrips + 1 disk read + 2 disk writes.
|
||||
- With lazy commit: 5.5 network roundtrips + 1 disk read + 2 disk writes + 2 disk fsyncs.
|
||||
- 0.5 in actually (k-1)/k which means that an additional roundtrip doesn't happen when
|
||||
the read sub-operation can be served locally.
|
||||
- Saturated parallel read iops: min(network bandwidth, sum(disk read iops)).
|
||||
- Saturated parallel write iops: min(network bandwidth, sum(disk write iops * number of data drives / (number of data + parity drives) / write amplification)).
|
||||
In fact, you should put disk write iops under the condition of ~10% reads / ~90% writes in this formula.
|
||||
|
||||
Write amplification for 4 KB blocks is usually 3-5 in Vitastor:
|
||||
1. Journal block write
|
||||
2. Journal data write
|
||||
3. Metadata block write
|
||||
4. Another journal block write for EC/XOR setups
|
||||
5. Data block write
|
||||
|
||||
If you manage to get an SSD which handles 512 byte blocks well (Optane?) you may
|
||||
lower 1, 3 and 4 to 512 bytes (1/8 of data size) and get WA as low as 2.375.
|
||||
|
||||
Lazy fsync also reduces WA for parallel workloads because journal blocks are only
|
||||
written when they fill up or fsync is requested.
|
||||
|
||||
## Example Comparison with Ceph
|
||||
|
||||
Hardware configuration: 4 nodes, each with:
|
||||
- 6x SATA SSD Intel D3-4510 3.84 TB
|
||||
- 2x Xeon Gold 6242 (16 cores @ 2.8 GHz)
|
||||
- 384 GB RAM
|
||||
- 1x 25 GbE network interface (Mellanox ConnectX-4 LX), connected to a Juniper QFX5200 switch
|
||||
|
||||
CPU powersaving was disabled. Both Vitastor and Ceph were configured with 2 OSDs per 1 SSD.
|
||||
|
||||
All of the results below apply to 4 KB blocks and random access (unless indicated otherwise).
|
||||
|
||||
Raw drive performance:
|
||||
- T1Q1 write ~27000 iops (~0.037ms latency)
|
||||
- T1Q1 read ~9800 iops (~0.101ms latency)
|
||||
- T1Q32 write ~60000 iops
|
||||
- T1Q32 read ~81700 iops
|
||||
|
||||
Ceph 15.2.4 (Bluestore):
|
||||
- T1Q1 write ~1000 iops (~1ms latency)
|
||||
- T1Q1 read ~1750 iops (~0.57ms latency)
|
||||
- T8Q64 write ~100000 iops, total CPU usage by OSDs about 40 virtual cores on each node
|
||||
- T8Q64 read ~480000 iops, total CPU usage by OSDs about 40 virtual cores on each node
|
||||
|
||||
T8Q64 tests were conducted over 8 400GB RBD images from all hosts (every host was running 2 instances of fio).
|
||||
This is because Ceph has performance penalties related to running multiple clients over a single RBD image.
|
||||
|
||||
cephx_sign_messages was set to false during tests, RocksDB and Bluestore settings were left at defaults.
|
||||
|
||||
In fact, not that bad for Ceph. These servers are an example of well-balanced Ceph nodes.
|
||||
However, CPU usage and I/O latency were through the roof, as usual.
|
||||
|
||||
Vitastor:
|
||||
- T1Q1 write: 7087 iops (0.14ms latency)
|
||||
- T1Q1 read: 6838 iops (0.145ms latency)
|
||||
- T2Q64 write: 162000 iops, total CPU usage by OSDs about 3 virtual cores on each node
|
||||
- T8Q64 read: 895000 iops, total CPU usage by OSDs about 4 virtual cores on each node
|
||||
- Linear write (4M T1Q32): 2800 MB/s
|
||||
- Linear read (4M T1Q32): 1500 MB/s
|
||||
|
||||
T8Q64 read test was conducted over 1 larger inode (3.2T) from all hosts (every host was running 2 instances of fio).
|
||||
Vitastor has no performance penalties related to running multiple clients over a single inode.
|
||||
If conducted from one node with all primary OSDs moved to other nodes the result was slightly lower (689000 iops),
|
||||
this is because all operations resulted in network roundtrips between the client and the primary OSD.
|
||||
When fio was colocated with OSDs (like in Ceph benchmarks above), 1/4 of the read workload actually
|
||||
used the loopback network.
|
||||
|
||||
Vitastor was configured with: `--disable_data_fsync true --immediate_commit all --flusher_count 8
|
||||
--disk_alignment 4096 --journal_block_size 4096 --meta_block_size 4096
|
||||
--journal_no_same_sector_overwrites true --journal_sector_buffer_count 1024
|
||||
--journal_size 16777216`.
|
||||
|
||||
### EC/XOR 2+1
|
||||
|
||||
Vitastor:
|
||||
- T1Q1 write: 2808 iops (~0.355ms latency)
|
||||
- T1Q1 read: 6190 iops (~0.16ms latency)
|
||||
- T2Q64 write: 85500 iops, total CPU usage by OSDs about 3.4 virtual cores on each node
|
||||
- T8Q64 read: 812000 iops, total CPU usage by OSDs about 4.7 virtual cores on each node
|
||||
- Linear write (4M T1Q32): 3200 MB/s
|
||||
- Linear read (4M T1Q32): 1800 MB/s
|
||||
|
||||
Ceph:
|
||||
- T1Q1 write: 730 iops (~1.37ms latency)
|
||||
- T1Q1 read: 1500 iops with cold cache (~0.66ms latency), 2300 iops after 2 minute metadata cache warmup (~0.435ms latency)
|
||||
- T4Q128 write (4 RBD images): 45300 iops, total CPU usage by OSDs about 30 virtual cores on each node
|
||||
- T8Q64 read (4 RBD images): 278600 iops, total CPU usage by OSDs about 40 virtual cores on each node
|
||||
- Linear write (4M T1Q32): 1950 MB/s before preallocation, 2500 MB/s after preallocation
|
||||
- Linear read (4M T1Q32): 2400 MB/s
|
||||
|
||||
### NBD
|
||||
|
||||
NBD is currently required to mount Vitastor via kernel, but it imposes additional overhead
|
||||
due to additional copying between the kernel and userspace. This mostly hurts linear
|
||||
bandwidth, not iops.
|
||||
|
||||
Vitastor with single-thread NBD on the same hardware:
|
||||
- T1Q1 write: 6000 iops (0.166ms latency)
|
||||
- T1Q1 read: 5518 iops (0.18ms latency)
|
||||
- T1Q128 write: 94400 iops
|
||||
- T1Q128 read: 103000 iops
|
||||
- Linear write (4M T1Q128): 1266 MB/s (compared to 2800 MB/s via fio)
|
||||
- Linear read (4M T1Q128): 975 MB/s (compared to 1500 MB/s via fio)
|
||||
|
||||
## Installation
|
||||
|
||||
### Debian
|
||||
|
||||
- Trust Vitastor package signing key:
|
||||
`wget -q -O - https://vitastor.io/debian/pubkey | sudo apt-key add -`
|
||||
- Add Vitastor package repository to your /etc/apt/sources.list:
|
||||
- Debian 11 (Bullseye/Sid): `deb https://vitastor.io/debian bullseye main`
|
||||
- Debian 10 (Buster): `deb https://vitastor.io/debian buster main`
|
||||
- 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-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`
|
||||
- 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`
|
||||
- Install packages: `yum/dnf install vitastor lpsolve etcd kernel-ml qemu-kvm`
|
||||
|
||||
### Building from Source
|
||||
|
||||
- Install Linux kernel 5.4 or newer, for io_uring support. 5.8 or later is highly recommended because
|
||||
there is at least one known io_uring hang with 5.4 and an HP SmartArray controller.
|
||||
- Install liburing 0.4 or newer and its headers.
|
||||
- Install lp_solve.
|
||||
- Install etcd, at least version 3.4.15. Earlier versions won't work because of various bugs,
|
||||
for example [#12402](https://github.com/etcd-io/etcd/pull/12402). You can also take 3.4.13
|
||||
with this specific fix from here: https://github.com/vitalif/etcd/, branch release-3.4.
|
||||
- Install node.js 10 or newer.
|
||||
- Install gcc and g++ 8.x or newer.
|
||||
- Clone https://yourcmc.ru/git/vitalif/vitastor/ with submodules.
|
||||
- Install QEMU 3.0+, get its source, begin to build it, stop the build and copy headers:
|
||||
- `<qemu>/include` → `<vitastor>/qemu/include`
|
||||
- Debian:
|
||||
* Use qemu packages from the main repository
|
||||
* `<qemu>/b/qemu/config-host.h` → `<vitastor>/qemu/b/qemu/config-host.h`
|
||||
* `<qemu>/b/qemu/qapi` → `<vitastor>/qemu/b/qemu/qapi`
|
||||
- CentOS 8:
|
||||
* Use qemu packages from the Advanced-Virtualization repository. To enable it, run
|
||||
`yum install centos-release-advanced-virtualization.noarch` and then `yum install qemu`
|
||||
* `<qemu>/config-host.h` → `<vitastor>/qemu/b/qemu/config-host.h`
|
||||
* For QEMU 3.0+: `<qemu>/qapi` → `<vitastor>/qemu/b/qemu/qapi`
|
||||
* For QEMU 2.0+: `<qemu>/qapi-types.h` → `<vitastor>/qemu/b/qemu/qapi-types.h`
|
||||
- `config-host.h` and `qapi` are required because they contain generated headers
|
||||
- You can also rebuild QEMU with a patch that makes LD_PRELOAD unnecessary to load vitastor driver.
|
||||
See `patches/qemu-*.*-vitastor.patch`.
|
||||
- Install fio 3.7 or later, get its source and symlink it into `<vitastor>/fio`.
|
||||
- Build & install Vitastor with `mkdir build && cd build && cmake .. && make -j8 && make install`.
|
||||
Pay attention to the `QEMU_PLUGINDIR` cmake option - it must be set to `qemu-kvm` on RHEL.
|
||||
|
||||
## Running
|
||||
|
||||
Please note that startup procedure isn't currently simple - you |