Il y a 16 ans -
Temps de lecture 4 minutes
Haute disponibilité des SGBD … avec des clusters actif-standby
La haute disponibilité des bases de données est un sujet de plus en plus fréquent chez nos clients et le choix de la solution est lourd d’impacts, non seulement financiers mais aussi sur l’architecture des applications.
Si un consensus se dégage autour de clusters actif-actif pour la haute disponibilité des applications Java, la solution pour les bases de données fait encore débat entre deux approches radicalement différentes : les clusters actif-actif (e.g. Oracle RAC) ou les cluster actif-standby (e.g. IBM DB2 HADR et Oracle DataGuard). Derrière des mots très proches de sens se cachent des complexités et des coûts totalement différents.
Un cluster actif-standby est simple à comprendre et économique : le nœud actif sert tous les clients et, en plus de persister les modifications sur disque, propage ces modifications au cluster en standby par une simple connexion réseau (typiquement du gigabit ethernet). Lorsque le serveur actif tombe (maintenance ou incident), le serveur en standby prend le relais.
En plus de la haute disponibilité, les clusters actif-standby offrent une meilleure tenue à la charge en permettant des accès en lecture seule au cluster en standby … avec toutes les limitations et les complexifications que la « lecture seule » entraine.
Un cluster actif-actif est incomparablement plus complexe et plus couteux : tous les nœuds servent simultanément les clients (typiquement en mode round robin). La cohérence des nœuds est assurée par une synchronisation permanente de la mémoire (données et verrous) et l’utilisation d’un espace de stockage partagé (typiquement un coûteux SAN). Encore plus impactant, il est nécessaire de changer le style de programmation des applications pour prendre en compte le délai de propagation des données entre les nœuds du cluster : on regroupe dans une même transaction les données dépendantes les unes des autres [2].
En plus de la haute disponibilité, les clusters actif-actif offrent une meilleure tenue à la charge en multipliant le nombre de serveurs qui traitent les requêtes.
La plus value des serveurs actif-actif par rapport à leur concurrents actif-standby est cependant à tempérer par deux réalités de terrains :
- Sommes-nous sûr qu’un seul serveur actif ne suffit pas ? L’augmentation de la puissance CPU permet à la plupart des bases de données que nous rencontrons sur nos projets de se contenter d’un très économique serveur lame équipé de deux processeurs quad core (< 5000 €). Et si dans un an, le serveur sature, il suffira d’acheter une nouvelle lame dont le nombre de cœurs aura doublé pour une somme toujours aussi modique [3].
- Enfin, la promesse de la transparence d’une mise en cluster actif-actif bute régulièrement sur ce problème de délimitation des transactions.
Il est le plus souvent rédhibitoire de revoir le code de gestion des transactions (délais + charges), on essaie alors de diminuer le délais de propagation des données entre les nœuds du cluster mais cela nuit gravement aux performances et ne suffit pas à faire disparaître les violations de clef étrangère … alors on finit par désactiver le load balancing ( "(load_balance=no)(failover=yes)" ) ! A la fin de la journée, on a payé un cluster actif-actif mais on l’utilise en mode actif-standby. Que d’efforts inutiles.
Pour conclure, OUI à la haute disponibilité des bases de données mais de grâce, pour les équipes de troubleshooting et les directions des achats, avec des clusters actif-standby.
Si un cluster actif-actif s’avère malgré tout nécessaire, il est impératif que la recette s’effectue sur une base de données clusterisée et donc d’en mettre aussi une à disposition des équipes de développement sur l’environnement d’intégration. Messieurs nos acheteurs, à vos calculettes ;-)
—
[1] Pour plus de précisions, voir Oracle DataGuard overview et DB2 Data Recovery and High Availability Guide and Reference (pdf).
[2] Exemple de code transactionnel inadapté aux clusters actif-actif : un acte de gestion qui créé dans la foulée un client et un caddy pourrait très légitimement utiliser deux transactions : une première pour insérer le client puis une deuxième pour insérer le caddy. Hélas, avec une base de données en cluster actif-actif, il y a un très fort risque de violation de clef étrangère : la deuxième transaction sera exécutée sur le deuxième nœud du cluster (cf. round robin) avant que le nouveau client soit propagé à ce deuxième nœud.
[3] c.f. Billy Newport Is Oracle RAC a product of the past
Publié par Cyrille Le Clerc
CTO de Xebia, Cyrille est aussi committer sur le projet Apache CXF. Après être récemment intervenu sur les sites web et les plateformes de web service à fort traffic d'opérateurs de télécommunication, Cyrille est actuellement responsable de la mise en place d'une grille de données inter-continentale pour une grande institution financière française. Après 7 ans chez IBM Global Services et 5 ans chez Xebia, Cyrille a une expérience variée allant du monde commercial aux écosystèmes Open Source dans des approches aussi bien très cadrées et contractuelles que légères et agiles. Cyrille est aussi blogger sur blog.engineering.publicissapient.fr et speaker dans des conférences (In Memory Data Grids & NoSQL, applications prêtes pour la production, etc).
Commentaire
1 réponses pour " Haute disponibilité des SGBD … avec des clusters actif-standby "
Published by wiztricks , Il y a 15 ans
Je ne contesterai pas qu’un cluster actif/passif est bien plus simple à mettre en oeuvre.
Ceci dit, il faut regarder l’intérêt des solutions respectives en fonction du nombre de TerraByte et du nombres de serveurs nécessaires pour supporter la charge d’une ou de plusieurs applications qui partageraient un même service SGDB.
Dans ce dernier cas, la construction du service SGDB peut être faite et administrée indépendamment des bases de données (et des applications correspondantes).
Ce changement d’échelle ne peut se justifier qu’avec (beaucoup) de volumes et la construction de tels services doit être faite indépendamment des projets qu’ils l’utilisent (sauf pour ce qui concerne la définition des services rendus).
Vous avez raison en disant qu’ajouter des systèmes à Oracle RAC est parfois équivalent au remplacement du système actif par une boîte plus musclée.
Pour trouver la moins mauvaise réponse technique, il faut peut être considérer l’évolution du(ou des SGDBs) sur 3/4 ans et évaluer différents scenarii en fonction des incertitudes qu’on peut avoir.
Exemple: si on prévoit qu’il faudra doubler les capacités dans les 3 ans:
– (scale up) est-ce qu’on achète des boîtiers dans lequels on pourra ajouter CPU et disques ou prend-t-on le risque d’avoir à requalifier l’application parce que dans 3 ans, le nouveau boitier demandera une mise à jour de l’OS et de la pile applicative?
– (scale out) si on ajoute des boîtiers dans le temps nous risquons d’avoir les mêmes problèmes de compatibilité? Faut-il virtualiser l’environnement système/appli pour s’en affranchir ?
Pour le reste, oui, le cluster RAC a des limitations liées à la localité des accès construire une application « avec » demande des expertises « spécifique ». Il faut donc que l’enjeu en vaille le coût et que la complexité qui en résulte soit gérable.
-W