Una panoramica sul mondo della Sicurezza Informatica, del Networking, della Virtualizzazione e non solo. Blog particolarmente indicato per i reparti IT che comunque alterna articoli scritti per specialisti con articoli formulati con linguaggio semplice e comprensibile a tutti.

Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

lunedì 14 novembre 2016

Architetture di collegamento: Fibre Channel su multi controller e RoundRobin

Quando ci si trova ad implementare uno storage collegato ad un'infrastruttura, soprattutto se virtuale, le performance divengono fondamentali. Spesso ci si domanda quale architettura seguire, quali sono le Best Practices e quale scenario è in grado, ad esempio, di sfruttare al massimo le performance di un array full SSD.

In passato abbiamo trattato alcuni temi, la cui lettura facilita la comprensione di questo articolo di approfondimento:


Immaginiamo di avere due scenari di questo tipo


Uno in iSCSI con 2 porte a 10Gbit con supporto TOE (per host) ed uno in Fibre Channel con 2 porte 8Gb (per host), in entrambi i casi in Direch Attach sulla SAN.

Qual è il metodo più conveniente per interconnettere gli apparati?


iSCSI con singolo controller


Dai test che abbiamo effettuato, quando è presente un solo controller, il metodo migliore per collegare gli host è in RoundRobin utilizzando la relativa funzione presente nel path manager di vmware.


In media è stato raggiunto un risultato di circa il 13% più performante rispetto al path singolo con il secondario in standby.



FC con singolo controller


Similarmente a quanto accade in ambito iSCSI, il collegamento in FC beneficia del meccanismo di distribuzione tipico del RoundRobin, ma in maniera persino superiore (22% rispetto al singolo path). Questo perchè l'overhead generato dal protocollo TCP in ambiente iSCSI probabilmente vanifica in parte il vantaggio di avere due percorsi bilanciati.



iSCSI e FC con doppio controller


Qui abbiamo una sorpresa. Qualora la SAN possieda due controller, utilizzare il RoundRobin comporta un rallentamento con entrambe le tecnologie rispetto ad un path singolo. Presupponendo di aver effettuato una pianificazione corretta, ovvero HBA1 su Controller1 e HBA2 su Controller2, il bilanciamento del carico impegna entrambi i controller che, nella realtà, perderanno tempo a ricostruire il flusso di informazioni che vengono loro richieste.
Abbiamo, sostanzialmente, creato un collo di bottiglia causato dal coinvolgimento dei due controller in un impegnativo stream ciclico (Ctrl1-Ctrl2-Ctrl1-Ctrl2...). Il RoundRobin non è, in questo scenario, conveniente.



Best Practices per incrementare le performance con SAN avente due o più controller

Abbiamo stabilito, quindi, che il meccanismo di bilanciamento RoundRobin è utile in caso di singolo controller perchè massimizza la parte network, ma è sfavorevole per gli scenari in cui la SAN abbia più controller perchè costringe questi ultimi ad un lavoro supplementare di interfacciamento tra di essi. Lavoro, questo, in grado di vanificare il vantaggio della doppia disponibilità di banda. 
Come fare, quindi? E' sufficientemente banale, creare più LUN e distribuirle lungo i path.
Come sappiamo, i path vengono gestiti per ogni LUN, quindi la creazione di N LUN scatenerà Nx2 path per host (nel nostro caso). A questo punto all'interno della SAN potremo definire il controller owner, ovvero il controller che prende in primis in carico la LUN e la presenta agli altri controller. Strutturando correttamente questa fase, sarà possibile avere un path primario per LUN, che coinciderà con il controller owner, e bilanciarne quindi i path in maniera manuale.

Proviamo a fare un esempio immaginando di aver creato 2 LUN:

La prima LUN è presentata dal controller 1, quindi noi utilizzeremo il path 1 con il 2 silente, pronto ad intervenire in caso di backup.


La seconda LUN, pariteticamente, viene gestita dal controller 2 utilizzando il path 2 (sullo stesso host, ovviamente).

Così facendo avremo naturalmente bilanciato i carichi utilizzando due path diversi su due LUN diverse. L'impegno dei controller sarà minimo perchè ognuno gestirà la sua owned LUN senza necessitare di impegnativi flussi di comunicazione come nel caso in cui venga utilizzato un RoundRobin su due controller differenti.

Lo scenario RoundRobin sullo stesso controller, ovviamente e per ovvie ragioni di inaffidabilità, non è stato contemplato perchè insicuro.


Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.