Мы не используем контроллеры с увеличенным количеством дисков, у сервера стоит родной backplane, который забит дисками. Поэтому согласно спецификации вендора контроллер поддерживает такую конфигурацию и в нашей ситуации узким местом не будет.
Спасибо за рекомендацию. Чисто теоретически это возможно, но на практике маловероятно. На текущий момент мы готовим переход на erasure coding, что позволит нам избежать описанной вами ситуации.
min_size у нас равно 1. Если использовать 2, то при любом выходе из строя диска или сервера весь кластер становится недоступен для IO, таким образом сервис оказывается недоступен, что для нас это неприемлемо.
Мы считаем что связка Ceph+RGW готова к промышленному применению, что она сейчас и демонстрирует у нас на боевом кластере. И как я уже написал выше, мы используем Cehp только как объектно-ориентированное хранилище, ни о блок-ориентированном, ни о CEPHFS пока речи не идет. К тому же серверы метаданных не используются в Cehp ни в связке с RGW (объектно-ориентированное хранилище), ни в RBD (блочное хранилище), а только в CEPHFS.
S3 — это объектное хранилище, где мы храним только статические файлы, которые не изменяются со временем. Дисковая подсистема для ВМ у нас представлена в двух видах: флеш СХД, где мы нарезаем сырые lun, и кластерная файловая система, где мы храним файлы в формате qcow2, которые являются дисками для ВМ клиентов. И S3, о котором идет речь в статье, никак не связано с этими двумя решениями.
На все серверы есть поддержка, поэтому вендор заменил все диски на новые.
Все диски подключены через рейд контроллер, поэтому SMART не пользуемся, вместо этого получаем статистику о ошибках с рейд контроллера:
1) Да, переписывали, crush map формируется во время деплоя и зависит от того конфига кластера, который мы напишем. Если под «replicated-domains» имелись ввиду geographic regions в RGW, то наши два дата-центра мы позиционируем как один регион и пока не используем эту функциональность.
2) Мы используем стандартный механизм репликации, erasure code пока не используем, но это вполне возможно в будущем. Мы храним две копии данных, на боевом кластере реплицируем между дата-центрами, на тестовых — между разными хостами.
1) Да, только на SATA.
2) 12 дисков по 2 Тб, итого 24 Тб на сервер.
3) Синтетическими тестами получали порядка 1,8к IOPS при записи блоками 4к.
4) Нет, не используем.
5) Не сталкивались, т.к. не используем снапшоты из коробки.
Все диски подключены через рейд контроллер, поэтому 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) Мы используем стандартный механизм репликации, erasure code пока не используем, но это вполне возможно в будущем. Мы храним две копии данных, на боевом кластере реплицируем между дата-центрами, на тестовых — между разными хостами.
2) 12 дисков по 2 Тб, итого 24 Тб на сервер.
3) Синтетическими тестами получали порядка 1,8к IOPS при записи блоками 4к.
4) Нет, не используем.
5) Не сталкивались, т.к. не используем снапшоты из коробки.