Virtuelle Server in Hyper-V sind über den Hypervisor an einen virtuellen Switch angeschlossen. Dieser kommuniziert wiederum über die physische Netzwerkkarte mit dem eigentlichen Netzwerk. Virtuelle Server haben also zu keinem Zeitpunkt Zugriff auf die physische Netzwerkkarte des Servers. Die Kommunikation erfolgt ausschließlich über den virtuellen Netzwerk-Switch, an den auch die physischen Netzwerkkarten des Servers angeschlossen sind.
Einstellungen finden Administratoren daher direkt im Treiber auf dem Hyper-V-Host, im Manager für virtuelle Netzwerke und in den Einstellungen einzelner virtueller Maschinen.
Microsoft stellt ein sehr ausführliches Whitepaper zur Verfügung, das die Netzwerkverwaltung von Hyper-V detailliert erklärt. In diesem Whitepaper finden Sie auch ausführliche Erläuterungen und Grafiken zu den verschiedenen Netzwerken. Im Folgenden gehen wir auf einige Möglichkeiten ein, wie Sie die Leistung im Netzwerk mit Hyper-V-Servern verbessern.
Dedizierte physische Netzwerkkarten
Hyper-V-Hosts sollten Sie über eine dedizierte Netzwerkkarte verwalten, die nicht durch Hyper-V verwendet wird. Setzen Sie außerdem bei der Anbindung an NAS oder iSCSI ebenfalls auf einen dedizierten Adapter. Netzwerklastigen Servern sollten Sie eine eigene Karte spendieren.
Wird Hyper-V im Cluster eingesetzt, empfiehlt es sich gleichfalls, einen dedizierten Adapter verwenden. Über diesen führt der Cluster zum Beispiel die Live-Migration durch. Beim Betrieb in Clustern sollten Sie die Kommunikation zwischen den Knoten und dem Cluster Shared Volume (CSV) ebenfalls mit dedizierten Netzwerkkarten ausstatten. Auf diese Weise können Sie die Performance virtueller Server im Netzwerk erhöhen, da die Netzwerkkarten die Last im Netzwerk unter sich aufteilen und die virtuellen Server nicht ausgebremst werden.
Optimales Konfigurieren der Netzwerkprotokolle
Auch wenn Sie dedizierte Netzwerkkarten in Hyper-V einsetzen, haben Sie noch Optimierungspotenzial im Bereich der Netzwerkprotokolle. In den Eigenschaften der Netzwerkverbindungen deaktivieren Sie bei der entsprechenden Netzwerkkarte die Protokolle, die nicht notwendig sind.
Die Netzwerkverbindung, mit der Sie den Server verwalten, können Sie so belassen, wie sie ist. Setzen Sie im Netzwerk kein IPv6 ein, können Sie das Protokoll deaktivieren. Das ist allerdings keine empfohlene Konfiguration. Das gilt auch für die nachfolgenden Netzwerkverbindungen bezüglich der Deaktivierung von IPv6. Das Protokoll für Microsoft virtueller Netzwerkswitch können Sie in der Verwaltungskarte ebenfalls deaktivieren, da dieses nur in Hyper-V eine Rolle spielt und die Verwaltungsverbindung keinerlei Kommunikation mit Hyper-V durchführen soll.
Für das Netzwerk, das Sie in Hyper-V eingebunden haben, also das Netzwerk, das die virtuellen Server mit dem physischen Netzwerk verbindet, aktivieren Sie nur Protokoll Microsoft virtueller Netzwerkswitch. Alle anderen Protokolle deaktivieren Sie, auch die Protokolle für IPv4 und IPv6. Hier können Sie IPv6 tatsächlich aktivieren, da die Verbindung nur das Protokoll Microsoft virtueller Netzwerkswitch benötigt.
Wenn Sie für die Kommunikation innerhalb des Clusters (Heartbeat) einen eigenen Adapter verwenden, was dringend zu empfehlen ist, können Sie hier ebenfalls IPv6 deaktivieren, wenn Sie das Protokoll nicht einsetzen. Außerdem können Sie den E/A-Treiber für Verbindungsschicht-Topologieerkennung deaktivieren. Das Protokoll dient nur der Anzeige des Servers in Überwachungs-Tools, zum Beispiel in der Netzwerkübersicht in Windows 7. In einem Cluster-Netzwerk benötigen Sie das Protokoll nicht; das gilt auch für Antwort für Verbindungsschicht-Topologieerkennung.
Das Protokoll Microsoft virtueller Netzwerkswitch kann ebenfalls deaktiviert werden. In sehr großen Umgebungen können Sie noch weiter gehen und die Kommunikation mit dem CSV (gemeinsamer Datenträger) und dem Heartbeat ebenfalls durch dedizierte Adapter voneinander trennen. Für CSV und Heartbeat verwenden Sie die gleichen Protokolle.
Bei dedizierten Adaptern für die Datenübertragung mit der Live-Migration deaktivieren Sie Protokoll Microsoft virtueller Netzwerkswitch und IPv6. Alle anderen Protokolle lassen Sie aktiv.
Verbinden Sie den Server noch mit einem iSCSI-Target, können Sie auch bei dieser Netzwerkverbindung Protokolle deaktivieren, und zwar alle Protokolle außer IPv4 deaktivieren. Nutzen Sie im Netzwerk noch IPv6, kann das Protokoll aktiv gelassen werden. Alles andere deaktivieren Sie. Die Kommunikation zum Speicher erfordert nur eine IP-Verbindung, keine anderen Protokolle.
Teaming für Netzwerkkarten
Viele Adapterhersteller bieten die Möglichkeit, mehrere Netzwerkkarten zu einem Team zusammenzufassen. Bevor Sie in Hyper-V eine solche Karte einsetzen, sollten Sie überprüfen, ob die Karte für Hyper-V freigegeben ist. Das gilt dann auch für den Betrieb auf einem Core-Server oder in einem Cluster, wenn Sie diese Funktionen von Windows Server 2008 R2 nutzen. Bevor Sie Windows Server 2008 R2 produktiv mit solchen Netzwerkkarten betreiben, sollten Sie in jedem Fall das BIOS des Servers und die Firmware der entsprechenden Netzwerkkarte auf den aktuellen Stand bringen.
Installieren Sie dann das Betriebssystem und anschließend Hyper-V. Erst dann installieren Sie die Zusatz-Tools des Treibers zur Verwaltung von Teaming. Wie Sie bei der Konfiguration der verschiedenen Server und Treiber vorgehen und wie Sie Fehler beheben, erfahren Sie in folgendem Blog-Eintrag.
Eigene Netzwerkkarten für PXE-Boot
Erstellen Sie einen virtuellen Server, integriert Hyper-V automatisch eine Netzwerkkarte, die über den Hypervisor mit dem Netzwerk verbunden ist.
Diese ist aber in den meisten Fällen nicht für das Booten über Netzwerk (PXE) ausgelegt. Wollen Sie einen virtuellen Server über das Netzwerk booten, können Sie solchen virtuellen Servern nachträglich eine passende Netzwerkkarte hinzufügen. Klicken Sie auf Hardware hinzufügen in den Einstellungen von virtuellen Servern, haben Sie die Möglichkeit, verschiedene Netzwerkkarten zu integrieren. Wählen Sie Ältere Netzwerkkarte aus; diese Adapter funktionieren ohne Treiber und unterstützen Booten über das Netzwerk.
Netzwerkaufgaben auf Netzwerkkarte auslagern
Windows Server 2008 R2 kann Berechnungen für Netzwerkverbindungen, die normalerweise der Prozessor erledigt, auf die Netzwerkkarte auslagern.
Das müssen die Karte und der installierte Treiber unterstützen. Diese Technik lässt sich auch in Hyper-V nutzen. Damit die Übertragung dieser Aufgaben funktioniert, müssen Sie auf dem Hyper-V-Host und allen virtuellen Servern den Befehl
netsh int tcp set global chimney=enabled
eingeben. Um die Funktion zu deaktivieren, verwenden Sie den Befehl
netsh int tcp set global chimney=disabled
Mit
netsh int tcp show global
zeigen Sie die Konfiguration an. Auf der Registerkarte Erweitert in den Eigenschaften des Treibers der Netzwerkkarte auf dem Hyper-V-Host suchen Sie nach der Funktion TCP-Prüfsummenabladung und aktivieren die Option Rx & Tx-aktiviert.
MAC-Adressen für virtuelle Server optimal konfigurieren
Hyper-V-Hosts verfügen über einen Pool an MAC-Adressen, die sie an die virtuellen Server verteilen. Setzen Sie Hyper-V im Cluster ein und verschieben einen virtuellen Server zwischen den Knoten, ändert sich dessen MAC-Adresse. Spätestens beim nächsten Start des virtuellen Servers ist die Adresse geändert. Dadurch können sich Probleme bei der Betriebssystemaktivierung oder beim Betrieb von virtuellen Servern in Lastenausgleichs-Clustern ergeben.
Den MAC-Adressbereich eines Hyper-V-Hosts sehen Sie im Manager für virtuelle Netzwerke bei MAC-Adressbereich. Der Pool wird beim Installieren der Hyper-V-Rolle erstellt. Welche MAC-Adressen im Pool enthalten sind, können Sie auch in der Registry anpassen. Die Einstellungen finden sich im Schlüssel HKLM\Software\Microsoft\Windows NT\CurrentVersion\Virtualization.
Hier stehen die Werte MinimumMacAddress und MaximumMacAddress. Wollen Sie Hyper-V-Hosts also klonen, sollten Sie das Image zum Klonen vor der Installation der Hyper-V-Rolle installieren. Sie können für virtuelle Server aber auch statische MAC-Adressen aktivieren. Diese Einstellung nehmen Sie im Bereich Netzwerkkarte der einzelnen virtuellen Server im Hyper-V-Manager vor.
Virtuelle LANs (VLAN) und Hyper-V
Hyper-V-Hosts und virtuelle Server können Sie auch an virtuelle LANS (VLANs) anbinden. Mit VLANs lassen sich Netzwerke logisch strukturieren. Nur Computer in einem gemeinsamen
VLAN können bei einer solchen Konfiguration miteinander kommunizieren. Zunächst konfigurieren Sie im Treiber der Netzwerkkarte der Hyper-V-Hosts die VLAN-ID. In Hyper-V wählen Sie im Manager für virtuelle Netzwerke die Netzwerkverbindung aus und konfigurieren ebenfalls die VLAN-ID.
Setzen Sie dazu die Option Identifizierung virtueller LANs für das Verwaltungsbetriebssystem aktivieren. Auch virtuelle Server können Sie an VLANs anbinden. Dazu müssen Sie in den Einstellungen der virtuellen Server ebenfalls die VLAN-ID angeben. Mit dieser Technik können Sie getrennte Testumgebungen aufbauen oder den Verwaltungsnetzwerkverkehr des Hyper-V-Hosts von den virtuellen Servern trennen.
Leistungsprobleme bei Active-Directory-Zugriff, Exchange & Co.
Liegen Leistungsprobleme in Exchange oder anderen Serverdiensten vor, die von Active Directory abhängen (zum Beispiel bezüglich des Postfachzugriffs oder des Versenden von Nachrichten), besteht häufig parallel auch ein Problem in Active Directory oder DNS. Nachfolgend gehen wir auf die Diagnose und auf Fehlerbehebungen in diesem Bereich ein.
Vor allem durch die Kommunikation zwischen virtuellem Server, virtuellem Netzwerk-Switch und physischem Netzwerk ist es oft schwer, Fehler zu erkennen. Exchange, aber auch andere Dienste, die Active Directory benötigen, greifen über die Systemdatei wldap32.dll auf Active Directory zu. Dabei laufen (vereinfacht) folgende Vorgänge ab:
1. Die Datei wldap32.dll auf dem Exchange-Server erhält durch einen Exchange-Prozess eine Anfrage, um auf den globalen Katalog zuzugreifen.
2. Per DNS versucht der Server, den globalen Katalogserver aufzulösen, um auf diesen zugreifen zu können. Dauert dieses Auflösen zu lange, verzögert sich bereits an dieser Stelle der Active-Directory-Zugriff.
3. Nach der Auflösung stellt die Datei eine Verbindung zum GC (Global Catalog, globaler Katalog) her und überträgt die Anfrage.
4. Anschließend werden eine TCP-Verbindung aufgebaut und eine LDAP-Abfrage gestartet. Damit die Verbindung funktioniert, benötigt die TCP-Verbindung drei Bestätigungen durch den Domänencontroller. Bei einer Latenz von 10 Millisekunden im Netzwerk dauert der Zugriff in diesem Fall also 30 Millisekunden, bevor der Exchange-Server die LDAP-Abfrage übertragen kann.
5. Die LDAP-Abfrage wird zur Datei lsass.exe auf dem Domänencontroller übertragen, die auf den LDAP-Port des Servers hört.
6. Der Domänencontroller nimmt die Abfrage an den GC entgegen und führt die Suche in seinem globalen Katalog durch.
7. Der GC sendet die Daten über die Netzwerkkarte zur Datei wldap32.dll auf dem Exchange-Server. Handelt es sich um eine hohe Anzahl an Daten, zum Beispiel beim Auflösen der Mitglieder einer Verteilergruppe, müssen erst alle Daten übertragen werden, bevor Exchange mit der Verarbeitung weitermachen kann.
Ein sehr großer Teil der Leistung hängt von der Netzwerkgeschwindigkeit zwischen dem Exchange-Server und dem globalen Katalog oder Domänencontroller ab, unabhängig davon, ob diese Server virtuell oder physisch installiert sind. Aus diesem Grund sollten Sie bei Leistungsproblemen der Exchange-Infrastruktur auch immer die Geschwindigkeit des Netzwerks messen.
Am besten messen Sie den Zugriff des virtuellen Servers und des Hyper-V-Hosts. Auch die Geschwindigkeit zum DNS-Server und eine schnelle, stabiler und korrekte Namensauflösung sind sehr wichtig. Die Geschwindigkeit zum DNS-Server darf 50 Millisekunden nicht überschreiten, wenn Sie die Leistung des Exchange-Servers optimieren wollen. Dauert die Anfrage länger, haben Sie schon den ersten Flaschenhals in der Exchange-Leistung.
Exchange-Server - Leistung überprüfen
Um die Leistung der Exchange-Server im Zusammenspiel mit Active Directory zu überprüfen, benötigen Sie zunächst die Leistungsdaten beim Abrufen von Active-Directory-Informationen über LDAP. Über LDAP greift Exchange auf Active Directory zu, um E-Mails senden zu können, die Replikation zu starten oder die Berechtigung zu überprüfen.
Ist die Verbindung zu Active Directory langsam, reagiert auch Exchange langsam. Der erste Schritt bei der Leistungsüberwachung führt daher zunächst über die Leistungsüberwachung auf dem Exchange-Server, die Sie mit perfmon.msc starten:
1. Klicken Sie anschließend auf Leistungsüberwachung.
2. Klicken Sie auf das +-Zeichen, um einen neuen Indikator hinzuzufügen.
3. Wichtig ist die Indikatorgruppe MSExchange ADAccess-Prozesse. Erweitern Sie diese Gruppe.
Wichtig sind in dieser Gruppe die beiden Indikatoren LDAP-Lesedauer und LDAP-Suchdauer. Klicken Sie auf die beiden Indikatoren, wählen Sie im unteren Bereich Instanzen die Instanz <Alle Instanzen> und klicken Sie auf Hinzufügen.
LDAP-Lesedauer misst die Zeit, die eine LDAP-Abfrage bis zur Datenübermittlung benötigt. LDAP-Suchdauer zeigt an, wie lang der Exchange-Server für eine Suche per LDAP in Active Directory braucht. Der Durchschnittswert für diese Indikatoren sollte unter 50 Millisekunden liegen, die Maximaldauer sollte nicht über 100 Millisekunden steigen.
Damit Exchange schnell und effizient Daten aus Active Directory abrufen kann, muss der globale Katalog, den Exchange verwendet, schnell und nicht überlastet sein. Um diese Auslastung zu überprüfen, können Sie in Windows Server 2008 und Windows Server 2008 R2 mit Bordmittelwerkzeugen arbeiten.
Der erste Schritt dazu ist, dass Sie auf dem Domänencontroller perfmon im Suchfeld des Startmenüs eingeben und die Leistungsüberwachung starten. Klicken Sie anschließend auf Sammlungssätze/System/Active Directory Diagnostics und anschließend auf das Symbol Sammlungssatz starten.
Während der Server die Daten misst, versuchen Sie, die Abfrage auf Active Directory durchzuführen, um festzustellen, ob das Problem aufseiten des globalen Katalogs liegt. Haben Sie die Abfrage durchgeführt, können Sie den Sammlungssatz anhalten, indem Sie auf das gleichnamige Symbol klicken. Anschließend lassen Sie sich über das Berichtssymbol die letzte Messung anzeigen. Wichtig in diesem Bericht ist zunächst der Bereich Active Directory. Klicken Sie im Bericht auf den kleinen Pfeil an der rechten Seite und wählen die Option Eindeutige Suchen aus.
Es öffnet sich eine neue Seite, in der Sie die Daten und Verbindungen sowie die Vorgänge detailliert anzeigen können. Vor allem im rechten Bereich sehen Sie die Antwortzeiten und die übertragenen Daten. Hier sollten keine größeren Ausschläge nach oben zu sehen sein. Wenn Sie den Bericht mit der rechten Maustaste anklicken, können Sie über den Menübefehl Ansicht/Ordner den Inhalt des Berichts anzeigen lassen. In der Ordneransicht stehen zum Beispiel auch eine .html-Datei sowie eine .xml-Datei zur Verfügung, welche die Daten des Berichts enthält. Diese Daten kann mit anderen Programmen weiterverarbeitet werden, um die Daten besser analysieren zu können. (mje)
Dieser Artikel basiert auf einem Beitrag der CW-Schwesterpublikation TecChannel.