Cet article a pour but de traiter d'une question que se posent tous les administrateurs d'environnements XenApp, à savoir : "Comment isoler un serveur XenApp de la production".
Cette isolation peut avoir pour raison une déficience du serveur ou tout simplement la nécessité d'effectuer des opérations de maintenance (mises à jour systèmes ou applicatives) sur celui-ci.
Dans le cadre de ce type d'opérations, plusieurs solutions sont à la disposition des Administrateurs XenApp :
Désactiver les Ouvertures de Session sur le (les) Serveurs(s) concerné(s)
Cette action, effectuée soit via l'Access Management Console (AMC) soit via la ligne de commande "change logon /disable" permet d'interdire toute nouvelle ouverture de session sur le serveur.
Depuis Windows 2003 (et Presentation Server 3.0 pour Windows 2003), cette méthode est persistante même en cas de redémarrage du serveur.
Elle a pour inconvénient majeur de bloquer toute tentative d'ouverture de session en Terminal Server (mode Console y-compris) ce qui peut être très pénalisant, notamment quand les serveurs se trouvent dans un DataCenter externe.
De plus, ce paramètre ce gère dans la console au niveau de chaque Serveur, et il peut rapidement devenir fastidieux de gèrer ce paramètre pour un sous-ensemble important de machines.
Dans ce cas, l'utilisation de scripts appelant MFCOM ou d'outils Tiers, type XenApp Servers Logon Manager devient rapidement indispensable.
Windows 2008 propose une variante plus souple de la désactivation des ouvertures de session appelée le mode de "Vidage" (ou "Drain Mode" en anglais).
Dans ce cas, les administrateurs peuvent toujours se connecter et les utilisateurs déjà connectés ont également la possibilité de se reconnecter.
Pour plus d'informations sur ce mode, je vous renvoie vers l'article de Laurent Falguiere traitant de ce sujet.
Isoler le (les) Serveurs(s) concerné(s) du système de Gestion de la Charge
Ce système, basé sur le Scripting, appelle une fonctionnalité disponible uniquement à partir de XenApp 4.5 au travers de la nouvelle interface de Management (sur laquelle repose l'AMC) appelée CPSCOM.
Via cette API, il est possible d'isoler un ou plusieurs serveurs de la table de Gestion de la Charge.
Un script PowerShell illustrant cette fonctionnalité est disponible Sur le Site de La Commauté des Développeurs Citrix.
Attention cependant car comme les précisent les commentaires présents sur la page ci-dessus, il existe encore un flou sur le support ou non de l'utilisation des APIs CPSCOM à ce jour.
Cette méthode a cependant l'avantage de ne pas bloquer les ouvertures de session RDP sur le serveur et donc par là même de permettre aux Administrateurs de se connecter tout en désactivant les connexions utilisateurs.
Elle nécessite toutefois des compétences en scripting car en dehors du fait de sortir un serveur de la table, il est ensuite nécessaire d'utiliser l'utilitaire enablelb.exe pour réintroduire le serveur dans le partage de charge et il n'existe pas d'outil de vérification graphique aisé de l'application ou non de ce script.
Il est également à noter qu'un redémarrage d'un serveur le replacera automatiquement dans la table du Système de Load Management.
A utiliser avec beaucoup de précautions donc.
-----------------------------------------------
$server = $Args[0]
$servicestatus = (Get-WmiObject -computer $server Win32_Service -Filter "name='IMAservice'").state
if ($servicestatus -eq "Running")
{
$newLM = New-Object -comobject CPSCOMInterop.CPSLoadManager.1
#remove server from LB
$returnvalue = $newLM.SetServerLMState($server,0)
}
else
{
write-host "$server's IMA service is not running, it can be moved off LB table"
}
-----------------------------------------------
Si vous préférez le scripting VBS, n'hésitez pas à consulter l'adaptation VBS de ce script par Joe Shonk
Utiliser un Calculateur de Charge de Maintenance
Il s'agit de la méthode que personnellement je préfère utiliser. Le premier Article identifié traitant du sujet que j'ai pu trouver est Cet Article de Scott Chiara sur le Site de Brian Madden.
Elle consiste à jouer sur la possibilité de créer un calculateur de charge particulier puis à l'appliquer ensuite aux serveurs concernés par les opérations de maintenance.
Pourquoi particulier ? Un calculateur de Charge XenApp est composé de règles, qui sont ensuite utilisées pour déterminer la charge du serveur.
La subtilité est ici de ne créer qu'une seule règle, basée sur le critère de planification.
A la base, cette règle permet de n'autoriser les connexions que sur certaines plages horaires ou quotidiennes.
Il est cependant possible de n'affecter aucun jour et aucune plage horaire à cette règle. De fait, celle-ci n'autorisera jamais les connexions.
Appliquer ce type de calculateur à un serveur XenApp le présentera donc vis à vis du système de Gestion de la charge comme en charge pleine n'acceptant aucune nouvelle connexion.
Cette méthode a pour avantages d'être pleinement supportée mais également de ne concerner que les ouvertures de sessions ICA et non les connexions Administrateur en RDP.
De plus, il est possible via la Console "XenApp Advanced Configuration" (ou Console Presentation Server) de visualiser rapidement les calculateurs de charge appliqués à chaque serveur.
Petit bémol cependant, depuis XenApp 4.5, l'affectation du calculateur de faisant dans l'AMC, il n'est plus possible d'affecter globalement un calculateur.
Dans ce cas, des scripts ou outils Tiers tel XenApp Load Evaluator Manager permettent d'affecter rapidement un calculateur de charge sur un ou plusieurs serveurs Xenapp.
