Спасибо, что заметили. Скриншот, о про который вы спрашиваете, — это дизайн дашборда с наполнением тестовыми данными. Мы хотели показать, как мы пришли к реализации нового интерфейса на этом примере, чтобы было понятно наглядно (как может выглядеть удобство дашборда при первом приближении, то есть после создания дизайна).
Остальные скриншоты ниже взяты уже с реальными нагрузками боевой инфраструктуры.
Будем рады, если начнете активно использовать наше решение)
В статье мы хотели показать разницу в подходах к хранению и как они влияют на худшие сценарии.
Поясню на примере. Берем 5 одинаковых серверов, в каждом пусть будет по диску на 10 ТБ...
А. CEPH
... Настраиваем Ceph с тройной репликацией, создаем блочное устройство 10ТБ, подключаем RBD, записываем данные в блочное устройство. В результате данные будут порезаны на блоки и блоки почти равномерно будут распределены на все 5 серверов.
Случается что-то нехорошее, и у нас остался только один сервер из пяти. На нем есть набор блоков и метаданные, из которых собрать ресурс полностью невозможно, потому что на сервере есть только 60% блоков. Результат - данные полностью и гарантировано потеряны, потому что для восстановления будет нужно оживить минимум 3 сервера.
Б. TROK
... Настраиваем DRBD ресурс объемом 10ТБ, подключаем DRBD, записываем данные в блочное устройство. В результате данные блочного устройства будут целиком храниться на трех серверах. Еще два сервера в запасе.
Случается что-то нехорошее, и у нас остался только один сервер из пяти. С вероятностью 60% на нем будет полная реплика данных. Причем реплика будет в виде тома, который можно просто примонтировать и прочитать.
Если нам с вероятностью 40% не повезло, то на выжившем сервере не будет вообще ничего.
Суть в том, что есть два подхода: порезать+распределить или хранить реплику целиком (data locality в наших терминах). Мы выбрали data locality. Это надежно, а мы любим надежность)
RedFish это хороший протокол, проблемы начинаются когда доходит дело до его реализации у различных вендоров. И если с разливкой ОС в различных реализациях можно худо-бедно справиться, то при изоляции гипервизора требуется 100% гарантия, что сервер будет выключен. К сожалению, добиться этого с использованием RedFish пока не получилось. Поэтому используются другие, более надежные, средства или функция не поставляется вовсе.
Мы удалили изображение, чтобы не вводить других читателей в заблуждение. Еще раз спасибо, что заметили.
Спасибо, что заметили. Скриншот, о про который вы спрашиваете, — это дизайн дашборда с наполнением тестовыми данными. Мы хотели показать, как мы пришли к реализации нового интерфейса на этом примере, чтобы было понятно наглядно (как может выглядеть удобство дашборда при первом приближении, то есть после создания дизайна).
Остальные скриншоты ниже взяты уже с реальными нагрузками боевой инфраструктуры.
Будем рады, если начнете активно использовать наше решение)
Как 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 пока не получилось. Поэтому используются другие, более надежные, средства или функция не поставляется вовсе.