Comments 51
Вы используете Ceph на выделенном кластере (чисто под хранилище) или совместно с другим софтом (прямо на ноде)?
Какая сеть используется между OSD?
Почему выбор пал именно на Ceph, а не на вполне себе стабильный Gluster?
Gluster является стабильным, в каком-то понимании, но не производительным. К тому же, во время выбора решения гластер не обладал ни драйвером в qemu, ни кворумом.
Зачем для гластера кворум? И кстати по поводу производительности Ceph умеет RDMA over IB?
Для рекавери. Без свойства автоматического восстановления применять кластерную фс в публичном облаке нельзя.
Если клиент обращается к объекту, который находится в degraded состоянии, Ceph вне очереди восстановит объект и его копии, а затем выполнит запрос клиента. Такой подход обеспечивает минимальное латенси I/O даже тогда, когда восстановление кластера идет полным ходом.
Нет ли тут противоречия?
Вы держите реплики в разных ДЦ? Если да — как Ceph реагирует на проблемы с меж-ДЦ каналом?
Нет, это как раз из области bad practices, мы упомянули об этом в статье.
Вы про фразу
Перефразирую тогда вопрос. Как ведёт себя Ceph при потере одной стойки? Через сколько секунд сервис начинает работать со штатными временами ответов? Данные, которые попали на вылетевшие машины, переходят в режим read only, или для них восстанавливается копия на свободных дисках?
Теоретически, подобный подход позволяет осуществлять в том числе гео-репликацию в реальном времени, однако на практике это можно использовать лишь в режиме Object Storage, поскольку в режимах CephFS и RBD задержки операций будут слишком велики., да? Это понятно. Я почему-то полагал, что вы и Object Storage делаете.
Перефразирую тогда вопрос. Как ведёт себя Ceph при потере одной стойки? Через сколько секунд сервис начинает работать со штатными временами ответов? Данные, которые попали на вылетевшие машины, переходят в режим read only, или для них восстанавливается копия на свободных дисках?
<тут был комментарий мимо ветки>
Если это не коммерческая тайна, какой примерно общий объем хранилища на базе ceph у вас? Сколько всего задействовано серверов/дисков непосредственно для хранения?
Не планируете сделать сравнение Ceph, Gluster и DRBD? Понимаю, что последнее не имеет всех тех же возможностей. Но всё же.
Гм, скорее нет — гластер настолько отстает в плане производительности, что делать сравнение равносильно принятию инвалида в грузчики по программе equal opportunities. Можно было бы сравнить Glusterfs и Cephfs — здесь первая, несомненно, впереди по ряду факторов, но это решение для очень узкого набора задач и, боюсь, практически никому не будет интересно.
>аппаратный отказ одной ноды незаметен для пользователей как событие
если нода = OSD то как речь про отказ соответствующего физического диска? или нода=физический сервер?(но тогда, с учетом что по вашим словам у вас и Ceph и гипервизор на одних и тех же нодах, что будет с теми виртуалками что жили на этом сервере?)
если нода = OSD то как речь про отказ соответствующего физического диска? или нода=физический сервер?(но тогда, с учетом что по вашим словам у вас и Ceph и гипервизор на одних и тех же нодах, что будет с теми виртуалками что жили на этом сервере?)
Нода — физический сервер. Виртуалки, безусловно, потеряют исполняемое состояние если нода «сгорит», то есть станет недоступной моментально, в этом случае они будут запущены заново в других местах автоматически. Аппаратный отказ подразумевает все иные классы событий — битая память, умерший бп, перегревающийся до троттлинга процессор и так далее.
Какую ОС используете для физических серверов (KVM гипервизоры и ноды ceph'a). Насколько хорошо эта ОС себя показала?
смотрели ли вы в сторону FhGFS?
Смотрели на этапе выбора, но у нее довольно конские лицензионные условия и очень мало информации по опыту применения в открытом доступе.
Я правильно понимаю, что Ceph нормально переваривает ситуацию, когда на нодах стороджа размер «сырых» дисков сильно разный?
Да, достаточно правильно указать вес — впрочем, начиная с cuttlefish, вес ставится автоматически в зависимости от размера диска.
в нашем облачном хостинге
А как бы посмотреть как будет меняться цена в вашем хостинге при выборе своих параметров при создании сервера? (в варианте «без границ»/«по потреблению»)
Не хочется создавать бесполезный аккаунт, а информация интересна. Может есть какой-нибудь demo-аккаунт для ознакомления с админкой?
Гуру подскажите, пожалуйста, нужен ли MetaDataServer если юзается Ceph Block Device (aka. RBD)? К примеру, кластер Proxmox юзает кластер Ceph.
А как обстоит дело с балансировкой по физическим линкам. Можно использовать multipath I/O совместно с Ceph? Или есть ли встроенный подобный функционал?
Multipath не нужен в силу архитектуры продукта, можно использовать обычный бондинг для большей отказоустойчивости отдельной ноды хранилища.
Наверное я не верно сформулировал свой вопрос.
Предположим что у нас нет средств на приобретение 10G Ethernet и прочих скоростных вещей вроде InfiniBand. А в наличии есть 1G Ethernet, многопортовые карточки и коммутатор. В таком случае бондинг не сильно поможет. В случае применения бондинга путь от одной ноды до другой будет всегда пролегать через один и тот же порт. Можно заставить ядро linux чередовать отправку пакетов с нескольких интерфейсов, но в случае применения коммутатора это бесполезно.
multipath I/O в случае с iSCSI может позволить задействовать несколько линков одновременно без участия в этом процессе бондинга. Суть вопроса сводилась к том можно ли в ceph применять напрямую multipath I/O или в нем есть какие то свои механизмы для распределения трафика по нескольким физическим интерфейсам (в контексте повышения пропускной способности).
Предположим что у нас нет средств на приобретение 10G Ethernet и прочих скоростных вещей вроде InfiniBand. А в наличии есть 1G Ethernet, многопортовые карточки и коммутатор. В таком случае бондинг не сильно поможет. В случае применения бондинга путь от одной ноды до другой будет всегда пролегать через один и тот же порт. Можно заставить ядро linux чередовать отправку пакетов с нескольких интерфейсов, но в случае применения коммутатора это бесполезно.
multipath I/O в случае с iSCSI может позволить задействовать несколько линков одновременно без участия в этом процессе бондинга. Суть вопроса сводилась к том можно ли в ceph применять напрямую multipath I/O или в нем есть какие то свои механизмы для распределения трафика по нескольким физическим интерфейсам (в контексте повышения пропускной способности).
В случае обычного коммутатора вам с очень большой вероятностью хватит линуксового balance-xxx. У цефа нет точек, являющихся средоточием пропускной способности, так что половинка от максимальной скорости на пару 5-tuple будет очень хорошо работать, за исключением граничных случаев (один клиент, потребляющий всю пропускную способность кластера).
Пожалуйста разжуйте ситуацию с Placement Group. Прочёл официальную документацию и не понял глубинного смысла в увеличении кол-ва PG.
Sign up to leave a comment.
Ceph: Cloud Storage без компромиссов