Комментарии 44
А какой релиз Ceph используете?
+1
Используем версию Hammer (Ceph-0.94.5-0), ждем версию Сeph-0.94.6-0, в которой замержены наши RP, исправляющие проблемы с Etag.
+1
Почаще делайте бэкапы ;)
+1
А что с ним не так?
У меня, правда, бывало что билась загрузочная запись на одном из rbd, но потерь данных не было(имею вииду крупных)
У меня, правда, бывало что билась загрузочная запись на одном из rbd, но потерь данных не было(имею вииду крупных)
+1
Разработчики Ceph'a не отличаются выверенными релизами, постоянно в рассылке какое-то нытье про потерянные данные. Да и наработанная «практика» других пользователей (sourceforge, cloudmouse) показывает, что в случае ceph бэкапы лишними не бывают.
0
Бэкапы Цефа нужны в первую очередь как защита от самих себя, то бишь от необдуманных действий над кластером.
+1
1) у вас хранилище только на HDD дисках построено?
2) сколько у вас сырых ТБ на один ОСД сервер приходится?
3) сколько IOPS снимаете с одного ОСД сервера?
4) используете ли снапшоты ceph?
5) сталкивались ли с проблемой чудовищных просадок при снапшотах и удалось ли решить проблему?
2) сколько у вас сырых ТБ на один ОСД сервер приходится?
3) сколько IOPS снимаете с одного ОСД сервера?
4) используете ли снапшоты ceph?
5) сталкивались ли с проблемой чудовищных просадок при снапшотах и удалось ли решить проблему?
+2
1) Карты переписывали? Делали ли replicated-domains?
2) используете стандартный механизм репликации или ERASURE CODED? Если стандартный то сколько реплик?
2) используете стандартный механизм репликации или ERASURE CODED? Если стандартный то сколько реплик?
+2
1) Да, переписывали, crush map формируется во время деплоя и зависит от того конфига кластера, который мы напишем. Если под «replicated-domains» имелись ввиду geographic regions в RGW, то наши два дата-центра мы позиционируем как один регион и пока не используем эту функциональность.
2) Мы используем стандартный механизм репликации, erasure code пока не используем, но это вполне возможно в будущем. Мы храним две копии данных, на боевом кластере реплицируем между дата-центрами, на тестовых — между разными хостами.
2) Мы используем стандартный механизм репликации, erasure code пока не используем, но это вполне возможно в будущем. Мы храним две копии данных, на боевом кластере реплицируем между дата-центрами, на тестовых — между разными хостами.
0
replica-domains. Я наткнулся на такое решение в поисках увеличения скорости восстановления. Нашел вот такую презентацию.
Правда, если я все правильно понимаю такое решение требует больший объем под хранимые данные.
Правда, если я все правильно понимаю такое решение требует больший объем под хранимые данные.
0
Какой вы используете min_size? — 1? — или тоже 2?
0
А цены как у Амазона? Где вообще можно увидеть калькулятор Крока по аналогам EC2/S3?
+1
А какой объём данных у вас сейчас хранится и сколько у вас сейчас серверов?
0
10 серверов. 148T данных с репликацией 2.
0
А какой предел нынешней систмы? Просто я думал что у вас несколько петабайт данных как минимум.
+2
Я думаю, вы понимаете, что фактор репликации 2 крайне опасен ввиду того, что одновременный выход из строя двух OSD из разных failure-доменов приводит к потере данных целого пула, включающего в себя эти две OSD.
Я бы не стал использовать RF=2 в продакшене, т.к. это дорога в один конец.
Я бы не стал использовать RF=2 в продакшене, т.к. это дорога в один конец.
+2
С дисками было интереснее всего: каждый диск тестировался dd и fio и полностью заполнялся нулями по несколько раз. Около 20% всех дисков сразу уехало обратно к вендору на замену.
а что было с уехавшими обратно дисками? bad-блоки и/или ошибки в SMART?
0
На все серверы есть поддержка, поэтому вендор заменил все диски на новые.
Все диски подключены через рейд контроллер, поэтому 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
…
Все диски подключены через рейд контроллер, поэтому 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
…
0
Если мы видим, что количество ошибок быстро увеличивается за короткий срок, то это признак того, что диск в ближайшее время выйдет из строя.
0
Не думали что использование контроллеров с увеличением количества дисков может стать узким местом?
+1
Очень интересно вы пишите. А как соблюдалась целостность пользовательских данных? Как я понимаю, переезжали не просто файлы, а образа работающих ВМ? То есть, конечно, тут можно измудриться — снэпшоты средствами гипервизора, live migration without shared storage и т.п., но ваши слова о том, что пересчитывались md5-суммы файлов, навели меня на мысль, что со старого хранилища на новое переезжали очень «холодные» данные.
0
S3 — это объектное хранилище, где мы храним только статические файлы, которые не изменяются со временем. Дисковая подсистема для ВМ у нас представлена в двух видах: флеш СХД, где мы нарезаем сырые lun, и кластерная файловая система, где мы храним файлы в формате qcow2, которые являются дисками для ВМ клиентов. И S3, о котором идет речь в статье, никак не связано с этими двумя решениями.
+1
И еще вопрос: тот же flops.ru потратил на доработку ceph до продакшен-состояния примерно год (правда, это было два года назад). Из вашей статьи следует, что, за исключением мелких недочетов, ceph 0.94.5 готов к промышленному использованию, в частности — в разрезе стабильности и надежности хранения данных. Так ли это?
Просто мы знаем, что «чем больше шкаф, тем громче падает», и иногда файл-ориентированное хранилище в духе Backblaze кажется более устойчивым, чем блок-ориентированное, в котором разрушение метаданных автоматом превращает весь кластер в тыкву.
Просто мы знаем, что «чем больше шкаф, тем громче падает», и иногда файл-ориентированное хранилище в духе Backblaze кажется более устойчивым, чем блок-ориентированное, в котором разрушение метаданных автоматом превращает весь кластер в тыкву.
+1
Мы считаем что связка Ceph+RGW готова к промышленному применению, что она сейчас и демонстрирует у нас на боевом кластере. И как я уже написал выше, мы используем Cehp только как объектно-ориентированное хранилище, ни о блок-ориентированном, ни о CEPHFS пока речи не идет. К тому же серверы метаданных не используются в Cehp ни в связке с RGW (объектно-ориентированное хранилище), ни в RBD (блочное хранилище), а только в CEPHFS.
0
Мужики, куда делась история про тачбанк и потерю данных? Была ветка и нет ветки.
0
Сколько у вас сейчас максимальное количество объектов в одном bucket'e? Используете bucket index sharding?
0
index'ные radosgw пулы перенесли на ssd-диски?
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
CEPH-кластер: хронология работ по апгрейду нашего файлового хранилища на новую архитектуру (56Gb/s IB)