Wer sich mit dem Konzept des Citrix™ Provisioning Server befasst wird zwangsläufig feststellen, dass die Lösung nicht nur für Clients sondern auch für Server einen erheblichen Mehrwert bietet. Schaut man dann allerdings hinter die Kulissen, stellt man relativ schnell fest das es sich um einen „Single Point of Failure“ handelt. Sollte der Provisioning Server ausfallen sind schlagartig alle Server (oder natürlich Clients) ohne Festplatten und können nicht mehr booten. In einem Rechenzentrum natürlich der Supergau. Deshalb ist es gerade bei der Umstellung auf einen Citrix™ Provisioning Server notwendig, sich über Hochverfügbarkeit entsprechende Gedanken zu machen und leider auch etwas Geld in die Hand zu nehmen.

Hochverfügbarkeit ist kein Thema das nur den Provisioning Server betrifft. Prinzipiell sind alle Komponenten der Infrastruktur betroffen und sollten hochverfügbar ausgelegt werden. Wie könnte also so eine hochverfügbare Infrastruktur aussehen?

Betrachten wir zuerst mal den Platz auf dem die vDisks abgelegt werden sollen. Von einem Fileserver Cluster unter Windows und beispielsweise einem externen SCSI Device über NAS oder SAN Systeme ist hier alles möglich. Jedes System hat seine Vor- und Nachteile. Wichtig an dieser Stelle ist es jedoch sicherzustellen, dass die Daten auf den Plattensystemen redundant gespeichert werden (RAID-Level, Snapshots, Mirroring usw.).

Nicht nur das Plattensystem muss redundant sein, sondern auch der Weg dahin. Das bedeutet doppelte Switche, ausfallsichere Netzwerkinterfaces (Teaming, Bonding) oder redundante HBA's mit Multipathing. Das betrifft nicht nur das Backend zum Speichersystem sondern auch Frontend ins LAN wo die Clientsystem angeordnet sind. Auch hier sind redundante Switches und ausfallsichere NIC's unbedingt erforderlich. Ein zusätzlicher Punkt der auch nicht vergessen werden sollte, sind die zusätzlich benötigten Systeme. Hier haben wir Domänencontroller, SQL-Server, Citrix™ Lizenzserver sowie die diversen Dienste wie DHCP, DNS, TFTP oder PXE. Nicht zu vergessen sind natürlich auch die Citrix™ Provisioning Server, die ebenfalls redundant und hochverfügbar ausgelegt werden sollten.

Ich gehe in diesem Artikel nicht auf die Konfiguration von Storage, Switchen oder anderen Komponenten ein. Das würde den Rahmen des Artikels sprengen. Was aber an dieser Stelle interessiert, ist die HA-Konfiguration des Citrix™ Provisioning Server.

In dem vorher abgebildeten Design benötigen wir zur hochverfügbaren Konfiguration mindestens zwei Citrix™ Provisioning Server 5.0 (im Beispiel mit 4 Netzwerkschnittstellen zwei NIC's ins LAN und zwei HBA's zur SAN). Diese beiden Server müssen wir nun erstmal installieren, in dem folgenden HowTo mit Windows Server 2003R2 SP2.

Der erste Schritt ist auf beiden Server die Installation des .NET 3.0 Framework, dass auf der Installations CD im Verzeichnis .\ISSetupPrerequisites zu finden ist. Wenn dieser Schritt abgeschlossen ist, installieren wir den Provisioning Server auf dem ersten der beiden Maschinen (Anleitung hier). Ich setze hier voraus, dass bereits eine Domäne, ein Microsoft SQL Server 2005 sowie der Citrix™ Lizenzserver 11.5 mit Provisioning Server Lizenz bereits existieren und die beiden PVS 5.0 Server Mitglied in dieser Domäne sind. In diesem Beispiel habe ich alles auf einen Domänen Kontroller installiert, was natürlich in einer produktiven Umgebung auf verteilten Systemen gemacht werden sollte.

Der erste Server erzeugt Farm, die Site und die Collection, der zweite Server wird während der Installation dann Mitglied der Farm und der Collection. Nach Abschluss der Installation und Konfiguration der beiden Provisioning Server sollte die Ansicht in der Konsole wie folgt aussehen.

Als erstes müssen wir nun die Bootstraps beider Provisioning Server anpassen. Dazu klicken wir mit der rechten Maustaste auf Configure Bootstrap.

In dem folgenden Dialog müssen beide Server für den Default Bootstrap File ARDBP32.BIN angegeben sein.

Als nächstes erstellen wir einen vDisk Store. Dieser Store sollte auf einem shared Storage (SAN, NAS, CIFS Share) liegen. Dazu klicken wir mit der rechten Maustaste auf den Knoten „Stores“ und wählen Create Store….

In dem Store Properties Dialog kann der Store Name und die Description frei vergeben werden. Nur das Feld Site that acts as the owner of this store muss auf die richtige Site verweisen (in diesem Beispiel haben wir ja nur die Site SiteOne).

Auf dem Reiter Paths müssen wir jetzt nur noch den Pfad zu dem vDisk Store sowie zu dem Default Write Cache angeben. Hier funktionieren verbundene Laufwerke (Z:\[…]) oder auch UNC Pfade (\\[Server]\[Share]).

Im letzen Reiter Servers nur noch die beiden Server auswählen und OK klicken.

Was wir jetzt noch brauchen ist eine vDisk in unserem Store. Dazu klicken wir mit der rechten Maustaste auf den soeben angelegten Store und wählen Create vDisk….

Prinzipiell ist in diesem Dialog alles selbsterklärend. Wichtig ist nur, die Disk size ausreichend groß zu wählen und anzugeben, ob es sich um eine feste oder dynamische vDisk handelt. Wenn die Disk erstellt ist folgt der normale Installationsprozess. Also Disk mounten, formatieren und wieder dismounten.

Bevor wir nun unser Master Target Device auf die vDisk übertragen, aktivieren wir auch hier noch die Hochverfügbarkeit. Dazu klicken wir mit der rechten Maustaste auf die vDisk und wählen Properties. Im folgenden Dialog entscheiden wir uns für das Loadbalancing zwischen den Provisioning Servern.

Danach klicken wir noch auf den Button Edit file properties und konfigurieren auf dem Reiter Options noch High Availability (HA) und Active Directory machine account password management.

An dieser Stelle sind wir mit der HA Konfiguration des Provisioning Servers fertig und können unser Master Target Device starten und auf die vDisk bringen. Dieser Prozess ist unter anderem in den folgenden Artikeln beschrieben.

Wenn nun das Target Device erfolgreich seine vDisk angelegt hat, können wir den Server (oder einen neu angelegten) von der vDisk starten. Hierfür muss lediglich in den Properties des Target Devices bei Boot from: statt der Hard-Disk die vDisk ausgewählt werden.

Nach dem Start des vDisk Servers sollte der Loadbalancing Mechanismus die Maschine auf einem der beiden Provisioning Server verbunden haben. Um jetzt die hochverfügbarkeit zu testen, stoppen wir einfach mal den Streaming Service auf dem Provisioning Server mit dem sich unser vDisk Server jetzt verbunden hat.

Kurz darauf erscheint der Provisioning Server in der Provisioning Server Konsole als Down. Der zweite Provisioning Server übernimmt wenig später die Verbindung und zeigt diese auch unter Connections an (mit F5).

Hier eine kurze Übersicht, wie viele Target Devices in einer Umgebung mit zwei Citrix™ Provisioning Server mit den unterschiedlichen Storage-Systemen und Write-Cache Konfigurationen unterstützt werden. Diese Übersicht basiert auf Tests von Citrix und sollte nur als ein ungefährer Richtwert angesehen werden.

Wer die oben beschriebene Konfiguration nachstellt (ich habe es in einer XenServer Umgebung installiert), kann sich schnell ein Bild davon machen das es Problemlos funktioniert.

Ein Problem in einer Umgebung die mit dem Provisioning Server versorgt wird ist der Write Cache. Da die vDisks im Normalfall ja Read-Only sind, müssen die Bewegungsdaten eines Servers ja irgendwo hingeschrieben werden. Citrix™ benutzt hier einen Write-Cache, der entweder auf den lokalen Platten des jeweiligen vDisk Servers oder aber auf dem Provisioning Server selbst (hier natürlich auch auf einem shared Storage) abgelegt wird. Das ganze kann verschlüsselt oder unverschlüsselt gespeichert werden.

Der Nachteil dieser Lösung ist, dass der Write-Cache nach jedem Reboot eines vDisk Servers gelöscht wird. Auf den ersten Blick nicht wirklich schlimm, denn der Server kommt ja ganz frisch nach einem Reboot wieder hoch. Was ist aber z.B. mit Virensignaturen oder sonstigen Updates die zur Laufzeit eines Server gespeichert werden müssen?

Mit dem ServicePack 1 für den Provisioning Server, liefert Citrix noch ein paar Features nach. Die betreffen zwar nicht unbedingt die Hochverfügbarkeit, haben aber für ein solches Design einen erheblichen Mehrwert. In der aktuellen Version, müsste eigentlich jedes Update der Virensignaturen in die vDisk eingebaut werden und diese vor einem Reboot der vDisk Server neu released werden. Auch z.B. Crashdumps sind dadurch nach einem Reboot verloren und Kernel debugging nicht mehr möglich.

Mit SP1 führt Citrix™ nun den Difference Disk mode ein. Dies erlaubt eine Speicherung des Write-Cache über einen Reboot hinaus. Der Write-Cache bleibt solange erhalten, bis eine neue Version der vDisk released wird. Erst dann wird der vorhandene Cache verworfen und ein neuer angelegt. Um hier das Konzept der Hochverfügbarkeit weiter zu verfolgen muss natürlich der Pfad zum Write-Cache auf einem Share liegen, auf das alle Provisioning Server Zugriff haben. Was in unserem Design dann etwa so aussehen würden.

Für alle die diesen Artikel hilfreich fanden gebe ich noch einen kleinen Ausblick auf zukünftige Artikel und Konzepte. Wer eine XenApp Farm betreibt und diese bei gleicher Useranzahl mit 2/3 weniger Server oder auf gleicher Anzahl Server 2/3 mehr User betreiben möchte, sollte mal einen Blick auf das folgende Design werfen.