È possibile utilizzare due VLAN non instradabili separate a livello logico e fisico per produrre una topologia air gap.

In questo esempio vengono forniti i passaggi di configurazione per un vSphere Distributed Switch ma è anche possibile utilizzare vSphere Standard Switch. Utilizza due NIC fisiche da 10 Gb e le separa logicamente a livello della rete vSphere.

Creare due gruppi di porte distribuiti per ogni vmknic VMkernel vSAN. Ogni gruppo di porte ha un tag VLAN separato. Per la configurazione VMkernel di vSAN, per il traffico vSAN sono necessari due indirizzi IP su entrambe le VLAN.

Nota:

Le implementazioni pratiche utilizzano in genere quattro uplink fisici per la ridondanza completa.

Per ogni gruppo di porte, il criterio di raggruppamento e failover utilizza le impostazioni predefinite.

  • Bilanciamento del carico impostato su Route in base all'ID della porta di origine

  • Rilevamento errori di rete impostato su Solo stato link

  • Commutatori di notifica impostati sul valore predefinito

  • Failback impostato sul valore predefinito

  • La configurazione di uplink ha un uplink nella posizione Attivo e un uplink nella posizione Non utilizzato.

Una rete è completamente isolata dall'altra rete.

Gruppo di porte 1 vSAN

In questo esempio viene utilizzato un gruppo di porte distribuito denominato vSAN-DPortGroup-1. VLAN 3266 è contrassegnato per questo gruppo di porte con i seguenti criteri di raggruppamento e failover:

  • Traffico nel gruppo di porte contrassegnato con VLAN 3266

  • Bilanciamento del carico impostato su Route in base all'ID della porta di origine

  • Rilevamento errori di rete impostato su Solo stato link

  • Commutatori di notifica impostati sul valore predefinito

  • Failback impostato sul valore predefinito

  • La configurazione di uplink prevede Uplink 1 nella posizione Attivo e Uplink 2 nella posizione Non utilizzato.

Più vmnic, route in base alla porta di origine

Gruppo di porte 2 vSAN

Per integrare il gruppo di porte 1 di vSAN, configurare un secondo gruppo di porte distribuito denominato vSAN-portgroup-2 con le seguenti differenze:

  • Traffico nel gruppo di porte contrassegnato con VLAN 3265

  • La configurazione di uplink prevede Uplink 2 nella posizione Attivo e Uplink 1 nella posizione Non utilizzato .

Configurazione della porta VMkernel di vSAN

Creare due interfacce VMkernel di vSAN e su entrambi i gruppi di porte. In questo esempio, i gruppi di porte sono denominati vmk1 e vmk2.

  • vmk1 è associato alla VLAN 3266 (172.40.0.xx) e di conseguenza al gruppo di porte vSAN-DPortGroup-1.

  • vmk2 è associato alla VLAN 3265 (192.60.0.xx) e di conseguenza al gruppo di porte vSAN-DPortGroup-2.

Configurazione delle porte VMkernel

Bilanciamento del carico

vSAN non dispone di un meccanismo di bilanciamento del carico per differenziare tra vmknic multiple, quindi il percorso di I/O vSAN scelto non è deterministico tra le NIC fisiche. I grafici delle prestazioni di vSphere mostrano che spesso viene utilizzata una NIC fisica rispetto all'altra. Da un semplice test I/O eseguito nei nostri laboratori utilizzando 120 macchine virtuali con un rapporto di lettura/scrittura di 70:30 con una dimensione di blocco di 64K in un cluster vSAN all-flash con quattro host è emerso un carico non bilanciato tra le NIC.

I grafici delle prestazioni di vSphere mostrano un carico non bilanciato tra le NIC.

Ridondanza uplink di rete persa

Si consideri un errore di rete introdotto in questa configurazione. vmnic1 non è abilitata in un determinato host vSAN. Questo influisce sulla porta vmk2. Una scheda NIC non riuscita attiva sia gli allarmi di connettività di rete sia gli allarmi di ridondanza.

Per vSAN, questo processo di failover si attiva circa 10 secondi dopo che CMMDS (monitoraggio del cluster, appartenenza e servizi Directory) rileva un errore. Durante il failover e il ripristino, vSAN interrompe tutte le connessioni attive nella rete non riuscita e tenta di ristabilire le connessioni nella rete funzionante.

Poiché due porte VMkernel di vSAN separate comunicano su VLAN isolate, potrebbero essere attivati errori dei controlli dell'integrità vSAN. Tale condizione è prevista poiché vmk2 non può più comunicare con i relativi peer nella VLAN 3265.

I grafici delle prestazioni mostrano che il carico di lavoro interessato è stato riavviato in vmnic0, perché in vmnic1 è presente un errore. Questo test illustra un'importante distinzione tra il raggruppamento NIC di vSphere e questa topologia. vSAN tenta di ristabilire o riavviare le connessioni sulla rete rimanente.

Tuttavia, in alcuni scenari di errore, il ripristino delle connessioni interessate potrebbe richiedere fino a 90 secondi a causa del timeout della connessione TCP ESXi. I successivi tentativi di connessione potrebbero non riuscire ma il timeout dei tentativi di connessione si verifica dopo 5 secondi e i tentativi vengono eseguiti su tutti i possibili indirizzi IP. Questo comportamento può influire sull'I/O guest della macchina virtuale. Di conseguenza, potrebbe essere necessario riprovare l'I/O dell'applicazione e della macchina virtuale.

Ad esempio, nelle macchine virtuali Windows Server 2012, durante il processo di failover e ripristino potrebbero essere registrati gli ID eventi 153 (reimpostazione del dispositivo) e 129 (eventi nuovi tentativi). Nell'esempio, l'ID evento 129 veniva registrato per circa 90 secondi finché l'I/O non veniva ripristinato.

Potrebbe essere necessario modificare le impostazioni di timeout del disco di alcuni sistemi operativi guest per verificare che non siano gravemente interessate. I valori di timeout del disco possono variare a seconda della presenza di VMware Tools, nonché del tipo e della versione specifici del sistema operativo guest. Per ulteriori informazioni sulla modifica dei valori di timeout del disco del sistema operativo guest, consultare l'articolo 1009465 della Knowledge Base di VMware.

Ripristino e failback

Quando la rete viene riparata, i carichi di lavoro non vengono ribilanciati automaticamente a meno che non si verifichi un altro errore per forzare il carico di lavoro a causa di un altro errore. Non appena la rete coinvolta viene ripristinata, diventa disponibile per nuove connessioni TCP.