Dans l`univers de l`IBM Power i

Dans l’univers de l’IBM Power i
Les solutions de Haute Disponibilité matérielles
sont elles
à la hauteur de leurs ambitions ?
Benoit MASSIET du BIEST
ACMI
Septembre 2015
B. MASSIET du BIEST
Copyright ACMI
page 1
Table des matières :
1.
Introduction ........................................................................................................................ 3
1.1
Le SAN dans l’univers du Power i ................................................................................ 3
2.1
Le Hardware mieux que le Software ? ........................................................................ 3
2.
Les solutions de sécurisation des données disponibles ...................................................... 4
3.
Le Power i (l’AS/400) : Un système pas comme les autres. ................................................ 5
3.1
La journalisation .......................................................................................................... 6
3.2
Les technologies pour sécuriser les données d’un Power i......................................... 7
4.
Les niveaux de sécurité et de services évoluent : ............................................................... 8
5. Où se situe le débat (technologie, facilité d’utilisation, temps de basculement, coût,
pérennité).................................................................................................................................... 9
6.
La technologie de réplication disque ................................................................................ 10
7.
Solution XSM : Geographic Mirroring ............................................................................... 14
8.
La réplication logicielle : .................................................................................................... 15
9.
La bonne utilisation des technologies : ............................................................................. 18
10.
L’avenir : la Haute Disponibilité en mode SaaS ............................................................. 19
11.
Conclusion ..................................................................................................................... 20
B. MASSIET du BIEST
Copyright ACMI
page 2
1. Introduction
1.1 Le SAN dans l’univers du Power i
L’architecture IBM Power héberge aujourd’hui l’OS IBM i, bien connu hier sous le nom
d’OS400. Cette plateforme bien particulière, très connue pour sa robustesse et son
intégration, a été conçue dans les années 1980, et voit aujourd’hui son architecture
matérielle évoluer au rythme de toute la gamme IBM.
En particulier, pour le stockage des données sur disque : autrefois, celui-ci était
exclusivement possible sur des disques internes, gérés par l’OS, maintenant, c’est une grande
partie de la gamme de stockage SAN d’IBM et compatibles qui peut être connectée aux
serveurs Power sous IBM i. La connexion peut être native ou utiliser les technologies de
virtualisation de SAN appelé VIOS ou SVC avec les unités de stockage : DS 3000, 4000, 5000,
6000 et 8000, Storwize V3500,V3700 et V7000,
Or les solutions de stockage servent très souvent de base aux solutions de sécurisation des
données, et pour certains OS offrent de réels services de Haute Disponibilité. Mais sont-elles
bien adaptées au Power i, quels sont les avantages et les limites de telles architectures ?
2.1 Le Hardware mieux que le Software ?
En matière de réplication à des fins de Haute Disponibilité : la cause semble entendue, rien
ne sert d’argumenter, « le matériel est plus fiable et plus sûr que le logiciel » !
Notre marché est régulièrement soumis à ces vérités indiscutables, qui réapparaissent
spontanément tels des « marronniers » dans notre presse hebdomadaire.
Seulement les faits sont également têtus, selon les sources en France, plus de 600 sociétés
utilisent des logiciels de réplication pour assurer la sécurité de leur environnement IBM i (ex
AS/400), en revanche seule une poignée de clients ont installé des solutions de réplication
matérielles. Comment expliquer cette différence ? Les solutions sont-elles comparables ?
Offrent-elles des services équivalents au quotidien et en cas de sinistre? Quelles sont les
contraintes, quels sont les couts réels ?
Si la réplication des disques semble sécuriser aisément les environnements Windows,
VMware, AIX, Linux, peut-on disposer d’une véritable Haute Disponibilité pour les données et
les applications sous IBM i ?
Ce document aborde ce vaste sujet, dans le but simplement d’éclairer le lecteur dans la
découverte des différentes solutions possibles.
B. MASSIET du BIEST
Copyright ACMI
page 3
2. Les solutions de sécurisation des données disponibles
Tout d’abord la séparation entre matériel et logiciel semble bien théorique : Les solutions
matérielles récentes embarquent toujours plus ou moins des logiciels spécialisés, notamment
pour les fonctions avancées comme la réplication, et n’offrent pas plus de stabilité ni de
fiabilité que la somme des technologies qu’elles intègrent.
Apportent-elles toute la sécurité attendue ? Sont-elles plus simples à mettre en œuvre, à
utiliser ? De leur côté, les solutions logicielles nées dans les années 1990 souffrent elles de
leur ancienneté ? Ont-elles évolué au rythme des exigences du marché ?
Regardons de plus près :
Il existe de nombreuses manières de protéger des serveurs et leurs données et on distingue
souvent ces solutions selon deux critères :


le RTO (objectif de temps de reprise), c’est-à-dire le temps nécessaire à
l’utilisateur pour se reconnecter à un serveur,
le RPO (point de reprise), souvent traduit par la perte de donnée maximale
acceptable, mesuré en unité de temps,
En voici une liste :








La sauvegarde locale ou déportée,
La journalisation locale ou déportée (remote),
Le mirroring qui se décline à plusieurs niveaux,
Les unités de disques commutables (IASP) soit au niveau tour soit au niveau LUN,
La réplication OS par page mémoire ou Cross Site Mirroring ,
La réplication entre baies de disques (type PPRC ou SRDF) synchrone, ou asynchrone,
avec ou sans IASP,
Les logiciels de réplication de données sur IBM i : MaxAva , Quick Edd, NoMax,
Les logiciels de Haute Disponibilité et de Clustering sur IBM i : Vision (Orion), iTera
HA, Mimix, iCluster
Pourquoi un nombre aussi important de technologies ont-elles été mises sur le marché
depuis la naissance de l’AS/400 ? Il faut probablement chercher une raison de cette
inflation dans la course effrénée de nombreux constructeurs pour attaquer le marché
toujours aussi solide des utilisateurs d’AS/400, iSeries, Power i , IBM i, mais également
par la richesse des technologies déployées autour de la sécurité.
B. MASSIET du BIEST
Copyright ACMI
page 4
3. Le Power i (l’AS/400) : Un système pas comme les autres.
L’AS/400 dès son annonce en 1988, a intégré de nombreuses caractéristiques, qui
apparaissent aujourd’hui) à la fois originales et modernes comme l’indépendance entre le
matériel et le logiciel, l’adressage natif sur 64 bits, une base de données relationnelle
intégrée, mais surtout, l’espace adressable unique.
Cette particularité, mauvaise traduction de « single level storage », garantit à l’utilisateur une
gestion complète des données par le nom de l’objet qui les contient, jamais par son adresse.
Ainsi, la localisation des données entre la mémoire principale (mémoire vive) et la mémoire
secondaire (sur disque) échappe totalement au programmeur. Ajoutez à cela, que les fichiers
sont volontairement morcelés et écrits sur un maximum de disques (data stripping) pour
maximiser le débit en écriture, vous comprenez aisément que la gestion de la sécurité des
données est un point très sensible dans l’environnement IBM i.
Ainsi, lorsqu’une transaction vient modifier le contenu d’une page mémoire, celle-ci a de
fortes chances de se trouver en mémoire principale (plus rapide), seule une action
particulière de l’OS va forcer son écriture sur disque : par exemple, l’écriture forcée d’un
poste de journal sur disque, le management des pages mémoires selon leur fréquence
d’utilisation, le management des journaux et la fermeture du fichier. Par voie de
conséquence, les disques ne contiennent à un instant T, qu’une partie incomplète, voire
fragmentée des données. De plus, l’arrivée d’une écriture sur disque, ne correspond pas
B. MASSIET du BIEST
Copyright ACMI
page 5
nécessaire à l’intégralité d’une transaction, l’espace disque contient des données partielles
non nécessairement intègres ni cohérentes entre elles.
Seule une action volontaire du système ou de l’utilisateur (d’un DBA) peut forcer l’écriture de
toutes les pages mémoires sur disques et rendre cohérent cet espace. Cela peut se faire par
un passage en mode « restreint utilisateur », par un Quiesce (nouvelle commande apparue
avec l’OS V6 qui permet de forcer l’écriture sur disque de l’ensemble des transactions en
cours de traitement et présentes uniquement en mémoire).
3.1 La journalisation
Une fonction essentielle de l’OS, permet d’historiser toutes les transactions et en plus est
nativement écrite sur disque : c’est la journalisation des fichiers physiques. Par ce mode,
toute transaction DB2, est copiée en temps réel dans un fichier ‘log’ spécial, le journal,
composé d’une série de récepteurs, qui contient toutes les données, créées ou mises à jour
‘update’, ainsi que de nombreuses informations relatives à cette donnée (job, utilisateur,
heure et date de création, etc).
D’autres caractéristiques du journal doivent être citées ici :


Le poste écrit dans un journal (journal entry) précède l’écriture dans la base de
données,
Le journal peut être écrit sur le système, ou plus fréquemment doublé (écrit en
miroir) sur un système distant, il porte alors le nom de remote journal,
B. MASSIET du BIEST
Copyright ACMI
page 6

Un journal contient les transactions d’un ensemble choisi de données, plusieurs
fichiers, plusieurs bibliothèques, il comprend également des postes spéciaux destinés
à des actions ultérieures. De plus, la donnée modifiée peut également être précédée
par l’image de cette donnée avant la modification. Ce mode d’écriture est
particulièrement utile pour la protection dite de ‘commitment control’
Il existe également un autre journal appelé journal d’audit (QAUDJRN), qui contient les
informations relatives aux modifications sur les objets autres que les fichiers.
Nous comprenons donc que la journalisation de l’ensemble de la base constitue un élément
clef de la sécurisation de ces données. Cette journalisation est la source essentielle et la base
des solutions de Haute disponibilité logicielle, mais elle n’est pas utilisée comme telle par les
solutions de réplication matérielles puisque ces solutions sont agnostiques (indépendantes
du système de fichiers qu’elles hébergent).
Notons tout de même que la présence de ces données dans un fichier ou sur un disque ne
permet pas à elle seule de garantir l’intégrité d’une base ni la cohérence de tous ces fichiers
entre eux.
La réplication de pages mémoires :
Une autre fonction de l’OS apparait avec la V5R4, elle consiste à propager les pages
mémoires modifiées vers un serveur distant, sans utiliser de mécanisme lié au disque.
Cette fonction est assurée par une série de fonctions et d’utilitaires contenus dans l’option
41 (HA Switchable Ressources) du système d’exploitation.
Cette solution est connue sous le nom de XSM (Cross site Mirroring ou Geographic Mirroring)
et permet de mirrorer un IASP sur un autre système distant. Un certain nombre de
limitations et de contraintes empêche réellement d’utiliser cette solution à des fins de haute
protection. Nous verrons ultérieurement plus en détail les limites de cette solution.
3.2 Les technologies pour sécuriser les données d’un Power i
Pour protéger en temps réel des données, les fournisseurs ont donc plusieurs solutions :
1. Utiliser les fonctions de mirroring natives de l’OS (IBM i) pour écrire en double sur un
disque (IASP) local et un IASP distant,
2. Utiliser les mécanismes de réplication de page mémoire de l’OS,
3. Utiliser la journalisation en mode local ou remote, synchrone ou asynchrone pour
assurer cette réplication,
4. Capturer les données par programme et gérer directement la mise à jour d’une base
miroir,
5. Utiliser des mécanismes de réplication propres aux baies de disques qui hébergent
les données.
B. MASSIET du BIEST
Copyright ACMI
page 7
Nous allons voir comment le choix de la technologie de la réplication influence :





l’intégrité des données,
le temps de surveillance nécessaire du bon fonctionnement de la solution,
la capacité à basculer sur le serveur de secours en cas de sinistre ou de basculement
planifié, le temps de basculement, le niveau d’expertise requis,
la capacité à utiliser le serveur de secours à d’autres usages pour accroitre le niveau
de service,
Le niveau de compétences requis pour maintenir en conditions opérationnelles
chaque type de solution (spécialiste IBM i, stockage, VIOS, …).
Glossaire :
4. Les niveaux de sécurité et de services évoluent :
Nous pouvons nous interroger sur le sens exact du terme « Haute Disponibilité » :
Aujourd’hui les entreprises attendent de leur service informatique, une continuité totale de
l’activité, sans perte de données, et donc une maitrise des risques normaux liés aux
technologies.
Cette continuité exige tout aussi bien la protection contre les sinistres, mais également
contre tout arrêt intempestif quotidien. Cela va de la sauvegarde aux opérations de
maintenance nécessaires.
B. MASSIET du BIEST
Copyright ACMI
page 8
Dans certains domaines, le respect total des normes de sécurité et la traçabilité sont imposés
par le secteur d’activité (Bancaire : Bale II, Assurance Solvency II, Agroalimentaire FDA /
traçabilité totale, SOX etc..) ; dans ce cas, la protection continue des données devient
primordiale ; elle doit permettre d’assurer la capacité à restaurer toutes données traitées,
quelle que soit la nature de l’arrêt ou de la panne d’un dispositif dans la chaîne de traitement
informatique.
Très tôt dans l’histoire de l’AS/400, les solutions de sécurisation matérielles et logicielles ont
été mises en œuvre. Tout d’abord, pour sécuriser ce qui semblait être le talon d’Achille de
cette architecture : l’espace disque. En effet la perte d’un seul disque dans un « pool »
mémoire (ASP), entrainait inéluctablement la perte de la totalité des données, puisque nous
savons que celles-ci sont réparties sur l’ensemble des disques disponibles dans l’ASP.
Ainsi sont apparues les solutions de mirroring (Disques, Bus ,etc..) puis de RAID-5, 1, 10 etc.
Dans le même temps, la réplication des données sur un site distant est apparue très vite
indispensable pour les utilisations critiques (applications bancaires, médicales, ..). Elles sont
devenues des solutions de mirroring système, aujourd’hui appelées Clusters de Haute
Disponibilité.
Les besoins essentiels étaient alors de garantir la récupération des données en cas d’incident
(RPO ~0), le temps de basculement des utilisateurs était une exigence secondaire.
Aujourd’hui, le terme de haute disponibilité prend tout son sens, la solution mise en place
doit pouvoir couvrir non seulement des temps de redémarrage toujours plus court, mais
également des fonctions plus utiles au quotidien :






Assurer un basculement rapide (RTO de moins d’une heure, si possible 15 mn) sans
perte de données sur le site de secours (RPO~0),
Permettre la sauvegarde quotidienne des données sans interruption de services
auprès des utilisateurs,
Assurer les opérations de maintenances sans interruption de services auprès des
utilisateurs : montée de version logicielle, modification « hardware », « reclaim
storage »,
Permettre les changements de serveurs (évolution technologiques, consolidation
physique vers virtuel) sans impact utilisateur,
Faciliter les déménagements d’un site de production sans interruption de service,
Permettre l’extraction des données ou l’exécution de requête en lecture seule, sans
perturber la production.
5. Où se situe le débat (technologie, facilité d’utilisation, temps de
basculement, coût, pérennité) ?
B. MASSIET du BIEST
Copyright ACMI
page 9
Selon le point de vue de votre interlocuteur commercial, ou technique, les avantages mis en
exergue ne concerneront souvent qu’une partie du problème.
En première approche, nous entendons souvent que le marché tend inéluctablement vers
l’intégration dans le matériel de fonctions hier fournies par des logiciels.
De plus, les volumes croissants de données rendraient impossibles la gestion fine d’une
réplication.
Mais aussi, que les serveurs et applications toujours plus complexes, comportent des
multiples bases de données et d’objets « système », et que seule une réplication matérielle
permettra d’assurer un redémarrage complet et cohérent.
Et pour finir, IBM serait le seul fournisseur à pouvoir intégrer dans sa technologie, les
fonctions indispensables à la sécurisation de ses propres matériels.
Penchons-nous un peu vers les technologies présentes :
6. La technologie de réplication disque
Les réplications « hardware » liées ou non à des technologies de baies, consistent à répliquer
en local ou à distance et en temps réel, le contenu des données sur disques, le plus souvent
contenu dans un IASP.
B. MASSIET du BIEST
Copyright ACMI
page 10
Comme nous l’avons vu plus haut, l’espace adresse unique sous IBM i crée une singularité et
impose une logique de réplication cohérente avec la nature de l’espace à protéger et de la
donnée à répliquer.
Ainsi protéger l’espace disque uniquement revient à répliquer une partie de l’ensemble des
données dont les toutes dernières ont de très fortes chances de se trouver en mémoire
principale et non sur disque. Cet espace est du point de vue de l’application comme une belle
« part de gruyère », nécessairement pleine de trous. Ces trous représentent les données, les
pointeurs, qui n’ont pas encore été écrits sur disque.
Certes, si l’espace répliqué contient bien le journal des fichiers physiques (le sac de billes ) et
l’audit journal alors les données et objets contenues dans ces journaux devraient permettre
de récupérer les données perdues.
Et bien NON ! Ce sac de billes et cet espace rempli de trou : le gruyère n’ont pas été créés et
remplis de manière cohérente, rien dans la gestion des pages mémoires ne garantit que les
données du journal permettent de combler les données manquantes sur l’espace disque.
Lors d’un basculement, il faut reconnecter l’espace disque de secours sur le système de
secours au sens logique, c’est-à-dire que ce système puisse gérer les adresses de cette
nouvelle unité de disque. Il faut donc un « vary-on » de l’IASP précédé d’un IPL anormal dont
une des fonctions est justement de tenter de récupérer les données incomplètes et de
valider l’intégrité de l’ensemble des objets. Cette phase peut prendre plusieurs heures,
durant laquelle doit s’effectuer pas moins de 34 étapes de « recovery » différents avant de
pouvoir redémarrer les applications.
Un récent test réalisé en vraie grandeur a été réalisé par un important client situé au GrandDuché du Luxembourg. Ce client a simulé trois sinistres, en arrêtant brutalement ses baies de
stockage connectés sur le serveur de production.
Le résultat est sans appel : Dans deux cas sur les trois possibles, les données contenues sur
l’unité de disque cible ont été partiellement corrompues et des objets étaient irrécupérables,
malgré ces deux IPLs et l’exécution de tous les outils de récupération fournis par IBM (cf.
expérience).
B. MASSIET du BIEST
Copyright ACMI
page 11
Dans tous les cas, les données répliquées doivent être stockées sur des baies compatibles
entre elles et stockées dans des IASP.
Notez que la mise en œuvre des IASP exige une modification de vos logiciels ou le support de
votre éditeur de logiciel applicatif, en effet, l’IASP impose un nouveau mode d’adressage des
objets.
Nous voyons que la technologie de réplication partielle de l’espace mémoire, ne garantit pas
la reprise sur des données cohérentes.
Pour essayer de positionner cette solution de réplication hardware, regardons les critères
d’usages suivants :
RTO : de 1 à 4 heures
RPO : non garanti, risque de corruption de données
Distance : Pour éviter les risques de perte de données, il est préférable d’être synchrone
(MetroMirror) donc les distances doivent êtres faibles (Fibre optique quelques kilomètres au
maximum)
Débit réseau : Elevé, l’élément répliqué est un secteur, le débit nécessaire est en moyenne
10 fois plus important que pour la réplication logicielle. De plus, il est difficilement prévisible.
Architecture nécessaire : les serveurs, leur OS, doivent être de même niveau technologie, de
version d’OS et PTF’s. Les baies de disques doivent également être compatibles et équipées
B. MASSIET du BIEST
Copyright ACMI
page 12
des mêmes logiciels de réplication (PPRC, SRDF, etc.) et les évolutions systèmes doivent
s’effectuer simultanément sur les systèmes source et cible.
Architecture possible : 1 vers 1, soit une réplication simple, il n’est pas possible aujourd’hui
de multiplier les nœuds dans une architecture en Y ou en cascade.
Accès aux données répliquées : Non, un seul système peut lire et écrire sur l’espace disque
de secours, mais par un arrêt momentané, puis un flash copy, il est possible créer une image
de l’espace répliqué, Celle-ci doit être alors connectée à un autre serveur pour être utilisable.
Sélection du périmètre répliqué : par IASP entier, de plus, pour être complet, les données
systèmes (SYSBAS) doivent être sécurisées par un autre mécanisme logiciel.
Surveillance faible : Une surveillance quotidienne est toutefois nécessaire pour corriger les
erreurs de réplication et autres défauts lié au système.
Conditions de basculement : les basculements planifiés ou non planifiés nécessitent un à
deux IPLs, la gestion du basculement (ou du cluster éventuel) doit être assuré par un
spécialiste.
Support du commit control : les processus de « roll back » doivent être déclenchés par
l’application, les logiciels de réplication ne communiquent pas avec la couche applicative
CDP (Continuous Data Protection) : Ces fonctions ne sont pas assurées par les baies ou les
disques pour l’environnement IBM i.
B. MASSIET du BIEST
Copyright ACMI
page 13
7. Solution XSM : Geographic Mirroring
C’est certainement la raison qui a conduit IBM, à relever d’un cran le niveau de capture des
modifications et développer une réplication fondée sur les pages mémoires. C’est le Cross
site Mirroring appelé aujourd’hui Geographic Mirroring.
Malheureusement cette technologie ne couvre pas l’intégralité des objets, elle ne permet
d’assurer que le mirroring d’un IASP, sans inclure les données de l’environnement système
(SYS BAS), elle ne fonctionne qu’en mode synchrone.
Elle nécessite un serveur de secours prêt à reconnecter l’IASP secouru, mais ce dernier ne
pourra accéder aux données de l’IASP qu’après une reconnexion (Boot) de la tour de disque
distant (Vary On).
En d’autres termes, cette solution, qui semblait plus cohérente avec l’architecture du Power
i, apporte son lot de contraintes, sans réellement se démarquer des solutions disques.
A notre connaissance, cette solution est très peu installée en France.
B. MASSIET du BIEST
Copyright ACMI
page 14
8. La réplication logicielle :
Depuis leurs premières versions apparues dans les années 1990, ces logiciels ont utilisé le
contenu des récepteurs de journaux, pour maintenir une base de données répliquée à
l’image du serveur source. L’avantage principal tient dans la réplication des seules
modifications, ce qui réduit au minimum l’occupation de la bande passante du lien de
communication entre les deux serveurs
Le transfert est assuré par IP, la réplication est le plus souvent asynchrone. Elle peut être
synchrone en déclarant ce mode lors de la mise en œuvre du remote journal.
Il ne s’agit donc pas d’un couplage entre dispositifs matériels, mais de deux systèmes
indépendants qui assurent des rôles différents : Production = émission, Secours : réception et
contrôle. Leur rôle peut être inversé à la demande, lors d’un basculement.
Les flux de réplication peuvent ainsi être multiples, indépendant des architectures
matérielles et les topologies matérielles de réplication multiples.
Cette architecture logicielle respecte parfaitement celle de l’IBM i, en particulier l’espace
adressable unique, les deux systèmes sont, à tout moment, capables de prendre un rôle de
production (source) ou de secours (cible) et en cas de sinistre, et toutes les données propres
à chaque serveur restent cohérentes entre elles.
Le RPO est assuré par l’absence de retard à l’envoi, et la bonne gestion du périmètre de
réplication, le RTO par la capacité à lancer rapidement les applications, sous systèmes et
basculer le réseau des utilisateurs.
Les différents logiciels existants vont différer par les mécanismes de réplication interne,
l’exploitation des nouveautés de l’OS liés aux journaux, la richesse de mécanisme de
contrôle, et la présence ou non de services capables de gérer le basculement.
Certaines solutions utilisent nativement la journalisation distante : (Remote journal) en voici
leurs fonctionnements comparés.
B. MASSIET du BIEST
Copyright ACMI
page 15
Le remote journal, apparue dès la V4R2 a apporté une grande simplification dans la gestion
de la réplication, en fiabilisant le transport des données et en réduisant la latence entre les
systèmes.
Une véritable solution de Haute Disponibilité :




doit être capable d’assurer des tests réguliers, sans nécessairement perturber
l’ensemble des utilisateurs,
doit permettre d’effectuer les sauvegardes sur le serveur de secours tout en
maintenant la réplication active, et pendant l’exécution de travaux ou de la
production sur le serveur principal
doit posséder des mécanismes d’alerte pour assister l’opérateur dans le maintien de
la réplication,
et fournir également un gestionnaire de basculement pour accompagner les
opérations de test planifié (switch over) ou de basculement sur sinistre (Fail over)
Regardons les critères d’usage des solutions logicielles :
RTO : de 15 min à 1 heure : La mise en place d’un cluster permet d’automatiser la détection
et de descendre à quelques minutes (fonction des performances et temps de redémarrage
applicatif)
RPO : proche de zéro ; La protection parfaite est possible, elle nécessite l’activation de la
journalisation remote synchrone (fonction standard de l’OS), mais entraine des contraintes
B. MASSIET du BIEST
Copyright ACMI
page 16
de performance et de débit. Les données perdues et non répliquées peuvent provenir des
transactions en cours d’écriture, ou en cours d’envoi. La maitrise du réseau et de
l’équilibrage des performances de chaque système permet de réduire ce risque.
Distance : La réplication étant asynchrone, il n’y a pas de limite de distance. Cette solution
rend possible les services de PRA à distance (solution Cloud).
Débit réseau : faible, seules les transactions en écriture sont répliquées. L’application des
modes d’optimisation de l’OS comme le « journal minimum data » permet de réduire encore
la bande passante utilisée. De plus, il est prévisible par une simple étude préalable des
volumes des écritures sur les serveurs.
Architecture nécessaire : les serveurs, leur OS, et les unités de stockage peuvent être
différents entre la source et la cible : disques internes ou disques externes, performances
allouées, version d’OS et PTF’s différentes. Des recommandations raisonnables concernent la
performance, la mémoire, le réseau, les unités de sauvegardes, et pour le serveur de secours
la compatibilité ascendante des codes exécutables. Ceci est généralement possible entre OS
avec au plus deux niveaux de release d’écart.
Architecture possible : Un vers Un, Un vers N, N vers Un . Les flux de réplication peuvent être
aisément utilisés pour préparer les déménagements ou simplement offrir un niveau de
sécurité additionnel par une réplication à distance.
Accès aux données répliquées : Oui: les deux ou N serveurs sont indépendants, ce qui
permet l’extraction de données, les sauvegardes pendant l’activité. Pendant ces opérations,
la sécurité des données est assurée en maintenant le flux de réplication actif.
Sélection du périmètre répliqué : Oui, le choix peut concerner l’ensemble des bibliothèques,
programmes et fichiers d’une application critique, en excluant les historiques ou autres
données temporaires. Tous les objets systèmes et applications sont également concernés.
Surveillance faible : Une surveillance quotidienne est toutefois nécessaire pour corriger les
erreurs de réplication et autres défaut système. Elle est assistée par des mécanismes
d’alertes qui réduisent le temps de nécessaire à la correction d’éventuelles erreurs.
Conditions de basculement : les basculements planifiés ou non planifiés sont
préprogrammés et peuvent être réalisés sous le contrôle d’un opérateur formé.
Support du commit control : Oui, si l’application le permet, le basculement peut assurer les
"roll back" nécessaires.
CDP (Continuous Data Protection) : Oui, par l’historisation des transactions la plupart des
logiciels permettent de reconstituer l’état d’un fichier ou d’une base en un point quelconque
du passé.
B. MASSIET du BIEST
Copyright ACMI
page 17
Synthèse des services rendus par les différents types de solutions possibles
9. La bonne utilisation des technologies :
Comme nous l’avons vu, le niveau de protection et de service rendu dépend des technologies
mises en œuvre ainsi que de la qualité des prestations de services nécessaires.
Une bonne solution de haute disponibilité doit être testée régulièrement, et les responsables
de son exploitation ne doivent pas hésiter à l’utiliser dès que nécessaire.
L’équipe en charge des systèmes doit connaitre les impacts d’un basculement vers le système
de secours et d’un retour en situation normale afin de faciliter leur prise de décision de
l’utilisation de la solution de haute disponibilité. Les tests permettront également de
maintenir un bon niveau de confiance de la solution. Ceci est un élément important dans la
prise de décision qui aura lieu dans une situation de crise.
Si les solutions de stockage ne proposent pas de véritables solutions de Haute Disponibilité,
elles permettent toutefois de bâtir des solutions de reprise à distance, et offrent toujours
B. MASSIET du BIEST
Copyright ACMI
page 18
l’avantage de consolider tous les besoins en stockage de l’entreprise, quel que soit le nombre
de serveurs, leur système d’exploitation et la nature des données.
C’est pourquoi, nous voyons souvent des solutions de réplication logicielle installées sur des
architectures munies de baies de stockage. Chaque environnement garde ses qualités
propres.
10.L’avenir : la Haute Disponibilité en mode SaaS
Grâce à la souplesse apportée par ces solutions logicielles, une offre de PRA à distance
vendue sous forme de service se développe à grande vitesse. Elle permet aux entreprises de
se consacrer pleinement au développement de leurs activités, confiant la gestion de
réplication, à des mains expertes et dans des lieux sécurisés, sans investissement lourd à la
clef.
B. MASSIET du BIEST
Copyright ACMI
page 19
11.Conclusion
Si le choix d’une bonne solution de Haute Disponibilité est critique pour l’entreprise, il doit
surtout permettre d’améliorer le niveau de service auprès des clients et aborder les
évolutions futures sans contraintes ou avec des facilités nouvelles.
La démarche est d’autant plus complexe, qu’elle est brouillée par la panoplie des
technologies disponibles et par le nombre croissant d’intervenants et les compétences
nécessaires pour comprendre, utiliser, gérer les évolutions et administrer ces solutions.
L’offre de stockage sur Power i est aujourd’hui plus riche avec l’arrivée des Storwize V3700,
Storwize V7000, et le SVC (SAN Volume Controller), les différentes déclinaisons de solutions
de protection de données (Lun Level Switching, GeographicMirroring, MetroMirror,
GlobalMirror) sont toujours plus variées, mais elles n’assurent pas les objectifs premiers
d’une Haute Disponibilité véritable sur IBM i en n’offrant pas la garantie totale de protection
des données en cas de sinistre, ni les facilités d’usage offertes par les solutions logicielles.
Mais alors, comment aborder cette problématique ?
Une bonne démarche doit s’initier par les questions suivantes :









Quel est l’objectif de protection (RPO, RTO) ?
Quels sont les risques qu’il faut contrôler ? Pannes, EDF, Risques naturels, Sociaux …
Quels sont les besoins dictés par l’activité de l’entreprise, le niveau de service
souhaité par les clients et les utilisateurs ?
Quels sont les objectifs de niveau de service, la stratégie vis-à-vis des utilisateurs ?
Quelle solution permettra d’atteindre ces objectifs et de couvrir ces risques ?
Ou doit-on localiser le site de secours ?
Quelle technologie saura assurer cette Haute Disponibilité ?
Quel fournisseur est capable d’accompagner l’entreprise aujourd’hui et demain ?
Quels retours d’expérience de clients ayant basculé lors d’un sinistre ou de tests
réguliers ?
B. MASSIET du BIEST
Copyright ACMI
page 20