forked from vitalif/vitastor
Compare commits
1 Commits
master
...
allow-etcd
| Author | SHA1 | Date |
|---|---|---|
 Vitaliy Filippov
|
a23f5535a3 |
|
|
@ -2,6 +2,6 @@ cmake_minimum_required(VERSION 2.8)
|
||||||
|
|
||||||
project(vitastor)
|
project(vitastor)
|
||||||
|
|
||||||
set(VERSION "0.6.17")
|
set(VERSION "0.6.4")
|
||||||
|
|
||||||
add_subdirectory(src)
|
add_subdirectory(src)
|
||||||
|
|
|
||||||
577
README-ru.md
577
README-ru.md
|
|
@ -4,68 +4,545 @@
|
||||||
|
|
||||||
## Идея
|
## Идея
|
||||||
|
|
||||||
Вернём былую скорость кластерному блочному хранилищу!
|
Я всего лишь хочу сделать качественную блочную SDS!
|
||||||
|
|
||||||
Vitastor - распределённая блочная SDS (программная СХД), прямой аналог Ceph RBD и
|
Vitastor - распределённая блочная SDS, прямой аналог Ceph RBD и внутренних СХД популярных
|
||||||
внутренних СХД популярных облачных провайдеров. Однако, в отличие от них, Vitastor
|
облачных провайдеров. Однако, в отличие от них, Vitastor быстрый и при этом простой.
|
||||||
быстрый и при этом простой. Только пока маленький :-).
|
Только пока маленький :-).
|
||||||
|
|
||||||
Vitastor архитектурно похож на Ceph, что означает атомарность и строгую консистентность,
|
Архитектурная схожесть с Ceph означает заложенную на уровне алгоритмов записи строгую консистентность,
|
||||||
репликацию через первичный OSD, симметричную кластеризацию без единой точки отказа
|
репликацию через первичный OSD, симметричную кластеризацию без единой точки отказа
|
||||||
и автоматическое распределение данных по любому числу дисков любого размера с настраиваемыми схемами
|
и автоматическое распределение данных по любому числу дисков любого размера с настраиваемыми схемами
|
||||||
избыточности - репликацией или с произвольными кодами коррекции ошибок.
|
избыточности - репликацией или с произвольными кодами коррекции ошибок.
|
||||||
|
|
||||||
Vitastor нацелен на SSD и SSD+HDD кластеры с как минимум 10 Гбит/с сетью, поддерживает
|
## Возможности
|
||||||
TCP и RDMA и на хорошем железе может достигать задержки 4 КБ чтения и записи на уровне ~0.1 мс,
|
|
||||||
что примерно в 10 раз быстрее, чем Ceph и другие популярные программные СХД.
|
|
||||||
|
|
||||||
Vitastor поддерживает QEMU-драйвер, протоколы NBD и NFS, драйверы OpenStack, Proxmox, Kubernetes.
|
Vitastor на данный момент находится в статусе предварительного выпуска, расширенные
|
||||||
Другие драйверы могут также быть легко реализованы.
|
возможности пока отсутствуют, а в будущих версиях вероятны "ломающие" изменения.
|
||||||
|
|
||||||
Подробности смотрите в документации по ссылкам ниже.
|
Однако следующее уже реализовано:
|
||||||
|
|
||||||
## Презентации и записи докладов
|
- Базовая часть - надёжное кластерное блочное хранилище без единой точки отказа
|
||||||
|
- Производительность ;-D
|
||||||
|
- Несколько схем отказоустойчивости: репликация, XOR n+1 (1 диск чётности), коды коррекции ошибок
|
||||||
|
Рида-Соломона на основе библиотеки jerasure с любым числом дисков данных и чётности в группе
|
||||||
|
- Конфигурация через простые человекочитаемые JSON-структуры в etcd
|
||||||
|
- Автоматическое распределение данных по OSD, с поддержкой:
|
||||||
|
- Математической оптимизации для лучшей равномерности распределения и минимизации перемещений данных
|
||||||
|
- Нескольких пулов с разными схемами избыточности
|
||||||
|
- Дерева распределения, выбора OSD по тегам / классам устройств (только SSD, только HDD) и по поддереву
|
||||||
|
- Настраиваемых доменов отказа (диск/сервер/стойка и т.п.)
|
||||||
|
- Восстановление деградированных блоков
|
||||||
|
- Ребаланс, то есть перемещение данных между OSD (дисками)
|
||||||
|
- Поддержка "ленивого" fsync (fsync не на каждую операцию)
|
||||||
|
- Сбор статистики ввода/вывода в etcd
|
||||||
|
- Клиентская библиотека режима пользователя для ввода/вывода
|
||||||
|
- Драйвер диска для QEMU (собирается вне дерева исходников QEMU)
|
||||||
|
- Драйвер диска для утилиты тестирования производительности fio (также собирается вне дерева исходников fio)
|
||||||
|
- NBD-прокси для монтирования образов ядром ("блочное устройство в режиме пользователя")
|
||||||
|
- Утилита удаления образов/инодов (vitastor-rm)
|
||||||
|
- Пакеты для Debian и CentOS
|
||||||
|
- Статистика операций ввода/вывода и занятого места в разрезе инодов
|
||||||
|
- Именование инодов через хранение их метаданных в etcd
|
||||||
|
- Снапшоты и copy-on-write клоны
|
||||||
|
- Сглаживание производительности случайной записи в SSD+HDD конфигурациях
|
||||||
|
- Поддержка RDMA/RoCEv2 через libibverbs
|
||||||
|
- CSI-плагин для Kubernetes
|
||||||
|
|
||||||
- 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
|
||||||
|
- Другие инструменты администрирования
|
||||||
|
- Плагины для OpenStack, OpenNebula, Proxmox и других облачных систем
|
||||||
|
- iSCSI-прокси
|
||||||
|
- Более быстрое переключение при отказах
|
||||||
|
- Фоновая проверка целостности без контрольных сумм (сверка реплик)
|
||||||
|
- Контрольные суммы
|
||||||
|
- Поддержка SSD-кэширования (tiered storage)
|
||||||
|
- Поддержка NVDIMM
|
||||||
|
- Web-интерфейс
|
||||||
|
- Возможно, сжатие
|
||||||
|
- Возможно, поддержка кэширования данных через системный page cache
|
||||||
|
|
||||||
- Введение
|
## Архитектура
|
||||||
- [Быстрый старт](docs/intro/quickstart.ru.md)
|
|
||||||
- [Возможности](docs/intro/features.ru.md)
|
Так же, как и в Ceph, в Vitastor:
|
||||||
- [Архитектура](docs/intro/architecture.ru.md)
|
|
||||||
- [Автор и лицензия](docs/intro/author.ru.md)
|
- Есть пулы (pools), PG, OSD, мониторы, домены отказа, дерево распределения (аналог crush-дерева).
|
||||||
- Установка
|
- Образы делятся на блоки фиксированного размера (объекты), и эти объекты распределяются по OSD.
|
||||||
- [Пакеты](docs/installation/packages.ru.md)
|
- У OSD есть журнал и метаданные и они тоже могут размещаться на отдельных быстрых дисках.
|
||||||
- [Proxmox](docs/installation/proxmox.ru.md)
|
- Все операции записи тоже транзакционны. В Vitastor, правда, есть режим отложенного/ленивого fsync
|
||||||
- [OpenStack](docs/installation/openstack.ru.md)
|
(коммита), в котором fsync не вызывается на каждую операцию записи, что делает его более
|
||||||
- [Kubernetes CSI](docs/installation/kubernetes.ru.md)
|
пригодным для использования на "плохих" (десктопных) SSD. Однако все операции записи
|
||||||
- [Сборка из исходных кодов](docs/installation/source.ru.md)
|
в любом случае атомарны.
|
||||||
- Конфигурация
|
- Клиентская библиотека тоже старается ждать восстановления после любого отказа кластера, то есть,
|
||||||
- [Обзор](docs/config.ru.md)
|
вы тоже можете перезагрузить хоть весь кластер разом, и клиенты только на время зависнут,
|
||||||
- Параметры
|
но не отключатся.
|
||||||
- [Общие](docs/config/common.ru.md)
|
|
||||||
- [Сетевые](docs/config/network.ru.md)
|
Некоторые базовые термины для тех, кто не знаком с Ceph:
|
||||||
- [Глобальные дисковые параметры](docs/config/layout-cluster.ru.md)
|
|
||||||
- [Дисковые параметры OSD](docs/config/layout-osd.ru.md)
|
- OSD (Object Storage Daemon) - процесс, который хранит данные на одном диске и обрабатывает
|
||||||
- [Прочие параметры OSD](docs/config/osd.ru.md)
|
запросы чтения/записи от клиентов.
|
||||||
- [Параметры мониторов](docs/config/monitor.ru.md)
|
- Пул (Pool) - контейнер для данных, имеющих одну и ту же схему избыточности и правила распределения по OSD.
|
||||||
- [Настройки пулов](docs/config/pool.ru.md)
|
- PG (Placement Group) - группа объектов, хранимых на одном и том же наборе реплик (OSD).
|
||||||
- [Метаданные образов в etcd](docs/config/inode.ru.md)
|
Несколько PG могут храниться на одном и том же наборе реплик, но объекты одной PG
|
||||||
- Использование
|
в норме не хранятся на разных наборах OSD.
|
||||||
- [vitastor-cli](docs/usage/cli.ru.md) (консольный интерфейс)
|
- Монитор - демон, хранящий состояние кластера.
|
||||||
- [fio](docs/usage/fio.ru.md) для тестов производительности
|
- Домен отказа (Failure Domain) - группа OSD, которым вы разрешаете "упасть" всем вместе.
|
||||||
- [NBD](docs/usage/nbd.ru.md) для монтирования ядром
|
Иными словами, это группа OSD, в которые СХД не помещает разные копии одного и того же
|
||||||
- [QEMU и qemu-img](docs/usage/qemu.ru.md)
|
блока данных. Например, если домен отказа - сервер, то на двух дисках одного сервера
|
||||||
- [NFS](docs/usage/nfs.ru.md)-прокси для VMWare и подобных
|
никогда не окажется 2 и более копий одного и того же блока данных, а значит, даже
|
||||||
- Производительность
|
если в этом сервере откажут все диски, это будет равносильно потере только 1 копии
|
||||||
- [Понимание сути производительности](docs/performance/understanding.ru.md)
|
любого блока данных.
|
||||||
- [Теоретический максимум](docs/performance/theoretical.ru.md)
|
- Дерево распределения (Placement Tree / CRUSH Tree) - иерархическая группировка OSD
|
||||||
- [Пример сравнения с Ceph](docs/performance/comparison1.ru.md)
|
в узлы, которые далее можно использовать как домены отказа. То есть, диск (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.
|
||||||
|
См `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` и `/usr/lib/vitastor/mon/make-osd.sh`.
|
||||||
|
- Создайте юниты systemd для etcd и мониторов: `/usr/lib/vitastor/mon/make-units.sh`
|
||||||
|
- Создайте юниты для OSD: `/usr/lib/vitastor/mon/make-osd.sh /dev/disk/by-partuuid/XXX [/dev/disk/by-partuuid/YYY ...]`
|
||||||
|
- Вы можете поменять параметры OSD в юнитах systemd. Смысл некоторых параметров:
|
||||||
|
- `disable_data_fsync 1` - отключает fsync, используется с SSD с конденсаторами.
|
||||||
|
- `immediate_commit all` - используется с SSD с конденсаторами.
|
||||||
|
- `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-rm. Например:
|
||||||
|
|
||||||
|
```
|
||||||
|
vitastor-rm --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).
|
||||||
|
|
||||||
|
## Известные проблемы
|
||||||
|
|
||||||
|
- Запросы удаления объектов могут в данный момент приводить к "неполным" объектам в EC-пулах,
|
||||||
|
если в процессе удаления произойдут отказы OSD или серверов, потому что правильная обработка
|
||||||
|
запросов удаления в кластере должна быть "трёхфазной", а это пока не реализовано. Если вы
|
||||||
|
столкнётесь с такой ситуацией, просто повторите запрос удаления.
|
||||||
|
|
||||||
|
## Принципы реализации
|
||||||
|
|
||||||
|
- Я люблю архитектурно простые решения. Vitastor проектируется именно так и я намерен
|
||||||
|
и далее следовать данному принципу.
|
||||||
|
- Если вы пришли сюда за идеальным кодом на C++, вы, вероятно, не по адресу. "Общепринятые"
|
||||||
|
практики написания C++ кода меня не очень волнуют, так как зачастую, опять-таки, ведут к
|
||||||
|
излишним усложнениям и код получается красивый... но медленный.
|
||||||
|
- По той же причине в коде иногда можно встретить велосипеды типа собственного упрощённого
|
||||||
|
HTTP-клиента для работы с etcd. Зато эти велосипеды маленькие и компактные и не требуют
|
||||||
|
использования десятка внешних библиотек.
|
||||||
|
- node.js для монитора - не случайный выбор. Он очень быстрый, имеет встроенную событийную
|
||||||
|
машину, приятный нейтральный C-подобный язык программирования и развитую инфраструктуру.
|
||||||
|
|
||||||
## Автор и лицензия
|
## Автор и лицензия
|
||||||
|
|
||||||
|
|
|
||||||
536
README.md
536
README.md
|
|
@ -1,71 +1,499 @@
|
||||||
# Vitastor
|
## Vitastor
|
||||||
|
|
||||||
[Читать на русском](README-ru.md)
|
[Читать на русском](README-ru.md)
|
||||||
|
|
||||||
## The Idea
|
## The Idea
|
||||||
|
|
||||||
Make Clustered Block Storage Fast Again.
|
Make Software-Defined Block Storage Great Again.
|
||||||
|
|
||||||
Vitastor is a distributed block SDS, direct replacement of Ceph RBD and internal SDS's
|
Vitastor is a small, simple and fast clustered block storage (storage for VM drives),
|
||||||
of public clouds. However, in contrast to them, Vitastor is fast and simple at the same time.
|
architecturally similar to Ceph which means strong consistency, primary-replication, symmetric
|
||||||
The only thing is it's slightly young :-).
|
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,
|
## Features
|
||||||
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 SSD and SSD+HDD clusters with at least 10 Gbit/s network, supports
|
Vitastor is currently a pre-release, a lot of features are missing and you can still expect
|
||||||
TCP and RDMA and may achieve 4 KB read and write latency as low as ~0.1 ms
|
breaking changes in the future. However, the following is implemented:
|
||||||
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, Proxmox, Kubernetes drivers.
|
- Basic part: highly-available block storage with symmetric clustering and no SPOF
|
||||||
More drivers may be created easily.
|
- 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-rm)
|
||||||
|
- 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
|
||||||
|
|
||||||
Read more details below in the documentation.
|
## Roadmap
|
||||||
|
|
||||||
## Talks and presentations
|
- Better OSD creation and auto-start tools
|
||||||
|
- Other administrative tools
|
||||||
|
- Plugins for OpenStack, 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),
|
## Architecture
|
||||||
[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)
|
|
||||||
|
|
||||||
## Documentation
|
Similarities:
|
||||||
|
|
||||||
- Introduction
|
- Just like Ceph, Vitastor has Pools, PGs, OSDs, Monitors, Failure Domains, Placement Tree.
|
||||||
- [Quick Start](docs/intro/quickstart.en.md)
|
- Just like Ceph, Vitastor is transactional (even though there's a "lazy fsync mode" which
|
||||||
- [Features](docs/intro/features.en.md)
|
doesn't implicitly flush every operation to disks).
|
||||||
- [Architecture](docs/intro/architecture.en.md)
|
- OSDs also have journal and metadata and they can also be put on separate drives.
|
||||||
- [Author and license](docs/intro/author.en.md)
|
- Just like in Ceph, client library attempts to recover from any cluster failure so
|
||||||
- Installation
|
you can basically reboot the whole cluster and only pause, but not crash, your clients
|
||||||
- [Packages](docs/installation/packages.en.md)
|
(I consider this a bug if the client crashes in that case).
|
||||||
- [Proxmox](docs/installation/proxmox.en.md)
|
|
||||||
- [OpenStack](docs/installation/openstack.en.md)
|
Some basic terms for people not familiar with Ceph:
|
||||||
- [Kubernetes CSI](docs/installation/kubernetes.en.md)
|
|
||||||
- [Building from Source](docs/installation/source.en.md)
|
- OSD (Object Storage Daemon) is a process that stores data and serves read/write requests.
|
||||||
- Configuration
|
- PG (Placement Group) is a container for data that (normally) shares the same replicas.
|
||||||
- [Overview](docs/config.en.md)
|
- Pool is a container for data that has the same redundancy scheme and placement rules.
|
||||||
- Parameter Reference
|
- Monitor is a separate daemon that watches cluster state and handles failures.
|
||||||
- [Common](docs/config/common.en.md)
|
- Failure Domain is a group of OSDs that you allow to fail. It's "host" by default.
|
||||||
- [Network](docs/config/network.en.md)
|
- Placement Tree groups OSDs in a hierarchy to later split them into Failure Domains.
|
||||||
- [Global Disk Layout](docs/config/layout-cluster.en.md)
|
|
||||||
- [OSD Disk Layout](docs/config/layout-osd.en.md)
|
Architectural differences from Ceph:
|
||||||
- [OSD Runtime Parameters](docs/config/osd.en.md)
|
|
||||||
- [Monitor](docs/config/monitor.en.md)
|
- Vitastor's primary focus is on SSDs. Proper SSD+HDD optimizations may be added in the future, though.
|
||||||
- [Pool configuration](docs/config/pool.en.md)
|
- Vitastor OSD is (and will always be) single-threaded. If you want to dedicate more than 1 core
|
||||||
- [Image metadata in etcd](docs/config/inode.en.md)
|
per drive you should run multiple OSDs each on a different partition of the drive.
|
||||||
- Usage
|
Vitastor isn't CPU-hungry though (as opposed to Ceph), so 1 core is sufficient in a lot of cases.
|
||||||
- [vitastor-cli](docs/usage/cli.en.md) (command-line interface)
|
- Metadata and journal are always kept in memory. Metadata size depends linearly on drive capacity
|
||||||
- [fio](docs/usage/fio.en.md) for benchmarks
|
and data store block size which is 128 KB by default. With 128 KB blocks metadata should occupy
|
||||||
- [NBD](docs/usage/nbd.en.md) for kernel mounts
|
around 512 MB per 1 TB (which is still less than Ceph wants). Journal doesn't have to be big,
|
||||||
- [QEMU and qemu-img](docs/usage/qemu.en.md)
|
the example test below was conducted with only 16 MB journal. A big journal is probably even
|
||||||
- [NFS](docs/usage/nfs.en.md) emulator for VMWare and similar
|
harmful as dirty write metadata also take some memory.
|
||||||
- Performance
|
- Vitastor storage layer doesn't have internal copy-on-write or redirect-write. I know that maybe
|
||||||
- [Understanding storage performance](docs/performance/understanding.en.md)
|
it's possible to create a good copy-on-write storage, but it's much harder and makes performance
|
||||||
- [Theoretical performance](docs/performance/theoretical.en.md)
|
less deterministic, so CoW isn't used in Vitastor.
|
||||||
- [Example comparison with Ceph](docs/performance/comparison1.en.md)
|
- 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 `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 specify configuration
|
||||||
|
and calculate disk offsets almost by hand. This will be fixed in near future.
|
||||||
|
|
||||||
|
- Get some SATA or NVMe SSDs with capacitors (server-grade drives). You can use desktop SSDs
|
||||||
|
with lazy fsync, but prepare for inferior single-thread latency.
|
||||||
|
- Get a fast network (at least 10 Gbit/s).
|
||||||
|
- Disable CPU powersaving: `cpupower idle-set -D 0 && cpupower frequency-set -g performance`.
|
||||||
|
- Check `/usr/lib/vitastor/mon/make-units.sh` and `/usr/lib/vitastor/mon/make-osd.sh` and
|
||||||
|
put desired values into the variables at the top of these files.
|
||||||
|
- Create systemd units for the monitor and etcd: `/usr/lib/vitastor/mon/make-units.sh`
|
||||||
|
- Create systemd units for your OSDs: `/usr/lib/vitastor/mon/make-osd.sh /dev/disk/by-partuuid/XXX [/dev/disk/by-partuuid/YYY ...]`
|
||||||
|
- You can edit the units and change OSD configuration. Notable configuration variables:
|
||||||
|
- `disable_data_fsync 1` - only safe with server-grade drives with capacitors.
|
||||||
|
- `immediate_commit all` - use this if all your drives are server-grade.
|
||||||
|
- `disable_device_lock 1` - only required if you run multiple OSDs on one block device.
|
||||||
|
- `flusher_count 256` - flusher is a micro-thread that removes old data from the journal.
|
||||||
|
You don't have to worry about this parameter anymore, 256 is enough.
|
||||||
|
- `disk_alignment`, `journal_block_size`, `meta_block_size` should be set to the internal
|
||||||
|
block size of your SSDs which is 4096 on most drives.
|
||||||
|
- `journal_no_same_sector_overwrites true` prevents multiple overwrites of the same journal sector.
|
||||||
|
Most (99%) SSDs don't need this option. But Intel D3-4510 does because it doesn't like when you
|
||||||
|
overwrite the same sector twice in a short period of time. The setting forces Vitastor to never
|
||||||
|
overwrite the same journal sector twice in a row which makes D3-4510 almost happy. Not totally
|
||||||
|
happy, because overwrites of the same block can still happen in the metadata area... When this
|
||||||
|
setting is set, it is also required to raise `journal_sector_buffer_count` setting, which is the
|
||||||
|
number of dirty journal sectors that may be written to at the same time.
|
||||||
|
- `systemctl start vitastor.target` everywhere.
|
||||||
|
- Create global configuration in etcd: `etcdctl --endpoints=... put /vitastor/config/global '{"immediate_commit":"all"}'`
|
||||||
|
(if all your drives have capacitors).
|
||||||
|
- Create pool configuration in etcd: `etcdctl --endpoints=... put /vitastor/config/pools '{"1":{"name":"testpool","scheme":"replicated","pg_size":2,"pg_minsize":1,"pg_count":256,"failure_domain":"host"}}'`.
|
||||||
|
For jerasure pools the configuration should look like the following: `2:{"name":"ecpool","scheme":"jerasure","pg_size":4,"parity_chunks":2,"pg_minsize":2,"pg_count":256,"failure_domain":"host"}`.
|
||||||
|
- At this point, one of the monitors will configure PGs and OSDs will start them.
|
||||||
|
- You can check PG states with `etcdctl --endpoints=... get --prefix /vitastor/pg/state`. All PGs should become 'active'.
|
||||||
|
|
||||||
|
### Name an image
|
||||||
|
|
||||||
|
```
|
||||||
|
etcdctl --endpoints=<etcd> put /vitastor/config/inode/<pool>/<inode> '{"name":"<name>","size":<size>[,"parent_id":<parent_inode_number>][,"readonly":true]}'
|
||||||
|
```
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
```
|
||||||
|
etcdctl --endpoints=http://10.115.0.10:2379/v3 put /vitastor/config/inode/1/1 '{"name":"testimg","size":2147483648}'
|
||||||
|
```
|
||||||
|
|
||||||
|
If you specify parent_id the image becomes a CoW clone. I.e. all writes go to the new inode and reads first check it
|
||||||
|
and then upper layers. You can then make parent readonly by updating its entry with `"readonly":true` for safety and
|
||||||
|
basically treat it as a snapshot.
|
||||||
|
|
||||||
|
So to create a snapshot you basically rename the previous upper layer (for example from testimg to testimg@0), make it readonly
|
||||||
|
and create a new top layer with the original name (testimg) and the previous one as a parent.
|
||||||
|
|
||||||
|
### Run fio benchmarks
|
||||||
|
|
||||||
|
fio command example:
|
||||||
|
|
||||||
|
```
|
||||||
|
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
|
||||||
|
```
|
||||||
|
|
||||||
|
If you don't want to access your image by name, you can specify pool number, inode number and size
|
||||||
|
(`-pool=1 -inode=1 -size=400G`) instead of the image name (`-image=testimg`).
|
||||||
|
|
||||||
|
### Upload VM image
|
||||||
|
|
||||||
|
Use qemu-img and `vitastor:etcd_host=<HOST>:image=<IMAGE>` disk filename. For example:
|
||||||
|
|
||||||
|
```
|
||||||
|
qemu-img convert -f qcow2 debian10.qcow2 -p -O raw 'vitastor:etcd_host=10.115.0.10\:2379/v3:image=testimg'
|
||||||
|
```
|
||||||
|
|
||||||
|
Note that the command requires to be run with `LD_PRELOAD=/usr/lib/x86_64-linux-gnu/qemu/block-vitastor.so qemu-img ...`
|
||||||
|
if you use unmodified QEMU.
|
||||||
|
|
||||||
|
You can also specify `:pool=<POOL>:inode=<INODE>:size=<SIZE>` instead of `:image=<IMAGE>`
|
||||||
|
if you don't want to use inode metadata.
|
||||||
|
|
||||||
|
### Start a VM
|
||||||
|
|
||||||
|
Run QEMU with `-drive file=vitastor:etcd_host=<HOST>:image=<IMAGE>` and use 4 KB physical block size.
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
```
|
||||||
|
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
|
||||||
|
```
|
||||||
|
|
||||||
|
You can also specify `:pool=<POOL>:inode=<INODE>:size=<SIZE>` instead of `:image=<IMAGE>`,
|
||||||
|
just like in qemu-img.
|
||||||
|
|
||||||
|
### Remove inode
|
||||||
|
|
||||||
|
Use vitastor-rm. For example:
|
||||||
|
|
||||||
|
```
|
||||||
|
vitastor-rm --etcd_address 10.115.0.10:2379/v3 --pool 1 --inode 1 --parallel_osds 16 --iodepth 32
|
||||||
|
```
|
||||||
|
|
||||||
|
### NBD
|
||||||
|
|
||||||
|
To create a local block device for a Vitastor image, use NBD. For example:
|
||||||
|
|
||||||
|
```
|
||||||
|
vitastor-nbd map --etcd_address 10.115.0.10:2379/v3 --image testimg
|
||||||
|
```
|
||||||
|
|
||||||
|
It will output the device name, like /dev/nbd0 which you can then format and mount as a normal block device.
|
||||||
|
|
||||||
|
Again, you can use `--pool <POOL> --inode <INODE> --size <SIZE>` insteaf of `--image <IMAGE>` if you want.
|
||||||
|
|
||||||
|
### Kubernetes
|
||||||
|
|
||||||
|
Vitastor has a CSI plugin for Kubernetes which supports RWO volumes.
|
||||||
|
|
||||||
|
To deploy it, take manifests from [csi/deploy/](csi/deploy/) directory, put your
|
||||||
|
Vitastor configuration in [csi/deploy/001-csi-config-map.yaml](001-csi-config-map.yaml),
|
||||||
|
configure storage class in [csi/deploy/009-storage-class.yaml](009-storage-class.yaml)
|
||||||
|
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. See example in [csi/deploy/example-pvc.yaml](csi/deploy/example-pvc.yaml).
|
||||||
|
|
||||||
|
## Known Problems
|
||||||
|
|
||||||
|
- Object deletion requests may currently lead to 'incomplete' objects in EC pools
|
||||||
|
if your OSDs crash during deletion because proper handling of object cleanup
|
||||||
|
in a cluster should be "three-phase" and it's currently not implemented.
|
||||||
|
Just repeat the removal request again in this case.
|
||||||
|
|
||||||
|
## Implementation Principles
|
||||||
|
|
||||||
|
- I like architecturally simple solutions. Vitastor is and will always be designed
|
||||||
|
exactly like that.
|
||||||
|
- I also like reinventing the wheel to some extent, like writing my own HTTP client
|
||||||
|
for etcd interaction instead of using prebuilt libraries, because in this case
|
||||||
|
I'm confident about what my code does and what it doesn't do.
|
||||||
|
- I don't care about C++ "best practices" like RAII or proper inheritance or usage of
|
||||||
|
smart pointers or whatever and I don't intend to change my mind, so if you're here
|
||||||
|
looking for ideal reference C++ code, this probably isn't the right place.
|
||||||
|
- I like node.js better than any other dynamically-typed language interpreter
|
||||||
|
because it's faster than any other interpreter in the world, has neutral C-like
|
||||||
|
syntax and built-in event loop. That's why Monitor is implemented in node.js.
|
||||||
|
|
||||||
## Author and License
|
## Author and License
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
commit 7f01510ef207940b07fac4f5fc8b9f1580b443aa
|
commit bd283191b3e7a4c6d1c100d3d96e348a1ebffe55
|
||||||
Author: Vitaliy Filippov <vitalif@yourcmc.ru>
|
Author: Vitaliy Filippov <vitalif@yourcmc.ru>
|
||||||
Date: Sun Jun 27 12:52:40 2021 +0300
|
Date: Sun Jun 27 12:52:40 2021 +0300
|
||||||
|
|
||||||
|
|
@ -65,38 +65,10 @@ index 4bf2b5f..dbc011b 100644
|
||||||
|
|
||||||
int virConnectListAllStoragePools(virConnectPtr conn,
|
int virConnectListAllStoragePools(virConnectPtr conn,
|
||||||
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
|
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
|
||||||
index 222bb8c..2c30c55 100644
|
index 222bb8c..685d255 100644
|
||||||
--- a/src/conf/domain_conf.c
|
--- a/src/conf/domain_conf.c
|
||||||
+++ b/src/conf/domain_conf.c
|
+++ b/src/conf/domain_conf.c
|
||||||
@@ -4667,8 +4667,7 @@ virDomainDeviceDefPostParseCommon(virDomainDeviceDefPtr dev,
|
@@ -8653,6 +8653,10 @@ virDomainDiskSourceNetworkParse(xmlNodePtr node,
|
||||||
if (dev->type == VIR_DOMAIN_DEVICE_DISK) {
|
|
||||||
virDomainDiskDefPtr disk = dev->data.disk;
|
|
||||||
|
|
||||||
- /* internal snapshots and config files are currently supported
|
|
||||||
- * only with rbd: */
|
|
||||||
+ /* internal snapshots are currently supported only with rbd: */
|
|
||||||
if (virStorageSourceGetActualType(disk->src) != VIR_STORAGE_TYPE_NETWORK &&
|
|
||||||
disk->src->protocol != VIR_STORAGE_NET_PROTOCOL_RBD) {
|
|
||||||
if (disk->src->snapshot) {
|
|
||||||
@@ -4677,11 +4676,15 @@ virDomainDeviceDefPostParseCommon(virDomainDeviceDefPtr dev,
|
|
||||||
"only with 'rbd' disks"));
|
|
||||||
return -1;
|
|
||||||
}
|
|
||||||
-
|
|
||||||
+ }
|
|
||||||
+ /* config files are currently supported only with rbd and vitastor: */
|
|
||||||
+ if (virStorageSourceGetActualType(disk->src) != VIR_STORAGE_TYPE_NETWORK &&
|
|
||||||
+ disk->src->protocol != VIR_STORAGE_NET_PROTOCOL_RBD &&
|
|
||||||
+ disk->src->protocol != VIR_STORAGE_NET_PROTOCOL_VITASTOR) {
|
|
||||||
if (disk->src->configFile) {
|
|
||||||
virReportError(VIR_ERR_XML_ERROR, "%s",
|
|
||||||
_("<config> element is currently supported "
|
|
||||||
- "only with 'rbd' disks"));
|
|
||||||
+ "only with 'rbd' and 'vitastor' disks"));
|
|
||||||
return -1;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
@@ -8653,6 +8656,10 @@ virDomainDiskSourceNetworkParse(xmlNodePtr node,
|
|
||||||
goto cleanup;
|
goto cleanup;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
@ -107,7 +79,7 @@ index 222bb8c..2c30c55 100644
|
||||||
if ((haveTLS = virXMLPropString(node, "tls")) &&
|
if ((haveTLS = virXMLPropString(node, "tls")) &&
|
||||||
(src->haveTLS = virTristateBoolTypeFromString(haveTLS)) <= 0) {
|
(src->haveTLS = virTristateBoolTypeFromString(haveTLS)) <= 0) {
|
||||||
virReportError(VIR_ERR_XML_ERROR,
|
virReportError(VIR_ERR_XML_ERROR,
|
||||||
@@ -23849,6 +23856,10 @@ virDomainDiskSourceFormatNetwork(virBufferPtr attrBuf,
|
@@ -23849,6 +23853,10 @@ virDomainDiskSourceFormatNetwork(virBufferPtr attrBuf,
|
||||||
|
|
||||||
virBufferEscapeString(attrBuf, " name='%s'", path ? path : src->path);
|
virBufferEscapeString(attrBuf, " name='%s'", path ? path : src->path);
|
||||||
|
|
||||||
|
|
@ -118,7 +90,7 @@ index 222bb8c..2c30c55 100644
|
||||||
VIR_FREE(path);
|
VIR_FREE(path);
|
||||||
|
|
||||||
if (src->haveTLS != VIR_TRISTATE_BOOL_ABSENT &&
|
if (src->haveTLS != VIR_TRISTATE_BOOL_ABSENT &&
|
||||||
@@ -30930,6 +30941,7 @@ virDomainDiskTranslateSourcePool(virDomainDiskDefPtr def)
|
@@ -30930,6 +30938,7 @@ virDomainDiskTranslateSourcePool(virDomainDiskDefPtr def)
|
||||||
|
|
||||||
case VIR_STORAGE_POOL_MPATH:
|
case VIR_STORAGE_POOL_MPATH:
|
||||||
case VIR_STORAGE_POOL_RBD:
|
case VIR_STORAGE_POOL_RBD:
|
||||||
|
|
@ -244,7 +216,7 @@ index 73e988a..ab7bb81 100644
|
||||||
case VIR_STORAGE_NET_PROTOCOL_NONE:
|
case VIR_STORAGE_NET_PROTOCOL_NONE:
|
||||||
virReportError(VIR_ERR_NO_SUPPORT,
|
virReportError(VIR_ERR_NO_SUPPORT,
|
||||||
diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
|
diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
|
||||||
index cbf0aa4..f0ca9e7 100644
|
index cbf0aa4..096700d 100644
|
||||||
--- a/src/qemu/qemu_block.c
|
--- a/src/qemu/qemu_block.c
|
||||||
+++ b/src/qemu/qemu_block.c
|
+++ b/src/qemu/qemu_block.c
|
||||||
@@ -959,6 +959,42 @@ qemuBlockStorageSourceGetRBDProps(virStorageSourcePtr src)
|
@@ -959,6 +959,42 @@ qemuBlockStorageSourceGetRBDProps(virStorageSourcePtr src)
|
||||||
|
|
@ -273,9 +245,9 @@ index cbf0aa4..f0ca9e7 100644
|
||||||
+
|
+
|
||||||
+ if (virJSONValueObjectCreate(&ret,
|
+ if (virJSONValueObjectCreate(&ret,
|
||||||
+ "s:driver", "vitastor",
|
+ "s:driver", "vitastor",
|
||||||
+ "S:etcd-host", etcd,
|
+ "S:etcd_host", etcd,
|
||||||
+ "S:etcd-prefix", src->relPath,
|
+ "S:etcd_prefix", src->relPath,
|
||||||
+ "S:config-path", src->configFile,
|
+ "S:config_path", src->configFile,
|
||||||
+ "s:image", src->path,
|
+ "s:image", src->path,
|
||||||
+ NULL) < 0)
|
+ NULL) < 0)
|
||||||
+ goto cleanup;
|
+ goto cleanup;
|
||||||
|
|
@ -303,7 +275,7 @@ index cbf0aa4..f0ca9e7 100644
|
||||||
if (!(fileprops = qemuBlockStorageSourceGetSheepdogProps(src)))
|
if (!(fileprops = qemuBlockStorageSourceGetSheepdogProps(src)))
|
||||||
return NULL;
|
return NULL;
|
||||||
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
|
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
|
||||||
index 822d5f8..abec34e 100644
|
index 822d5f8..e375cef 100644
|
||||||
--- a/src/qemu/qemu_command.c
|
--- a/src/qemu/qemu_command.c
|
||||||
+++ b/src/qemu/qemu_command.c
|
+++ b/src/qemu/qemu_command.c
|
||||||
@@ -975,6 +975,43 @@ qemuBuildNetworkDriveStr(virStorageSourcePtr src,
|
@@ -975,6 +975,43 @@ qemuBuildNetworkDriveStr(virStorageSourcePtr src,
|
||||||
|
|
@ -321,7 +293,7 @@ index 822d5f8..abec34e 100644
|
||||||
+ virBufferStrcat(&buf, "vitastor:image=", src->path, NULL);
|
+ virBufferStrcat(&buf, "vitastor:image=", src->path, NULL);
|
||||||
+
|
+
|
||||||
+ if (src->nhosts > 0) {
|
+ if (src->nhosts > 0) {
|
||||||
+ virBufferAddLit(&buf, ":etcd-host=");
|
+ virBufferAddLit(&buf, ":etcd_host=");
|
||||||
+ for (i = 0; i < src->nhosts; i++) {
|
+ for (i = 0; i < src->nhosts; i++) {
|
||||||
+ if (i)
|
+ if (i)
|
||||||
+ virBufferAddLit(&buf, ",");
|
+ virBufferAddLit(&buf, ",");
|
||||||
|
|
@ -339,10 +311,10 @@ index 822d5f8..abec34e 100644
|
||||||
+ }
|
+ }
|
||||||
+
|
+
|
||||||
+ if (src->configFile)
|
+ if (src->configFile)
|
||||||
+ virBufferEscape(&buf, '\\', ":", ":config-path=%s", src->configFile);
|
+ virBufferEscape(&buf, '\\', ":", ":config_path=%s", src->configFile);
|
||||||
+
|
+
|
||||||
+ if (src->relPath)
|
+ if (src->relPath)
|
||||||
+ virBufferEscape(&buf, '\\', ":", ":etcd-prefix=%s", src->relPath);
|
+ virBufferEscape(&buf, '\\', ":", ":etcd_prefix=%s", src->relPath);
|
||||||
+
|
+
|
||||||
+ ret = virBufferContentAndReset(&buf);
|
+ ret = virBufferContentAndReset(&buf);
|
||||||
+ break;
|
+ break;
|
||||||
|
|
@ -415,7 +387,7 @@ index 4a13e90..33301c7 100644
|
||||||
ignore_value(VIR_STRDUP(stable_path, data->path));
|
ignore_value(VIR_STRDUP(stable_path, data->path));
|
||||||
break;
|
break;
|
||||||
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
|
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
|
||||||
index bd4b027..8454906 100644
|
index bd4b027..b323cd6 100644
|
||||||
--- a/src/util/virstoragefile.c
|
--- a/src/util/virstoragefile.c
|
||||||
+++ b/src/util/virstoragefile.c
|
+++ b/src/util/virstoragefile.c
|
||||||
@@ -84,7 +84,8 @@ VIR_ENUM_IMPL(virStorageNetProtocol, VIR_STORAGE_NET_PROTOCOL_LAST,
|
@@ -84,7 +84,8 @@ VIR_ENUM_IMPL(virStorageNetProtocol, VIR_STORAGE_NET_PROTOCOL_LAST,
|
||||||
|
|
@ -466,16 +438,16 @@ index bd4b027..8454906 100644
|
||||||
+ if (STRPREFIX(p, "image=")) {
|
+ if (STRPREFIX(p, "image=")) {
|
||||||
+ if (VIR_STRDUP(src->path, p + strlen("image=")) < 0)
|
+ if (VIR_STRDUP(src->path, p + strlen("image=")) < 0)
|
||||||
+ return -1;
|
+ return -1;
|
||||||
+ } else if (STRPREFIX(p, "etcd-prefix=")) {
|
+ } else if (STRPREFIX(p, "etcd_prefix=")) {
|
||||||
+ if (VIR_STRDUP(src->relPath, p + strlen("etcd-prefix=")) < 0)
|
+ if (VIR_STRDUP(src->relPath, p + strlen("etcd_prefix=")) < 0)
|
||||||
+ return -1;
|
+ return -1;
|
||||||
+ } else if (STRPREFIX(p, "config-path=")) {
|
+ } else if (STRPREFIX(p, "config_file=")) {
|
||||||
+ if (VIR_STRDUP(src->configFile, p + strlen("config-path=")) < 0)
|
+ if (VIR_STRDUP(src->configFile, p + strlen("config_file=")) < 0)
|
||||||
+ return -1;
|
+ return -1;
|
||||||
+ } else if (STRPREFIX(p, "etcd-host=")) {
|
+ } else if (STRPREFIX(p, "etcd_host=")) {
|
||||||
+ char *h, *sep;
|
+ char *h, *sep;
|
||||||
+
|
+
|
||||||
+ h = p + strlen("etcd-host=");
|
+ h = p + strlen("etcd_host=");
|
||||||
+ while (h < e) {
|
+ while (h < e) {
|
||||||
+ for (sep = h; sep < e; ++sep) {
|
+ for (sep = h; sep < e; ++sep) {
|
||||||
+ if (*sep == '\\' && (sep[1] == ',' ||
|
+ if (*sep == '\\' && (sep[1] == ',' ||
|
||||||
|
|
@ -535,8 +507,8 @@ index bd4b027..8454906 100644
|
||||||
+{
|
+{
|
||||||
+ const char *filename;
|
+ const char *filename;
|
||||||
+ const char *image = virJSONValueObjectGetString(json, "image");
|
+ const char *image = virJSONValueObjectGetString(json, "image");
|
||||||
+ const char *conf = virJSONValueObjectGetString(json, "config-path");
|
+ const char *conf = virJSONValueObjectGetString(json, "config_path");
|
||||||
+ const char *etcd_prefix = virJSONValueObjectGetString(json, "etcd-prefix");
|
+ const char *etcd_prefix = virJSONValueObjectGetString(json, "etcd_prefix");
|
||||||
+ virJSONValuePtr servers = virJSONValueObjectGetArray(json, "server");
|
+ virJSONValuePtr servers = virJSONValueObjectGetArray(json, "server");
|
||||||
+ size_t nservers;
|
+ size_t nservers;
|
||||||
+ size_t i;
|
+ size_t i;
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
commit 4e74c622884e2585b2cfcdf322fbd2bff6de41ca
|
commit 41cdfe8317d98f70aadedfdbb381effed2641bdd
|
||||||
Author: Vitaliy Filippov <vitalif@yourcmc.ru>
|
Author: Vitaliy Filippov <vitalif@yourcmc.ru>
|
||||||
Date: Fri Jul 9 01:31:57 2021 +0300
|
Date: Fri Jul 9 01:31:57 2021 +0300
|
||||||
|
|
||||||
|
|
@ -65,38 +65,10 @@ index 089e1e0..d7e7ef4 100644
|
||||||
|
|
||||||
int virConnectListAllStoragePools(virConnectPtr conn,
|
int virConnectListAllStoragePools(virConnectPtr conn,
|
||||||
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
|
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
|
||||||
index 01b7187..645c758 100644
|
index 01b7187..c6e9702 100644
|
||||||
--- a/src/conf/domain_conf.c
|
--- a/src/conf/domain_conf.c
|
||||||
+++ b/src/conf/domain_conf.c
|
+++ b/src/conf/domain_conf.c
|
||||||
@@ -5230,8 +5230,7 @@ virDomainDiskDefPostParse(virDomainDiskDefPtr disk,
|
@@ -8261,7 +8261,8 @@ virDomainDiskSourceNetworkParse(xmlNodePtr node,
|
||||||
const virDomainDef *def,
|
|
||||||
virDomainXMLOptionPtr xmlopt)
|
|
||||||
{
|
|
||||||
- /* internal snapshots and config files are currently supported
|
|
||||||
- * only with rbd: */
|
|
||||||
+ /* internal snapshots are currently supported only with rbd: */
|
|
||||||
if (virStorageSourceGetActualType(disk->src) != VIR_STORAGE_TYPE_NETWORK &&
|
|
||||||
disk->src->protocol != VIR_STORAGE_NET_PROTOCOL_RBD) {
|
|
||||||
if (disk->src->snapshot) {
|
|
||||||
@@ -5240,11 +5239,15 @@ virDomainDiskDefPostParse(virDomainDiskDefPtr disk,
|
|
||||||
"only with 'rbd' disks"));
|
|
||||||
return -1;
|
|
||||||
}
|
|
||||||
-
|
|
||||||
+ }
|
|
||||||
+ /* config files are currently supported only with rbd and vitastor: */
|
|
||||||
+ if (virStorageSourceGetActualType(disk->src) != VIR_STORAGE_TYPE_NETWORK &&
|
|
||||||
+ disk->src->protocol != VIR_STORAGE_NET_PROTOCOL_RBD &&
|
|
||||||
+ disk->src->protocol != VIR_STORAGE_NET_PROTOCOL_VITASTOR) {
|
|
||||||
if (disk->src->configFile) {
|
|
||||||
virReportError(VIR_ERR_XML_ERROR, "%s",
|
|
||||||
_("<config> element is currently supported "
|
|
||||||
- "only with 'rbd' disks"));
|
|
||||||
+ "only with 'rbd' and 'vitastor' disks"));
|
|
||||||
return -1;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
@@ -8261,7 +8264,8 @@ virDomainDiskSourceNetworkParse(xmlNodePtr node,
|
|
||||||
src->configFile = virXPathString("string(./config/@file)", ctxt);
|
src->configFile = virXPathString("string(./config/@file)", ctxt);
|
||||||
|
|
||||||
if (src->protocol == VIR_STORAGE_NET_PROTOCOL_HTTP ||
|
if (src->protocol == VIR_STORAGE_NET_PROTOCOL_HTTP ||
|
||||||
|
|
@ -106,7 +78,7 @@ index 01b7187..645c758 100644
|
||||||
src->query = virXMLPropString(node, "query");
|
src->query = virXMLPropString(node, "query");
|
||||||
|
|
||||||
if (virDomainStorageNetworkParseHosts(node, ctxt, &src->hosts, &src->nhosts) < 0)
|
if (virDomainStorageNetworkParseHosts(node, ctxt, &src->hosts, &src->nhosts) < 0)
|
||||||
@@ -31392,6 +31396,7 @@ virDomainStorageSourceTranslateSourcePool(virStorageSourcePtr src,
|
@@ -31392,6 +31393,7 @@ virDomainStorageSourceTranslateSourcePool(virStorageSourcePtr src,
|
||||||
|
|
||||||
case VIR_STORAGE_POOL_MPATH:
|
case VIR_STORAGE_POOL_MPATH:
|
||||||
case VIR_STORAGE_POOL_RBD:
|
case VIR_STORAGE_POOL_RBD:
|
||||||
|
|
@ -244,7 +216,7 @@ index 17b93d0..c5a0084 100644
|
||||||
case VIR_STORAGE_NET_PROTOCOL_NONE:
|
case VIR_STORAGE_NET_PROTOCOL_NONE:
|
||||||
virReportError(VIR_ERR_NO_SUPPORT,
|
virReportError(VIR_ERR_NO_SUPPORT,
|
||||||
diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
|
diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
|
||||||
index f9c6da2..d837a05 100644
|
index f9c6da2..922dde5 100644
|
||||||
--- a/src/qemu/qemu_block.c
|
--- a/src/qemu/qemu_block.c
|
||||||
+++ b/src/qemu/qemu_block.c
|
+++ b/src/qemu/qemu_block.c
|
||||||
@@ -938,6 +938,38 @@ qemuBlockStorageSourceGetRBDProps(virStorageSourcePtr src,
|
@@ -938,6 +938,38 @@ qemuBlockStorageSourceGetRBDProps(virStorageSourcePtr src,
|
||||||
|
|
@ -272,9 +244,9 @@ index f9c6da2..d837a05 100644
|
||||||
+ }
|
+ }
|
||||||
+
|
+
|
||||||
+ if (virJSONValueObjectCreate(&ret,
|
+ if (virJSONValueObjectCreate(&ret,
|
||||||
+ "S:etcd-host", etcd,
|
+ "S:etcd_host", etcd,
|
||||||
+ "S:etcd-prefix", src->query,
|
+ "S:etcd_prefix", src->query,
|
||||||
+ "S:config-path", src->configFile,
|
+ "S:config_path", src->configFile,
|
||||||
+ "s:image", src->path,
|
+ "s:image", src->path,
|
||||||
+ NULL) < 0)
|
+ NULL) < 0)
|
||||||
+ return NULL;
|
+ return NULL;
|
||||||
|
|
@ -321,7 +293,7 @@ index f9c6da2..d837a05 100644
|
||||||
driver = "sheepdog";
|
driver = "sheepdog";
|
||||||
if (!(location = qemuBlockStorageSourceGetSheepdogProps(src)))
|
if (!(location = qemuBlockStorageSourceGetSheepdogProps(src)))
|
||||||
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
|
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
|
||||||
index 6f970a3..4c03fb8 100644
|
index 6f970a3..10b39ca 100644
|
||||||
--- a/src/qemu/qemu_command.c
|
--- a/src/qemu/qemu_command.c
|
||||||
+++ b/src/qemu/qemu_command.c
|
+++ b/src/qemu/qemu_command.c
|
||||||
@@ -1034,6 +1034,43 @@ qemuBuildNetworkDriveStr(virStorageSourcePtr src,
|
@@ -1034,6 +1034,43 @@ qemuBuildNetworkDriveStr(virStorageSourcePtr src,
|
||||||
|
|
@ -339,7 +311,7 @@ index 6f970a3..4c03fb8 100644
|
||||||
+ virBufferStrcat(&buf, "vitastor:image=", src->path, NULL);
|
+ virBufferStrcat(&buf, "vitastor:image=", src->path, NULL);
|
||||||
+
|
+
|
||||||
+ if (src->nhosts > 0) {
|
+ if (src->nhosts > 0) {
|
||||||
+ virBufferAddLit(&buf, ":etcd-host=");
|
+ virBufferAddLit(&buf, ":etcd_host=");
|
||||||
+ for (i = 0; i < src->nhosts; i++) {
|
+ for (i = 0; i < src->nhosts; i++) {
|
||||||
+ if (i)
|
+ if (i)
|
||||||
+ virBufferAddLit(&buf, ",");
|
+ virBufferAddLit(&buf, ",");
|
||||||
|
|
@ -357,10 +329,10 @@ index 6f970a3..4c03fb8 100644
|
||||||
+ }
|
+ }
|
||||||
+
|
+
|
||||||
+ if (src->configFile)
|
+ if (src->configFile)
|
||||||
+ virBufferEscape(&buf, '\\', ":", ":config-path=%s", src->configFile);
|
+ virBufferEscape(&buf, '\\', ":", ":config_path=%s", src->configFile);
|
||||||
+
|
+
|
||||||
+ if (src->query)
|
+ if (src->query)
|
||||||
+ virBufferEscape(&buf, '\\', ":", ":etcd-prefix=%s", src->query);
|
+ virBufferEscape(&buf, '\\', ":", ":etcd_prefix=%s", src->query);
|
||||||
+
|
+
|
||||||
+ ret = virBufferContentAndReset(&buf);
|
+ ret = virBufferContentAndReset(&buf);
|
||||||
+ break;
|
+ break;
|
||||||
|
|
@ -443,7 +415,7 @@ index 29c4c86..a27ad94 100644
|
||||||
case VIR_STORAGE_POOL_LOGICAL:
|
case VIR_STORAGE_POOL_LOGICAL:
|
||||||
case VIR_STORAGE_POOL_DISK:
|
case VIR_STORAGE_POOL_DISK:
|
||||||
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
|
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
|
||||||
index 0d3c2af..edb7f9e 100644
|
index 0d3c2af..36e3afc 100644
|
||||||
--- a/src/util/virstoragefile.c
|
--- a/src/util/virstoragefile.c
|
||||||
+++ b/src/util/virstoragefile.c
|
+++ b/src/util/virstoragefile.c
|
||||||
@@ -91,6 +91,7 @@ VIR_ENUM_IMPL(virStorageNetProtocol,
|
@@ -91,6 +91,7 @@ VIR_ENUM_IMPL(virStorageNetProtocol,
|
||||||
|
|
@ -490,14 +462,14 @@ index 0d3c2af..edb7f9e 100644
|
||||||
+
|
+
|
||||||
+ if (STRPREFIX(p, "image=")) {
|
+ if (STRPREFIX(p, "image=")) {
|
||||||
+ src->path = g_strdup(p + strlen("image="));
|
+ src->path = g_strdup(p + strlen("image="));
|
||||||
+ } else if (STRPREFIX(p, "etcd-prefix=")) {
|
+ } else if (STRPREFIX(p, "etcd_prefix=")) {
|
||||||
+ src->query = g_strdup(p + strlen("etcd-prefix="));
|
+ src->query = g_strdup(p + strlen("etcd_prefix="));
|
||||||
+ } else if (STRPREFIX(p, "config-path=")) {
|
+ } else if (STRPREFIX(p, "config_file=")) {
|
||||||
+ src->configFile = g_strdup(p + strlen("config-path="));
|
+ src->configFile = g_strdup(p + strlen("config_file="));
|
||||||
+ } else if (STRPREFIX(p, "etcd-host=")) {
|
+ } else if (STRPREFIX(p, "etcd_host=")) {
|
||||||
+ char *h, *sep;
|
+ char *h, *sep;
|
||||||
+
|
+
|
||||||
+ h = p + strlen("etcd-host=");
|
+ h = p + strlen("etcd_host=");
|
||||||
+ while (h < e) {
|
+ while (h < e) {
|
||||||
+ for (sep = h; sep < e; ++sep) {
|
+ for (sep = h; sep < e; ++sep) {
|
||||||
+ if (*sep == '\\' && (sep[1] == ',' ||
|
+ if (*sep == '\\' && (sep[1] == ',' ||
|
||||||
|
|
@ -554,8 +526,8 @@ index 0d3c2af..edb7f9e 100644
|
||||||
+{
|
+{
|
||||||
+ const char *filename;
|
+ const char *filename;
|
||||||
+ const char *image = virJSONValueObjectGetString(json, "image");
|
+ const char *image = virJSONValueObjectGetString(json, "image");
|
||||||
+ const char *conf = virJSONValueObjectGetString(json, "config-path");
|
+ const char *conf = virJSONValueObjectGetString(json, "config_path");
|
||||||
+ const char *etcd_prefix = virJSONValueObjectGetString(json, "etcd-prefix");
|
+ const char *etcd_prefix = virJSONValueObjectGetString(json, "etcd_prefix");
|
||||||
+ virJSONValuePtr servers = virJSONValueObjectGetArray(json, "server");
|
+ virJSONValuePtr servers = virJSONValueObjectGetArray(json, "server");
|
||||||
+ size_t nservers;
|
+ size_t nservers;
|
||||||
+ size_t i;
|
+ size_t i;
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
commit c97d7f2bfb7798f0d68bdba2646245dcfb940efa
|
commit c6e1958a1b4974828e8e5852beb252ce6594e670
|
||||||
Author: Vitaliy Filippov <vitalif@yourcmc.ru>
|
Author: Vitaliy Filippov <vitalif@yourcmc.ru>
|
||||||
Date: Mon Jun 28 01:20:19 2021 +0300
|
Date: Mon Jun 28 01:20:19 2021 +0300
|
||||||
|
|
||||||
|
|
@ -86,37 +86,6 @@ index d78f846..f7222e3 100644
|
||||||
case VIR_STORAGE_POOL_SHEEPDOG:
|
case VIR_STORAGE_POOL_SHEEPDOG:
|
||||||
case VIR_STORAGE_POOL_GLUSTER:
|
case VIR_STORAGE_POOL_GLUSTER:
|
||||||
case VIR_STORAGE_POOL_LAST:
|
case VIR_STORAGE_POOL_LAST:
|
||||||
diff --git a/src/conf/domain_validate.c b/src/conf/domain_validate.c
|
|
||||||
index 2124d25..6acc6fa 100644
|
|
||||||
--- a/src/conf/domain_validate.c
|
|
||||||
+++ b/src/conf/domain_validate.c
|
|
||||||
@@ -470,7 +470,7 @@ virDomainDiskDefValidateSourceChainOne(const virStorageSource *src)
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
- /* internal snapshots and config files are currently supported only with rbd: */
|
|
||||||
+ /* internal snapshots are currently supported only with rbd: */
|
|
||||||
if (virStorageSourceGetActualType(src) != VIR_STORAGE_TYPE_NETWORK &&
|
|
||||||
src->protocol != VIR_STORAGE_NET_PROTOCOL_RBD) {
|
|
||||||
if (src->snapshot) {
|
|
||||||
@@ -479,11 +479,15 @@ virDomainDiskDefValidateSourceChainOne(const virStorageSource *src)
|
|
||||||
"only with 'rbd' disks"));
|
|
||||||
return -1;
|
|
||||||
}
|
|
||||||
-
|
|
||||||
+ }
|
|
||||||
+ /* config files are currently supported only with rbd and vitastor: */
|
|
||||||
+ if (virStorageSourceGetActualType(src) != VIR_STORAGE_TYPE_NETWORK &&
|
|
||||||
+ src->protocol != VIR_STORAGE_NET_PROTOCOL_RBD &&
|
|
||||||
+ src->protocol != VIR_STORAGE_NET_PROTOCOL_VITASTOR) {
|
|
||||||
if (src->configFile) {
|
|
||||||
virReportError(VIR_ERR_XML_ERROR, "%s",
|
|
||||||
_("<config> element is currently supported "
|
|
||||||
- "only with 'rbd' disks"));
|
|
||||||
+ "only with 'rbd' and 'vitastor' disks"));
|
|
||||||
return -1;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c
|
diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c
|
||||||
index 2aa9a3d..166ca1f 100644
|
index 2aa9a3d..166ca1f 100644
|
||||||
--- a/src/conf/storage_conf.c
|
--- a/src/conf/storage_conf.c
|
||||||
|
|
@ -279,7 +248,7 @@ index c0905b0..c172378 100644
|
||||||
case VIR_STORAGE_NET_PROTOCOL_NONE:
|
case VIR_STORAGE_NET_PROTOCOL_NONE:
|
||||||
virReportError(VIR_ERR_NO_SUPPORT,
|
virReportError(VIR_ERR_NO_SUPPORT,
|
||||||
diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
|
diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
|
||||||
index 6627d04..f769d24 100644
|
index 6627d04..c33f428 100644
|
||||||
--- a/src/qemu/qemu_block.c
|
--- a/src/qemu/qemu_block.c
|
||||||
+++ b/src/qemu/qemu_block.c
|
+++ b/src/qemu/qemu_block.c
|
||||||
@@ -928,6 +928,38 @@ qemuBlockStorageSourceGetRBDProps(virStorageSource *src,
|
@@ -928,6 +928,38 @@ qemuBlockStorageSourceGetRBDProps(virStorageSource *src,
|
||||||
|
|
@ -307,9 +276,9 @@ index 6627d04..f769d24 100644
|
||||||
+ }
|
+ }
|
||||||
+
|
+
|
||||||
+ if (virJSONValueObjectCreate(&ret,
|
+ if (virJSONValueObjectCreate(&ret,
|
||||||
+ "S:etcd-host", etcd,
|
+ "S:etcd_host", etcd,
|
||||||
+ "S:etcd-prefix", src->query,
|
+ "S:etcd_prefix", src->query,
|
||||||
+ "S:config-path", src->configFile,
|
+ "S:config_path", src->configFile,
|
||||||
+ "s:image", src->path,
|
+ "s:image", src->path,
|
||||||
+ NULL) < 0)
|
+ NULL) < 0)
|
||||||
+ return NULL;
|
+ return NULL;
|
||||||
|
|
@ -356,7 +325,7 @@ index 6627d04..f769d24 100644
|
||||||
driver = "sheepdog";
|
driver = "sheepdog";
|
||||||
if (!(location = qemuBlockStorageSourceGetSheepdogProps(src)))
|
if (!(location = qemuBlockStorageSourceGetSheepdogProps(src)))
|
||||||
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
|
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
|
||||||
index ea51369..d714597 100644
|
index ea51369..8258632 100644
|
||||||
--- a/src/qemu/qemu_command.c
|
--- a/src/qemu/qemu_command.c
|
||||||
+++ b/src/qemu/qemu_command.c
|
+++ b/src/qemu/qemu_command.c
|
||||||
@@ -1074,6 +1074,43 @@ qemuBuildNetworkDriveStr(virStorageSource *src,
|
@@ -1074,6 +1074,43 @@ qemuBuildNetworkDriveStr(virStorageSource *src,
|
||||||
|
|
@ -374,7 +343,7 @@ index ea51369..d714597 100644
|
||||||
+ virBufferStrcat(&buf, "vitastor:image=", src->path, NULL);
|
+ virBufferStrcat(&buf, "vitastor:image=", src->path, NULL);
|
||||||
+
|
+
|
||||||
+ if (src->nhosts > 0) {
|
+ if (src->nhosts > 0) {
|
||||||
+ virBufferAddLit(&buf, ":etcd-host=");
|
+ virBufferAddLit(&buf, ":etcd_host=");
|
||||||
+ for (i = 0; i < src->nhosts; i++) {
|
+ for (i = 0; i < src->nhosts; i++) {
|
||||||
+ if (i)
|
+ if (i)
|
||||||
+ virBufferAddLit(&buf, ",");
|
+ virBufferAddLit(&buf, ",");
|
||||||
|
|
@ -392,10 +361,10 @@ index ea51369..d714597 100644
|
||||||
+ }
|
+ }
|
||||||
+
|
+
|
||||||
+ if (src->configFile)
|
+ if (src->configFile)
|
||||||
+ virBufferEscape(&buf, '\\', ":", ":config-path=%s", src->configFile);
|
+ virBufferEscape(&buf, '\\', ":", ":config_path=%s", src->configFile);
|
||||||
+
|
+
|
||||||
+ if (src->query)
|
+ if (src->query)
|
||||||
+ virBufferEscape(&buf, '\\', ":", ":etcd-prefix=%s", src->query);
|
+ virBufferEscape(&buf, '\\', ":", ":etcd_prefix=%s", src->query);
|
||||||
+
|
+
|
||||||
+ ret = virBufferContentAndReset(&buf);
|
+ ret = virBufferContentAndReset(&buf);
|
||||||
+ break;
|
+ break;
|
||||||
|
|
@ -466,7 +435,7 @@ index c2ff4b8..70d0689 100644
|
||||||
case VIR_STORAGE_POOL_ZFS:
|
case VIR_STORAGE_POOL_ZFS:
|
||||||
case VIR_STORAGE_POOL_LAST:
|
case VIR_STORAGE_POOL_LAST:
|
||||||
diff --git a/src/storage_file/storage_source_backingstore.c b/src/storage_file/storage_source_backingstore.c
|
diff --git a/src/storage_file/storage_source_backingstore.c b/src/storage_file/storage_source_backingstore.c
|
||||||
index e48ae72..2017ccc 100644
|
index e48ae72..d7a9b72 100644
|
||||||
--- a/src/storage_file/storage_source_backingstore.c
|
--- a/src/storage_file/storage_source_backingstore.c
|
||||||
+++ b/src/storage_file/storage_source_backingstore.c
|
+++ b/src/storage_file/storage_source_backingstore.c
|
||||||
@@ -284,6 +284,75 @@ virStorageSourceParseRBDColonString(const char *rbdstr,
|
@@ -284,6 +284,75 @@ virStorageSourceParseRBDColonString(const char *rbdstr,
|
||||||
|
|
@ -505,14 +474,14 @@ index e48ae72..2017ccc 100644
|
||||||
+
|
+
|
||||||
+ if (STRPREFIX(p, "image=")) {
|
+ if (STRPREFIX(p, "image=")) {
|
||||||
+ src->path = g_strdup(p + strlen("image="));
|
+ src->path = g_strdup(p + strlen("image="));
|
||||||
+ } else if (STRPREFIX(p, "etcd-prefix=")) {
|
+ } else if (STRPREFIX(p, "etcd_prefix=")) {
|
||||||
+ src->query = g_strdup(p + strlen("etcd-prefix="));
|
+ src->query = g_strdup(p + strlen("etcd_prefix="));
|
||||||
+ } else if (STRPREFIX(p, "config-path=")) {
|
+ } else if (STRPREFIX(p, "config_file=")) {
|
||||||
+ src->configFile = g_strdup(p + strlen("config-path="));
|
+ src->configFile = g_strdup(p + strlen("config_file="));
|
||||||
+ } else if (STRPREFIX(p, "etcd-host=")) {
|
+ } else if (STRPREFIX(p, "etcd_host=")) {
|
||||||
+ char *h, *sep;
|
+ char *h, *sep;
|
||||||
+
|
+
|
||||||
+ h = p + strlen("etcd-host=");
|
+ h = p + strlen("etcd_host=");
|
||||||
+ while (h < e) {
|
+ while (h < e) {
|
||||||
+ for (sep = h; sep < e; ++sep) {
|
+ for (sep = h; sep < e; ++sep) {
|
||||||
+ if (*sep == '\\' && (sep[1] == ',' ||
|
+ if (*sep == '\\' && (sep[1] == ',' ||
|
||||||
|
|
@ -569,8 +538,8 @@ index e48ae72..2017ccc 100644
|
||||||
+{
|
+{
|
||||||
+ const char *filename;
|
+ const char *filename;
|
||||||
+ const char *image = virJSONValueObjectGetString(json, "image");
|
+ const char *image = virJSONValueObjectGetString(json, "image");
|
||||||
+ const char *conf = virJSONValueObjectGetString(json, "config-path");
|
+ const char *conf = virJSONValueObjectGetString(json, "config_path");
|
||||||
+ const char *etcd_prefix = virJSONValueObjectGetString(json, "etcd-prefix");
|
+ const char *etcd_prefix = virJSONValueObjectGetString(json, "etcd_prefix");
|
||||||
+ virJSONValue *servers = virJSONValueObjectGetArray(json, "server");
|
+ virJSONValue *servers = virJSONValueObjectGetArray(json, "server");
|
||||||
+ size_t nservers;
|
+ size_t nservers;
|
||||||
+ size_t i;
|
+ size_t i;
|
||||||
|
|
@ -15,10 +15,9 @@
|
||||||
<target dev='vda' bus='virtio' />
|
<target dev='vda' bus='virtio' />
|
||||||
<driver name='qemu' type='raw' />
|
<driver name='qemu' type='raw' />
|
||||||
<!-- name is Vitastor image name -->
|
<!-- name is Vitastor image name -->
|
||||||
<!-- query (optional) is Vitastor's etcd_prefix -->
|
|
||||||
<source protocol='vitastor' name='debian9' query='/vitastor'>
|
|
||||||
<!-- config (optional) is the path to Vitastor's configuration file -->
|
<!-- config (optional) is the path to Vitastor's configuration file -->
|
||||||
<config file='/etc/vitastor/vitastor.conf' />
|
<!-- query (optional) is Vitastor's etcd_prefix -->
|
||||||
|
<source protocol='vitastor' name='debian9' query='/vitastor' config='/etc/vitastor/vitastor.conf'>
|
||||||
<!-- hosts = etcd addresses -->
|
<!-- hosts = etcd addresses -->
|
||||||
<host name='192.168.7.2' port='2379' />
|
<host name='192.168.7.2' port='2379' />
|
||||||
</source>
|
</source>
|
||||||
|
|
@ -1 +1 @@
|
||||||
Subproject commit 45e6d1f13196a0824e2089a586c53b9de0283f17
|
Subproject commit 5dc108754ad40d3b1d024f9bd7cca0595ef1a1db
|
||||||
|
|
@ -1,2 +1,3 @@
|
||||||
vitastor-csi
|
vitastor-csi
|
||||||
|
go.sum
|
||||||
Dockerfile
|
Dockerfile
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
# Compile stage
|
# Compile stage
|
||||||
FROM golang:buster AS build
|
FROM golang:buster AS build
|
||||||
|
|
||||||
ADD go.sum go.mod /app/
|
ADD go.mod /app/
|
||||||
RUN cd /app; CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go mod download -x
|
RUN cd /app; CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go mod download -x
|
||||||
ADD . /app
|
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'`
|
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'`
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
VERSION ?= v0.6.17
|
VERSION ?= v0.6.4
|
||||||
|
|
||||||
all: build push
|
all: build push
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -49,7 +49,7 @@ spec:
|
||||||
capabilities:
|
capabilities:
|
||||||
add: ["SYS_ADMIN"]
|
add: ["SYS_ADMIN"]
|
||||||
allowPrivilegeEscalation: true
|
allowPrivilegeEscalation: true
|
||||||
image: vitalif/vitastor-csi:v0.6.17
|
image: vitalif/vitastor-csi:v0.6.4
|
||||||
args:
|
args:
|
||||||
- "--node=$(NODE_ID)"
|
- "--node=$(NODE_ID)"
|
||||||
- "--endpoint=$(CSI_ENDPOINT)"
|
- "--endpoint=$(CSI_ENDPOINT)"
|
||||||
|
|
|
||||||
|
|
@ -116,7 +116,7 @@ spec:
|
||||||
privileged: true
|
privileged: true
|
||||||
capabilities:
|
capabilities:
|
||||||
add: ["SYS_ADMIN"]
|
add: ["SYS_ADMIN"]
|
||||||
image: vitalif/vitastor-csi:v0.6.17
|
image: vitalif/vitastor-csi:v0.6.4
|
||||||
args:
|
args:
|
||||||
- "--node=$(NODE_ID)"
|
- "--node=$(NODE_ID)"
|
||||||
- "--endpoint=$(CSI_ENDPOINT)"
|
- "--endpoint=$(CSI_ENDPOINT)"
|
||||||
|
|
|
||||||
|
|
@ -1,13 +0,0 @@
|
||||||
---
|
|
||||||
apiVersion: v1
|
|
||||||
kind: PersistentVolumeClaim
|
|
||||||
metadata:
|
|
||||||
name: test-vitastor-pvc-block
|
|
||||||
spec:
|
|
||||||
storageClassName: vitastor
|
|
||||||
volumeMode: Block
|
|
||||||
accessModes:
|
|
||||||
- ReadWriteMany
|
|
||||||
resources:
|
|
||||||
requests:
|
|
||||||
storage: 10Gi
|
|
||||||
|
|
@ -1,17 +0,0 @@
|
||||||
apiVersion: v1
|
|
||||||
kind: Pod
|
|
||||||
metadata:
|
|
||||||
name: vitastor-test-block-pvc
|
|
||||||
namespace: default
|
|
||||||
spec:
|
|
||||||
containers:
|
|
||||||
- name: vitastor-test-block-pvc
|
|
||||||
image: nginx
|
|
||||||
volumeDevices:
|
|
||||||
- name: data
|
|
||||||
devicePath: /dev/xvda
|
|
||||||
volumes:
|
|
||||||
- name: data
|
|
||||||
persistentVolumeClaim:
|
|
||||||
claimName: test-vitastor-pvc-block
|
|
||||||
readOnly: false
|
|
||||||
|
|
@ -1,17 +0,0 @@
|
||||||
apiVersion: v1
|
|
||||||
kind: Pod
|
|
||||||
metadata:
|
|
||||||
name: vitastor-test-nginx
|
|
||||||
namespace: default
|
|
||||||
spec:
|
|
||||||
containers:
|
|
||||||
- name: vitastor-test-nginx
|
|
||||||
image: nginx
|
|
||||||
volumeMounts:
|
|
||||||
- mountPath: /usr/share/nginx/html/s3
|
|
||||||
name: data
|
|
||||||
volumes:
|
|
||||||
- name: data
|
|
||||||
persistentVolumeClaim:
|
|
||||||
claimName: test-vitastor-pvc
|
|
||||||
readOnly: false
|
|
||||||
448
csi/go.sum
448
csi/go.sum
|
|
@ -1,448 +0,0 @@
|
||||||
cloud.google.com/go v0.34.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw=
|
|
||||||
cloud.google.com/go v0.38.0/go.mod h1:990N+gfupTy94rShfmMCWGDn0LpTmnzTp2qbd1dvSRU=
|
|
||||||
cloud.google.com/go v0.44.1/go.mod h1:iSa0KzasP4Uvy3f1mN/7PiObzGgflwredwwASm/v6AU=
|
|
||||||
cloud.google.com/go v0.44.2/go.mod h1:60680Gw3Yr4ikxnPRS/oxxkBccT6SA1yMk63TGekxKY=
|
|
||||||
cloud.google.com/go v0.45.1/go.mod h1:RpBamKRgapWJb87xiFSdk4g1CME7QZg3uwTez+TSTjc=
|
|
||||||
cloud.google.com/go v0.46.3/go.mod h1:a6bKKbmY7er1mI7TEI4lsAkts/mkhTSZK8w33B4RAg0=
|
|
||||||
cloud.google.com/go v0.51.0/go.mod h1:hWtGJ6gnXH+KgDv+V0zFGDvpi07n3z8ZNj3T1RW0Gcw=
|
|
||||||
cloud.google.com/go/bigquery v1.0.1/go.mod h1:i/xbL2UlR5RvWAURpBYZTtm/cXjCha9lbfbpx4poX+o=
|
|
||||||
cloud.google.com/go/datastore v1.0.0/go.mod h1:LXYbyblFSglQ5pkeyhO+Qmw7ukd3C+pD7TKLgZqpHYE=
|
|
||||||
cloud.google.com/go/pubsub v1.0.1/go.mod h1:R0Gpsv3s54REJCy4fxDixWD93lHJMoZTyQ2kNxGRt3I=
|
|
||||||
cloud.google.com/go/storage v1.0.0/go.mod h1:IhtSnM/ZTZV8YYJWCY8RULGVqBDmpoyjwiyrjsg+URw=
|
|
||||||
dmitri.shuralyov.com/gpu/mtl v0.0.0-20190408044501-666a987793e9/go.mod h1:H6x//7gZCb22OMCxBHrMx7a5I7Hp++hsVxbQ4BYO7hU=
|
|
||||||
github.com/Azure/go-ansiterm v0.0.0-20170929234023-d6e3b3328b78/go.mod h1:LmzpDX56iTiv29bbRTIsUNlaFfuhWRQBWjQdVyAevI8=
|
|
||||||
github.com/Azure/go-autorest/autorest v0.9.0/go.mod h1:xyHB1BMZT0cuDHU7I0+g046+BFDTQ8rEZB0s4Yfa6bI=
|
|
||||||
github.com/Azure/go-autorest/autorest v0.9.6/go.mod h1:/FALq9T/kS7b5J5qsQ+RSTUdAmGFqi0vUdVNNx8q630=
|
|
||||||
github.com/Azure/go-autorest/autorest/adal v0.5.0/go.mod h1:8Z9fGy2MpX0PvDjB1pEgQTmVqjGhiHBW7RJJEciWzS0=
|
|
||||||
github.com/Azure/go-autorest/autorest/adal v0.8.2/go.mod h1:ZjhuQClTqx435SRJ2iMlOxPYt3d2C/T/7TiQCVZSn3Q=
|
|
||||||
github.com/Azure/go-autorest/autorest/date v0.1.0/go.mod h1:plvfp3oPSKwf2DNjlBjWF/7vwR+cUD/ELuzDCXwHUVA=
|
|
||||||
github.com/Azure/go-autorest/autorest/date v0.2.0/go.mod h1:vcORJHLJEh643/Ioh9+vPmf1Ij9AEBM5FuBIXLmIy0g=
|
|
||||||
github.com/Azure/go-autorest/autorest/mocks v0.1.0/go.mod h1:OTyCOPRA2IgIlWxVYxBee2F5Gr4kF2zd2J5cFRaIDN0=
|
|
||||||
github.com/Azure/go-autorest/autorest/mocks v0.2.0/go.mod h1:OTyCOPRA2IgIlWxVYxBee2F5Gr4kF2zd2J5cFRaIDN0=
|
|
||||||
github.com/Azure/go-autorest/autorest/mocks v0.3.0/go.mod h1:a8FDP3DYzQ4RYfVAxAN3SVSiiO77gL2j2ronKKP0syM=
|
|
||||||
github.com/Azure/go-autorest/logger v0.1.0/go.mod h1:oExouG+K6PryycPJfVSxi/koC6LSNgds39diKLz7Vrc=
|
|
||||||
github.com/Azure/go-autorest/tracing v0.5.0/go.mod h1:r/s2XiOKccPW3HrqB+W0TQzfbtp2fGCgRFtBroKn4Dk=
|
|
||||||
github.com/BurntSushi/toml v0.3.1/go.mod h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU=
|
|
||||||
github.com/BurntSushi/xgb v0.0.0-20160522181843-27f122750802/go.mod h1:IVnqGOEym/WlBOVXweHU+Q+/VP0lqqI8lqeDx9IjBqo=
|
|
||||||
github.com/NYTimes/gziphandler v0.0.0-20170623195520-56545f4a5d46/go.mod h1:3wb06e3pkSAbeQ52E9H9iFoQsEEwGN64994WTCIhntQ=
|
|
||||||
github.com/PuerkitoBio/purell v1.0.0/go.mod h1:c11w/QuzBsJSee3cPx9rAFu61PvFxuPbtSwDGJws/X0=
|
|
||||||
github.com/PuerkitoBio/urlesc v0.0.0-20160726150825-5bd2802263f2/go.mod h1:uGdkoq3SwY9Y+13GIhn11/XLaGBb4BfwItxLd5jeuXE=
|
|
||||||
github.com/alecthomas/template v0.0.0-20160405071501-a0175ee3bccc/go.mod h1:LOuyumcjzFXgccqObfd/Ljyb9UuFJ6TxHnclSeseNhc=
|
|
||||||
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.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=
|
|
||||||
github.com/envoyproxy/protoc-gen-validate v0.1.0/go.mod h1:iSmxcyjqTsJpI2R4NaDN7+kN2VEUnK/pcBlmesArF7c=
|
|
||||||
github.com/evanphx/json-patch v4.9.0+incompatible/go.mod h1:50XU6AFN0ol/bzJsmQLiYLvXMP4fmwYFNcr97nuDLSk=
|
|
||||||
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=
|
|
||||||
github.com/go-logfmt/logfmt v0.3.0/go.mod h1:Qt1PoO58o5twSAckw1HlFXLmHsOX5/0LbT9GBnD5lWE=
|
|
||||||
github.com/go-logfmt/logfmt v0.4.0/go.mod h1:3RMwSq7FuexP4Kalkev3ejPJsZTpXXBr9+V4qmtdjCk=
|
|
||||||
github.com/go-logr/logr v0.1.0/go.mod h1:ixOQHD9gLJUVQQ2ZOR7zLEifBX6tGkNJF4QyIY7sIas=
|
|
||||||
github.com/go-logr/logr v0.2.0 h1:QvGt2nLcHH0WK9orKa+ppBPAxREcH364nPUedEpK0TY=
|
|
||||||
github.com/go-logr/logr v0.2.0/go.mod h1:z6/tIYblkpsD+a4lm/fGIIU9mZ+XfAiaFtq7xTgseGU=
|
|
||||||
github.com/go-openapi/jsonpointer v0.0.0-20160704185906-46af16f9f7b1/go.mod h1:+35s3my2LFTysnkMfxsJBAMHj/DoqoB9knIWoYG/Vk0=
|
|
||||||
github.com/go-openapi/jsonreference v0.0.0-20160704190145-13c6e3589ad9/go.mod h1:W3Z9FmVs9qj+KR4zFKmDPGiLdk1D9Rlm7cyMvf57TTg=
|
|
||||||
github.com/go-openapi/spec v0.0.0-20160808142527-6aced65f8501/go.mod h1:J8+jY1nAiCcj+friV/PDoE1/3eeccG9LYBs0tYvLOWc=
|
|
||||||
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=
|
|
||||||
github.com/golang/mock v1.3.1/go.mod h1:sBzyDLLjw3U8JLTeZvSv8jJB+tU5PVekmnlKIyFUx0Y=
|
|
||||||
github.com/golang/protobuf v1.2.0/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
|
|
||||||
github.com/golang/protobuf v1.3.1/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
|
|
||||||
github.com/golang/protobuf v1.3.2/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U=
|
|
||||||
github.com/golang/protobuf v1.3.3/go.mod h1:vzj43D7+SQXF/4pzW/hwtAqwc6iTitCiVSaWz5lYuqw=
|
|
||||||
github.com/golang/protobuf v1.4.0-rc.1/go.mod h1:ceaxUfeHdC40wWswd/P6IGgMaK3YpKi5j83Wpe3EHw8=
|
|
||||||
github.com/golang/protobuf v1.4.0-rc.1.0.20200221234624-67d41d38c208/go.mod h1:xKAWHe0F5eneWXFV3EuXVDTCmh+JuBKY0li0aMyXATA=
|
|
||||||
github.com/golang/protobuf v1.4.0-rc.2/go.mod h1:LlEzMj4AhA7rCAGe4KMBDvJI+AwstrUpVNzEA03Pprs=
|
|
||||||
github.com/golang/protobuf v1.4.0-rc.4.0.20200313231945-b860323f09d0/go.mod h1:WU3c8KckQ9AFe+yFwt9sWVRKCVIyN9cPHBJSNnbL67w=
|
|
||||||
github.com/golang/protobuf v1.4.0/go.mod h1:jodUvKwWbYaEsadDk5Fwe5c77LiNKVO9IDvqG2KuDX0=
|
|
||||||
github.com/golang/protobuf v1.4.1/go.mod h1:U8fpvMrcmy5pZrNK1lt4xCsGvpyWQ/VVv6QDs8UjoX8=
|
|
||||||
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=
|
|
||||||
github.com/google/go-cmp v0.3.1/go.mod h1:8QqcDgzrUqlUb/G2PQTWiueGozuR1884gddMywk6iLU=
|
|
||||||
github.com/google/go-cmp v0.4.0 h1:xsAVV57WRhGj6kEIi8ReJzQlHHqcBYCElAvkovg3B/4=
|
|
||||||
github.com/google/go-cmp v0.4.0/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
|
|
||||||
github.com/google/gofuzz v1.0.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg=
|
|
||||||
github.com/google/gofuzz v1.1.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg=
|
|
||||||
github.com/google/martian v2.1.0+incompatible/go.mod h1:9I4somxYTbIHy5NJKHRl3wXiIaQGbYVAs8BPL6v8lEs=
|
|
||||||
github.com/google/pprof v0.0.0-20181206194817-3ea8567a2e57/go.mod h1:zfwlbNMJ+OItoe0UupaVj+oy1omPYYDuagoSzA8v9mc=
|
|
||||||
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=
|
|
||||||
github.com/kr/pretty v0.2.0 h1:s5hAObm+yFO5uHYt5dYjxi2rXrsnmRpJx4OYvIWUaQs=
|
|
||||||
github.com/kr/pretty v0.2.0/go.mod h1:ipq/a2n7PKx3OHsz4KJII5eveXtPO4qwEXGdVfWzfnI=
|
|
||||||
github.com/kr/pty v1.1.1/go.mod h1:pFQYn66WHrOpPYNljwOMqo10TkYh1fy3cYio2l3bCsQ=
|
|
||||||
github.com/kr/text v0.1.0 h1:45sCR5RtlFHMR4UwH9sdQ5TC8v0qDQCHnXt+kaKSTVE=
|
|
||||||
github.com/kr/text v0.1.0/go.mod h1:4Jbv+DJW3UT/LiOwJeYQe1efqtUx/iVham/4vfdArNI=
|
|
||||||
github.com/kubernetes-csi/csi-lib-utils v0.9.1 h1:sGq6ifVujfMSkfTsMZip44Ttv8SDXvsBlFk9GdYl/b8=
|
|
||||||
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=
|
|
||||||
github.com/mxk/go-flowrate v0.0.0-20140419014527-cca7078d478f/go.mod h1:ZdcZmHo+o7JKHSa8/e818NopupXU1YMK5fe1lsApnBw=
|
|
||||||
github.com/onsi/ginkgo v0.0.0-20170829012221-11459a886d9c/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE=
|
|
||||||
github.com/onsi/ginkgo v1.6.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE=
|
|
||||||
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=
|
|
||||||
github.com/spf13/pflag v1.0.5/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg=
|
|
||||||
github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
|
|
||||||
github.com/stretchr/objx v0.1.1/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME=
|
|
||||||
github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs=
|
|
||||||
github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UVUgZn+9EI=
|
|
||||||
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/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=
|
|
||||||
golang.org/x/crypto v0.0.0-20190510104115-cbcb75029529/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI=
|
|
||||||
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/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=
|
|
||||||
golang.org/x/exp v0.0.0-20190829153037-c13cbed26979/go.mod h1:86+5VVa7VpoJ4kLfm080zCjGlMRFzhUhsZKEZO7MGek=
|
|
||||||
golang.org/x/exp v0.0.0-20191227195350-da58074b4299/go.mod h1:2RIsYlXP63K8oxa1u096TMicItID8zy7Y6sNkU49FU4=
|
|
||||||
golang.org/x/image v0.0.0-20190227222117-0694c2d4d067/go.mod h1:kZ7UVZpmo3dzQBMxlp+ypCbDeSB+sBbTgSJuh5dn5js=
|
|
||||||
golang.org/x/image v0.0.0-20190802002840-cff245a6509b/go.mod h1:FeLwcggjj3mMvU+oOTbSwawSJRM1uh48EjtB4UJZlP0=
|
|
||||||
golang.org/x/lint v0.0.0-20190227174305-5b3e6a55c961/go.mod h1:wehouNa3lNwaWXcvxsM5YxQ5yQlVC4a0KAMCusXpPoU=
|
|
||||||
golang.org/x/lint v0.0.0-20190301231843-5614ed5bae6f/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE=
|
|
||||||
golang.org/x/lint v0.0.0-20190313153728-d0100b6bd8b3/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc=
|
|
||||||
golang.org/x/lint v0.0.0-20190409202823-959b441ac422/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc=
|
|
||||||
golang.org/x/lint v0.0.0-20190909230951-414d861bb4ac/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc=
|
|
||||||
golang.org/x/lint v0.0.0-20191125180803-fdd1cda4f05f/go.mod h1:5qLYkcX4OjUUV8bRuDixDT3tpyyb+LUpUlRWLxfhWrs=
|
|
||||||
golang.org/x/mobile v0.0.0-20190312151609-d3739f865fa6/go.mod h1:z+o9i4GpDbdi3rU15maQ/Ox0txvL9dWGYEHz965HBQE=
|
|
||||||
golang.org/x/mobile v0.0.0-20190719004257-d2bd2a29d028/go.mod h1:E/iHnbuqvinMTCcRqshq8CkpyQDoeVncDDYHnLhea+o=
|
|
||||||
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.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=
|
|
||||||
golang.org/x/net v0.0.0-20190108225652-1e06a53dbb7e/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
|
|
||||||
golang.org/x/net v0.0.0-20190213061140-3a22650c66bd/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4=
|
|
||||||
golang.org/x/net v0.0.0-20190311183353-d8887717615a/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
|
|
||||||
golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
|
|
||||||
golang.org/x/net v0.0.0-20190501004415-9ce7a6920f09/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
|
|
||||||
golang.org/x/net v0.0.0-20190503192946-f4e77d36d62c/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg=
|
|
||||||
golang.org/x/net v0.0.0-20190603091049-60506f45cf65/go.mod h1:HSz+uSET+XFnRR8LxR5pz3Of3rY3CfYBVs4xY44aLks=
|
|
||||||
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-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-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=
|
|
||||||
golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY=
|
|
||||||
golang.org/x/sys v0.0.0-20190312061237-fead79001313/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
|
||||||
golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
|
||||||
golang.org/x/sys v0.0.0-20190422165155-953cdadca894/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
|
||||||
golang.org/x/sys v0.0.0-20190502145724-3ef323f4f1fd/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
|
||||||
golang.org/x/sys v0.0.0-20190507160741-ecd444e8653b/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
|
||||||
golang.org/x/sys v0.0.0-20190606165138-5da285871e9c/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
|
||||||
golang.org/x/sys v0.0.0-20190624142023-c5567b49c5d0/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
|
||||||
golang.org/x/sys v0.0.0-20191005200804-aed5e4c7ecf9/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
|
|
||||||
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-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/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=
|
|
||||||
golang.org/x/tools v0.0.0-20181030221726-6c7e314b6563/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=
|
|
||||||
golang.org/x/tools v0.0.0-20190226205152-f727befe758c/go.mod h1:9Yl7xja0Znq3iFh3HoIrodX9oNMXvdceNzlUR8zjMvY=
|
|
||||||
golang.org/x/tools v0.0.0-20190311212946-11955173bddd/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
|
|
||||||
golang.org/x/tools v0.0.0-20190312151545-0bb0c0a6e846/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
|
|
||||||
golang.org/x/tools v0.0.0-20190312170243-e65039ee4138/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs=
|
|
||||||
golang.org/x/tools v0.0.0-20190425150028-36563e24a262/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q=
|
|
||||||
golang.org/x/tools v0.0.0-20190506145303-2d16b83fe98c/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q=
|
|
||||||
golang.org/x/tools v0.0.0-20190524140312-2c0ae7006135/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q=
|
|
||||||
golang.org/x/tools v0.0.0-20190606124116-d0a3d012864b/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc=
|
|
||||||
golang.org/x/tools v0.0.0-20190621195816-6e04913cbbac/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc=
|
|
||||||
golang.org/x/tools v0.0.0-20190624222133-a101b041ded4/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc=
|
|
||||||
golang.org/x/tools v0.0.0-20190628153133-6cdbf07be9d0/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc=
|
|
||||||
golang.org/x/tools v0.0.0-20190816200558-6889da9d5479/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
|
|
||||||
golang.org/x/tools v0.0.0-20190911174233-4f2ddba30aff/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
|
|
||||||
golang.org/x/tools v0.0.0-20191012152004-8de300cfc20a/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo=
|
|
||||||
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.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=
|
|
||||||
google.golang.org/api v0.4.0/go.mod h1:8k5glujaEP+g9n7WNsDg8QP6cUVNI86fCNMcbazEtwE=
|
|
||||||
google.golang.org/api v0.7.0/go.mod h1:WtwebWUNSVBH/HAw79HIFXZNqEvBhG+Ra+ax0hx3E3M=
|
|
||||||
google.golang.org/api v0.8.0/go.mod h1:o4eAsZoiT+ibD93RtjEohWalFOjRDx6CVaqeizhEnKg=
|
|
||||||
google.golang.org/api v0.9.0/go.mod h1:o4eAsZoiT+ibD93RtjEohWalFOjRDx6CVaqeizhEnKg=
|
|
||||||
google.golang.org/api v0.15.0/go.mod h1:iLdEw5Ide6rF15KTC1Kkl0iskquN2gFfn9o9XIsbkAI=
|
|
||||||
google.golang.org/appengine v1.4.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4=
|
|
||||||
google.golang.org/appengine v1.5.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4=
|
|
||||||
google.golang.org/appengine v1.6.1/go.mod h1:i06prIuMbXzDqacNJfV5OdTW448YApPu5ww/cMBSeb0=
|
|
||||||
google.golang.org/appengine v1.6.5/go.mod h1:8WjMMxjGQR8xUklV/ARdw2HLXBOI7O7uCIDZVag1xfc=
|
|
||||||
google.golang.org/genproto v0.0.0-20190307195333-5fe7a883aa19/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
|
|
||||||
google.golang.org/genproto v0.0.0-20190418145605-e7d98fc518a7/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
|
|
||||||
google.golang.org/genproto v0.0.0-20190425155659-357c62f0e4bb/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
|
|
||||||
google.golang.org/genproto v0.0.0-20190502173448-54afdca5d873/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE=
|
|
||||||
google.golang.org/genproto v0.0.0-20190801165951-fa694d86fc64/go.mod h1:DMBHOl98Agz4BDEuKkezgsaosCRResVns1a3J2ZsMNc=
|
|
||||||
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=
|
|
||||||
google.golang.org/grpc v1.25.1/go.mod h1:c3i+UQWmh7LiEpx4sFZnkU36qjEYZ0imhYfXVyQciAY=
|
|
||||||
google.golang.org/protobuf v0.0.0-20200109180630-ec00e32a8dfd/go.mod h1:DFci5gLYBciE7Vtevhsrf46CRTquxDuWsQurQQe4oz8=
|
|
||||||
google.golang.org/protobuf v0.0.0-20200221191635-4d8936d0db64/go.mod h1:kwYJMbMJ01Woi6D6+Kah6886xMZcty6N08ah7+eCXa0=
|
|
||||||
google.golang.org/protobuf v0.0.0-20200228230310-ab0ca4ff8a60/go.mod h1:cfTl7dwQJ+fmap5saPgwCLgHXTUD7jkjRqWcaiX5VyM=
|
|
||||||
google.golang.org/protobuf v1.20.1-0.20200309200217-e05f789c0967/go.mod h1:A+miEFZTKqfCUM6K7xSMQL9OKL/b6hQv+e19PK+JZNE=
|
|
||||||
google.golang.org/protobuf v1.21.0/go.mod h1:47Nbq4nVaFHyn7ilMalzfO3qCViNmqZ2kzikPIcrTAo=
|
|
||||||
google.golang.org/protobuf v1.22.0/go.mod h1:EGpADcykh3NcUnDUJcl1+ZksZNG86OlYog2l/sGQquU=
|
|
||||||
google.golang.org/protobuf v1.23.0/go.mod h1:EGpADcykh3NcUnDUJcl1+ZksZNG86OlYog2l/sGQquU=
|
|
||||||
google.golang.org/protobuf v1.23.1-0.20200526195155-81db48ad09cc/go.mod h1:EGpADcykh3NcUnDUJcl1+ZksZNG86OlYog2l/sGQquU=
|
|
||||||
google.golang.org/protobuf v1.24.0 h1:UhZDfRO8JRQru4/+LlLE0BRKGF8L+PICnvYZmx/fEGA=
|
|
||||||
google.golang.org/protobuf v1.24.0/go.mod h1:r/3tXBNzIEhYS9I1OUVjXDlt8tc493IdKGjtUeSXeh4=
|
|
||||||
gopkg.in/alecthomas/kingpin.v2 v2.2.6/go.mod h1:FMv+mEhP44yOT+4EoQTLFTRgOQ1FBLkstjWtayDeSgw=
|
|
||||||
gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
|
|
||||||
gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
|
|
||||||
gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15 h1:YR8cESwS4TdDjEe65xsg0ogRM/Nc3DYOhEAlW+xobZo=
|
|
||||||
gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0=
|
|
||||||
gopkg.in/errgo.v2 v2.1.0/go.mod h1:hNsd1EY+bozCKY1Ytp96fpM3vjJbqLJn88ws8XvfDNI=
|
|
||||||
gopkg.in/fsnotify.v1 v1.4.7/go.mod h1:Tz8NjZHkW78fSQdbUxIjBTcgA1z1m8ZHf0WmKUhAMys=
|
|
||||||
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=
|
|
||||||
gopkg.in/yaml.v2 v2.2.8/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI=
|
|
||||||
gotest.tools v2.2.0+incompatible/go.mod h1:DsYFclhRJ6vuDpmuTbkuFWG+y2sxOXAzmJt81HFBacw=
|
|
||||||
gotest.tools/v3 v3.0.2/go.mod h1:3SzNCllyD9/Y+b5r9JIKQ474KzkZyqLqEfYqMsX94Bk=
|
|
||||||
honnef.co/go/tools v0.0.0-20190102054323-c2f93a96b099/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
|
|
||||||
honnef.co/go/tools v0.0.0-20190106161140-3f1c8253044a/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
|
|
||||||
honnef.co/go/tools v0.0.0-20190418001031-e561f6794a2a/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
|
|
||||||
honnef.co/go/tools v0.0.0-20190523083050-ea95bdfd59fc/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
|
|
||||||
honnef.co/go/tools v0.0.1-2019.2.3/go.mod h1:a3bituU0lyd329TUQxRnasdCoJDkEUEAqEt0JzvZhAg=
|
|
||||||
k8s.io/api v0.19.0/go.mod h1:I1K45XlvTrDjmj5LoM5LuP/KYrhWbjUKT/SoPG0qTjw=
|
|
||||||
k8s.io/apimachinery v0.19.0/go.mod h1:DnPGDnARWFvYa3pMHgSxtbZb7gpzzAZ1pTfaUNDVlmA=
|
|
||||||
k8s.io/client-go v0.19.0/go.mod h1:H9E/VT95blcFQnlyShFgnFT9ZnJOAceiUHM3MlRC+mU=
|
|
||||||
k8s.io/component-base v0.19.0/go.mod h1:dKsY8BxkA+9dZIAh2aWJLL/UdASFDNtGYTCItL4LM7Y=
|
|
||||||
k8s.io/gengo v0.0.0-20200413195148-3a45101e95ac/go.mod h1:ezvh/TsK7cY6rbqRK0oQQ8IAqLxYwwyPxAX1Pzy0ii0=
|
|
||||||
k8s.io/klog v1.0.0 h1:Pt+yjF5aB1xDSVbau4VsWe+dQNzA0qv1LlXdC2dF6Q8=
|
|
||||||
k8s.io/klog v1.0.0/go.mod h1:4Bi6QPql/J/LkTDqv7R/cd3hPo4k2DG6Ptcz060Ez5I=
|
|
||||||
k8s.io/klog/v2 v2.0.0/go.mod h1:PBfzABfn139FHAV07az/IF9Wp1bkk3vpT2XSJ76fSDE=
|
|
||||||
k8s.io/klog/v2 v2.2.0 h1:XRvcwJozkgZ1UQJmfMGpvRthQHOvihEhYtDfAaxMz/A=
|
|
||||||
k8s.io/klog/v2 v2.2.0/go.mod h1:Od+F08eJP+W3HUb4pSrPpgp9DGU4GzlpG/TmITuYh/Y=
|
|
||||||
k8s.io/kube-openapi v0.0.0-20200805222855-6aeccd4b50c6/go.mod h1:UuqjUnNftUyPE5H64/qeyjQoUZhGpeFDVdxjTeEVN2o=
|
|
||||||
k8s.io/utils v0.0.0-20200729134348-d5654de09c73/go.mod h1:jPW/WVKK9YHAvNhRxK0md/EJ228hCsBRufyofKtW8HA=
|
|
||||||
k8s.io/utils v0.0.0-20210305010621-2afb4311ab10 h1:u5rPykqiCpL+LBfjRkXvnK71gOgIdmq3eHUEkPrbeTI=
|
|
||||||
k8s.io/utils v0.0.0-20210305010621-2afb4311ab10/go.mod h1:jPW/WVKK9YHAvNhRxK0md/EJ228hCsBRufyofKtW8HA=
|
|
||||||
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 (
|
const (
|
||||||
vitastorCSIDriverName = "csi.vitastor.io"
|
vitastorCSIDriverName = "csi.vitastor.io"
|
||||||
vitastorCSIDriverVersion = "0.6.17"
|
vitastorCSIDriverVersion = "0.6.4"
|
||||||
)
|
)
|
||||||
|
|
||||||
// Config struct fills the parameters of request or user input
|
// Config struct fills the parameters of request or user input
|
||||||
|
|
|
||||||
|
|
@ -354,9 +354,9 @@ func (cs *ControllerServer) DeleteVolume(ctx context.Context, req *csi.DeleteVol
|
||||||
return nil, status.Error(codes.Internal, "invalid "+inodeCfgKey+" key in etcd: "+err.Error())
|
return nil, status.Error(codes.Internal, "invalid "+inodeCfgKey+" key in etcd: "+err.Error())
|
||||||
}
|
}
|
||||||
|
|
||||||
// Delete inode data by invoking vitastor-cli
|
// Delete inode data by invoking vitastor-rm
|
||||||
args := []string{
|
args := []string{
|
||||||
"rm-data", "--etcd_address", strings.Join(etcdUrl, ","),
|
"--etcd_address", strings.Join(etcdUrl, ","),
|
||||||
"--pool", fmt.Sprintf("%d", idx.PoolId),
|
"--pool", fmt.Sprintf("%d", idx.PoolId),
|
||||||
"--inode", fmt.Sprintf("%d", idx.Id),
|
"--inode", fmt.Sprintf("%d", idx.Id),
|
||||||
}
|
}
|
||||||
|
|
@ -364,7 +364,7 @@ func (cs *ControllerServer) DeleteVolume(ctx context.Context, req *csi.DeleteVol
|
||||||
{
|
{
|
||||||
args = append(args, "--config_path", ctxVars["configPath"])
|
args = append(args, "--config_path", ctxVars["configPath"])
|
||||||
}
|
}
|
||||||
c := exec.Command("/usr/bin/vitastor-cli", args...)
|
c := exec.Command("/usr/bin/vitastor-rm", args...)
|
||||||
var stderr bytes.Buffer
|
var stderr bytes.Buffer
|
||||||
c.Stdout = nil
|
c.Stdout = nil
|
||||||
c.Stderr = &stderr
|
c.Stderr = &stderr
|
||||||
|
|
@ -372,7 +372,7 @@ func (cs *ControllerServer) DeleteVolume(ctx context.Context, req *csi.DeleteVol
|
||||||
stderrStr := string(stderr.Bytes())
|
stderrStr := string(stderr.Bytes())
|
||||||
if (err != nil)
|
if (err != nil)
|
||||||
{
|
{
|
||||||
klog.Errorf("vitastor-cli rm-data failed: %s, status %s\n", stderrStr, err)
|
klog.Errorf("vitastor-rm failed: %s, status %s\n", stderrStr, err)
|
||||||
return nil, status.Error(codes.Internal, stderrStr+" (status "+err.Error()+")")
|
return nil, status.Error(codes.Internal, stderrStr+" (status "+err.Error()+")")
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -67,44 +67,29 @@ func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublis
|
||||||
klog.Infof("received node publish volume request %+v", protosanitizer.StripSecrets(req))
|
klog.Infof("received node publish volume request %+v", protosanitizer.StripSecrets(req))
|
||||||
|
|
||||||
targetPath := req.GetTargetPath()
|
targetPath := req.GetTargetPath()
|
||||||
isBlock := req.GetVolumeCapability().GetBlock() != nil
|
|
||||||
|
|
||||||
// Check that it's not already mounted
|
// Check that it's not already mounted
|
||||||
_, error := mount.IsNotMountPoint(ns.mounter, targetPath)
|
free, error := mount.IsNotMountPoint(ns.mounter, targetPath)
|
||||||
if (error != nil)
|
if (error != nil)
|
||||||
{
|
{
|
||||||
if (os.IsNotExist(error))
|
if (os.IsNotExist(error))
|
||||||
{
|
{
|
||||||
if (isBlock)
|
error := os.MkdirAll(targetPath, 0777)
|
||||||
|
if (error != nil)
|
||||||
{
|
{
|
||||||
pathFile, err := os.OpenFile(targetPath, os.O_CREATE|os.O_RDWR, 0o600)
|
return nil, status.Error(codes.Internal, error.Error())
|
||||||
if (err != nil)
|
|
||||||
{
|
|
||||||
klog.Errorf("failed to create block device mount target %s with error: %v", targetPath, err)
|
|
||||||
return nil, status.Error(codes.Internal, err.Error())
|
|
||||||
}
|
|
||||||
err = pathFile.Close()
|
|
||||||
if (err != nil)
|
|
||||||
{
|
|
||||||
klog.Errorf("failed to close %s with error: %v", targetPath, err)
|
|
||||||
return nil, status.Error(codes.Internal, err.Error())
|
|
||||||
}
|
|
||||||
}
|
|
||||||
else
|
|
||||||
{
|
|
||||||
err := os.MkdirAll(targetPath, 0777)
|
|
||||||
if (err != nil)
|
|
||||||
{
|
|
||||||
klog.Errorf("failed to create fs mount target %s with error: %v", targetPath, err)
|
|
||||||
return nil, status.Error(codes.Internal, err.Error())
|
|
||||||
}
|
|
||||||
}
|
}
|
||||||
|
free = true
|
||||||
}
|
}
|
||||||
else
|
else
|
||||||
{
|
{
|
||||||
return nil, status.Error(codes.Internal, error.Error())
|
return nil, status.Error(codes.Internal, error.Error())
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
if (!free)
|
||||||
|
{
|
||||||
|
return &csi.NodePublishVolumeResponse{}, nil
|
||||||
|
}
|
||||||
|
|
||||||
ctxVars := make(map[string]string)
|
ctxVars := make(map[string]string)
|
||||||
err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
|
err := json.Unmarshal([]byte(req.VolumeId), &ctxVars)
|
||||||
|
|
@ -164,6 +149,7 @@ func (ns *NodeServer) NodePublishVolume(ctx context.Context, req *csi.NodePublis
|
||||||
|
|
||||||
// Format the device (ext4 or xfs)
|
// Format the device (ext4 or xfs)
|
||||||
fsType := req.GetVolumeCapability().GetMount().GetFsType()
|
fsType := req.GetVolumeCapability().GetMount().GetFsType()
|
||||||
|
isBlock := req.GetVolumeCapability().GetBlock() != nil
|
||||||
opt := req.GetVolumeCapability().GetMount().GetMountFlags()
|
opt := req.GetVolumeCapability().GetMount().GetMountFlags()
|
||||||
opt = append(opt, "_netdev")
|
opt = append(opt, "_netdev")
|
||||||
if ((req.VolumeCapability.AccessMode.Mode == csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY ||
|
if ((req.VolumeCapability.AccessMode.Mode == csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY ||
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
#!/bin/bash
|
#!/bin/bash
|
||||||
|
|
||||||
cat < vitastor.Dockerfile > ../Dockerfile
|
sed 's/$REL/bullseye/g' < vitastor.Dockerfile > ../Dockerfile
|
||||||
cd ..
|
cd ..
|
||||||
mkdir -p packages
|
mkdir -p packages
|
||||||
sudo podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f Dockerfile .
|
sudo podman build -v `pwd`/packages:/root/packages -f Dockerfile .
|
||||||
rm Dockerfile
|
rm Dockerfile
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
#!/bin/bash
|
#!/bin/bash
|
||||||
|
|
||||||
cat < vitastor.Dockerfile > ../Dockerfile
|
sed 's/$REL/buster/g' < vitastor.Dockerfile > ../Dockerfile
|
||||||
cd ..
|
cd ..
|
||||||
mkdir -p packages
|
mkdir -p packages
|
||||||
sudo podman build --build-arg REL=buster -v `pwd`/packages:/root/packages -f Dockerfile .
|
sudo podman build -v `pwd`/packages:/root/packages -f Dockerfile .
|
||||||
rm Dockerfile
|
rm Dockerfile
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
vitastor (0.6.17-1) unstable; urgency=medium
|
vitastor (0.6.4-1) unstable; urgency=medium
|
||||||
|
|
||||||
* RDMA support
|
* RDMA support
|
||||||
* Bugfixes
|
* Bugfixes
|
||||||
|
|
|
||||||
|
|
@ -9,47 +9,9 @@ Rules-Requires-Root: no
|
||||||
|
|
||||||
Package: vitastor
|
Package: vitastor
|
||||||
Architecture: amd64
|
Architecture: amd64
|
||||||
Depends: vitastor-osd, vitastor-mon, vitastor-client, vitastor-client-dev, vitastor-fio
|
Depends: ${shlibs:Depends}, ${misc:Depends}, fio (= ${dep:fio}), qemu (= ${dep:qemu}), nodejs (>= 10), node-sprintf-js, node-ws (>= 7), libjerasure2, lp-solve
|
||||||
Description: Vitastor, a fast software-defined clustered block storage
|
Description: Vitastor, a fast software-defined clustered block storage
|
||||||
Vitastor is a small, simple and fast clustered block storage (storage for VM drives),
|
Vitastor is a small, simple and fast clustered block storage (storage for VM drives),
|
||||||
architecturally similar to Ceph which means strong consistency, primary-replication,
|
architecturally similar to Ceph which means strong consistency, primary-replication,
|
||||||
symmetric clustering and automatic data distribution over any number of drives of any
|
symmetric clustering and automatic data distribution over any number of drives of any
|
||||||
size with configurable redundancy (replication or erasure codes/XOR).
|
size with configurable redundancy (replication or erasure codes/XOR).
|
||||||
|
|
||||||
Package: vitastor-osd
|
|
||||||
Architecture: amd64
|
|
||||||
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.
|
|
||||||
|
|
||||||
Package: vitastor-mon
|
|
||||||
Architecture: amd64
|
|
||||||
Depends: ${misc:Depends}, nodejs (>= 10), node-sprintf-js, node-ws (>= 7), lp-solve
|
|
||||||
Description: Vitastor, a fast software-defined clustered block storage - monitor
|
|
||||||
Vitastor monitor, i.e. server program responsible for watching cluster state and
|
|
||||||
scheduling cluster-level operations.
|
|
||||||
|
|
||||||
Package: vitastor-client
|
|
||||||
Architecture: amd64
|
|
||||||
Depends: ${shlibs:Depends}, ${misc:Depends}
|
|
||||||
Description: Vitastor, a fast software-defined clustered block storage - client
|
|
||||||
Vitastor client library and command-line interface.
|
|
||||||
|
|
||||||
Package: vitastor-client-dev
|
|
||||||
Section: devel
|
|
||||||
Architecture: amd64
|
|
||||||
Depends: ${misc:Depends}, vitastor-client (= ${binary:Version})
|
|
||||||
Description: Vitastor, a fast software-defined clustered block storage - development files
|
|
||||||
Vitastor library headers for development.
|
|
||||||
|
|
||||||
Package: vitastor-fio
|
|
||||||
Architecture: amd64
|
|
||||||
Depends: ${shlibs:Depends}, ${misc:Depends}, vitastor-client (= ${binary:Version}), fio (= ${dep:fio})
|
|
||||||
Description: Vitastor, a fast software-defined clustered block storage - fio drivers
|
|
||||||
Vitastor fio drivers for benchmarking.
|
|
||||||
|
|
||||||
Package: pve-storage-vitastor
|
|
||||||
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.
|
|
||||||
|
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
dep:fio=3.16-1
|
|
||||||
|
|
@ -1,4 +1,3 @@
|
||||||
VNPL-1.1.txt usr/share/doc/vitastor
|
VNPL-1.1.txt usr/share/doc/vitastor
|
||||||
GPL-2.0.txt usr/share/doc/vitastor
|
GPL-2.0.txt usr/share/doc/vitastor
|
||||||
README.md usr/share/doc/vitastor
|
mon usr/lib/vitastor
|
||||||
README-ru.md usr/share/doc/vitastor
|
|
||||||
|
|
|
||||||
|
|
@ -1,40 +0,0 @@
|
||||||
# Build patched libvirt for Debian Buster or Bullseye/Sid inside a container
|
|
||||||
# cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/libvirt.Dockerfile .
|
|
||||||
|
|
||||||
ARG REL=
|
|
||||||
FROM debian:$REL
|
|
||||||
ARG REL=
|
|
||||||
|
|
||||||
WORKDIR /root
|
|
||||||
|
|
||||||
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; \
|
|
||||||
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 devscripts
|
|
||||||
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 /root
|
|
||||||
RUN set -e; \
|
|
||||||
mkdir -p /root/packages/libvirt-$REL; \
|
|
||||||
rm -rf /root/packages/libvirt-$REL/*; \
|
|
||||||
cd /root/packages/libvirt-$REL; \
|
|
||||||
dpkg-source -x /root/libvirt*.dsc; \
|
|
||||||
D=$(ls -d libvirt-*/); \
|
|
||||||
V=$(ls -d libvirt-*/ | perl -pe 's/libvirt-(\d+\.\d+).*/$1/'); \
|
|
||||||
cp /root/libvirt-$V-vitastor.diff $D/debian/patches; \
|
|
||||||
echo libvirt-$V-vitastor.diff >> $D/debian/patches/series; \
|
|
||||||
cd $D; \
|
|
||||||
V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)(~bpo[\d\+]*)?(\+deb[u\d]+)?\).*$/$1/')+vitastor2; \
|
|
||||||
DEBEMAIL="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v $V 'Add Vitastor support'; \
|
|
||||||
DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
|
|
||||||
rm -rf /root/packages/libvirt-$REL/$D
|
|
||||||
|
|
@ -1,17 +1,15 @@
|
||||||
# Build patched QEMU for Debian Buster or Bullseye/Sid 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 .
|
# cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/patched-qemu.Dockerfile .
|
||||||
|
|
||||||
ARG REL=
|
|
||||||
FROM debian:$REL
|
FROM debian:$REL
|
||||||
ARG REL=
|
|
||||||
|
|
||||||
WORKDIR /root
|
WORKDIR /root
|
||||||
|
|
||||||
RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
|
RUN if [ "$REL" = "buster" ]; then \
|
||||||
echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
|
echo 'deb http://deb.debian.org/debian buster-backports main' >> /etc/apt/sources.list; \
|
||||||
echo >> /etc/apt/preferences; \
|
echo >> /etc/apt/preferences; \
|
||||||
echo 'Package: *' >> /etc/apt/preferences; \
|
echo 'Package: *' >> /etc/apt/preferences; \
|
||||||
echo "Pin: release a=$REL-backports" >> /etc/apt/preferences; \
|
echo 'Pin: release a=buster-backports' >> /etc/apt/preferences; \
|
||||||
echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
|
echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
|
||||||
fi; \
|
fi; \
|
||||||
grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
|
grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
|
||||||
|
|
@ -21,41 +19,26 @@ RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
|
||||||
RUN apt-get update
|
RUN apt-get update
|
||||||
RUN apt-get -y install qemu fio liburing1 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
|
RUN apt-get -y build-dep qemu
|
||||||
# To build a custom version
|
RUN apt-get -y build-dep fio
|
||||||
#RUN cp /root/packages/qemu-orig/* /root
|
|
||||||
RUN apt-get --download-only source qemu
|
RUN apt-get --download-only source qemu
|
||||||
|
RUN apt-get --download-only source fio
|
||||||
|
|
||||||
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/
|
ADD qemu-5.0-vitastor.patch qemu-5.1-vitastor.patch /root/vitastor/
|
||||||
RUN set -e; \
|
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; \
|
|
||||||
mkdir -p /root/packages/qemu-$REL; \
|
mkdir -p /root/packages/qemu-$REL; \
|
||||||
rm -rf /root/packages/qemu-$REL/*; \
|
rm -rf /root/packages/qemu-$REL/*; \
|
||||||
cd /root/packages/qemu-$REL; \
|
cd /root/packages/qemu-$REL; \
|
||||||
dpkg-source -x /root/qemu*.dsc; \
|
dpkg-source -x /root/qemu*.dsc; \
|
||||||
if ls -d /root/packages/qemu-$REL/qemu-5.0*; then \
|
if [ -d /root/packages/qemu-$REL/qemu-5.0 ]; then \
|
||||||
D=$(ls -d /root/packages/qemu-$REL/qemu-5.0*); \
|
cp /root/vitastor/qemu-5.0-vitastor.patch /root/packages/qemu-$REL/qemu-5.0/debian/patches; \
|
||||||
cp /root/vitastor/patches/qemu-5.0-vitastor.patch $D/debian/patches; \
|
echo qemu-5.0-vitastor.patch >> /root/packages/qemu-$REL/qemu-5.0/debian/patches/series; \
|
||||||
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 \
|
else \
|
||||||
cp /root/vitastor/patches/qemu-5.1-vitastor.patch /root/packages/qemu-$REL/qemu-*/debian/patches; \
|
cp /root/vitastor/qemu-5.1-vitastor.patch /root/packages/qemu-$REL/qemu-*/debian/patches; \
|
||||||
P=`ls -d /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; \
|
echo qemu-5.1-vitastor.patch >> $P/series; \
|
||||||
fi; \
|
fi; \
|
||||||
cd /root/packages/qemu-$REL/qemu-*/; \
|
cd /root/packages/qemu-$REL/qemu-*/; \
|
||||||
quilt push -a; \
|
|
||||||
quilt add block/vitastor.c; \
|
|
||||||
cp /root/vitastor/patches/qemu_driver.c block/vitastor.c; \
|
|
||||||
quilt refresh; \
|
|
||||||
V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)(~bpo[\d\+]*)?\).*$/$1/')+vitastor1; \
|
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'; \
|
DEBFULLNAME="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v $V 'Plug Vitastor block driver'; \
|
||||||
DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
|
DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
|
||||||
rm -rf /root/packages/qemu-$REL/qemu-*/
|
rm -rf /root/packages/qemu-$REL/qemu-*/
|
||||||
|
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
patches/PVE_VitastorPlugin.pm usr/share/perl5/PVE/Storage/Custom/VitastorPlugin.pm
|
|
||||||
|
|
@ -1,19 +0,0 @@
|
||||||
/* Removed in Linux 5.14 */
|
|
||||||
|
|
||||||
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
|
|
||||||
#ifndef __LINUX_RAW_H
|
|
||||||
#define __LINUX_RAW_H
|
|
||||||
|
|
||||||
#include <linux/types.h>
|
|
||||||
|
|
||||||
#define RAW_SETBIND _IO( 0xac, 0 )
|
|
||||||
#define RAW_GETBIND _IO( 0xac, 1 )
|
|
||||||
|
|
||||||
struct raw_config_request
|
|
||||||
{
|
|
||||||
int raw_minor;
|
|
||||||
__u64 block_major;
|
|
||||||
__u64 block_minor;
|
|
||||||
};
|
|
||||||
|
|
||||||
#endif /* __LINUX_RAW_H */
|
|
||||||
|
|
@ -5,6 +5,5 @@ export DH_VERBOSE = 1
|
||||||
dh $@
|
dh $@
|
||||||
|
|
||||||
override_dh_installdeb:
|
override_dh_installdeb:
|
||||||
cat debian/fio_version >> debian/vitastor-fio.substvars
|
cat debian/substvars >> debian/vitastor.substvars
|
||||||
[ -f debian/qemu_version ] && (cat debian/qemu_version >> debian/vitastor-qemu.substvars) || true
|
|
||||||
dh_installdeb
|
dh_installdeb
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,2 @@
|
||||||
|
dep:fio=3.16-1
|
||||||
|
dep:qemu=1:5.1+dfsg-4+vitastor1
|
||||||
|
|
@ -1,2 +0,0 @@
|
||||||
usr/include
|
|
||||||
usr/lib/*/pkgconfig
|
|
||||||
|
|
@ -1,7 +0,0 @@
|
||||||
usr/bin/vita
|
|
||||||
usr/bin/vitastor-cli
|
|
||||||
usr/bin/vitastor-rm
|
|
||||||
usr/bin/vitastor-nbd
|
|
||||||
usr/bin/vitastor-nfs
|
|
||||||
usr/lib/*/libvitastor*.so*
|
|
||||||
mon/make-osd.sh /usr/lib/vitastor
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
usr/lib/*/libfio*.so*
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
mon usr/lib/vitastor
|
|
||||||
|
|
@ -1,2 +0,0 @@
|
||||||
usr/bin/vitastor-osd
|
|
||||||
usr/bin/vitastor-dump-journal
|
|
||||||
|
|
@ -1,17 +1,15 @@
|
||||||
# Build Vitastor packages for Debian Buster or Bullseye/Sid inside a container
|
# 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 .
|
# cd ..; podman build --build-arg REL=bullseye -v `pwd`/packages:/root/packages -f debian/vitastor.Dockerfile .
|
||||||
|
|
||||||
ARG REL=
|
|
||||||
FROM debian:$REL
|
FROM debian:$REL
|
||||||
ARG REL=
|
|
||||||
|
|
||||||
WORKDIR /root
|
WORKDIR /root
|
||||||
|
|
||||||
RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
|
RUN if [ "$REL" = "buster" ]; then \
|
||||||
echo "deb http://deb.debian.org/debian $REL-backports main" >> /etc/apt/sources.list; \
|
echo 'deb http://deb.debian.org/debian buster-backports main' >> /etc/apt/sources.list; \
|
||||||
echo >> /etc/apt/preferences; \
|
echo >> /etc/apt/preferences; \
|
||||||
echo 'Package: *' >> /etc/apt/preferences; \
|
echo 'Package: *' >> /etc/apt/preferences; \
|
||||||
echo "Pin: release a=$REL-backports" >> /etc/apt/preferences; \
|
echo 'Pin: release a=buster-backports' >> /etc/apt/preferences; \
|
||||||
echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
|
echo 'Pin-Priority: 500' >> /etc/apt/preferences; \
|
||||||
fi; \
|
fi; \
|
||||||
grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
|
grep '^deb ' /etc/apt/sources.list | perl -pe 's/^deb/deb-src/' >> /etc/apt/sources.list; \
|
||||||
|
|
@ -19,8 +17,10 @@ RUN if [ "$REL" = "buster" -o "$REL" = "bullseye" ]; then \
|
||||||
echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
|
echo 'APT::Install-Suggests false;' >> /etc/apt/apt.conf
|
||||||
|
|
||||||
RUN apt-get update
|
RUN apt-get update
|
||||||
RUN apt-get -y install fio liburing1 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
|
||||||
RUN apt-get -y build-dep fio
|
RUN apt-get -y build-dep fio
|
||||||
|
RUN apt-get --download-only source qemu
|
||||||
RUN apt-get --download-only source fio
|
RUN apt-get --download-only source fio
|
||||||
RUN apt-get update && apt-get -y install libjerasure-dev cmake libibverbs-dev
|
RUN apt-get update && apt-get -y install libjerasure-dev cmake libibverbs-dev
|
||||||
|
|
||||||
|
|
@ -30,25 +30,37 @@ RUN set -e -x; \
|
||||||
cd /root/fio-build/; \
|
cd /root/fio-build/; \
|
||||||
rm -rf /root/fio-build/*; \
|
rm -rf /root/fio-build/*; \
|
||||||
dpkg-source -x /root/fio*.dsc; \
|
dpkg-source -x /root/fio*.dsc; \
|
||||||
|
cd /root/packages/qemu-$REL/; \
|
||||||
|
rm -rf qemu*/; \
|
||||||
|
dpkg-source -x qemu*.dsc; \
|
||||||
|
cd /root/packages/qemu-$REL/qemu*/; \
|
||||||
|
debian/rules b/configure-stamp; \
|
||||||
|
cd b/qemu; \
|
||||||
|
make -j8 qapi/qapi-builtin-types.h; \
|
||||||
mkdir -p /root/packages/vitastor-$REL; \
|
mkdir -p /root/packages/vitastor-$REL; \
|
||||||
rm -rf /root/packages/vitastor-$REL/*; \
|
rm -rf /root/packages/vitastor-$REL/*; \
|
||||||
cd /root/packages/vitastor-$REL; \
|
cd /root/packages/vitastor-$REL; \
|
||||||
cp -r /root/vitastor vitastor-0.6.17; \
|
cp -r /root/vitastor vitastor-0.6.4; \
|
||||||
cd vitastor-0.6.17; \
|
ln -s /root/packages/qemu-$REL/qemu-*/ vitastor-0.6.4/qemu; \
|
||||||
ln -s /root/fio-build/fio-*/ ./fio; \
|
ln -s /root/fio-build/fio-*/ vitastor-0.6.4/fio; \
|
||||||
|
cd vitastor-0.6.4; \
|
||||||
FIO=$(head -n1 fio/debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
|
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; \
|
QEMU=$(head -n1 qemu/debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
|
||||||
|
sh copy-qemu-includes.sh; \
|
||||||
sh copy-fio-includes.sh; \
|
sh copy-fio-includes.sh; \
|
||||||
rm fio; \
|
rm qemu fio; \
|
||||||
mkdir -p a b debian/patches; \
|
mkdir -p a b debian/patches; \
|
||||||
|
mv qemu-copy b/qemu; \
|
||||||
mv fio-copy b/fio; \
|
mv fio-copy b/fio; \
|
||||||
diff -NaurpbB a b > debian/patches/fio-headers.patch || true; \
|
diff -NaurpbB a b > debian/patches/qemu-fio-headers.patch || true; \
|
||||||
echo fio-headers.patch >> debian/patches/series; \
|
echo qemu-fio-headers.patch >> debian/patches/series; \
|
||||||
rm -rf a b; \
|
rm -rf a b; \
|
||||||
echo "dep:fio=$FIO" > debian/fio_version; \
|
rm -rf /root/packages/qemu-$REL/qemu*/; \
|
||||||
|
echo "dep:fio=$FIO" > debian/substvars; \
|
||||||
|
echo "dep:qemu=$QEMU" >> debian/substvars; \
|
||||||
cd /root/packages/vitastor-$REL; \
|
cd /root/packages/vitastor-$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; \
|
tar --sort=name --mtime='2020-01-01' --owner=0 --group=0 --exclude=debian -cJf vitastor_0.6.4.orig.tar.xz vitastor-0.6.4; \
|
||||||
cd vitastor-0.6.17; \
|
cd vitastor-0.6.4; \
|
||||||
V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
|
V=$(head -n1 debian/changelog | perl -pe 's/^.*\((.*?)\).*$/$1/'); \
|
||||||
DEBFULLNAME="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v "$V""$REL" "Rebuild for $REL"; \
|
DEBFULLNAME="Vitaliy Filippov <vitalif@yourcmc.ru>" dch -D $REL -v "$V""$REL" "Rebuild for $REL"; \
|
||||||
DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
|
DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage --jobs=auto -sa; \
|
||||||
|
|
|
||||||
|
|
@ -1,9 +0,0 @@
|
||||||
# Build Docker image with Vitastor packages
|
|
||||||
|
|
||||||
FROM debian:bullseye
|
|
||||||
|
|
||||||
ADD vitastor.list /etc/apt/sources.list.d
|
|
||||||
ADD vitastor.gpg /etc/apt/trusted.gpg.d
|
|
||||||
ADD vitastor.pref /etc/apt/preferences.d
|
|
||||||
ADD apt.conf /etc/apt/
|
|
||||||
RUN apt-get update && apt-get -y install vitastor qemu-system-x86 qemu-system-common && apt-get clean
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
APT::Install-Recommends false;
|
|
||||||
Binary file not shown.
|
|
@ -1 +0,0 @@
|
||||||
deb http://vitastor.io/debian bullseye main
|
|
||||||
|
|
@ -1,3 +0,0 @@
|
||||||
Package: *
|
|
||||||
Pin: origin "vitastor.io"
|
|
||||||
Pin-Priority: 1000
|
|
||||||
|
|
@ -1,37 +0,0 @@
|
||||||
[Documentation](../README.md#documentation) → Configuration Reference
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](config.ru.md)
|
|
||||||
|
|
||||||
# Configuration Reference
|
|
||||||
|
|
||||||
Vitastor configuration consists of:
|
|
||||||
- [Configuration parameters (key-value)](#parameter-reference)
|
|
||||||
- [Pool configuration](config/pool.en.md)
|
|
||||||
- [OSD placement tree configuration](config/pool.en.md#placement-tree)
|
|
||||||
- [Separate OSD settings](config/pool.en.md#osd-settings)
|
|
||||||
- [Inode configuration](config/inode.en.md) i.e. image metadata like name, size and parent reference
|
|
||||||
|
|
||||||
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, 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)
|
|
||||||
- [Global Disk Layout](config/layout-cluster.en.md)
|
|
||||||
- [OSD Disk Layout](config/layout-osd.en.md)
|
|
||||||
- [OSD Runtime Parameters](config/osd.en.md)
|
|
||||||
- [Monitor](config/monitor.en.md)
|
|
||||||
|
|
@ -1,39 +0,0 @@
|
||||||
[Документация](../README-ru.md#документация) → Конфигурация Vitastor
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](config.en.md)
|
|
||||||
|
|
||||||
# Конфигурация Vitastor
|
|
||||||
|
|
||||||
Конфигурация Vitastor состоит из:
|
|
||||||
- [Параметров (ключ-значение)](#список-параметров)
|
|
||||||
- [Настроек пулов](config/pool.ru.md)
|
|
||||||
- [Настроек дерева OSD](config/pool.ru.md#дерево-размещения)
|
|
||||||
- [Настроек отдельных OSD](config/pool.ru.md#настройки-osd)
|
|
||||||
- [Настроек инодов](config/inode.ru.md), т.е. метаданных образов, таких, как имя, размер и ссылки на
|
|
||||||
родительский образ
|
|
||||||
|
|
||||||
Параметры конфигурации могут задаваться в 3 местах:
|
|
||||||
- Файле конфигурации (`/etc/vitastor/vitastor.conf` или по другому пути)
|
|
||||||
- Ключе в etcd `/vitastor/config/global`. Большая часть параметров может
|
|
||||||
задаваться там, кроме, естественно, самих параметров соединения с etcd,
|
|
||||||
которые должны задаваться в файле конфигурации
|
|
||||||
- В командной строке компонентов Vitastor: OSD, монитора, опциях fio и QEMU,
|
|
||||||
настроек OpenStack, Proxmox и т.п. Последние, как правило, не включают полный
|
|
||||||
набор параметров напрямую, но разрешают определить путь к файлу конфигурации
|
|
||||||
и задать любые параметры в нём.
|
|
||||||
|
|
||||||
В будущем также могут быть добавлены другие способы конфигурации:
|
|
||||||
- Суперблок OSD, в котором будут храниться параметры OSD, связанные с дисковым
|
|
||||||
форматом и с этим конкретным OSD.
|
|
||||||
- OSD-специфичные ключи в etcd типа `/vitastor/config/osd/<номер>`.
|
|
||||||
|
|
||||||
## Список параметров
|
|
||||||
|
|
||||||
- [Общие](config/common.ru.md)
|
|
||||||
- [Сеть](config/network.ru.md)
|
|
||||||
- [Глобальные дисковые параметры](config/layout-cluster.ru.md)
|
|
||||||
- [Дисковые параметры OSD](config/layout-osd.ru.md)
|
|
||||||
- [Прочие параметры OSD](config/osd.ru.md)
|
|
||||||
- [Параметры мониторов](config/monitor.ru.md)
|
|
||||||
|
|
@ -1,46 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Common Parameters
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](common.ru.md)
|
|
||||||
|
|
||||||
# Common Parameters
|
|
||||||
|
|
||||||
These are the most common parameters which apply to all components of Vitastor.
|
|
||||||
|
|
||||||
- [config_path](#config_path)
|
|
||||||
- [etcd_address](#etcd_address)
|
|
||||||
- [etcd_prefix](#etcd_prefix)
|
|
||||||
- [log_level](#log_level)
|
|
||||||
|
|
||||||
## config_path
|
|
||||||
|
|
||||||
- Type: string
|
|
||||||
- Default: /etc/vitastor/vitastor.conf
|
|
||||||
|
|
||||||
Path to the JSON configuration file. Configuration file is optional,
|
|
||||||
a non-existing configuration file does not prevent Vitastor from
|
|
||||||
running if required parameters are specified.
|
|
||||||
|
|
||||||
## etcd_address
|
|
||||||
|
|
||||||
- Type: string or array of strings
|
|
||||||
|
|
||||||
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_prefix
|
|
||||||
|
|
||||||
- Type: string
|
|
||||||
- Default: /vitastor
|
|
||||||
|
|
||||||
Prefix for all keys in etcd used by Vitastor. You can change prefix and, for
|
|
||||||
example, use a single etcd cluster for multiple Vitastor clusters.
|
|
||||||
|
|
||||||
## log_level
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 0
|
|
||||||
|
|
||||||
Log level. Raise if you want more verbose output.
|
|
||||||
|
|
@ -1,45 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Общие параметры
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](common.en.md)
|
|
||||||
|
|
||||||
# Общие параметры
|
|
||||||
|
|
||||||
Это наиболее общие параметры, используемые всеми компонентами Vitastor.
|
|
||||||
|
|
||||||
- [config_path](#config_path)
|
|
||||||
- [etcd_address](#etcd_address)
|
|
||||||
- [etcd_prefix](#etcd_prefix)
|
|
||||||
- [log_level](#log_level)
|
|
||||||
|
|
||||||
## config_path
|
|
||||||
|
|
||||||
- Тип: строка
|
|
||||||
- Значение по умолчанию: /etc/vitastor/vitastor.conf
|
|
||||||
|
|
||||||
Путь к файлу конфигурации в формате JSON. Файл конфигурации необязателен,
|
|
||||||
без него Vitastor тоже будет работать, если переданы необходимые параметры.
|
|
||||||
|
|
||||||
## etcd_address
|
|
||||||
|
|
||||||
- Тип: строка или массив строк
|
|
||||||
|
|
||||||
Адрес(а) подключения к etcd. Несколько адресов могут разделяться запятой
|
|
||||||
или указываться в виде JSON-массива `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
|
|
||||||
|
|
||||||
## etcd_prefix
|
|
||||||
|
|
||||||
- Тип: строка
|
|
||||||
- Значение по умолчанию: /vitastor
|
|
||||||
|
|
||||||
Префикс для ключей etcd, которые использует Vitastor. Вы можете задать другой
|
|
||||||
префикс, например, чтобы запустить несколько кластеров Vitastor с одним
|
|
||||||
кластером etcd.
|
|
||||||
|
|
||||||
## log_level
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 0
|
|
||||||
|
|
||||||
Уровень логгирования. Повысьте, если хотите более подробный вывод.
|
|
||||||
|
|
@ -1,32 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Image metadata in etcd
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](inode.ru.md)
|
|
||||||
|
|
||||||
# Image metadata in etcd
|
|
||||||
|
|
||||||
Image list is stored in etcd in `/vitastor/config/inode/<pool>/<inode>` keys.
|
|
||||||
|
|
||||||
You can even create images manually:
|
|
||||||
|
|
||||||
```
|
|
||||||
etcdctl --endpoints=<etcd> put /vitastor/config/inode/<pool>/<inode> '{"name":"<name>","size":<size>[,"parent_id":<parent_inode_number>][,"readonly":true]}'
|
|
||||||
```
|
|
||||||
|
|
||||||
For example:
|
|
||||||
|
|
||||||
```
|
|
||||||
etcdctl --endpoints=http://10.115.0.10:2379/v3 put /vitastor/config/inode/1/1 '{"name":"testimg","size":2147483648}'
|
|
||||||
```
|
|
||||||
|
|
||||||
If you specify parent_id the image becomes a CoW clone. I.e. all writes go to the new inode and reads first check it
|
|
||||||
and then upper layers. You can then make parent readonly by updating its entry with `"readonly":true` for safety and
|
|
||||||
basically treat it as a snapshot.
|
|
||||||
|
|
||||||
So to create a snapshot you basically rename the previous upper layer (for example from testimg to testimg@0), make it readonly
|
|
||||||
and create a new top layer with the original name (testimg) and the previous one as a parent.
|
|
||||||
|
|
||||||
vitastor-cli, K8s, OpenStack and other drivers also store the reverse mapping in `/vitastor/index/image/<name>` keys
|
|
||||||
in JSON format: `{"id":<inode>,"pool_id":<pool>}` and ID counters in `/vitastor/index/maxid/<pool>` as numbers
|
|
||||||
to simplify ID generation.
|
|
||||||
|
|
@ -1,34 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Метаданные образов в etcd
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](inode.en.md)
|
|
||||||
|
|
||||||
# Метаданные образов в etcd
|
|
||||||
|
|
||||||
Список образов хранится в etcd в ключах `/vitastor/config/inode/<pool>/<inode>`.
|
|
||||||
|
|
||||||
Вы можете даже создавать образы вручную:
|
|
||||||
|
|
||||||
```
|
|
||||||
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), ссылающийся на только что переименованный
|
|
||||||
в качестве родительского.
|
|
||||||
|
|
||||||
vitastor-cli и драйвера K8s, OpenStack и т.п. также хранят обратный маппинг в ключах `/vitastor/index/image/<name>`
|
|
||||||
в JSON-формате: `{"id":<inode>,"pool_id":<pool>}` и счётчики ID `/vitastor/index/maxid/<pool>` в виде просто чисел
|
|
||||||
для упрощения генерации ID новых образов.
|
|
||||||
|
|
@ -1,124 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Cluster-Wide Disk Layout Parameters
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](layout-cluster.ru.md)
|
|
||||||
|
|
||||||
# Cluster-Wide Disk Layout Parameters
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
- [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 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 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.
|
|
||||||
|
|
||||||
## bitmap_granularity
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 4096
|
|
||||||
|
|
||||||
Required virtual disk write alignment ("sector size"). Must be a multiple
|
|
||||||
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.
|
|
||||||
|
|
||||||
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: false
|
|
||||||
|
|
||||||
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, 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
|
|
||||||
fast with and without fsync because their cache is protected from sudden
|
|
||||||
power loss by a built-in supercapacitor-based "UPS".
|
|
||||||
|
|
||||||
Some software-defined storage systems always fsync each write and thus are
|
|
||||||
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" 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
|
|
||||||
supercapacitors even with Vitastor, especially given that they cost only
|
|
||||||
a bit more than desktop models.
|
|
||||||
|
|
||||||
There is also a common SATA SSD (and HDD too!) firmware bug (or feature)
|
|
||||||
that makes server SSDs which have supercapacitors slow with fsync. To check
|
|
||||||
if your SSDs are affected, compare benchmark results from `fio -name=test
|
|
||||||
-ioengine=libaio -direct=1 -bs=4k -rw=randwrite -iodepth=1` with and without
|
|
||||||
`-fsync=1`. Results should be the same. If fsync=1 result is worse you can
|
|
||||||
try to work around this bug by "disabling" drive write-back cache by running
|
|
||||||
`hdparm -W 0 /dev/sdXX` or `echo write through > /sys/block/sdXX/device/scsi_disk/*/cache_type`
|
|
||||||
(IMPORTANT: don't mistake it with `/sys/block/sdXX/queue/write_cache` - it's
|
|
||||||
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).
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
@ -1,134 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Дисковые параметры уровня кластера
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](layout-cluster.en.md)
|
|
||||||
|
|
||||||
# Дисковые параметры уровня кластера
|
|
||||||
|
|
||||||
Данные параметры используются клиентами и OSD, задаются в момент инициализации
|
|
||||||
диска OSD и не могут быть изменены после этого без потери данных.
|
|
||||||
|
|
||||||
- [block_size](#block_size)
|
|
||||||
- [bitmap_granularity](#bitmap_granularity)
|
|
||||||
- [immediate_commit](#immediate_commit)
|
|
||||||
- [client_dirty_limit](#client_dirty_limit)
|
|
||||||
|
|
||||||
## block_size
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 131072
|
|
||||||
|
|
||||||
Размер объектов (блоков данных), на которые делятся физические и виртуальные
|
|
||||||
диски в Vitastor. Одна из ключевых на данный момент настроек, влияет на
|
|
||||||
потребление памяти, объём избыточной записи (write amplification) и
|
|
||||||
эффективность распределения нагрузки по OSD.
|
|
||||||
|
|
||||||
Рекомендуемые по умолчанию размеры блока - 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 КБ блоке.
|
|
||||||
|
|
||||||
## bitmap_granularity
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 4096
|
|
||||||
|
|
||||||
Требуемое выравнивание записи на виртуальные диски (размер их "сектора").
|
|
||||||
Должен быть кратен disk_alignment. Называется гранулярностью битовой карты
|
|
||||||
потому, что Vitastor хранит битовую карту для каждого объекта, содержащую
|
|
||||||
по 2 бита на каждые (bitmap_granularity) байт.
|
|
||||||
|
|
||||||
Данный параметр нельзя менять после инициализации OSD без потери данных.
|
|
||||||
Также он фиксирован для всего кластера Vitastor, т.е. разные значения
|
|
||||||
не могут сосуществовать в одном кластере.
|
|
||||||
|
|
||||||
Клиенты ДОЛЖНЫ знать правильное значение этого параметра, так что если вы
|
|
||||||
его меняете, обязательно прописывайте изменённое значение в etcd в ключ
|
|
||||||
/vitastor/config/global.
|
|
||||||
|
|
||||||
## immediate_commit
|
|
||||||
|
|
||||||
- Тип: строка
|
|
||||||
- Значение по умолчанию: false
|
|
||||||
|
|
||||||
Ещё один важный для производительности параметр.
|
|
||||||
|
|
||||||
Модели SSD для настольных компьютеров очень быстрые (100000+ операций в
|
|
||||||
секунду) при простой случайной записи без сбросов кэша. Однако они очень
|
|
||||||
медленные (всего порядка 1000 iops), если вы пытаетесь сбрасывать кэш после
|
|
||||||
каждой записи, то есть, если вы пытаетесь гарантировать, что каждое
|
|
||||||
изменение физически записывается в энергонезависимую память.
|
|
||||||
|
|
||||||
С другой стороны, серверные SSD с конденсаторами - функцией, называемой
|
|
||||||
"Advanced/Enhanced Power Loss Protection" или просто "Supercapacitor-based
|
|
||||||
Power Loss Protection" - одинаково быстрые и со сбросом кэша, и без
|
|
||||||
него, потому что их кэш защищён от потери питания встроенным "источником
|
|
||||||
бесперебойного питания" на основе суперконденсаторов и на самом деле они
|
|
||||||
его никогда не сбрасывают.
|
|
||||||
|
|
||||||
Некоторые программные СХД всегда сбрасывают кэши дисков при каждой записи
|
|
||||||
и поэтому работают очень медленно с настольными SSD. Vitastor, однако, может
|
|
||||||
откладывать fsync до явного его вызова со стороны клиента и таким образом
|
|
||||||
эффективно утилизировать настольные SSD.
|
|
||||||
|
|
||||||
Данный параметр влияет как раз на это. Когда он установлен в значение "all",
|
|
||||||
весь кластер Vitastor мгновенно фиксирует каждое изменение на физические
|
|
||||||
носители и клиенты могут просто игнорировать запросы fsync, т.к. они точно
|
|
||||||
знают, что fsync-и не нужны. Это уменьшает число необходимых обращений к OSD
|
|
||||||
по сети и улучшает производительность. Поэтому даже с Vitastor лучше всегда
|
|
||||||
использовать только серверные модели SSD с суперконденсаторами, особенно
|
|
||||||
учитывая то, что стоят они ненамного дороже настольных.
|
|
||||||
|
|
||||||
Также в прошивках SATA SSD (и даже HDD!) очень часто встречается либо баг,
|
|
||||||
либо просто особенность логики, из-за которой серверные SSD, имеющие
|
|
||||||
конденсаторы и защиту от потери питания, всё равно медленно работают с
|
|
||||||
fsync. Чтобы понять, подвержены ли этой проблеме ваши SSD, сравните
|
|
||||||
результаты тестов `fio -name=test -ioengine=libaio -direct=1 -bs=4k
|
|
||||||
-rw=randwrite -iodepth=1` без и с опцией `-fsync=1`. Результаты должны
|
|
||||||
быть одинаковые. Если результат с `fsync=1` хуже, вы можете попробовать
|
|
||||||
обойти проблему, "отключив" кэш записи диска командой `hdparm -W 0 /dev/sdXX`
|
|
||||||
либо `echo write through > /sys/block/sdXX/device/scsi_disk/*/cache_type`
|
|
||||||
(ВАЖНО: не перепутайте с `/sys/block/sdXX/queue/write_cache` - этот параметр
|
|
||||||
менять руками небезопасно). Такая же проблема может встречаться и в новых
|
|
||||||
HDD-дисках с внутренним SSD или "медиа" кэшем - например, она встречается во
|
|
||||||
многих дисках Seagate EXOS (у них есть внутренний SSD-кэш, хотя это и не
|
|
||||||
указано в спецификациях).
|
|
||||||
|
|
||||||
Данный параметр нужно указывать и в 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.
|
|
||||||
|
|
@ -1,176 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → OSD Disk Layout Parameters
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](layout-osd.ru.md)
|
|
||||||
|
|
||||||
# OSD Disk Layout Parameters
|
|
||||||
|
|
||||||
These parameters apply to OSDs, are fixed at the moment of OSD drive
|
|
||||||
initialization and can't be changed after it without losing data.
|
|
||||||
|
|
||||||
- [data_device](#data_device)
|
|
||||||
- [meta_device](#meta_device)
|
|
||||||
- [journal_device](#journal_device)
|
|
||||||
- [journal_offset](#journal_offset)
|
|
||||||
- [journal_size](#journal_size)
|
|
||||||
- [meta_offset](#meta_offset)
|
|
||||||
- [data_offset](#data_offset)
|
|
||||||
- [data_size](#data_size)
|
|
||||||
- [meta_block_size](#meta_block_size)
|
|
||||||
- [journal_block_size](#journal_block_size)
|
|
||||||
- [disable_data_fsync](#disable_data_fsync)
|
|
||||||
- [disable_meta_fsync](#disable_meta_fsync)
|
|
||||||
- [disable_journal_fsync](#disable_journal_fsync)
|
|
||||||
- [disable_device_lock](#disable_device_lock)
|
|
||||||
- [disk_alignment](#disk_alignment)
|
|
||||||
|
|
||||||
## data_device
|
|
||||||
|
|
||||||
- Type: string
|
|
||||||
|
|
||||||
Path to the block device to use for data. It's highly recommendded to use
|
|
||||||
stable paths for all device names: `/dev/disk/by-partuuid/xxx...` instead
|
|
||||||
of just `/dev/sda` or `/dev/nvme0n1` to not mess up after server restart.
|
|
||||||
Files can also be used instead of block devices, but this is implemented
|
|
||||||
only for testing purposes and not for production.
|
|
||||||
|
|
||||||
## meta_device
|
|
||||||
|
|
||||||
- Type: string
|
|
||||||
|
|
||||||
Path to the block device to use for the metadata. Metadata must be on a fast
|
|
||||||
SSD or performance will suffer. If this option is skipped, `data_device` is
|
|
||||||
used for the metadata.
|
|
||||||
|
|
||||||
## journal_device
|
|
||||||
|
|
||||||
- Type: string
|
|
||||||
|
|
||||||
Path to the block device to use for the journal. Journal must be on a fast
|
|
||||||
SSD or performance will suffer. If this option is skipped, `meta_device` is
|
|
||||||
used for the journal, and if it's also empty, journal is put on
|
|
||||||
`data_device`. It's almost always fine to put metadata and journal on the
|
|
||||||
same device, in this case you only need to set `meta_device`.
|
|
||||||
|
|
||||||
## journal_offset
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 0
|
|
||||||
|
|
||||||
Offset on the device in bytes where the journal is stored.
|
|
||||||
|
|
||||||
## journal_size
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
|
|
||||||
Journal size in bytes. By default, all available space between journal_offset
|
|
||||||
and data_offset, meta_offset or the end of the journal device is used.
|
|
||||||
Large journals aren't needed in SSD-only setups, 32 MB is always enough.
|
|
||||||
In SSD+HDD setups it is beneficial to use larger journals (for example, 1 GB)
|
|
||||||
and enable [throttle_small_writes](osd.en.md#throttle_small_writes).
|
|
||||||
|
|
||||||
## meta_offset
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 0
|
|
||||||
|
|
||||||
Offset on the device in bytes where the metadata area is stored.
|
|
||||||
Again, set it to something if you colocate metadata with journal or data.
|
|
||||||
|
|
||||||
## data_offset
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 0
|
|
||||||
|
|
||||||
Offset on the device in bytes where the data area is stored.
|
|
||||||
Again, set it to something if you colocate data with journal or metadata.
|
|
||||||
|
|
||||||
## data_size
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
|
|
||||||
Data area size in bytes. By default, the whole data device up to the end
|
|
||||||
will be used for the data area, but you can restrict it if you want to use
|
|
||||||
a smaller part. Note that there is no option to set metadata area size -
|
|
||||||
it's derived from the data area size.
|
|
||||||
|
|
||||||
## meta_block_size
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 4096
|
|
||||||
|
|
||||||
Physical block size of the metadata device. 4096 for most current
|
|
||||||
HDDs and SSDs.
|
|
||||||
|
|
||||||
## journal_block_size
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 4096
|
|
||||||
|
|
||||||
Physical block size of the journal device. Must be a multiple of
|
|
||||||
`disk_alignment`. 4096 for most current HDDs and SSDs.
|
|
||||||
|
|
||||||
## disable_data_fsync
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: false
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: false
|
|
||||||
|
|
||||||
Same as disable_data_fsync, but for the metadata device. If the metadata
|
|
||||||
device is not set or if the data device is used for the metadata the option
|
|
||||||
is ignored and disable_data_fsync value is used instead of it.
|
|
||||||
|
|
||||||
## disable_journal_fsync
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: false
|
|
||||||
|
|
||||||
Same as disable_data_fsync, but for the journal device. If the journal
|
|
||||||
device is not set or if the metadata device is used for the journal the
|
|
||||||
option is ignored and disable_meta_fsync value is used instead of it. If
|
|
||||||
the same device is used for data, metadata and journal the option is also
|
|
||||||
ignored and disable_data_fsync value is used instead of it.
|
|
||||||
|
|
||||||
## disable_device_lock
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: false
|
|
||||||
|
|
||||||
Do not lock data, metadata and journal block devices exclusively with
|
|
||||||
flock(). Though it's not recommended, but you can use it you want to run
|
|
||||||
multiple OSD with a single device and different offsets, without using
|
|
||||||
partitions.
|
|
||||||
|
|
||||||
## disk_alignment
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 4096
|
|
||||||
|
|
||||||
Required physical disk write alignment. Most current SSD and HDD drives
|
|
||||||
use 4 KB physical sectors even if they report 512 byte logical sector
|
|
||||||
size, so 4 KB is a good default setting.
|
|
||||||
|
|
||||||
Note, however, that physical sector size also affects WA, because with block
|
|
||||||
devices it's impossible to write anything smaller than a block. So, when
|
|
||||||
Vitastor has to write a single metadata entry that's only about 32 bytes in
|
|
||||||
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 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.
|
|
||||||
|
|
@ -1,185 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Дисковые параметры OSD
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](layout-osd.en.md)
|
|
||||||
|
|
||||||
# Дисковые параметры OSD
|
|
||||||
|
|
||||||
Данные параметры используются только OSD и, также как и общекластерные
|
|
||||||
дисковые параметры, задаются в момент инициализации дисков OSD и не могут быть
|
|
||||||
изменены после этого без потери данных.
|
|
||||||
|
|
||||||
- [data_device](#data_device)
|
|
||||||
- [meta_device](#meta_device)
|
|
||||||
- [journal_device](#journal_device)
|
|
||||||
- [journal_offset](#journal_offset)
|
|
||||||
- [journal_size](#journal_size)
|
|
||||||
- [meta_offset](#meta_offset)
|
|
||||||
- [data_offset](#data_offset)
|
|
||||||
- [data_size](#data_size)
|
|
||||||
- [meta_block_size](#meta_block_size)
|
|
||||||
- [journal_block_size](#journal_block_size)
|
|
||||||
- [disable_data_fsync](#disable_data_fsync)
|
|
||||||
- [disable_meta_fsync](#disable_meta_fsync)
|
|
||||||
- [disable_journal_fsync](#disable_journal_fsync)
|
|
||||||
- [disable_device_lock](#disable_device_lock)
|
|
||||||
- [disk_alignment](#disk_alignment)
|
|
||||||
|
|
||||||
## data_device
|
|
||||||
|
|
||||||
- Тип: строка
|
|
||||||
|
|
||||||
Путь к диску (блочному устройству) для хранения данных. Крайне рекомендуется
|
|
||||||
использовать стабильные пути: `/dev/disk/by-partuuid/xxx...` вместо простых
|
|
||||||
`/dev/sda` или `/dev/nvme0n1`, чтобы пути не могли спутаться после
|
|
||||||
перезагрузки сервера. Также вместо блочных устройств можно указывать файлы,
|
|
||||||
но это реализовано только для тестирования, а не для боевой среды.
|
|
||||||
|
|
||||||
## meta_device
|
|
||||||
|
|
||||||
- Тип: строка
|
|
||||||
|
|
||||||
Путь к диску метаданных. Метаданные должны располагаться на быстром
|
|
||||||
SSD-диске, иначе производительность пострадает. Если эта опция не указана,
|
|
||||||
для метаданных используется `data_device`.
|
|
||||||
|
|
||||||
## journal_device
|
|
||||||
|
|
||||||
- Тип: строка
|
|
||||||
|
|
||||||
Путь к диску журнала. Журнал должен располагаться на быстром SSD-диске,
|
|
||||||
иначе производительность пострадает. Если эта опция не указана,
|
|
||||||
для журнала используется `meta_device`, если же пуста и она, журнал
|
|
||||||
располагается на `data_device`. Нормально располагать журнал и метаданные
|
|
||||||
на одном устройстве, в этом случае достаточно указать только `meta_device`.
|
|
||||||
|
|
||||||
## journal_offset
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 0
|
|
||||||
|
|
||||||
Смещение на устройстве в байтах, по которому располагается журнал.
|
|
||||||
|
|
||||||
## journal_size
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
|
|
||||||
Размер журнала в байтах. По умолчанию для журнала используется всё доступное
|
|
||||||
место между journal_offset и data_offset, meta_offset или концом диска.
|
|
||||||
В SSD-кластерах большие журналы не нужны, достаточно 32 МБ. В гибридных
|
|
||||||
(SSD+HDD) кластерах осмысленно использовать больший размер журнал (например, 1 ГБ)
|
|
||||||
и включить [throttle_small_writes](osd.ru.md#throttle_small_writes).
|
|
||||||
|
|
||||||
## meta_offset
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 0
|
|
||||||
|
|
||||||
Смещение на устройстве в байтах, по которому располагаются метаданные.
|
|
||||||
Эту опцию нужно задать, если метаданные у вас хранятся на том же
|
|
||||||
устройстве, что данные или журнал.
|
|
||||||
|
|
||||||
## data_offset
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 0
|
|
||||||
|
|
||||||
Смещение на устройстве в байтах, по которому располагаются данные.
|
|
||||||
Эту опцию нужно задать, если данные у вас хранятся на том же
|
|
||||||
устройстве, что метаданные или журнал.
|
|
||||||
|
|
||||||
## data_size
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
|
|
||||||
Размер области данных в байтах. По умолчанию под данные будет использована
|
|
||||||
вся доступная область устройства данных до конца устройства, но вы можете
|
|
||||||
использовать эту опцию, чтобы ограничить её меньшим размером. Заметьте, что
|
|
||||||
опции размера области метаданных нет - она вычисляется из размера области
|
|
||||||
данных автоматически.
|
|
||||||
|
|
||||||
## meta_block_size
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 4096
|
|
||||||
|
|
||||||
Размер физического блока устройства метаданных. 4096 для большинства
|
|
||||||
современных SSD и HDD.
|
|
||||||
|
|
||||||
## journal_block_size
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 4096
|
|
||||||
|
|
||||||
Размер физического блока устройства журнала. Должен быть кратен
|
|
||||||
`disk_alignment`. 4096 для большинства современных SSD и HDD.
|
|
||||||
|
|
||||||
## disable_data_fsync
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: false
|
|
||||||
|
|
||||||
Не отправлять fsync-и устройству данных, т.е. не сбрасывать его кэш.
|
|
||||||
Безопасно, ТОЛЬКО если ваше устройство данных имеет кэш со сквозной
|
|
||||||
записью (write-through). Если вы отключаете кэш через `hdparm` или
|
|
||||||
`scsi_disk/cache_type`, то удостоверьтесь, что команда отключения кэша
|
|
||||||
выполняется перед каждым запуском Vitastor OSD, например, в systemd unit-е.
|
|
||||||
Смотрите также опцию `immediate_commit` для инструкций по отключению кэша
|
|
||||||
и о том, как из этого извлечь выгоду.
|
|
||||||
|
|
||||||
## disable_meta_fsync
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: false
|
|
||||||
|
|
||||||
То же, что disable_data_fsync, но для устройства метаданных. Если устройство
|
|
||||||
метаданных не задано или если оно равно устройству данных, значение опции
|
|
||||||
игнорируется и вместо него используется значение опции disable_data_fsync.
|
|
||||||
|
|
||||||
## disable_journal_fsync
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: false
|
|
||||||
|
|
||||||
То же, что disable_data_fsync, но для устройства журнала. Если устройство
|
|
||||||
журнала не задано или если оно равно устройству метаданных, значение опции
|
|
||||||
игнорируется и вместо него используется значение опции disable_meta_fsync.
|
|
||||||
Если одно и то же устройство используется и под данные, и под журнал, и под
|
|
||||||
метаданные - значение опции также игнорируется и вместо него используется
|
|
||||||
значение опции disable_data_fsync.
|
|
||||||
|
|
||||||
## disable_device_lock
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: false
|
|
||||||
|
|
||||||
Не блокировать устройства данных, метаданных и журнала от открытия их
|
|
||||||
другими OSD с помощью flock(). Так делать не рекомендуется, но теоретически
|
|
||||||
вы можете это использовать, чтобы запускать несколько OSD на одном
|
|
||||||
устройстве с разными смещениями и без использования разделов.
|
|
||||||
|
|
||||||
## disk_alignment
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 4096
|
|
||||||
|
|
||||||
Требуемое выравнивание записи на физические диски. Почти все современные
|
|
||||||
SSD и HDD диски используют 4 КБ физические секторы, даже если показывают
|
|
||||||
логический размер сектора 512 байт, поэтому 4 КБ - хорошее значение по
|
|
||||||
умолчанию.
|
|
||||||
|
|
||||||
Однако стоит понимать, что физический размер сектора тоже влияет на
|
|
||||||
избыточную запись (WA), потому что ничего меньше блока (сектора) на блочное
|
|
||||||
устройство записать невозможно. Таким образом, когда Vitastor-у нужно
|
|
||||||
записать на диск всего лишь одну 32-байтную запись метаданных, фактически
|
|
||||||
приходится перезаписывать 4 КБ сектор целиком.
|
|
||||||
|
|
||||||
Поэтому, на самом деле, может быть выгодно найти SSD, хорошо работающие с
|
|
||||||
меньшими, 512-байтными, блоками и использовать 512-байтные disk_alignment,
|
|
||||||
journal_block_size и meta_block_size. Однако единственные SSD, которые
|
|
||||||
теоретически могут попасть в эту категорию - это Intel Optane (но и это
|
|
||||||
пока не проверялось автором).
|
|
||||||
|
|
||||||
Клиентам не обязательно знать про disk_alignment, так что помещать значение
|
|
||||||
этого параметра в etcd в /vitastor/config/global не нужно.
|
|
||||||
|
|
@ -1,79 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Monitor Parameters
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](monitor.ru.md)
|
|
||||||
|
|
||||||
# Monitor Parameters
|
|
||||||
|
|
||||||
These parameters only apply to Monitors.
|
|
||||||
|
|
||||||
- [etcd_mon_ttl](#etcd_mon_ttl)
|
|
||||||
- [etcd_mon_timeout](#etcd_mon_timeout)
|
|
||||||
- [etcd_mon_retries](#etcd_mon_retries)
|
|
||||||
- [mon_change_timeout](#mon_change_timeout)
|
|
||||||
- [mon_stats_timeout](#mon_stats_timeout)
|
|
||||||
- [osd_out_time](#osd_out_time)
|
|
||||||
- [placement_levels](#placement_levels)
|
|
||||||
|
|
||||||
## etcd_mon_ttl
|
|
||||||
|
|
||||||
- Type: seconds
|
|
||||||
- Default: 30
|
|
||||||
- Minimum: 10
|
|
||||||
|
|
||||||
Monitor etcd lease refresh interval in seconds
|
|
||||||
|
|
||||||
## etcd_mon_timeout
|
|
||||||
|
|
||||||
- Type: milliseconds
|
|
||||||
- Default: 1000
|
|
||||||
|
|
||||||
etcd request timeout used by monitor
|
|
||||||
|
|
||||||
## etcd_mon_retries
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 5
|
|
||||||
|
|
||||||
Maximum number of attempts for one monitor etcd request
|
|
||||||
|
|
||||||
## mon_change_timeout
|
|
||||||
|
|
||||||
- Type: milliseconds
|
|
||||||
- Default: 1000
|
|
||||||
- Minimum: 100
|
|
||||||
|
|
||||||
Optimistic retry interval for monitor etcd modification requests
|
|
||||||
|
|
||||||
## mon_stats_timeout
|
|
||||||
|
|
||||||
- Type: milliseconds
|
|
||||||
- Default: 1000
|
|
||||||
- Minimum: 100
|
|
||||||
|
|
||||||
Interval for monitor to wait before updating aggregated statistics in
|
|
||||||
etcd after receiving OSD statistics updates
|
|
||||||
|
|
||||||
## osd_out_time
|
|
||||||
|
|
||||||
- Type: seconds
|
|
||||||
- Default: 600
|
|
||||||
|
|
||||||
Time after which a failed OSD is removed from the data distribution.
|
|
||||||
I.e. time which the monitor waits before attempting to restore data
|
|
||||||
redundancy using other OSDs.
|
|
||||||
|
|
||||||
## placement_levels
|
|
||||||
|
|
||||||
- Type: json
|
|
||||||
- Default: `{"host":100,"osd":101}`
|
|
||||||
|
|
||||||
Levels for the placement tree. You can define arbitrary tree levels by
|
|
||||||
defining them in this parameter. The configuration parameter value should
|
|
||||||
contain a JSON object with level names as keys and integer priorities as
|
|
||||||
values. Smaller priority means higher level in tree. For example,
|
|
||||||
"datacenter" should have smaller priority than "osd". "host" and "osd"
|
|
||||||
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").
|
|
||||||
|
|
@ -1,80 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Параметры мониторов
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](monitor.en.md)
|
|
||||||
|
|
||||||
# Параметры мониторов
|
|
||||||
|
|
||||||
Данные параметры используются только мониторами Vitastor.
|
|
||||||
|
|
||||||
- [etcd_mon_ttl](#etcd_mon_ttl)
|
|
||||||
- [etcd_mon_timeout](#etcd_mon_timeout)
|
|
||||||
- [etcd_mon_retries](#etcd_mon_retries)
|
|
||||||
- [mon_change_timeout](#mon_change_timeout)
|
|
||||||
- [mon_stats_timeout](#mon_stats_timeout)
|
|
||||||
- [osd_out_time](#osd_out_time)
|
|
||||||
- [placement_levels](#placement_levels)
|
|
||||||
|
|
||||||
## etcd_mon_ttl
|
|
||||||
|
|
||||||
- Тип: секунды
|
|
||||||
- Значение по умолчанию: 30
|
|
||||||
- Минимальное значение: 10
|
|
||||||
|
|
||||||
Интервал обновления etcd резервации (lease) монитором
|
|
||||||
|
|
||||||
## etcd_mon_timeout
|
|
||||||
|
|
||||||
- Тип: миллисекунды
|
|
||||||
- Значение по умолчанию: 1000
|
|
||||||
|
|
||||||
Таймаут выполнения запросов к etcd от монитора
|
|
||||||
|
|
||||||
## etcd_mon_retries
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 5
|
|
||||||
|
|
||||||
Максимальное число попыток выполнения запросов к etcd монитором
|
|
||||||
|
|
||||||
## mon_change_timeout
|
|
||||||
|
|
||||||
- Тип: миллисекунды
|
|
||||||
- Значение по умолчанию: 1000
|
|
||||||
- Минимальное значение: 100
|
|
||||||
|
|
||||||
Время повтора при коллизиях при запросах модификации в etcd, производимых монитором
|
|
||||||
|
|
||||||
## mon_stats_timeout
|
|
||||||
|
|
||||||
- Тип: миллисекунды
|
|
||||||
- Значение по умолчанию: 1000
|
|
||||||
- Минимальное значение: 100
|
|
||||||
|
|
||||||
Интервал, который монитор ожидает при изменении статистики по отдельным
|
|
||||||
OSD перед обновлением агрегированной статистики в etcd
|
|
||||||
|
|
||||||
## osd_out_time
|
|
||||||
|
|
||||||
- Тип: секунды
|
|
||||||
- Значение по умолчанию: 600
|
|
||||||
|
|
||||||
Время, через которое отключенный OSD исключается из распределения данных.
|
|
||||||
То есть, время, которое монитор ожидает перед попыткой переместить данные
|
|
||||||
на другие OSD и таким образом восстановить избыточность хранения.
|
|
||||||
|
|
||||||
## placement_levels
|
|
||||||
|
|
||||||
- Тип: json
|
|
||||||
- Значение по умолчанию: `{"host":100,"osd":101}`
|
|
||||||
|
|
||||||
Определения уровней для дерева размещения OSD. Вы можете определять
|
|
||||||
произвольные уровни, помещая их в данный параметр конфигурации. Значение
|
|
||||||
параметра должно содержать JSON-объект, ключи которого будут являться
|
|
||||||
названиями уровней, а значения - целочисленными приоритетами. Меньшие
|
|
||||||
приоритеты соответствуют верхним уровням дерева. Например, уровень
|
|
||||||
"датацентр" должен иметь меньший приоритет, чем "OSD". Уровни с названиями
|
|
||||||
"host" и "osd" являются предопределёнными и не могут быть удалены. Если
|
|
||||||
один из них отсутствует в конфигурации, он доопределяется с приоритетом по
|
|
||||||
умолчанию (100 для уровня "host", 101 для "osd").
|
|
||||||
|
|
@ -1,214 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Network Protocol Parameters
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](network.ru.md)
|
|
||||||
|
|
||||||
# Network Protocol Parameters
|
|
||||||
|
|
||||||
These parameters apply to clients and OSDs and affect network connection logic
|
|
||||||
between clients, OSDs and etcd.
|
|
||||||
|
|
||||||
- [tcp_header_buffer_size](#tcp_header_buffer_size)
|
|
||||||
- [use_sync_send_recv](#use_sync_send_recv)
|
|
||||||
- [use_rdma](#use_rdma)
|
|
||||||
- [rdma_device](#rdma_device)
|
|
||||||
- [rdma_port_num](#rdma_port_num)
|
|
||||||
- [rdma_gid_index](#rdma_gid_index)
|
|
||||||
- [rdma_mtu](#rdma_mtu)
|
|
||||||
- [rdma_max_sge](#rdma_max_sge)
|
|
||||||
- [rdma_max_msg](#rdma_max_msg)
|
|
||||||
- [rdma_max_recv](#rdma_max_recv)
|
|
||||||
- [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_timeout](#etcd_ws_keepalive_timeout)
|
|
||||||
|
|
||||||
## tcp_header_buffer_size
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 65536
|
|
||||||
|
|
||||||
Size of the buffer used to read data using an additional copy. Vitastor
|
|
||||||
packet headers are 128 bytes, payload is always at least 4 KB, so it is
|
|
||||||
usually beneficial to try to read multiple packets at once even though
|
|
||||||
it requires to copy the data an additional time. The rest of each packet
|
|
||||||
is received without an additional copy. You can try to play with this
|
|
||||||
parameter and see how it affects random iops and linear bandwidth if you
|
|
||||||
want.
|
|
||||||
|
|
||||||
## use_sync_send_recv
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: false
|
|
||||||
|
|
||||||
If true, synchronous send/recv syscalls are used instead of io_uring for
|
|
||||||
socket communication. Useless for OSDs because they require io_uring anyway,
|
|
||||||
but may be required for clients with old kernel versions.
|
|
||||||
|
|
||||||
## use_rdma
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: true
|
|
||||||
|
|
||||||
Try to use RDMA for communication if it's available. Disable if you don't
|
|
||||||
want Vitastor to use RDMA. TCP-only clients can also talk to an RDMA-enabled
|
|
||||||
cluster, so disabling RDMA may be needed if clients have RDMA devices,
|
|
||||||
but they are not connected to the cluster.
|
|
||||||
|
|
||||||
## rdma_device
|
|
||||||
|
|
||||||
- Type: string
|
|
||||||
|
|
||||||
RDMA device name to use for Vitastor OSD communications (for example,
|
|
||||||
"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
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 1
|
|
||||||
|
|
||||||
RDMA device port number to use. Only for devices that have more than 1 port.
|
|
||||||
See `phys_port_cnt` in `ibv_devinfo -v` output to determine how many ports
|
|
||||||
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.
|
|
||||||
|
|
||||||
**IMPORTANT:** If you want to use RoCEv2 (as recommended) then the correct
|
|
||||||
rdma_gid_index is usually 1 (IPv6) or 3 (IPv4).
|
|
||||||
|
|
||||||
## rdma_mtu
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 4096
|
|
||||||
|
|
||||||
RDMA Path MTU to use. Must be 1024, 2048 or 4096. There is usually no
|
|
||||||
sense to change it from the default 4096.
|
|
||||||
|
|
||||||
## rdma_max_sge
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 128
|
|
||||||
|
|
||||||
Maximum number of scatter/gather entries to use for RDMA. OSDs negotiate
|
|
||||||
the actual value when establishing connection anyway, so it's usually not
|
|
||||||
required to change this parameter.
|
|
||||||
|
|
||||||
## rdma_max_msg
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 1048576
|
|
||||||
|
|
||||||
Maximum size of a single RDMA send or receive operation in bytes.
|
|
||||||
|
|
||||||
## rdma_max_recv
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 8
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
Interval before attempting to reconnect to an unavailable OSD.
|
|
||||||
|
|
||||||
## peer_connect_timeout
|
|
||||||
|
|
||||||
- Type: seconds
|
|
||||||
- Default: 5
|
|
||||||
- Minimum: 1
|
|
||||||
|
|
||||||
Timeout for OSD connection attempts.
|
|
||||||
|
|
||||||
## osd_idle_timeout
|
|
||||||
|
|
||||||
- Type: seconds
|
|
||||||
- Default: 5
|
|
||||||
- Minimum: 1
|
|
||||||
|
|
||||||
OSD connection inactivity time after which clients and other OSDs send
|
|
||||||
keepalive requests to check state of the connection.
|
|
||||||
|
|
||||||
## osd_ping_timeout
|
|
||||||
|
|
||||||
- Type: seconds
|
|
||||||
- Default: 5
|
|
||||||
- Minimum: 1
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
Maximum number of attempts for etcd requests which can't be retried
|
|
||||||
indefinitely.
|
|
||||||
|
|
||||||
## etcd_quick_timeout
|
|
||||||
|
|
||||||
- Type: milliseconds
|
|
||||||
- Default: 1000
|
|
||||||
|
|
||||||
Timeout for etcd requests which should complete quickly, like lease refresh.
|
|
||||||
|
|
||||||
## etcd_slow_timeout
|
|
||||||
|
|
||||||
- Type: milliseconds
|
|
||||||
- Default: 5000
|
|
||||||
|
|
||||||
Timeout for etcd requests which are allowed to wait for some time.
|
|
||||||
|
|
||||||
## etcd_keepalive_timeout
|
|
||||||
|
|
||||||
- Type: seconds
|
|
||||||
- Default: max(30, etcd_report_interval*2)
|
|
||||||
|
|
||||||
Timeout for etcd connection HTTP Keep-Alive. Should be higher than
|
|
||||||
etcd_report_interval to guarantee that keepalive actually works.
|
|
||||||
|
|
||||||
## etcd_ws_keepalive_timeout
|
|
||||||
|
|
||||||
- Type: seconds
|
|
||||||
- Default: 30
|
|
||||||
|
|
||||||
etcd websocket ping interval required to keep the connection alive and
|
|
||||||
detect disconnections quickly.
|
|
||||||
|
|
@ -1,224 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Параметры сетевого протокола
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](network.en.md)
|
|
||||||
|
|
||||||
# Параметры сетевого протокола
|
|
||||||
|
|
||||||
Данные параметры используются клиентами и OSD и влияют на логику сетевого
|
|
||||||
взаимодействия между клиентами, OSD, а также etcd.
|
|
||||||
|
|
||||||
- [tcp_header_buffer_size](#tcp_header_buffer_size)
|
|
||||||
- [use_sync_send_recv](#use_sync_send_recv)
|
|
||||||
- [use_rdma](#use_rdma)
|
|
||||||
- [rdma_device](#rdma_device)
|
|
||||||
- [rdma_port_num](#rdma_port_num)
|
|
||||||
- [rdma_gid_index](#rdma_gid_index)
|
|
||||||
- [rdma_mtu](#rdma_mtu)
|
|
||||||
- [rdma_max_sge](#rdma_max_sge)
|
|
||||||
- [rdma_max_msg](#rdma_max_msg)
|
|
||||||
- [rdma_max_recv](#rdma_max_recv)
|
|
||||||
- [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_timeout](#etcd_ws_keepalive_timeout)
|
|
||||||
|
|
||||||
## tcp_header_buffer_size
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 65536
|
|
||||||
|
|
||||||
Размер буфера для чтения данных с дополнительным копированием. Пакеты
|
|
||||||
Vitastor содержат 128-байтные заголовки, за которыми следуют данные размером
|
|
||||||
от 4 КБ и для мелких операций ввода-вывода обычно выгодно за 1 вызов читать
|
|
||||||
сразу несколько пакетов, даже не смотря на то, что это требует лишний раз
|
|
||||||
скопировать данные. Часть каждого пакета за пределами значения данного
|
|
||||||
параметра читается без дополнительного копирования. Вы можете попробовать
|
|
||||||
поменять этот параметр и посмотреть, как он влияет на производительность
|
|
||||||
случайного и линейного доступа.
|
|
||||||
|
|
||||||
## use_sync_send_recv
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: false
|
|
||||||
|
|
||||||
Если установлено в истину, то вместо io_uring для передачи данных по сети
|
|
||||||
будут использоваться обычные синхронные системные вызовы send/recv. Для OSD
|
|
||||||
это бессмысленно, так как OSD в любом случае нуждается в io_uring, но, в
|
|
||||||
принципе, это может применяться для клиентов со старыми версиями ядра.
|
|
||||||
|
|
||||||
## use_rdma
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: true
|
|
||||||
|
|
||||||
Пытаться использовать RDMA для связи при наличии доступных устройств.
|
|
||||||
Отключите, если вы не хотите, чтобы Vitastor использовал RDMA.
|
|
||||||
TCP-клиенты также могут работать с RDMA-кластером, так что отключать
|
|
||||||
RDMA может быть нужно только если у клиентов есть RDMA-устройства,
|
|
||||||
но они не имеют соединения с кластером Vitastor.
|
|
||||||
|
|
||||||
## rdma_device
|
|
||||||
|
|
||||||
- Тип: строка
|
|
||||||
|
|
||||||
Название RDMA-устройства для связи с Vitastor OSD (например, "rocep5s0f0").
|
|
||||||
Имейте в виду, что поддержка RDMA в Vitastor требует функций устройства
|
|
||||||
Implicit On-Demand Paging (Implicit ODP) и Scatter/Gather (SG). Например,
|
|
||||||
адаптеры Mellanox ConnectX-3 и более старые не поддерживают Implicit ODP и
|
|
||||||
потому не поддерживаются в Vitastor. Запустите `ibv_devinfo -v` от имени
|
|
||||||
суперпользователя, чтобы посмотреть список доступных RDMA-устройств, их
|
|
||||||
параметры и возможности.
|
|
||||||
|
|
||||||
## rdma_port_num
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 1
|
|
||||||
|
|
||||||
Номер порта RDMA-устройства, который следует использовать. Имеет смысл
|
|
||||||
только для устройств, у которых более 1 порта. Чтобы узнать, сколько портов
|
|
||||||
у вашего адаптера, посмотрите `phys_port_cnt` в выводе команды
|
|
||||||
`ibv_devinfo -v`.
|
|
||||||
|
|
||||||
## rdma_gid_index
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 0
|
|
||||||
|
|
||||||
Номер глобального идентификатора адреса RDMA-устройства, который следует
|
|
||||||
использовать. Разным gid_index могут соответствовать разные протоколы связи:
|
|
||||||
RoCEv1, RoCEv2, iWARP. Чтобы понять, какой нужен вам - смотрите строчки со
|
|
||||||
словом "GID" в выводе команды `ibv_devinfo -v`.
|
|
||||||
|
|
||||||
**ВАЖНО:** Если вы хотите использовать RoCEv2 (как мы и рекомендуем), то
|
|
||||||
правильный rdma_gid_index, как правило, 1 (IPv6) или 3 (IPv4).
|
|
||||||
|
|
||||||
## rdma_mtu
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 4096
|
|
||||||
|
|
||||||
Максимальная единица передачи (Path MTU) для RDMA. Должно быть равно 1024,
|
|
||||||
2048 или 4096. Обычно нет смысла менять значение по умолчанию, равное 4096.
|
|
||||||
|
|
||||||
## rdma_max_sge
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 128
|
|
||||||
|
|
||||||
Максимальное число записей разделения/сборки (scatter/gather) для RDMA.
|
|
||||||
OSD в любом случае согласовывают реальное значение при установке соединения,
|
|
||||||
так что менять этот параметр обычно не нужно.
|
|
||||||
|
|
||||||
## rdma_max_msg
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 1048576
|
|
||||||
|
|
||||||
Максимальный размер одной RDMA-операции отправки или приёма.
|
|
||||||
|
|
||||||
## rdma_max_recv
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 8
|
|
||||||
|
|
||||||
Максимальное число параллельных RDMA-операций получения данных. Следует
|
|
||||||
иметь в виду, что данное число буферов размером `rdma_max_msg` выделяется
|
|
||||||
для каждого подключённого клиентского соединения, так что данная настройка
|
|
||||||
влияет на потребление памяти. Это так потому, что RDMA-приём данных в
|
|
||||||
Vitastor, увы, всё равно не является zero-copy, т.е. всё равно 1 раз
|
|
||||||
копирует данные в памяти. Данная особенность, возможно, будет исправлена в
|
|
||||||
более новых версиях Vitastor.
|
|
||||||
|
|
||||||
## peer_connect_interval
|
|
||||||
|
|
||||||
- Тип: секунды
|
|
||||||
- Значение по умолчанию: 5
|
|
||||||
- Минимальное значение: 1
|
|
||||||
|
|
||||||
Время ожидания перед повторной попыткой соединиться с недоступным OSD.
|
|
||||||
|
|
||||||
## peer_connect_timeout
|
|
||||||
|
|
||||||
- Тип: секунды
|
|
||||||
- Значение по умолчанию: 5
|
|
||||||
- Минимальное значение: 1
|
|
||||||
|
|
||||||
Максимальное время ожидания попытки соединения с OSD.
|
|
||||||
|
|
||||||
## osd_idle_timeout
|
|
||||||
|
|
||||||
- Тип: секунды
|
|
||||||
- Значение по умолчанию: 5
|
|
||||||
- Минимальное значение: 1
|
|
||||||
|
|
||||||
Время неактивности соединения с OSD, после которого клиенты или другие OSD
|
|
||||||
посылают запрос проверки состояния соединения.
|
|
||||||
|
|
||||||
## osd_ping_timeout
|
|
||||||
|
|
||||||
- Тип: секунды
|
|
||||||
- Значение по умолчанию: 5
|
|
||||||
- Минимальное значение: 1
|
|
||||||
|
|
||||||
Максимальное время ожидания ответа на запрос проверки состояния соединения.
|
|
||||||
Если OSD не отвечает за это время, соединение отключается и производится
|
|
||||||
повторная попытка соединения.
|
|
||||||
|
|
||||||
## up_wait_retry_interval
|
|
||||||
|
|
||||||
- Тип: миллисекунды
|
|
||||||
- Значение по умолчанию: 500
|
|
||||||
- Минимальное значение: 50
|
|
||||||
|
|
||||||
Когда OSD получают от клиентов запросы ввода-вывода, относящиеся к не
|
|
||||||
поднятым на данный момент на них PG, либо к PG в процессе синхронизации,
|
|
||||||
они отвечают клиентам специальным кодом ошибки, означающим, что клиент
|
|
||||||
должен некоторое время подождать перед повторением запроса. Именно это время
|
|
||||||
ожидания задаёт данный параметр.
|
|
||||||
|
|
||||||
## max_etcd_attempts
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 5
|
|
||||||
|
|
||||||
Максимальное число попыток выполнения запросов к etcd для тех запросов,
|
|
||||||
которые нельзя повторять бесконечно.
|
|
||||||
|
|
||||||
## etcd_quick_timeout
|
|
||||||
|
|
||||||
- Тип: миллисекунды
|
|
||||||
- Значение по умолчанию: 1000
|
|
||||||
|
|
||||||
Максимальное время выполнения запросов к etcd, которые должны завершаться
|
|
||||||
быстро, таких, как обновление резервации (lease).
|
|
||||||
|
|
||||||
## etcd_slow_timeout
|
|
||||||
|
|
||||||
- Тип: миллисекунды
|
|
||||||
- Значение по умолчанию: 5000
|
|
||||||
|
|
||||||
Максимальное время выполнения запросов к etcd, для которых не обязательно
|
|
||||||
гарантировать быстрое выполнение.
|
|
||||||
|
|
||||||
## etcd_keepalive_timeout
|
|
||||||
|
|
||||||
- Тип: секунды
|
|
||||||
- Значение по умолчанию: max(30, etcd_report_interval*2)
|
|
||||||
|
|
||||||
Таймаут для HTTP Keep-Alive в соединениях к etcd. Должен быть больше, чем
|
|
||||||
etcd_report_interval, чтобы keepalive гарантированно работал.
|
|
||||||
|
|
||||||
## etcd_ws_keepalive_timeout
|
|
||||||
|
|
||||||
- Тип: секунды
|
|
||||||
- Значение по умолчанию: 30
|
|
||||||
|
|
||||||
Интервал проверки живости вебсокет-подключений к etcd.
|
|
||||||
|
|
@ -1,297 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Runtime OSD Parameters
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](osd.ru.md)
|
|
||||||
|
|
||||||
# Runtime OSD Parameters
|
|
||||||
|
|
||||||
These parameters only apply to OSDs, are not fixed at the moment of OSD drive
|
|
||||||
initialization and can be changed with an OSD restart.
|
|
||||||
|
|
||||||
- [etcd_report_interval](#etcd_report_interval)
|
|
||||||
- [run_primary](#run_primary)
|
|
||||||
- [osd_network](#osd_network)
|
|
||||||
- [bind_address](#bind_address)
|
|
||||||
- [bind_port](#bind_port)
|
|
||||||
- [autosync_interval](#autosync_interval)
|
|
||||||
- [autosync_writes](#autosync_writes)
|
|
||||||
- [recovery_queue_depth](#recovery_queue_depth)
|
|
||||||
- [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)
|
|
||||||
- [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)
|
|
||||||
- [journal_sector_buffer_count](#journal_sector_buffer_count)
|
|
||||||
- [journal_no_same_sector_overwrites](#journal_no_same_sector_overwrites)
|
|
||||||
- [throttle_small_writes](#throttle_small_writes)
|
|
||||||
- [throttle_target_iops](#throttle_target_iops)
|
|
||||||
- [throttle_target_mbs](#throttle_target_mbs)
|
|
||||||
- [throttle_target_parallelism](#throttle_target_parallelism)
|
|
||||||
- [throttle_threshold_us](#throttle_threshold_us)
|
|
||||||
- [osd_memlock](#osd_memlock)
|
|
||||||
|
|
||||||
## etcd_report_interval
|
|
||||||
|
|
||||||
- Type: seconds
|
|
||||||
- Default: 5
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
## run_primary
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: true
|
|
||||||
|
|
||||||
Start primary OSD logic on this OSD. As of now, can be turned off only for
|
|
||||||
debugging purposes. It's possible to implement additional feature for the
|
|
||||||
monitor which may allow to separate primary and secondary OSDs, but it's
|
|
||||||
unclear why anyone could need it, so it's not implemented.
|
|
||||||
|
|
||||||
## osd_network
|
|
||||||
|
|
||||||
- Type: string or array of strings
|
|
||||||
|
|
||||||
Network mask of the network (IPv4 or IPv6) to use for OSDs. Note that
|
|
||||||
although it's possible to specify multiple networks here, this does not
|
|
||||||
mean that OSDs will create multiple listening sockets - they'll only
|
|
||||||
pick the first matching address of an UP + RUNNING interface. Separate
|
|
||||||
networks for cluster and client connections are also not implemented, but
|
|
||||||
they are mostly useless anyway, so it's not a big deal.
|
|
||||||
|
|
||||||
## bind_address
|
|
||||||
|
|
||||||
- Type: string
|
|
||||||
- Default: 0.0.0.0
|
|
||||||
|
|
||||||
Instead of the network mask, you can also set OSD listen address explicitly
|
|
||||||
using this parameter. May be useful if you want to start OSDs on interfaces
|
|
||||||
that are not UP + RUNNING.
|
|
||||||
|
|
||||||
## bind_port
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
|
|
||||||
By default, OSDs pick random ports to use for incoming connections
|
|
||||||
automatically. With this option you can set a specific port for a specific
|
|
||||||
OSD by hand.
|
|
||||||
|
|
||||||
## autosync_interval
|
|
||||||
|
|
||||||
- Type: seconds
|
|
||||||
- Default: 5
|
|
||||||
|
|
||||||
Time interval at which automatic fsyncs/flushes are issued by each OSD when
|
|
||||||
the immediate_commit mode if disabled. fsyncs are required because without
|
|
||||||
them OSDs quickly fill their journals, become unable to clear them and
|
|
||||||
stall. Also this option limits the amount of recent uncommitted changes
|
|
||||||
which OSDs may lose in case of a power outage in case when clients don't
|
|
||||||
issue fsyncs at all.
|
|
||||||
|
|
||||||
## autosync_writes
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 128
|
|
||||||
|
|
||||||
Same as autosync_interval, but sets the maximum number of uncommitted write
|
|
||||||
operations before issuing an fsync operation internally.
|
|
||||||
|
|
||||||
## recovery_queue_depth
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 4
|
|
||||||
|
|
||||||
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
|
|
||||||
|
|
||||||
Maximum number of recovery operations before issuing an additional fsync.
|
|
||||||
|
|
||||||
## readonly
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: false
|
|
||||||
|
|
||||||
Read-only mode. If this is enabled, an OSD will never issue any writes to
|
|
||||||
the underlying device. This may be useful for recovery purposes.
|
|
||||||
|
|
||||||
## no_recovery
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: false
|
|
||||||
|
|
||||||
Disable automatic background recovery of objects. Note that it doesn't
|
|
||||||
affect implicit recovery of objects happening during writes - a write is
|
|
||||||
always made to a full set of at least pg_minsize OSDs.
|
|
||||||
|
|
||||||
## no_rebalance
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: false
|
|
||||||
|
|
||||||
Disable background movement of data between different OSDs. Disabling it
|
|
||||||
means that PGs in the `has_misplaced` state will be left in it indefinitely.
|
|
||||||
|
|
||||||
## print_stats_interval
|
|
||||||
|
|
||||||
- Type: seconds
|
|
||||||
- Default: 3
|
|
||||||
|
|
||||||
Time interval at which OSDs print simple human-readable operation
|
|
||||||
statistics on stdout.
|
|
||||||
|
|
||||||
## slow_log_interval
|
|
||||||
|
|
||||||
- Type: seconds
|
|
||||||
- Default: 10
|
|
||||||
|
|
||||||
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".
|
|
||||||
|
|
||||||
## max_write_iodepth
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 128
|
|
||||||
|
|
||||||
Parallel client write operation limit per one OSD. Operations that exceed
|
|
||||||
this limit are pushed to a temporary queue instead of being executed
|
|
||||||
immediately.
|
|
||||||
|
|
||||||
## min_flusher_count
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 1
|
|
||||||
|
|
||||||
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.
|
|
||||||
Minimum number is set by this parameter.
|
|
||||||
|
|
||||||
## max_flusher_count
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 256
|
|
||||||
|
|
||||||
Maximum number of journal flushers (see above min_flusher_count).
|
|
||||||
|
|
||||||
## inmemory_metadata
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: true
|
|
||||||
|
|
||||||
This parameter makes Vitastor always keep metadata area of the block device
|
|
||||||
in memory. It's required for good performance because it allows to avoid
|
|
||||||
additional read-modify-write cycles during metadata modifications. Metadata
|
|
||||||
area size is currently roughly 224 MB per 1 TB of data. You can turn it off
|
|
||||||
to reduce memory usage by this value, but it will hurt performance. This
|
|
||||||
restriction is likely to be removed in the future along with the upgrade
|
|
||||||
of the metadata storage scheme.
|
|
||||||
|
|
||||||
## inmemory_journal
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: true
|
|
||||||
|
|
||||||
This parameter make Vitastor always keep journal area of the block
|
|
||||||
device in memory. Turning it off will, again, reduce memory usage, but
|
|
||||||
hurt performance because flusher coroutines will have to read data from
|
|
||||||
the disk back before copying it into the main area. The memory usage benefit
|
|
||||||
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.
|
|
||||||
|
|
||||||
## journal_sector_buffer_count
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 32
|
|
||||||
|
|
||||||
Maximum number of buffers that can be used for writing journal metadata
|
|
||||||
blocks. The only situation when you should increase it to a larger value
|
|
||||||
is when you enable journal_no_same_sector_overwrites. In this case set
|
|
||||||
it to, for example, 1024.
|
|
||||||
|
|
||||||
## journal_no_same_sector_overwrites
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: false
|
|
||||||
|
|
||||||
Enable this option for SSDs like Intel D3-S4510 and D3-S4610 which REALLY
|
|
||||||
don't like when a program overwrites the same sector multiple times in a
|
|
||||||
row and slow down significantly (from 25000+ iops to ~3000 iops). When
|
|
||||||
this option is set, Vitastor will always move to the next sector of the
|
|
||||||
journal after writing it instead of possibly overwriting it the second time.
|
|
||||||
|
|
||||||
Most (99%) other SSDs don't need this option.
|
|
||||||
|
|
||||||
## throttle_small_writes
|
|
||||||
|
|
||||||
- Type: boolean
|
|
||||||
- Default: false
|
|
||||||
|
|
||||||
Enable soft throttling of small journaled writes. Useful for hybrid OSDs
|
|
||||||
with fast journal/metadata devices and slow data devices. The idea is that
|
|
||||||
small writes complete very quickly because they're first written to the
|
|
||||||
journal device, but moving them to the main device is slow. So if an OSD
|
|
||||||
allows clients to issue a lot of small writes it will perform very good
|
|
||||||
for several seconds and then the journal will fill up and the performance
|
|
||||||
will drop to almost zero. Throttling is meant to prevent this problem by
|
|
||||||
artifically slowing quick writes down based on the amount of free space in
|
|
||||||
the journal. When throttling is used, the performance of small writes will
|
|
||||||
decrease smoothly instead of abrupt drop at the moment when the journal
|
|
||||||
fills up.
|
|
||||||
|
|
||||||
## throttle_target_iops
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 100
|
|
||||||
|
|
||||||
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
|
|
||||||
(HDDs).
|
|
||||||
|
|
||||||
## throttle_target_mbs
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 100
|
|
||||||
|
|
||||||
Target maximum bandwidth in MB/s of throttled operations per second under
|
|
||||||
the condition of full journal. Set it to approximate linear write
|
|
||||||
performance of your data devices (HDDs).
|
|
||||||
|
|
||||||
## throttle_target_parallelism
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 1
|
|
||||||
|
|
||||||
Target maximum parallelism of throttled operations under the condition of
|
|
||||||
full journal. Set it to approximate internal parallelism of your data
|
|
||||||
devices (1 for HDDs, 4-8 for SSDs).
|
|
||||||
|
|
||||||
## throttle_threshold_us
|
|
||||||
|
|
||||||
- Type: microseconds
|
|
||||||
- Default: 50
|
|
||||||
|
|
||||||
Minimal computed delay to be applied to throttled operations. Usually
|
|
||||||
doesn't need to be changed.
|
|
||||||
|
|
||||||
## osd_memlock
|
|
||||||
|
|
||||||
- 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).
|
|
||||||
|
|
@ -1,310 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Изменяемые параметры OSD
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](osd.en.md)
|
|
||||||
|
|
||||||
# Изменяемые параметры OSD
|
|
||||||
|
|
||||||
Данные параметры используются только OSD, но, в отличие от дисковых параметров,
|
|
||||||
не фиксируются в момент инициализации дисков OSD и могут быть изменены в любой
|
|
||||||
момент с перезапуском OSD.
|
|
||||||
|
|
||||||
- [etcd_report_interval](#etcd_report_interval)
|
|
||||||
- [run_primary](#run_primary)
|
|
||||||
- [osd_network](#osd_network)
|
|
||||||
- [bind_address](#bind_address)
|
|
||||||
- [bind_port](#bind_port)
|
|
||||||
- [autosync_interval](#autosync_interval)
|
|
||||||
- [autosync_writes](#autosync_writes)
|
|
||||||
- [recovery_queue_depth](#recovery_queue_depth)
|
|
||||||
- [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)
|
|
||||||
- [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)
|
|
||||||
- [journal_sector_buffer_count](#journal_sector_buffer_count)
|
|
||||||
- [journal_no_same_sector_overwrites](#journal_no_same_sector_overwrites)
|
|
||||||
- [throttle_small_writes](#throttle_small_writes)
|
|
||||||
- [throttle_target_iops](#throttle_target_iops)
|
|
||||||
- [throttle_target_mbs](#throttle_target_mbs)
|
|
||||||
- [throttle_target_parallelism](#throttle_target_parallelism)
|
|
||||||
- [throttle_threshold_us](#throttle_threshold_us)
|
|
||||||
- [osd_memlock](#osd_memlock)
|
|
||||||
|
|
||||||
## etcd_report_interval
|
|
||||||
|
|
||||||
- Тип: секунды
|
|
||||||
- Значение по умолчанию: 5
|
|
||||||
|
|
||||||
Интервал, с которым OSD обновляет своё состояние в etcd. Значение параметра
|
|
||||||
влияет на время резервации (lease) OSD и поэтому на скорость переключения
|
|
||||||
при падении OSD. Время lease равняется значению этого параметра плюс
|
|
||||||
max_etcd_attempts * etcd_quick_timeout.
|
|
||||||
|
|
||||||
## run_primary
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: true
|
|
||||||
|
|
||||||
Запускать логику первичного OSD на данном OSD. На данный момент отключать
|
|
||||||
эту опцию может иметь смысл только в целях отладки. В теории, можно
|
|
||||||
реализовать дополнительный режим для монитора, который позволит отделять
|
|
||||||
первичные OSD от вторичных, но пока не понятно, зачем это может кому-то
|
|
||||||
понадобиться, поэтому это не реализовано.
|
|
||||||
|
|
||||||
## osd_network
|
|
||||||
|
|
||||||
- Тип: строка или массив строк
|
|
||||||
|
|
||||||
Маска подсети (IPv4 или IPv6) для использования для соединений с OSD.
|
|
||||||
Имейте в виду, что хотя сейчас и можно передать в этот параметр несколько
|
|
||||||
подсетей, это не означает, что OSD будут создавать несколько слушающих
|
|
||||||
сокетов - они лишь будут выбирать адрес первого поднятого (состояние UP +
|
|
||||||
RUNNING), подходящий под заданную маску. Также не реализовано разделение
|
|
||||||
кластерной и публичной сетей OSD. Правда, от него обычно всё равно довольно
|
|
||||||
мало толку, так что особенной проблемы в этом нет.
|
|
||||||
|
|
||||||
## bind_address
|
|
||||||
|
|
||||||
- Тип: строка
|
|
||||||
- Значение по умолчанию: 0.0.0.0
|
|
||||||
|
|
||||||
Этим параметром можно явным образом задать адрес, на котором будет ожидать
|
|
||||||
соединений OSD (вместо использования маски подсети). Может быть полезно,
|
|
||||||
например, чтобы запускать OSD на неподнятых интерфейсах (не UP + RUNNING).
|
|
||||||
|
|
||||||
## bind_port
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
|
|
||||||
По умолчанию OSD сами выбирают случайные порты для входящих подключений.
|
|
||||||
С помощью данной опции вы можете задать порт для отдельного OSD вручную.
|
|
||||||
|
|
||||||
## autosync_interval
|
|
||||||
|
|
||||||
- Тип: секунды
|
|
||||||
- Значение по умолчанию: 5
|
|
||||||
|
|
||||||
Временной интервал отправки автоматических fsync-ов (операций очистки кэша)
|
|
||||||
каждым OSD для случая, когда режим immediate_commit отключён. fsync-и нужны
|
|
||||||
OSD, чтобы успевать очищать журнал - без них OSD быстро заполняют журналы и
|
|
||||||
перестают обрабатывать операции записи. Также эта опция ограничивает объём
|
|
||||||
недавних незафиксированных изменений, которые OSD могут терять при
|
|
||||||
отключении питания, если клиенты вообще не отправляют fsync.
|
|
||||||
|
|
||||||
## autosync_writes
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 128
|
|
||||||
|
|
||||||
Аналогично autosync_interval, но задаёт не временной интервал, а
|
|
||||||
максимальное количество незафиксированных операций записи перед
|
|
||||||
принудительной отправкой fsync-а.
|
|
||||||
|
|
||||||
## recovery_queue_depth
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 4
|
|
||||||
|
|
||||||
Максимальное число операций восстановления на одном первичном OSD в любой
|
|
||||||
момент времени. На данный момент единственный параметр, который можно менять
|
|
||||||
для ускорения или замедления восстановления и перебалансировки данных, но
|
|
||||||
в планах реализация других параметров.
|
|
||||||
|
|
||||||
## recovery_sync_batch
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 16
|
|
||||||
|
|
||||||
Максимальное число операций восстановления перед дополнительным fsync.
|
|
||||||
|
|
||||||
## readonly
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: false
|
|
||||||
|
|
||||||
Режим "только чтение". Если включить этот режим, OSD не будет писать ничего
|
|
||||||
на диск. Может быть полезно в целях восстановления.
|
|
||||||
|
|
||||||
## no_recovery
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: false
|
|
||||||
|
|
||||||
Отключить автоматическое фоновое восстановление объектов. Обратите внимание,
|
|
||||||
что эта опция не отключает восстановление объектов, происходящее при
|
|
||||||
записи - запись всегда производится в полный набор из как минимум pg_minsize
|
|
||||||
OSD.
|
|
||||||
|
|
||||||
## no_rebalance
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: false
|
|
||||||
|
|
||||||
Отключить фоновое перемещение объектов между разными OSD. Отключение
|
|
||||||
означает, что PG, находящиеся в состоянии `has_misplaced`, будут оставлены
|
|
||||||
в нём на неопределённый срок.
|
|
||||||
|
|
||||||
## print_stats_interval
|
|
||||||
|
|
||||||
- Тип: секунды
|
|
||||||
- Значение по умолчанию: 3
|
|
||||||
|
|
||||||
Временной интервал, с которым OSD печатают простую человекочитаемую
|
|
||||||
статистику выполнения операций в стандартный вывод.
|
|
||||||
|
|
||||||
## slow_log_interval
|
|
||||||
|
|
||||||
- Тип: секунды
|
|
||||||
- Значение по умолчанию: 10
|
|
||||||
|
|
||||||
Временной интервал, с которым OSD выводят в стандартный вывод список
|
|
||||||
медленных или зависших операций, если таковые имеются. Также время, при
|
|
||||||
превышении которого операция считается "медленной".
|
|
||||||
|
|
||||||
## max_write_iodepth
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 128
|
|
||||||
|
|
||||||
Максимальное число одновременных клиентских операций записи на один OSD.
|
|
||||||
Операции, превышающие этот лимит, не исполняются сразу, а сохраняются во
|
|
||||||
временной очереди.
|
|
||||||
|
|
||||||
## min_flusher_count
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 1
|
|
||||||
|
|
||||||
Flusher - это микро-поток (корутина), которая копирует данные из журнала в
|
|
||||||
основную область устройства данных. Их число настраивается динамически между
|
|
||||||
минимальным и максимальным значением. Этот параметр задаёт минимальное число.
|
|
||||||
|
|
||||||
## max_flusher_count
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 256
|
|
||||||
|
|
||||||
Максимальное число микро-потоков очистки журнала (см. выше min_flusher_count).
|
|
||||||
|
|
||||||
## inmemory_metadata
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: true
|
|
||||||
|
|
||||||
Данный параметр заставляет Vitastor всегда держать область метаданных диска
|
|
||||||
в памяти. Это нужно, чтобы избегать дополнительных операций чтения с диска
|
|
||||||
при записи. Размер области метаданных на данный момент составляет примерно
|
|
||||||
224 МБ на 1 ТБ данных. При включении потребление памяти снизится примерно
|
|
||||||
на эту величину, но при этом также снизится и производительность. В будущем,
|
|
||||||
после обновления схемы хранения метаданных, это ограничение, скорее всего,
|
|
||||||
будет ликвидировано.
|
|
||||||
|
|
||||||
## inmemory_journal
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: true
|
|
||||||
|
|
||||||
Данный параметр заставляет Vitastor всегда держать в памяти журналы OSD.
|
|
||||||
Отключение параметра, опять же, снижает потребление памяти, но ухудшает
|
|
||||||
производительность, так как для копирования данных из журнала в основную
|
|
||||||
область устройства OSD будут вынуждены читать их обратно с диска. Выигрыш
|
|
||||||
по памяти при этом обычно крайне низкий, так как для SSD OSD обычно
|
|
||||||
достаточно 16- или 32-мегабайтного журнала. Однако в теории отключение
|
|
||||||
параметра может оказаться полезным для гибридных OSD (HDD+SSD) с большими
|
|
||||||
журналами, расположенными на быстром по сравнению с HDD устройстве.
|
|
||||||
|
|
||||||
## journal_sector_buffer_count
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 32
|
|
||||||
|
|
||||||
Максимальное число буферов, разрешённых для использования под записываемые
|
|
||||||
в журнал блоки метаданных. Единственная ситуация, в которой этот параметр
|
|
||||||
нужно менять - это если вы включаете journal_no_same_sector_overwrites. В
|
|
||||||
этом случае установите данный параметр, например, в 1024.
|
|
||||||
|
|
||||||
## journal_no_same_sector_overwrites
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: false
|
|
||||||
|
|
||||||
Включайте данную опцию для SSD вроде Intel D3-S4510 и D3-S4610, которые
|
|
||||||
ОЧЕНЬ не любят, когда ПО перезаписывает один и тот же сектор несколько раз
|
|
||||||
подряд. Такие SSD при многократной перезаписи одного и того же сектора
|
|
||||||
сильно замедляются - условно, с 25000 и более iops до 3000 iops. Когда
|
|
||||||
данная опция установлена, Vitastor всегда переходит к следующему сектору
|
|
||||||
журнала после записи вместо потенциально повторной перезаписи того же
|
|
||||||
самого сектора.
|
|
||||||
|
|
||||||
Почти все другие SSD (99% моделей) не требуют данной опции.
|
|
||||||
|
|
||||||
## throttle_small_writes
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: false
|
|
||||||
|
|
||||||
Разрешить мягкое ограничение скорости журналируемой записи. Полезно для
|
|
||||||
гибридных OSD с быстрыми устройствами метаданных и медленными устройствами
|
|
||||||
данных. Идея заключается в том, что мелкие записи в этой ситуации могут
|
|
||||||
завершаться очень быстро, так как они изначально записываются на быстрое
|
|
||||||
журнальное устройство (SSD). Но перемещать их потом на основное медленное
|
|
||||||
устройство долго. Поэтому если OSD быстро примет от клиентов очень много
|
|
||||||
мелких операций записи, он быстро заполнит свой журнал, после чего
|
|
||||||
производительность записи резко упадёт практически до нуля. Ограничение
|
|
||||||
скорости записи призвано решить эту проблему с помощью искусственного
|
|
||||||
замедления операций записи на основании объёма свободного места в журнале.
|
|
||||||
Когда эта опция включена, производительность мелких операций записи будет
|
|
||||||
снижаться плавно, а не резко в момент окончательного заполнения журнала.
|
|
||||||
|
|
||||||
## throttle_target_iops
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 100
|
|
||||||
|
|
||||||
Расчётное максимальное число ограничиваемых операций в секунду при условии
|
|
||||||
отсутствия свободного места в журнале. Устанавливайте приблизительно равным
|
|
||||||
максимальной производительности случайной записи ваших устройств данных
|
|
||||||
(HDD) в операциях в секунду.
|
|
||||||
|
|
||||||
## throttle_target_mbs
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 100
|
|
||||||
|
|
||||||
Расчётный максимальный размер в МБ/с ограничиваемых операций в секунду при
|
|
||||||
условии отсутствия свободного места в журнале. Устанавливайте приблизительно
|
|
||||||
равным максимальной производительности линейной записи ваших устройств
|
|
||||||
данных (HDD).
|
|
||||||
|
|
||||||
## throttle_target_parallelism
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Значение по умолчанию: 1
|
|
||||||
|
|
||||||
Расчётный максимальный параллелизм ограничиваемых операций в секунду при
|
|
||||||
условии отсутствия свободного места в журнале. Устанавливайте приблизительно
|
|
||||||
равным внутреннему параллелизму ваших устройств данных (1 для HDD, 4-8
|
|
||||||
для SSD).
|
|
||||||
|
|
||||||
## throttle_threshold_us
|
|
||||||
|
|
||||||
- Тип: микросекунды
|
|
||||||
- Значение по умолчанию: 50
|
|
||||||
|
|
||||||
Минимальная применимая к ограничиваемым операциям задержка. Обычно не
|
|
||||||
требует изменений.
|
|
||||||
|
|
||||||
## osd_memlock
|
|
||||||
|
|
||||||
- Тип: булево (да/нет)
|
|
||||||
- Значение по умолчанию: false
|
|
||||||
|
|
||||||
Блокировать всю память OSD с помощью mlockall, чтобы запретить её выгрузку в пространство подкачки. Требует достаточного значения ulimit -l (лимита заблокированной памяти).
|
|
||||||
|
|
@ -1,254 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → [Configuration](../config.en.md) → Pool configuration
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](pool.ru.md)
|
|
||||||
|
|
||||||
# Pool configuration
|
|
||||||
|
|
||||||
Pool configuration is set in etcd key `/vitastor/config/pools` in the following
|
|
||||||
JSON format:
|
|
||||||
|
|
||||||
```
|
|
||||||
{
|
|
||||||
"<Numeric ID>": {
|
|
||||||
"name": "<name>",
|
|
||||||
...other parameters...
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
Pool configuration is also affected by:
|
|
||||||
|
|
||||||
- [OSD Placement Tree](#placement-tree)
|
|
||||||
- [Separate OSD settings](#osd-settings)
|
|
||||||
|
|
||||||
Parameters:
|
|
||||||
|
|
||||||
- [name](#name)
|
|
||||||
- [scheme](#scheme)
|
|
||||||
- [pg_size](#pg_size)
|
|
||||||
- [parity_chunks](#parity_chunks)
|
|
||||||
- [pg_minsize](#pg_minsize)
|
|
||||||
- [pg_count](#pg_count)
|
|
||||||
- [failure_domain](#failure_domain)
|
|
||||||
- [max_osd_combinations](#max_osd_combinations)
|
|
||||||
- [pg_stripe_size](#pg_stripe_size)
|
|
||||||
- [root_node](#root_node)
|
|
||||||
- [osd_tags](#osd_tags)
|
|
||||||
- [primary_affinity_tags](#primary_affinity_tags)
|
|
||||||
|
|
||||||
Examples:
|
|
||||||
|
|
||||||
- [Replicated Pool](#replicated-pool)
|
|
||||||
- [Erasure-coded Pool](#erasure-coded-pool)
|
|
||||||
|
|
||||||
# Placement Tree
|
|
||||||
|
|
||||||
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>",
|
|
||||||
"parent": "<parent node name, if any>"
|
|
||||||
},
|
|
||||||
...
|
|
||||||
}
|
|
||||||
`
|
|
||||||
|
|
||||||
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
|
|
||||||
override parent node of the OSD which is its host by default.
|
|
||||||
|
|
||||||
Non-numeric node names refer to other placement tree nodes like hosts, racks,
|
|
||||||
datacenters and so on.
|
|
||||||
|
|
||||||
Hosts of all OSDs are auto-created in the tree with level "host" and name
|
|
||||||
equal to the host name reported by a corresponding OSD. You can refer to them
|
|
||||||
without adding them to this JSON tree manually.
|
|
||||||
|
|
||||||
Level may be "host", "osd" or refer to some other placement tree level
|
|
||||||
from [placement_levels](monitor.en.md#placement_levels).
|
|
||||||
|
|
||||||
Parent node reference is required for intermediate tree nodes.
|
|
||||||
|
|
||||||
# OSD settings
|
|
||||||
|
|
||||||
Separate OSD settings are set in etc keys `/vitastor/config/osd/<number>`
|
|
||||||
in JSON format `{"<key>":<value>}`.
|
|
||||||
|
|
||||||
As of now, there is only one setting:
|
|
||||||
|
|
||||||
## reweight
|
|
||||||
|
|
||||||
- Type: number, between 0 and 1
|
|
||||||
- Default: 1
|
|
||||||
|
|
||||||
Every OSD receives PGs proportional to its size. Reweight is a multiplier for
|
|
||||||
OSD size used during PG distribution.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
# Pool parameters
|
|
||||||
|
|
||||||
## name
|
|
||||||
|
|
||||||
- Type: string
|
|
||||||
- Required
|
|
||||||
|
|
||||||
Pool name.
|
|
||||||
|
|
||||||
## scheme
|
|
||||||
|
|
||||||
- Type: string
|
|
||||||
- Required
|
|
||||||
- One of: "replicated", "xor" or "jerasure"
|
|
||||||
|
|
||||||
Redundancy scheme used for data in this pool.
|
|
||||||
|
|
||||||
## pg_size
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Required
|
|
||||||
|
|
||||||
Total number of disks for PGs of this pool - i.e., number of replicas for
|
|
||||||
replicated pools and number of data plus parity disks for EC/XOR pools.
|
|
||||||
|
|
||||||
## parity_chunks
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
|
|
||||||
Number of parity chunks for EC/XOR pools. For such pools, data will be lost
|
|
||||||
if you lose more than parity_chunks disks at once, so this parameter can be
|
|
||||||
equally described as FTT (number of failures to tolerate).
|
|
||||||
|
|
||||||
Required for EC/XOR pools, ignored for replicated pools.
|
|
||||||
|
|
||||||
## pg_minsize
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Required
|
|
||||||
|
|
||||||
Number of available live disks for PGs of this pool to remain active.
|
|
||||||
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).
|
|
||||||
|
|
||||||
FIXME: pg_minsize behaviour may be changed in the future to only make PGs
|
|
||||||
read-only instead of deactivating them.
|
|
||||||
|
|
||||||
## pg_count
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Required
|
|
||||||
|
|
||||||
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 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.
|
|
||||||
|
|
||||||
In Vitastor, PGs are ephemeral, so you can change pool PG count anytime just
|
|
||||||
by overwriting pool configuration in etcd. Amount of the data affected by
|
|
||||||
rebalance will be smaller if the new PG count is a multiple of the old PG count
|
|
||||||
or vice versa.
|
|
||||||
|
|
||||||
## failure_domain
|
|
||||||
|
|
||||||
- Type: string
|
|
||||||
- Default: host
|
|
||||||
|
|
||||||
Failure domain specification. Must be "host" or "osd" or refer to one of the
|
|
||||||
placement tree levels, defined in [placement_levels](monitor.en.md#placement_levels).
|
|
||||||
|
|
||||||
Two replicas, or two parts in case of EC/XOR, of the same block of data are
|
|
||||||
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.
|
|
||||||
|
|
||||||
## max_osd_combinations
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 10000
|
|
||||||
|
|
||||||
Vitastor data placement algorithm is based on the LP solver and OSD combinations
|
|
||||||
which are fed to it are generated ramdonly. This parameter specifies the maximum
|
|
||||||
number of combinations to generate when optimising PG placement.
|
|
||||||
|
|
||||||
This parameter usually doesn't require to be changed.
|
|
||||||
|
|
||||||
## pg_stripe_size
|
|
||||||
|
|
||||||
- Type: integer
|
|
||||||
- Default: 0
|
|
||||||
|
|
||||||
Specifies the stripe size for this pool according to which images are split into
|
|
||||||
different PGs. Stripe size can't be smaller than [block_size](layout-cluster.en.md#block_size)
|
|
||||||
multiplied by (pg_size - parity_chunks) for EC/XOR pools, or 1 for replicated pools,
|
|
||||||
and the same value is used by default.
|
|
||||||
|
|
||||||
This means first `pg_stripe_size = (block_size * (pg_size-parity_chunks))` bytes
|
|
||||||
of an image go to one PG, next `pg_stripe_size` bytes go to another PG and so on.
|
|
||||||
|
|
||||||
Usually doesn't require to be changed separately from the block size.
|
|
||||||
|
|
||||||
## root_node
|
|
||||||
|
|
||||||
- Type: string
|
|
||||||
|
|
||||||
Specifies the root node of the OSD tree to restrict this pool OSDs to.
|
|
||||||
Referenced root node must exist in /vitastor/config/node_placement.
|
|
||||||
|
|
||||||
## osd_tags
|
|
||||||
|
|
||||||
- Type: string or array of strings
|
|
||||||
|
|
||||||
Specifies OSD tags to restrict this pool to. If multiple tags are specified,
|
|
||||||
only OSDs having all of these tags will be used for this pool.
|
|
||||||
|
|
||||||
## primary_affinity_tags
|
|
||||||
|
|
||||||
- Type: string or array of strings
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
# Examples
|
|
||||||
|
|
||||||
## Replicated pool
|
|
||||||
|
|
||||||
```
|
|
||||||
{
|
|
||||||
"1": {
|
|
||||||
"name":"testpool",
|
|
||||||
"scheme":"replicated",
|
|
||||||
"pg_size":2,
|
|
||||||
"pg_minsize":1,
|
|
||||||
"pg_count":256,
|
|
||||||
"failure_domain":"host"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
## Erasure-coded pool
|
|
||||||
|
|
||||||
```
|
|
||||||
{
|
|
||||||
"2": {
|
|
||||||
"name":"ecpool",
|
|
||||||
"scheme":"jerasure",
|
|
||||||
"pg_size":3,
|
|
||||||
"parity_chunks":1,
|
|
||||||
"pg_minsize":2,
|
|
||||||
"pg_count":256,
|
|
||||||
"failure_domain":"host"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
@ -1,253 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → [Конфигурация](../config.ru.md) → Конфигурация пулов
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](pool.en.md)
|
|
||||||
|
|
||||||
# Конфигурация пулов
|
|
||||||
|
|
||||||
Настройки пулов задаются в ключе etcd `/vitastor/config/pools` в JSON-формате:
|
|
||||||
|
|
||||||
```
|
|
||||||
{
|
|
||||||
"<Численный ID>": {
|
|
||||||
"name": "<имя>",
|
|
||||||
...остальные параметры...
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
На настройку пулов также влияют:
|
|
||||||
|
|
||||||
- [Дерево размещения OSD](#дерево-размещения)
|
|
||||||
- [Настройки отдельных OSD](#настройки-osd)
|
|
||||||
|
|
||||||
Параметры:
|
|
||||||
|
|
||||||
- [name](#name)
|
|
||||||
- [scheme](#scheme)
|
|
||||||
- [pg_size](#pg_size)
|
|
||||||
- [parity_chunks](#parity_chunks)
|
|
||||||
- [pg_minsize](#pg_minsize)
|
|
||||||
- [pg_count](#pg_count)
|
|
||||||
- [failure_domain](#failure_domain)
|
|
||||||
- [max_osd_combinations](#max_osd_combinations)
|
|
||||||
- [pg_stripe_size](#pg_stripe_size)
|
|
||||||
- [root_node](#root_node)
|
|
||||||
- [osd_tags](#osd_tags)
|
|
||||||
- [primary_affinity_tags](#primary_affinity_tags)
|
|
||||||
|
|
||||||
Примеры:
|
|
||||||
|
|
||||||
- [Реплицированный пул](#реплицированный-пул)
|
|
||||||
- [Пул с кодами коррекции ошибок 2+1](#пул-с-кодами-коррекции-ошибок)
|
|
||||||
|
|
||||||
# Дерево размещения
|
|
||||||
|
|
||||||
Дерево размещения OSD задаётся в отдельном ключе etcd `/vitastor/config/node_placement`
|
|
||||||
в следующем JSON-формате:
|
|
||||||
|
|
||||||
`
|
|
||||||
{
|
|
||||||
"<имя узла или номер OSD>": {
|
|
||||||
"level": "<уровень>",
|
|
||||||
"parent": "<имя родительского узла, если есть>"
|
|
||||||
},
|
|
||||||
...
|
|
||||||
}
|
|
||||||
`
|
|
||||||
|
|
||||||
Здесь, если название узла - число, считается, что это OSD. Уровень OSD
|
|
||||||
всегда равен "osd" и не может быть переопределён. Для OSD вы можете только
|
|
||||||
переопределить родительский узел. По умолчанию родителем OSD считается его хост.
|
|
||||||
|
|
||||||
Нечисловые имена узлов относятся к другим узлам дерева OSD, таким, как хосты (серверы),
|
|
||||||
стойки, датацентры и так далее.
|
|
||||||
|
|
||||||
Хосты всех OSD автоматически создаются в дереве с уровнем "host" и именем, равным имени хоста,
|
|
||||||
сообщаемым соответствующим OSD. Вы можете ссылаться на эти хосты, не заводя их
|
|
||||||
в дереве вручную.
|
|
||||||
|
|
||||||
Уровень может быть "host", "osd" или относиться к другому уровню размещения из
|
|
||||||
[placement_levels](monitor.ru.md#placement_levels).
|
|
||||||
|
|
||||||
Родительский узел нужен только для промежуточных узлов дерева.
|
|
||||||
|
|
||||||
# Настройки OSD
|
|
||||||
|
|
||||||
Настройки отдельных OSD задаются в ключах etcd `/vitastor/config/osd/<number>`
|
|
||||||
в JSON-формате `{"<key>":<value>}`.
|
|
||||||
|
|
||||||
На данный момент поддерживается одна настройка:
|
|
||||||
|
|
||||||
## reweight
|
|
||||||
|
|
||||||
- Тип: число, от 0 до 1
|
|
||||||
- По умолчанию: 1
|
|
||||||
|
|
||||||
Каждый OSD получает число PG, пропорциональное его размеру. Reweight - это
|
|
||||||
множитель для размера, используемый в процессе распределения PG.
|
|
||||||
|
|
||||||
Это значит, что OSD, сконфигурированный с reweight меньше 1 будет получать
|
|
||||||
меньше PG, чем обычно. OSD с reweight, равным 0, не будет участвовать в
|
|
||||||
хранении данных вообще. Вы можете установить reweight в 0, чтобы убрать
|
|
||||||
все данные с OSD.
|
|
||||||
|
|
||||||
# Параметры
|
|
||||||
|
|
||||||
## name
|
|
||||||
|
|
||||||
- Тип: строка
|
|
||||||
- Обязательный
|
|
||||||
|
|
||||||
Название пула.
|
|
||||||
|
|
||||||
## scheme
|
|
||||||
|
|
||||||
- Тип: строка
|
|
||||||
- Обязательный
|
|
||||||
- Возможные значения: "replicated", "xor" или "jerasure"
|
|
||||||
|
|
||||||
Схема избыточности, используемая в данном пуле.
|
|
||||||
|
|
||||||
## pg_size
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Обязательный
|
|
||||||
|
|
||||||
Размер PG данного пула, т.е. число реплик для реплицированных пулов или
|
|
||||||
число дисков данных плюс дисков чётности для пулов EC/XOR.
|
|
||||||
|
|
||||||
## parity_chunks
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
|
|
||||||
Число дисков чётности для EC/XOR пулов. Иными словами, число дисков, при
|
|
||||||
одновременной потере которых данные будут потеряны.
|
|
||||||
|
|
||||||
Игнорируется для реплицированных пулов, обязательно для EC/XOR.
|
|
||||||
|
|
||||||
## pg_minsize
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Обязательный
|
|
||||||
|
|
||||||
Число доступных дисков для PG данного пула, при котором PG остаются активны.
|
|
||||||
Если становится невозможно размещать новые данные в PG как минимум на pg_minsize
|
|
||||||
OSD, PG деактивируется на чтение и запись. Иными словами, всегда известно,
|
|
||||||
что новые блоки данных всегда записываются как минимум на pg_minsize дисков.
|
|
||||||
|
|
||||||
FIXME: Поведение pg_minsize может быть изменено в будущем с полной деактивации
|
|
||||||
PG на перевод их в режим только для чтения.
|
|
||||||
|
|
||||||
## pg_count
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- Обязательный
|
|
||||||
|
|
||||||
Число PG для данного пула. Число должно быть достаточно большим, чтобы монитор
|
|
||||||
мог равномерно распределить по ним данные.
|
|
||||||
|
|
||||||
Обычно это означает примерно 64-128 PG на 1 OSD, т.е. pg_count можно устанавливать
|
|
||||||
равным (общему числу OSD * 100 / pg_size). Значение можно округлить до ближайшей
|
|
||||||
степени 2, чтобы потом было легче уменьшать или увеличивать число PG, умножая
|
|
||||||
или деля его на 2.
|
|
||||||
|
|
||||||
PG в Vitastor эферемерны, то есть вы можете менять их число в любой момент,
|
|
||||||
просто перезаписывая конфигурацию пулов в etcd. Однако объём перемещения данных
|
|
||||||
при этом будет минимален, если новое число PG кратно старому (или наоборот).
|
|
||||||
|
|
||||||
## failure_domain
|
|
||||||
|
|
||||||
- Тип: строка
|
|
||||||
- По умолчанию: host
|
|
||||||
|
|
||||||
Домен отказа для пула. Может быть равен "host" или "osd" или любому другому
|
|
||||||
уровню дерева OSD, задаваемому в настройке [placement_levels](monitor.ru.md#placement_levels).
|
|
||||||
|
|
||||||
Смысл домена отказа в том, что 2 копии, или 2 части одного блока данных в случае
|
|
||||||
кодов коррекции ошибок, никогда не помещаются на OSD, принадлежащие одному домену отказа.
|
|
||||||
Иными словами, домен отказа - это то, от отказа чего вы защищаете себя избыточным
|
|
||||||
хранением.
|
|
||||||
|
|
||||||
## max_osd_combinations
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- По умолчанию: 10000
|
|
||||||
|
|
||||||
Алгоритм распределения данных Vitastor основан на решателе задачи линейного
|
|
||||||
программирования. При этом для снижения сложности задачи возможные комбинации OSD
|
|
||||||
генерируются случайно и ограничиваются количеством, равным значению этого параметра.
|
|
||||||
|
|
||||||
Обычно данный параметр не требует изменений.
|
|
||||||
|
|
||||||
## pg_stripe_size
|
|
||||||
|
|
||||||
- Тип: целое число
|
|
||||||
- По умолчанию: 0
|
|
||||||
|
|
||||||
Данный параметр задаёт размер полосы "нарезки" образов на PG. Размер полосы не может
|
|
||||||
быть меньше, чем [block_size](layout-cluster.ru.md#block_size), умноженный на
|
|
||||||
(pg_size - parity_chunks) для EC-пулов или 1 для реплицированных пулов. То же
|
|
||||||
значение используется по умолчанию.
|
|
||||||
|
|
||||||
Это означает, что по умолчанию первые `pg_stripe_size = (block_size * (pg_size-parity_chunks))` байт
|
|
||||||
образа помещаются в одну PG, следующие `pg_stripe_size` байт помещаются в другую
|
|
||||||
и т.п.
|
|
||||||
|
|
||||||
Данный параметр обычно тоже не требует изменений.
|
|
||||||
|
|
||||||
## root_node
|
|
||||||
|
|
||||||
- Тип: строка
|
|
||||||
|
|
||||||
Корневой узел дерева OSD для ограничения OSD, выбираемых для пула. Задаваемый
|
|
||||||
узел должен быть предварительно задан в /vitastor/config/node_placement.
|
|
||||||
|
|
||||||
## osd_tags
|
|
||||||
|
|
||||||
- Тип: строка или массив строк
|
|
||||||
|
|
||||||
Теги OSD для ограничения OSD, выбираемых для пула. Если задаётся несколько тегов
|
|
||||||
массивом, то выбираются только OSD, у которых есть все эти теги.
|
|
||||||
|
|
||||||
## primary_affinity_tags
|
|
||||||
|
|
||||||
- Тип: строка или массив строк
|
|
||||||
|
|
||||||
Теги OSD, по которым должны выбираться OSD, предпочитаемые в качестве первичных
|
|
||||||
для PG этого пула. Имейте в виду, что для EC-пулов Vitastor также всегда
|
|
||||||
предпочитает помещать первичный OSD на один из OSD с данными, а не с чётностью.
|
|
||||||
|
|
||||||
# Примеры
|
|
||||||
|
|
||||||
## Реплицированный пул
|
|
||||||
|
|
||||||
```
|
|
||||||
{
|
|
||||||
"1": {
|
|
||||||
"name":"testpool",
|
|
||||||
"scheme":"replicated",
|
|
||||||
"pg_size":2,
|
|
||||||
"pg_minsize":1,
|
|
||||||
"pg_count":256,
|
|
||||||
"failure_domain":"host"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
## Пул с кодами коррекции ошибок
|
|
||||||
|
|
||||||
```
|
|
||||||
{
|
|
||||||
"2": {
|
|
||||||
"name":"ecpool",
|
|
||||||
"scheme":"jerasure",
|
|
||||||
"pg_size":3,
|
|
||||||
"parity_chunks":1,
|
|
||||||
"pg_minsize":2,
|
|
||||||
"pg_count":256,
|
|
||||||
"failure_domain":"host"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
@ -1,3 +0,0 @@
|
||||||
# Common Parameters
|
|
||||||
|
|
||||||
These are the most common parameters which apply to all components of Vitastor.
|
|
||||||
|
|
@ -1,3 +0,0 @@
|
||||||
# Общие параметры
|
|
||||||
|
|
||||||
Это наиболее общие параметры, используемые всеми компонентами Vitastor.
|
|
||||||
|
|
@ -1,35 +0,0 @@
|
||||||
- name: config_path
|
|
||||||
type: string
|
|
||||||
default: "/etc/vitastor/vitastor.conf"
|
|
||||||
info: |
|
|
||||||
Path to the JSON configuration file. Configuration file is optional,
|
|
||||||
a non-existing configuration file does not prevent Vitastor from
|
|
||||||
running if required parameters are specified.
|
|
||||||
info_ru: |
|
|
||||||
Путь к файлу конфигурации в формате JSON. Файл конфигурации необязателен,
|
|
||||||
без него Vitastor тоже будет работать, если переданы необходимые параметры.
|
|
||||||
- name: etcd_address
|
|
||||||
type: string or array of strings
|
|
||||||
type_ru: строка или массив строк
|
|
||||||
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.
|
|
||||||
info_ru: |
|
|
||||||
Адрес(а) подключения к etcd. Несколько адресов могут разделяться запятой
|
|
||||||
или указываться в виде JSON-массива `["10.0.115.10:2379/v3","10.0.115.11:2379/v3"]`.
|
|
||||||
- name: etcd_prefix
|
|
||||||
type: string
|
|
||||||
default: "/vitastor"
|
|
||||||
info: |
|
|
||||||
Prefix for all keys in etcd used by Vitastor. You can change prefix and, for
|
|
||||||
example, use a single etcd cluster for multiple Vitastor clusters.
|
|
||||||
info_ru: |
|
|
||||||
Префикс для ключей etcd, которые использует Vitastor. Вы можете задать другой
|
|
||||||
префикс, например, чтобы запустить несколько кластеров Vitastor с одним
|
|
||||||
кластером etcd.
|
|
||||||
- name: log_level
|
|
||||||
type: int
|
|
||||||
default: 0
|
|
||||||
info: Log level. Raise if you want more verbose output.
|
|
||||||
info_ru: Уровень логгирования. Повысьте, если хотите более подробный вывод.
|
|
||||||
|
|
@ -1,4 +0,0 @@
|
||||||
# Cluster-Wide Disk Layout Parameters
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
@ -1,4 +0,0 @@
|
||||||
# Дисковые параметры уровня кластера
|
|
||||||
|
|
||||||
Данные параметры используются клиентами и OSD, задаются в момент инициализации
|
|
||||||
диска OSD и не могут быть изменены после этого без потери данных.
|
|
||||||
|
|
@ -1,200 +0,0 @@
|
||||||
- name: block_size
|
|
||||||
type: int
|
|
||||||
default: 131072
|
|
||||||
info: |
|
|
||||||
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 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.
|
|
||||||
info_ru: |
|
|
||||||
Размер объектов (блоков данных), на которые делятся физические и виртуальные
|
|
||||||
диски в Vitastor. Одна из ключевых на данный момент настроек, влияет на
|
|
||||||
потребление памяти, объём избыточной записи (write amplification) и
|
|
||||||
эффективность распределения нагрузки по OSD.
|
|
||||||
|
|
||||||
Рекомендуемые по умолчанию размеры блока - 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 КБ блоке.
|
|
||||||
- name: bitmap_granularity
|
|
||||||
type: int
|
|
||||||
default: 4096
|
|
||||||
info: |
|
|
||||||
Required virtual disk write alignment ("sector size"). Must be a multiple
|
|
||||||
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.
|
|
||||||
|
|
||||||
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 без потери данных.
|
|
||||||
Также он фиксирован для всего кластера Vitastor, т.е. разные значения
|
|
||||||
не могут сосуществовать в одном кластере.
|
|
||||||
|
|
||||||
Клиенты ДОЛЖНЫ знать правильное значение этого параметра, так что если вы
|
|
||||||
его меняете, обязательно прописывайте изменённое значение в etcd в ключ
|
|
||||||
/vitastor/config/global.
|
|
||||||
- name: immediate_commit
|
|
||||||
type: string
|
|
||||||
default: false
|
|
||||||
info: |
|
|
||||||
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, 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
|
|
||||||
fast with and without fsync because their cache is protected from sudden
|
|
||||||
power loss by a built-in supercapacitor-based "UPS".
|
|
||||||
|
|
||||||
Some software-defined storage systems always fsync each write and thus are
|
|
||||||
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" 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
|
|
||||||
supercapacitors even with Vitastor, especially given that they cost only
|
|
||||||
a bit more than desktop models.
|
|
||||||
|
|
||||||
There is also a common SATA SSD (and HDD too!) firmware bug (or feature)
|
|
||||||
that makes server SSDs which have supercapacitors slow with fsync. To check
|
|
||||||
if your SSDs are affected, compare benchmark results from `fio -name=test
|
|
||||||
-ioengine=libaio -direct=1 -bs=4k -rw=randwrite -iodepth=1` with and without
|
|
||||||
`-fsync=1`. Results should be the same. If fsync=1 result is worse you can
|
|
||||||
try to work around this bug by "disabling" drive write-back cache by running
|
|
||||||
`hdparm -W 0 /dev/sdXX` or `echo write through > /sys/block/sdXX/device/scsi_disk/*/cache_type`
|
|
||||||
(IMPORTANT: don't mistake it with `/sys/block/sdXX/queue/write_cache` - it's
|
|
||||||
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).
|
|
||||||
|
|
||||||
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: |
|
|
||||||
Ещё один важный для производительности параметр.
|
|
||||||
|
|
||||||
Модели SSD для настольных компьютеров очень быстрые (100000+ операций в
|
|
||||||
секунду) при простой случайной записи без сбросов кэша. Однако они очень
|
|
||||||
медленные (всего порядка 1000 iops), если вы пытаетесь сбрасывать кэш после
|
|
||||||
каждой записи, то есть, если вы пытаетесь гарантировать, что каждое
|
|
||||||
изменение физически записывается в энергонезависимую память.
|
|
||||||
|
|
||||||
С другой стороны, серверные SSD с конденсаторами - функцией, называемой
|
|
||||||
"Advanced/Enhanced Power Loss Protection" или просто "Supercapacitor-based
|
|
||||||
Power Loss Protection" - одинаково быстрые и со сбросом кэша, и без
|
|
||||||
него, потому что их кэш защищён от потери питания встроенным "источником
|
|
||||||
бесперебойного питания" на основе суперконденсаторов и на самом деле они
|
|
||||||
его никогда не сбрасывают.
|
|
||||||
|
|
||||||
Некоторые программные СХД всегда сбрасывают кэши дисков при каждой записи
|
|
||||||
и поэтому работают очень медленно с настольными SSD. Vitastor, однако, может
|
|
||||||
откладывать fsync до явного его вызова со стороны клиента и таким образом
|
|
||||||
эффективно утилизировать настольные SSD.
|
|
||||||
|
|
||||||
Данный параметр влияет как раз на это. Когда он установлен в значение "all",
|
|
||||||
весь кластер Vitastor мгновенно фиксирует каждое изменение на физические
|
|
||||||
носители и клиенты могут просто игнорировать запросы fsync, т.к. они точно
|
|
||||||
знают, что fsync-и не нужны. Это уменьшает число необходимых обращений к OSD
|
|
||||||
по сети и улучшает производительность. Поэтому даже с Vitastor лучше всегда
|
|
||||||
использовать только серверные модели SSD с суперконденсаторами, особенно
|
|
||||||
учитывая то, что стоят они ненамного дороже настольных.
|
|
||||||
|
|
||||||
Также в прошивках SATA SSD (и даже HDD!) очень часто встречается либо баг,
|
|
||||||
либо просто особенность логики, из-за которой серверные SSD, имеющие
|
|
||||||
конденсаторы и защиту от потери питания, всё равно медленно работают с
|
|
||||||
fsync. Чтобы понять, подвержены ли этой проблеме ваши SSD, сравните
|
|
||||||
результаты тестов `fio -name=test -ioengine=libaio -direct=1 -bs=4k
|
|
||||||
-rw=randwrite -iodepth=1` без и с опцией `-fsync=1`. Результаты должны
|
|
||||||
быть одинаковые. Если результат с `fsync=1` хуже, вы можете попробовать
|
|
||||||
обойти проблему, "отключив" кэш записи диска командой `hdparm -W 0 /dev/sdXX`
|
|
||||||
либо `echo write through > /sys/block/sdXX/device/scsi_disk/*/cache_type`
|
|
||||||
(ВАЖНО: не перепутайте с `/sys/block/sdXX/queue/write_cache` - этот параметр
|
|
||||||
менять руками небезопасно). Такая же проблема может встречаться и в новых
|
|
||||||
HDD-дисках с внутренним SSD или "медиа" кэшем - например, она встречается во
|
|
||||||
многих дисках Seagate EXOS (у них есть внутренний SSD-кэш, хотя это и не
|
|
||||||
указано в спецификациях).
|
|
||||||
|
|
||||||
Данный параметр нужно указывать и в 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.
|
|
||||||
|
|
@ -1,4 +0,0 @@
|
||||||
# OSD Disk Layout Parameters
|
|
||||||
|
|
||||||
These parameters apply to OSDs, are fixed at the moment of OSD drive
|
|
||||||
initialization and can't be changed after it without losing data.
|
|
||||||
|
|
@ -1,5 +0,0 @@
|
||||||
# Дисковые параметры OSD
|
|
||||||
|
|
||||||
Данные параметры используются только OSD и, также как и общекластерные
|
|
||||||
дисковые параметры, задаются в момент инициализации дисков OSD и не могут быть
|
|
||||||
изменены после этого без потери данных.
|
|
||||||
|
|
@ -1,206 +0,0 @@
|
||||||
- name: data_device
|
|
||||||
type: string
|
|
||||||
info: |
|
|
||||||
Path to the block device to use for data. It's highly recommendded to use
|
|
||||||
stable paths for all device names: `/dev/disk/by-partuuid/xxx...` instead
|
|
||||||
of just `/dev/sda` or `/dev/nvme0n1` to not mess up after server restart.
|
|
||||||
Files can also be used instead of block devices, but this is implemented
|
|
||||||
only for testing purposes and not for production.
|
|
||||||
info_ru: |
|
|
||||||
Путь к диску (блочному устройству) для хранения данных. Крайне рекомендуется
|
|
||||||
использовать стабильные пути: `/dev/disk/by-partuuid/xxx...` вместо простых
|
|
||||||
`/dev/sda` или `/dev/nvme0n1`, чтобы пути не могли спутаться после
|
|
||||||
перезагрузки сервера. Также вместо блочных устройств можно указывать файлы,
|
|
||||||
но это реализовано только для тестирования, а не для боевой среды.
|
|
||||||
- name: meta_device
|
|
||||||
type: string
|
|
||||||
info: |
|
|
||||||
Path to the block device to use for the metadata. Metadata must be on a fast
|
|
||||||
SSD or performance will suffer. If this option is skipped, `data_device` is
|
|
||||||
used for the metadata.
|
|
||||||
info_ru: |
|
|
||||||
Путь к диску метаданных. Метаданные должны располагаться на быстром
|
|
||||||
SSD-диске, иначе производительность пострадает. Если эта опция не указана,
|
|
||||||
для метаданных используется `data_device`.
|
|
||||||
- name: journal_device
|
|
||||||
type: string
|
|
||||||
info: |
|
|
||||||
Path to the block device to use for the journal. Journal must be on a fast
|
|
||||||
SSD or performance will suffer. If this option is skipped, `meta_device` is
|
|
||||||
used for the journal, and if it's also empty, journal is put on
|
|
||||||
`data_device`. It's almost always fine to put metadata and journal on the
|
|
||||||
same device, in this case you only need to set `meta_device`.
|
|
||||||
info_ru: |
|
|
||||||
Путь к диску журнала. Журнал должен располагаться на быстром SSD-диске,
|
|
||||||
иначе производительность пострадает. Если эта опция не указана,
|
|
||||||
для журнала используется `meta_device`, если же пуста и она, журнал
|
|
||||||
располагается на `data_device`. Нормально располагать журнал и метаданные
|
|
||||||
на одном устройстве, в этом случае достаточно указать только `meta_device`.
|
|
||||||
- name: journal_offset
|
|
||||||
type: int
|
|
||||||
default: 0
|
|
||||||
info: Offset on the device in bytes where the journal is stored.
|
|
||||||
info_ru: Смещение на устройстве в байтах, по которому располагается журнал.
|
|
||||||
- name: journal_size
|
|
||||||
type: int
|
|
||||||
info: |
|
|
||||||
Journal size in bytes. By default, all available space between journal_offset
|
|
||||||
and data_offset, meta_offset or the end of the journal device is used.
|
|
||||||
Large journals aren't needed in SSD-only setups, 32 MB is always enough.
|
|
||||||
In SSD+HDD setups it is beneficial to use larger journals (for example, 1 GB)
|
|
||||||
and enable [throttle_small_writes](osd.en.md#throttle_small_writes).
|
|
||||||
info_ru: |
|
|
||||||
Размер журнала в байтах. По умолчанию для журнала используется всё доступное
|
|
||||||
место между journal_offset и data_offset, meta_offset или концом диска.
|
|
||||||
В SSD-кластерах большие журналы не нужны, достаточно 32 МБ. В гибридных
|
|
||||||
(SSD+HDD) кластерах осмысленно использовать больший размер журнал (например, 1 ГБ)
|
|
||||||
и включить [throttle_small_writes](osd.ru.md#throttle_small_writes).
|
|
||||||
- name: meta_offset
|
|
||||||
type: int
|
|
||||||
default: 0
|
|
||||||
info: |
|
|
||||||
Offset on the device in bytes where the metadata area is stored.
|
|
||||||
Again, set it to something if you colocate metadata with journal or data.
|
|
||||||
info_ru: |
|
|
||||||
Смещение на устройстве в байтах, по которому располагаются метаданные.
|
|
||||||
Эту опцию нужно задать, если метаданные у вас хранятся на том же
|
|
||||||
устройстве, что данные или журнал.
|
|
||||||
- name: data_offset
|
|
||||||
type: int
|
|
||||||
default: 0
|
|
||||||
info: |
|
|
||||||
Offset on the device in bytes where the data area is stored.
|
|
||||||
Again, set it to something if you colocate data with journal or metadata.
|
|
||||||
info_ru: |
|
|
||||||
Смещение на устройстве в байтах, по которому располагаются данные.
|
|
||||||
Эту опцию нужно задать, если данные у вас хранятся на том же
|
|
||||||
устройстве, что метаданные или журнал.
|
|
||||||
- name: data_size
|
|
||||||
type: int
|
|
||||||
info: |
|
|
||||||
Data area size in bytes. By default, the whole data device up to the end
|
|
||||||
will be used for the data area, but you can restrict it if you want to use
|
|
||||||
a smaller part. Note that there is no option to set metadata area size -
|
|
||||||
it's derived from the data area size.
|
|
||||||
info_ru: |
|
|
||||||
Размер области данных в байтах. По умолчанию под данные будет использована
|
|
||||||
вся доступная область устройства данных до конца устройства, но вы можете
|
|
||||||
использовать эту опцию, чтобы ограничить её меньшим размером. Заметьте, что
|
|
||||||
опции размера области метаданных нет - она вычисляется из размера области
|
|
||||||
данных автоматически.
|
|
||||||
- name: meta_block_size
|
|
||||||
type: int
|
|
||||||
default: 4096
|
|
||||||
info: |
|
|
||||||
Physical block size of the metadata device. 4096 for most current
|
|
||||||
HDDs and SSDs.
|
|
||||||
info_ru: |
|
|
||||||
Размер физического блока устройства метаданных. 4096 для большинства
|
|
||||||
современных SSD и HDD.
|
|
||||||
- name: journal_block_size
|
|
||||||
type: int
|
|
||||||
default: 4096
|
|
||||||
info: |
|
|
||||||
Physical block size of the journal device. Must be a multiple of
|
|
||||||
`disk_alignment`. 4096 for most current HDDs and SSDs.
|
|
||||||
info_ru: |
|
|
||||||
Размер физического блока устройства журнала. Должен быть кратен
|
|
||||||
`disk_alignment`. 4096 для большинства современных SSD и HDD.
|
|
||||||
- name: disable_data_fsync
|
|
||||||
type: bool
|
|
||||||
default: false
|
|
||||||
info: |
|
|
||||||
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-и устройству данных, т.е. не сбрасывать его кэш.
|
|
||||||
Безопасно, ТОЛЬКО если ваше устройство данных имеет кэш со сквозной
|
|
||||||
записью (write-through). Если вы отключаете кэш через `hdparm` или
|
|
||||||
`scsi_disk/cache_type`, то удостоверьтесь, что команда отключения кэша
|
|
||||||
выполняется перед каждым запуском Vitastor OSD, например, в systemd unit-е.
|
|
||||||
Смотрите также опцию `immediate_commit` для инструкций по отключению кэша
|
|
||||||
и о том, как из этого извлечь выгоду.
|
|
||||||
- name: disable_meta_fsync
|
|
||||||
type: bool
|
|
||||||
default: false
|
|
||||||
info: |
|
|
||||||
Same as disable_data_fsync, but for the metadata device. If the metadata
|
|
||||||
device is not set or if the data device is used for the metadata the option
|
|
||||||
is ignored and disable_data_fsync value is used instead of it.
|
|
||||||
info_ru: |
|
|
||||||
То же, что disable_data_fsync, но для устройства метаданных. Если устройство
|
|
||||||
метаданных не задано или если оно равно устройству данных, значение опции
|
|
||||||
игнорируется и вместо него используется значение опции disable_data_fsync.
|
|
||||||
- name: disable_journal_fsync
|
|
||||||
type: bool
|
|
||||||
default: false
|
|
||||||
info: |
|
|
||||||
Same as disable_data_fsync, but for the journal device. If the journal
|
|
||||||
device is not set or if the metadata device is used for the journal the
|
|
||||||
option is ignored and disable_meta_fsync value is used instead of it. If
|
|
||||||
the same device is used for data, metadata and journal the option is also
|
|
||||||
ignored and disable_data_fsync value is used instead of it.
|
|
||||||
info_ru: |
|
|
||||||
То же, что disable_data_fsync, но для устройства журнала. Если устройство
|
|
||||||
журнала не задано или если оно равно устройству метаданных, значение опции
|
|
||||||
игнорируется и вместо него используется значение опции disable_meta_fsync.
|
|
||||||
Если одно и то же устройство используется и под данные, и под журнал, и под
|
|
||||||
метаданные - значение опции также игнорируется и вместо него используется
|
|
||||||
значение опции disable_data_fsync.
|
|
||||||
- name: disable_device_lock
|
|
||||||
type: bool
|
|
||||||
default: false
|
|
||||||
info: |
|
|
||||||
Do not lock data, metadata and journal block devices exclusively with
|
|
||||||
flock(). Though it's not recommended, but you can use it you want to run
|
|
||||||
multiple OSD with a single device and different offsets, without using
|
|
||||||
partitions.
|
|
||||||
info_ru: |
|
|
||||||
Не блокировать устройства данных, метаданных и журнала от открытия их
|
|
||||||
другими OSD с помощью flock(). Так делать не рекомендуется, но теоретически
|
|
||||||
вы можете это использовать, чтобы запускать несколько OSD на одном
|
|
||||||
устройстве с разными смещениями и без использования разделов.
|
|
||||||
- name: disk_alignment
|
|
||||||
type: int
|
|
||||||
default: 4096
|
|
||||||
info: |
|
|
||||||
Required physical disk write alignment. Most current SSD and HDD drives
|
|
||||||
use 4 KB physical sectors even if they report 512 byte logical sector
|
|
||||||
size, so 4 KB is a good default setting.
|
|
||||||
|
|
||||||
Note, however, that physical sector size also affects WA, because with block
|
|
||||||
devices it's impossible to write anything smaller than a block. So, when
|
|
||||||
Vitastor has to write a single metadata entry that's only about 32 bytes in
|
|
||||||
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 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.
|
|
||||||
info_ru: |
|
|
||||||
Требуемое выравнивание записи на физические диски. Почти все современные
|
|
||||||
SSD и HDD диски используют 4 КБ физические секторы, даже если показывают
|
|
||||||
логический размер сектора 512 байт, поэтому 4 КБ - хорошее значение по
|
|
||||||
умолчанию.
|
|
||||||
|
|
||||||
Однако стоит понимать, что физический размер сектора тоже влияет на
|
|
||||||
избыточную запись (WA), потому что ничего меньше блока (сектора) на блочное
|
|
||||||
устройство записать невозможно. Таким образом, когда Vitastor-у нужно
|
|
||||||
записать на диск всего лишь одну 32-байтную запись метаданных, фактически
|
|
||||||
приходится перезаписывать 4 КБ сектор целиком.
|
|
||||||
|
|
||||||
Поэтому, на самом деле, может быть выгодно найти SSD, хорошо работающие с
|
|
||||||
меньшими, 512-байтными, блоками и использовать 512-байтные disk_alignment,
|
|
||||||
journal_block_size и meta_block_size. Однако единственные SSD, которые
|
|
||||||
теоретически могут попасть в эту категорию - это Intel Optane (но и это
|
|
||||||
пока не проверялось автором).
|
|
||||||
|
|
||||||
Клиентам не обязательно знать про disk_alignment, так что помещать значение
|
|
||||||
этого параметра в etcd в /vitastor/config/global не нужно.
|
|
||||||
|
|
@ -1,120 +0,0 @@
|
||||||
#!/usr/bin/nodejs
|
|
||||||
|
|
||||||
const fs = require('fs');
|
|
||||||
const yaml = require('yaml');
|
|
||||||
|
|
||||||
const L = {
|
|
||||||
en: {
|
|
||||||
Documentation: 'Documentation',
|
|
||||||
Configuration: 'Configuration',
|
|
||||||
Crossref: 'Read in English',
|
|
||||||
toc_root: '[Documentation](../README.md#documentation)',
|
|
||||||
toc_intro: 'Introduction',
|
|
||||||
toc_installation: 'Installation',
|
|
||||||
toc_config: '[Configuration](../config.en.md)',
|
|
||||||
toc_usage: 'Usage',
|
|
||||||
toc_performance: 'Performance',
|
|
||||||
},
|
|
||||||
ru: {
|
|
||||||
Documentation: 'Документация',
|
|
||||||
Configuration: 'Конфигурация',
|
|
||||||
Type: 'Тип',
|
|
||||||
Default: 'Значение по умолчанию',
|
|
||||||
Minimum: 'Минимальное значение',
|
|
||||||
Crossref: 'Читать на русском',
|
|
||||||
toc_root: '[Документация](../README-ru.md#документация)',
|
|
||||||
toc_intro: 'Введение',
|
|
||||||
toc_installation: 'Установка',
|
|
||||||
toc_config: '[Конфигурация](../config.ru.md)',
|
|
||||||
toc_usage: 'Использование',
|
|
||||||
toc_performance: 'Производительность',
|
|
||||||
},
|
|
||||||
};
|
|
||||||
const types = {
|
|
||||||
en: {
|
|
||||||
string: 'string',
|
|
||||||
bool: 'boolean',
|
|
||||||
int: 'integer',
|
|
||||||
sec: 'seconds',
|
|
||||||
ms: 'milliseconds',
|
|
||||||
us: 'microseconds',
|
|
||||||
},
|
|
||||||
ru: {
|
|
||||||
string: 'строка',
|
|
||||||
bool: 'булево (да/нет)',
|
|
||||||
int: 'целое число',
|
|
||||||
sec: 'секунды',
|
|
||||||
ms: 'миллисекунды',
|
|
||||||
us: 'микросекунды',
|
|
||||||
},
|
|
||||||
};
|
|
||||||
const params_files = fs.readdirSync(__dirname)
|
|
||||||
.filter(f => f.substr(-4) == '.yml')
|
|
||||||
.map(f => f.substr(0, f.length-4));
|
|
||||||
|
|
||||||
for (const file of params_files)
|
|
||||||
{
|
|
||||||
const cfg = yaml.parse(fs.readFileSync(__dirname+'/'+file+'.yml', { encoding: 'utf-8' }));
|
|
||||||
for (const lang in types)
|
|
||||||
{
|
|
||||||
let out = '\n';
|
|
||||||
for (const c of cfg)
|
|
||||||
{
|
|
||||||
out += `\n- [${c.name}](#${c.name})`;
|
|
||||||
}
|
|
||||||
for (const c of cfg)
|
|
||||||
{
|
|
||||||
out += `\n\n## ${c.name}\n\n`;
|
|
||||||
out += `- ${L[lang]['Type'] || 'Type'}: ${c["type_"+lang] || types[lang][c.type] || c.type}\n`;
|
|
||||||
if (c.default !== undefined)
|
|
||||||
out += `- ${L[lang]['Default'] || 'Default'}: ${c.default}\n`;
|
|
||||||
if (c.min !== undefined)
|
|
||||||
out += `- ${L[lang]['Minimum'] || 'Minimum'}: ${c.min}\n`;
|
|
||||||
out += `\n`+(c["info_"+lang] || c["info"]).replace(/\s+$/, '');
|
|
||||||
}
|
|
||||||
const head = fs.readFileSync(__dirname+'/'+file+'.'+lang+'.md', { encoding: 'utf-8' });
|
|
||||||
out = head.replace(/\s+$/, '')+out+"\n";
|
|
||||||
fs.writeFileSync(__dirname+'/../'+file+'.'+lang+'.md', out);
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
// Add "Read in..." to all other documentation files
|
|
||||||
|
|
||||||
for (const file of find_files(__dirname+'/../..', name => name.substr(-3) == '.md' && !/config\/src\//.exec(name)))
|
|
||||||
{
|
|
||||||
const m = /^(?:(.*?)\/)?([^\/]+)\.([^\.]+)\.[^\.]+$/.exec(file);
|
|
||||||
if (!m)
|
|
||||||
continue;
|
|
||||||
const [ , subdir, filename, lang ] = m;
|
|
||||||
if (!L[lang])
|
|
||||||
continue;
|
|
||||||
let text = fs.readFileSync(__dirname+'/../../'+file, { encoding: 'utf-8' });
|
|
||||||
const title = /(^|\n)# ([^\n]+)/.exec(text)[2];
|
|
||||||
let read_in = Object.keys(L).filter(other => other != lang)
|
|
||||||
.map(other => `[${L[other].Crossref}](${filename}.${other}.md)`)
|
|
||||||
.join(' ')+'\n\n';
|
|
||||||
read_in = L[lang]['toc_root'].replace(/\.\.\//, subdir ? '../../' : '../')+' → '+
|
|
||||||
(subdir ? L[lang]['toc_'+subdir]+' → ' : '')+
|
|
||||||
title+'\n\n-----\n\n'+
|
|
||||||
read_in;
|
|
||||||
if (text.substr(0, read_in.length) != read_in)
|
|
||||||
{
|
|
||||||
fs.writeFileSync(__dirname+'/../../'+file, read_in + (text[0] == '#' ? text : text.replace(/^([\s\S]*?\n)?#/, '#')));
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
function find_files(dir, fn, subdir = '', res = [])
|
|
||||||
{
|
|
||||||
for (const ent of fs.readdirSync(dir+'/'+subdir, { withFileTypes: true }))
|
|
||||||
{
|
|
||||||
if (ent.isDirectory())
|
|
||||||
{
|
|
||||||
find_files(dir, fn, subdir ? subdir+'/'+ent.name : ent.name, res);
|
|
||||||
}
|
|
||||||
else if (fn(subdir ? subdir+'/'+ent.name : ent.name, ent))
|
|
||||||
{
|
|
||||||
res.push(subdir ? subdir+'/'+ent.name : ent.name);
|
|
||||||
}
|
|
||||||
}
|
|
||||||
return res;
|
|
||||||
}
|
|
||||||
|
|
@ -1,3 +0,0 @@
|
||||||
# Monitor Parameters
|
|
||||||
|
|
||||||
These parameters only apply to Monitors.
|
|
||||||
|
|
@ -1,3 +0,0 @@
|
||||||
# Параметры мониторов
|
|
||||||
|
|
||||||
Данные параметры используются только мониторами Vitastor.
|
|
||||||
|
|
@ -1,65 +0,0 @@
|
||||||
- name: etcd_mon_ttl
|
|
||||||
type: sec
|
|
||||||
min: 10
|
|
||||||
default: 30
|
|
||||||
info: Monitor etcd lease refresh interval in seconds
|
|
||||||
info_ru: Интервал обновления etcd резервации (lease) монитором
|
|
||||||
- name: etcd_mon_timeout
|
|
||||||
type: ms
|
|
||||||
default: 1000
|
|
||||||
info: etcd request timeout used by monitor
|
|
||||||
info_ru: Таймаут выполнения запросов к etcd от монитора
|
|
||||||
- name: etcd_mon_retries
|
|
||||||
type: int
|
|
||||||
default: 5
|
|
||||||
info: Maximum number of attempts for one monitor etcd request
|
|
||||||
info_ru: Максимальное число попыток выполнения запросов к etcd монитором
|
|
||||||
- name: mon_change_timeout
|
|
||||||
type: ms
|
|
||||||
min: 100
|
|
||||||
default: 1000
|
|
||||||
info: Optimistic retry interval for monitor etcd modification requests
|
|
||||||
info_ru: Время повтора при коллизиях при запросах модификации в etcd, производимых монитором
|
|
||||||
- name: mon_stats_timeout
|
|
||||||
type: ms
|
|
||||||
min: 100
|
|
||||||
default: 1000
|
|
||||||
info: |
|
|
||||||
Interval for monitor to wait before updating aggregated statistics in
|
|
||||||
etcd after receiving OSD statistics updates
|
|
||||||
info_ru: |
|
|
||||||
Интервал, который монитор ожидает при изменении статистики по отдельным
|
|
||||||
OSD перед обновлением агрегированной статистики в etcd
|
|
||||||
- name: osd_out_time
|
|
||||||
type: sec
|
|
||||||
default: 600
|
|
||||||
info: |
|
|
||||||
Time after which a failed OSD is removed from the data distribution.
|
|
||||||
I.e. time which the monitor waits before attempting to restore data
|
|
||||||
redundancy using other OSDs.
|
|
||||||
info_ru: |
|
|
||||||
Время, через которое отключенный OSD исключается из распределения данных.
|
|
||||||
То есть, время, которое монитор ожидает перед попыткой переместить данные
|
|
||||||
на другие OSD и таким образом восстановить избыточность хранения.
|
|
||||||
- name: placement_levels
|
|
||||||
type: json
|
|
||||||
default: '`{"host":100,"osd":101}`'
|
|
||||||
info: |
|
|
||||||
Levels for the placement tree. You can define arbitrary tree levels by
|
|
||||||
defining them in this parameter. The configuration parameter value should
|
|
||||||
contain a JSON object with level names as keys and integer priorities as
|
|
||||||
values. Smaller priority means higher level in tree. For example,
|
|
||||||
"datacenter" should have smaller priority than "osd". "host" and "osd"
|
|
||||||
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").
|
|
||||||
info_ru: |
|
|
||||||
Определения уровней для дерева размещения OSD. Вы можете определять
|
|
||||||
произвольные уровни, помещая их в данный параметр конфигурации. Значение
|
|
||||||
параметра должно содержать JSON-объект, ключи которого будут являться
|
|
||||||
названиями уровней, а значения - целочисленными приоритетами. Меньшие
|
|
||||||
приоритеты соответствуют верхним уровням дерева. Например, уровень
|
|
||||||
"датацентр" должен иметь меньший приоритет, чем "OSD". Уровни с названиями
|
|
||||||
"host" и "osd" являются предопределёнными и не могут быть удалены. Если
|
|
||||||
один из них отсутствует в конфигурации, он доопределяется с приоритетом по
|
|
||||||
умолчанию (100 для уровня "host", 101 для "osd").
|
|
||||||
|
|
@ -1,4 +0,0 @@
|
||||||
# Network Protocol Parameters
|
|
||||||
|
|
||||||
These parameters apply to clients and OSDs and affect network connection logic
|
|
||||||
between clients, OSDs and etcd.
|
|
||||||
|
|
@ -1,4 +0,0 @@
|
||||||
# Параметры сетевого протокола
|
|
||||||
|
|
||||||
Данные параметры используются клиентами и OSD и влияют на логику сетевого
|
|
||||||
взаимодействия между клиентами, OSD, а также etcd.
|
|
||||||
|
|
@ -1,225 +0,0 @@
|
||||||
- name: tcp_header_buffer_size
|
|
||||||
type: int
|
|
||||||
default: 65536
|
|
||||||
info: |
|
|
||||||
Size of the buffer used to read data using an additional copy. Vitastor
|
|
||||||
packet headers are 128 bytes, payload is always at least 4 KB, so it is
|
|
||||||
usually beneficial to try to read multiple packets at once even though
|
|
||||||
it requires to copy the data an additional time. The rest of each packet
|
|
||||||
is received without an additional copy. You can try to play with this
|
|
||||||
parameter and see how it affects random iops and linear bandwidth if you
|
|
||||||
want.
|
|
||||||
info_ru: |
|
|
||||||
Размер буфера для чтения данных с дополнительным копированием. Пакеты
|
|
||||||
Vitastor содержат 128-байтные заголовки, за которыми следуют данные размером
|
|
||||||
от 4 КБ и для мелких операций ввода-вывода обычно выгодно за 1 вызов читать
|
|
||||||
сразу несколько пакетов, даже не смотря на то, что это требует лишний раз
|
|
||||||
скопировать данные. Часть каждого пакета за пределами значения данного
|
|
||||||
параметра читается без дополнительного копирования. Вы можете попробовать
|
|
||||||
поменять этот параметр и посмотреть, как он влияет на производительность
|
|
||||||
случайного и линейного доступа.
|
|
||||||
- name: use_sync_send_recv
|
|
||||||
type: bool
|
|
||||||
default: false
|
|
||||||
info: |
|
|
||||||
If true, synchronous send/recv syscalls are used instead of io_uring for
|
|
||||||
socket communication. Useless for OSDs because they require io_uring anyway,
|
|
||||||
but may be required for clients with old kernel versions.
|
|
||||||
info_ru: |
|
|
||||||
Если установлено в истину, то вместо io_uring для передачи данных по сети
|
|
||||||
будут использоваться обычные синхронные системные вызовы send/recv. Для OSD
|
|
||||||
это бессмысленно, так как OSD в любом случае нуждается в io_uring, но, в
|
|
||||||
принципе, это может применяться для клиентов со старыми версиями ядра.
|
|
||||||
- name: use_rdma
|
|
||||||
type: bool
|
|
||||||
default: true
|
|
||||||
info: |
|
|
||||||
Try to use RDMA for communication if it's available. Disable if you don't
|
|
||||||
want Vitastor to use RDMA. TCP-only clients can also talk to an RDMA-enabled
|
|
||||||
cluster, so disabling RDMA may be needed if clients have RDMA devices,
|
|
||||||
but they are not connected to the cluster.
|
|
||||||
info_ru: |
|
|
||||||
Пытаться использовать RDMA для связи при наличии доступных устройств.
|
|
||||||
Отключите, если вы не хотите, чтобы Vitastor использовал RDMA.
|
|
||||||
TCP-клиенты также могут работать с RDMA-кластером, так что отключать
|
|
||||||
RDMA может быть нужно только если у клиентов есть RDMA-устройства,
|
|
||||||
но они не имеют соединения с кластером Vitastor.
|
|
||||||
- name: rdma_device
|
|
||||||
type: string
|
|
||||||
info: |
|
|
||||||
RDMA device name to use for Vitastor OSD communications (for example,
|
|
||||||
"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").
|
|
||||||
Имейте в виду, что поддержка 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
|
|
||||||
info: |
|
|
||||||
RDMA device port number to use. Only for devices that have more than 1 port.
|
|
||||||
See `phys_port_cnt` in `ibv_devinfo -v` output to determine how many ports
|
|
||||||
your device has.
|
|
||||||
info_ru: |
|
|
||||||
Номер порта RDMA-устройства, который следует использовать. Имеет смысл
|
|
||||||
только для устройств, у которых более 1 порта. Чтобы узнать, сколько портов
|
|
||||||
у вашего адаптера, посмотрите `phys_port_cnt` в выводе команды
|
|
||||||
`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.
|
|
||||||
|
|
||||||
**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`.
|
|
||||||
|
|
||||||
**ВАЖНО:** Если вы хотите использовать RoCEv2 (как мы и рекомендуем), то
|
|
||||||
правильный rdma_gid_index, как правило, 1 (IPv6) или 3 (IPv4).
|
|
||||||
- name: rdma_mtu
|
|
||||||
type: int
|
|
||||||
default: 4096
|
|
||||||
info: |
|
|
||||||
RDMA Path MTU to use. Must be 1024, 2048 or 4096. There is usually no
|
|
||||||
sense to change it from the default 4096.
|
|
||||||
info_ru: |
|
|
||||||
Максимальная единица передачи (Path MTU) для RDMA. Должно быть равно 1024,
|
|
||||||
2048 или 4096. Обычно нет смысла менять значение по умолчанию, равное 4096.
|
|
||||||
- name: rdma_max_sge
|
|
||||||
type: int
|
|
||||||
default: 128
|
|
||||||
info: |
|
|
||||||
Maximum number of scatter/gather entries to use for RDMA. OSDs negotiate
|
|
||||||
the actual value when establishing connection anyway, so it's usually not
|
|
||||||
required to change this parameter.
|
|
||||||
info_ru: |
|
|
||||||
Максимальное число записей разделения/сборки (scatter/gather) для RDMA.
|
|
||||||
OSD в любом случае согласовывают реальное значение при установке соединения,
|
|
||||||
так что менять этот параметр обычно не нужно.
|
|
||||||
- name: rdma_max_msg
|
|
||||||
type: int
|
|
||||||
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: 8
|
|
||||||
info: |
|
|
||||||
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_msg` выделяется
|
|
||||||
для каждого подключённого клиентского соединения, так что данная настройка
|
|
||||||
влияет на потребление памяти. Это так потому, что RDMA-приём данных в
|
|
||||||
Vitastor, увы, всё равно не является zero-copy, т.е. всё равно 1 раз
|
|
||||||
копирует данные в памяти. Данная особенность, возможно, будет исправлена в
|
|
||||||
более новых версиях Vitastor.
|
|
||||||
- name: peer_connect_interval
|
|
||||||
type: sec
|
|
||||||
min: 1
|
|
||||||
default: 5
|
|
||||||
info: Interval before attempting to reconnect to an unavailable OSD.
|
|
||||||
info_ru: Время ожидания перед повторной попыткой соединиться с недоступным OSD.
|
|
||||||
- name: peer_connect_timeout
|
|
||||||
type: sec
|
|
||||||
min: 1
|
|
||||||
default: 5
|
|
||||||
info: Timeout for OSD connection attempts.
|
|
||||||
info_ru: Максимальное время ожидания попытки соединения с OSD.
|
|
||||||
- name: osd_idle_timeout
|
|
||||||
type: sec
|
|
||||||
min: 1
|
|
||||||
default: 5
|
|
||||||
info: |
|
|
||||||
OSD connection inactivity time after which clients and other OSDs send
|
|
||||||
keepalive requests to check state of the connection.
|
|
||||||
info_ru: |
|
|
||||||
Время неактивности соединения с OSD, после которого клиенты или другие OSD
|
|
||||||
посылают запрос проверки состояния соединения.
|
|
||||||
- name: osd_ping_timeout
|
|
||||||
type: sec
|
|
||||||
min: 1
|
|
||||||
default: 5
|
|
||||||
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
|
|
||||||
is scheduled.
|
|
||||||
info_ru: |
|
|
||||||
Максимальное время ожидания ответа на запрос проверки состояния соединения.
|
|
||||||
Если 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
|
|
||||||
info: |
|
|
||||||
Maximum number of attempts for etcd requests which can't be retried
|
|
||||||
indefinitely.
|
|
||||||
info_ru: |
|
|
||||||
Максимальное число попыток выполнения запросов к etcd для тех запросов,
|
|
||||||
которые нельзя повторять бесконечно.
|
|
||||||
- name: etcd_quick_timeout
|
|
||||||
type: ms
|
|
||||||
default: 1000
|
|
||||||
info: |
|
|
||||||
Timeout for etcd requests which should complete quickly, like lease refresh.
|
|
||||||
info_ru: |
|
|
||||||
Максимальное время выполнения запросов к etcd, которые должны завершаться
|
|
||||||
быстро, таких, как обновление резервации (lease).
|
|
||||||
- name: etcd_slow_timeout
|
|
||||||
type: ms
|
|
||||||
default: 5000
|
|
||||||
info: Timeout for etcd requests which are allowed to wait for some time.
|
|
||||||
info_ru: |
|
|
||||||
Максимальное время выполнения запросов к etcd, для которых не обязательно
|
|
||||||
гарантировать быстрое выполнение.
|
|
||||||
- name: etcd_keepalive_timeout
|
|
||||||
type: sec
|
|
||||||
default: max(30, etcd_report_interval*2)
|
|
||||||
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_timeout
|
|
||||||
type: sec
|
|
||||||
default: 30
|
|
||||||
info: |
|
|
||||||
etcd websocket ping interval required to keep the connection alive and
|
|
||||||
detect disconnections quickly.
|
|
||||||
info_ru: |
|
|
||||||
Интервал проверки живости вебсокет-подключений к etcd.
|
|
||||||
|
|
@ -1,4 +0,0 @@
|
||||||
# Runtime OSD Parameters
|
|
||||||
|
|
||||||
These parameters only apply to OSDs, are not fixed at the moment of OSD drive
|
|
||||||
initialization and can be changed with an OSD restart.
|
|
||||||
|
|
@ -1,5 +0,0 @@
|
||||||
# Изменяемые параметры OSD
|
|
||||||
|
|
||||||
Данные параметры используются только OSD, но, в отличие от дисковых параметров,
|
|
||||||
не фиксируются в момент инициализации дисков OSD и могут быть изменены в любой
|
|
||||||
момент с перезапуском OSD.
|
|
||||||
|
|
@ -1,345 +0,0 @@
|
||||||
- name: etcd_report_interval
|
|
||||||
type: sec
|
|
||||||
default: 5
|
|
||||||
info: |
|
|
||||||
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. Время lease равняется значению этого параметра плюс
|
|
||||||
max_etcd_attempts * etcd_quick_timeout.
|
|
||||||
- name: run_primary
|
|
||||||
type: bool
|
|
||||||
default: true
|
|
||||||
info: |
|
|
||||||
Start primary OSD logic on this OSD. As of now, can be turned off only for
|
|
||||||
debugging purposes. It's possible to implement additional feature for the
|
|
||||||
monitor which may allow to separate primary and secondary OSDs, but it's
|
|
||||||
unclear why anyone could need it, so it's not implemented.
|
|
||||||
info_ru: |
|
|
||||||
Запускать логику первичного OSD на данном OSD. На данный момент отключать
|
|
||||||
эту опцию может иметь смысл только в целях отладки. В теории, можно
|
|
||||||
реализовать дополнительный режим для монитора, который позволит отделять
|
|
||||||
первичные OSD от вторичных, но пока не понятно, зачем это может кому-то
|
|
||||||
понадобиться, поэтому это не реализовано.
|
|
||||||
- name: osd_network
|
|
||||||
type: string or array of strings
|
|
||||||
type_ru: строка или массив строк
|
|
||||||
info: |
|
|
||||||
Network mask of the network (IPv4 or IPv6) to use for OSDs. Note that
|
|
||||||
although it's possible to specify multiple networks here, this does not
|
|
||||||
mean that OSDs will create multiple listening sockets - they'll only
|
|
||||||
pick the first matching address of an UP + RUNNING interface. Separate
|
|
||||||
networks for cluster and client connections are also not implemented, but
|
|
||||||
they are mostly useless anyway, so it's not a big deal.
|
|
||||||
info_ru: |
|
|
||||||
Маска подсети (IPv4 или IPv6) для использования для соединений с OSD.
|
|
||||||
Имейте в виду, что хотя сейчас и можно передать в этот параметр несколько
|
|
||||||
подсетей, это не означает, что OSD будут создавать несколько слушающих
|
|
||||||
сокетов - они лишь будут выбирать адрес первого поднятого (состояние UP +
|
|
||||||
RUNNING), подходящий под заданную маску. Также не реализовано разделение
|
|
||||||
кластерной и публичной сетей OSD. Правда, от него обычно всё равно довольно
|
|
||||||
мало толку, так что особенной проблемы в этом нет.
|
|
||||||
- name: bind_address
|
|
||||||
type: string
|
|
||||||
default: "0.0.0.0"
|
|
||||||
info: |
|
|
||||||
Instead of the network mask, you can also set OSD listen address explicitly
|
|
||||||
using this parameter. May be useful if you want to start OSDs on interfaces
|
|
||||||
that are not UP + RUNNING.
|
|
||||||
info_ru: |
|
|
||||||
Этим параметром можно явным образом задать адрес, на котором будет ожидать
|
|
||||||
соединений OSD (вместо использования маски подсети). Может быть полезно,
|
|
||||||
например, чтобы запускать OSD на неподнятых интерфейсах (не UP + RUNNING).
|
|
||||||
- name: bind_port
|
|
||||||
type: int
|
|
||||||
info: |
|
|
||||||
By default, OSDs pick random ports to use for incoming connections
|
|
||||||
automatically. With this option you can set a specific port for a specific
|
|
||||||
OSD by hand.
|
|
||||||
info_ru: |
|
|
||||||
По умолчанию OSD сами выбирают случайные порты для входящих подключений.
|
|
||||||
С помощью данной опции вы можете задать порт для отдельного OSD вручную.
|
|
||||||
- name: autosync_interval
|
|
||||||
type: sec
|
|
||||||
default: 5
|
|
||||||
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
|
|
||||||
them OSDs quickly fill their journals, become unable to clear them and
|
|
||||||
stall. Also this option limits the amount of recent uncommitted changes
|
|
||||||
which OSDs may lose in case of a power outage in case when clients don't
|
|
||||||
issue fsyncs at all.
|
|
||||||
info_ru: |
|
|
||||||
Временной интервал отправки автоматических fsync-ов (операций очистки кэша)
|
|
||||||
каждым OSD для случая, когда режим immediate_commit отключён. fsync-и нужны
|
|
||||||
OSD, чтобы успевать очищать журнал - без них OSD быстро заполняют журналы и
|
|
||||||
перестают обрабатывать операции записи. Также эта опция ограничивает объём
|
|
||||||
недавних незафиксированных изменений, которые OSD могут терять при
|
|
||||||
отключении питания, если клиенты вообще не отправляют fsync.
|
|
||||||
- name: autosync_writes
|
|
||||||
type: int
|
|
||||||
default: 128
|
|
||||||
info: |
|
|
||||||
Same as autosync_interval, but sets the maximum number of uncommitted write
|
|
||||||
operations before issuing an fsync operation internally.
|
|
||||||
info_ru: |
|
|
||||||
Аналогично autosync_interval, но задаёт не временной интервал, а
|
|
||||||
максимальное количество незафиксированных операций записи перед
|
|
||||||
принудительной отправкой fsync-а.
|
|
||||||
- name: recovery_queue_depth
|
|
||||||
type: int
|
|
||||||
default: 4
|
|
||||||
info: |
|
|
||||||
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 в любой
|
|
||||||
момент времени. На данный момент единственный параметр, который можно менять
|
|
||||||
для ускорения или замедления восстановления и перебалансировки данных, но
|
|
||||||
в планах реализация других параметров.
|
|
||||||
- name: recovery_sync_batch
|
|
||||||
type: int
|
|
||||||
default: 16
|
|
||||||
info: Maximum number of recovery operations before issuing an additional fsync.
|
|
||||||
info_ru: Максимальное число операций восстановления перед дополнительным fsync.
|
|
||||||
- name: readonly
|
|
||||||
type: bool
|
|
||||||
default: false
|
|
||||||
info: |
|
|
||||||
Read-only mode. If this is enabled, an OSD will never issue any writes to
|
|
||||||
the underlying device. This may be useful for recovery purposes.
|
|
||||||
info_ru: |
|
|
||||||
Режим "только чтение". Если включить этот режим, OSD не будет писать ничего
|
|
||||||
на диск. Может быть полезно в целях восстановления.
|
|
||||||
- name: no_recovery
|
|
||||||
type: bool
|
|
||||||
default: false
|
|
||||||
info: |
|
|
||||||
Disable automatic background recovery of objects. Note that it doesn't
|
|
||||||
affect implicit recovery of objects happening during writes - a write is
|
|
||||||
always made to a full set of at least pg_minsize OSDs.
|
|
||||||
info_ru: |
|
|
||||||
Отключить автоматическое фоновое восстановление объектов. Обратите внимание,
|
|
||||||
что эта опция не отключает восстановление объектов, происходящее при
|
|
||||||
записи - запись всегда производится в полный набор из как минимум pg_minsize
|
|
||||||
OSD.
|
|
||||||
- name: no_rebalance
|
|
||||||
type: bool
|
|
||||||
default: false
|
|
||||||
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.
|
|
||||||
info_ru: |
|
|
||||||
Отключить фоновое перемещение объектов между разными OSD. Отключение
|
|
||||||
означает, что PG, находящиеся в состоянии `has_misplaced`, будут оставлены
|
|
||||||
в нём на неопределённый срок.
|
|
||||||
- name: print_stats_interval
|
|
||||||
type: sec
|
|
||||||
default: 3
|
|
||||||
info: |
|
|
||||||
Time interval at which OSDs print simple human-readable operation
|
|
||||||
statistics on stdout.
|
|
||||||
info_ru: |
|
|
||||||
Временной интервал, с которым OSD печатают простую человекочитаемую
|
|
||||||
статистику выполнения операций в стандартный вывод.
|
|
||||||
- name: slow_log_interval
|
|
||||||
type: sec
|
|
||||||
default: 10
|
|
||||||
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
|
|
||||||
"slow".
|
|
||||||
info_ru: |
|
|
||||||
Временной интервал, с которым OSD выводят в стандартный вывод список
|
|
||||||
медленных или зависших операций, если таковые имеются. Также время, при
|
|
||||||
превышении которого операция считается "медленной".
|
|
||||||
- name: max_write_iodepth
|
|
||||||
type: int
|
|
||||||
default: 128
|
|
||||||
info: |
|
|
||||||
Parallel client write operation limit per one OSD. Operations that exceed
|
|
||||||
this limit are pushed to a temporary queue instead of being executed
|
|
||||||
immediately.
|
|
||||||
info_ru: |
|
|
||||||
Максимальное число одновременных клиентских операций записи на один OSD.
|
|
||||||
Операции, превышающие этот лимит, не исполняются сразу, а сохраняются во
|
|
||||||
временной очереди.
|
|
||||||
- name: min_flusher_count
|
|
||||||
type: int
|
|
||||||
default: 1
|
|
||||||
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.
|
|
||||||
Minimum number is set by this parameter.
|
|
||||||
info_ru: |
|
|
||||||
Flusher - это микро-поток (корутина), которая копирует данные из журнала в
|
|
||||||
основную область устройства данных. Их число настраивается динамически между
|
|
||||||
минимальным и максимальным значением. Этот параметр задаёт минимальное число.
|
|
||||||
- name: max_flusher_count
|
|
||||||
type: int
|
|
||||||
default: 256
|
|
||||||
info: |
|
|
||||||
Maximum number of journal flushers (see above min_flusher_count).
|
|
||||||
info_ru: |
|
|
||||||
Максимальное число микро-потоков очистки журнала (см. выше min_flusher_count).
|
|
||||||
- name: inmemory_metadata
|
|
||||||
type: bool
|
|
||||||
default: true
|
|
||||||
info: |
|
|
||||||
This parameter makes Vitastor always keep metadata area of the block device
|
|
||||||
in memory. It's required for good performance because it allows to avoid
|
|
||||||
additional read-modify-write cycles during metadata modifications. Metadata
|
|
||||||
area size is currently roughly 224 MB per 1 TB of data. You can turn it off
|
|
||||||
to reduce memory usage by this value, but it will hurt performance. This
|
|
||||||
restriction is likely to be removed in the future along with the upgrade
|
|
||||||
of the metadata storage scheme.
|
|
||||||
info_ru: |
|
|
||||||
Данный параметр заставляет Vitastor всегда держать область метаданных диска
|
|
||||||
в памяти. Это нужно, чтобы избегать дополнительных операций чтения с диска
|
|
||||||
при записи. Размер области метаданных на данный момент составляет примерно
|
|
||||||
224 МБ на 1 ТБ данных. При включении потребление памяти снизится примерно
|
|
||||||
на эту величину, но при этом также снизится и производительность. В будущем,
|
|
||||||
после обновления схемы хранения метаданных, это ограничение, скорее всего,
|
|
||||||
будет ликвидировано.
|
|
||||||
- name: inmemory_journal
|
|
||||||
type: bool
|
|
||||||
default: true
|
|
||||||
info: |
|
|
||||||
This parameter make Vitastor always keep journal area of the block
|
|
||||||
device in memory. Turning it off will, again, reduce memory usage, but
|
|
||||||
hurt performance because flusher coroutines will have to read data from
|
|
||||||
the disk back before copying it into the main area. The memory usage benefit
|
|
||||||
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.
|
|
||||||
info_ru: |
|
|
||||||
Данный параметр заставляет Vitastor всегда держать в памяти журналы OSD.
|
|
||||||
Отключение параметра, опять же, снижает потребление памяти, но ухудшает
|
|
||||||
производительность, так как для копирования данных из журнала в основную
|
|
||||||
область устройства OSD будут вынуждены читать их обратно с диска. Выигрыш
|
|
||||||
по памяти при этом обычно крайне низкий, так как для SSD OSD обычно
|
|
||||||
достаточно 16- или 32-мегабайтного журнала. Однако в теории отключение
|
|
||||||
параметра может оказаться полезным для гибридных OSD (HDD+SSD) с большими
|
|
||||||
журналами, расположенными на быстром по сравнению с HDD устройстве.
|
|
||||||
- name: journal_sector_buffer_count
|
|
||||||
type: int
|
|
||||||
default: 32
|
|
||||||
info: |
|
|
||||||
Maximum number of buffers that can be used for writing journal metadata
|
|
||||||
blocks. The only situation when you should increase it to a larger value
|
|
||||||
is when you enable journal_no_same_sector_overwrites. In this case set
|
|
||||||
it to, for example, 1024.
|
|
||||||
info_ru: |
|
|
||||||
Максимальное число буферов, разрешённых для использования под записываемые
|
|
||||||
в журнал блоки метаданных. Единственная ситуация, в которой этот параметр
|
|
||||||
нужно менять - это если вы включаете journal_no_same_sector_overwrites. В
|
|
||||||
этом случае установите данный параметр, например, в 1024.
|
|
||||||
- name: journal_no_same_sector_overwrites
|
|
||||||
type: bool
|
|
||||||
default: false
|
|
||||||
info: |
|
|
||||||
Enable this option for SSDs like Intel D3-S4510 and D3-S4610 which REALLY
|
|
||||||
don't like when a program overwrites the same sector multiple times in a
|
|
||||||
row and slow down significantly (from 25000+ iops to ~3000 iops). When
|
|
||||||
this option is set, Vitastor will always move to the next sector of the
|
|
||||||
journal after writing it instead of possibly overwriting it the second time.
|
|
||||||
|
|
||||||
Most (99%) other SSDs don't need this option.
|
|
||||||
info_ru: |
|
|
||||||
Включайте данную опцию для SSD вроде Intel D3-S4510 и D3-S4610, которые
|
|
||||||
ОЧЕНЬ не любят, когда ПО перезаписывает один и тот же сектор несколько раз
|
|
||||||
подряд. Такие SSD при многократной перезаписи одного и того же сектора
|
|
||||||
сильно замедляются - условно, с 25000 и более iops до 3000 iops. Когда
|
|
||||||
данная опция установлена, Vitastor всегда переходит к следующему сектору
|
|
||||||
журнала после записи вместо потенциально повторной перезаписи того же
|
|
||||||
самого сектора.
|
|
||||||
|
|
||||||
Почти все другие SSD (99% моделей) не требуют данной опции.
|
|
||||||
- name: throttle_small_writes
|
|
||||||
type: bool
|
|
||||||
default: false
|
|
||||||
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
|
|
||||||
small writes complete very quickly because they're first written to the
|
|
||||||
journal device, but moving them to the main device is slow. So if an OSD
|
|
||||||
allows clients to issue a lot of small writes it will perform very good
|
|
||||||
for several seconds and then the journal will fill up and the performance
|
|
||||||
will drop to almost zero. Throttling is meant to prevent this problem by
|
|
||||||
artifically slowing quick writes down based on the amount of free space in
|
|
||||||
the journal. When throttling is used, the performance of small writes will
|
|
||||||
decrease smoothly instead of abrupt drop at the moment when the journal
|
|
||||||
fills up.
|
|
||||||
info_ru: |
|
|
||||||
Разрешить мягкое ограничение скорости журналируемой записи. Полезно для
|
|
||||||
гибридных OSD с быстрыми устройствами метаданных и медленными устройствами
|
|
||||||
данных. Идея заключается в том, что мелкие записи в этой ситуации могут
|
|
||||||
завершаться очень быстро, так как они изначально записываются на быстрое
|
|
||||||
журнальное устройство (SSD). Но перемещать их потом на основное медленное
|
|
||||||
устройство долго. Поэтому если OSD быстро примет от клиентов очень много
|
|
||||||
мелких операций записи, он быстро заполнит свой журнал, после чего
|
|
||||||
производительность записи резко упадёт практически до нуля. Ограничение
|
|
||||||
скорости записи призвано решить эту проблему с помощью искусственного
|
|
||||||
замедления операций записи на основании объёма свободного места в журнале.
|
|
||||||
Когда эта опция включена, производительность мелких операций записи будет
|
|
||||||
снижаться плавно, а не резко в момент окончательного заполнения журнала.
|
|
||||||
- name: throttle_target_iops
|
|
||||||
type: int
|
|
||||||
default: 100
|
|
||||||
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
|
|
||||||
(HDDs).
|
|
||||||
info_ru: |
|
|
||||||
Расчётное максимальное число ограничиваемых операций в секунду при условии
|
|
||||||
отсутствия свободного места в журнале. Устанавливайте приблизительно равным
|
|
||||||
максимальной производительности случайной записи ваших устройств данных
|
|
||||||
(HDD) в операциях в секунду.
|
|
||||||
- name: throttle_target_mbs
|
|
||||||
type: int
|
|
||||||
default: 100
|
|
||||||
info: |
|
|
||||||
Target maximum bandwidth in MB/s of throttled operations per second under
|
|
||||||
the condition of full journal. Set it to approximate linear write
|
|
||||||
performance of your data devices (HDDs).
|
|
||||||
info_ru: |
|
|
||||||
Расчётный максимальный размер в МБ/с ограничиваемых операций в секунду при
|
|
||||||
условии отсутствия свободного места в журнале. Устанавливайте приблизительно
|
|
||||||
равным максимальной производительности линейной записи ваших устройств
|
|
||||||
данных (HDD).
|
|
||||||
- name: throttle_target_parallelism
|
|
||||||
type: int
|
|
||||||
default: 1
|
|
||||||
info: |
|
|
||||||
Target maximum parallelism of throttled operations under the condition of
|
|
||||||
full journal. Set it to approximate internal parallelism of your data
|
|
||||||
devices (1 for HDDs, 4-8 for SSDs).
|
|
||||||
info_ru: |
|
|
||||||
Расчётный максимальный параллелизм ограничиваемых операций в секунду при
|
|
||||||
условии отсутствия свободного места в журнале. Устанавливайте приблизительно
|
|
||||||
равным внутреннему параллелизму ваших устройств данных (1 для HDD, 4-8
|
|
||||||
для SSD).
|
|
||||||
- name: throttle_threshold_us
|
|
||||||
type: us
|
|
||||||
default: 50
|
|
||||||
info: |
|
|
||||||
Minimal computed delay to be applied to throttled operations. Usually
|
|
||||||
doesn't need to be changed.
|
|
||||||
info_ru: |
|
|
||||||
Минимальная применимая к ограничиваемым операциям задержка. Обычно не
|
|
||||||
требует изменений.
|
|
||||||
- name: osd_memlock
|
|
||||||
type: bool
|
|
||||||
default: false
|
|
||||||
info: >
|
|
||||||
Lock all OSD memory to prevent it from being unloaded into swap with
|
|
||||||
mlockall(). Requires sufficient ulimit -l (max locked memory).
|
|
||||||
info_ru: >
|
|
||||||
Блокировать всю память OSD с помощью mlockall, чтобы запретить её выгрузку
|
|
||||||
в пространство подкачки. Требует достаточного значения ulimit -l (лимита
|
|
||||||
заблокированной памяти).
|
|
||||||
|
|
@ -1,20 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → Installation → Kubernetes CSI
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](kubernetes.ru.md)
|
|
||||||
|
|
||||||
# Kubernetes CSI
|
|
||||||
|
|
||||||
Vitastor has a CSI plugin for Kubernetes which supports RWO (and block RWX) volumes.
|
|
||||||
|
|
||||||
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:
|
|
||||||
|
|
||||||
```
|
|
||||||
for i in ./???-*.yaml; do kubectl apply -f $i; done
|
|
||||||
```
|
|
||||||
|
|
||||||
After that you'll be able to create PersistentVolumes. See example in [csi/deploy/example-pvc.yaml](../../csi/deploy/example-pvc.yaml).
|
|
||||||
|
|
@ -1,20 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → Установка → Kubernetes CSI
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](kubernetes.en.md)
|
|
||||||
|
|
||||||
# Kubernetes CSI
|
|
||||||
|
|
||||||
У Vitastor есть CSI-плагин для Kubernetes, поддерживающий RWO, а также блочные RWX, тома.
|
|
||||||
|
|
||||||
Для установки возьмите манифесты из директории [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. Пример смотрите в файле [csi/deploy/example-pvc.yaml](../csi/deploy/example-pvc.yaml).
|
|
||||||
|
|
@ -1,40 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → Installation → OpenStack
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](openstack.ru.md)
|
|
||||||
|
|
||||||
# OpenStack
|
|
||||||
|
|
||||||
To enable Vitastor support in an OpenStack installation:
|
|
||||||
|
|
||||||
- Install vitastor-client, patched QEMU and libvirt packages from Vitastor DEB or RPM repository
|
|
||||||
- Use `patches/nova-21.diff` or `patches/nova-23.diff` to patch your Nova installation.
|
|
||||||
Patch 21 fits Nova 21-22, patch 23 fits Nova 23-24.
|
|
||||||
- Install `patches/cinder-vitastor.py` as `..../cinder/volume/drivers/vitastor.py`
|
|
||||||
- Define a volume type in cinder.conf (see below)
|
|
||||||
- Block network access from VMs to Vitastor network (to OSDs and etcd),
|
|
||||||
because Vitastor doesn't support authentication
|
|
||||||
- Restart Cinder and Nova
|
|
||||||
|
|
||||||
Cinder volume type configuration example:
|
|
||||||
|
|
||||||
```
|
|
||||||
[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
|
|
||||||
```
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
@ -1,40 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → Установка → OpenStack
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](openstack.en.md)
|
|
||||||
|
|
||||||
# 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),
|
|
||||||
однако, поддержка этой функции ещё не проверялась.
|
|
||||||
|
|
@ -1,44 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → Installation → Packages
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](packages.ru.md)
|
|
||||||
|
|
||||||
# Packages
|
|
||||||
|
|
||||||
## 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`
|
|
||||||
|
|
||||||
## Installation requirements
|
|
||||||
|
|
||||||
- Linux kernel 5.4 or newer, for io_uring support. 5.8 or later is highly
|
|
||||||
recommended because io_uring is a relatively new technology and there is
|
|
||||||
at least one bug which reproduces with io_uring and HP SmartArray
|
|
||||||
controllers in 5.4
|
|
||||||
- liburing 0.4 or newer
|
|
||||||
- lp_solve
|
|
||||||
- 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
|
|
||||||
|
|
@ -1,43 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → Установка → Установка из пакетов
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](packages.en.md)
|
|
||||||
|
|
||||||
# Установка из пакетов
|
|
||||||
|
|
||||||
## 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`
|
|
||||||
|
|
||||||
## Установочные требования
|
|
||||||
|
|
||||||
- Ядро Linux 5.4 или новее, для поддержки io_uring. Рекомендуется даже 5.8,
|
|
||||||
так как io_uring - относительно новый интерфейс и в версиях до 5.8 встречались
|
|
||||||
некоторые баги, например, зависание с io_uring и контроллером HP SmartArray
|
|
||||||
- liburing 0.4 или новее
|
|
||||||
- lp_solve
|
|
||||||
- etcd 3.4.15 или новее. Более старые версии не будут работать из-за разных багов,
|
|
||||||
например, [#12402](https://github.com/etcd-io/etcd/pull/12402).
|
|
||||||
- node.js 10 или новее
|
|
||||||
|
|
@ -1,39 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → Installation → Proxmox VE
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](proxmox.ru.md)
|
|
||||||
|
|
||||||
# Proxmox VE
|
|
||||||
|
|
||||||
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
|
|
||||||
(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),
|
|
||||||
because Vitastor doesn't support authentication
|
|
||||||
- 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: 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), 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
|
|
||||||
# prefix for images
|
|
||||||
vitastor_prefix pve/
|
|
||||||
# use NBD mounter (only required for containers)
|
|
||||||
vitastor_nbd 0
|
|
||||||
```
|
|
||||||
|
|
||||||
\* 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,39 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → Установка → Proxmox
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](proxmox.en.md)
|
|
||||||
|
|
||||||
# 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`.
|
|
||||||
|
|
@ -1,65 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → Installation → Building from Source
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](source.ru.md)
|
|
||||||
|
|
||||||
# Building from Source
|
|
||||||
|
|
||||||
- [Requirements](#requirements)
|
|
||||||
- [Basic instructions](#basic-instructions)
|
|
||||||
- [QEMU Driver](#qemu-driver)
|
|
||||||
|
|
||||||
## Requirements
|
|
||||||
|
|
||||||
- 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
|
|
||||||
- tcmalloc (google-perftools-dev)
|
|
||||||
|
|
||||||
## Basic instructions
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
Build and install Vitastor:
|
|
||||||
|
|
||||||
```
|
|
||||||
cd vitastor
|
|
||||||
mkdir build
|
|
||||||
cd build
|
|
||||||
cmake .. && make -j8 install
|
|
||||||
```
|
|
||||||
|
|
||||||
## QEMU Driver
|
|
||||||
|
|
||||||
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/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:
|
|
||||||
- Get QEMU 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
|
|
||||||
- Configure Vitastor with `WITH_QEMU=yes` and, if you're on RHEL, also with `QEMU_PLUGINDIR=qemu-kvm`:
|
|
||||||
`cmake .. -DWITH_QEMU=yes`.
|
|
||||||
- After that, Vitastor will build `block-vitastor.so` during its build process.
|
|
||||||
- This way you can use the driver even with unmodified QEMU, but you'll need to set
|
|
||||||
environment variable `LD_PRELOAD=/usr/lib/x86_64-linux-gnu/qemu/block-vitastor.so`
|
|
||||||
and Vitastor disks won't work in QAPI and in "new" JSON syntax `-blockdev` in this case.
|
|
||||||
|
|
@ -1,68 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → Установка → Сборка из исходных кодов
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](source.en.md)
|
|
||||||
|
|
||||||
# Сборка из исходных кодов
|
|
||||||
|
|
||||||
- [Требования](#требования)
|
|
||||||
- [Базовая инструкция](#базовая-инструкция)
|
|
||||||
- [Драйвер QEMU](#драйвер-qemu)
|
|
||||||
|
|
||||||
## Требования
|
|
||||||
|
|
||||||
- gcc и g++ >= 8, либо clang >= 10, либо другой компилятор с поддержкой C++11 плюс
|
|
||||||
назначенных инициализаторов (designated initializers) из C++20
|
|
||||||
- CMake
|
|
||||||
- Заголовки liburing, jerasure
|
|
||||||
- tcmalloc (google-perftools-dev)
|
|
||||||
|
|
||||||
## Базовая инструкция
|
|
||||||
|
|
||||||
Скачайте исходные коды, например, из git: `git clone --recurse-submodules https://yourcmc.ru/git/vitalif/vitastor/`
|
|
||||||
|
|
||||||
Скачайте исходные коды пакета `fio`, распакуйте их и создайте символическую ссылку на них
|
|
||||||
в директории исходников Vitastor: `<vitastor>/fio`. Либо, если вы не хотите собирать плагин fio,
|
|
||||||
его можно исключить из сборки путём передачи `-DWITH_FIO=no` в cmake.
|
|
||||||
|
|
||||||
Собрать и установить Vitastor:
|
|
||||||
|
|
||||||
```
|
|
||||||
cd vitastor
|
|
||||||
mkdir build
|
|
||||||
cd build
|
|
||||||
cmake .. && make -j8 install
|
|
||||||
```
|
|
||||||
|
|
||||||
## Драйвер QEMU
|
|
||||||
|
|
||||||
Драйвер QEMU (qemu_driver.c) рекомендуется собирать вместе с самим QEMU. Для этого:
|
|
||||||
- Установите заголовки клиентской библиотеки Vitastor (из исходников или из пакета vitastor-client-dev)
|
|
||||||
- Возьмите соответствующий патч из `patches/qemu-*-vitastor.patch` и примените его к исходникам QEMU
|
|
||||||
- Скопируйте [src/qemu_driver.c](../../src/qemu_driver.c) в директорию исходников QEMU как `block/block-vitastor.c`
|
|
||||||
- Соберите QEMU как обычно
|
|
||||||
|
|
||||||
Однако в целях отладки драйвер также можно собирать отдельно от QEMU. Для этого:
|
|
||||||
- Установите QEMU, возьмите исходные коды установленного пакета, начните его пересборку,
|
|
||||||
через некоторое время остановите её и скопируйте следующие заголовки:
|
|
||||||
- `<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` нужны, т.к. в них содержатся автогенерируемые заголовки
|
|
||||||
- Сконфигурируйте cmake Vitastor с `WITH_QEMU=yes` (`cmake .. -DWITH_QEMU=yes`) и, если вы
|
|
||||||
используете RHEL-подобый дистрибутив, также с `QEMU_PLUGINDIR=qemu-kvm`.
|
|
||||||
- После этого в процессе сборки Vitastor также будет собираться подходящий для вашей
|
|
||||||
версии QEMU `block-vitastor.so`.
|
|
||||||
- Таким образом можно использовать драйвер даже с немодифицированным QEMU, но в этом случае
|
|
||||||
диски Vitastor не будут работать через QAPI и через JSON-синтаксис `-blockdev`, а также
|
|
||||||
потребуется устанавливать переменную окружения
|
|
||||||
`LD_PRELOAD=/usr/lib/x86_64-linux-gnu/qemu/block-vitastor.so`.
|
|
||||||
|
|
@ -1,91 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → Introduction → Architecture
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](architecture.ru.md)
|
|
||||||
|
|
||||||
# Architecture
|
|
||||||
|
|
||||||
- [Basic concepts](#basic-concepts)
|
|
||||||
- [Similarities to Ceph](#similarities-to-ceph)
|
|
||||||
- [Differences from Ceph](#differences-from-ceph)
|
|
||||||
- [Implementation Principles](#implementation-principles)
|
|
||||||
|
|
||||||
## Basic concepts
|
|
||||||
|
|
||||||
- OSD (Object Storage Daemon) is a process that stores data and serves read/write requests.
|
|
||||||
- PG (Placement Group) is a "shard" of the cluster, group of data stored on one set of replicas.
|
|
||||||
- Pool is a container for data that has equal 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.
|
|
||||||
|
|
||||||
## Similarities to Ceph
|
|
||||||
|
|
||||||
- Vitastor also has Pools, PGs, OSDs, Monitors, Failure Domains, Placement Tree:
|
|
||||||
- Vitastor also distributes every image data across the whole cluster.
|
|
||||||
- Vitastor is also transactional. Even though there's a "lazy fsync mode" which
|
|
||||||
doesn't implicitly flush every operation to disks, every write to the cluster is atomic.
|
|
||||||
- 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.
|
|
||||||
|
|
||||||
## Differences from Ceph
|
|
||||||
|
|
||||||
- Vitastor's primary focus is on SSDs: SSD-only and SSD+HDD clusters.
|
|
||||||
- The basic layer of Vitastor is block storage with fixed-size blocks, not object storage with
|
|
||||||
rich semantics like in Ceph (RADOS).
|
|
||||||
- PGs are ephemeral in Vitastor. This means that they aren't stored on data disks and only exist
|
|
||||||
in memory while OSDs are running.
|
|
||||||
- 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 is always kept in memory which removes the need for extra disk reads. Metadata size
|
|
||||||
depends linearly on drive capacity and data store block size which is 128 KB by default.
|
|
||||||
With 128 KB blocks metadata takes around 512 MB per 1 TB (which is still less than Ceph wants).
|
|
||||||
Journal is also kept in memory by default, but in SSD-only clusters it's only 32 MB, and in SSD+HDD
|
|
||||||
clusters, where it's beneficial to increase it, [inmemory_journal](docs/config/osd.en.md#inmemory_journal) can be disabled.
|
|
||||||
- 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.
|
|
||||||
- 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.
|
|
||||||
- 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.
|
|
||||||
|
|
||||||
## Implementation Principles
|
|
||||||
|
|
||||||
- I like architecturally simple solutions. Vitastor is and will always be designed
|
|
||||||
exactly like that.
|
|
||||||
- I also like reinventing the wheel to some extent, like writing my own HTTP client
|
|
||||||
for etcd interaction instead of using prebuilt libraries, because in this case
|
|
||||||
I'm confident about what my code does and what it doesn't do.
|
|
||||||
- I don't care about C++ "best practices" like RAII or proper inheritance or usage of
|
|
||||||
smart pointers or whatever and I don't intend to change my mind, so if you're here
|
|
||||||
looking for ideal reference C++ code, this probably isn't the right place.
|
|
||||||
- I like node.js better than any other dynamically-typed language interpreter
|
|
||||||
because it's faster than any other interpreter in the world, has neutral C-like
|
|
||||||
syntax and built-in event loop. That's why Monitor is implemented in node.js.
|
|
||||||
|
|
||||||
## Known Problems
|
|
||||||
|
|
||||||
- Deleting images in a degraded cluster may currently lead to objects reappearing
|
|
||||||
after dead OSDs come back, and in case of erasure-coded pools, they may even
|
|
||||||
reappear as incomplete. Just repeat the removal request again in this case.
|
|
||||||
This problem will be fixed in the nearest future, the fix is already implemented
|
|
||||||
in the "epoch-deletions" branch.
|
|
||||||
|
|
@ -1,208 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → Введение → Архитектура
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](architecture.en.md)
|
|
||||||
|
|
||||||
# Архитектура
|
|
||||||
|
|
||||||
Краткое описание архитектуры Vitastor.
|
|
||||||
|
|
||||||
- [Серверные компоненты](#серверные-компоненты)
|
|
||||||
- [Базовые понятия](#базовые-понятия)
|
|
||||||
- [Клиентские компоненты](#клиентские-компоненты)
|
|
||||||
- [Общий процесс записи и чтения](#общий-процесс-записи-и-чтения)
|
|
||||||
- [Особенности обработки запросов](#особенности-обработки-запросов)
|
|
||||||
- [Схожесть с Ceph](#схожесть-с-ceph)
|
|
||||||
- [Отличия от Ceph](#отличия-от-ceph)
|
|
||||||
- [Принципы разработки](#принципы-разработки)
|
|
||||||
|
|
||||||
## Серверные компоненты
|
|
||||||
|
|
||||||
- **OSD** (Object Storage Daemon) — процесс, который непосредственно работает с диском, пишет и читает данные.
|
|
||||||
Один OSD управляет одним диском (или разделом). OSD общаются с etcd и друг с другом — от etcd они
|
|
||||||
получают состояние кластера, а друг другу передают запросы записи и чтения вторичных копий данных.
|
|
||||||
- **etcd** — кластерная key/value база данных, используется для хранения настроек и верхнеуровневого
|
|
||||||
состояния кластера, а также предотвращения разделения сознания. Блоки данных в etcd не хранятся,
|
|
||||||
в обработке клиентских запросов чтения и записи etcd не участвует.
|
|
||||||
- **Монитор** — отдельный демон на node.js, рассчитывающий необходимые изменения в конфигурацию
|
|
||||||
кластера, сохраняющий эту информацию в etcd и таким образом командующий OSD применить эти изменения.
|
|
||||||
Также агрегирует статистику. Контактирует только с etcd, OSD с монитором не общаются.
|
|
||||||
|
|
||||||
## Базовые понятия
|
|
||||||
|
|
||||||
- **Пул (Pool)** — контейнер для данных, имеющих одну и ту же схему избыточности и правила распределения по OSD.
|
|
||||||
- **PG (Placement Group)** — "шард", единица деления пулов в кластере, которой назначается свой набор
|
|
||||||
OSD для хранения данных (копий или частей объектов).
|
|
||||||
- **Домен отказа (Failure Domain)** — группа OSD, одновременное падение которых рассматривается
|
|
||||||
как вероятное. По умолчанию это "host" (сервер).
|
|
||||||
- **Дерево распределения** (Placement Tree, в Ceph CRUSH Tree) — иерархическая группировка OSD
|
|
||||||
в узлы, которые далее можно использовать как домены отказа.
|
|
||||||
|
|
||||||
## Клиентские компоненты
|
|
||||||
|
|
||||||
- **Клиентская библиотека** — инкапсулирует логику на стороне клиента. Соединяются с etcd и со всеми OSD,
|
|
||||||
от etcd получают состояние кластера, команды чтения и записи отправляют на все OSD напрямую.
|
|
||||||
В силу архитектуры все отдельные блоки данных (по умолчанию по 128 КБ) располагается на разных
|
|
||||||
OSD, но клиент устроен так, что всегда точно знает, к какому OSD обращаться, и подключается
|
|
||||||
к нему напрямую.
|
|
||||||
|
|
||||||
На базе клиентской библиотеки реализованы все остальные клиенты:
|
|
||||||
|
|
||||||
- **vitastor-cli** — утилита командной строки для управления кластером. В данный момент позволяет
|
|
||||||
просматривать общее состояние кластера и управлять образами — т.е. создавать, менять и удалять
|
|
||||||
виртуальные диски, их снимки и клоны.
|
|
||||||
- **Драйвер QEMU** — подключаемый модуль QEMU, позволяющий QEMU/KVM виртуальным машинам работать
|
|
||||||
с виртуальными дисками Vitastor напрямую из пространства пользователя с помощью клиентской
|
|
||||||
библиотеки, без необходимости отображения дисков в виде блочных устройств.
|
|
||||||
- **vitastor-nbd** — утилита, позволяющая монтировать образы Vitastor в виде блочных устройств
|
|
||||||
с помощью NBD (Network Block Device), на самом деле скорее работающего как "BUSE"
|
|
||||||
(Block Device In Userspace). Модуля ядра Linux для выполнения той же задачи в Vitastor нет
|
|
||||||
(по крайней мере, пока).
|
|
||||||
- **CSI драйвер** — драйвер для подключения Vitastor-образов в виде персистентных томов (PV) Kubernetes.
|
|
||||||
Работает через vitastor-nbd — образы отражаются в виде блочных устройств и монтируются
|
|
||||||
в контейнеры.
|
|
||||||
- **Драйвера Proxmox, OpenStack и т.п.** — подключаемые модули для соответствующих систем,
|
|
||||||
позволяющие использовать Vitastor как хранилище в оных.
|
|
||||||
- **vitastor-nfs** — утилита, предоставляющая файловый доступ к образам в кластере Vitastor
|
|
||||||
по протоколу NFS 3.0. Предназначена для гипервизоров, не основанных на QEMU и Linux, но при
|
|
||||||
этом поддерживающих NFS.
|
|
||||||
|
|
||||||
## Общий процесс записи и чтения
|
|
||||||
|
|
||||||
- В Vitastor хранятся виртуальные диски, также называемые "образы" или "иноды".
|
|
||||||
- Каждый образ хранится в определённом пуле. Пул определяет параметры хранения образов в нём,
|
|
||||||
такие, как схему избыточности (репликация или EC — коды коррекции ошибок), домен отказа
|
|
||||||
и ограничения по выбору OSD для размещения данных образов. См. [Конфигурация пулов](../config/pool.ru.md).
|
|
||||||
- Каждый образ разбивается на объекты фиксированного размера, равного [block_size](../config/layout-cluster.ru.md#block_size)
|
|
||||||
(по умолчанию 128 КБ), умноженному на число частей данных для EC или на 1 для реплик.
|
|
||||||
То есть, например, если в пуле используется схема кодирования 4+2 (4 части данных + 2 чётности),
|
|
||||||
то при стандартном block_size образы разбиваются на части по 512 КБ.
|
|
||||||
- Клиентские запросы чтения/записи разделяются на части, соответствующие этим объектам.
|
|
||||||
- Для каждого объекта определяется номер PG, которой он принадлежит, путём простого взятия
|
|
||||||
остатка от деления ID образа и смещения на число PG в пуле, которому принадлежит образ.
|
|
||||||
- Клиент читает информацию о первичном OSD всех PG из etcd. Первичный OSD каждой PG назначается
|
|
||||||
монитором в процессе работы кластера, вместе с текущим целевым набором OSD этой PG.
|
|
||||||
- Клиент соединяется (если ещё не соединён) с первичными OSD всех PG, объекты которых участвуют
|
|
||||||
в запросе и одновременно отправляет им запросы чтения/записи частей.
|
|
||||||
- Если какие-то из первичных OSD недоступны, клиент повторяет попытки соединения бесконечно до
|
|
||||||
тех пор, пока они не станут доступны или пока PG не будут назначены другие первичные OSD.
|
|
||||||
- Клиент также повторяет запросы, если первичные OSD отвечают кодом ошибки EPIPE, означающим,
|
|
||||||
что запрос не может быть обработан в данный момент. Это происходит, если PG либо не активна
|
|
||||||
вообще, либо не активна на данном OSD в данный момент (например, если в этот момент меняется
|
|
||||||
её первичный OSD) или если в процессе обработки запроса сам первичный OSD теряет подключение
|
|
||||||
к репликам.
|
|
||||||
- Первичный OSD определяет, на каких OSD находятся части объекта. По умолчанию все объекты
|
|
||||||
считаются находящимися на текущем целевом наборе OSD соответствующей PG, но какие-то могут
|
|
||||||
находиться на других OSD, если эти объекты деградированы или перемещены, или идёт процесс
|
|
||||||
ребаланса. Запросы для проверки по сети не отправляются, информация о местоположении всех
|
|
||||||
объектов рассчитывается первичным OSD при активации PG и хранится в памяти.
|
|
||||||
- Первичный OSD соединяется (если ещё не соединён) с вторичными OSD, на которых располагаются
|
|
||||||
части объекта, и отправляет им запросы чтения/записи, а также читает/пишет из/в своё локальное
|
|
||||||
хранилище, если сам входит в набор.
|
|
||||||
- После завершения всех вторичных операций чтения/записи первичный OSD отправляет ответ клиенту.
|
|
||||||
|
|
||||||
### Особенности обработки запросов
|
|
||||||
|
|
||||||
- Если в пуле используются коды коррекции ошибок и при этом часть OSD недоступна, первичный
|
|
||||||
OSD при чтении восстанавливает данные из оставшихся частей.
|
|
||||||
- Каждый объект имеет номер версии. При записи объекта первичный OSD сначала читает из номер
|
|
||||||
версии объекта. Так как первичный OSD обычно сам хранит копию или часть объекта, номер
|
|
||||||
версии обычно читается из памяти самого OSD. Однако, если ни одна часть обновляемого объекта
|
|
||||||
не находится на первичном OSD, для получения номера версии он обращается к одному из вторичных
|
|
||||||
OSD, на которых копия объекта есть. Обращения к диску при этом всё равно не происходит,
|
|
||||||
так как метаданные объектов, включая номер версии, все OSD хранят в памяти.
|
|
||||||
- Если в пуле используются коды коррекции ошибок, перед частичной записью объекта для вычисления
|
|
||||||
чётности зачастую требуется чтение частей объекта с вторичных OSD или с локального диска
|
|
||||||
самого первичного OSD.
|
|
||||||
- Также, если в пуле используются коды коррекции ошибок, для закрытия Write Hole применяется
|
|
||||||
двухфазный алгоритм записи: сначала на все вторичные OSD записывается новая версия частей
|
|
||||||
объекта, но при этом старая версия не удаляется, а потом, после получения подтверждения
|
|
||||||
успешной записи от всех вторичных OSD, новая версия фиксируется и разрешается удаление старой.
|
|
||||||
- Если в кластере не включён режим immediate_commit, то запросы записи, отправляемые клиентами,
|
|
||||||
не считаются зафиксированными на физических накопителях сразу. Для фиксации данных клиенты
|
|
||||||
должны отдельно отправлять запросы SYNC (отдельный от чтения и записи вид запроса),
|
|
||||||
а пока такой запрос не отправлен, считается, что записанные данные могут исчезнуть,
|
|
||||||
если соответствующий OSD упадёт. Поэтому, когда режим immediate_commit отключён, все
|
|
||||||
запросы записи клиенты копируют в памяти и при потере соединения и повторном соединении
|
|
||||||
с OSD повторяют из памяти. Скопированные в память данные удаляются при успешном fsync,
|
|
||||||
а чтобы хранение этих данных не приводило к чрезмерному потреблению памяти, клиенты
|
|
||||||
автоматически выполняют fsync каждые [client_dirty_limit](../config/layout-cluster.ru.md#client_dirty_limit)
|
|
||||||
записанных байт.
|
|
||||||
|
|
||||||
## Схожесть с Ceph
|
|
||||||
|
|
||||||
- В Vitastor тоже есть пулы (pools), PG, OSD, мониторы, домены отказы, дерево распределения (аналог crush-дерева).
|
|
||||||
- Vitastor тоже равномерно распределяет данные каждого образа по всем PG пула.
|
|
||||||
- Vitastor тоже транзакционный, то есть, каждая запись в кластер атомарна.
|
|
||||||
- У Vitastor OSD тоже есть журнал и метаданные и их тоже можно размещать на отдельном диске.
|
|
||||||
- Как и в Ceph, клиентская библиотека пытается дождаться восстановления работы
|
|
||||||
при любом полном или частичном отказе кластера, то есть, вы можете перезагрузить
|
|
||||||
хоть весь кластер разом, и клиенты не отключатся, только на время зависнут.
|
|
||||||
|
|
||||||
## Отличия от Ceph
|
|
||||||
|
|
||||||
- Vitastor в первую очередь сфокусирован на использовании с SSD: либо в кластерах на основе
|
|
||||||
только SSD, либо гибридных (HDD с журналами на SSD).
|
|
||||||
- Базовый слой Vitastor — простое блочное хранилище с блоками фиксированного размера, а не
|
|
||||||
объектное со сложной семантикой, как в Ceph (RADOS).
|
|
||||||
- PG в Vitastor эфемерны. Это означает, что они не хранятся на дисках и существуют только в
|
|
||||||
памяти работающих OSD.
|
|
||||||
- Vitastor OSD однопоточные и всегда такими останутся. Если вам нужно выделить больше 1 ядра
|
|
||||||
на 1 диск — создайте несколько OSD на разделах этого диска. Нужно это в основном для NVMe,
|
|
||||||
так как Vitastor не потребляет много ресурсов CPU.
|
|
||||||
- Метаданные всегда размещаются в памяти, благодаря чему никогда не тратится лишнее время
|
|
||||||
на чтение метаданных с диска. Объём метаданных линейно зависит от ёмкости диска и размера
|
|
||||||
блока хранилища (block_size, по умолчанию 128 КБ). С 128 КБ блоком потребление памяти
|
|
||||||
составляет примерно 512 МБ на 1 ТБ данных. Журналы по умолчанию тоже хранятся в памяти,
|
|
||||||
но в SSD-кластерах нужный размер журнала составляет всего 32 МБ, а в гибридных (SSD+HDD)
|
|
||||||
кластерах, в которых есть смысл делать журналы больше, можно отключить [inmemory_journal](../docs/config/osd.ru.md#inmemory_journal).
|
|
||||||
- В Vitastor нет внутреннего copy-on-write. Я считаю, что реализация CoW-хранилища гораздо сложнее,
|
|
||||||
поэтому сложнее добиться устойчиво хороших результатов. Возможно, в один прекрасный день
|
|
||||||
я придумаю красивый алгоритм для CoW-хранилища, но пока нет — внутреннего CoW в Vitastor не будет.
|
|
||||||
Всё это не относится к "внешнему" CoW (снапшотам и клонам).
|
|
||||||
- В Vitastor есть режим "ленивых fsync", в котором OSD группирует запросы записи перед сбросом их
|
|
||||||
на диск, что позволяет получить лучшую производительность с дешёвыми настольными SSD без конденсаторов
|
|
||||||
("Advanced Power Loss Protection" / "Capacitor-Based Power Loss Protection").
|
|
||||||
Тем не менее, такой режим всё равно медленнее использования нормальных серверных SSD и мгновенного
|
|
||||||
fsync, так как приводит к дополнительным операциям передачи данных по сети, поэтому рекомендуется
|
|
||||||
всё-таки использовать хорошие серверные диски, тем более, стоят они почти так же, как десктопные.
|
|
||||||
- Процессы восстановления оперируют отдельными объектами, а не целыми PG.
|
|
||||||
- "Мониторы" не хранят данные. Конфигурация и состояние кластера хранятся в 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 напрямую в конфигурации пулов.
|
|
||||||
|
|
||||||
## Принципы разработки
|
|
||||||
|
|
||||||
- Я люблю простые решения. Поэтому Vitastor простой и быстрый и всегда будет таковым.
|
|
||||||
- Я не против иногда изобрести велосипед, например, собственный простенький HTTP-клиент
|
|
||||||
для работы с etcd, вместо того, чтобы взять тяжёлую готовую библиотеку, ибо в данном
|
|
||||||
случае я точно уверен в том, что знаю, что делает код.
|
|
||||||
- Общепринятые практики написания C++ кода с RAII, наследованием, умными указателями
|
|
||||||
и так далее меня также не волнуют, поэтому если вы хотели увидеть здесь красивый
|
|
||||||
идиоматичный C++ код, вы, вероятно, пришли не по адресу.
|
|
||||||
- Из всех интерпретаторов скриптоты больше всех я люблю node.js, это самый быстрый в мире
|
|
||||||
интерпретатор, у него есть встроенная событийная машина, развитая инфраструктура и
|
|
||||||
приятный нейтральный C-подобный язык программирования. Поэтому Монитор реализован на node.js.
|
|
||||||
|
|
||||||
## Известные проблемы
|
|
||||||
|
|
||||||
- Удаление образов в деградированном кластере может в данный момент приводить к повторному
|
|
||||||
"появлению" удалённых объектов после поднятия отключённых OSD, причём в случае EC-пулов,
|
|
||||||
объекты могут появиться в виде "неполных". Если вы столкнётесь с такой ситуацией, просто
|
|
||||||
повторите запрос удаления. Исправление этой проблемы уже реализовано в ветке "epoch-deletions"
|
|
||||||
и вскоре будет включено в релиз.
|
|
||||||
|
|
@ -1,37 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → Introduction → Author and License
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](author.ru.md)
|
|
||||||
|
|
||||||
# Author and License
|
|
||||||
|
|
||||||
Copyright (c) Vitaliy Filippov (vitalif [at] yourcmc.ru), 2019+
|
|
||||||
|
|
||||||
Join Vitastor Telegram Chat: https://t.me/vitastor
|
|
||||||
|
|
||||||
All server-side code (OSD, Monitor and so on) is licensed under the terms of
|
|
||||||
Vitastor Network Public License 1.1 (VNPL 1.1), a copyleft license based on
|
|
||||||
GNU GPLv3.0 with the additional "Network Interaction" clause which requires
|
|
||||||
opensourcing all programs directly or indirectly interacting with Vitastor
|
|
||||||
through a computer network and expressly designed to be used in conjunction
|
|
||||||
with it ("Proxy Programs"). Proxy Programs may be made public not only under
|
|
||||||
the terms of the same license, but also under the terms of any GPL-Compatible
|
|
||||||
Free Software License, as listed by the Free Software Foundation.
|
|
||||||
This is a stricter copyleft license than the Affero GPL.
|
|
||||||
|
|
||||||
Please note that VNPL doesn't require you to open the code of proprietary
|
|
||||||
software running inside a VM if it's not specially designed to be used with
|
|
||||||
Vitastor.
|
|
||||||
|
|
||||||
Basically, you can't use the software in a proprietary environment to provide
|
|
||||||
its functionality to users without opensourcing all intermediary components
|
|
||||||
standing between the user and Vitastor or purchasing a commercial license
|
|
||||||
from the author 😀.
|
|
||||||
|
|
||||||
Client libraries (cluster_client and so on) are dual-licensed under the same
|
|
||||||
VNPL 1.1 and also GNU GPL 2.0 or later to allow for compatibility with GPLed
|
|
||||||
software like QEMU and fio.
|
|
||||||
|
|
||||||
You can find the full text of VNPL-1.1 in the file [VNPL-1.1.txt](../../VNPL-1.1.txt).
|
|
||||||
GPL 2.0 is also included in this repository as [GPL-2.0.txt](../../GPL-2.0.txt).
|
|
||||||
|
|
@ -1,37 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → Введение → Автор и лицензия
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](author.en.md)
|
|
||||||
|
|
||||||
# Автор и лицензия
|
|
||||||
|
|
||||||
Автор: Виталий Филиппов (vitalif [at] yourcmc.ru), 2019+
|
|
||||||
|
|
||||||
Заходите в Telegram-чат Vitastor: https://t.me/vitastor
|
|
||||||
|
|
||||||
Лицензия: VNPL 1.1 на серверный код и двойная VNPL 1.1 + GPL 2.0+ на клиентский.
|
|
||||||
|
|
||||||
VNPL - "сетевой копилефт", собственная свободная копилефт-лицензия
|
|
||||||
Vitastor Network Public License 1.1, основанная на GNU GPL 3.0 с дополнительным
|
|
||||||
условием "Сетевого взаимодействия", требующим распространять все программы,
|
|
||||||
специально разработанные для использования вместе с Vitastor и взаимодействующие
|
|
||||||
с ним по сети, под лицензией VNPL или под любой другой свободной лицензией.
|
|
||||||
|
|
||||||
Идея VNPL - расширение действия копилефта не только на модули, явным образом
|
|
||||||
связываемые с кодом Vitastor, но также на модули, оформленные в виде микросервисов
|
|
||||||
и взаимодействующие с ним по сети.
|
|
||||||
|
|
||||||
Таким образом, если вы хотите построить на основе Vitastor сервис, содержаший
|
|
||||||
компоненты с закрытым кодом, взаимодействующие с Vitastor, вам нужна коммерческая
|
|
||||||
лицензия от автора 😀.
|
|
||||||
|
|
||||||
На Windows и любое другое ПО, не разработанное *специально* для использования
|
|
||||||
вместе с Vitastor, никакие ограничения не накладываются.
|
|
||||||
|
|
||||||
Клиентские библиотеки распространяются на условиях двойной лицензии VNPL 1.0
|
|
||||||
и также на условиях GNU GPL 2.0 или более поздней версии. Так сделано в целях
|
|
||||||
совместимости с таким ПО, как QEMU и fio.
|
|
||||||
|
|
||||||
Вы можете найти полный текст VNPL 1.1 в файле [VNPL-1.1.txt](../../VNPL-1.1.txt),
|
|
||||||
а GPL 2.0 в файле [GPL-2.0.txt](../../GPL-2.0.txt).
|
|
||||||
|
|
@ -1,62 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → Introduction → Features
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](features.ru.md)
|
|
||||||
|
|
||||||
# Features
|
|
||||||
|
|
||||||
- [Server-side features](#server-side-features)
|
|
||||||
- [Plugins and tools](#plugins-and-tools)
|
|
||||||
- [Roadmap](#roadmap)
|
|
||||||
|
|
||||||
## Server-side features
|
|
||||||
|
|
||||||
- Basic part: highly-available block storage with symmetric clustering and no SPOF
|
|
||||||
- [Performance](../performance/comparison1.en.md) ;-D
|
|
||||||
- [Multiple redundancy schemes](../config/pool.en.md#scheme): 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 (parameters, pools and images)
|
|
||||||
- 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](../config/layout-cluster.en.md#immediate_commit)
|
|
||||||
- Per-OSD and per-image I/O and space usage statistics in etcd
|
|
||||||
- Snapshots and copy-on-write image clones
|
|
||||||
- [Write throttling to smooth random write workloads in SSD+HDD configurations](../config/osd.en.md#throttle_small_writes)
|
|
||||||
- [RDMA/RoCEv2 support via libibverbs](../config/network.en.md#rdma_device)
|
|
||||||
|
|
||||||
## Plugins and tools
|
|
||||||
|
|
||||||
- [Debian and CentOS packages](../installation/packages.en.md)
|
|
||||||
- [Image management CLI (vitastor-cli)](../usage/cli.en.md)
|
|
||||||
- Generic user-space client library
|
|
||||||
- [Native QEMU driver](../usage/qemu.en.md)
|
|
||||||
- [Loadable fio engine for benchmarks](../usage/fio.en.md)
|
|
||||||
- [NBD proxy for kernel mounts](../usage/nbd.en.md)
|
|
||||||
- [CSI plugin for Kubernetes](../installation/kubernetes.en.md)
|
|
||||||
- [OpenStack support: Cinder driver, Nova and libvirt patches](../installation/openstack.en.md)
|
|
||||||
- [Proxmox storage plugin and packages](../installation/proxmox.en.md)
|
|
||||||
- [Simplified NFS proxy for file-based image access emulation (suitable for VMWare)](../usage/nfs.en.md)
|
|
||||||
|
|
||||||
## Roadmap
|
|
||||||
|
|
||||||
The following features are planned for the future:
|
|
||||||
|
|
||||||
- Better OSD creation and auto-start tools
|
|
||||||
- Other administrative tools
|
|
||||||
- Web GUI
|
|
||||||
- OpenNebula plugin
|
|
||||||
- iSCSI proxy
|
|
||||||
- Multi-threaded client
|
|
||||||
- Faster failover
|
|
||||||
- Scrubbing without checksums (verification of replicas)
|
|
||||||
- Checksums
|
|
||||||
- Tiered storage (SSD caching)
|
|
||||||
- NVDIMM support
|
|
||||||
- Compression (possibly)
|
|
||||||
- Read caching using system page cache (possibly)
|
|
||||||
|
|
@ -1,62 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → Введение → Возможности Vitastor
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](features.en.md)
|
|
||||||
|
|
||||||
# Возможности Vitastor
|
|
||||||
|
|
||||||
- [Серверные функции](#серверные-функции)
|
|
||||||
- [Драйверы и инструменты](#драйверы-и-инструменты)
|
|
||||||
- [Планы развития](#планы-развития)
|
|
||||||
|
|
||||||
## Серверные функции
|
|
||||||
|
|
||||||
- Базовая часть - надёжное кластерное блочное хранилище без единой точки отказа
|
|
||||||
- [Производительность](../comparison1.ru.md) ;-D
|
|
||||||
- [Несколько схем отказоустойчивости](../config/pool.ru.md#scheme): репликация, XOR n+1 (1 диск чётности), коды коррекции ошибок
|
|
||||||
Рида-Соломона на основе библиотеки jerasure с любым числом дисков данных и чётности в группе
|
|
||||||
- Конфигурация через простые человекочитаемые JSON-структуры в etcd
|
|
||||||
- Автоматическое распределение данных по OSD, с поддержкой:
|
|
||||||
- Математической оптимизации для лучшей равномерности распределения и минимизации перемещений данных
|
|
||||||
- Нескольких пулов с разными схемами избыточности
|
|
||||||
- Дерева распределения, выбора OSD по тегам / классам устройств (только SSD, только HDD) и по поддереву
|
|
||||||
- Настраиваемых доменов отказа (диск/сервер/стойка и т.п.)
|
|
||||||
- Восстановление деградированных блоков
|
|
||||||
- Ребаланс, то есть перемещение данных между OSD (дисками)
|
|
||||||
- [Поддержка "ленивого" fsync (fsync не на каждую операцию)](../config/layout-cluster.ru.md#immediate_commit)
|
|
||||||
- Сбор статистики ввода/вывода в etcd
|
|
||||||
- Статистика операций ввода/вывода и занятого места в разрезе инодов
|
|
||||||
- Именование инодов через хранение их метаданных в etcd
|
|
||||||
- Снапшоты и copy-on-write клоны
|
|
||||||
- [Сглаживание производительности случайной записи в SSD+HDD конфигурациях](../config/osd.ru.md#throttle_small_writes)
|
|
||||||
- [Поддержка RDMA/RoCEv2 через libibverbs](../config/network.ru.md#rdma_device)
|
|
||||||
|
|
||||||
## Драйверы и инструменты
|
|
||||||
|
|
||||||
- [Пакеты для Debian и CentOS](../installation/packages.ru.md)
|
|
||||||
- [Консольный интерфейс управления образами (vitastor-cli)](../usage/cli.ru.md)
|
|
||||||
- Общая пользовательская клиентская библиотека для работы с кластером
|
|
||||||
- [Драйвер диска для QEMU](../usage/qemu.ru.md)
|
|
||||||
- [Драйвер диска для утилиты тестирования производительности fio](../usage/fio.ru.md)
|
|
||||||
- [NBD-прокси для монтирования образов ядром](../usage/nbd.ru.md) ("блочное устройство в режиме пользователя")
|
|
||||||
- [CSI-плагин для Kubernetes](../installation/kubernetes.ru.md)
|
|
||||||
- [Базовая поддержка OpenStack: драйвер Cinder, патчи для Nova и libvirt](../installation/openstack.ru.md)
|
|
||||||
- [Плагин для Proxmox](../installation/proxmox.ru.md)
|
|
||||||
- [Упрощённая NFS-прокси для эмуляции файлового доступа к образам (подходит для VMWare)](../usage/nfs.ru.md)
|
|
||||||
|
|
||||||
## Планы развития
|
|
||||||
|
|
||||||
- Более корректные скрипты разметки дисков и автоматического запуска OSD
|
|
||||||
- Другие инструменты администрирования
|
|
||||||
- Web-интерфейс
|
|
||||||
- Плагин для OpenNebula
|
|
||||||
- iSCSI-прокси
|
|
||||||
- Многопоточный клиент
|
|
||||||
- Более быстрое переключение при отказах
|
|
||||||
- Фоновая проверка целостности без контрольных сумм (сверка реплик)
|
|
||||||
- Контрольные суммы
|
|
||||||
- Поддержка SSD-кэширования (tiered storage)
|
|
||||||
- Поддержка NVDIMM
|
|
||||||
- Возможно, сжатие
|
|
||||||
- Возможно, поддержка кэширования данных через системный page cache
|
|
||||||
|
|
@ -1,95 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → Introduction → Quick Start
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](quickstart.ru.md)
|
|
||||||
|
|
||||||
# Quick Start
|
|
||||||
|
|
||||||
- [Preparation](#preparation)
|
|
||||||
- [Configure monitors](#configure-monitors)
|
|
||||||
- [Configure OSDs](#configure-osds)
|
|
||||||
- [Create a pool](#create-a-pool)
|
|
||||||
- [Check cluster status](#check-cluster-status)
|
|
||||||
- [Create an image](#create-an-image)
|
|
||||||
- [Install plugins](#install-plugins)
|
|
||||||
|
|
||||||
## Preparation
|
|
||||||
|
|
||||||
- Get some SATA or NVMe SSDs with capacitors (server-grade drives). You can use desktop SSDs
|
|
||||||
with lazy fsync, but prepare for inferior single-thread latency. Read more about capacitors
|
|
||||||
[here](../config/layout-cluster.en.md#immediate_commit).
|
|
||||||
- Get a fast network (at least 10 Gbit/s). Something like Mellanox ConnectX-4 with RoCEv2 is ideal.
|
|
||||||
- Disable CPU powersaving: `cpupower idle-set -D 0 && cpupower frequency-set -g performance`.
|
|
||||||
- [Install Vitastor packages](../installation/packages.en.md).
|
|
||||||
|
|
||||||
## Configure monitors
|
|
||||||
|
|
||||||
On the monitor hosts:
|
|
||||||
- Edit variables at the top of `/usr/lib/vitastor/mon/make-units.sh` to desired values.
|
|
||||||
- Create systemd units for the monitor and etcd: `/usr/lib/vitastor/mon/make-units.sh`
|
|
||||||
- Start etcd and monitors: `systemctl start etcd vitastor-mon`
|
|
||||||
|
|
||||||
## Configure OSDs
|
|
||||||
|
|
||||||
- Put etcd_address and osd_network into `/etc/vitastor/vitastor.conf`. Example:
|
|
||||||
```
|
|
||||||
{
|
|
||||||
"etcd_address": ["10.200.1.10:2379","10.200.1.11:2379","10.200.1.12:2379"],
|
|
||||||
"osd_network": "10.200.1.0/24"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
- Initialize OSDs:
|
|
||||||
- Simplest, SSD-only: `/usr/lib/vitastor/mon/make-osd.sh /dev/disk/by-partuuid/XXX [/dev/disk/by-partuuid/YYY ...]`
|
|
||||||
**Warning!** This very simple script by default makes units for server-grade SSDs with write-through cache!
|
|
||||||
If it's not your case, you MUST remove disable_data_fsync and immediate_commit from systemd units.
|
|
||||||
- Hybrid, HDD+SSD: `/usr/lib/vitastor/mon/make-osd-hybrid.js /dev/sda /dev/sdb ...` — pass all your
|
|
||||||
devices (HDD and SSD) to this script — it will partition disks and initialize journals on its own.
|
|
||||||
This script skips HDDs which are already partitioned so if you want to use non-empty disks for
|
|
||||||
Vitastor you should first wipe them with `wipefs -a`. SSDs with GPT partition table are not skipped,
|
|
||||||
but some free unpartitioned space must be available because the script creates new partitions for journals.
|
|
||||||
- You can change OSD configuration in units or in `vitastor.conf`.
|
|
||||||
Check [Configuration Reference](../config.en.md) for parameter descriptions.
|
|
||||||
- If all your drives have capacitors, create global configuration in etcd: \
|
|
||||||
`etcdctl --endpoints=... put /vitastor/config/global '{"immediate_commit":"all"}'`
|
|
||||||
- Start all OSDs: `systemctl start vitastor.target`
|
|
||||||
|
|
||||||
## Create a pool
|
|
||||||
|
|
||||||
Create pool configuration in etcd:
|
|
||||||
|
|
||||||
```
|
|
||||||
etcdctl --endpoints=... put /vitastor/config/pools '{"1":{"name":"testpool",
|
|
||||||
"scheme":"replicated","pg_size":2,"pg_minsize":1,"pg_count":256,"failure_domain":"host"}}'
|
|
||||||
```
|
|
||||||
|
|
||||||
For jerasure pools the configuration should look like the following:
|
|
||||||
|
|
||||||
```
|
|
||||||
etcdctl --endpoints=... put /vitastor/config/pools '{"2":{"name":"ecpool",
|
|
||||||
"scheme":"jerasure","pg_size":4,"parity_chunks":2,"pg_minsize":2,"pg_count":256,"failure_domain":"host"}`
|
|
||||||
```
|
|
||||||
|
|
||||||
After you do this, one of the monitors will configure PGs and OSDs will start them.
|
|
||||||
|
|
||||||
## Check cluster status
|
|
||||||
|
|
||||||
`vitastor-cli status`
|
|
||||||
|
|
||||||
Or you can check PG states with `etcdctl --endpoints=... get --prefix /vitastor/pg/state`. All PGs should become 'active'.
|
|
||||||
|
|
||||||
## Create an image
|
|
||||||
|
|
||||||
Use vitastor-cli ([read CLI documentation here](../usage/cli.en.md)):
|
|
||||||
|
|
||||||
```
|
|
||||||
vitastor-cli create -s 10G testimg
|
|
||||||
```
|
|
||||||
|
|
||||||
After that, you can [run benchmarks](../usage/fio.en.md) or [start QEMU manually](../usage/qemu.en.md) with this image.
|
|
||||||
|
|
||||||
## Install plugins
|
|
||||||
|
|
||||||
- [Proxmox](../installation/proxmox.en.md)
|
|
||||||
- [OpenStack](../installation/openstack.en.md)
|
|
||||||
- [Kubernetes CSI](../installation/kubernetes.en.md)
|
|
||||||
|
|
@ -1,103 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → Введение → Быстрый старт
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](quickstart.en.md)
|
|
||||||
|
|
||||||
# Быстрый старт
|
|
||||||
|
|
||||||
- [Подготовка](#подготовка)
|
|
||||||
- [Настройте мониторы](#настройте-мониторы)
|
|
||||||
- [Настройте OSD](#настройте-osd)
|
|
||||||
- [Создайте пул](#создайте-пул)
|
|
||||||
- [Проверьте состояние кластера](#проверьте-состояние-кластера)
|
|
||||||
- [Создайте образ](#создайте-образ)
|
|
||||||
- [Установите плагины](#установите-плагины)
|
|
||||||
|
|
||||||
## Подготовка
|
|
||||||
|
|
||||||
- Возьмите серверы с SSD (SATA или NVMe), желательно с конденсаторами (серверные SSD). Можно
|
|
||||||
использовать и десктопные SSD, включив режим отложенного fsync, но производительность будет хуже.
|
|
||||||
О конденсаторах читайте [здесь](../config/layout-cluster.ru.md#immediate_commit).
|
|
||||||
- Возьмите быструю сеть, минимум 10 гбит/с. Идеал - что-то вроде Mellanox ConnectX-4 с RoCEv2.
|
|
||||||
- Для лучшей производительности отключите энергосбережение CPU: `cpupower idle-set -D 0 && cpupower frequency-set -g performance`.
|
|
||||||
- [Установите пакеты Vitastor](../installation/packages.ru.md).
|
|
||||||
|
|
||||||
## Настройте мониторы
|
|
||||||
|
|
||||||
На хостах, выделенных под мониторы:
|
|
||||||
- Пропишите нужные вам значения в файле `/usr/lib/vitastor/mon/make-units.sh`
|
|
||||||
- Создайте юниты systemd для etcd и мониторов: `/usr/lib/vitastor/mon/make-units.sh`
|
|
||||||
- Запустите etcd и мониторы: `systemctl start etcd vitastor-mon`
|
|
||||||
- Пропишите 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"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
## Настройте OSD
|
|
||||||
|
|
||||||
- Пропишите 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"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
- Инициализуйте OSD:
|
|
||||||
- SSD: `/usr/lib/vitastor/make-osd.sh /dev/disk/by-partuuid/XXX [/dev/disk/by-partuuid/YYY ...]`. \
|
|
||||||
**Внимание!** Скрипт по умолчанию рассчитан на то, что у вас диски с конденсаторами и отключённым
|
|
||||||
кэшем! Если это не так, из юнитов systemd нужно убрать строчки disable_data_fsync и immediate_commit!
|
|
||||||
- Гибридные, HDD+SSD: `/usr/lib/vitastor/mon/make-osd-hybrid.js /dev/sda /dev/sdb ...` - передайте
|
|
||||||
все ваши SSD и HDD скрипту в командной строке подряд, скрипт автоматически выделит разделы под
|
|
||||||
журналы на SSD и данные на HDD. Скрипт пропускает HDD, на которых уже есть разделы
|
|
||||||
или вообще какие-то данные, поэтому если диски непустые, сначала очистите их с помощью
|
|
||||||
`wipefs -a`. SSD с таблицей разделов не пропускаются, но так как скрипт создаёт новые разделы
|
|
||||||
для журналов, на SSD должно быть доступно свободное нераспределённое место.
|
|
||||||
- Вы можете менять параметры OSD в юнитах systemd или в `vitastor.conf`. Описания параметров
|
|
||||||
смотрите в [справке по конфигурации](../config.ru.md).
|
|
||||||
- Если все ваши диски - серверные с конденсаторами, пропишите это в глобальную конфигурацию в etcd: \
|
|
||||||
`etcdctl --endpoints=... put /vitastor/config/global '{"immediate_commit":"all"}'`
|
|
||||||
- Запустите все OSD: `systemctl start vitastor.target`
|
|
||||||
|
|
||||||
## Создайте пул
|
|
||||||
|
|
||||||
Создайте конфигурацию пула с помощью etcdctl:
|
|
||||||
|
|
||||||
```
|
|
||||||
etcdctl --endpoints=... put /vitastor/config/pools '{"1":{"name":"testpool",
|
|
||||||
"scheme":"replicated","pg_size":2,"pg_minsize":1,"pg_count":256,"failure_domain":"host"}}'
|
|
||||||
```
|
|
||||||
|
|
||||||
Для пулов с кодами коррекции ошибок конфигурация должна выглядеть примерно так:
|
|
||||||
|
|
||||||
```
|
|
||||||
etcdctl --endpoints=... put /vitastor/config/pools '{"2":{"name":"ecpool",
|
|
||||||
"scheme":"jerasure","pg_size":4,"parity_chunks":2,"pg_minsize":2,"pg_count":256,"failure_domain":"host"}`
|
|
||||||
```
|
|
||||||
|
|
||||||
После этого один из мониторов должен сконфигурировать PG, а OSD должны запустить их.
|
|
||||||
|
|
||||||
## Проверьте состояние кластера
|
|
||||||
|
|
||||||
`vitastor-cli status`
|
|
||||||
|
|
||||||
Либо же вы можете проверять состояние PG прямо в etcd: `etcdctl --endpoints=... get --prefix /vitastor/pg/state`. Все PG должны быть 'active'.
|
|
||||||
|
|
||||||
## Создайте образ
|
|
||||||
|
|
||||||
Используйте vitastor-cli ([смотрите документацию CLI здесь](../usage/cli.ru.md)):
|
|
||||||
|
|
||||||
```
|
|
||||||
vitastor-cli create -s 10G testimg
|
|
||||||
```
|
|
||||||
|
|
||||||
После этого вы можете [запускать тесты](../usage/fio.ru.md) или [вручную запускать QEMU](../usage/qemu.ru.md) с новым образом.
|
|
||||||
|
|
||||||
## Установите плагины
|
|
||||||
|
|
||||||
- [Proxmox](../installation/proxmox.ru.md)
|
|
||||||
- [OpenStack](../installation/openstack.ru.md)
|
|
||||||
- [Kubernetes CSI](../installation/kubernetes.ru.md)
|
|
||||||
|
|
@ -1,108 +0,0 @@
|
||||||
[Documentation](../../README.md#documentation) → Performance → Example Comparison with Ceph
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Читать на русском](comparison1.ru.md)
|
|
||||||
|
|
||||||
# Example Comparison with Ceph
|
|
||||||
|
|
||||||
- [Test environment](#test-environment)
|
|
||||||
- [Raw drive performance](#raw-drive-performance)
|
|
||||||
- [2 replicas](#2-replicas)
|
|
||||||
- [Ceph 15.2.4 (Bluestore)](#ceph-15-2-4-bluestore)
|
|
||||||
- [Vitastor 0.4.0 (native)](#vitastor-0-4-0-native)
|
|
||||||
- [Vitastor 0.4.0 (NBD)](#vitastor-0-4-0-nbd)
|
|
||||||
- [EC/XOR 2+1](#ec/xor-2-1)
|
|
||||||
- [Ceph 15.2.4](#ceph-15-2-4)
|
|
||||||
- [Vitastor 0.4.0](#vitastor-0-4-0)
|
|
||||||
|
|
||||||
## Test environment
|
|
||||||
|
|
||||||
Hardware configuration: 4 nodes, each with:
|
|
||||||
- 6x SATA SSD Intel D3-S4510 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).
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
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`.
|
|
||||||
|
|
||||||
## 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
|
|
||||||
|
|
||||||
## 2 replicas
|
|
||||||
|
|
||||||
### 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
|
|
||||||
|
|
||||||
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 0.4.0 (native)
|
|
||||||
|
|
||||||
- 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
|
|
||||||
|
|
||||||
### Vitastor 0.4.0 (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-threaded 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)
|
|
||||||
|
|
||||||
## EC/XOR 2+1
|
|
||||||
|
|
||||||
### Ceph 15.2.4
|
|
||||||
|
|
||||||
- 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
|
|
||||||
|
|
||||||
### Vitastor 0.4.0
|
|
||||||
|
|
||||||
- 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
|
|
||||||
|
|
@ -1,113 +0,0 @@
|
||||||
[Документация](../../README-ru.md#документация) → Производительность → Пример сравнения с Ceph
|
|
||||||
|
|
||||||
-----
|
|
||||||
|
|
||||||
[Read in English](comparison1.en.md)
|
|
||||||
|
|
||||||
# Пример сравнения с Ceph
|
|
||||||
|
|
||||||
- [Описание стенда](#описание-стенда)
|
|
||||||
- [Производительность голых дисков](#производительность-голых-дисков)
|
|
||||||
- [2 реплики](#2-реплики)
|
|
||||||
- [Ceph 15.2.4 (Bluestore)](#ceph-15-2-4-bluestore)
|
|
||||||
- [Vitastor 0.4.0 (нативный драйвер fio)](#vitastor-0-4-0-нативный-драйвер-fio)
|
|
||||||
- [Vitastor 0.4.0 (NBD)](#vitastor-0-4-0-nbd)
|
|
||||||
- [EC/XOR 2+1](#ec/xor-2-1)
|
|
||||||
- [Ceph 15.2.4](#ceph-15-2-4)
|
|
||||||
- [Vitastor 0.4.0](#vitastor-0-4-0)
|
|
||||||
|
|
||||||
## Описание стенда
|
|
||||||
|
|
||||||
Железо: 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 КБ блоками (если явно не указано обратное).
|
|
||||||
|
|
||||||
Тесты в 8 потоков проводились на 8 400GB RBD образах со всех хостов (с каждого хоста запускалось 2 процесса fio).
|
|
||||||
Это нужно потому, что в Ceph несколько RBD-клиентов, пишущих в 1 образ, очень сильно замедляются.
|
|
||||||
|
|
||||||
Настройки RocksDB и Bluestore в Ceph не менялись, единственным изменением было отключение cephx_sign_messages.
|
|
||||||
|
|
||||||
Тест на чтение в 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`.
|
|
||||||
|
|
||||||
## Производительность голых дисков
|
|
||||||
|
|
||||||
- T1Q1 запись ~27000 iops (задержка ~0.037ms)
|
|
||||||
- T1Q1 чтение ~9800 iops (задержка ~0.101ms)
|
|
||||||
- T1Q32 запись ~60000 iops
|
|
||||||
- T1Q32 чтение ~81700 iops
|
|
||||||
|
|
||||||
## 2 реплики
|
|
||||||
|
|
||||||
### 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 ядер на каждом сервере
|
|
||||||
|
|
||||||
Если не учитывать как обычно запредельное потребление CPU (40 ядер), не так уж и плохо для Ceph.
|
|
||||||
Данные серверы - как раз хороший пример сбалансированных Ceph-нод - 6 SATA SSD как раз
|
|
||||||
утилизируют 25-гигабитную сеть, а без 2 мощных процессоров Ceph-у бы не хватило ядер,
|
|
||||||
чтобы выдать пристойный результат.
|
|
||||||
|
|
||||||
### Vitastor 0.4.0 (нативный драйвер fio)
|
|
||||||
|
|
||||||
- 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 МБ/с
|
|
||||||
|
|
||||||
### Vitastor 0.4.0 (NBD)
|
|
||||||
|
|
||||||
NBD расшифровывается как "сетевое блочное устройство", но на самом деле оно также
|
|
||||||
работает просто как аналог FUSE для блочных устройств, то есть, представляет собой
|
|
||||||
"блочное устройство в пространстве пользователя".
|
|
||||||
|
|
||||||
NBD - на данный момент единственный способ монтировать Vitastor ядром Linux. Его
|
|
||||||
производительность немного хуже из-за дополнительных операций копирований данных
|
|
||||||
между ядром и пространством пользователя, что, правда, в основном затрагивает линейное
|
|
||||||
чтение/запись, а не случайный доступ.
|
|
||||||
|
|
||||||
- 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)
|
|
||||||
|
|
||||||
## EC/XOR 2+1
|
|
||||||
|
|
||||||
### Ceph 15.2.4
|
|
||||||
|
|
||||||
- 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 МБ/с
|
|
||||||
|
|
||||||
### Vitastor 0.4.0
|
|
||||||
|
|
||||||
- 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 МБ/с
|
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue