Finns det de bland oss (tsefovodov) som inte gillar "professionell extrem"?
Det är osannolikt - annars skulle vi inte tumla runt med denna extremt intressanta och roliga produkt.
Många av dem som var inblandade i driften av Ceph har stött på ett inte särskilt frekvent (eller snarare till och med mycket sällsynt) men ibland efterfrågat fall - att ansluta Ceph via iSCSI eller FC. För vad? Jo, till exempel, skicka in en bild från Ceph till en Windows- eller Solaris-server som ännu inte har virtualiserats av någon anledning. Eller en virtualiserad, men med hjälp av en hypervisor som inte kan göra Ceph - och som vi vet finns det gott om dem. Till exempel? Jo, till exempel HyperV eller ESXi, som används aktivt. Och om uppgiften dyker upp att servera en bild från Ceph till en gästmaskin blir detta en mycket spännande uppgift.
Så givet:
- ett redan kört Ceph-kluster
- en redan befintlig bild som måste serveras via iSCSI
- Poolens namn mypool, bildnamn min bild
Börja?
Först och främst, när vi pratar om FC eller iSCSI, har vi sådana enheter som initiativtagare och mål. Target är faktiskt en server, initiator är en klient. Vår uppgift är att lämna in Ceph-bilden till initiativtagaren med minimal ansträngning. Det betyder att vi måste utöka målet. Men var, på vilken dator?
Lyckligtvis har vi i ett Ceph-kluster minst en komponent vars IP-adress är fixerad och på vilken en av de viktigaste komponenterna i Ceph är konfigurerad, och den komponenten är monitorn. Följaktligen installerar vi ett iSCSI-mål på monitorn (och en initiator samtidigt, åtminstone för tester). Jag gjorde detta på CentOS, men lösningen passar även för alla andra distributioner - du behöver bara installera paketen på det sätt som är acceptabelt i din distribution.
# yum -y install iscsi-initiator-utils targetcli
Vad är syftet med de installerade paketen?
- targetcli — ett verktyg för att hantera SCSI-målet inbyggt i Linux-kärnan
- iscsi-initiator-utils — ett paket med verktyg som används för att hantera iSCSI-initiatorn inbyggd i Linux-kärnan
För att skicka in en bild via iSCSI till initiativtagaren finns det två alternativ för utveckling av händelser - använd användarutrymmets backend för målet eller anslut bilden som en blockenhet som är synlig för operativsystemet och exportera den via iSCSI. Vi kommer att gå den andra vägen - användarutrymmets backend är fortfarande i ett "experimentellt" tillstånd och är något inte redo för produktiv användning. Dessutom finns det fallgropar med det, som man kan prata mycket om och (oh skräck!) bråka om.
Om vi använder till och med en något stabil distribution med en lång supportcykel, så är kärnan vi har någon gammal, uråldrig version. Till exempel, i CentOS7 är det 3.10.*, i CentOS8 är det 4.19. Och vi är intresserade av en kärna på minst 5.3 (eller snarare 5.4) och nyare. Varför? Eftersom Ceph-bilder som standard har en uppsättning alternativ aktiverade som inte är kompatibla med äldre kärnor. Detta innebär att vi ansluter ett arkiv med en ny kärna för vår distribution (till exempel för CentOS är detta elrepo), installerar den nya kärnan och startar om systemet för att arbeta med den nya kärnan:
- Anslut till monitorn som valts för experimentet
- Vi ansluter elrepo-förvar enligt instruktionerna -
- Installera kärnan: yum -y —enablerepo=elrepo-kärna installera kernel-ml
- Starta om servern med bildskärmen (vi har tre bildskärmar, eller hur?)
Ansluta bilden som en blockenhet
# rbd map mypool/myimage
/dev/rbd0
Allt som återstår är att konfigurera målet. I det här exemplet kommer jag att konfigurera målet i den så kallade. demoläge - utan autentisering, synligt och tillgängligt för alla. I en produktionsmiljö kommer du sannolikt att vilja konfigurera autentisering - men det är lite utanför räckvidden för dagens övning för skojs skull.
Skapa en backend som heter disk1 associerad med filen /dev/rbd/mypool/myimage. Den angivna filen är en symbolisk länk som automatiskt skapas av udev-demonen till /dev/rbd0. Vi använder en symbolisk länk eftersom namnet på rbd-enheten kan ändras beroende på i vilken ordning Ceph-bilderna är anslutna till värden.
Skapa en backend:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Skapa ett iSCSI-mål:
# targetcli /iscsi create iqn.2020-01.demo.ceph:mypool
Vi ansluter backend som ett LUN till målet:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Låt oss konfigurera målet för demoläge:
# 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
Spara konfigurationen:
# targetcli saveconfig
Kontrollera tillgängligheten för målet:
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool
Vi kopplar målet:
# 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.
Om du gjorde allt korrekt kommer en ny disk att dyka upp på servern, som ser ut som en SCSI-enhet, men som egentligen är en bild från Ceph, som nås via ett iSCSI-mål. För att undvika startproblem är det bättre att ta bort den anslutna disken och det upptäckta målet från den lokala initiatorn:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Allt som återstår är att bevara konfigurationen så att bilden ansluts automatiskt och, efter anslutning, stratifieras målet. Att skjuta upp ett mål består av två steg - att ansluta RBD och faktiskt starta målet.
Låt oss först konfigurera den automatiska anslutningen av RBD-bilder till värden. Detta görs genom att lägga till följande rader i filen /etc/ceph/rbdmap:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
Att återställa målkonfigurationen är lite mer komplicerat - vi måste skriva en enhet för systemd som återställer konfigurationen:
# 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
Det sista testet är att starta om vår bildskärm igen (det är nu ett iSCSI-mål). Det bör noteras att om vi inte hade rensat initiatorns databas med kommandot iscsiadm -n discoverydb -o radera ... du kan sluta med en server som inte laddas eller som tar lång tid att ladda.
Vad är kvar?
Konfigurera initiatorn på servern dit vi vill skicka målet.
Hur säkerställer vi feltolerans för vårt mål?
Du kan på liknande sätt konfigurera mål på andra bildskärmar och ställa in multipath (vmware kommer att förstå detta och till och med fungera, Hyper-V kommer inte att förstå - det kräver SCSI-lås). Eftersom Ceph-klienten från kärnan inte använder cachning är detta ganska fungerande. Eller ett annat alternativ är att skapa en klusterresurs med tre komponenter - en dedikerad mål-IP-adress och rbdmap och scsi-target-tjänster, och hantera denna resurs genom klustringsverktyg (vem sa pacemaker?)
i stället för en epilog
Som tydligt är den här artikeln lite av ett skämt - men i den försökte jag "snabbt och med exempel" överväga flera ganska populära ämnen samtidigt - iSCSI-mål, som kanske inte nödvändigtvis exporterar Ceph-bilder - men t.ex. exportera LVM-volymer, grunderna för att arbeta med en iSCSI-initiator (hur man skannar ett mål, hur man ansluter till ett mål, kopplar bort, tar bort en målpost från databasen), skriver din egen enhet för systemd och några andra
Jag hoppas att även om du inte upprepar hela detta experiment i sin helhet, kommer åtminstone något från den här artikeln att vara användbart för dig.
Källa: will.com