Чи серед нас (цефоводів) є ті, хто не любить «професійний екстрим»?
Навряд чи — інакше б ми не перекидалися з цим надзвичайно цікавим та кумедним продуктом.
Багато хто з тих, хто займався експлуатацією Ceph, зустрічали один не дуже частий (а скоріше навіть дуже нечастий) але іноді затребуваний кейс - підключити Ceph по iSCSI або FC. Навіщо? Ну, наприклад, подати образ із Ceph на чомусь ще не віртуалізований сервер Windows чи Solaris. Або на віртуалізований, але за допомогою гіпервізора, який не вміє Ceph, а їх, як ми знаємо, вистачає. Наприклад? Ну, наприклад, HyperV чи ESXi, які активно використовуються. І якщо виникає завдання подати образ із Ceph у гостьову машину, це перетворюється на досить захоплююче завдання.
Отже, дано:
- вже працюючий кластер Ceph
- вже існуючий образ, який треба подати через iSCSI
- Ім'я пула mypool, ім'я образу мій образ
Починаємо?
Насамперед, коли ми говоримо про 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-ініціатор-utils — пакет з утилітами для керування ініціатором iSCSI, вбудованим у ядро Linux
Для того, щоб подати образ через iSCSI на ініціатор, є два варіанти розвитку подій - використовувати userspace'ний бакенд таргета або підключати образ як блочний пристрій видимий для операційної системи та експортувати його по iSCSI. Ми підемо другим шляхом — userspace'ний бакенд поки що знаходиться в «експериментальному» стані і для продуктивного використання трохи не готовий. Крім того, з ним є підводне каміння, про яке можна багато розмовляти і (о жах!) сперечатися.
Якщо ми використовуємо хоч якийсь стабільний дистрибутив з дооолгім циклом підтримки, то ядро у нас якоїсь стародавньої версії. Наприклад, у CentOS7 це 3.10.*, у CentOS8 це 4.19. А нам цікаве ядро як мінімум 5.3 (а скоріше 5.4) і нове. Чому? Тому що за замовчуванням образи в Ceph мають підключений набір опцій, який не сумісний зі старими ядрами. Отже, ми підключаємо репозиторій з новим ядром для нашого дистрибутива (наприклад, для CentOS це elrepo), встановлюємо нове ядро і перезавантажуємо систему, щоб працювати з новим ядром:
- Підключаємося до вибраного для експерименту монітора
- Підключаємо репозиторії elrepo за інструкцією
- Встановлюємо ядро: 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 і запуску таргета.
Спочатку налаштуємо автоматичне підключення 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 … то могли б отримати сервер, що не завантажується або довго завантажується.
Що залишилось?
Конфігурувати ініціатор на тому сервері, куди хочемо подати таргет.
Як забезпечити відмовостійкість нашого таргету?
Можна аналогічно конфігурувати таргети на інших моніторах і влаштувати multipath (vmware це зрозуміє і навіть працюватиме, Hyper-V не зрозуміє - там потрібні блокування SCSI). Оскільки клієнт Ceph з ядра не використовує кешування, це цілком працездатно. Або інший варіант — створити кластерний ресурс із трьох компонентів — виділеної IP-адреси націлення та сервісів rbdmap та scsi-target, та керувати цим ресурсом через інструменти кластеризації (хто сказав pacemaker?)
замість післямови
Як відомо, ця стаття трохи жарт - але в ній я спробував "швидко і на прикладах" розглянути одночасно кілька досить популярних тем - iSCSI target, який може зовсім не обов'язково експортувати образи Ceph - але наприклад експортувати томи LVM, ази роботи з iSCSI ініціатором ( як просканувати таргет, як підключитися до таргету, відключитися, видалити запис про таргети з бази), написання власного юніту для systemd та деякі інші
Сподіваюся, що навіть якщо Ви не повторюватимете весь цей експеримент у повному обсязі, то хоч щось із цієї статті виявиться для Вас недаремним.
Джерело: habr.com