Pull to refresh
3
0
Стас Буткеев @sbutkeev

Пользователь

Send message
Мы не используем контроллеры с увеличенным количеством дисков, у сервера стоит родной backplane, который забит дисками. Поэтому согласно спецификации вендора контроллер поддерживает такую конфигурацию и в нашей ситуации узким местом не будет.
Написаны скрипты, которые анализируют полученную с контроллера информацию и отправляют ее в центральную систему мониторинга.
Спасибо за рекомендацию. Чисто теоретически это возможно, но на практике маловероятно. На текущий момент мы готовим переход на erasure coding, что позволит нам избежать описанной вами ситуации.
Предела нет, будем по мере необходимости добавлять серверы с дисками. На сегодняшний момент нет точной информации о максимальной емкости Ceph.
min_size у нас равно 1. Если использовать 2, то при любом выходе из строя диска или сервера весь кластер становится недоступен для IO, таким образом сервис оказывается недоступен, что для нас это неприемлемо.
Если мы видим, что количество ошибок быстро увеличивается за короткий срок, то это признак того, что диск в ближайшее время выйдет из строя.
Мы считаем что связка Ceph+RGW готова к промышленному применению, что она сейчас и демонстрирует у нас на боевом кластере. И как я уже написал выше, мы используем Cehp только как объектно-ориентированное хранилище, ни о блок-ориентированном, ни о CEPHFS пока речи не идет. К тому же серверы метаданных не используются в Cehp ни в связке с RGW (объектно-ориентированное хранилище), ни в RBD (блочное хранилище), а только в CEPHFS.
S3 — это объектное хранилище, где мы храним только статические файлы, которые не изменяются со временем. Дисковая подсистема для ВМ у нас представлена в двух видах: флеш СХД, где мы нарезаем сырые lun, и кластерная файловая система, где мы храним файлы в формате qcow2, которые являются дисками для ВМ клиентов. И S3, о котором идет речь в статье, никак не связано с этими двумя решениями.
На все серверы есть поддержка, поэтому вендор заменил все диски на новые.
Все диски подключены через рейд контроллер, поэтому 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

Мы используем 2 ssd диска в рейд 1.
Уточните, какие задержки вы имеете ввиду?
1) Да, переписывали, crush map формируется во время деплоя и зависит от того конфига кластера, который мы напишем. Если под «replicated-domains» имелись ввиду geographic regions в RGW, то наши два дата-центра мы позиционируем как один регион и пока не используем эту функциональность.
2) Мы используем стандартный механизм репликации, erasure code пока не используем, но это вполне возможно в будущем. Мы храним две копии данных, на боевом кластере реплицируем между дата-центрами, на тестовых — между разными хостами.
Обсуждать цены можно с Максимом Березиным: MBerezin@croc.ru
1) Да, только на SATA.
2) 12 дисков по 2 Тб, итого 24 Тб на сервер.
3) Синтетическими тестами получали порядка 1,8к IOPS при записи блоками 4к.
4) Нет, не используем.
5) Не сталкивались, т.к. не используем снапшоты из коробки.
Используем версию Hammer (Ceph-0.94.5-0), ждем версию Сeph-0.94.6-0, в которой замержены наши RP, исправляющие проблемы с Etag.

Information

Rating
Does not participate
Location
Россия
Works in
Registered
Activity