Es ist schon erstaunlich, wie die Zeit vergeht. Bereits 8 Monate sind vergangen, seitdem ich den ersten Teil von PVS Internals geschrieben habe. In letzter Zeit war ich sehr beschäftigt, daher entschuldige ich mich, dass es so lange gedauert hat, den zweiten Teil des Blog-Beitrags zu vervollständigen.
Im ersten Teil habe ich die theoretischen Grundlagen für die Diskussion über die richtige Dimensionierung des Speichers vorbereitet. Sie sollten bereits das Konzept des Windows-Caching-Managers verstehen.
Missverständnisse über PVS beseitigen
Es gibt viele Missverständnisse und falsche Vorstellungen über Provisioning Services (PVS) – und eines davon ist, dass PVS eine enorme Menge an Speicher benötigt, um ordnungsgemäß zu funktionieren. Ja, PVS verwendet Speicher (als kostengünstigen Cache-Mechanismus), aber das bedeutet nicht, dass Sie einen Supercomputer bauen müssen, um Provisioning Services zu nutzen. Die Gründe, warum PVS zusätzlichen Speicher benötigt, wurden bereits in meinem vorherigen Artikel erläutert – es handelt sich um einen Dienst, der Ihren ungenutzten Speicher effizient nutzen kann.
Wenn Sie einen Berater nach der richtigen Dimensionierung des PVS-Speichers fragen, erhalten Sie wahrscheinlich entweder die Antwort “Es hängt davon ab” (lieben Sie es nicht?), oder Sie erhalten Berechnungen auf der Grundlage sicherer Schätzungen. Wenn Sie keine Zeit oder Ressourcen haben, um eine ordnungsgemäße Dimensionierung durchzuführen, empfehle ich Ihnen dringend unsere Beratungs-Whitepaper, in dem fortgeschrittene Speicherüberlegungen für Provisioning Services (CTX125126) beschrieben werden. Es ist jedoch sehr empfehlenswert, eine ordnungsgemäße Dimensionierungsübung durchzuführen – jedes Projekt ist anders und die Anforderungen an die Dimensionierung können völlig unterschiedlich sein, wenn Sie Desktops mit zahlreichen Anwendungen veröffentlichen im Vergleich zur Situation, in der Sie nur verriegelte veröffentlichte Anwendungen veröffentlichen. Sie möchten außerdem feststellen, ob vor der Produktionsbereitstellung mehr Speicher erforderlich ist.
Tools zur Speicherdimensionierung
Es gibt zwei Tools, die ich sehr gerne verwende, wenn ich mit PVS arbeite. Sie ergänzen sich perfekt:
- Resource Monitor – Resource Monitor gehört zu den am meisten unterschätzten integrierten Tools im Windows-Stack. Resource Monitor bietet einen sehr guten Überblick über Ihre Umgebung – Sie können Engpässe leicht erkennen, eine Übersicht über CPU-, Speicher-, Festplatten- und Netzwerkaktivitäten anzeigen und detailliertere Informationen abrufen. Resource Monitor ist die perfekte Kombination aus Leistungsüberwachung und Task-Manager.
- RamMap – RamMap ist ein großartiges Tool von Mark Russinovich für detailliertere Untersuchungen. Wie im vorherigen Artikel besprochen, verwendet PVS nur Arbeitsspeicher für den Cache (Pagefile wird nicht für den Standby-Cache verwendet) und RamMap bietet perfekte Details zur Nutzung Ihres RAM.
Wenn Sie sie kombinieren, erhalten Sie einen globalen Überblick über die Nutzung Ihres Speichers, aber auch detaillierte Informationen, um fundierte Entscheidungen zu treffen. Beachten Sie, dass Resource Monitor in Echtzeit aktualisiert wird, während RamMap eine manuelle Aktualisierung erfordert.
Empfohlener Ansatz
Für die Überwachung des Speicherverbrauchs verwenden wir beide Tools. Während der Resource Monitor uns Informationen über den allgemeinen Speicherverbrauch liefert, verwenden wir RamMap, um festzustellen, wie viel Speicher wir tatsächlich für jeden vDisk benötigen.
Der gesamte Prozess kann wie folgt definiert werden:
- Standby-Cache leeren, um klare Ergebnisse zu erhalten.
- Zielgerät bis zum Anmeldebildschirm starten – Erste Überprüfung
- Warten Sie, bis Windows vollständig geladen ist – Zweite Überprüfung
- Ersten Benutzer anmelden – Dritte Überprüfung
- Reguläre Anwendungen ausführen, idealerweise von regulären Benutzern durchgeführt – Vierte Überprüfung
- Zielgerät herunterfahren – Fünfte Überprüfung
- Speicheranforderungen überprüfen
- Booten Sie beliebig viele Geräte und lassen Sie sie einige Tage/Wochen laufen.
Beispielhafte Dimensionierung
Im Folgenden finden Sie einen schrittweisen Prozess, um den Speicherverbrauch Ihrer PVS-Server besser zu verstehen.
Die Umgebung besteht aus einem einzigen Windows Server 2008 R2-Image, das nur die IE-Anwendung bereitstellt. Die Größe des Images beträgt 40 GB und wir speichern unsere vDisks lokal.
Zunächst fahren wir alle Geräte herunter, die PVS verwenden, um ein klares Bild unserer Umgebung zu erhalten. Nichts sollte vom PVS-Server gelesen werden, und stellen Sie sicher, dass Sie keine Daten vom oder zum PVS-Server kopieren.
Wir verwenden RamMap, um den Standby-Cache zu leeren (Option “Empty Standby List”):
Zu diesem Zeitpunkt arbeitet unser PVS-Server mit leerem Standby-Cache. Dies können wir leicht bestätigen, indem wir uns den Resource Monitor ansehen:
Nun ist es an der Zeit, unsere VM(s) zu starten. Normalerweise starte ich mehrere VMs gleichzeitig – da sie alle zur gleichen Zeit von einem Standard-Image booten, sollte es keinen großen Unterschied machen, ob man eine oder mehrere VMs bootet.
Sobald wir mit dem Starten der VMs beginnen, sehen wir, dass der Standby-Cache zunimmt:
Wenn wir zu RamMap wechseln und den Tab “Dateisummary” auswählen, können wir deutlich sehen, wer für das Füllen des Caches verantwortlich ist:
Haben Sie etwas bemerkt? Die .VHD-Datei wird nicht nur im Standby-Cache gespeichert, sondern auch im aktiven Seitenpool. Dies wird durch den Prozess StreamProcess.exe verursacht. Dies ist wichtig, da einige Seiten aktiv sind und die Überwachung nur der Größe des Standby-Caches keine genaue Darstellung wäre (da fast 25% des Gesamtspeichers nicht im Standby-Cache gespeichert sind).
Sobald wir den Anmeldebildschirm erreichen (Strg + Alt + Entf drücken, um sich anzumelden), sehen wir, dass das Image etwa 450 MB Speicher belegt:
Der Standby-Cache beträgt hingegen bereits 561 MB. Dies liegt daran, dass Windows nicht nur unsere .VHD-Datei zwischenspeichert, sondern auch jede andere gepufferte Leseoperation:
Nun könnten wir sagen, dass PVS ~450 MB lesen muss, um Windows Server 2008 R2 vollständig zu starten. Diese Aussage wäre jedoch nicht korrekt. Erinnern Sie sich an den Abschnitt “Lie to Children” aus meinem vorherigen Artikel? Windows ist viel komplexer, als wir zugeben möchten, und es gibt viel mehr unter der Oberfläche, als man auf den ersten Blick sieht. Während der Vorbereitung auf die Anmeldung (und Sie können sich tatsächlich schon anmelden) laufen im Hintergrund noch viele Operationen.
Daher ist es wichtig zu identifizieren, wann wir entscheiden, dass Windows vollständig gestartet ist. In meinem Fall übermittle ich die Farmkonfigurationen immer über Gruppenrichtlinien, daher warte ich, bis XenApp der Farm beigetreten ist – und um sicherzustellen, dass es wirklich im Leerlauf ist, warte ich, bis die gemeldete Auslastung 0 beträgt (Qfarm /Load) – nur zur Information, der Unterschied zwischen “Farm beitreten” und “Nullauslastung” beträgt etwa 250 MB:
Jetzt kann ich sagen, dass das vollständig geladene XenApp-Image etwa 735 MB benötigt. Wenn Sie es mit der einfachen Überprüfung des Anmeldebildschirms vergleichen, sehen Sie den Unterschied von fast 300 MB.
Der nächste wichtige Schritt ist die Benutzeranmeldung. Im Durchschnitt erfordert die erste Benutzeranmeldung zusätzliche 50-60 MB (weniger bei lokalen Konten), selbst wenn Ihr Standardprofil nur 1 MB groß ist. Der potenzielle Grund (ich nehme es als Tatsache hin und untersuche es nie ausführlich) ist, dass bei der ersten Anmeldung andere Betriebssystemkomponenten involviert sind – zum Beispiel Aufrufe bestimmter APIs (aus Bibliotheken, die noch nicht heruntergeladen wurden):
Nachdem wir uns von diesem ersten Benutzer abgemeldet haben, sehen wir, dass unsere Situation tatsächlich sehr ähnlich ist wie beim ersten Abmelden – es handelt sich nicht nur um die einfache Löschung des Ordners, sondern es sind zusätzliche APIs beteiligt:
Um Ihnen den Unterschied zwischen Standby-Cache und tatsächlicher Speicherbelegung der Datei zu zeigen, hier dasselbe Bild aus dem Resource Monitor. Beachten Sie, dass der Standby-Cache 1292 MB beträgt (wie wir zuvor gesehen haben, werden nur 740 MB tatsächlich von unserer vDisk verwendet):
Der Unterschied zwischen diesen beiden Zahlen kann Ihnen tatsächlich sagen, wie viel Speicher Sie mindestens für den PVS-Server-Cache reservieren sollten (operativer Speicher + Standard-Systemcache + vDisk-Systemcache). Unsere Standardempfehlung lautet, 512 MB Systemcache für das Betriebssystem selbst zu reservieren, und Sie können sehen, dass diese Zahl die realen Erfahrungen im wirklichen Leben ziemlich gut widerspiegelt.
Dies ist die Strafe für die erste Anmeldung/Abmeldung – die anderen Benutzer sind davon nicht betroffen. Dies ist ähnlich wie der erste Benutzer, der beim Anwendungs-Streaming seinen Cache aufbaut und die Anwendung streamt. Kann man den ersten Benutzer vorab cachen? Kaum, die einzige potenzielle Lösung wäre die automatische Anmeldung mit einem streng begrenzten Benutzer oder das Initiieren des Prozesses, das auch das Benutzerprofil lädt. Dies erfordert jedoch aufgrund von Sicherheitsgründen eine sorgfältige Überlegung. Der Großteil der Datenlesevorgänge während der Profilerstellung stammt tatsächlich aus dem System32-Ordner und nicht aus dem C:Benutzer-Ordner selbst. Der potenzielle Gewinn ist wahrscheinlich sehr gering für XenApp-Server, könnte jedoch für XenDesktop-Workloads interessanter sein (und könnte möglicherweise zu einem dritten PVS-Internals-Artikel führen).
Unser Server kann zu diesem Zeitpunkt als vollständig für die Benutzerlast vorbereitet angesehen werden – jetzt ist es an der Zeit, Ihre Pilotbenutzer zu bitten, einige Tests durchzuführen. Am Ende könnten Sie sehr überrascht sein – in meinem Fall betrug der durchschnittliche Speicherbedarf für den Betrieb einiger Server für 4 Tage nur etwa 1 GB:
Bedeutet dies, dass ich nur 3 GB Speicher für meinen PVS-Server benötige (2 GB für das Betriebssystem und 1 GB für vDisk)? Definitiv nicht, und das wäre eine sehr schlechte Entscheidung. Schauen wir uns unsere Formel für die Dimensionierung an:
2GB + (#XA_vDisk 4GB) + (#XD_vDisk 2GB) + 15% (Puffer)
Wir haben gerade bewiesen, dass unsere vDisk nicht mehr Speicher benötigt als empfohlen. In diesem Fall wäre die Empfehlung, sich auf 4 GB Speicher pro vDisk zu beschränken. Wenn unsere Tests höhere Speicheranforderungen ergeben würden, müssten wir diese Anforderung erhöhen, aber mit sehr wenigen Ausnahmen sollte diese Formel die meisten Fälle abdecken. Vergessen Sie nicht, dass Sie etwas System-Cache für nicht mit PVS zusammenhängende Seiten bereitstellen müssen (dies ist im 15%igen Puffer enthalten).
Bitte beachten Sie, dass dies nicht bedeutet, dass Sie 1 GB Speicher für diese vDisk reservieren müssen. Das Ziel von PVS ist es, ~80% der Festplattenlesevorgänge zu optimieren. Wenn PVS hin und wieder von einer Festplatte lesen muss, bedeutet dies nicht unbedingt, dass Ihre Dimensionierung falsch ist.
Zusammenfassung
Beachten Sie bei der Speicherdimensionierung für PVS einige allgemeine Empfehlungen:
- Verwenden Sie die Größe der vDisk nicht zur Berechnung des Speicherbedarfs. Der Cache-Manager zwischenspeichert Blöcke, nicht die gesamten Dateien. Sie werden wahrscheinlich überrascht sein, wie wenig Speicher Sie tatsächlich für das durchschnittliche Betriebssystem benötigen.
- Streben Sie nicht danach, 100% der Lesevorgänge aus dem Cache bereitzustellen. Mit 2-4 GB Speicher für jede vDisk können Sie wahrscheinlich eine Erfolgsrate von 80% bei den Lesevorgängen erreichen (mit Ausnahmen natürlich).
- Verwenden Sie den Standby-Cache nicht zur Dimensionierung. Windows versucht alles zu zwischenspeichern, solange ausreichend Speicher vorhanden ist, und Dateien werden nicht aus dem Cache entfernt, es sei denn, es gibt eine bessere Verwendung für diesen Speicher. Wenn Sie Ihren PVS-Server für einige Wochen unbeaufsichtigt lassen und dann beschließen, dass Sie mehr RAM kaufen müssen, weil kein freier Speicher vorhanden ist, sollten Sie zuerst zu PVS Internals 1 zurückkehren und es diesmal sorgfältiger lesen. Wie ich versucht habe zu erklären: PVS benötigt tatsächlich weniger Speicher als die meisten Leute erwarten.
- Unterschätzen Sie nicht den Speicherbedarf Ihrer VMs. Es ist ein sehr häufiger Fehler, dass Sie für den PVS-Server selbst viel Speicher haben, aber nicht genug Speicher für Ihre VMs. Vergessen Sie nicht, dass Ihre Zielgeräte auch den System-Cache verwenden – dadurch werden die Neu-Lesevorgänge vom PVS-Server reduziert. Für ein Einzelbenutzer-Betriebssystem sollten Sie mindestens 500 MB für den System-Cache reservieren, für ein Mehrbenutzer-Betriebssystem mindestens 2GB.
- Löschen Sie den Cache vor der Benchmark-Messung. Stellen Sie immer sicher, dass der Standby-Cache geleert ist, bevor Sie Zahlen aufzeichnen, um klare Ergebnisse zu erhalten. Windows versucht alles zu zwischenspeichern, daher ist es leicht, den Cache “aufzufüllen”. Dies ist völlig normal und wie zuvor erklärt, dank des priorisierten Cache-Managers werden Einzelschussoperationen nicht die häufig genutzten Datenblöcke überschreiben. Für Ihre endgültigen Dimensionierungszahlen vergessen Sie nicht, etwas Overhead (in der Regel etwa 15%) hinzuzufügen.
- Identifizieren Sie Breakpoints während Ihrer Tests. Erwarten Sie nicht, dass Windows vollständig geladen ist, wenn der Anmeldebildschirm angezeigt wird. Wie Sie in Ihren Tests feststellen werden, werden immer noch Daten im Hintergrund gelesen.
- Achten Sie auf Komponenten, die alle Dateien lesen. Wenn Sie einen falsch konfigurierten Virenschutz oder andere Komponenten haben, die auf die Festplatte zugreifen können, kann Ihr Standby-Cache leicht gefüllt werden. Achten Sie darauf, die Verwendung des Cache zu überwachen, um solche Probleme frühzeitig zu erkennen. Dieses Problem kann sowohl auf dem PVS-Server als auch auf dem Zielgerät selbst auftreten.
- Verwenden Sie unsere magische Formel, es sei denn, Sie haben einen sehr spezifischen Grund, dies nicht zu tun. Diese Formel deckt die meisten Implementierungen ab. Es sei denn, Sie haben einen sehr spezifischen Grund dafür oder Sie haben eine hohe Anzahl von vDisks, sollten Sie ihr folgen. Hier ist sie noch einmal zur Erinnerung:
2GB + (#XA_vDisk 4GB) + (#XD_vDisk 2GB) + 15% (Puffer)
Ich möchte auch meinen Kollegen Dan Allen, Nicholas Rintalan und Pablo Legorreta (in alphabetischer Reihenfolge, damit sie sich nicht streiten) für ihre enorme Hilfe danken!
Martin Zugec
