Duquesne Group Duquesne Group

English version
Recherche et Analyse

Pour éclairer les décideurs dans le domaine de la Continuité d'Activité et de la Sécurité de l'Information, Duquesne Group propose ses analyses et réflexions issues de ses réalisations concrètes en clientèle. Observation critique du terrain par nos experts, contacts permanents avec les principaux acteurs du domaine et expérience vécue dans nos missions de conseil sont nos principales sources. Contactez-nous pour en savoir +
French version
Research

To support decision makers in the management and optimisation of information systems, Duquesne Group delivers in-depth analyses of information technologies, their implementations and their markets. Our research is based on critical observation of the market by our analysts and their on-going contacts with the vendor community, together with hands-on, practical experience from our consulting work. Contact us to find out more


Tech : Les fonctions de base d'un cluster de serveurs


Nos fiches techniques passent en revue un sujet technologique précis utile à la Continuité.

La mise en cluster est courante en informatique pour assurer fiabilité et disponibilité.

Mais que recouvre-t-elle réellement ?



crédit DR
crédit DR

Le cluster est partout

La mise en cluster (ou en grappe) de serveurs est courante en informatique.

Cela consiste à associer divers serveurs (appelés alors des nœuds) afin de les faire travailler ensemble en partageant plus ou moins des ressources communes.

Cette association de nœuds peut prendre des formes différentes, ils peuvent être tous actifs ou bien certains peuvent être en attente et démarrer en cas de panne ou de forte charge ; ils peuvent partager des ressources comme du stockage, des accès réseau, sous le contrôle de l'un d'entre eux ou de différentes manières.

Cette fiche technique décrit succinctement les fonctions habituelles d'une mise en cluster.

L'objectif de cette fiche est double :

  • comprendre l'apport que le cluster a pour la disponibilité et donc la continuité d'activité ;

  • choisir à bon escient les fonctions correspondant aux besoins

Il existe de multiples implémentations dans le monde mainframe, les Unix courants (AIX, HP-UX, Solaris) et les plate-formes x-86. De plus en plus aussi certaines de ces fonctions sont prises en charge au niveau du système de gestion de base de données ou des hyperviseurs et de leurs outils.

Cette fiche présente des fonctions généralement implémentées.

Les fonctions de bascule ('fail-over')

En anglais : fail-over.

C'est la fonction de base du cluster : à cause d'une difficulté (panne, blocage) un traitement va basculer d'un nœud vers un autre (dit de back-up) plus ou moins rapidement. Plus tard, le traitement pourra revenir sur ce même nœud ou sur un autre.

Les fonctions sont alors les suivantes :

Le mode de fail-over et recovery:

  • un noeud peut-il être le back-up de plusieurs autres ?
  • un noeud peut-il basculer sur plusieurs autres ?
  • la bascule en cascade est-elle possible ?
  • peut-on sélectionner un sous ensemble qui bascule ?
  • peut-on sélectionner le noeud de back-up ?

Les conditions dans lesquelles cette bascule se fait :

  • la détection de la panne de noeud : est-elle automatique ou semi-automatique ?
  • sur quels événements cela se fait-il ?
  • peut-on détecter les applications en blocage ('hung appli' ou 'abend' ou équivalent) ?
  • existe-t-il des possibilités de bascule prédictive (sur signe avant-coureurs ?) et lesquelles ?
  • des agents logiciels existent-ils pour alerter ?

Ces fonctions couvrent ainsi la détection des pannes ou signes forts avant-coureurs et la souplesse de bascule assistée ou pas.

Les fonctions de rétablissement ('recovery')

Il s'agit véritablement de "reprendre pied" suite à la panne d'un nœud. Cela peut se faire de différentes manières, plus ou moins souples et plus ou moins assistées ou automatisées.

Les choix à la console :

  • possibilité de choix de reprise sur le nœud ('local recovery') ou de bascule sur un autre ?
  • confirmation manuelle pour valider la bascule ?
  • délai configurable avant prise de main ?

Les degrés de liberté pour le rétablissement :

  • rétablissement des ressources en parallèle ?
  • le nœud en panne peut-il devenir le nœud de back-up une fois réparé ?
  • le nœud restauré reprend-il les ressources ?

Le rétablissement de l'exploitation (ou retour à la normale) peut-être long s'il n'est pas facilité par le type de cluster ni assisté à la console.

Attention là aux confusions de vocabulaire sur le mot 'recovery'. Il peut s'agir de deux choses :
  • la reprise sur des ressources de secours provisoires
  • le retour à la normale : après bascule sur le secours on re-bascule sur le 'normal' réparé.
On le voit, si le provisoire devient définitif, la distinction n'a pas lieu d'être, mais c'est rarement le cas pour l'ensemble des moyens.

Dans certains cas, donc le retour est réduit (on reste sur secours qui devient nominal) ou facilité (on bascule sur le 'normal' mais celui-ci récupère les disques par exemple du secours, ce qui évite les tâches de récupération des disques ou de leur contenu.

La variété des configurations possibles

Un cluster, c'est un ensemble de serveurs auxquels diverses ressources sont associées : mémoire, cache, disques, contrôleurs, cartes réseaux sur bus ou canal, etc. La capacité à gérer et modifier ces ressources, avec des choix technologiques variés est importante à regarder.

On pourra considérer les points suivants :

La configuration du cluster lui-même :

  • combien de nœuds supportés ?
  • quelle interconnexion ? (FDDI, FCS, ...)
  • quelle connexions aux disques ? (par un seul nœud, commutée, Infiniband,...)
  • quels accès réseau, SAN et commutateurs ?

Les différents firmware, middleware d'accès aux périphériques et leur support :

  • implémentation de stockage RAID en logiciel ou sur une carte adaptateur
  • richesse de l'interconnexion disques et des substitutions possibles (SCSI, iSCSI, SAS, FCS, FC-AL)
  • possibilité de changer de drivers pour des supports d'adaptateurs différents
  • capacité à conserver les verrous ('locks') des systèmes de fichiers (comme NFS) d'un nœud à l'autre
  • acquisition d'adresses IP et TCP
  • capacité à basculer la connexion d'un dérouleur de bande vers un autre nœud
  • capacité à booter sur serveur de boot, ou directement à partir du SAN
  • etc.

La manière de partager ou non les données entre noeuds de cluster et de gérer les locks d'accès aux données, systèmes de fichiers et SGBD est un sujet d'étude à part entière. Nous ne le détaillons pas ici. Très souvent d'ailleurs, un intégrateur ou le constructeur lui-même a déjà réalisé des optimisations.

Toutes ces facilités simplifient grandement les tâches de l'exploitant et permettent de la diversité de reprise.

Le rétablissement interne sur panne ('in system failure recovery')

C'est une capacité qu'a un serveur (donc un nœud) à tolérer une panne interne. Cela permet de limiter les cas de bascule.

Si le serveur choisi a des capacités de recovery interne fortes, on pourra même se passer de cluster pour certaines applications non 24/24 peu critiques.

Voici quelques points à considérer :

La manière de contenir la panne et d'y faire face, pour :

  • les mémoires, les CPU, l'OS, les bus
  • les adaptateurs de bus, canal ou LAN
  • les ventilateurs, les alimentations électriques
  • les erreurs mémoire (en mode user)
  • les caches mémoire (L1, L2, L3)
  • le root disk journaling
  • les applications suspendues ('hung applications')

Détecter la panne, l'isoler puis activer un secours interne au serveur ou demander une intervention manuelle rapide (utilisant le fameux 'hot plug' ou 'hot switch' : échange à chaud).

Autres aspects intéressants, le comportement en cas d'événements comme :

  • La coupure de courant : y a-t-il une autonomie interne (petite batterie) puis purge des caches et arrêt propre au bout d'un certain temps ? quel usage est fait de mémoire flash non volatile ?
  • Le début de surchauffe : démarrage de ventilateurs ? ou arrêt propre ?
  • En cas de redémarrage manuel : temporisation pour recharger la batterie ? ou refroidir la machine ?

Ces fonctionnalités sont des atouts très intéressants pour restreindre la panne à un périmètre très circonscrit et limiter les cas de pannes nécessitant bascule en cluster. On les regroupe souvent sous les mots 'tolérance aux pannes'.

Le pilotage de la haute disponibilité et du 'disaster recovery'

Ce point est critique car il détermine les moyens que l'on a pour découvrir la panne et réagir en conséquence avec des moyens préparés.

Faisons alors la distinction entre trois notions :

  • tolérance aux pannes : capacité à ne pas sentir la panne car une parade automatique est mise en place et s'active. En terme de pilotage, cela nécessite néanmoins d'être tenu au courant de la panne pour agir afin de remplacer l'équipement défaillant (ex : le ventilateur de secours marche : il faut changer le ventilateur principal qui est en panne)

  • haute disponibilité : capacité à répartir un traitement sur deux (ou plusieurs) nœuds de serveurs en permanence ou en cas de panne ou de nécessité d'arrêter un nœud (pour une intervention quelconque). Il peut y avoir interruption de service, mais sur une période courte. Les données sont fraîches. A priori les serveurs sont assez proches l'un de l'autre (nécessité du synchronisme et de la proximité opérationnelle.) Par précaution on les mettra dans deux salles indépendantes.

  • disaster recovery : capacité à reprendre le service en cas de gros pépin. Il y a interruption de service. La reprise est plus ou moins rapide avec des données plus ou moins fraîches. Par construction le serveur principal et son secours doivent être éloignés (> 30 km? > 150 km ?) pour éviter un désastre commun.

Les points à regarder sont en terme de pilotage et d'opérations :

  • la console ou poste de pilotage : unique ? attaché à la machine ou distant ? via le web ?
  • les automatismes : scripts ? fournis par le constructeur ? développés maison ? testés ?
  • les outils pour le load balancing : faciles à appréhender ? manuellement ? assisté ?
  • modification de configuration, addition de ressources, déplacement de charges : facile ? aidé ?
  • les copies distantes ? mirroring ? synchrone ou pas ? points de reprise ?
  • les resynchronisations disques ? la bascule TCP/IP ? automatismes ? aides ?
  • les limitations techniques de distances entre console et serveurs, entre baies de disques ? entre disques et serveurs ?
  • etc.

Le système de cluster choisi devra posséder des capacités sur ces points.

Choisir en connaissance de cause

L'ensemble des points listés ci-dessus concourent à déterminer les implémentations à faire en fonction des contraintes.

En effet, il existe trois familles de contrainte à considérer :

  • les exigences des métiers en terme de continuité et reprise (à déterminer dans un BIA voir ce sujet sur le site Duquesne)

  • le paysage de risques auxquels il faut faire face : peut-on avoir deux salles proches ou faut-il les éloigner ? faut-il un troisième site et de quel niveau d'activité ?

  • enfin : les contraintes imposées par l'humain opérationnel : tout ceci doit être suffisamment simple et compréhensible. En cas de panne ou sinistre encore plus.

Emmanuel Besluau
Jeudi 22 Mai 2014

Home Home    Mail Mail    Print Print    Zoom + Zoom +    Zoom - Zoom -    Share Share


Duquesne Research Newsletter