iSCSI

In vista dell' utilizzo di un nas come disco di backup di un server faccio un po' di esperienza con gli strumenti che linux mi mette a disposizione per gestire client e server iscsi.

Per prima cosa procedo a creare sul server 2 falsi dischi (da 10GiB l'uno) che poi verranno montati in remoto dal client tramite iscsi.

Nota che  all'interno di questi file potrei creare un file system ext4 (mkfs.ext4 ./fs.img ) e poi montarli in loop come dischi locali.

Ora prendo un po' di confidenza con la terminologia collegata a iscsi.

SERVER
iSCSI target

Un target iscsi solitamente rappresenta  un gruppo di risorse di storage che si trovano su un server iscsi. Generalmente anche i nas più economici fungono da server iscsi e permettono di mappare porzioni di disco come target iscsi.
Al target (che è il contenitore) andiamo poi ad associare le risorse (chiamate LUN) che rappresentano i dischi (o le partizioni) che poi il client andrà fisicamente a leggere.

Su linux -  demone: tgtd - comandi tgtadm tgt-admin

 

CLIENT
iSCSI initiator

Un client iscsi, detto iSCSI initiator, contatta i target sul server e invia i tipici comandi scsi tramite un rete TCP/IP: normalemnte questi comandi (cose del tipo, la testina X scriva sulla traccia Y) verrebbero mandati su un hard disk scsi fisicamente collegato tramite bus al computer.

Su linux - demone: iscsid o openiscsi - comandi iscsiadm

 

Ora procedo con le configurazioni

SERVER - 192.168.0.254

Su fedora/centos/redht il pacchetto che fornisce tgtd si chiama iscsi-target-utils, semplicemente tgt su debian/ubuntu.
Installo quindi il pacchetto e faccio partire il servizio (appunto tgtd).

In /etc/sysconfig/tgtd (o /etc/defaults/tgtd) ci sono le opzioni di start del demone e le indicazioni sul dove leggere i file di configurazione, per esempio

ISCSI options
These parameters apply only to the iSCSI frontend.
portal=<ip-address[:port]>

This option is used to bind tgtd to a specific ip-address/portal and/or port. By default tgtd will bind to port 3260 on the wildcard address.
Example: to bind tgtd to a specific address and port
tgtd --iscsi portal=192.0.2.1:3260

quindi vado a mettere in /etc/sysconfig/tgtd

# options for tgtd
TGTD_OPTS="--iscsi portal=192.168.0.254:3260"

così si binda su una sola interfaccia. Verifico con netstat

Ci sono 2 modi per configurare tgtd, si possono utilizzare i comandi appositi, modificando qundi "online" (a servizio attivo) la configurazione ma perdendola in caso di riavvio, oppure si può agire sui file di configurazione che si trovano in /etc/tgt. Si può anche procedere in modo ibrido facendo partire il servizio, configurandolo online e poi effettaundo il dump delle configurazioni effettuate su un file che poi diverrà la configurazione.

Oa devo creare il target, ovvero il contenitore di risorse che verrà poi contattato dal client.
Sbircio la documentazione

Quindi

Il nome che ho dato (rolle.merli.net:disco.prova) è completamente casuale, anche se sarebbe meglio se avesse una logica o quantomeno se aiutasse a ricordarsi poi quale risorsa si sta condividendo. Viene chiamato IQN ed è l'identificativo del target.

Ho quindi creato un target
Nome: rolle.merli.net:disco.prova
Id: 1

Posso anche vedere quel che ho fatto con questo comando che da parecchie informazioni

 

 

Ora voglio che solo un client con un ip specifico possa poi montarsi le risorse (i LUN) che assocerò più tardi al target: sbircio ancora la documentazione

Quindi il comando da dare è

Riguardo i parametri del target e mi trovo correttamente le informazioni appena inserite.

Ora voglio agganciare a questo target i 2 falsi dischi che ho creato inizialmente.

(mi raccomando il path deve essere completo /repo/merli/iscsi/fs.img, non puoi solo dirgli ./fs.img)
Ovviamente avrei dovuto specificare -b /deb/sdXY se al posto di un file immagine avessi voluto passare un vero block device.
--tid 1 vuol dire che lo associo al target 1
--lun 1 sto creando la risorsa con id 1

Aggancio ora il secondo lun allo stesso target

tid è sempre 1 , lun in questo caso è 2.

Ora guardo i dettagli del target

 AUTENTICAZIONE CHAP

E' anche possibile specificare un'autenticazione di tipo CHAP, ovvero una coppia di credenziali utente/password che un client deve specificare se vuol effettuare il montaggio delle risorse condivise sul target.
La man page di tgtd, sezione CHAP AUTHENTICATION è piuttosto chiara, io quindi mi limito a eseguire

Creo utente/password

Associo al target 1 le credenziali appena create

In questo modo quando guardo i dettagli del target vedrò anche la voce

Queste configurazione sono da subito funzionanti ma, come scritto precedentemente, non rimarrebbero memorizzate dopo un riavvio.

Vado quindi a effettuare il dump delle configurazioni, salvandolo in un file chiamato /etc/tgt/targets.conf (che è un po' l'analogo di /etc/exports per nfs)

Il file generato sarà così:

La password va reinserita a mano all'interno del file in quanto il dump non mostra in chiaro la password precedentemente inserita (sempre in chiaro comunque) col comando tgtadm

Quando poi il client effettua il login sul target e monta il lun, guardando i dettagli del target col solito comando vedremo

Tutta questa procedura su un nas "casalingo" è molto più semplice: da questa interfaccia, per esempio, ho creato 2 target iscsi ciascuno con un lun in questo modo:

backup1_nas_iscsi

 

CLIENT - 192.168.0.5

Il pacchetto che mi servirà si chiama iscsi-initiator-utils (su fedora/centos/redhat) o open-iscsi (su debian/ubuntu).
Una volta installato farò partire il demone iscsid o open-iscsi.

Il primo passaggio da effettuare è il discovery dei target condivisi dal server

Nel caso precedente, solo 1.

Fatto questo bisognerà effettuare il login sul target desiderato (in questo caso senza autenticazione chap)

Dopo aver dato questo comando, guardo nei log di sistema e vedo

Quindi è come se avessimo collegato 2 dischi, sdc e sdd privi di partizioni, file system e tavola delle partizioni

Non mi resta che utilizzare lo strumento che preferisco (gparted)

backup2_nas_iscsi

per creare partizioni e file system e poi effettuare il montaggio come se il disco fosse in locale, per esempio in questo modo:

Fatto questo posso SMONTARE la partizione ed effettuare il logout dal target (è essenziale prima di fare logout smontare la partizione, altrimenti è come se staccassimo il cavo sata di un disco montato) dando il comando:

AUTENTICAZIONE CHAP - CLIENT

Volendo passare al target anche le credenziali per l'autenticazione CHAP i comandi da dare, prima di effettuare il login, sono:

Il demone iscsid si salva le configurazioni inserite, per ciascun target su cui ci si logga (IQN) e per ciascun ip del server, quindi le informazioni di autenticazione per esempio, basta darle una volta e verranno memorizzate.
I file con queste configurazioni si trovano in /var/lib/iscsi/nodes/ (per fedora/centos/redhat) o /etc/iscsi/nodes/ (per debian redhat). All'interno di questa directory troverò una sotto-struttura di questo tipo

All'interno della quale ci sarà il file "default" che conterrà per esempio le informazioni di autenticazione appena inserite:

 

ACCESSO CONTEMPORANEO?
No, non montare mai lo stesso lun su 2 macchine provando ad accedervici/scriverci contemporaneamente in maniera diretta. iSCSI da solo non può controllare richieste multiple dall' initiator. Quello che si può sicuramente fare è condividere tramite smb uno share che è in realtà un target iSCSI, però la parte di condivisione deve essere fatta da una terza parte.

Print Friendly, PDF & Email