Se avete letto l’articolo precedente, dovreste esservi fatti un’idea abbastanza chiara relativamente alle complessità da affrontare nel dimensionamento di una singola Azure Virtual Machine. In questa nuova puntata della serie, per rendere il quadro generale più chiaro, tratteremo le tematiche di alta disponibilità (HA) e di contenimento dei costi, che ci consentono di ottenere ambienti affidabili ed a impatto ridotto sul fronte economico.
come gestire l’alta disponibilta’ in azure iaas?
Solitamente, un ambiente di produzione on-prem dispone di meccanismi di HA ed è ragionevole pensare che, una volta migrato in cloud, questo debba sottostare quantomeno agli stessi livelli di servizio che offriva in precedenza.
Possiamo aumentare la resilienza della nostra soluzione su Azure? Assolutamente sì, ed abbiamo diverse possibilità in funzione dei tempi di ripartenza (Recovery Time Objectives – RTO) che ci prefiggiamo e della quantità di dati (Recovery Point Objectives – RPO) che è ammissibile perdere a seguito di un failover.
Per via delle peculiarità infrastrutturali di Azure, la nostra architettura diventerà più complessa. Vediamo cosa ci troveremo ad affrontare.
In Azure, per dare un minimo di resilienza ad una singola Virtual Machine, dovremo dotarla di dischi Premium SSD e sottoporla a backup costanti. Così facendo, disporremo di un Service Level Agreement (SLA) concordato, che ci garantisce un uptime della macchina pari al 99,5%. In caso di problemi seri al sistema, per erogare nuovamente il servizio, nella peggiore delle ipotesi dovremo ripristinare la VM dal backup e provvedere al riallineamento di tutti i database con il restore dei transaction log. Sebbene questo sia un punto di partenza più che rispettabile, RTO e RPO di questa soluzione sono più vicini ad un sistema pensato per il disaster recovery (DR) che per HA.
Possiamo ottenere livelli di servizio maggiori mediante un sistema composto da più Virtual Machine che utilizzino tecnologie di clustering applicativo. Ad esempio, sfruttando i servizi Always On di SQL Server, potremo distribuire i singoli nodi del sistema in Availability Set per ottenere uno SLA del 99,95%, che salirà al 99,99% se si utilizzano invece le Availability Zone.
Una volta definita la strategia di distribuzione, occorre definire la tecnologia che supporterà il nostro backend database. Le tecnologie disponibili sono sostanzialmente quelle che possiamo già usare on-premises: ciò che cambia è la metodologia di implementazione.
Se si dispone di licenze Enterprise, si potrà basare la propria strategia di HA su Always On Availability Group: questa è la soluzione principe in termini di flessibilità ed espandibilità per ottenere un sistema di Business Continuity/Disaster Recovery (BCDR) basato su una singola tecnologia, eventualmente integrato anche con il datacenter on-premises o con una region Azure remota per fini di DR. Qualora, invece, si disponga di un budget più limitato e di licenze Standard Edition, si potrà andare a realizzare un sistema basato su Always On Basic Availability Group, o ad una Always On Failover Cluster Instance (FCI) appoggiata ad un tradizionale failover cluster.
Tutte le soluzioni descritte sopra prevedono storage dedicato su ogni nodo del sistema SQL Server, con relativo impatto sui costi di gestione e sulla complessità di configurazione.
Qui iniziano le differenze: anche nel caso di FCI occorre implementare una storage replica basata su Storage Spaces Direct, in quanto non è attualmente supportata la condivisione dei dischi tra più nodi, quantomeno con tecnologie Microsoft. Novità su questo fronte sono attese nel breve periodo, con l’introduzione degli Shared Disks; questi permetteranno di utilizzare un disco condiviso tra più nodi del cluster, analogamente a quanto avviene normalmente on-prem.
Nell’attesa, è possibile utilizzare le Azure File Share di tipo Premium per ospitare i database di un FCI, evitando lo storage condiviso. Questa interessante soluzione va comunque ragionata bene in termini di rapporto costi/performance rispetto allo storage dedicato su ogni nodo.
Oltre agli aspetti legati allo storage, bisogna prestare particolare attenzione lato networking: in IaaS, abbiamo la necessità di utilizzare load balancer davanti ai sistemi clusterizzati per gestire gli IP di cluster in modalità compatibile con l’implementazione Software Defined Network di Azure. Questo comporta la gestione di ulteriori risorse nella nostra soluzione, che vanno correttamente configurate affinché i sistemi possano funzionare regolarmente in caso di failover.
Insomma, alle complessità viste la volta precedente, se ne aggiungono altre. Passiamo al capitolo costi che ci mostra qualche spiraglio di luce in fondo al tunnel.
è conveniente implementare una vm in iaas?
Come direbbero gli Inglesi: “it depends”.
Tendenzialmente, un’implementazione IaaS deve essere vista come una soluzione strategica: ad esempio per estendere un data center on-prem, o come punto di passaggio nel corso di una trasformazione da applicazione legacy verso uno scenario cloud. L’adozione di una soluzione IaaS fine a sé stessa, nel lungo periodo, potrebbe rivelarsi una scelta economicamente non oculata; è pur vero, comunque, che in IaaS si paga un canone per una VM che, sotto al cofano, potrà godere di hardware potenzialmente sempre in evoluzione – cosa non facilmente gestire in un datacenter tradizionale.
Premesso questo, bisogna dire che Azure offre varie possibilità per ridurre i costi di una Virtual Machine con a bordo SQL Server.
Ad esempio, se stiamo predisponendo un ambiente che non necessita di rimanere acceso 24/7, potremmo valutare di acquisire la VM licenziata in modalità Pay-As-You-Go (PAYG) e di tenerla spenta al di fuori delle finestre di utilizzo: così facendo, ridurremmo i costi di compute e di licensing, in funzione dell’effettivo utilizzo. Per contro, se stiamo preparando un ambiente strategico, che deve rimanere sempre attivo e che ha un orizzonte temporale di utilizzo ampio, potremmo valutare di creare una reserved instance ad uno o tre anni per ottenere degli sconti sulla componente compute. Ad Ignite 2019, Microsoft ha annunciato che saranno presto introdotte reservation anche sullo storage, per abbattere ulteriormente i costi di infrastruttura.
Lato licensing, è possibile sfruttare licenze acquisite on-premises e coperte da Software Assurance (SA) grazie ad Azure Hybrid Benefit (AHB). Rispetto al PAYG, questo approccio riduce i costi sia lato Windows che SQL Server sul lungo periodo.
Il nuovo modello di licensing di SQL Server 2019, inoltre, ha introdotto interessantissime novità sulla gestione dei nodi di HA e DR: qualora le licenze siano coperta da SA, è ora possibile estendere la propria infrastruttura SQL in diversi modi senza incorrere in ulteriori costi licenza. Ad esempio, è possibile estendere un proprio sistema SQL Server on-prem aggiungendo un nodo di DR in Azure a costo zero in termini di licensing; con le precedenti condizioni di licenza, per il nodo in cloud sarebbe stato necessario licenziare tutti i core disponibili sulla macchina, con tutto ciò che ne consegue in termini di costi.
Ulteriori informazioni su questo tema sono disponibili consultando la guida di licensing di SQL Server 2019.
ma ne vale la pena?
Chiudo questa coppia di articoli dedicati alle Virtual Machine rispondendo ad una domanda che a questo punto potrebbe sorgervi spontanea: “Ma ne vale la pena?”. Assolutamente sì!
Come già detto, Azure IaaS ci dà la possibilità di rispondere a certe situazioni che non possiamo gestire – al momento – in PaaS. Possiamo realizzare un sistema performante e resiliente, coperto anche da soluzioni di DR, ma la progettazione e l’implementazione di un’infrastruttura al top richiedono impegno e competenza analoghi a quanto normalmente viene richiesto per un data center on-premises. Per questo, è sempre consigliabile documentarsi bene prima di procedere o avvalersi di chi ha più esperienza sul campo, in modo da minimizzare gli sprechi e realizzare sistemi affidabili.
→ Vai all’articolo “SQL Server on Azure: quando realizzare una Virtual Machine?“
→ Vai all’articolo “SQL Server: viaggio verso il cloud“
