Tutto ciò che i nostri partner devono sapere per posizionare, dimensionare e realizzare un progetto active cluster
Active Cluster è la soluzione Pure Storage per creare in modo semplice una Business Continuity, in grado di garantire il massimo livello di servizio applicativo. Diversamente da molte soluzioni sul mercato, Active Cluster è in grado di garantire un accesso active/active sullo stesso volume in entrambi i siti, senza HW o SW aggiuntivi. Le applicazioni saranno quindi “convinte” di lavorare su volumi residenti in un singolo sito, quando invece sono “stretched” in due siti diversi. Il risultato è la flessibilità di poter bilanciare carichi applicativi tra siti diversi senza dare disservizio; considerando un ambiente virtualizzato basta una vmotion per spostare un servizio senza spegnerlo, oppure avviarlo nuovamente in automatico a fronte di un problema su un server ESX, semplicemente con VMWARE HA (High Availability) invece di dover usare VMWARE SRM (Site Recovery Manager).
Un’altra peculiarità di Active Cluster consiste nel poter utilizzare Pure1 Cloud Mediator per gestire tutti gli scenari di fallimento in maniera automatica. Solitamente le soluzioni di Business Continuity hanno necessità di una Virtual Machine o di un Volume in un terzo sito per gestire correttamente i failover applicativi mentre Active Cluster, grazie a Pure1 Cloud Mediator, offre questo servizio incluso nel prezzo: un bel vantaggio per il cliente che non ha un terzo sito di controllo.
Riepiloghiamo ora le caratteristiche di differenziazione di Active Cluster rispetto alle altre soluzioni esistenti:
- Accesso active/active ai volumi, in modo trasparente da entrambi i siti.
- Gestione degli scenari di fallimento e di riallineamento replica senza necessità di interventi manuali.
- Possibilità di replica asincrona verso un terzo sito.
- Nessuna licenza richiesta o ulteriore HW necessario
- Cloud Mediator incluso
Ora che abbiamo correttamente posizionato la soluzione, vediamo come dimensionarla correttamente.
Grazie al nostro Sizing Tool, accessibile anche dai nostri partner, è possibile dimensionare una configurazione active cluster, in termini di spazio e performance richiesti.
Cosa succede se il vincolo di replica sincrona viene meno per motivi esterni (rete, connettività WAN etc,?) semplicemente il cluster comincia ad utilizzare il meccanismo di replica asincrona per riallineare il cluster fino a dare il via alla replica sincrona. Il valore di questa caratteristica consiste nel fatto che un cliente o il partner fa managed services non dovrà svegliarsi di notte per riallineare le repliche o eseguire un tuning di banda per garantire il servizio.
Come calcolo quindi questo spazio che toglie diversi mal di testa? La strada è in discesa: sarà sufficiente attivare il flag corretto nel tab Active Cluster per fare in modo che il configuratore tenga conto dei valori necessari per le snapshot.
Per ogni dimensionamento applicativo il Sizing Tool mi permette di includere crescita, policy di snapshot, configurazioni stretched con Active Cluster, configurazioni in replica asincrona. I nostri partner quindi non devono preoccuparsi di effettuare calcoli complicati: questo tool li fa per loro!
Una volta definiti i modelli e le configurazioni degli array in gioco, vediamo quali sono i requisiti per configurare la soluzione presso il cliente.
Per prima cosa devo eseguire il setup di entrambi i FlashArray; nel caso in cui il primo storage sia già in produzione, sarà sufficiente eseguire la configurazione del secondo: active cluster può infatti estendere una configurazione iniziale single-site senza dare impatti alla produzione in essere.
Poiché devo mettere in replica sincrona i volumi applicativi, è necessario assicurarsi che i requisiti della rete di interconnessione tra i due siti siano soddisfatti. Active Cluster ha requisiti mediamente inferiori alle altre soluzioni di Business Continuity: il primo di questi è relativo a RTT (Round Trip Time) inferiore a 11ms. Questo solitamente non è un grosso vincolo (VMWARE supporta soluzioni stretched con RTT inferiore a 10ms ad esempio). Ovviamente devo anche assicurarmi di avere una banda disponibile almeno pari ai massimi valori di scrittura applicativi, in modo da non avere penalizzazioni dovute alla sincronia (in tutte le repliche sincrone l’acknowledge di avvenuta scrittura del dato viene inviato solo se questo è stato correttamente salvato in entrambi i siti, per cui alte latenze di rete rallentano questa operazione, producendo lentezze applicative).
Per attivare una configurazione Active Cluster devo attivare le 4 porte di replica sugli array, disponendo quindi degli indirizzi IP e delle relative informazioni di rete, e devo aver attivato tutte e 4 le interfacce di management di ciascun array; anche in questo caso devo disporre delle informazioni per configurare opportunamente i parametri di rete.
Un’altra informazione da condividere con il cliente sono i requisiti lato firewall. Vi è la necessità di apertura della porta 8117 sulle porte di replica e la porta 443 sulle porte di management (già requisito in installazione per permettere all’array di interfacciarsi con Pure1, il nostro servizio di supporto predittivo).
Con queste informazioni e conferme da parte del cliente posso procedere alle 4 operazioni che consentono a due array di creare la Business Continuity.
- Connessione dei due array tramite GUI.
- Creazione di un POD (ovvero il gruppo di consistenza dei volumi che voglio replicare).
- Immissione o creazione di nuovi volumi all’interno del POD.
- Stretch del POD sul secondo array.
Questa operazione esegue in automatico la creazione dei volumi gemelli sul secondo array, mettendoli in relazione con i volumi appena immessi o creati all’interno del POD. A questo punto l’ultima operazione necessaria è quella di connettere anche i volumi remoti agli host, in modo che tutti i path di visibilità dei volumi vengano garantiti.
Posso ovviamente creare diversi POD per diversi gruppi applicativi e avere dei POD locali che non hanno necessità di essere replicati:
A questo punto è necessario capire lo use case del cliente: con Active Cluster ci sono diverse topologie disponibili per venire incontro a tutte le esigenze dei clienti; è possibile suddividere le applicazioni in due siti perfettamente speculari, creare configurazioni uniformi o meno e anche interconnettere un terzo sito in replica asincrona che crei un “triangolo” con i due siti in Business Continuity.
Se i due siti si trovano all’interno di un campus, posso usare una configurazione uniforme, con tutti i path verso i volumi aventi il medesimo peso. Questo permette di sfruttare al massimo il parallelismo delle letture dagli storage, con gli host utilizzanti tutti i path disponibili, come riportato nello schema seguente:
Se i due siti del cliente fossero invece a distanza metropolitana o si volessero privilegiare le letture verso i volumi locali per non creare eccessive latenze applicative è possibile implementare una configurazione uniforme con i path locali ottimizzati e i path verso il secondo sito non-ottimizzati. Gli host accederanno al dato sempre dallo storage locale e utilizzeranno i path non-ottimizzati solamente qualora i path primari non fossero disponibili.
L’ultima alternativa consiste in una configurazione non uniforme, che consente ai volumi stretched di essere acceduti e sincronizzati in entrambi i siti, ma senza condivisioni sulla SAN, ovvero senza ISL (inter switch link) tra i siti: gli host nei rispettivi siti vedranno quindi solamente i volumi dello storage locale. Gli use case per questa topologia sono per esempio: due aziende sorelle che si proteggono vicendevolmente, ma senza interferenze relativamente alle SAN, oppure configurazioni minimali, con gli array collegati direttamente (direct attach) a pochi host su ciascun sito.
Come prima accennato è possibile estendere una configurazione Active cluster in un terzo sito, collegato in replica asincrona ai primi due. Questo è uno scenario applicabile fin da subito oppure in evoluzione di una configurazione Active Cluster esistente.
Abbiamo quindi visto tutte le fasi di un progetto Active Cluster, per permettere ad un cliente di usare le caratteristiche di Business Continuity di FlashArray, estensibili anche a contesti di Disaster Recovery. In fase di proposizione, i plus di Active Cluster possono aiutare a differenziare la soluzione rispetto alle altre proposte di mercato, la fase di dimensionamento è eseguibile in modo semplice grazie ai nostri Sizing Tool e, rispettati i requisiti appena esposti per la fase di delivery, è possibile implementare diverse topologie in base alle necessità del cliente.
Quali possibili evoluzioni possiamo aspettarci da Active Cluster? Come sapete la replica di Pure è una funzione di Sistema Operativo, non richiede licenze ed è agnostica rispetto alla fabric sottostante. Per questo motivo “stay tuned” sulle nostre prossime novità in arrivo!
Sono ovviamente a disposizione per quesiti e richieste di approfondimento.
Umberto Galtarossa
Channel Technical Manager – Pure Storage Italia
@umberoot
