Reprise après sinistre, à  bon compte

Beaucoup de produits du marché visent à assurer la disponibilité continue et la permutation rapide des rôles dans les sites System i. Certains s’appuient fortement sur le matériel. D’autres recourent aux logiciels pour la réplication d’objets logiques. Mais tous, ou presque, demandent la même chose : vous faire sortir le carnet de chèques et ajouter des fonctions matérielles/logicielles à votre machine.Installer de tels produits et configurer le support additionnel est souvent une démarche prudente, particulièrement si l’on vise une permutation de rôles rapide et la réplication d’une grande variété de types d’objets. Mais cet article s’intéresse à une autre méthode. Elle vous concerne si vous n’avez pas les moyens d’acquérir de tels produits, si vous pouvez vous contenter de répliquer simplement les derniers changements apportés à vos fichiers base de données les plus critiques, de n’effectuer généralement que de simples opérations base de données, et si vous êtes prêts à accepter des rafraîchissements périodiques plutôt que le replay continu sur un système cible. En utilisant ce qui existe déjà dans i5/OS, peut-on pratiquer une reprise plus ponctuelle que les seules sauvegardes nocturnes ? La réponse est un oui fort et clair !

Bien sûr il n’est pas ici question de haute disponibilité (HA, high availability) au sens traditionnel. Pour être honnête, il s’agit plutôt d’une disponibilité moyenne au mieux. Elle ne conviendrait pas à des environnements complexes et exigeants. Mais cette technique est gratuite !

Je me suis intéressé pour la première fois à cette méthode voilà quelques années, quand un consultant m’a demandé si la commande CL Apply Journal Changes (APYJRNCHG) pourrait utiliser comme entrée un journal distant. Ma première réponse fut « Certainement pas ! ». Cependant, alors que nous continuions à échanger des courriels, il m’est apparu que l’on pourrait peut-être leurrer quelque peu le système d’exploitation en lui faisant croire qu’un récepteur de journal distant avait été transformé en un récepteur de journal local. Ce consultant envisageait le scénario suivant : Il emploierait le support de journal distant traditionnel pour envoyer les changements de base de données d’une machine de production à une machine cible, seconde par seconde, puis périodiquement (une fois par heure environ) réveiller la cible et répéter ces changements sur une réplique des fichiers base de données critiques. Cette tactique garantit que la plupart des changements de base de données les plus récents ont été transportés sur une machine distante, disponible pour un replay périodique. Ce n’est pas la plus haute disponibilité ni la permutation de rôles instantanée, mais c’est généralement mieux et plus ponctuel qu’une simple sauvegarde nocturne des fichiers base de données critiques.