Clustering nel dispositivo Azure Stack Edge Pro GPU

SI APPLICA A:Azure Stack Edge Pro - GPUAzure Stack Edge Pro 2

Questo articolo offre una breve panoramica del clustering nel dispositivo Azure Stack Edge.

Informazioni sul clustering di failover

Azure Stack Edge può essere configurato come un singolo dispositivo autonomo o un cluster a due nodi. Un cluster a due nodi è costituito da due dispositivi Azure Stack Edge indipendenti connessi da cavi fisici e da software. Questi nodi quando il cluster funziona insieme come in un cluster di failover di Windows, offrono disponibilità elevata per applicazioni e servizi in esecuzione nel cluster.

Se uno dei nodi del cluster ha esito negativo, l'altro nodo inizia a fornire il servizio (il processo è noto come failover). Anche i ruoli del cluster vengono monitorati in modo proattivo per assicurarsi che funzionino correttamente. Se non funzionano, vengono riavviati o spostati nel secondo nodo.

Azure Stack Edge usa Windows Server Failover Clustering per il cluster a due nodi. Per altre informazioni, vedere Clustering di failover in Windows Server.

Quorum e server di controllo del cluster

Un quorum viene sempre mantenuto nel cluster Azure Stack Edge per rimanere online in caso di errore. Se uno dei nodi ha esito negativo, la maggior parte dei nodi sopravvissuti deve verificare che il cluster rimanga online. Il concetto di maggioranza esiste solo per i cluster con un numero dispari di nodi. Per altre informazioni sul quorum del cluster, vedere Informazioni sul quorum.

Per un cluster Azure Stack Edge con due nodi, se un nodo ha esito negativo, un cluster di controllo fornisce il terzo voto in modo che il cluster rimanga online (poiché il cluster viene lasciato con due voti su tre, una maggioranza). È necessario un server di controllo del cluster nel cluster Azure Stack Edge. È possibile configurare il server di controllo del mirroring nel cloud o in una condivisione file locale usando l'interfaccia utente locale del dispositivo.

• Per altre informazioni sul server di controllo del cluster, vedere Controllo del cluster in Azure Stack Edge.
• Per altre informazioni sul server di controllo del mirroring nel cloud, vedere Configurare il controllo cloud.
• Per la procedura dettagliata per distribuire un cloud di controllo, vedere Distribuire cloud di controllo per un cluster di failover.

Cluster di infrastruttura

Il cluster di infrastruttura nel dispositivo fornisce l'archiviazione permanente ed è illustrato nel diagramma seguente:

• Il cluster di infrastruttura è costituito dai due nodi indipendenti che eseguono il sistema operativo Windows Server con un livello Hyper-V. I nodi contengono dischi fisici per l'archiviazione e le interfacce di rete connesse back-to-back o con commutatori.

• I dischi tra i due nodi vengono usati per creare un pool di archiviazione logico. Gli spazi di archiviazione diretti in questo pool forniscono il mirroring e la parità per il cluster.

• È possibile distribuire i carichi di lavoro dell'applicazione sopra il cluster dell'infrastruttura.

  • I carichi di lavoro non in contenitori, ad esempio le macchine virtuali, possono essere distribuiti direttamente nel cluster dell'infrastruttura.

    

  • I carichi di lavoro in contenitori usano Kubernetes per la distribuzione e la gestione del carico di lavoro. Un cluster Kubernetes costituito da una macchina virtuale master e da due macchine virtuali di lavoro (una per ogni nodo) viene distribuita sopra il cluster dell'infrastruttura.

  Il cluster Kubernetes consente l'orchestrazione delle applicazioni, mentre il cluster dell'infrastruttura fornisce un'archiviazione permanente.

Topologie di rete supportate

In base al caso d'uso e ai carichi di lavoro, è possibile selezionare la modalità di connessione dei due nodi del dispositivo Azure Stack Edge. Le topologie di rete variano a seconda che si usi un dispositivo Azure Stack Edge Pro GPU o un dispositivo Azure Stack Edge Pro 2.

A livello generale, le topologie di rete supportate per ognuno dei tipi di dispositivo sono descritte qui.

Azure Stack Edge Pro GPU

Nel nodo del dispositivo Azure Stack Edge Pro GPU:

• La porta 2 viene usata per il traffico di gestione.
• La porta 3 e la porta 4 vengono usate per il traffico di archiviazione e cluster. Questo traffico include che è necessario per il mirroring dell'archiviazione e il traffico heartbeat del cluster Azure Stack Edge necessario affinché il cluster sia online.

Sono disponibili le topologie di rete seguenti:

• Opzione 1 : usare questa opzione quando non sono disponibili commutatori ad alta velocità nell'ambiente per il traffico di archiviazione e cluster.

  In questa opzione, la porta 3 e la porta 4 sono connesse back-to-back senza un commutatore. Queste porte sono dedicate all'archiviazione e al traffico del cluster Azure Stack Edge e non sono disponibili per il traffico del carico di lavoro. Facoltativamente, è anche possibile specificare gli indirizzi IP per queste porte.

• Opzione 2 - Usare commutatori e gruppo NIC: usare questa opzione quando sono disponibili commutatori ad alta velocità per l'uso con i nodi del dispositivo per il traffico di archiviazione e cluster.

  Ognuna delle porte 3 e 4 dei due nodi del dispositivo è connessa tramite un commutatore esterno. La porta 3 e la porta 4 sono raggruppate in ogni nodo e vengono creati un commutatore virtuale e due schede di interfaccia di rete virtuali che consentono la ridondanza a livello di porta per il traffico di archiviazione e cluster. Queste porte possono essere usate anche per il traffico del carico di lavoro.

• Opzione 3 - Usare commutatori senza gruppo NIC: usare questa opzione quando è necessaria una porta dedicata aggiuntiva per il traffico del carico di lavoro e la ridondanza a livello di porta non è necessaria per il traffico di archiviazione e cluster.

  La porta 3 in ogni nodo è connessa tramite un commutatore esterno. Se la porta 3 ha esito negativo, il cluster potrebbe andare offline. I commutatori virtuali separati vengono creati sulla porta 3 e sulla porta 4.

Per altre informazioni, vedere Scegliere una topologia di rete per il nodo del dispositivo.

Azure Stack Edge Pro 2

Nel nodo del dispositivo Azure Stack Edge Pro 2:

• Opzione 1: la porta 1 e la porta 2 si trovano in subnet diverse. Vengono creati commutatori virtuali separati. La porta 3 e la porta 4 si connettono a un commutatore virtuale esterno.

• Opzione 2 : la porta 1 e la porta 2 si trovano nella stessa subnet. Viene creato un commutatore virtuale a gruppo. La porta 3 e la porta 4 si connettono a un commutatore virtuale esterno.

• Opzione 3 : la porta 1 e la porta 2 si trovano in subnet separate. I commutatori virtuali separati vengono creati sulla porta 1 e sulla porta 2. La porta 3 e la porta 4 sono connesse back-to-back, senza cambio per la porta 3 e la porta 4.

• Opzione 4 : la porta 1 e la porta 2 si trovano nella stessa subnet. Viene creato un commutatore virtuale a gruppo. La porta 3 e la porta 4 sono connesse back-to-back, senza cambio per la porta 3 e la porta 4.

  Nota

  Se si eseguono carichi di lavoro PMEC, usare l'opzione 1 o l'opzione 2.

Considerazioni sull'utilizzo nei nodi del dispositivo Azure Stack Edge Pro 2:

• Switchless per la porta 3 e la porta 4 : usare questa opzione quando non sono disponibili commutatori ad alta velocità nell'ambiente oppure si vuole dedicare la porta 3 e la porta 4 per il traffico di archiviazione e cluster.
  • Porta 1 e Porta 2 in subnet separate: questa è l'opzione predefinita. In questo caso, la porta 1 e la porta 2 hanno commutatori virtuali separati e sono connessi a subnet separate.
  • Porta 1 e Porta 2 nella stessa subnet : in questo caso, la porta 1 e la porta 2 hanno un commutatore virtuale con gruppo e entrambe le porte si trovano nella stessa subnet.
• Uso di commutatori esterni per la porta 3 e la porta 4 : usare questa opzione quando sono disponibili commutatori ad alta velocità (>=10 GbE) per l'uso con i nodi del dispositivo e si vuole consentire a una scheda di rete VM di connettersi alla rete virtuale creata sulla porta 3 o sulla porta 4, come un caso d'uso PMEC.
  • Porta 1 e Porta 2 in subnet separate: questa è l'opzione predefinita. In questo caso, la porta 1 e la porta 2 hanno commutatori virtuali separati e sono connessi a subnet separate.
  • Porta 1 e Porta 2 nella stessa subnet : in questo caso, la porta 1 e la porta 2 hanno un commutatore virtuale con gruppo e entrambe le porte si trovano nella stessa subnet.

Considerazioni aggiuntive:

• La porta 1 viene usata per la configurazione iniziale. La porta 1 viene quindi riconfigurata e assegnata un indirizzo IP che potrebbe o meno trovarsi nella stessa subnet della porta 2.
• Se si seleziona l'opzione Uso di commutatori esterni, la porta 1 e la porta 2 vengono usate per l'archiviazione in modalità di raggruppamento e non di raggruppamento.
• Quando si usa l'opzione Switchless , la porta 3 e la porta 4 sono connesse direttamente al back-to-back, senza un commutatore. Queste porte sono dedicate all'archiviazione e al traffico del cluster Azure Stack Edge. La porta 3 e la porta 4 non sono disponibili per il traffico del carico di lavoro.

I vantaggi e i svantaggi per le topologie supportate sono riepilogati nel modo seguente:

Opzione dell'interfaccia utente Web locale	Vantaggi	Svantaggi
La porta 3 e la porta 4 sono senza commutatori, porta 1 e porta 2 in subnet separate, commutatori virtuali separati.	Percorsi ridondanti per la gestione e il traffico di archiviazione.	I client devono riconnettersi se la porta 1 o la porta 2 ha esito negativo.
	Nessun singolo punto di guasto all'interno del dispositivo.	Il carico di lavoro della macchina virtuale non può sfruttare la porta 3 o la porta 4 per connettersi agli endpoint di rete diversi da un nodo di Azure Stack Edge peer. Ecco perché i carichi di lavoro PMEC non possono usare questa opzione.
	Larghezza di banda per il traffico di archiviazione e cluster tra i nodi.
	Può essere distribuito con la porta 1 e la porta 2 in subnet diverse.
La porta 3 e la porta 4 sono senza cambio, la porta 1 e la porta 2 si trovano nella stessa subnet, commutatore virtuale con gruppo.	Percorsi ridondanti per la gestione e il traffico di archiviazione.	Il carico di lavoro della macchina virtuale non può sfruttare la porta 3 o la porta 4 per connettersi agli endpoint di rete diversi da un nodo di Azure Stack Edge peer. Ecco perché i carichi di lavoro PMEC non possono usare questa opzione.
	Larghezza di banda per il traffico di archiviazione e cluster tra i nodi.
	Maggiore tolleranza di errore.
La porta 3 e la porta 4 usano un commutatore esterno con >=10 Gbps collegamento larghezza di banda, porta 1 e porta 2 in subnet separate, commutatori virtuali separati	Due commutatori virtuali indipendenti e percorsi di rete offrono ridondanza.	I client devono riconnettersi se la porta 1 o la porta 2 ha esito negativo.
	Nessun singolo punto di guasto con il dispositivo.
	La porta 1 e la porta 2 possono essere connesse a subnet diverse.
La porta 3 e la porta 4 usano un commutatore esterno con >larghezza di banda di collegamento =10 Gbps, porta 1 e porta 2 nella stessa subnet, commutatore virtuale con gruppo.	Bilanciamento del carico.
	Maggiore tolleranza di errore.	Non è possibile distribuire in un ambiente con subnet diverse.
	Due percorsi indipendenti e ridondanti tra i nodi.
	I client non devono eseguire di nuovo la connessione.

Distribuzione cluster

Azure Stack Edge Pro GPU

Prima di configurare il clustering nel dispositivo, è necessario cablare i dispositivi in base a una delle topologie di rete supportate che si intende configurare. Per distribuire un cluster di infrastruttura a due nodi nei dispositivi Azure Stack Edge, seguire questa procedura generale:

1. Ordinare due dispositivi Azure Stack Edge indipendenti. Per altre informazioni, vedere Ordinare un dispositivo Azure Stack Edge.
2. Cablare ogni nodo in modo indipendente come si farebbe per un singolo dispositivo a nodo. In base ai carichi di lavoro che si intende distribuire, connettere le interfacce di rete in questi dispositivi tramite cavi e con o senza commutatori. Per istruzioni dettagliate, vedere Cablare il dispositivo cluster a due nodi.
3. Avviare la creazione del cluster nel primo nodo. Scegliere la topologia di rete conforme al cablaggio tra i due nodi. La topologia scelta determina il traffico di archiviazione e clustering tra i nodi. Vedere i passaggi dettagliati in Configurare la rete e il proxy Web nel dispositivo.
4. Preparare il secondo nodo. Configurare la rete nel secondo nodo nello stesso modo in cui è stata configurata nel primo nodo. Verificare che le impostazioni della porta corrispondano tra lo stesso nome di porta in ogni appliance. Ottenere il token di autenticazione in questo nodo.
5. Usare il token di autenticazione dal nodo preparato e aggiungere questo nodo al primo nodo per formare un cluster.
6. Configurare un server di controllo cloud usando un account Archiviazione di Azure o un server di controllo locale in una condivisione file SMB.
7. Assegnare un indirizzo IP virtuale per fornire un endpoint per Servizi coerenti di Azure o quando si usa NFS.
8. Assegnare finalità di calcolo o gestione ai commutatori virtuali creati nelle interfacce di rete. È anche possibile configurare gli INDIRIZZI IP dei nodi Kubernetes e gli INDIRIZZI IP del servizio Kubernetes qui per l'interfaccia di rete abilitata per il calcolo.
9. Facoltativamente, configurare il proxy Web, configurare le impostazioni del dispositivo, configurare i certificati e infine attivare il dispositivo.

Per altre informazioni, vedere le esercitazioni sulla distribuzione di dispositivi a due nodi a partire da Ottenere l'elenco di controllo per la configurazione della distribuzione.

Azure Stack Edge Pro 2

Prima di configurare il clustering nel dispositivo, è necessario cablare i dispositivi in base a una delle topologie di rete supportate che si intende configurare. Per distribuire un cluster di infrastruttura a due nodi nei dispositivi Azure Stack Edge, seguire questa procedura generale:

1. Ordinare due dispositivi Azure Stack Edge indipendenti. Per altre informazioni, vedere Ordinare un dispositivo Azure Stack Edge.
2. Cablare ogni nodo in modo indipendente come si farebbe per un singolo dispositivo a nodo. In base ai carichi di lavoro che si intende distribuire, connettere le interfacce di rete in questi dispositivi tramite cavi e con o senza commutatori. Per istruzioni dettagliate, vedere Cablare il dispositivo cluster a due nodi.
3. Avviare la creazione del cluster nel primo nodo. Scegliere la topologia di rete conforme al cablaggio tra i due nodi. La topologia scelta determina il traffico di archiviazione e clustering tra i nodi. Vedere i passaggi dettagliati in Configurare la rete e il proxy Web nel dispositivo.
4. Preparare il secondo nodo. Configurare la rete nel secondo nodo nello stesso modo in cui è stata configurata nel primo nodo. Verificare che le impostazioni della porta corrispondano tra lo stesso nome di porta in ogni appliance. Ottenere il token di autenticazione in questo nodo.
5. Usare il token di autenticazione dal nodo preparato e aggiungere questo nodo al primo nodo per formare un cluster.
6. Configurare un server di controllo cloud usando un account Archiviazione di Azure o un server di controllo locale in una condivisione file SMB.
7. Assegnare un indirizzo IP virtuale per fornire un endpoint per Servizi coerenti di Azure o quando si usa NFS.
8. Assegnare finalità di calcolo o gestione ai commutatori virtuali creati nelle interfacce di rete. È anche possibile configurare gli INDIRIZZI IP dei nodi Kubernetes e gli INDIRIZZI IP del servizio Kubernetes qui per l'interfaccia di rete abilitata per il calcolo.
9. Facoltativamente, configurare il proxy Web, configurare le impostazioni del dispositivo, configurare i certificati e infine attivare il dispositivo.

Per altre informazioni, vedere le esercitazioni sulla distribuzione di dispositivi a due nodi a partire da Ottenere l'elenco di controllo per la configurazione della distribuzione.

Carichi di lavoro di clustering

Nel cluster a due nodi è possibile distribuire carichi di lavoro non in contenitori o carichi di lavoro in contenitori.

• Carichi di lavoro non in contenitori, ad esempio macchine virtuali: il cluster a due nodi garantirà una disponibilità elevata delle macchine virtuali distribuite nel cluster del dispositivo. La migrazione in tempo reale delle macchine virtuali non è supportata.

• Carichi di lavoro in contenitori, ad esempio Kubernetes o IoT Edge: il cluster Kubernetes distribuito all'inizio del cluster di dispositivi è costituito da una macchina virtuale master Kubernetes e da due macchine virtuali del ruolo di lavoro Kubernetes. Ogni nodo Kubernetes ha una macchina virtuale di lavoro aggiunta a ogni nodo di Azure Stack Edge. Il failover comporta il failover della macchina virtuale master Kubernetes (se necessario) e del ribilanciamento basato su Kubernetes dei pod nella macchina virtuale del ruolo di lavoro sopravvissuta.

  Per altre informazioni, vedere Kubernetes in un dispositivo Azure Stack Edge in cluster.

Gestione dei cluster

È possibile gestire il cluster Azure Stack Edge tramite l'interfaccia PowerShell del dispositivo o tramite l'interfaccia utente locale. Alcune attività di gestione tipiche sono:

• Annullare la preparazione del nodo
• Configurare il controllo cloud
• Configurare un server di controllo locale
• Configurare le impostazioni IP virtuali
• Rimuovere il cluster

Aggiornamenti del cluster

Un aggiornamento del dispositivo in cluster a due nodi applicherà prima gli aggiornamenti del dispositivo seguiti dagli aggiornamenti del cluster Kubernetes. Gli aggiornamenti in sequenza ai nodi del dispositivo garantiscono tempi di inattività minimi dei carichi di lavoro.

Quando si applicano questi aggiornamenti tramite il portale di Azure, è necessario avviare il processo solo in un nodo e entrambi i nodi vengono aggiornati. Per istruzioni dettagliate, vedere Applicare aggiornamenti al dispositivo Azure Stack Edge a due nodi.

Fatturazione

Se si distribuisce un cluster a due nodi di Azure Stack Edge, ogni nodo viene fatturato separatamente. Per altre informazioni, vedere La pagina dei prezzi per Azure Stack Edge.

Passaggi successivi

• Informazioni sul server di controllo del cluster per Azure Stack Edge.
• Vedere Kubernetes per Azure Stack Edge
• Informazioni sugli scenari di failover del cluster