Introduction

Ce chapitre est dédié à la haute disponibilité. L’objectif est de parcourir les possibilités offertes en termes de haute disponibilité par Windows Server 2016. Augmenter la disponibilité des services offerts est un challenge permanent pour toutes les DSI.

Un ensemble de facteurs favorise cela :

Homogénéiser les serveurs en passant par une installation et des paramètres identiques (voir le chapitre Déploiement des serveurs et postes de travail).
Centraliser la configuration par GPO (voir le chapitre Domaine Active Directory).
Sauvegarder et maintenir à jour les serveurs (voir le chapitre Cycle de vie de votre infrastructure).
Répliquer les fichiers bureautiques (voir le chapitre Architecture distribuée d’accès aux ressources).
Doubler les services d’infrastructure réseau (contrôleurs de domaines, serveurs DNS, DHCP...).
Utiliser la version Core de Windows Server 2016 pour limiter les temps d’arrêt dus à l’installation des mises à jour de sécurité.
Virtualiser le service et héberger la machine virtuelle sur un cluster Hyper-V.

Une fois tous ces facteurs en œuvre, certains services critiques sont toujours dépendants d’un serveur unique qui tombera forcément en panne tôt ou tard, ou qu’il faudra redémarrer suite à l’installation...

Les choix d’architecture

1. Les différentes architectures

Derrière les termes de haute disponibilité se cachent deux types de solutions distinctes :

La solution de type actif/passif.
La solution de type actif/actif.

La première solution augmente la disponibilité en basculant les ressources d’un serveur à un autre en cas de problème (solution hautement disponible). La deuxième solution permet d’avoir plusieurs serveurs qui répondent aux demandes en même temps (répartition de charge) et qui peuvent tolérer la perte d’un membre (solution hautement disponible).

Les solutions de type actif/actif peuvent sembler de prime abord plus intéressantes, mais elles sont également encore plus complexes et doivent être envisagées pour répondre d’abord à un problème de répartition de charge. Dans un environnement Microsoft, les solutions sont les suivantes :

Solution actif/passif : cluster à basculement (MSCS - Microsoft Cluster Service).
Solution actif/actif : cluster à répartition de la charge réseau (NLB, Network Load Balancing).

Une application destinée aux utilisateurs doit être compatible avec une solution de haute disponibilité. En dehors des « grands » éditeurs de logiciels, il est courant qu’un éditeur n’ait jamais testé son application en environnement hautement disponible et ne puisse donc s’engager sur son bon fonctionnement. Au minimum, les points suivants sont à analyser :

Est-ce que l’ensemble des données peut résider sur des volumes partagés et donc autres que les lecteurs locaux C:, D:... ?
Est-ce que certaines clés de registre doivent être répliquées entre les serveurs ?
L’application utilise-t-elle un dispositif de protection physique (dongle sur port USB ou parallèle par exemple) ou une connexion physique qui ne peut pas être doublée ou connectée sur deux machines ?
Est-ce que les clients peuvent utiliser un nom NetBIOS/DNS et une adresse IP différents de ceux de la machine physique (nom/IP virtuels) ?
Quels sont les mécanismes pour détecter une panne de l’application et décider de basculer ?

Cas 1 : solution...

La répartition de charge (cluster NLB)

La répartition de charge devient indispensable quand un seul serveur ne suffit plus pour tenir la charge ou maintenir un temps de réponse acceptable. Si le besoin de disponibilité supplémentaire n’est pas un critère, il est conseillé d’ajouter d’abord des ressources matérielles au premier serveur avant d’envisager plusieurs serveurs.

La répartition de charge n’induit pas une capacité de charge linéaire. Si un serveur peut traiter 200 utilisateurs, deux serveurs ne permettront pas forcément de traiter 400 utilisateurs. Tout va dépendre de la nature de la charge et du comportement des sessions TCP générées. La notion d’affinité permet de conserver un utilisateur sur le même nœud tant que celui-ci fonctionne. De cette façon, on minimise le chargement des sessions utilisateurs sur les serveurs. Pour cela la ferme calcule un hash à partir de l’adresse IP du client et sa destination. Si tous les clients se présentent avec la même adresse IP (par exemple derrière un pare-feu avec du NAT), ils seront tous dirigés vers le même serveur, annulant ainsi la répartition de charge.

La répartition n’est pas faite en fonction de la charge des serveurs. Si quelques utilisateurs saturent à eux seuls un des nœuds, il recevra pour autant le même nombre d’utilisateurs que les autres nœuds. Si la charge entre vos nœuds n’est pas du tout uniforme, vous devrez développer une routine qui draine les nœuds au-delà d’une certaine charge.

1. Prérequis pour NLB

Bien que l’installation de la fonctionnalité équilibrage de la charge réseau soit simple, il convient de respecter certains prérequis pour avoir les meilleures performances. La première étape consiste à installer les dernières mises à jour pour le système d’exploitation. En effet, il serait dommage de le faire juste après la mise en production du cluster… bien qu’il ne devrait pas y avoir d’arrêt de service le cas échéant.

Les serveurs participant au cluster ne doivent pas être des contrôleurs de domaine. Cependant, il est nécessaire...

Le cluster à basculement

La technologie de cluster à basculement a une approche très différente de NLB. L’objectif est de maintenir des ressources en ligne en permanence. Chaque ressource est instanciée sur un seul serveur à la fois, mais plusieurs serveurs peuvent être actifs en même temps sur des ressources différentes. Afin de garantir le bon fonctionnement, la couche cluster vérifie un ensemble de points :

Est-ce que l’adresse IP et le nom virtuel fonctionnent ?
Est-ce que l’accès au stockage fonctionne ?
Est-ce que le nœud peut communiquer avec les autres nœuds (pas d’isolation) ?
Est-ce que les services à maintenir en ligne sont fonctionnels ?

Si un incident est détecté sur un de ces points, le cluster bascule l’ensemble des ressources nécessaires au(x) service(s) sur un autre nœud.

Au minimum, un cluster possède au moins un groupe (le « groupe cluster ») qui contient :

Une adresse IP virtuelle.
Un nom virtuel.
Potentiellement un volume faisant office de quorum, ou un partage de fichiers témoin.

Windows Server 2012 R2 apportait une fonctionnalité, Directory-Detached Cluster, qui permet de créer un cluster à basculement sans créer de compte ordinateur pour le cluster dans l’Active Directory, mais les nœuds devaient appartenir au domaine et être dans le même sous-réseau.

Windows Server 2016 va plus loin dans les possibilités de construire un cluster, car les nœuds n’ont plus obligation d’être dans le même domaine ou d’être membres d’un domaine :

Single-domain cluster : cela correspond à la construction habituelle d’un cluster, soit tous les nœuds dans le même domaine Active Directory et dans le même sous-réseau.
Multi-domain cluster : les nœuds composant le cluster proviennent de domaines Active Directory différents. Les domaines Active Directory doivent avoir une relation d’approbation entre eux.
Workgroup cluster : tous les nœuds du cluster sont en groupe de travail (non joint à un domaine, donc).
Mixed cluster (Workgroup et Domain cluster) : des nœuds peuvent venir d’un domaine et d’autres peuvent être en groupe...

Conclusion

Vous connaissez maintenant les avantages et contraintes d’une solution de haute disponibilité et/ou de répartition de charge. Vous avez les cartes en main pour préparer votre solution et la gérer une fois en production. Comme pour beaucoup de solutions, vous ne devez pas attendre d’avoir besoin de cette technologie (au moment d’un dysfonctionnement par exemple) pour valider son bon fonctionnement. Vous devez planifier des tests aussi régulièrement que possible, afin que la bascule fonctionne le jour J. Contrairement à la plupart des projets, c’est parce que l’utilisateur ne se rendra compte de rien (invisible) que le projet sera un succès et sera rentabilisé.

Haute disponibilité