Через тернии к Сeph

Уход иностранных компаний с отечествен­ного рынка не пощадил и сферу информа­ционных технологий. Если «Макдональдс» просто сменил название на «Вкусно - и точка», то в сфере программного и аппа­ратного обеспечения всё гораздо сложнее. Перед многими компаниями встал вопрос: как дальше хранить растущий массив ин­формации. И тут все вспомнили про SDS. Что это такое?

Software-defined storage - это группа про­граммного обеспечения, позволяющая постро­ить хранилище на базе локальных дисков стан­дартных серверов.

Одним из самых интересных SDS считается сво­бодное программное обеспечение - Ceph. В ста­тье я расскажу вам историю одного из успеш­ных проектов её внедрения.

Все дороги ведут к Ceph

Когда-то я работал в подразделении крупной ИТ-организации. Компания предоставляла услуги централизованной ИТ-инфраструктуры. Её база была достаточно классической: несколько ферм виртуализации с классическими системами хране­ния данных (СХД) больших вендеров под ногами.

С увеличением информационных систем росли не только объёмы данных, но и узлы скопления информации. В то время как другие подразде­ления доверяли свои данные виртуальным ма­шинам, мы поступили иначе. Мы закупили клас­сические СХД с модулями файлового доступа для централизованных систем, которые мы об­служиваем. Такие СХД мало того, что были до­рогими, так ещё и потеряли актуальность в свя­зи с ростом объёмов и нагрузок.

Наша цель была по максимуму использовать от­ечественные разработки и ПО с открытым ис­ходным кодом. В тот момент российский произ­водитель предложил нам протестировать свой продукт. Это был SDS, который мог предостав­лять доступ к распределённой файловой си­стеме по протоколу NFS. Также продукт давал доступ к объектному хранилищу S3 и выступал в качестве блочного хранилища с возможно­стью экспортировать тома по iSCSI.

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

Тогда я уже немного почитал про SDS и понял, что по функционалу наиболее близким аналогом является Ceph. Я собрал тестовый стенд на Ceph.

Неожиданно Ceph превзошёл отечественный аналог по всем фронтам, притом на меньшем ко­личестве оборудования! С этого и началась исто­рия его внедрения в нашу компанию.

Как всё проектировалось

Когда мы начали внедрять Ceph, в нашей ор­ганизации были два полноценных центра об­работки данных (ЦОД). Для надёжности боль­шинство сервисов проектировалось с учётом требований работы одновременно на двух пло­щадках. Новое хранилище должно было пре­доставлять сервис для хранения данных си­стемам, спроектированным на случай отказа одного из центра обработки данных. В связи с этим СХД тоже должна была пережить отказ площадки.

Больше всего нас интересовала распределён­ная файловая система. Репликация через два независимых кластера для неё на тот момент была недоступна. Из-за этого появились огра­ничения в конечном дизайне. В результате мы решили делать растянутый на два ЦОДа кла­стер. Нам повезло, что сеть это позволяла.

Для сохранности данных мы выбрали фактор репликации 4 с минимальным размером 2. То есть если количество реплик станет меньше двух, то кластер остановит работу. Мы зада­ли логику так, чтобы при записи в каждый ЦОД создавались по две копии. А если одна из пло­щадок выйдет из строя, то система продолжит работать на двух репликах. При этом после её возвращения в ЦОД докатываются изменения.

Для первой версии системы мы взяли 12 серве­ров на каждую площадку. Наша конфигурация дала нам примерно 750 TB полезного простран­ства. Конфигурация серверов была примерно такой:

• 2 x cpu Intel Xeon e5-2640 v3
• 32G RAM
• 8 x HDD 4T 7200
• 4 x 1G Network

Мы решили использовать физические узлы только для хранения данных, а все служеб­ные компоненты размещать в виртуальных ма­шинах на продуктивных фермах виртуализа­ции. На место DVD-привода мы подключили маленькие харды под операционную систему. Сетевые интерфейсы собрали в два агрега­та. Первый предназначен для публичной сети, второй - для кластерной.

Запускайте бычка

Пусконаладочные работы заняли около меся­ца. Это не много для такого проекта. И вот мы наконец-то собрали кластер, который удовлет­воряет всем нашим требованиям. Тестирование вышло не долгим так, как файловая СХД уже не вытягивала, мы начали синхронизировать данные почтовой системы, в которую входят десятки тысяч ящиков в формате mailbox. В это время мы выявили и исправили ряд багов, вы­званных проблемами конфигурации. Так мы по­немногу начали привыкать к Сeph.

Перенос почтовых данных занял около месяца. Самым проблемным местом оказался не Сeph, а файловая СХД. Так как файлер создавал мно­го проблем, мы переключили почтовую систему практически сразу после полной синхронизации.

Первый крупный сбой

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

И тут классическая драма: через пару месяцев Сeph перестал работать. Несколько дисков не­ожиданно заполнились на 95%, и кластер пе­решёл в состояние full, что переводится как «полный». Система перешла в режим readonly, то есть «только для чтения». Для нас это было равносильно её остановке.

Это была не первая «поломка». Однако пре­дыдущие аварии не приводили к длительным отказам, и в основном система преодолевала их самостоятельно. В этот раз сбой продлился несколько часов. Мы не понимали почему ди­ски, заполненные на 80%, неожиданно станови­лись переполнены, поэтому поиск безопасного решения занял больше времени, чем обычно.

Что повлияло на аварию:

• неоптимальная конфигурация;
• неоптимальное распределение данных;
• увеличение прироста данных в связи с боль­шим количеством заводимых систем;
• игнорирование ограничителей переполнения при резервировании пространства для пере­носа данных с одного диска на другой;
• выход одного сервера.

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

Первый апгрейд

За время эксплуатации продукта мы выявили сла­бые места этой конфигурации. Проведя дополни­тельный анализ, мы решили выполнить апгрейд не только жёстких дисков, но также докинуть оперативной памяти, увеличить сеть и добавить NVMe-накопители. Сложная процедура закуп­ки требовала много времени, и нам пришлось на время перестать выделять объёмы новым системам и приостановить перенос тех, кото­рые не успели доехать. Несколько месяцев ушло на закупку. Ещё столько же понадобилось на пе- резаливку узлов, так как менялась их конфигура­ция приходилось накатывать каждый узел с нуля.

Осложняла всё частичная ребалансировка дан­ных в кластере, которая возникает при вводе нового узла. Чтобы уменьшить негативное воз­действие на потребителей, перезаливку при­ходилось делать ночью и не более двух узлов за раз. Это была не последняя перезаливка кла­стера. После неё таких процедур понадобилось довольно много. Через 4-5 месяцев кластер увеличился до 2.4 ПБ, и мы возобновили выде­ление ресурсов и перевод систем.

Спустя время мы обновили программное обе­спечение, переехав с ветки mimic на ветку nautilus. В «наутилусе» добавили предупрежде­ние, что база данных OSD вылезает с быстрых дисков на медленные. Это привело к необходи­мости реконфигурации узлов хранения и к ещё одной перезаливке всех узлов кластера.

Всего за несколько лет работы кластер прошёл примерно 5-6 расширений и вырос до объёма в 9 ПБ, а до конца лета запланировано ещё од­но расширение до 12 ПБ.

Сеть имеет значение

Серh работает по сети и очень сильно зависит от её качества. Однажды в разгар рабочего дня он у нас отвалился, и все зависимые системы встали. Это была очередная серьёзная авария. Мониторинг показывал, что у нас упали при­мерно 15% OSD, и количество падений продол­жало расти. В логах было видно, что OSD от­стреливают друг друга по таймауту. Однако все узлы были доступны и с них удавалось пингануть соседние хосты. Мы не сразу поняли, что OSD из одного ЦОДа помечают OSD из другого, как мёртвые. Ещё какое-то время нам понадо­билось, чтобы локализовать и устранить про­блему. Виной всему был роутинг, который по­ломался между ЦОДами в приватном сегменте. Вследствие этого 80% демонов хранения упали. Ожидание подъёма системы было для нас на­стоящим испытанием, так как мы не тестирова­ли такую ситуацию.

Какие перспективы у Ceph?

Ceph позволяет построить систему хранения практически под любые задачи. При правильном подходе к проектированию система способна пережить практически любые сбои, за исключе­нием необдуманных действий персонала. В ре­алиях секционных ограничений система хране­ния данных на базе Сeph позволяет не только удовлетворять текущие потребности, но и пла­нировать рост. Это впечатляет, ведь на рынке классических систем хранения данных всё до­статочно грустно. Мы не собираемся останав­ливаться на достигнутом и продолжаем нара­щивать мощности, а также проектируем новые кластеры для внедрения.

Казанский Александр
Head of SRE, более 20 лет в ИТ, большая экспертиза в созда­нии больших ИТ инфраструктур высокой критичности.

ceph.expert