Комментарии 4
Разжуйте, пожалуйста, более развёрнуто фразу "В RBD части реплик данных размазаны по многим серверам, и если в строю остается лишь один, данные не собрать.". А то сдаётся несправедливый камень прилетел в огород вашего конкурента.
Как 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. Это надежно, а мы любим надежность)
Как сайзится? Какая производительность? Как ведет себя при большом количестве операций записи и большом количестве нод? Как подключается? (увидел только iscsi и NFS)
Добрый день) Спасибо за вопросы, постарались расписать все по полочкам.
Сайзинг у нас простой - поскольку используется тройная репликация, то нужный объем нужно умножить на три.
Если весь нужный объем помещается в один сервер, то просто берем три одинаковых узла хранения.
Для контроллеров выделять отдельные узлы хранения не нужно.
Если система с высокими требованиями к отказоусточивости, то нужно и добавить еще один узел хранения для обеспечения восстановления реплик при отказе узла хранения.
При большом количестве операций и нод нагрузка распределяется на все узлы кластера, поэтому работает стабильно и предсказуемо. Конкретные цифры всегда будут зависеть от профиля нагрузки и железа. На хорошей конфигурации можно достичь сотен тысяч IOPS. На большом кластере при большом количестве блочных устройств можно увидеть миллионы IOPS.
Подключение потребителей:
- блочные протоколы iSCSI, NVMEoF
- файловые протоколы NFS, SMB
- сейчас разрабатываем объектный S3.
TROK SDS вышел на батл за надежное хранение