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

# 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 и некоторые другие

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

Автор: outlingo

Источник