Automatisiertes Testen der XenApp-Performance (AAM)

Wer hätte nicht gerne eine EMail oder Warnung, *bevor* die Performance des XenApps / der Citrix Terminalserver-Farm den User zum Anruf bewegt? Eben. Dass es dafür ein Tool aus dem Dunstkreis von EdgeSight gibt, dass prinzipielle jeder einsetzen darf, der XenApp in der Enterprise- oder Platinum-Edition lizenziert hat, ist aber scheinbar eher unbekannt. Deshalb (und um einen Fehler nachzustellen, der mir in einem CXA-301 Lab begegnete – Danke an Sam!) geht es in diesem Blogbeitrag heute um “Active Application Monitoring” (AAM).

Kapitel 1: die Installation

Das AAM kann von der XenApp DVD installiert werden – dort befindet es sich im “\Service Monitoring\Installers\Server”-Verzeichnis als “EdgeSight Active Application Monitoring.msi”.

Vor der Installation sollte das J#.Net Paket aus dem \Support-Ordner installiert werden umd die Unterstützung für die direkte Ansprache des XML-Dienstes zu erhalten, die Installation selbst kann dann mit “Custom” angepasst werden.

In der angepassten Installation lässt sich der WebInterface-Connector auswählen, der beim typischen Setup nicht vorselektiert wäre.

Der nachfolgende Dialog verlangt die Eingabe eines Kennworts – dies soll den Launcher-Dienst schützen, so dass er lediglich Instruktionen von Controllern entgegennimmt, die über das passende Kennwort verfügen – zu Demozwecken habe ich hier “Password1” eingetragen.

Next: die Installation beginnt.

Nach der Installation folgt die übliche Erfolgsmeldung.

Kapitel 2: Konfiguration des Controllers

Nach der Installation lässt sich das Programm über den Link zum “AAM Controller” aus dem Startmenü starten.

Das daraufhin einzugebende Kennwort muss das gleiche sein, was bei der Installation des Launcher-Dienstes angegeben wurde. Hierauf spielt auch die Verknüpfung “PasswortReset” an, die das für den Launcher-Dienst hinterlegte Kennwort ändert.

Im Hauptfenster des Controllers sollte nun zuerst die Verbindung zum EdgeSight Server eingetragen werden – sie wird benötigt, falls ein Test überhaupt nicht starten kann (Volllast auf den Servern, alle XenApp-Server down etc.)  und nicht bloß schlechte Performancewerte melden möchte.

In Punkt 1 wird der EdgeSight (for XenApp) Server eingetragen (netbios oder fqdn), gefolgt von dem verwendeten Webserverport. Ein Test (Punkt 2) prüft, ob die Verbindung erfolgreich hergestellt werden kann – die Erfolgsmeldung ist in Punkt 3 dargestellt.

Danach wird in dem (bereits erstellten) Test ein neues Skript angelegt, welches später die Verbindungsdaten und Ablaufinstruktionen enthält.

In den Eigenschaften des Skripts wird die verwendete Bildschirmauflösung festgelegt (sie sollte in etwa der von den Usern verwendeten Auflösung entsprechen). Im unteren Teil des Dialogs wird festgelegt, in welchem Intervall und an welchen Tagen der Test automatisiert laufen soll.

Nun wird ein Testuser in dem Programm benannt, die zuvor jedoch im Active Directory erstellt werden müssen (eine passende Batch-datei habe ich unter http://seetricks.blogspot.de/2011/10/demouser-anlegen.html abgelegt).

Ok, langsam – das Anlegen des Users zieht ein paar weitere Entscheidungen nach sich:
Punkt 1: “Connect from” bezeichnet den Netbios-Namen, den FQDN oder die IP-Adresse der Maschine, die den Lasttest tatsächlich durchführt (in diesem Beispiel der Controller-PC selbst, daher “localhost”).
Punkt 2: Benutzernamen des Testusers
Punkt 3: Passwort des Testusers
Punkt 4: hier wird die Domäne des Testusers eingetragen
Punkt 5: Hier kann entweder eine statische ICA-Datei angegeben werden (z.B. erstellt mit dem Citrix Tool QuickLaunch, zu finden unter CTX122536) . Ich wähle in diesem Demo den XML-Dienst.
Punkt 6: Über “Browse” lässt sich dann, wie im nächsten Dialogfenster dargestellt, die zyklisch zu testende Anwendung auswählen
Punkt 7: Der Server, dessen XML-Port angefragt wird
Punkt 8: der XML-Port des XenApp Servers
Punkt 9-11: die Credentials des Testbenutzers
Punkt 12: fragt mit den Daten aus Punkt 7-11 die Liste der freigegebenen Ressourcen des Testbenutzers ab.
Punkt 13: Auswahl der zu testenden Anwendung
Punkt 14: Schließen des aktuellen Dialogfensters und Übernahme der Daten in das vorige Dialogfenster (welches dann mit OK zu bestätigen ist)

Eine kleine Eigenart des Programms – der User, mit dem die nachfolgende Aufzeichnung gestartet werden soll, wird durch einen Mausklick auf das Monitorsymbol aktiviert.

Kapitel 3: Aufzeichung des Skripts

Durch Auswahl des Menüpunkts Test\Record wird eine Sitzung mit den in Kapitel 2 festgelegten Parametern gestartet – in meinem Beispiel also als Demo\Nurse1 mit Notepad.

Die aufgebaute Sitzung erscheint (vorausgesetzt ein Receiver ist installiert).

Nun kann die Applikation passend bedient werden. Alle Schritte, Mausklicks etc. werden aufgezeichnet – auch Passwörter.

Nach der Aufzeichnung wird die Sitzung auf normalem Weg beendet.

Hierbei ist daran zu denken, dass das spätere Skript in gleicher Weise wieder und wieder erneut durchlaufen können muss. Das Speichern einer simplen Datei wird also später die Frage im Skript aufwerfen, ob die Datei überschrieben werden darf. Zur Erinnerung: Das Skript kann diese Entscheidung nicht treffen – lediglich das Aufgezeichnete kann erneut abgearbeitet werden.

Wenn das Aufzeichnen des Skripts beendet ist, sind die einzelnen Aktionen im Controller-Programm unterhalb des Instructions-Knoten aufgeführt.

Zum Strukturieren der Aufzeichnung – und um eine bestimmte Sequenz zeitlich erfassbar zu machen, wird ein Ordner (“Folder”) benötigt. Dieser wird einfach mit einem Rechtsklick oberhalb des angeklickten Objekts erstellt.

In den neu erstellten Ordner können nun markierte Zeilen aus dem Skript verschoben werden (Achtung, ein Verschieben innerhalb eines Fensters kann ggf. nur eine Umsortierung der aufgezeichneten Schritte bedeuten! Haben wir schon über das Speichern geredet?)
Besser ist hier allemal ein Verschieben über die Fenstergrenze von rechts nach links.

Der Ordner wird im Folgenden in einen “Monitoring Point” gewandelt – nur diese Monitoring Points sind später aus EdgeSight for XenApp bezüglich ihrer Durchlaufdauer erfassbar.

Hierzu bekommt der Monitoring Point einen Namen. Dieser sollte später inklusive des führenden Backslashes in EdgeSight for XenApp hinterlegt werden.

Kapitel 4: Einrichten der Alarmmeldung in EdgeSight for XenApp

Unter Configure/Rules/New Alert Rule kann nun eine neue Alarmmeldung erzeugt werden.

Als Typ für den Alarm ist “XenApp Performance Alert” auszuwählen.

Die Unterrubrik für diese Demo ist “Application Response Time” – falls ein Test komplett fehlschlägt, also abbricht oder nicht einmal gestartet werden kann, ist “Application Response Failure” zu wählen.

Neben einem Namen ist hier vor allem der “Test name” und der Monitoring Point anzugeben. Der Monitoring Point entspricht dem zuvor angelegten “Ordner”  - allerdings mit dem führenden Backslash! Der “Test Name” ist der Dateiname, unter dem der komplette Test inklusive Skript (erstellt in Kapitel 1) angelegt und gespeichert wurde. “Script name” entspricht dem Namen des Skripts.
Ich habe in diesem Beispiel die Durchlaufzeit auf unrealistische zwei Sekunden gestellt, so dass die Ausführung des Skripts auf alle Fälle einen Alarm provoziert. In der Praxis ist hier der maximale (unter normaler Last) ermittelte / erwünschte Wert für eine solche Sequenz einzutragen. Sind auf unbelasteten Servern also 10 Sekunden normal, auf belasteten Servern 15 Sekunden der Mittelwert und ist 30 ein Wert, der nicht tragbar ist, sollte der Alarm auf 28 oder 30 Sekunden eingestellt werden.

Durch einen Klick auf Next erscheint der nächste Dialog, der für Dokumentationszwecke die Einstellungen zusammenfasst.

Die Einrichtung des Alarms ist hiermit eigentlich beendet – allerdings fehlt noch die Zuordnung zu einem Department, um die darin beheimateten XenApp Server auf den neuen meldepflichtigen Alarm hinzuweisen.

Um nicht bis zum nächsten Lauf der Konfigurationsprüfung warten zu müssen, kann unter Configure/Agents/Run Worker der (oder die) XenApp Server ausgewählt werden (Punkt 1 und 2), die den “Configuration Check”-Worker außerplanmäßig ausführen sollen (Punkt 3 und 4).

Wenige Minuten, nachdem der Test auf dem Controller gestartet wurde – und abhängig vom eingestellten Intervall des Tests, erscheint die erste Alarmmeldung in der EdgeSight for XenApp WebConsole, wahlweise unter Monitor/Farm Monitor oder…

…unter Alert list (ohne Flash). Durch Binden einer Aktion an die Alert Rule eines Departments könnte EdgeSight auch eine EMail oder einen SNMP-Trap senden, oder wahlweise auch ein Skript/Exe-Datei ausführen.


Have fun!