Nella più recente versione di Azure Stack HCI viene inclusa la possibilità di creare stretched cluster per estendere un cluster Azure Stack HCI in due location differenti (stanze, edifici oppure anche città differenti). Questa soluzione di disaster recovery fornisce una replica dello storage (sincrona oppure asincrona) e contempla la crittografia, la resilienza locale del sito ed il failover automatico delle macchine virtuali. In questo articolo vengono approfondite le possibili architetture e le caratteristiche della soluzione.
Per migliorare ulteriormente la resilienza built-in nella soluzione Azure Stack HCI è possibile implementare un cluster composto da due gruppi di nodi, definito “stretched cluster”. Ogni gruppo è dislocato in un sito differente e deve contenere un minimo di due nodi. Uno stretched cluster può essere composto da un minimo di quattro fino a sedici nodi fisici (numero massimo di nodi supportati da un cluster Azure Stack HCI), i quali devono soddisfare i requisiti hardware standard per soluzioni HCI.
Figura 1 – Panoramica di uno stretched cluster in una architettura hyper-converged di Azure Stack HCI
Scendendo nel dettaglio dell’architettura i componenti e le funzionalità utilizzate sono:
- Azure Stack HCI. La versione minima richiesta è la 20H2, distribuita come servizio hybrid di Azure e rilasciata a dicembre 2020. Si tratta di una infrastruttura hyper-converged (HCI), dove vengono rimossi diversi componenti hardware, sostituti dal software, in grado di unire i layer di elaborazione, storage e rete in un’unica soluzione.
- Storage Replica. La tecnologia inclusa in Windows Server che consente la replica dei volumi tra server oppure tra cluster ai fini di disaster recovery.
- Live Migration. La funzionalità di Hyper-V che consente di spostare facilmente le macchine virtuali (VMs) in esecuzione su un host Hyper-V ad un altro, senza avere tempi di inattività. Tale funzionalità risulta utile per gestire downtime attesi oppure programmati.
- Risorsa Witness. Il Witness è un componente obbligatorio all’interno dei cluster Azure Stack HCI. Per implementarlo è possibile scegliere un Azure Cloud Witness oppure un File Share Witness. Azure Cloud Witness è la scelta consigliata per i stretched cluster Azure Stack HCI purché tutti i nodi dispongano di una connessione Internet affidabile.
Uno stretched cluster di Azure Stack HCI si basa sull’utilizzo di Storage Replica ed è possibile avere una replica sincrona oppure asincrona del dato:
- Utilizzando la replica sincrona viene effettuato un mirroring dei dati tra i siti in una rete a bassa latenza. I volumi risultano crash-consistent per garantire una perdita di dati pari a zero a livello di file system durante un evento di failure. Il requisito per la replica sincrona applicabile ai stretched cluster impone come latenza di rete 5 ms di round trip tra i due gruppi di nodi dislocati nei siti replicati. A seconda delle caratteristiche di connettività della rete fisica, questo vincolo si traduce in genere in circa 30-45 Km di distanza. Con questa configurazione, se capita un problema che influisce sulla disponibilità di un sito, il cluster è in grado di trasferire automaticamente i workload ai nodi del sito non interessato dalla problematica per ridurre al minimo i potenziali tempi di inattività.
- La replica asincrona esegue il mirroring dei dati tra i siti su collegamenti di rete con latenze più elevate, ma non si ha la garanzia che entrambi i siti dispongano di copie identiche dei dati quando si verifica un evento di failure. In presenza di replica asincrona, è necessario portare online manualmente i volumi di destinazione nell’altro sito in seguito ad un failover.
Esistono due tipologie di stretched cluster: attivo-attivo e attivo-passivo.
Figura 2 – Tipologie di stretched cluster a confronto
Un sito attivo è un sito che dispone di risorse e ospita ruoli e workload ai quali i client possono connettersi. Un sito passivo è un sito che non eroga ruoli oppure workload per i client, ma è in attesa di un failover dal sito attivo a fini di disaster recovery.
La replica in uno stretched cluster attivo-passivo ha una direzione preferita, mentre la replica in uno stretched cluster attivo-attivo può avvenire in modo bidirezionale da entrambi i siti.
Azure Stack HCI e Storage Replica supportano anche la deduplica dei dati, utile ad aumentare la capacità di archiviazione utilizzabile, identificando porzioni duplicate di file e archiviandole solo una volta. A partire da Windows Server 2019, la deduplica è disponibile sui volumi formattati con Resilient File System (ReFS), che è il file system consigliato per Azure Stack HCI. Negli stretched cluster di Azure Stack HCI è consigliato abilitare la Data Deduplication solo sui nodi del cluster di origine, e non sui nodi di destinazione, i quali ricevono sempre copie deduplicate di ciascun volume.
Conclusioni
La possibilità di estendere i cluster Azure Stack HCI in due location differenti consente di implementare architetture di disaster recovery in un modo totalmente integrato nella soluzione, senza la necessità di dover adottare prodotti di terze parti. Questa caratteristica, unita alla possibilità di connettere Azure Stack HCI con i servizi Azure per ottenere un sistema hyper-converged ibrido, la rende una soluzione completa, stabile ed affidabile, in grado di rispondere alle esigenze più avanzate nell’ospitare workload business critical.
