Guide de sauvegarde : choisir les données à répliquer

Bien qu’il semble plus facile de copier tout le système, sachez que cela copie vraiment tout : les attributs réseau, les valeurs système, les ressources matérielles — tout ce qui se trouve sur disque.

C’est plus facile à mettre en place mais le temps de reprise sera plus long. Il vous faudra faire un IPL anormal du système de reprise après sinistre, puis procéder aux changements nécessaires pour rendre le système opérationnel (entre autres, changer les paramètres réseau et les noms des ressources). Vous pouvez intégrer cela dans votre script de reprise après sinistre, mais il faudra quand même du temps.

Guide de sauvegarde : choisir les données à répliquer

La méthode la plus courante, certes plus difficile, consiste à placer les données vraiment importantes dans un IASP. Le miroir matériel ne réplique que l’IASP et son contenu. Considérez un IASP comme un seau. Sur un système sans IASP, il y a juste un grand seau dans l’ASP système, appelé couramment SYSBAS. Tous les objets s’y trouvent.

Quand vous créez un IASP, il y a désormais un second seau. En fait, vous pouvez créer de multiples IASP, mais en respectant quelques règles.

Pour rester dans l’analogie du seau, quand vous vous connectez au système, vous ne pouvez d’abord voir que ce qui se trouve dans le seau ASP système.

Commande Set Auxiliary Storage Pool Group

Quand l’IASP est « varied on », vous pouvez y accéder en le faisant spécifier par votre description de job ou un émettant la commande Set Auxiliary Storage Pool Group (SETASPGRP). Dans ce cas, l’IASP est ajouté au « namespace » de ce job. C’est un peu comme prendre un second seau.

De même que vous n’avez que deux mains, vous (ou en l’occurrence n’importe quel job du système) ne pouvez avoir que deux « seaux » à la fois. Vous devez avoir SYSBAS (c’est l’endroit où se trouve l’OS), et vous pouvez avoir soit aucun seau soit un autre seau (IASP). Donc, si vous avez mis en place de multiples IASP, vous devez en « poser » un avant d’en « prendre » un autre. C’est à nouveau la commande SETASPGRP.

La méthode du double IASP mérite quelques considérations au niveau applicatif. Supposons que vous ayez une bibliothèque appelée MYLIB et deux IASP appelés TEST et PROD. MYLIB peut exister à la fois dans TEST et PROD, puisque vous ne pouvez en « détenir » qu’un à la fois. S’il existe dans l’un ou l’autre des IASP, il ne peut pas exister dans SYSBAS. Le piège à surveiller ici est que quand les IASP seront « varied off », ils vous permettront de créer MYLIB dans SYSBAS — mais alors ils refuseront de refaire « vary on » sur les IASP !

Il est donc important de synchroniser soigneusement les changements entre les systèmes primaire et secondaire dans un couple reprise après sinistre/HA. Si vous créez une bibliothèque dans SYSBAS, puis décidez de passer à l’IASP, vous devez faire la même chose sur le système reprise après sinistre/HA. Faute de quoi, quand vous essaierez de basculer, l’IASP ne passera pas en « vary on ». Ce peut être une erreur très difficile à diagnostiquer.

Il faut réfléchir à quelques points avant de décider ce qui va, ou non, dans l’IASP. Tout d’abord, considérer les choses qui ne peuvent pas exister ou être utilisées dans un IASP. Cette liste se raccourcit avec chaque release, mais le plus important est que l’IASP n’est pas disponible pendant l’IPL, dont vous ne pouvez pas y stocker des choses nécessaires au moment de l’IPL : elles doivent rester dans SYSBAS. L’IASP et les objets qu’il contient apparaissent juste comme une unité « varied-off » au moment de l’IPL (et non, vous ne pouvez pas spécifier Online at IPL…*YES).

Cela inclut des choses comme vos récepteurs de journaux d’audit et aussi des objets de gestion de travail (par exemple, description de sous-systèmes, description de job, classes). Vous devrez vous assurer, au prix d’un certain effort, qu’aucune de ces choses ne référence des objets dans l’IASP. Par exemple, est-ce que vos jobs prestart référencent un JOBD ou une classe dans une bibliothèque que vous avez déplacée vers l’IASP ?

Vous devriez diviser votre programme de démarrage en deux parties : les choses qui démarrent en n’utilisant que des objets dans SYSBAS et celles qui requièrent les données et les objets IASP. La partie SYSBAS peut être appelée comme un programme de démarrage standard, et la partie IASP peut être appelée à partir d’un programme point de sortie (à noter qu’il y a des points de sortie pour le pré et post « vary-on » des unités).

En outre, il y a certains objets qui ne peuvent pas vivre dans un IASP. Les plus courants d’entre eux sont probablement les documents library objects (DLO). Ils sont la première méthode de stockage de fichiers de type PC en OS/400 et remontent au défunt programme OfficeVision. Il vaut bien mieux stocker ces types de fichiers dans l’IFS. Mais peut-être avez-vous des applications qui les utilisent.

Si vous ne pouvez pas faire migrer ces objets, tout espoir n’est pas perdu. Vous pouvez utiliser une forme limitée de réplication logicielle pour les répliquer sur le système à distance. Ou, s’ils changent peu fréquemment, vous pouvez les sauvegarder dans un fichier de sauvegarde qui existe dans l’IASP et les restaurer dans le cadre de votre reprise. Bien que les DLO ne puissent pas exister dans l’IASP, un fichier de sauvegarde les contenant le peut et il sera répliqué automatiquement par la réplication matérielle.

Demandez donc aussi à vos fournisseurs de logiciel leur opinion sur la mise en oeuvre de la réplication de stockage externe. En effet, certains produits ne supportent peut-être pas les IASP bien que ces derniers soient disponibles depuis plusieurs releases. Si ces applications sont plutôt statiques, il suffira peut-être de s’assurer qu’elles sont installées sur les deux systèmes : production et reprise après sinistre. Si ce n’est pas le cas, elles pourraient bien faire l’objet d’une réplication logicielle limitée. Rappelons que le rôle de l’IASP est de protéger vos données de production ; donc tant que la plupart se trouvent dans l’IASP, la réplication matérielle reste bénéfique.

IASP dans Sybase

Quand vous mettez en oeuvre l’IASP, il est probable que vous devez apporter quelques autres changements au support des applications. Il se peut que certains objets (comme des descriptions de jobs) doivent aller dans une nouvelle bibliothèque dans SYSBAS, car il y a d’autres objets dans leur bibliothèque précédente qui devraient être dans l’IASP. Cela pourrait demander le changement du chemin de bibliothèque dans une application.

Par ailleurs, l’IBM i traite la structure de bibliothèques QSYS standard d’un IASP d’une manière différente que pour l’IFS. Les bibliothèques qui se trouvent dans cet IASP apparaissent comme si elles étaient dans l’ASP système.

Gestion des atributs de l’objet

Les attributs de l’objet vous indiquent à quel ASP il appartient, mais le job peut y accéder de manière transparente. Il n’en est pas ainsi dans l’IFS, où l’IASP lui-même apparaît comme un sous-répertoire sous le répertoire racine (/). Soit un IASP nommé IASP01. Si vous avez une application qui recherchait le fichier /mydir/mydoc.pdf et si vous avez mis mydir dans l’IASP pour le protéger, vous devrez désormais faire référence à l’objet en tant que /IASP01/mydir/mydoc.pdf. Mais il existe un élégant contournement. Vous pouvez utiliser la commande Add Link (ADDLNK) pour créer un lien symbolique qui pointera vers l’IASP :
ADDLNK  OBJ(‘/IASP01/mydir/mydoc.pdf’)
NEWLNK(‘/mydir/mydoc.pdf’)
LNKTYPE(*SYMBOLIC)

Ainsi, quand on programme demandera /mydir/mydoc.pdf, il sera dirigé vers le répertoire dans l’IASP. Bien sûr, en cas de multiples IASP, le lien ne peut pointer que vers un seul.
Il y a aussi certaines commandes qui font référence aux objets dans la structure QSYS en utilisant une nomenclature de style répertoire, par exemple, les commandes SAV faisant référence à un fichier SAV. Ainsi, si vous utilisiez /qsys.lib/mylib/mysavf.file comme cible d’une commande SAV et si mylib est maintenant dans IASP01, le paramètre de commande doit être changé en /IASP01/qsys.lib/mylib/mysavf.file.

Une dernière différence de programmation concerne les opérations (du genre SQL) qui établissent des connexions avec une base de données. Nous sommes habitués à la présence d’une base de données intégrée sur l’IBM i. Avec IASP, il y a une base de données pour SYSBAS (par défaut, elle porte le nom du système) et une pour chaque IASP. Si vous vous connectez à la mauvaise base de données, la bibliothèque que vous recherchez n’y sera pas (ou, pis encore, elle sera dans la copie TEST au lieu de la copie PROD !)

Vous vous en doutez, les IASP demandent un peu de travail et d’analyse. Mais c’est une technologie mature qui fonctionne bien dès lors qu’on tient compte de toutes les différences. Une fois encore, il vaut mieux acquérir une formation (IBM Rochester offre un atelier juste sur l’IASP) et faire appel à un expert.