Konfiguration 2: Mehrere vmknics, Anhand der ursprünglichen ID des Ports routen

Sie können zwei nicht routingfähige VLANs verwenden, die logisch und physisch getrennt sind, um eine Air-Gap-Topologie zu erstellen.

In diesem Beispiel werden Konfigurationsschritte für einen vSphere Distributed Switch bereitgestellt, aber Sie können auch vSphere Standard-Switches verwenden. Es werden zwei physische Netzwerkkarten mit 10 GB verwendet und logisch auf der vSphere-Netzwerkschicht geteilt.

Erstellen Sie zwei verteilte Portgruppen für jede vSAN VMkernel-vmknic. Jede Portgruppe verfügt über ein separates VLAN-Tag. Für die vSAN VMkernel-Konfiguration sind zwei IP-Adressen in beiden VLANs für den vSAN-Datenverkehr erforderlich.

Hinweis:

Bei praktischen Implementierungen werden üblicherweise vier physische Uplinks für die vollständige Redundanz verwendet.

Für jede Portgruppe werden hinsichtlich der Gruppierungs- und Failover-Richtlinien die Standardeinstellungen verwendet.

• Lastausgleich festgelegt auf Anhand der ursprünglichen ID des Ports routen

• Netzwerkfehlererkennung festgelegt auf Nur Verbindungsstatus

• „Switches benachrichtigen“ festgelegt auf den Standardwert Ja

• Failback festgelegt auf den Standardwert Ja

• Die Uplink-Konfiguration verfügt über einen Uplink in der Position Aktiv Position und einen Uplink in der Position Nicht verwendet.

Ein Netzwerk ist vollständig vom anderen Netzwerk isoliert.

vSAN-Portgruppe 1

In diesem Beispiel wird eine verteilte Portgruppe mit dem Namen vSAN-DPortGroup-1 verwendet. VLAN 3266 ist für diese Portgruppe mit der folgenden Gruppierungs- und Failover-Richtlinie gekennzeichnet:

• Datenverkehr auf der Portgruppe mit dem Tag VLAN 3266

• Lastausgleich festgelegt auf Anhand der ursprünglichen ID des Ports routen

• Netzwerkfehlererkennung festgelegt auf Nur Verbindungsstatus

• „Switches benachrichtigen“ festgelegt auf den Standardwert Ja

• Failback festgelegt auf den Standardwert Ja

• In der Uplink-Konfiguration ist Uplink 1 in der Position Aktiv und Uplink 2 in der Position Nicht verwendet.

vSAN-Portgruppe 2

Konfigurieren Sie zur Ergänzung von vSAN-Portgruppe 1 eine zweite verteilte Portgruppe mit dem Namen vSAN-portgroup-2 mit den folgenden Unterschieden:

• Datenverkehr auf der Portgruppe mit dem Tag VLAN 3265

• In der Uplink-Konfiguration ist Uplink 2 in der Position Aktiv und Uplink 1 in der Position Nicht verwendet.

vSAN VMkernel-Portkonfiguration

Erstellen Sie zwei vSAN-VMkernel-Schnittstellen auf beiden Portgruppen. In diesem Beispiel werden die Portgruppen vmk1 und vmk2 benannt.

• vmk1 ist mit VLAN 3266 (172.40.0.xx) verknüpft und demzufolge die Portgruppe vSAN-DPortGroup-1.

• vmk2 ist mit VLAN 3265 (192.60.0.xx) verknüpft und demzufolge die Portgruppe vSAN-DPortGroup-2.

Lastausgleich

vSAN verfügt über keinen Lastausgleichsmechanismus, um zwischen mehreren vmknics zu unterscheiden, sodass der ausgewählte E/A-Pfad für vSAN nicht über physische Netzwerkkarten hinweg deterministisch ist. Die vSphere-Leistungsdiagramme zeigen, dass eine physische Netzwerkkarte häufig stärker ausgelastet ist als die andere. Ein einfacher E/A-Test, der in unseren Labors durchgeführt wurde mit 120 VMs mit einem Lese-/Schreibverhältnis von 70:30 und einer Blockgröße von 64 KB auf einem vSAN-All-Flash-Cluster mit vier Hosts ergab eine unausgeglichene Last der Netzwerkkarten.

vSphere-Leistungsdiagramme zeigen eine nicht ausgeglichene Last für die verschiedenen Netzwerkkarten.

Netzwerk-Uplink-Redundanz verloren

Berücksichtigen Sie einen Netzwerkfehler, der in dieser Konfiguration eingeführt wurde. vmnic1 ist auf einem bestimmten vSAN-Host nicht aktiviert. Dadurch wird Port vmk2 beeinträchtigt. Eine fehlerhafte Netzwerkkarte löst sowohl Netzwerkkonnektivitätsalarme als auch Redundanzalarme aus.

Für vSAN wird dieser Failover-Vorgang nach ungefähr 10 Sekunden ausgelöst, sobald CMMDS (Clusterüberwachung, Mitgliedschaft und Verzeichnisdienste) einen Fehler erkannt hat. Während des Failovers und der Wiederherstellung stoppt vSAN alle aktiven Verbindungen für das fehlerhafte Netzwerk ab und versucht, Verbindungen im noch funktionstüchtigen Netzwerk wiederherzustellen.

Da zwei getrennte vSAN VMkernel-Ports in isolierten VLANs kommunizieren, können vSAN-Systemzustandsprüfungsfehler ausgelöst werden. Dies wird erwartet, da vmk2 nicht mehr mit seinen Peers über VLAN 3265 kommunizieren kann.

Die Leistungsdiagramme zeigen, dass die betroffene Arbeitslast auf vmnic0 neu gestartet wurde, da vmnic1 einen Fehler aufweist. Dieser Test veranschaulicht einen wichtigen Unterschied zwischen der vSphere NIC-Gruppierung und dieser Topologie. vSAN versucht, Verbindungen im verbleibenden Netzwerk erneut herzustellen oder neu zu starten.

In einigen Fehlerszenarien kann die Wiederherstellung der betroffenen Verbindungen jedoch aufgrund des ESXi TCP-Verbindungszeitüberschreitung bis zu 90 Sekunden dauern. Nachfolgende Verbindungsversuche schlagen möglicherweise fehl, aber für die Verbindungsversuche tritt bei 5 Sekunden eine Zeitüberschreitung ein, und die Versuche durchlaufen alle möglichen IP-Adressen. Dieses Verhalten kann sich auf die Gast-E/A der virtuellen Maschine auswirken. Folglich müssen die E/A-Vorgänge für Anwendungen und virtuelle Maschinen möglicherweise erneut versucht werden.

Auf Windows Server 2012-VMs werden möglicherweise während des Failover- und Wiederherstellungsvorgangs die Ereignis-IDs 153 (Gerät zurücksetzen) und 129 (Wiederholungsereignisse) protokolliert. In dem Beispiel wurde die Ereignis-ID 129 für ca. 90 Sekunden protokolliert, bis die E/A wiederhergestellt wurde.

Möglicherweise müssen Sie die Zeitüberschreitungseinstellungen für Datenträger einiger Gastbetriebssysteme ändern, um sicherzustellen, dass sie nicht schwerwiegend beeinträchtigt werden. Datenträger-Zeitüberschreitungswerte können variieren. Dies ist von den vorhandenen VMware Tools und dem jeweiligen Typ und der jeweiligen Version des Gastbetriebssystems abhängig. Weitere Informationen zum Ändern der Werte für die Datenträger-Zeitüberschreitung des Gastbetriebssystems finden Sie im VMware-Knowledgebase-Artikel 1009465.

Wiederherstellung und Failback

Beim Reparieren des Netzwerks werden Arbeitslasten nicht automatisch neu verteilt, es sei denn, die Arbeitslast wird aufgrund eines anderen Fehlers nicht erzwungen. Sobald das betroffene Netzwerk wiederhergestellt wurde, ist es für neue TCP-Verbindungen verfügbar.