Geoclusters, Extended/Stretch clusters… Voici un sujet qui m’a croisé plusieurs fois depuis maintenant 7 ans, dans 4 pays et sur 2 continents. Sujet passionnant avec plus d’embûches que d’étincelantes réussites personnelles, il faut l’avouer ! Bien sur : j’en connais qui finalement fonctionnent et même auxquels j’ai modestement contribué quand c’était avec RAC… mais si c’était à refaire ?

Ce n’est un secret pour personne que ce n’est pas franchement mon cheval de bataille. Non pas que je n’adorerais pas avoir les mains libres pour mener un tel projet de bout en bout. Non pas que ce soit infaisable (en production j’entends !). Non pas, et ça fait des frissons rien qu’en le disant, que la technologie ne soit pas là et bientôt mature ! Non ce sont : la motivation, la compréhension de la vie d’une application, la gestion des problèmes.

Prenons la motivation. Si quelqu’un pouvait venir me voir en disant, « Nous voulons mettre en place un cluster étendu pour notre image de marque ». Ou s’il disait, « Je veux faire ça parce que je crois ce que me dit IBM, Sun, HP, Symantec ou Oracle et que leur marketing est trop bon ! ». S’il disait : « J’en ai besoin pour être conforme à je ne sais pas quelle législation de dans 15 jours ». S’il disait : « Je crois que c’est un passage pour adresser quelque chose de plus grand ensuite » ou « Je suis en mission pour le Seigneur, il faut que tu reviennes dans le band ! ».

A vrai dire à chaque fois qu’on vient avec ce sujet, c’est pour mettre en place un DRP, pour utiliser toutes les ressources ou parce que l’application est 24×7 avec 5 neufs : banalités !

Prenons la compréhension de la vie d’une application, maintenant :

• A quoi ça sert d’utiliser toutes les ressources si pour le même prix, on pourrait avoir 5 fois plus de ressources et une solution DRP sans Geo Clusters ? Qu’on n’a pas besoin de 5 neufs ? Je sais, c’est fou le nombre de clients qui ont des liens DWDM de 300 kms gratuits ou pour qui RAC ou Veritas est déjà payé. A se demander pourquoi il y en a qui paient !
• Alors disons qu’il vous faut les 5 neufs ou même 4. Il y a des choses à faire avant de mettre en place un geocluster, d’autres pendant et d’autres après. Les geoclusters que je connais sont souvent dans un « no man’s land » ; le jour où ils pourront servir, on verra ce qu’il adviendra. Mais, c’est vrai, on parle d’un monde sans RTOS !

Alors voila, disons le autrement : je serais honoré de travailler pour celui qui aura compris ça et qui pourra dire : Je veux 99.999% et je veux pouvoir migrer de version d’OS, d’application ou de base de données sans arrêter mon système et je veux que le système soit conforme aux exigences de performances pendant cette période. J’ai un cahier des charges, un SLA correctement formalisé, j’ai un plan de continuité de service, ET j’ai le pouvoir de le faire !

Faisons l’analyste du Gartner : C’est pour 2008 (Probabilité 0,0001%)! Alors… Et mes rêves de geoclusters flamboyants ? C’est ce que je disais, ce n’est pas mon cheval de bataille, quoique !

Bon je vais partager 3 ou 4 réflexions, si vous n’êtes pas encore découragés par ce post

la gestion des problèmes ou plutôt, parce que je n’ai pas l’intention d’être exhaustif, voilà ce que vous pourriez appeler les idées les plus communément fausses sur le sujet.

Nota Bene : On supposera que l’objectif affiché d’un geocluster est de survivre la perte d’un site et que la bascule entre les 2 sites se fasse de manière automatique ! Ce n’est qu’une supposition je l’avoue mais c’est ce que pense la plupart des gens.

• Fausse idée numéro 1 : le cluster étendu est d’abord un problème de cluster !

Explication : Prenez un crayon et dessinez une architecture étendue sur le serveur de données ! La première question que vous allez vous poser, c’est où mettre les données, non ? Si on veux survivre à la panne d’un site, il faut les mettre sur 2 site séparés. Pour mettre les données dans 2 data center avec un cluster (C’est à dire pas avec une techno de type standby ou un système de réplication de la base de données), de quoi disposez-vous ?
a) La réplication au niveau de la baie ! C’est à peu près incompatible avec un geocluster, au moins avec une bascule automatique… Non pas vraiment que la bascule ne soit pas automatisable mais qu’après la bascule l’environnement entrera dans un mode dégradé. La bascule a un coût qui empêche de l’automatiser (*)
b) La réplication au niveau du serveur (host) soit avec ASM dans le cas d’Oracle soit avec un Volume Manager. Remarquez que ASM peut fonctionner sur un volume logique et le fait d’utiliser ASM ne signifie pas forcément que c’est ASM qui réplique les fichiers de base de données mais je m’égare…

Corollaire : Le jeu #1 du GeoCluster consiste donc à construire un sous-système de stockage qui soit performant malgré la distance et qui puisse repartir d’autre chose que de zéro lorsque pour une raison x ou y il y a eu perte d’un site. Pour construire ce genre de bête, il faut savoir faire de l’affinité en lecture avec les baies de stockage et ne ré-appliquer que le différentiel en cas de perte momentanée de l’accès à un système de stockage. Justement ce que ASM 11g sait faire ! VxVM sait aussi mais à quoi bon investir dans un trucs, même gratuit, dont on aura toutes les peines du monde à se débarrasser ensuite ?

Bon mais je vais un peu vite à la conclusion. En fait tout est une question de besoin. Est-ce que lire une données aléatoirement d’un site à l’autre en fonctionnement initial convient à vos objectifs de performance ? Est-ce que reconstruire l’intégralité des miroirs disques en cas de perte momentanée de l’accès a un site convient à vos contraintes de disponibilité ? Si oui, c’est un début… mais, même si votre base de données fait 2 Go, assurez-vous que 15 ms ou plus pour faire un I/O sur les redo logs est bien tolérable ; On a tué des gestionnaires de SAN pour moins que ça, vous savez.

Deux dernières remarques :
* Pour l’instant, il n’est pas question de RAC plutôt que d’une autre solution avec Oracle en single instance ; il faut toutefois que je précise maintenant qu’avec RAC, il y a une contrainte supplémentaire, il faut que le Volume Manager si vous voulez l’utilisez fonctionne en cluster et en parallèle. Ce n’est pas le cas de tous les VM et c’est souvent l’objet de licences supplémentaires. Enfin ASM, met tout le monde d’accord ; ça fonctionne toujours mais ne règle pas tous les problèmes de performances du sous-système de stockage. Il peut que ce qu’il peut
* Ce n’est pas parce que vos bases de données font 2 Go que vous pouvez tolérer que votre sous système I/O ne soit pas performants. Par exemple, chaque groupe de commit implique un I/O.

• Fausse idée numéro 2 : On peut mettre en place un cluster étendu avec 2 sites distant !

Et non ! Il faut 3 sites et la raison s’explique en quelques mots… par l’absurde.

Disons que vous avez 2 sites que nous appellerons A et B. Il y a plusieurs types de pannes possibles et vous voudrez à tout prix éviter que les données deviennent incohérentes. Vous voudrez éviter le « split brain syndrome » (Foutaises ! j’ai une diagonale). Pour cela, il faut à tout prix qu’à aucun moment il y ait 2 incarnations du même système vivant des vies séparées et incapables ensuite de se resynchroniser. Pour adresser cette contrainte, le cluster
utilise le suicide (Je n’aborderais pas la vieille histoire du STONITH mais sur un geocluster plus qu’ailleurs, c’est impossible). Imaginons donc que vous perdiez le lien entre A et B. Vous ne pouvez pas laisser dans une telle situation A et B survivre. Il faut que l’un des 2 et un seulement un survive ! Disons que nous choisissons A survit. Je vous laisse faire le raisonnement ou vous choisissez B.

Maintenant imaginons que A soit détruit ! Si B reste seul au monde sans aucun autre site pour l’aider et qu’il ne peut plus joindre A que peut-il supposer ? La connexion vers A est morte ou A est mort ? En fait dans ce cas B n’a aucun moyen de faire la différence et pour agréer votre choix qui est que A survit dans le cas d’un perte de la connexion entre les sites, B choisira de se suicider.

Conclusion : Il faut 3 sites pour construire un geocluster si vous voulez que la bascule soit automatique ! (Encore une fois RAC ou pas)

• Fausse idée numéro 3 : Le débit de DWDM convient pour faire du cluster etendu jusqu’à 180 km !

La évidemment je suis provocateur et tout est encore une question de l’objectif que l’on se fixe. Mais en substance ce que je veux dire c’est que le débit en bien moins important que la latence dans ce cas. N’oubliez pas, par exemple, qu’à chaque fois que vous validez une transaction, vous devez attendre un « ack » du sous système de stockage pour valider la transaction.

Bien sur la plupart des constructeurs font des différences selon la distance et parlent, par exemple de Metro Cluster. Disons pour faire simple que c’est juste un problème d’ampleur de ce que vous allez rencontrez. Et considérez qu’au delà de 3 km votre vie va basculer.

Si, en plus, vous utilisez RAC, il y a le trafic du cache fusion à considérer. 9i proposait une solution RAC Guard pour réduire cette contrainte. 10g permet de « partitionner » l’activité grâce aux services et, je ne dis pas que vous en aurez besoin, mais gardez cette carte dans votre manche et validez que on peut différencier les activités au niveau de l’application. Pour dire les chose autrement : Un point de synchronisation qui empêche la montée en charge d’une application sur une single instance, pourra devenir un problème avec RAC et un gros problème avec RAC en geocluster.

• Fausse idée numéro 4 : Un stretch cluster est une solution de DRP

J’imagine que vous direz que je joue sur les mots mais (cf fausse idée numéro 1), c’est le sous-système de stockage qui assure la reprise des données en cas de désastre dans un cluster étendu et non pas le logiciel cluster (avec ou sans RAC). Le clusterware, quelque soit son fournisseur, n’est qu’une partie de la solution. Autrement dit… si je factorise et ramène tout à Oracle, la question revient à se poser la question équivalente qui est : « Vaut-il mieux utiliser ASM ou Data Guard pour dupliquer ses données sur un site distant ? » (Et laisser respectivement au logiciel cluster ou à l’observer de Fast Start Failover le soin de basculer automatiquement). Et la réponse pour paraphraser un homme illustre est : « It all depends » !

Pour conclure :
En dépit de mes demi-réussites dans ce domaine et de ce post en demi-teinte, le temps est sans doute venu pour que se développent de plus en plus de clusters étendus. La technologie est là avec 11g et 2008, 2009 et probablement 11g R2 la verront maturer. Quand à savoir si le bon projet pour y allez, c’est le vôtre ? Moi, j’ai fait ma part du travail en vous prévenant, si après ça, vous êtes encore plus motivé… Je vous envie déjà : racontez moi la suite !

Grégory

(*) Le problème d’un cluster failover c’est qu’il a souvent tendance à faire ce pourquoi il a été conçu, c’est à dire basculer. C’est comme la femme de ménage qui débranche le serveur pour passer l’aspirateur. Vous me direz c’est pas grave sauf si la bascule laisse des traces. Une bascule avec de la réplication de baie laisse des traces…