martedì 31 marzo 2015

“Native” or “Not Native” MultiPath Software.. that is the question!!!

Finita la spesa al Supermercato il desiderio maggiore del Cliente è quello di pagare velocemente e potersene tornare a casa il prima possibile; ed è proprio in quest’ottica che la scelta della fila a cui accodarsi tra le n casse del supermercato diventa cruciale e decisiva.

A questo punto immaginate un Cliente che senza neanche riflettere si accoda alla prima fila che incontra; al contrario immaginate un secondo Cliente, più smaliziato, che in pochi secondi, dopo un rapido sguardo esplorativo, sceglie deliberatamente di mettersi in coda in una specifica fila dopo aver tenuto in considerazione il numero di persone nelle diverse file, la loro età (le persone anziane impiegherebbero certamente più tempo nel trasferire le cose acquistate sul nastro trasportatore), il numero e la dimensione dei “pezzi” all’interno dei vari carrelli o dei cestini, etc..

Nella maggioranza dei casi il secondo Cliente impiegherà certamente meno tempo e lasciando il supermercato si compiacerà con se stesso per la scelta fatta in precedenza.

Questo è un ottimo esempio per fare riflettere gli Storage Admin e gli IT Architect sull’importanza della giusta scelta del Software di MultiPath, di quel software che spesso è il primo elemento che viene sacrificato per mancanza di budget e che potrebbe ovviare o ridurre al minimo a eventuali problemi dovuti a traffico eccessivo, Path non disponibili, HBA guaste, etc..




Secondo “letteratura” i SW di MultiPath possono essere di tre tipologie differenti:

  • Active-active: le richieste di I/O possono essere inviate a una LUN mediante qualsiasi porta e path
  • Pseudo Active-Active: noto anche come ALUA (Asymmetric Logical Unit Access), i dati possono essere trasferiti mediante qualsiasi percorso, tuttavia se quello utilizzato non è ottimale, viene generato un trespass della LUN da uno storage processor ad un altro.
  • Active-Passive: i dati utilizzano un percorso active e uno passive e, in caso di errore, si abilita il path passive

Ogni tipologia di multipath, ha tipicamente diverse Path Selection Policy (PSP). Ad esempio VMware permette all’amministratore di scegliere tra 3 policy PSP:

  • Fisso: i dati vengono inviati nel percorso ottimizzato;
  • MRU (Most Recently Used): i dati vengono inviati su un path  fino a quando questo risulta disponibile. Quando il path è in failure, i dati vengono inviati sul path passive.
  • RR (Round Robin): Viene inviata una quantità fissa di dati verso un path. L’algoritmo ogni volta sceglie un path differente in maniera sequenziale.

I SW Nativi di MultiPath (MPIO) sono offerti gratuitamente all’interno dei diversi sistemi operativi degli host e sono semplici da utilizzare. Tuttavia non forniscono un bilanciamento del carico proattivo e gli amministratori sono costretti ad assegnare manualmente un determinato path per LUN. Questo inevitabilmente può creare uno sbilanciamento tra i path perché le LUN avranno in generale workload differenti.

All’interno di un DataCenter si hanno generalmente più sistemi operativi (Windows, Linux, AIX, VMware, etc..) e quindi inevitabilmente più software MPIO. Ognuno di questi avrà i suoi comandi, policy e relativa configurazione.
I Native MPIO utilizzano il Round Robin come PSP e di conseguenza:
  • Non sono prese in considerazione le code
  • Non sono considerate le attività sugli storage e sulla SAN
  • Non viene esaminato preventivamente lo stato di un path (available o failure)
Caratteristica
PowerPath
Native MPIO
Intelligent Load Balancing
Usa tutti i Path disponibili. Il bilanciamento del carico viene fatto in maniera intelligente tra i Path, considerando il carico su ciascun Path. I Path vengono trattati secondo il loro stato.
Utilizza solo il PSP Round Robin ovvero usa tutti i Path in una configurazione statica e considera tutti i Path come equivalenti (No intelligence)
Fault Intelligence
Identifica dinamicamente quali sono i Path in failure e redirige le I/O verso il Path disponibile.
I cambiamenti di stato dei Path non sono dinamicamente identificati.  Con l’unica Path Selection Policy (PSP) Round Robin, si possono selezionare “n” Path in failure prima di identificare il Path disponibile.
Optimized VNX and VMAX Algorithms
Su VMAX o VNX fornisce il load balancing ed il failover per Path multipli e gestisce il routing intelligente tra i Path analizzando: numero, size, throughput e I/O type e ritardi nelle code.
Non ha specifici algoritmi per VMAX o VNX e utilizza il solo algoritmo di Round Robin

Le differenze tra i Native MPIO (NMP) e la soluzione EMC PowerPath, porta inevitabilmente ad avere sensibili differenze di performance.

All’interno di un ambiente VMware, ESG (Enterprise Strategy Group) ha potuto registrare interessanti differenze prestazionali tra l’NMP di VMware e EMC PowerPath/VE (Virtual Edition).

L’ambiente di test è stato il seguente:



ESG Lab ha generato diversi workload attraverso Iometer: file serving, Exchange database, e 8K OLTP su entrambi I server, uno configurato con PowerPath/VE e l’altro con NMP. Allo stesso tempo, per creare contesa tra le risorse, sono stati generati carichi di backup su 5 Windows Servers. A fronte di questa contesa, PowerPath/VE ha ogni volta determinato il path corretto, mentre l’NMP server, ha utilizzato il suo PSP  Round Robin:



Gli stessi test sono stati svolti anche simulando sui server primari workload di tipo Decision Support, Exchange log, e Video-On-Demand. È stato rilevato il throughput rispetto a eventi comuni come il downloading di file di grandi dimensioni che generalmente degradano le prestazioni dell’infrastruttura. Di seguito i risultati:



A valle di quanto evidenziato, la conclusione è di conseguenza semplice: non trascurare la scelta del software di MultiPath! In generale, oltre alla continuità operativa garantita nel caso di Path indisponibili, le infrastrutture IT, grazie all’utilizzo di PowerPath, non potranno che trarne giovamenti da un punto di vista prestazionale.

Buona Spesa a Tutti!!!

Gianluca Carbone (Account Systems Engineer) - Twitter @GLCarbone
Diego Ricci
(Account Systems EngineerTwitter @Dieguito83


Nessun commento:

Posta un commento