Ці ёсць сярод нас (цэфаводаў) тыя, хто не любіць "прафесійны экстрым"?
Ці наўрад - інакш бы мы не куляліся з гэтым надзвычай цікавым і пацешным прадуктам.
Многія з тых, хто займаліся эксплуатацыяй 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-таргетам
- iscsi-ініцыятар-ўтыліты - пакет з утылітамі выкарыстоўванымі для кіравання ізноў жа ўбудаваным у ядро 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 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 … то маглі б атрымаць сервер, які не загружаецца ці доўга загружаецца.
Што засталося?
Cканфігураваць ініцыятар на тым серверы куды жадаем падаць таргет.
Як забяспечыць адмоваўстойлівасць нашага таргета?
Можна аналагічна сканфігураваць таргеты на іншых маніторах і задаволіць multipath (vmware гэта зразумее і нават будзе працаваць, Hyper-V не зразумее - тамака патрабуюцца SCSI блакаванні). Паколькі кліент Ceph з ядра не выкарыстоўвае кэшавання, гэта суцэль сабе працаздольна. Або іншы варыянт - стварыць кластарны рэсурс з трох кампанентаў - выдзеленага IP-адрасы таргета і сэрвісаў rbdmap і scsi-target, і кіраваць гэтым рэсурсам праз інструменты кластарызацыі (хто сказаў pacemaker?)
замест пасляслоўя
Як зразумела, гэты артыкул трошкі жарт – але ў ім я паспрабаваў «хутка і на прыкладах» разгледзець адначасова некалькі досыць папулярных тэм – iSCSI target, які можа зусім не абавязкова экспартаваць выявы Ceph – але напрыклад экспартаваць тамы LVM, азы працы з iSCSI ініцыятарам ( як прасканаваць таргет, як падключыцца да таргета, адключыцца, выдаліць запіс аб таргеце з базы), напісанне ўласнага юніта для systemd і некаторыя іншыя
Спадзяюся, што нават калі Вы не будзеце паўтараць увесь гэты эксперымент у поўным аб'ёме, то хоць што-небудзь з гэтага артыкула апынецца для Вас некарысным.
Крыніца: habr.com