Er det de blant oss (tsefovodov) som ikke liker "profesjonelt ekstrem"?
Det er usannsynlig - ellers ville vi ikke tumlet rundt med dette ekstremt interessante og morsomme produktet.
Mange av de som var involvert i driften av Ceph har støtt på en som ikke er veldig hyppig (eller snarere til og med veldig sjelden), men noen ganger etterspurt - kobler til Ceph via iSCSI eller FC. For hva? Vel, for eksempel, send inn et bilde fra Ceph til en Windows- eller Solaris-server som ennå ikke er virtualisert av en eller annen grunn. Eller en virtualisert en, men ved å bruke en hypervisor som ikke kan Ceph - og som vi vet er det mange av dem. For eksempel? Vel, for eksempel HyperV eller ESXi, som brukes aktivt. Og hvis oppgaven dukker opp med å servere et bilde fra Ceph til en gjestemaskin, blir dette en veldig spennende oppgave.
Så gitt:
- en allerede kjørende Ceph-klynge
- et allerede eksisterende bilde som må serveres via iSCSI
- Bassengnavn mypool, bildenavn mitt bilde
Begynne?
Først av alt, når vi snakker om FC eller iSCSI, har vi slike enheter som initiativtaker og mål. Target er faktisk en server, initiativtaker er en klient. Vår oppgave er å sende inn Ceph-bildet til initiativtakeren med minimal innsats. Dette betyr at vi må utvide målet. Men hvor, på hvilken datamaskin?
Heldigvis har vi i en Ceph-klynge minst én komponent hvis IP-adresse er fast og som en av de viktigste komponentene i Ceph er konfigurert på, og den komponenten er skjermen. Følgelig installerer vi et iSCSI-mål på skjermen (og en initiativtaker samtidig, i det minste for tester). Jeg gjorde dette på CentOS, men løsningen passer også for enhver annen distribusjon - du trenger bare å installere pakkene på den måten som er akseptabel i distribusjonen din.
# yum -y install iscsi-initiator-utils targetcli
Hva er hensikten med de installerte pakkene?
- targetcli — et verktøy for å administrere SCSI-målet innebygd i Linux-kjernen
- iscsi-initiator-utils — en pakke med verktøy som brukes til å administrere iSCSI-initiatoren innebygd i Linux-kjernen
For å sende inn et bilde via iSCSI til initiativtakeren, er det to alternativer for utvikling av hendelser – bruk brukerområdets backend av målet eller koble bildet som en blokkenhet synlig for operativsystemet og eksporter det via iSCSI. Vi vil gå den andre veien - brukerområdets backend er fortsatt i en "eksperimentell" tilstand og er litt ikke klar for produktiv bruk. I tillegg er det fallgruver med det, som du kan snakke mye om og (å grusomt!) krangle om.
Hvis vi bruker til og med en noe stabil distribusjon med en lang støttesyklus, så er kjernen vi har en eldgammel, eldgammel versjon. For eksempel, i CentOS7 er det 3.10.*, i CentOS8 er det 4.19. Og vi er interessert i en kjerne på minst 5.3 (eller rettere sagt 5.4) og nyere. Hvorfor? Fordi Ceph-bilder som standard har et sett med alternativer aktivert som ikke er kompatible med eldre kjerner. Dette betyr at vi kobler et depot med en ny kjerne for distribusjonen vår (for eksempel for CentOS er dette elrepo), installerer den nye kjernen og starter systemet på nytt for å jobbe med den nye kjernen:
- Koble til monitoren som er valgt for eksperimentet
- Vi kobler til elrepo-lagre i henhold til instruksjonene -
- Installer kjernen: yum -y —enablerepo=elrepo-kernel installer kernel-ml
- Start serveren på nytt med skjermen (vi har tre skjermer, ikke sant?)
Koble til bildet som en blokkenhet
# rbd map mypool/myimage
/dev/rbd0
Alt som gjenstår er å konfigurere målet. I dette eksemplet vil jeg konfigurere målet i den såkalte. demomodus - uten autentisering, synlig og tilgjengelig for alle. I et produksjonsmiljø vil du sannsynligvis ønske å konfigurere autentisering - men det er litt utenfor rekkevidden for dagens bare for moro skyld øvelse.
Lag en backend kalt disk1 assosiert med filen /dev/rbd/mypool/myimage. Den angitte filen er en symbolsk lenke automatisk opprettet av udev-daemonen til /dev/rbd0. Vi bruker en symbolsk lenke fordi navnet på rbd-enheten kan endres avhengig av rekkefølgen som Ceph-bildene er koblet til verten.
Lag en backend:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Opprett et iSCSI-mål:
# targetcli /iscsi create iqn.2020-01.demo.ceph:mypool
Vi kobler backend som en LUN til målet:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns create /backstores/block/disk1
La oss konfigurere målet for demomodus:
# 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
Lagre konfigurasjonen:
# targetcli saveconfig
Kontrollere tilstedeværelsen av 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 kobler 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 gjorde alt riktig, vil det dukke opp en ny disk på serveren, som ser ut som en SCSI-enhet, men som faktisk er et bilde fra Ceph, som du får tilgang til via et iSCSI-mål. For å unngå oppstartsproblemer er det bedre å fjerne den tilkoblede disken og det oppdagede målet fra den lokale initiatoren:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Alt som gjenstår er å fortsette konfigurasjonen slik at bildet kobles til automatisk, og etter tilkobling blir målet stratifisert. Å lansere et mål består av to trinn - å koble til RBD og faktisk lansere målet.
La oss først konfigurere den automatiske tilkoblingen av RBD-bilder til verten. Dette gjøres ved å legge til følgende linjer i filen /etc/ceph/rbdmap:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
Å gjenopprette målkonfigurasjonen er litt mer komplisert - vi må skrive en enhet for systemd som vil gjenopprette konfigurasjonen:
# 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 siste testen er å starte skjermen på nytt (det er nå et iSCSI-mål). Det skal bemerkes at hvis vi ikke hadde tømt initiativtakerens database med kommandoen iscsiadm -n discoverydb -o slette ... du kan ende opp med en server som ikke laster eller tar lang tid å laste.
Hva er igjen?
Konfigurer initiatoren på serveren vi ønsker å sende målet til.
Hvordan sikre feiltoleranse for målet vårt?
Du kan på samme måte konfigurere mål på andre skjermer og sette opp multipath (vmware vil forstå dette og til og med fungere, Hyper-V vil ikke forstå - det krever SCSI-låser). Siden Ceph-klienten fra kjernen ikke bruker caching, er dette ganske gjennomførbart. Eller et annet alternativ er å lage en klyngressurs av tre komponenter - en dedikert mål-IP-adresse og rbdmap og scsi-target-tjenester, og administrere denne ressursen gjennom klyngeverktøy (hvem sa pacemaker?)
i stedet for en epilog
Som det er klart, er denne artikkelen litt av en spøk - men i den prøvde jeg å "raskt og med eksempler" vurdere flere ganske populære emner på samme tid - iSCSI-mål, som kanskje ikke nødvendigvis eksporterer Ceph-bilder - men for eksempel, eksportere LVM-volumer, det grunnleggende om å jobbe med en iSCSI-initiator (hvordan skanne et mål, hvordan koble til et mål, koble fra, slette en måloppføring fra databasen), skrive din egen enhet for systemd og noen andre
Jeg håper at selv om du ikke gjentar hele dette eksperimentet i sin helhet, vil i det minste noe fra denne artikkelen være nyttig for deg.
Kilde: www.habr.com