IBM i

Version 7.3.0

Disponibilité
Haute disponibilité - Présentation

IBM
IBM i
Version 7.3.0

Disponibilité
Haute disponibilité - Présentation

IBM
 Important
Avant d'utiliser le présent document et le produit associé, prenez connaissance des informations générales figurant à la
section «Remarques», à la page 35.

LE PRESENT DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE. IBM
DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES INFORMATIONS EN CAS DE
CONTREFACON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL DONNE.
Ce document est mis à jour périodiquement. Chaque nouvelle édition inclut les mises à jour. Les informations qui y
sont fournies sont susceptibles d'être modifiées avant que les produits décrits ne deviennent eux-mêmes
disponibles. En outre, il peut contenir des informations ou des références concernant certains produits, logiciels ou
services non annoncés dans ce pays. Cela ne signifie cependant pas qu'ils y seront annoncés.
Pour plus de détails, pour toute demande d'ordre technique, ou pour obtenir des exemplaires de documents IBM,
référez-vous aux documents d'annonce disponibles dans votre pays, ou adressez-vous à votre partenaire
commercial.
Vous pouvez également consulter les serveurs Internet suivants :
v http://www.fr.ibm.com (serveur IBM en France)
v http://www.ibm.com/ca/fr (serveur IBM au Canada)
v http://www.ibm.com (serveur IBM aux Etats-Unis)
Compagnie IBM France
Direction Qualité
17, avenue de l'Europe
92275 Bois-Colombes Cedex
Cette édition s'applique à IBM i 7.3 (numéro de produit 5770-SS1) et à toutes les éditions et modifications
ultérieures, sauf mention contraire dans les nouvelles éditions. Elle n'est pas compatible avec tous les modèles RISC
et CISC.
Le présent document peut contenir des références au microcode sous licence. Le microcode sous licence est un code
machine pour lequel une licence d'utilisation vous est accordée conformément aux dispositions des Conditions
d'Utilisation du Code Machine IBM.
© Copyright IBM Corporation 2002, 2015.
 Table des matières
Avis aux lecteurs canadiens . . . . . . v | Présentation d'IBM PowerHA SystemMirror for i . . 18
| Comparaison des technologies de résilience des
Présentation de la haute disponibilité . . 1 | données PowerHA . . . . . . . . . . . 19
| IBM i 7.3 - Nouveautés . . . . . . . . . . . 1
| Unité logique (LUN) commutée . . . . . 19
Présentation de la haute disponibilité - Fichier PDF . 1
| Protection géographique par disque miroir . . 20
Avantages de la haute disponibilité . . . . . . . 2
| Fonction Metro Mirror. . . . . . . . . 22
Temps d'indisponibilité planifiés . . . . . . . 2
| Global Mirror. . . . . . . . . . . . 23
Arrêts non planifiés . . . . . . . . . . . 3
| DS8000 Full System HyperSwap . . . . . 24
Reprise après incident . . . . . . . . . . 4
| DS8000 HyperSwap avec pools de mémoire
Réduction de la fenêtre de sauvegarde. . . . . 5
| secondaire indépendants (IASP) . . . . . 25
| Scénarios de cas d'utilisation . . . . . 25
Equilibrage de charge . . . . . . . . . . 6
Critères de la haute disponibilité . . . . . . . 7
| FlashCopy . . . . . . . . . . . . . 31
Budget . . . . . . . . . . . . . . . 7
| Technologies à haute disponibilité combinées . . 31
| Gestion de la haute disponibilité . . . . . . 31
Besoins en temps de disponibilité . . . . . . 7
Vue d'ensemble des types d'indisponibilité . . . 8
| Interfaces IBM PowerHA SystemMirror for i 31
| Interface graphique de PowerHA . . . . 32
Objectif de temps de reprise (RTO) . . . . . . 9
Objectif de point de reprise (RPO) . . . . . . 9
| Option 41 (ressources commutables à haute
| disponibilité) . . . . . . . . . . . . 32
Besoins en résilience . . . . . . . . . . . 9
| Détection avancée des défaillances des noeuds 33
Reprise en ligne et commutation automatiques 10
| Fonction de haute disponibilité dans le
Critères de distance. . . . . . . . . . . 11
| système d'exploitation de base . . . . . . 33
Nombre de systèmes de secours . . . . . . 11
Présentation de la haute disponibilité - Informations
Accès à une copie secondaire des données . . . 11
connexes . . . . . . . . . . . . . . . 33
Performances du système. . . . . . . . . 12
Composants de la haute disponibilité . . . . . . 12
Résilience des applications . . . . . . . . 13 Remarques . . . . . . . . . . . . . 35
Niveaux de résilience des applications . . . . 14 Documentation sur l'interface de programmation . . 37
Résilience des données . . . . . . . . . 14 Marques . . . . . . . . . . . . . . . 37
Résilience de l'environnement . . . . . . . 17 Dispositions . . . . . . . . . . . . . . 37
Simplicité . . . . . . . . . . . . . . 18

© Copyright IBM Corp. 2002, 2015 iii

iv IBM i - Haute disponibilité - Présentation
Avis aux lecteurs canadiens
Le présent document a été traduit en France. Voici les principales différences et particularités dont vous
devez tenir compte.

Illustrations

Les illustrations sont fournies à titre d'exemple. Certaines peuvent contenir des données propres à la
France.

Terminologie

La terminologie des titres IBM peut différer d'un pays à l'autre. Reportez-vous au tableau ci-dessous, au
besoin.

IBM France IBM Canada

ingénieur commercial représentant
agence commerciale succursale
ingénieur technico-commercial informaticien
inspecteur technicien du matériel

Claviers

Les lettres sont disposées différemment : le clavier français est de type AZERTY, et le clavier
français-canadien de type QWERTY.

OS/2 et Windows - Paramètres canadiens

Au Canada, on utilise :
v les pages de codes 850 (multilingue) et 863 (français-canadien),
v le code pays 002,
v le code clavier CF.

Nomenclature

Les touches présentées dans le tableau d'équivalence suivant sont libellées différemment selon qu'il s'agit
du clavier de la France, du clavier du Canada ou du clavier des États-Unis. Reportez-vous à ce tableau
pour faire correspondre les touches françaises figurant dans le présent document aux touches de votre
clavier.

© Copyright IBM Corp. 2002, 2015 v

Brevets

Il est possible qu'IBM détienne des brevets ou qu'elle ait déposé des demandes de brevets portant sur
certains sujets abordés dans ce document. Le fait qu'IBM vous fournisse le présent document ne signifie
pas qu'elle vous accorde un permis d'utilisation de ces brevets. Vous pouvez envoyer, par écrit, vos
demandes de renseignements relatives aux permis d'utilisation au directeur général des relations
commerciales d'IBM, 3600 Steeles Avenue East, Markham, Ontario, L3R 9Z7.

Assistance téléphonique

Si vous avez besoin d'assistance ou si vous voulez commander du matériel, des logiciels et des
publications IBM, contactez IBM direct au 1 800 465-1234.

vi IBM i - Haute disponibilité - Présentation

 Présentation de la haute disponibilité
La continuité opérationnelle désigne la capacité d'une entreprise à résister aux temps d'indisponibilité (arrêts
planifiés ou non, pannes, sinistres) et à faire fonctionner normalement et sans interruption des services
importants, en respectant les contrats de niveau de service (SLA) qu'elle s'est fixés. Pour obtenir le niveau
de continuité opérationnelle recherché, vous devez sélectionner un ensemble de services, de logiciels, de
matériels et de procédures, les décrire dans un plan documenté, les implémenter et les mettre en pratique
régulièrement. La solution de continuité opérationnelle doit englober les données, l'environnement
d'exploitation, les applications, l'environnement hébergeant les applications et l'interface utilisateur. Pour
qu'elle soit considérée comme performante et complète, elle doit faire en sorte que tous ces éléments
soient disponibles.

La continuité opérationnelle inclut la reprise après incident et la haute disponibilité. Elle peut être définie
comme la capacité à résister à tous les types d'indisponibilité (arrêts planifiés ou non et sinistres), et à
assurer le traitement ininterrompu de toutes les applications importantes. L'objectif final est d'atteindre
un temps d'indisponibilité inférieur à 0,001 % de la durée du service totale. Un environnement à haute
disponibilité se caractérise par des objectifs qui sont plus exigeants en matière de temps de reprise
(quelques secondes à quelques minutes) et de point de reprise (aucune interruption pour les utilisateurs)
que dans le cadre d'un scénario de reprise après incident.

Les solutions à haute disponibilité assurent une reprise en ligne entièrement automatique sur un système
de secours, permettant ainsi aux utilisateurs et aux applications de continuer à travailler sans
interruption. Ces solutions doivent être capables de fournir un point de reprise immédiat. En même
temps, elles doivent garantir un temps de reprise très supérieur à celui d'une topologie de solution sans
haute disponibilité.

| IBM i 7.3 - Nouveautés

| Consultez les nouvelles informations de l'ensemble de rubriques de la Présentation de la haute
| disponibilité.

| Numéro de licence sous licence IBM® PowerHA SystemMirror for i 5770-HAS) -

| version 7.2 améliorée

| Le logiciel sous licence IBM PowerHA SystemMirror for i n'est pas en cours d'actualisation à la version
| 7.3. Le numéro de logiciel sous licence (5770-HAS) 7.2 s'exécute donc sous l'IBM i 7.3 ou l'IBM i 7.2.

| IBM PowerHA for i Enterprise Edition a été amélioré pour prendre en charge DS8000 HyperSwap avec
| pools de mémoire secondaire indépendants (IASP). Cette nouvelle fonction garantit une durée
| d'immobilisation quasi-nulle en cas d'indisponibilités planifiées et non planifiées liées au stockage et elle
| peut être utilisée avec d'autres technologies PowerHA de type IASP. Cette fonction est fournie via une
| nouvelle PTF de fonction PowerHA.

| Dans IBM Knowledge Center, les termes IASP et pool de stockage sur disque indépendant sont
| synonymes.
|
| Présentation de la haute disponibilité - Fichier PDF
| Nous vous proposons un fichier PDF de la présente documentation que vous pouvez afficher et
| imprimer.

© Copyright IBM Corp. 2002, 2015 1

| Pour afficher ou télécharger la version PDF de ce document, sélectionnez Implémentation de la haute

| disponibilité .

| Vous pouvez afficher ou télécharger ces PDF d'ensembles de rubriques connexes :

| v Technologies à haute disponibilité contient les rubriques suivantes :

| – Technologie de mise en grappe IBM i
| – Détection avancée des défaillances des noeuds
| – Domaine d'administration de grappe
| – Technologies de réplication de données PowerHA
– Gestion de la haute disponibilité
– Surveillance et contrôle des ressources

v Implémentation de la haute disponibilité contient les rubriques suivantes :

– Installation du programme sous licence IBM PowerHA SystemMirror for i (5770-HAS)
– Désinstallation du programme sous licence IBM PowerHA SystemMirror for i (5770-HAS)
| – Planification de la solution à haute disponibilité
– Implémentation de PowerHA
– Gestion de PowerHA
– Identification et résolution des incidents d'une solution à haute disponibilité

Sauvegarde des fichiers PDF

Pour sauvegarder un fichier PDF sur votre poste de travail afin de l'afficher ou de l'imprimer, procédez
comme suit :
1. Cliquez avec le bouton droit de la souris sur le lien PDF dans votre navigateur.
2. Cliquez sur l'option d'enregistrement en local du fichier PDF.
3. Indiquez le répertoire dans lequel il doit être enregistré.
4. Cliquez sur Enregistrer.

Téléchargement d'Adobe Reader

Adobe Reader doit être installé sur votre système pour que vous puissiez afficher ou imprimer ces
fichiers PDF. Une version gratuite de ce logiciel est téléchargeable sur le site Web Adobe
(www.adobe.com/products/acrobat/readstep.html) .

Avantages de la haute disponibilité

La haute disponibilité protège les entreprises contre les pertes de chiffre d'affaires en cas d'interruption de
l'accès à leurs données et leurs applications critiques.

Pour choisir une solution à haute disponibilité, vous devez commencer par identifier tous les aspects des
problèmes de disponibilité que vous souhaitez résoudre. En ce qui concerne la continuité opérationnelle,
ces problèmes peuvent être divisés en cinq grandes catégories.

Temps d'indisponibilité planifiés

La haute disponibilité de l'IBM i peut réduire l'impact sur vos clients et vos utilisateurs chaque fois que
vous devez mettre hors ligne des systèmes ou des données pour exécuter des tâches de maintenance
indispensables telles que les sauvegardes nocturnes ou l'installation de nouveaux matériels ou logiciels.

2 IBM i - Haute disponibilité - Présentation

Au fur et à mesure qu'une entreprise se développe, le temps de disponibilité devient un facteur de plus
en plus important. La fenêtre de maintenance de vos systèmes peut se réduire radicalement. Les temps
d'indisponibilité planifiés concernent notamment les sauvegardes sur bande et les mises à niveau des
applications et du système d'exploitation. Combien d'heures par semaine l'application peut-elle être
indisponible sans impact néfaste sur votre activité métier ? Les temps d'indisponibilité sont en général la
raison la plus courante qui justifie l'emploi d'une solution à haute disponibilité.

L'IBM i propose une solution de disponibilité pour système unique qui privilégie la maintenance
simultanée des matériels et des logiciels et la redondance matérielle. Toutefois, les opérations réalisables
au niveau d'un système unique ont une limite. Les technologies IBM i à haute disponibilité, telles que les
grappes et les pools de stockage sur disque indépendants, permettent de basculer la production sur un
deuxième système ou de disposer d'un deuxième ensemble de données. Ces solutions IBM i à haute
disponibilité permettent à l'entreprise de poursuivre son activité pendant l'exécution de la maintenance
du ssytème. Elles atténuent ainsi l'impact des temps d'indisponibilité planifiés.
Sauvegardes hors ligne sur bande
Les sauvegardes sur bande peuvent être effectuées à partir d'un système de secours sur lequel
réside une deuxième copie des données de l'utilisateur.
Correctifs ou mises à niveau des applications et du système d'exploitation
Il est possible d'effectuer une mise à niveau sans interruption pour installer des correctifs ou des
mises à jour. Les correctifs peuvent être appliqués au système de secours pendant que le système
principal reste opérationnel en production. La charge de travail peut alors être basculée vers le
système de secours et les correctifs être appliqués au système principal. Une fois la mise à niveau
terminée, la production peut être rebasculée vers le système principal.
Maintenance matérielle
Les modifications qui ne peuvent pas être gérées par la maintenance matérielle simultanée
nécessitent en général un arrêt du système. Une solution à haute disponibilité permet de basculer
la production sur un système de secours et d'exécuter la maintenance matérielle sans impact pour
l'entreprise.
Concepts associés:
«Vue d'ensemble des types d'indisponibilité», à la page 8
Contre quel type d'indisponibilité (arrêt ou panne) l'entreprise tente-t-elle de se prémunir ? La réduction
de la fenêtre de sauvegarde, la maintenance planifiée, les arrêts non prévus, ou les sinistres frappant un
site sont des événements que vous devez prendre en compte lorsque vous choisissez une solution à haute
disponibilité.
Information associée:
Réduction des indisponibilités planifiées

Arrêts non planifiés

Les solutions à haute disponibilité IBM i assurent une protection contre les arrêts non planifiés dus aux
erreurs humaines, aux problèmes logiciels, aux pannes matérielles et aux problèmes environnementaux.

Au fur et à mesure que l'entreprise se développe, la protection contre les événements imprévus devient
un facteur primordial. Malheureusement, c'est la particularité des événements non planifiés : leur
imprévisibilité. Les besoins en haute disponibilité de l'entreprise doivent donc déterminer en priorité la
plage de temps qui est la plus importante pour l'activité métier. Le coût d'un arrêt ou d'une panne au
moment le plus critique doit être pris en compte lorsque vous sélectionnez les solutions à haute
disponibilité et leur mode d'implémentation.

Les arrêts non planifiés peuvent être classés en différentes catégories :

Erreur humaine
Malheureusement, les erreurs humaines sont sans doute le principal facteur des arrêts non
planifiés. Les causes sont multiples : procédures mal suivies, avertissements négligés, manque de

Présentation de la haute disponibilité 3

 formation, ou problèmes de communication et malentendus entre les groupes. Toutes ces raisons
peuvent provoquer des arrêts non planifiés qui ont des conséquences néfastes pour l'entreprise.
Problèmes logiciels
La complexité inhérente aux applications, aux systèmes d'exploitation, aux middleware ou aux
bases de données peut provoquer des arrêts non planifiés. Chaque entreprise est unique et les
interactions entre différents composants logiciels peuvent être source de problèmes.
Panne matérielles
A un moment donné, les équipements mécaniques subissent inévitablement des pannes. Les
composants électriques sont soumis à des modifications de leur environnement (chaleur,
humidité, décharges d'électricité statique) qui peuvent entraîner des pannes prématurées. Des
câbles peuvent être endommagés, des connexions peuvent céder.
Problèmes environnementaux
Les coupures de courant, les pannes du réseau ou de la climatisation peuvent rendre indisponible
un système unique. Vous pouvez mettre en place des mesures de redondance pour régler certains
de ces problèmes, mais elles ont leurs limites.

La reprise suite à des arrêts non planifiés dans un environnement à haute disponibilité consiste à opérer
une reprise en ligne vers un système de secours. Pendant que le problème est diagnostiqué et corrigé,
l'activité métier peut se poursuivre sur le serveur de secours.
Concepts associés:
«Vue d'ensemble des types d'indisponibilité», à la page 8
Contre quel type d'indisponibilité (arrêt ou panne) l'entreprise tente-t-elle de se prémunir ? La réduction
de la fenêtre de sauvegarde, la maintenance planifiée, les arrêts non prévus, ou les sinistres frappant un
site sont des événements que vous devez prendre en compte lorsque vous choisissez une solution à haute
disponibilité.
Information associée:
Réduction des indisponibilités non planifiées
Prévention des indisponibilités non planifiées
Restauration des modifications récentes après une indisponibilité non planifiée
Restauration des données perdues après une indisponibilité non planifiée

Reprise après incident

La reprise après incident comprend l'ensemble des ressources, les plans, les services et les procédures qui
permettent de d'effectuer la reprise des applications métier critiques sur un site distant en cas de sinistre.

Au fur et à mesure que l'entreprise se développe, la reprise après incident à partir d'une sauvegarde sur
bandes depuis un site distant peut ne pas être faisable dans les délais requis par l'entreprise. Chaque site
physique est différent mais est forcément exposé à un type ou un autre de sinistre. Les incendies, les
tempêtes, les séismes et les ouragans ont des conséquences géographiques de grande portée. C'est la
raison pour laquelle les sites de sauvegarde distants sont de plus en plus éloignés les uns des autres.
Dans certains cas, les réglementations sectorielles peuvent aussi déterminer la distance minimum entre les
sites.

Quelques questions importantes sur les facteurs à prendre en compte dans la prévention des sinistres :
v Quelles sont les conséquences financières pour l'entreprise en cas de sinistre ?
v Quand l'activité peut-elle reprendre la production ?
v A partir de quel point de cohérence puis-je effectuer la reprise ?
v Combien de bande passante de communication puis-je me permettre ?
v Quelle est la solution de reprise après incident viable au vu des critères de distance auxquels je suis
soumis ?

4 IBM i - Haute disponibilité - Présentation

Les solutions IBM i à haute disponibilité peuvent être adaptées en fonction des réponses à ces questions.
Toutes les possibilités sont envisageables : renforcer un site, louer des équipements qui seront chargés de
restaurer les bandes et de relancer l'activité, ou mettre en place une sauvegarde instantanée et actualisée
sur un site distant capable de prendre le relais du site de production.
Information associée:
Planning de reprise après incident
Recovering your system

Réduction de la fenêtre de sauvegarde

Les solutions IBM i à haute disponibilité permettent de réduire le temps d'indisponibilité de votre
système ou de vos services pendant les sauvegardes. Le temps nécessaire à l'exécution d'une sauvegarde,
de A jusqu'à Z, est appelé une fenêtre de sauvegarde. La difficulté consiste à sauvegarder la totalité des
données dans cette fenêtre de temps.

Les techniques les plus évidentes permettant de réduire ou d'éliminer la fenêtre de sauvegarde consistent
à écourter la durée de la sauvegarde ou à réduire la quantité des données sauvegardées. Elles
comprennent notamment :
Des technologies de bande optimisées
Les technologies de bande caractérisées par une plus grande rapidité et une densité suéprieure
permettent de réduire la durée totale de la sauvegarde.
Sauvegardes parallèles
L'utilisation simultanée de plusieurs unités de bande permet de réduire la durée de sauvegarde
en éliminant ou réduisant le traitement série sur une seule unité.
Sauvegarde sur des supports non amovibles
La sauvegarde sur des supports non amovibles, par exemple sur des unités de stockage à accès
direct (DASD) permet de réduire la fenêtre de sauvegarde. Les données peuvent être migrées
ultérieurement sur des supports amovibles.
Archivage des données
Les données non nécessaires aux opérations normales de production peuvent être archivées et
mises hors ligne. Elles ne sont remises en ligne que lorsque cela est nécessaire, par exemple pour
exécuter un traitement en fin de mois ou de trimestre. La fenêtre de sauvegarde quotidienne est
réduite, car les données archivées ne sont pas inclues.
Les sauvegardes quotidiennes concernent uniquement les objets modifiés au cours de la journée
La fenêtre de sauvegarde peut diminuer de façon considérable si le pourcentage des objets non
modifiés est relativement élevé.

Les autres techniques de réduction des fenêtres de sauvegarde exploitent une deuxième copie des
données (réelle ou virtuelle). Ces techniques sont les suivantes :
Sauvegarde depuis un deuxième système
Les technologies de résilience des données, telles que la réplication logique, qui rendent
disponible une deuxième copie des données, permettent de déplacer la fenêtre de sauvegarde de
la copie principale vers la copie secondaire. Cette technique élimine la fenêtre de sauvegarde sur
le système principal. Par conséquent, elle n'affecte pas la production, car le traitement de la
sauvegarde est effectué sur un autre système.
Sauvegarde en mise à jour
Dans un environnement comprenant un seul système, une technique de sauvegarde en mise à
jour est utilisée, c'est-à-dire que les données sont sauvegardées alors que les applications sont en
production. Pour assurer l'intégrité et la possibilité d'utiliser les données, un point de contrôle
garantissant un point de cohérence est réalisé. Les images objet du point de contrôle sont
sauvegardées, pendant que les opérations de modification se poursuivent sur l'objet lui-même.
Les objets sauvegardés sont cohérents entre eux, ce qui vous permet de restaurer l'environnement

Présentation de la haute disponibilité 5

 d'application à un état connu. La sauvegarde en mise à jour peut aussi être déployée sur une
copie redondante obtenue par réplication logique. Cette technique permet de supprimer
efficacement la fenêtre de sauvegarde.
IBM System Storage FlashCopy
Cette technologie utilise la fonction IBM System Storage of FlashCopy sur un pool de stockage
sur disque indépendant. Un instantané de point de cohérence du pool est effectué sur un seul
serveur System Storage. La copie du pool de stockage sur disque indépendant est exécutée sur le
serveur System Storage. L'hôte ne détecte pas la copie. La mise en grappe permet d'activer la
copie sur le système de secours, afin d'effectuer des sauvegardes ou des opérations de traitement
hors ligne. Elle permet aussi de réintégrer le deuxième système dans la grappe sans provoquer
d'interruption. La mise en grappe prend en charge plusieurs pools de stockage sur disque
indépendant à partir du même système, ou à partir de plusieurs systèmes de production
connectés en même temps à l'unité de stockage.
Concepts associés:
«Vue d'ensemble des types d'indisponibilité», à la page 8
Contre quel type d'indisponibilité (arrêt ou panne) l'entreprise tente-t-elle de se prémunir ? La réduction
de la fenêtre de sauvegarde, la maintenance planifiée, les arrêts non prévus, ou les sinistres frappant un
site sont des événements que vous devez prendre en compte lorsque vous choisissez une solution à haute
disponibilité.
Information associée:
Replication overview

Equilibrage de charge
Les solutions IBM i à haute disponibilité peuvent être utilisées pour l'équilibrage de charge. Les
technologies les plus courantes d'équilibrage de charge consistent à déplacer le travail vers les ressources
disponibles. Par comparaison, les techniques courantes de gestion des performances transfèrent les
ressources vers les travaux ne répondant pas aux objectifs de performances.

Exemples de technologies d'équilibrage de charge (chacune avec ses propres implications en termes de
haute disponibilité) :
Routeurs frontaux
Ces routeurs gèrent toutes les requêtes entrantes puis utilisent un algorithme pour distribuer le
travail plus équitablement entre les serveurs disponibles. Les algorithmes peuvent être simples,
utilisant la distribution par répartition séquentielle (circulaire) ou complexe, basés sur les
performances réellement mesurées.
Serveurs d'applications multiples
Un utilisateur distribue le travail à l'aide d'une configuration ou d'une règle prédéfinie, sur
plusieurs serveurs d'applications. En général, l'association entre demandeur et serveur est
relativement statique, mais les demandeurs sont distribués aussi équitablement que possible sur
plusieurs serveurs.
Application distribuées multi-parties
Ces applications réagissent aux demandes des utilisateurs finaux qui émanent en fait de plusieurs
serveurs. La façon dont le travail est distribué reste invisible pour l'utilisateur. Chaque partie de
l'application exécute une tâche prédéfinie, puis transmet le travail au serveur suivant dans la
séquence. L'exemple le plus courant de ce type d'équilibrage de charge est une application à trois
niveaux avec un serveur dorsal de base de données.
Commutation contrôlée d'application
Le travail est au départ distribué d'une façon prédéterminée entre plusieurs serveurs. Un serveur
peut héberger plusieurs applications, plusieurs instances de la même application, ou les deux. Si
un serveur donné atteint un état de surcharge alors que les autres serveurs disposent d'une
capacité en excès, les opérateurs déplacent alors les applications ou les instances d'applications

6 IBM i - Haute disponibilité - Présentation

 avec les données associées depuis le serveur en surcharge vers les serveurs sous-exploités. Le
transfert de la charge de travail peut être manuel ou s'effectuer automatiquement, en fonction
d'une règle prédéfinie.
Information associée:
TCP/IP routing and workload balancing
Création de groupes de ressources en grappe homologues

Critères de la haute disponibilité

La haute disponibilité IBM i propose plusieurs technologies différentes de résilience des données et de
disponibilité des applications. Chacune de ces technologies a des caractéristiques différentes. Ces
caractéristiques doivent être choisies en fonction des besoins uniques de chaque application métier. Vous
devez avoir une vision claire des paramètres suivants et devez les prendre en compte avant de choisir la
technique de résilience des données convenant le mieux à votre entreprise.

Budget
Chaque solution à haute disponibilité implique un coût. Son coût doit être comparé aux avantages qu'elle
apporte à l'entreprise. Lorsque l'on demande aux clients quelle solution de haute disponibilité ils
souhaitent, la plupart répondent qu'il veulent une disponibilité continue avec un temps d'indisponibilité
nul. Bien que cela soit possible sur le plan technique, le coût de la protection assurée par une telle
solution risque d'être trop élevé.

La question essentielle qui se cache derrière la quantité de ressources à affecter à une solution à haute
disponibilité est “Quel est le coût d'un temps d'indisponibilité ?”. Les sites de sauvegarde, les systèmes
de secours et les copies de sauvegarde des données des applications ont tous un coût, mais aussi des
avantages. Tant que vous ne connaissez pas le coût réel de chaque unité de temps d'indisponibilité, il est
impossible d'attribuer une valeur réelle aux avantages apportés au client par la solution à haute
disponibilité.

Le coût de la solution est le coût total de possession, qui comprend le coût initial d'achat et de déploiement
de la solution, ses coûts d'exploitation, et tous les impacts éventuels en terme de rapport
coût/performance. Le coût est en général calculé sur la base d'une analyse minutieuse de l'impact sur
l'entreprise. Plusieurs postulats de départ influencent une telle analyse :
v Le facteur coût n'entre pas en ligne de compte.
v Le coût a une légère incidence sur la décision.
v Sur la base d'une analyse des indisponibilités, le coût de la solution doit respecter certaines contraintes
budgétaires.
v Le coût est un facteur important dans la décision.
v Le client rechigne à consacrer des dépenses à une solution de disponibilité, ou ne peut pas se le
permettre.

Besoins en temps de disponibilité

Les besoins en temps de disponibilité désignent la durée totale de disponibilité du système pour les
applications de utilisateurs finaux. La valeur est exprimée en pourcentage du total des heures de travail
planifiées.

Vous trouverez ci-après les pourcentages de disponibilité et les valeurs de temps d'indisponibilité
correspondantes pour des clients nécessitant une disponibilité permanente (24 heures sur 24, 365 jours
par an).
v Moins de 90% (temps d'indisponibilité de 876 heures ou plus (36 jours/an)
v 90 à 95% (temps d'indisponibilité de 438 à 876 heures/an)
v 95 à 99% (temps d'indisponibilité de 438 heures/an)

Présentation de la haute disponibilité 7

v 99,1 à 99,9% (temps d'indisponibilité de 8,8 à 88 heures/an)
v 99,99% (temps d'indisponibilité d'environ 50 minutes/an)
v 99,999% (temps d'indisponibilité d'environ 5 minutes/an)

En général, le coût par heure d'indisponibilité est utilisé comme un facteur déterminant dans les besoins
en temps de disponibilité. Concernant les arrêts non planifiés, les besoins en temps de disponibilité
doivent uniquement être basés sur les heures de travail planifiées. Cela signifie le coût d'une
indisponibilité doit être calculé en fonction du pire scénario possible.

Vue d'ensemble des types d'indisponibilité

Contre quel type d'indisponibilité (arrêt ou panne) l'entreprise tente-t-elle de se prémunir ? La réduction
de la fenêtre de sauvegarde, la maintenance planifiée, les arrêts non prévus, ou les sinistres frappant un
site sont des événements que vous devez prendre en compte lorsque vous choisissez une solution à haute
disponibilité.

Vous devez étudier les types d'indisponibilité contre lesquels vous voulez protéger vote entreprise.
Réduction de la fenêtre de sauvegarde
Dans un environnement à un seul système, la sauvegarde du système est la raison la plus
courante des arrêts planifiés. Mais, au fur et à mesure que les besoins de l'entreprise en
disponibilité de ses applications augmentent, le temps disponible pour la sauvegarde des données
continue à se réduire. Une solution à haute disponibilité vous permet d'effectuer des sauvegardes
hors ligne. Une sauvegarde hors ligne consiste à sauvegarder les données d'une application à
partir d'une copie de sauvegarde. Chacune des différentes technologies de résilience des données
offre des avantages différents.
Maintenance planifiée
La maintenance planifiée signifie que le système doit être arrêté pour permettre l'exécution de
mises à niveau d'applications, de logiciels et de matériels. Lorsque les horaires d'activité rendent
impossible la programmation de la maintenance planifiée, l'implémentation d'une solution à
haute disponibilité permettant la maintenance hors ligne peut être envisagée. Avec la maintenance
hors ligne, le système de secours est mis à niveau en premier. Lorsque l'environnement de
production est basculé vers le système mis à niveau, l'ancien système de production est alors mis
à niveau à son tour.
Arrêts non planifiés
Un arrêt non planifié est un temps d'indisponibilité survenant pendant les horaires d'activité. Il
peut être du à une erreur humaine, à des échecs d'applications ou de logiciels, à des pannes
matérielles ou des défaillances d'utilitaires, et a pour conséquence un arrêt du système de
production. La solution à haute disponibilité vous donne la possibilité de basculer
l'environnement de production vers un système de secours.
Sinistres frappant un site
Les catastrophes naturelles sont le type de sinistre affectant les sites qui viennent le plus
spontanément à l'esprit. Pour cette raison, la solution à haute disponibilité nécessite de disperser
géographiquement les systèmes. Les catastrophes naturelles ne sont cependant pas les seules
responsables. D'autres événements peuvent se produire et impacter votre site pendant une durée
prolongée : catastrophes d'origine humaine (par exemple fuites de produits chimiques) attaques
terroristes, coupures de courant géantes touchant toute une métropole. Chacune des solutions à
haute disponibilité présente des caractéristiques différentes en termes de délais et de restrictions
de distance. Vous devez prendre en compte le facteur des objectifs de temps de reprise (RTO) et
vous demander si vous allez exécuter des opérations normales sur le site distant, ou seulement
un sous-ensemble des processus métier.

Vous devez également envisager le niveau d'interruption qu'un utilisateur peut tolérer. L'impact sur
l'application peut être défini comme suit :

8 IBM i - Haute disponibilité - Présentation

v Ne constitue pas un problème. La disponibilité de l'application est le point le plus important. Une
détérioration des performances est acceptable à condition que la solution de disponibilité joue son rôle.
v Un certain degré de détérioration des performances est acceptable.
v Une légère détérioration des performances des performances est acceptable.
v Les performances ne doivent subir aucun impact.
Concepts associés:
«Temps d'indisponibilité planifiés», à la page 2
La haute disponibilité de l'IBM i peut réduire l'impact sur vos clients et vos utilisateurs chaque fois que
vous devez mettre hors ligne des systèmes ou des données pour exécuter des tâches de maintenance
indispensables telles que les sauvegardes nocturnes ou l'installation de nouveaux matériels ou logiciels.
«Arrêts non planifiés», à la page 3
Les solutions à haute disponibilité IBM i assurent une protection contre les arrêts non planifiés dus aux
erreurs humaines, aux problèmes logiciels, aux pannes matérielles et aux problèmes environnementaux.

Objectif de temps de reprise (RTO)

L'objectif de temps de reprise (RTO) est le délai nécessaire pour effectuer la reprise après un arrêt
(planifié, non planifié ou sinistre) et relancer le fonctionnement normal d'une application ou d'un
ensemble d'applications.

L'objectif de temps de reprise (RTO) peut être différent pour les arrêts planifiés, non planifiés ou les
sinistres. Les différentes technologies de résilience des données ont des objectifs de temps de reprise
différents. Les valeurs possibles des objectifs de temps de reprise sont les suivantes :
v Plus de 4 jours si ce délai est acceptable
v 1 à 4 jours
v Moins de 24 heures
v Moins de 4 heures
v Moins d'une heure
v Proche de zéro (quasi-immédiate)

Objectif de point de reprise (RPO)

L'objectif de point de reprise (RPO) est le point de cohérence jusqu'où vous devez préserver les données
en cas de panne. Les modifications des données précédant la panne ou le sinistre et qui interviennent au
moins dans cette plage de temps sont préservées grâce au processus de reprise. La valeur zéro est admise
et équivaut à une exigence de "perte de données zéro".

Les valeurs possibles de l'objectif de point de reprise (RPO) sont les suivantes :
v Dernière sauvegarde (hebdomadaire, quotidienne...)
v Début de la rotation de la dernière équipe de travail (8 heures)
v Dernière interruption majeure (4 heures)
v Dernier lot de travail (1 heure à plusieurs dizaines de minutes)
v Dernière transaction (plusieurs secondes à quelques minutes)
v Risque de pertes des modifications en cours (cohérence avec la coupure d'alimentation)
v Zéro perte de données

Besoins en résilience
L'entreprise doit identifier ce dont elle a besoin pour se protéger en cas de panne du système hébergeant
l'application. Les besoins en résilience englobent l'ensemble des applications, des données et des
environnements système qui doivent être protégés pendant tout le temps d'indisponibilité du système de
production. Ces entités restent disponibles pendant toute la reprise en ligne, même lorsque le système qui
les héberge tombe en panne.

Présentation de la haute disponibilité 9

Les options possibles sont les suivantes :
v Aucune protection n'est nécessaire
v Données d'application
v Données d'application et système
v Programmes d'application
v Etat de l'application
v Environnement d'application
v Protection de la totalité des communications et des connexions client
Concepts associés:
«Résilience des applications», à la page 13
La résilience des applications peut être évaluée en fonction de son impact sur les utilisateurs. Dans une
infrastructure de grappe IBM i, la résilience des applications est contrôlée par un objet du groupe de
ressources en grappe (CRG). A l'aide d'un programme d'exit, ce CRG fournit le mécanisme qui contrôle le
démarrage, l'arrêt, le redémarrage et la commutation de l'application de sauvegarde des systèmes. La
totalité de l'environnement d'application, y compris la réplication des données et les unités commutées,
peut être contrôlée via l'infrastructure de grappe comme une seule et unique entité.
«Résilience des données», à la page 14
La résilience des données correspond à la disponibilité des données nécessaires dans un environnement
de production. Plusieurs technologies permettent de satisfaire les besoins en résilience des données
décrits dans la section “Avantages de la haute disponibilité”. Ces technologies peuvent être divisées en
deux catégories principales sur l'IBM i : la réplication logique ou logicielle et la réplication matérielle ou
sur disque.
«Résilience de l'environnement», à la page 17
La résilience de l'environnement peut être divisée en deux parties : l'environnement physique et
l'environnement logique. L'environnement physique, qui relève en fait de la disponibilité pour un
système unique, privilégie les aspects tels que la redondance matérielle, la topologie de réseau,
l'infrastructure de l'alimentation et la capacité de refroidissement. L'environnement logique est
l'environnement qui héberge et exécute les applications. Il comprend les paramètres systèmes, les profils
utilisateur et les attributs système qui permettent à l'utilisateur d'exécuter l'application sur plusieurs
serveurs.

Reprise en ligne et commutation automatiques

L'entreprise doit définir le degré de contrôle qu'elle concède aux fonctions d'automatisation en cas des
arrêts non planifiés. Les solutions IBM i à haute disponibilité permettent de personnaliser le degré
d'interaction lors du traitement d'une reprise en ligne. En cas de panne, l'application peut effectuer
automatiquement une reprise en ligne sur un système de secours, y compris la totalité du démarrage de
l'environnement d'application.

Certains clients veulent cependant pouvoir contrôler la reprise en ligne. Dans ce cas, le système a besoin
d'une réponse pour lancer la reprise en ligne. Dans une solution dans laquelle une interaction
d'utilisateur est requise pour la reprise en ligne, le temps de réflexion (c'est-à-dire le temps nécessaire
pour prendre la décision de la reprise en ligne) est directement déduit de l'objectif de temps de reprise.
L'entreprise doit décider du degré de contrôle d'automatisation qui doit être accordé au système pendant
la reprise en ligne. Le temps nécessaire à la décision du lancement de la reprise en ligne sur le système
de secours ne doit pas excéder le temps nécessaire à l'exécution de la reprise en ligne elle-même.
Concepts associés:
Switchover
Information associée:
Reprise en ligne

10 IBM i - Haute disponibilité - Présentation

 Critères de distance
La distance entre les systèmes (dispersion géographique) a ses avantages mais reste soumise à des
limitations physiques et pratiques. Dans le cas d'une solution de reprise après incident, la possibilité
d'une dispersion géographique des systèmes est toujours avantageuse. En général, plus la distance est
grande entre les systèmes, plus la protection contre les sinistres à grande ampleur est élevée. Toutefois,
cette distance a une incidence sur l'environnement d'application.

Pour une solution de réplication des données, la distance implique un phénomène de temps d'attente. Il
s'agit du temps supplémentaire nécessaire aux données pour atteindre le système cible. Plus les systèmes
sont éloignés les uns des autres, plus le temps d'attente lié à la transmission des données est important. Il
existe deux types de modes de transmission des communications : mode synchrone et asynchrone.

Pour assurer la résilience des données, les communications synchrones nécessitent que le système cible
renvoie un accusé de réception pour signaler que la transmission de données a été reçue avant de
poursuivre. Ce processus ne garantit pas la perte des données en cours entre la source et la cible en cas
de panne. Toutefois, le temps d'attente de l'accusé de réception peut affecter les performances de
l'application.

Pour assurer la résilience des données, les communications asynchrones n'ont pas besoin que le système
cible renvoie un accusé de réception pour poursuivre la transmission des données. Comme ce mécanisme
n'attend pas d'établissement de liaison, les données envoyées peu avant la panne risquent d'être perdues.
C'est ce que l'on appelle la perte des données en cours.

L'application, la quantité des données envoyées et la dispersion géographique des systèmes déterminent
le mécanisme de transport à utiliser avec votre solution à haute disponibilité.
Information associée:
| Détermination de la configuration du site

Nombre de systèmes de secours

Les différentes technologies de résilience des données sont proposées avec des nombres variables de
systèmes de secours et de données d'application.

Dans un environnement à deux systèmes (sauvegarde unique), la maintenance planifiée laisse votre
entreprise vulnérable. En cas de défaillance pendant cette plage de temps, vous n'avez pas accès à la
reprise en ligne. Dans ce cas, vous pouvez préserver la continuité opérationnelle en ajoutant un autre
système de secours. Le nombre de systèmes de secours et le nombre des ensembles de données dont vous
avez besoin déterminent la technologie de résilience des données requise pour votre entreprise.

Accès à une copie secondaire des données

Les différentes technologies de résilience des données sont soumises à des restrictions différentes
concernant l'ensemble des données de sauvegarde. Les besoins liés à l'accès à l'ensemble des données de
sauvegarde doivent définir le niveau d'accès requis aux copies secondaires des données, dans le cas des
autres activités déchargées à partir des copies principales, par exemple les sauvegardes et les
requêtes/rapports. Vous devez prendre en compte la fréquence, la durée et le type d'accès requis à la
copie de sauvegarde des données.

Exemples de besoins :
v Aucun.
v Pendant les périodes hors production.
v Peu fréquent, mais pendant les périodes normales de production, pour de courtes durées
(quelques secondes à quelques minutes).
v Peu fréquent, mais pendant les périodes normales de production, pour des durées importantes.
v Fréquemment, pendant les périodes de production pour de courtes durées.

Présentation de la haute disponibilité 11

v Fréquemment, pendant les périodes de production pour des durées importantes.
v Quasiment en permanence (besoin d'accès quasi-continu).
Information associée:
Sauvegarde à partir d'une deuxième copie

Performances du système
L'implémentation de la haute disponibilité a souvent des implications sur les performances. L'entreprise
doit déterminer la technologie de résilience des données qu'elle va choisir en fonction de ses besoins.

L'implémentation de la haute disponibilité a souvent des implications diverses sur les performances. La
journalisation de la réplication logique et les opérations de la protection géographique par disque miroir
nécessitent des ressources système pour permettre une exécution normale. En outre, la journalisation
distante synchrone, la protection géographique par disque miroir en mode de livraison synchrone et les
technologies Metro Mirror s'exécutent toutes en mode de communication synchrone. Ce mode synchrone
génère un temps d'attente qui varie selon la distance et la topologie de réseau, avec des impacts sur
l'environnement d'application. Les besoins de l'entreprise et les tests permettent de déterminer la solution
viable pour le client.

La protection géographique par disque miroir prend aussi en charge un mode de livraison asynchrone
qui peut nécessiter des ressources supplémentaires (unité centrale, mémoire principale).

Les opérations de commutation et de reprise en ligne ne sont pas instantanées et nécessitent un certain
temps système. Chaque technologie a des caractéristiques différentes pour mettre en ligne un ensemble
de données ou l'environnement d'application tout entier.
Information associée:
Managing system performance
System values: Performance overview

Composants de la haute disponibilité

La haute disponibilité permet de continuer à pouvoir accéder aux applications et aux données métier
critiques en cas d'une interruption de service. Les solutions IBM i à haute disponibilité atténuent et
parfois éliminent totalement l'impact des arrêts planifiés ou non et des sinistres frappant tout un site. Ces
solutions IBM i se basent sur la technologie de grappe.

Une grappe se compose d'un ou de plusieurs systèmes (ou d'images du système d'exploitation) qui
partagent des ressources et des opérations de traitement et assurent une sauvegarde en cas de temps
d'indisponibilité. Avec la mise en grappe, la haute disponibilité n'est pas considérée comme un ensemble
de copies identiques de la même ressource dans ces systèmes, mais comme un ensemble de ressources
partagées qui fournissent en permanence des services essentiels aux utilisateurs et aux applications.

La mise en grappe ne constitue pas une solution de haute disponibilité à elle seule, mais c'est la
technologie principale sur laquelle reposent toutes les solutions IBM i de haute disponibilité.
L'infrastructure de grappe, appelée service-ressource de mise en grappe, fournit les mécanismes
sous-jacents permettant de créer et de gérer plusieurs systèmes et leurs ressources comme s'il s'agissait
d'une seule entité informatique homogénéisée. La mise en grappe surveille également les systèmes et les
ressources définis dans l'environnement à haute disponibilité afin de rechercher les pannes et prend les
mesures appropriées en fonction du type d'indisponibilité. La mise en grappe associe matériels et logiciels
afin de réduire le coût et d'atténuer l'impact des arrêts planifiés ou non, en restaurant rapidement les
services lorsque ces arrêts se produisent. Bien que la reprise ne soit pas instantanée avec une mise en
grappe, elle est néanmoins rapide.

La section suivante définit les principaux composants d'une solution à haute disponibilité.
Concepts associés:

12 IBM i - Haute disponibilité - Présentation

| «Présentation d'IBM PowerHA SystemMirror for i», à la page 18
Lorsque vous avez déterminé les objectifs et les besoins de votre entreprise, vous devez ensuite choisir la
solution IBM i à haute disponibilité adaptée à votre entreprise. IBM PowerHA SystemMirror for i est un
produit IBM qui fournit une solution complète à haute disponibilité pour les environnements de
production IBM i. Il assure la résilience des données, des applications et des environnements et offre une
| interface de gestion qui permet une configuration et un fonctionnement en toute transparence.

Résilience des applications

La résilience des applications peut être évaluée en fonction de son impact sur les utilisateurs. Dans une
infrastructure de grappe IBM i, la résilience des applications est contrôlée par un objet du groupe de
ressources en grappe (CRG). A l'aide d'un programme d'exit, ce CRG fournit le mécanisme qui contrôle le
démarrage, l'arrêt, le redémarrage et la commutation de l'application de sauvegarde des systèmes. La
totalité de l'environnement d'application, y compris la réplication des données et les unités commutées,
peut être contrôlée via l'infrastructure de grappe comme une seule et unique entité.

La résilience des applications est classifiée selon les catégories suivantes.

Pas de reprise de l'application
Suite à une panne ou un arrêt, les utilisateurs doivent redémarrer manuellement leurs
applications. En fonction de l'état des données, les utilisateurs déterminent à quel moment
redémarrer le traitement au sein de l'application.
Redémarrage automatique des applications et repositionnement manuel dans les applications
Les applications qui étaient actives au moment de la panne ou de l'arrêt sont redémarrées
automatiquement par le programme d'exit du CRG. L'utilisateur doit cependant déterminer à
quel endroit reprendre dans l'application, en fonction de l'état des données.
Redémarrage automatique des applications et reprise semi-automatique
En plus du redémarrage automatique des applications, les utilisateurs reviennent à un “point de
redémarrage” prédéfini dans l'application. Ce point de redémarrage peut être par exemple un
menu principal. Cette technique est normalement cohérente avec l'état des données de
l'application résiliente, mais l'utilisateur devra éventuellement avancer au sein de l'application
pour revenir effectivement à l'état des données souhaité. Les modifications de l'application sont
obligatoires pour sauvegarder les données d'état utilisateur. Lors de l'ouverture de session,
l'application détecte l'état de chaque utilisateur et détermine s'il est nécessaire de récupérer le
dernier état sauvegardé de l'application.
Redémarrage automatique des applications et reprise automatique jusqu'à la dernière frontière de
transaction
L'utilisateur est repositionné dans l'application au point de traitement cohérent avec la dernière
transaction validée. Les données d'application et le point de redémarrage de l'application
coïncident exactement. Cette catégorie nécessite de modifier le code de l'application afin de
sauvegarder les états utilisateur à la fin de chaque cycle de validation, afin que l'application sache
à quel endroit se trouve chaque utilisateur en cas de défaillance.
Résilience totale de l'application avec redémarrage automatique et reprise en ligne transparente
L'utilisateur est repositionné sur la dernière transaction validée, et il voit s'afficher exactement la
même fenêtre et les mêmes données que celles qu'il consultait lors de la panne ou de l'arrêt.
Aucune perte de données ne se produit, une ouverture une session n'est pas requise, et aucune
perte des ressources serveur n'est perçue. L'utilisateur perçoit uniquement un retard dans les
temps de réponse. Cette catégorie ne peut être mise en oeuvre que dans une application ayant
une relation client-serveur.
Concepts associés:

Présentation de la haute disponibilité 13

 «Besoins en résilience», à la page 9
L'entreprise doit identifier ce dont elle a besoin pour se protéger en cas de panne du système hébergeant
l'application. Les besoins en résilience englobent l'ensemble des applications, des données et des
environnements système qui doivent être protégés pendant tout le temps d'indisponibilité du système de
production. Ces entités restent disponibles pendant toute la reprise en ligne, même lorsque le système qui
les héberge tombe en panne.
Information associée:
Niveaux de résilience des applications
La résilience des applications peut être personnalisée en fonction du niveau du résilience dont l'entreprise
a besoin, à l'aide des fonctionnalités de la structure de mise en grappe IBM i.
Rendre résilients des programmes d'application
| Applications en grappes

Niveaux de résilience des applications

La résilience des applications peut être personnalisée en fonction du niveau du résilience dont l'entreprise
a besoin, à l'aide des fonctionnalités de la structure de mise en grappe IBM i.

L'objectif de temps de reprise (RTO) de votre entreprise influe directement sur le niveau de résilience des
applications requis. Comme on l'a vu dans la rubrique Composants de la haute disponibilité, il existe
différents niveaux de résilience des applications. Ces niveaux vont de la non-reprise de l'application, qui
oblige l'opérateur système à redémarrer manuellement l'application, au service ininterrompu, cas dans
lequel l'utilisateur ne s'aperçoit même pas qu'un arrêt s'est produit. Votre entreprise doit évaluer
elle-même les besoins en disponibilité des applications suite à une panne, afin de déterminer le degré
d'automatisation de l'application résilient suite à un arrêt du système.

La structure de mise en grappe IBM i permet d'automatiser la reprise des applications selon différents
types de pannes. Le degré d'automatisation possible dépend de la quantité de codage nécessaire pour
automatiser les procédures manuelles, ainsi que du type des applications utilisées par l'entreprise. Pour
optimiser la résilience des applications, toutes les étapes manuelles de commutation/reprise en ligne
doivent être automatisées à l'aide de programmes d'exit. En outre, les applications doivent être de type
client-serveur, c'est-à-dire que la disponibilité de l'application doit être distincte de la disponibilité de ses
données.

Résilience des données

| La résilience des données correspond à la disponibilité des données nécessaires dans un environnement
| de production. Plusieurs technologies permettent de satisfaire les besoins en résilience des données
| décrits dans la section “Avantages de la haute disponibilité”. Ces technologies peuvent être divisées en
| deux catégories principales sur l'IBM i : la réplication logique ou logicielle et la réplication matérielle ou
| sur disque.

Réplication logique
La réplication logique est une topologie multi-systèmes de résilience des données destinée à la haute
disponibilité (HA) dans l'espace IBM i. Elle est en général déployée via un produit fourni par un éditeur
de logiciel indépendant (ISV) spécialisé en haute disponibilité. La réplication est exécutée sur des objets
via des méthodes logicielles. Les modifications apportées aux objets (par exemple les fichiers, les
membres, les zones de données ou les programmes) sont répliquées sur une copie de sauvegarde. La
réplication s'effectue en temps ou quasi-temps réel (journalisation distante synchrone) sur tous les objets
journalisés. En règle général, si l'objet, tel qu'un fichier, est journalisé, la réplication est gérée au niveau
de l'enregistrement. Pour les objets tels que les espaces utilisateur, qui ne sont pas journalisés, la
réplication est normalement gérée au niveau de l'objet. Dans ce cas, la totalité de l'objet est répliquée
lorsque chaque ensemble des modifications apportées à l'objet est complet.

14 IBM i - Haute disponibilité - Présentation

 La plupart des solutions de réplication logique autorisent des fonctions supplémentaires en plus de la
réplication d'objets. Vous pouvez par exemple installer des fonctions d'audit supplémentaires, observer le
statut de la réplication en temps réel, ajouter automatiquement les nouveaux objets à ceux qui sont en
cours de réplication, et répliquer uniquement un sous-ensemble d'objets dans une bibliothèque ou un
répertoire donné.

Pour créer une solution multi-systèmes à haute disponibilité utilisant la réplication logique qui soit à la
fois fiable et efficace, il est préférable d'utiliser la journalisation distante comme mécanisme de transport.
Avec la journalisation distante, l'IBM i transfère en permanence les nouvelles données arrivant dans le
récepteur de journal vers le récepteur de journal du serveur de sauvegarde. A ce stade, une solution
logicielle permet de “relire” ces mises à jour du journal et de les placer dans l'objet sur le serveur de
sauvegarde. Une fois cet environnement créé, on obtient deux objets distincts mais identiques, un sur le
serveur principal et un autre sur le serveur de sauvegarde.

Avec cette solution, vous pouvez rapidement activer votre environnement de production sur le serveur
de sauvegarde en exécutant une opération de permutation de rôle.

Un avantage essentiel de cette catégorie de solution est que le fichier base de données est accessible en
temps réel par les opérations de sauvegarde ou les autres types d'application en lecture seule, telles que
les applications de création de rapports. Par ailleurs, les opérations de reprise sont normalement réduites
au strict minimum lorsque vous commutez vers la copie de sauvegarde.

La difficulté que pose cette catégorie de solution est la complexité de la configuration et de la

maintenance d'un tel environnement. L'un des plus grands défis consiste à ne pas surveiller avec
suffisamment de rigueur les modifications désordonnées des copies en temps réel des objets résidant sur
le serveur de sauvegarde. Si cette discipline n'est pas appliquée, vous risquez d'obtenir des instances dans
lesquelles utilisateurs et programmeurs effectuent des modifications sur la copie en temps réel, qui finit
par ne plus correspondre à la copie de production. Si c'est le cas, les versions principale et de sauvegarde
de vos fichiers ne sont alors plus identiques.

Un autre défi lié à cette approche est que les objets non journalisés doivent passer par un point de
contrôle, être sauvegardés, puis envoyés séparément au serveur de sauvegarde. Par conséquent, la
granularité du processus en temps réel risque d'être restreinte à la granularité du plus gros objet répliqué
pour une opération donnée.

Par exemple, un programme met à jour un enregistrement qui se trouve dans un fichier consigné. Dans le
cadre de cette même opération, il met également à jour un objet, tel qu'un espace utilisateur, qui n'est pas
consigné. La copie de sauvegarde devient complètement cohérente quand l'espace utilisateur est
entièrement répliqué dans le système de secours. En pratique, si le système principal tombe en panne, et
que l'objet espace utilisateur n'est pas encore totalement répliqué, un processus de reprise manuelle est
requis pour réconcilier l'état de l'espace utilisateur non journalisé afin qu'il corresponde à la dernière
opération valide dont les données ont été complètement répliquées.

| Les solutions de réplication logique permettent généralement de faire face à tous les types
| d'indisponibilité, selon l'implémentation. L'objectif de point de reprise peut être défini sur 0 si la distance
| entre les systèmes permet une journalisation à distance synchrone et que tous les objets répliqués sont
| journalisés. L'utilisation de la journalisation à distance asynchrone et de la réplication des objets à partir
| du journal d'audit accroît le RPO.

Une autre difficulté éventuelle liée à cette approche concerne le temps d'attente du processus de
réplication. Ceci a un rapport avec la durée du temps de décalage entre l'heure à laquelle les
modifications ont été apportées sur le système source et l'heure à laquelle ces modifications sont
devenues disponibles sur le système de secours. La journalisation distante synchrone peut minimiser cela
de façon considérable. Quel que soit le mécanisme de transmission utilisé, vous devez prévoir de façon
adéquate votre volume de transmission et dimensionner correctement vos lignes et vitesses de
transmission pour garantir que votre environnement soit capable de gérer des volumes de réplication

Présentation de la haute disponibilité 15

 quand ils atteignent leur limite. Dans un environnement traitant de gros volumes, une réexécution des
commandes en attente et le temps d'attente peuvent poser problème du côté cible même si vos fonctions
de transmission sont correctement dimensionnées.

| Réplication matérielle

| La réplication matérielle s'effectue au niveau du système d'exploitation ou du disque et non au niveau de

| l'objet. L'avantage que présente cette technologie par rapport à la réplication logique est que la réplication
| est réalisée à un niveau inférieur et que les deux copies des données sont identiques en cas de réplication
| synchrone. L'inconvénient de cette technologie est que les données ne sont accessibles qu'à partir d'une
| copie et que la deuxième copie ne peut pas être utilisée lorsque la réplication est active.

| En ce qui concerne la réplication matérielle, on distingue deux catégories : la réplication du pool de

| mémoire secondaire indépendant (IASP) et la réplication complète du système. IBM PowerHA
| SystemMirror for i offre plusieurs technologies de réplication matérielle de type IASP (pool de mémoire
| secondaire indépendant). Un ASP indépendant ou IASP est un ensemble d'unités de disques pouvant être
| configurées séparément d'un système hôte spécifique et dont la mise en fonction et hors fonction peut se
| faire indépendamment. Un IASP permet de séparer les données d'application du système d'exploitation.
| Par conséquent, les données d'application peuvent être répliquées à l'aide de la réplication matérielle sans
| entraîner la réplication du système d'exploitation. L'implémentation IBM i des IASP prend en charge à la
| fois les objets répertoire (par exemple le système de fichiers intégré (IFS)) et les objets de bibliothèque
| (par exemple les fichiers de base de données). Lors de la migration des données d'application contenues
| dans l'IASP, étape séparée de la configuration de l'environnement, la réplication des données et non du
| système d'exploitation peut présenter plusieurs avantages. Les commutations planifiées ou non vers le
| système de secours s'effectuent plus rapidement que lorsque l'ensemble du système est répliqué. Le
| système de secours contient une copie distincte du système d'exploitation et peut être utilisé pour
| d'autres tâches alors même qu'il est également utilisé en tant que système de secours en production. Ces
| technologies peuvent être utilisées en cas de mises à niveau non planifiées du système d'exploitation
| étant donné qu'il y a encore deux copies du système d'exploitation.

| Si la migration des données d'application contenues dans un IASP n'est pas faisable, il est également
| possible d'utiliser la réplication matérielle au niveau du système. On parle alors généralement de
| réplication complète du système. La protection géographique par miroir, qui est une technologie de
| réplication IBM i, peut être utilisée dans un environnement hébergé de type i pour répliquer un système
| de production. Les technologies de réplication fournies par les systèmes de stockage IBM peuvent
| également être utilisées pour répliquer tout un système. La réplication complète du système, bien que
| plus simple à configurer, ne nécessite pas plus de bande passant que la réplication IASP. Elle est
| davantage considérée comme une technologie de reprise après incident qu'une technologie à haute
| disponibilité, car il n'y a qu'un seul environnement de production et que la procédure de chargement
| initial (IPL) de cet environnement doit être lancée sur un autre système physique en cas d'indisponibilité
| planifiée ou non. Des outils et des contrats de service, disponibles auprès d'IBM Lab Services, permettent
| d'automatiser et de personnaliser l'environnement de réplication complète du système, le cas échéant.
Concepts associés:
| «Comparaison des technologies de résilience des données PowerHA», à la page 19
La résilience des données permet aux données de rester disponibles pour les applications et les utilisateurs,
même en cas de panne du système qui les hébergeait à l'origine. Choisir correctement les technologies de
résilience des données dans le contexte de votre stratégie globale de continuité opérationnelle peut
s'avérer une tâche difficile. Il est important d'avoir une idée claire des différentes solutions de résilience
des données que vous pouvez utiliser pour améliorer la de résilience des données dans des
environnements multi-systèmes. Vous pouvez choisir une seule solution ou recourir à une combinaison
de ces technologies adaptée à vos besoins. Les rubriques suivantes comparent les différentes technologies
| existantes au sein du produit PowerHA.

16 IBM i - Haute disponibilité - Présentation

| «Présentation d'IBM PowerHA SystemMirror for i», à la page 18
Lorsque vous avez déterminé les objectifs et les besoins de votre entreprise, vous devez ensuite choisir la
solution IBM i à haute disponibilité adaptée à votre entreprise. IBM PowerHA SystemMirror for i est un
produit IBM qui fournit une solution complète à haute disponibilité pour les environnements de
production IBM i. Il assure la résilience des données, des applications et des environnements et offre une
| interface de gestion qui permet une configuration et un fonctionnement en toute transparence.
«Besoins en résilience», à la page 9
L'entreprise doit identifier ce dont elle a besoin pour se protéger en cas de panne du système hébergeant
l'application. Les besoins en résilience englobent l'ensemble des applications, des données et des
environnements système qui doivent être protégés pendant tout le temps d'indisponibilité du système de
production. Ces entités restent disponibles pendant toute la reprise en ligne, même lorsque le système qui
les héberge tombe en panne.
Information associée:
Planification du test de résilience des données
Serveurs de stockage pris en charge par PowerHA
| Domaine d'administration de grappe
| Technologies de réplication de données PowerHA

Résilience de l'environnement
La résilience de l'environnement peut être divisée en deux parties : l'environnement physique et
l'environnement logique. L'environnement physique, qui relève en fait de la disponibilité pour un
système unique, privilégie les aspects tels que la redondance matérielle, la topologie de réseau,
l'infrastructure de l'alimentation et la capacité de refroidissement. L'environnement logique est
l'environnement qui héberge et exécute les applications. Il comprend les paramètres systèmes, les profils
utilisateur et les attributs système qui permettent à l'utilisateur d'exécuter l'application sur plusieurs
serveurs.
Environnement physique
L'environnement physique se compose de fonctions de disponibilité adaptées à un système
unique et d'utilitaires requis pour la maintenance correcte d'un environnement informatique. Ces
fonctions de disponibilité pour système unique sont essentielles pour préserver un environnement
à haute disponibilité. Le système comporte de nombreuses fonctions qui le protègent des pannes
matérielles. Le premier composant à protéger est le sous-système de disques. RAID 5, RAID 6,
RAID 10 et la protection par disque miroir sont les mécanismes de protection possibles. Toute
entreprise doit obligatoirement disposer d'un de ces mécanismes de protection.
Un autre composant à protéger est le réseau. Le concept de réseau englobe les cartes réseau
redondantes sur le système, et les chemins réseau de communication utilisant les matériels réseau
redondants, à l'usage des utilisateurs comme des systèmes.
L'environnement physique comprend également les services d'utilitaire requis pour exploiter la
salle informatique. Le système peut fonctionner avec un double cordon d'alimentation, c'est-à-dire
que chaque tour ou armoire rack est équipée de deux câbles d'alimentation qui doivent être
raccordés à deux prises secteur différentes. Cela permet à la salle informatique de disposer de
deux panneaux de disjoncteurs alimentant chaque tour ou armoire. En raison des incertitudes liés
au réseau d'alimentation électrique public, il est vivement conseillé de protéger l'alimentation de
la salle informatique par une alimentation de secours (UPS) ou par un générateur.
Vous devez également prendre en compte les spécifications physiques de la salle (chauffage,
refroidissement, taux d'humidité, pureté de l'air).
Environnement logique
| L'environnement logique est l'environnement d'exécution des applications. Il comprend les
| attributs système, les valeurs système, les attributs de configuration de réseau, la configuration de
| la gestion des travaux et les profils utilisateur. Ces éléments doivent être identiques sur le
| système de secours et sur le système principal de production pour assurer un fonctionnement

Présentation de la haute disponibilité 17

| correct de l'environnement d'application. Pour garantir la cohérence de ces valeurs
| d'environnement logique sur plusieurs systèmes, vous pouvez utiliser un domaine administratif
| de grappe, la réplication logique ou un processus manuel répondant à des spécifications
| rigoureuses.
Concepts associés:
«Besoins en résilience», à la page 9
L'entreprise doit identifier ce dont elle a besoin pour se protéger en cas de panne du système hébergeant
l'application. Les besoins en résilience englobent l'ensemble des applications, des données et des
environnements système qui doivent être protégés pendant tout le temps d'indisponibilité du système de
production. Ces entités restent disponibles pendant toute la reprise en ligne, même lorsque le système qui
les héberge tombe en panne.
Information associée:
Planification du test de résilience de l'environnement
| Domaine d'administration de grappe

Simplicité
La haute disponibilité IBM i concerne trois domaines : la personnalisation, le contrôle et l'automatisation,
avec l'objectif d'introduire une simplicité opérationnelle.
Personnalisation
Chaque client possède un environnement unique, dont les besoins sont uniques. L'architecture
IBM i à haute disponibilité fournit une structure de base à partir de laquelle chaque client peut
concevoir une solution adaptée à son propre environnement d'application et à ses besoins.
Contrôle
L'architecture IBM PowerHA SystemMirror for i met en place un contrôle simple de votre
environnement à haute disponibilité. Grâce à un certain degré de personnalisation, l'activation,
l'arrêt, la commutation et la reprise de la totalité de l'environnement d'application sont contrôlés
par une interface conviviale de mise en grappe. L'opérateur système se transforme en opérateur
de grappe.
Automatisation
La haute disponibilité de l'environnement de production du client nécessite une exploitation
soigneuse et coordonnée de tous les aspects de l'application afin de préserver la résilience, et de
pouvoir basculer rapidement d'un serveur à l'autre en cas de panne ou d'arrêt du serveur
principal. L'automatisation de l'environnement garantit une interruption de la production aussi
brève que possible. Un avantage majeur des fonctions d'automatisation d'IBM PowerHA
SystemMirror for i est qu'elle réduit les erreurs des utilisateurs dans les scénarios de panne. La
diminution des risques d'erreurs des utilisateurs améliore le processus décisionnel en cas de
défaillance.

| Présentation d'IBM PowerHA SystemMirror for i

| Lorsque vous avez déterminé les objectifs et les besoins de votre entreprise, vous devez ensuite choisir la
| solution IBM i à haute disponibilité adaptée à votre entreprise. IBM PowerHA SystemMirror for i est un
| produit IBM qui fournit une solution complète à haute disponibilité pour les environnements de
| production IBM i. Il assure la résilience des données, des applications et des environnements et offre une
| interface de gestion qui permet une configuration et un fonctionnement en toute transparence.

| Cette section compare les technologies disponibles au sein du produit IBM PowerHA SystemMirror for i.
| Concepts associés:

18 IBM i - Haute disponibilité - Présentation

| «Résilience des données», à la page 14
| La résilience des données correspond à la disponibilité des données nécessaires dans un environnement
| de production. Plusieurs technologies permettent de satisfaire les besoins en résilience des données
| décrits dans la section “Avantages de la haute disponibilité”. Ces technologies peuvent être divisées en
| deux catégories principales sur l'IBM i : la réplication logique ou logicielle et la réplication matérielle ou
| sur disque.
| «Composants de la haute disponibilité», à la page 12
| La haute disponibilité permet de continuer à pouvoir accéder aux applications et aux données métier
| critiques en cas d'une interruption de service. Les solutions IBM i à haute disponibilité atténuent et
| parfois éliminent totalement l'impact des arrêts planifiés ou non et des sinistres frappant tout un site. Ces
| solutions IBM i se basent sur la technologie de grappe.
| Information associée:
| Gestion de PowerHA
| Technologies de réplication de données PowerHA

| Comparaison des technologies de résilience des données PowerHA

| La résilience des données permet aux données de rester disponibles pour les applications et les utilisateurs,
| même en cas de panne du système qui les hébergeait à l'origine. Choisir correctement les technologies de
| résilience des données dans le contexte de votre stratégie globale de continuité opérationnelle peut
| s'avérer une tâche difficile. Il est important d'avoir une idée claire des différentes solutions de résilience
| des données que vous pouvez utiliser pour améliorer la de résilience des données dans des
| environnements multi-systèmes. Vous pouvez choisir une seule solution ou recourir à une combinaison
| de ces technologies adaptée à vos besoins. Les rubriques suivantes comparent les différentes technologies
| existantes au sein du produit PowerHA.
| Concepts associés:
| «Résilience des données», à la page 14
| La résilience des données correspond à la disponibilité des données nécessaires dans un environnement
| de production. Plusieurs technologies permettent de satisfaire les besoins en résilience des données
| décrits dans la section “Avantages de la haute disponibilité”. Ces technologies peuvent être divisées en
| deux catégories principales sur l'IBM i : la réplication logique ou logicielle et la réplication matérielle ou
| sur disque.
| Information associée:
| Technologies de réplication de données PowerHA
| Planification du test de résilience des données

| Unité logique (LUN) commutée

| Les unités logiques (LUN) commutées permettent de basculer des données stockées dans le pool de
| stockage sur disque indépendant à partir d'unités logiques créées sur un IBM DS8000, un contrôleur de
| volume SAN ou Storwize d'un système à l'autre, et ainsi de mettre en oeuvre une haute disponibilité. Les
| unités logiques commutables sont un ensemble d'unités de disques dans un pool de stockage sur disque
| qui est contrôlé par un groupe de ressources de grappe d'unité constitué par une grappe d'unités, et qui
| peut être commuté entre les différents noeuds au sein d'une grappe. La combinaison de la commutation
| d'unités logiques à la technologie des grappes IBM i vous permet de créer une solution à haute
| disponibilité à la fois simple et économique, adaptée aux indisponibilités planifiées ou non.

| Un groupe de systèmes dans une grappe peut exploiter la fonction de commutation afin de transférer
| l'accès au pool d'unités logiques commutées d'un système à un autre. Une unité logique commutée doit
| se trouver dans un IBM System Storage connecté via un réseau de stockage SAN. Lorsque le pool de
| stockage sur disque indépendant est commuté, les unités logiques de l'IBM System Storage sont
| réaffectées d'un système à l'autre.

Présentation de la haute disponibilité 19

| L'avantage du recours à des unités logiques commutées pour la résilience des données est leur simplicité
| d'utilisation. La copie unique des données est toujours à jour, c'est-à-dire qu'il n'existe pas d'autre copie
| avec laquelle une synchronisation doit être effectuée. Les données en cours, par exemple les données
| transmises en mode asynchrone, ne peuvent pas être perdues, et l'opération affecte très peu les
| performances. La permutation ou la commutation de rôle sont relativement directes, bien qu'il faille
| prendre en compte le temps nécessaire à la mise en fonction du pool de stockage sur disque indépendant.

| Un autre avantage majeur est le temps d'attente nul, qui peut affecter toute technologie de réplication.
| Les principales tâches nécessaires avec cette solution sont la configuration des unités de stockage à accès
| direct (DASD), des données et de la structure d'applications.

| La solution à base d'unités logiques commutées a cependant des limites. Tout d'abord, il n'existe qu'une
| seule copie logique des données. Ceci peut constituer un point de défaillance unique, bien que les
| données puissent être protégées par une protection RAID 5, RAID 6, RAID 10 ou par la mise en miroir.
| Les deux hôtes ne peuvent pas accéder simultanément aux données. Des opérations comme l'accès en
| lecture ou la sauvegarde sur bande ne peuvent pas être exécutées à partir du système de secours.
| Certains types d'objets, tels que les objets de configuration, ne peuvent pas être stockés dans un pool de
| stockage sur disque indépendant. Vous devez recourir à un autre mécanisme, par exemple à des
| sauvegardes et des restaurations régulières, à la mise en grappe du domaine administratif ou à la
| réplication logique pour garantir la maintenance de ces objets.

| Les limites liées au matériel constituent une autre restriction. Par exemple, les pannes associées à
| certaines mises à niveau matérielles. Le pool de stockage sur disque indépendant ne peut pas être mis en
| ligne sur un système doté d'une édition précédente. Il convient donc de garder tous ces points à l'esprit
| et de planifier à l'avance une phase de conception et d'analyse de l'environnement système.

| Caractéristiques des unités logiques commutées

| v Toutes les données gérées dans un pool de stockage sur disque indépendant peuvent être basculées et
| rendues disponibles sur un système de secours
| v Aucun problème de synchronisation des données
| v Ensemble de données unique, avec à la clé un budget disques réduit
| v Point de défaillance unique des données du pool de stockage sur disque indépendant
| v Solution mono-site sans fonction de reconfiguration dynamique
| v Requiert IBM System Storage.
| v La commutation et la reprise en ligne nécessitent un temps de mise en fonction avant que les données
| du pool de stockage sur disque indépendant soient disponibles
| v Peut être utilisé avec d'autres technologies.

| Pour plus d'informations sur les technologies de stockage fournies par IBM, voir Serveurs de stockage
| pris en charge par PowerHA.
| Information associée:
| Unités logiques commutées
| Configuration des unités logiques commutées (LUN)
| Gestion des unités logiques commutées (LUN)
| Serveurs de stockage pris en charge par PowerHA

| Protection géographique par disque miroir

| La protection géographique par disque miroir est une fonction du système d'exploitation IBM i. Toutes les
| données placées dans la copie de production de l'IASP son mises en miroir sur un deuxième IASP, sur un
| deuxième système qui peut être distant. La réplication s'effectue au sein du système d'exploitation. Cette
| solution peut donc être utilisée avec n'importe quel type de stockage. On distingue deux versions de
| protection géographique par disque miroir : une version synchrone et une version asynchrone. La
| protection géographique par disque miroir synchrone garantit que les deux copies des données sont

20 IBM i - Haute disponibilité - Présentation

| identiques, mais elle comporte une limitation de distance, puisque la transaction d'E-S n'aboutira pas sur
| le système source tant qu'elle n'aura pas atteint le système cible. La protection géographique par disque
| miroir asynchrone ne comporte pas de limitation de distance mais en cas d'échec inattendu du côté
| source, une perte de données de l'ordre de quelques secondes est possible.

| Les avantages de cette solution sont essentiellement les mêmes que ceux de la solution à base d'unités
| logique commutées, avec l'atout supplémentaire d'assurer une reprise après incident sur une deuxième
| copie, résidant à une distance plus importante. Le plus grand atout reste la simplicité d'utilisation. Les
| opérations de commutation sont pour l'essentiel identiques à celles de la solution à base d'unités logiques
| commutées, sauf que vous commutez vers la copie en miroir de l'IASP, et bénéficiez ainsi d'une solution
| à haute disponibilité que vous pouvez déployer et exploiter directement. Comme dans le cas de la
| solution à base d'unités logiques commutées, les objets ne résidant pas dans l'IASP doivent être gérés par
| un autre mécanisme, tel que le domaine d'administration. L'IAS ne peut pas être mis en ligne sur un
| système plus ancien. La protection géographique par disque miroir prend aussi en charge la réplication
| en temps réel des environnements intégrés hébergés tels que Microsoft Windows et Linux. Cette prise en
| charge est en général impossible via la réplication logique par journalisation.

| Comme la réplication s'effectue au sein du système d'exploitation IBM i dans le cadre de la protection
| géographique par disque miroir, une limite potentielle d'une telle solution est l'impact sur les
| performances dans certains environnements de charge de travail. Lors de l'exécution de travaux par lots
| comportant un très grand nombre d'entrées-sorties (E-S), il peut se produire une détérioration des
| performances sur le système principal pour la protection géographique par disque miroir synchrone. Vous
| devez aussi tenir compte du fait que la la protection géographique par disque miroir sollicite davantage
| l'unité centrale.

| La copie de sauvegarde du pool de stockage sur disque indépendant n'est pas accessible pendant la
| synchronisation des données. Par exemple, si vous voulez faire une sauvegarde sur bande depuis la copie
| protégée géographiquement par disque miroir, vous devez mettre au repos les opérations sur le système
| source et déconnecter la copie mise en miroir. Vous devez ensuite mettre en fonction la copie déconnectée
| du pool de stockage sur disque indépendant sur le système de secours, effectuer la procédure de
| sauvegarde, puis reconnecter le pool de stockage sur disque indépendant à l'hôte de production d'origine.
| La synchronisation des données qui ont été modifiées pendant la déconnexion du pool de stockage sur
| disque indépendant est alors effectuée. Votre solution à haute disponibilité est alors vulnérable lors des
| sauvegardes et de la synchronisation, c'est-à-dire qu'il n'existe pas de deuxième ensemble de données à
| jour. La protection géographique par disque miroir utilise le suivi côté source et côté cible pour minimiser
| cette vulnérabilité.

| Caractéristiques de la protection géographique par disque miroir

| v Toutes les données du pool de stockage sur disque indépendant sont répliquées sur une deuxième
| copie sur un deuxième système.
| v La réplication est une fonction du système d'exploitation IBM i. Par conséquent, n'importe quel type de
| stockage peut être utilisé.
| v L'application peut être basculée vers le système de secours et être exécutée sur la copie du pool de
| stockage sur disque indépendant.
| v Le fait de disposer de deux copies des données élimine tout point de défaillance unique.
| v Lorsque vous utiliser la protection géographique par disque miroir, les deux copies de l'IASP sont
| forcément identiques. La protection géographique par disque miroir synchrone, si elle doit parcourir
| une certaine distance, peut impacter les performances de l'application, en raison du temps d'attente des
| communications.
| v La deuxième copie des données peut se trouver à un tout autre endroit sur le plan géographique si
| vous utilisez la protection géographique par disque miroir asynchrone. En cas d'indisponibilité non
| planifiée sur le système source, une perte de données de quelques secondes est possible.
| v La transmission de données transite par 1 à 4 lignes de communication TCP/IP afin d'améliorer le
| débit et la redondance.

Présentation de la haute disponibilité 21

| v Il est en outre conseillé d'utiliser une ligne distincte pour le signal de présence de la grappe, car le
| partage de ce signal avec le port de données peut provoquer des conflits et des délais d'attente.
| v Il est possible d'exécuter des sauvegardes hors ligne et d'interroger la copie de sauvegarde des données
| lorsque que l'ensemble des données de sauvegarde est déconnecté.
| v La résilience des données n'est pas garantie lorsque l'ensemble des données de sauvegarde est
| déconnecté. Elle est rétablie une fois la resynchronisation partielle ou complète terminée.
| v La solution peut être utilisée avec la technologie de commutation d'unités logiques IBM i.
| v La protection géographique par disque miroir a une incidence sur les performances du système en
| termes de temps système.
| v Il est vivement recommandé de configurer séparément les principaux pools de stockage ou les travaux
| utilisateurs accédant aux pools de stockage sur disque indépendants afin d'éviter que ces travaux
| n'entrent en conflit avec d'autres travaux sur le système et n'utilisent trop de stockage. En particulier,
| les travaux du pool de stockage sur disque indépendant ne doivent pas utiliser le pool machine ou le
| pool de base. Si des travaux du pool de stockage sur disque indépendant utilisent la même mémoire
| que les travaux n'accédant pas à ces pools,les travaux du pool risquent de monopoliser le pool de
| mémoire, de verrouiller d'autres travaux, et, dans des cas extrêmes, de paralyser le système. Le risque
| de voir cette situation se produire est plus élevé lorsque la protection géographique par disque miroir
| est utilisée.
| v Les objets journalisés dans le pool de stockage sur disque indépendant garantissent la mise à jour des
| données sur le système cible.
| v La solution assure une surveillance simple de la fonction miroir.
| v Vous devez tenir compte du coût d'un deuxième ensemble de disques.
| v La réplication s'effectue au niveau de la page de mémoire gérée par l'IBM i.
| Information associée:
| Geographic mirroring
| Planification de la protection géographique par disque miroir
| Configuration de la protection géographique par disque miroir
| Gestion de la protection géographique par disque miroir
| Messages de la protection géographique par disque miroir
| Scénario : Protection géographique par disque miroir

| Fonction Metro Mirror

| Metro Mirror est une fonction d'IBM System Storage Server. Les données stockées dans les IASP résident
| sur des unités de disques du serveur System Storage Server. Cette solution implique la réplication au
| niveau matériel sur un second serveur de stockage utilisant IBM System Storage Copy Services. Chaque
| serveur de stockage est connecté à un IBM i différent. Un IASP est l'unité de stockage de base de la
| fonction System Storage Peer-to-Peer Remote Copy (PPRC). La fonction PPRC assure la réplication de
| l'IASP sur un autre System Storage Server. IBM i fournit un ensemble de fonctions combinant PPRC, les
| IASP et les services de ressource en grappe IBM i afin d'assurer la commutation coordonnée et la reprise
| en ligne via un groupe de ressources de grappe d'unité (CRG). Vous pouvez combiner cette solution avec
| d'autres fonctions de services de copie de System Storage, notamment les unités logiques commutables et
| FlashCopy, afin de réduire la fenêtre de sauvegarde.

| La réplication avec Metro Mirror s'effectue en mode synchrone. Vous devez aussi tenir compte des
| limitations en termes de distance et des besoins en bande passante liés aux durées de transmission,
| comme c'est le cas de toute solution utilisant les communications synchrones.

| Caractéristiques de Metro Mirror

| v Solution IBM System Storage Server intégrée à une structure de grappe PowerHA.
| v La deuxième copie des données peut se trouver à un tout autre endroit sur le plan géographique, à
| courte ou moyenne distance du site d'origine.

22 IBM i - Haute disponibilité - Présentation

| v Deux serveurs System Storage Servers ou deux ensembles de données sur le même System Storage
| Server sont nécessaires
| v Vous devez tenir compte du coût d'un deuxième ensemble de disques.
| v Les sauvegardes hors ligne et les requêtes sont possibles lorsque la réplication est suspendue ou
| effectuée à partir d'une copie d'un point de cohérence des données.
| v La résilience des données n'est pas garantie lorsque l'ensemble des données de sauvegarde est
| déconnecté. Elle est rétablie une fois la resynchronisation terminée.
| v La transmission des données s'effectue en mode synchrone. Aucune perte de données en cours n'est
| possible.
| v La réplication synchrone des données peut impacter les performances des applications si la bande
| passante des communications n'est pas correctement dimensionnée ou si la distance est trop
| importante.
| v Metro Mirror ne nécessite pas de temps système supplémentaire car il est géré par le serveur Storage
| Server.
| v La journalisation des objets dans le pool de stockage sur disque indépendant garantit que les
| modifications sont forcées rapidement sur le disque, à partir duquel elles sont ensuite répliquées sur le
| système cible.
| v La réplication des données du pool de stockage sur disque indépendant s'effectue au niveau du secteur
| du disque, entre les disques de deux serveurs Storage Servers. Tous les objets du pool de stockage sur
| disque indépendant sont synchronisés.
| v Plusieurs lignes de communication Fiber Channel sont disponibles à des fins de redondance et
| d'augmentation de la bande passante.
| Information associée:
| Fonction Metro Mirror
| Planification de Metro Mirror
| Configuration de Metro Mirror
| Gestion de Metro Mirror
| Scénario : Metro Mirror

| Global Mirror
| Global Mirror utilise la même technologie de base que Metro Mirror, mais effectue la transmission des
| données en mode asynchrone. Lorsque Global Mirror est utilisé sur le DS8000 et avec un contrôleur de
| volume SAN et des volumes de changement de système Storwize, un troisième ensemble de disques est
| nécessaire pour garantir la cohérence des données.

| Du fait de cette transmission de données asynchrone, la distance entre les emplacements géographiques
| des serveurs System Storage n'est soumise à aucune limite.

| Caractéristiques de Global Mirror

| v Solution IBM System Storage Server intégrée à une structure de grappe PowerHA.
| v La deuxième copie des données peut se trouver à un tout autre endroit sur le plan géographique, à
| une distance qui peut être très importante.
| v La solution nécessite deux serveurs System Storage Servers.
| v Deux copies des données sur le serveur cible System Storage Server sont requises pour garantir la
| cohérence des données sur les deux sites distants.
| v Les sauvegardes hors ligne et les requêtes sont possibles à partir d'une copie de point de cohérence,
| avec préservation de la résilience des données.
| v La transmission des données s'effectue en mode asynchrone. Une perte de données en cours est
| possible.
| v Le processus de réplication asynchrone des données n'affecte pas les performances des applications.

Présentation de la haute disponibilité 23

| v La réplication des données du pool de stockage sur disque indépendant s'effectue au niveau du secteur
| du disque, entre les disques de deux serveurs Storage Servers. Tous les objets du pool de stockage sur
| disque indépendant sont synchronisés.
| v Vous devez tenir compte du coût d'un deuxième et d'un troisième ensemble de disques.
| v Global Mirror ne nécessite pas de temps système supplémentaire car il est géré par le serveur Storage
| Server.
| v La journalisation des objets dans le pool de stockage sur disque indépendant garantit que les
| modifications sont forcées rapidement sur le disque, à partir duquel elles sont ensuite répliquées sur le
| système cible.
| v Plusieurs lignes de communication Fiber Channel sont disponibles à des fins de redondance et
| d'augmentation de la bande passante.
| Information associée:
| Global Mirror
| Planification de Global Mirror
| Configuration de Global Mirror
| Gestion de Global Mirror
| Scénario : Global Mirror

| DS8000 Full System HyperSwap

| Full System HyperSwap est une solution système complète qui accepte les unités logiques mises en
| miroir entre deux unités IBM System Storage DS8000. L'IBM i peut basculer l'accès du DS8000 principal
| vers le DS8000 secondaire avec une durée d'indisponibilité minimale, tout en garantissant un impact
| minimal sur la solution à haute disponibilité.

| DS8000 Full System HyperSwap est une solution système IBM i unique qui utilise deux serveurs IBM
| System Storage Server et ne nécessite pas de grappe. L'IBM i permet au système de basculer entre les
| serveurs DS8000 en cas d'indisponibilités planifiées et non planifiées liées au stockage sans perdre l'accès
| aux données pendant la commutation.

| Etant donné que HyperSwap utilise la fonction DS8000 Metro Mirror, le transfert des données s'effectue
| de façon synchrone. Vous devez tenir compte des mêmes limitations en termes de distance et des mêmes
| besoins en bande passante liés aux durées de transmission, comme c'est le cas de toute solution envoyant
| des communications synchrones.

| Caractéristiques de Full System HyperSwap

24 IBM i - Haute disponibilité - Présentation

| v Solution système unique.
| v Partition IBM i unique avec accès à deux systèmes IBM System Storage.
| v Deux serveurs IBM System Storage Servers utilisant la fonctin IBM System Storage Copy Services
| Peer-to-Peer Remote Copy (PPRC) Metro Mirror.
| v Toutes les unités de disque associées au système IBM i doivent figurer dans une relation Metro Mirror
| afin de permettre le bon fonctionnement de HyperSwap.
| v Transfert de données synchrone.
| v Durée d'immobilisation quasi-nulle en cas d'indisponibilités planifiées liées au stockage
| v Durée d'immobilisation minimale en cas d'indisponibilités non planifiées liées au stockage (de
| quelques secondes à quelques minutes)
| v Définition d'affinité pour permettre la commutation automatique des serveurs de stockage pendant une
| commutation Live Partition Mobility (PowerVM Live Partition Mobility)
| Information associée:
| DS8000 Full System HyperSwap
| Planification de DS8000 Full System HyperSwap
| Configuration de DS8000 Full System HyperSwap
| Gestion de DS8000 Full System HyperSwap

| DS8000 HyperSwap avec pools de mémoire secondaire indépendants (IASP)

| PowerHA Enterprise Edition prend en charge DS8000 HyperSwap au niveau IASP. HyperSwap
| fonctionne de façon indépendante pour SYSBAS et les IASP. Des relations HyperSwap peuvent n'être
| configurées que pour des unités logiques SYSBAS, que pour des unités logiques IASP ou pour ces deux
| types d'unité à la fois.

| Caractéristiques de DS8000 HyperSwap avec IASP

| v Durée d'immobilisation quasi-nulle en cas d'indisponibilités planifiées liées au stockage
| v Durée d'immobilisation minimale en cas d'indisponibilités non planifiées liées au stockage (de
| quelques secondes à quelques minutes)
| v Indisponibilités planifiées ou non planifiées du serveur gérées par la technologie de commutation
| d'unités logiques pour garantir une durée d'immobilisation minimale.
| v Toutes les unités de disque associées au système IBM i doivent figurer dans une relation Metro Mirror
| afin de permettre le bon fonctionnement de HyperSwap.
| v Définition d'affinité pour permettre la commutation automatique des serveurs de stockage pendant une
| commutation Live Partition Mobility (PowerVM Live Partition Mobility)
| v Fonction de commutation PowerHA en cas de mise à niveau ou d'indisponibilité planifiée d'un serveur,
| d'un microprogramme ou d'un système IBM i
| v Fonction de reprise en ligne PowerHA en cas d'indisponibilité non planifiée d'un serveur, d'un
| microprogramme ou d'un système IBM i
| Information associée:
| DS8000 HyperSwap avec IASP
| Planification de DS8000 HyperSwap avec pools de mémoire secondaire indépendants (IASP)
| Configuration de DS8000 HyperSwap avec pools de mémoire secondaire indépendants (IASP)
| Gestion de DS8000 HyperSwap avec pools de mémoire secondaire indépendants (IASP)

| Scénarios de cas d'utilisation :

| Cette section vous présente les scénarios possibles à votre disposition pour permettre à votre entreprise
| de bénéficier des services à haute disponibilité et de reprise après incident.

Présentation de la haute disponibilité 25

| Une image est parfois plus parlante que des mots. Nous espérons que les images ci-après vous aideront à
| identifier la solution la plus appropriée aux besoins de votre entreprise.

| Environnement HyperSwap + commutation d'unités logiques :

| La plupart de nos clients qui utilisent HyperSwap dans un environnement IASP combinent HyperSwap
| et la technologie de commutation d'unités logiques (LUN) PowerHA.

| Grâce à la combinaison de ces technologies, les clients bénéficient :

| v d'une durée d'immobilisation quasi-nulle en cas d'indisponibilité planifiée du serveur de stockage
| v d'une durée d'immobilisation minimale en cas d'indisponibilité non planifiée liée au stockage (de
| quelques secondes à quelques minutes)
| v de la fonction de commutation PowerHA en cas de mise à niveau ou d'indisponibilité planifiée d'un
| serveur, d'un microprogramme ou d'un système IBM i
| v de la fonction de reprise en ligne PowerHA en cas d'indisponibilité non planifiée d'un serveur, d'un
| microprogramme ou d'un système IBM i

| Le diagramme ci-dessus représente une combinaison d'environnement de commutation HyperSwap et

| d'unités logiques. En cas d'indisponibilité planifiée du DS8000 de production, une commutation
| HyperSwap peut être initiée vers le DS8000 cible avec une durée d'immobilisation quasi-nulle. Ce type de
| commutation n'implique pas la commutation de l'accès de l'IASP de l'IBM i A vers l'IBM i B ni la mise
| hors fonction ou la mise en fonction de l'IASP.

26 IBM i - Haute disponibilité - Présentation

|

| Le diagramme ci-dessus représente une combinaison d'environnement de commutation HyperSwap et

| d'unités logiques. En cas d'indisponibilité non planifiée du DS8000 de production, une reprise en ligne
| HyperSwap est automatiquement initiée vers le DS8000 cible avec une durée d'immobilisation quasi-nulle
| (de quelques secondes à quelques minutes). Ce type de commutation n'implique pas la commutation de
| l'accès de l'IASP de l'IBM i A vers l'IBM i B ni la mise hors fonction ou la mise en fonction de l'IASP.

Présentation de la haute disponibilité 27

|

| Le diagramme ci-dessus représente une combinaison d'environnement de commutation HyperSwap et

| d'unités logiques. En cas d'indisponibilité planifiée de la partition de production (IBM i A), une
| commutation d'unités logiques peut être initiée vers la partition cible (IBM i B) avec une durée
| d'immobilisation quasi-nulle. Si l'affinité a été définie, une commutation HyperSwap devrait également
| être initié pour commuter l'accès aux données du DS8000 de production vers le DS8000 cible. Ce type de
| commutation n'implique pas la commutation de l'accès de l'IASP de l'IBM i A vers l'IBM i B ni la mise
| hors fonction ou la mise en fonction de l'IASP.

28 IBM i - Haute disponibilité - Présentation

|

| Le diagramme ci-dessus représente une combinaison d'environnement de commutation HyperSwap et

| d'unités logiques. En cas d'indisponibilité non planifiée de la partition de production (IBM i A), une
| reprise en ligne de la commutation d'unités logiques peut être initiée vers la partition cible (IBM i B) avec
| une durée d'immobilisation minimale. Si l'affinité a été définie, une commutation HyperSwap devrait
| également être initié pour commuter l'accès aux données du DS8000 de production vers le DS8000 cible.
| Ce type de commutation n'implique pas la commutation de l'accès de l'IASP de l'IBM i A vers l'IBM i B
| ni la mise hors fonction ou la mise en fonction de l'IASP.

| Etant donné que la commutation HyperSwap et la commutation des unités logiques sont des technologies
| locales, ces technologies n'offriront pas de protection en cas d'indisponibilité du site.

| Environnement HyperSwap + affinité :

| Une affinité peut être définie avec ou sans environnement de commutation d'unités logiques.

| L'affinité garantit que les E/S transitent sur le serveur de stockage avec l'affinité la plus appropriée au
| serveur Power qui héberge la partition IBM i, que ce soit dans le cadre d'une commutation Live Partition
| Mobility ou d'une commutation d'unités logiques.

Présentation de la haute disponibilité 29

|

| Dans l'image ci-dessus, un environnement HyperSwap est configuré à partir de la partition IBM i A sur le
| système de stockage DS8000 M et DS8000 N. Lorsque Live Partition Mobility est utilisé pour activer la

| partition sur le matériel de secours dans , les données restent accessibles via le DS8000 M qui se
| trouve plus loin, ce qui peut entraîner une altération des performances sur chaque E/S. L'affinité peut
| être définie de façon à associer DS8000 M au serveur POWER situé à gauche et DS8000 N au serveur

| situé à droite. Par la suite, comme indiqué dans , dans le cadre de la commutation Live Partition
| Mobility, la relation HyperSwap sera également inversée afin que les données soient désormais
| accessibles depuis DS8000 N.

| Ajout de la fonction FlashCopy :

| La technologie FlashCopy peut également être utilisée en association avec HyperSwap.

| Grâce à l'ajout de la fonction FlashCopy, une copie de point de cohérence distincte de l'IASP peut être
| créée et activée sur une autre partition IBM i, ce qui permet d'effectuer des sauvegardes hors ligne.

30 IBM i - Haute disponibilité - Présentation

| FlashCopy
| FlashCopy est une fonction d'IBM System Storage Server. FlashCopy fournit une copie rapide de point de
| cohérence des données, qui peut être mise en ligne sur une partition distincte ou un système distinct.
| Cette copie peut être utilisée pour les sauvegardes hors ligne ou pour le remplissage des données dans
| un système de développement ou de test. FlashCopy peut être utilisée avec n'importe quelle technologie
| de résilience de données fournie dans PowerHA ou peut être utilisée séparément.

| Caractéristiques de FlashCopy
| v Technologie IBM System Storage Server intégrée à la structure PowerHA.
| v Fournit une copie rapide de point de cohérence à utiliser dans les sauvegardes hors ligne.
| v N'est pas une technologie à haute disponibilité en elle-même car elle consiste en une copie de point de
| cohérence.
| v Nécessite de l'espace disque supplémentaire pour créer la copie sur le même serveur de stockage que
| celui où se trouve la copie source.
| Information associée:
| FlashCopy

| Technologies à haute disponibilité combinées

| La plupart des technologies disponibles dans PowerHA peuvent être combinées afin de fournir un niveau
| supérieur de disponibilité et de protection pour faire face à différents types d'indisponibilité.

| Voici quelques exemples :

| v Certains clients disposent d'une mémoire interne sur un système et d'une mémoire externe sur un
| autre. La protection géographique par disque miroir peut être utilisée pour effectuer une réplication
| entre la mémoire interne et la mémoire externe. Des unités logiques commutées peuvent être
| configurées sur le système doté de la mémoire externe pour fournir une protection locale en cas
| d'indisponibilité du serveur et la protection géographique par disque miroir peut ensuite fournir une
| protection en cas d'indisponibilité de la mémoire et de reprise après incident.
| v Des unités logiques commutées peuvent également être combinées avec Metro Mirror ou Global Mirror
| pour fournir une protection locale en cas d'indisponibilité du serveur et une réplication vers un site
| distant en cas d'indisponibilité de la mémoire et de reprise après incident.
| v La fonction FlashCopy peut être combinée avec n'importe quelle technologie de mémoire externe pour
| fournir une copie de point de cohérence qui permet d'effectuer des sauvegardes ou d'alimenter des
| systèmes de développement ou de test.

| Gestion de la haute disponibilité

| La planification, la configuration et la gestion d'une solution complète à haute disponibilité nécessitent un
| ensemble d'outils et d'offres de gestion. Avec les systèmes IBM i, vous avez plusieurs options possibles en
| matière de gestion de la haute disponibilité.

| Selon vos besoins et vos critères, la gestion de la haute disponibilité fournit des interfaces graphiques, des
| commandes et des interfaces de programme d'application (API) qui permettent de créer et de gérer votre
| environnement. Vous pouvez aussi choisir l'application d'un partenaire commercial IBM. Chacun de ces
| outils a ses avantages et ses limitations.

| Interfaces IBM PowerHA SystemMirror for i

| IBM PowerHA SystemMirror for i, numéro de logiciel sous licence 5770-HAS), est une solution de haute
| disponibilité de bout en bout. Associé à des pools de stockage secondaire indépendants (iASPs) à des
| ressources commutables à haute disponibilité (HASR - Option 41), il constitue une solution solution qui
| est déployée via un serveur IBM System Storage server ou un disque interne. PowerHA fournit plusieurs
| interfaces permettant de configurer et gérer des solutions et des technologies à haute disponibilité.

Présentation de la haute disponibilité 31

| Pour plus d'informations sur les technologies de stockage qu'offre l'IBM i, voir Serveurs de stockage pris
| en charge par PowerHA.

| Le logiciel sous licence IBM PowerHA SystemMirror for i fournit une interface graphique qui vous
| permet de configurer et gérer une solution à haute disponibilité. Ce produit fournit les commandes et les
| API correspondantes aux fonctions en rapport avec les technologies à haute disponibilité. Avec ce logiciel
| sous licence, les administrateurs chargés de la haute disponibilité peuvent créer et gérer une solution à
| haute disponibilité adaptée aux besoins de leur entreprise, en choisissant les interfaces convenant à leurs
| compétences et leur préférences. Vous pouvez aussi utiliser plusieurs interfaces de façon interchangeable,
| à l'aide d'interfaces graphiques pour certaines tâches, et de commandes et d'API pour d'autres.

| Le logiciel sous licence IBM PowerHA SystemMirror for i fournit les interfaces suivantes :
| Interface graphique PowerHA
| Cette interface graphique facilite la configuration, le contrôle et la gestion de votre solution à
| haute disponibilité. Les clients effectuant une mise à niveau à partir d'une édition antérieure à la
| version 7.2 bénéficient d'une interface graphique qui combine la simplicité de l'interface
| graphique High Availability Solutions Manager et la souplesse de l'interface graphique des
| services-ressources de mise en grappe.
| Commandes PowerHA
| Ces commandes vous permettent de configurer et gérer votre solution à haute disponibilité via
| une interface de ligne de commande.
| API PowerHA
| Ces API vous permettent d'utiliser la version PowerHA et de récupérer des informations sur
| PowerHA.

| Interface graphique de PowerHA :

| Le logiciel sous licence IBM PowerHA SystemMirror for i fournit une interface graphique qui vous
| permet d'exécuter des tâches avec les technologies IBM i à haute disponibilité afin de configurer,
| contrôler et gérer une solution à haute disponibilité.

| Vous pouvez utiliser l'interface graphique PowerHA pour créer et gérer des grappes, des groupes de
| ressources en grappe, des domaines d'unité, des domaines d'administration de grappe et des ASP
| indépendants à partir d'un seule interface graphique.
| Information associée:
| Interface graphique PowerHA
| Implémentation de PowerHA

| Option 41 (ressources commutables à haute disponibilité)

| L'Option 41 (ressources commutables à haute disponibilité) est obligatoire lorsque vous utilisez des
| interfaces et des fonctions IBM i de gestion à haute disponibilité. Elle doit être installée pour que vous
| puissiez les exploiter.

| Option 41 (ressources commutables b) est obligatoire pour utiliser les interfaces suivantes :
| v Logiciel sous licence IBM PowerHA SystemMirror for i.
| – Interface graphique PowerHA
| – Commandes PowerHA
| – API PowerHA

| L'option 41 est également obligatoire pour créer ou gérer un domaine d'unité.

32 IBM i - Haute disponibilité - Présentation

| Détection avancée des défaillances des noeuds
| Les Services-ressources de mise en grappe peuvent désormais utiliser une console HMC (Hardware
| Management Console) ou une partition VIOS (Virtual I/O Server) sur un serveur géré IVM (Integrated
| Virtualization Manager) afin de détecter la défaillance d'un noeud de grappe.

| La console HMC (Hardware Management Console) ou un serveur IVM permettent de détecter la

| défaillance d'un noeud de grappe. Le logiciel suivant doit être installé sur un noeud de grappe configuré
| avec un moniteur de grappe.
| v Option 33 IBM i , IBM Portable Application Solutions Environment for i
| v 5733-SC1, IBM Portable Utilities for i
| v Option 5733-SC1 1, OpenSSH, OpenSSL, zlib
| v 5770-UME, IBM Universal Manageability Enablement for i
| Information associée:
| Détection avancée des défaillances des noeuds

| Fonction de haute disponibilité dans le système d'exploitation de base

| Certaines commandes de grappe CL et toutes les API de grappe existent sur l'IBM i de base.

| Commandes de grappe

| Les commandes de grappe suivantes restent dans QSYS à des fins de débogage et pour supprimer les
| objets relatifs à une grappe :
| v Delete Cluster Resource Group (DLTCRG)
| v Dump Cluster Trace (DMPCLUTRC)
| v Change Cluster Recovery (CHGCLURCY)
| v Start Clustered Hash Table Server (STRCHTSVR)
| v End Clustered Hash Table Server (ENDCHTSVR)

| API de grappe

| Vous pouvez écrire votre propre application personnalisée pour configurer et gérer votre grappe à l'aide
| des API de grappe. Ces API tirent parti de la technologie fournie par les services-ressources de mise en
| grappe fournis avec l'IBM i. De nouvelles fonctions améliorées figurent dans les commandes IBM
| PowerHA SystemMirror for i fournies avec le logiciel sous licence IBM PowerHA SystemMirror for i.

Présentation de la haute disponibilité - Informations connexes

Les manuels des produits, les publications IBM Redbooks, les sites Web et d'autres ensembles de
rubriques de l'Information Center contiennent des informations relatives à l'ensemble de rubriques sur la
haute disponibilité. Vous y trouverez également des informations relatives à l'implémentation de pools de
stockage sur disque indépendants, aux technologies PowerHA et à la reprise après incident. Tous ces PDF
peut être consultés ou imprimés.

IBM Redbooks

v IBM i and IBM Storwize Family: A Practical Guide to Usage Scenarios

v IBM i and IBM System Storage: A Guide to Implementing External Disks on IBM i

v Implementing PowerHA for IBM i

v Introduction to Storage Area Networks

Présentation de la haute disponibilité 33

v iSeries in Storage Area Networks: A Guide to Implementing FC Disk and Tape with iSeries

v PowerHA SystemMirror for IBM i Cookbook

v Simple Configuration Example for Storwize V7000 FlashCopy and PowerHA SystemMirror for i

Sites Web
v Haute disponibilité avec IBM PowerHA Il s'agit du site IBM relatif à la haute disponibilité et aux
grappes pour les systèmes i, UNIX et Linux.

v IBM i

v IBM PowerHA SystemMirror for i

v IBM PowerHA SystemMirror for i wiki

v IBM Storage

v Services Power
Ce site IBM contient les services de laboratoire et formations proposés pour les systèmes IBM i.

v IBM System Storage Interoperation Center (SSIC)

v IBM Techdocs Library

Ce site permet d'accéder aux toutes dernières informations en matière d'installation, de planification et
de support technique disponibles auprès du support avant-vente d'IBM. Il est très régulièrement mis à
jour. Vous trouverez les dernières versions des documentations techniques sur la haute disponibilité, les
pools de stockage sur disque indépendants, SAP, JD Edwards, etc.

v Learning Services US
Il s'agit du site IBM pour la formation sur les produits TI, les solutions personnalisées et l'e-Learning.
Vous y trouverez des cours sur la mise en grappe et les pools de stockage sur disque indépendants.

v Performance Management on IBM i

v Recommended fixes
Ce site fournit des liens vers les PTF disponibles pour plusieurs produits IBM i. Pour les PTF liées à la
haute disponibilité, sélectionnez la rubrique High Availability: Cluster, IASP, XSM, and Journal.

Ensembles de rubriques de l'Information Center

v Feuille de route sur la disponibilité
v Haute disponibilité - Présentation
v Technologies à haute disponibilité
v Contrôleur de volume SAN IBM du Knowledge Center
v IBM Storwize V7000 du Knowledge Center
v IBM Storwize V3700 du Knowledge Center
v IBM DS8000 du Knowledge Center
v Implémentation de la haute disponibilité

Autres informations
v Gestion de disques
v Surveillance et contrôle des ressources (RMC)

34 IBM i - Haute disponibilité - Présentation

Remarques
Le présent document peut contenir des informations ou des références concernant certains produits,
logiciels ou services IBM non annoncés dans ce pays.

Ce document peut contenir des informations ou des références concernant certains produits, logiciels ou
services IBM non annoncés dans ce pays. Pour plus de détails, référez-vous aux documents d'annonce
disponibles dans votre pays, ou adressez-vous à votre partenaire commercial IBM. Toute référence à un
produit, logiciel ou service IBM n'implique pas que seul ce produit, logiciel ou service IBM puisse être
utilisé. Tout autre élément fonctionnellement équivalent peut être utilisé, s'il n'enfreint aucun droit d'IBM.
Il est de la responsabilité de l'utilisateur d'évaluer et de vérifier lui-même les installations et applications
réalisées avec des produits, logiciels ou services non expressément référencés par IBM.

IBM peut détenir des brevets ou des demandes de brevet couvrant les produits mentionnés dans le
présent document. La remise de ce document ne vous donne aucun droit de licence sur ces brevets ou
demandes de brevet. Si vous désirez recevoir des informations concernant l'acquisition de licences,
veuillez en faire la demande par écrit à l'adresse suivante :

IBM Director of Licensing

IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
Etats-Unis

Pour le Canada, veuillez adresser votre courrier à :

IBM Director of Commercial Relations

IBM Canada Ltd.
3600 Steeles Avenue East
Markham, Ontario
L3R 9Z7
Canada

Les informations sur les licences concernant les produits utilisant un jeu de caractères double octet,
peuvent être obtenues par écrit à l'adresse suivante :

Intellectual Property Licensing

Legal and Intellectual Property Law
IBM Japan Ltd.
1623-14, Shimotsuruma, Yamato-shi
Kanagawa 242-8502 Japan

Le paragraphe suivant ne s'applique ni au Royaume-Uni, ni dans aucun pays dans lequel il serait
contraire aux lois locales : CE DOCUMENT EST LIVRE EN L'ETAT SANS AUCUNE GARANTIE
EXPLICITE OU IMPLICITE. IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES
INFORMATIONS EN CAS DE CONTREFAÇON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A
L'EXECUTION D'UN TRAVAIL DONNE. Certaines juridictions n'autorisent pas l'exclusion des garanties
implicites, auquel cas l'exclusion ci-dessus ne vous sera pas applicable.

Le présent document peut contenir des inexactitudes ou des coquilles. Il est mis à jour périodiquement.
Chaque nouvelle édition inclut les mises à jour. IBM peut modifier sans préavis les produits et logiciels
décrits dans ce document.

© Copyright IBM Corp. 2002, 2015 35

Les références à des sites Web non IBM sont fournies à titre d'information uniquement et n'impliquent en
aucun cas une adhésion aux données qu'ils contiennent. Les éléments figurant sur ces sites Web ne font
pas partie des éléments du présent produit IBM et l'utilisation de ces sites relève de votre seule
responsabilité.

IBM pourra utiliser ou diffuser, de toute manière qu'elle jugera appropriée et sans aucune obligation de
sa part, tout ou partie des informations qui lui seront fournies.

Les licenciés souhaitant obtenir des informations permettant : (i) l'échange des données entre des logiciels
créés de façon indépendante et d'autres logiciels (dont celui-ci), et (ii) l'utilisation mutuelle des données
ainsi échangées, doivent adresser leur demande à :

IBM Corporation
Software Interoperability Coordinator, Department YBWA
3605 Highway 52 N
Rochester, MN 55901
U.S.A

Ces informations peuvent être soumises à des conditions particulières, prévoyant notamment le paiement
d'une redevance.

Le logiciel sous licence décrit dans ce document et tous les éléments sous licence disponibles s'y
rapportant sont fournis par IBM conformément aux dispositions du Livret Contractuel IBM, des
Conditions d'Utilisation du Code Machine IBM ou de tout autre contrat équivalent.

Les données de performance indiquées dans ce document ont été déterminées dans un environnement
contrôlé. Par conséquent, les résultats peuvent varier de manière significative selon l'environnement
d'exploitation utilisé. Certaines mesures évaluées sur des systèmes en cours de développement ne sont
pas garanties sur tous les systèmes disponibles. En outre, elles peuvent résulter d'extrapolations. Les
résultats peuvent donc varier. Il incombe aux utilisateurs de ce document de vérifier si ces données sont
applicables à leur environnement d'exploitation.

Les informations concernant des produits non IBM ont été obtenues auprès des fournisseurs de ces
produits, par l'intermédiaire d'annonces publiques ou via d'autres sources disponibles. IBM n'a pas testé
ces produits et ne peut confirmer l'exactitude de leurs performances ni leur compatibilité. Toute question
concernant les performances de produits non IBM doit être adressée aux fournisseurs de ces produits.

Toute instruction relative aux intentions d'IBM pour ses opérations à venir est susceptible d'être modifiée
ou annulée sans préavis, et doit être considérée uniquement comme un objectif.

Ces informations sont fournies uniquement à titre de planification. Elles sont susceptibles d'être modifiées
avant la mise à disposition des produits décrits.

Le présent document peut contenir des exemples de données et de rapports utilisés couramment dans
l'environnement professionnel. Ces exemples mentionnent des noms fictifs de personnes, de sociétés, de
marques ou de produits à des fins illustratives ou explicatives uniquement. Toute ressemblance avec des
noms de personnes, de sociétés ou des données réelles serait purement fortuite.

LICENCE DE COPYRIGHT :

Le présent document contient des exemples de programmes d'application en langage source destinés à
illustrer les techniques de programmation sur différentes plateformes d'exploitation. Vous avez le droit de
copier, de modifier et de distribuer ces exemples de programmes sous quelque forme que ce soit et sans
paiement d'aucune redevance à IBM, à des fins de développement, d'utilisation, de vente ou de
distribution de programmes d'application conformes aux interfaces de programmation des plateformes
pour lesquels ils ont été écrits ou aux interfaces de programmation IBM. Ces exemples de programmes

36 IBM i - Haute disponibilité - Présentation

n'ont pas été rigoureusement testés dans toutes les conditions. Par conséquent, IBM ne peut garantir
expressément ou implicitement la fiabilité, la maintenabilité ou le fonctionnement de ces programmes. Les
programmes exemples sont fournis "en l'état", sans garantie d'aucune sorte. IBM ne sera en aucun cas
responsable de tout dommage résultant de l'utilisation de ces exemples de programmes.

Toute copie totale ou partielle de ces programmes exemples et des oeuvres qui en sont dérivées doit
comprendre une notice de copyright, libellée comme suit :

© (nom de votre société (année). Des segments de code sont dérivés des Programmes exemples d'IBM
Corp.

© Copyright IBM Corp. _indiquez l'année ou les années_.

Documentation sur l'interface de programmation

La présente publication Présentation de la haute disponibilité décrit des interfaces de programme
d'application que le client peut utiliser pour écrire des programmes permettant d'exploiter les services
d'IBM i.

Marques
IBM, le logo IBM et ibm.com sont des marques d'International Business Machines Corp. aux Etats-Unis
et/ou dans certains autres pays. Les autres noms de produits et de services peuvent appartenir à IBM ou
à des tiers. La liste actualisée de toutes les marques d'IBM est disponible sur la page Web «Copyright
and trademark information» à l'adresse www.ibm.com/legal/copytrade.shtml.

Adobe, le logo Adobe, PostScript, et le logo PostScript sont des marques d'Adobe Systems Incorporated
aux Etats-Unis et/ou dans certains autres pays.

Linux est une marque de Linus Torvalds aux Etats-Unis et/ou dans certains autres pays.

Microsoft, Windows, Windows NT et le logo Windows sont des marques de Microsoft Corporation aux
Etats-Unis et/ou dans certains autres pays.

Les autres noms de produits et de services peuvent appartenir à IBM ou à des tiers.

Dispositions
Les droits d'utilisation relatifs à ces publications sont soumis aux dispositions suivantes.

Usage personnel : Vous pouvez reproduire ces publications pour votre usage personnel, non commercial,
sous réserve que toutes les mentions de propriété soient conservées. Vous ne pouvez distribuer ou
publier tout ou partie de ces publications ou en faire des oeuvres dérivées sans le consentement exprès
d'IBM.

Usage commercial : Vous pouvez reproduire, distribuer et publier ces publications uniquement au sein
de votre entreprise, sous réserve que toutes les mentions de propriété soient conservées. Vous ne pouvez
reproduire, distribuer, afficher ou publier tout ou partie de ces publications en dehors de votre entreprise,
ou en faire des oeuvres dérivées, sans le consentement exprès d'IBM.

Excepté les droits d'utilisation expressément accordés dans ce document, aucun autre droit, licence ou
autorisation, implicite ou explicite, n'est accordé pour ces publications ou autres informations, données,
logiciels ou droits de propriété intellectuelle contenus dans ces publications.

Remarques 37
IBM se réserve le droit de retirer les autorisations accordées ici si, à sa discrétion, l'utilisation des
publications s'avère préjudiciable à ses intérêts ou que, selon son appréciation, les instructions
susmentionnées n'ont pas été respectées.

Vous ne pouvez télécharger, exporter ou réexporter ces informations qu'en total accord avec toutes les lois
et règlements applicables dans votre pays, y compris les lois et règlements américains relatifs à
l'exportation.

IBM N'OCTROIE AUCUNE GARANTIE SUR LE CONTENU DE CES PUBLICATIONS. LES

PUBLICATIONS SONT LIVREES EN L'ETAT SANS AUCUNE GARANTIE EXPLICITE OU IMPLICITE.
IBM DECLINE NOTAMMENT TOUTE RESPONSABILITE RELATIVE A CES PUBLICATIONS EN CAS
DE CONTREFAÇON AINSI QU'EN CAS DE DEFAUT D'APTITUDE A L'EXECUTION D'UN TRAVAIL
DONNE.

38 IBM i - Haute disponibilité - Présentation

Remarques 39
IBM®

Numéro de programme : 5770-SS1