Создаем объектное хранилище с использованием инфраструктуры Ceph — часть 1

logo_ceph_CMYK_coatedДанная статья продвинутого уровня рассматривает создание масштабируемого объектного хранилища данных с помощью экосистемы Ceph. Что такое объектное хранилище данных? Это хранилище, доступ к которому осуществляется через REST API и которое хранит произвольные бинарные объекты, доступ к которым так же предоставляется с помощью REST API. Типичный и широко используемый пример объектного хранилища данных — Amazon S3.

Зачем оно надо?

Опытный пользователь может задать вопрос: «А зачем вообще нужны эти объектные хранилища? Есть файловые системы, в которых можно хранить те же изображения, видео, музыкальные файлы и отдавать их по протоколу HTTP тем же Nginx». Действительно, часто достаточно использовать локальное файловое хранилище и не думать о чем-то большем, но современные объектные хранилища данных решают вопросы, которые выходят за рамки малых систем, а именно:

  1. Объектное хранилище сразу определяет протокол работы как для сохранения объектов, так и для их получения, удаления и т.п. что благоприятно сказывается при росте систем, поскольку не подразумевается что хранилище локальное, как в случае файлового хранилища, где, по-умолчанию, считается что хранилище здесь же, где и сервер (может быть NFS, Samba), но выглядит как локальное. При этом объектное хранилище доступно по основному протоколу internet HTTP и по умолчанию хорошо работает на каналах с потерями, задержками, высокой и меняющейся задержкой, что может существенно негативно влиять на протоколы сетевых файловых систем типа NFS, Samba.
  2. В силу своей природы, современные объектные хранилища данных разрабатываются как эластичные, «резиновые» хранилища, что позволяет увеличивать емкость хранилища практически неограниченно, при этом общаться с хранилищем как с единой сущностью.
  3. Следующее killer-свойство — репликация. Объектные хранилища по умолчанию определяют фактор репликации данных как 2 или 3, что подразумевает полное дублирование ваших данных в двух или трех экземплярах, предпочтительно в разных ЦОД. Например, если каждый узел хранилища использует «сырые» диски (рекомендуется HADOOP), то желательно использовать трехкратную репликацию, а если используется RAID (например, RAID6) с избыточностью на каждом узле хранилища, то фактор репликации может быть задан как 2.
  4. За репликацией идет высокая доступность (high availability и производительность). Объектные хранилища позволяют обращаться к данным через несколько равнозначных шлюзов, что позволяет во-первых распределять нагрузку на систему, а во-вторых увеличить отказоустойчивость системы.
  5. GEO-балансировка. Распределяя узлы по географическому принципу потенциально возможно обеспечить и лучшие пути движения трафика между системой и потребителем.

Таким образом, подключая к своему приложению систему хранения данных работающую по принципу объектного хранилища Вы сразу получаете бесконечно масштабируемую систему хранения, обладающую лучшими свойствами.

Сегодня, большинство объектных хранилищ частично или полностью совместимы с протоколом хранилища Amazon S3, по крайней мере, существуют шлюзы/конвертеры протоколов, позволяющие работать с хранилищем по по данному протоколу. В связи с этим фактом, при разработке рекомендуется ориентироваться именно на протокол S3.

Обзор Ceph

Ceph — одна из самых перспективных разработок в сфере распределенных, масштабируемых хранилищ данных. Во главу угла при разработке Ceph ставится производительность, надежность и гибкость.

Ceph определяет три интерфейса для хранимых данных:

  1. Объектное хранилище RADOS;
  2. POSIX-совместимая файловая система с поддержкой в ядре linux и fuse CEPHFS;
  3. блочные устройства RADOS BLOCK DEVICE (RBD) с поддержкой в ядре linux.

В настоящее время (1) и (3) являются стабильными подсистемами и могут успешно использоваться в любых проектах, в то время как (2) разрабатывается с меньшим приоритетом и не должна использоваться в критических задачах. Например, мы наблюдали эффект залипания файловой системы CEPHFS при очистке PHP-сессий при использовании CEPHFS в качестве разделяемого хранилища для проекта PHP. Необходимо отметить, что проект интенсивно разрабатывается, возможно, что на момент прочтения статьи CEPHFS уже вышла в стадию стабильной.

Объектное хранилище RADOS и будет героем этой статьи, совместно с совместимым интерфейсом S3 к нему.

Архитектура CEPH определяет три типа узлов:

  1. OSD — узлы, на которых фактически хранятся данные;
  2. MON — узлы, отвечающие за управление файловой системой;
  3. MDS — узлы, обслуживающие файловую систему CEPHFS (если используется).

В системе должно быть нечетное количество узлов MON (минимально — 3), поскольку в системе используется алгоритм PAXOS парламент, который позволяет предотвратить ситуации Split brain, характерные для кластерных систем.

В системе должно быть минимально число OSD равное используемому фактору репликации, если 3, то 3 узла OSD.

Для обеспечения высокой доступности требуется как минимум два узла MDS, если Вы планируете использовать CEPHFS.

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

Хотя CEPH достаточно свободно определяет как должен выглядеть узел хранения данных, мы на своей практике убедились, что существует две топологии — правильная и неправильная:

  1. правильная — узел OSD является надежным и изначально полностью укомплектован, например, 2xSSD 240GB RAID1 для журнала, 22x3TB SATA7.2K RAID-6 для данных, на узле работает 1 демон osd;
  2. неправильная — узел OSD комплектуется по ходу необходимости (вставляются диски) и на каждом диске запускается отдельный демон osd, по сути — своеобразный JBOD.

CEPH позволит Вам эксплуатировать как первую топологию, так и вторую, однако, необходимо отметить, что все работает одинаково хорошо только до первого сбоя, поскольку при вылете диска во втором случае включится механизм репликации данных, который будет пытаться перераспределить данные с «вылетевшего» устройства на доступные. Что можно сказать по этому поводу… Все грустно, даже на 60 дисках 3ТБ при факторе репликации 3, вылет одного диска приводил к весьма существенной деградации производительности, если же вылетал весь сервер с 20ю дисками, то все становилось просто печально…

Поэтому, мой совет — если планируете использовать CEPH для сервиса RBD, то надо использовать 1ю топологию, если же время отклика системы не принципиально, то можно использовать — 2ю. Конечно, неправильная топология выглядит очень соблазнительно — pay as you grow, но ее недостатки перекрывают экономические плюсы.

Кроме того, мы рекомендуем не использовать в случае «неправильной» топологии аппаратные RAID-контроллеры. Мы сталкивались с тем, что добавленные диски после ребута оказывались нулевыми, то есть, контроллер Adaptec их забывал. В случае с обычными HBA-картами такого не случится. В случае же «правильной» топологии аппаратные RAID-контроллеры наоборот дадут существенное преимущество, поскольку разгрузят процессор, а с батарейкой и увеличат производительность, упростят администрирование.

Есть еще одно соображение в пользу «правильной» топологии — поломка одного диска в случае использования массива с избыточностью приведет к локальному восстановлению данных без создания сетевого трафика и восстановление данных будет управляемым и щадящим, в случае же «неправильной» топологии возникнет большой сетевой трафик сначала при поломке диска, потом обратный при добавлении диска (представьте что Вам надо по сети перегнать 3ТБ данных).

В случае «правильной» топологии мы рекомендуем использовать две площадки и фактор репликации — 2, в случае «неправильной» — три площадки и фактор репликации — 3.

В том случае, если Ваше хранилище полностью построено на SSD накопителях (не Bcache, Flashcache, maxCache Plus и подобных), а именно только на SSD, то можно использовать «неправильную» топологию, поскольку SSD-диски не станут узким местом в системе. В этом случае я бы рекомендовал Вам делать что-то в духе Core i3/8GB/4xSSD 480GB и запускать на таком узле либо RAID-0 + 1 OSD, либо 4OSD, каждый на своем диске.

Еще один нюанс CEPH — вес узла OSD. Этот момент так же явно не оговаривается. От веса узла будет зависеть сколько данных алгоритм CRUSH затолкает на этот OSD. Очень важный нюанс, что при этом не учитывается есть на узле свободное место или нет. Админ должен следить чтобы оно было, вот такая редиска… А если места нет — надо срочно докидывать новые OSD. Поэтому, можно 1ТБ принять за 0.1, тогда в зависимости от емкости OSD его вес Вы будете устанавливать как NTB x 0.1.

На этом мы закончим экскурс в теорию CEPH. Все интересующиеся могут подробно поинтересоваться деталями на сайте ceph.com или обратиться в нашу компанию за платным консалтингом. Мы будем далее использовать следующую топологию: 3 виртуальных машины с дисками по 60 GB. На каждой VM будет размещаться OSD и MON, MDS использоваться не будет. Фактор репликации будем использовать как 3.