Перформикс
Компания
29,47
рейтинг
17 апреля 2014 в 11:35

Разное → Ceph: Cloud Storage без компромиссов

Здравствуйте, уважаемые читатели!

Современные облака, используемые для целей хостинга, высоко поднимают планку требований к инфраструктуре хранения данных. Чтобы клиент получил качественную услугу, системе хранения данных должен быть присущ целый ряд свойств:
  • высокая надежность хранения
  • высокая доступность данных, то есть минимальное время простоя при авариях
  • высокая скорость доступа и минимальные задержки
  • низкая удельная стоимость хранения
  • различные прикладные возможности: клонирование, снимки состояния и т.д.

Ни RAID-массивы, ни «железные» СХД не способны решить все перечисленные задачи одновременно. Именно поэтому все большее распространение в индустрии хостинга приобретает Software-defined storage. Одним из ярких представителей SDS является распределенное хранилище под названием Ceph.

Мы решили рассказать об этом замечательном продукте, который используется в CERN, 2GIS, Mail.ru и в нашем облачном хостинге.
image

Что такое Ceph?


Ceph — отказоустойчивое распределенное хранилище данных, работающее по протоколу TCP. Одно из базовых свойств Ceph — масштабируемость до петабайтных размеров. Ceph предоставляет на выбор три различных абстракции для работы с хранилищем: абстракцию объектного хранилища (RADOS Gateway), блочного устройства (RADOS Block Device) или POSIX-совместимой файловой системы (CephFS).

Абстракция объектного хранилища

Абстракция объектного хранилища (RADOS Gateway, или RGW) вкупе с FastCGI-сервером позволяет использовать Ceph для хранения пользовательских объектов и предоставляет API, совместимый с S3/Swift. На Хабре уже была статья о том, как по-быстрому настроить Ceph и RGW. В режиме объектного хранилища Ceph давно и успешно используется в продакшене у ряда компаний.

Абстракция блочного устройства

Абстракция блочного устройства (в оригинале — RADOS Block Device, или RBD) предоставляет пользователю возможность создавать и использовать виртуальные блочные устройства произвольного размера. Программный интерфейс RBD позволяет работать с этими устройствами в режиме чтения/записи и выполнять служебные операции — изменение размера, клонирование, создание и возврат к снимку состояния итд.

Гипервизор QEMU содержит драйвер для работы с Ceph и обеспечивает виртуальным машинам доступ к блочным устройствам RBD. Поэтому Ceph сейчас поддерживается во всех популярных решениях для оркестровки облаков — OpenStack, CloudStack, ProxMox. RBD также готов к промышленному использованию.

Абстракция POSIX-совместимой файловой системы

CephFS — POSIX-совместимая файловая система, использующая Ceph в качестве хранилища. Несмотря на то, что CephFS не является production-ready и пока не имеет значимого промышленного применения, здесь на Хабре уже есть инструкция по ее настройке.

Терминология


Ниже перечислены основные сущности Ceph.

Metadata server (MDS) — вспомогательный демон для обеспечения синхронного состояния файлов в точках монтирования CephFS. Работает по схеме активная копия + резервы, причем активная копия в пределах кластера только одна.

Mon (Monitor) — элемент инфраструктуры Ceph, который обеспечивает адресацию данных внутри кластера и хранит информацию о топологии, состоянии и распределении данных внутри хранилища. Клиент, желающий обратиться к блочному устройству rbd или к файлу на примонтированной cephfs, получает от монитора имя и положение rbd header — специального объекта, описывающего положение прочих объектов, относящихся к запрошенной абстракции (блочное устройство или файл) и далее общается со всеми OSD, участвующими в хранении файла.

Объект (Object) — блок данных фиксированного размера (по умолчанию 4 Мб). Вся информация, хранимая в Ceph, квантуется такими блоками. Чтобы избежать путаницы подчеркнем — это не пользовательские объекты из Object Storage, а объекты, используемые для внутреннего представления данных в Ceph.

OSD (object storage daemon) — сущность, которая отвечает за хранение данных, основной строительный элемент кластера Ceph. На одном физическом сервере может размещаться несколько OSD, каждая из которых имеет под собой отдельное физическое хранилище данных.

Карта OSD (OSD Map) — карта, ассоциирующая каждой плейсмент-группе набор из одной Primary OSD и одной или нескольких Replica OSD. Распределение placement groups (PG) по нодам хранилища OSD описывается срезом карты osdmap, в которой указаны положения всех PG и их реплик. Каждое изменение расположения PG в кластере сопровождается выпуском новой карты OSD, которая распространяется среди всех участников.

Плейсмент-группа (Placement Group, PG) — логическая группа, объединяющая множество объектов, предназначенная для упрощения адресации и синхронизации объектов. Каждый объект состоит лишь в одной плейсмент группе. Количество объектов, участвующих в плейсмент-группе, не регламентировано и может меняться.

Primary OSD — OSD, выбранная в качестве Primary для данной плейсмент-группы. Клиентское IO всегда обслуживается той OSD, которая является Primary для плейсмент группы, в которой находится интересующий клиента блок данных (объект). Primary OSD в асинхронном режиме реплицирует все данные на Replica OSD.

RADOS Gateway (RGW) — вспомогательный демон, исполняющий роль прокси для поддерживаемых API объектных хранилищ. Поддерживает географически разнесенные инсталляции (для разных пулов, или, в представлении Swift, регионов) и режим active-backup в пределах одного пула.

Replica OSD (Secondary) — OSD, которая не является Primary для данной плейсмент-группы и используется для репликации. Клиент никогда не общается с ними напрямую.

Фактор репликации (RF) — избыточность хранения данных. Фактор репликации является целым числом и показывает, сколько копий одного и того же объекта хранит кластер.

Архитектура Ceph


arch-diag1

Основных типов демонов в Ceph два — мониторы (MON) и storage-ноды (OSD). RGW и MDS демоны не участвуют в распределении данных, являясь вспомогательными сервисами. Мониторы объединяются в кворум и общаются по PAXOS-подобному протоколу. Собственно, кластер является работоспособным до тех пор, пока в нем сохраняется большинство участников сконфигурированного кворума, то есть при ситуации split-brain посередине и четном количестве участников «выживет» только одна часть, поскольку предыдущие выборы в PAXOS автоматически уменьшили число активных участников до нечетного числа. При потере большинства кворума кластер «замораживается» для любых операций, предотвращая возможное рассогласование записанных или прочитанных данных до восстановления минимального кворума.

Восстановление и перебалансировка данных


Потеря из вида одной из копий объекта приводит к переходу объекта и содержащей его плейсмент-группы в состояние degraded и выпуску новой карты OSD (osdmap). Новая карта содержит новое расположение потерянной копии объекта и, если через заданное время утраченная копия не вернется, недостающая копия будет восстановлена в другом месте, чтобы сохранить число копий, определяемое фактором репликации. Операции, выполнявшиеся в момент подобной ошибки, автоматически переключатся на одну из доступных копий. В худшем случае их задержка будет измеряться единицами секунд.

Важным свойством Ceph является то, что все операции по перебалансировке кластера происходят в фоновом режиме одновременно с пользовательским I/O. Если клиент обращается к объекту, который находится в recovering состоянии, Ceph вне очереди восстановит объект и его копии, а затем выполнит запрос клиента. Такой подход обеспечивает минимальное латенси I/O даже тогда, когда восстановление кластера идет полным ходом.

Распределение данных в кластере


Одна из самых важных особенностей Ceph — возможность тонкой настройки репликации, задаваемой правилами CRUSH — мощного и гибкого механизма, базирующегося на случайном распределении PG по группе OSD с учетом правил (вес, состояние ноды, запрет на размещение в той же группе нод). По умолчанию OSD имеют вес, базирующийся на величине свободного места в соответствующей точке монтирования в момент ввода OSD в кластер и подчиняются правилу распределения данных, запрещающему держать две копии одной PG на одной ноде. CRUSHMAP — описание распределения данных — может быть модифицирован под правила, запрещающие держать вторую копию в пределах одной стойки, тем самым обеспечивая отказоустойчивость на уровне вылета целой стойки.

Теоретически, подобный подход позволяет осуществлять в том числе гео-репликацию в реальном времени, однако на практике это можно использовать лишь в режиме Object Storage, поскольку в режимах CephFS и RBD задержки операций будут слишком велики.

Альтернативы и преимущества Ceph


Наиболее качественной и близкой по духу свободной кластерной ФС являются GlusterFS. Она поддерживается RedHat и имеет некоторые преимущества (например, локализует Primary копию данных рядом с клиентом). Однако наши тесты показали некоторое отставание GlusterFS в смысле производительности и плохую отзывчивость при перестроении. Другие серьезные минусы — отсутствие CoW (в том числе и в прогнозируемом будущем) и низкая активность сообщества.

Преимущество Ceph перед прочими кластерными системами хранения данных состоит в отсутствии единых точек отказа и в практически нулевой стоимости обслуживания при восстановительных операциях. Избыточность и устойчивость к авариям заложена на уровне дизайна и достается даром.

Возможные замены подразделяются на два типа — кластерные фс для суперкомпьютеров(GPFS/Lustre/etc.) и дешевые централизованные решения вроде iSCSI или NFS. Первый тип достаточно сложен в обслуживании и не заточен на эксплуатацию в условиях отказавшего оборудования — «замораживание» ввода-вывода, особенно чувствительное при экспорте точки монтирования в вычислительную ноду, не позволяет использовать подобные фс в публичном сегменте. Минусы «классических» решений довольно хорошо понятны — отсутствие масштабируемости и необходимость закладывать топологию для failover на уровне железа, что приводит к увеличению стоимости.

С Ceph восстановление и перестроение кластера происходят действительно незаметно, практически не влияя на клиентское I/O. То есть деградировавший кластер для Ceph — это не экстраординарная ситуация, а всего лишь одно из рабочих состояний. Насколько нам известно, ни одна другая открытая программная СХД не имеет этого свойства, достаточного для ее использования в публичном облаке, где запланированное прекращение обслуживания невозможно.

Производительность


Как указывалось в начале статьи, данные в Ceph квантуются достаточно маленькими порциями и псевдослучайно распределены по OSD. Это приводит к тому, что реальное I/O каждого клиента Ceph достаточно равномерно «размазывается» по всем дискам кластера. В результате этого:
  1. Снижается накал борьбы между клиентами за дисковый ресурс
  2. Растет верхняя планка теоретически возможной интенсивности работы с блочным устройством
  3. Вследствие п.1 и 2 каждый клиент получает существенно большие удельные лимиты по iops и bandwidth, чем может дать классический подход за те же деньги

Есть и другие причины быстродействия Ceph. Все операции записи сначала попадают в журнал OSD, а затем, не задерживая клиента, асинхронно переносятся в персистентное файловое хранилище. Поэтому размещение журнала на SSD, которое рекомендовано в документации Ceph, многократно ускоряет операции записи.

Цели и результаты


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

image

Например, сразу после публичного релиза год назад мы обнаружили, что перестроение кластера влияет на его отзывчивость больше, чем хотелось бы. Или что определенный вид операций приводит к существенному увеличению латенси последующих операций. Или что в определенных (к счастью, редких) условиях клиентская виртуальная машина может намертво зависнуть на I/O. Так или иначе, багфикс длительностью в полгода сделал свое дело, и на сегодняшний день мы абсолютно уверены в нашей СХД. Ну а в процессе устранения трудностей мы обзавелись целым рядом инструментов отладки и мониторинга. Один из них — мониторинг длительности всех без исключения операций с блочными устройствами (на данный момент кластер ежесекундно обслуживает несколько тысяч операций чтения/записи). Вот так сегодня выглядит отчет о латенси в нашей админ-панели:

image
Зеленым на графике отмечена минимальная длительность операций, красным — максимальная, бирюзовым — медиана. Впечатляет, не правда ли?

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

В конечном счете Ceph позволил нам обеспечить:
  • снижение IO latency до значений хорошего локального SSD
  • апгрейд всех дисков хранилища с 1Tb на 4Tb модели в незаметном для пользователей режиме
  • аппаратный отказ одной ноды незаметен для пользователей как событие
  • благодаря живой миграции и использованию Ceph аппаратные и программные обновления происходят с нулевым даунтаймом
  • снэпшоты, клонирование, инкрементальные диффы нашли свое применение в продакшене и радуют клиентов
  • сверхнизкие цены на услуги

Flops.ru остается единственным в России и одним из немногих в мире хостеров, кто использует Ceph в продакшене. Благодаря Ceph у нас получилось реализовать то, о чем часто пишут в визионерских постах о будущем облаков — совместить вычислительные ноды и ноды хранилища на обычном железе и достичь показателей, близких к значениям энтерпрайзных «полок» без увеличения стоимости. Ну а поскольку сэкономленные деньги — все равно что заработанные, мы получили возможность снизить цены на услуги практически до уровня западных дискаунтеров. В этом легко убедиться, взглянув на наши тарифы.

Если вы используете выделенный хостинг в своей работе — предлагаем вам попробовать наши услуги в действии и оценить, какие преимущества дает Ceph. Платить ничего не нужно — двухнедельный пробный период и тестовый баланс в 500 рублей вы сможете активировать сразу после регистрации.

В следующих постах мы рассмотрим практическую сторону использования Ceph, расскажем о фичах, которые появились у нас за последний год (а их немало) и остановимся подробнее на преимуществах, которые дает использование SSD.

Спасибо за внимание!
Автор: @teraflops
Перформикс
рейтинг 29,47
Компания прекратила активность на сайте

Похожие публикации

Комментарии (51)

  • +1
    Вы используете Ceph на выделенном кластере (чисто под хранилище) или совместно с другим софтом (прямо на ноде)?
    • 0
      Как мы отметили, роли compute и storage совмещены.
  • +1
    Какая сеть используется между OSD?
    • +1
      IPoIB QDR
      • 0
        Дорого.
        • 0
          DDR/10GigE стоят в пределах десятипроцентной разницы столько же. В пределах стойки разница вообще не заметна.
  • 0
    Почему выбор пал именно на Ceph, а не на вполне себе стабильный Gluster?
    • +1
      Gluster является стабильным, в каком-то понимании, но не производительным. К тому же, во время выбора решения гластер не обладал ни драйвером в qemu, ни кворумом.
      • 0
        Зачем для гластера кворум? И кстати по поводу производительности Ceph умеет RDMA over IB?
        • 0
          Для рекавери. Без свойства автоматического восстановления применять кластерную фс в публичном облаке нельзя.
          • 0
            RDMA транспорт будет в обозримом будущем, но он не дает большого прироста на обычных операциях — уменьшается задержка, связанная с TCP стеком и соответствующая нагрузка на процессор, в современных системах тоже достаточно скромная удельно.
  • +1
    Если клиент обращается к объекту, который находится в degraded состоянии, Ceph вне очереди восстановит объект и его копии, а затем выполнит запрос клиента. Такой подход обеспечивает минимальное латенси I/O даже тогда, когда восстановление кластера идет полным ходом.

    Нет ли тут противоречия?
    • 0
      К сожалению, тут вкралась неточность — не degraded, a recovering, т.е. восстанавливающийся в настоящий момент времени объект. Такой объект будет восстановлен с наибольшим приоритетом, потому что состояние recovering блокирует операции из-за возможного изменения положения primary копии.
  • 0
    Вы держите реплики в разных ДЦ? Если да — как Ceph реагирует на проблемы с меж-ДЦ каналом?
    • 0
      Нет, это как раз из области bad practices, мы упомянули об этом в статье.
      • +2
        Вы про фразу
        Теоретически, подобный подход позволяет осуществлять в том числе гео-репликацию в реальном времени, однако на практике это можно использовать лишь в режиме Object Storage, поскольку в режимах CephFS и RBD задержки операций будут слишком велики.
        , да? Это понятно. Я почему-то полагал, что вы и Object Storage делаете.

        Перефразирую тогда вопрос. Как ведёт себя Ceph при потере одной стойки? Через сколько секунд сервис начинает работать со штатными временами ответов? Данные, которые попали на вылетевшие машины, переходят в режим read only, или для них восстанавливается копия на свободных дисках?
        • +2
          Если говорить о, допустим, трех стойках, RF=3 и одной вылетевшей, то латенси устаканится примерно за минуту. Данные, безусловно, доступны на чтение и на запись сразу после пересчета расположения новых primary копий(что в масштабе 500тб будет занимать 5-10 секунд).
  • 0
    <тут был комментарий мимо ветки>
  • 0
    Если это не коммерческая тайна, какой примерно общий объем хранилища на базе ceph у вас? Сколько всего задействовано серверов/дисков непосредственно для хранения?
    • 0
      Можем ответить для масштаба стойки — примерно 110 терабайт с учетом трехкратной репликации, то есть 350 «сырых».
  • +1
    Не планируете сделать сравнение Ceph, Gluster и DRBD? Понимаю, что последнее не имеет всех тех же возможностей. Но всё же.
    • +1
      Гм, скорее нет — гластер настолько отстает в плане производительности, что делать сравнение равносильно принятию инвалида в грузчики по программе equal opportunities. Можно было бы сравнить Glusterfs и Cephfs — здесь первая, несомненно, впереди по ряду факторов, но это решение для очень узкого набора задач и, боюсь, практически никому не будет интересно.
  • 0
    >аппаратный отказ одной ноды незаметен для пользователей как событие
    если нода = OSD то как речь про отказ соответствующего физического диска? или нода=физический сервер?(но тогда, с учетом что по вашим словам у вас и Ceph и гипервизор на одних и тех же нодах, что будет с теми виртуалками что жили на этом сервере?)
    • 0
      Нода — физический сервер. Виртуалки, безусловно, потеряют исполняемое состояние если нода «сгорит», то есть станет недоступной моментально, в этом случае они будут запущены заново в других местах автоматически. Аппаратный отказ подразумевает все иные классы событий — битая память, умерший бп, перегревающийся до троттлинга процессор и так далее.
      • 0
        А виртуалки поднимаются в том же состоянии в котором они были в случае физического отказа сервера?
        Что происходит в случае если виртуалка работает «boot-from-volume» и на compute ноде отваливается сеть?
        • 0
          В первом вопросе у вас заключается сам ответ — да, безусловно, состояние и конфигурация виртуалок остаются. У нас нет противопоставления опенстековскому boot from volume — все машины всегда работают только с rbd. В этом случае нода приравнивается к сгоревшей и машины также перезапускаются.
  • 0
    Какую ОС используете для физических серверов (KVM гипервизоры и ноды ceph'a). Насколько хорошо эта ОС себя показала?
    • +1
      Свой дистрибутив с базой на debian stable.
  • 0
    смотрели ли вы в сторону FhGFS?
    • 0
      Смотрели на этапе выбора, но у нее довольно конские лицензионные условия и очень мало информации по опыту применения в открытом доступе.
      • 0
        А на MooseFS?
        • 0
          Не смотрели, но, судя по всему, правильно. POSIX слой с точкой монтирования в хосте — огромная проблема в плане совместимости.
          • 0
            Совместимости чего с чем? Но moose здесь и правда не подойдёт, потому как надо выдавать блочные устройства, а moose всё-таки FUSE-based.
            • 0
              Блочные устройства можно размещать на фс, в этом нет проблем. Проблема в том, что хост должен «уметь» эту фс. В случае Ceph гипервизор вообще не знает о том, что первый существует, и это хорошо — можно поставить пачку гиперви или esx хостов и подцепить к хранилищу через iscsi реэкспорт.
  • 0
    Я правильно понимаю, что Ceph нормально переваривает ситуацию, когда на нодах стороджа размер «сырых» дисков сильно разный?
    • 0
      Да, достаточно правильно указать вес — впрочем, начиная с cuttlefish, вес ставится автоматически в зависимости от размера диска.
      • 0
        А как проходит миграция виртуалок? Не бывает ли проблем?
        Или у вас всякие HA не используются?
        А то после описанного бага в DRBD как то страшно.
        • 0
          Нет, миграция совершенно прозрачная и без ощутимого даунтайма сети при переучивании маршрутов.
          • 0
            А рулится все это через OpenStack? Или что-то другое?
            • +1
              Нет, оркестровка полностью самописная. К слову, мы считаем, что все опенсорсные продукты для оркестровки облаков очень сильно недотягивают до нашего уровня в смысле как минимум интегрированности компонент.
  • 0
    в нашем облачном хостинге


    А как бы посмотреть как будет меняться цена в вашем хостинге при выборе своих параметров при создании сервера? (в варианте «без границ»/«по потреблению»)
    Не хочется создавать бесполезный аккаунт, а информация интересна. Может есть какой-нибудь demo-аккаунт для ознакомления с админкой?
    • +2
      На днях выкатим соответствующую главную страницу, сейчас доверстываем.
  • 0
    Гуру подскажите, пожалуйста, нужен ли MetaDataServer если юзается Ceph Block Device (aka. RBD)? К примеру, кластер Proxmox юзает кластер Ceph.
    • 0
      Нет, не нужен. В статье выше, к слову говоря, подробно расписаны роли демонов :)
      • 0
        Спасибо большое за ответ. Я на 99% понял роль MDS, но решил подвериться. Уфффф нет MDS нет проблем =) тем более его не удалить из кластера нормально.
  • 0
    А как обстоит дело с балансировкой по физическим линкам. Можно использовать multipath I/O совместно с Ceph? Или есть ли встроенный подобный функционал?
    • 0
      Multipath не нужен в силу архитектуры продукта, можно использовать обычный бондинг для большей отказоустойчивости отдельной ноды хранилища.
      • 0
        Наверное я не верно сформулировал свой вопрос.

        Предположим что у нас нет средств на приобретение 10G Ethernet и прочих скоростных вещей вроде InfiniBand. А в наличии есть 1G Ethernet, многопортовые карточки и коммутатор. В таком случае бондинг не сильно поможет. В случае применения бондинга путь от одной ноды до другой будет всегда пролегать через один и тот же порт. Можно заставить ядро linux чередовать отправку пакетов с нескольких интерфейсов, но в случае применения коммутатора это бесполезно.

        multipath I/O в случае с iSCSI может позволить задействовать несколько линков одновременно без участия в этом процессе бондинга. Суть вопроса сводилась к том можно ли в ceph применять напрямую multipath I/O или в нем есть какие то свои механизмы для распределения трафика по нескольким физическим интерфейсам (в контексте повышения пропускной способности).
        • 0
          В случае обычного коммутатора вам с очень большой вероятностью хватит линуксового balance-xxx. У цефа нет точек, являющихся средоточием пропускной способности, так что половинка от максимальной скорости на пару 5-tuple будет очень хорошо работать, за исключением граничных случаев (один клиент, потребляющий всю пропускную способность кластера).
  • 0
    Пожалуйста разжуйте ситуацию с Placement Group. Прочёл официальную документацию и не понял глубинного смысла в увеличении кол-ва PG.
    • 0
      Чем больше число PG, тем более гладким получится псевдослучайное распределение данных. С другой стороны, при числе PG более 50..70к в одном пуле начинаются проблемы с производительностью кластера.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное