RAID

RAID (Redundant Array of Independent Disks) è un sistema che utilizza un insieme di dischi rigidi per condividere o replicare le informazioni.

Rispetto all’uso di un singolo disco, i sistemi RAID introducono i seguenti benefici:

• aumento dell’integrità dei dati
• tolleranza ai guasti
• aumento delle prestazioni

Esistono 7 differenti schemi di organizzazione dei dischi denominati LIVELLI

RAID LEVEL 0 (striping)

Il sistema RAID 0 divide i dati in chunks di uguale dimensione, che vengono salvati su dischi fisici differenti secondo una coda round-robin (stripe).

RAID 0 non gestisce alcuna informazione di parità o ridondanza, pertanto la rottura di un sigolo disco compromette l’intero array

Utilizzi tipici:

Aumento delle performance e creazione di dischi virtuali di grandi dimensioni da un insieme di molti dischi più piccoli

Nota: in un sistema RAID 0 l’affidabilità complessiva decresce in maniera proporzionale al numero di elementi connessi

RAID LEVEL 1 (mirroring)

RAID 1 crea una copia esatta (mirror) di tutti i dati su due o più dischi. È utile nei casi in cui la ridondanza è più importante che usare tutti i dischi alla loro massima capacità

RAID 1 non gestisce alcuna informazione di parità

Utilizzi tipici:

Aumento dell’affidabilità mediante ridondanza dei dischi

Nota: in un sistema RAID 1 la dimensione massima sfruttabile è uguale a quella del disco più piccolo, inoltre si ha che la velocità di lettura è legata alle performace del disco più veloce e quella di scrittura al disco più lento

RAID LEVEL 5/6

RAID 5 utilizza una divisione dei dati a livello di blocco (chunk), con dati di parità distribuiti tra tutti i dischi.

I chunks di parità vengono calcolati sull’intera stripe, e ricalcolati ogni volta che cambia il singolo chunk

Il blocco di parità viene utilizzato esclusivamente quando la lettura di un chunk fallisce (CRC ERROR su disco)

Il RAID LEVEL 5 fornisce fault tolerance alla rottura di un solo disco, in quanto utilizza un unico blocco di parità

Nota: è possibile aumentare la tolleranza ai guasti implementando uno schema a 2 blocchi di parità (RAID LEVEL 6). Ulteriori blocchi di parità non sono utilizzati per ragioni di performance

Altri schemi RAID

Altri livelli di RAID, scarsamente implementati e di interesse più che altro teorico sono:

• RAID Level 2: divisione dei dati a livello di bit (e non di blocco) e controllo di parità con codice Hamming (è possibile correggere i dati). Il RAID Level 2 presuppone la sincronizzazione delle testine di lettura tra i singoli dischi dell’array
• RAID Level 3: divisione dei dati a livello di byte e gestione della parità su singolo disco (nessuna applicazione pratica)
• RAID Level 4: come il raid 3 ma utilizza blocchi invece che byte, permettendo lettura simultanea da dischi differenti dell’array
• RAID Level 7: (marchio registrato) aggiunge una cache ad array di tipo Level 3 o Level 4

Schemi misti (annidati)

Alcune implementazioni RAID permettono l’annidamento di array, ovvero l’utilizzo di livelli RAID come base per la costruzione di strutture più complesse.

Esempi:

• RAID 0+1: mirror tra 2 array Level 0 (striped)
• RAID 1+0 (o RAID 10): stripe tra n array Level 1 (mirrored)

  
                RAID1                                   RAID0
                  |                                       |  
         /-----------------\                /-------------------...-----\
         |                 |                |             |             |
       RAID 0            RAID 0           RAID1        RAID1    ...   RAID1
   /-----------\     /-----------\       /-----\      /-----\      
   |     |     |     |     |     |       |     |      |     |      
  120GB 120GB 120GB 120GB 120GB 120GB   120GB 120GB  120GB 120GB  
  

Implementazioni RAID

I sistemi RAID possono essere implementati sia in Hardware che in Software:

• i RAID hardware sono più performanti in quanto gestiscono code, scheduling e calcolo della parità su chip dedicati

• questo tipo di soluzione è comunque più costosa e legata a controller e dischi specifici
  
  

• le implementazioni in software sono in generale più economiche e maggiormente scalabili (utilizzano normali controller)

• soffrono tuttavia di cali prestazionali (soprattutto in schemi più complessi come il RAID5), aumentando il carico sulla CPU

RAID software in Linux

RAID è presente in Linux fin dal kernel 2.4.

L’implementazione attuale prevede una componente in kernel space ( driver raidX ) ed un tool ( mdadm ) in user space che comunica con i moduli del kernel

È possibile verificare il supporto del proprio sistema a RAID, controllando l’esistenza del file /proc/mdstat

Linux supporta l’assemblaggio di array RAID basati su interi dischi o partizioni

User space RAID tools

La gestione dei RAID software su GNU/Linux è sovraintesa dal comando mdadm

La sintassi base del comando è la seguente:

mdadm [modalità] array [opzioni] devices

Modalità principali:

• create: creazione di un array
• assemble: riassemblamento di un array precedentemente stoppato
• manage (modo implicito): gestione di un array. Questo modo è il default del tool, e può essere omesso sulla linea di comando
• monitor: monitoring degli array e notifiche via e-mail

Esempi mdadm

Creazione array RAID1

mdadm --create /dev/md0 --level=raid1 --raid-devices=2 /dev/sdb1 /dev/sdc1
cat /proc/mdstat

Gestione dei dischi dell’array

mdadm /dev/md0 --fail /dev/sdc1
mdadm /dev/md0 --remove /dev/sdc1
mdadm /dev/md0 --add /dev/sdc1

Shutdown/riavvio di un array

mdadm --stop 
mdadm --assemble /dev/md0 -s

Cancellazione superblock

mdadm --zero /dev/sdb1

Configurare mdadm

La configurazione di mdadm è mantenuta nel file /etc/mdadm/mdadm.conf. Il file deve contenere:

• opzioni generali
• indirizzo e-mail a cui inviare i messaggi in monitoring mode
• array presenti sul sistema

Per permettere al kernel di avviare gli array RAID in fase di boot (initramfs), è necessario dunque modificare questo file e rigenerare l’immagine initram:

  mdadm --examine -s >> /etc/mdadm/mdadm.conf
  update-initramfs -u

LVM

LVM (Logical Volume Manager) è un sistema che permette di gestire lo spazio disco ad un livello di astrazione superiore rispetto al classico modello dischi/partizioni

Le funzionalità tipiche di un LVM sono:

• resize e spostamento di filesystem su dischi differenti
• aggiunta a caldo di spazio disco addizionale (se presente hotplug)
• gestione dello storage mediante label (e non device name)
• hot-snapshots mediante meccanismi di copy-on-write o branching (ro/rw)

Linux LVM

GNU/Linux offre una implementazione di LVM fin dal 1998 (LVM1)

Nel 2002 è iniziata una completa riscrittura dell’intero LVM (LVM2), che ha portato maggiore stabilità e alcune nuove funzionalità. Questa implementazione mantiene comunque la retrocompatibilità con il vecchio sistema

LVM2 (l’implementazione Linux) è costituito da tre componenti:

• funzionalità di device-mapping nel kernel
• supporto al device-mapper in user-space (via libdevmapper e dmsetup)
• tool di gestione in user-space (LVM2 tools)

Architettura LVM (1/2)

Terminologia:

• Volume groups: il livello di astrazione più alto nella gestione dello storage. Unisce volumi fisici e logici in un’unica entità
• Physical volumes: spazio disco fisico (generalmente dischi o partizioni, ma anche RAID devices)
• Logical volumes: l’equivalente logico di una partizione in un sistema LVM. Un volume logico viene visto dal sistema come un block device, e deve contenere un FS

• Physical extent: in fase di creazione dei Volumre Groups, lo spazio disco viene suddiviso in chunks di eguale dimensione detti PE
• Logical extent: suddivisione in chunks dello spazio disco di un Logical Volume. La dimensione dei LE è sempre uguale a quella dei PE, ed è la stessa per tutti i volumi logici di un volume group

Getting it all together

Si supponga questio semplice scenario:

• Un unico volume group, denominato VG1
• VG1 gestisce due volumi fisici, /dev/sdb1 e /dev/sdc1 (PV1 e PV2), il cui spazio è suddiviso in chunks (PE) di 4Mb
• PV1 e PV2 hanno dimensione differente, e contengono, rispettivamente, 100 e 250 PE (400MB e 900MB)
• Nel creare un volume logico, dunque, si avranno a disposizione al max 350 PE, per una dimensione totale di 1300MB, che verranno mappati nei rispettivi LE

Mapping tra PE e LE

In fase di creazione dei volumi logici, viene definito il mapping tra PE e LE

L’amministratore ha a disposizione due semplici algoritmi di mapping:

• Linear mapping: similmente al RAID lineare (JBOD), LVM alloca i PE in ordine rispetto ai volumi fisici gestiti (rispetto all’esempio precedente, prima i 100 PE di PV1, e poi i restanti 250 di PV2)
• Striped mapping: come nel raid 0, il PE vengono interlacciati tra i volumi fisici in una coda round-robin

Preparazione volumi fisici

Prima di poter utilizzare dischi o partizioni con LVM, è necessario inizializzarli come physical volumes:

• pvcreate /dev/sdb
• pvcreate /dev/sdb1

• pvdisplay /dev/sdb1

Nota: è possibile inizializzare sia dischi che partizioni, ma è preferibile utilizzare le seconde, in quanto l’assenza di una partition-table sul disco potrebbe confondere altri SO.

LVM1 su architetture PC con partizioni DOS, necessita del partiton-ID 0x8e

Creazione volume group

La creazione di un volume group avviene mediante il comando vgcreate

In fase di creazione è possibile definire:

• dimensione dei PE (default 4MB)
• numero max di PVs gestibili
• numero max di LVs creabili

Sintassi base:

vgcreate [opzioni] vg_name PVs

Esempio:

vgcreate -s10 VG0 /dev/sdb1 /dev/sdc1

Gestione volume group

Attivazione/Disattivazione VG:

vgchange -a [y|n]

Rimozione VG (dopo disattivazione):

vgremove vg_name

Aggiunta PVs ad un VG:

vgextend vg_name PV

Rimozione PVs (solo se non ci sono PE allocati):

vgreduce vg_name PV

Gestione dei volumi logici

Creazione di un LV di 300M di nome test, con allocazione lineare, nel VG data:

• lvcreate -L300 -n test data

Creazione di un LV di 200 LE di nome test2, con striped mapping, nel VG data:

• lvcreate -l200 -i2 -n test2 data

Rimozione volumi logici

• umount /dev/data/test1
• lvremove /dev/data/test1

Ridimensionamento volumi logici

Per estendere un LV, ed il relativo FS contenuto, occorre procedere in tre passi:

• chiusura del LV (unmounting)
• espansione del LV
• espansione del FS contenuto

Nel dettaglio:

• umount /dev/data/test
• lvextend -L+200M /dev/data/test
• fsck -f /dev/data/test
• resize2fs /dev/data/test (solo per FS ext2/ext3)

Getting infos

Informazioni relative ai PVs: pvs / pvdisplay

Informazioni relative ai VGs: vgs / vgdisplay

Informazioni relative ai LVs: lgs / lvdisplay

Etckeeper

etckeeper è un piccola applicazione bash che consente di tenere in revisione i file di configurazione normalmente contenuti nella directory /etc di un sistema *nix

Per fare ciò, etckeeper fornisce un’interfaccia utente (in command line) ai sistemi di revisione distribuita (git, bzr, mercurial)

Why etckeeper?

Nel revisioning dei file di configurazione (a differenza dei file sorgente di un’applicazione) è di fondamentale importanza preservare non solo i permessi, ma anche utenti e gruppi, in caso contrario un ripristino di una revisione prececente potrebbe, in modo apparentemente inspiegabile, non funzionare come ci si aspetterebbe

Inoltre alcuni sistemi di revisione (come ad esempio git) non tengono in revisione le directory, per cui le directory vuote non sarebbero di fatto preservate

Etckeeper risolve questi problemi creando e mantenedo il file di metadati /etc/.etckeeper

Integrazione col sistema

Allo scopo di assolvere al meglio il compito di tenere in revisioning i file di configurazione etckeeper è in grado di agganciarsi agli hook di apt-get in modo tale da effettuare automaticamente dei commit prima e dopo l’installazione di nuovi pacchetti,

In questo modo vengono separati i commit delle modifiche provenienti dagli script di pre/post-installazione dai commit contenenti modifiche effettuate dall’amministratore

Installazione

Debian/Ubuntu contengono già etckeeper all’interno del loro pool di pacchetti per cui sarà sufficiente un semplice:

apt-get install etckeeper [git-core]

In ogni caso, poichè etckeeper è costituito esclusivamente da un insieme di bash script, l’installazione dai sorgenti è molto semplice e non prevede nessuna particolare build-dependency.

Nota: Le dipendenze di runtime sono solo bash ed uno dei sistemi di revisione distribuita supportati (bzr di default)

Configurazione

Sul sito web di etckeeper non è presente documentazione utile al suo utilizzo ma, essendo il tool concettualmente molto semplice, la sua pagina man risulta più che sufficiente per apprenderne il funzionamento

L’unico file di configurazione è il file /etc/etckeeper/etckeeper.conf mediante il quale è possibile configurare il sistema di revisione e il sistema di pacchettizzazione utilizzato dal sistema (attualmente solo dpkg e apt), oltre ad alcune variabili d’ambiente con cui è possibile modificare alcune delle opzioni utilizzate

QuickStart

Per inizializzare la cartella /etc possiamo procedere secondo questo schema:

• cd /etc
• etckeeper init
• git add .
• etckeeper commit “Commit Iniziale”
• git gc

Ovvero:

• ci posizioniamo nella cartella /etc
• diciamo ad etckeeper di crearsi tutti i file necessari per poter gestire /etc come repository git
• aggiungiamo ricorsivamente tutto il contenuto di /etc (in questo modo inseriremo anche la cartella .git)
• settiamo il punto di partenza
• facciamo pulizia del repository prima di iniziare

Commit manuale

Se apportiamo modifiche ai file di configurazione e vogliamo forzare un commit manuale possiamo procedere come segue:

root@hostname:/etc# $(facciamo qualunque modifica)
root@hostname:/etc# git commit 'Descrizione del commit'

Nota: qualsiasi modifica verra’ fatta in /etc dalla dis/installazione di un nuovo pacchetto, sarà comunque registrata da etckeeper grazie agli hooks presenti nei file di configurazione di apt

Utilizzo del tool

I 3 comandi principali di etckeeper (gli altri sono in realtà eseguiti dagli hook apt/dpkg o utilizzati internamente, come list-installed) sono:

• etckeeper init: inizializza la directory corrente come un nuovo repository etckeeper
• etckeeper unclean: ritorna 0 se ci sono modifiche di cui effettuare commit, != 0 in caso contrario
• etckeeper commit “commit message”: rigenera la mappa dei metadata ed effettua il commit di tutti i file modificati (anche quelli non ancora in revisione a meno che non ricadano nella lista degli ignore file del sistema di revisione sottostante)

Per tutte le altre funzionalità (log, status, diff, push/pull, merge) è necessario utilizzare direttamente il tool di revisione sottostante

Note

Differenza tra etckeeper commit e git commit:

• controllo di esistenza dei comandi necessari (git, hg, bzr)
• check del primo “git add .”
• controllo sulle directory vuote, che verrebbero rimosse automaticamente nel repo git
• controllo sul nome utente, sulla destinazione delle email di sistema e sul messaggio di commit

Ignore file:

• anche se un file è in ignore, il file dei metadata verrà comunque modificato ogni volta che cambieremo attributi/permessi e genererà di conseguenza un commit (contenente la modifica al file dei metadata)

Etckeeper’s hooks

Nella directory /etc/etckeeper sono contenute una serie di directory che rappresentano degli hook a cui è possibile agganciare ulteriori bash script:

root@godot:~# ls /etc/etckeeper/ -l

HackNote!!!: analizzando velocemente il funzionamento dello script principale è possibile verificare che tali directory corrispondono ai sottocomandi di etckeeper; pertanto per aggiungere un nuovo comando ad etckeeper è sufficiente creare una nuova directory con la medesima convenzione nella scelta del nome ed inserire al suo interno uno script bash che ne implementi la logica