Sheepdog — масштабируемая система, которая предоставляет виртуальным машинам распределенные блочные устройства. Его развитие началось в 2009 году разработчиками из японской компании Nippon Telegraph and Telephone Corporation. Sheepdog — это приложение с открытым исходным кодом под лицензией GPL2. Последняя версия 0.9.3, выпущенная в ноябре 2015 года станет наследиком версии 1.0, пригодной для коммерческого испрользования1. (уже стала — прим.пер.) Принцип работы Sheepdog очень хорошо описан в опубликованной презентации, поэтому я ограничусь лишь кратким обзором. Он масштабируемый
Объем кластера может быть произвольно увеличен как на уровне ноды, увеличивая емкость и место под данные во время работы, так и путем увеличиния числа нод. Чем больше нод, тем выше производительность ввода-вывода VDI. Он простой
В отличие от других систем, таких как CEPH, Sheepdog работает не напрямую с файловой системой а оперирует блоками фиксированного размера, поэтому не требует отдельных демонов для обслуживания метаданных. Все управление выполняется с помощью единственного инструмента dog, который напрямую связывается с овечками (sheep)
(ceph тоже использует объекты — прим.пер.) Вычисляет упавшую ноду
Каждый VDI состоит из этих блоков (объектов), которые реплицируются одновременно на несколько нод, поэтому, если одна из них падает, данные остаются доступны, а объекты с упавшей ноды начнут реплицироваться на другую ноду. Поддерживает снапшоты на уровне блочного устройства
Снапшоты в Sheepdog работают так же, как и в Btrfs. Заснапшоченные блоки VDI сохраняются, а новые данные записываются в новые блоки. Следующие функции могут быть проблематичными при определенных обстоятельствах: Sheepdog не поддерживает SPOF
Если VDI используется как блочное-устройство через QEMU, может возникнуть проблема, если он одновременно будет подключен в нескольких местах. Этому мог бы помешать SPOF3, которого у Sheepdog нет. Однако в новой версии Sheepdog VDI можно заблокировать, чтобы не разрешать более одного соединения. Жизненный цикл объектов данных
Объекты VDI могут быть удалены только при удалении всех клонов и снапшотов, связанных с ними. Это точно так же, как и для Btrfs. Поэтому удалить неиспользуемые снапшоты может быть недостаточно, чтобы освободить место для хранения. Sheepdog смехотворно мал по сравнению с Ceph или GlusterFS. Это потому, что он не пытается решить все задачи сам, а по максимуму использует то, что уже работает. В свою очередь, он предоставляет блочное устройство, которое может использоваться как физический диск, так и программный рейд и т.д. Он заботится только о распределении объектов данных между нодами, на которых он запущен. Однако ему необходима информация, которую предоставляет демон коммуникации — ключевой компонент, без которого Sheepdog работать не будет. Демон коммуникации — не предоставляет возможность обмена данными между нодами. Это то, о чем занимаются sheep-демоны. Через него sheeps только узнает, какие ноды в настоящее время живы. В первую очередь Sheepdog предполагает, что ноды будут общаться друг с другом через corosync. Он поддерживает до 64 нод, хотя теоретически он должен иметь возможность обслуживать больше, его использование оптимально для небольших кластеров до 16 нод. Как правило, corosync также использует Pacemaker, поэтому нет необходимости устанавливать что-либо еще. Corosync есть в репозиториях дистрибутива, и его установка проста: Разработчики Sheepdog рекомендуют использовать zookeeper для более крупных кластеров. По словам разработчиков, было построено и протестировано тестовое хранилище Sheepdog с 1000 нодами4. Запуск демона.. Порт по умолчанию, на котором работает zookeeper — 2181 Запуск sheepdog с поддержкой zookeeper: Бонусом zookeeper является то, что в его случае Sheepdog имеет более четкую и более легкую конфигурацию нод, но есть проблема в том, что установочный пакет Debian не включает его поддержку. Поэтому, что бы получить Sheepdog с поддержкой zookeeper, придется компировать его из исходного кода. Хотя я не могу исключить, что в настоящее время ситуация может быть иной.
(поддержка zookeeper по прежнему требует компиляции из исходников — прим.пер.) Нода становится частью Sheepdog, когда запускается диспетчер объектов — демон sheep. Он всегда работает в двух экземплярах: Первый экземпляр процесса запускается как шлюз (Gateway), который принимает запросы ввода-вывода от клиентов (например, от драйверов блочных устройств QEMU), вычисляет целевые узлы и передает запросы для дальнейшей обработки между ними. То есть устанавливает множество сетевых подключений. Параметры конфигурации демона sheep могут быть переданы в качестве аргументов командной строки при выполнении. Если их нет будут использованны значения по умолчанию, с которыми вы должны быть осторожны: Номер порта
Если не указано иное, демон sheep работает на порте 7000 Путь к хранилищу
Если не указано иное, каталог shep использует каталог /var/lib/sheepdog, а объекты VDI хранятся в его подкаталоге obj. На машинах, не имеющих места для хранения объектов VDI, демон sheep можно запускать исключительно в режиме шлюза, с флагом -G. В этом случае при распространении объектов VDI локальное хранилище не будет использоваться вообще, и данные будут распределены непосредственно на другие ноды. Второй запущенный инстанс, работает как локальный диспетчер объектов, принимает запросы ввода-вывода из инстанса, который запускается как шлюз, и выполняет r/w операции в локальном хранилище объектов (Object storage)  По умолчанию хранилищем для объектов VDI в Sheepdog является каталог /var/lib/sheepdog/obj, который так же используется демоном sheep как часть его внутренней структуры каталогов — это путь хранилища по умолчанию. Если вы хотите, чтобы объекты VDI хранились в другом месте, вы можете передать путь, куда смонтированно другое блочное стройство, в качестве параметра при запуске. Путей можно передать еще больше. Новая версия Sheepdog поддерживает так называемую технологию multi-device, которая позволяет динамически увеличивать емкость памяти, если это необходимо, без необходимости перезапуска Sheepdog. Увеличение емкости для хранения работает подобно Btrfs. (первый указанный каталог будет использоваться только под метаданные — прим.пер) Дополнительное хранилище можно также добавить (или удалить) через dog node md ... Функциональность, предлагаемая multi-device особенно полезна, когда файловая система хранилища не поддерживает этого "by design" (в отличии от Btrfs или ZFS). В целом, выбор файловой системы под хранение объектов, их свойств, параметров и настроек может существенно повлиять на производительность IO файловой системы виртуальной машины. При форматировании кластера, среди прочих опций можно указать тип хранилища (backend storage). Вы можете установить тип plain или tree. Для типа plain структура каталогов будет выглядеть так: Все VDI объекты в каталоге obj будет отправлены в подкаталог, имя которого основано на текущем идентификаторе эпохи. То есть для каждой эпохи соответствующие объекты VDI будут храниться отдельно. Однако в течение одной эпохи в каталоге может появиться большое количество VDI объектов, которые в последствии замедляют доступ к файлам. Поэтому вы можете выбрать второй вариант, которым является tree: В этом типе хранилища демон sheep создает набор из 256 поддиректорий с именами 0a, ..., 99 в каталоге obj, а затем разбрасывает объекты на основе двух последних символов VDI id, который уникален не только для каждого контейнера VDI но также и его снапшотов или клонов. Когда Sheepdog сохраняет данные в контейнере VDI, в хранилище данных obj начнут появляться файлы, каждый будет иметь свое имя состоящее из нескольких элементов: Первые два символа обозначают тип объекта. Объекты данных начинаются с 00... а метаданные (которые могут быть сохранены в другом каталоге) 80... Затем следует идентификатор VDI. Он уникален не только для каждого контейнера, но так же и для его снапшота или клона. Последние две цифры VDI идентификатора указывают — в случае типа хранения tree — в котором находится подкаталог, к которому принадлежит объект. А за идентификатором VDI контейнера в шестнадцатеричной форме следует порядковый номер объекта в VDI контейнере В подкаталоге epoch находятся бинарные списки объектов, принадлежащих эпохе. Номер эпохи увеличивается, каждый раз когда каждый кластер изменяется — когда добавляется или удаляется нода. Каждое такое изменение запустает процесс восстановления, в течение которого текущее состояние локальных объектов будет проверяться на нодах, за тем последует увеличение эпохи. Доступная емкость для хранения вычисляется на основе свободного места на нодах. Пространство выбираемое sheep, всегда зависит от того, сколько пространства доступно в блочном устройстве, где хранятся объекты VDI. Размер VDI контейнера — это только виртуальная фигура, которая никоим образом не связана с тем, сколько пространства занимают объекты VDI. Важно знать, как Sheepdog обрабатывает данные в кластере: Это означает, что если одна из нод падает, эпоха изменится, и Sheepdog немедленно начнет процесс восстановления, он будет создавать недостающие объекты VDI на оставшихся нодах, чтобы компенсировать потерю. Аналогичная ситуация возникнет при добавлении новой ноды. Sheepdog начнет равномерно перемещать VDI объекты с новых нод в свой репозиторий, так что процентное заполнение пространства данных на нодах будет максимально сбалансированно. Используйте следующую команду, чтобы получить глобальный обзор того, насколько использованно в настоящее время пространство на ваших нодах: Здесь важно сказать, что Sheepdog работает иначе чем Ceph, и имеет другие приоритеты. Для Ceph "вес" OSD-устройства играет решающее значение при размещении объектов данных, так же как и производительность блочного устройства, подключение к хосту и скорость ответа. (на самом деле нет — прим.пер) Делает ли что-то подобное Sheepdog, я не знаю. Возможно. Данные для него на первом месте. Производительность с точки зрения I/O операций является вторичной. Конечно, с более мощными узлами его I/O производительность может улучшиться, но всегда зависит от конкретной структуры. (однако тесты показывают более лучшую производительность sheepdog по сравнению с ceph — прим.пер) Для Sheepdog применимо следующее правило: «Чем больше VDI объектов будет на нодах с быстрым соединением, тем лучше будет производитеьность I/O операций». Из-за того, что перемещение объектов VDI происходит в фоновом режиме, означает, что «быстрая смерть ноды» замедлит репликацию тех объектов данных которые занимают больше всего места, это будет проявляться как снижение производительности I/O операций VDI контейнера  При размещении объектов данных объем свободного пространства является решающим для демона sheep. Механизм кажется простым. Демон sheep, через который осуществляется коммуникация данных с VDI-контейнером, время от времени определяет коэффициент использования свободного и занятого места на нодах, который сортирует. Затем данные распределяются по узлам с самым низким коэффициентом использования. Если существует преимущественно быстрый путь записи, операция записи в VDI контейнер также будет быстрой. Поскольку чем быстрее выполняются I/O операции VDI контейнера, тем раньше sheep демон может перейти к следующей операции. Важно то, что с Sheepdog не возникет ситуации, когда одна из нод будет полностью переполнена. Если коэффициент использования на узле становится значительно хуже, то sheep демон начинает перемещать свои объекты данных в другое место. Sheepdog работает так же, как Btrfs — используя только действительно занятое место. Таким образом, вы можете создать виртуальный VDI контейнер объемом 1 ТБ, который фактически будет занимает столько же места сколько и хранимых в нем данных. С этой точки зрения в VDI контейнерах желательно использовать такие форматы виртуальных дисков и файловых систем, которые способны подчищать за друг за другом. Это общая аббревиатура в Sheepdog для обозначения виртуального диска, а не его конкретного формата7. В целом это виртуальная коробка с отсеками фиксированного размера, в которой Sheepdog затем помещает данные, которые передает клиент. Прежде чем мы создадим или импортируем первый VDI нам нужно отформатировать кластер. При форматировании кластера устанавливаются параметры, которые затем будут использоваться по умолчанию при создании каждого следующего VDI. Пример демонстрирующий создание нового VDI с именем Disk1 и размером 1 ГБ 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 — это данные. Это распределенное блочное устройство, так что Sheepdog не решает полезны эти данные или мусор. С этой точки зрения VDI выглядит как логический том LVM. Предварительно заполненый VDI соответствует классическому LV-разделу с выделенным диапазоном, в то же время VDI напоминает и тонкий раздел LV, созданный в пуле (см. LVM (thin_provisioning)), но с той разницей, что экстенты данных (объекты) сохраняются не на локальные блочные устройства, а разбросаны между нодами. Что бы узнать больше о формате VDI можно использовать qemu-img info: Из вывода команды вы можете узнать, что disk1 имеет номинальный размер 12G. В настоящее время это занимает всего 4G. Поскольку он находится в формате qcow2, очевидно, что он был создан как инкрементный. В этом случае Disk2 был создан как предварительно выделенный VDI размером 4 ГБ в формате raw с размером блока 2 ГБ, который фактически занимает только два 2 ГБ Содержимое VDI можно экспортировать из Sheepdog несколькими способами. Возможно, самым быстрым является использование dog read. Команда немного запутанна, но просто означает: "Загрузить содержимое VDI и отправьте его в STDOUT ..", который можно перенаправить в файл: Если VDI имеет 10G, но использованно только 2G, он создаст файл с полным объемом 10 ГБ. В этой команде содержимое VDI неизменно, поэтому если содержимое VDI, например, виртуальный диск в сжатом формате qcow2, можно использовать непосредственно Другой способ получить содержимое VDI в файл — использовать qemu-img convert. Это не так быстро, но позволяет конвертировать VDI в другой формат с использованием разных опций соответствующего формата виртуального диска. Создание инкрементной резервной копии Дельта между Первым и Вторым снапшотом .. Восстановление VDI из инкрементной резервной копии При импорте инкрементной резервной копии VDI разумеется должен иметь снапшот, с которого была сделана резервная копия. Проверка путем считывания исходного содержимого образа test ... Импорт существующего виртуального диска в виде локального файла FS может быть выполнен аналогично экспорту. Но с той разницей, что используется dog write ("Чтение данных из STDIN и запись в файл VDI ..")    Если VDI еще не существует и мы не знаем, сколько места потребуются для виртуального диска, мы можем использовать qemu-img convert http://www.sheepdog-project.org/doc/vdi_read_and_write.html  При проверке целостности VDI проверяется, находятся ли блоки данных на месте. ПРИМЕЧАНИЕ: мы использовали ‘dog node kill’ для удаления ноды из кластера, но вы можете просто выключить ее или выдернуть ethernet кабель, вручную убить sheep процесс и тому подобное. Если бы вы не хотели удалять ноду из кластера (скажем, вы вынули кабель Ethernet), попробуйте как можно скорее вставить его обратно запустить sheep демон. Это остановит восстановление данных на других узлах и быстро вернёт последние измененные данные на ноде. Производительность VDI зависит от многих факторов. Прежде всего от производительности контроллера и характеристик используемых блочных устройств. Чем медленнее контроллеры и диски на нодах, тем хуже IO производительность устройств VDI. По умолчанию Sheepdog работает в режиме SYNC, который не предусматривает кэширование. Каждая операция ввода-вывода, которая не использует кеширование VFS, завершается только тогда, когда ядро получает сигнал от блочного устройства, что результат предыдущей операции был успешно сохранен. В случае виртуальной машины которая использует VDI на Sheepdog это происходит только тогда, когда приходит информация о сохранении всех копий объекта на физические устройства нод. Однако эта операция может быть очень медленной для хранилищ с медленными дисками и контроллерами. Поэтому Sheepdog предлагает несколько вариантов для значительного улучшения производительности VDI-устройств. Простейшим шагом для улучшения производительности IO для VDI является запуск на нодах демонов sheep с параметром -n. Это будет возвращать SYNC не когда данные будут фактически записаны на блочное устройство, а в момент, когда он будет передан для обработки в VFS ноды. Однако существует потенциальный риск того, что если VFS не сохранит, произойдет сбой ноды, в этом случае он будет потерян! Однако в большинстве случаев это не является серьезной проблемой. Это может быть опасным только в тех случаях где запускаются виртуальные машины, которые хранят большое количество важных данных на регулярной основе — например, машины, которые обрабатывают финансовые транзакции. Другим способом повышения производительности ввода-вывода является объектный кеш. Здесь демон sheep будет записывать объекты непосредственно не в распределенное хранилище а на блок-устройство с быстрым IO — обычно SSD диск. Виртуальная машина, работающая с VDI, не должна ждать пока будет получен SYNC с других узлов. Затем распределение объектов и их хранение на других узлах реализуется с определенной задержкой. Но у него есть один большой недостаток, если этот VDI должен использоваться на нескольких нодах, что как правило является типичным случаем для распределенного VDI в кластерной среде. Объекты, которые еще не успели перераспределиться, будут доступны только для узла, через который первоначально был подключен VDI. size
Объем кэша directio
При включении этого параметра sheep не записывает данные в оперативную память, а сразу же отправляет на диск. Это рекомендуемый выбор при использовании SSD. dir  Состояние кеша объекта может быть проверено (и настроено) с помощью dog. Лучшее решение — использовать журналирование. В этом случае ноды не записывают данные непосредственно в объекты VDI, напротив они полагаются на VFS где они запущены, но запись данных происходит сначала во вновь созданный файл журнала (/store_dir/journal/[epoch]/[vdi_object_id]), который будет удален после того, как данные будут переписаны. Увеличение производительности IO операций объясняется тем, что запись в объекты происходит не случайно (cik, cak), а последовательно (sequence). Кроме того, Sheepdog позволяет хранить файлы журналов вне системы хранения VDI объектов, что может быть тем же устройством что и для кэшей объектов, например SSD-диск. Если нода выходит из строя, прежде чем данные будут перезаписанны в VDI объект на медленном хранилище, ничего страшного не произойдет потому что журнал может быть переписан постфактум, и в отличие от объектного кэша журнал не привязан к узлу с которого был подключен VDI. Журналирование может быть включено через параметр демона sheep и может иметь различную форму — в любом случае необхдимо указать размер файла журнала Если путь к хранилищу журналов не указан, журналы VDI будут храниться в том же хранилище, что и объекты данных. Однако ведение журнала влияет на производительность операций ввода-вывода, поэтому выгодно — если возможно — хранить его на блочном устройстве с лучшей производительностью ввода-вывода: Параметр dir = указывает не путь к блочному устройству, а точку монтирования к которой подключено это быстрое блочное устройство. Это не обязательно должно быть одноблочное устройство, это также может быть SW RAID из нескольких быстрых накопителей SSD. Примечание: После перезапуска нода sheep первым делом пытается переписать данные, которые хранятся в журнале. В этом нет обязательной необходимости, поэтому мы можем использовать параметр skip, чтобы предотвратить это. ↑ Btrfs — это файловая система COW, которая в принципе значительно снижает вероятность того, что объект данных будет поврежден сбоем физического блока. С другой стороны, это значительно увеличивает накладные расходы ввода-вывода, делая копию для каждого измененного объекта. Однако это также может быть выгодным, поскольку объекты номинально одного размера, а их содержимое может быть более или менее сжато чтобы они занимали меньше места. И если их содержимое будет изменено, то последует новое сжатие которое приведет даннные к объему, который занимает оригинал. Это означает, что эти параметры будут утеряны: autodefrag — Экстенты с объектами настолько малы, что практически никакой фрагментации не может произойти ни с одним. Поскольку при изменении объекта происходит новое сжатие nocow — потому что в файловой системе он работает со целыми файлами (объектами), а не с их содержимым — как и в случае с доступом к блочному устройству через GlusterFS Преимущество Btrfs заключается в том, что он объединяет ряд вещей, которые проще решить в FS, но в последствии их должен заменить Sheepdog. Это, конечно же, уменьшает количество необходимых операций для восстановления соединения узла, которое было отключено и повторно подключено к Sheepdog. ↑ Ext2. Если вы хотите использовать какие-нибудь другие FS вместо Btrfs, лучше всего использовать ext2, который использует фиксированную таблицу inode. Журналирование с использованием ext3 и ext4 в этом случае является контрпродуктивным. Если местоположение inode фиксировано, Sheepdog только заменяет содержимое соответствующего индексного дескриптора при изменении содержимого объекта. Примечательно, что это уменьшает количество операций ввода-вывода, связанных с записью. В случае физического инородного повреждения данные объекта будут поступать на том, но поскольку Sheepdog имеет копии объекта на других нодах, он может легко заменить этот поврежденный объект командой dog vdi check. Однако, недостатком ext2 является то, что такая файловая система не может динамически расширяться другими блочными устройствами — это может в какой-то мере быть заменено командой dog vdi md, которая позволяет разложить объекты одного устройства VDI на несколько физических блочных устройств. 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 года Суперпользователь