Ceph через iSCSI — или на лыжах стоя в гамаке

    Есть ли среди нас (цефоводов) те, кто не любит «профессиональный экстрим»?

    Вряд ли — иначе бы мы не кувыркались с этим чрезвычайно интересным и забавным продуктом.

    Многие из тех, кто занимались эксплуатацией Ceph, встречали один не слишком частый (а скорее даже очень нечастый) но иногда востребованный кейс — подключить Ceph по iSCSI или FC. Зачем? Ну, например, подать образ с Ceph на почему-то еще не виртуализированный сервер Windows или Solaris. Или на виртуализированный, но посредством гипервизора, который не умеет Ceph — а их, как мы знаем, хватает. Например? Ну, например, HyperV или ESXi, которые активно используются. И если возникает задача подать образ с Ceph в гостевую машину, это превращается в весьма увлекательную задачу.

    Итак, дано:

    1. уже работающий кластер Ceph
    2. уже существующий образ который надо подать через iSCSI
    3. Имя пула mypool, имя образа myimage

    Начинаем?

    Прежде всего, когда мы говорим о FC или iSCSI, у нас появляются такие сущности как инциатор (initiator) и цель (target). Target это фактически сервер, initiator — клиент. Наша задача — с минимальными трудозатратами подать образ Ceph на инициатор. А значит, мы должны развернуть target. Но где, на каком компьютере?

    К счастью, в кластере Ceph у нас есть как минимум один компонент, чей IP-адрес фиксирован и на котором сконфигурирован один из самых важных компонентов Ceph, и этот компонент — монитор. Соответственно, на мониторе устанавливаем iSCSI target (и initator заодно, как минимум для тестов). Я делал это на CentOS, но для любого другого дистрибутива решение также подойдет — достаточно просто ставить пакеты тем способом который приемлем в вашем дистрибутиве.

    # yum -y install iscsi-initiator-utils targetcli

    Каково назначение устанавливаемых пакетов?

    • targetcli — утилита управления встроенным в ядро Linux SCSI-таргетом
    • iscsi-initiator-utils — пакет с утилитами используемыми для управления опять же встроенным в ядро Linux iSCSI initiator'ом

    Для того, чтобы подать образ через iSCSI на инициатор, есть два варианта развития событий — использовать userspace'ный бакэнд таргета или подключать образ как блочное устройство видимое для операционной системы и экспортировать его по iSCSI. Мы пойдем вторым путем — userspace'ный бакэнд пока находится в «экспериментальном» состоянии и для продуктивного использования слегка не готов. Кроме того, с ним есть подводные камни, о которых можно много разговаривать и (о ужас!) спорить.

    Если мы используем хоть сколь-нибудь стабильный дистрибутив с дооолгим циклом поддержки, то ядро у нас какой-нибудь древней-древней версии. Например в CentOS7 это 3.10.*, в CentOS8 это 4.19. А нам интересно ядро как минимум 5.3 (а скорее 5.4) и более новое. Почему? Потому, что по умолчанию образы в Ceph имеют подключенный набор опций, который не совместим со старыми ядрами. А значит, мы подключаем репозиторий с новым ядром для нашего дистрибутива (например, для CentOS это elrepo), устанавливаем новое ядро и перезагружаем систему чтобы работать с новым ядром:

    • Подключаемся к выбранному для эксперимента монитору
    • Подключаем репозитории elrepo по инструкции — elrepo.org/tiki/tiki-index.php
    • Устанавливаем ядро: yum -y --enablerepo=elrepo-kernel install kernel-ml
    • Перезагружаем сервер с монитором (у нас ведь три монитора, верно?)

    Подключаем образ как блочное устройство

    # rbd map mypool/myimage
    /dev/rbd0


    Осталось только сконфигурировать таргет. В этом примере я сконфигурирую таргет в т.н. demo-режиме — без аутентификации, видимым и доступным для всех. В продуктивной среде Вы, скорее всего, захотите сконфигурировать аутентификацию — но это немного out-of-scope сегодняшнего just-for-fun упражнения.

    Создаем бакэнд с именем disk1 сопоставленый файлу /dev/rbd/mypool/myimage. Указанный файл это автоматически созданная демоном udev символьная ссылка на /dev/rbd0. Мы используем именно символьную ссылку, поскольку имя устройства rbd может меняться из за порядка подключения образов Ceph к хосту.

    Создаем бакэнд:

    # targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage

    Создаем iSCSI таргет:

    # targetcli /iscsi create iqn.2020-01.demo.ceph:mypool

    Подключаем бакэнд как LUN к таргету:

    # targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1

    Донастраиваем таргет для demo-режима:

    # targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set \
    > attribute demo_mode_write_protect=0
    # targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set \
    > attribute generate_node_acls=1
    # targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set \
    > attribute cache_dynamic_acls=1


    Сохраняем конфигурацию:

    # targetcli saveconfig

    Проверяем наличие таргета:

    # iscsiadm -m discovery -t st -p 127.0.0.1:3260
    127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool


    Подключаем таргет:

    # iscsiadm -m node --login
    Logging in to [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (multiple)
    Login to [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] successful.


    Если Вы всё сделали правильно, то на сервере появится новый диск, который выглядит как SCSI-устройство, но на самом деле являетс образом из Ceph, доступ к которому идет через iSCSI таргет. Во избежание проблем при загрузке, лучше удалить подключенный диск и обнаруженный таргет с локального инициатора:

    # iscsiadm -m node --logout
    # iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260


    Всё что осталось — персистировать конфигурацию, чтобы образ подключался автоматически и после подключения стратовал таргет. Запуск таргета состоит из двху шагов — подключения RBD и собственно запуска таргета.

    Cначала сконфигурируем автоматическое подключение RBD образов к хосту. Делается это добавлением строк в файл /etc/ceph/rbdmap:

    # cat /etc/ceph/rbdmap
    # RbdDevice Parameters
    mypool/myimage id=admin
    # systemctl enable rbdmap


    С восстановлением конфигурации таргета чуть сложнее — нам надо написать unit для systemd, который будет восстанвливать конфигурацию:

    # cat /usr/lib/systemd/system/scsi-target.service
    [Unit]
    Description=Start iSCSI target

    After=network-online.target rbdmap.service
    Before=remote-fs-pre.target
    Wants=network-online.target remote-fs-pre.target

    [Service]
    Type=oneshot
    RemainAfterExit=yes
    ExecStart=/bin/targetcli restoreconfig

    [Install]
    WantedBy=multi-user.target

    # systemctl daemon-reload
    # systemctl enable scsi-target


    Финальный тест — еще раз перезагружаем наш монитор (он же теперь iSCSI-таргет). Надо заметить, что если бы мы не очистили базу инициатора командой iscsiadm -n discoverydb -o delete ... то могли бы получить незагружающийся или долго загружающийся сервер.

    Что осталось?

    Cконфигурировать инициатор на том сервере куда хотим подать таргет.

    Как обеспечить отказоустойчивость нашего таргета?

    Можно аналогично сконфигурировать таргеты на других мониторах и устроить multipath (vmware это поймет и даже будет работать, Hyper-V не поймет — там требуются SCSI блокировки). Поскольку клиент Ceph из ядра не использует кэширования, это вполне себе работоспособно. Или другой вариант — создать кластерный ресурс из трех компонентов — выделенного IP-адреса таргета и сервисов rbdmap и scsi-target, и управлять этим ресурсом через инструменты кластеризации (кто сказал pacemaker?)

    Вместо послесловия


    Как понятно, эта статья немножко шутка — но в ней я попытался «быстро и на примерах» рассмотреть одновременно несколько достаточно популярных тем — iSCSI target, который может совсем не обязательно экспортировать образы Ceph — но например экспортировать тома LVM, азы работы с iSCSI инициатором (как просканировать таргет, как подключиться к таргету, отключиться, удалить запись о таргете из базы), написание собственного юнита для systemd и некоторые другие

    Надеюсь, что даже если Вы не будете повторять весь этот эксперимент в полном объеме, то хоть что-нибудь из этой статьи окажется для Вас небесполезным.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 15

      0
      Надеюсь, что даже если Вы не будете повторять весь этот эксперимент в полном объеме

      Но почему?
      И появился же штатный механизм для этого docs.ceph.com/docs/mimic/rbd/iscsi-target-cli
        0

        Так веселее. И производительней. Librbd добавляет достаточно заметный оверхед. Плюс появляются всякие крайне интересные плюшки типа возможности сделать blktrace и т.д., нет риска вляпаться в кэш в юзерспейсе и прочее. И плюс универсальности. Можно другой таргет впилить например. Ну да, кое что может не работать ибо ядерный клиент беднее.

      • UFO just landed and posted this here
          0
          А почему просто не поставить на этот сервер ceph-клиента? Как модуль ядра или через FUSE, и просто примонтировать искомый образ. Зачем вообще тут iSCSI?
            0
            В hyper-v? Если данные из образа нужны внутри windows? Например, файл БД на 400гб, и копировать его куда-то через smb, это ещё на пару часов.
              0

              Почему на пару часов? вполне можно уложиться за несколько минут при наличии нескольких линков 10/25 gbps и нормальных дисках, тем более есть smb multichannel

                +1
                Когда возникает такая ситуация (раз в пару лет) то этот образ почему-то нужно открыть или на отдельно стоящем сервере, или вообще на десктопе, до которых только гигабит. И вдобавок к этому на этих клиентах в этот момент времени будет свободно только 350гб из 400, и начинается: надо бы почистить место, потом надо бы скопировать, может проще ещё одну виртуальную воткнуть, потом подключиться к ней, а потом…
                0

                А для винды нет ceph-драйвера? Не знал, вопрос снимаю..

              –1
              А зачем подключать образ как блочное устройство?
              Не надо совсем.
                0
                Наверое за тем, что образ блочного устройства надо видеть как блочное устройство?
                  0

                  Для цепха ISCSI шлюз сам все монтирует, вот ман: https://docs.ceph.com/docs/master/rbd/iscsi-target-cli/


                  Просто создаёшь пул, а в нем образ, который подрубаешь через gwcli.

                    0
                    Уже объяснялось раньше.
                    Здесь решается больше одной цели, и в частности:
                    1. Получить производительность (хоть какую-нибудь)
                    2. Избавиться от юзерспейса — чтобы остановка сервиса не приводила к похоронам таргетов
                    2. Задействовать каждый «кубик» по отдельности, чтобы:
                    2.1. Понять как работать с каждым компонентом
                    2.2. Иметь возможность применять полезные инструменты диагностики
                      0
                      Наверное, стоит добавить в статью про эту разницу.
                      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, а не ядерный модуль.
                        0
                        Юзерспейсный клиент быстрее и проще развивать, поскольку он строится на общей кодовой базе Ceph, поэтому он поддерживает больше «фич» RBD. Ядерный клиент это отдельный проект — но он производительней, поскольку меньше гоняет данные kernelspace <-> userspace. Когда кластер all-flash на хороших процессорах и хорошей сети, разница достаточно существенна.
                        0

                        Спасибо, понятно

                Only users with full accounts can post comments. Log in, please.