Ci sono tra noi (cephisti) coloro che non amano l'«estremo professionale»?
Difficilmente, altrimenti non ci saremmo buttati in questo prodotto estremamente interessante e divertente.
Molti di quelli che hanno operato con Ceph hanno incontrato un caso non troppo comune (anzi, molto raro) ma talvolta richiesto: connettere Ceph tramite iSCSI o FC. Perché? Ad esempio, per fornire un'immagine da Ceph a un server Windows o Solaris che non è ancora virtualizzato. Oppure a uno virtualizzato, ma tramite un hypervisor che non supporta Ceph — e ce ne sono, come sappiamo, a sufficienza. Ad esempio? Beh, HyperV o ESXi, che vengono utilizzati attivamente. E se sorge l'esigenza di fornire un'immagine da Ceph a una macchina guest, diventa un compito piuttosto affascinante.
Quindi, abbiamo:
- un cluster Ceph già funzionante
- un'immagine esistente da fornire tramite iSCSI
- Nome del pool mypool, nome dell'immagine myimage
Iniziamo?
Prima di tutto, quando parliamo di FC o iSCSI, emergono entità come initiator e target. Il target è fondamentalmente il server, l'initiator è il client. Il nostro obiettivo è fornire l'immagine Ceph all'initiator con il minimo dispendio di effort. Quindi, dobbiamo implementare il target. Ma dove, su quale computer?
Fortunatamente, nel cluster Ceph abbiamo almeno un componente il cui indirizzo IP è fisso e su cui è configurato uno dei componenti più importanti di Ceph, ed è questo componente: il monitor. Di conseguenza, installiamo il target iSCSI sul monitor (e l'initiator anche, almeno per i test). L'ho fatto su CentOS, ma per qualsiasi altra distribuzione la soluzione è altrettanto valida: è sufficiente installare i pacchetti nel modo che è accettabile per la vostra distribuzione.
# yum -y install iscsi-initiator-utils targetcli
Qual è lo scopo dei pacchetti che stiamo installando?
- targetcli — strumento di gestione del target SCSI integrato nel kernel Linux
- iscsi-initiator-utils — pacchetto con strumenti utilizzati per gestire, di nuovo, l'initiator iSCSI integrato nel kernel Linux
Per presentare un'immagine tramite iSCSI a un initiator, ci sono due possibili strade: utilizzare un backend target in userspace oppure collegare l'immagine come un dispositivo a blocchi visibile per il sistema operativo ed esportarla tramite iSCSI. Noi seguiremo la seconda opzione: il backend in userspace è ancora in uno stato "sperimentale" e non è completamente pronto per un uso produttivo. Inoltre, ci sono insidie di cui si può discutere a lungo e (oh, orrore!) argomentare.
Se utilizziamo una distribuzione anche solo vagamente stabile con un lungo ciclo di supporto, allora il kernel sarà di una qualche versione molto datata. Ad esempio, in CentOS7 è 3.10.*, in CentOS8 è 4.19. Ma a noi interessa un kernel almeno 5.3 (o meglio 5.4) e più recente. Perché? Perché, per impostazione predefinita, le immagini in Ceph hanno un insieme di opzioni connesse che non sono compatibili con i kernel più vecchi. Di conseguenza, colleghiamo il repository con il nuovo kernel per la nostra distribuzione (ad esempio, per CentOS è elrepo), installiamo il nuovo kernel e riavviamo il sistema per lavorare con il nuovo kernel:
- Ci connettiamo al monitor scelto per l'esperimento
- Colleghiamo i repository elrepo secondo le istruzioni —
- Installiamo il kernel: yum -y —enablerepo=elrepo-kernel install kernel-ml
- Riavviamo il server con il monitor (abbiamo tre monitor, giusto?)
Colleghiamo l'immagine come dispositivo a blocchi
# mappa rbd mypool/myimage
/dev/rbd0
Resta solo da configurare il target. In questo esempio configurerò il target in modalità nota come demo — senza autenticazione, visibile e accessibile a tutti. In un ambiente produttivo, probabilmente vorresti configurare l'autenticazione — ma questo è leggermente oltre lo scopo dell'esercizio di oggi solo per divertimento.
Creiamo un backend di nome disk1 associato al file /dev/rbd/mypool/myimage. Il file specificato è un collegamento simbolico creato automaticamente dal demone udev su /dev/rbd0. Utilizziamo proprio il collegamento simbolico, poiché il nome del dispositivo rbd può cambiare a causa dell'ordine di collegamento delle immagini Ceph all'host.
Creiamo il backend:
# targetcli /backstores/block crea disk1 /dev/rbd/mypool/myimage
Creiamo il target iSCSI:
# targetcli /iscsi crea iqn.2020-01.demo.ceph:mypool
Colleghiamo il backend come LUN al target:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/luns crea /backstores/block/disk1
Configuriamo ulteriormente il target per la modalità demo:
# 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
Salviamo la configurazione:
# targetcli saveconfig
Controlliamo la presenza del target:
# iscsiadm -m discovery -t st -p 127.0.0.1:3260
127.0.0.1:3260,1 iqn.2020-01.demo.ceph:mypool
Colleghiamo il target:
# iscsiadm -m node --login
Accesso a [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] (multiplo)
Accesso a [iface: default, target: iqn.2020-01.demo.ceph:mypool, portal: 127.0.0.1,3260] riuscito.
Se hai fatto tutto correttamente, sul server apparirà un nuovo disco che appare come un dispositivo SCSI, ma in realtà è un'immagine di Ceph, a cui si accede tramite un target iSCSI. Per evitare problemi durante il caricamento, è meglio rimuovere il disco connesso e il target rilevato dall'iniziatore locale:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Tutto ciò che rimane è persistere la configurazione, in modo che l'immagine venga montata automaticamente e dopo la connessione venga avviato il target. L'avvio del target consiste in due fasi: collegamento RBD e avvio del target stesso.
Innanzitutto configuriamo il collegamento automatico delle immagini RBD all'host. Questo avviene aggiungendo le righe al file /etc/ceph/rbdmap:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
La configurazione del target è un po' più complessa: dobbiamo scrivere un'unità per systemd, che ripristinerà la configurazione:
# cat /usr/lib/systemd/system/scsi-target.service
[Unit]
Descrizione=Avviare il target iSCSI
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
Il test finale: riavviamo ancora una volta il nostro monitor (che ora è anche un target iSCSI). Si deve notare che se non avessimo cancellato il database dell'iniziatore con il comando iscsiadm -n discoverydb -o delete … potremmo avere un server che non si avvia o che impiega molto tempo per avviarsi.
Cosa resta?
Configurare l'iniziatore sul server a cui vogliamo inviare il target.
Come garantire la disponibilità del nostro target?
Si possono configurare analogamente i target su altri monitor e organizzare un multipath (vmware lo capirà e funzionerà, Hyper-V non lo capirà: lì sono necessarie le serrature SCSI). Poiché il client Ceph dal kernel non utilizza la cache, questo è perfettamente funzionale. Un'altra opzione è creare una risorsa cluster di tre componenti: un target dedicato e i servizi rbdmap e scsi-target, e gestire questa risorsa tramite strumenti di clustering (chi ha detto pacemaker?) Indirizzi IP Come si capisce, questo articolo è un po' una battuta - ma ci ho provato a esaminare 'rapidamente e con esempi' simultaneamente diversi argomenti abbastanza popolari - il target iSCSI, che può non necessariamente esportare immagini Ceph - ma ad esempio esportare volumi LVM, le basi del funzionamento con l'iniziatore iSCSI (come scansionare il target, come collegarsi al target, scollegarsi, rimuovere la voce del target dal database), scrivere la propria unità per systemd e alcune altre.
In conclusione
Come è ovvio, questo articolo è un po' uno scherzo — ma in esso ho cercato di esaminare «in modo rapido e con esempi» contemporaneamente diversi argomenti piuttosto popolari — l'obiettivo iSCSI, che non deve necessariamente esportare immagini Ceph — ma ad esempio esportare volumi LVM, le basi del lavoro con l'iniziatore iSCSI (come scansionare l'obiettivo, come collegarsi all'obiettivo, disconnettersi, rimuovere la registrazione dell'obiettivo dal database), scrivere la propria unità per systemd e alcune altre.
Spero che anche se non ripeterai completamente questo esperimento, almeno qualcosa di questo articolo possa risultarti utile.
Fonte: habr.com
