Link Aggregation - Istituto Nazionale di Fisica Nucleare

Transcript

Università degli Studi di Genova
Facoltà di Scienze Matematiche Fisiche e Naturali
Corso di Laurea in
Informatica
Analisi di funzionalità e
prestazioni del protocollo
802.3ad Link Aggregation su
infrastruttura di rete Gigabit
Ethernet
Tesi di Laurea di
Alessandro Solimando
Relatore:
Prof. Alessandro Brunengo
Anno Accademico 2007/2008
Indice
Introduzione
v
1 Analisi e comprensione della topologia della rete in esame
1
1.1
. . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1
I dischi . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.2
I disk-server . . . . . . . . . . . . . . . . . . . . . . . .
3
La rete locale . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.1
Gli host . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.2
Switch e Router . . . . . . . . . . . . . . . . . . . . . .
4
2 Test sul corretto funzionamento della rete allo stato attuale
5
1.2
2.1
2.2
Il sistema di storage
Introduzione agli strumenti utilizzati per la misura delle prestazioni: netperf e dstat . . . . . . . . . . . . . . . . . . . . .
5
Validazione strumenti di misurazione . . . . . . . . . . . . . .
6
3 Descrizione e configurazione dello switch BlackDiamond 8800
8
3.1
Approfondimento sulle VLAN . . . . . . . . . . . . . . . . . .
3.2
Gestione e configurazione dello switch per il Bonding . . . . . 10
4 Configurazione degli host per il Bonding
4.1
8
16
Caricamento e configurazione del modulo del kernel . . . . . . 16
Indice
ii
4.1.1
/etc/modprobe.conf . . . . . . . . . . . . . . . . . . . . 16
4.2
Definizione dell’interfaccia di rete per il Bonding: bond0 . . . 17
4.3
Riconfigurazione delle interfacce di rete eth0 ed eth1
4.3.1
. . . . . 18
Monitoraggio delle impostazioni del modulo . . . . . . 20
5 Test di performance con diverse configurazioni del Bonding 22
5.1
5.2
Traffico in direzione della macchina in bonding (farm06) . . . 23
5.1.1
Static L2 . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.2
Static L3 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.3
LACP L2 ed L3 . . . . . . . . . . . . . . . . . . . . . . 28
Traffico in uscita dalla macchina in bonding (farm06) . . . . . 29
5.2.1
Mode = xor balancing (Statico) con xmit hash policy
= 0 (L2) . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.2
Mode = xor balancing (Statico) con xmit hash policy
= 1 (L3+L4) . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.3
Mode = 802.3ad (LACP) con xmit hash policy = 0
(L2) e Mode = 802.3ad (LACP) con xmit hash policy
= 1 (L3+L4) . . . . . . . . . . . . . . . . . . . . . . . 31
5.3
Test di tolleranza alla disconnessione fisica di un link . . . . . 34
5.4
Considerazioni conclusive sulla scelta del protocollo per il bonding 36
6 Prestazioni della infrastruttura di produzione
39
6.1
Dettaglio della infrastruttura di storage . . . . . . . . . . . . . 39
6.2
File system GPFS . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.1
Accesso al file system . . . . . . . . . . . . . . . . . . . 41
6.3
Valutazione del sistema in produzione . . . . . . . . . . . . . . 41
6.4
Confronto di performance dei disk-server e dei file system . . . 42
6.4.1
Prestazioni in scrittura . . . . . . . . . . . . . . . . . . 42
Indice
iii
6.5
Analisi in lettura . . . . . . . . . . . . . . . . . . . . . . . . . 44
7 Analisi dell’utilizzo dei dischi gestiti dai disk-server
46
7.1
Definizione del layout per i test . . . . . . . . . . . . . . . . . 47
7.2
Test su borex1 dev . . . . . . . . . . . . . . . . . . . . . . . . 48
7.3
Test su farm1 dev . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.4
Test con doppio accesso . . . . . . . . . . . . . . . . . . . . . 52
7.5
Test su farm1 dev con stesso file . . . . . . . . . . . . . . . . . 53
7.6
Considerazioni sui test con accesso al disco . . . . . . . . . . . 57
8 Conclusioni
58
8.1
Algoritmo di smistamento . . . . . . . . . . . . . . . . . . . . 58
8.2
Protocollo di gestione delle interfacce . . . . . . . . . . . . . . 58
8.3
Sistema di monitoraggio delle interfacce . . . . . . . . . . . . . 59
8.4
Test sugli host farm
8.5
Test sull’infrastruttura in produzione . . . . . . . . . . . . . . 59
8.6
Valutazione conclusiva . . . . . . . . . . . . . . . . . . . . . . 60
. . . . . . . . . . . . . . . . . . . . . . . 59
A RAID
61
B Approfondimento su alcune tipologie di test di netperf
64
C Dettaglio sui parametri del modulo
66
D Riepilogo per la scelta della modalità di bonding
74
Bibliografia
77
. . . una dedica
Introduzione
La rete locale del Centro Calcolo della sezione di Genova dell’INFN1 è
prevalentemente costituita da una infrastruttura Ethernet commutata, ed
utilizza un backbone in Gigabit Ethernet che permette velocità non superiori ad 1 Gbps.
Nuove applicazioni di prossima attivazione, in particolare quelle legate alla
analisi dati degli esperimenti in fase di attivazione sull’acceleratore LHC2
del CERN3 di Ginevra, presentano esigenze di banda di accesso ai dati che
sicuramente eccederanno tale limite.
La naturale evoluzione della rete è orientata verso la realizzazione di un’infrastruttura a 10 Gigabit Ethernet, il cui costo però è ancora elevato.
Una soluzione alternativa può essere il link aggregation, conosciuto anche
come port trunking o bonding, che consiste nel definire una interfaccia di rete virtuale corrispondente alla aggregazione di due o più interfacce fisiche.
Questa tecnica permette di utilizzare le interfacce fisiche come se fossero una
singola interfaccia di rete, con una capacità trasmissiva pari alla somma delle
interfacce aggregate.
Il basso costo di schede Gigabit Ethernet, anche in considerazione che i server
attuali già dispongono di due interfacce di rete integrate sulla scheda madre,
permetterebbe di incrementare la banda verso i server di disco a costi molto
1
Istituto Nazionale di Fisica Nucleare
Large Hadron Collider
3
Conseil Européen pour la Recherche Nucléaire
2
Introduzione
vi
contenuti.
Le caratteristiche del link aggregation offrono inoltre funzionalità interessanti come il bilanciamento del traffico tra le interfacce aggregate ed il failover
su eventuali guasti alle singole connessioni.
Il presente lavoro è finalizzato a testare le diverse configurazioni disponibili
per il bonding e valutarne le funzionalità di failover e di prestazioni, dapprima con test memory-to-memory, poi con reali accessi al sistema di storage
della infrastruttura in produzione.
Capitolo 1
Analisi e comprensione della
topologia della rete in esame
1.1
Il sistema di storage
Lo storage disponibile nella infrastruttura in produzione consiste di svariate decine di terabyte di spazio disco resi disponibili da controller Raid, ed
esportati tramite diversi disk server.
La complessità dello storage ed esigenze di affidabilità e flessibilità di gestione hanno richiesto l’utilizzo di una SAN (Storage Area Network ), cioè di una
rete di tipo switched dedicata allo storage, in tecnologia Fibre Channel [1]
per la connessione server-disco.
1.1.1
I dischi
La maggior parte dei dischi sono di tipo SATA, organizzati in batterie,
ognuna servita da un doppio controller Raid per motivi di ridondanza.
I dischi sono aggregati in volumi gestiti tramite RAID 1 di livello 5 e 6, in
gruppi di 4 o 8 più i dischi di ridondanza.
L’organizzazione mediante RAID ha imposto, per ogni volume oggetto di test,
1
Per un approfondimento sui diversi sistemi RAID consultare l’Appendice A a
pagina 61.
Capitolo 1. Analisi e comprensione della topologia della rete in esame
Figura 1.1: Rete di studio
2
3
un’indagine riguardo la block-size e relativa stripe-size in quanto costituiscono
fattori che hanno impatto sulle prestazioni di I/O.
1.1.2
I disk-server
Tutta l’infrastruttura di calcolo è costituita da calcolatori su cui è installato il sistema operativo Linux, nelle distribuzioni SLC4 [2] e SL5 [3]. Lo
stesso sistema è installato sui diversi disk server che esportano i volumi.
Tutti i server sono biprocessori Intel o AMD, dual o quad core, dotati di 4 o
8 GB di RAM, e forniti di una interfaccia di rete Gigabit Ethernet operativa
e di una seconda interfaccia di rete identica alla prima ma inattiva, oltre ad
una scheda Fibre Channel dual head per la connessione alla SAN.
Per motivi di prestazioni e di flessibilità i volumi sono esportati tramite il file
system di rete distribuito e parallelo GPFS (General Parallel File System),
un file system proprietario IBM ideato appositamente per gestire accessi concorrenti e volumi distribuiti [4]. La coerenza dei dati e il locking sui file sono
gestiti tramite demoni che girano sia sui disk-server che sui client; questi demoni sono in comunicazione fra loro, ed in grado di sincronizzare le proprie
informazioni (riguardanti i dati, metadati e i lock sulle porzioni del file system) in modo da garantire la consistenza del file system anche in occasione
di accessi concomitanti ai suoi volumi.
1.2
1.2.1
La rete locale
Gli host
La farm è attualmente costituita da circa 50 nodi di calcolo biprocessori
Intel o AMD a 32 o 64 bit, dual o quad core e sia i server che i client fanno
uso del Sistema Operativo Scientific Linux CERN 4. I nodi di calcolo sono
4
suddivisi per architettura e per gruppo sperimentale di proprietà, ma la configurazione utilizza un meccanismo di condivisione delle risorse che permette
agli utenti di utilizzare tutta la potenza di calcolo disponibile anche se non
di proprietà.
1.2.2
Switch e Router
Nella rete locale sono presenti uno switch di core Extreme Networks Black
Diamond 8800, dotato di 112 interfacce di rete Gigabit Ethernet in rame o
fibra ottica, per l’interconnessione delle macchine (sia per quanto riguarda
i nodi di calcolo che i disk-server) e che svolge anche funzioni di routing
interno tra le reti IP locali, ed un router per la connessione geografica verso
l’esterno della rete locale INFN. Sia i client che i server sono collegati allo
switch mediante interfacce di rete Gigabit-Ethernet.
La LAN, date le dimensioni non trascurabili, è partizionata attraverso il
meccanismo delle VLAN per evitare la replicazione di parte dell’hardware.
Le VLAN, necessarie a capire l’organizzazione della rete di studio, saranno
trattate in maggior dettaglio alla sezione 3.1 a pagina 8.
Capitolo 2
Test sul corretto funzionamento
della rete allo stato attuale
2.1
Introduzione agli strumenti utilizzati per
la misura delle prestazioni: netperf e dstat
Netperf [6] è un’applicazione di pubblico dominio sviluppata da Hewlett
Packard per effettuare misurazioni sulle capacità di trasmissione e ricezione fra due macchine collegate. È composto da una componente
client (netperf ) e da una server (netserver ) che dialogano generando
flussi di traffico controllati in modo da calcolare la capacità trasmissiva
della singola connessione. Il server è un demone che resta in ascolto
su una porta TCP che può essere scelta tramite il parametro “-p”. Il
client è un applicativo interattivo al quale bisogna specificare il nome
del server e la porta TCP su cui aprire la comunicazione, il tempo di
durata ed il tipo di test.
Le tipologie di test utilizzate per questi test di controllo sono state TCP STREAM e UDP STREAM, i quali generano rispettivamente
traffico TCP e UDP in direzione della macchina su cui è in ascolto
Capitolo 2. Test sul corretto funzionamento della rete allo stato attuale 6
netserver. In alcuni casi si è anche fatto ricorso a TCP MAERTS, analogo a TCP STREAM ma con il flusso dati in senso contrario, ovvero
generato dal server in direzione del client.
Alcune tra le rimanenti tipologie di test sono state riportate in appendice B.
Dstat [7] è un tool che, leggendo opportuni contatori del kernel Linux tramite il file system /proc, è in grado di mostrare statistiche riguardanti
la macchina su cui è in esecuzione, fornendo diversi dati fra i quali l’utilizzo di CPU, della rete e dell’accesso al disco. La capacità di separare
i contatori delle singole interfacce di rete o relativi ai singoli volumi di
storage ne fa lo strumento ideale per la nostra sperimentazione.
2.2
Validazione strumenti di misurazione
Questi test iniziali sono stati realizzati senza configurazione di bonding
allo scopo di verificare il corretto rilevamento dei dati da parte dei programmi utilizzati e il corretto funzionamento delle interfacce di rete e dei cavi di
collegamento, nonché dello switch di core che le collega.
I test unidirezionali sono avvenuti fra le 4 macchine prese in esame, rispettivamente farm06, farm07, farm08 e farm09. Le misurazioni sono state effettuate
a partire da ciascuna delle quattro macchine verso le altre 3, sia per quanto
riguarda il protocollo TCP che per l’UDP, generando traffico con netperf e
confrontando i dati di questo programma con quelli forniti in output dalle
istanze di dstat (una per ogni macchina interessata dal singolo test). Durante
i test con entrambi i protocolli si sono raggiunti stabilmente i 118 MB/s, cor-
Capitolo 2. Test sul corretto funzionamento della rete allo stato attuale 7
rispondenti a circa 944 Mbps, su tutte le coppie di connessione tra le quattro
macchine.
Il risultato è ragionevole tenendo conto che il mancato raggiungimento del
limite teorico di 125 MB/s è da imputare al limite intrinseco delle interfacce
di rete e dei protocolli utilizzati (gestione degli interrupt, separazione dei
frame, gestione delle connessioni).
Capitolo 3
Descrizione e configurazione
dello switch BlackDiamond
8800
3.1
Approfondimento sulle VLAN
La gestione della rete in esame si basa fortemente sull’utilizzo delle VLAN
(Virtual Local Area Network), un’astrazione che permette la ripartizione logica di un’unica rete locale in una serie di reti virtualmente distinte tra loro
grazie ad una particolare etichettatura dei frame [8]. Ogni VLAN sarà identificata da un id univoco sulla rete, detto VLAN Tag o VLAN ID, che sarà
inserito utilizzando 4 byte aggiuntivi nell’header dei frame trasmessi.
Esistono diverse implementazioni di questa tecnologia, più o meno compatibilitra loro. Tuttavia è stato definito un protocollo standard per l’implementazione di tale tecnica, noto con la sigla IEEE 802.1Q. Tutti gli apparati
della rete locale di produzione supportano questo standard, cosı̀ come le più
recenti distribuzioni di linux utilizzate localmente.
Le singole porte degli switch della rete locale dovranno essere assegnate ad
una o più VLAN, cioè faranno parte di una o più reti virtuali, in modalità
tagged o untagged :
Capitolo 3. Descrizione e configurazione dello switch BlackDiamond 8800 9
• quando una porta è assegnata ad una VLAN in modalità tagged, i
frame appartenenti a quella VLAN in uscita sulla porta manterranno
la tag nell’header. Se la tag è assente, lo switch la inserirà prima di
trasmettere il frame;
quando arriva un frame con tag nell’header, cioè appartenente ad una
certa VLAN, attraverso una porta, questo frame sarà accettato solo se
quella porta è associata alla VLAN in modalità tagged.
• quando una porta è associata ad una VLAN in modalità untagged, un
frame appartenente a quella VLAN che debba essere trasmesso in uscita su quella porta verrà privato della tag prima di essere inviato;
in ingresso, un frame privo di tag verrà accettato ed assegnato automaticamente alla VLAN a cui la porta è associata in modalità untagged.
Questa tecnica permette agli switch di trattare correttamente i frame in
transito, evitando trasmissioni degli stessi verso rami non appartenenti alla
VLAN corretta. La modalità untagged permette agli stessi switch di trasmettere i frame privi di tag verso porzioni di rete (switch o host) che non
sarebbero in grado di identificare correttamente l’header esteso contenente la
TAG della VLAN.
Sostanzialmente due VLAN differenti si comportano come se fossero due reti
locali distinte, ed il transito di dati da una all’altra richiede la presenza di
un apparato di routing che possa fare il forward del pacchetto attraverso il
confine tra le VLAN.
Il principale vantaggio di questa tecnica stà nel fatto di poter separare in più
reti virtualmente distinte gli apparati connessi alla stessa rete locale fisica,
per motivi di sicurezza, di management o semplicemente per limitare il flusso
di messaggi broadcast sempre presenti su una rete locale alle sole porzioni
della rete di interesse, migliorando la prestazione globale della rete.
Capitolo 3. Descrizione e configurazione dello switch BlackDiamond 880010
La rete su cui è stata svolta la sperimentazione è suddivisa in diverse reti
virtuali, di cui le principali sono dedicate a diversi gruppi sperimentali ed
una dedicata ai server di calcolo ed ai server di disco. Queste reti interne
sono connesse a livello 3 (cioè a livello di routing) dal core switch, che quindi
opera non solo come switch vero e proprio ma anche come router.
3.2
Gestione e configurazione dello switch per
il Bonding
Lo switch a cui sono collegate le 4 macchine di test (farm06, farm 07,
farm08, farm09) e i disk-server è un BlackDiamond 8800 della Extreme Networks, switch modulare a 10 slot configurato attualmente con due schede di
rete di management e due schede di switching a 48 porte in Gigabit-Ethernet
in rame.
Lo switch supporta il Link Aggregation con diverse politiche di smistamento del traffico sulle diverse porte appartenenti al LAG (Link Aggregation
Group), la porta logica che le rappresenta, il corrispettivo dell’interfaccia logica per il bonding su un host.
Le porte appartententi ad un singolo LAG devono avere la stessa velocità
e i diversi LAG devono avere insiemi a intersezione nulla fra loro.
L’ExtremeWare XOS 11.3, il Sistema Operativo presente sullo switch, supporta il Link Aggregation tra porte posizionate su schede diverse, in modo
da poter garantire maggior robustezza anche contro il malfunzionamento di
un intero modulo.
Nel caso di utilizzo delle VLAN, queste vedranno il LAG come un’unica
porta virtuale, detta master port, definita al momento della creazione del
LAG stesso. Inserire una porta in un LAG avrà come side-effect la sua eliminazione da tutte le VLAN in cui era stata precedentemente configurata, ciò
perché, a livello logico, quella porta non può essere più referenziata direttamente nel VLAN database1 , in quanto parte di una porta logica, il LAG. La
porta aggiunta verrà automaticamente inserita nelle VLAN configurate per
il LAG.
Link Aggregation Statico e Dinamico:
La tecnica di aggregazione statica richiede che le porte appartenenti al
LAG siano predefinite e la cardinalità del loro insieme può variare solo diminuendo. Ciò avviene nel caso in cui un link perda connettività: in questo
caso il traffico, se possibile, viene ridistribuito ed eventualmente bilanciato
sulle rimanenti porte. In caso il link precedentemente fallito ritorni ad essere disponibile verrà reintegrato dinamicamente nel LAG. Questa modalità
non prevede però nessuna forma di dialogo con il device connesso alle porte
del LAG. Quest’ultimo deve essere configurato opportunamente per evitare
malfunzionamenti, anche gravi, sullo switch e sull’intera rete locale.
Il link aggregation dinamico, al contrario,permette di definire un insieme
di porte appartenenti al LAG in modo che solo una parte di esse venga utilizzato attivamente, mentre le altre rimangono in stato di standby, pronte a
subentrare al posto di link rilevati in fallimento. In questo modo, in occasione
di una failure, la capacità trasmissiva del LAG non diminuisce come nel caso
statico, ma viene mantenuta grazie alla attivazione delle porte in stand-by.
1
Ovvero il database utilizzato internamente dallo switch.
La modalità dinamica si basa sul LACP (Link Aggregation Control Protocol) che fa parte dello standard 802.3ad ed è utilizzabile solo se il dispositivo
remoto utilizza anch’esso questa modalità. La sincronizzazione con la controparte precede sempre l’invio di dati ed avviene per mezzo di uno scambio
di LACPDU (Link Aggregation Control Protocol Data Unit) che rappresentano dei frame di controllo definiti dal protocollo LACP.
Inizialmente tutte le porte del LAG sono in uno stato detto unselected e
non vengono utilizzate per l’invio di dati (ad esclusione dei LACPDU). In
seguito, dopo la sincronizzazione con il dispositivo remoto, verrà scelto il
sottoinsieme di porte aventi MAC address minore fra quelle correttamente
sincronizzate, le altre saranno messe in standby (mentre le porte non sincronizzate manterranno lo stato unselected). È eventualmente possibile definire
diversi criteri per la priorità nella scelta delle porte, che saranno anche utlizzati per scegliere il sostituto di una porta in fallimento fra quelle in standby.
È da notare che si avranno delle porte in standby se e solo se le porte selected
saranno in numero maggiore rispetto a quelle definite per il LAG.
Algoritmi di smistamento del traffico:
La scelta della porta fisica attraverso cui instradare un frame sul LAG
può essere effettuata in base a diversi algoritmi. Il firmware del core switch
permette di utilizzare due diversi algoritmi, sia nel caso statico che dinamico.
L’algoritmo con scelta in base all’indirizzo di livello 2 utilizza una funzione dipendente dai MAC address sorgente e destinazione, mentre quello di
livello 3 utilizzerà gli indirizzi IP. In caso sia scelto un algoritmo di livello 3
e arrivino pacchetti non IP verrà comunque utilizzato l’algoritmo basato sul
MAC address, che è anche la scelta di default.
Configurazione pratica dello switch:
1. Creazione di un LAG consistente in almeno una porta (la master-port):
enable sharing <port> grouping <port_list> {algorithm
[address-based {L2|L3}]} {lacp}
dove:
- <port> indica la master-port, in caso di switch modulare il formato sarà numeroModulo:numeroPorta. Va sottolineato che il LAG
prenderà come identificativo il nome della master-port.
- <port list> indica la lista delle porte del LAG, dove andrà specificata anche la master-port; si può anche specificare in modo compatto un range di porte contigue con il formato portaInizioRangeportaFineRange.
- algorithm indica l’algoritmo di smistamento dei frame.
- L2 (Layer 2) ed L3 (Layer 3) indicano se l’algoritmo address based
utilizzerà il MAC Address (indirizzo di Layer 2) o l’IP (indirizzo
Layer 3) per la scelta della porta su cui far uscire il frame.
- Il parametro opzionale lacp, invece, indica se utilizzare Link Aggregation Statico (default) o Dinamico (specificando lacp al fondo).
Per disabilitare un LAG si deve fare ricorso al seguente comando:
disable sharing <port>
dove <port> è la master-port definita per il LAG.
2. Aggiunta o rimozione di porte dal LAG:
configure sharing <port> add ports <port_list>
configure sharing <port> delete ports <port_list>
Vincoli generali:
• Il numero massimo di LAG configurabili sullo switch è pari a 32.
• Il tipo delle porte di un LAG può essere eterogeneo2 , ma devono tutte avere la stessa capacità trasmissiva. Qualora si utilizzasse un mix
di porte in fibra e rame è opportuno disabilitare su queste ultime
l’autonegoziazione della velocità.
• Le porte non devono essere necessariamente contigue e non devono per
forza appartenere allo stesso modulo.
Vincoli per la configurazione statica:
• Un LAG statico può essere costituito da al più 8 porte.
Vincoli per la configurazione dinamica:
• Il numero massimo di porte è pari a 16, di cui al più 8 utilizzate e 8 in
standby.
Comandi di verifica e visualizzazione delle configurazioni:
• verifica dello stato del Link Aggregation:
show ports sharing
• visualizzazione delle informazioni relative al LACP:
show lacp
2
Come ad esempio fibra ottica e cavo in rame.
• visualizzazione delle informazioni relative ad un singolo LAG:
show lacp lag <group-id> {detail}, dove:
- <group-id> è rappresentato dalla master-port del LAG.
- detail, se specificato, aumenta la verbosità del resoconto.
• visualizzare informazioni su una porta di uno specifico LAG:
show lacp member-port <port> {detail}, dove:
- <port> è l’id univoco della porta.
- detail, se specificato, aumenta il dettaglio del resoconto.
• azzerare le statistiche e i contatori:
clear lacp counters
Per una trattazione più dettagliata dei comandi di verifica e diagnostica si
rimanda a [9].
La disponibilità di tali configurazioni ha reso l’infrastruttura di rete a disposizione idonea alla sperimentazione del Link Aggregation, in quanto dovranno
essere configurati un LAG per ogni server, e ciascun LAG dovrà aggregare
due interfacce di rete.
Capitolo 4
Configurazione degli host per il
Bonding
La configurazione del bonding su un host con Sistema Operativo Linux
prevede il caricamento di un omonimo modulo del kernel [10], la specifica
dei parametri per il suo funzionamento, la configurazione di un’interfaccia
virtuale che rappresenterà l’aggregato e delle interfacce fisiche da aggregare
in essa.
4.1
4.1.1
Caricamento e configurazione del modulo
del kernel
/etc/modprobe.conf
Il caricamento del modulo va effettuato modificando il file /etc/modprobe.conf
che serve ad installare e rimuovere moduli del kernel, definire alias e specificare opzioni. Il bonding è già disponibile nelle principali distribuzioni di linux
server-oriented1 senza necessità di ricompilare il kernel ed è stato solamente
necessario aggiungere un alias e specificare le opzioni per il modulo.
1
tra cui la Scientific Linux utilizzata nella rete di studio
Capitolo 4. Configurazione degli host per il Bonding
17
Di seguito un esempio di istruzioni aggiunte a /etc/modprobe.conf:
alias bond0 bonding
options bonding mode=4 miimon=100 xmit_hash_policy=1
L’alias permette il caricamento automatico del modulo bonding se l’interfaccia virtuale bond0 risulterà configurata. Le opzioni riportate sopra indicano
rispettivamente:
- mode=4: impone una gestione delle interfacce aggregate secondo il
protocollo 802.3ad.
- miimon=100: stabilisce l’intervallo in millisecondi tra un controllo e
l’altro dello stato delle interfacce.
- xmit hash policy=1: indica l’utilizzo di una politica di smistamento
dei frame basata sugli indirizzi Layer 2.
Le altre opzioni disponibili per il modulo del bonding sono riportate in dettaglio nell’appendice C.
Per verificare che il modulo sia stato effettivamente caricato si può utilizzare
il comando lsmod che visualizza con una formattazione chiara il contenuto
di /proc/modules, ovvero la lista dei moduli caricati ed alcune informazioni
aggiuntive a loro relative.
4.2
Definizione dell’interfaccia di rete per il
Bonding: bond0
In RedHat Enterprise Linux e distribuzioni basate su di essa, al caricamento della rete, vengono lette le informazioni sulla configurazione delle interfacce da file residenti nella directory /etc/sysconfig/network-scripts aventi il
18
seguente formato per il nome: ifcfg-<nome_interfaccia>.
Per quanto riguarda l’interfaccia virtuale da utilizzare per il bonding è stato quindi necessario creare il file ifcfg-bond0 contenente le seguenti righe di
configurazione:
DEVICE=bond0
ONBOOT=yes
BOOTPROTO=dhcp
USERCTL=no
dove:
• DEVICE indica il nome dell’interfaccia di rete.
• ONBOOT = yes forza il caricamento dell’interfaccia all’avvio.
• BOOTPROTO = dhcp indica rispettivamente di utilizzare il procollo
DHCP (Dynamic Host Configuration Protocol) e ricevere da un server
apposito l’indirizzo IP e gli altri parametri per la rete. L’alternativa è
una definizione statica di queste informazioni2
• USERCTL = no impedisce che lo stato dell’interfaccia possa essere
modificato anche da utenti non privilegiati.
4.3
Riconfigurazione delle interfacce di rete
eth0 ed eth1
Sempre nella directory /etc/sysconfig/network-scripts sono stati modificati
i file ifcfg-eth0 ed ifcfg-eth1 per configurare le due interfacce come dipendenti
da bond0 e non più disponibili indipendentemente:
2
Fra cui le principali sono: Indirizzo IP, Net-mask, Default Gateway, indirizzi dei server
DNS.
19
cat /etc/sysconfig/network-scripts/ifcfg-eth0 (prima delle modifiche):
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
cat /etc/sysconfig/network-scripts/ifcfg-eth0 (dopo le modifiche):
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
TYPE=Ethernet
MASTER=bond0
SLAVE=yes
Il file ifcfg-eth1 è analogo, quindi per brevità non sarà riportato.
Si può notare come sia stato cambiato il Boot Protocol da dhcp a none perché
essendo le interfacce eth0 ed eth1 aggregate nell’interfaccia virtuale bond0
esse non saranno più visibili ed utilizzabili singolarmente, perciò sarà necessario impostare l’indirizzo IP e il MAC Address solo per bond03 .
Sono altresı̀ state aggiunte le informazioni MASTER=interfacciaMaster, dove
interfacciaMaster è il nome dell’interfaccia virtuale utilizzata per il bonding,
e SLAVE=yes per indicare che l’utilizzo dell’interfaccia sarà soggetto e subordinato alla master appena definita.
Per distribuzioni che non supportano tali file per la configurazione delle intefacce di rete si dovrà ricorrere all’utility ifenslave con la seguente sintassi:
ifenslave <interfacciaMaster> <interfacciaSlave>
3
Il primo ricevuto dal DHCP Server, il secondo preso dalla prima interfaccia tra quelle
aggregate, ma modificabile manualmente tramite il file di configurazione opppure tramite
ifconfig.
4.3.1
20
Monitoraggio delle impostazioni del modulo
Ogni interfaccia virtuale di bonding possiede un file di sola lettura nella
directory /proc/net/bonding. Con la configurazione di esempio mostrata nel
paragrafo precedente, mediante il comando cat /proc/net/bonding/bond0
si avrà il seguente output:
Ethernet Channel Bonding Driver: v2.6.3-rh (June 8, 2005)
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
802.3ad info
LACP rate: slow
Active Aggregator Info:
Aggregator ID: 5
Number of ports: 2
Actor Key: 17
Partner Key: 3007
Partner Mac Address: 00:04:96:1d:cd:60
Slave Interface: eth0
MII Status: up
Link Failure Count: 3
Permanent HW addr: 00:30:48:7e:2d:0a
Aggregator ID: 5
Slave Interface: eth1
MII Status: up
Link Failure Count: 3
Permanent HW addr: 00:30:48:7e:2d:0b
Aggregator ID: 5
Il formato e le informazioni variano in dipendenza dalla modalità di bonding
utilizzata, dallo stato e dalla versione del driver per il bonding in uso, si può
comunque scevrare uno scheletro comune:
21
nella parte iniziale vengono visualizzate le informazioni generali sulle impostazioni per il bonding, come ad esempio la modalità di gestione dei link
(statico o dinamico) e l’algoritmo di smistamento del traffico utilizzato. Successivamente viene dettagliato lo stato per ogni singola interfaccia aggregata
tramite il bonding.
Capitolo 5
Test di performance con diverse
configurazioni del Bonding
Per poter effettuare un confronto sotto il profilo del throughput, del bilanciamento del carico e dell’affidabilità sono stati svolti diversi test utilizzando
le varie configurazioni possibili al fine di identificare la più adatta per la rete
di studio, sia per quanto riguarda il modulo del kernel per gli host, sia per le
opzioni offerte dallo switch.
Queste prove sono state realizzate utilizzando quattro calcolatori dedicati:
Figura 5.1: configurazione test con flussi diretti verso il server
uno (farm06) dotato di due interfacce di rete Gigabit Ethernet configurate
in bonding e quindi facente funzioni di server, e altri tre calcolatori uguali al
server (farm07, farm08 e farm09), ma utilizzati come client e configurati con
un link Gigabit Ethernet ciascuno (vedi fig. 5.1).
Capitolo 5. Test di performance con diverse configurazioni del Bonding 23
5.1
Traffico in direzione della macchina in bonding
(farm06)
Questi test sono finalizzati a verificare la funzionalità dei diversi algoritmi di smistamento del traffico operati dallo switch, generando flussi di dati
concomitanti dai client verso il server, ed anche a valutare un eventuale impatto del layer del bonding sulle prestazioni delle singole interfacce di rete.
Lo smistamento del traffico dei tre client dovrebbe permettere di saturare la
doppia interfaccia del server e di bilanciare i flussi tra client concorrenti.
Allo scopo di valutare le funzionalità dei due protocolli (statico e dinamico)
nei due possibili algoritmi di instradamento dei frame disponibili (basati su
indirizzi MAC o indirizzi IP), sul modulo numero 3 dello switch sono state
definite quattro coppie di porte in bonding con diverse configurazioni:
• (3:1, 3:2): Link Aggregation Statico e algoritmo di redistribuzione dei
pacchetti basato su indirizzi di livello 2
• (3:3, 3:4): Link Aggregation Statico e algoritmo basato su indirizzi di
livello 3
• (3:5, 3:6): Link Aggregation Dinamico (LACP) e algoritmo basato su
indirizzi di livello 2
• (3:7, 3:8): Link Aggregation Dinamico (LACP) e algoritmo basato su
indirizzi di livello 3
5.1.1
Static L2
In questa configurazione l’algoritmo di smistamento applicato dallo switch
determina l’interfaccia di uscita di ciascun frame, tra quelle aggregate, se-
condo la formula:
(S M AC ⊕ D M AC) % slave count
dove
• S MAC: l’indirizzo hardware della macchina sorgente, cioè della scheda
di rete denominate eth0
• D MAC: l’indirizzo hardware dell’interfaccia virtuale di farm06, ovvero
il MAC address del destinatario
• slave count: pari a 2 nel nostro caso, equivalente al numero di schede
di rete aggregate.
Sono stati realizzati diversi test utilizzando uno, due e tre client concomitanti, sia con protocollo TCP che con protocollo UDP. Si vede chiaramente
in fig. 5.2 che il comportamento non è quello auspicato, in quanto tutto il
traffico viene instradato attraverso una sola interfaccia del server, eth1, mentre attraverso l’altra non passano dati. Questo accade perché le interfacce di
tutti e tre i client hanno un MAC address pari, per cui l’algoritmo di selezione sceglie per i tre flussi sempre la stessa interfaccia in uscita.
Va considerato che gli odierni calcolatori utilizzati come server di calcolo
vengono prodotti con due interfacce di rete integrate sulla scheda madre, i
cui indirizzi sono sequenziali. Quasi sempre la prima delle due interfacce ha
indirizzo pari, per cui il problema osservato non è da considerarsi un fatto
contingente ma un potenziale problema che si verificherebbe quasi sempre,
annullando di fatto la funzionalità di aggregazione del bonding.
Per aggirare questo problema si potrebbe procedere ad un reindirizzamento
delle schede di rete dei client in modo opportuno, ma questa opzione non
Figura 5.2: Static/L2: flusso concomitante dei tre client verso il server; viene
utilizzata solo una interfaccia di rete che satura a 118 MB/s, mentre l’altra non
viene utilizzata
è consigliabile in quanto comporterebbe un carico di lavoro aggiuntivo e la
necessità di tenere conto degli indirizzi ridefiniti per evitare duplicazioni, con
conseguente divergenza della complessità di gestione per una rete non banale
come quella in esame.
Test effettuati generando flussi non concomitanti tra i client ed il server hanno
confermato questo comportamento: tutti i flussi utilizzano la stessa interfaccia di rete del bonding verso il server.
Va comunque osservato che la banda aggregata che si ottiene raggiunge
i 118 MB/s, cioe’ satura l’interfaccia Gigabit Ethernet utilizzata, e che la
banda disponibile viene equamente ripartita tra i diversi client (vedi fig. 5.3):
questo conferma che l’utilizzo del bonding in modalità statica non comporta
un calo di prestazioni e che il protocollo bilancia correttamente la banda
Figura 5.3: Static/L2: flusso concomitante dei tre client verso il server; viene
utilizzata solo una interfaccia di rete che satura a 118 MB/s, con la banda ripartita
equamente fra i tre client
disponibile tra i diversi utilizzatori.
5.1.2
Static L3
La porta di uscita per il singolo frame, in questa modalità, sarà determinata
dallo switch secondo la seguente formula:
(S IP ⊕ D IP ) % slave count
dove
• S IP: l’indirizzo IP della macchina sorgente.
• D IP: l’indirizzo IP del destinatario.
• slave count: equivale al numero di schede di rete aggregate.
La ripartizione del traffico in questo caso dipende evidentemente dagli indirizzi IP, che possono essere definiti in modo opportuno più facilmente rispetto
agli indirizzi di livello 2. L’utilizzo di questo algoritmo dovrebbe permettere
di ripartire il traffico su entrambe le interfacce di rete.
In fig. 5.4 si può osservare come l’algoritmo selezioni porte differenti per
i diversi client, raggiungendo un throughput aggregato pari a ∼236 MB/s,
corrispondente di fatto alla saturazione delle due interfacce in bonding.
I flussi provenienti dai tre client vengono distribuiti uno verso una interfaccia
e due verso l’altra; in questo modo un client (farm08) dispone ed utilizza
interamente la banda di 1 Gbps, gli altri due (farm07 e farm09) si suddividono equamente la banda dell’altra interfaccia, ottenendo ∼58 MB/s ciascuno
(cioè circa 466 Mbps).
Figura 5.4: Static/L3: traffico TCP da 3 client verso il server con saturazione di
entrambe le interfacce Gigabit Ethernet.
5.1.3
LACP L2 ed L3
Questi test sono finalizzati a misurare funzionalità e prestazioni del bonding
realizzato tramite il protocollo di aggregazione dinamico LACP.
Poiché gli algoritmi di smistamento del traffico sono indipendenti dalla tipologia di bonding, ci si aspetta che il comportamento coincida con quello dei
test relativi alla sezione 5.1.1 e 5.1.2
Figura 5.5: LACP/L3: tre flussi concomitanti verso il server: sono mostrati i
contatori sulle singole interfacce del server, e l’aggregato; la banda disponibile
viene completamente saturata (236 MB/s)
Le misure dimostrano che anche il protocollo dinamico LACP ha piena funzionalità e permette di raggiungere un throughput aggregato pari a
∼236 MB/s, saturando entrambe le interfacce del server, qualora si utilizzi
l’algoritmo basato sugli indirizzi IP (L3) (vedi fig. 5.5).
5.2
Traffico in uscita dalla macchina in bonding
(farm06)
Il traffico in uscita dal server viene instradato verso una delle interfacce
aggregate in base ad algoritmi implementati nel driver del bonding installato
sul server, che sono diversi da quelli che operano sul traffico in ingresso e che
sono implementati nel firmware dello switch; è quindi necessario verificarne
la funzionalità generando ed analizzando flussi dal server verso i client.
Il driver del bonding permette la scelta fra due algoritmi per lo smistamento
dei frame, uno basato sui MAC address (L2) del tutto identico all’algoritmo
utilizzato dallo switch, l’altro che dipende sia dagli indirizzi IP che dalle
porte TCP o UDP utilizzate dagli applicativi che comunicano. Quest’ultimo
è quindi un algoritmo che lavora ai livelli 3 e 4 dei protocolli di rete.
Si configura la scelta dell’algoritmo tramite il parametro xmit hash policy:
xmit_hash_policy = 0: algoritmo L2 (indirizzi hardware)
xmit_hash_policy = 1, algoritmo L3+L4 (indirizzi IP e porte TCP/UDP)
In quest’ultimo caso l’interfaccia verso cui instradare il frame è determinata
dalla formula:
((S P ORT ⊕ D P ORT ) ⊕ ((S IP ⊕ D IP ) ⊕ 0xffff)) % slave count
dove
- S PORT: porta sulla macchina sorgente
- D PORT: porta sulla macchina di destinazione
- S IP: indirizzo IP della macchina sorgente
- D IP: indirizzo IP della macchina di destinazione
- slave count: corrisponde al numero di interfacce in bonding
La dipendenza dalle porte TCP o UDP rende virtualmente impossibile
prevedere quale interfaccia verrà utilizzata in quanto spesso gli applicativi
utilizzano porte scelte dinamicamente, perciò al di là del nostro controllo.
In questa situazione la distribuzione dei flussi sulle diverse interfacce del
bonding è garantita a livello statistico.
5.2.1
Mode = xor balancing (Statico) con xmit hash policy = 0 (L2)
Figura 5.6: Static/L2: traffico TCP dal server verso 2 client; i due client
condividono e saturano la stessa interfaccia GE.
Utilizzando l’algoritmo basato sul MAC address il comportamento atteso
dovrebbe essere conforme a quanto avveniva generando traffico in direzione
contraria (Sezione 5.1.1).
I test effettuati (figura 5.6) hanno avuto l’esito previsto: tutto il traffico passa su una sola interfaccia, eth0.
5.2.2
Mode = xor balancing (Statico) con xmit hash policy = 1 (L3+L4)
L’utilizzo di un algoritmo basato su indirizzi IP e numero di porte TCP/UDP,
dovrebbe permettere di redistribuire i flussi su più d’una interfaccia, in modo
analogo all’algoritmo L3 implementato dallo switch.
Dai grafici si nota come in un caso (figura 5.7) vengano utilizzate entrambe
le interfacce di rete riuscendo cosı̀ a raggiungere i 2 Gbps, e come nell’altro
(figura 5.8) si abbia l’utilizzo di una sola scheda, rimanendo limitati alla velocità di 1 Gbps. Tale difformità è conseguenza del fatto che netperf utilizza
porte dinamiche: evidentemente nel secondo caso la combinazione di porte
ed indirizzi IP delle due connessioni è stata tale da determinare la stessa
interfaccia per l’instradamento dei due flussi, lasciando quindi una interfaccia inutilizzata e limitando il throughput aggregato ad un solo link Gigabit
Ethernet. Nel primo caso si è invece riusciti a sfruttare completamente la
banda offerta dal bonding.
5.2.3
Mode = 802.3ad (LACP) con xmit hash policy
= 0 (L2) e Mode = 802.3ad (LACP) con xmit hash policy = 1 (L3+L4)
Cosı̀ come per lo switch, anche per l’host la tipologia di bonding non
influenza lo smistamento dei frame, perciò i risultati attesi erano analoghi a
quelli delle sezioni 5.2.1 e 5.2.2, come confermato dai test mostrati in fig.
5.9 e 5.10.
Figura 5.7: Static/L3+L4: traffico TCP dal server verso 2 client; il traffico si
distribuisce sulle due interfacce GE e le saturano entrambe.
Figura 5.8: Static/L3+L4: traffico TCP dal server verso 2 client: in questo caso i
flussi condividono e saturano la stessa interfaccia GE.
Figura 5.9: LACP/L2: traffico in uscita dal server; viene utilizzata una sola
interfaccia GE.
Figura 5.10: LACP/L3+L4: taffico in uscita dal server; entrambe le interfacce del
server vengono saturate.
5.3
Test di tolleranza alla disconnessione fisica di un link
Uno dei requisiti per l’utilizzo in produzione del bonding sulla rete in esame è la robustezza a eventi dannosi quali la perdita di un link, qualunque ne
sia la causa.
A questo proposito sono state testate le due diverse tipologie di gestione
dei link a disposizione, quella statica e quella dinamica, entrambe con algoritmo di smistamento di tipo L3 (L3+L4 lato server) in modo da saturare la
banda, scenario in cui una riduzione dei link dovrebbe avere un esito visibilmente negativo.
Per questi test è stato utilizzato netperf perché in grado di generare traffico
a piena banda con possibilità di scegliere il protocollo. Interessava altresı̀ verificare il comportamento di una generica applicazione di file transfer, perciò
si è fatto ricorso al comando cp mediante l’utilizzo di NFS (Network File
System), grazie a cui è possibile montare file system remoti su una macchina
locale. I file trasferiti con cp avevano tutti la dimensione di 16 GByte in modo di avere un tempo di trasferimento sufficientemente lungo da permettere
un monitoraggio significativo.
La perdita di un link è stata simulata disconnettendo fisicamente uno dei
due cavi in rame dallo switch, successivamente riattaccato per controllare
che il traffico riprendesse a fluire come prima dell’interruzione, chiaramente
verificando eventuali errori.
Per quanto riguarda la configurazione del modulo di bonding sulla macchina
farm06 è stato utilizzato un miimon pari a 100, valore in grado di fornire
reattività nell’individuare il cambio di stato di un link senza però stressare
troppo la macchina con un controllo troppo frequente.
Le misure effettuate utilizzando il protocollo statico sono mostrate in fig.
5.11 (contatori lato server) ed in fig. 5.12 (contatori lato client), mentre i
test con LACP sono mostrati in fig. 5.13 e 5.14 (sempre lato server e client
rispettivamente).
Figura 5.11: Static, contatori delle interfacce lato server: dopo 60 secondi è stato
disconnesso il link eth0, riconnesso poi dopo 10 secondi. Si può notare come
la disconnessione non influisca negativamente sul link ancora connesso e come il
traffico riprenda regolarmente al momento della riconnessione.
In tutti i test eseguiti non è stato rilevato alcun errore. Al momento della
disconnessione l’host rilevava correttamente l’accaduto (come è stato verificato controllando i messaggi di diagnostica del kernel) riducendo la banda
e continuando il trasferimento, senza errori, sull’unico link rimasto per poi
tornare a piena banda su entrambe le tratte al momento della riconnessione.
Figura 5.12: Static, contatori delle interfacce lato client; dal grafico appare evidente
come al momento della disconnessione del link i 3 client condividano equamente
la banda disponibile.
La reazione alla perdita del link è quindi pienamente soddisfacente ed in
linea con quanto atteso.
5.4
Considerazioni conclusive sulla scelta del
protocollo per il bonding
Le misure effettuate hanno mostrato una completa equivalenza tra il protocollo statico e quello dinamico sia per quanto riguarda le prestazioni che per
le funzionalità di failover e di bilanciamento. Tuttavia l’utilizzo del protocollo
dinamico, oltre ad essere uo standard riconosciuto, offre superiori garanzie di
protezione della rete locale, in quanto l’attivazione del link avviene solo dopo
un controllo sulla corretta configurazione di entrambi i lati della connessione
Figura 5.13: LACP lato server: si può ossevare chiaramente come il throughput
aggregato scende a 118 MB/s con un solo link disponibile. Durante questo periodo
le tre istanze di netperf condividono la banda disponibile dell’unico link attivo.
Figura 5.14: LACP lato client: il grafico evidenzia chiaramente come al momento
della disconnessione del cavo, nell’intervallo che va dal secondo 60 all’80, il flusso
dati verso i 3 client si riduca alla velocità di 1 Gbps.
aggregata.
Per questo motivo si è scelto di utilizzare in seguito il protocollo di aggregazione dinamico.
Per quanto riguarda la scelta dell’algoritmo di instradamento dei frame, si è
potuto vedere come l’algoritmo basato sugli indirizzi MAC spesso impedisce
un completo sfruttamento della banda aggregata, non soltanto in conseguenza del più o meno casuale indirizzamento concorde delle schede dei server.
Si deve infatti considerare che ogni qualvolta l’accesso ai server avvenga attraverso un processo di routing (cioè di instradamento a livello 3), i frame in
entrata ed in partenza dai server avranno sempre come destinataria l’interfaccia ethernet dell’apparato che effettua il routing (il router di frontiera per
le connessioni esterne alla rete locale, o lo switch di core per le connessioni
provenienti da VLAn diverse da quella di appartenenza dei server).
Poiché nella configurazione locale molti client sono collocati su VLAN diverse
da quella dei server, questo effetto sarebbe frequente.
Per questo motivo nel seguito si è scelto di utilizzare gli algoritmi basati sugli
indirizzi L3 lato switch e sugli indirizzi L3+L4 lato server.
Capitolo 6
Prestazioni della infrastruttura
di produzione
Per poter analizzare in modo completo la tecnologia in esame, è necessario
effettuare test con effettivo accesso al sistema di storage, in quanto lo scopo
della sperimentazione è ottenere un aumento di banda verso i dischi.
Si è quindi reso indispensabile utilizzare l’infrastruttura in produzione, l’unica in grado di offrire un sistema disco capace di supportare il carico di I/O
necessario a dimostrare la validità della soluzione tecnologica.
6.1
Dettaglio della infrastruttura di storage
Lo storage di produzione e’ costituito da un insieme di sei disk server che
esportano volumi acceduti tramite una Storage Area Network via protocollo
Fibre Channel con link a 4 Gbps (vedi fig. 1.1).
Ogni server è connesso alla SAN da una scheda Fibre Channel dual head
attraverso due switch per motivi di ridondanza.
I sistemi disco sono costituiti da tre batterie di dischi SATA gestite ciascuna
da un doppio controller RAID con interfaccia Fibre Channel per la connessione alla SAN. Ciascuna coppia di controller ha configurato la propria batteria
Capitolo 6. Prestazioni della infrastruttura di produzione
40
di dischi in volumi Raid 5 o Raid 6, per garantire prestazioni ed affidabilità
al sistema.
Ciascun disk server esporta quindi una parte dei volumi configurati sui controller di disco; per motivi di prestazioni e di flessibilità sui volumi sono
configurati diversi file system di tipo GPFS (General Parallel File System),
un file system parallelo sviluppato e distribuito da IBM.
I meccanismi di funzionamento di questo file system devono essere analizzati
per poter pianifilcare correttamente i test che si desidera realizzare.
6.2
File system GPFS
Un file system GPFS è costituito dalla unione di uno o più volumi fisici,
che vengono visti come un unico contenitore (il file system, appunto) la cui
dimensione è pari alla somma delle dimensioni dei volumi aggregati. I volumi, che nel nostro caso sono i volumi esportati dai controller raid, vengono
chiamati NSD (Network Shared Disk) e resi disponibili ai client da uno o più
server (detti NSD server).
In una infrastruttura SAN, in cui uno stesso volume può essere visto direttamente da più di un server, è possibile configurare GPFS in modo che quel
volume sia esportato da un server primario, ma che altri server secondari
possano intervenire in sostituzione del primo in caso di guasto, senza perdere
di funzionalità; in questo modo si realizza un sistema di accesso al disco altamente affidabile grazie a ridondanze multiple (sul volume Raid, sul doppio
controller, sul path multiplo della SAN, ed infine sul disk server) che proteggono da qualsiasi guasto singolo.
6.2.1
41
Accesso al file system
GPFS realizza l’accesso (in scrittura ed in lettura) al file system facendo striping su tutti gli NSD che costituiscono il file system stesso. Questo permette
di parallelizzare gli accessi aumentando notevolmente le prestazioni di I/O:
se abbiamo un file system costituito da N NSD, e si vogliono eseguire N
distinte operazioni di I/O (ad esempio quando si deve leggere o scrivere sequenzialmente un grosso file), queste vengono eseguite contemporaneamente
una su ciascun NSD, distribuendo cosı̀ il carico di lavoro di I/O su diversi
volumi. Se gli NSD sono esportati da server differenti, si potrà anche parallelizzare gli accessi su più server; in questo modo si aumenta la banda oltre
i limiti della capacità di I/O del disco o della capacità di banda del singolo
server.
6.3
Valutazione del sistema in produzione
Nella configurazione attuale del sistema di storage sono configurati più di 25
NSD, raggruppati in una decina di file system GPFS, ed esportati da 6 disk
server. Questi file system hanno prestazioni piuttosto differenti in funzione
dell’età dell’hardware, e della capacità di banda del singoli controller.
Si deve quindi avere una iniziale valutazione di quali siano i file system più
performanti per poter identificare una piattaforma opportuna di test su cui
operare. Le prove descritte nel presente capitolo sono finalizzate proprio a
questo scopo, e sono state effettuate prima di configurare il bonding sui disk
server.
6.4
42
Confronto di performance dei disk-server
e dei file system
I test sono stati realizzati mediante l’impiego di 14 client della farm di produzione, creando opportuni script, ciascuno dei quali esegue sequenzialmente
scrittura e lettura di 128 file da 1 GB con una block-size di 512 KByte1 .
Gli script sono stati sottomessi come batch job sulla farm di produzione tramite il batch system LSF (Load Sharing Facility), che è stato opportunamente configurato per dedicare slot sui client selezionati per questa specifica
funzione.
6.4.1
Prestazioni in scrittura
Ognuna delle 14 macchine per il test ha eseguito un job consistente in uno
Shell Script che effettuasse la scrittura mediante l’utility dd2 e riportasse il
tempo impiegato per scrivere ciascun file nel file job# .out.
Successivamente è stato utilizzato uno script per analizzare i file di output e
calcolare la media del tempo necessario a completare la scrittura dei file per
ciascuna macchina.
Di seguito la tabella riassuntiva per il test effettuato:
1
Valore ottimale in quanto in grado di sfruttare al meglio lo striping offerto
dall’organizzazione dei dischi mediante RAID 6.
2
Utility in grado di copiare in modalità raw interi dischi o partizioni, oppure di specificare una grandezza in byte dei dati. La modalità raw consiste nella copia fisica dei dati
a prescindere dall’organizzazione del file system e della tavola delle partizioni.
Job #
Macchina File System
43
Disk-Server
Valor medio di scrittura (sec)
1
atlas08
aiace2 fs
gpfs5, gpfs6
116
2
atlas07
geant4 fs
gpfs3
138
3
atlas09
home fs
gpfs2
N/A
4
aiace05
borex1 fs
gpfs3, gpfs4
64
5
aiace01
atlas1 fs
gpfs3, gpfs4
55
6
aiace06
borex1 fs
gpfs3, gpfs4
64
7
totem01
farm1 fs
gpfs3, gpfs4
64
8
aiace04
babar0 fs
gpfs5, gpfs6
107
9
aiace02
atlas1 fs
gpfs3, gpfs4
55
10
totem03
geant4 fs
gpfs3
130
11
totem02
farm1 fs
gpfs3, gpfs4
64
12
aiace03
babar0 fs
gpfs5, gpfs6
109
13
geant12
aiace3 fs
gpfs3, gpfs4
64
14
geant13
aiace3 fs
gpfs3, gpfs4
64
15
teo15
aiace2 fs
gpfs5, gpfs6
106
16
teo16
home fs
gpfs2
N/A
I test 3 e 16, anche se pianificati, non sono stati portati a termine in quanto
avrebbero sovraccaricato il file system dove risiedono le home directory utente causando disservizi non tollerabili.
La differenza di prestazioni sui diversi file system è dovuta in parte al diverso
numero di dischi disponibili per ognuno, in parte al disk-server incaricato di
esportarlo (e più precisamente al numero di file system che esso deve gestire)
e in parte dalla ripartizione sulle diverse batterie di dischi gestite da diversi
controller. La configurazione è troppo complessa per procedere con una stima sommaria, si è perciò preferito non scendere nel dettaglio in quanto al
44
di fuori dell’argomento di indagine. Si sono tuttavia potuti selezionare i file
system fra i più performanti da utilizzare per i successivi test di stress del
sistema di storage e rete annessa: aiace3 fs, borex1 fs, farm1 fs; il file system
atlas1 fs non è stato preso in considerazione per via della sua configurazione
che lo rende inadatto alla sperimentazione in oggetto: esso è infatti costituito
da 3 NSD che, per un errore di configurazione, sono esportati dallo stesso
server; l’utilizzo del bonding su questo file system risulterebbe meno efficace
che negli altri casi.
Tutti i file system sopracitati sono serviti dai disk-server GPFS3 e GPFS4,
sui quali verrà configurato il bonding.
6.5
Analisi in lettura
Il test in lettura è strutturato in modo speculare a quello per la scrittura,
sempre mediante Job ma stavolta con l’ausilio di uno script che effettui operazioni di lettura anziché scrittura, sempre tramite dd.
Poiché erano già stati individuati i file system più performanti si è proceduto alla misura del throughput in lettura solo per questi.
Job #
Macchina File System
Disk-Server
Valor medio di lettura (sec)
1
totem01
farm1 fs
gpfs3, gpfs4
30
2
totem02
farm1 fs
gpfs3, gpfs4
30
3
aiace05
borex1 fs
gpfs3, gpfs4
31
4
aiace06
borex1 fs
gpfs3, gpfs4
32
5
geant12
aiace3 fs
gpfs3, gpfs4
32
6
geant13
aiace3 fs
gpfs3, gpfs4
32
I risultati per i diversi file system sono risultati accettabili e pressochè identi-
45
ci fra loro. L’aggregato delle prestazioni su questi file system in lettura è pari
a circa 200 MB/s, cioè vicina alla saturazione delle due interfacce Gigabit
Ethernet disponibili per l’accesso agli NSD, una per ciascun server.
Capitolo 7
Analisi dell’utilizzo dei dischi
gestiti dai disk-server
Questi ultimi test sono dedicati a misurare il throughput massimo ottenibile dal sistema di storage configurando in bonding le due interfacce di rete
dei server di disco. La configurazione del bonding utilizzata è quella che associa il protocollo dinamico (LACP) con l’algoritmo basato sugli indirizzi L3
(lato switch) e L3+L4 (lato server).
In base a quanto visto nel cap. 6 si è deciso di operare soltanto sui file
system più performanti, tutti serviti dai soli due server gpfs3 e gpfs4. Tutti
i file system in questione sono costituiti da due NSD; per ottimizzare le prestazioni ciascun NSD di un file system è servito da un server diverso.
La definizione del layout dei test deve essere fatta in modo da permettere in
linea teorica di saturare la banda disponibile.
Come mostrato in fig. 7.1, in cui per semplicità non è mostrato il dettaglio della SAN, ogni NSD dispone di 4 Gbps verso il server che la esporta
(link Fibre Channel), che a sua volta offre un link a 2 Gbps (il bonding delle
interfacce di rete) verso la rete locale. Ogni accesso al file system viene pa-
Capitolo 7. Analisi dell’utilizzo dei dischi gestiti dai disk-server
47
Figura 7.1: path di accesso ai volumi del singolo file system: i client devono
essere scelti in modo che tutte le interfacce di rete dei server siano completamente
utilizzate.
rallelizzato sui due NSD, quindi l’aggregato disponibile verso il file system è
di 4 Gbps.
Poichè ogni client dispone di un link ad 1 Gbps (la sua interfaccia Gigabit
Ethernet), sarà necessario generare flussi concomitanti da almeno quattro
client.
Tutte le misure verranno fatte in scrittura ed in lettura, anche se si prevede
che solo queste ultime saranno in grado di fornire un throughput sufficiente
a saturare i 4 Gbps disponibili.
7.1
Definizione del layout per i test
Se si vuole saturare la banda, i client dovranno essere scelti in modo che
l’algoritmo di instradamento del bonding operi bilanciando il traffico verso i
quattro client su tutte le interfacce dei server.
A questo proposito deve essere fatta una considerazione relativa al fatto che
l’algoritmo dipende non solo dagli indirizzi IP ma anche dalle porte TCP
48
utilizzate nelle singole connessioni, almeno per i flussi uscenti dai server: in
principio i numeri di porta non sono controllabili, perchè scelti dinamicamente dagli applicativi; tuttavia GPFS opera in modo da permetterci di
prevedere la strada che prenderanno i dati verso i diversi client, perchè la
scelta della porta, sia sui server che sui client, viene fatta al bootstrap e non
cambia fino al successivo restart.
In queste condizioni è possibile eseguire una mappatura dei cammini seguiti
dai flussi in funzione del client, e scegliere opportunamente quattro client che
possano saturare entrambe le interfacce dei due server.
Per ogni singolo client utilizzato nei test seguenti, ove non espressamente
specificato, si è fatto ricorso ad un file da 8 GByte, sia in lettura che in scrittura. L’elevata dimensione permette di annullare eventuali effetti di caching
dei disk server e dei controller di disco che potrebbero alterare le misure; in
particolare, per verificare che i dati trasmessi sulla rete fossero stati effettivamente letti da disco, sono sempre stati misurati tramite dstat i throughput
sia sulle interfacce di rete che sull’accesso al disco.
Durante tutte le prove sono stati monitorati anche i valori dei contatori della
CPU per riscontrare eventuali anomalie o carico eccessivo, ma nulla di tutto
ciò è stato riscontrato in nessuno dei test condotti.
7.2
Test su borex1 dev
I test in scrittura (fig. 7.2) mostrano come si raggiunga sulla rete un throughput aggregato medio di ∼310 MB/s (2.4 Gbps) sul file system, con punte fino
a 400 MB/s (3.2 Gbps). Il risultato e’ ottimo e già sufficiente a dimostrare
come la tecnologia del bonding permetta di superare il limite dei 2 Gbps. In
lettura (fig. 7.3) si ottengono prestazioni leggermente migliori: ∼340 MB/s
(2.7 Gbps) in media, e punte di quasi 450 MB/s (3.6 Gbps).
49
In entrambi i grafici si può notare che il flusso da e verso il server gpfs4
risulta essere abbastanza regolare, mentre quello relativo a gpfs3 presenta
delle cadute evidenti per intervalli temporali significativi.
Per capire se questo fenomeno fosse in qualche modo legato all’utilizzo del
bonding è stato svolto un test di lettura utilizzando un solo client e, come si
può vedere dalla fig. 7.4, l’interruzione del flusso dati riguardante gpfs3 si è
verificata anche in questo caso.
Analizzando nel dettaglio la configurazione dei due NSD (Network Shared
Disk) relativi al file system in uso ci si è accorti che le loro dimensioni sono diverse, rispettivamente pari a 6 TByte e 4 TByte, mentre l’occupazione
percentuale dei due NSD è identica. Ne consegue che il file system GPFS
realizza lo striping sugli NSD di uno stesso file system bilanciando le scritture in modo da occupare equamente i diversi NSD a livello percentuale e
non assoluto. Nel nostro caso, avendo gli NSD dimensioni diverse, GPFS
necessariamente dovrà scrivere più spesso sull’NSD più grande, bilanciando
cosı̀ l’occupazione percentuale.
Questo è il motivo per cui nei test precedenti il server gpfs3 ciclicamente interrompe la sua attività: è infatti proprio gpfs3 a servire l’NSD più piccola.
Una situazione del tutto analoga si presenta ovviamente anche in lettura.
7.3
Test su farm1 dev
Per verificare la nostra ipotesi sono stati svolti test su farm1 dev, uno
dei file system selezionati al cap. 6, che è costituito da due NSD di uguale
dimensione.
In figura 7.5 è mostrato il grafico relativo alla scrittura contemporanea
di quattro client. Dopo una fase iniziale il throughput si attesta con una
certa stabilità intorno ai 390 MByte/s, pari a circa 3.1 Gbps. A differenza
50
Figura 7.2: quattro client in scrittura su borex1 dev; sono mostrati il throughput
in entrata sul bonding dei due server e l’aggregato, ed il throughput aggregato di
scrittura su disco (WRITE).
Figura 7.3: quattro client in lettura su borex1 dev; anche in questo caso sono
mostrati i throughput delle interfacce dei due server, la loro somma, e la somma
del throughput di I/O in lettura dal disco.
51
Figura 7.4: La caduta di throughput verso gpfs3 nonostante la lettura su borex1 dev da parte di un singolo client mostra come questo comportamento avvenga
indipendentemente dall’utilizzo del bonding
di quanto accadeva con il file system borex1 dev, i due disk-server hanno
un flusso dati perfettamente bilanciato, dimostrando come il bonding non
fosse responsabile dell’asimmetria. Per quanto riguarda la lettura (fig. 7.6),
sempre mediante quattro client, la velocità media raggiunta è stata circa la
stessa, con punte fino a 450 MB/s.
Dal grafico si nota che poco dopo i 60 secondi si è verificato un calo di
prestazioni, questa volta su entrambi i flussi dei due disk-server; questo è
probabilmente dovuto a qualche operazione di I/O eseguita dai server ma
non legata al nostro test, evento possibile in una rete in produzione come
quella utilizzata.
52
Figura 7.5: quattro client in scrittura su farm1 dev: i flussi sono sempre bilanciati
sui due server
7.4
Test con doppio accesso
Il test di fig. 7.7 è stato svolto con quattro client per ciascuno dei due file
system utilizzati in precedenza per verificare la velocità massima ottenibile,
che è risultata essere stabilmente sopra i 3.2 Gbps, ben oltre i 2 Gbps ottenibili senza bonding.
Anche in questo test si notano gli effetti prodotti dalla asimmetria degli NSD
di uno dei due file system, che però pesa in modo minore per via del contributo simmetrico degli accessi all’altro file system.
Osservando il grafico si può notare ancora una volta come il calo subito da
borex1 dev non si verifichi su farm1 dev grazie alla ripartizione simmetrica
di quest’ultimo sui diversi dischi, ripartizione che permette di sfruttare al
meglio lo striping, permesso dall’organizzazione dei dischi tramite RAID 6.
53
Figura 7.6: quattro client in lettura su farm1 dev
7.5
Test su farm1 dev con stesso file
I test effettuati fin’ora erano finalizzati a valutare le prestazioni dell’accesso
al disco annullando eventuali effetti di ottimizzazione dovuti alle cache del
file system e dei controller. A questo scopo sono stati utilizzati file differenti
per ciascun client, e di dimensioni tali da impedire qualsiasi efficacia delle
cache.
Il test descritto nel presente paragrafo ha invece lo scopo di verificare quali
siano i reali limiti nell’utilizzo della banda disponibile, sempre associato ad
un reale accesso al disco, mettendo il disco in condizioni di non essere collo
di bottiglia.
Sono quindi stati eseguiti due test in lettura con quattro ed otto client che
hanno letto contemporaneamente lo stesso file, sempre di 8 GB. In questo
modo eventuali ottimizzazioni delle cache dovrebbero apparire evidenti.
54
Figura 7.7: test con quattro client in accesso contemporaneo per ognuno dei due
file system
I test sono stati fatti operando sul file system farm1 fs, per evitare i comportamenti asimmetrici visti nei paragrafi precedenti.
In fig. 7.8) si può osservare come in questa condizione il flusso di dati sulla
rete si attesti stabilmente intorno ai 460 MB/s, pari a ∼3.7 Gbps, che costituiscono la saturazione delle quattro interfacce dei server.
Nella stessa figura è anche mostrato il throughput dei dati letti dal disco,
o più precisamente letti dalle schede FC dei server e quindi trasmessi dal
controller del disco verso la SAN.
Come si può vedere il flusso si attesta stabilmente intorno ai 440 MB/s; questo significa che non è stata la cache del file system ad intervenire, perchè la
quantità di dati buttati su rete equivale alla quantità di dati letti dai controller, ma piuttosto la cache dei controller stessi, i quali, dovendo servire più
volte gli stessi dati letti dai dischi, non hanno dovuto operare letture mul-
55
Figura 7.8: lettura da parte di quattro client di uno stesso file su farm1 dev
tiple dello stesso file. In questo modo i dati sono risultati essere disponibili
senza ritardi legati alla lettura fisica dai dischi, e le prestazioni hanno potuto
saturare la banda di rete disponible.
In fig. 7.9 è mostrato il grafico relativo ad 8 client concomitanti in lettura
sullo stesso file: il grafico è assolutamente identico al precedente. Questo
mostra come l’aumento di connessioni sulla rete non comporta inefficienze
sulle prestazioni del bonding.
Sia nel primo che nel secondo test si nota una discrepanza fissa fra il throughput aggregato di rete dei due disk server (indicato come aggregato-recv in
entrambi i grafici) e il throughput in lettura del disco, sempre aggregato. La
differenza è dovuta al fatto che la quantità di byte letti dal disco ed inviati
sulla rete non è la stessa, per via degli overhead dei protocolli di rete.
Il frame ethernet inviato sulla rete è costituito dai seguienti campi:
• header Ethernet: il protocollo utilizza un header di 14 byte
56
Figura 7.9: lettura da parte di otto client di uno stesso file su farm1 dev
• header IP: nella versione IPv4, quella utilizzata, consiste di 20 byte
• header TCP: questo è costituito dai 20 byte standard più 14 Byte di parte opzionale (2 byte di NOOP e una coppia di 6 byte per il timestamp),
il cui utilizzo è stato verificato tramite l’utility tcpdump
• campo dati: questo campo contiene i dati che vengono letti da disco ed
inviati alla applicazione remota, ed è costituito da 1446 byte
• trailer Ethernet: costituito da 4 byte di Frame Check Sequence
L’overhead totale dovuto ai protocolli di rete risulta quindi di 72 byte sui
1518 trasmessi verso i client, cioè pari a circa il 5%, esattamente lo scarto fra
i valori misurati nei test.
7.6
57
Considerazioni sui test con accesso al disco
La serie di misure effettuate dimostra che la tecnologia del port trunking permette di ottenere prestazioni eccellenti sulla rete anche in associazione ad un
elevato I/O di accesso al disco.
L’architettura ed il dimensionamento dei server disponibili sulla infrastruttura di produzione sono idonei a sostenere questo throughput, sia per la banda
passante offerta dalle schede che per la potenza di CPU disponibile sui server,
che non sono mai andati in sofferenza.
Per poter sfruttare opportunamente la banda disponibile si devono tuttavia
considerare attentamente tutti i fattori che concorrono a limitarne l’efficienza. Nella configurazione locale, ad esempio, una errata configurazione dei
volumi e dei file system comporta una perdita del 13% rispetto alla configurazione bilanciata.
Inoltre gli ultimi test hanno mostrato che, sfruttando la cache del controller, le prestazioni arrivino a saturare tutte le interfacce disponibili; questo
implicitamente significa che nei test precedenti il limite reale è costituito
dall’accesso fisico ai dati sui dischi. Anche questo è un fattore da tenere
in considerazione per realizzare un sistema ad alte prestazioni: è necessario parallelizzare gli accessi ai volumi per poter raggiungere le prestazioni
desiderate.
Capitolo 8
Conclusioni
8.1
Algoritmo di smistamento
La scelta dell’algoritmo di smistamento per il bilanciamento è ricaduta su
L2-L3 per quanto concerne lo switch ed L2-L3-L4 per il modulo del bonding.
Il solo utilizzo degli indirizzi di livello 2, infatti, anche se teoricamente garantisce il bilanciamento, nella rete di studio non era applicabile per la presenza
di soli MAC Address pari e per la difficoltà di tener conto nell’economia di
gestione presente e futura di un evenutuale renumbering di tali indirizzi. Un
altro motivo che ha portato all’esclusione dell’algoritmo Layer 2 è stato il
traffico proveniente dalla WAN1 i cui pacchetti, per via dell’operazione di
rotazione effettuata dal router, assumevano come indirizzo sorgente il MAC
Address di quest’ultimo, impedendo cosı̀ il bilanciamento.
8.2
Protocollo di gestione delle interfacce
Per il protocollo invece, la scelta è ricaduta sull’802.3ad perché più sicuro
della versione statica: la negoziazione con la controparte infatti, impedisce
che eventuali errori di configurazione o collegamento dei cavi portino a mal1
Ma più in generale il traffico passante per il router.
Capitolo 8. Conclusioni
59
funzionamenti che potrebbero ripercuotersi sull’intera rete locale, evento mai
auspicabile, tantomeno su un’infrastruttura di rete in produzione, come nel
nostro caso.
8.3
Sistema di monitoraggio delle interfacce
Per quello che riguarda il sistema di monitoraggio delle interfacce dell’host
con il modulo del bonding, è stata esclusa la soluzione che fa uso di pacchetti Arp la quale, in presenza di traffico non bilanciato dove uno o più
link non vengono utilizzati, porterebbe a considerare in fallimento anche i
link inutilizzati ma funzionanti, per l’assenza di Arp Reply su di essi. Si
è invece preferito il mii-monitoring che agisce a livello di interfaccia di rete
monitorandone lo stato reale, aspetto che lo rende decisamente più affidabile.
8.4
Test sugli host farm
Le prove, di tipo memory to memory, condotte sulle infrastrutture di test hanno confermato come il comportamento sia effettivamente conforme a
quanto la tecnologia promette, sia per quanto riguarda il bilanciamento, sia
per la fault-tolerance, sia per l’aumento del throughput. I test condotti su
queste macchine dedicate erano volti alla valutazione della sola tecnologia,
escludendo per quanto possibile altri fattori esterni, quali l’accesso disco o
l’utilizzo massivo della rete da parte di terzi, requisiti impossibili da ottenere
in una rete in produzione.
8.5
Test sull’infrastruttura in produzione
I test sulle infrastrutture in produzione, con accesso al sistema di storage,
mostrano come sia possibile raddoppiare la banda disponibile verso il file
Capitolo 8. Conclusioni
60
system fino a raggiungere la velocità di 470 MB/s2 . Si evidenzia anche come
per ottenere le massime prestazioni la configurazione debba essere effettuata
con cura (ad esempio per quel che riguarda il bilanciamento del throughput
verso gli NSD) in quanto sono molti i fattori che concorrono e una loro scelta
non oculata può impedire di sfruttare appieno le potenzialità offerte dalla
tencologia di bonding.
8.6
Valutazione conclusiva
La tecnologia in esame si è rivelata a tal punto soddisfacente per quel che
concerne gli aspetti di affidabilità, bilanciamento del traffico e aumento del
throughput che la configurazione, utilizzata per condurre i test e le sperimentazioni del presente lavoro, è stata mantenuta ed è tutt’ora utilizzata dai
sistemi di storage in produzione della sezione di Genova dell’INFN.
2
circa 3,7 Gbps
Appendice A
RAID
RAID (Redundant Array of Independent Disks): metodologia Hardware
e Software di organizzazione dei dischi al fine di aumentarne l’affidabilità,
la tolleranza ai guasti e l’efficienza. Vi sono diverse tipolgie che pongono maggiormente l’accento su uno degli aspetti sopra elencati, vedremo le
principali
RAID 0 detto anche striping, partiziona i dati in segmenti di uguale dimensione e sceglie il disco su cui scrivere secondo una politica di alternanza
Round Robin. In questo modo si aumenta l’efficienza, si dimunisce l’affidabilità (si moltiplicano i punti di fallimento, ognuno dei quali porta
potenzialmente alla perdita dell’intero file system) e non v’è alcuna
ridondanza o controllo di parità sui dati.
RAID 1 detto anche mirroring, implementato mediante la replicazione totale dei dati su un altro disco, aumentando cosı̀ l’affidabilità grazie alla
ridondanza completa che comporta però un impiego di memoria pari
al doppio di quanto richiesto dai soli dati. Anche l’efficienza aumenta
poiché è spesso supportata la lettura da entrambi i dischi in parallelo.
RAID 2 la divisione dei dati avviene a livello di singolo bit, e la replicazione
Appendice A. RAID
62
è affiancata dal codice di Hamming, in grado di correggere un errore su
un singolo bit e di rilevare errori su due.
RAID 3 suddivisione in byte, necessita di un numero minimo di 3 dischi, 2
per i dati e un terzo per la parità, raramente utilizzato perché richiede
l’uso di tutti i dischi contemporaneamente in caso di lettura dati.
RAID 4 suddivisione in blocchi, anche qui su N dischi, N-1 conterranno dati
(non replicati) e il disco rimanente sarà usato per la parità. Poiché la
suddivisione avviene a blocchi interi, una richiesta su un singolo blocco
potrà essere soddisfatta da un solo disco e, se supportato, permettere
letture in parallelo su blocchi che risiedono su altri dischi.
RAID 5 anche in questo caso il partizionamento è effettuato a blocchi con
dati di parità, suddivisi però sui vari dischi. Tutti i blocchi sui vari
dischi sono idealmente numerati e quelli che condividono lo stesso numero sui diversi dischi appartengono ad una stripe. Per ogni stripe è
presente un blocco di parità, che non risiede sempre sullo stesso disco.
Ad ogni modifica di un blocco di una stripe, ne viene ricalcolata la
parità che va a sovrascrivere la precedente.
Data la block size (dimensione del blocco) e il numero di dischi in RAID
viene definita la stripe-size, ovvero la grandezza di una singola stripe:
stripe-size = block-size ∗ (N − 1)
dove N è il numero dei dischi, a cui viene sottratto il blocco con i dati
di parità.
Questa quantità è importante per l’ottimizzazione in scrittura, in quanto scrivere un insieme di dati con grandezza pari alla stripe-size è l’unico
Appendice A. RAID
63
modo che il sistema ha per poter calcolare preventivamente la parità e
scrivere in contemporanea su tutti i dischi, senza far precedere l’operazione di scrittura da una di lettura del sottoinsieme della stripe che
non verrebbe sovrascritto.
In lettura, invece, il blocco di parità non viene letto, a meno di errori CRC sui dati, che imporrebbero un ricalcolo, se possibile, dei dati
danneggiati mediante gli altri blocchi unitamente a quelli di parità, celando cosı̀ eventuali malfunzionamenti (rilevabili mediante diagnostica
o dall’inevitabile calo di prestazioni).
Alla rottura di un secondo disco però i dati non saranno più recuperabili.
RAID 6 corrisponde al RAID 5, con l’aggiunta di un ulteriore blocco di parità per ogni stripe per aumentare l’affidabilità, basandosi sul fatto che
la probabilità di rottura di un secondo disco nell’intervallo che va dalla
rottura del primo alla scoperta di quanto accaduto sia relativamente
bassa, anche se influenzata da moltissimi fattori. In questo modo su N
dischi impiegati, N-2 conterranno dati e i rimanenti parità (anche se i
blocchi sono suddivisi fra tutti i dischi).
Appendice B
Approfondimento su alcune
tipologie di test di netperf
• TCP RR: permette di misurare il tempo necessario a ricevere una risposta (Response) ad un’interrogazione (Request), che è detto Round
Trip Time. La dimensione dei pacchetti utilizzati come interrogazione
e risposta sono impostati di default a 1 Byte, anche se può essere specificata. La grandezza del buffer per il socket sarà quella di default per
il sistema se non indicato esplicitamente dall’utilizzatore.
Opzioni utili:
-r sizespec permette di cambiare la dimensione dei pacchetti Request/Response
-l value se value è maggiore di zero indica la durata in secondi del test,
altrimenti il numero di transizioni (intese come invio di richiesta
e ricezione di risposta) che saranno effettuate
-s sizespec imposta la grandezza del buffer del socket (sia in ricezione
che in trasmissione)
Appendice B. Approfondimento su alcune tipologie di test di netperf
65
-S sizespec analogo al precedente ma relativo ai buffer dell’host remoto
-D imposta il flag TCP NODELAY (attivando il flag PUSH nell’header dei pacchetti TCP che indica di non aspettare di riempire il
buffer in invio prima di spedire i dati) sia sull’host locale che su
quello remoto
È da notare però che essendo TCP un protocollo stream e non a messaggi può essere necessario iterare il processo di ricezione fino a ricevere
l’intero pacchetto (non azzerando il puntatore del buffer del socket ma
incrementandolo ogni volta per non sovrascrivere i dati letti fino a quel
momento).
• UDP RR: analogo a TCP RR ma con l’assenza del flag -D, in quanto
privo di senso per il protocollo UDP.
• TCP MAERTS: questa tipologia di test invoca lo stesso script che gestisce TCP STREAM, ma in questo caso il flusso di dati procede da
netserver verso netperf (cioè dall’host remoto verso la macchina locale
su cui è lanciato il test), contrariamente a quanto avveniva con TCP STREAM.
Questa particolarità può essere utile per testare la rete dopo la modifica di parametri dell’elaboratore verso cui è destinato il flusso dei
dati (che essendo la macchina locale evita di ricorrere a rsh o similari
per modificare i parametri e per lanciare il test).
Appendice C
Dettaglio sui parametri del
modulo
arp interval: intervallo in millisecondi dopo cui un link è considerato in
fallimento se non ha ricevuto alcun ARP Reply. Per questo motivo
è adatto esclusivamente per algoritmi di smistamento dei pacchetti di
tipo “fair” fra i link, come ad esempio il Round Robin (alterna i vari
link per l’invio di ogni frame). In caso si utilizzi un algoritmo basato su
uno XOR fra gli indirizzi di livello 2 è altamente probabile che tutto il
traffico converga su un unico link, comprese le ARP Reply, portando in
questo modo a considerare in fallimento tutti gli altri link. Se impostato
a 0 questo metodo di controllo dello stato dei link viene disabilitato.
Valore di Default: 0
arp ip target: quando arp interval ha un valore maggiore di zero esso rappresenta la macchina verso cui effettuare l’ARP Request. Il formato
atteso è di tipo ddd.ddd.ddd.ddd e più indirizzi vanno separati da virgola, per un massimo di 16.
Valore di Default: nessun indirizzo IP
downdelay/updelay: ritardo temporale in millisecondi dopo cui riflettere
Appendice C. Dettaglio sui parametri del modulo
67
il cambio di stato di un link, dev’essere un multiplo del parametro miimon, altrimenti verrà approssimato automaticamente. Specificare un
valore maggiore di zero può essere sensato in caso si utilizzi dell’hardware che effettui diverse transizioni di stato prima di stabilizzarsi in
quello effettivo, come può ad esempio accadere durante l’avvio di uno
switch.
lacp rate: indica la frequenza di invio di pacchetti Lacp. I valori ammessi
sono 0 (slow, un LACPDU ogni 30 secondi) e 1 (fast, un pacchetto ogni
secondo).
max bonds: numero di interfacce di rete virtuali gestite dall’istanza corrente del driver di bonding.
miimon: indica la frequenza in millisecondi con cui verrà invocato il MII
link monitoring, ovvero il controllo di stato del link. Indicando 0 come
valore il monitor verrà disabilitato. Specificare un numero troppo basso
(ovvero inferiore a 100) si può incorrere in un degrado delle prestazioni.
È inoltre da ricordare che il suo utilizzo è mutuamente esclusivo con
quello dell’ARP Monitor.
primary: permette di specificare come prioritaria una particolare interfaccia. In caso quest’interfaccia subisca un failover (link in fallimento)
e successivamente ritorni disponibile, allora verrà reintegrata come interfaccia primaria per lo smistamento del traffico. Questo parametro
è sensato solo con la modalità active-backup ed è utile quanto si ha
68
un link preferibile agli altri sotto qualche aspetto (come ad esempio il
throughput).
use carrier: in caso miimon abbia un valore maggiore di zero questo parametro indicherà l’applicazione da utilizzare come monitor dello status
dei link. I valori ammessi sono 0 per il deprecato MII or ETHTOOL
ioctls e 1 per netif carrier ok(). In caso il driver della NIC utilizzata
non supporti netif carrier ok(), questo mostrerà l’interfaccia come attiva indipendentemente dallo stato reale poiché questo è il risultato di
default per l’applicazione. Per testare lo stato dell’interfaccia di rete si
può ricorrere all’utility mii-tool, ecco un esempio di output:
eth0: negotiated 100baseTx-FD flow-control, link ok
eth1: no link
Prima di impostare il parametro use carrier è bene controllare lo stato dell’interfaccia mediante mii-tool per verificare che esso sia rilevato
correttamente.
In alternativa, per verificare il supporto MII, si può anche ricorrere
ad ethtool, con il seguente comando:
ethtool eth? | grep "Link detected"
dove eth? sta per il nome dell’interfaccia di rete per cui si vuole effettuare il controllo.
mode: Questo parametro prende come valore una stringa con il nome della
69
modalità oppure il numero intero ad essa associato, nell’ordine in cui
sono riportati nella lista.
0. balance-rr:
questa modalità implementa lo smistamento dei pacchetti seguendo una politica Round Robin, cioè selezionando ciclicamente, dalla prima all’ultima, un fra le interfacce disponibili per l’inivio. In
questo modo sono garantiti sia il bilanciamento del carico che la
tolleranza ai guasti.
1. active-backup:
ad ogni istante solo una delle interfacce disponibili è realmente
utilizzata per l’inivio e la ricezione. In caso di un suo fallimento
una tra le altre disponibili verrà scelta per rimpiazzarla (la quale
sarà preferenzialmente quella specificata attraverso il parametro
“primary”). Con questa modalità è garantita la sola tolleranza ai
guasti mentre si perdono i miglioramenti di throughput ottenibili
mediante il bonding.
2. balance-xor:
l’interfaccia su cui inviare un frame è scelta, di default, in base
alla seguente formula
(S M AC ⊕ D M AC) % slave count
dove,
- S MAC: MAC Address dell’interfaccia di bonding
- D MAC: MAC Address dell’interfaccia della macchina remota
- slave count: numero delle interfacce di rete aggregate
70
Durante la stessa connessione le due macchine non cambiano, come nemmeno i due MAC Address, perciò il risultato della formula
sarà costante e verrà perciò utilizzata sempre una data interfaccia
per la stessa connessione.
È però possibile utilizzare un calcolo diverso per la scelta dell’interfaccia su cui trasmettere, modificando il valore del parametro
xmit hash policy.
Questo modalità assicura bilanciamento e fault-tolerance.
3. broadcast:
tutto il traffico viene replicato su ognuna delle interfacce di rete
disponibili, garantendo cosı̀ la fault-tolerance ma non aumentando
il throughput “utile”1 .
4. 802.3ad:
è un’implementazione dello standard IEEE detto “Dynamic Link
Aggregation”2 .
Come prescritto dallo standard, le porte da aggregare devono avere la stessa velocità e la stessa modalità per il duplex, non sono
perciò consentiti aggregati eterogenei sotto questi aspetti.
L’interfaccia in uscita per un frame è nuovamente determinata da
un calcolo effettuato in base alla xmit hash policy scelta.
Prerequisiti per l’utilizzo:
- Supporto di EthTool da parte dei driver per verificare la velocità e le impostazioni duplex per le interfacce.
1
non aumenta infatti l’apporto informativo poiché, nonostante il volume di traffico
aumenti, non si ha maggiore informazione ma solo una sua replicazione
2
Le specifiche sono disponibili in [8]
71
- Uno switch che supporti l’802.3ad, eventualmente da configurare3 .
5. balance-tlb:
questa modalità implementa una trasmissione adattiva con bilanciamento del carico ma, a differenza della 802.3ad, non è imposto
nessun vincolo per quanto riguarda lo switch.
La ripartizione del carico in uscita avviene cercando di bilanciarlo, calcolandolo per ciascuna interfaccia in proporzione alla sua
capacità trasmissiva.
In caso un link fallisca, per non perdere la comunicazione, un altro fra i disponibili assumerà dinamicamente il suo MAC Address.
Prerequisiti per l’utilizzo:
- Supporto di EthTool da parte dei driver per verificare la velocità e le impostazioni duplex per le interfacce.
- Interfacce di rete dotate di driver in grado di cambiare dinamicamente il MAC Address.
6. balance-alb:
come il balance-tlb per il traffico in uscita, con l’aggiunta del bilanciamento anche per il flusso dati in ingresso4 .
Il driver del bonding intercetta le APR Reply della macchina su
cui gira sovrascrivendone il MAC Address con quello di una delle
interfacce aggregate, cambiata ogni volta con politica Round Robin, cosı̀ da ripartire i diversi client sui diversi link.
Il bilanciamento in ricezione è altresı̀ possibile per le connessioni
3
Alla sezione 3.2 di pagina 13 è riportata la procedura di configurazione dello switch
della rete di studio.
4
solo per il tipo IPV4
72
stabilite da un host remoto; ad ogni invio dalla macchina locale di
un ARP Request il driver salverà l’IP della macchina che si vuole contattare e quando arriverà un ARP Reply da una macchina
con l’IP memorizzato invierà a sua volta un ARP Reply a quella
macchina con il MAC Address di una delle interfacce aggregate.
Il fatto che le ARP Request della macchina in bonding riportino
tutte il MAC Address dell’interfaccia virtuale porta a far collassare il traffico sull’interfaccia reale che possiede quel MAC, ma
il problema è aggirabile aggiornando le informazioni nelle cache
delle macchine remote con un ulteriore ARP Reply. Allo stesso
modo, quando un’interfaccia in fallimento torna attiva, il traffico
viene redistribuito anche su di essa sempre tramite una negoziazione ARP.
Si deve però notare che per contrastare l’ARP Cache Poisoning 5
molti sistemi ignorano pacchetti con informazioni ARP provenienti da macchine con cui non hanno richieste pendenti.
Valore di Default: 0 (ovvero balance-rr)
xmit hash policy: Permette di scegliere la formula per calcolare l’interfaccia di rete da utilizzare in uscita con le seguenti modalità
1. layer2: vedi parametro mode, valore balance-xor
Si sottolinea che questo metodo di calcolo è conforme allo standard
802.3ad
2. layer3+4:
questa politica di scelta utilizza informazioni dei livelli superiori,
5
tecnica di attacco informatico
73
ovvero gli indirizzi IP e le porte, mediante la formula
((S P ORT ⊕ D P ORT ) ⊕ ((S IP ⊕ D IP ) ⊕ 0xffff)) % slave count
dove,
- S PORT: porta della macchina sorgente
- D PORT: porta della macchina di destinazione
- S IP: indirizzo IP della macchina sorgente
- D IP: indirizzo IP della macchina di destinazione
- slave count: numero delle interfacce aggregate e al momento
disponibili
È da notare che il traffico UDP e TCP frammentato sia privo delle
informazioni riguardanti le porte6 e che per tutto il traffico che
non utilizza pacchetti IP viene in ogni caso utilizzata la formula
relativa agli indirizzi di livello 2.
Valore di Default: 0 (layer2)
6
presenti solo nel primo frammento
Appendice D
Riepilogo per la scelta della
modalità di bonding
• Come si è cercato di evidenziare nell’Appendice C, la scelta dell’algoritmo di gestione delle interfacce e quello di smistamento dei pacchetti
sono cruciali per adattare la tecnologia in esame alle necessità di una
specifica rete. Per individuare la configurazione più adatta bisogna
anzitutto individuare quali aspetti vadano privilegiati fra:
Affidabilità: è necessario scegliere con accuratezza fra la soluzione
mediante monitor ARP e quella tramite il monitoraggio delle NIC
dei singoli link. La prima soluzione non è però applicabile quando
tutte le interfacce dell’host in bonding sono connesse ad un’unico
apparato di rete intermedio (quale ad esempio uno switch), come già sottolineato all’Appendice C relativamente al parametro
arp interval .
Per quanto riguarda le modalità di gestione delle interfacce bisogna procedere ad un distinguo fra due casi, uno in cui l’host in
bonding sia connesso ad un solo apparato di rete (o direttamen-
Appendice D. Riepilogo per la scelta della modalità di bonding
75
te alla macchina di destinazione), un altro in cui la macchina sia
connessa ad entità intermedie indipendenti fra loro.
1. Nel primo caso, per quanto concerne la sola affidabilità, le
modalità applicabili sono indifferentemente la balance-xor, la
802.3ad, la balance-tlb e la balance-alb, poiché tutte in grado di
ripartire il traffico fra le interfacce attive quando viene rilevato
un link in fallimento.
2. Nel secondo caso può invece essere conveniente adottare la
modalità active-backup, la quale prevede l’utilizzo attivo di
una sola interfaccia in ogni singolo istante, tenendo come altenativa le restanti intefacce aggregate. Se queste connettono l’host ad altri switch, ad esempio, un fallimento del link
primario dovuto ad un problema dell’entità a cui è collegato potrebbe evitare l’isolamento della macchina senza alcun
degrado di prestazioni rilevabile.
La prima soluzione permette di aumentare il throughput ma può
gestire solo fallimenti a livello di interfaccia, la seconda non aumenta la performance ma, se unita all’utilizzo di più apparati di
rete intermedi indipendenti fra loro, si rivela molto più robusta
della precedente.
Ridondanza: l’unica modalità in grado di assicurare una ridondanza
totale senza attendere il fallimento di alcun link è la broadcast,
la quale replica lo stesso flusso su tutte le interfacce aggregate, a
detrimento però delle performance.
Performance: sotto questo aspetto non vi sono evidenti differenze fra
le varie modalità, ad eccezione di active-backup e broadcast per cui
Appendice D. Riepilogo per la scelta della modalità di bonding
76
il limite massimo di velocità raggiungibile è pari a quello di una
singola interfaccia.
Bilanciamento: il bilanciamento totale si ha per mezzo della modalità
balance-rr che alterna con politica Round Robin fra le varie interfacce, perdendo però la caratteristica di trasmettere i pacchetti di
una stessa connessione sullo stesso link.
Compatibilità:
- la modalità 802.3ad prevede una fase di dialogo con la controparte che preceda il reale invio di dati, questo impone un
supporto del protocollo da parte dell’entità a cui l’host in
bonding è connesso.
- balace-tlb necessita che Ethtool supporti il driver delle varie interfacce di rete, come già mostrato in Appendice C a
pagina 66.
- balance-alb questa modalità ha lo stesso requisito della precedente a cui va però aggiunta anche la capacità da parte
del driver di cambiare dinamicamente l’indirizzo fisico delle
interfacce utilizzate.
Bibliografia
[1] Fibre Channel Industry Association (FCIA).
http://www.fibrechannel.org/
[2] Scientific Linux CERN 4 (SLC4).
http://linux.web.cern.ch/linux/scientific4/
[3] Scientific Linux (SL).
https://www.scientificlinux.org/
[4] General Parallel File System (GPFS).
http://www-03.ibm.com/systems/clusters/software/gpfs/
[5] IEEE 802.1Q Standards for Local and metropolitan area networks: Virtual Bridged Local Area Networks (’03).
http://standards.ieee.org/getieee802/download/802.1Q-2003.pdf
[6] Netperf.
http://www.netperf.org/netperf/
[7] Dstat.
http://dag.wieers.com/home-made/dstat/
[8] Netperf.
http://www.netperf.org/netperf/
BIBLIOGRAFIA
78
[9] ExtremeWare XOS 11.3 Concepts Guide (’03).
http://www.extremenetworks.com/libraries/services/ExtremeWareXOSConcepts11 3.pdf
[10] Documentazione driver Bonding per Linux.
http://www.linuxfoundation.org/en/Net:Bonding
[11] Netperf manual revision 2.0, Information Network Division, Hewlett
Packard
http://www.netperf.org/netperf/training/Netperf.html

Link Aggregation - Istituto Nazionale di Fisica Nucleare

Transcript

Documenti analoghi

Figura 1-6: Immagine dell`interfaccia del Norton Antivirus, in questa

Permettere ad utenti non esperti di eseguire procedure di STATA

Locandina - Scuola Superiore di Catania

Switch VGA 4-porte Il VS491 è uno switch video a 4 porte che

Product datasheet

Channel Bonding per il Cluster Arcosu

Bonding Agent

La VPN SSL di Juniper in 6 slide

BONDIG Istruzioni

Capitale sociale: ci vuole un giusto equilibrio