Комментарии 4
Вы в самом начале пути, поздравляю с запуском)
Но мне как тех специалисту, не хватило подробностей от слова совсем(((
1. Обновили Ceph до версии 19.2.2 -- вы отчаянные ребята, сравнительные тесты производительности делали? Пояему именно 19.2.2?
2. проводили миграции между различными типами носителей - как мигрировали?
3. Каждый сервер подключен к сети с двумя 40 Gbit-интерфейсами -- Почему не разделяете публичную и кластерную, а если разделяете вланами, то не боитесь падения порта во время ребаланса?4. на базе Erasure Coding -- хоть бы указали какой профиль используете и почему?5.SATA SSD объемом 8 ТБ — это базовый класс хранения -- почему именно 8тб?6. Вышли из бета-версии, обеспечив SLA 99.95% для всех клиентов -- самое вкусное)) А как вы считаете SLA?)
Здравствуйте! Спасибо за поздравления! По поводу вопросов:
В версии 19.2.2 есть ряд полезных фичей в части S3, и одновременно с этим лучше производительность OSD. Когда-нибудь, возможно, сделаем материал про то, как мы бенчмаркаем кластеры.
Мигрировали по-разному :) Например, переносом пула между device class'ами, без смены EC-профиля, или через cache tiering — иначе нельзя перенести данные в пулы с разным EC-профилем.
Разделяем вланами, не боимся — LACP все стерпит, .1p всех сравняет.
Это зависит от (размера) кластера, количества фейлюр доменов. Обычно мы выставляем m=2 для обеспечения возможности потери двух доменов отказа + оставляем всегда запас по оборудованию, как минимум в один домен отказа, чтобы при утрате домена отказа было куда мигрировать данные. В итоге для нас типичные конфигурации это X+2, где X может быть 6, 8, 10, 12 и так далее.
Самый главный фактор — в мире существует крайне ограниченное количество производителей, которые делают SATA SSD грейда дата-центров объемом более 8 TБ и никто из них не представлен на российском рынке. Ну а менее 8 TБ уменьшают плотность, не давая по сути никаких плюсов при больших объемах (но если объем кластера небольшой, а нагрузка большая — это может, конечно же, иметь смысл).
SLA считаем на основе опыта эксплуатации всех облачных продуктов. Достигается за счет сочетания отказоустойчивой архитектуры, мониторинга, резервирования и быстрого реагирования, а расчет проводится на основе точного учета времени доступности сервиса.
В версии 19.2.2 есть ряд полезных фичей в части S3
В статье вы указываете стандартные вещи версии 17 например) Вот и хотелось бы узнать, почему именно 19
SATA SSD грейда дата-центров
Если не секрет, что за диски вы используете?
SLA считаем на основе опыта эксплуатации всех облачных продуктов. Достигается за счет сочетания отказоустойчивой архитектуры, мониторинга, резервирования и быстрого реагирования, а расчет проводится на основе точного учета времени доступности сервиса.
Можно тут по подробнее? Какие формулы берете за основу? Какие параметры?
Может быть у вас есть где-то на сайте описание?
почему именно 19
Как написали выше, у 19 версии в первую очередь лучше стабильность и производительность OSD. Основная цель нашего апдейта сейчас — изменения/фиксы в RGW и OSD. Фичи — это попозже.
Если не секрет, что за диски вы используете?
У нас Intel/Solidigm TLC
Какие формулы берете за основу?
Формула для SLA стандартная: (Общее время − Время простоя) / Общее время × 100%. Для SLA 99.95% допустимый простой в месяц — около 21 минуты. Цифры берем исходя из скорости аварийного поднятия инфраструктуры при тестировании и не берем в расчет выход компонентов (деградированное состояние кластера). У нас есть отдельное соглашение об SLA, если интересно: https://img.reg.ru/faq/SLA_18032025.pdf
Полгода с S3 — полет нормальный: как мы пронесли объектное хранилище на Ceph от запуска до выхода из беты