Van köztünk (Ceph-szakértők) olyan, aki nem szereti a "professzionális extrémot"?
Valószínűtlen, különben nem foglalkoznánk ezzel a rendkívül érdekes és szórakoztató termékkel.
Sokan, akik Ceph üzemeltetéssel foglalkoztak, találkoztak egy nem túl gyakori (sőt, inkább nagyon ritka) de néha igényelt esettel — Ceph csatlakoztatása iSCSI vagy FC-n keresztül. Miért? Például, hogy egy Cephről készült képet egy még nem virtualizált Windows vagy Solaris szerverre küldjünk. Vagy egy virtualizált szerverre, de olyan hypervisoron keresztül, amely nem ismeri a Ceph-t — és ezekből, mint tudjuk, elég sok van. Például? Mondjuk, HyperV vagy ESXi, amelyeket aktívan használnak. És ha az a feladat, hogy egy Ceph képet egy vendéggépnek küldjünk, az egy elég izgalmas kihívássá válik.
Tehát, adott:
- már működő Ceph klaszter
- már meglévő kép, amelyet iSCSI-n keresztül kell egyesíteni
- A pool neve mypool, a kép neve myimage
Kezdhetjük?
Elsősorban, amikor FC-ről vagy iSCSI-ról beszélünk, megjelennek ilyen entitások, mint az initiator és a target. A target gyakorlatilag a szerver, az initiator — az ügyfél. A mi feladatunk az, hogy minimális munkával elküldjük a Ceph képet az initiatornak. Tehát el kell indítanunk a targetet. De hol, melyik számítógépen?
Szerencsére a Ceph klaszterben legalább egy olyan komponens van, amelynek IP-címe fix és amelyen az egyik legfontosabb Ceph komponens van konfigurálva, ez pedig a monitor. Ennek megfelelően a monitorra telepítjük az iSCSI target-et (és az initiatort is, legalább a teszteléshez). Én ezt CentOS-on csináltam, de bármely más disztribúcióhoz megfelelő megoldás működik — elég, ha a csomagokat a saját disztribúciód által elfogadott módon telepíted.
# yum -y install iscsi-initiator-utils targetcli
Milyen célja van a telepített csomagoknak?
- targetcli — a Linux kernelbe beépített SCSI target kezelő eszköz
- iscsi-initiator-utils — csomag az ismét a Linux kernelbe beépített iSCSI initiátor kezelésére szolgáló eszközökkel
Ahhoz, hogy képet használjunk iSCSI-n keresztül az initiátorhoz, két lehetőségünk van - használhatjuk a felhasználói térben lévő target backend-et, vagy csatlakoztathatjuk a képet blokkeszközként, amely a rendszer számára látható, és exportálhatjuk iSCSI-n. A második utat választjuk - a felhasználói térbeli backend még "kísérleti" állapotban van, és produktív használatra nem teljesen készen áll. Ezen kívül sok buktatója van, amiről sokat lehet beszélni és (jaj!) vitatkozni.
Ha stabil disztribúciót használunk hosszú távú támogatási ciklussal, akkor a kernel valószínűleg valamilyen nagyon régi verzió. Például a CentOS7-ben ez 3.10.*, a CentOS8-ban pedig 4.19. És minket legalább az 5.3-as (valószínűleg 5.4) és újabb kernel érdekel. Miért? Mert alapértelmezetten a Ceph képekhez csatlakoztatott opciók készlete nem kompatibilis a régi kernellel. Ezért hozzáadunk egy új kernel repót disztribúciónkhoz (például a CentOS esetében ez az elrepo), telepítjük az új kernelt, és újraindítjuk a rendszert, hogy az új kernellel dolgozhassunk:
- Csatlakozzunk a kiválasztott kísérleti monitorhoz.
- Csatlakoztassuk az elrepo repókat az utasítás szerint -
- Telepítjük a kernelt: yum -y --enablerepo=elrepo-kernel install kernel-ml
- Újraindítjuk a monitort (ugyanis három monitorunk van, igaz?)
Csatlakoztassuk a képet blokkeszközként.
# rbd térkép mypool/myimage
/dev/rbd0
Csak a target konfigurálása marad hátra. Ebben a példában a targetet a "demó" módban fogom konfigurálni - hitelesítés nélkül, látható és mindenki számára elérhető. Produktív környezetben valószínűleg szeretné a hitelesítést beállítani - de ez kissé kívül esik a mai, csak mókázós gyakorlat céljain.
Backendet hozunk létre disk1 néven, amely a /dev/rbd/mypool/myimage fájlhoz van hozzárendelve. Az adott fájl az udev démon által automatikusan létrehozott szimbolikus hivatkozás a /dev/rbd0-ra. Kifejezetten a szimbolikus hivatkozást használjuk, mivel az rbd eszköz neve a Ceph képek csatlakoztatásának sorrendje miatt változhat.
Backend létrehozása:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
iSCSI target létrehozása:
# targetcli \/iscsi create iqn.2020-01.demo.ceph:mypool
Backend csatlakoztatása LUN-ként a targethez:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Target végső beállítása a demó módban:
# 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
Konfiguráció mentése:
# targetcli saveconfig
Target ellenőrzése:
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool
Target csatlakoztatása:
# iscsiadm -m node --login
Bejelentkezés [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (többes)
A bejelentkezés a [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] sikeres.
Ha mindent helyesen csinált, akkor a szerveren megjelenik egy új lemez, amely SCSI-eszköznek tűnik, de valójában a Ceph egyik képe, amelyhez az iSCSI célpontján keresztül fér hozzá. A boot problémák elkerülése érdekében jobb, ha eltávolítja a csatlakoztatott lemezt és a helyi kezdeményezőt a felfedezett célponttal együtt:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Minden, ami hátra van — a konfiguráció állandósítása, hogy a kép automatikusan csatlakozzon és a célpont elinduljon. A célpont elindítása két lépésből áll — az RBD csatlakoztatásából és a célpont tényleges elindításából.
Először konfiguráljuk az RBD képek automatikus csatlakoztatását a hosztra. Ezt úgy végezzük, hogy sorokat adunk hozzá a /etc/ceph/rbdmap fájlhoz:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
A célpont konfigurációjának helyreállítása kissé bonyolultabb — egy unitot kell írnunk a systemd számára, amely helyreállítja a konfigurációt:
# cat /usr/lib/systemd/system/scsi-target.service
[Unit]
Leírás=iSCSI cél indítása
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
A végső teszt — újraindítjuk a monitorunkat (ami most már iSCSI célpont is). Meg kell jegyezni, hogy ha nem tisztítottuk volna meg a kezdeményező adatbázisát a parancs segítségével iscsiadm -n discoverydb -o delete … akkor egy nem bootolható vagy lassan bootoló szervert kaphattunk volna.
Mi maradt?
Konfigurálnunk kell a kezdeményezőt azon a szerveren, ahová a célpontot szeretnénk bevinni.
Hogyan lehet biztosítani a célpontunk hibátlan működését?
Hasonlóképpen lehet konfigurálni a célpontokat más monitorokon, és létrehozni multipath-t (ezt a VMware megérti és működik is, a Hyper-V nem érti — ott SCSI zárolásokra van szükség). Mivel a Ceph kliens nem használja a cache-elést a kernelen belül, ez teljesen működőképes. Vagy egy másik lehetőség — létrehozni egy klaszter erőforrást három komponensből — dedikált IP address célpontból és az rbdmap és scsi-target szolgáltatásokból, és ezt az erőforrást klaszterezési eszközökkel (ki mondta, hogy pacemaker?) kezelni.
A befejezés helyett
Ahogy látható, ez a cikk kissé vicces — de megpróbáltam "gyorsan és példákkal" egyszerre több, meglehetősen népszerű témát áttekinteni — iSCSI célpont, amely egyáltalán nem szükséges, hogy Ceph képeket exportáljon — hanem például LVM köteteket exportálni, az iSCSI kezdeményezővel való munka alapjai (hogyan lehet beolvasni a célpontot, hogyan csatlakozzunk a célponthoz, hogyan kapcsolódjunk le, töröljük a célpontról a bejegyzést az adatbázisból), saját unit írása a systemd számára és néhány más
Remélem, hogy még ha nem is fogod teljes mértékben megismételni ezt a kísérletet, legalább valami hasznosat találsz ebből a cikkből.
Forrás: habr.com
