La continuité de l’activité avec LPAR

moins) deux manières
possibles d’assurer la continuité de
l’activité.
Une première méthode consiste à 
configurer un serveur en double avec
exactement les mêmes ressources et
le même nombre de partitions – pour
cloner le serveur primaire. Il faudra
dans ce cas répliquer les changements
apportés à  la base de données et aux
applications de nombreuses partitions
source aux partitions cible.
La deuxième méthode consiste à 
instaurer la haute disponibilité en distribuant
les charges de travail critiques
sur les deux serveurs et en faisant
jouer au reste des partitions le
rôle de partitions de secours pour les
partitions source. Ainsi, les partitions
qui garantissent la continuité de l’activité
sur le système A peuvent valider
les services de réplication pour la
haute disponibilité sur les partitions
du système B. De même, les partitions
critiques sur le système B peuvent décider
de choisir des partitions du système
A pour assurer la continuité.
Ce scénario a un double avantage :
il répartit les charges de travail critiques
sur deux serveurs et il simplifie
la reprise en cas de défaillance système
sur l’un des serveurs. Cette pratique
permet aux utilisateurs de LPAR
d’optimiser des partitions haute disponibilité
avec suffisamment de ressources
pour s’adapter aux changements
de journaux, puis commuter
dynamiquement les ressources des
partitions non critiques vers les partitions
haute disponibilité dès que cela
s’avère nécessaire pour assurer la continuité de l’activité.
La figure 1 illustre une combinaison
de ces approches. IASP36 est
composé d’unités de disque logées
dans une tour d’I/O commutable. A
noter que la commutation des pools
de disques indépendants entre deux
partitions logiques peut s’effectuer au
niveau d’un processeur d’I/O. Une
tour d’I/O n’est requise que quand on
commute des pools de disques indépendants
entre deux serveurs. Dans
cet exemple, la tour d’I/O est sur la
même boucle HSL (High Speed Link)
que deux systèmes, dont l’un comporte
quatre partitions logiques. En
supposant que les noeuds C et D et le
second serveur, noeud E, sont définis
comme étant dans le même domaine
d’unité (device domain), le pool de
disques indépendants peut être commuté
entre ces trois noeuds.
C’est intéressant quand, par
exemple, le système primaire fait l’objet
d’une maintenance programmée,
comme des correctifs d’application
ou de programme, ou des mises à  niveau
du système d’exploitation. En
faisant le nécessaire pour s’assurer
que l’application est indépendante
des changements du système d’exploitation,
on peut commuter les utilisateurs
et leurs données vers une
autre partition ou un autre système.
Supposons, par exemple, que la
partition D de la figure 1 soit une partition
de test et qu’elle contienne la
dernière release d’OS/400. La partition
C utilise une release précédente.
Une fois que la release a été vérifiée
dans la partition D, les utilisateurs et
leurs données de la partition C peuvent
être commutés sur la partition D,
et on peut déclencher une mise à  niveau
de release programmée sur la
partition C. Après mise à  niveau du
système d’exploitation, les utilisateurs
et leurs données de la partition D
peuvent être rebasculés sur la partition
C. Cette façon de faire réduit le
temps d’immobilisation qu’entraînent les mises à  niveau des nouvelles
releases.