Ci sono tra di noi (gli utenti di Ceph) quelli che non amano il «profesisonale estremo»?
Difficile che ci siano — altrimenti non ci daremmo da fare con questo prodotto estremamente interessante e divertente.
Molti di coloro che si sono occupati dell'implementazione di Ceph hanno incontrato un caso non molto comune (anzi, piuttosto raro) ma a volte richiesto — connettere Ceph tramite iSCSI o FC. Perché? Bene, ad esempio, per fornire un'immagine da Ceph a un server Windows o Solaris che non è stato ancora virtualizzato. Oppure a uno virtualizzato, ma tramite un hypervisor che non supporta Ceph — e ce ne sono, come sappiamo, molti. Ad esempio? Beh, ad esempio, HyperV o ESXi, che sono ampiamente utilizzati. E se sorge l'esigenza di fornire un'immagine da Ceph a una macchina virtuale, questo si trasforma in un compito piuttosto affascinante.
Dunque, abbiamo:
- un cluster Ceph già funzionante
- un'immagine esistente che deve essere fornita tramite iSCSI
- Nome del pool mypool, nome dell'immagine myimage
Iniziamo?
Prima di tutto, quando parliamo di FC o iSCSI, ci troviamo di fronte a entità come l'iniziatore (initiator) e il target. Il target è fondamentalmente il server, mentre l'iniziatore è il client. Il nostro compito è fornire l'immagine di Ceph all'iniziatore con il minimo sforzo. Questo significa che dobbiamo implementare il target. Ma dove, su quale computer?
Fortunatamente, nel cluster Ceph abbiamo almeno un componente con un indirizzo IP fisso su cui è configurato uno dei componenti più importanti di Ceph, ossia il monitor. Pertanto, installiamo il target iSCSI sul monitor (e l'iniziatore, almeno per i test). L'ho fatto su CentOS, ma la soluzione è valida anche per qualsiasi altra distribuzione; basta installare i pacchetti in un modo che sia accettabile per la vostra distribuzione.
# yum -y install iscsi-initiator-utils targetcli
Qual è la funzione dei pacchetti da installare?
- targetcli — un'utilità per gestire il target SCSI integrato nel kernel Linux
- iscsi-initiator-utils — un pacchetto con strumenti utilizzati per gestire anche l'iniziatore iSCSI integrato nel kernel Linux
Per inviare un'immagine tramite iSCSI a un initiator, ci sono due possibili sviluppi: utilizzare un backend target in userspace oppure collegare l'immagine come un dispositivo di blocco visibile per il sistema operativo ed esportarlo via iSCSI. Seguiremo la seconda strada: il backend in userspace è attualmente in uno stato "sperimentale" e non è del tutto pronto per un uso produttivo. Inoltre, ci sono alcuni aspetti controversi di cui si può discutere molto e (orrore!) persino litigare.
Se utilizziamo una distribuzione relativamente stabile con un lungo ciclo di supporto, il kernel sarà di una versione piuttosto antica. Ad esempio, in CentOS7 è 3.10.*, in CentOS8 è 4.19. A noi interessa un kernel di almeno 5.3 (e probabilmente 5.4) o superiore. Perché? Perché, per impostazione predefinita, le immagini in Ceph hanno un insieme di opzioni attivo, che non è compatibile con i kernel più vecchi. Significa che dobbiamo abilitare il repository con il nuovo kernel per la nostra distribuzione (ad esempio, per CentOS, è elrepo), installare il nuovo kernel e riavviare il sistema per lavorare con il nuovo kernel:
- Connettiamoci al monitor scelto per l'esperimento
- Colleghiamo i repository elrepo seguendo le istruzioni —
- Installiamo il kernel: yum -y --enablerepo=elrepo-kernel install kernel-ml
- Riavviamo il server con monitor (abbiamo tre monitor, giusto?)
Colleghiamo l'immagine come dispositivo di blocco
# mappa rbd mypool/myimage
/dev/rbd0
Rimane solo da configurare il target. In questo esempio configurerò il target in modalità demo — senza autenticazione, visibile e accessibile a tutti. In un ambiente di produzione, probabilmente vorrete configurare l'autenticazione — ma questo è leggermente fuori tema per l'esercizio di oggi, solo per divertimento.
Creiamo un backend chiamato disk1 associato al file /dev/rbd/mypool/myimage. Il file specificato è un collegamento simbolico creato automaticamente dal demone udev a /dev/rbd0. Utilizziamo proprio il collegamento simbolico perché il nome del dispositivo rbd può cambiare a causa dell'ordine di collegamento delle immagini Ceph all'host.
Creiamo il backend:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Creiamo il target iSCSI:
# targetcli /iscsi create 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
Finire di configurare il target per la modalità demo:
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/set
> attributo demo_mode_write_protect=0
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/set
> attributo generate_node_acls=1
# targetcli /iscsi/iqn.2020-01.demo.ceph:mypool/tpg1/set
> attributo cache_dynamic_acls=1
Salviamo la configurazione:
# targetcli saveconfig
Verifichiamo 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, accessibile tramite il target iSCSI. Per evitare problemi all'avvio, è meglio rimuovere il disco connesso e il target individuato dall'iniziatore locale:
# iscsiadm -m nodo --logout
# iscsiadm -m discoverydb -o elimina -t st -p 127.0.0.1:3260
L'unica cosa che resta è persistere la configurazione, affinché l'immagine si connetta automaticamente e dopo la connessione venga avviato il target. L'avvio del target consiste in due passaggi: la connessione RBD e l'effettivo avvio del target.
Iniziamo a configurare la connessione automatica delle immagini RBD all'host. Si fa aggiungendo righe al file /etc/ceph/rbdmap:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
Con il ripristino della configurazione del target è un po' più complicato: dobbiamo scrivere un'unità per systemd, che ripristinerà la configurazione:
# cat /usr/lib/systemd/system/scsi-target.service
[Unit]
Descrizione=Avvia 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 di nuovo il nostro monitor (che ora è anche il target iSCSI). È importante notare che se non avessimo ripulito il database dell'iniziatore con il comando iscsiadm -n discoverydb -o delete … potreste avere un server che non si carica o si carica lentamente.
Cosa rimane?
Configurare l'iniziatore sul server a cui vogliamo inviare il target.
Come garantire la tolleranza ai guasti del nostro target?
È possibile configurare i target su altri monitor in modo simile e organizzare un multipath (vmware lo comprenderà e funzionerà, Hyper-V non lo capirà — ci vogliono blocchi SCSI). Poiché il client Ceph non utilizza la cache dal kernel, questo è perfettamente funzionale. Oppure un'altra opzione è creare una risorsa clusterizzata composta da tre componenti — un target dedicato e i servizi rbdmap e scsi-target, gestendo questa risorsa attraverso strumenti di clustering (chi ha detto pacemaker?) Indirizzi IP Come è chiaro, questo articolo è un po' una battuta — ma in esso ho cercato di esaminare "rapidamente e con esempi" diversi argomenti relativamente popolari — il target iSCSI, che non deve necessariamente esportare immagini Ceph — ma può esportare volumi LVM, le basi del funzionamento con un iniziatore iSCSI (come scansionare il target, come connettersi al target, disconnettersi, eliminare la voce del target dal database), scrivere la propria unità per systemd e alcuni altri.
Invece del postfazione
Come evidente, questo articolo è un po' una scherzo — ma ho cercato di esaminare "velocemente e con esempi" diversi argomenti abbastanza popolari: il target iSCSI, che non deve necessariamente esportare immagini Ceph — ma ad esempio può esportare volumi LVM, le basi del lavoro con l'iniziatore iSCSI (come scansionare il target, come connettersi al target, disconnettersi, eliminare la registrazione del target dal database), scrivere una propria unità per systemd e alcune altre cose.
Spero che anche se non ripeterai del tutto questo esperimento, almeno qualcosa di questo articolo ti risulti utile.
Fonte: habr.com
