von Redaktion IT-A…
Lesezeit
2 Minuten
Seite 2 - vSphere: Best Practices für Infrastruktur, Betrieb & Troubleshooting (1)
Fehlerquelle DNS
VMware-vSphere-Cluster sind in hohem Maße abhängig von korrekter Namensauflösung. Eine lückenlose Registrierung des vCenters, aller Hosts und aller beteiligten Zusatzprodukte im DNS (Forward und Reverse) ist zwingend erforderlich. Kann ein Name oder eine IP-Adresse nicht erfolgreich aufgelöst werden, sind Verbindungsprobleme die Folge. Diese sind oft nicht direkt als solche erkennbar und äußern sich in seltsamen Fehlfunktionen. Beim Troubleshooting gehört daher ein nslookup zu den ersten Kontrollen. Ist der richtige DNS-Server in vCenter eingetragen und kann dieser die IP-Adressen und Hostnamen der ESX-Server auflösen? Als scherzhafte Faustregel mit ernstem Hintergrund gilt: Wenn DNS als Ursache nicht in Frage kommt, dann sollten Sie DNS nochmals überprüfen.
Durch Verwendung virtueller Domaincontroller (DC) oder DNS-Server kann Hochverfügbarkeit durch ESX-integrierte Funktionen wie High Availability (HA) oder Fault Tolerance (FT) gewährleistet werden. Auch Backup und Recovery des DC gestalten sich wesentlich einfacher, wenn dieser virtuell ist. In seltenen Fällen ist es jedoch notwendig, ganze Datacenter abzuschalten, weil dort beispielsweise Wartungsarbeiten an der Stromversorgung durchgeführt werden müssen. Versuchen Sie im Anschluss, einen solchen ESX-Cluster wieder kalt zu starten, fehlen den Hosts zunächst die DC/DNS-Server und eine Namensauflösung oder eine Authentifizierung ist nicht möglich. In solchen Fällen ersparen Sie sich einigen Ärger, wenn im LAN ein physischer DNS-Server verfügbar ist, den die ESX-Hosts beim Systemstart abfragen können. Wird Microsofts Active Directory verwendet, so empfiehlt sich zusätzlich zum virtuellen DC ein Read-only-Domaincontroller (RODC) auf physischer Hardware.
Fehlerquelle LAN
Über mögliche Fehlerquellen im LAN lassen sich ganze Bände füllen. Im Zusammenhang mit ESX-Clustern sollten Sie jedoch zur Problemvermeidung einige grundlegende Regeln beachten. Datenverkehr und iSCSI-Storage sollten auf dem ESX-Host über digitale Adapter-Ports geführt werden. Den iSCSI-Datenverkehr sollten Sie zumindest über ein eigenes VLAN, besser jedoch über eigene Hardware-Infrastruktur führen.
Eine der Kerneigenschaften von ESX-Clustern ist die Fähigkeit, VMs im laufenden Betrieb von einem Host auf einen anderen zu migrieren (vMotion). Während einer Migration werden große Datenmengen zwischen Quell- und Zielhost über das LAN bewegt. Häufig wird hierfür dasselbe Interface verwendet wie für das Servermanagement oder gar das iSCSI-SAN. Auch wenn dies erlaubt ist, ist es nicht zu empfehlen. Es besteht die Möglichkeit des Kontaktverlustes zum Host oder das Auftreten starker Latenzen auf dem SAN. Besser sollten Sie dedizierte Ports für vMotion anlegen, die nicht den VM-Datenverkehr oder das Host-Management beeinträchtigen. In der Knowledge-Base (KB) von VMware gibt es einen ausführlichen Artikel [2], der die Einrichtung getrennter VM-Kernel-Ports für vMotion erklärt.
Anstatt vMotion über nur einen Kernel-Port und damit einen physischen Adapter zu führen, ist es empfehlenswert, dafür mehrere Verbindungen bereitzustellen. Man spricht dann vom "Multi-Nic-vMotion". Die dafür notwendigen Portgruppen und Kernel-Ports können wahlweise in der GUI des vSphere-Clients oder über PowerCLI-Kommandos konfiguriert werden. Mit zunehmender Anzahl Hosts lohnt sich ein Skript. Im zweiten Teil des Workshops besprechen wir die dazu notwendigen PowerCLI-Befehle nur exemplarisch. Für größere Umgebungen wäre auch das zu umständlich. Hier ist der Weg der Wahl, die Daten (Hostname, IP-Adresse der Kernel-Ports, physischer Uplink) in einer CSV-Datei abzulegen, die dann von einem Skript gelesen und dynamisch verarbeitet wird.
Multi-NIC-vMotion lässt sich mit klassischen Standard-vSwitches und mit verteilten (distributed) vSwitches (dvSwitch) realisieren. Es wird ein vSwitch mit zwei physischen Uplinks erzeugt, dessen Name (vSwitch2) zuvor noch nicht verwendet wurde. Die physischen Uplink-Ports müssen frei sein. Auf dem neuen vSwitch werden zwei Portgruppen angelegt mit jeweils einem Kernel-Port in einem eigenen VLAN. Hier finden Sie die Kommandos einzeln erläutert, jedoch sind diese wesentlich leistungsfähiger und vielseitiger im Rahmen eines Skripts.
Seite 1: Blick in die Hardware Compatibility List
Seite 2: Fehlerquellen in DNS und LAN
Im zweiten Teil des Workshops schauen wir uns die Erzeugung von vSwitches und Distributed Switches an und erklären das Ressourcen-Pool-Paradoxon. Im dritten Teil geht es darum, wie sich vSphere-Admins mit Drittwerkzeugen vor allem beim Monitoring das Leben leichter machen.
dr/ln/Dr. Jens Söldner und Dr. Michael Schröder
[2] https://kb.vmware.com/s/article/2007467
VMware-vSphere-Cluster sind in hohem Maße abhängig von korrekter Namensauflösung. Eine lückenlose Registrierung des vCenters, aller Hosts und aller beteiligten Zusatzprodukte im DNS (Forward und Reverse) ist zwingend erforderlich. Kann ein Name oder eine IP-Adresse nicht erfolgreich aufgelöst werden, sind Verbindungsprobleme die Folge. Diese sind oft nicht direkt als solche erkennbar und äußern sich in seltsamen Fehlfunktionen. Beim Troubleshooting gehört daher ein nslookup zu den ersten Kontrollen. Ist der richtige DNS-Server in vCenter eingetragen und kann dieser die IP-Adressen und Hostnamen der ESX-Server auflösen? Als scherzhafte Faustregel mit ernstem Hintergrund gilt: Wenn DNS als Ursache nicht in Frage kommt, dann sollten Sie DNS nochmals überprüfen.
Durch Verwendung virtueller Domaincontroller (DC) oder DNS-Server kann Hochverfügbarkeit durch ESX-integrierte Funktionen wie High Availability (HA) oder Fault Tolerance (FT) gewährleistet werden. Auch Backup und Recovery des DC gestalten sich wesentlich einfacher, wenn dieser virtuell ist. In seltenen Fällen ist es jedoch notwendig, ganze Datacenter abzuschalten, weil dort beispielsweise Wartungsarbeiten an der Stromversorgung durchgeführt werden müssen. Versuchen Sie im Anschluss, einen solchen ESX-Cluster wieder kalt zu starten, fehlen den Hosts zunächst die DC/DNS-Server und eine Namensauflösung oder eine Authentifizierung ist nicht möglich. In solchen Fällen ersparen Sie sich einigen Ärger, wenn im LAN ein physischer DNS-Server verfügbar ist, den die ESX-Hosts beim Systemstart abfragen können. Wird Microsofts Active Directory verwendet, so empfiehlt sich zusätzlich zum virtuellen DC ein Read-only-Domaincontroller (RODC) auf physischer Hardware.
Fehlerquelle LAN
Über mögliche Fehlerquellen im LAN lassen sich ganze Bände füllen. Im Zusammenhang mit ESX-Clustern sollten Sie jedoch zur Problemvermeidung einige grundlegende Regeln beachten. Datenverkehr und iSCSI-Storage sollten auf dem ESX-Host über digitale Adapter-Ports geführt werden. Den iSCSI-Datenverkehr sollten Sie zumindest über ein eigenes VLAN, besser jedoch über eigene Hardware-Infrastruktur führen.
Eine der Kerneigenschaften von ESX-Clustern ist die Fähigkeit, VMs im laufenden Betrieb von einem Host auf einen anderen zu migrieren (vMotion). Während einer Migration werden große Datenmengen zwischen Quell- und Zielhost über das LAN bewegt. Häufig wird hierfür dasselbe Interface verwendet wie für das Servermanagement oder gar das iSCSI-SAN. Auch wenn dies erlaubt ist, ist es nicht zu empfehlen. Es besteht die Möglichkeit des Kontaktverlustes zum Host oder das Auftreten starker Latenzen auf dem SAN. Besser sollten Sie dedizierte Ports für vMotion anlegen, die nicht den VM-Datenverkehr oder das Host-Management beeinträchtigen. In der Knowledge-Base (KB) von VMware gibt es einen ausführlichen Artikel [2], der die Einrichtung getrennter VM-Kernel-Ports für vMotion erklärt.
Anstatt vMotion über nur einen Kernel-Port und damit einen physischen Adapter zu führen, ist es empfehlenswert, dafür mehrere Verbindungen bereitzustellen. Man spricht dann vom "Multi-Nic-vMotion". Die dafür notwendigen Portgruppen und Kernel-Ports können wahlweise in der GUI des vSphere-Clients oder über PowerCLI-Kommandos konfiguriert werden. Mit zunehmender Anzahl Hosts lohnt sich ein Skript. Im zweiten Teil des Workshops besprechen wir die dazu notwendigen PowerCLI-Befehle nur exemplarisch. Für größere Umgebungen wäre auch das zu umständlich. Hier ist der Weg der Wahl, die Daten (Hostname, IP-Adresse der Kernel-Ports, physischer Uplink) in einer CSV-Datei abzulegen, die dann von einem Skript gelesen und dynamisch verarbeitet wird.
Multi-NIC-vMotion lässt sich mit klassischen Standard-vSwitches und mit verteilten (distributed) vSwitches (dvSwitch) realisieren. Es wird ein vSwitch mit zwei physischen Uplinks erzeugt, dessen Name (vSwitch2) zuvor noch nicht verwendet wurde. Die physischen Uplink-Ports müssen frei sein. Auf dem neuen vSwitch werden zwei Portgruppen angelegt mit jeweils einem Kernel-Port in einem eigenen VLAN. Hier finden Sie die Kommandos einzeln erläutert, jedoch sind diese wesentlich leistungsfähiger und vielseitiger im Rahmen eines Skripts.
Seite 2: Fehlerquellen in DNS und LAN
Im zweiten Teil des Workshops schauen wir uns die Erzeugung von vSwitches und Distributed Switches an und erklären das Ressourcen-Pool-Paradoxon. Im dritten Teil geht es darum, wie sich vSphere-Admins mit Drittwerkzeugen vor allem beim Monitoring das Leben leichter machen.
| << Vorherige Seite | Seite 2 von 2 |
dr/ln/Dr. Jens Söldner und Dr. Michael Schröder
[2] https://kb.vmware.com/s/article/2007467
