dans l’univers de l’ibm power - acmi · 3.2 les technologies pour sécuriser les données...

B. MASSIET du BIEST Copyright ACMI page 1

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


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


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.


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é.


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


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,


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.


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.


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é) ?


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.


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 Grand-

Duché 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).


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


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.


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.


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.


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


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é.


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


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.


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 ?

dans l’univers de l’ibm power - acmi · 3.2 les technologies pour sécuriser les données...

Documents