Vannak közöttünk olyanok (cefovodov), akik nem szeretik a „professzionális szélsőséget”?
Valószínűtlen – különben nem bukdácsolnánk ezzel a rendkívül érdekes és vicces termékkel.
A Ceph működtetésében részt vevők közül sokan találkoztak egy nem túl gyakori (vagy inkább nagyon ritkán), de olykor igényes esettel - amely a Ceph-t iSCSI-n vagy FC-n keresztül köti össze. Miért? Nos, például küldjön be egy képet a Ceph-ről egy Windows vagy Solaris szerverre, amely valamiért még nem lett virtualizálva. Vagy egy virtualizált, de olyan hypervisor használatával, amely nem képes Ceph-re – és mint tudjuk, rengeteg van belőlük. Például? Nos, például a HyperV vagy az ESXi, amelyeket aktívan használnak. És ha felmerül az a feladat, hogy Ceph-ből egy képet tálaljunk egy vendéggépre, ez egy nagyon izgalmas feladattá válik.
Így adott:
- egy már futó Ceph-fürt
- egy már létező kép, amelyet iSCSI-n keresztül kell kiszolgálni
- Medence neve mypool, kép neve az én képem
Kezdődik?
Először is, amikor FC-ről vagy iSCSI-ről beszélünk, olyan entitásaink vannak, mint a kezdeményező és a cél. A cél valójában egy szerver, a kezdeményező pedig egy kliens. A mi feladatunk, hogy a Ceph képet minimális ráfordítással beküldjük a kezdeményezőnek. Ez azt jelenti, hogy ki kell terjesztenünk a célt. De hol, milyen számítógépen?
Szerencsére egy Ceph-fürtben van legalább egy olyan összetevő, amelynek IP-címe rögzített, és amelyen a Ceph egyik legfontosabb összetevője van konfigurálva, és ez a komponens a monitor. Ennek megfelelően egy iSCSI-célt telepítünk a monitorra (és egyúttal kezdeményezőt is, legalábbis tesztekhez). Ezt CentOS-en csináltam, de a megoldás bármilyen más disztribúcióhoz is alkalmas - csak a csomagokat kell a disztribúciódban elfogadható módon telepíteni.
# yum -y install iscsi-initiator-utils targetcli
Mi a telepített csomagok célja?
- targetcli — egy segédprogram a Linux kernelbe épített SCSI-cél kezelésére
- iscsi-iniciátor-utils — a Linux kernelbe épített iSCSI-kezdeményező kezelésére szolgáló segédprogramokat tartalmazó csomag
Ahhoz, hogy egy képet iSCSI-n keresztül küldjön el a kezdeményezőnek, két lehetőség van az események fejlesztésére - használja a cél felhasználói felületének hátterét, vagy csatlakoztassa a képet az operációs rendszer számára látható blokkeszközként, és exportálja iSCSI-n keresztül. A második utat választjuk - a felhasználói tér háttérrendszere még mindig „kísérleti” állapotban van, és kissé nem áll készen a produktív használatra. Ráadásul vannak benne buktatók, amiről sokat lehet beszélni és (ó iszonyat!) vitatkozni.
Ha egy kissé stabil disztribúciót használunk, hosszú támogatási ciklussal, akkor a rendszermagunk valami ősi, ősi verzió. Például a CentOS7-ben 3.10.*, a CentOS8-ban 4.19. És minket egy legalább 5.3-as (vagy inkább 5.4-es) és újabb kernel érdekel. Miért? Mivel alapértelmezés szerint a Ceph-képek egy sor olyan beállítást engedélyeznek, amelyek nem kompatibilisek a régebbi kernelekkel. Ez azt jelenti, hogy csatlakoztatunk egy tárolót egy új kernellel a 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 működjön:
- Csatlakoztassa a kísérlethez kiválasztott monitorhoz
- Az elrepo adattárakat az utasítások szerint csatlakoztatjuk -
- Telepítse a kernelt: yum -y —enablerepo=elrepo-kernel install kernel-ml
- Indítsa újra a szervert a monitorral (három monitorunk van, igaz?)
A kép csatlakoztatása blokkeszközként
# rbd map mypool/myimage
/dev/rbd0
Már csak a cél konfigurálása van hátra. Ebben a példában a célt az ún. demó mód - hitelesítés nélkül, mindenki számára látható és elérhető. Éles környezetben valószínűleg be kell állítania a hitelesítést – de ez egy kicsit túlterhelt a mai szórakozásból.
Hozzon létre egy disk1 nevű háttérprogramot a /dev/rbd/mypool/myimage fájlhoz társítva. A megadott fájl egy szimbolikus hivatkozás, amelyet az udev démon automatikusan létrehoz a /dev/rbd0 fájlhoz. Szimbolikus hivatkozást használunk, mert az rbd eszköz neve változhat attól függően, hogy a Ceph képek milyen sorrendben kapcsolódnak a gazdagéphez.
Háttér létrehozása:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Hozzon létre egy iSCSI-célt:
# targetcli /iscsi create iqn.2020-01.demo.ceph:mypool
A háttérrendszert LUN-ként csatlakoztatjuk a célhoz:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Állítsuk be a célt a demó módhoz:
# 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
Mentse el a konfigurációt:
# targetcli saveconfig
A célpont jelenlétének 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
Összekapcsoljuk a célpontot:
# 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.
Ha mindent helyesen csinált, egy új lemez jelenik meg a szerveren, amely úgy néz ki, mint egy SCSI-eszköz, de valójában egy Ceph-kép, amely egy iSCSI-célponton keresztül érhető el. A rendszerindítási problémák elkerülése érdekében jobb, ha eltávolítja a csatlakoztatott lemezt és az észlelt célt a helyi kezdeményezőből:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Már csak a konfigurációt kell fenntartani, hogy a kép automatikusan csatlakozzon, és a csatlakozás után a cél rétegzett legyen. A célpont elindítása két lépésből áll - az RBD összekapcsolásából és a célpont tényleges kilövéséből.
Először is állítsuk be az RBD-képek automatikus csatlakozását a gazdagéphez. Ez úgy történik, hogy a következő sorokat adjuk hozzá az /etc/ceph/rbdmap fájlhoz:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
A célkonfiguráció visszaállítása egy kicsit bonyolultabb - írnunk kell egy egységet a systemd számára, amely visszaállítja a konfigurációt:
# 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
Az utolsó teszt a monitor újraindítása (most már iSCSI-célpont). Meg kell jegyezni, hogy ha nem töröltük volna a kezdeményező adatbázisát a paranccsal iscsiadm -n discoverydb -o törlés... előfordulhat, hogy egy szerver nem töltődik be, vagy sokáig tart a betöltése.
Mi maradt?
Állítsa be a kezdeményezőt a kiszolgálón, ahová el akarjuk küldeni a célt.
Hogyan biztosítható a célunk hibatűrése?
Hasonlóképpen konfigurálhatja a célokat más monitorokon, és beállíthat több útvonalat (a vmware ezt megérti, sőt működik, a Hyper-V nem fogja megérteni - ehhez SCSI-zárak szükségesek). Mivel a kernelből származó Ceph kliens nem használ gyorsítótárat, ez teljesen működőképes. Vagy egy másik lehetőség egy három összetevőből álló fürterőforrás létrehozása - egy dedikált cél IP-címből, valamint rbdmap és scsi-target szolgáltatásokból, és ezt az erőforrást fürtöző eszközökön keresztül kezeli (ki mondta a pacemakert?)
Helyett utószó
Amint az világos, ez a cikk egy kis vicc - de igyekeztem "gyorsan és példákkal" több, meglehetősen népszerű témát egyszerre figyelembe venni - iSCSI target, amely nem feltétlenül exportál Ceph képeket - de pl. LVM-kötetek exportálása, az iSCSI-kezdeményezővel való munka alapjai (cél szkennelése, célponthoz való csatlakozás, leválasztás, célbejegyzés törlése az adatbázisból), saját egység írása systemd-hez és néhány más
Remélem, még ha nem is ismétli meg teljesen ezt a kísérletet, legalább valami ebből a cikkből hasznos lesz az Ön számára.
Forrás: will.com