Добрый день) Спасибо за вопросы, постарались расписать все по полочкам.
Сайзинг у нас простой - поскольку используется тройная репликация, то нужный объем нужно умножить на три.
Если весь нужный объем помещается в один сервер, то просто берем три одинаковых узла хранения.
Для контроллеров выделять отдельные узлы хранения не нужно.
Если система с высокими требованиями к отказоусточивости, то нужно и добавить еще один узел хранения для обеспечения восстановления реплик при отказе узла хранения.
При большом количестве операций и нод нагрузка распределяется на все узлы кластера, поэтому работает стабильно и предсказуемо. Конкретные цифры всегда будут зависеть от профиля нагрузки и железа. На хорошей конфигурации можно достичь сотен тысяч IOPS. На большом кластере при большом количестве блочных устройств можно увидеть миллионы IOPS.
Спасибо, что заметили. Скриншот, о про который вы спрашиваете, — это дизайн дашборда с наполнением тестовыми данными. Мы хотели показать, как мы пришли к реализации нового интерфейса на этом примере, чтобы было понятно наглядно (как может выглядеть удобство дашборда при первом приближении, то есть после создания дизайна).
Остальные скриншоты ниже взяты уже с реальными нагрузками боевой инфраструктуры.
Будем рады, если начнете активно использовать наше решение)
В статье мы хотели показать разницу в подходах к хранению и как они влияют на худшие сценарии.
Поясню на примере. Берем 5 одинаковых серверов, в каждом пусть будет по диску на 10 ТБ...
А. CEPH
... Настраиваем Ceph с тройной репликацией, создаем блочное устройство 10ТБ, подключаем RBD, записываем данные в блочное устройство. В результате данные будут порезаны на блоки и блоки почти равномерно будут распределены на все 5 серверов.
Случается что-то нехорошее, и у нас остался только один сервер из пяти. На нем есть набор блоков и метаданные, из которых собрать ресурс полностью невозможно, потому что на сервере есть только 60% блоков. Результат - данные полностью и гарантировано потеряны, потому что для восстановления будет нужно оживить минимум 3 сервера.
Б. TROK
... Настраиваем DRBD ресурс объемом 10ТБ, подключаем DRBD, записываем данные в блочное устройство. В результате данные блочного устройства будут целиком храниться на трех серверах. Еще два сервера в запасе.
Случается что-то нехорошее, и у нас остался только один сервер из пяти. С вероятностью 60% на нем будет полная реплика данных. Причем реплика будет в виде тома, который можно просто примонтировать и прочитать.
Если нам с вероятностью 40% не повезло, то на выжившем сервере не будет вообще ничего.
Суть в том, что есть два подхода: порезать+распределить или хранить реплику целиком (data locality в наших терминах). Мы выбрали data locality. Это надежно, а мы любим надежность)
RedFish это хороший протокол, проблемы начинаются когда доходит дело до его реализации у различных вендоров. И если с разливкой ОС в различных реализациях можно худо-бедно справиться, то при изоляции гипервизора требуется 100% гарантия, что сервер будет выключен. К сожалению, добиться этого с использованием RedFish пока не получилось. Поэтому используются другие, более надежные, средства или функция не поставляется вовсе.
Добрый день) Спасибо за вопросы, постарались расписать все по полочкам.
Сайзинг у нас простой - поскольку используется тройная репликация, то нужный объем нужно умножить на три.
Если весь нужный объем помещается в один сервер, то просто берем три одинаковых узла хранения.
Для контроллеров выделять отдельные узлы хранения не нужно.
Если система с высокими требованиями к отказоусточивости, то нужно и добавить еще один узел хранения для обеспечения восстановления реплик при отказе узла хранения.
При большом количестве операций и нод нагрузка распределяется на все узлы кластера, поэтому работает стабильно и предсказуемо. Конкретные цифры всегда будут зависеть от профиля нагрузки и железа. На хорошей конфигурации можно достичь сотен тысяч IOPS. На большом кластере при большом количестве блочных устройств можно увидеть миллионы IOPS.
Подключение потребителей:
- блочные протоколы iSCSI, NVMEoF
- файловые протоколы NFS, SMB
- сейчас разрабатываем объектный S3.
Мы удалили изображение, чтобы не вводить других читателей в заблуждение. Еще раз спасибо, что заметили.
Спасибо, что заметили. Скриншот, о про который вы спрашиваете, — это дизайн дашборда с наполнением тестовыми данными. Мы хотели показать, как мы пришли к реализации нового интерфейса на этом примере, чтобы было понятно наглядно (как может выглядеть удобство дашборда при первом приближении, то есть после создания дизайна).
Остальные скриншоты ниже взяты уже с реальными нагрузками боевой инфраструктуры.
Будем рады, если начнете активно использовать наше решение)
Как RBD распределяет данные - тема отдельной большой статьи, обзорно можно посмотреть в документации https://ceph.io/assets/pdfs/weil-rados-pdsw07.pdf в параграфе 2.2
В статье мы хотели показать разницу в подходах к хранению и как они влияют на худшие сценарии.
Поясню на примере. Берем 5 одинаковых серверов, в каждом пусть будет по диску на 10 ТБ...
А. CEPH
... Настраиваем Ceph с тройной репликацией, создаем блочное устройство 10ТБ, подключаем RBD, записываем данные в блочное устройство. В результате данные будут порезаны на блоки и блоки почти равномерно будут распределены на все 5 серверов.
Случается что-то нехорошее, и у нас остался только один сервер из пяти. На нем есть набор блоков и метаданные, из которых собрать ресурс полностью невозможно, потому что на сервере есть только 60% блоков. Результат - данные полностью и гарантировано потеряны, потому что для восстановления будет нужно оживить минимум 3 сервера.
Б. TROK
... Настраиваем DRBD ресурс объемом 10ТБ, подключаем DRBD, записываем данные в блочное устройство. В результате данные блочного устройства будут целиком храниться на трех серверах. Еще два сервера в запасе.
Случается что-то нехорошее, и у нас остался только один сервер из пяти. С вероятностью 60% на нем будет полная реплика данных. Причем реплика будет в виде тома, который можно просто примонтировать и прочитать.
Если нам с вероятностью 40% не повезло, то на выжившем сервере не будет вообще ничего.
Суть в том, что есть два подхода: порезать+распределить или хранить реплику целиком (data locality в наших терминах). Мы выбрали data locality. Это надежно, а мы любим надежность)
RedFish это хороший протокол, проблемы начинаются когда доходит дело до его реализации у различных вендоров. И если с разливкой ОС в различных реализациях можно худо-бедно справиться, то при изоляции гипервизора требуется 100% гарантия, что сервер будет выключен. К сожалению, добиться этого с использованием RedFish пока не получилось. Поэтому используются другие, более надежные, средства или функция не поставляется вовсе.