Concept et architecture 

  • Nous parlerons de ferme TSE pour désigner le regroupement des serveurs TSE.
  • Grâce au service Network Load Balancing, cette ferme sera identifiée sur le réseau par une adresse IP et un nom virtuel.
  • Afin d’optimiser les performances, le trafic réseaux des clients sera séparé de celui pour l’accès aux ressources et à l’infrastructure générale.
  • Le service Session Directory sera utilisé pour permettre à un utilisateur de retrouver sa session sur le bon serveur en cas de déconnexion réseau.

Prés-requis logiciels

Terminal Serveur :Au moins deux Windows Serveur 2003 Entreprise Edition ou Datacenter Edition avec le service Terminal Serveur installé. La version Standard édition est néanmoins utilisable mais le service Session Directory ne sera pas disponible (une solution de remplacement basée sur la configuration du NLB sera proposée dans cet article).

Les serveurs Terminal Server auront la même configuration logicielle. L’utilisation des profils itinérants Terminal Server est vivement recommandée.

Session Directory:

Session Directory est disponible a partir de Windows Serveur 2003 Standard Edition. Néanmoins en cas de mise en cluster MSCS du service, la version Windows Serveur 2003 Entreprise Edition ou Datacenter Edition est nécessaire.

Considérations matérielles 

Dans un environnement de production une telle configuration logicielle serait inutile sans une configuration matérielle adéquate. Le choix et surtout la stratégie quand au matériel utilisé est primordiale, le but étant d’éviter les points uniques de défaillance . Pour cela tous les composants critiques doivent être redondants :

  • Blocs d’alimentation redondants et connexions d’onduleurs redondants à partir d’alimentations électriques séparés.
  • Réseau redondant avec utilisation de commutateurs supportant le Spanning Tree
  • Les serveurs stratégiques de l’infrastructure seront éventuellement en cluster.
  • Multipathing (« plusieurs chemins ») des serveurs de l’infrastructure au système de stockage (pour compenser un défaut d’un contrôleur unique)

Ce dernier point est essentiel, le stockage sera de préférence virtualisé et en réseau. Il existe depuis peu des solutions permettant de faire du SAN à moindre coût sur des plateformes X86, pourquoi s’en priver ! Cette liste concernant le matériel n’est pas exhaustive, la redondance est une question de compromis. Il faut éviter des aberrations comme alimenter vos clusters sans onduleurs distincts ou redondant. Cela dépasse la portée de ce projet, néanmoins il est impératif d’étudier l’infrastructure dans son ensemble et l’ensemble des scénarios.

Installation et test de fonctionnement

2.1 Configuration des interfaces réseau

Il convient d’utiliser deux interfaces réseaux physiques, une pour le Front End network et une pour le Back End.Cette configuration devra être commune à tous les noeuds du cluster

Configuration TCP/IP de l’interface Front-End Network

  • Adresse IP : On notera ici l’adresse IP du cluster et non pas l’adresse IP de la machine physique.
  • Masque de sous-réseau : Masque de sous réseaux du cluster.
  • Paramètres avancés : L’adresse IP de la machine physique (ici 192.168.0.16) sera configurée en cliquant sur « Avancé… ». Elle devra apparaître en deuxième position, sous l’adresse IP du cluster et sera bien sûr unique dans le sous réseaux.

Configuration TCP/IP de l’interface Back-End Network

Aucune difficulté pour la configuration de cette interface qui va permettre la communication avec le réseau d’infrastructure.Ici l’adresse IP de l’interface est 192.168.0.100. Elle devra être différente pour chaque nœud du cluster.

2.2 Configuration du service Network Load Balancing

Le service NLB est déjà installé, il suffit de l’activer dans les propriétés de l’interface Front-End Network.

Onglet paramètres du cluster 

  • Adresse IP : Adresse IP virtuelle du cluster ici 192.168.0.20
  • Masque réseau : Masque de l’adresse IP virtuelle du cluster
  • Nom internet complet : Nom DNS virtuel du cluster. Il semblerait que l’enregistrement dans le serveur DNS ne soit pas dynamique. Il faut donc créer à la main cet enregistrement sur le serveur DNS faisant autorité dans votre réseau.
  • Mode d’opération du cluster : Nous possédons deux carte réseaux sur nos serveurs, nous utiliserons donc le mode Monodiffusion. Les cartes réseaux du Front-End Network seront identifiées par une seule adresse MAC virtuelle. La communication entre les nœuds se fera par les interfaces Back-end network
  • Le mode Multidiffusion permet la communication des nœuds avec une seule carte réseau. Cependant, cela peut poser problème avec les switch et routeurs (rejet des requêtes ARP) car les interfaces physique possèderons deux adresses MAC, une physique et une virtuelle.

Onglet paramètre de l’hôte

  • Priorité: Identifiant unique des nœuds du cluster. Ici 1 pour le premier nœud, 2 pour le second,ect….
  • Adresse IP: Adresse IP physique de l’interface Front-End du nœud. Elle devra être différente pour chaque nœud du cluster.
  • Maque de sous réseau: Masque de l’IP physique le l’interface Front-End du nœud.

Onglet régles de port.

L’utilisation de deux cartes réseaux nous permet dédier une interface (Front-end) au trafic réseau TSE. Cela garantie le bon fonctionnement et surtout la pertinence du load balancer. Seul le protocole RPD (Port 3389 en TCP) sera autorisé, le reste sera rejeté. Nous devons donc configurer 3 règles de port.

Régle de port autorisant trafic Terminal Serveur

  • Adresse IP du cluster: ici 192.168.0.20
  • Etendu du port : 3389 en TCP, ce qui correspond à au protocole RPD.
  • Mode filtrage :Cette page de configuration doit être identique sur tous les nœuds du cluster, cela est une source courante de disfonctionnement.
    • Si vous utilisez Session Directory : Dans le cas de l’utilisation du service Session Directory, on configurera le mode de filtrage avec aucune affinité et un poids de charge égal entre les nœuds.
    • Si vous n’utilisez pas le service Session Directory: Le réglage de l’affinité sur Unique permet de déterminer si les requêtes d’un client continueront d’être routées sur un serveur spécifique (en cas de déconnexion par exemple). Ce routage est basé sur l’adresse IP. Ce mode de configuration est indispensable si on n’utilise pas Session Directory (qui est basé sur la session).

Régles refusant de tout autre trafic réseau

Pour refuser tout autre trafic il suffit de désactiver tout les autres ports pour les protocoles TCP et UDP. On créra pour cela deux autre régles de ports, l’une désactivant les ports de 0 à 3388 et l’autre de 3390 à 65535.

2.2 Configuration du service Terminal Serveur

Il convient juste de sélectionner l’interface utilisée par les client pour se connecter au Terminal Serveur du protocole RDP des serveurs Terminal Server

  • 1. Ouvrir la console MMC Configuration des services Terminal Server\connexions.
  • 2. Clic droit sur RPD-Tcp
  • 3. Sélectionner l’onglet carte réseaux
  • 4. Sélectionner la carte destinée à recevoir les connexions des clients TSE (Front-End Network)

2.3 Test de fonctionnement du NLB

Taper à l’invite de commande nlb –dispaly all sur tous les nœuds du cluster.

Vous y trouverez les log ainsi que le statuts de chaque nœud.

Ici le nœud 1 a convergé en tant que hôte par défaut du cluster alors que le nœud 2 est un simple membre du cluster. Si les deux nœuds avaient convergé comme hôte par défaut, cela aurait indiqué un problème de communication entre les nœuds.

Vous pouvez maintenant tester les connexions RPD avec le cluster et vérifier la répartition des sessions sur l’ensemble des nœuds. Ne pas hésiter à ouvrir au moins 8 sessions.

2.4 En cas de problème

Voici quelques pistes à suivre en cas de problème:

  • Test de communication entre les nœuds via la commande ping.
  • Utilisation de la commande netstat –am pour vérifier que le port 3389 est en écoute sur l’adresse IP du cluster.
  • Ici, 192.168.0.20 est l’adresse IP virtuelle du cluster.

    Ci ce n’est pas le cas, il faut vérifier que l’IP du cluster est bien en première positions dans les paramètre TCP/Ip avancés.

  • Utilisation de la commande nlb display all pour vérifier les logs du cluster.
  • Un petit coup d’ethereal pour valider les signaux heartbeat entre les nœuds.
  • Session Directory. 

    Session directory est un petit service consommant très peu de ressource. Il va permettre d’indexer les sessions par rapport aux utilisateurs. L’utilisateur pourra ainsi retrouver sa session sur le bon serveur de la ferme après une éventuelle déconnexion. La disponibilité du service Session Directory doit être optimale. Nous proposerons ici une installation en cluster MSCS.

    Lors du démarrage du service, Session Directory va créer un groupe local à la machine. Il est donc vivement recommandé de ne pas installer Session Directory sur un contrôleur de domaine car un groupe de domaine sera alors créé.

    Session Directory fonctionne sur toute la gamme 2003 serveur, néanmoins les TSE désirants l’utiliser doivent être sous 2003 Serveur Entreprise ou Datacenter Edition.

    3.1 Installation de Session Directory

    Session Directory est déjà installé, il suffit juste de l’activer dans la gestion des services.

    3.2 Mise en cluster MSCS du service Session Directory

    Nous ne détaillerons pas ici l’installation du service cluster MSCS mais uniquement de la création de la ressource Session Directory.

    Pour fonctionner en cluster, le service Session Directory nécessite la création d’une ressource de service générique.

  • Création d’une ressource générique.

  • Choix des dépendances.

  • Le service Session Directory sera dépendant des ressources suivantes : -Un disque du cluster-Nom réseau du cluster

  • Nom du service.

  • Entrez le nom du service (TSSDIS) et cochez ‘Utiliser le nom réseau pour le nom d’ordinateur’.

  • Ajout d’une clef de registre.

  • Entrer la clef System\CurrentControlSet\Services\Tssdis\Parameters nécessaire au bon fonctionnement du service en cluster.

    3.3 Installation et configuration de session Directory

  • 1.Installation de Session Directory.

  • Session Directory est déjà installé, il suffit juste de l’activer dans la gestion des services.

  • Ajout des ordinateurs de la ferme Terminal Seveur dans le groupe Ordinateurs annuaire de sessions.

  • Une fois démarré, le service va créer un groupe ‘Ordinateurs annuaire de sessions’ Ce groupe devra contenir les Terminal Serveur de votre ferme.

  • Création d’une GPO pour utiliser Session Directory.

  • Pour appliquer Session Directory, il convient de créer un GPO pour votre ferme de serveur TSE, le mieux étant de placer les serveurs TSE dans une OU et de lier la GPO à cette OU.

  • Configurer la GPO pour utiliser Session Directory.

  • Déployer Configuration Ordinateur/Modèle d’administration/Windows Components/Terminal Services/Session Directory

  • Join Session Directory : Enable
  • Session Directory Server : Enable
  • Addresse Ip du serveur hébergeant le service Session Directory (ici 192.168.0.15)
  • Session Directory Cluster Name : Enable
  • Nom réseau virtuel du cluster (ici tse.secur33.lan)
  • Test du système

  • 1. Simuler une panne sur le premier Terminal Server (désactivation de l’interface réseau Front-End).
  • 2. Ouvrer une dizaine de sessions. Elles vont se répartir sur le ou les Terminal Server restant.
  • 3. Déconnecter (sans fermer sa session) un utilisateur précis du Terminal Server grâce au gestionnaire des taches. Toto par exemple.
  • 4. Réactiver l’interface une premier Terminal Server.
  • 5. Ouvrer une session d’un utilisateur lambda. Cette session va aller sur le premier Terminal Server car il n’y a aucune de session ouverte dessus.
  • 6. Fermer la session de cet utilisateur
  • 7. Reconnecter l’utilisateur Toto via un client RDP.
  • 8. La session de Toto ne doit pas se créer sur le premier Terminal Server pourtant vide d’utilisateur mais doit reprendre celle crée précédemment..
  • Conclusion

    Nous avons vu ici comment créer une infrastructure Terminal Serveur haute disponibilité.

    Microsoft nous propose en natif sur la gamme 2003 Serveur un Load Balancer simple et efficace. Il ne comporte néanmoins pas les fonctionnalités avancées de ces concurrents qui, en plus de la charge réseau peuvent prendre en compte divers paramètres comme la charge CPU des serveurs. Ces solutions restent cependant très onéreuses et pas forcément justifiées.