Sheepdog

Sheepdog — масштабируемая система, которая предоставляет виртуальным машинам распределенные блочные устройства. Его развитие началось в 2009 году разработчиками из японской компании Nippon Telegraph and Telephone Corporation. Sheepdog — это приложение с открытым исходным кодом под лицензией GPL2. Последняя версия 0.9.3, выпущенная в ноябре 2015 года станет наследиком версии 1.0, пригодной для коммерческого испрользования¹. (уже стала — прим.пер.)

Чисто ради интереса, первая версия (0.1.0), была выпущена разработчиками в августе 2010 года — и в то же время поддержка sheepdog сразу была включена в основную ветку разработки QEMU.
Первые испытания над sheepdog я провел в ноябре 2011 года² и результаты были неплохими для операций ввода-вывода. Однако тогда еще система Sheepdog имела проблемы с восстановлением упавшей ноды. Вероятно эта проблема вскоре была устранена, так как разработка приложения довольно живая, но на тот момент я использовал другое решение.

Возможности

Принцип работы Sheepdog очень хорошо описан в опубликованной презентации, поэтому я ограничусь лишь кратким обзором.

Он масштабируемый
Объем кластера может быть произвольно увеличен как на уровне ноды, увеличивая емкость и место под данные во время работы, так и путем увеличиния числа нод. Чем больше нод, тем выше производительность ввода-вывода VDI.

Он простой
В отличие от других систем, таких как CEPH, Sheepdog работает не напрямую с файловой системой а оперирует блоками фиксированного размера, поэтому не требует отдельных демонов для обслуживания метаданных. Все управление выполняется с помощью единственного инструмента dog, который напрямую связывается с овечками (sheep)
(ceph тоже использует объекты — прим.пер.)

Вычисляет упавшую ноду
Каждый VDI состоит из этих блоков (объектов), которые реплицируются одновременно на несколько нод, поэтому, если одна из них падает, данные остаются доступны, а объекты с упавшей ноды начнут реплицироваться на другую ноду.

Поддерживает снапшоты на уровне блочного устройства
Снапшоты в Sheepdog работают так же, как и в Btrfs. Заснапшоченные блоки VDI сохраняются, а новые данные записываются в новые блоки.

Следующие функции могут быть проблематичными при определенных обстоятельствах:

Sheepdog не поддерживает SPOF
Если VDI используется как блочное-устройство через QEMU, может возникнуть проблема, если он одновременно будет подключен в нескольких местах. Этому мог бы помешать SPOF³, которого у Sheepdog нет. Однако в новой версии Sheepdog VDI можно заблокировать, чтобы не разрешать более одного соединения.

Жизненный цикл объектов данных
Объекты VDI могут быть удалены только при удалении всех клонов и снапшотов, связанных с ними. Это точно так же, как и для Btrfs. Поэтому удалить неиспользуемые снапшоты может быть недостаточно, чтобы освободить место для хранения.

Демон коммуникации

Sheepdog смехотворно мал по сравнению с Ceph или GlusterFS. Это потому, что он не пытается решить все задачи сам, а по максимуму использует то, что уже работает.

В свою очередь, он предоставляет блочное устройство, которое может использоваться как физический диск, так и программный рейд и т.д.

Он заботится только о распределении объектов данных между нодами, на которых он запущен.

Однако ему необходима информация, которую предоставляет демон коммуникации — ключевой компонент, без которого Sheepdog работать не будет.

Демон коммуникации — не предоставляет возможность обмена данными между нодами. Это то, о чем занимаются sheep-демоны. Через него sheeps только узнает, какие ноды в настоящее время живы.

corosync

В первую очередь Sheepdog предполагает, что ноды будут общаться друг с другом через corosync. Он поддерживает до 64 нод, хотя теоретически он должен иметь возможность обслуживать больше, его использование оптимально для небольших кластеров до 16 нод.

Как правило, corosync также использует Pacemaker, поэтому нет необходимости устанавливать что-либо еще.

Установка corosync на Debian

Corosync есть в репозиториях дистрибутива, и его установка проста:

$ apt-get install corosync libcorosync-common4

Настройка corosync

zookeeper

Разработчики Sheepdog рекомендуют использовать zookeeper для более крупных кластеров. По словам разработчиков, было построено и протестировано тестовое хранилище Sheepdog с 1000 нодами⁴.

Установка zookeeper на Debian

$ apt-get install zookeeper zookeeperd

Запуск демона..

$ /usr/share/zookeeper/bin/zkServer.sh start

Порт по умолчанию, на котором работает zookeeper — 2181

Запуск sheepdog с поддержкой zookeeper:

$ sheep -c zookeeper:IP1:PORT1,IP2:PORT2,IP3:PORT3 ...other...option...

Бонусом zookeeper является то, что в его случае Sheepdog имеет более четкую и более легкую конфигурацию нод, но есть проблема в том, что установочный пакет Debian не включает его поддержку.

Поэтому, что бы получить Sheepdog с поддержкой zookeeper, придется компировать его из исходного кода. Хотя я не могу исключить, что в настоящее время ситуация может быть иной.
(поддержка zookeeper по прежнему требует компиляции из исходников — прим.пер.)

Настройка демона sheep

Нода становится частью Sheepdog, когда запускается диспетчер объектов — демон sheep. Он всегда работает в двух экземплярах:

1. Первый экземпляр процесса запускается как шлюз (Gateway), который принимает запросы ввода-вывода от клиентов (например, от драйверов блочных устройств QEMU), вычисляет целевые узлы и передает запросы для дальнейшей обработки между ними. То есть устанавливает множество сетевых подключений.

   
   
2. Другой работает как локальный диспетчер объектов (Object Manager)

Параметры конфигурации демона sheep могут быть переданы в качестве аргументов командной строки при выполнении. Если их нет будут использованны значения по умолчанию, с которыми вы должны быть осторожны:

Номер порта
Если не указано иное, демон sheep работает на порте 7000

Путь к хранилищу
Если не указано иное, каталог shep использует каталог /var/lib/sheepdog, а объекты VDI хранятся в его подкаталоге obj.

Теоретически ничто не мешает нескольким экземплярам sheep работать на одном узле — основное условие состоит в том, что бы каждый использовал свой номер порта и собственное хранилище. Вопрос IP-адреса ноды практически решен. Каждый запущенный экземпляр демона sheep, работающий на другом порту, автоматически подключится к существующему кластеру!

Важная информация заключается в том, что номер порта является частью конфигурации VDI-контейнера. Вам нужно знать, хотите ли вы изменить конфигурацию демона sheep для запуска на другом порту существующего кластера.

По этому если вы запустите экземпляр sheep демона с другим номером порта, но с тем же путем к хранилищу объектов, вы можете потерять информацию в существующих контейнерах VDI.

Демон sheep как шлюз

На машинах, не имеющих места для хранения объектов VDI, демон sheep можно запускать исключительно в режиме шлюза, с флагом -G.

В этом случае при распространении объектов VDI локальное хранилище не будет использоваться вообще, и данные будут распределены непосредственно на другие ноды.

Демон sheep как менеджер объектов

Второй запущенный инстанс, работает как локальный диспетчер объектов, принимает запросы ввода-вывода из инстанса, который запускается как шлюз, и выполняет r/w операции в локальном хранилище объектов (Object storage)

Хранилище объектов

По умолчанию хранилищем для объектов VDI в Sheepdog является каталог /var/lib/sheepdog/obj, который так же используется демоном sheep как часть его внутренней структуры каталогов — это путь хранилища по умолчанию.

Если вы хотите, чтобы объекты VDI хранились в другом месте, вы можете передать путь, куда смонтированно другое блочное стройство, в качестве параметра при запуске.

sheep ... /cesta_do_přípojného_bodu

Путей можно передать еще больше. Новая версия Sheepdog поддерживает так называемую технологию multi-device, которая позволяет динамически увеличивать емкость памяти, если это необходимо, без необходимости перезапуска Sheepdog. Увеличение емкости для хранения работает подобно Btrfs.

sheep ... /cesta_do_A,/cesta_do_B,/cesta_do_C

(первый указанный каталог будет использоваться только под метаданные — прим.пер)

Дополнительное хранилище можно также добавить (или удалить) через dog node md

...

Функциональность, предлагаемая multi-device особенно полезна, когда файловая система хранилища не поддерживает этого "by design" (в отличии от Btrfs или ZFS). В целом, выбор файловой системы под хранение объектов, их свойств, параметров и настроек может существенно повлиять на производительность IO файловой системы виртуальной машины.

Технология multi-device требует расширенных атрибутов со стороны файловой стороны, что не является проблемой для современных файловых систем, таких как btrfs⁵ или ext4. Но некоторые старые файловые системы, такие как reiserfs или ext2⁶, не поддерживают их.

Если вы хотите использовать файловую систему, которая не поддерживает расширенные атрибуты для хранения объектов, нам необходимо скомпилировать Sheepdog без поддержки multi-device.

Тип хранилища — plain versus tree

При форматировании кластера, среди прочих опций можно указать тип хранилища (backend storage). Вы можете установить тип plain или tree. Для типа plain структура каталогов будет выглядеть так:

|
|- obj
|    |- <id эпохи>
|    |          |-<идентификатор объекта>
|    |          |-<идентификатор объекта>
|    |          |-<идентификатор объекта>
|    |          |- ...
|    |- <id следующей эпохи>
|    | ...
|- config [идентификатор]
|- epoch
|    |- <файл эпохи>
|    |- <файл эпохи>
|    |- ...
|- journal
\- sheep.log [лог]

Все VDI объекты в каталоге obj будет отправлены в подкаталог, имя которого основано на текущем идентификаторе эпохи. То есть для каждой эпохи соответствующие объекты VDI будут храниться отдельно. Однако в течение одной эпохи в каталоге может появиться большое количество VDI объектов, которые в последствии замедляют доступ к файлам. Поэтому вы можете выбрать второй вариант, которым является tree:

|- obj
|    |- aa
|    |   |-<идентификатор объекта>
|    |   |-<идентификатор объекта>
|    |   |-<идентификатор объекта>
|    |   |- ...
|    |- ab
|    | ...
|    |- meta
|    |    |- <файл метаданных>
|    |    |- ...
|    |- 0a
|    | ...
|- config [идентификатор]
|- epoch
|    |- <файл эпохи>
|    |- <файл эпохи>
|    |- ...
\- sheep.log [лог]

В этом типе хранилища демон sheep создает набор из 256 поддиректорий с именами 0a, ..., 99 в каталоге obj, а затем разбрасывает объекты на основе двух последних символов VDI id, который уникален не только для каждого контейнера VDI но также и его снапшотов или клонов.

Имена VDI объектов

Когда Sheepdog сохраняет данные в контейнере VDI, в хранилище данных obj начнут появляться файлы, каждый будет иметь свое имя состоящее из нескольких элементов:

../obj/8f/00e8b18f00000005
          ^^

Первые два символа обозначают тип объекта. Объекты данных начинаются с 00... а метаданные (которые могут быть сохранены в другом каталоге) 80...

../obj/8f/00e8b18f00000005
            ^^^^^^        

Затем следует идентификатор VDI. Он уникален не только для каждого контейнера, но так же и для его снапшота или клона.

../obj/8f/00e8b18f00000005
       ^^       ^^

Последние две цифры VDI идентификатора указывают — в случае типа хранения tree — в котором находится подкаталог, к которому принадлежит объект.

../obj/8f/00e8b18f00000005
                  ^^^^^^^^

А за идентификатором VDI контейнера в шестнадцатеричной форме следует порядковый номер объекта в VDI контейнере

Эпоха

В подкаталоге epoch находятся бинарные списки объектов, принадлежащих эпохе. Номер эпохи увеличивается, каждый раз когда каждый кластер изменяется — когда добавляется или удаляется нода. Каждое такое изменение запустает процесс восстановления, в течение которого текущее состояние локальных объектов будет проверяться на нодах, за тем последует увеличение эпохи.

Как оптимально выбрать хранилище VDI объектов

Доступная емкость для хранения вычисляется на основе свободного места на нодах. Пространство выбираемое sheep, всегда зависит от того, сколько пространства доступно в блочном устройстве, где хранятся объекты VDI.

Размер VDI контейнера — это только виртуальная фигура, которая никоим образом не связана с тем, сколько пространства занимают объекты VDI. Важно знать, как Sheepdog обрабатывает данные в кластере:

Sheepdog всегда пытается сохранить данные равномерно между всеми машинами эпохи.

Это означает, что если одна из нод падает, эпоха изменится, и Sheepdog немедленно начнет процесс восстановления, он будет создавать недостающие объекты VDI на оставшихся нодах, чтобы компенсировать потерю.

Аналогичная ситуация возникнет при добавлении новой ноды. Sheepdog начнет равномерно перемещать VDI объекты с новых нод в свой репозиторий, так что процентное заполнение пространства данных на нодах будет максимально сбалансированно. Используйте следующую команду, чтобы получить глобальный обзор того, насколько использованно в настоящее время пространство на ваших нодах:

nod1 ~ # collie node md info -A
Id      Size    Used    Avail   Use%    Path
Node 0:
 0      1.1 TB  391 GB  720 GB   35%    /local/sheepdog-data/obj
Node 1:
 0      702 GB  394 GB  307 GB   56%    /local/sheepdog-data/obj
Node 2:
 0      794 GB  430 GB  364 GB   54%    /local/sheepdog-data/obj
Node 3:
 0      1.6 TB  376 GB  1.2 TB   22%    /local/sheepdog-data/obj
Node 4:
 0      1.2 TB  401 GB  838 GB   32%    /local/sheepdog-data/obj
Node 5:
 0      1.5 TB  370 GB  1.1 TB   24%    /local/sheepdog-data/obj
Node 6:
 0      1.6 TB  388 GB  1.2 TB   23%    /local/sheepdog-data/obj

Производительность I/O

Здесь важно сказать, что Sheepdog работает иначе чем Ceph, и имеет другие приоритеты.

Для Ceph "вес" OSD-устройства играет решающее значение при размещении объектов данных, так же как и производительность блочного устройства, подключение к хосту и скорость ответа. (на самом деле нет — прим.пер)

Делает ли что-то подобное Sheepdog, я не знаю. Возможно. Данные для него на первом месте. Производительность с точки зрения I/O операций является вторичной. Конечно, с более мощными узлами его I/O производительность может улучшиться, но всегда зависит от конкретной структуры. (однако тесты показывают более лучшую производительность sheepdog по сравнению с ceph — прим.пер)

Я добавил новую ноду в Sheepdog с данными, хранящимися на вращающемся 2TB SATA II диске. Максимальная скорость записи для этого диска составляет около 80M/s. На самом деле она сильно варьируется, потому что диски SATA не могут читать и писать одновременно.

Вначале средняя скорость записи на VDI на этом диске составляла около 20~30M/s, так как в дополнение к данным с VDI на нем реплицировалось 392G данных контейнера как часть процесса восстановления. Это продолжалось 6,5 часа. Скорость записи колебалась между 40~55M/s.

Совершенно очевидно, что в этом случае скорость записи была ограничена производительностью ввода-вывода локального блочного устройства.

Для Sheepdog применимо следующее правило: «Чем больше VDI объектов будет на нодах с быстрым соединением, тем лучше будет производитеьность I/O операций».

Из-за того, что перемещение объектов VDI происходит в фоновом режиме, означает, что «быстрая смерть ноды» замедлит репликацию тех объектов данных которые занимают больше всего места, это будет проявляться как снижение производительности I/O операций VDI контейнера

Занимаемое пространство

При размещении объектов данных объем свободного пространства является решающим для демона sheep. Механизм кажется простым. Демон sheep, через который осуществляется коммуникация данных с VDI-контейнером, время от времени определяет коэффициент использования свободного и занятого места на нодах, который сортирует. Затем данные распределяются по узлам с самым низким коэффициентом использования.

Если существует преимущественно быстрый путь записи, операция записи в VDI контейнер также будет быстрой. Поскольку чем быстрее выполняются I/O операции VDI контейнера, тем раньше sheep демон может перейти к следующей операции.

Важно то, что с Sheepdog не возникет ситуации, когда одна из нод будет полностью переполнена. Если коэффициент использования на узле становится значительно хуже, то sheep демон начинает перемещать свои объекты данных в другое место.

Sheepdog работает так же, как Btrfs — используя только действительно занятое место. Таким образом, вы можете создать виртуальный VDI контейнер объемом 1 ТБ, который фактически будет занимает столько же места сколько и хранимых в нем данных. С этой точки зрения в VDI контейнерах желательно использовать такие форматы виртуальных дисков и файловых систем, которые способны подчищать за друг за другом.

Запуск кластера

В то время как остановка всех нод может быть выполнена одновременно, ноды не могут быть запущены за один раз!!! Ноды следует подключать постепенно. Начиная с ноды, которая была впервые указан в списке узлов.
(вот это крайне странное утверждение — прим.пер)

VDI

Это общая аббревиатура в Sheepdog для обозначения виртуального диска, а не его конкретного формата⁷. В целом это виртуальная коробка с отсеками фиксированного размера, в которой Sheepdog затем помещает данные, которые передает клиент.

Создание VDI

Прежде чем мы создадим или импортируем первый VDI нам нужно отформатировать кластер. При форматировании кластера устанавливаются параметры, которые затем будут использоваться по умолчанию при создании каждого следующего VDI.

Пример демонстрирующий создание нового VDI с именем Disk1 и размером 1 ГБ

root@nod1 :~# collie vdi create disk1 1G
root@nod1 :~# collie vdi list
Name        Id    Size    Used  Shared    Creation time   VDI id  Copies  Tag   Block Size Shift
disk1        0  1.0 GB  0.0 MB  0.0 MB 2015-12-04 14:07   e8b18f      2                22

Id
VDI идентификатор

Size
Размер VDI, который не обязательно будет сразу заполнен (preallocated).
Если этот VDI находится в инкрементном формате (qcow2 и тому подобные), созданный с помощью qemu-img convert, он не будет соответствовать размеру виртуального диска, но он будет постоянно увеличиваться.

Used
Информация о том, сколько места занимают объекты данных VDI.
VDI, который не требует выделения объектов данных при создании, будет занимать нисколько, поскольку для него ещё не созданны объекты данных.

Shared
Объем объектов данных, которые совместно используются другими VDI

Creation time
Время создания VDI

Block size
Размер объекта VDI. Внимание! Он не указан в MB, а как степень от двух байтов. В старых версиях использовались только объекты размером 4 МБ фиксированного размера. В настоящее время VDI может иметь и более крупные объекты. Оптимальный размер для объекта VDI обычной виртуальной машины выглядит как 64MB (26). Размер по умолчанию 22 (4 МБ) также минимален. Меньше установить нельзя. Чем меньше размер объекта, тем большее количество файлов придется обрабатывать Sheepdog во вреия работы с VDI, а работа с файлами не является дешевой проблемой с точки зрения IO. Большое количество файлов, особенно с медленными контроллерами SATA, может привести к резкому ухудшению скорости чтения и записи. Максимальный размер объектов, которые могут быть использованы, составляет 31 (2 ГБ). Это может быть выгодно, если в VDI последовательно хранятся большое количество статических данных, таких как резервные копии.

VDI id
VDI идентификатор.

Что содержит VDI?

Содержимое VDI — это данные. Это распределенное блочное устройство, так что Sheepdog не решает полезны эти данные или мусор. С этой точки зрения VDI выглядит как логический том LVM. Предварительно заполненый VDI соответствует классическому LV-разделу с выделенным диапазоном, в то же время VDI напоминает и тонкий раздел LV, созданный в пуле (см. LVM (thin_provisioning)), но с той разницей, что экстенты данных (объекты) сохраняются не на локальные блочные устройства, а разбросаны между нодами.

Формат VDI работает в этой аналогии как файловая система. Одни занимают зарезервированные экстенты (объекты) последовательно, другие сопоставляют их как свои inodes, а затем отправляют данные непосредственно им. Неправильная комбинация файловой системы хранилища на нодох, формата VDI и внутренней файловой системы может привести к значительному ухудшению производительности ввода-вывода.

Как получить информацию о VDI

Что бы узнать больше о формате VDI можно использовать qemu-img info:

root@nod1 :~# qemu-img info sheepdog:localhost:8000:disk1
image: sheepdog:localhost:8000:test2
file format: qcow2
virtual size: 12G (12884901888 bytes)
disk size: 4.0G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Из вывода команды вы можете узнать, что disk1 имеет номинальный размер 12G. В настоящее время это занимает всего 4G. Поскольку он находится в формате qcow2, очевидно, что он был создан как инкрементный.

root@nod1 :~# collie vdi list
 Name        Id    Size    Used  Shared    Creation time   VDI id  Copies  Tag   Block Size Shift
 disk2        0  4.0 GB  4.0 GB  0.0 MB 2015-12-04 16:07   825dc1      2                31
root@nod1 :~# qemu-img info sheepdog:localhost:8000:disk2
image: sheepdog:localhost:8000:disk2
file format: raw
virtual size: 4.0G (4294967296 bytes)
disk size: 4.0G
root@nod1 :~# find /datastore/obj/ | grep 825dc1
/datastore/obj/meta/80825dc100000000
/datastore/obj/c1/00825dc100000000
/datastore/obj/c1/00825dc100000001

В этом случае Disk2 был создан как предварительно выделенный VDI размером 4 ГБ в формате raw с размером блока 2 ГБ, который фактически занимает только два 2 ГБ

Экспорт VDI в файл

Содержимое VDI можно экспортировать из Sheepdog несколькими способами. Возможно, самым быстрым является использование dog read. Команда немного запутанна, но просто означает: "Загрузить содержимое VDI и отправьте его в STDOUT ..", который можно перенаправить в файл:

root@nod1 :~# collie vdi read disk1 > /backups/soubor.raw

Если VDI имеет 10G, но использованно только 2G, он создаст файл с полным объемом 10 ГБ.

В этой команде содержимое VDI неизменно, поэтому если содержимое VDI, например, виртуальный диск в сжатом формате qcow2, можно использовать непосредственно

.. -drive file=file:/disk1_exportovany_z_vdi,..,format=qcow2 ..

Другой способ получить содержимое VDI в файл — использовать qemu-img convert. Это не так быстро, но позволяет конвертировать VDI в другой формат с использованием разных опций соответствующего формата виртуального диска.

root@nod1 :~# qemu-img convert -f qcow2 -O file -o preallocation=full,nocow=on sheepdog:localhost:8000:disk1 /disk1_exportovany_z_vdi

Инкрементное резервное копирование

Создание инкрементной резервной копии

Дельта между Первым и Вторым снапшотом ..

root@nod1 :~# collie vdi backup test -F snap1 -s snap2 /backups/soubor_diff

Восстановление VDI из инкрементной резервной копии

root@nod1 :~# collie vdi restore test -s snap1 /tmp/backup
  restoring /tmp/backup... done

При импорте инкрементной резервной копии VDI разумеется должен иметь снапшот, с которого была сделана резервная копия.

Проверка путем считывания исходного содержимого образа test ...

 root@nod1 :~# collie vdi read test 0 512 -s 3

Импорт VDI из файла

Импорт существующего виртуального диска в виде локального файла FS может быть выполнен аналогично экспорту. Но с той разницей, что используется dog write ("Чтение данных из STDIN и запись в файл VDI ..")

root@nod1 :~# collie vdi write disk1 < /backups/soubor.raw 

 

• Содержимое может быть импортировано только в существующий VDI.
• Импортированный VDI всегда занимает больше места, чем исходный файл, поскольку блоки данных, из которых восстановлен VDI, содержат данные на размеченной области.

Если VDI еще не существует и мы не знаем, сколько места потребуются для виртуального диска, мы можем использовать qemu-img convert

root@nod1 :~# qemu-img convert -f file -O qcow2 -o redundancy=2:1 ./disk_ukladany_do_vdi sheepdog:localhost:8000:disk

Хотя VDI-форматы, такие как qcow2, qed и другие могут использоваться в VDI. Для эффективности ввода-вывода лучше заранее выделять блоки данных.
Я также рекомендую делать это, потому что вы не будете иметь кучу Sheepdog проблем с проверкой целостности VDI.

http://www.sheepdog-project.org/doc/vdi_read_and_write.html

Проверка VDI

При проверке целостности VDI проверяется, находятся ли блоки данных на месте.

root@nod1 :~# collie vdi check disk1

Не запускайте проверку VDI, если его использует виртуальная машина. В новой версии Sheepdog это сделать уже невозможно, поскольку в нем уже используются блокировки. Однако она ведет себя странно, потому что каждая повторная проверка снова и снова исправляет некоторые несогласованные блоки.

ПРИМЕЧАНИЕ: мы использовали ‘dog node kill’ для удаления ноды из кластера, но вы можете просто выключить ее или выдернуть ethernet кабель, вручную убить sheep процесс и тому подобное. Если бы вы не хотели удалять ноду из кластера (скажем, вы вынули кабель Ethernet), попробуйте как можно скорее вставить его обратно запустить sheep демон. Это остановит восстановление данных на других узлах и быстро вернёт последние измененные данные на ноде.

IO производительность VDI

Производительность VDI зависит от многих факторов. Прежде всего от производительности контроллера и характеристик используемых блочных устройств. Чем медленнее контроллеры и диски на нодах, тем хуже IO производительность устройств VDI.

По умолчанию Sheepdog работает в режиме SYNC, который не предусматривает кэширование. Каждая операция ввода-вывода, которая не использует кеширование VFS, завершается только тогда, когда ядро получает сигнал от блочного устройства, что результат предыдущей операции был успешно сохранен.

В случае виртуальной машины которая использует VDI на Sheepdog это происходит только тогда, когда приходит информация о сохранении всех копий объекта на физические устройства нод. Однако эта операция может быть очень медленной для хранилищ с медленными дисками и контроллерами. Поэтому Sheepdog предлагает несколько вариантов для значительного улучшения производительности VDI-устройств.

Использование VFS-кэша ноды

Простейшим шагом для улучшения производительности IO для VDI является запуск на нодах демонов sheep с параметром -n. Это будет возвращать SYNC не когда данные будут фактически записаны на блочное устройство, а в момент, когда он будет передан для обработки в VFS ноды. Однако существует потенциальный риск того, что если VFS не сохранит, произойдет сбой ноды, в этом случае он будет потерян!

Однако в большинстве случаев это не является серьезной проблемой. Это может быть опасным только в тех случаях где запускаются виртуальные машины, которые хранят большое количество важных данных на регулярной основе — например, машины, которые обрабатывают финансовые транзакции.

 sheep -n ...

По умолчанию Sheepdog кэширует объекты в памяти перед сохранением. Это может быть отключено параметром -D

Объектный кэш

Другим способом повышения производительности ввода-вывода является объектный кеш. Здесь демон sheep будет записывать объекты непосредственно не в распределенное хранилище а на блок-устройство с быстрым IO — обычно SSD диск. Виртуальная машина, работающая с VDI, не должна ждать пока будет получен SYNC с других узлов. Затем распределение объектов и их хранение на других узлах реализуется с определенной задержкой.

Но у него есть один большой недостаток, если этот VDI должен использоваться на нескольких нодах, что как правило является типичным случаем для распределенного VDI в кластерной среде. Объекты, которые еще не успели перераспределиться, будут доступны только для узла, через который первоначально был подключен VDI.

sheep -w size=20000,directio,dir=/dir ...

size
Объем кэша

directio
При включении этого параметра sheep не записывает данные в оперативную память, а сразу же отправляет на диск. Это рекомендуемый выбор при использовании SSD.

dir

Путь к точке монтирования блочного устройства, которое используется как объектный кэш.

Состояние кеша объекта может быть проверено (и настроено) с помощью dog.

Если с другой ноды будет подклчение к VDI которое использует объектный кэш без выполнения на ней команды dog vd cashe flush, это может безвозвратно повредить VDI!

Журнал

Лучшее решение — использовать журналирование. В этом случае ноды не записывают данные непосредственно в объекты VDI, напротив они полагаются на VFS где они запущены, но запись данных происходит сначала во вновь созданный файл журнала (/store_dir/journal/[epoch]/[vdi_object_id]), который будет удален после того, как данные будут переписаны.

Увеличение производительности IO операций объясняется тем, что запись в объекты происходит не случайно (cik, cak), а последовательно (sequence).

Кроме того, Sheepdog позволяет хранить файлы журналов вне системы хранения VDI объектов, что может быть тем же устройством что и для кэшей объектов, например SSD-диск. Если нода выходит из строя, прежде чем данные будут перезаписанны в VDI объект на медленном хранилище, ничего страшного не произойдет потому что журнал может быть переписан постфактум, и в отличие от объектного кэша журнал не привязан к узлу с которого был подключен VDI.

Журналирование может быть включено через параметр демона sheep и может иметь различную форму — в любом случае необхдимо указать размер файла журнала

$ sheep -j size=256M ...

Если путь к хранилищу журналов не указан, журналы VDI будут храниться в том же хранилище, что и объекты данных. Однако ведение журнала влияет на производительность операций ввода-вывода, поэтому выгодно — если возможно — хранить его на блочном устройстве с лучшей производительностью ввода-вывода:

$ sheep -j dir=/dir,size=256M ...

Параметр dir = указывает не путь к блочному устройству, а точку монтирования к которой подключено это быстрое блочное устройство. Это не обязательно должно быть одноблочное устройство, это также может быть SW RAID из нескольких быстрых накопителей SSD.

Примечание: После перезапуска нода sheep первым делом пытается переписать данные, которые хранятся в журнале. В этом нет обязательной необходимости, поэтому мы можем использовать параметр skip, чтобы предотвратить это.

$ sheep -j dir=/dir,size=256M,skip ...

---

1. ^{↑ См. Информацию в конце презентации в июне 2015 г. http://events.linuxfoundation.jp/sites/events/files/slides/COJ2015_Sheepdog_20150604.pdf}
2. ^{↑ http://www.abclinuxu.cz/blog/kenyho_stesky/2011/11/sheepdog-hrajeme-si-v-hampejzu}
3. ^{↑ SPOF (Single point of failure) гарантирует, что есть только один аутентифицированный клиент который может подключиться к конкретному блочному устройству. Поддержка SPOF есть для VDI при экспорте iSCSI через tgtd}
4. ^{↑ 1}

5. ^{↑ Btrfs — это файловая система COW, которая в принципе значительно снижает вероятность того, что объект данных будет поврежден сбоем физического блока. С другой стороны, это значительно увеличивает накладные расходы ввода-вывода, делая копию для каждого измененного объекта. Однако это также может быть выгодным, поскольку объекты номинально одного размера, а их содержимое может быть более или менее сжато чтобы они занимали меньше места. И если их содержимое будет изменено, то последует новое сжатие которое приведет даннные к объему, который занимает оригинал. Это означает, что эти параметры будут утеряны:}

   
   

   ^{autodefrag — Экстенты с объектами настолько малы, что практически никакой фрагментации не может произойти ни с одним.}

   
   

   ^{Поскольку при изменении объекта происходит новое сжатие}

   
   

   ^{nocow — потому что в файловой системе он работает со целыми файлами (объектами), а не с их содержимым — как и в случае с доступом к блочному устройству через GlusterFS}

   
   

   ^{Преимущество Btrfs заключается в том, что он объединяет ряд вещей, которые проще решить в FS, но в последствии их должен заменить Sheepdog.}

   
   
   • ^{Он сохраняет согласованность объектов данных, уменьшая вероятность того, что найдется поврежденный объект, который будет необходимо восстановить из копии}
   • ^{Он поддерживает multipath, так что пространство для объектов данных может динамически расширяться или даже перемещаться на другие блочные устройства одновременно и без необходимости восстановления объектов с других нод.}
   
   

   ^{Это, конечно же, уменьшает количество необходимых операций для восстановления соединения узла, которое было отключено и повторно подключено к Sheepdog.}

   
   

6. ^{↑ Ext2. Если вы хотите использовать какие-нибудь другие FS вместо Btrfs, лучше всего использовать ext2, который использует фиксированную таблицу inode. Журналирование с использованием ext3 и ext4 в этом случае является контрпродуктивным. Если местоположение inode фиксировано, Sheepdog только заменяет содержимое соответствующего индексного дескриптора при изменении содержимого объекта. Примечательно, что это уменьшает количество операций ввода-вывода, связанных с записью. В случае физического инородного повреждения данные объекта будут поступать на том, но поскольку Sheepdog имеет копии объекта на других нодах, он может легко заменить этот поврежденный объект командой dog vdi check. Однако, недостатком ext2 является то, что такая файловая система не может динамически расширяться другими блочными устройствами — это может в какой-то мере быть заменено командой dog vdi md, которая позволяет разложить объекты одного устройства VDI на несколько физических блочных устройств.}

   
   
7. ^{↑ Форматы виртуальных дисков включая, но не ограничиваясь, vdi описаны на QEMU_Block_Disk}

Ссылки

https://github.com/collie/sheepdog/wiki — вики, которая является частью репозитория с исходными кодами
http://www.osrg.net/sheepdog/ — Сайт проекта в Nippon Telegraph and Telephone Corporation
http://www.sheepdog-project.org/doc/index.html — Руководство администратора Sheepdog для версии 0.8.0; автор — Valerio Pachera
http://www.admin-magazine.com/Archive/2014/23/Distributed-storage-with-Sheepdog — статья Udo Seidela о развертывании Sheepdog, опубликованная в 23-м номере журнала Admin в октябре 2014 года