Как стать автором
Обновить

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

Время на прочтение 10 мин
Количество просмотров 22K
Всего голосов 29: ↑26 и ↓3 +23
Комментарии 44

Комментарии 44

А какой релиз Ceph используете?
Используем версию Hammer (Ceph-0.94.5-0), ждем версию Сeph-0.94.6-0, в которой замержены наши RP, исправляющие проблемы с Etag.
Почаще делайте бэкапы ;)
А что с ним не так?
У меня, правда, бывало что билась загрузочная запись на одном из rbd, но потерь данных не было(имею вииду крупных)
Разработчики Ceph'a не отличаются выверенными релизами, постоянно в рассылке какое-то нытье про потерянные данные. Да и наработанная «практика» других пользователей (sourceforge, cloudmouse) показывает, что в случае ceph бэкапы лишними не бывают.
А это разве не касается по большей части ceph-fs? вроде как rbd и rados двесьма стабильные.
Бекапы никогда не бывают лишними…
Бэкапы Цефа нужны в первую очередь как защита от самих себя, то бишь от необдуманных действий над кластером.
Кстати, с фактором репликации 2 бэкапы вам могут скоро пригодиться :)
1) у вас хранилище только на HDD дисках построено?
2) сколько у вас сырых ТБ на один ОСД сервер приходится?
3) сколько IOPS снимаете с одного ОСД сервера?
4) используете ли снапшоты ceph?
5) сталкивались ли с проблемой чудовищных просадок при снапшотах и удалось ли решить проблему?
1) Да, только на SATA.
2) 12 дисков по 2 Тб, итого 24 Тб на сервер.
3) Синтетическими тестами получали порядка 1,8к IOPS при записи блоками 4к.
4) Нет, не используем.
5) Не сталкивались, т.к. не используем снапшоты из коробки.
Вы написали, что также используете SSD (перенесли на локальное хранилище) для журналов.
Какое количество SSD и в каком raid?
Какие задержки средние?
Мы используем 2 ssd диска в рейд 1.
Уточните, какие задержки вы имеете ввиду?
1) Карты переписывали? Делали ли replicated-domains?
2) используете стандартный механизм репликации или ERASURE CODED? Если стандартный то сколько реплик?
1) Да, переписывали, crush map формируется во время деплоя и зависит от того конфига кластера, который мы напишем. Если под «replicated-domains» имелись ввиду geographic regions в RGW, то наши два дата-центра мы позиционируем как один регион и пока не используем эту функциональность.
2) Мы используем стандартный механизм репликации, erasure code пока не используем, но это вполне возможно в будущем. Мы храним две копии данных, на боевом кластере реплицируем между дата-центрами, на тестовых — между разными хостами.
replica-domains. Я наткнулся на такое решение в поисках увеличения скорости восстановления. Нашел вот такую презентацию.
Правда, если я все правильно понимаю такое решение требует больший объем под хранимые данные.
Какой вы используете min_size? — 1? — или тоже 2?
min_size у нас равно 1. Если использовать 2, то при любом выходе из строя диска или сервера весь кластер становится недоступен для IO, таким образом сервис оказывается недоступен, что для нас это неприемлемо.
А цены как у Амазона? Где вообще можно увидеть калькулятор Крока по аналогам EC2/S3?
Обсуждать цены можно с Максимом Березиным: MBerezin@croc.ru
А какой объём данных у вас сейчас хранится и сколько у вас сейчас серверов?
10 серверов. 148T данных с репликацией 2.
А какой предел нынешней систмы? Просто я думал что у вас несколько петабайт данных как минимум.
Предела нет, будем по мере необходимости добавлять серверы с дисками. На сегодняшний момент нет точной информации о максимальной емкости Ceph.
Я думаю, вы понимаете, что фактор репликации 2 крайне опасен ввиду того, что одновременный выход из строя двух OSD из разных failure-доменов приводит к потере данных целого пула, включающего в себя эти две OSD.
Я бы не стал использовать RF=2 в продакшене, т.к. это дорога в один конец.
Да они там охренели RF=2 использовать :)
Спасибо за рекомендацию. Чисто теоретически это возможно, но на практике маловероятно. На текущий момент мы готовим переход на erasure coding, что позволит нам избежать описанной вами ситуации.
С дисками было интереснее всего: каждый диск тестировался dd и fio и полностью заполнялся нулями по несколько раз. Около 20% всех дисков сразу уехало обратно к вендору на замену.

а что было с уехавшими обратно дисками? bad-блоки и/или ошибки в SMART?
На все серверы есть поддержка, поэтому вендор заменил все диски на новые.
Все диски подключены через рейд контроллер, поэтому SMART не пользуемся, вместо этого получаем статистику о ошибках с рейд контроллера:

# /opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL
Adapter #0

Enclosure Device ID: 32
Slot Number: 0
Drive's position: DiskGroup: 1, Span: 0, Arm: 0
Enclosure position: N/A
Device Id: 0

Media Error Count: 0
Other Error Count: 0

Если мы видим, что количество ошибок быстро увеличивается за короткий срок, то это признак того, что диск в ближайшее время выйдет из строя.
т.е. вы условно «по крону» запускаете указанную команду или есть спец.средство от вендора? можете рассказать об этом?
Написаны скрипты, которые анализируют полученную с контроллера информацию и отправляют ее в центральную систему мониторинга.
Не думали что использование контроллеров с увеличением количества дисков может стать узким местом?
Мы не используем контроллеры с увеличенным количеством дисков, у сервера стоит родной backplane, который забит дисками. Поэтому согласно спецификации вендора контроллер поддерживает такую конфигурацию и в нашей ситуации узким местом не будет.
Надеюсь бэкплейн без SAS экспандера?
Очень интересно вы пишите. А как соблюдалась целостность пользовательских данных? Как я понимаю, переезжали не просто файлы, а образа работающих ВМ? То есть, конечно, тут можно измудриться — снэпшоты средствами гипервизора, live migration without shared storage и т.п., но ваши слова о том, что пересчитывались md5-суммы файлов, навели меня на мысль, что со старого хранилища на новое переезжали очень «холодные» данные.
S3 — это объектное хранилище, где мы храним только статические файлы, которые не изменяются со временем. Дисковая подсистема для ВМ у нас представлена в двух видах: флеш СХД, где мы нарезаем сырые lun, и кластерная файловая система, где мы храним файлы в формате qcow2, которые являются дисками для ВМ клиентов. И S3, о котором идет речь в статье, никак не связано с этими двумя решениями.
И еще вопрос: тот же flops.ru потратил на доработку ceph до продакшен-состояния примерно год (правда, это было два года назад). Из вашей статьи следует, что, за исключением мелких недочетов, ceph 0.94.5 готов к промышленному использованию, в частности — в разрезе стабильности и надежности хранения данных. Так ли это?
Просто мы знаем, что «чем больше шкаф, тем громче падает», и иногда файл-ориентированное хранилище в духе Backblaze кажется более устойчивым, чем блок-ориентированное, в котором разрушение метаданных автоматом превращает весь кластер в тыкву.
Мы считаем что связка Ceph+RGW готова к промышленному применению, что она сейчас и демонстрирует у нас на боевом кластере. И как я уже написал выше, мы используем Cehp только как объектно-ориентированное хранилище, ни о блок-ориентированном, ни о CEPHFS пока речи не идет. К тому же серверы метаданных не используются в Cehp ни в связке с RGW (объектно-ориентированное хранилище), ни в RBD (блочное хранилище), а только в CEPHFS.
Мужики, куда делась история про тачбанк и потерю данных? Была ветка и нет ветки.
Подтверждаю, видел ветку. На сохабре пока есть. Похоже, сотрудник банка сболтнул в ней что-то очень лишнее.
Киньте ссылку, пожалуйста.
Обращайтесь в ЛС если нужны скрины этой истории.
Сколько у вас сейчас максимальное количество объектов в одном bucket'e? Используете bucket index sharding?
index'ные radosgw пулы перенесли на ssd-диски?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий