> Tech > Reprise après sinistre, à  bon compte

Reprise après sinistre, à  bon compte

Tech - Par Larry Youngren - Publié le 24 juin 2010
email

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.

Reprise après sinistre, à  bon compte

D’ordinaire, les fichiers base de données sur une machine de production sont protégés par un journal local. Celui-ci peut être répliqué à distance, produisant ainsi un journal distant (figure 1). Le journal distant et ses récepteurs de journaux correspondants résident généralement sur une machine cible séparée de celle qui contient les fichiers base de données originaux. La machine cible peut se trouver à bonne distance de la machine source, offrant ainsi la survie et la protection en cas de sinistres du genre incidents, inondations, tornades, séismes, et autres ouragans. Tout ce qui va dans le journal local sur la machine source s’écoule rapidement vers le journal distant sur la machine cible. A quelle vitesse ? Généralement en quelques fractions de secondes. On voit donc que le récepteur de journal distant devient une source d’informations fiable et permanente, concernant les changements de base de données les plus récents qui affectent vos fichiers de production.

Dans ce genre d’agencement, le journal distant est un jumeau du journal local, avec une différence importante : il considère qu’aucun fichier base de données ne l’alimente – au moins aucun résidant sur la machine cible. Par conséquent, toute tentative d’opération APYJRNCHG vis-à-vis de ce journal distant sera rejetée, et c’est précisément à ce problème que le consultant était confronté et c’est ce qu’il cherchait à résoudre.

Téléchargez gratuitement cette ressource

Guide de Survie aux Incidents IT

Guide de Survie aux Incidents IT

Découvrez le Top 100 des termes essentiels à une communication claire et précise lors d'un incident informatique. Classés en fonction des 5 phases du cycle de vie des incidents, ce guide de survie exclusif a été créé pour améliorer la communication de crise des équipes IT. Un Must Have !

Tech - Par Larry Youngren - Publié le 24 juin 2010