Esperimenti con VirtualBox: creare una lan virtuale - 2/3 - SAN

Nella puntata precedente abbiamo realizzato il fw per la nostra piccola lan virtuale.
Andiamo ora a realizzare la SAN, cioè quel sistema che esporterà via rete i dischi verso il cluster. In effetti questo è un artificio, in un contesto reale i dischi delle SAN sono visibili contemporaneamente a tutti i sistemi e sono normalmente connessi ai server attraverso schede a fibra ottica per ottimizzare i trasferimenti.
Con vmware, ad esempio, è possibile armeggiare un po' con la configurazione ed avere un disco realmente condiviso tra due (o più, credo, ma ho sperimentato solo con 2) server diversi, con virtualbox questo non è possibile, allora proviamo ad aggirare il problema.
La macchina virtuale che farà da SAN, nel mio caso, ha le seguenti caratteristiche:
1 scheda di rete sulla lan-net
1 scheda di rete sulla san-net
Ricordo che la lan-net è la rete interna al firewall (10.100.100.0/24 nel mio caso) mentre la san-net è la rete che useremo per accedere ai dischi. Si potrebbe, in effetti, utilizzare una unica scheda di rete per entrambe le funzioni (cioè raggiungibilità del server ed esportazione dei dischi) però così è formalmente più corretto ed è una configurazione auspicabile quando si abbia una grossa mole di dati che passano sulla rete.
Ci sono diversi standard per il trasporto dei dati su una rete: nfs, sshfs, AoE, iscsi,... I due più interessanti, secondo me, sono AoE (cioè Ata over Ethernet) e iScsi. AoE è forse più semplice da configurare, però non permette né l'autenticazione dei client che si collegano al server per accedere ai dischi né supporta il fatto che client e server stiano su lan diverse. Al contrario iScsi offre sia l'autenticazione che la ruotabilità, permette cioè di esportare dischi anche attraverso lan diverse. Inoltre c'è una interessante feature sperimentale di virtualbox che usa iscsi, poi vedremo meglio.
Nello screenshot qui sotto c'è la configurazione del sistema virtuale.

Ho aggiunto 3 dischi con controller SATA (dovrebbero fornire prestazioni migliori, anche se in effetti in questa applicazione non dovrebbe influire molto) che esporteremo verso il cluster. Questi dischi sono vuoti. Ciascun disco va inizializzato con fdisk. Ad esempio il primo:

san1:~# fdisk /dev/sda

fdisk vi comunicherà che la tabella delle partizioni non è valida. Premendo w fdisk scriverà una tabella valida. Non sono necessari per ora altri interventi sui dischi.
C'è inoltre un disco "boot generico" che useremo per l'esperimento :)
In questo caso abbiamo bisogno di due schede di rete, una verso la lan interna (lan-net) e una per esportare i dischi (san-net).
Il disco di boot è quello clonato dal template, per cui come per il fw ci sono delle modifiche da fare. Una nota: se avete configurato in precedenza il fw con le regole postate potete accedere al sistema via ssh dalla macchina host. Per accedere via ssh alla san1 bisogna collegarsi dalla shell del sistema fw in quanto san1 non ha schede di rete che possono accedere alla rete host.
Come fatto in precedenza annotiamo i mac delle schede di rete.
Modifica del file /etc/hosts

127.0.0.1 localhost
#ip sulla lan locale lan-net
10.100.100.1 fw.rebeldia-lab.local fw
10.100.100.10 san1.rebeldia-lab.local san1
#ip sulla lan dello storage san-net
10.120.32.1 san1.san-net.local

modifica del file /etc/hostname
Riavvio...

san1:~# ifconfig -a
lan0 Link encap:Ethernet HWaddr 08:00:27:b9:c4:d0
inet addr:10.100.100.10 Bcast:10.100.100.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:feb9:c4d0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:70 errors:0 dropped:0 overruns:0 frame:0
TX packets:62 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7644 (7.4 KiB) TX bytes:8060 (7.8 KiB)
Interrupt:11 Base address:0xd020

san0 Link encap:Ethernet HWaddr 08:00:27:93:f0:08
inet addr:10.120.32.1 Bcast:10.120.32.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe93:f008/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:120 (120.0 B) TX bytes:468 (468.0 B)
Interrupt:10 Base address:0xd240

Verifichiamo se il link sulla lan-net funziona. Per fare questo dobbiamo avere acceso anche il fw. Il fw non risponde, nella configurazione attuale, al ping, però se il fw ha l'interfaccia esterna connessa ad internet allora il ping a un sito web dalla san1 dovrebbe, passando attraverso il fw, dare esito positivo:

san1:~# ping www.yahoo.it
PING www.euro.fyeu.b.yahoo.com (217.146.186.51) 56(84) bytes of data.
64 bytes from www.vip.ird.yahoo.com (217.146.186.51): icmp_seq=1 ttl=50 time=56.0 ms
64 bytes from www.vip.ird.yahoo.com (217.146.186.51): icmp_seq=2 ttl=50 time=55.0 ms
^C64 bytes from www.vip.ird.yahoo.com (217.146.186.51): icmp_seq=3 ttl=50 time=54.4 ms

--- www.euro.fyeu.b.yahoo.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 10191ms
rtt min/avg/max/mdev = 54.464/55.176/56.066/0.718 ms

un po' lento... ma funziona :) del resto al momento ci interessa la visibilità nella lan privata, non la velocità di connessione.
Prima di proseguire con l'installazione di iscsi potrebbe, per chi non conoscesse il protocollo, dare una occhiata qui
Dunque, san1 sarà il terminatore della connessione (il server) mentre i vari client che dovranno accedere ai dischi saranno gli iniziatori.
Installiamo il software necessario (per questo è necessario che san1 possa accedere ad internet):

san1:~# aptitude install iscsitarget

dobbiamo configurare il terminatore.
nel mio esempio il layout dei dischi è il seguente:
/dev/sda è un disco di boot generico
/dev/sdb,sdc,sdd sono dischi vuoti da 5 GB
Ogni entità iscsi, che per semplicità chiameremo disco :), è rappresentata nella seguente maniera:
iqn.yyyy-mm.[:identificatore]
iqn è il formato di rappresentazione più usato. In pratica i vari campi hanno il seguente significato:
yyyy-mm : anno e mese. A piacimento... ma non nel futuro.
: il nome del dominio della san invertito. Nel mio caso il nome del dominio è rebeldia-lab.local quindi l'inverso sarà local.rebeldia-lab
[:identificatore] : il nome che vogliamo dare alla risorsa per riconoscerla meglio.
La configurazione del terminatore si effettua modificando il file /etc/ietd.conf (questa serie di post è solo a scopo di test, la configurazione di iscsi non sarà autenticata e avrà la configurazione minima per funzionare):

Target iqn.2010-09.local.rebeldia-lab:bootdisk
Lun 0 Path=/dev/sda,Type=fileio

Target iqn.2010-09.local.rebeldia-lab:SANdisk1
Lun 0 Path=/dev/sdb,Type=fileio

Target iqn.2010-09.local.rebeldia-lab:SANdisk2
Lun 0 Path=/dev/sdc,Type=fileio

Target iqn.2010-09.local.rebeldia-lab:SANdisk3
Lun 0 Path=/dev/sdd,Type=fileio

Bisogna modificare nel file /etc/default/iscsitarget da false a true la riga:

ISCSITARGET_ENABLE=false

Infine c'è da installare il modulo nel kernel.

san1:~# apt-get install iscsitarget-modules
Lettura della lista dei pacchetti in corso... Fatto
Generazione dell'albero delle dipendenze in corso
Lettura informazioni sullo stato... Fatto
Il pacchetto iscsitarget-modules è un pacchetto virtuale fornito da:
iscsitarget-modules-2.6.26-2-xen-686 2.6.26+0.4.16+svn162-6+lenny1
iscsitarget-modules-2.6.26-2-vserver-686-bigmem 2.6.26+0.4.16+svn162-6+lenny1
iscsitarget-modules-2.6.26-2-vserver-686 2.6.26+0.4.16+svn162-6+lenny1
iscsitarget-modules-2.6.26-2-openvz-686 2.6.26+0.4.16+svn162-6+lenny1
iscsitarget-modules-2.6.26-2-amd64 2.6.26+0.4.16+svn162-6+lenny1
iscsitarget-modules-2.6.26-2-686-bigmem 2.6.26+0.4.16+svn162-6+lenny1
iscsitarget-modules-2.6.26-2-686 2.6.26+0.4.16+svn162-6+lenny1
iscsitarget-modules-2.6.26-2-486 2.6.26+0.4.16+svn162-6+lenny1
Bisogna esplicitamente sceglierne uno da installare.
E: Il pacchetto iscsitarget-modules non ha candidati da installare

si copia il nome del pacchetto per la vostra architettura. Nel mio caso:

san1:~# apt-get install iscsitarget-modules-2.6.26-2-686
...
san1:~# /etc/init.d/iscsitarget start
Starting iSCSI enterprise target service: succeeded.

Per testare se funziona il terminatore facciamo l'esperimento di cui parlavo prima. In pratica sfruttiamo una feature sperimentale di virtualbox che permette, al sistema virtuale, di vedere una risorsa iscsi come se fosse un disco locale. Realizziamo, cioè, una macchina virtuale diskless.
nell'help di virtualbox c'è la voce relativa alla procedura per consentire all'ambiente virtuale (cioè alla macchina virtuale prima del boot) di fungere da iniziatore (client) verso la san.
Per fare questo esperimento però bisogna spegnere il sistema san1, aggiungere nella configurazione una scheda di rete in bridge o in nat. Questo perchè il meccanismo di routing delle vlan non permette di accedere ad una rete interna prima del boot della macchina.
Creiamo una macchina virtuale con le caratteristiche che vogliamo, non aggiungiamo dischi al sistema e rimuoviamo anche la scheda di rete che di default viene aggiunta alla creazione. Avremo quindi un sistema diskless e nicless.

Le informazioni da annotare prima di cominciare sono
1) ip di san1 della interfaccia (nuova) aggiunta = 10.19.74.75 (lan non interna)
2) un mac address, generato ad esempio dalle proprietà delle schede di rete
3) un indirizzo ip da assegnare alla scheda di rete del sistema virtuale = 10.19.74.251


Ora sul sistema HOST con l'utenza che usate per avviare virtualbox:

domenico@cerbero:~$ VBoxManage setextradata TEST VBoxInternal/Devices/IntNetIP/0/Trusted 1
VirtualBox Command Line Management Interface Version 3.0.6
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

domenico@cerbero:~$ VBoxManage setextradata TEST VBoxInternal/Devices/IntNetIP/0/Config/MAC 08:00:27:ee:9a:45
VirtualBox Command Line Management Interface Version 3.0.6
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

domenico@cerbero:~$ VBoxManage setextradata TEST VBoxInternal/Devices/IntNetIP/0/Config/IP 10.19.74.251
VirtualBox Command Line Management Interface Version 3.0.6
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

domenico@cerbero:~$ VBoxManage setextradata TEST VBoxInternal/Devices/IntNetIP/0/Config/Netmask 255.255.255.0
VirtualBox Command Line Management Interface Version 3.0.6
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

domenico@cerbero:~$ VBoxManage setextradata TEST VBoxInternal/Devices/IntNetIP/0/LUN#0/Driver IntNet
VirtualBox Command Line Management Interface Version 3.0.6
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

domenico@cerbero:~$ VBoxManage setextradata TEST VBoxInternal/Devices/IntNetIP/0/LUN#0/Config/Network privata1
VirtualBox Command Line Management Interface Version 3.0.6
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

domenico@cerbero:~$ VBoxManage setextradata TEST VBoxInternal/Devices/IntNetIP/0/LUN#0/Config/IsService 1
VirtualBox Command Line Management Interface Version 3.0.6
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

A questo punto dovrebbe essere correttamente configurata l'interfaccia sulla san-net. Attiviamo l'iniziatore e facciamo connettere il disco:

domenico@cerbero:~$ VBoxManage addiscsidisk --server 10.29.74.75 --target iqn.2010-09.local.rebeldia-lab:bootdisk --intnet
VirtualBox Command Line Management Interface Version 3.0.6
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.
iSCSI disk created. UUID: c75b6257-5dbe-4d4d-9b99-ad0b2b2184e1

Torniamo alla configurazione della macchina TEST, nella sezione dischi fissi aggiungere un disco ide primario e selezionare dalla lista il disco che come nome ha server|target, come si vede dalla figura qui sotto:

A questo punto si riavvia il sistema, se è andato tutto bene, il sistema diskless farà il boot.
Il boot è chiaramente un po' più lento.
E' importante, affinché questa prova abbia buon esito, che il sistema san1 sia acceso e che la scheda di rete in bonding o in nat sia correttamente configurata prima di avviare la macchina di test.
A questo punto è possibile spegnere la san1, rimuovere la scheda in bridge o in nat e riavviare san1.

Altra prova possibile, si clona un'altra immagine del disco template, si construisce una macchina di prova con una sola scheda di rete sulla lan interna san-net, si assegna il disco clonato come primario e la si avvia.
una volta avviato il sistema installiamo quanto necessario per l'iniziatore (client)

template-debian:~# apt-get install open-iscsi

e, infine, verifichiamo che la connessione con san1 funzioni:

template-debian:~# iscsiadm -m discovery
10.120.32.1:3260 via sendtargets
template-debian:~# iscsiadm -m discovery -t st -p 10.120.32.1
10.120.32.1:3260,1 iqn.2010-09.local.rebeldia-lab:bootdisk
10.120.32.1:3260,1 iqn.2010-09.local.rebeldia-lab:SANdisk2
10.120.32.1:3260,1 iqn.2010-09.local.rebeldia-lab:SANdisk1
10.120.32.1:3260,1 iqn.2010-09.local.rebeldia-lab:SANdisk3

e questi sono, appunto, i target che avevamo impostato in precedenza su san1.

Questi dischi importati possono essere facilmente utilizzabili:

template-debian:~# iscsiadm -m node --targetname "iqn.2010-09.local.rebeldia-lab:SANdisk2" --portal "10.120.32.1:3260" --login
Logging in to [iface: default, target: iqn.2010-09.local.rebeldia-lab:SANdisk2, portal: 10.120.32.1,3260]
Login to [iface: default, target: iqn.2010-09.local.rebeldia-lab:SANdisk2, portal: 10.120.32.1,3260]: successful

leggendo i messages:

[ 442.020178] scsi0 : iSCSI Initiator over TCP/IP
[ 442.357305] scsi 0:0:0:0: Direct-Access IET VIRTUAL-DISK 0 PQ: 0 ANSI: 4
[ 442.490153] Driver 'sd' needs updating - please use bus_type methods
[ 442.504137] sd 0:0:0:0: [sda] 10485760 512-byte hardware sectors (5369 MB)
[ 442.509827] sd 0:0:0:0: [sda] Write Protect is off

Il disco è stato importato come /dev/sda. Adesso è possibile compiere qualsiasi operazione su questi device così come fareste se fosse un disco connesso direttamente.

Attraverso il protocollo iscsi è possibile esportare anche partizioni o file system invece che dischi interi. L'importante è configurare correttamente il terminatore e, soprattutto, che il fs che stiamo esportando non siano montati sul sistema terminatore.

Nella prossima puntata il cluster.

domenico .-. www.mentularia.info