Installare e configurare un server iSCSI su Ubuntu 22.04

Obiettivo e scelta architetturale

Un server iSCSI espone blocchi disco via rete TCP/IP. Il client, detto initiator, vede un volume remoto come un disco locale. Su Ubuntu 22.04 la scelta più comune per il target è LIO, gestito tramite il pacchetto targetcli-fb. È la soluzione nativa, integrata con il kernel, stabile e adatta sia a laboratori sia a piccoli ambienti di produzione.

Prima di partire conviene fissare alcuni punti: iSCSI non sostituisce un file server, quindi non va usato per condividere file tra più host sullo stesso filesystem senza un cluster file system. Serve invece per presentare un LUN a uno o più initiator in modo controllato. Se l’obiettivo è storage a blocchi per hypervisor, database o host singoli, iSCSI è una scelta sensata. Se invece ti serve solo uno spazio condiviso per documenti, meglio NFS o SMB.

In questa guida configuriamo un target iSCSI su Ubuntu 22.04, con autenticazione opzionale, persistenza al reboot e controlli di base lato client. Assumo una macchina server con IP statico e un disco o una partizione dedicata da esportare.

Prerequisiti minimi

Servono:

• Ubuntu 22.04 aggiornato sul server.
• Un volume dedicato da esportare, ad esempio un disco vuoto o una partizione non montata.
• Connettività di rete tra server e client sulla porta TCP 3260.

Verifica subito che il volume scelto non contenga dati da preservare. Un target iSCSI espone un blocco raw: qualsiasi errore di selezione del dispositivo può causare perdita dati.

Comandi utili per l’inventario iniziale:

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT,MODEL

Controlla che il disco destinato a iSCSI risulti non montato e senza filesystem, oppure che sia un LVM LV o un file immagine creato apposta per questo scopo.

Installazione dei pacchetti

Su Ubuntu 22.04 il target iSCSI si gestisce con targetcli-fb. Installa anche gli strumenti di verifica e, se vuoi usare CHAP o test lato client, i pacchetti initiator.

sudo apt update
sudo apt install targetcli-fb open-iscsi

targetcli-fb fornisce l’interfaccia di configurazione del target. open-iscsi è utile sia sul server per testare il login come initiator sia sul client vero e proprio.

Verifica il servizio del kernel target:

sudo systemctl status target

In molti casi il demone user-space non esiste come servizio classico, perché LIO vive nel kernel e viene configurato da targetcli. L’elemento importante è che il modulo e il filesystem configfs siano disponibili, cosa che avviene normalmente su Ubuntu 22.04.

Preparare il disco o il backstore

Hai due approcci comuni: esportare un disco fisico o una partizione, oppure creare un file immagine e usarlo come backstore. In produzione è preferibile un device dedicato o un LV LVM, perché il file immagine aggiunge un livello in più e prestazioni meno prevedibili.

Esempio con un disco dedicato, supponiamo /dev/sdb. Prima assicurati che non sia montato:

lsblk -f /dev/sdb

Se il disco ha già dati, fermati. Per esportarlo “raw” non devi creare filesystem. Se invece vuoi usare un volume LVM già predisposto, verifica il path del logical volume, ad esempio /dev/vg_iscsi/lv_data.

Esempio con file image, utile in laboratorio:

sudo mkdir -p /srv/iscsi
sudo fallocate -l 20G /srv/iscsi/lun01.img

Il file deve stare su un filesystem affidabile e con spazio sufficiente. In produzione meglio evitare questo schema se il carico è serio.

Configurazione del target con targetcli

Apri la console di configurazione:

sudo targetcli

La struttura logica di LIO è semplice: backstores per i dispositivi fisici o file, iscsi per il target, portals per l’ascolto, acls per autorizzare gli initiator, e luns per collegare il backstore al target.

Creiamo un backstore da disco o file. Se usi un file:

/backstores/fileio create lun01 /srv/iscsi/lun01.img 20G

Se usi un device block dedicato:

/backstores/block create lun01 /dev/sdb

Ora crea il target iSCSI. Il nome IQN deve essere univoco. Usa una convenzione chiara, ad esempio dominio invertito e data:

/iscsi create iqn.2024-01.local.example:storage.lun01

Configura il portal di ascolto sulla porta standard 3260. Se il server ha più IP, puoi limitare l’ascolto a uno specifico indirizzo; altrimenti lascia il wildcard.

/iscsi/iqn.2024-01.local.example:storage.lun01/tpg1/portals create 0.0.0.0 3260

Associa il LUN al target:

/iscsi/iqn.2024-01.local.example:storage.lun01/tpg1/luns create /backstores/fileio/lun01

A questo punto il target esiste, ma chiunque potrebbe tentare l’accesso se non limiti gli ACL. Per l’uso reale aggiungi almeno un initiator autorizzato.

Limitare l’accesso con ACL

Ogni client iSCSI ha un IQN proprio. Lo trovi sul client in /etc/iscsi/initiatorname.iscsi oppure con:

cat /etc/iscsi/initiatorname.iscsi

Supponiamo che l’initiator sia iqn.2024-01.local.example:client01. Sul target crea l’ACL corrispondente:

/iscsi/iqn.2024-01.local.example:storage.lun01/tpg1/acls create iqn.2024-01.local.example:client01

Con ACL attive, solo quell’initiator potrà fare login. Se vuoi restringere ulteriormente, puoi aggiungere CHAP. In ambienti esposti su reti non fidate, CHAP è consigliabile; su LAN isolate può bastare l’ACL, ma la decisione va valutata in base al rischio.

Abilitare CHAP opzionale

Per impostare CHAP sul target, entra nella sessione del target e configura username e password. Usa credenziali forti e non riutilizzate. Non salvare segreti in chiaro in documenti o ticket.

Esempio:

/iscsi/iqn.2024-01.local.example:storage.lun01/tpg1 set attribute authentication=1
/iscsi/iqn.2024-01.local.example:storage.lun01/tpg1 set auth userid=iscsiuser
/iscsi/iqn.2024-01.local.example:storage.lun01/tpg1 set auth password='una-password-lunga-e-unica'

Se abiliti CHAP, poi dovrai configurare il client con le stesse credenziali. Se il login fallisce, i primi punti da controllare sono IQN, ACL, username e password. È facile confondere un problema di rete con uno di autenticazione, quindi conviene verificare prima la reachability sulla porta 3260.

Salvataggio e persistenza

Le modifiche fatte in targetcli vanno salvate, altrimenti spariscono al reboot. Salva la configurazione corrente con:

sudo targetcli saveconfig

Controlla che il file di configurazione esista, in genere sotto /etc/target/saveconfig.json. Questo è il punto da versionare o da includere nel backup della macchina, perché contiene la definizione del target, dei LUN e spesso anche dati sensibili come parametri di autenticazione.

Per verificare la configurazione caricata:

sudo targetcli ls

Nel riepilogo dovresti vedere il target IQN, il portal 3260, il LUN e l’ACL associata. Se manca qualcosa, correggi prima di andare oltre.

Firewall e rete

Il servizio iSCSI usa TCP 3260. Se hai UFW attivo, consenti solo le sorgenti necessarie, idealmente la subnet dei client autorizzati o gli IP singoli degli initiator.

sudo ufw allow from 192.0.2.0/24 to any port 3260 proto tcp

Se UFW non è usato, applica la stessa logica sul firewall di rete o tramite security group, se sei in cloud. Non esporre iSCSI su Internet pubblica: il protocollo non è progettato per quel contesto e il rischio operativo è inutile.

Verifica dall’esterno che la porta sia aperta solo dove previsto:

nc -vz 192.0.2.10 3260

Atteso: connessione riuscita dal client autorizzato e rifiuto o timeout da reti non autorizzate, secondo la tua policy.

Configurazione del client initiator

Sul client installa open-iscsi:

sudo apt update
sudo apt install open-iscsi

Imposta l’IQN dell’initiator se necessario in /etc/iscsi/initiatorname.iscsi. Di solito il pacchetto genera un nome valido, ma in ambienti strutturati conviene standardizzarlo.

Fai la discovery del target:

sudo iscsiadm -m discovery -t sendtargets -p 192.0.2.10

Se il target risponde, vedrai l’IQN esportato. Poi effettua il login:

sudo iscsiadm -m node -T iqn.2024-01.local.example:storage.lun01 -p 192.0.2.10 --login

Se usi CHAP, prima salva le credenziali nel nodo corrispondente e poi fai il login. Dopo l’accesso verifica il nuovo disco:

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

Dovresti vedere un device nuovo, spesso come /dev/sdX. Non montarlo se non hai ancora inizializzato il volume secondo la tua policy.

Persistenza del login lato client

Per fare in modo che il client riconnetta automaticamente al boot, abilita l’avvio del servizio open-iscsi e la sessione del nodo:

sudo systemctl enable iscsid open-iscsi
sudo systemctl restart iscsid open-iscsi

In molte installazioni il login automatico si gestisce anche tramite il database nodi di iscsiadm. Verifica che la voce del nodo abbia l’opzione di startup automatica:

sudo iscsiadm -m node -o show

Controlla node.startup = automatic o equivalente. Se non è così, imposta il nodo:

sudo iscsiadm -m node -T iqn.2024-01.local.example:storage.lun01 -p 192.0.2.10 -o update -n node.startup -v automatic

Questo evita interventi manuali dopo ogni reboot del client.

Inizializzazione del volume sul client

Se il LUN è nuovo, sul client puoi creare filesystem o usare LVM sopra il device iSCSI, a seconda del caso d’uso. Esempio molto semplice con ext4 su un disco dedicato al client singolo:

sudo mkfs.ext4 /dev/sdX

Attenzione: scegli il device corretto. Un errore qui distrugge i dati sul blocco sbagliato. Dopo la formattazione crea il mountpoint e monta:

sudo mkdir -p /mnt/iscsi
sudo mount /dev/sdX /mnt/iscsi

Per renderlo persistente, usa l’UUID nel file /etc/fstab:

sudo blkid /dev/sdX

Inserisci la riga con UUID e tipo filesystem. Se il servizio iSCSI parte in ritardo rispetto al mount, il boot può fallire. In quel caso aggiungi opzioni appropriate in fstab o usa unità systemd con dipendenza dal login iSCSI.

Verifiche operative

Le verifiche minime da fare subito dopo la configurazione sono tre:

1. Il target ascolta su 3260: ss -lntp | grep 3260 o nc -vz server 3260.
2. La discovery mostra l’IQN corretto: iscsiadm -m discovery -t sendtargets -p server.
3. Il client vede il disco e il mount funziona: lsblk, mount, df -h.

Se qualcosa non torna, i primi log da guardare sono lato server e client. Sul server controlla i log di sistema e i messaggi di targetcli o del kernel. Sul client guarda i messaggi di iscsid e i log di sistema:

journalctl -u iscsid -b
journalctl -u open-iscsi -b

Un login rifiutato con disco non visibile spesso indica ACL sbagliata o IQN errato. Un timeout verso la porta 3260 suggerisce firewall, routing o servizio non in ascolto. Un disco visibile ma non montabile punta invece a filesystem, partizione o mountpoint errati.

Gestione e manutenzione

Una buona pratica è documentare il mapping tra target, LUN e client autorizzati. Tieni traccia di:

• IQN del target.
• IQN degli initiator autorizzati.
• Backstore usato e dimensione.
• Eventuali credenziali CHAP.
• Indirizzi IP e subnet autorizzate sul firewall.

Se devi cambiare il backstore, pianifica la disconnessione del client, il backup dei dati e il rollback. Su storage a blocchi non si improvvisa: qualsiasi modifica al device sottostante va trattata come change controllato.

Per rimuovere correttamente una configurazione, prima disconnetti i client, poi elimina LUN e ACL, infine il target e il backstore. Non cancellare il file image o il device senza aver verificato che non sia più in uso. Il rollback, se hai salvato la configurazione, consiste nel ripristinare /etc/target/saveconfig.json o ricreare gli oggetti con targetcli.

Conclusione operativa

Su Ubuntu 22.04 il modo più lineare per offrire iSCSI è LIO tramite targetcli-fb. La sequenza corretta è: preparare il volume, creare backstore, definire target e portal, limitare con ACL, salvare la configurazione, aprire la porta 3260 solo ai client necessari e verificare il login dal lato initiator. Se il target serve in un ambiente serio, aggiungi CHAP, logging adeguato e una procedura di change con rollback chiaro. L’errore più comune non è tecnico ma operativo: esporre il LUN senza controllo o puntare il device sbagliato. Assunzione: il volume iSCSI è dedicato a un singolo host o a un uso coordinato con software di clustering appropriato.