NSX multisito

NSX supporta distribuzioni multisito in cui è possibile gestire tutti i siti da un cluster NSX Manager.

Sono supportati due tipi di distribuzione multisito:

• Ripristino di emergenza
• Attivo-attivo

Il diagramma seguente illustra una distribuzione del ripristino di emergenza.

In una distribuzione con ripristino di emergenza, la piattaforma NSX nel sito principale gestisce la rete per l'azienda. Il sito secondario è in standby e subentra solo in caso di errore irreversibile nel sito primario.

Il diagramma seguente illustra una distribuzione attiva-attiva.

È possibile distribuire due siti per il ripristino automatico o manuale/controllato da script del piano di gestione e del piano dati.

Ripristino automatico del piano di gestione

Requisiti:

• Un cluster vCenter esteso con alta disponibilità (HA) nei siti configurati.
• Una VLAN di gestione estesa.

Il cluster di NSX Manager viene distribuito nella VLAN di gestione e si trova fisicamente nel sito primario. Se si verifica un errore del sito primario, vSphere HA riavvierà gli NSX Manager nel sito secondario. Tutti i nodi di trasporto si riconnetteranno automaticamente agli NSX Manager riavviati. Il processo richiede circa 10 minuti. Durante questo periodo di tempo, il piano di gestione non è disponibile ma questo non influisce in alcun modo sul piano dati.

I diagrammi seguenti illustrano il ripristino automatico del piano di gestione.

Prima del ripristino di emergenza:

Dopo il ripristino di emergenza:

Ripristino automatico del piano dati

Per ottenere il ripristino automatico del piano dati, è possibile configurare domini di errore per i nodi Edge. È possibile raggruppare i nodi Edge di un cluster Edge in diversi domini di errore. NSX Manager posiziona automaticamente qualsiasi nuovo gateway di livello 1 attivo nel dominio di errore preferito e il gateway di livello 1 di standby nell'altro dominio. I gateway di livello 1 distribuiti prima della creazione del dominio di errore mantengono il posizionamento del nodo Edge originale e potrebbero non essere in esecuzione nella posizione desiderata. Se si desidera modificarne la posizione, modificare il gateway di livello 1 selezionando manualmente i nodi Edge per il gateway attivo di livello 1 e il gateway di standby di livello 1.

Requisiti:

• La latenza massima tra i nodi Edge è 10 ms.
• Il routing nord-sud asimmetrico non è realizzabile, ad esempio un firewall fisico viene utilizzato in nordbound verso il nodo di NSX Edge, la modalità HA per il gateway di livello 0 deve essere attivo-standby e la modalità di failover deve essere preventiva.
• Se il routing nord-sud asimmetrico è possibile, ad esempio le due posizioni sono due edifici senza alcun firewall fisico tra loro, la modalità HA per il gateway di livello 0 può essere attiva-attiva.

I nodi Edge possono essere macchine virtuali o bare-metal. La modalità di failover del gateway di livello 1 può essere preventiva o non preventiva, ma è consigliata la modalità preventiva per garantire che i gateway di livello 0 e 1 si trovino nella stessa posizione.

Passaggi di configurazione:

• Utilizzando l'API di, creare domini di errore per i due siti, ad esempio FD1A-Preferred_Site1 e FD2A-Preferred_Site1. Impostare il parametro preferred_active_edge_services su true per il sito primario e su false per il sito secondario.

  POST /api/v1/failure-domains
  {
  "display_name": "FD1A-Preferred_Site1",
  "preferred_active_edge_services": "true"
  }
  
  POST /api/v1/failure-domains
  {
  "display_name": "FD2A-Preferred_Site1",
  "preferred_active_edge_services": "false"
  }

• Utilizzando l'API, configurare un cluster Edge che è stato esteso tra i due siti. Ad esempio, il cluster include i nodi Edge EdgeNode1A e EdgeNode1B nel sito primario e i nodi Edge EdgeNode2A e EdgeNode2B nel sito secondario. Il gateway di livello 0 attivo e il gateway di livello 1 attivo vengono eseguiti in EdgeNode1A e EdgeNode1B. Il gateway di livello 0 di standby e il gateway di livello 1 di standby vengono eseguiti in EdgeNode2A e EdgeNode2B.
• Utilizzando l'API, associare ogni nodo Edge al dominio di errore per il sito. Per recuperare i dati relativi al nodo Edge, eseguire l'API GET /api/v1/transport-nodes/<transport-node-id>. Utilizzare il risultato dell'API GET come input per l'API PUT /api/v1/transport-nodes/<transport-node-id>, con la proprietà failure_domain_id impostata correttamente. Ad esempio,

  GET /api/v1/transport-nodes/<transport-node-id>
  Response:
  
      "resource_type": "TransportNode", 
      "description": "Updated NSX configured Test Transport Node",
      "id": "77816de2-39c3-436c-b891-54d31f580961",
      ...
  }
  
  PUT /api/v1/transport-nodes/<transport-node-id>
  {
      "resource_type": "TransportNode",
      "description": "Updated NSX configured Test Transport Node",
      "id": "77816de2-39c3-436c-b891-54d31f580961",
      ...
      "failure_domain_id": "<UUID>",
  }

• Utilizzando l'API, configurare il cluster Edge per allocare i nodi in base al dominio di errore. Per recuperare i dati relativi al cluster Edge, eseguire l'API GET /api/v1/edge-clusters/<edge-cluster-id>. Utilizzare il risultato dell'API GET come input per l'API PUT /api/v1/edge-clusters/<edge-cluster-id> con la proprietà aggiuntiva allocation_rules impostata correttamente. Ad esempio,

  GET /api/v1/edge-clusters/<edge-cluster-id>
  Response:
  {
      "_revision": 0,
      "id": "bf8d4daf-93f6-4c23-af38-63f6d372e14e",
      "resource_type": "EdgeCluster",
      ...
  }
  
  PUT /api/v1/edge-clusters/<edge-cluster-id>
  {
      "_revision": 0,
      "id": "bf8d4daf-93f6-4c23-af38-63f6d372e14e",
      "resource_type": "EdgeCluster",
      ...
      "allocation_rules": [
          {
              "action": {
                        "enabled": true,
                        "action_type": "AllocationBasedOnFailureDomain"
                        }
          }
      ],
  }

• Creare il gateway di livello 0 eil gatewy di livello 1 utilizzando l'API o l'interfaccia utente di NSX Manager.

Se si verifica un errore dell'intero sito primario, il gateway di standby di livello 0 e il gateway di standby di livello 1 nel sito secondario subentrano automaticamente e diventano i nuovi gateway attivi.

I diagrammi seguenti illustrano il ripristino automatico del piano dati.

Prima del ripristino di emergenza:

Dopo il ripristino di emergenza:

Se si verifica un errore di uno dei nodi Edge nel sito primario, ma non si tratta di un errore dell'intero sito, è importante che venga applicato lo stesso principio. Ad esempio, nel diagramma "Prima del ripristino di emergenza", si supponga che il nodo Edge 1B ospiti il gateway attivo di livello 1 blu e che il nodo Edge 2B ospiti il gateway di standby di livello 1 blu. Se si verifica un errore nel nodo Edge 1B, subentra il gateway di standby di livello 1 blu nel nodo Edge 2B e diventa il nuovo gateway attivo di livello 1 blu.

Ripristino manuale/controllato da script del piano di gestione

Requisiti:

• DNS per NSX Manager con TTL breve, ad esempio 5 minuti.
• Backup continuo di NSX Manager.

Non sono necessari né vSphere HA, né una VLAN di gestione estesa. NSX Manager deve essere associato a un nome DNS con TTL breve. Tutti i nodi di trasporto (nodi Edge e hypervisor) devono connettersi a NSX Manager utilizzando il loro nome DNS. Per risparmiare tempo, è possibile facoltativamente preinstallare un cluster NSX Manager nel sito secondario.

I passaggi per il ripristino sono:

1. Modificare il record DNS in modo che il cluster NSX Manager presenti indirizzi IP diversi.
2. Ripristinare il cluster NSX Manager da un backup.
3. Connettere i nodi di trasporto al nuovo cluster NSX Manager.

I diagrammi seguenti illustrano il ripristino manuale/controllato da script del piano di gestione.

Prima del ripristino di emergenza:

Dopo il ripristino di emergenza:

Ripristino manuale/controllato da script del piano dati

Requisito: la latenza massima tra i nodi Edge deve essere di 150 ms.

I nodi Edge possono essere macchine virtuali o bare-metal. I gateway di livello 0 in ogni posizione possono essere attivo-standby o attivo-attivo. È possibile installare le macchine virtuali del nodo Edge in vCenter Server diversi. vSphere HA non è necessario.

I passaggi per il ripristino sono:

• Per tutti i livelli 1 nel sito primario (blu), aggiornare la configurazione del cluster Edge in modo che sia il sito del cluster Edge secondario.
• Per tutti i livelli 1 nel sito primario (blu), riconnetterli a T0 secondario (verde).

I diagrammi seguenti illustrano il ripristino manuale/controllato da script del piano dati con entrambe le viste della rete logica e fisica.

Prima del ripristino di emergenza (visualizzazioni logiche e fisiche):

Dopo il ripristino di emergenza (visualizzazioni logiche e fisiche):

Requisiti per le distribuzioni multisito

Comunicazione tra siti

• La larghezza di banda deve essere pari ad almeno 1 Gbps e la latenza (RTT) deve essere inferiore a 150 ms.
• Impostare MTU su 9000. Deve essere almeno 1600.

NSX Manager

• Con ripristino automatico del piano di gestione con gestione VLAN estesa tra i siti. vSphere HA tra i siti per le macchine virtuali di NSX Manager.
• Con ripristino manuale/controllato da script del piano di gestione con gestione VLAN estesa tra i siti. VMware SRM per le macchine virtuali di NSX Manager.
• Con ripristino manuale/controllato da script del piano di gestione senza gestione VLAN estesa tra i siti.
  • Backup continuo di NSX Manager.
  • NSX Manager deve essere configurato per l'utilizzo del nome di dominio completo.

Piano dati

• Se gli indirizzi IP pubblici vengono esposti tramite servizi come NAT o il bilanciamento del carico, è necessario utilizzare lo stesso provider Internet.
• Con il ripristino automatico del piano di gestione
  • La latenza massima tra le posizioni è 10 ms.
  • La modalità HA per il gateway di livello 0 deve essere attiva-standby e la modalità di failover deve essere preventiva per evitare il routing asimmetrico.
  • La modalità HA per il gateway di livello 0 può essere attiva-attiva se il routing asimmetrico è accettato (ad esempio edifici diversi in una regione metropolitana).
• Con ripristino manuale/controllato da script del piano di gestione
  • La latenza massima tra le posizioni è 150 ms.

Cloud Management System (CMS)

• CMS deve supportare un plug-in NSX. In questa versione, VMware Integrated OpenStack (VIO) e vRealize Automation (vRA) soddisfano questo requisito.

Limitazioni

• Nessuna funzionalità di uscita locale. Tutto il traffico nord-sud deve avvenire all'interno di un sito.
• Il software per il ripristino di emergenza deve supportare NSX, ad esempio VMware Site Recovery Manager 8.1.2 o versione successiva.
• Se si ripristinano NSX Manager in un ambiente con più siti, eseguire le operazioni seguenti nel sito secondario/primario:
  • Dopo la sospensione del processo di ripristino al passaggio AggiungiNodoACluster, è innanzitutto necessario rimuovere il VIP esistente e impostare il nuovo IP virtuale nella pagina dell'interfaccia utente Sistema > Appliance prima di aggiungere nodi del gestore.
  • Aggiungere nuovi nodi a un cluster con un solo nodo ripristinato dopo l'aggiornamento del VIP.