Комментарии 15
Надеюсь, что даже если Вы не будете повторять весь этот эксперимент в полном объеме
Но почему?
И появился же штатный механизм для этого docs.ceph.com/docs/mimic/rbd/iscsi-target-cli
Так веселее. И производительней. Librbd добавляет достаточно заметный оверхед. Плюс появляются всякие крайне интересные плюшки типа возможности сделать blktrace и т.д., нет риска вляпаться в кэш в юзерспейсе и прочее. И плюс универсальности. Можно другой таргет впилить например. Ну да, кое что может не работать ибо ядерный клиент беднее.
НЛО прилетело и опубликовало эту надпись здесь
А почему просто не поставить на этот сервер ceph-клиента? Как модуль ядра или через FUSE, и просто примонтировать искомый образ. Зачем вообще тут iSCSI?
В hyper-v? Если данные из образа нужны внутри windows? Например, файл БД на 400гб, и копировать его куда-то через smb, это ещё на пару часов.
Почему на пару часов? вполне можно уложиться за несколько минут при наличии нескольких линков 10/25 gbps и нормальных дисках, тем более есть smb multichannel
Когда возникает такая ситуация (раз в пару лет) то этот образ почему-то нужно открыть или на отдельно стоящем сервере, или вообще на десктопе, до которых только гигабит. И вдобавок к этому на этих клиентах в этот момент времени будет свободно только 350гб из 400, и начинается: надо бы почистить место, потом надо бы скопировать, может проще ещё одну виртуальную воткнуть, потом подключиться к ней, а потом…
А для винды нет ceph-драйвера? Не знал, вопрос снимаю..
А зачем подключать образ как блочное устройство?
Не надо совсем.
Не надо совсем.
Наверое за тем, что образ блочного устройства надо видеть как блочное устройство?
Для цепха ISCSI шлюз сам все монтирует, вот ман: https://docs.ceph.com/docs/master/rbd/iscsi-target-cli/
Просто создаёшь пул, а в нем образ, который подрубаешь через gwcli.
Уже объяснялось раньше.
Здесь решается больше одной цели, и в частности:
1. Получить производительность (хоть какую-нибудь)
2. Избавиться от юзерспейса — чтобы остановка сервиса не приводила к похоронам таргетов
2. Задействовать каждый «кубик» по отдельности, чтобы:
2.1. Понять как работать с каждым компонентом
2.2. Иметь возможность применять полезные инструменты диагностики
Здесь решается больше одной цели, и в частности:
1. Получить производительность (хоть какую-нибудь)
2. Избавиться от юзерспейса — чтобы остановка сервиса не приводила к похоронам таргетов
2. Задействовать каждый «кубик» по отдельности, чтобы:
2.1. Понять как работать с каждым компонентом
2.2. Иметь возможность применять полезные инструменты диагностики
Наверное, стоит добавить в статью про эту разницу.
docs.ceph.com/docs/master/rbd/iscsi-overview
Интересно, почему они в своем шлюзе используют librbd, а не ядерный модуль.
docs.ceph.com/docs/master/rbd/iscsi-overview
Each iSCSI gateway runs the Linux IO target kernel subsystem (LIO) to provide the iSCSI protocol support. LIO utilizes a userspace passthrough (TCMU) to interact with Ceph’s librbd library and expose RBD images to iSCSI clients.
Интересно, почему они в своем шлюзе используют librbd, а не ядерный модуль.
Юзерспейсный клиент быстрее и проще развивать, поскольку он строится на общей кодовой базе Ceph, поэтому он поддерживает больше «фич» RBD. Ядерный клиент это отдельный проект — но он производительней, поскольку меньше гоняет данные kernelspace <-> userspace. Когда кластер all-flash на хороших процессорах и хорошей сети, разница достаточно существенна.
Спасибо, понятно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ceph через iSCSI — или на лыжах стоя в гамаке