Failover clustering

clustering laissait à 
désirer. Mais Microsoft l’a complètement
réécrit dans SQL Server 2000 et a
facilité sa mise en oeuvre grâce à  de
nombreuses nouvelles possibilités de
SQL Server 2000. Vous gérez le cluster
de la même manière qu’une installation
SQL Server à  une seule machine. A
moins d’interagir avec le desktop et
Cluster Administrator (l’utilitaire de
mise en place du clustering), rien ne
permet de savoir que SQL Server
tourne sur un cluster. Cette transparence
rend très simple l’administration
d’un cluster.
Bien que les procédures administratives
ne changent pas quand on
passe d’une configuration monomachine
à  une configuration multimachines,
on gagne une possibilité
intéressante. En cas de défaillance
matérielle, le cluster déplace l’application
SQL Server 2000 sur un autre matériel
disponible du cluster et le met en
ligne. Moyennant certaines pratiques
de développement (que je décris plus
loin), vos utilisateurs finaux ne sauront
même pas qu’il y a eu un incident. Ce
point est important parce que le taux
de disponibilité au niveau du serveur
présente peu d’intérêt. Seule importe
la disponibilité sur le poste du
« consommateur » de données, ou usager.
Quand l’élément matériel (appelé
un noeud) sur lequel fonctionne SQL
Server est défaillant, SQL Server s’arrête.
Le service Microsoft Cluster transfère
la propriété de l’espace disque sur
un autre noeud et démarre SQL Server.
Le failover des ressources dans un cluster
se produit en 15 secondes environ,
dans des circonstances normales. Mais
beaucoup de personnes ne prennent
pas conscience des implications de
l’arrêt et du redémarrage de SQL
Server. Quand SQL Server démarre, il
passe par un processus séquentiel spécifique
appelé reprise de redémarrage.
La partie cruciale ici est la phase undoredo
(défaire-refaire) pour une base de
données. La phase redo est toujours
brève ; vous la contrôlez par l’option
de configuration de l’intervalle de reprise.
Dans la phase undo, vous êtes
tributaire de la manière dont une application
a été codée. Des transactions
dont l’exécution est longue peuvent
dégrader sensiblement le temps de failover
du cluster.
Supposons qu’un utilisateur déclenche
dans la base de données une
opération dont l’exécution demande 6
heures. A 5:59:00 dans le processus, le
noeud exécutant SQL Server tombe en
panne. Le service Cluster prend le relais,
déplace des ressources et remet
SQL Server online en 15 secondes.
Bien que le cluster ait basculé en 15 secondes,
les utilisateurs devront quand
même attendre près de 6 heures avant
que leurs données ne redeviennent
disponibles, à  cause de la phase
« undo » de la reprise. Si le développeur
avait écrit cette application pour qu’elle s’exécute en tranches récupérables
d’une durée maximale de 3 à  5
secondes, le cluster aurait basculé et
les données seraient redevenues disponibles
aux utilisateurs dans les 20 secondes
suivant la défaillance du noeud
principal.
Il est un autre domaine où le talent
du développeur peut donner à  l’utilisateur
final une disponibilité nettement
meilleure : c’est le traitement des
connexions et des transactions à  l’intérieur
d’une application. Quel que soit
le matériel sur lequel un SQL Server
s’exécute, il aura toujours le même
nom. Si un utilisateur est connecté à 
un SQL Server en cluster qui bascule
soudainement, cet utilisateur est déconnecté.
Pour poursuivre le traitement,
il suffit à  l’utilisateur de réétablir
la connexion avec SQL Server. Les développeurs
peuvent en profiter pour
rendre les clusters failovers transparents
aux utilisateurs finaux, en programmant
l’application de manière à 
ce qu’elle détecte une déconnexion de
SQL Server, attende quelques secondes,
puis se reconnecte. Une fois
reconnectée, l’application devrait être
capable de réémettre toute transaction
qui n’est pas allée à  son terme avant le
basculement. Ce genre d’application
fournit une architecture système résiliente
garantissant qu’une défaillance
du système ne détruit aucune donnée
utilisateur.
Il est temps de dissiper quelques
idées fausses à  propos du cluster. Un
cluster SQL Server n’est qu’un mécanisme
de protection matériel. Par
conséquent, il ne vous protègera nullement
des défaillances de données, des
failles de la logique applicative, des erreurs
utilisateur ou de la corruption de
données. La protection passe ici par les
sauvegardes des bases de données. Un
cluster SQL Server n’augmente pas
non plus la performance ou l’évolutivité.
On peut bien avoir plusieurs éléments
matériels se comportant
comme une ressource, mais SQL
Server ne peut pas accéder aux ressources
sur un autre élément matériel,
et une application ne sera pas plus évolutive
sur un cluster qu’elle ne l’est sur
un noeud.