Распределённые блочные хранилища

В ходе возни с кластером на работе, решил посмотреть существующие распределённые блочные хранилища. Что вообще за хрень такая, в каком оно состоянии и возможные подводные камни.

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

После изучении гугла, если откинуть откровенно наколеночные поделки, окажется что вариантов не так уж и много: drbd, sheepdog, ceph. Это именно блочные/объектные хранилища, fs здесь не рассматриваю.

DRBD или "сетевой RAID1"

Сначала расскажу про первый, чтоб потом к нему не возвращаться.

Грубо говоря, это "RAID1 по сети". Работаем с блочным устройством как обычно, чтение идёт локально, запись зеркалируется по сети на другой хост. При отвале локального диска устройство переходит на "сетевой". При отвале связи - локально продолжает работать, но удалённая реплика становится устаревшей. При появлении сети - реплика или "догоняет" локальную копию, или синхронизируется полностью (зависит от прошедшего времени с разрыва связи).

Штатный режим работы - master/slave, он описан выше. Можно использовать для организации отказоустойчивости в виде "упал основной сервер - всё работает на резервном" или для кросс-дублирования данных (работают оба сервера, даже при отказе дисковой на одном из них).

Есть ещё режим master/master, когда данные пишутся на одно и то же устройство на разных хостах. Естественно, писать нужно в разные области, для этого идеально подходит LVM+CLVM поверх DRBD.

Допустим у нас 2 хоста, на каждом под drbd отдан терабайтный диск. Можно сделать 2 x master/slave по 500 гигов, а можно один терабайтный, но master/master. Начинаем создавать типовые виртуалки с диском по 200 гб. В первом случае их можно сделать 4 (по 100 гигов неиспользуемого места на хост), во втором - 5. Но самое важное - в режиме master/master виртуалки можно невозбранно таскать с хоста на хост поштучно.

Бич этого режима - split-brain. Это когда теряется связь между нодами и те начинают работать "сами по себе". В результате реплики расходятся и на каждом хосте накапливаются свои уникальные изменения. Чинится такое только руками.

Плюсами этого решения является простота архитектуры, возможность восстановления данных, минимум зависимостей. corosync / zookeeper для работы не нужен, хотя если вы мастерите HA, он всё равно понадобится.

По результатам тестов (ветка 8.X) - работает стабильно. Из замечаний - часто меняют синтаксис конфигов. Судя по документации, в ветке 9.X добавлен режим работы one-to-many, т.е. теперь реплик может быть больше одной. Сам пока не смотрел, для этого надо обновлять кластер.

Ceph

Великий и ужасный. Представляет собой "фреймворк" для построения распределённых хранилищ. Самый нижний уровень (rados) - менеджер объектов, уровнем выше - rbd, который собирает из этих объектов блочное устройство и fs, который из этих же объектов собирает распределёную fs. Первые два стабильны, последний - экспериментален.

Архитектурно представляет собой комплекс из трёх видов демонов:

osd -- непосредственно чтение/запись объектов,
mon -- координатор объектов, который говорит osd что и куда писать
mds -- хранилище метаданных для режима "fs"

По результатам раскопок в гугле, а потом и собственных тестов выявлены следующие проблемы:

жор ресурсов (скажем спасибо c++/boost, ладно хоть не жаба)
периодически подглюкивает (потому что запихано очень много всего)
не совсем адекватное поведение при recovery -- может легко выжрать всю сеть и лимиты по i/o на дисковой
в некоторых режимах использования есть проблемы со скоростью (например ОЧЕНЬ не любит большие iops'ы)

Несмотря на перечисленное - в отрасли используется очень широко и давно. По функциям - абсолютный лидер в своей области. Поэтому недостаток производительности подпирают ssd-диском под журнал, сеть внутри ДЦ - infiniband'ом или 10/40GbE, и работают.

corosync / zookeeper для работы также не нужен.

Sheepdog

Это тоже Ъ-распределённое хранилище. Писалось по мотивам ceph'а, с прицелом на один конкретный use-case: распределённое хранилище для кластера qemu. Чтоб без гемора, просто, дешёво и сердито.

В отличие от ceph'а здесь нет:

...мониторов. Сеть одноранговая, каждый узел равноправен.
...CRUSH-map как такового. Где лежат блоки - определяется по хешу от его id. меняется структура кластера - какие-то блоки переезжают на другие ноды. Одним failure-domain'ом считается один хост.
...placement groups. Разруливает само.
...node-discovery. Оно отдано стороннему софту: corosync/zookeeper/...
...авторизации в любом виде. То же самое.
...tier. Связано с отсутствием CRUSH-map, эмулируется или через bcache или запуском 2х кластеров.
...pool'ов. Есть дефолт на уровне всего кластера, его можно переопределить на уровне отдельной vdi.
...чексумм для передаваемых данных. Отдано TCP.
...многоуровневой архитектуры. В терминах ceph: rados слит с rbd, fs нет вообще.
...допиленного блочного устройства. Код ядерного модуля есть в исходниках, но компилять будете сами.

Теперь плюсы по сравнению с ceph:

написано на няшной сишечке (потребление ресурсов - 30МБ(!) RSS и около гига VSZ на терабайт места)
за счёт отказа от мониторов достигается НАМНОГО более высокая производительность при работе со множеством мелких блоков (плюс к тому же нет единой точки отказа, кластер работает, пока есть хоть одна копия нужного блока)
за счёт отказа от отдельного журнала повышается общая производительность записи (при записи на vdi в три реплики она всего на 7-10% ниже, чем при записи просто на локальный диск; хотя теоретически должно быть наоборот: писать в журнал всё подряд линейно - быстрее)
к существующему кластеру докручивается реально с полпинка (поставил пакет, показал куда класть данные, запустил демон, и всё, оно работает)
"osd" здесь понимает несколько независимых дисков. С hotplug'ом и автовышибанием сбойного.

Из замеченных багов (для 0.9.X):

В самом начале тестов поймал ситуацию, когда ни одного vdi нет, но место на нодах чем-то занято. До этого активно создавались-удалялись vdi и параллельно запускался check/reweight. После киляния такой ноды и удаления метаданных всё пришло в норму, т.е. это был просто мусор. Вывод: во время recover'а лучше ничего не делать.
alter-copy на используемом vdi заставляет использующую его виртуалку срать кирпичами. Лечится выключением виртуалки и запуском заново.
Связано с предыдущим пунктом - alter-copy в сторону увеличения на используемой vdi вообще нестабилен, есть риск появления неконсистентных копий объекта. Причём vdi check будет периодически фиксить реплики поочерёдно. Выход - остановить, прочекать, запустить обратно.
При «copies = 2» в процессе recovery есть риск возникновения split-brain. Симптомы: «no majority of XXXXXXXXXXX» при vdi/cluster check. Лечится руками удалением нужного объекта на одной из нод при неиспользуемом vdi с последующем check'ом.
Поддержка erasure coded vdi всё ещё сырая. При непустом кластере выставить alter-copy в любую комбинацию erasure-code (а она влияет только на новые создаваемые объекты) просто не даст - unimplemented. Также, такие объекты на чтение явно медленнее, экспериментально выяснено - от 2х до 4х раз. Измерялось с предварительным выделением места.
При включенных блокировках (dog cluster format -l <…>) не будет работать «живая» миграция в proxmox'е.
Документация неконсистентна. В вики упоминается jornaling и object cache, поддержка которых недавно удалена.
Производительность по дефолту не очень, потому что включен O_SYNC для записи. Если его выключить (sheep -n <...>), скорость записи вырастет кратно, но ценой возможной потери части данных, если для всего кластера внезапно выключить свет.

См ссылку из официальной документации.

Уверен про ceph такой список косяков тоже можно написать, просто я его так подробно не копал.

Выводы

Если у вас больше двух нод не планируется - берите drbd с lvm. При учёте момента с split-brain оно будет жить долго и счастливо. Если ровно три - смотрите drbd9, не подойдёт - тогда уже ceph/sheepdog.

Если больше трёх, есть бюджет и хранимые данные очень критичны - однозначно ceph, как наиболее стабильный в работе. То же самое, если у вас географически разнесённый кластер, который должен работать как одно целое - тоже ceph, т.к. понадобится CRUSH-map'ы.

Если нужна максимальная производительность для qemu, а кластер располагается в одном ДЦ - sheepdog. Во всех остальных случаях - ceph.

Про производительность последних двух (в цифрах) напишу в следующий раз.