CEPH-кластер: хронология работ по апгрейду нашего файлового хранилища на новую архитектуру (56Gb-s IB)

в 6:36, , рубрики: ceph, s3, SDS, Блог компании КРОК, виртуализация, высокая производительность, ит-инфраструктура, кластер, облако, СХД, хранение, хранение данных

CEPH-кластер: хронология работ по апгрейду нашего файлового хранилища на новую архитектуру (56Gb-s IB) - 1

Запустив наше облако, мы стали предоставлять сервис хранения, аналогичный S3 Амазона (с совместимым API, чтобы российские заказчики могли использовать стандартные клиенты для работы с S3, изменив только endpoint для подключения). Основная задача сервиса — хранение снапшотов виртуальных машин и различных файлов клиентов. Амазон был взят за образец, куда надо развиваться, и в начале 2014 года стало понятно, что имеющееся файловое хранилище устарело, заказчики требовали современных фичей, недоступных у нас и так нравящихся им у AWS. Но доработка существующего решения светила огромными трудозатратами, поэтому было принято решение построить новое S3-совместимое хранилище с нуля.

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

Это было чертовски долго, но всё прошло спокойно.

Что хотелось

Итак, на момент начала работ задачи были такие:

  1. Под хранилищем лежала платная файловая система, хорошая на момент раннего развития облака, но уже неоптимальная в текущей стадии роста и развития.
  2. На носу были большие проекты, требовавшие принципиально других подходов по объёму хранимых данных. Нужно было быстро и гибко масштабироваться. Имеющееся решение было сложно в настройке и требовало немалых человеческих ресурсов для конфигурирования репликации и слежения за здоровьем кластера.
  3. Старая файловая система не позволяла делать фоновую ребалансировку данных при добавлении новых серверов с дисками, а это порядка 24 Тб сырого пространства на сервер. А если всё же и запускали активную задачу, то мы получали колоссальную просадку в производительности.
  4. Мониторинг старого хранилища был проблематичным и затратным. Для этого дежурной смене дата-центра раз в день ставилась задача ручной проверки состояния и доступности дисков в файловом хранилище. Все попытки автоматизировать мониторинг приводили к существенной дополнительной нагрузке на ФС. Для нового решения потребовалось написать всего несколько плагинов для существующей системы мониторинга, чтобы полностью видеть состояние кластера, не создавая при этом практически никакой дополнительной нагрузки.
  5. Нужны были новые плюшки, в частности multipart upload. Надо было делить большие файлы на чанки и поддерживать докачку файлов при внезапном разрыве соединения — это история и про оптимизацию канала для далёкой нефтяной компании, и про доставку данных чемоданами прямо в ЦОД.
  6. Создание снапшотов также нуждалось в модернизации, их закачка на старое хранилище осуществлялась по 1Gb/s каналу — новая сеть Infiniband должна была дать подходящий канал для быстрого снятия онлайн-снапшотов.
  7. Хотелось оптимизировать сетевую инфраструктуру, и новое решение позволило доутилизировать существующую Infiniband-фабрику, которую мы используем для виртуальных сетей между ВМ и доставкой LUN с флеш-массивов к гипервизорам.

Как шли работы

В сентябре-октябре 2014-го рассматривали два решения: Swift + Swift3, Ceph + Rados Gateway. Сравнивали совместимость с API Amazon S3, изучали общую информацию о решениях, документированность, roadmap продуктов, оценивали качество саппорта и поддержку opensource-сообщества, сложность интеграции с облаком, простоту обслуживания и масштабирования. API Amazon S3 имеет около 300 методов, наличие которых мы проверяли у наших претендентов. При тестировании первого решения (Swift + Swift3) получили 136 проваленных тестов, Ceph + Rados Gateway провалил около 50.

Ceph, как и ожидалось, победил по причине большего соответствия вышеописанным критериям.

Архитектура кластера ещё не была придумана, знали только, что будет всего три компонента (OSD, MON, RGW), поэтому что и где будет крутиться, оставалось загадкой. В ноябре начали доскональное изучение документации Ceph и написание своей по развёртке. На базе этих документов разработчики смогли понять, как устроен и как работает кластер.

Параллельно шло проектирование архитектуры кластера (тестового и продакшена). Одна схема выше, вот ещё одна:

CEPH-кластер: хронология работ по апгрейду нашего файлового хранилища на новую архитектуру (56Gb-s IB) - 2

В декабре мы вышли на первый тестовый стенд. Это была уменьшенная копия боевого кластера, всего по три сервера в каждом дата-центре. Он также был растянут географически (на два дата-центра). Вот схема тестового кластера:

CEPH-кластер: хронология работ по апгрейду нашего файлового хранилища на новую архитектуру (56Gb-s IB) - 3

Немногие open-source продукты могут похвастаться такой подробной и качественной документацией, как у Ceph, поэтому никаких сюрпризов и недокументированных багов мы не нашли. Полностью поняв, что такое Ceph и с чем его едят, мы потрогали и родную утилиту деплоя. Она оказалась хороша для кластеров с простой архитектурой и сетевой топологией, которые зачастую разворачиваются обособленно от клиентов. Но нам требовалась более гибкая и удобная утилита деплоя для развёртки непосредственно в облаке. Мы написали программу, которая анализировала конфигурационный файл и собирала по кусочкам кластер либо в последовательном, либо в параллельном режиме. Теперь в конфиге указываем хосты, компоненты на них, а наше ПО определяет количество дата-центров, на которые растянуто решение, тип репликации данных, какую сеть использовать для передачи данных. Особенно это актуально для тестовых стендов облака, которые могут перезаливаться несколько раз за день.

Это фрагмент конфигурационного файла:
CEPH = {
"S3": {
"options": {
"suffix": "f",
"allow-deployment" : False,
"journal-dir": "/CEPH_JOURNAL"
},
"hosts": {
"ru-msk-vol51": [
{ "host": "XX087", "role": "rgw", "id": "a" },
{ "host": "XX088", "role": "rgw", "id": "b" },
{ "host": "XX088", "role": "mon", "id": "a" },
{ "host": "XX089", "role": "mon", "id": "b" },
{ "host": "XX090", "role": "mon", "id": "c" },
{ "host": "XX087", "role":"osd", "id":"0", "disk":"sdb"},
{ "host": "XX087", "role":"osd", "id":"1", "disk":"sdc"},
{ "host": "XX087", "role":"osd", "id":"2", "disk":"sdd"},
{ "host": "XX087", "role":"osd", "id":"3", "disk":"sde"},
{ "host": "XX087", "role":"osd", "id":"4", "disk":"sdf"},
{ "host": "XX087", "role":"osd", "id":"5", "disk":"sdg"},
.....
{ "host": "XX086", "role":"osd", "id":"114", "disk":"sdl"},
{ "host": "XX086", "role":"osd", "id":"115", "disk":"sdm"},
{ "host": "XX086", "role":"osd", "id":"116", "disk":"sdh"},
{ "host": "XX086", "role":"osd", "id":"117", "disk":"sdg"},
{ "host": "XX086", "role":"osd", "id":"118", "disk":"sdk"},
{ "host": "XX086", "role":"osd", "id":"119", "disk":"sdj"}
],
"ru-msk-comp1p": [
{ "host": "YY016", "role": "rgw", "id": "c" },
{ "host": "YY049", "role": "rgw", "id": "d" },
{ "host": "YY056", "role": "mon", "id": "d" },
{ "host": "YY068", "role": "mon", "id": "e" },
{ "host": "YY016", "role":"osd", "id":"48", "disk":"sdb"},
{ "host": "YY016", "role":"osd", "id":"49", "disk":"sdc"},
{ "host": "YY016", "role":"osd", "id":"50", "disk":"sdd"},
{ "host": "YY016", "role":"osd", "id":"51", "disk":"sde"},
{ "host": "YY016", "role":"osd", "id":"52", "disk":"sdf"},
{ "host": "YY016", "role":"osd", "id":"53", "disk":"sdg"},
.....
{ "host": "YY032", "role":"osd", "id":"102", "disk":"sdj"},
{ "host": "YY032", "role":"osd", "id":"103", "disk":"sdk"},
{ "host": "YY032", "role":"osd", "id":"104", "disk":"sdl"},
{ "host": "YY032", "role":"osd", "id":"105", "disk":"sdm"},
{ "host": "YY032", "role":"osd", "id":"106", "disk":"sdn"},
{ "host": "YY032", "role":"osd", "id":"107", "disk":"sdi"}
]
}
}
}

До февраля мы играли на devel-стенде с тестированием ПО для развёртки кластера. Описывали в файлах различные конфигурации кластера и запускали деплой. Как и ожидалось, он взрывался. Это был итеративный процесс усовершенствований и доработок. За время проектирования и внедрения вышла новая версия Ceph, в которой были немного изменены деплой и настройка компонентов кластера, и наш продукт пришлось в очередной раз дописывать.

В феврале началась разработка плагинов для существующей системы мониторинга. Мы ставили цель покрыть все компоненты решения и получить детальную статистику с кластера, что позволило нам быстро находить конкретные точки сбоев и решать мелкие проблемы в считанные минуты. К концу марта был готов код облака для работы с новым S3-кластером, который научил облако работать с API RadosGW. Где-то в это же время мы поняли, что кое-что забыли… А именно — про static website, с помощью которого пользователи могут размещать статические web-сайты у себя в bucket. Оказалось, что RGW не поддерживает этот функционал из коробки, и нам пришлось написать небольшое дополнение к нашему решению, чтобы исправить это упущение.

До конца мая писали ПО для миграции со старого кластера на новый. Утилита последовательно брала файл, записывала в базу данных имя, размер, владельца, права и так далее, файлу присваивался статус «несмигрирован», далее делались попытки миграции. После успешной миграции ему выставлялся статус «смигрирован», при неудачной попытке миграции выставлялся статус «ошибка» и этот файл должен был мигрироваться вторично при следующем запуске скрипта.

В мае же было выполнено перепроектирование и изменение существующей Infiniband-фабрики для кластера CEPH. В фабрику было добавлено десять серверов для Ceph-кластера и выделен отдельный partition key, c помощью которого трафик кластера был отделён от остального трафика в Infiniband-сети. Также в каждый дата-центр было установлено по 2 коммутатора SX1012 c VPI лицензиями, которые выполняют роль proxy между Ethernet и Infiniband сетями кластера, таким образом серверы в разных дата-центрах оказались в одном L2 сегменте. Коммутаторы были объединены в логический кластер и работали как одна железка, балансируя трафик и добавляя решению ещё больше отказоустойчивости. С точки зрения сети, наверное, это самая интересная часть. О том, что именно коллеги делали на физическом уровне, можно чуть подробнее прочитать вот здесь.

В июне разворачивали продуктив. Всё шло штатно и по регламентам инженеров. Серверы под кластер уже были в наличии, пришлось перевести несколько серверов из одного дата-центра в другой. Далее, как и положено, началось тестирование серверов, проверяли память, диски. С дисками было интереснее всего: каждый диск тестировался dd и fio и полностью заполнялся нулями по несколько раз. Около 20% всех дисков сразу уехало обратно к вендору на замену. Все работы были выполнены в течение 1–2 недель.

До июля правили минорные баги и дописывали мелкие вещи. Из серьёзного было два изменения в архитектуре кластера:

  • Журналы Ceph перенесены на флеш-диски. Было интенсивное обращение к журналам, и обычные SATA-диски, которые используются в нашем решении, не справлялись с задачей: производительность кластера проседала и постоянно сыпались ошибки slow requests, после чего кластер переходил в состояние WARN. Думали, думали и придумали. Каждый диск под журналы был презентован с двух разных флеш-СХД по Infiniband-сети, на хосте собирались multipath устройства и объединялись в софтовый рэйд. Мы считали, что это отличное отказоустойчивое решение, но на практике при какой-либо проблеме с одной из СХД или IB сети или multipath софтовый рэйд разваливался, и приходилось его собирать руками. Поэтому в конечном итоге было принято решение отказаться от презентованных дисков и перейти на локальные SSD.
  • Отказались от Ethernet management сети в пользу Infiniband. Первоначально в кластере использовались две сети, одна для управления — 1Gb/s, вторая для передачи данных между хостами кластера — 56Gb/s. И когда начали тестировать производительность кластера и закачивать файлы в него, то обнаружили, что скорость закачки не превышает 1Gb/s. Долго думали и гадали, в итоге посмотрели загрузку интерфейсов и поняли, в чём наша проблема: RGW обращался к мониторам кластера по сети управления и затем по этой же сети начинал загружать данные. Мы отказались от сети управления на Ethernet и перенесли всё в Infiniband, после чего тесты показали уже совсем другие результаты.

На этой же стадии железячники издевались над кластером, как могли: вынимали диски «на горячую», вырубали серверы и вообще всячески пытались вызвать нарушение целостности данных. Так сказать, определяли границы возможного. Система показала себя очень хорошо, и полностью сломать кластер так и не получилось.

После началась полная миграция в тестовом режиме, в частности, для проверки шейпинга при работе с огромным объёмом данных. Пришлось вспомнить всеми нелюбимый tc, несколько раз прочитывали документацию и наконец-то написали несколько магических правил, которые будут ограничивать скорость. Миграция шла медленно, канал связи дико шейпили, чтобы заказчики не почувствовали проседания производительности на старом кластере. Полная копия была создана только в августе — через две недели после начала. И запустили проверку целостности — сравнивали MD5-суммы файлов. Также имелся отдельный тестовый API endpoint для нового кластера, через который были проверены тестовые аккаунты и доступ к файлам в них (все стандартные действия, которые можно выполнять в S3).

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

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

Будут вопросы по работе с Сeph в высоконагруженных облачных средах — пишите здесь в комментариях или на почту: SButkeev@croc.ru

Автор: КРОК

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js