Pull to refresh

Comments 51

Вы используете Ceph на выделенном кластере (чисто под хранилище) или совместно с другим софтом (прямо на ноде)?
Как мы отметили, роли compute и storage совмещены.
Какая сеть используется между OSD?
DDR/10GigE стоят в пределах десятипроцентной разницы столько же. В пределах стойки разница вообще не заметна.
Почему выбор пал именно на Ceph, а не на вполне себе стабильный Gluster?
Gluster является стабильным, в каком-то понимании, но не производительным. К тому же, во время выбора решения гластер не обладал ни драйвером в qemu, ни кворумом.
Зачем для гластера кворум? И кстати по поводу производительности Ceph умеет RDMA over IB?
Для рекавери. Без свойства автоматического восстановления применять кластерную фс в публичном облаке нельзя.
RDMA транспорт будет в обозримом будущем, но он не дает большого прироста на обычных операциях — уменьшается задержка, связанная с TCP стеком и соответствующая нагрузка на процессор, в современных системах тоже достаточно скромная удельно.
Если клиент обращается к объекту, который находится в degraded состоянии, Ceph вне очереди восстановит объект и его копии, а затем выполнит запрос клиента. Такой подход обеспечивает минимальное латенси I/O даже тогда, когда восстановление кластера идет полным ходом.

Нет ли тут противоречия?
К сожалению, тут вкралась неточность — не degraded, a recovering, т.е. восстанавливающийся в настоящий момент времени объект. Такой объект будет восстановлен с наибольшим приоритетом, потому что состояние recovering блокирует операции из-за возможного изменения положения primary копии.
Вы держите реплики в разных ДЦ? Если да — как Ceph реагирует на проблемы с меж-ДЦ каналом?
Нет, это как раз из области bad practices, мы упомянули об этом в статье.
Вы про фразу
Теоретически, подобный подход позволяет осуществлять в том числе гео-репликацию в реальном времени, однако на практике это можно использовать лишь в режиме Object Storage, поскольку в режимах CephFS и RBD задержки операций будут слишком велики.
, да? Это понятно. Я почему-то полагал, что вы и Object Storage делаете.

Перефразирую тогда вопрос. Как ведёт себя Ceph при потере одной стойки? Через сколько секунд сервис начинает работать со штатными временами ответов? Данные, которые попали на вылетевшие машины, переходят в режим read only, или для них восстанавливается копия на свободных дисках?
Если говорить о, допустим, трех стойках, RF=3 и одной вылетевшей, то латенси устаканится примерно за минуту. Данные, безусловно, доступны на чтение и на запись сразу после пересчета расположения новых primary копий(что в масштабе 500тб будет занимать 5-10 секунд).
Если это не коммерческая тайна, какой примерно общий объем хранилища на базе ceph у вас? Сколько всего задействовано серверов/дисков непосредственно для хранения?
Можем ответить для масштаба стойки — примерно 110 терабайт с учетом трехкратной репликации, то есть 350 «сырых».
Не планируете сделать сравнение Ceph, Gluster и DRBD? Понимаю, что последнее не имеет всех тех же возможностей. Но всё же.
Гм, скорее нет — гластер настолько отстает в плане производительности, что делать сравнение равносильно принятию инвалида в грузчики по программе equal opportunities. Можно было бы сравнить Glusterfs и Cephfs — здесь первая, несомненно, впереди по ряду факторов, но это решение для очень узкого набора задач и, боюсь, практически никому не будет интересно.
>аппаратный отказ одной ноды незаметен для пользователей как событие
если нода = OSD то как речь про отказ соответствующего физического диска? или нода=физический сервер?(но тогда, с учетом что по вашим словам у вас и Ceph и гипервизор на одних и тех же нодах, что будет с теми виртуалками что жили на этом сервере?)
Нода — физический сервер. Виртуалки, безусловно, потеряют исполняемое состояние если нода «сгорит», то есть станет недоступной моментально, в этом случае они будут запущены заново в других местах автоматически. Аппаратный отказ подразумевает все иные классы событий — битая память, умерший бп, перегревающийся до троттлинга процессор и так далее.
А виртуалки поднимаются в том же состоянии в котором они были в случае физического отказа сервера?
Что происходит в случае если виртуалка работает «boot-from-volume» и на compute ноде отваливается сеть?
В первом вопросе у вас заключается сам ответ — да, безусловно, состояние и конфигурация виртуалок остаются. У нас нет противопоставления опенстековскому boot from volume — все машины всегда работают только с rbd. В этом случае нода приравнивается к сгоревшей и машины также перезапускаются.
Какую ОС используете для физических серверов (KVM гипервизоры и ноды ceph'a). Насколько хорошо эта ОС себя показала?
Свой дистрибутив с базой на debian stable.
Смотрели на этапе выбора, но у нее довольно конские лицензионные условия и очень мало информации по опыту применения в открытом доступе.
Не смотрели, но, судя по всему, правильно. POSIX слой с точкой монтирования в хосте — огромная проблема в плане совместимости.
Совместимости чего с чем? Но moose здесь и правда не подойдёт, потому как надо выдавать блочные устройства, а moose всё-таки FUSE-based.
Блочные устройства можно размещать на фс, в этом нет проблем. Проблема в том, что хост должен «уметь» эту фс. В случае Ceph гипервизор вообще не знает о том, что первый существует, и это хорошо — можно поставить пачку гиперви или esx хостов и подцепить к хранилищу через iscsi реэкспорт.
Я правильно понимаю, что Ceph нормально переваривает ситуацию, когда на нодах стороджа размер «сырых» дисков сильно разный?
Да, достаточно правильно указать вес — впрочем, начиная с cuttlefish, вес ставится автоматически в зависимости от размера диска.
А как проходит миграция виртуалок? Не бывает ли проблем?
Или у вас всякие HA не используются?
А то после описанного бага в DRBD как то страшно.
Нет, миграция совершенно прозрачная и без ощутимого даунтайма сети при переучивании маршрутов.
А рулится все это через OpenStack? Или что-то другое?
Нет, оркестровка полностью самописная. К слову, мы считаем, что все опенсорсные продукты для оркестровки облаков очень сильно недотягивают до нашего уровня в смысле как минимум интегрированности компонент.
в нашем облачном хостинге


А как бы посмотреть как будет меняться цена в вашем хостинге при выборе своих параметров при создании сервера? (в варианте «без границ»/«по потреблению»)
Не хочется создавать бесполезный аккаунт, а информация интересна. Может есть какой-нибудь demo-аккаунт для ознакомления с админкой?
На днях выкатим соответствующую главную страницу, сейчас доверстываем.
Гуру подскажите, пожалуйста, нужен ли MetaDataServer если юзается Ceph Block Device (aka. RBD)? К примеру, кластер Proxmox юзает кластер Ceph.
Нет, не нужен. В статье выше, к слову говоря, подробно расписаны роли демонов :)
Спасибо большое за ответ. Я на 99% понял роль MDS, но решил подвериться. Уфффф нет MDS нет проблем =) тем более его не удалить из кластера нормально.
А как обстоит дело с балансировкой по физическим линкам. Можно использовать multipath I/O совместно с Ceph? Или есть ли встроенный подобный функционал?
Multipath не нужен в силу архитектуры продукта, можно использовать обычный бондинг для большей отказоустойчивости отдельной ноды хранилища.
Наверное я не верно сформулировал свой вопрос.

Предположим что у нас нет средств на приобретение 10G Ethernet и прочих скоростных вещей вроде InfiniBand. А в наличии есть 1G Ethernet, многопортовые карточки и коммутатор. В таком случае бондинг не сильно поможет. В случае применения бондинга путь от одной ноды до другой будет всегда пролегать через один и тот же порт. Можно заставить ядро linux чередовать отправку пакетов с нескольких интерфейсов, но в случае применения коммутатора это бесполезно.

multipath I/O в случае с iSCSI может позволить задействовать несколько линков одновременно без участия в этом процессе бондинга. Суть вопроса сводилась к том можно ли в ceph применять напрямую multipath I/O или в нем есть какие то свои механизмы для распределения трафика по нескольким физическим интерфейсам (в контексте повышения пропускной способности).
В случае обычного коммутатора вам с очень большой вероятностью хватит линуксового balance-xxx. У цефа нет точек, являющихся средоточием пропускной способности, так что половинка от максимальной скорости на пару 5-tuple будет очень хорошо работать, за исключением граничных случаев (один клиент, потребляющий всю пропускную способность кластера).
Пожалуйста разжуйте ситуацию с Placement Group. Прочёл официальную документацию и не понял глубинного смысла в увеличении кол-ва PG.
Чем больше число PG, тем более гладким получится псевдослучайное распределение данных. С другой стороны, при числе PG более 50..70к в одном пуле начинаются проблемы с производительностью кластера.
Only those users with full accounts are able to leave comments. Log in, please.