Fachartikel

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.

<< Vorherige Seite Seite 2 von 2
3.05.2021/dr/ln/Dr. Jens Söldner und Dr. Michael Schröder

Nachrichten

Zerto für Kubernetes erhältlich [21.04.2021]

Zerto hat die Verfügbarkeit von Zerto for Kubernetes (Z4K) bekanntgegeben und eine Vorschau auf Zerto 9.0 präsentiert. Z4K wendet Zertos Continuous-Data-Protection-Technologie auf containerisierte Anwendungen an und soll damit eine neue Sichtweise für die Sicherung und Notfallwiederherstellung von Anwendungen und Daten über Infrastrukturen in Cloud- und On-Premises hinweg bieten. [mehr]

Dell trennt sich von VMware [15.04.2021]

Nach gut 17 Jahren wird VMware offenbar wieder zu einem eigenständigen Unternehmen. Dell, das knapp 81 Prozent an VMware hält, will sich im vierten Quartal dieses Jahres von seiner Beteiligung trennen. Dadurch hofft das Unternehmen auf knapp 10 Milliarden US-Dollar, um so unter anderem bestehende Schulden zu tilgen. [mehr]

Tipps & Tools

Benutzerrollen in Microsoft Teams verwalten [4.04.2021]

Microsoft Teams gehört derzeit zu den am meisten verwendeten Diensten in Microsoft 365. Auch hierfür gibt es verschiedene Benutzerrollen. Unser Tipp erklärt die wichtigsten Gruppen für die Verwaltung und Delegierung von Microsoft Teams und zeigt anhand eines Beispiels, wie Sie einem Benutzer eine Rolle zuweisen. [mehr]

OTRS Community Edition lebt als Fork weiter [25.03.2021]

Nach dem abrupten Aus der populären Community-Edition des Ticketsystems OTRS setzt sich ein neu formierter Zusammenschluss von IT-Dienstleistern für ihren Fortbestand ein. Konkret hat sich die OTTER Alliance auf die Fahne geschrieben, den OTRS-Fork Znuny weiterzuentwickeln. [mehr]

Buchbesprechung

Computernetze und Internet of Things

von Patrick-Benjamin Bök, Andreas Noack, Marcel Müller

Anzeigen