Multipathing in Gentoo
1.
Introduzione
I servizi di multipath, tipicamente presenti negli ambienti enterprise,
forniscono uno strumento di memorizzazione dei dati in grado di garantire alte
prestazioni, bilanciamento di carico e tolleranza d'errore sia localmente che su
uno storage di rete (storage area network, SAN). Il multipath permette in
maniera trasparente di accedere ad un singolo dispositivo di storage da uno o
più percorsi. Per esempio, se fossero presenti due connessioni dall'HBA (Host
Bus Adapter, la scheda che interfaccia un host con una SAN) di un server a due
switch in fibra ottica e quindi ad una SAN, il modulo HBA durante il caricamento
effettuerebbe una scansione del bus e riconoscerebbe quattro percorsi
disponibili per la SAN: due percorsi per raggiungere lo switch ed altrettanti
dallo switch alla SAN. Sfruttando questa situazione, Multipath permette di
utilizzare ogni percorso contemporaneamente o indipendentemente, assicurando una
connessione costante ed affidabile ai dati nello storage. Nel momento in cui
viene a mancare un percorso, Multipath agisce da failover, rendendo i dati
critici sempre disponibili grazie alla ridondanza nella progettazione e nella
implementazione del sistema.
Nello stadio più elementare, Multipath si compone di due parti distinte:
device-mapper e multipath-tools. Device Mapper è il primo
elemento chiave dell'applicazione. Agli amministratori probabilmente
risulteranno familiari Device Mapper come LVM, EVMS, dm-crypt o, in questo caso,
Multipath. In breve, lavorando nel kernel space, il Device Mapper rimappa un
dispositivo a blocchi come /dev/sda (tutte le esportazioni delle
SAN risultano in qualche modo periferiche SCSI) in un altro dispositivo.
Entrando maggiormente nel dettaglio, Device Mapper crea un dispositivo a blocchi
virtuale che riconosce tutti i comandi di un dispositivo a blocchi regolare, ma
inoltra i dati al dispositivo a blocchi reali. Come anticipato, il processo di
rimappatura viene interamente gestito nello spazio kernel: nulla viene eseguito
nello spazio utente.
Multipath Tools comprende un insieme di applicazioni che lavorano in
spazio utente le quali interagiscono con il Device Mapper e creano le strutture
per gestire il device, implementando l'I/O attraverso più percorsi a livello di
sistema operativo. In un tipico ambiente SAN, saranno presenti più percorsi per
uno stesso dispositivo di storage: una scheda (o più) in fibra ottica che
collega il server ad uno switch, collegato a sua volta allo storage vero e
proprio (come lo scenario presentato precedentemente). In questo caso gli
amministratori potrebbero raggiungere lo stesso device da una a quattro volte in
base alle situazioni: ogni scheda vedrebbe la LUN (Logical Unit Number, un
numero che identifica partizioni differenti di un medesimo RAID set) due volte,
una per ogni percorso disponibile. Così, un singolo dispositivo potrebbe venire
riconosciuto come sda, sdb, sdc, e
sdd. Per esempio, se si volesse montare /dev/sda su
/san1, si andrebbe ad utilizzare solamente un percorso singolo
attraverso una scheda in fibra connessa ad uno switch e quindi ad una porta sul
dispositivo di storage stesso: se uno qualsiasi di questi tre punti fallisse, lo
storage device verrebbe perso e occorrerebbe smontarlo per sostituirlo con
un'altro device (sdb).
Di conseguenza, utilizzare solamente uno dei quattro percorsi disponibili non
risulta la soluzione ideale, soprattutto in ambienti enterprise. In questi casi,
la soluzione si ottiene combinando Multipath Tools e Device Mapper.
Quest'ultimo, come già spiegato, provvede a creare un dispositivo a blocchi
virtuali e quindi a passare le informazioni al dispositivi reale.
2.
Installazione e Configurazione
Installazione dei Multipath Tools
Anzitutto, è necessario emergere multipath-tools e sg3_utils.
Quindi è necessario individuare il wwid (World Wide Identification) del
disco: a tal fine è possibile utilizzare sg_vpd (fornito da
sg3_utils).
Codice 2.1: Installazione di multipath-tools e configurazione iniziale |
# emerge multipath-tools sg3_utils
# /usr/bin/sg_vpd --page=di /dev/DEVICE
|
Se DEVICE è il dispositivo scsi, il codice identificativo restituito inizierà
con 0x6. Sostituendo 0x con 3, si otterrà l'ID corretto da
inserire all'interno del multipath wwid in
/etc/multipath.conf. Informazioni più approfondite verranno
specificate nel prossimo capitolo.
Preparare Gentoo per il multipath
Per utilizzare multipath in Gentoo, occorre abilitare i seguenti parametri nel
kernel:
Codice 2.2: Aggiungere il supporto a multipath |
Device Drivers --->
SCSI device support --->
<*> SCSI target support
<*> SCSI disk support
[*] Probe all LUNs on each SCSI device
[*] Multiple devices driver support (RAID and LVM) --->
<*> Multipath I/O support
<*> Device mapper support
<*> Multipath target
)
<*> EMC CX/AX multipath support
<*> LSI/Engenio RDAC multipath support
<*> HP MSA multipath support
|
Nota:
Lo scsi_id viene generato dai dispositivi. I drive IDE hanno due
tipologie di connessione: un amministratore ha la possibilità di impostare un
dispositivo come master e un altro come slave oppure lasciarlo decidere al
sistema modificando i ponticelli. scsi_id si comporta in modo simile: ogni drive
o Logical Unit Number (LUN) contiene un id univoco da 0 a 254. Un dispositivo
con ID 0 verrà identificato prima di un dispositivo con -per esempio- ID 120,
dal momento che il sistema effettua una scansione del bus per individuare quali
device rispondono (LIP) in maniera incrementale partendo da zero.
|
All'interno del menù di configurazione del kernel, ci si assicuri di impostare
il parametro CONFIG_SCSI_MULTI_LUN=y per dare al sottosistema SCSI l'abilità di
testare tutte le LUN (raccomandato nelle situazioni in cui ci si trova ad avere
un dispositivo con ID 0 e 2 ma nessun 1: semplicemente si
troverebbe il device con ID 0 ma non quello con 2). Si verifichi
inoltre di aver abilitato tutti i device hardware necessari per il sistema SCSI,
come le schede QLogic 2400, che non si trovano nel settore dei driver SCESI di
basso livello.
Per apprendere meglio quanto detto, si considerino i seguenti scenari:
Prendiamo ad esempio un sistema con tre dispositivi con ID 0,1 e 2. Senza
l'opzione "probe all LUNs", ritroveremmo gli ID 0,1,2 come sda,sdb,sdc: tutti
i dispositivi verrebbero correttamente riconosciuti. A questo punto eliminando
il drive con ID 1, quelli con ID 0 e 2 dovrebbero continuare ad essere visibili:
sarebbe logico pensare che adesso siano visibili sda ed sdb (sdc dovrebbe
essersi spostato su sdb, dal momento che non è più presente il dispositivo
precedente). A questo punto ci si potrebbe trovare in una delle seguenti
situazioni:
Scenario 1: Senza aver impostato l'opzione "probe all LUNs", all'avvio della
scansione verrebbe riconosciuto il dispositivo con ID 0 ed assegnato al disco
sda: a questo punto non individuando nessun dispositivo con ID 1, la scansione
verrebbe terminata e considerata completa sebbene ci sia un device con ID 2 o
superiore.
Scenario 2: Con l'opzione "probe all LUNs" impostata, all'avvio della scansione
verrebbe nuovamente individuato il dispositivo ID 0 ed assegnato al dispositivo
sda. A questo punto però la ricerca procederebbe con l'ID 1 (non presente) ma
- a differenza dallo scenario precedente - proseguirebbe alla ricerca di altri
dispositivi, assegnando la lun 2 al dispositivo sdb. La scansione verrebbe
considerata conclusa solo se non si riuscisse ad individuare nessun altro
dispositivo con ID superiore.
Nota:
Sebbene possa sembrare irrealistico o anche non necessario avere device
distanziati tra loro da multe LUN, per ricoprire il più ampio ventaglio di
possibilità è preferibile effettuare una scansione completa di tutte le LUN. Un
amministratore potrebbe avere le più svariate ragioni per implementare una
simile configurazione. Pertanto, il secondo scenario presentato risulterebbe
ottimale per assicurare che tutti i dispositivi vengano riconosciuti ed
assegnati durante il processo di configurazione di multipath.
|
Dopo aver testato tutte le LUN, tutti i dispositivi sono stati riconosciuti ed
assegnati ad un ID di Multipath.
3.
Uno sguardo all'architettura
Essendo parte di Multipath Tools, i dispositivi menzionati precedentemente
verranno riuniti in gruppi. Dopo aver configurato ed avviato
multipath-tools tramite il comando /etc/init.d/multipath start,
sarà possibile elencare i gruppi di dispositivi tramite multipath -l.
Il risultato ottenuto sarà simile al seguente:
Codice 3.1: output di multipath -l |
EVA_SAN (3600508b4001044ee00013000031e0000)
[size=300 GB][features="1 queue_if_no_path"][hwhandler="0"]
\_ round-robin 0 [active]
\_ 0:0:0:1 sda 8:0 [active]
\_ round-robin 0 [enabled]
\_ 0:0:1:1 sdb 8:16 [active]
EVA_SAN2 (3600508b4001044ee0001300003880000)
[size=300 GB][features="1 queue_if_no_path"][hwhandler="0"]
\_ round-robin 0 [active]
\_ 0:0:0:2 sdc 8:32 [active]
\_ round-robin 0 [enabled]
\_ 0:0:1:2 sdd 8:48 [active]
|
Come impostazione predefinita, verrà preso in considerazione il primo gruppo
disponibile (per esempio il primo round-robin per il san
EVA_SAN2,sdc). In questa specifica situazione, dal momento che è
stato impostato una politica round-robin, i due percorsi verranno utilizzati
alternativamente; tuttavia nel momento in cui uno dei due percorsi fallisse,
tutte le informazioni verrebbero inviate tramite l'altro percorso ed il
dispositivo continuerebbe ad essere disponibile. Solamente se tutti i percorsi
al device fallissero contemporaneamente, il dispositivo risulterebbe
irraggiungibile e si dovrebbe usufruire del gruppo secondario.
Una configurazione tipica
Vediamo ora un esempio di una tipica configurazione di multipath:
Codice 3.2: Un tipico /etc/multipath.conf |
defaults {
udev_dir /dev
polling_interval 15
selector "round-robin 0"
path_grouping_policy group_by_prio
failback 5
path_checker tur
prio_callout "/sbin/mpath_prio_tpc /dev/%n"
rr_min_io 100
rr_weight uniform
no_path_retry queue
user_friendly_names yes
}
blacklist {
devnode cciss
devnode fd
devnode hd
devnode md
devnode sr
devnode scd
devnode st
devnode ram
devnode raw
devnode loop
devnode sda
}
multipaths {
multipath {
wwid
alias DB_SAN
}
devices {
device {
"IBM "
"1815 FAStT "
}
}
}
|
Importante:
Per quanto riguarda le proprie periferiche, è opportuno utilizzare cat
/sys/block/sd(device)/device/model e cat
/sys/block/device/sd(device)/device/vendor per popolare
direttamente la sezione corretta del file di configurazione escludendo errori
di battitura: in determinati casi, gli spazi bianchi potrebbero risultare non
visibili. Questa sezione è necessaria dal momento che non tutte le stringhe
identificative dei vendor rispettano le convenzioni del kernel, e di
conseguenza, non sempre vengono riconosciute correttamente.
|
Una configurazione tipica di multipath che utilizza un EVA_SAN riconosciuto
correttamente dal kernel, potrebbe essere simile alla seguente:
Codice 3.3: Configurazione di EVA_SAN |
multipaths {
multipath {
wwid 3600508b4001044ee00013000031e0000
alias EVA_SAN
}
multipath {
wwid 3600508b4001044ee0001300003880000
alias EVA_SAN2
}
}
|
4.
Configurare il proprio sistema
La configurazione di multipath è abbastanza semplice da realizzare dal momento
che l'unico file su cui occorre intervenire è /etc/multipath.conf.
Anzitutto, occorre impostare nel parametro polling interview la frequenza
(in secondi) con cui verrà effettuato un controllo per assicurarsi che il
percorso sia disponibile.
selector andrà impostato su "round-robin 0".
Nota:
Il settore round-robin sarà l'unico utilizzato in questa configurazione.
|
prio_callout: questo parametro è abbastanza importante. Sono disponibili
numerose differenti priorità adatte ai differenti dispositivi, come ad esempio:
- mpath_prio_alua
- mpath_prio_emc
- mpath_prio_hds_modular
- mpath_prio_netapp
- mpath_prio_tpc
Nota:
Per la maggior parte delle configurazioni, mpath_prio_tpc sarà la
soluzione migliore. Altri dispositivi come mpath_prio_netapp offrono
funzionalità particolari come il raggruppamento per priorità, come netapps.
|
path_grouping_policy possiede alcune possibili opzioni: failover,
multibus, group_by_prio. Failover manterrà solamente un disco per ogni
gruppo di priorità. Multibus inserirà tutti i dispositivi in un gruppo.
Group_by_prio utilizza un "valore di priorità": percorsi con stesso
valore vengono raggruppati insieme. Tali valori vengono determinati alla
chiamata del programma.
no_path_retry è impostato a queue perchè nella maggior parte delle
situazioni in caso di fallimento di un percorso, si preferisce non inviare i
dati del tutto. Così, in presenza di un fallimento, il sistema operativo metterà
le operazioni di I/O in coda finchè il dispositivo non ritornerà ad essere
disponibile; a quel punto verrà inviato nuovamente l'intero blocco di dati. In
se al proprio traffico, questo comportamento può provocare problemi di
sovraccarico.
rr_min_io è il numero di operazioni che il sistema operativo deve
effettuare per ogni percorso prima di passare al successivo percorso all'interno
dello stesso gruppo. Se sda ed sdb fossero nello
stesso gruppo, rr_min_io permetterebbe di fare 100 operazioni di I/O su
sda e quindi 100 su sdb, continuando a passare da uno
all'altro. Questa impostazione va perfezionata e personalizzata su ogni istanza
per massimizzare le prestazioni dal momento che il carico delle operazioni di
I/O cambiano molto in base alle situazioni. Il valore predefinito è 1000,
ma in alcune circostanze è preferibile un valore minore in modo da cambiare
porte più spesso, quando possibile.
user_friendly_names rende più facile individuare le periferiche con cui
si sta lavorando. In questo esempio, impostando user_friendly_names a no,
la SAN sarà identificata tramite il suo WWID piuttosto che EVA_SAN.
I contenuti di questo documento sono rilasciati sotto la licenza Creative
Commons - Attribution / Share Alike.
|