Last Updated on 1. Februar 2020 by Sebastian
In diesem Blogbeitrag möchte ich über ein Thema sprechen das mit Sicherheit schon sehr viele beleuchtet haben und das mit Sicherheit auch in div. Citrix Artikeln bereits behandelt wurde. Da dieser Blog allerdings meine Sicht auf die Dinge darstellen soll sowie auch meine Wissensdatenbank gibt sehe ich mich dazu gezwungen dieses Thema auch durchzukauen.
Eine Citrix Infrastruktur besteht aus diverse Komponenten die alle verschiedene Aufgaben zu erfüllen haben. Diese Komponenten leben von einem engen zusammenspiel untereinander.
Der Lizenzserver
Seine Aufgabe ist das bereitstellen von Lizenzen für eine Citrix-Session. Es gibt zwei verschiedene Lizenzierungsarten. Per User/Device oder Concurrent. Per User/Device bedeutet in diesem Fall das die Lizenz fest einem User oder Gerät zugewiesen wird. Sollte sich ein User oder ein Gerät innerhalb von 90 Tagen nicht mehr anmelden wird die Lizenz wieder frei für einen anderen User oder Gerät. Das Concurrent Modell bedeutet das der User für den Zeitraum seiner Session eine Lizenz zugewiesen bekommt. Wird die Session beendet wird auch automatisch die Lizenz für den nächsten User frei. Der Lizenzserver hat sehr geringe Hardwareanforderungen. 2 GB für den reinen Dienst. Eine VM mit 2 vCPUs und 4 GB ist absolut ausreichend. Eine Hochverfügbarkeit kann über ein Cold Standby Clone hergestellt werden. Ist allerdings nicht nötig da bei einem nicht verfügbaren Lizenzserver der Delivery Controller in eine 30 Tage Grace Period verfällt. Innerhalb dieser 30 Tage sollte ein Administrator den Lizenzserver wiederherstellen.
Der Storefront
Die primäre Aufgabe des Storefronts ist die Authentifizierung des Users mit Username und Password aus dem Active Directory. Alternativ gibt es aber auch die Möglichkeit einer SmartCard Authentifizierung, Single SignOn (Auf Basis der Active Directory Daten) und weiteren Authentifizierungsarten(FAS). Darüberhinaus ist der Storefront für das Anzeigen der Applikationen/Desktops, die dem User zur Verfügung stehen zuständig. Er leitet die Anfragen (Klick auf das Programmicon) entsprechend an den Delivery Controller(XML Request) weiter und stellt die daraus resultierende ICA Datei dem Benutzer zur Verfügung. Der Storefront selbst ist eine Webanwendung und benötigt einen IIS ( Internet Information Service ) von Microsoft. Der Storefront benötigt 2GB RAM und sollte auf einer VM mit 2 – 4vCPUs und 4 GB RAM installiert werden. Ein Storefront sollte grundsätzlich Redundant ausgelegt werden, weil bei einem Ausfall kein Login mehr möglich ist. Es gibt hier die N+1 Regel. Die Storefront Server in einer Farm müssen spätestens nach einer Anpassung an einem der Storefronts abgeglichen werden. Hierzu muss eine Replikation in der Storefront-Konsole durchgeführt werden. Immer von dem Server auf dem man auch die Änderungen vorgenommen hat. Da hier ein simpler Kopierprozess die C:\Inetpub\wwwroot Verzeichnisse synchron hält.
Der Delivery Controller
Der Delivery Controller ist das Herzstück der Citrix Virtual Apps und Desktop Infrastruktur ( Ehemals XenApp & XenDesktop ). Er ist der Broker ( Vermittler ) zwischen den anfragenden Usern ( Endpoints ) und den Desktops oder Applikationen. Er verwaltet auch die Maschinen ( Server, Desktop und Remote PCs ) in sog. Maschinenkataloge und stellt diese einer bestimmten Gruppe von Usern in Bereitstellungsgruppen zur Verfügung. Er holt sich die Lizenzen beim Lizenzserver aber er kann auch über MCS ( Machine Creation Service ) selbstständig Maschinen auf dem Hypervisor klonen und bereitstellen. Der Delivery Controller sollte hierfür immer redundant ausgelegt sein. Auch hier gilt die Regel N+1. Der Vorteil beim Delivery Controller ist das nachdem die beiden Controller miteinander verbunden sind ein automatischer Abgleich der Daten periodisch erfolgt. Ein DeliveryController sollte in der Regel 4GB RAM und 4vCPUs bekommen. Damit sind im Schnitt 5000 Active Sessions möglich.
SQL Server
Der SQL Server ist wichtig da er die 3 Datenbanken des Delivery Controller enthält.
- Site Database
- Configuration Logging
- Monitoring Database
Die Site Database ist die Wichtigste von den 3 Datenbanken da Sie die komplette Konfiguration der Site eines Delivery Controllers oder Clusters enthält. Hier sind alle Informationen über Desktops, Applikationen, Maschinen etc. gespeichert.
Die Configuration Logging enthält alle Informationen über Administrative Ereignisse die auf einem Delivery Controller passieren. z.B. Bereitstellungsgruppe in den Wartungsmodus versetzt von $admin
Die Monitoring Database ist die wichtigste Quelle für den Citrix Director. Hier befinden sich alle Wichtigen Informationen zu laufen Sessions, angemeldeten Usern, Anmeldezeiten etc.
Sollte ein SQL Server ausfallen ist der Delivery Controller nur noch eingeschränkt handlungsfähig. Er besitzt zwar schon seit etwas 7.6 ein LHC ( Local Host Cache ), allerdings ist dies SQL Express Datenbank lediglich ein Schnappschuss der eigentlichen Site Database. Er hat also Infos über aktuelle verbundene User und deren Sessions aber gerade im Bereich Non Persistent ist es nicht möglich mit dem LHC sauber zu arbeiten. Deswegen solle man einen SQL Server redundant auslegen. Entweder High Availability oder Cluster Betrieb. Die Datenbanken selbst haben eine recht überschaubare Größe. Die Site Database kann von 30 – 390 MB erreichen. Die Monitoring 20 MB – 119 GB und die Config 30 – 200 MB. Die Monitoring Database ist natürlich stark davon abhängig wie lange die Daten gespeichert werden sollen.
Bei der Hardwarevoraussetzung gilt grundsätzlich die Regel. 0 – 5 tausend User 2vCPUs 4 GB ; 5 – 15 tausend User 4vCPUs 8 GB ; Größer 15 tausend 8vCPUs 16 GB
Citrix Director
Er ist ist das Helpdesk Tool und eine wichtige Komponente. Nicht direkt eine Kernkomponente aber ich möchte ihn trotzdem erwähnen da er das Leben eines Citrix Admin leichter machen kann. Der Director ist eine Web Applikation die sich an den Delivery Controller hängt um dort die Daten aus der Site Database, sowie Monitoring Database auszulesen und dem Service Desk Mitarbeiter zur Verfügung zu stellen. Hier gibt es die Möglichkeit die Session eines Users zu Spiegeln, Prozesse zu terminieren, abzumelden, Profile zurückzusetzen oder Anmeldezeiten auszuwerten. Darüberhinaus liefert er viele weitere wichtige Informationen. Es gibt die Möglichkeit den Director auf einem Delivery Controller oder Storefront mitlaufen zu lassen. Die Empfehlung sagt bis 100 Helpdesk Mitarbeiter 4 vCPUs und 4 GB RAM. In großen Umgebungen sollte der Citrix Director auf einer eigenen VM laufen. Er kann mehrfach installiert werden und benötigt kein Datenabgleich da seine Quelle der DeliveryController bzw. die SQL Datenbank ist.