( san + mdadm + lvm ) <- rsync

Di seguito riporto una breve giornata di lavoro (ieri) in cui, interrotto continuamente dall'attivita' ordinaria, sono riuscito nel mio intento, quello di configurare lo storage di una macchina di backup e documentarlo in questo post.
La configurazione proposta e' corredata da un po' di comandi per ottenere un backup on line con snapshot giornalieri per una validita' settimanale.

La situazione di partenza prevede una lama di un Blade installata con GNU/Linux (distribuzione Ubuntu server 10.04, quindi LTS) collegata alla SAN via fiber channel con doppio path, SAN configurata con un chunk da 5.37 TB.

Non avrei necessita' di utilizzare l'utility mdadm poiche' il raid voluto l'ho definito direttamente dal gestore della SAN (ax4-5 gestito con il software Navisphere), in particolare ho impostato un raid 5 per i 5.37 TB, ma sono presenti due path per raggiungere lo storage.
Cio' equivale a vedere due dispositivi (sda e sdc) lato sistema, ma essi costituiscono semplicemente due percorsi diversi di uno stesso chunk di storage.
Il metodo primitivo e' eseguire un mount utilizzando uno dei due percorsi. Ma perche' decidere di utilizzarne uno in particolare? E' possibile utilizzarli entrambi e demandare al sistema di scegliere tramite politica ad-hoc quale di volta in volta utilizzare? O utilizzarne uno se l'altro cade? Nel caso manuale, se quello a cadere fosse quello utilizzato nel mount, avrei un fault con brutte conseguenze, nel caso di scelta del sistema il problema non sussiste poiche' sceglierebbe il percorso sano. :-) Chiaramente seguiamo la via elegante.

Ok, allora utilizziamo la tecnologia matura del multipath. Ci sono diversi modalita', io preferisco utilizzare l'utility mdadm con il seguente comando

mdadm --create /dev/md0 --level=multipath  --raid-devices=2 /dev/sda /dev/sdc

Purtroppo, dal comando sopra ottengo quanto segue:

> mdadm --create /dev/...

[..] open("/dev/mapper/mpath1", O_RDONLY|O_EXCL) = -1 EBUSY (Device or resource busy)
[...]

> 

Risorsa occupata?? Qualcuno mente.
Un rapidissimo giro e vedo dmsetup, in qualche modo l'antagonista di mdadm. Ok, ho un riscontro positivo e successivamente libero la risorsa con i seguenti comandi:

> dmsetup ls
> dmsetup remove_all

e poi nuovamente

mdadm --create /dev/md0 --level=multipath  --raid-devices=2 /dev/sda /dev/sdc

ma qui ottengo

> mdadm --create /dev/...

[..] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
[..]
[..] sd 0:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16).

La questione non quadra. Vado a consultare direttamente l'archivio della mailing list del software mdadm, discretamente attiva. Leggo un po' di questioni simili, ma tutti risolti in versioni precedenti a quella utilizzata da me (mdadm - v2.6.7.1).
In particolare, da questo thread

http://www.mail-archive.com/linux-raid@vger.kernel.org/msg03953.html

leggo come risposta

The amount of each component drive this is actually in use is stored -
in the default metadata - in a 32bit number as kilobytes.
This sets a limit of 4TB.

The version-1 metadata format has a 64bit field.

If you use mdadm 2.3, it will automatically select version-1 metadata
if you choose a size larger than 2TB (I think).

scritta da Neil Brown, proprio l'autore del software. Non scendendo nei dettagli, ma pensava male :-)
Nel senso che i metadata utilizzati di default non erano compatibili con la capacita' dello storage. Pero' ci ha fornito l'indizio per andare avanti e documentandosi un attimino sul superblocco (raid metadata)

mdadm --create /dev/md0  --metadata=1.0 --level=multipath  --raid-devices=2 /dev/sda /dev/sdc

si ottiene lo storage /dev/md0 voluto. Ripeto per chiarezza, /dev/md0 e' equivalente allo storage precedente (sda e sdc) raggiungibile con due path diversi in maniera trasparente per l'utente.

Ora veniamo alla questione del volume. Come accennavo precedentemente, e' necessario avere uno storage con un backup live e degli snapshot distanziati temporalmente un giorno per un totale di una settimana, quindi sette snapshot. Vediano ai comandi (la spiegazione generica la trovate facilmente googlando):

> pvcreate /dev/md0
> pvdisplay
  PV Name              /dev/md0
  VG Name             storage
  PV Size                5,37 TiB / not usable 1,99 MiB
  Allocatable           yes
  PE Size               4,00 MiB
  Total PE              1408547
  Free PE               77000
  Allocated PE       1331547
  PV UUID              beHZj3-hBTB-ySYQ-O4em-GFia-6aOA-IMIjbM

e poi

> vgcreate storage /dev/md0
> vgdisplay
  VG Name              storage
  System ID            
  Format                 lvm2
  [..]

e qui siamo sullo standard. Ora calcoliamo quando extent mi occorrono per gli snapshot. Ne ho disponibili 1408547 ciascuno da 4,00 MiB. Calcolo che per gli snapshot mi occorreranno un totale di 77000 extent (posseggo le statistiche di utilizzo nel server precedente ;-) ), quindi devo creare un volume logico di 1331547 extent. Procediamo:

> lvcreate -l 1331547 -nlast storage

> lvdisplay

  LV Name                /dev/storage/last
  VG Name               storage
  LV UUID                Mrk51R-DtwY-8b0K-zcyN-KwXq-NwHW-4ncucf
  LV Write Access    read/write
  LV Status              available
  # open                  0
  LV Size                  5,08 TiB
  Current LE             1331547
  [..]

in cui last indica l'ultimo snapshot. Guardiamo nuovamente il volume group

> vgdisplay
 VG Name               storage
  System ID            
  Format                lvm2
  Metadata Areas  1
  Metadata Sequence No  4
  VG Access          read/write
  VG Status           resizable
  MAX LV               0
  Cur LV                1
  Open LV              0
  Max PV               0
  Cur PV                1
  Act PV                1
  VG Size               5,37 TiB
  PE Size               4,00 MiB
  Total PE              1408547
  Alloc PE / Size       1331547 / 5,08 TiB
  Free  PE / Size       77000 / 300,78 GiB
  VG UUID               xU5lG2-kveU-2pNS-Qwvm-6ZSO-8kM8-upxXmB

Vediamo che mancano 77.000 extent da utilizzare che diviso 7 fa un totale di 11.000 extent per ciascuno snapshot.
Bene. Formattiamo il volume logico last:

> mkfs.ext4 -m1 /dev/storage/last

[...]

> mkdir -p /storage/last

> mount /dev/storage/last /storage/last

Per creare gli snapshot qualcosa del genere

> lvcreate --snapshot --permission r -l 11000 --name Tue /dev/storage/last

e montarli

> mkdir -p /storage/snapshot/Tue
> mount /dev/storage/Tue /storage/snapshots/Tue

Nelle precedenti righe ho scelto Tue perche e' martedi' (LANG=en /bin/date '+%a'). :-)
Per gli altri giorni e' analogo. Scrippettino per automatizzare tutto (non volete anche questo, vero?) e il gioco e' fatto. Chiaramente se esiste gia' lo snapshot (che e' quindi vecchio di una settimana), lo si cancella con il comando lvremove e lo si ricrea.

Per quanto riguarda l'oggetto del post abbiamo terminato, anzi quasi terminato,
Rimane il trasferimento del materiale. Il server vecchio ed il nuovo sono in lan. Bene. Riconfiguro /etc/rsyncd.conf, lancio il comando rsync sulla nuova e il trasferimento di 1.4 TB e' iniziato. mi lascia il tempo di scrivere questo post e... ci aggiorniamo per la tempistica.

Ok, siamo arrivati a meta', ma da subito ho notato che andiamo molto ma molto lenti. Verifico che il tratto e 1Gb/s (schede di rete a 1 Gb/s, switch a 1 Gb/s), ma andiamo lenti. Pero' mi sono ricordato che avevamo problemi di performance sul vecchio storage. Pazienza. Il collo di bottiglia non si puo' eliminare, ma fortunatamente lo storage sara' impiegato per altre funzioni. L'rsync corrente finira' in tarda serata, domani nuovo rsync, e poi spostero' la macchina in produzione.