Gentoo Logo

Multipathing in Gentoo

Indice:

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
(Si sostituisca /dev/DEVICE con il proprio disco per identificare il suo wwid)
# /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
        (Si selezioni il/i proprio/i dispositivo/i dall'elenco))
    <*>      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
(Per individuare il proprio wwid, si utilizzi /usr/bin/sg_vpd --page=di /dev/DEVICE.
L'indirizzo dovrebbe iniziare con il prefisso 0x6: si rimuovano i primi due caratteri 0x e li si sostituisca con 3.)
alias DB_SAN
}
devices {
device {
(Gli spazi bianchi sono importanti in questi elementi per ottenere una
esatta corrispondenza con le specifiche dei vendor.)
"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.



Stampa

Aggiornato il 7 febbraio 2011

La versione originale di questo documento non è più mantenuta

Oggetto: Questo documento illustra come configurare un servizio multipath per lo storage dei dati.

Joshua Jackson
Autore

Matthew Summers
Autore

Richard Anderson
Autore

Steve Rucker
Autore

Joshua Saddler
Redazione

Andrea Venino
Traduzione

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.