Creare il cluster vSAN VMware esteso

Una volta completate tutte le configurazioni dei prerequisiti, è ora possibile continuare a creare il cluster esteso vSAN VMware. Questo passo formalizza la connessione tra gli host in OCI Dedicated Region A e OCI Dedicated Region B, nonché il nodo Witness distribuito in una terza area.

È possibile utilizzare la Creazione guidata Quickstart o passare direttamente a: Cluster, Configure, vSAN, Fault Domains and Stretched Cluster nell'interfaccia utente di VMware vCenter.

Configurare quanto segue durante questo processo:

  • Assegna OCI Dedicated Region a un host al dominio di errore 1
  • Assegna host OCI Dedicated Region B a dominio di errore 2
  • Specificare l'host testimone (aggiunto in precedenza) per il quorum

Per ulteriori dettagli, vedere Stretched Cluster Requirements e VMware vSAN Stretched Cluster Guide.

Dopo la creazione del cluster esteso:

  • Eseguire i controlli dello stato vSAN per convalidare l'integrità del cluster.
  • Risolvere eventuali errori relativi alla rete (ad esempio, problemi di mancata corrispondenza MTU o di instradamento).

Nota

È possibile che si verifichino oggetti vSAN non più validi in determinati host dai cluster originali. Per rimuoverli, fare riferimento alla presente guida: Come eliminare oggetti inaccessibili nel datastore vSAN

Una volta completato, il cluster deve riportare un punteggio di integrità vSAN nel valore massimo 90s, a indicare una configurazione estesa riuscita.

Configura NSX

Con il cluster vSAN VMware esteso, aggiornare NSX VMware per supportare la rete overlay tra siti. Questo passo garantisce che gli host ESXi di entrambe le aree possano comunicare tramite tunnel NSX utilizzando le rispettive zone di trasporto.

Duplica configurazione TEP NSX
  • Copiare il pool di IP NSX TEP da NSX Manager OCI Dedicated Region B in OCI Dedicated Region A NSX Manager.
  • Per evitare conflitti IP con l'host di gestione ESXi ancora presente in OCI Dedicated Region B, configurare il nuovo pool di IP in OCI Dedicated Region A per iniziare da .10.

    Esempio: in OCI Dedicated Region un NSX Manager, creare un pool TEP con un intervallo di .10–.20 per gli host OCI Dedicated Region B per garantire che non si sovrappongano agli IP esistenti.

Crea un profilo Uplink per OCI Dedicated Region B in OCI Dedicated Region A
  • Nella OCI Dedicated Region A NSX Manager definire un nuovo profilo Uplink in modo specifico per gli host OCI Dedicated Region B.
  • Utilizzare l'ID VLAN corretto e assicurarsi che l'ordine di collegamento corrisponda alla configurazione B di OCI Dedicated Region.
Prepara host per NSX
  • Utilizzare OVERLAY-TZ e VLAN-TZ come zone di trasporto.
  • Durante la preparazione dell'host, assegnare il profilo uplink appropriato, a seconda che l'host provenga da OCI Dedicated Region A o OCI Dedicated Region B.

    Nota: in alcuni scenari, in particolare dopo un evento di failover, è possibile che le interfacce del tunnel NSX non vengano visualizzate correttamente. Per risolvere questo problema, eseguire le operazioni riportate di seguito.

    • Eseguire il reboot dell'host ESXi interessato o
    • Eseguire il riavvio services.sh tramite SSH sull'host.

    Ciò garantisce l'avvio di tutti i servizi NSX nell'ordine corretto e il ripristino della stabilità del tunnel.

Crea segmenti sovrapposizione NSX
  • Creare quattro segmenti di sovrapposizione NSX.
  • Assicurarsi che questi segmenti siano visibili e sincronizzati in tutti gli host ESXi in entrambi i siti.
Configurare DHCP (facoltativo)
  • Facoltativamente, configurare le impostazioni DHCP per i nuovi segmenti di sovrapposizione.
  • Le impostazioni DNS sono già state configurate in precedenza in questa guida e non è necessario ripetere qui.
Convalida connettività di sovrapposizione end-to-end
  • Distribuisci quattro VM, posizionandone una su ogni host in entrambe le aree.
  • Assegnare a ciascuna VM un indirizzo IP statico all'interno del rispettivo intervallo di segmenti.
  • Eseguire il ping dei gateway dei segmenti e tra le VM per convalidare la connettività di overlay L3 nell'ambiente esteso.

Abilita connettività esterna per VM sovrapposte

Per consentire alle VM di overlay NSX VMware di accedere a reti esterne, configurare le regole NAT e l'instradamento per le VLAN pertinenti.

In VCN-MGMT-Active e VCN-MGMT-Failover, aggiornare la configurazione NAT per la VLAN NSX Edge Uplink 1:

  • Utilizza gli stessi IP di accesso esterno in entrambe le aree, corrispondenti a quelli utilizzati durante la distribuzione di OCI Dedicated Region A.
  • Verificare che l'IP utilizzato sia il HA VIP per i nodi NSX Edge, visibile in NSX Manager.

Aggiornare inoltre le regole di accesso esterno per le VLAN vSphere:

  • Configurare le regole NAT per vcenter-vip, nsxt-manager-vip e HCX-manager-vip (se si utilizza HCX) in entrambe le reti VCN.

Supporto dell'inoltro DNS

Le VM overlay in genere utilizzano un inoltro DNS (ad esempio, 192.168.253.253) definito in NSX-T. Per instradare queste query DNS:

  1. Creare una tabella di instradamento dedicata per il gateway NAT.
  2. Definire un instradamento statico:
    • Destinazione: 10.x.x.x (subnet VM di overlay)
    • Destinazione: gateway NAT
    • IP dell'inoltro DNS: 192.168.253.253

Questa configurazione deve essere replicata in entrambi i siti. Associare la nuova tabella di instradamento al gateway NAT per garantire un funzionamento coerente.

Riassegnare le VLAN host ESXi alla VCN mobile

Nell'impostazione corrente, a ogni host ESXi viene assegnato il provisioning con due NIC fisici, ciascuno associato a un set predefinito di VLAN configurate tramite collegamenti VNIC a VCN-Primary (OCI Dedicated Region A) e VCN-Secondary (OCI Dedicated Region B). Queste VNIC vengono configurate utilizzando il blocco CIDR secondario (172.45.0.0/16) collegato alle rispettive VCN.

Per completare la transizione verso una configurazione estesa, tutte le VLAN con tag 200 e successive (ad esempio, per vSphere, HCX, NSX Edge e così via) devono essere migrate alle VCN galleggianti:
  • VCN-MGMT-Active in OCI Dedicated Region A
  • VCN-MGMT-Failover in OCI Dedicated Region B

Esegui migrazione delle VNIC alla VCN mobile

Attenersi alla procedura riportata di seguito per ogni host ESXi in entrambi gli SDDC.
  1. Accesso ai dettagli host ESXi: nella console OCI, andare a Computazione, host ESXi.
  2. Elimina collegamenti VNIC esistenti: per ogni host, eliminare le VNIC associate alle VLAN 201 e successive dalla VCN primaria o dalla VCN secondaria.

    Nota

    Questo passo è obbligatorio perché non è possibile creare una nuova VNIC per la stessa VLAN mentre quella precedente esiste.
  3. Ricreare le VNIC nella VCN mobile:
    • Creare una nuova VNIC per ogni VLAN nella VCN mobile corrispondente:
      • Utilizza VCN-MGMT-Active in OCI Dedicated Region A
      • Utilizza VCN-MGMT-Failover in OCI Dedicated Region B
    • Selezionare la VLAN contrassegnata con il suffisso -NEW appropriato per distinguerla dall'originale.

    Ripetere questo processo per entrambi i tipi di VNIC per host. Si consiglia un approccio sistematico: iniziare con vnic0 e vnic1 per la VLAN 201, completare le sostituzioni, quindi procedere con la VLAN successiva.

    Considerazioni speciali per gli host del sito secondario

    Dopo aver eseguito la migrazione delle VNIC per gli host nel sito principale, ripetere il processo per tutti gli host nel sito secondario. Tuttavia, notare un dettaglio chiave:

    • I componenti di gestione vSphere nel sito secondario sono stati inizialmente distribuiti su una VLAN temporanea (ad esempio, VLAN-Stretched-Cls-Mgmt-vSphere-TEMP).
    • Questa VLAN temporanea può rimanere in vigore durante la transizione. Non influisce sulla funzionalità vSAN estesa e offre l'accesso di fallback ai componenti vCenter e NSX, se necessario.

    La conservazione di questa VLAN temporanea garantisce un accesso di gestione ininterrotto durante la VNIC e il workflow di migrazione di rete.

    Impatto e recupero della connettività

    Durante gli aggiornamenti della VNIC, è prevista la perdita temporanea della connettività agli host vCenter, NSX Manager o ESXi. Per garantire il recupero:

    1. Verificare i collegamenti DRG: verificare che le VCN di gestione appropriate (sia attive che di failover) siano collegate ai rispettivi Dynamic Routing Gateway (DRG).
    2. Aggiornamento delle tabelle di instradamento:
      • Aggiornare la tabella di instradamento master in ogni VCN di gestione in modo che punti al DRG.
      • Aggiornare le tabelle di instradamento della subnet di base per garantire che il traffico di gestione venga instradato correttamente tra le reti VCN e tra le aree.
    3. Convalida accesso:
      • Dopo aver aggiornato gli instradamenti, è necessario ripristinare l'accesso a tutte le interfacce di gestione dall'host Bastion.
      • Se alcune risorse rimangono non raggiungibili, controllare due volte le regole NSG e la propagazione dell'instradamento tra VCN.

    Cleanup migrazione successiva alla vNIC

    Una volta completata la migrazione della VNIC:

    • Rimuovere tutte le VLAN non utilizzate dalle VCN-Primary e VCN-Secondary appartenenti al blocco CIDR 172.45.0.0/16.
    • Scollegare il CIDR secondario (172.45.0.0/16) da VCN-Primary poiché non è più in uso.

    OCI consentirà lo scollegamento CIDR solo quando non viene utilizzato da alcuna risorsa attiva (VNIC, subnet o VLAN).

    • È possibile osservare gli indicatori di avvertenza nella pagina delle risorse dell'SDDC nella console OCI, poiché il servizio Oracle Cloud VMware Solution non tiene più traccia dei componenti inizialmente distribuiti in VCN-Primary.

    Aggiorna instradamento per nuovi allegati VCN

    1. Collegare VCN-MGMT-Active al DRG in OCI Dedicated Region A.
    2. Aggiornamento delle tabelle di instradamento:
      • Per VCN-MGMT-Active: indicare l'instradamento predefinito (0.0.0.0/0) al DRG.
      • Per la subnet di base in VCN-Primary: aggiornare la tabella di instradamento in modo che punti al DRG per assicurarsi che possa comunque accedere a VMware vCenter e a VMware NSX Manager.

    Dopo aver apportato queste modifiche, VMware vCenter e VMware NSX Manager in OCI Dedicated Region A devono diventare raggiungibili dall'host Bastion, anche se le relative interfacce di base ora risiedono in una VCN diversa.

Configurare le regole di affinità DRS, HA e il criterio di storage vSAN VMware

Una volta che il cluster esteso è completamente operativo e la rete è stabile in entrambi i siti, configurare Distributed Resource Scheduler (DRS), High Availability (HA) e assegnare un criterio di storage vSAN VMware basato sul sito al carico di lavoro e alle virtual machine (VM) di gestione.

Queste configurazioni garantiscono il posizionamento ottimale delle VM nei domini di errore e consentono il recupero automatico durante gli errori del sito.

Eseguire la migrazione delle VM al cluster esteso

Iniziare eseguendo la migrazione di tutte le VM di gestione e test delle VM dei carichi di lavoro nel cluster esteso appena creato:

  • Utilizzare vMotion per spostare le VM dai cluster specifici del sito originale al cluster compresso.
  • Se tutto è configurato correttamente (rete, storage, gruppi di porte), la migrazione delle VM dovrebbe essere completata senza alcun problema.

Se esistono regole NSX DRS predefinite e sono impostate su DEVE, rimuoverle. Questi possono interferire con le operazioni HA e impedire il failover dei nodi NSX Edge e delle VM NSX Manager.

Creare VM e gruppi di host

Definire i gruppi di affinità per il posizionamento del carico di lavoro:

  1. Crea gruppi host:
    • Raggruppa gli host appartenenti al sito principale.
    • Raggruppa gli host appartenenti al sito secondario.
  2. Creazione di gruppi VM:
    • VM di gestione dei gruppi che devono risiedere sugli host all'interno di ciascun sito (ad esempio, vCenter, NSX Manager, nodi NSX Edge, HCX Manager e altri, se applicabile).
    • Analogamente, raggruppare tutte le VM del carico di lavoro (nel nostro caso tutte le VM di test).

Definisci regole affinità VM/host

Dopo la definizione dei gruppi:

  • Creare regole di affinità tra VM e host per mantenere le VM situate sugli host nel sito previsto.
  • Utilizzare le regole Esegui VM sugli host per consentire la flessibilità HA negli scenari di failover.
  • Creare tali regole sia per la VM di gestione che per i gruppi di VM del carico di lavoro.

Questa impostazione garantisce che durante il normale funzionamento, ogni sito ospita i carichi di lavoro previsti, ma consente il recupero automatico in caso di errore di un host o di un sito.

Abilitazione di High Availability (HA)
  • Assicurarsi che HA sia abilitato a livello di cluster dopo che sono state definite regole di affinità.
  • L'opzione predefinita per il riavvio delle VM in caso di errore host garantisce il riavvio della VM durante errori imprevisti, incluse le interruzioni complete del sito.

Creare e applicare un criterio di storage vSAN esteso

Per garantire la ridondanza dei dati in entrambi i siti in una configurazione estesa, definire un nuovo criterio SBPM (Storage-Based Policy Management) vSAN. Questo criterio controllerà la modalità di distribuzione dei dati VM nei domini di errore e nel sito di testimonianza.

Configurare le regole di posizionamento seguenti all'interno del criterio:

  • Tipo di memorizzazione: vSAN
  • Tolleranza ai disastri del sito: mirroring del sito: cluster esteso
  • Errore di tolleranza: nessuna ridondanza dei dati
  • Numero di stripe di dischi per oggetto: 1
  • Limite IOPS per oggetto: 0

Lasciare tutte le altre opzioni ai valori predefiniti.

Una volta creato il criterio, procedere come segue.

  1. Applicare il criterio a tutte le VM di test e gestione all'interno del cluster esteso.
  2. Passare a Monitoraggio, vSAN, risincronizzazione degli oggetti per osservare e tenere traccia del processo di risincronizzazione.
  3. Al termine della risincronizzazione, verificare il posizionamento dell'oggetto per verificare che il criterio funzioni come previsto:
    • Un oggetto replica si trova nel sito principale
    • Un secondo oggetto di replica si trova nel sito secondario
    • Il componente testimone risiede nell'area Witness remota

Tutte le VM verranno inizialmente visualizzate come non conformi. Selezionare ogni VM o un gruppo di VM e assegnare manualmente il criterio esteso appena creato per garantirne la conformità.

Inoltre, andare a Monitoraggio, vSAN, risincronizzazione di oggetti e oggetti virtuali. Una volta completato il processo di risincronizzazione, è necessario osservare che gli oggetti virtuali di ciascuna VM vengono distribuiti correttamente nel sito primario, nel sito secondario e nel nodo Witness, convalidando la piena conformità alla progettazione del cluster estesa.