Azure IaaS: Gestione dell’alta Disponibilità

Autore: Daniele Grandini

La cloud pubblica in generale e Microsoft Azure in particolare stanno vivendo anche in Italia una forte espansione. Diversi possono essere gli approcci, ma la motivazione condivisa è quella di concentrare il proprio business sui servizi applicativi senza doversi preoccupare degli aspetti fisici del proprio data center. In modo particolare il primo e più semplice approccio alla cloud pubblica è lo “spostamento” delle proprie virtual machine presso il cloud provider. In sostanza si tratta di estendere il proprio data center a quello del provider sfruttando le funzionalità di Infrastructure as a Service (IaaS). È evidente che in prospettiva i massimi vantaggi si otterranno sfruttando le funzionalità di piattaforma (Platform as a Service – PaaS), ma per cogliere questa opportunità occorre modificare le applicazioni utilizzate e non sarà un processo rapido. A onor del vero le modifiche possono anche essere minimali, ma è imprescindibile la collaborazione e il supporto del produttore software.

Lo spostamento delle proprie virtual machine è dunque un primo passo che permette di dimenticarsi dei limiti fisici del proprio data center.

Spostare i propri workload su servizi IaaS pubblici impone però di pensare in modo diverso alle soluzioni scelte per i propri sistemi on-premises. In sintesi: i problemi da risolvere sono i medesimi, ma le risposte da dare cambiano. Uno degli argomenti più dibattuti è certamente come porre in alta disponibilità i propri workload sulla cloud pubblica.

Per “alta disponibilità” (high availability – HA) si intende quella caratteristica che permette ad un sistema di ripristinare i propri servizi in un tempo limitato a fronte di un fault. Tipicamente per “tempo limitato” si intende da qualche decina di secondi a qualche minuto.

Esistono tipi diversi tipi di alta disponibilità in base alla caratteristica del fault, possiamo sintetizzarli, senza voler essere esaustivi, come segue:

Alta disponibilità rispetto a fault della fabric (fault hardware)
Alta disponibilità rispetto a fault applicativi (un fault software, di configurazione, ecc.)

I sistemi di alta disponibilità implementati tramite i moderni hypervisor rispondono alla prima casistica, la seconda è indirizzata da meccanismi specifici dell’applicazione (es. SQL AlwaysOn, Exchange DAG, scaleout applicativo, bilanciatori, …).

Utilizzando Windows come sistema operativo si ha a disposizione anche un meccanismo generico di alta disponibilità costituito dal Failover Cluster. Il failover cluster può essere utilizzato per servizi o applicazioni generiche non pensate per essere poste in HA e permette alle stesse di riavviarsi su sistemi diversi a fronte di un fault.

Alta Disponibilità in Azure

Non tutti questi meccanismi di alta disponibilità hanno una corrispondenza in Azure. In primis in Azure il concetto di hypervisor in alta disponibilità è diverso da come lo sperimentiamo on-premises. In pratica a fronte di fault dell’host che sta eseguendo la Virtual Machine la stessa viene riavviata su un host differente e fin qui nulla di diverso, ma in caso di manutenzione dell’host le VM ospitate vengono semplicemente spente per il tempo necessario all’aggiornamento, tipicamente si tratta del tempo di reboot, ma questo non è pèosisbile escludere fermi più lunghi in base al tipo di aggiornamento. Questa caratteristica è declinata secondo due concetti:

Fault domain – ossia un insieme di risorse che non sono di per se stesse in alta disponibilità a fronte di un fault
Update domain – ossia un insieme di risorse la cui manutenzione può avvenire contemporaneamente

Tutti i dettagli possono essere consultati nella sezione riferimenti.

Semplificando possiamo pensare ad un fault domain come ad un rack e ad un update domain come un singolo hypervisor.

Per ottenere alta disponibilità delle virtual machine su azure occorre quindi averne almeno due per ogni ruolo e distribuirle in fault e update domain differenti.

Due aspetti da considerare:

Poter attivare più di una virtual machine per ogni ruolo è una caratteristica applicativa, se l’applicativo non ha questa possibilità di architettura, dobbiamo trovare strade diverse. Ad esempio sfruttando un Failover cluster generico.
Distribuire effettivamente le VM in fault e update domain differenti. Fortunatamente questo avviene in automatico tutte le volte che più VM all’interno del medesimo cloud service vengono inserite in Avialability Set.

Mentre l’alta disponibilità rispetto a fault della fabric su Azure segue criteri differenti rispetto a quanto è possibile realizzare on-premises, l’alta disponibilità applicativa è in generale realizzabile su Azure esattamente come on-premises, con un unico se. Il meccanismo di alta disponibilità non deve prevedere dischi condivisi, infatti non esiste su Azure la possibilità di condividere il medesimo disco tra VM differenti (ad oggi questo è vero anche per AWS e Google).

In sintesi fin tanto che l’applicativo è stateless o prevede propri meccanismi di replica del dato (es. SQL AlwaysOn Availability Groups o Exchange DAG) è possibile implementarlo su Azure esattamente nello stesso modo. Piccole differenze potranno rimanere, come ad esempio la scelta del bilanciatore, ma in sostanza il meccanismo rimane il medesimo. Se invece il meccanismo di HA prevede dischi condivisi, come è nel caso di Windows Failover Cluster per scenari “tradizionali” o “generici”, Azure (ma anche AWS) non mettono a disposizione meccanismi nativi.

Failover Cluster su Azure – SIOS Datakeeper

Purtroppo esistono ancora applicativi la cui alta disponibilità è affidata a failover cluster con dischi condivisi. Per questi scenari è però possibile ricorrere ad una terza parte come SIOS Datakeeper che permette da un lato di mantenere in replica dischi su virtual machine diverse e dall’altro di mostrare al sistema operativo un risorsa disco “clusterizzabile”. Questa soluzione è stata recentemente certificata su Azure e al momento è l’unica di mia conoscenza supportata su Azure (vedi riferimenti). Come tutte le soluzioni ha le proprie caratteristiche da tenere in considerazione in fase di progetto, l’aspetto più importante riguarda l’impatto sulle scritture.

Dal momento che in questo scenario la replica deve essere sincrona, particolare attenzione deve essere posta se l’applicativo è write intensive. Esiste infatti un impatto sulle scritture su questo tipo di risorsa dato da un lato dalla capacità del network e dall’altro dall’efficacia del software nel tracciare e replicare le scritture.

Su Azure la capacità effettiva del networking ha un livello di servizio legato alle caratteristiche della VM, questi SLA al momento non sono stati ufficialmente pubblicati, ma come regola di minima è possibile prendere a riferimento la seguente tabella:

In realtà si possono osservare throughput molto maggiori, ad esempio su una VM A3 ho potuto sperimentare fino a 1.2 Gbps di sustained throughput.

Dal momento che Azure supporta più NIC per VM è una buona idea dedicare una NIC a questo tipo di traffico.

Da test effettuati lasciando il sistema configurato di default, su un workload che effettuava letture e scritture sequenziali da 16 KB con un pattern tra letture e scritture di 50/50 il throughput e gli IOPs totali venivano ridotti a circa un 20% di quanto disponibile su un disco non soggetto a replica. Ovviamente questi test non simulano workload applicativi reali, quindi l’impatto nel mondo reale sarà sicuramente molto inferiore, questa indicazione deve essere presa come un segnale di attenzione in fase di pianificazione.

Nel grafico seguente vengono confrontati il numero di IOps raggiungibili su due differenti dischi (E non replicato, F soggetto a replica). Come si può vedere non esiste impatto sulle letture, mentre quello sulle scritture è significativo. I test sono stati effettuati utilizzando sqlio (), ma devono essere presi con beneficio di inventario in quanto non vogliono essere esaustivi e sicuramente non rappresentano workload reali. Si tratta, appunto, di un benchmark comparativo.

Conclusioni

In conclusione, porre in alta disponibilità i propri workload su Azure segue regole diverse rispetto all’implementazione on-premises. Se da un lato la piattaforma si occupa di gestire i fault hardware, potrebbe dare risultati inattesi durante update pianificati degli host di virtualizzazione. In tutti i casi la strada maestra è adottare i meccanismi di HA forniti dall’applicativo. Nel caso di sistemi Windows se dovesse essere necessario un Failover Cluster a dischi condivisi è possibile ricorrere a SIOS DataKeeper, avendo cura di profilare attentamente i pattern di scrittura.

Riferimenti

Alcuni articoli, la maggior parte di essi in lingua inglese, utili per approfondire alcuni degli aspetti trattati nell’articolo: