Condividi tramite


Panoramica dei cluster estesi

Si applica a: Azure Stack HCI, versioni 22H2 e 21H2

Importante

I cluster estesi non sono ancora supportati in Azure Stack HCI versione 23H2.

Una soluzione cluster estesa di Azure Stack HCI per il ripristino di emergenza offre il failover automatico per ripristinare rapidamente la produzione e senza la necessità di intervento manuale. Replica archiviazione fornisce la replica dei volumi tra siti per il ripristino di emergenza, con tutti i server che rimangono sincronizzati.

Replica archiviazione supporta sia la replica sincrona che la replica asincrona:

  • La replica sincrona esegue il mirroring dei dati tra siti in una rete a bassa latenza con volumi coerenti con l'arresto anomalo del sistema per garantire una perdita di dati zero a livello di file system durante un errore.
  • La replica asincrona esegue il mirroring dei dati tra siti oltre gli intervalli metropolitani su collegamenti di rete con latenze più elevate, ma senza garantire che entrambi i siti dispongano di copie identiche dei dati al momento di un errore. Se la replica viene completata prima dell'errore, il volume di destinazione viene online automaticamente dopo il failover. Se la replica è in corso al momento dell'errore, è necessario portare online il volume di destinazione manualmente.

Esistono due tipi di cluster estesi, attivo-passivo e attivo-attivo.There are two types of stretched clusters, active-passive and active-active-active. È possibile configurare la replica del sito attivo-passivo, in cui è presente un sito e una direzione preferiti per la replica. La replica attiva-attiva è la posizione in cui la replica può avvenire in modo bidirezionale da entrambi i siti. Questo articolo illustra solo la configurazione attiva/passiva.

In termini semplici, un sito attivo è uno che dispone di risorse e fornisce ruoli e carichi di lavoro a cui i client possono connettersi. Un sito passivo è uno che non fornisce ruoli o carichi di lavoro per i client ed è in attesa di un failover dal sito attivo per il ripristino di emergenza.

I siti possono trovarsi in due stati diversi, città diverse, piani diversi o camere diverse. I cluster estesi che usano due siti forniscono il ripristino di emergenza e la continuità aziendale in caso di interruzione o errore di un sito.

Dedicare alcuni minuti a guardare il video sul clustering esteso con Azure Stack HCI:

Cluster esteso attivo-passivo

Il diagramma seguente mostra Site 1 come sito attivo con replica nel sito 2, una replica unidirezionale.

Scenario del cluster esteso attivo/passivo.

Cluster esteso attivo-attivo

Il diagramma seguente mostra sia Site 1 che Site 2 come siti attivi, con replica bidirezionale nell'altro sito.

Scenario di cluster esteso attivo/attivo

Considerazioni sul failover IP guest

Quando si parla di clustering esteso, una delle considerazioni da tenere in considerazione sono le macchine virtuali e gli indirizzi IP usati. I data center che risiedono in posizioni diverse hanno in genere subnet IP diverse. Gli indirizzi IP usati dalle macchine virtuali sono validi per un data center, ma non raggiungibili in un altro. Pertanto, la pianificazione di come gestire le modifiche degli indirizzi IP deve essere considerata. In genere, esistono quattro modi diversi per gestire la modifica dell'indirizzo IP nella macchina virtuale in caso di failover. Ci possono essere altri, ma questo articolo illustra i primi quattro.

Il primo e più semplice è l'uso di DHCP. Quando si sposta una macchina virtuale da un sito a un altro, la macchina virtuale richiede un indirizzo DHCP. In questo modo viene ottenuto l'indirizzo IP appropriato per il sito in cui si trova purché sia disponibile un server DHCP.

Successivamente, è possibile usare un indirizzo statico. Tuttavia, a differenza della replica Hyper-V, non esiste un modo per specificare un indirizzo IP alternativo. Pertanto, è necessario creare uno script per assegnare l'indirizzo IP appropriato per la macchina virtuale a seconda del sito in cui si trova. Ad esempio, SiteA usa una rete 1.x e SiteB usa una rete 156.x. Questo script deve rilevare la rete in cui si trova la macchina virtuale e impostare uno schema di indirizzi IP 1.x se si trova in SiteA o uno schema di indirizzi IP 156.x se si trova in SiteB. Domain Name Services (DNS) deve anche essere avvisato della modifica e replicata tra i siti.

Un'altra opzione è l'uso di un dispositivo di rete intermedio che fornisce un singolo indirizzo IP per la macchina virtuale per la connettività client, che può instradare il traffico alla macchina virtuale. I client e il DNS hanno sempre lo stesso indirizzo per la macchina virtuale e il dispositivo intermedio deve tenere traccia dell'indirizzo IP e della posizione effettivi della macchina virtuale in modo che i client vengano indirizzati alla macchina virtuale in modo appropriato.

L'ultima opzione è l'uso di una vLAN estesa. Con una vLAN estesa, le macchine virtuali possono mantenere lo stesso indirizzo IP indipendentemente dal sito in cui si trova. Tuttavia, a causa di alcune delle complessità della configurazione e della gestione di una vLAN estesa, questa opzione non è consigliata da Microsoft.

Con una delle opzioni precedenti, è necessario tenere conto di altre considerazioni (DNS, cache ARP, TTL e così via) quando si tratta di connettività client e deve essere accuratamente pensato. Collaborare con il team di rete per identificare l'opzione migliore per soddisfare le proprie esigenze.

Passaggi successivi