Насколько я знаю, пока никак. Кластер не может быть растянут на две автономные площадки, то есть если половинки развалятся, каждая будет жить сама по себе и никакой консистенции не будет. Как-то так.
Но, делать репликацию между двумя кластерами (они могут быть в разных датацентрах) для объектного доступа RadosGW уже возможно, но я не копал в эту сторону глубоко http://ceph.com/docs/master/radosgw/federated-config/.
Используя KVM виртуализацию, OpenVSwitch и прочие opensource пакеты мы не изобрели велосипед, а Openstack – оркестратор процессов, который достаточно легко «дописывается»
А вот тут можно чуточку поподробнее? Что вы использовали из OpenStack, а что «дописывали» сами?
Так, давай по порядку. Цель топика, как не сложно догадаться из названия, быстро поднять RADOS Gateway. Как я уже написал чуть выше, возможных конфигураций ceph множество и за один топик ну не описать все, тем более в режиме гайда. Ну а как ты хотел?
Теперь по твоему варианту, давай более предметно. Допустим у тебя есть 100 серверов, которые дампят файлы на хранилище раз в 15 минут. Ожидаемый объем одного такого файла 1ГБ. Грубый просчет тогда такой: 1ГБ за 15 минут это 1,3 МБ/c c одного сервера или 130 МБ/c со 100. Допустим ты хочешь иметь три реплики — умножаем на три получаем 390 МБ/c.
Вот тут есть грамотные тесты с правильным кешированием ceph.com/community/ceph-performance-part-1-disk-controller-write-throughput/. То есть контроллер с пробросом 6-и 7200RPM SATA дисков + журналы osd на ssd выдают что-то около 100 МБ/c на диск при XFS, который рекомендуют в продакшн.
Я не знаю что у тебя хранилище сейчас, но если интересны плюшки Сeph, то есть смысл попробовать собрать 3 сервера с 6-12 шпинделями и одним ssd на каждом + правильный контроллер.
В общем, вариантов построения ceph множество. Типы и способы подключения дисков, файловые системы, кеширование, вынесение журналов и многое другое. Тут необходимо думать, выбирать и тестировать.
Но, на днях видел инициативу в сообществе о создании некоего калькулятора основанного на замерах конкретных конфигураций — www.spinics.net/lists/ceph-users/msg01738.html
Потому что расточительно. Воспринимайте Ceph как RAID только с гранулярнорстью в объект при очень большом количестве дисков с построением карты иерархии/весов (учитывается размещение физических дисков друг к другу).
Вы же не делаете RAID поверж прицепленых дисков с полки где тоже сделали RAID?
Принимая во внимание то, что отказ демона (или его диска) и восстановление данных будут не заметны для клиента, применение RAID вместе с Ceph выйдет всегда сильно расточительно.
Логика RADOS в том, что бы разбить данные на блоки и положить их на файловые системы дисковых ресурсов. Во время записи блоки можно продублировать столько раз сколько необходимо на разные физические диски учитывая размещение физических дисков друг к другу (ноды, шкафы). При правильной архитектуре мы можем прозрачно потерять не только диск, OSD демон, но и всю ноду или шкаф.
Если есть такие простаивающие ресурсы как дисковые полки, их можно попробовать разбить по одному LUN на каждую ноду. Специально закупать классическую СХД под Ceph нет никакого экономического смысла.
Ceph обычно делают минимум на 3 ноды.
Дело в том, что демоны мониторинга mon находятся в кворуме — большинство определяет состояние кластера. То есть комбинации 1, 2:3, 3:5, 4:6 и т.д.
да, отзывы именно о cephfs, а вглубь уже не интересно, если на этом уровне работает нестабильно.
Не совсем так. CephFS это не уровень, это проект выстроенный «сверху» над хранилищем.
RBD и RADOS Gateway уже работают у многих в продакшн, погуглите.
Скорое напишу подробнее о RADOS Gateway.
Но, делать репликацию между двумя кластерами (они могут быть в разных датацентрах) для объектного доступа RadosGW уже возможно, но я не копал в эту сторону глубоко http://ceph.com/docs/master/radosgw/federated-config/.
А вот тут можно чуточку поподробнее? Что вы использовали из OpenStack, а что «дописывали» сами?
Теперь по твоему варианту, давай более предметно. Допустим у тебя есть 100 серверов, которые дампят файлы на хранилище раз в 15 минут. Ожидаемый объем одного такого файла 1ГБ. Грубый просчет тогда такой: 1ГБ за 15 минут это 1,3 МБ/c c одного сервера или 130 МБ/c со 100. Допустим ты хочешь иметь три реплики — умножаем на три получаем 390 МБ/c.
Вот тут есть грамотные тесты с правильным кешированием ceph.com/community/ceph-performance-part-1-disk-controller-write-throughput/. То есть контроллер с пробросом 6-и 7200RPM SATA дисков + журналы osd на ssd выдают что-то около 100 МБ/c на диск при XFS, который рекомендуют в продакшн.
Я не знаю что у тебя хранилище сейчас, но если интересны плюшки Сeph, то есть смысл попробовать собрать 3 сервера с 6-12 шпинделями и одним ssd на каждом + правильный контроллер.
Но, на днях видел инициативу в сообществе о создании некоего калькулятора основанного на замерах конкретных конфигураций — www.spinics.net/lists/ceph-users/msg01738.html
ceph osd treeи все поймете.Вы же не делаете RAID поверж прицепленых дисков с полки где тоже сделали RAID?
Я имел в виду возможно ли удаленно посмотреть по ssh или teamviewer?
Если есть такие простаивающие ресурсы как дисковые полки, их можно попробовать разбить по одному LUN на каждую ноду. Специально закупать классическую СХД под Ceph нет никакого экономического смысла.
Дело в том, что демоны мониторинга mon находятся в кворуме — большинство определяет состояние кластера. То есть комбинации 1, 2:3, 3:5, 4:6 и т.д.
Не совсем так. CephFS это не уровень, это проект выстроенный «сверху» над хранилищем.
RBD и RADOS Gateway уже работают у многих в продакшн, погуглите.
Скорое напишу подробнее о RADOS Gateway.
Многие путаются между CephFS и собственно самим хранилищем Ceph (RADOS). Вот так выглядит «экосистема»: