Ci sono quelli tra noi (tsefovodov) a cui non piace il “professionale estremo”?
È improbabile, altrimenti non ci troveremmo a giocare con questo prodotto estremamente interessante e divertente.
Molti di coloro che sono stati coinvolti nel funzionamento di Ceph si sono imbattuti in uno non molto frequente (o meglio anche molto raro) ma a volte richiesto: connettere Ceph tramite iSCSI o FC. Per quello? Bene, ad esempio, invia un'immagine da Ceph a un server Windows o Solaris che per qualche motivo non è stato ancora virtualizzato. Oppure virtualizzato, ma utilizzando un hypervisor che non può eseguire Ceph e, come sappiamo, ce ne sono molti. Per esempio? Bene, ad esempio, HyperV o ESXi, che vengono utilizzati attivamente. E se si presenta il compito di fornire un'immagine da Ceph a una macchina ospite, questo si trasforma in un compito molto entusiasmante.
Quindi, dato:
- un cluster Ceph già in esecuzione
- un'immagine già esistente che deve essere servita tramite iSCSI
- Nome della piscina mypool, nome dell'immagine la mia immagine
Inizio?
Prima di tutto, quando parliamo di FC o iSCSI, abbiamo entità come iniziatore e destinazione. Il target è in realtà un server, l'iniziatore è un client. Il nostro compito è inviare l'immagine Ceph all'iniziatore con il minimo sforzo. Ciò significa che dobbiamo espandere il target. Ma dove, su quale computer?
Fortunatamente, in un cluster Ceph abbiamo almeno un componente il cui indirizzo IP è fisso e su cui è configurato uno dei componenti più importanti di Ceph, e quel componente è il monitor. Di conseguenza, installiamo un target iSCSI sul monitor (e contemporaneamente un iniziatore, almeno per i test). L'ho fatto su CentOS, ma la soluzione è adatta anche a qualsiasi altra distribuzione: devi solo installare i pacchetti nel modo accettabile per la tua distribuzione.
# yum -y install iscsi-initiator-utils targetcli
Qual è lo scopo dei pacchetti installati?
- targetcli — un'utilità per la gestione del target SCSI integrato nel kernel Linux
- iscsi-iniziatore-utils — un pacchetto con utilità utilizzate per gestire l'iniziatore iSCSI integrato nel kernel Linux
Per inviare un'immagine tramite iSCSI all'iniziatore, ci sono due opzioni per lo sviluppo di eventi: utilizzare il backend dello spazio utente della destinazione o connettere l'immagine come dispositivo a blocchi visibile al sistema operativo ed esportarla tramite iSCSI. Seguiremo la seconda strada: il backend dello spazio utente è ancora in uno stato "sperimentale" e leggermente non pronto per l'uso produttivo. Inoltre, ci sono delle insidie di cui puoi parlare molto e (oh orrore!) Discutere.
Se usiamo anche una distribuzione abbastanza stabile con un lungo ciclo di supporto, allora il kernel che abbiamo è una versione antica, molto antica. Ad esempio, in CentOS7 è 3.10.*, in CentOS8 è 4.19. E a noi interessa un kernel almeno 5.3 (o meglio 5.4) e successivi. Perché? Perché per impostazione predefinita le immagini Ceph hanno una serie di opzioni abilitate che non sono compatibili con i kernel precedenti. Ciò significa che colleghiamo un repository con un nuovo kernel per la nostra distribuzione (ad esempio, per CentOS questo è elrepo), installiamo il nuovo kernel e riavviamo il sistema per lavorare con il nuovo kernel:
- Connettersi al monitor selezionato per l'esperimento
- Colleghiamo i repository elrepo secondo le istruzioni -
- Installa il kernel: yum -y —enablerepo=elrepo-kernel installa kernel-ml
- Riavvia il server con il monitor (abbiamo tre monitor, giusto?)
Collegamento dell'immagine come dispositivo a blocchi
# rbd map mypool/myimage
/dev/rbd0
Non resta che configurare il target. In questo esempio, configurerò la destinazione nel cosiddetto. modalità demo - senza autenticazione, visibile e accessibile a tutti. In un ambiente di produzione, probabilmente vorrai configurare l'autenticazione, ma questo è un po' fuori dall'ambito dell'esercizio di oggi, solo per divertimento.
Crea un backend denominato disk1 associato al file /dev/rbd/mypool/myimage. Il file specificato è un collegamento simbolico creato automaticamente dal demone udev a /dev/rbd0. Utilizziamo un collegamento simbolico perché il nome del dispositivo rbd può cambiare a seconda dell'ordine in cui le immagini Ceph sono collegate all'host.
Crea un back-end:
# targetcli /backstores/block create disk1 /dev/rbd/mypool/myimage
Creare una destinazione 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 create /backstores/block/disk1
Configuriamo 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
Salva la configurazione:
# targetcli saveconfig
Verifica della 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 l'obiettivo:
# 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.
Se hai fatto tutto correttamente, sul server apparirà un nuovo disco, che assomiglia a un dispositivo SCSI, ma in realtà è un'immagine di Ceph, a cui si accede tramite un target iSCSI. Per evitare problemi di avvio, è meglio rimuovere il disco connesso e la destinazione rilevata dall'iniziatore locale:
# iscsiadm -m node --logout
# iscsiadm -m discoverydb -o delete -t st -p 127.0.0.1:3260
Non resta che persistere la configurazione in modo che l'immagine venga connessa automaticamente e, dopo la connessione, il target venga stratificato. Il lancio di un bersaglio consiste in due passaggi: collegare l'RBD e lanciare effettivamente il bersaglio.
Innanzitutto, configuriamo la connessione automatica delle immagini RBD all'host. Questo viene fatto aggiungendo le seguenti righe al file /etc/ceph/rbdmap:
# cat /etc/ceph/rbdmap
# RbdDevice Parameters
mypool/myimage id=admin
# systemctl enable rbdmap
Ripristinare la configurazione di destinazione è un po' più complicato: dobbiamo scrivere un'unità per systemd che ripristinerà la configurazione:
# 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
Il test finale consiste nel riavviare nuovamente il nostro monitor (ora è un target iSCSI). Va notato che se non avessimo cancellato il database dell'iniziatore con il comando iscsiadm -n discoverydb -o elimina ... potresti ritrovarti con un server che non si carica o impiega molto tempo a caricarsi.
Cosa rimane?
Configura l'iniziatore sul server a cui vogliamo inviare la destinazione.
Come garantire la tolleranza agli errori del nostro obiettivo?
Allo stesso modo puoi configurare target su altri monitor e impostare multipath (VMware lo capirà e funzionerà anche, Hyper-V non lo capirà: richiede blocchi SCSI). Poiché il client Ceph del kernel non utilizza la memorizzazione nella cache, questo è abbastanza fattibile. Oppure un'altra opzione è creare una risorsa cluster di tre componenti: un indirizzo IP di destinazione dedicato e servizi rbdmap e scsi-target e gestire questa risorsa tramite strumenti di clustering (chi ha detto pacemaker?)
Invece di una postfazione
Come è chiaro, questo articolo è un po' uno scherzo - ma in esso ho cercato di considerare "rapidamente e con esempi" diversi argomenti abbastanza popolari allo stesso tempo - target iSCSI, che potrebbe non necessariamente esportare immagini Ceph - ma ad esempio, esportare volumi LVM, nozioni di base per lavorare con un iniziatore iSCSI (come scansionare un target, come connettersi a un target, disconnettersi, eliminare una voce di destinazione dal database), scrivere la propria unità per systemd e alcuni altri
Spero che anche se non ripeterai l'intero esperimento per intero, almeno qualcosa di questo articolo ti sarà utile.
Fonte: habr.com