Runecast-Akademie
6
:

Vernetzung

In diesem Artikel konzentrieren wir uns auf Netzwerkthemen im Zusammenhang mit dem vSphere Standard Switch (vSwitch).

Vernetzung

In diesem Artikel konzentrieren wir uns auf Netzwerkthemen im Zusammenhang mit dem vSphere Standard Switch (vSwitch).

Zu den wichtigsten Bereichen, die wir hier abdecken, gehören:

  • Was Portgruppen sind und wie sie funktionieren
  • Arten von Netzwerkkarten für virtuelle Maschinen und Hinweise zu physischen Netzwerkadaptern
  • Und schließlich die Sicherheit (einschließlich Promiscuous-Modus und gefälschte Übertragungen)

Runecast Academy Serie 1 - Teil 6. Networking

Wir haben also eine virtuelle Maschine, die vom Hypervisor gesteuert wird und deren Daten auf dem Datenspeicher gespeichert sind. Jetzt möchten Sie eine Verbindung zu dieser Maschine herstellen und Daten mit ihr austauschen, richtig? Lassen Sie uns das Netzwerk auf dem ESXi-Server konfigurieren.

vSphere-Standard-Switch

Das Herzstück des ESXi-Netzwerks ist der vSphere Standard Switch (vSwitch), ein recht einfacher, aber sehr stabiler und leistungsfähiger Dienst, der wie ein einfacher Layer-2-Switch funktioniert und Daten entsprechend den MAC-Adressen überträgt. vSwitch muss keine MAC-Adressen aus dem Datenverkehr lernen, da ESXi bereits weiß, welche MAC-Adresse auf welcher Netzwerkkarte der virtuellen Maschine konfiguriert ist. Dies kann Kopfschmerzen verursachen, wenn Sie eine VM innerhalb einer VM ausführen möchten, da die super-virtualisierte MAC dem physischen ESXi-Host nicht bekannt ist. vSwitch hat keine separate Verwaltung, er ist ein integraler Bestandteil des ESXi-Servers, und wir können ESXi (oder vCenter) Verwaltungswerkzeuge verwenden, um ihn zu konfigurieren. Der vSwitch wird für jeden ESXi-Server separat definiert und konfiguriert.


Hafengruppen

Wie wäre es, einige virtuelle Maschinen an den vSwitch anzuschließen? Dazu müssen wir die Portgruppe(n) definieren. Es mag ein wenig unwahrscheinlich klingen, aber der Name der Portgruppe ist nicht nur ein Etikett, sondern der Hauptbezeichner der Portgruppe. Die Netzwerkkarte der VM ist über den Namen mit der Portgruppe verbunden, und wenn wir die VM zwischen ESXi-Hosts migrieren, wird sie automatisch mit der Portgruppe verbunden, die denselben Namen trägt wie die ursprüngliche, unabhängig davon, wie sie konfiguriert ist. Wenn wir nicht vorsichtig genug sind, kann unsere VM nach der vMotion leicht offline werden.

Jede Portgruppe hat eine konfigurierte VLAN-Richtlinie. Sie kann 0 sein, wenn das native VLAN auf dem physischen Switch-Port konfiguriert ist. Das bringt ein kleines Labyrinth in das Netzwerkdesign. Sie kann eine echte VLAN-ID sein, wenn sich VLANs in einem Trunk am physischen Switch-Port befinden. Sie kann auch 4095 sein, was bedeutet, dass die Daten unverändert an die VM gesendet werden und das Betriebssystem selbst das VLAN-Tagging übernimmt. Es muss einen wirklich guten Grund geben, die letzte Option zu verwenden.

Vom Standpunkt des virtuellen Switches aus betrachtet, sind VMkernel-Netzwerkadapter spezielle Arten von Portgruppen, der einzige Unterschied besteht darin, dass wir dort keine angeschlossenen VMs haben, aber das ESXi-Management kommuniziert darüber.

Netzwerkkarten für virtuelle Maschinen

VMs können mit bis zu 10 virtuellen Netzwerkkarten (vNICs) konfiguriert werden. Normalerweise verwenden wir VMXNET 3 oder möglicherweise den E1000 vNIC-Typ. E1000 ist die Emulation der generischen Intel E1000 Netzwerkkarte. Die meisten Betriebssysteme unterstützen sie und wir können sie sofort verwenden. Da es sich jedoch um eine emulierte physische Karte handelt, muss das Betriebssystem sie wie ein physisches Gerät mit allen Unterbrechungen und Aufrufen handhaben, und ESXi wiederum muss sie emulieren. Da die Intel E1000 eine 1-Gb-Karte ist, könnte ein solcher Durchsatz nicht ausreichen. Wenn wir kein super-exotisches Betriebssystem verwenden, dann haben wir VMXNET 3, das vom Betriebssystem selbst unterstützt wird, oder der Treiber kann als Teil der VMware Tools installiert werden. Wie sieht VMXNET 3 von der Seite des Betriebssystems aus? Wir können es uns wie ein Loch vorstellen - eines, in das wir einfach Daten einwerfen und das Antworten aus dem Netzwerk ausspuckt. Das Betriebssystem muss sich nicht darum kümmern, und die Geschwindigkeit wird nur durch die Host-CPU begrenzt.

Wenn zwei VMs auf demselben ESXi-Host laufen, die mit demselben Subnetz verbunden sind, und versuchen, einen Ping von der einen zur anderen zu senden, gelangen die Daten in den vSwitch. vSwitch kennt bereits die MAC-Adresse des virtuellen Ports der Ziel-VM, und wenn die Einstellung der Portgruppe dies zulässt, werden die Daten direkt an die Ziel-VM übermittelt.

Physikalische Netzwerkadapter

Wahrscheinlich wollen wir von der Außenwelt auf unsere VM zugreifen. Dazu benötigen wir einige Uplink-Ports (physische Netzwerkkarten), die dem vSwitch zugewiesen sind. Physikalische NICs mit einer Geschwindigkeit von bis zu 100 Gb werden unterstützt, aber seien Sie sehr vorsichtig bei der Auswahl und Installation von Firmware und Treibern und stellen Sie sicher, dass die verwendete Kombination mit der Hardware Compatibility List (HCL) übereinstimmt. Eine nicht unterstützte Kombination kann zu Konnektivitätsproblemen oder sogar zu einem PSOD führen.

Um eine hohe Verfügbarkeit zu gewährleisten, wollen wir mindestens zwei Uplinks pro virtuellem Switch verwenden. Wie entscheidet der vSwitch, welche Daten durch welches physische Kabel gehen? Standardmäßig wird für jede virtuelle Netzwerkkarte eine physische Netzwerkkarte "zufällig" (nun ja, "zufällig" gemäß der virtuellen Port-ID) ausgewählt, und das ändert sich nur, wenn die physische Verbindung unterbrochen wird. Wir können eine etwas ausgewogenere Auslastung der Uplinks erreichen, indem wir die Route Based on IP Hash-Methode verwenden. Dann wird der Pfad für jedes Paket einzeln ausgewählt, was uns etwas CPU-Leistung kostet und von den physischen Switches möglicherweise nicht erwartet wird. Wir können auch eine strenge Aktiv-Passiv-Richtlinie einrichten.

Sicherheit

Normalerweise brauchen wir die Sicherheitseinstellungen des vSwitch nicht zu ändern. Aber der VM-Besitzer, typischerweise aus der Sicherheits- oder Netzwerkabteilung Team, kann neben unserem Schreibtisch erscheinen und uns zwingen, einige der Sicherheitseinstellungen für seine VM fein abzustimmen. Höchstwahrscheinlich wird er den Promiscuous-Modus zulassen wollen. Wenn wir diese Einstellung auf Akzeptieren ändern, empfängt die VM alle Frames, die gemäß der konfigurierten VLAN-Richtlinie auf der Portgruppe erlaubt sind, unabhängig davon, ob sie an die VM adressiert sind oder nicht. Standardmäßig unterstützt vSwitch keine Port-Spiegelung und der Promiscuous-Modus kann in diesem Fall als Workaround verwendet werden. Um den gesamten vSwitch-Verkehr in die überwachende VM zu leiten, verwenden Sie ihn in Kombination mit einem auf 4095 konfigurierten VLAN.

Die "physische" MAC-Adresse wird auf der VMware-Seite konfiguriert, und diese wird normalerweise vom Betriebssystem wiederverwendet, aber das Betriebssystem kann die Einstellung umschreiben. Ohne besondere Gründe wollen wir dies nicht zulassen, da eine solche virtuelle Maschine dann anstelle eines anderen Servers Anfragen senden oder Daten empfangen könnte, die für etwas anderes bestimmt sind. Die Sicherheitseinstellung MAC-Adressänderungen auf Annehmen bewirkt, dass Frames an den VM-Adapter zugestellt werden, auch wenn die auf der VMware-Seite konfigurierte MAC anders ist. Um der VM zu ermöglichen, Pakete mit unterschiedlichen MAC-Adressen zu senden, akzeptieren Sie Gefälschte Übertragungen.

Schlussfolgerung

vSphere Standard Switch ist ein leichtgewichtiger Dienst, der unabhängig von vCenter oder einer anderen zentralisierten Verwaltung ist. Die Verwendung von vSphere Standard Switch könnte etwas einschränkend sein, aber im Gegenzug bringt es Unabhängigkeit vom vCenter und als Bonus ist es in der Standard vSphere Lizenz enthalten. Alternativ können wir auch vSphere Distributed Switch (dvSwitch) verwenden, das in einem zukünftigen Runecast Academy-Artikel beschrieben wird.

Martin Rehula

Martin ist ein VMware-Ingenieur bei Runecast. Er begann seine Karriere als UNIX-Administrator, aber als er zum ersten Mal mit VMware ESX in Berührung kam (damals in den Tagen von v2.5), beschloss er, im Bereich der Virtualisierung zu bleiben. Er war Administrator in VMware- und Citrix-basierten virtuellen Umgebungen mit Schwerpunkt auf zentralisiertem Management und Automatisierung bei Tieto und Hella. Vielleicht treffen Sie ihn in der Stadt, im Wald oder in den Bergen - auf der Suche nach dem entscheidenden Moment und Punkt, den er mit seiner Kamera einfangen kann. Sie finden ihn auf Twitter als @virt4all.

Alle Artikel der Akademie
Keine Artikel gefunden.