Sonderbeitrag: Windows Server 2008
Einblick in die Änderungen am Windows Server 2008-Kernel
Mark Russinovich
Kurz zusammengefasst:
- Speicherverwaltung und SMB 2.0
- NTFS-Selbstreparaturfunktion, Windows Hardware Error Architecture und Treiberüberprüfung
- Skalierbarkeit mit E/A-Abschlussports, Threadpools und NUMA
- Hyper-V-Virtualisierung
Windows Server 2008 ist die aktuelle Version der Serverplattform von Microsoft und enthält Änderungen auf Systemebene, die von der Speicherverwaltung
bis zur Threadplanung und vom Netzwerk bis zur Sicherheit (um nur eine kleine Auswahl zu nennen) jeden funktionalen Bereich des Betriebssystems betreffen.
Da Windows Server® 2008 den gleichen Kernel wie Windows Vista® SP1 besitzt, enthält es viele der Verbesserungen, die ich in folgenden früheren TechNet Magazin-Artikeln bereits behandelt habe: „Einblick in den Windows Vista-Kernel“, Teil 1 bis 3 (Februar, März und April 2007) und „Die Benutzerkontensteuerung von Windows Vista“ (Juni 2007). Nur sehr wenige der Features, die ich in diesen Artikeln beschrieben habe, sind ausschließlich auf Clients ausgerichtet und nicht in Windows Server 2008 enthalten, wie z. B. SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot und der Multimediaklassen-Planungsdienst (Multimedia Class Scheduler Service, MMCSS).
Statt erneut auf die wichtigen Änderungen des Kernels einzugehen, die in Windows Vista eingeführt wurden und auch in Windows Server 2008 enthalten sind (z. B. die E/A-Priorisierung, die neue Startarchitektur, BitLockerTM, Codeintegrität und obligatorische Integritätsebenen), werde ich mich auf die wichtigsten Änderungen konzentrieren, die ich in diesen Artikeln nicht behandelt habe, wie z. B. die Änderungen, die sich auf Zuverlässigkeit, Leistung und Skalierbarkeit sowie auf Hyper-VTM, die neue Hypervisor-Computervirtualisierungstechnologie von Microsoft, beziehen.
Genau wie in den vorherigen Artikeln werde ich mich auch in diesem Artikel auf den Betriebssystemkernel „Ntoskrnl.exe“ und auf eng damit verbundene Systemkomponenten beschränken. So werde ich beispielsweise nicht auf Änderungen an Installation (WIM oder Windows® Imaging Format und komponentenbasierte Wartung), Verwaltung (Verbesserungen der Gruppenrichtlinie und von Active Directory®), allgemeiner Diagnose und Überwachung (Windows-Diagnose-Infrastruktur oder WDI), wichtiger Netzwerkfunktionalität (die neue Firewall und TCP/IP-Implementierung), Server Core oder Serverrollen eingehen.
Arbeiten mit Mehrprozessorsystemen
Eine der konkreten Änderungen am System besteht darin, dass Windows Server 2008 nur eine für Mehrprozessorsysteme konzipierte Version des Kernels enthält. Früher verwendete Windows eine Version, die speziell für Einzelprozessoren in Computern mit einer einzigen CPU vorgesehen war, weil sich mit dieser Version eine etwas bessere Leistung erzielen ließ, indem der Synchronisierungscode vermieden wurde, der nur in Mehrprozessorumgebungen benötigt wird. Als die Hardware immer schneller wurde, ist der durch die Optimierungen erzielte Leistungsvorteil so minimal geworden, dass auf ihn verzichtet werden kann, und heute besitzen die meisten Serversysteme mehrere Prozessoren, wodurch eine Version für Einprozessorsysteme überflüssig ist.
Abbildung 1 zeigt die Varianten des Windows Server 2008-Kernels, wobei die Version, die in einem System verwendet wird, jeweils davon abhängig ist, ob die Debugversion (Checked) oder die Einzelhandelsversion des Betriebssystems vorliegt, ob es sich um die 32-Bit-Installation oder die 64-Bit-Installation (Itanium, Intel 64 oder AMD64) handelt und (im Falle einer 32-Bit-Installation) ob das System physischen Speicher von mehr als 4 GB besitzt oder Datenausführungsverhinderung (Data Execution Prevention, DEP) unterstützt. Windows Server 2008 ist auch das letzte Windows Server-Betriebssystem, von dem noch erwartet wird, eine 32-Bit-Version zu bieten.
Figure 1 Kernelvarianten von Windows Server 2008
| Kernel | 32-Bit | 64-Bit |
| Mehrprozessor | Ja | Ja |
| Mehrprozessor Checked | Ja | Ja |
| Mehrprozessor Physical Address Extension (PAE) | Ja | Nein |
| Mehrprozessor PAE Checked | Ja | Nein |
Bei jeder Version von Windows Server steht die Leistungsverbesserung wichtiger Serverszenarios wie z. B. Dateiserverfunktionalität, Netzwerk-E/A und Speicherverwaltung im Vordergrund. Darüber hinaus bietet Windows Server 2008 mehrere Änderungen und neue Features, die es Windows ermöglichen, neue Hardwarearchitekturen zu nutzen, sich an Netzwerke mit hoher Latenz anzupassen und Engpässe zu beseitigen, die in früheren Windows-Versionen die Leistung beeinträchtigt haben. Dieser Abschnitt befasst sich mit Verbesserungen des Speichermanagers und des E/A-Systems und stellt das neue Netzwerkdateisystem SMB 2.0 vor.
Speicherverwaltung
Experiment: Anzeigen großer Datenträger-E/As
Sie können ein Dateisystemüberwachungstool wie z. B. TechNet Sysinternals Process Monitor (technet.microsoft.com/sysinternals/bb896645.aspx) verwenden, um auf einem Windows Server 2008-System nach großen Datei-E/A-Vorgängen zu suchen.
Es gibt mehrere Möglichkeiten, große Ein- und Ausgaben zu generieren. Wenn Sie ein zweites System besitzen, auf dem entweder Windows Vista Service Pack 1 oder Windows Server 2008 ausgeführt wird, können Sie auf dem Server das Überwachungstool „Process Monitor“ ausführen und die Dateikopiervorgänge zum zweiten System überwachen. Sie können große Auslagerungsdatei-E/As normalerweise auch generieren, indem Sie ein speicherintensives Programm ausführen, das den Speichermanager dazu bringt, Seiten in die Auslagerungsdatei zu schreiben.
Abbildung A zeigt das Überwachungstool „Process Monitor“ nach der Ausführung eines speicherintensiven Programms auf einem Windows XP-System. Im Optionsmenü von Process Monitor ist die Option „Enable Advanced Output“ (Erweiterte Ausgabe aktivieren) ausgewählt. Außerdem ist ein Filter eingestellt, der bewirkt, dass nur Schreibvorgänge in die Auslagerungsdatei „pagefile.sys“ angezeigt werden. Die Detailspalte zeigt, dass die Schreibausgaben 64 KB groß sind.
Abbildung A (Klicken Sie zum Vergrößern auf das Bild)
Wenn Sie dieselben Schritte unter Windows Server 2008 ausführen, wird mit größter Wahrscheinlichkeit etwas Ähnliches wie in Abbildung B angezeigt, in der zu sehen ist, dass die meisten Schreibausgaben ungefähr 1 MB groß sind.
Abbildung B (Klicken Sie zum Vergrößern auf das Bild)
Der Speichermanager enthält in Windows Server 2008 mehrere Leistungsverbesserungen. So gibt er beispielsweise weniger und größere Datenträger-E/As als unter Windows Server 2003 aus, wenn er Daten aus der Auslagerungsdatei abruft oder an zugeordneten Dateien Vorauslese-E/As durchführt. Die größeren Datei-E/As werden durch Änderungen im E/A-System erleichtert, durch die eine E/A-Größenbegrenzung von 64 KB aufgehoben wird, die seit der ersten Version von Windows NT® vorhanden war.
Sie müssen auch beachten, dass Datenlesevorgänge für Vorauslesevorgänge (spekulative Lesevorgänge) von zugeordneten Dateien durch den Cache-Manager unter Windows Server 2008 in der Regel zwei Mal so groß wie unter Windows Server 2003 sind und direkt in die Standbyliste (den Code- und Datencache des Systems) geleitet werden. Dieses Verhalten erübrigt die Anforderung an den Cache-Manager, virtuellen Arbeitsspeicher zuzuordnen und die Daten in den Arbeitssatz des Systems (den vom Speichermanager dem System zugewiesenen Speicher) einzulesen, was dazu führen könnte, dass sonstige Codes oder Daten, die verwendet werden, unnötigerweise aus dem Arbeitssatz entfernt werden.
Der Speichermanager führt auch beim Schreiben von Daten in die Auslagerungsdatei größere Ein- und Ausgaben durch. Während Windows Server 2003 oft Schreibvorgänge ausführt, die weniger als 64 KB umfassen, gibt der Speichermanager unter Windows Server 2008 normalerweise Schreibvorgänge aus, die 1 MB groß sind.
Die größeren Schreibvorgänge verringern nicht nur die Fragmentierung innerhalb der Auslagerungsdatei, sondern verbessern durch das Verringern der Anzahl von Schreibvorgängen in die Auslagerungsdatei auch die Leistung. Dies wiederum führt zu einer Verringerung der Anzahl von Lesevorgängen und Datenträgersuchvorgängen, die zum Zurücklesen mehrerer Seiten erforderlich sind, da sie in den meisten Fällen aneinander angrenzen.
Der Speichermanager versucht auch, andere geänderte Seiten zu schreiben, die nicht weit von der Seite entfernt sind, die in den Adressraum des besitzenden Prozesses geschrieben wird, und zielt dabei auf denjenigen Bereich der Auslagerungsdatei ab, in dem sich bereits andere angrenzende Seiten befinden. Dies minimiert ebenfalls die Fragmentierung und kann die Leistung verbessern, weil Seiten, die möglicherweise noch in die Auslagerungsdatei geschrieben werden sollen, bereits dorthin geschrieben wurden. Darüber hinaus verringert dies die Anzahl der Auslagerungslesevorgänge, die erforderlich sind, um einen Bereich angrenzender Prozessseiten in die Datei zu schreiben. Weitere Informationen dazu, wie der Speichermanager große Ein- und Ausgaben verwendet, finden Sie in der Randleiste „Experiment: Anzeigen großer Datenträger-E/As“.
SMB 2.0
Das SMB-Remotedateisystemprotokoll (Server Message Block), das auch als CIFS (Common Internet File System) bezeichnet wird, ist die Grundlage der Windows-Dateiserverfunktionalität, seit die Dateiserverfunktionalität in Windows eingeführt wurde. Im Verlauf der letzten Jahre haben die Entwurfseinschränkungen von SMB die Leistung der Windows-Dateiserverfunktionalität sowie die Fähigkeit, neue lokale Dateisystemfeatures zu nutzen, eingeschränkt. So beträgt beispielsweise die maximale Puffergröße, die in einer einzigen Nachricht übertragen werden kann, ungefähr 60 KB, und SMB 1.0 konnte symbolische Verknüpfungen auf der Seite des NTFS-Clients, die in Windows Vista und Windows Server 2008 hinzugefügt wurden, nicht erkennen.
In Windows Vista und Windows Server 2008 wurde SMB 2.0 eingeführt. SMB 2.0 ist ein neues Protokoll für die Remotedateiserverfunktionalität, das Windows verwendet, wenn es sowohl vom Client als auch vom Server unterstützt wird. SMB 2.0 verarbeitet nicht nur clientseitige symbolische Verknüpfungen und andere NTFS-Verbesserungen korrekt, sondern verwendet auch Batchverarbeitung, um die Anzahl der Nachrichten zu minimieren, die zwischen einem Client und einem Server ausgetauscht werden. Batchverarbeitung kann bei Netzwerken mit hoher Latenz wie z. B. Fernnetzen (wide-area networks, WANs) den Durchsatz verbessern, weil sie ermöglicht, mehr Daten gleichzeitig zu übertragen.
Während SMB 1.0 Ein- und Ausgaben für eine einzige Datei sequenziell durchgeführt hat, implementiert SMB 2.0 E/A-Pipelining, wodurch SMB 2.0 für dieselbe Datei mehrere gleichzeitige Ein- und Ausgaben durchführen kann. SMB 2.0 misst, wie viel Serverspeicher ein Client für die verbleibenden Ein- und Ausgaben verwendet, um zu ermitteln, wie tief dieses Pipelining gehen muss.
Aufgrund der Änderungen am E/A-Speichermanager und am E/A-System von Windows, der automatischen Optimierung des TCP/IP-Empfangsfensters sowie der Verbesserungen am Dateikopiermodul ermöglicht SMB 2.0 enorme Durchsatzverbesserungen und Verkürzungen der Dateikopierzeiten bei umfangreichen Übertragungen. Da beide Betriebssysteme SMB 2.0 implementieren, hat der Einsatz von Windows Server 2008-Dateiservern mit Windows Vista-Clients zur Folge, dass SMB 2.0 verwendet werden kann und diese Leistungsvorteile genutzt werden können.
Zuverlässigkeit durch die NTFS-Selbstreparaturfunktion
Da Zuverlässigkeit eine wichtige Servereigenschaft ist, bietet Windows Server 2008 verschiedene Verbesserungen, die Administratoren helfen, ihre Server reibungslos zu betreiben. Zu diesen Verbesserungen zählen die Online-NTFS-Konsistenzreparatur, eine neue Infrastruktur zur Hardwarefehlerberichterstattung und Erweiterungen der Treiberüberprüfung.
Bei den heutigen Speichergeräten, die einen Speicherplatz von mehreren Terabyte bieten, kann das Offlineschalten eines Volumes zur Durchführung einer Konsistenzüberprüfung einen Dienstausfall von mehreren Stunden zur Folge haben. Da erkannt wurde, dass viele Datenträgerbeschädigungen auf eine einzige Datei oder einen einzigen Abschnitt von Metadaten zurückzuführen sind, implementiert Windows Server 2008 ein neues NTFS-Selbstreparaturfeature, damit Schäden repariert werden können, während das betreffende Volume online bleibt.
Wenn NTFS eine Beschädigung erkennt, verhindert es den Zugriff auf die beschädigten Dateien und erstellt einen Systemarbeitsthread, der an den beschädigten Datenstrukturen CHKDSK-artige Korrekturen vornimmt und danach den Zugriff auf die reparierten Dateien freigibt. Während dieses Vorgangs kann auf andere Dateien weiterhin ganz normal zugegriffen werden, wodurch die Dienstunterbrechung minimal gehalten wird.
WHEA-Infrastruktur
Die WHEA-Infrastruktur (Windows Hardware Error Architecture), die in Windows Server 2008 enthalten ist, verspricht, die Verwaltung von Hardwarefehlern zu vereinfachen und proaktive Reaktionen auf Fehler zu ermöglichen, die nicht schwerwiegend sind. Da Server oft strenge Betriebszeitgarantien erfüllen müssen, ist es von entscheidender Bedeutung, bei derartigen Systemen Fehler rechtzeitig erkennen und auf sie reagieren zu können.
Eine mit OCA (Online Crash Analysis) vorgenommene Analyse der bei Microsoft gemeldeten Abstürze zeigt, dass ungefähr 10 Prozent aller Betriebssystemabstürze auf einen Hardwarefehler zurückzuführen sind, aber es war schwer oder unmöglich, die Hauptursache dieser Abstürze zu ermitteln, da bei einem Absturz nicht genügend Fehlerinformationen von der Hardware bereitgestellt und aufgezeichnet werden. Darüber hinaus hat Windows vor Windows Server 2008 keine integrierte Unterstützung für eine Überwachung der Integrität von Geräten, keine implementierte Wiederherstellung und keine Warnung vor einem bevorstehenden Ausfall bereitgestellt. Dies liegt daran, dass Hardwaregeräte kein gemeinsames Fehlerformat verwenden und keine Fehlerverwaltungssoftware unterstützen.
WHEA stellt einen einheitlichen Mechanismus zur Ermittlung der Fehlerquelle und zur Fehlerberichterstattung für Plattformgeräte einschließlich Prozessoren, Speichern, Caches und Bussen wie z. B. PCI und PCI Express bereit. Um dies zu ermöglichen, wird die in Abbildung 2 gezeigte Architektur implementiert, in deren Kern sich eine Kernel-API befindet, die von Fehlerquellen aufgerufen wird, um Fehler zu melden. Die API setzt voraus, dass für alle Fehler dasselbe Format verwendet wird, und protokolliert Fehler mithilfe von ETW-Ereignissen (Event Tracing for Windows, Ereignisablaufverfolgung für Windows). Schwerwiegende Fehler werden erst nach einem Neustart protokolliert.
Abbildung 2** Infrastruktur der WHEA-Fehlerberichterstattung **(Klicken Sie zum Vergrößern auf das Bild)
ETW wurde in Windows 2000 eingeführt, und die Verwendung von ETW durch WHEA macht es für Hardware- und Softwarehersteller leicht, Anwendungen zur Gerätediagnoseverwaltung zu entwickeln, die WHEA-Ereignisse verwenden. Wenn ein Ereignis schwerwiegend genug ist, um zu einem Systemabsturz zu führen, stellt WHEA sicher, dass die Aufzeichnung des schwerwiegenden Fehlers in der Absturzabbilddatei gespeichert wird, damit die Administratoren die Hauptursache des Absturzes bestimmen können.
Ein weiterer wichtiger Bestandteil von WHEA ist der plattformspezifische Hardwarefehlertreiber (Platform Specific Hardware Error Driver, PSHED), der sich in der Datei „%Systemroot%\System32\Pshed.dll“ befindet. Der Kernel stellt eine Verbindung zum PSHED her und dient als Schnittstelle zur Plattform- und Firmwarehardware, wobei er praktisch als Übersetzungsschicht zwischen ihren Fehlerbenachrichtigungen und der WHEA-Fehlerberichterstattungs-API fungiert. Für jede Plattformarchitektur (x86, x64, Itanium) wird von Microsoft ein PSHED bereitgestellt, der ein Plug-In-Modell zur Verfügung stellt, damit Hardwareanbieter und -hersteller das Standardverhalten durch ein für ihre Plattformen spezifisches Verhalten ersetzen können.
Hinzu kommt, dass Komponenten des Systems, die als Schnittstelle zu anderen Fehlerquellen wie z. B. Gerätetreibern, der Hardwareabstraktionsschicht (Hardware Abstraction Layer, HAL) und dem Kernel dienen, LLHEHs (Low-Level Hardware Error Handlers) implementieren können, die eine Fehlerbedingung anfänglich verarbeiten. Ein LLHEH hat die Aufgabe, Fehlerinformationen aus dem Gerät zu extrahieren, den PSHED zu benachrichtigen, um diesem zu ermöglichen, zusätzliche Plattformfehlerinformationen zu sammeln, und anschließend die WHEA-Fehlerberichterstattungs-API des Kernels aufzurufen.
Treiberüberprüfung
Die Treiberüberprüfung, ein leistungsfähiges Tool zum Aufspüren fehlerhafter Gerätetreiber und fehlerhafter Hardware, ist seit Windows 2000 in jeder Windows-Version enthalten. Administratoren konfigurieren die Treiberüberprüfung („%Systemroot%\System32\Verifier.exe“) normalerweise zu dem Zweck, das Verhalten von Gerätetreibern, die im Verdacht stehen, Systemabstürze zu verursachen, genau zu überwachen. Die Treiberüberprüfung fängt unzulässige Treibervorgänge ab, sodass eine Absturzabbilddatei den Schuldigen eindeutig identifiziert.
Ein Nachteil früherer Implementierungen der Treiberüberprüfung besteht darin, dass die meisten Konfigurationsänderungen einen Neustart des Systems erfordern, was bei einem Produktionsserver natürlich nicht wünschenswert ist. Die Windows Server 2008-Implementierung der Treiberüberprüfung verbessert diesen Prozess, indem bei den nützlichsten Überprüfungen die Voraussetzung eines Neustarts abgeschafft wurde, wodurch es möglich ist, einen problembehafteten Server zu reparieren, ohne ihn neu starten zu müssen.
Darüber hinaus führt die Treiberüberprüfung drei neue Überprüfungen ein, die in Abbildung 3 zu sehen sind. Durch „Sicherheitsüberprüfungen“ wird sichergestellt, dass Gerätetreiber für jene Objekte, die sie als Schnittstelle zu Anwendungen verwenden, sichere Berechtigungen festlegen. Durch „Ausstehende E/A-Anforderungen erzwingen“ wird die Sicherheit eines Treibers bei asynchronen E/A-Vorgängen getestet, die nicht erst nach einer Verzögerung, sondern sofort abgeschlossen werden. Durch „Verschiedene Überprüfungen“ wird nach Treibern gesucht, die fälschlicherweise gerade verwendete Ressourcen freisetzen, WMI-Registrierungs-APIs (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation) falsch verwenden und Ressourcenhandles verlieren.
Abbildung 3** Treiberüberprüfung mit aktivierten Windows Server 2008-Optionen **(Klicken Sie zum Vergrößern auf das Bild)
Skalierbarkeit
Skalierbarkeit bezeichnet die Fähigkeit eines Betriebssystems oder einer Anwendung, mehrere Prozessoren und viel Speicher effektiv nutzen zu können. Mit jeder Version von Windows wird die Skalierbarkeit verbessert, indem die Verwendung von Sperren, die die Parallelität bei Mehrprozessoren verringern, minimiert oder eliminiert wird. In dieser Hinsicht bildet auch Windows Server 2008 keine Ausnahme.
Eine relativ kleine, aber bedeutende Verbesserung stellt der Code dar, der den Zeitgeberablauf ausführt. Dieser verwendet keine Verteilersperre mehr (eine von allen Synchronisierungsvorgängen niedriger Ebene verwendete systemweite Zeitplanungssperre). Die daraus resultierende Verringerung des CPU-Synchronisierungsaufwands ermöglicht Windows Server 2008-Terminalserversystemen, ungefähr 30 Prozent mehr gleichzeitige Benutzer zu unterstützen als Windows Server 2003.
Weitere Verbesserungen der Skalierbarkeit in Windows Server 2008 umfassen Abschlussportverbesserungen, eine neue Threadpoolimplementierung, eine effizientere Verwendung von NUMA-Hardware (Non-Uniform Memory Access) sowie die dynamische Systempartitionierung.
Verbesserte E/A-Abschlussportverarbeitung
Die meisten skalierbaren Windows-Serveranwendungen einschließlich IIS, SQL Server® und Exchange Server verlassen sich darauf, dass eine als „Abschlussport“ bezeichnete Windows-Synchronisierungs-API beim Ausführen von E/A-Vorgängen das Wechseln zwischen mehreren Ausführungsthreads minimiert. Dies wird dadurch erreicht, dass sie zunächst Benachrichtigungen über das Eintreffen neuer Anforderungen (z. B. Webserver-Clientverbindungen) einem Abschlussport zuordnen und einen Threadpool auf Benachrichtigungen warten lassen. Wenn eine Anforderung eintrifft, plant Windows einen Thread, der dann in der Regel andere E/A-Vorgänge ausführt, wie z. B. das Lesen einer Webseite von einem Datenträger und das Senden dieser Webseite an den Client, um die Anforderung abzuschließen.
Damit derselbe Thread so schnell wie möglich wieder dazu übergehen kann, auf weitere Clientanforderungen zu warten, führt der Thread asynchron Ein- und Ausgaben durch und ordnet E/A-Abschlüssse dem Abschlussport zu. Danach beginnt der Thread wieder, am Abschlussport zu warten, der den Thread plant, sobald entweder eine neue Anforderung eintrifft oder eine der Ein- und Ausgaben abgeschlossen ist. Auf diese Weise bleibt auf einer CPU derselbe Thread aktiv, der abwechselnd Clientanforderungen verarbeitet und am Abschlussport wartet.
Ein Nachteil der Abschlussportimplementierung früherer Windows-Versionen besteht darin, dass beim Abschluss einer Ein- und Ausgabe das E/A-System den Thread, der die Ein- und Ausgabe durchführte, anwies, sofort ein wenig Abschlussverarbeitung durchzuführen, unabhängig davon, womit er gerade beschäftigt war. Wenn andere Threads aktiv waren, hatte dies oft zur Folge, dass der Planer einen aktiven Thread verdrängte und einen Kontextwechsel zum ausgebenden Thread durchführte.
Windows Server 2008 vermeidet diese Kontextwechsel, indem es die Abschlussverarbeitung zurückstellt, bis der nächste Thread am Abschlussport wartet, dem die Ein- und Ausgabe zugeordnet ist. Dadurch wird selbst dann, wenn ein anderer Thread als Nächstes am Abschlussport wartet, zuerst die Abschlussverarbeitung durchgeführt, bevor ein anderer Code ausgeführt wird, und der Planer muss nicht zum ausgebenden Thread wechseln. Diese Minimierung von Kontextwechseln kann die Skalierbarkeit stark belasteter Serveranwendungen beträchtlich verbessern.
Effizientere Threadpools
Da es schwer sein kann, Anwendungen zu schreiben, die mehrere CPUs nutzen, wurden in Windows XP Arbeitsthreadpools eingeführt, eine Infrastruktur mit zugehöriger API, die die Details der Ausführung kleiner Arbeitseinheiten über mehrere CPUs hinweg zusammenfasst. Eine Anwendung teilt der Threadpool-API die Arbeitsschritte mit, und die Threadpool-API führt diese Arbeitsschritte danach mithilfe einer Reihe von Threads durch, die sie für jede CPU im System erstellt und verwaltet.
Das Ziel des Threadpools besteht darin, Kontextwechsel zu minimieren, indem dieselben Threads verwendet werden, um mehrere Arbeitsschritte hintereinander durchzuführen. Falls dies nicht möglich ist, weil einer der Threads dieses Pools bereits mit einer anderen Arbeit ausgelastet ist, wird der Arbeitsschritt mithilfe eines anderen Threads auf einer anderen CPU durchgeführt.
Die Threadpoolimplementierung von Windows Server 2008 nutzt die CPUs auf indirekte Weise besser, da sie von den Abschlussportverbesserungen profitiert. Zusätzlich nutzt sie die CPUs auf direkte Weise besser, da sie die Threadverwaltung so optimiert, dass Arbeitsthreads dynamisch kommen und gehen, wie sie gerade benötigt werden, um die Arbeitsauslastung einer Anwendung zu bewältigen. Darüber hinaus wurde der Kern der Infrastruktur in den Kernelmodus verlagert, wodurch die Anzahl der Systemaufrufe durch Anwendungen, die die API verwenden, minimiert wird. Außerdem macht es die neue API für Anwendungen einfacher, bestimmte Vorgänge (z. B. das Abbrechen von in die Warteschlange gestellten Arbeitsschritten beim Herunterfahren der Anwendung) durchzuführen.
NUMA-Optimierungen
Windows Server 2003 hat für NUMA-Computer Optimierungen im Threadplaner und im Speichermanager eingeführt, aber Windows Server 2008 fügt NUMA-Optimierungen im E/A-Manager hinzu und erweitert die NUMA-Optimierungen des Speichermanagers.
Bei NUMA-Systemen handelt es sich in der Regel um Mehrprozessorsysteme, bei denen der Speicher in Abhängigkeit davon, welcher Prozessor auf ihn zugreift, mit unterschiedlicher Latenz arbeitet (siehe Abbildung 4). Speicher wird in Knoten unterteilt, wobei die Latenzen zwischen CPUs und den Knoten variieren können und jede CPU als Bestandteil eines Knotens betrachtet wird, auf den sie am schnellsten zugreifen kann.
Abbildung 4** Beispiel eines NUMA-Systems **(Klicken Sie zum Vergrößern auf das Bild)
NUMA-Systeme (vor allem jene mit mehr als acht CPUs) sind oft kostengünstiger und in ihrer Leistung effizienter als UMA-Systeme (Uniform Memory Access). Während ein UMA-System Speicher für alle CPUs gleichermaßen verfügbar machen muss, kann ein NUMA-System dort, wo Speicher direkt mit einer CPU verbunden ist, Hochgeschwindigkeitsverbindungen implementieren und dort, wo Speicher und CPU weiter voneinander entfernt sind, kostengünstigere Verbindungen mit höherer Latenz einrichten.
Um bei einem NUMA-System eine effektive Skalierung durchzuführen, muss ein Betriebssystem oder eine Anwendung die Knotentopologie kennen, damit die Rechenarbeit in der Nähe jenes Speichers ausgeführt wird, der die Daten und den Code der Berechnungen enthält. So weist beispielsweise der Windows-Planer jedem Thread einen so genannten idealen Prozessor zu, bei dem es sich um jene CPU handelt, auf der der Planer den Thread immer auszuführen versucht. Diese Vorgehensweise erhöht die Wahrscheinlichkeit, dass Daten, die der Thread im Cache der CPU ablegt, bei jeder Ausführung des Threads für den Thread verfügbar sind.
In Windows Server 2003 erweitert der Planer dieses Konzept, indem er den Knoten, der den idealen Prozessor enthält, als idealen Knoten des Threads betrachtet und dann versucht, den Thread auf einer anderen CPU im idealen Knoten zu planen, falls der ideale Prozessor gerade damit ausgelastet ist, einen anderen Thread auszuführen. Der Speichermanager von Windows Server 2003 ist ebenfalls NUMA-fähig geworden und leitet, falls dies möglich ist, die Speicherzuordnungen eines Threads zum Speicher jenes Knotens, auf dem der Thread ausgeführt wird.
In Windows Server 2008 verteilt der Speichermanager die nicht ausgelagerten Speicherpuffer des Kernels (vom Kernel und von Gerätetreibern verwendeter Speicher für das Speichern von Daten, die mit Sicherheit im RAM bleiben) so über die Knoten hinweg, dass Zuordnungen aus jenem Speicher des Knotens kommen, von dem die Zuordnung ausgeht. System-PTEs (Page Table Entries, Seitentabelleneinträge) werden nicht, wie dies in Windows Server 2003 der Fall ist, aus einem beliebigen Knoten, sondern aus jenem Knoten zugeordnet, von dem die Zuordnung ausgeht, falls die Zuordnung eine neue Seitentabellenseite benötigt.
In Windows Server 2003 bevorzugt der Speichermanager dann, wenn ein Thread eine Speicherzuordnung vornimmt, jenen Knoten, auf dem der Thread zum Zeitpunkt der Zuordnung ausgeführt wird. Falls der Thread vorübergehend auf einem Knoten geplant wird, der nicht der ideale Knoten ist, gehen alle Zuordnungen, die in dieser Zeitspanne vorgenommen werden, vom nicht idealen Knoten aus. Aus diesem Grund kann dann, wenn der Thread schließlich auf seinem idealen Knoten ausgeführt wird, der Thread den im zugeordneten Speicher gespeicherten Daten oder Codes nicht so nahe sein, wie dies möglich wäre.
Um dies zu verbessern, bevorzugt der Speichermanager von Windows Server 2008 bei allen Zuordnungen eines Threads dessen idealen Knoten, auch wenn der Thread in der Nähe eines anderen Knotens ausgeführt wird. Der Speichermanager berücksichtigt auch automatisch die Latenzen zwischen Prozessoren und Knoten. Wenn also der ideale Knoten keinen verfügbaren Speicher besitzt, überprüft der Speichermanager daher jenen Knoten, der dem idealen Knoten am nächsten ist. Zusätzlich migriert der Speichermanager Seiten in seiner Standbyliste zum idealen Knoten eines Threads, wenn ein Thread auf den Code oder die Daten verweist.
Anwendungen, die ihr Zuordnungsziel kontrollieren wollen, können neue NUMA-Speicher-APIs verwenden, die es ihnen ermöglichen, einen bevorzugten Knoten für Speicherzuordnungen, Dateizuordnungsansichten und Dateizuordnungsobjekte festzulegen. Bei einer Zuordnung für eine Dateizuordnung überprüft der Speichermanager, ob vom Zuordnungsvorgang ein Knoten angegeben wird. Danach überprüft er, ob vom Dateizuordnungsobjekt ein Knoten angegeben wird. Falls beides nicht der Fall ist, verwendet er den idealen Knoten des Threads.
Vor Windows Server 2008 konnten der Interrupt und der zugehörige DPC (Deferred Procedure Call) für einen Speicher oder eine Netzwerk-E/A auf jeder beliebigen CPU ausgeführt werden, einschließlich der CPUs von Knoten, auf denen die Ein- und Ausgabe nicht gestartet wurde, was zur Folge haben konnte, dass sich die beim E/A-Vorgang gelesenen oder geschriebenen Daten im Speicher eines anderen Knotens als dem Knoten befanden, in dem auf sie zugegriffen wurde.
Um dies zu vermeiden, leitet das E/A-System von Windows Server 2008 die DPC-Ausführung zu einer CPU in dem Knoten, der die Ein- und Ausgabe gestartet hat, und Systeme mit Geräten, die PCI-Bus-MSI-X – eine Erweiterung des MSI-Standards (Message Signaled Interrupt) – unterstützen, können die E/A-Verarbeitung noch genauer lokalisieren, indem sie Gerätetreiber verwenden, die mithilfe von Windows Server 2008-APIs den Interrupt einer Ein- und Ausgabe zu dem Prozessor leiten, der die Ein- und Ausgabe gestartet hat.
Dynamische Partitionierung
Eine der Methoden, mit denen ein System skalierbarer gemacht werden kann, besteht darin sicherzustellen, dass es das dynamische Hinzufügen von Hardwareressourcen wie z. B. CPUs und Speicher unterstützen kann. Diese Unterstützung kann auch die Verfügbarkeit des Systems steigern, wenn diese Ressourcen ersetzt werden können, ohne das System neu starten zu müssen.
Windows Server 2003 unterstützte eine Speicherhinzufügung bei laufendem Betrieb, die es Servern mit Unterstützung für dynamischen Speicher ermöglichte, RAM zu verwenden, sobald dieser von einem Administrator hinzugefügt wurde. Windows Server 2008 erweitert diese Unterstützung dynamischen Speichers, indem es zulässt, dass Speicher ersetzt wird.
Wenn RAM abhängiger von ECC-Korrekturen wird (Error Correcting Code), besteht das Risiko, dass er komplett ausfällt. Aus diesem Grund kann Windows Server 2008 bei einem Server, der das Ersetzen von Speicher bei laufendem Betrieb unterstützt, Daten von ausfallenden Speicherbänken transparent auf Ersatzspeicherbänke migrieren. Bei diesem Vorgang migriert es zuerst die Daten, die unter der Kontrolle des Betriebssystems stehen. Danach fährt es Hardwaregeräte praktisch herunter, indem es sie in einen Energiesparmodus schaltet, migriert die übrigen Daten des Speichers und schaltet danach die Geräte wieder in den normalen Energiemodus, damit sie weiterarbeiten können.
Windows Server 2008 unterstützt auch das Hinzufügen und Ersetzen von Prozessoren bei laufendem Betrieb. Beim Ersetzen bei laufendem Betrieb muss die Hardware das Konzept von Ersatz-CPUs unterstützen, die entweder online geschaltet oder dynamisch hinzugefügt werden können, wenn eine vorhandene CPU Fehleranzeigen generiert. Dies ist derzeit jedoch nur bei High-End-Systemen möglich. Der Planer von Windows Server 2008 verlangsamt die Aktivitäten auf der ausfallenden CPU und migriert die Arbeit auf die Ersatz-CPU. Anschließend kann die ausfallende CPU durch eine neue CPU ersetzt werden.
Dass Windows Server 2008 das Hinzufügen von Prozessoren bei laufendem Betrieb unterstützt, ermöglicht einem Administrator, die Verarbeitungskapazität eines Servers zu steigern, ohne den Server herunterfahren zu müssen. Der Planer und die E/A-Systeme machen eine neue CPU allerdings nur für Gerätetreiber und Anwendungen verfügbar, die über neue APIs anfordern, von der Installation neuer CPUs in Kenntnis gesetzt zu werden, denn einige Anwendungen gehen grundsätzlich davon aus, dass die Anzahl der CPUs während einer Startsitzung unverändert bleibt. So könnte beispielsweise eine Anwendung für jede CPU ein Array von Arbeitswarteschlangen zuordnen, wobei ein Thread die Warteschlange verwendet, die der CPU zugeordnet ist, auf der er ausgeführt wird. Wenn dann der Planer einen der Threads der Anwendung auf eine neue CPU migriert, würde der Thread versuchen, auf eine nicht vorhandene Warteschlange zu verweisen, was dazu führen kann, dass die Daten der Anwendung beschädigt werden, wodurch die Anwendung wahrscheinlich abstürzen würde.
CPU-Hinzufügungen werden von serverbasierten Microsoft-Anwendungen wie z. B. SQL Server und Exchange Server sowie von verschiedenen zentralen Windows-Prozessen wie z. B. dem System-Prozess, dem Sitzungs-Manager-Prozess (%SystemRoot%\System32\Smss.exe) und dem Prozess für das Hosten allgemeiner Dienste (%Systemroot%\System32\Svchost.exe) unterstützt. Andere Prozesse können ebenfalls über eine Windows-API anfordern, von der Installation neuer CPUs in Kenntnis gesetzt zu werden. Wenn eine neue CPU installiert wird, weist Windows Gerätetreiber auf die bevorstehende Installation hin, startet die CPU und benachrichtigt anschließend Gerätetreiber und Anwendungen, die dafür programmiert wurden, neue CPUs nutzen zu können, damit sie ggf. Datenstrukturen zuordnen, um Aktivitäten auf der neuen CPU nachzuverfolgen.
Computervirtualisierung
Vor Windows Server 2008 wurden Virtualisierungsprodukte von Microsoft einschließlich Virtual Server 2005 durch gehostete Virtualisierung implementiert, wie in Abbildung 5 zu sehen ist. Bei der gehosteten Virtualisierung werden virtuelle Computer von einem VMM (Virtual Machine Monitor) implementiert, der (i. d. R. als Gerätetreiber) zusätzlich zu einem Hostbetriebssystem ausgeführt wird. Der VMM nutzt die Ressourcenverwaltung und die Gerätetreiber des Hostbetriebssystems, und wenn das Hostbetriebssystem die Ausführung des VMM plant, teilt der VMM die CPU durch Zeitabschnitte unter den aktiven virtuellen Computern (virtual machines, VMs) auf.
Abbildung 5** Virtualisierung gehosteter Computer **(Klicken Sie zum Vergrößern auf das Bild)
Hyper-V, das ehemals den Codenamen „Viridian“ trug, wird durch Hypervisorvirtualisierung implementiert. Der Hypervisor hat vollständige Kontrolle über alle Hardwareressourcen, und selbst das Betriebssystem Windows Server 2008, das den Computer startet und über das Sie virtuelle Computer steuern, wird praktisch auf einem virtuellen Computer ausgeführt, wie in Abbildung 6 zu sehen ist.
Abbildung 6** Hyper-V-Architektur **(Klicken Sie zum Vergrößern auf das Bild)
Der Hypervisor kann das System in mehrere virtuelle Computer partitionieren und behandelt die startende Instanz von Windows Server 2008 als Master- bzw. Stammpartition, der er direkten Zugriff auf Hardwaregeräte wie z. B. die Festplatte, die Netzwerkadapter und den Grafikprozessor gewährt. Der Hypervisor erwartet von der Stammpartition, die Energieverwaltung durchzuführen und auf Plug und Play-Ereignisse von Hardware zu reagieren. Er fängt die Hardwaregeräte-E/A ab, die in einer untergeordneten Partition gestartet wird, und leitet sie in die Stammpartition, die für den Hardwarezugriff Standardgerätetreiber von Windows Server 2008 verwendet. Auf diese Weise können Server, auf denen Hyper-V ausgeführt wird, die Windows-Unterstützung von Hardwaregeräten voll nutzen.
Wenn Sie Windows Server 2008 mit der Hyper-V-Serverrolle konfigurieren, setzt Windows die Boot Configuration Database (BCD)-Einstellung „hypervisorimagelaunchtypeboot“ auf „auto“ (automatisch) und konfiguriert den Gerätetreiber „Hvboot.sys“ dafür, beim Startvorgang schon früh zu starten. Falls die Option konfiguriert ist, bereitet „Hvboot.sys“ das System auf die Virtualisierung vor und lädt danach in Abhängigkeit davon, ob das System AMD-V- oder Intel VT-CPU-Virtualisierungserweiterungen implementiert, entweder %Systemroot%\System32\Hvax64.exe oder %Systemroot%\System32\Hvix64.exe in den Speicher.
Nachdem der Hypervisor geladen wurde, verwendet er die Virtualisierungserweiterungen, um sich unterhalb von Windows Server 2008 selbst einzufügen. Da Benutzermodusanwendungen die Berechtigungsstufe „Ring 3“ des x64-Prozessors verwenden und Kernelmoduscode bei „Ring 0“ ausgeführt wird, arbeitet der Hypervisor auf der konzeptionellen Berechtigungsstufe „Ring minus 1“, denn er kann die Ausführungsumgebung von Code, der auf der Stufe „Ring 0“ ausgeführt wird, kontrollieren.
Wenn Sie die Hyper-V-Verwaltungskonsole verwenden, um eine untergeordnete Partition zu erstellen oder zu starten, kommuniziert sie mit dem Hypervisor über den Treiber „%Systemroot%\System32\Drivers\Winhv.sys“, der die öffentlich dokumentierte Hypercall-API verwendet, um den Hypervisor anzuweisen, eine neue Partition mit einer festgelegten Größe des physischen Speichers und festgelegten Ausführungsmerkmalen zu erstellen. Der VM-Dienst (%Systemroot%\System32\Vmms.exe) innerhalb des Stamms erstellt für jede untergeordnete Partition einen VM-Arbeitsprozess (%Systemroot%\System32\Vmwp.exe), um den Status der untergeordneten Partition zu verwalten.
Eine der Methoden, mit der Windows die Leistung von Betriebssystemen untergeordneter virtueller Computer verbessert, besteht darin, dass sowohl Windows Server 2008 als auch Windows Vista so genannte „Enlightenments“ implementiert, bei denen es sich um Codesequenzen handelt, die nur dann aktiviert werden, wenn das Betriebssystem auf einem Hypervisor ausgeführt wird, der die Microsoft-Hypercall-API implementiert. Indem der untergeordnete virtuelle Computer Dienste des Hypervisors direkt anfordert, vermeidet er einen übermäßigen Aufwand an Virtualisierungscode, der notwendig wäre, wenn der Hypervisor die Absicht des untergeordneten Betriebssystems erraten müsste.
So würde beispielsweise ein Gastbetriebssystem, das keine Enlightenments für Spinlocks implementiert, die eine untergeordnete Mehrprozessorsynchronisierung ausführen, einfach in einer engen Schleife hängen bleiben und darauf warten, dass ein Spinlock von einem anderen virtuellen Prozessor freigegeben wird. Dieses Hängenbleiben in der Schleife könnte eine der Hardware-CPUs so lange binden, bis der Hypervisor den zweiten virtuellen Prozessor geplant hätte. Bei Betriebssystemen mit Enlightenments benachrichtigt der Spinlockcode in dem Augenblick, in dem er normalerweise in der Schleife hängen bleiben würde, über einen Hypercall den Hypervisor, damit der Hypervisor sofort einen anderen virtuellen Prozessor planen kann, um die verschwenderische CPU-Nutzung zu verringern.
Eine andere Methode, mit der Windows Server 2008 die Leistung virtueller Computer verbessert, besteht darin, den Zugriff virtueller Computer auf Geräte zu beschleunigen. Die Leistung wird verbessert, indem im untergeordneten Betriebssystem eine Reihe von Komponenten installiert wird, die zusammenfassend als „VM-Integrationskomponenten“ bezeichnet werden.
Wenn Sie einen virtuellen Computer ausführen, ohne Integrationskomponenten zu installieren, konfiguriert das untergeordnete Betriebssystem für die emulierten Geräte, die ihm vom Hypervisor präsentiert werden, Hardwaregerätetreiber. Der Hypervisor muss dann, wenn ein Gerätetreiber versucht, eine Hardwareressource anzusteuern, eingreifen, um die Stammpartition zu verständigen, die danach Geräte-E/A-Vorgänge durchführt, indem sie im Namen des Betriebssystems des untergeordneten virtuellen Computers standardmäßige Windows-Gerätetreiber verwendet. Da ein einziger E/A-Vorgang auf hoher Ebene (z. B. das Lesen von einem Datenträger) viele separate Hardwarezugriffe umfassen kann, kann er viele Übergänge (Abfangvorgänge) im Hypervisor und in der Stammpartition auslösen.
Windows Server 2008 minimiert Abfangvorgänge durch drei Komponenten: den VM-Bustreiber (%Systemroot%\System32\Drivers\Vmbus.sys), virtuelle Dienstclients (Virtual Service Clients, VSCs) und virtuelle Dienstanbieter (Virtual Service Providers, VSPs). Wenn Sie Integrationskomponenten in einem virtuellen Computer (virtual machine, VM) mit einem unterstützten Betriebssystem installieren, übernehmen VSCs die Rolle von Gerätetreibern und verwenden die Dienste des Vmbus.sys-Treibers im untergeordneten virtuellen Computer, um über die Hypercall- und Speicherfreigabedienste des Hypervisors übergeordnete E/A-Anforderungen an den VM-Bustreiber in der Stammpartition zu senden. In der Stammpartition leitet Vmbus.sys die Anforderung an den entsprechenden VSP weiter, der danach über die Gerätetreiber der Stammpartition die Standard-E/A-Anforderungen von Windows startet.
Wie Sie sehen können, spielt Windows Server 2008 durch seine Einführung der hypervisorbasierten Hyper-V-Virtualisierung eine wichtige Rolle in der Computervirtualisierungsstrategie von Microsoft. Weitere Informationen zu diesen und anderen Features finden Sie in der nächsten Ausgabe meines Buchs „Microsoft Windows Internals“, das in diesem Jahr veröffentlicht werden soll.
Mark Russinovich ist Technical Fellow in der Platform and Services Division von Microsoft. Er ist Mitautor von Microsoft Windows Internals (Microsoft Press, 2004) und hält häufig Vorträge auf IT- und Entwicklerkonferenzen, einschließlich Microsoft TechEd und der Professional Developers Conference (PDC). Mark Russinovich wechselte bei der Übernahme des von ihm mitgegründeten Unternehmens Winternals Software zu Microsoft. Darüber hinaus gründete er Sysinternals, wo er viele populäre Dienstprogramme einschließlich Process Explorer, Filemon und Regmon veröffentlichte.
© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.