You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
148 lines
15 KiB
148 lines
15 KiB
8 years ago
|
---
|
||
|
title: Распределённые блочные хранилища (ликбез)
|
||
|
tags: software, ceph, sheepdog, репост
|
||
|
---
|
||
|
В ходе возни с кластером на работе,
|
||
|
решил посмотреть существующие распределённые блочные хранилища.
|
||
|
Что вообще за хрень такая, в каком оно состоянии и возможные подводные камни.
|
||
|
|
||
|
---
|
||
|
|
||
|
> Лирическое отступление: хрень эта нужна исключительно для живой миграции и отказоустойчивости.
|
||
|
> Использование сабжа в масштабе менее трёх машин неоправдано, и часто менее надёжно,
|
||
|
> просто потому что к возможным проблемам с железом добавляются проблемы с сетью,
|
||
|
> та тоже становится критически важным звеном для функционирования системы в целом.
|
||
|
|
||
|
После изучении гугла, если откинуть откровенно наколеночные поделки,
|
||
|
окажется что вариантов не так уж и много: 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 на терабайт места)
|
||
|
* за счёт отказа от мониторов достигается [НАМНОГО](https://forum.proxmox.com/threads/ceph-and-kvm-terrible-disk-io.30128/#post-151238)
|
||
|
более высокая производительность при работе со множеством мелких блоков
|
||
|
(плюс к тому же нет единой точки отказа, кластер работает, пока есть хоть одна копия нужного блока)
|
||
|
* за счёт отказа от отдельного журнала повышается общая производительность записи
|
||
|
(при записи на 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](https://github.com/sheepdog/sheepdog/wiki/Journaling) и object cache, поддержка которых недавно [удалена](https://github.com/sheepdog/sheepdog/issues/221).
|
||
|
* Производительность по дефолту не очень, потому что включен `O_SYNC` для записи. Если его выключить (sheep -n <...>), скорость записи вырастет кратно,
|
||
|
но ценой возможной потери части данных, если для **всего** кластера внезапно выключить свет.
|
||
|
|
||
|
См [ссылку](https://github.com/sheepdog/sheepdog/wiki/Why-The-Performance-Of-My-Cluster-Is-Bad) из официальной документации.
|
||
|
|
||
|
Уверен про ceph такой список косяков тоже можно написать, просто я его так подробно не копал.
|
||
|
|
||
|
Выводы
|
||
|
------
|
||
|
|
||
|
Если у вас больше двух нод не планируется - берите drbd с lvm. При учёте момента с split-brain оно будет жить долго и счастливо.
|
||
|
Если ровно три - смотрите drbd9, не подойдёт - тогда уже ceph/sheepdog.
|
||
|
|
||
|
Если больше трёх, есть бюджет и хранимые данные очень критичны - однозначно ceph, как наиболее стабильный в работе.
|
||
|
То же самое, если у вас географически разнесённый кластер, который должен работать как одно целое - тоже ceph, т.к. понадобится CRUSH-map'ы.
|
||
|
|
||
|
Если нужна максимальная производительность для qemu, а кластер располагается в одном ДЦ - sheepdog.
|
||
|
Во всех остальных случаях - ceph.
|
||
|
|
||
|
Про производительность последних двух (в цифрах) напишу в следующий раз.
|