Citrix Provisioning Services – ist eine Technologie, die es ermöglicht die große Anzahl von Maschinen (virtuelle oder physische Zielsysteme) bereitzustellen. Die Zielsysteme im Gegensatz zu einem klassischen PC verfügen nicht über eine Festplatte mit einem installierten Betriebssystem und werden direkt vom Netzwerk gestartet.
Citrix Provisioning Services Architecture Diagram and Communication Ports
Download: Citrix_PVS_Architecture_Communication_Ports-onPrem.pdf
Download: Citrix_PVS_Architecture_Communication_Ports-onPrem.vsdx
Funktionsweise
Der Kernpunkt der PVS-Infrastruktur ist der Provisioning Server. Der PVS-Server ist nicht nur für die Verwaltung der PVS-Umgebung zuständig, sondern ist ein zentraler Streaming-Point der vDisks. Alle Konfiguration-Einstellungen werden in einer MS SQL-Datenbank gespeichert. Im Vergleich zu MCS ist PVS kein integrierter Bestandsteil von XenApp/XenDesktop.
Durch redundante Installation von PVS-Servern erreicht man eine kontinuierliche Verfügbarkeit von Hauptkomponenten. Man braucht mindesten zwei PVS-Server um die Ausfallsicherheit zu gewährleisten. Für die Kommunikation miteinander verwenden die PVS-Server ein IPC Protokoll.
Die folgenden Schritte beschreiben im Groben die Funktionsweise:
1. PVS Streaming Service stellt einen PXE-Bootstrap File zur Verfügung. PXE-Bootstrap File enthält die Anweisungen eine vDisk anzufordern.
2. Es wird überprüft, ob das Zielsystem einen Eintrag in der PVS-Datenbank hat (MAC-Adresse).
3. vDisk wird zum Zielsystem gestreamt. Die Übertragung ist UDP basierend.
Master Image - vDisk
Auf einem Server oder Desktop Betriebssystem wird ein PVS Target Device installiert. Die Target Device Software konvertiert (Imaging Wizard) die C:\ Partition in eine vDisk. Für die Konvertierung wird XenConvert Tool verwendet. Am Ende des Vorgangs wird die C:\ Partition auf dem Store als .vhd-File (ab Version 7.7 haben Sie eine Wahl zwischen VHD und VHDX) gespeichert.
Dateitypen:
.vhdx - die vDisk selbst
.lok - Lok-File wenn in die vDisk in Benutzung ist
.pvp - vDisk Eingenschaften
.avhd - (z.B. .1.avhdx) – ist ein Delta-File (Differencing Disk)
Boot Methoden
Es gibt drei unterschiedliche Arten die Zielsysteme in einer PVS-Umgebung zu starten: DHCP, PXE und BDM
1. DHCP Methode
DHCP ist die am weitesten verbreitete und meist genutzte Methode. Der Client bekommt von DHCP-Server eine IP-Adresse, die unteranderem folgende Optionen enthält:
- Option 66 ist der Server, wo die VM nach weitere Information sucht (IP-Adresse des PVS-Servers).
- Option 67 - Name des BootStrap File (ARDBP32.bin)
2. PXE Methode
Der Client bekommt nur die IP Adresse von einem DCHP-Server, da auf dem DHCP Server keine Optionen 66 / 67 konfiguriert wurden. Der PVS hört auf Request und antwortet drauf mit Option 66 / 67. Diese Methode kann je nach Netzwerk-Konfiguration nicht realisierbar sein.
3. BDM (Boot Device Manager)
In diesem Fall wird das Zielsystem von einem physischen Bootmedium (CD) gestartet. In diesem Fall brauchen Sie keine DHCP-Optionen oder keinen PXE-Server.
4. BDM Boot Disk Partition
Diese Option ist ab der Version 7.9 verfügbar und bietet die Möglichket zusätzlich eine bootfähige Partition zu erstellen.
Schrittweise Beschreibung des Boot-Prozesses
PVS Boot Process
- IP Acquisition – The Target Device acquires an IP address.
- Bootstrap Download – The bootstrap file is downloaded.
- PVS Logon Process – The Target Device logs on to PVS.
- Single Read Mode – Single read mode communicaton is established between the Target Device and the PVS Server.
- BNISTACK/MIO – The BNISTACK driver on the Target Device takes over communications with the PVS Server and Multiple I/O
Detaillierte bildliche Darstellung des Boot Prozesses finden Sie in folgenden Dokumenten:
- Citrix Provisioning Services (PVS) Boot Process
- CTX235809 - Provisioning Services Logon Process Sequence
- CTX227725 - Citrix Provisioning Services Boot Process (Beschreibung)
- CTX136378 - Provisioning Services Boot Process Diagram
PVS Store
Ein Store ist ein physischer Speicherort (ein Ordner) für die vDisks. Dieser Ordner kann sich auf jedem PVS-Server befinden oder auf dem gemeinsamen Speicher vorhanden sein. Sorgen Sie für die ausreichenden Platzkapazitäten und Leseperformance.
Die Verwendung von Shared Storage benötigt keine zusätzlichen Mechanismen um den vDisks synchron zu halten.
Die Provisioning Services haben keine eingebauten Mechanismen, um die vDisks zwischen den Knoten zu replizieren. Man verwendet dafür oft eine einfache und elektive Methode, nämlich ein Robocopy-Script. Der Einsatz von DFS (Distributed File System) ist möglich. RAID 1 oder RAID 10 ist der empfohlene RAID Level für Write Cache Files.
Write Cache
Write Cache ist ein temporärer Speicher, die Daten enthält, die vom laufenden Betriebssystem geschrieben wurden, sowie die Informationen, die nach einem Reboot erhalten bleiben sollen (z.B. Eventlogs, Virensignaturen, App-V Cache). Write Cache Disk ist auch der typischen Speicherort für Windows Pagefile.
Die Write-Cache Datei (vdiskdiff.vhdx) kann ständig wachsen und wird erst nach dem Reboot wieder zurückgesetzt. vdiskdiff ist eigentlich “Cache on Target Device Hard Drive” oder „Cache in device RAM with overflow on hard disk“
Die aktuelle Version des PVS Servers bietet sechs verschiedenen Optionen zur Speicherung des Write Caches. Jede Option hat einige Vor und Nachteile. Die Option Cache in device RAM with overflow on hard disk wird empfohlen.
- Lokal auf der Festplatte des PVS-Servers (Cache on server)
Diese Option bedeutet, dass die ständigen Zugriffe über das Netzwerk stattfinden. Das konnte je nach Storage und Netzwerk langsam sein.
- Lokal auf der Festplatte des Zielgerätes (Cache on device hard disk)
Im diesem Fall handelt es sich um Zugriffe auf dieselbe VM. Diese Option war vor kurzem die beste Wahl.
- Im Arbeitsspeicher des Zielgerätes (Cache in device RAM)
Wenn Sie die bestmöglichen Performancewerte erreichen wollen, dann ist diese Option gerade passend, verursacht aber die höheren Kosten
- Lokal auf der Festplatte des Zielgerätes mit Überlauf Im Arbeitsspeicher (Cache on device RAM with overflow on hard disk)
Die letzte Option schafft die ideale Balance zwischen Performance und Kosten und gilt mittlerweile als empfohlen. Zuerst wird Arbeitsspeicher benutzt und danach die Festplatte.
- Cache on device hard disk persistent und Cache on server, persistent
Wie der Name auch sagt, wird die Write Cache Datei nicht nach einem Reboot zurückgesetzt.
vDisk Zugriffmodus
Private Mode - in diesem Fall befindet sich die vDisk in einem beschreibbaren Zustand und gehöht einer VM.
Standard Mode - die vDisk ist schreibgeschützt und kann gleichzeitig von mehrere VMs verwendet werden.
Wenn wir die Datenbank-Sprache verwenden, eine vDisk in Privat Mode ist immer eine 1: 1-Beziehung, in Standard Mode immer eine 1:n-Beziehung.
vDisk Aktualisierung
Wie auf dem unteren Bild zu sehen ist, besteht ein Target Device aus zwei unterschiedlichen Datei-Arten: .x.avhdx und .vhdx. Bei der .x.avhdx-Datei handelt es sich um eine sogenannte Differencing Disk (.avhdx), die fortlaufend nummeriert wird. Die Differencing Disks werden für die Installation von Software, Updates oder sonstigen Anpassungen verwendet.
Das Thema vDisk Aktualisierung wurde detailliert in folgendem Artikel beschrieben: PVS vDisk Update, Full-Kopie vs. Versionierung
Zum besseren Technologieverständnis ist folgende Artikelreihe von Martin Zugec zu empfehlen:
Hilfreiche Links
Size Matters: PVS RAM Cache Overflow Sizing | Öffnen
Understanding Write Cache in Provisioning Services Server | Öffnen
Frequently Asked Questions: Provisioning Services Write Cache | Öffnen
PVS Write Cache Sizing & Considerations | Öffnen