diff --git a/_static/compare-old-new-tcmu-runner-rw_bs64k_d32_bw.-2Dtrend.png b/_static/compare-old-new-tcmu-runner-rw_bs64k_d32_bw.-2Dtrend.png new file mode 100644 index 0000000..709c8f2 Binary files /dev/null and b/_static/compare-old-new-tcmu-runner-rw_bs64k_d32_bw.-2Dtrend.png differ diff --git a/_static/compare-rw_bs64k_d32_bw.-2Dtrend.png b/_static/compare-rw_bs64k_d32_bw.-2Dtrend.png new file mode 100644 index 0000000..9ce0656 Binary files /dev/null and b/_static/compare-rw_bs64k_d32_bw.-2Dtrend.png differ diff --git a/about.rst b/about.rst index 487cd51..18bb813 100644 --- a/about.rst +++ b/about.rst @@ -22,3 +22,4 @@ http://ceph-docs.readthedocs.io * Maksim Shchuplov * Vitaliy Filippov * Коренберг Марк +* Алексей Костин diff --git a/ceph-choice.rst b/ceph-choice.rst index 11efc50..a1bbbbb 100644 --- a/ceph-choice.rst +++ b/ceph-choice.rst @@ -23,8 +23,6 @@ * Огромное S3-хранилище. Миллиард объектов в Ceph будут болью, лучше рассмотреть иные решения, например, поверх чистых k-v хранилищ. -* iscsi + rbd. Очень сложно. - * Когда все данные вмещаются на один сервер. Нужно 50ТБ? Соберите RAID. diff --git a/cephiscsi.rst b/cephiscsi.rst new file mode 100644 index 0000000..c15d01e --- /dev/null +++ b/cephiscsi.rst @@ -0,0 +1,210 @@ +************ +Ceph + iscsi +************ + +В случае использования в роли СХД кластер Ceph, а в роли клиента сервера с ОС на базе Linux, использование iscsi +не выглядит целесообразным, т.к. можно использовать rbd нативно, но если +клиентом выступает сервер с Vmware или Windows, других вариантов использовать блочное устройство на клиенте, +кроме как отдать rbd по iSCSI, на данный момент нет. + +В дальнейшем речь пойдет об организации доступа на клиентах к rbd по протоколу iSCSI. + +Терминология +============ +Терминология iSCSI во многом основывается на терминологии, использующейся в SCSI: + +* initiator — тот, кто устанавливает соединение с целью(target). Чаще всего это узел (в общем случае) осуществляет ввод/вывод на блочные устройства. +* target — экспортируемый объект. В зависимости от контекста цель(target) называют или целиком экспортирующий узел, или только экспортируемый объект. Сам объект может делиться на lun’ы. +* Портал — группа целей(targets), которые анонсируются вместе. Чаще всего один узел хранения — один портал. +* IQN — полное имя участника взаимодействия. На практике существует iqn у инициатора и у цели(target). +* endpoint — уточнённое имя ресурса, чаще всего включает в себя iqn, номер LUN’а и указание на конкретный метод доступа к нему (например, номер соединения, LUN и IP-адрес, с которого следует получать доступ к устройству). +* LUN (Logical Unit Number) — номер объекта внутри цели(target). Ближайшим аналогом является раздел диска или отдельный том. +* LIO - Linux-IO (LIO) Target является открытой имплементацией SCSI таргета которая включена в стандартное ядро Linux. +* kRBD - модуль rbd в ядре Linux +* ALUA - Asymmetric Logical Unit Access, протокол внутри спецификаций SCSI-2 и SCSI-3, позволяющий правильно + организовывать доступ к данным, доступным по различным путям с различными характеристиками доступа. + Для его использования, понимать ALUA должны все участники, как система хранения, так и OS хоста. +* MTU - maximum transmission unit, означает максимальный размер полезного блока данных одного пакета + (англ. payload), который может быть передан протоколом без фрагментации. + + +Ceph-iscsi +========== + +Первый, и основной способ, это использование ceph-iscsi. Продукт этот на данный момент зрелый, поддерживается +компанией RedHat и, с недавних пор, SUSE. + +Пакеты можно взять на официальном репозитории https://download.ceph.com/ceph-iscsi/ . +Установка тривиальна и хорошо описана в официальной документации Ceph http://docs.ceph.com/docs/master/rbd/iscsi-overview/ , +так и в документации Red Hat Ceph Storage 3+ https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/block_device_guide/using_an_iscsi_gateway . +В документации так же описано как настраивать инициаторы, и этих правил следует придерживаться, +т.к. у текущей реализации есть свои ограничения https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3.0/pdf/release_notes/Red_Hat_Ceph_Storage-3.0-Release_Notes-en-US.pdf , например: + +:: + + Having more than one path from an initiator to an iSCSI gateway is not supported + In the iSCSI gateway, tcmu-runner might return the same inquiry and Asymmetric logical + unit access (ALUA) info for all iSCSI sessions to a target port group. + This can cause the initiator or multipath layer to use the incorrect port info to reference + the internal structures for paths and devices, which can result in failures, failover and failback failing, + or incorrect multipath and SCSI log or tool output. Therefore, having more than one iSCSI session + from an initiator to an iSCSI gateway is not supported. (BZ#1502740) + +Стоит отметить что ограничения описанные в документации связаны с особенностью реализации tcmu-runner'а и +касаются версии 1.3, возможно, с развитием проекта ограничения частично +будут ослаблены. Актуальный changelog можно узнать на странице проекта на github https://github.com/open-iscsi/tcmu-runner/releases + +Из приятных бонусов этого решения, по сравнению с вариантом kRBD + LIO: + +* Централизованое управление через утилиту gwcli +* Простой деплой самого приложения (описана установка вручную и через ansible) +* Интегрированность в Ceph (в частности, в выводе `ceph -s` можно увидеть `tcmu-runner: 3 daemons active` ) +* Поддержка SCSI-3 persistent reservations (так же известный как SCSI-3 PR или SCSI-3 PGR) + http://www.gonzoleeman.net/scsi-3-pgr-tutorial-v1.0 , которая может понадобиться, + например, для серверов на базе ОС Windows для кворумных дисков или общих ресурсов для БД или кластеризиции, т.к. в этом + случае обязательно наличие устройства поддерживающего persistant reservation (если используется блочное устройство, а не samba). + + SCSI-3 PR обеспечивает доступ для нескольких узлов к устройству и одновременно блокирует доступ для других узлов. + SCSI-3 PR использует концепцию регистрации и резервирования. Каждая система регистрирует свой «ключ» на устройстве + поддерживающим SCSI-3 (например, эксклюзивное чтение). https://www.systutorials.com/docs/linux/man/8-sg_persist/ + +* Отказоустойчивость из коробки, т.к. вы анонсируете портальную группу, нет нужды синхронизировать конфигурацию на серверах, + настраивать каждый из порталов и настраивать взаимосвязь, и ваш клиент может переключиться по failover на другой портал. +* Нет необходимости (tcmu-runner 1.3+) маппить rbd, в связи с этим нет ограничений на включенные features rbd. + +Минусы этого решения: + +* Не будет бонусов в виде отказоустойчивости, если инициатор не умеет с этим работать (нужна поддержика ALUA и multipath) +* В основе продукта лежит tcmu-runner, который **значительно** медленнее работает чем вариант + "замаппить rbd и отдать его как диск", т.к. последний вариант близок по скорости к варианту отдать rbd нативно через librbd, + в то время, как вариант с tcmu-runner'ом медленнее в ~2 раза + +Особенности этого решения: + +Приведу здесь несколько графиков, снятых с помощью fio на достаточно слабом кластере. Тесты производились из ВМ +в которую одним из методов подключались диски (librbd, nfs-ganesha, ceph-iscsi, kRBD + LIO) + +Профиль: + +:: + + [global] + ioengine=libaio + direct=1 + buffered=0 + time_based=1 + size=20g + wait_for_previous + filename=/root/tests/bigfile + + [rw_bs64k_d32] + iodepth=32 + rw=randwrite + bs=4m + +* Разница между tcmu-runner версий 1.3.0 и версии 1.3.X с одним из последних патчей который повышает производительность, + который бэкпортировали себе в продукт RHCEPH компания RedHat + + .. image:: _static/compare-old-new-tcmu-runner-rw_bs64k_d32_bw.-2Dtrend.png + +| + +* Разница между различными бэкендами (raw iscsi в данном графике подразумевает kRBD + LIO, т.е. + без ceph-iscsi и tcmu-runner) + + .. image:: _static/compare-rw_bs64k_d32_bw.-2Dtrend.png + +| + +Из этих графиков видно что: + +#. TCMU-runner значительно медленее варианта с kRBD + LIO + +#. Работа по решению проблем со скоростью ведется, и стоит ожидать что в следующих версиях + скорость будет выше + + +kRBD + LIO +========== + +Второй вариант заключается в том что нужно замаппить rbd на систему предполагаемого таргета +и анонсировать как блочное устройство. + +Плюсы этого решения: + +* Скорость близка к нативному rbd +* Нет надобности ставить дополнительное ПО + +Минусы этого решения: + +* Так как не все rbd features реализованы в модуле rbd в ядре (далее kRBD), необходимо отключать все + features rbd выше layering (далее выдержка из master ветки ядра, что конкретно реализовано у Вас нужно смотреть в исходниках + ядра Вашего дистрибутива) + +:: + + /* Feature bits */ + #define RBD_FEATURE_LAYERING (1ULL<<0) + #define RBD_FEATURE_STRIPINGV2 (1ULL<<1) + #define RBD_FEATURE_EXCLUSIVE_LOCK (1ULL<<2) + #define RBD_FEATURE_DATA_POOL (1ULL<<7) + #define RBD_FEATURE_OPERATIONS (1ULL<<8) + +* Т.к. используется kRBD, существует вполне реальная опасность, что некорректно работающий инициатор может `положить` + не только iSCSI, но и кластер Ceph. Были случаи, когда Windows initiator "вешал" модуль LIO, а + вместе с ним падал и Ceph, т.к. появлялось много blocked requests, связанных с sub ops'ами. + +* Если нужна отказоустойчивость непосредственно iSCSI gateway, придётся делать её самому. +* Больше слоев абстракций между Ceph'ом и инициатором + +Плюсы этого решения: + +* Относительная простота + +* Скорость работы + +При работе с kRBD следует максимально обезопасить кластер, для этого нужно обновлять ПО на инициаторе (например кумулятивные +апдейты windows), и обновлять версию ядра на кластере с iSCSI таргетами, т.к. модули LIO и RBD находятся в ядре, +более новые ядра ведут себя стабильнее даже когда начинаются проблемы с подсистемой iSCSI (LIO), это уже не так пагубно влияет +на кластер Ceph. Желательно использовать 4.14+. + +У автора данной заметки windows initiator с определенным набором апдейтов с MTU 9000 на сетевом адаптере выводил из строя +кластер Ceph, и при этом же с MTU 1500 такой проблемы не наблюдалось. + +Если нужен SCSI-3 PR, то оптимальным вариантом будет сделать "плавающий" +таргет. Самый простой вариант сделать virtual ip (далее vip), настроить таргеты на прослушивание этого vip, и сделать +миграцию адреса через pacemaker, keepalived, etc. + +В этом случае будет работать Persistant Reservation, т.к. PR эмулируется LIO локально на таргете. +Но все запросы будут приходить на один сервер + +Если не требуется поддержка PR, то можно сделать несколько разных порталов с идентичными таргетами (c одинаковыми wwn), и настраивать +failover на инициаторах (например, через multipath). В некоторых решениях, используется кластерный lvm (clvmd или lvmlockd). + + +Резюмируя вышесказанное +======================= + +Выводы: + +#. Самый простой отказоустойчивый способ использовать iSCSI и Ceph - использовать ceph-iscsi. Все остальные способы + потребуют инженерной смекалки и осторожности. + +#. Всегда предварительно нужно тестировать работу на конкретном оборудовании. + Упомянутая проблема с MTU на других моделях серверов при идентичной версии ПО не воспроизводилась, + т.е. могут встретиться неожиданные аппаратно-программные проблемы (не обязательно таких же проблем, как описаны выше). + В большей степени это касается случая с kRBD, т.к. в этом случае задействованы kRBD и block layer ядра, и, скорее всего + установки с tcmu-runner (в т.ч. ceph-iscsi) не будут подверженны подобным проблемам затрагивающим Ceph. + +#. Очень желательно ставить обновления, на системы, что на Linux (обновление системы и ядра), что Windows, ставить + последние прошивки и драйвера для сетевых устройств. + +#. В ядро rhel постоянно бэкпортируют части кода из нового ядра, но в некоторых случаях новые ядра ведут себя стабильнее. + А т.к. модули Lio и модуль rbd находятся в ядре, и в них регулярно вносят изменения, то это напрямую влияет на + возможности и стабильность кластера. В официальной документации рекомендованы lts ядра версий 4.9 или 4.14. Если + используется ceph-iscsi, то ядра 4.16+/ядра из rhel 7.5+, т.к. для его работы нужны специфичные патчи в ядро. + + + + + diff --git a/index.rst b/index.rst index 47b13c1..9766a09 100644 --- a/index.rst +++ b/index.rst @@ -14,6 +14,7 @@ bench bluestore cephfs + cephiscsi cpu_and_mem disks how-it-works