Planifier la disponibilité

le temps d’immobilisation, quelle qu’en soit la cause. De nombreux facteurs peuvent contribuer à  l’immobilisation : maintenance (mise à  niveau du matériel et du logiciel, par exemple), coupures de courant, processus de sauvegarde qui requièrent un système dédié et autres.

  Il existe de nombreuses technologies iSeries pour augmenter la disponibilité en réduisant le temps d’immobilisation. L’examen détaillé de ces technologies dépasse le cadre de cet article, mais la liste suivante peut fournir quelques pistes :

• RAID-5 est une méthode de protection des données presque universellement reconnue comme un standard. Elle implique une relation de données logique entre le contenu des données sur plusieurs volumes disques identiques. RAID-5 est une méthode économique de protection contre un crash de disque, mais au détriment des performances de celui-ci.

• Avant RAID-5, les disques en miroir étaient le niveau de continuité de la disponibilité des disques généralement reconnu. Il consiste à  avoir un disque  » chaud  » en double pour chaque unité de disque. A la fin des années 90, le mode miroir a été largement supplanté par RAID-5, mais voilà  qu’il fait son retour dans le monde d’axes disques de plus grande taille, où la contention des têtes de disque pose un problème croissant.

• SMAPP (System Managed Access Path Protection) protège les voies d’accès ouvertes contre une défaillance système pendant les heures ouvrables. SMAPP limite le temps nécessaire pour reconstruire des voies d’accès après une fermeture anormale et journalise les voies d’accès en coulisse. A compter de la V3R1, SMAPP est actif par défaut. Sa valeur initiale de 150 minutes a été ramenée à  90 minutes dans la V4R5.

• La journalisation consiste à  enregistrer une copie de chaque changement (ajout, mise à  jour ou suppression de l’enregistrement) apporté à  un fichier base de données, zone de données ou file d’attente de données. Sur l’iSeries, la journalisation utilise deux objets en relation étroite : un journal (*jrn) est un objet gérant qui stocke les informations sur chaque transaction dans un journal receiver (*jrnrcv), qui est lui-même un objet de capture de données. La V4R2 offre la journalisation à  distance, dans laquelle le journal récepteur (journal receiver) réside à  la fois sur le système local et un système distant. L’OS/400 V5R1 supporte la journalisation Lecture (Read) (en plus d’ajout, mise à  jour et suppression), qui enregistre chaque transaction qui visualise des données. Ce type de journalisation est lourd et ne contribue pas à  la reprise des données, même s’il est utile pour l’audit.

• Le contrôle de validation (commitment) permet aux programmeurs de contrôler les mises à  jour de bases de données au niveau des transactions logiques. Dans un tel environnement, on définit toutes les mises à  jour qui constituent une transaction logique complète et on s’assure que toutes les, ou aucune des, transactions sont prises en compte (post). Il s’agit d’éviter les problèmes causés par des mises à  jour partielles, comme dans le cas où un fichier de stock n’est pas synchronisé avec un fichier de commandes ouvertes. Bien que le contrôle de validation existe depuis le System/38 CPF Release 5.0, il est peut utilisé sur l’iSeries. Le contrôle de validation suppose un modèle de programmation spécifique et l’utilisation de la journalisation. La fiabilité de l’iSeries est telle que les utilisateurs ont rarement besoin d’un tel niveau de complexité. Toutefois, ceux qui se convertissent à  l’iSeries à  partir d’autres architectures, utilisent fréquemment le contrôle de validation.

• Les ASP (Auxiliary Storage Pools) utilisateur ou les Disk Pools en terminologie OpsNav, offrent un pool séparé de stockage à  un seul niveau qui survivra à  une défaillance disque dans un autre pool de stockage. Les ASP aident aux performances de la journalisation et des fichiers de sauvegarde.

• Le logiciel haute disponibilité proposé par des fournisseurs tiers réplique les informations entre deux systèmes ou plus afin de créer une sauvegarde actualisée des données et des applications. La journalisation, y compris la journalisation à  distance, joue un important rôle sousjacent pour des solutions haute disponibilité. Le logiciel haute disponibilité peut collaborer avec d’autres niveaux de protection, comme RAID-5, et il admet la séparation physique des systèmes en cas de sinistre régional.

• Le clustering consiste à  relier entre eux des systèmes multiples pour obtenir la redondance. Le but ultime est d’assurer une transition de système à  système via la prise en main d’IP en cas de défaillance système. En principe, le clustering est associé au logiciel haute disponibilité (qui requiert la journalisation) et à  des modifications du logiciel utilisateur. L’adoption du clustering est plutôt timide.

fenêtre de panne lors d’une opération de sauvegarde. Réduire la panne demande peu d’efforts, mais il faudra un plan solide et du code pour bien gérer le processus. L’élimination de la panne de sauvegarde est complexe et demande la journalisation, le contrôle de validation (commitment), et un plan de restauration plus compliqué.

En utilisant tout ou partie de ces fonctions, vous éviterez peut-être la mise en oeuvre du plan antisinistre, et c’est après tout la meilleure reprise sur sinistre qui soit.