Er der dem blandt os (tsefovodov), der ikke kan lide "professionel ekstrem"?
Det er usandsynligt - ellers ville vi ikke tumle rundt med dette ekstremt interessante og sjove produkt.
Mange af dem, der var involveret i driften af Ceph, er stødt på en ikke særlig hyppig (eller rettere endda meget sjælden), men nogle gange efterspurgt sag - der forbinder Ceph via iSCSI eller FC. For hvad? Nå, for eksempel, indsend et billede fra Ceph til en Windows- eller Solaris-server, der endnu ikke er blevet virtualiseret af en eller anden grund. Eller en virtualiseret, men ved at bruge en hypervisor, der ikke kan Ceph - og, som vi ved, er der masser af dem. For eksempel? Nå, for eksempel HyperV eller ESXi, som bruges aktivt. Og opstår opgaven med at servere et billede fra Ceph til en gæstemaskine, bliver det til en meget spændende opgave.
Så givet:
- en allerede kørende Ceph-klynge
- et allerede eksisterende billede, der skal serveres via iSCSI
- Pool navn mypool, billednavn mit billede
Begynde?
Først og fremmest, når vi taler om FC eller iSCSI, har vi sådanne enheder som initiativtager og mål. Target er faktisk en server, initiativtager er en klient. Vores opgave er at indsende Ceph-billedet til initiativtageren med minimal indsats. Det betyder, at vi skal udvide målet. Men hvor, på hvilken computer?
Heldigvis har vi i en Ceph-klynge mindst én komponent, hvis IP-adresse er fast, og hvor en af de vigtigste komponenter i Ceph er konfigureret, og den komponent er monitoren. Derfor installerer vi et iSCSI-mål på skærmen (og en igangsætter på samme tid, i det mindste til test). Det gjorde jeg på CentOS, men løsningen er også velegnet til enhver anden distribution - du skal blot installere pakkerne på den måde, som er acceptabel i din distribution.
# yum -y install iscsi-initiator-utils targetcli
Hvad er formålet med de installerede pakker?
- targetcli — et værktøj til styring af SCSI-målet indbygget i Linux-kernen
- iscsi-initiator-utils — en pakke med hjælpeprogrammer, der bruges til at administrere iSCSI-initiatoren indbygget i Linux-kernen
For at indsende et billede via iSCSI til initiativtageren, er der to muligheder for udvikling af hændelser - brug brugerområdets backend af målet eller tilslut billedet som en blokenhed, der er synlig for operativsystemet, og eksporter det via iSCSI. Vi vil gå den anden vej - brugerområdets backend er stadig i en "eksperimentel" tilstand og er lidt ikke klar til produktiv brug. Derudover er der faldgruber med, som man kan snakke meget om og (åh rædsel!) skændes om.
Hvis vi bruger selv en noget stabil distribution med en lang supportcyklus, så er den kerne, vi har, en gammel, gammel version. For eksempel er det i CentOS7 3.10.*, i CentOS8 er det 4.19. Og vi er interesseret i en kerne på mindst 5.3 (eller rettere 5.4) og nyere. Hvorfor? Fordi Ceph-billeder som standard har et sæt muligheder aktiveret, som ikke er kompatible med ældre kerner. Det betyder, at vi forbinder et lager med en ny kerne til vores distribution (for CentOS er dette elrepo), installerer den nye kerne og genstarter systemet for at arbejde med den nye kerne:
- Tilslut til den monitor, der er valgt til eksperimentet
- Vi forbinder elrepo repositories i henhold til instruktionerne -
- Installer kernen: yum -y —enablerepo=elrepo-kernel installer kernel-ml
- Genstart serveren med skærmen (vi har tre skærme, ikke?)
Tilslutning af billedet som en blokenhed
# rbd map mypool/myimage
/dev/rbd0
Det eneste, der er tilbage, er at konfigurere målet. I dette eksempel vil jeg konfigurere målet i den såkaldte. demotilstand - uden godkendelse, synlig og tilgængelig for alle. I et produktionsmiljø vil du sandsynligvis gerne konfigurere godkendelse - men det er lidt uden for rammerne for dagens bare for sjov øvelse.
Opret en backend ved navn disk1 forbundet med filen /dev/rbd/mypool/myimage. Den angivne fil er et symbolsk link, der automatisk oprettes af udev-dæmonen til /dev/rbd0. Vi bruger et symbolsk link, fordi navnet på rbd-enheden kan ændre sig afhængigt af den rækkefølge, hvori Ceph-billederne er forbundet til værten.
Opret en backend:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Opret et iSCSI-mål:
# targetcli /iscsi create iqn.2020-01.demo.ceph:mypool
Vi forbinder backend som en LUN til målet:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
Lad os konfigurere målet for demotilstand:
# 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
Gem konfigurationen:
# targetcli saveconfig
Kontrol af tilstedeværelsen af 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 forbinder 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.
Hvis du har gjort alt korrekt, vil der dukke en ny disk op på serveren, som ligner en SCSI-enhed, men som faktisk er et billede fra Ceph, der tilgås via et iSCSI-mål. For at undgå opstartsproblemer er det bedre at fjerne den tilsluttede disk og det detekterede mål fra den lokale initiator:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Det eneste, der er tilbage, er at fortsætte konfigurationen, så billedet forbindes automatisk, og efter tilslutning bliver målet stratificeret. Affyring af et mål består af to trin - at forbinde RBD'en og faktisk affyre målet.
Lad os først konfigurere den automatiske forbindelse af RBD-billeder til værten. Dette gøres ved at tilføje følgende linjer til filen /etc/ceph/rbdmap:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
Gendannelse af målkonfigurationen er lidt mere kompliceret - vi skal skrive en enhed til systemd, der vil gendanne 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
Den sidste test er at genstarte vores skærm igen (det er nu et iSCSI-mål). Det skal bemærkes, at hvis vi ikke havde ryddet initiativtagerens database med kommandoen iscsiadm -n discoverydb -o slet ... du kan ende med en server, der ikke indlæses eller tager lang tid at indlæse.
Hvad er der tilbage?
Konfigurer initiatoren på serveren, hvor vi vil sende målet.
Hvordan sikrer vi vores måls fejltolerance?
Du kan på samme måde konfigurere mål på andre skærme og opsætte multipath (vmware vil forstå dette og endda arbejde, Hyper-V vil ikke forstå - det kræver SCSI-låse). Da Ceph-klienten fra kernen ikke bruger caching, er dette ganske brugbart. Eller en anden mulighed er at oprette en klyngressource af tre komponenter - en dedikeret mål-IP-adresse og rbdmap og scsi-target-tjenester og administrere denne ressource gennem klyngeværktøjer (hvem sagde pacemaker?)
i stedet for en epilog
Som det er klart, er denne artikel lidt af en vittighed - men i den forsøgte jeg at "hurtigt og med eksempler" overveje flere temmelig populære emner på samme tid - ISCSI -mål, som muligvis ikke nødvendigvis eksporterer Ceph -billeder - men for eksempel Eksport LVM -volumener, det grundlæggende ved at arbejde med en iSCSI -initiator (hvordan man scanner et mål, hvordan man opretter forbindelse til et mål, afbryder, slet et målindgang fra databasen), skriver din egen enhed til systemd og nogle andre
Jeg håber, at selvom du ikke gentager hele dette eksperiment fuldt ud, vil i det mindste noget fra denne artikel være nyttigt for dig.
Kilde: www.habr.com