Вначале было слово

По мере роста инфраструктуры, стало не хватать места на каждом из отдельных серверов виртуализации. Несмотря даже на то что в каждом пачка дисков в 10 рейде. Хоть диски и шпиндельные, производительности чаще всего хватало, ибо SAS 15k, чего нельза сказать про свободный объем. Отдельную боль доставляло оИнформационная перегрузкатсутствие понастоящему живой миграции. Поэтому решили делать общее хранилище.

О дивный новый мир

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

mdadm + lvm + ext4

Золотая тройка в мире linux серверов, любой бородатый админ скажет вам что тут всё идеально, полный unix-way, надежнойсть проверенная тысячелетиями суммарной работы серверов. Но, несмотря на то что я сторонник софтварного рейда в linux он не лишен недостатков, в моем случае это скорость, оказалось так, что при увеличении количества дисков в страйпе скорость растет не линейно и нет особой разницы 4 или 10 дисков в raid10, а больше в сервера не засунуть(((

Плюсом идет так же странная работа с виртуализацией, можно отдать LVM vg гипервизору и он сам всё будет нарезать и счастье, работает быстрее чем qcow2 из-за отсутствия фс, а образ всегда можно подмонтировать. Но снапшоты, при их использовании мы получаем ну просто невозможно низкую скорость записи. Это связано с механизмомо реализации снапшотов в LVM. Плюсом у нас нет Thin-provision, что нехорошо когда у тебя итак недостаток места.

Проблему отчасти решает LVM-Thin, который в данный момент активно используется, в нём экстенты выделяются динамиески, что автоматически даёт нам адекватные по производительности снапшоты и более медленную работу из-за высокой фрагментации записи.

В любом случае на чистом md рейде я получил около 200 мб/с последовательной записи.

zfs

Или как из 3-х слов сделать одно. Тут у нас и менеджер пулов (дисков), и менеджер томов и файловая система. Файловая система тоже не простая CoW, снапшоты, сжатие, дедубликация, контрольные суммы, квоты, автомоунт (никакого /etc/fstab). Вообще это любовь с первого взгляда, многие пишут в интернетах что-то про нестабильность и ненужность, но я с ней впернвые познакомился в 2к19 когда zfsonlinux стал выглядеть серьёзнее оригинального проприетарного zfs и в убунте уже изкоробки вкомпилен ядерным модулем.

Имел с ней положительный опыт на нагруженных серверах, где нужно было уменьшить объем данных, данные хорошо сжимаемые, поэтому с помощью сжатия zfs получили 40% экономию пространства.

Плюсом proxmox умеет zfs-over-iscsi со ВСЕМИ фишками (блочные устройства, снапшоты, живая миграция). Из минусов, поскольку CoW быстро работает только на SSD, на моих шпинделях около 100Мб/с.

28 часов спустя

Или колько времени мне понадобилось на Quick Start Guide Ceph, чтобы понять его архитектуру и принципы. Тут появилось чувство знакомое со времен использования zfs. Те же слова что данные очень важны, та же фичастость (без дедубликации, скорее наоборот)). Решил пробовать.

Первое что хочется отметить, больший unix-way видел только в бакуле) Сперва немного пугает, а потом ничего, втягиваешься. Второе, что оно работает и работает действительно неплохо. Ceph проектировался как система в которой отказ оборудования это обыденность.

Архитектурно он состоит из:

  • OSD (Object Store Device) это демон который обслуживает устройство хранения, размещает на нём данные и предоставляет их.
  • Monitor кворум из демонов которые хранят в себе состояние кластера диски, ноды, стойки, датацентры всё это описывается в CRUSH-map (Controlled Replication Under Scalable Meshing) и отдает его клиентам
  • Ещё есть MDS (Meta Data Store) используются для CephFS но о нём позже.

Для минимального функционирования нужны только OSD и мониторы. Как только в мониторах появляется CRUSH-map он готов принимать и отдавать данные. Или в терминологии Ceph появляется RADOS (Replicated Autonomic Distributed Object Store) На вопрос где в Ceph хранятся метаданные о том как распологать и откуда брать даные ответ НИГДЕ. Это понастоящему невероятно, раз нигде то мы их не потеряем, их не надо реплицировать, они всегда консистентны и за ними не надо никуда ходить теряя время и увеличивая зедержку. Всем занимается алгоритм CRUSH который на основе карты вычисляет в какой OSD положить или из какого прочитать данные.

Плюсом так же идет встроенная поддержка таких опций как:

  • RBD (RADOS Block Device) блочные устройства для ваших xen, kvm
  • NFS
  • Экспорт метрик в zabbix
  • Экспорт метрик в prometheus

Что касается скорости, она получилась как у zfs на 1 сервере,около 100Мб/с, достойный показатель для распределённой системы.

Насчет надёжности тоже всё неплохо, по стандарту все данные сохраняются в 3 osd, предпочтительно на разных серверах, если остается в результате аварии менее 2 записей кластер останавливается. Если какая-то часть кластера выходит из строя, остальная часть ребалансирется чтобы восстановить потерянные копии данных. Для меня это выглядит надёжнее чем рейд, в котором когда умирает контролер, умирают и данные. Неоднократно тестировал разлиные сценарии, в итоге сломалась ext4 на которой стояла система а Ceph при этом работал и даже не показал деградацию производительности.

Мелочи жизни

Да, я знаю что есть и другие распределённые системы и сам Ceph не без изъянов, есть опыт с gluster, но лушее враг хорошего.

Cephfs только недавно стал стабильным и он всё равно очень медленный из-за глобальных блокировок, получается как gluster, файловая система с блокировками поверх файловых систем.

Как часто пишут “У Ceph много минусов, но это лучшее что есть в Open Source”, но пока что впечатления всё больше положительные.