Bonjour,
Voici donc comme promis le retour d’expérience sur la mise en place des virtual IP avec XenApp 6.0…
Certaines applications nécessitent une IP unique par instance. Dans un environnement
XenApp, c’est donc l’IP du serveur qui est retournée lors d’un appel aux APIs
Winsock : problématique avec ce genre d’applications!
Les IP virtuelles ont été introduites dans CPS4.0 et Microsoft l’a implémenté dans
Windows 2008 R2. Donc, depuis XenApp 6.0, il faut au minimum configurer les IP
virtuelles via RDS (GPO etc) et activer les stratégies XenApp idoines si l’on
souhaite davantage de fonctionnalités (VIP en loopback etc).
Voila pour la théorie… avec des vrais gens, dans un vrai environnement,
c’est évident que les choses se compliquent comme pour nous dans le cas de
l’utilisation des VIP… Ici, nous avions besoin d’une VIP pour
Internet Explorer 8.0. Les décisions suivantes ont donc été faites :
DHCP pour fournir une VIP sur le subnet des serveurs XenApp, attribution des VIP par
programme (via GPO), configuration des stratégies Citrix idoines.
Problèmes rencontrés (et leurs solutions!!) :
1. VIP et VMWare vSphere:
Les serveurs XenApp étaient sous VMWare vSphere 4. dans ce cas (voir
http://communities.vmware.com/thread/255821?start=15&tstart=0), il faut
désinstaller le pilote VMCI des VMWare tools et désactiver IPv6 avec la clef
HKLM\CurrentControlSet\services\TCPIP6\Parameters\DisabledComponents DWORD
0xFFFFFFFF
Pour info, il n’est pas indispensable d’être en VMXNet3, ça marche très
bien en E1000.
Note: cela fonctionne du premier coup avec XenServer …
2. Tables ARP des routeurs
chose que nous avons découverte, c’est que le DHCP qui fourni les VIP utilise
une MAC unique bien à lui pour chaque VIP, en ajoutant un nombre au début et à la
fin de la MAC de la carte du serveur XenApp. Résultat? les tables ARP des routeurs
ne se mettent pas à jour assez vite pour que les VIP soient joignables (in/out du
serveur)… effectivement, avec disons 10 sessions ouvertes et fermées cela
suffisait pour perdre les VIP.
La solution? utilisation d’une plage de VIP par serveur au travers du registre
(et donc suppression du DHCP) :
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server\TSAppSrv\VirtualIP]
“EnableVirtualIP”=dword:00000001
“ComponentDLL”=”%SystemRoot%\\system32\\TSVIPSrv.dll”
“VirtualMode”=dword:00000000
“AdapterAddress”=”00-13-21-09-DD-AE”
“IPPool”=”%SystemRoot%\\system32\\TSVIPool.dll”
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server\TSAppSrv\VirtualIP\IPPool]
“Start”=”10.10.62.1”
“End”=”10.10.62.20”
“SubnetMask”=”255.248.0.0”
3. perte des VIP…
suite au problème 2, les IP ont été renseignées via le registre. nous avons donc un
mix registre et GPO pour la configuration des VIP et plus de DHCP. Aléatoirement,
les VIP disparaissaient sur les serveurs XenApp et n’importe quand dans la
journée, sur un ou plusieurs serveurs.. Merci qui? merci le refresh automatique de
GPO qui met donc à jour la GPO et le mécanisme de VIP se rafraichit (clairement
visible dans l’event viewer dédié aux VIP Applications and Services
Logs\Microsoft\Windows\TerminalServices-TSAppSrv-T SVIP\Admin). Sans DHCP, pas de
nouvelles requêtes de VIP : si celles-ci sont allouées via le registre, alors cette
allocation est faite une fois pour toutes au logon..
Solution: pas de configuration par GPO.. tout dans le registre ! pas pratique, il va
y avoir du script.. même avec PVS (la cible chez ce client) car la plage de VIP est
définie dans le registre.. et qui dit PVS dit.. registre identique pour tous les
XenApp..
Bref, 3 problèmes que nous avons rencontré et corrigés, qui nous ont pris du temps (beaucoup) et pas mal de sueurs froides. Il me semblait important de faire partager cette aventure car il y a un criant manque d’information sur la gestion des VIP sous RDS pour le moment..
Last but not least, un GRAND merci et un grand bravo à Nicolas H. et Nicolas D. qui se reconnaitront : nos cerveaux ont bien chauffé pour trouver tout cela…
edit: disponible en anglais sur http://blogs.citrix.com/2012/01/03/xenapp-virtualip-rds/
ThinIsFat