Хабрахабр

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

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

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

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

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

Начинаем?

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

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

# yum -y install iscsi-initiator-utils targetcli

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

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

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

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

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

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

# rbd map mypool/myimage
/dev/rbd0

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

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

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

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

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

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

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

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

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

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

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

# targetcli saveconfig

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

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

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

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

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

0. # iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127. 1:3260
0.

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

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

# 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

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

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

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

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

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

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

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

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

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»