Editions ENI Livres | Vidéos | e-Formations
Implémentation de la haute disponibilité
Introduction
Les services AD LDS ont permis aux entreprises d’implémenter facilement et rapidement des annuaires LDAP qui reposent sur les mêmes fondamentaux que l’Active Directory sans encourir de risques de corruption du schéma.
Au fur et à mesure que les usages AD LDS se généralisent, la demande pour faire évoluer leur implémentation et garantir des niveaux de disponibilité plus élevés augmente. Le code source de l’AD LDS est identique à celui de l’AD DS. Les deux disposent du même moteur de réplication et donc des mêmes caractéristiques de performance, sauf que les mécanismes de haute disponibilité sont différents.
Dans un environnement Active Directory, les opérations d’équilibrage de charge se déroulent en arrière-plan, grâce au processus de découverte automatique, qui permet de localiser les contrôleurs de domaine. Ce n’est pas le cas pour les services AD LDS.
AD LDS n’est pas à l’abri d’une interruption de service, il est donc important d’étudier l’intégration de cette solution à une topologie adaptée au service qui doit être rendu. Pour ce faire, Microsoft propose NLB (Network Load Balancing), qui permet d’accroître la disponibilité...
Les risques d’une architecture centralisée
Aujourd’hui, les entreprises sont confrontées à de nouveaux challenges dans la gestion de leurs systèmes informatiques. Les utilisateurs sont de plus en plus exigeants, ils s’attendent à ce que les services soient toujours disponibles et surtout plus performants.
Cependant, il peut arriver que ces services s’interrompent de temps à autre, mais cela ne devra porter atteinte ni au système d’information ni à l’activité de l’entreprise.
Une infrastructure qui repose sur une architecture centralisée paraissait peut-être une bonne idée à l’époque - n’avoir en général à maintenir qu’un seul système facilitait le travail des administrateurs lors du déploiement et de l’administration des applications.
À l’heure actuelle, ce type d’infrastructure soulève plusieurs difficultés.
Tout d’abord, avoir un point unique de défaillance (SPOF - Single Point Of Failure) présente un risque potentiel pour les organisations. Si le serveur central tombe en panne, les services qui lui sont associés ne peuvent plus traiter les demandes des utilisateurs.
Deuxièmement, étant donné que toutes les applications sont gérées par un seul serveur, la scalabilité reste...
La haute disponibilité de l’annuaire AD LDS
Le fait de configurer deux serveurs AD LDS en réplication "jeu de configuration" permet d’assurer la redondance de l’instance et des données de l’annuaire. Cependant, le serveur AD LDS ne dispose d’aucune fonction de redirection du service LDAP si un des deux annuaires tombe ou devient défaillant.
Il convient donc de déléguer la vérification de l’état de santé du serveur AD LDS à l’agent (ou utilisateur) ou bien à un équipement réseau entre le serveur AD LDS et ses utilisateurs. Ce scénario est illustré à la figure suivante, où l’utilisateur se trouve dans l’incapacité de communiquer avec le serveur SRV-LDS01.
1. Configuration de plusieurs serveurs AD LDS
Pour régler le problème de l’exemple précèdent, nous pouvons spécifier l’existence d’un serveur redondant aux clients AD LDS. Par exemple, les applications ayant une adhérence avec l’annuaire AD LDS permettent la configuration de plusieurs services d’annuaire dans leurs fichiers de configuration. De ce fait, si l’utilisateur n’arrive plus à accéder à son serveur, il contactera (après plusieurs tentatives) le deuxième...
L’équilibrage de charge
L’équilibrage de charge est une méthode permettant d’améliorer la disponibilité et les performances des applications. Elle vise à répartir le traitement et le trafic de manière égale sur plusieurs serveurs d’un groupe, en veillant à ce qu’aucun d’entre eux ne soit submergé. Cette méthode est employée dans plusieurs domaines, en particulier avec les serveurs web frontaux qui interceptent les requêtes http émises par les utilisateurs et qui nécessitent de la persistance ou du traitement.
Les solutions d’équilibrage de charge peuvent agir soit au niveau de la couche transport (TCP/IP), soit au niveau de la couche 7 du modèle OSI (http, ldap, smtp) :
-
Les équilibreurs de charge en couche 4 sont génériques, indépendants de l’application ou du protocole utilisé. L’application ne communique pas directement avec la solution d’équilibrage de charge et le composant d’équilibrage de charge ne connaît pas l’application dont il assure la disponibilité.
-
Les équilibreurs de charge en couche 7 fournissent une répartition de charge avec un contrôle plus avancé du protocole applicatif. Si le service répond, mais de manière dégradée, un autre serveur prend en charge automatiquement et sans délai la charge de travail de ce serveur défaillant.
1. Algorithme d’équilibrage de charge
Parmi les algorithmes d’équilibrage de charge les plus couramment utilisés, nous trouvons, par exemple :
-
Round Robin : le Round Robin est le mécanisme de répartition de charge le plus simple à utiliser pour la distribution du trafic. Une rotation circulaire permet de choisir parmi un ensemble de serveurs celui qui va traiter la requête de l’utilisateur. De cette façon, l’ordre dans lequel ces serveurs sont contactés est modifié d’une requête à l’autre.
L’algorithme Round Robin traite toutes les requêtes de la même manière, indépendamment de leur urgence ou de la charge qu’elles peuvent entraîner sur le serveur. Ainsi, une solution d’équilibrage...
La fonctionnalité NLB de Windows Server
1. Présentation
Présent dans toutes les versions de Windows Server, NLB est une fonctionnalité qui permet la mise en place de la répartition de charge réseau sur plusieurs hôtes, améliorant ainsi considérablement l’accès au serveur. Il permet également une haute disponibilité des services car ce répartiteur de charge qui repose sur la couche 4 du modèle OSI agit sur les paquets IP transmis et distribue le trafic sur de multiples hôtes en fonction de l’algorithme d’équilibrage de charge choisi.
Le service NLB peut s’exécuter sur un serveur physique ou virtuel et permet d’intégrer jusqu’à 32 nœuds au sein d’un même cluster. L’ensemble de ces nœuds peuvent répondre simultanément aux requêtes des utilisateurs. Lors de la mise en place d’un cluster NLB, une interface réseau virtuelle dédiée ainsi qu’une adresse réseau virtuelle sont créées. Cette interface réseau dédiée dispose d’une adresse IP ainsi que d’une adresse MAC.
Par défaut, la répartition de charge est égale entre les nœuds du cluster. Ainsi, chaque nœud dispose de la même capacité de traitement des demandes provenant des clients. Lorsqu’une demande d’accès est reçue, le NLB envoie cette dernière au nœud le moins sollicité.
Le cluster NLB fonctionne parfaitement pour les applications sans état (stateless) telles que les services web frontaux. À l’inverse, il n’est pas possible d’utiliser cette fonctionnalité pour les applications avec état (stateful), comme un serveur de base de données ou un serveur de fichiers. En fait, cela est dû au mode de connexion : ces types d’application nécessitent obligatoirement une connexion au même hôte.
Lorsqu’un utilisateur souhaite accéder à l’application, il utilise l’adresse du cluster. L’ensemble des hôtes reçoivent la demande d’accès, mais un seul parmi eux accepte la requête adressée à l’application. Celui-ci est déterminé...
La mise en place d’un NLB
L’infrastructure NLB nécessite l’utilisation des deux serveurs SRV-LDS01 et SRV-LDS02, hébergeant chacun une copie de l’instance AD LDS LABO. Les deux serveurs sont membres du domaine editions-eni.local.
Comme nous l’avons précédemment indiqué, deux adaptateurs réseau sont fortement recommandés sur chaque hôte afin de pouvoir isoler le trafic spécifique au cluster de celui destiné aux clients. Dans ce scénario, les cartes associées aux deux types de trafic doivent être configurées sur deux réseaux différents, comme illustré sur la figure suivante.
1. Installer la fonctionnalité NLB
Ouvrez une session sur le serveur SRV-LDS01 puis lancez le Gestionnaire de serveur à partir de la barre des tâches.
Cliquez sur le menu Gérer puis sur Ajouter des rôles et fonctionnalités.
Dans la page Avant de commencer, cliquez sur le bouton Suivant.
Dans la page Type d’installation, cliquez sur Installation basée sur un rôle ou une fonctionnalité puis cliquez sur Suivant.
Dans la fenêtre Sélection du serveur, sélectionnez votre serveur dans la liste Pool de serveurs puis cliquez sur Suivant.
Dans la page Rôles de serveurs cliquez sur Suivant.
Dans la page Sélectionner des fonctionnalités, cochez la case Équilibrage de la charge réseau, puis cliquez sur Ajouter des fonctionnalités sur la fenêtre qui s’ouvre. Cliquez ensuite sur Suivant.
Dans la fenêtre Confirmez les sélections d’installation, cliquez sur Installer.
Lorsque l’installation des composants est terminée, cliquez sur Fermer.
La console d’administration...
Conclusion
Au cours de ce chapitre, plusieurs aspects ont été abordés pour permettre de comprendre la haute disponibilité. Il faut cependant garder à l’esprit que la haute disponibilité est un élément clé dans une entreprise. Elle nécessite toute une panoplie de techniques et d’outils pour être réellement efficace.
Dans de nombreux scénarios de déploiement des services AD LDS, il est nécessaire de prévoir une solution de haute disponibilité en cas de panne matérielle d’un serveur. Grâce à la fonctionnalité NLB de Windows Server, il est possible de rendre l’accès à l’annuaire AD LDS hautement disponible à travers la mise en œuvre d’un cluster de répartition de charge. Ceci permettra ainsi d’apporter aux utilisateurs un service continu et de garantir une qualité de service optimale quelle que soit la charge.