Comments 21
Мощно.
Спасибо за статью!
Поделитесь ссылками на баги?
Да, ссылки все потерялись из статьи, сейчас мы их впилим обратно.
Тот самый баг Ceph http://tracker.ceph.com/issues/13098
Производителя материнки «паленых» серверов не назовете?
Спасибо за статью, но есть пара вопросов.
Т.к. количество машин не чётное предполагаю что в случае смерти одной из них гостевые системы переедут на оставшиеся. Вопрос в следующем, при смерти какого максимального кол-ва машин вы всё ещё будуте выполнять SLA по производительности?
InfiniBand действительно не самое бюджетное решение, чем не устроил Fibre Channel?
В итоге вся сборка состояла из 12 машин: 3 в кластере хранилища и 9 в вычислительном кластере.
Т.к. количество машин не чётное предполагаю что в случае смерти одной из них гостевые системы переедут на оставшиеся. Вопрос в следующем, при смерти какого максимального кол-ва машин вы всё ещё будуте выполнять SLA по производительности?
InfiniBand действительно не самое бюджетное решение, чем не устроил Fibre Channel?
Необходимо добавить ещё один IB-коммутатор и соединять с имеющимся последовательно.После появления FC Gen 6, не рассматривали вариант с Brocade или возможными аналогами?
при смерти какого максимального кол-ва машин вы всё ещё будете выполнять SLA по производительности?На сегодняшний день допускается выход из строя одного сервера хранилища и двух вычислительных серверов.
После появления FC Gen 6, не рассматривали вариант с Brocade или возможными аналогами?К сожалению, этот вариант мы не рассматривали.
InfiniBand действительно не самое бюджетное решение, чем не устроил Fibre Channel?
Скажите, пожалуйста, а OpenVZ (или какую-либо другую систему контейнеризации) с InfiniBand Вы не пробовали скрещивать на уровне дать доступ к полноценной IB сети из контейнеров?
Почему не proxmox?
Спасибо за статью, интересно почитать про «живое» применение ceph в продакшне. Хотел бы задать вопрос, чем проводились тесты на чтение и запись? Насколько процентов заполнялись диски в процессе теста?
ceph: bw=393.181 KB/s, iops=3071
ssd: bw=70.371 KB/s, iops=549
Проводился тест fio, на volume 30 Гб с величиной блока 128 Кб и глубиной очереди 8.
А как вообще может распределённая-сетевая система выдавать в разы большие показатели, чем локальный SSD, причём и по иопсам и по полосе одновременно?
Так совершенно разных поколений железо сравнивалось в этом тесте или я чего-то не понимаю? Ведь Infiniband наверное не ускоряет SSD на узлах кластера хранения.
В итоге мы приходим к тому, что для CEPH нужно много серверов с 4-6 дисками и дисками объемом до 2тб.
Только вот дороговато получается в такой схеме. Ну тут каждый решает сам. Объем vs Iops и отказоустойчивость, но почему-то сначала выбирают объем, а потом удивляются а где наши iops и чего оно так долго ребилдится?
Пользуясь случаем порекламирую канал, в котором обсуждают ceph openstack и обычно дают оперативную помощь новичкам. https://telegram.me/pro_openstack
Только вот дороговато получается в такой схеме. Ну тут каждый решает сам. Объем vs Iops и отказоустойчивость, но почему-то сначала выбирают объем, а потом удивляются а где наши iops и чего оно так долго ребилдится?
Пользуясь случаем порекламирую канал, в котором обсуждают ceph openstack и обычно дают оперативную помощь новичкам. https://telegram.me/pro_openstack
Скажите пожалуйста, вы используете bluestore или filestore в качестве бэкенда хранения? И еще вопрос — включали ли вы компрессию?
Большинство выводов верны. Но позволю себе дополнить.
1. Не используйте кэш из SSD. Кэш помогает сгладить пики, но вовсе не решает проблему производительности ваших HDD. Это с играет с вами злую шутку, даст вам запустится а затем когда данные перестанут влезать в кэш вы сильно попадете. Причем сразу и сильно. Если в случае с SSD в качестве основных дисков вы постепенно начнете испытывать «тормоза», и у вас будет время что бы модернизировать систему, то в случае переполнения кэша сразу наступит ахтунг.
2. Сеть, чем быстрее тем лучше. Используйте две сети public и cluster. Так как при пересинхронизации ceph использует именно кластерную сеть и public сеть забитая клиентами для этого подходит очень плохо. Используйте LACP(bonding)+VPC(или его аналог). Избегайте единой точки отказа. Падение линка и его восстановление это пересинхронизация, а этого можно избежать если предусмотреть резервирование. Без этого вы получите геморой на ровном месте.
3. Не используйте корзины с большим количеством дисков. Здесь я с автором не соглашусь. Не игнорируйте рекомендации разработчиков! Используйте много машин с небольшим количеством дисков. Или же тестируйте пересинхронизацию под большой клиентской нагрузкой.
В остальном отличная статья и руководство к действию. Все выводы верные. Нужна хорошая сеть и быстрые диски. Эти параметры должны быть сбалансированы. Тогда все у вас будет хорошо. И не читайте всякий бред типа «анатомия катастрофы». Где напихали по 15 SSD в три машины, обвязали 10Г сетью, а потом понаписали всякой ереси.
1. Не используйте кэш из SSD. Кэш помогает сгладить пики, но вовсе не решает проблему производительности ваших HDD. Это с играет с вами злую шутку, даст вам запустится а затем когда данные перестанут влезать в кэш вы сильно попадете. Причем сразу и сильно. Если в случае с SSD в качестве основных дисков вы постепенно начнете испытывать «тормоза», и у вас будет время что бы модернизировать систему, то в случае переполнения кэша сразу наступит ахтунг.
2. Сеть, чем быстрее тем лучше. Используйте две сети public и cluster. Так как при пересинхронизации ceph использует именно кластерную сеть и public сеть забитая клиентами для этого подходит очень плохо. Используйте LACP(bonding)+VPC(или его аналог). Избегайте единой точки отказа. Падение линка и его восстановление это пересинхронизация, а этого можно избежать если предусмотреть резервирование. Без этого вы получите геморой на ровном месте.
3. Не используйте корзины с большим количеством дисков. Здесь я с автором не соглашусь. Не игнорируйте рекомендации разработчиков! Используйте много машин с небольшим количеством дисков. Или же тестируйте пересинхронизацию под большой клиентской нагрузкой.
В остальном отличная статья и руководство к действию. Все выводы верные. Нужна хорошая сеть и быстрые диски. Эти параметры должны быть сбалансированы. Тогда все у вас будет хорошо. И не читайте всякий бред типа «анатомия катастрофы». Где напихали по 15 SSD в три машины, обвязали 10Г сетью, а потом понаписали всякой ереси.
Sign up to leave a comment.
Как мы отказоустойчивый кластер запускали