Infrastructure et services de base

1. Tolérance aux pannes

L’exemple du chapitre Application standalone, qui est le fil rouge de ce livre, a mis en évidence de nombreux problèmes qu’il va falloir corriger.

Pour qu’un service reste disponible, il doit être tolérant aux pannes. Cela signifie qu’en cas de problème, matériel ou logiciel, l’application et ses dépendances doivent rester accessibles, jusqu’à la limite du raisonnable : si on éteint tout, il est évident que plus rien ne va fonctionner. Mais si on éteint quelques serveurs, si on perd quelques services, si on coupe quelques câbles réseau, si on perd une alimentation, peut-on trouver un moyen pour continuer à fonctionner ?

2. Taux de disponibilité

Un système informatique est dit à haute disponibilité (High Availability - HA), quand il a un taux de disponibilité élevé. Par disponibilité, on entend que le service est rendu de manière convenable.

Généralement, c’est un élément contractuel : un fournisseur s’engage à fournir une disponibilité de 99,9 %, ce qui signifie que le service doit être fourni 99,9 % du temps sur une période donnée (année, mois, semaine, jour…). Sur une année, cela correspond à moins de 9 heures d’interruption. La méthode de calcul de la disponibilité peut varier. On peut décider, par exemple, de ne pas décompter les interruptions programmées ou les microcoupures (moins de quelques minutes ou secondes).

Voici un tableau qui donne quelques valeurs d’indisponibilité maximales en fonction du taux de disponibilité souhaité :

1. Exemple d’architecture

Voici un diagramme représentant une architecture classique de haute disponibilité d’une infrastructure informatique, qui se veut la plus tolérante possible aux pannes.

Figure 1 : Infrastructure en haute disponibilité

On constate que le matériel est redondant :

Les connexions elles-mêmes sont redondantes :

2. Caractéristiques matérielles d’un serveur

Dans un datacenter (ou centre de données), les serveurs sont installés sous forme de lames dans des racks. Ces serveurs ont des particularités par rapport à un ordinateur classique :

1. Réseau VirtualBox

Sous VirtualBox, vous devez créer un réseau privé hôte.

Figure 3 : Création d’un réseau privé hôte sous VirtualBox

Par rapport à la configuration des machines virtuelles, le point important concerne les interfaces réseau. Mis à part les deux serveurs infra01 et infra02, tous les serveurs ne disposent que d’une seule interface réseau. Configurez celle-ci avec les paramètres suivants :

infra01 et infra02 sont différents. Ils sont exposés sur le réseau utilisateur (entreprise, intranet, réseau d’une box), la première interface est configurée autrement :

Enfin, pour les simulations d’exposition sur Internet, ces deux serveurs disposent d’une troisième interface, totalement interne aux machines virtuelles :

Figure 4 : Configuration des interfaces des machines virtuelles

2. Réseau Hyper-V

Hyper-V est l’hyperviseur par défaut de Microsoft, disponible sur les versions Server, Windows 10 et 11. C’est aussi l’hyperviseur de la plateforme Cloud Azure. Pour connaître les étapes d’activation, veuillez vous reporter à la page suivante :

https://support.microsoft.com/fr-fr/windows/activer-la-virtualisation-sur-windows-11-pc-c5578302-6e43-4b4b-a449-8ced115f58e1

1. Vitesse et tolérance aux pannes

Les connexions réseau des serveurs doivent être tolérantes aux pannes. Linux permet d’agréger plusieurs interfaces réseau physiques en une seule interface logique en créant une liaison logique (bonding) entre plusieurs interfaces (adaptateurs) réseau. En cas de perte d’un lien sur une carte, le trafic peut être basculé sur une autre.

Le mode de fonctionnement de cet agrégat d’interfaces dépend de son paramétrage et couvre des possibilités différentes. Le bonding permet :

Deux méthodes existent sous Linux pour gérer les agrégats : l’utilisation de bonding, qui est la méthode historique gérée par le noyau, et l’utilisation de teamd, qui est la méthode apparue avec les noyaux 3.3, avec un service (daemon) en espace utilisateur. C’est la version historique qui est présentée ici, totalement supportée sur l’ensemble des versions d’Ubuntu. Le principe reste cependant le même, quelle que soit la méthode.

2. Considérations matérielles

L’utilisation de certains modes d’agrégat nécessite une configuration spécifique des ports des switchs sur lesquels les interfaces du serveur sont raccordées, mais même un modèle basique permet l’utilisation de certains modes de fonctionnement. La configuration des switchs managés est de la responsabilité des équipes réseau et ne sera pas abordée dans cet ouvrage. La description des modes de fonctionnement indique quand une configuration particulière doit être appliquée.

3. Modes de fonctionnement

Un agrégat définit une interface réseau logique dite maître, sur laquelle sont configurées les différentes adresses IP du serveur....

1. Comment Linux résout-il les adresses ?

Un des nombreux rôles des serveurs infra01 et infra02 est de proposer un service de résolution des noms de domaine via un DNS (Domain Name System). Linux dispose de plusieurs moyens pour associer et résoudre les noms d’hôtes et les adresses IP. Les commandes et outils standards utilisent la fonction C gethostbyname, au sein de la bibliothèque C standard. C’est le resolver. L’ordre de recherche est défini dans le fichier /etc/nsswitch.conf :

hosts:          files dns 

Avec cette ligne, la fonction recherche d’abord une correspondance dans le fichier /etc/hosts, et ensuite avec le service DNS. L’avantage de la première solution, c’est qu’elle est locale et donc rapide, et non impactée par la perte d’un autre service. L’inconvénient, c’est aussi qu’elle est locale. Le contenu du fichier /etc/hosts doit être synchronisé à chaque modification avec l’ensemble des serveurs. Sur des grosses infrastructures, c’est intenable.

Le DNS résout ce problème en fournissant un service réseau hiérarchique et distribué de résolution de noms : on lui fournit un nom, il retourne l’adresse correspondante, et vice versa (résolution inverse). Les avantages sont très nombreux : il n’y a plus qu’un seul endroit où mettre à jour des associations ; et selon la configuration, si le serveur ne trouve pas le nom, il peut transmettre la requête à un autre.

L’inconvénient est qu’en cas de perte du service de résolution, Linux ne peut alors plus résoudre les adresses, entraînant la perte de nombreux autres services. Un second inconvénient est une éventuelle latence dans la vitesse de résolution. Dans les deux cas, le problème est surmontable par l’utilisation des éléments suivants :

La mise en place d’un DNS primaire et d’un DNS secondaire est assez simple et correspond à l’objectif de mettre en place un service en haute disponibilité...