sbutkeev 11 фев 2016 в 09:36

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

10 мин

22K

Блог компании КРОКВысокая производительность*

+23

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

ilukyanov 11 фев 2016 в 10:17

А какой релиз Ceph используете?

sbutkeev 11 фев 2016 в 11:06

Используем версию Hammer (Ceph-0.94.5-0), ждем версию Сeph-0.94.6-0, в которой замержены наши RP, исправляющие проблемы с Etag.

ilukyanov 11 фев 2016 в 12:46

Почаще делайте бэкапы ;)

MrNobody 11 фев 2016 в 13:08

А что с ним не так?
У меня, правда, бывало что билась загрузочная запись на одном из rbd, но потерь данных не было(имею вииду крупных)

ilukyanov 11 фев 2016 в 14:10

Разработчики Ceph'a не отличаются выверенными релизами, постоянно в рассылке какое-то нытье про потерянные данные. Да и наработанная «практика» других пользователей (sourceforge, cloudmouse) показывает, что в случае ceph бэкапы лишними не бывают.

MrNobody 11 фев 2016 в 15:14

А это разве не касается по большей части ceph-fs? вроде как rbd и rados двесьма стабильные.
Бекапы никогда не бывают лишними…

angapov 12 фев 2016 в 17:21

Бэкапы Цефа нужны в первую очередь как защита от самих себя, то бишь от необдуманных действий над кластером.

angapov 12 фев 2016 в 19:02

Кстати, с фактором репликации 2 бэкапы вам могут скоро пригодиться :)

ultral 11 фев 2016 в 10:23

1) у вас хранилище только на HDD дисках построено?
2) сколько у вас сырых ТБ на один ОСД сервер приходится?
3) сколько IOPS снимаете с одного ОСД сервера?
4) используете ли снапшоты ceph?
5) сталкивались ли с проблемой чудовищных просадок при снапшотах и удалось ли решить проблему?

sbutkeev 11 фев 2016 в 11:08

1) Да, только на SATA.
2) 12 дисков по 2 Тб, итого 24 Тб на сервер.
3) Синтетическими тестами получали порядка 1,8к IOPS при записи блоками 4к.
4) Нет, не используем.
5) Не сталкивались, т.к. не используем снапшоты из коробки.

svuser 11 фев 2016 в 15:24

Вы написали, что также используете SSD (перенесли на локальное хранилище) для журналов.
Какое количество SSD и в каком raid?
Какие задержки средние?

sbutkeev 12 фев 2016 в 09:28

Мы используем 2 ssd диска в рейд 1.
Уточните, какие задержки вы имеете ввиду?

MrNobody 11 фев 2016 в 12:12

1) Карты переписывали? Делали ли replicated-domains?
2) используете стандартный механизм репликации или ERASURE CODED? Если стандартный то сколько реплик?

sbutkeev 12 фев 2016 в 08:25

1) Да, переписывали, crush map формируется во время деплоя и зависит от того конфига кластера, который мы напишем. Если под «replicated-domains» имелись ввиду geographic regions в RGW, то наши два дата-центра мы позиционируем как один регион и пока не используем эту функциональность.
2) Мы используем стандартный механизм репликации, erasure code пока не используем, но это вполне возможно в будущем. Мы храним две копии данных, на боевом кластере реплицируем между дата-центрами, на тестовых — между разными хостами.

MrNobody 12 фев 2016 в 08:33

replica-domains. Я наткнулся на такое решение в поисках увеличения скорости восстановления. Нашел вот такую презентацию.
Правда, если я все правильно понимаю такое решение требует больший объем под хранимые данные.

kvaps 12 фев 2016 в 12:35

Какой вы используете min_size? — 1? — или тоже 2?

sbutkeev 16 фев 2016 в 14:37

min_size у нас равно 1. Если использовать 2, то при любом выходе из строя диска или сервера весь кластер становится недоступен для IO, таким образом сервис оказывается недоступен, что для нас это неприемлемо.

neiromancer 11 фев 2016 в 13:09

А цены как у Амазона? Где вообще можно увидеть калькулятор Крока по аналогам EC2/S3?

sbutkeev 12 фев 2016 в 08:24

Обсуждать цены можно с Максимом Березиным: MBerezin@croc.ru

evilbot 11 фев 2016 в 15:03

А какой объём данных у вас сейчас хранится и сколько у вас сейчас серверов?

sbutkeev 12 фев 2016 в 08:22

10 серверов. 148T данных с репликацией 2.

evilbot 12 фев 2016 в 14:16

А какой предел нынешней систмы? Просто я думал что у вас несколько петабайт данных как минимум.

sbutkeev 16 фев 2016 в 14:38

Предела нет, будем по мере необходимости добавлять серверы с дисками. На сегодняшний момент нет точной информации о максимальной емкости Ceph.

angapov 12 фев 2016 в 17:10

Я думаю, вы понимаете, что фактор репликации 2 крайне опасен ввиду того, что одновременный выход из строя двух OSD из разных failure-доменов приводит к потере данных целого пула, включающего в себя эти две OSD.
Я бы не стал использовать RF=2 в продакшене, т.к. это дорога в один конец.

ilukyanov 12 фев 2016 в 18:57

Да они там охренели RF=2 использовать :)

sbutkeev 16 фев 2016 в 14:38

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

jazzl0ver 11 фев 2016 в 17:19

С дисками было интереснее всего: каждый диск тестировался dd и fio и полностью заполнялся нулями по несколько раз. Около 20% всех дисков сразу уехало обратно к вендору на замену.

а что было с уехавшими обратно дисками? bad-блоки и/или ошибки в SMART?

sbutkeev 12 фев 2016 в 09:36

На все серверы есть поддержка, поэтому вендор заменил все диски на новые.
Все диски подключены через рейд контроллер, поэтому 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
…

sbutkeev 12 фев 2016 в 13:38

Если мы видим, что количество ошибок быстро увеличивается за короткий срок, то это признак того, что диск в ближайшее время выйдет из строя.

jazzl0ver 12 фев 2016 в 15:24

т.е. вы условно «по крону» запускаете указанную команду или есть спец.средство от вендора? можете рассказать об этом?

sbutkeev 16 фев 2016 в 14:39

Написаны скрипты, которые анализируют полученную с контроллера информацию и отправляют ее в центральную систему мониторинга.

svuser 12 фев 2016 в 22:19

Не думали что использование контроллеров с увеличением количества дисков может стать узким местом?

sbutkeev 16 фев 2016 в 14:39

Мы не используем контроллеры с увеличенным количеством дисков, у сервера стоит родной backplane, который забит дисками. Поэтому согласно спецификации вендора контроллер поддерживает такую конфигурацию и в нашей ситуации узким местом не будет.

fortyseven 20 фев 2016 в 09:56

Надеюсь бэкплейн без SAS экспандера?

lovecraft 11 фев 2016 в 17:40

Очень интересно вы пишите. А как соблюдалась целостность пользовательских данных? Как я понимаю, переезжали не просто файлы, а образа работающих ВМ? То есть, конечно, тут можно измудриться — снэпшоты средствами гипервизора, live migration without shared storage и т.п., но ваши слова о том, что пересчитывались md5-суммы файлов, навели меня на мысль, что со старого хранилища на новое переезжали очень «холодные» данные.

sbutkeev 12 фев 2016 в 10:52

S3 — это объектное хранилище, где мы храним только статические файлы, которые не изменяются со временем. Дисковая подсистема для ВМ у нас представлена в двух видах: флеш СХД, где мы нарезаем сырые lun, и кластерная файловая система, где мы храним файлы в формате qcow2, которые являются дисками для ВМ клиентов. И S3, о котором идет речь в статье, никак не связано с этими двумя решениями.

lovecraft 12 фев 2016 в 07:18

И еще вопрос: тот же flops.ru потратил на доработку ceph до продакшен-состояния примерно год (правда, это было два года назад). Из вашей статьи следует, что, за исключением мелких недочетов, ceph 0.94.5 готов к промышленному использованию, в частности — в разрезе стабильности и надежности хранения данных. Так ли это?
Просто мы знаем, что «чем больше шкаф, тем громче падает», и иногда файл-ориентированное хранилище в духе Backblaze кажется более устойчивым, чем блок-ориентированное, в котором разрушение метаданных автоматом превращает весь кластер в тыкву.

sbutkeev 12 фев 2016 в 11:59

Мы считаем что связка Ceph+RGW готова к промышленному применению, что она сейчас и демонстрирует у нас на боевом кластере. И как я уже написал выше, мы используем Cehp только как объектно-ориентированное хранилище, ни о блок-ориентированном, ни о CEPHFS пока речи не идет. К тому же серверы метаданных не используются в Cehp ни в связке с RGW (объектно-ориентированное хранилище), ни в RBD (блочное хранилище), а только в CEPHFS.