Pourquoi utiliser les stratégies d’équilibrage de charge dans un environnement Citrix XenApp ou XenDesktop ?

  • La valeur ajoutée d’une stratégie d’équilibrage de charge est maximum dans le cas d’un environnement Citrix déployé sur plusieurs centres de données avec une bande passante inégale entre l’utilisateur et ceux-ci.

Le but ici est de forcer un groupe d’utilisateurs à se connecter sur un site A en priorité mais que le site B soit disponible en cas de panne ou maintenance du site A.
Un autre groupe d’utilisateurs se connecte en priorité sur le site B, avec un retour sur le site A si nécessaire.

  • On peut aussi utiliser ces stratégies dans le cas de la création d’une infrastructure Active-Passive.
  • Ou alors lors de la création d’un environnement multi-silos ou les applications sont déployées sur plusieurs silos et on souhaite prioriser l’ordre de connexion aux silos.

Configuration sous Citrix XenApp 6.5

La configuration de ces stratégies entre un environnement XenApp 6.5 et XenApp 7.x est radicalement différent. Cet article a pour but de montrer comment reproduire sous XenApp 7, les stratégies que l’on pouvait appliquer en 6.5.
Pour créer une nouvelle stratégie d’équilibrage de charge en XenApp 6.5, cela se fait depuis la console AppCenter

1

Donner un nom à votre stratégie

2

Il vous faut ensuite définir les filtres, c’est-à-dire, à quel moment ou à quels utilisateurs souhaitez-vous que cette stratégie s’applique.
Il existe 4 types de filtres :

– Type d’accès

Vous pouvez distinguer les utilisateurs qui se connectent directement sur la Web Interface/Storefront des utilisateurs qui passent par une Citrix Access Gateway.
Il est possible d’aller plus loin et de passer des filtres afin de distinguer vos Citrix Access Gateway. Par exemple, connecter l’utilisateur dans l’environnement Citrix qui se trouve dans le même centre de données que l’Access Gateway qui a répondu.

– Adresse IP cliente

Le filtre peut être basé sur l’adresse IP du client.
Vous pouvez spécifier une adresse ou alors une plage d’adresse, afin que celle-ci soit prise en compte (correspondre) ou alors soit ignorer (ignorer) de la stratégie.

3

– Nom du client

Vous pouvez vous baser sur les noms de machines clientes.

4

– Utilisateurs

Ou finalement par utilisateur ou groupe d’utilisateurs

5

Une fois les filtres choisis, il ne reste plus qu’à configurer les stratégies d’équilibrage de charge.
Placer les Groupes de tâches correspondant et assigner les priorités désirées.

6

Déploiement d’applications sous Citrix XenApp 6.5

Pour que tout ceci fonctionne, il faut bien sûr qu’une même application soit disponible sur nos différents groupes de tâches.
Tout simplement publier la même application dans AppCenter sur les différents groupes de tâches.

7

Reproduire les stratégies sous Citrix XenApp 7.x

Vous ne trouverez pas dans la console Citrix Studio d’interface ou d’options permettant de reproduire en quelques clics la même configuration que sous XenApp 6.5
La partie de configuration d’équilibrage de charge que l’on pouvait trouver au niveau de la console de management Citrix AppCenter en 6.5 est maintenant en partie déporter dans Storefront et en partie sur les Contrôleurs des sites XenApp 7.x

Configurer l’équilibrage de charge, basculement, la reprise après sinistre, et le mappage d’utilisateurs pour un magasin

On reprend notre scénario de XenApp 6.5 avec un site A et un site B.

8

Les utilisateurs se connectent aux Netscaler le plus proche, on utilise le GSLB afin de réaliser ceci.
Les serveurs Storefront qui lui sont retournés sont alors les serveurs se trouvant sur le même site mais les serveurs du second site sont aussi disponibles avec une priorité inférieure en cas de panne ou maintenance sur le premier site.
C’est au niveau de la configuration des Storefront que nous allons définir aux utiliser ou ils doivent se connecter et ouvrir leur session.
On peut soit configurer un seul groupe de serveur Storefront avec des Magasins différents pour nos 2 sites ou alors chaque site à un groupe de serveur indépendant.
Au niveau de la déclaration des contrôleurs dans les Magasins Storefront, il faut alors déclarer les serveurs du Site A mais aussi du Site B.

9

Il ne nous reste plus qu’à définir qui va se connecter ou est quand.
Pour cela, on va aller modifier le fichier web.config de notre Magasin Storefront.
Chercher dans le fichier la partie

Code 1

Définir la configuration souhaitée

Code 2

Source : Citrix eDocs http://support.citrix.com/proddocs/topic/dws-storefront-26/nl/fr/dws-configure-ha-lb.html?locale=fr

Dans le cas de notre configuration sur 2 Sites A et B, on retrouvera la même configuration sur nos Storefront, que l’on ait 1 ou 2 groupes de serveurs :

Code 3

Il est très important de configurer correctement nos applications afin que les utilisateurs n’énumèrent pas la même application 2 fois. C’est ici que rentre en jeu l’agrégation que l’on a défini précédent dans notre configuration mais aussi la publication de nos applications au niveau de Citrix Studio.

Le nom publié à nos utilisateurs doit être identique sur tous nos Sites.
L’utilisateur se connectera à l’application selon les règles définis par Storefront.

10

Configurer les stratégies de balance de charge au niveau des applications.

Il est possible de publier les applications sur plusieurs Groupes de mise à disposition en même temps.
Vous pouvez forcer une application à ouvrir en priorité sur certaines machines en respectant un ordre défini.

La première étape consiste à publier une application depuis la console Citrix Studio sur le Groupe qui sera prioritaire de préférence.

11

Par défaut, une application créée depuis la console Studio a une priorité de 0, la plus forte.
Afin de publier cette application sur un autre groupe de mise à disposition, on va devoir faire cela avec PowerShell.
Ouvrir PowerShell sur un des contrôleurs XenApp et charger les outils XenApp :

12

Lancer ensuite la commande ci-dessous qui vous permettra de publier cette même application sur le Groupe de mise à disposition 2

13

Le groupe 1 à une priorité de 0, et maintenant notre groupe 2 est le suivant à une priorité de 1.
Ceci peut être intéressant lors de la création par exemple d’un environnement Développement, Pré Production et Production.
Si l’on se rend dans la console Citrix Studio, on peut voir que l’application est membres de plusieurs groupes à la fois mais on n’a pas plus d’informations.

14

On va donc continuer d’utiliser PowerShell afin de vérifier les paramètres de priorité.

15

Au niveau des Bureaux publiés, les stratégies restent celles vues précédemment dans Storefront.
Si vous n’avez pas de stratégies au niveau de Storefront et que vous priorisez les applications, cela ne s’appliquera pas sur les Bureaux.
Lors de l’énumération, les noms des Bureaux ne sont pas agrégés et les utilisateurs se retrouvent avec 2 Bureaux qui ont même nom sans savoir lequel est le bon. Il faut alors trouver une convention de nom et en informer les utilisateurs.

16

Il est recommandé de passer le correctif DStudio760WX64001 http://support.citrix.com/article/CTX141745 afin de régler un problème avec les priorités qui peuvent être perdues lors de modification depuis Citrix Studio.

Stratégies d’accès au niveau des Groupes de mise à disposition

Il est toujours possible de spécifier dans les groupes de mise à disposition des stratégies d’accès au niveau de la connexion LAN, Netscaler Gateway comme on pouvait le faire en XenApp 6.5

17

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s