Comment assurer une bonne mise en oeuvre du cluster

La réponse se résume en un mot :
planification. Les processus de
mise en oeuvre et le logiciel de validation
ne peuvent pas être entièrement
standard. Pour bénéficier pleinement
du clustering, il faut d’abord prendre en compte les particularités de votre
environnement. Par exemple :

Quelle est pour vous l’importance
de récupérer une application défaillante
le plus près possible du point
d’incident ? La reprise après défaillance
d’une application passe par le lancement
d’un programme de sortie par la
logique cluster du système d’exploitation.
Il faut exécuter ce programme
quand un noeud est défaillant, qu’il est
déconnecté pour maintenance ou que
des modifications sont apportées au
cluster. Plus l’objectif du point de reprise
est exigeant, plus l’application
doit être résiliente. Pour cela, il faut développer
et maintenir des informations
sur l’état de l’application, que
celle-ci utilisera pour s’autorécupérer
après une défaillance.

Pouvez-vous tolérer une dégradation
des performances de l’application
quand un noeud primaire est offline ? Si
la réponse est négative, il faut que les
noeuds de secours soient suffisamment
grands pour offrir des performances
suffisantes quand ils prennent le relais
du traitement. En outre, certaines entreprises
réduisent les coûts en configurant
tous les systèmes de manière à 
ce qu’ils agissent comme des noeuds
primaires pour certaines applications
et comme des noeuds de secours pour
d’autres. Cette méthode assure la redondance
du système sans maintenir à 
grands frais des systèmes de secours le
plus souvent inactifs. Toutefois, si la
performance est primordiale, ce partage
des rôles n’est possible que si l’on
a correctement dimensionné tous les
noeuds pour qu’ils traitent la charge de
travail du noeud défaillant en même
temps que leur charge de travail normale.

Est-il important de ne perdre aucune
information transactionnelle « en
vol » ? Si la réponse est positive, une
journalisation à  distance synchrone est
nécessaire. Notons que la journalisation
à  distance synchrone demande
nettement plus de bande passante
pour réduire l’impact sur les performances
de l’application.

Voulez-vous protéger le site contre
les sinistres ? Si oui, vous placerez probablement
au moins un noeud de secours
loin du noeud primaire (dans
une autre ville par exemple) afin
qu’une catastrophe naturelle ne puisse
pas frapper les deux en même temps.
Dans des situations critiques, on peut
également prévoir plus d’un noeud de
secours. Ainsi, si le premier noeud de
secours tombe en panne pendant que
le noeud primaire est neutralisé pour
maintenance, il vous restera encore un
noeud disponible à  la disposition du
cluster.

Ce ne sont que quatre exemples
des nombreux problèmes concernant
le clustering. Si vous ne les prenez pas
en compte et ne les traitez pas, votre
cluster risque de ne pas atteindre les
objectifs fixés.