Er det noen av oss (Ceph-brukere) som ikke elsker "professionelt ekstremt"?
Sannsynligvis ikke â ellers ville vi ikke deltatt i dette ekstremt interessante og morsomme produktet.
Mange av dem som har drevet med Ceph har mĂžtt en ikke sĂ„ vanlig (eller kanskje veldig sjelden) men noen ganger etterspurt case â Ă„ koble Ceph via iSCSI eller FC. Hvorfor? For eksempel, for Ă„ levere et bilde fra Ceph til en eller annen grunn ikke virtualisert Windows- eller Solaris-server. Eller til en virtualisert, men gjennom en hypervisor som ikke stĂžtter Ceph â og det er det, som vi vet, mange av. For eksempel? Tja, for eksempel HyperV eller ESXi, som brukes aktivt. Og hvis oppgaven er Ă„ levere et bilde fra Ceph til en gjestemaskin, blir dette en ganske spennende oppgave.
SĂ„, gitt:
- et allerede fungerende Ceph-kluster
- et allerede eksisterende bilde som mÄ leveres via iSCSI
- Navnet pÄ bassenget mypool, navnet pÄ bildet myimage
Skal vi begynne?
FÞrst og fremst, nÄr vi snakker om FC eller iSCSI, har vi begrepene initiator og target. Target er faktisk serveren, initiator er klienten. VÄr oppgave er Ä levere Ceph-bildet til initiatoren med minimal arbeidsinnsats. Det betyr at vi mÄ sette opp target. Men hvor, pÄ hvilken datamaskin?
Heldigvis har vi i Ceph-klusteret minst Ă©n komponent, hvis IP-adresse er fast og der en av de viktigste komponentene i Ceph er konfigurert, og denne komponenten er overvĂ„kningssystemet. Dermed setter vi opp iSCSI target pĂ„ overvĂ„kningssystemet (og initiator for en del, i det minste for testing). Jeg gjorde dette pĂ„ CentOS, men for hvilken som helst annen distribusjon passer lĂžsningen ogsĂ„ â det er bare Ă„ installere pakkene pĂ„ en mĂ„te som er akseptabel i din distribusjon.
# yum -y install iscsi-initiator-utils targetcli
Hva er hensikten med de installerede pakkene?
- targetcli â verktĂžy for Ă„ administrere den innebygde SCSI-targeten i Linux-kjernen
- iscsi-initiator-utils â pakke med verktĂžy som brukes til Ă„ administrere igjen den innebygde iSCSI-initiatoren i Linux-kjernen
For submitting an image over iSCSI to the initiator, there are two options â using a userspace target backend or connecting the image as a block device visible to the operating system and exporting it via iSCSI. We will take the second approach â the userspace backend is still in an 'experimental' state and is slightly unready for production use. Moreover, it has some pitfalls that can be extensively discussed and (oh horror!) debated.
If we use a relatively stable distribution with a long support cycle, the kernel will be some ancient version. For example, in CentOS 7 it's 3.10.*, in CentOS 8 it's 4.19. But we are interested in a kernel of at least 5.3 (preferably 5.4) or a newer version. Why? Because by default, images in Ceph have a set of options enabled that are incompatible with old kernels. Therefore, we are connecting a repository with a new kernel for our distribution (for CentOS it's elrepo), installing the new kernel, and rebooting the system to work with it:
- Connecting to the selected monitor for the experiment.
- Add the elrepo repositories according to the instructions â
- Install the kernel: yum -y --enablerepo=elrepo-kernel install kernel-ml
- Reboot the server with the monitor (we have three monitors, right?)
Connect the image as a block device.
# rbd kort minpool/mybillede
/dev/rbd0
All that's left is to configure the target. In this example, I will configure the target in a so-called demo mode â without authentication, visible and accessible to everyone. In a production environment, you might want to configure authentication â but that's a bit out-of-scope for today's just-for-fun exercise.
Create a backend named disk1 mapped to the file /dev/rbd/mypool/myimage. The specified file is a symbolically linked file automatically created by the udev daemon to /dev/rbd0. We use the symbolic link specifically because the name of the rbd device can change due to the order in which Ceph images connect to the host.
Create a backend:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Create an iSCSI target:
# targetcli /iscsi opret iqn.2020-01.demo.ceph:mypool
Connect the backend as a LUN to the target:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Fine-tune the target for demo mode:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribut demo_mode_write_protect=0
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribut generate_node_acls=1
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/ set
> attribut cache_dynamic_acls=1
Save the configuration:
# targetcli saveconfig
Check for the target:
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool
Connect to the target:
# iscsiadm -m node --login
Log ind pÄ [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (flere)
Login til [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] var succesfuld.
Hvis du har gjort alt rigtigt, vil der pÄ serveren dukke op en ny disk, der ser ud som et SCSI-enhed, men faktisk er et billede fra Ceph, som tilgÄs via iSCSI-target. For at undgÄ problemer under opstart, er det bedst at fjerne den tilsluttede disk og den opdagede target fra den lokale initiator:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Det, der er tilbage â er at vedholde konfigurationen, sĂ„ billedet automatisk tilsluttes, og target bliver startet efter tilslutning. Starten af target bestĂ„r af to skridt â tilslutning af RBD og selve starten af target.
FĂžrst konfigurerer vi automatisk tilslutning af RBD-billeder til vĂŠrten. Dette gĂžres ved at tilfĂžje linjer til filen /etc/ceph/rbdmap:
# kat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl aktiver rbdmap
Det er lidt mere kompliceret med gendannelsen af target-konfigurationen â vi skal skrive en enhed til systemd, som vil genskabe konfigurationen:
# kat /usr/lib/systemd/system/scsi-target.service
[Unit]
Beskrivelse=Start iSCSI mÄl
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
Den endelige test â genstart vores monitor endnu engang (som nu ogsĂ„ er iSCSI-target). Det skal bemĂŠrkes, at hvis vi ikke havde renset initiatorens database med kommandoen iscsiadm -n discoverydb -o delete ⊠ville vi kunne fĂ„ en server, der ikke kunne boote eller tog lang tid om at boote.
Hvad er der tilbage?
Konfigurer initiatoren pÄ den server, hvor vi Þnsker at levere target.
Hvordan sikrer vi, at vores target er fejltolerant?
Vi kan tilsvarende konfigurere targets pÄ andre monitorer og etablere multipath (vmware vil forstÄ dette og det vil endda fungere, Hyper-V vil ikke forstÄ - der krÊves SCSI-lÄse). Da Ceph-klienten ikke bruger caching fra kernen, er dette fuldt fungerende. Eller et andet alternativ - oprette en klyngeresource bestÄende af tre komponenter - en dedikeret IP-adresser target og tjenesterne rbdmap og scsi-target, og styre denne ressource gennem klyngevÊrktÞjer (hvem sagde pacemaker?)
I stedet for et efterskrift
Som det fremgĂ„r, er denne artikel lidt af en joke â men jeg har forsĂžgt at gennemgĂ„ flere ret populĂŠre emner hurtigt og med eksempler â iSCSI-mĂ„l, der ikke nĂždvendigvis skal eksportere Ceph-billeder â men som eksempel pĂ„ at eksportere LVM-volumener, grundlĂŠggende arbejde med iSCSI-initiator (hvordan man scanner mĂ„let, hvordan man forbinder til mĂ„let, frakobler, sletter registreringen af mĂ„let fra databasen), skrivning af ens egen enhed til systemd og nogle andre emner.
Jeg hÄber, at selv hvis du ikke vil gentage hele dette eksperiment i sin helhed, sÄ vil noget fra denne artikel vÊre nyttigt for dig.
Kilde: habr.com
