Mise au travail des disques commutés

conditions suivantes existent, comme l’illustre la figure ci-dessous :

· Winter est le nom du cluster
· Snow et Cold sont les noms des noeuds dans le cluster
· January est domaine d’unité qui contient les noeuds Snow et Cold
· Les unités résilientes sont des lecteurs de disques contenus dans une tour qui se trouve sur une liaison HSL entre les deux noeuds dans le domaine d’unité

A ce stade, nous avons défini le matériel et le domaine d’unité des disques commutés. Cependant, pour définir l’ASP comme un ensemble de disques que l’on peut commuter entre les deux noeuds dans le domaine d’unité, il nous faut solliciter davantage le cluster OS/400.

Créer un CRG (Cluster Resource Group) d’unités résilientes. On utilise les CRG pour définir la résilience des données, applications et unités (nouveau dans la V5R1). Ainsi, pour définir et contrôler l’emplacement de nos unités commutées, nous créons une unité résiliente CRG qui comporte plusieurs éléments clé :

· Les désignations de noeuds primaire et de sauvegarde. Cet élément du CRG indique simplement quel noeud possèdera les unités de disques initialement et quel noeud s’appropriera les disques en cas de défaillance du noeud primaire.

· Les unités capables de passer du primaire à  la sauvegarde. Cet élément indique l’ASP qui sera commuté entre les systèmes. Dans notre exemple, nous n’avons qu’un ASP indépendant, mais il pourrait y en avoir plus. De même, nous n’avons qu’une tour, mais il pourrait y en avoir jusqu’à  trois (selon le matériel du système) ; un ASP indépendant peut être réparti sur plusieurs tours. Quand le noeud primaire échoue, toutes les tours qui contiennent des disques commutables passent du noeud primaire au noeud de sauvegarde.

· Une indication de variation (vary on). Ce réglage automatise la variation (vary on) des unités chaque fois que des disques sont commutés d’un noeud sur un autre. L’acte de commutation des unités peut se produire quand un système primaire échoue ou qu’une action administrative commute les lecteurs de disques. Dans les deux cas, l’action de variation est effectuée d’après l’indication de variation que l’on a définie. Aucun autre événement du cluster ne peut faire varier on ou off les unités.

· Un programme de sortie CRG. Ce programme écrit par l’utilisateur est appelé chaque fois qu’une action du cluster se déroule. Ce programme peut gérer des conditions que l’OS/400 ne traite pas automatiquement. Ainsi, il existe plusieurs événements de cluster dans lesquels une variation on ou off peut être souhaitable, mais l’OS/400 n’effectue pas la variation on ou off. Dans ces conditions, le programme écrit par l’utilisateur peut se charger de la fonction vary on.

En créant notre CRG d’unités résilientes, nous avons défini la résilience de nos disques. Pour l’activer, nous utilisons une opération du cluster pour démarrer le CRG. Comme l’OS/400 ne fera pas varier on automatiquement les unités pendant une opération de démarrage, le programme de sortie doit effectuer cette fonction. Dans notre exemple, ResDev sera le CRG d’unités résilientes.

Créer un CRG applicatif. Un CRG applicatif effectue beaucoup des mêmes fonctions qu’un CRG d’unité résiliente, à  cela près qu’il est utilisé pour fournir l’emplacement primaire pour les utilisateurs de notre application. Bien que le CRG d’unités résilientes fournisse les disques à  commuter entre les noeuds, le CRG applicatif fournit une adresse IP que l’on peut commuter entre un noeud primaire et de sauvegarde. Ainsi, nos utilisateurs accèdent au système via une adresse IP gérée par un CRG et des unités d’accès contrôlées par un CRG.

Dans notre exemple, Shovel est le nom du CRG applicatif (figure 4). Comme on peut le voir, l’adresse IP est démarrée et la tour commutable est actuellement activée sur le système primaire. En cas de défaillance, la tour et l’adresse IP seront déplacées sur le système de sauvegarde (figure 5). Le support du cluster OS/400 et les programmes de sortie associés au CRG et écrits par l’utilisateur replacent l’application et les disques commutés. En outre, le support du cluster OS/400 peut varier on automatiquement les unités commutées sur le système de sauvegarde. Quand on remet en service le primaire original, il faut une action administrative pour rendre l’application et les disques commutés au primaire original. En outre, tant qu’un utilisateur sera en train d’accéder aux données sur les disques commutés, les disques ne seront pas replacés. Par conséquent, avant d’essayer de recommuter les disques sur les systèmes originaux, il faut que tous les utilisateurs du contenu des disques mettent fin à  leurs travaux.