Има ли между нас (цефоводите) такива, които не обичат "професионалния екстрем"?
Малко вероятно — иначе нямаше да се занимаваме с този изключително интересен и забавен продукт.
Много от хората, които са работили с Ceph, са срещали един не толкова често срещан (по-скоро много рядък) случай — да се свържат с Ceph чрез iSCSI или FC. Защо? Например, за да подадат образ от Ceph на по някаква причина неиз виртуализиран Windows или Solaris сървър. Или на виртуализиран, но чрез хипервизор, който не поддържа Ceph — а такива, както знаем, не липсват. Например? Например, HyperV или ESXi, които се използват активно. И ако възникне задачата да се подаде образ от Ceph на гостуваща машина, това се превръща в доста увлекателна задача.
И така, имаме:
- вече работещ Ceph клъстер
- вече съществуващ образ, който трябва да се подаде чрез iSCSI
- Име на пула 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-target
- iscsi-initiator-utils — пакет с утилити, използвани за управление на интегрирания в ядрото на Linux iSCSI initiator.
За да подадем образ чрез 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 карта mypool/myimage
/dev/rbd0
Остава само да конфигурираме таргета. В този пример ще конфигурирам таргета в т.н. demo-режим — без автентикация, видим и достъпен за всички. В продуктивна среда вероятно ще искате да конфигурирате автентикация — но това е малко извън обсега на днешната просто-за-забавление задача.
Създаваме бекенд с името 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
Вход в [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
