Има ли между нас (цефоводите) някой, който не обича „професионален екстрем“?
Малко вероятно — иначе нямаше да се занимаваме с този изключително интересен и забавен продукт.
Много от тези, които са експлоатирали Ceph, са се сблъсквали с един не твърде често срещан (а вероятно дори много рядък), но понякога търсен случай — да свържат Ceph чрез iSCSI или FC. Защо? Например, за да предоставят образ от Ceph на някакъв не виртуализиран сървър с Windows или Solaris. Или на виртуализиран, но чрез хипервизор, който не поддържа Ceph — а тях, както знаем, има достатъчно. Например? Например, HyperV или ESXi, които се използват активно. И ако възникне задачата да предоставим образ от Ceph на гостуващата машина, това става наистина увлекателно.
И така, дадено:
- вече работещ кластер Ceph
- вече съществуващ образ, който трябва да бъде предоставен чрез iSCSI
- Име на пула mypool, име на образа myimage
Започваме?
Преди всичко, когато говорим за FC или iSCSI, имаме такива същества, като инициатор (initiator) и цел (target). Target е фактическия сървър, а инициаторът — клиент. Нашата задача е с минимални усилия да предоставим образ от Ceph на инициатора. А значи, трябва да развернем target. Но къде, на кой компютър?
За щастие, в кластера Ceph имаме поне един компонент, чието IP-адрес е фиксирано и на който е конфигуриран един от най-важните компоненти на Ceph, а именно — монитор. Следователно, на монитора инсталираме iSCSI target (и инициатора също, поне за тестове). Правих го на CentOS, но за всяко друго дистрибуция решението също подхожда — просто е необходимо да инсталирате пакетите по начин, който е приемлив за вашето дистрибуция.
# yum -y install iscsi-initiator-utils targetcli
Какова е целта на инсталираните пакети?
- targetcli — инструменти за управление на вградената в ядрото Linux SCSI target
- iscsi-initiator-utils — пакет с инструменти, използвани за управление отново на вградената в ядрото Linux iSCSI initiator
За да подадем образ чрез iSCSI на инициатор, имаме два варианта — да използваме back-end на target в потребителското пространство или да свържем образа като блочно устройство, видимо за операционната система, и да го експортираме по iSCSI. Ние ще изберем втория вариант — back-end в потребителското пространство все още е в "експериментален" стадий и не е напълно готов за продуктивна употреба. Освен това, с него има подводни камъни, за които може да се говори много и (о ужас!) да се спори.
Ако използваме какъвто и да е стабилен дистрибутив с дълъг цикъл на поддръжка, ядрото ще бъде на някоя древна версия. Например в CentOS7 е 3.10.*, в CentOS8 е 4.19. А нас ни интересува ядро поне 5.3 (а вероятно 5.4) и по-ново. Защо? Защото по подразбиране образите в Ceph имат свързан набор опции, който не е съвместим със старите ядра. Затова ще свържем репозиторий с ново ядро за нашия дистрибутив (например за CentOS това е elrepo), инсталираме новото ядро и рестартираме системата, за да работим с новото ядро:
- Свързваме се с избрания за експеримента монитор
- Свързваме репозиториите elrepo по инструкциите —
- Инсталираме ядрото: yum -y --enablerepo=elrepo-kernel install kernel-ml
- Рестартираме сървъра с монитора (все пак имаме три монитора, нали?)
Свързваме образа като блочно устройство
# rbd карта mypool\/myimage
/dev/rbd0
Остава само да конфигурираме target. В този пример аз ще конфигурирам target в така наречения demo-режим — без аутентификация, видим и достъпен за всички. В продуктивна среда вероятно ще искате да конфигурирате аутентификация — но това е малко извън обхвата на днешното упражнение, което е просто за забавление.
Създаваме back-end с име disk1, свързан с файла /dev/rbd/mypool/myimage. Указаният файл е автоматично създадена символьна връзка от демонa udev към /dev/rbd0. Използваме именно символьната връзка, тъй като името на устройството rbd може да се променя заради реда на свързване на образите Ceph към хоста.
Създаваме back-end:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Създаваме iSCSI target:
# targetcli /iscsi create iqn.2020-01.demo.ceph:mypool
Свързваме back-end като LUN към target:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Допълнително настройваме target за demo-режим:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/set
> атрибут demo_mode_write_protect=0
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/set
> атрибут generate_node_acls=1
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/set
> атрибут cache_dynamic_acls=1
Запазваме конфигурацията:
# targetcli saveconfig
Проверяваме наличието на target:
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool
Свързваме target:
# iscsiadm -m node --login
Вход в [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (множество)
Вход в [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] успешен.
Ако всичко е направено правилно, на сървъра ще се появи нов диск, който изглежда като 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:
# котка /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
С възстановяването на конфигурацията на таргета е малко по-сложно — трябва да напишем unit за systemd, който ще възстановява конфигурацията:
# котка /usr/lib/systemd/system/scsi-target.service
[Unit]
Описание=Стартиране на iSCSI цел
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 таргет, който може да не экспортва задължително образи Ceph — а, например, да експортира LVM томове, основи на работа с iSCSI инициатор (как да сканирате таргет, как да се свържете с таргета, да се отключите, да изтриете записа за таргета от базата), написването на собствен юнит за systemd и някои други.
Надявам се, че дори да не повторите целия този експеримент в пълния му обем, поне нещо от тази статия ще бъде полезно за вас.
Източник: habr.com
