Haute Disponibilité, Notes techniques

Comparatif des solutions de Disponibilité sur IBM i

Publié le 30/06/2020

Avec l’introduction de Db2 Mirror for i, en 7.4, une nouvelle solution de disponibilité des données est proposée sur la plateforme IBM i.

Nous sommes régulièrement interrogés sur les fonctionnalités entre les multiples solutions existantes. Cet article a pour but d’expliquer et de comparer les principales caractéristiques et différences des technologies disponibles sur IBM i, permettant de sécuriser le serveur et les données.

Il n’y aura pas de classement des solutions dans un TOP10 mais juste un positionnement de chaque solution dans une catégorie. Les niveaux de disponibilité ne sont pas identiques, nous verrons que certaines permettent d’obtenir des niveaux plus élevés que d’autres. La classification des offres se décompose en trois niveaux :

  • Solution de Disponibilité Modérée
  • Solution de Haute Disponibilité
  • Solution de Haute Disponibilité avec Continuité d’Activité

Les solutions comparées dans cet article sont les suivantes :

* Nous avons regroupé les principales solutions de réplication logicielle existant sur le marché IBM i, dans une catégorie unifiée, sous le nom « Solutions logicielles », afin de ne pas entrer dans le détail des fonctionnalités de chacune de ces solutions.

Commençons par le sondage effectué par la société HelpSystems, acteur majeur de l’écosystème IBM i. Publié en 2020, il correspond aux chiffres de l’année 2019, sur une enquête réalisée auprès de plus de 500 sociétés réparties dans le monde entier et représentant la majorité des secteurs d’activité.

A la question sur les principales préoccupations des directions informatiques, la Haute Disponibilité est arrivée en seconde position après la sécurité.

Puis sur la question relative aux solutions utilisées pour la disponibilité, on constate qu’un peu plus de 56% des sociétés déclarent disposer d’une solution contre 44% qui n’en possèdent pas.

Pour information, dans le sondage 2019, HelpSystems n’a pas publié ou n’a pas posé la question sur les solutions utilisées. La dernière enquête sur le sujet date de l’année 2017.

Lorsque les entreprises déclarent disposer d’une solution de Disponibilité, les solutions logicielles arrivent largement en tête, puisqu’elles représentent au moins 74% du total. Le hardware, quant à lui, se contentant de 13% des cas au minimum, et pouvant monter à 26% (la catégorie « Autres » correspondant majoritairement à des solutions hardwares).

Comme nous l’expliquions précédemment, les solutions n’ont pas toutes le même niveau de Disponibilité. Elles peuvent être classées en fonction du « nombre de neuf ». Plus ce dernier est élevé, plus la solution sera considérée comme Hautement Disponible.

Source Wikipedia.

La Haute Disponibilité correspond à une valeur de 99,99% (soit moins d’une heure de coupure par an), et la Haute Disponibilité avec Continuité d’Activité correspond à 99,999% (soit 5 minutes de coupure maximum par an).

Si les chiffres semblent proches, il y a quand même une grande différence entre eux, la durée d’indisponibilité est inférieure d’un rapport 10 entre chaque niveau de « 9 ».

Ex : Un système 99,99% est 10 fois moins indisponible qu’un système ayant un niveau 99,9%. En effet le système 99,99% est indisponible moins d’une heure par an (52 minutes) alors que le système 99,9% est indisponible près de 9 heures.

1 – Solutions logicielles

Principes de la technologie

Les solutions logicielles, dites HABP (High Availability Business Partner) sont des applications qui fonctionnent au niveau Operating System IBM i. Elles s’appuient sur la journalisation pour la réplication des données et sur l’audit journal pour la réplication des objets.

Les deux systèmes (Prod et Backup) sont actifs. En cas de bascule, il n’y aura pas nécessité de démarrer le Backup, seuls une inversion des rôles et un démarrage sous-systèmes applicatifs seront nécessaires.

Le principe général, est de répliquer les objets et données sur le système de secours.

Le périmètre de réplication est synchronisé lors de l’installation afin d’avoir une copie exacte des données et objets sur le système secondaire.

Puis, une fois en exploitation, toute création de données (Exemple dans le fichier CLIENTS avec la ligne « Client 666 »), sera répliquée sur le second système grâce à la journalisation.

Même principe pour une suppression de donnée (Exemple avec l’enregistrement « Client 412 » du fichier CLIENTS), lorsque la ligne est supprimée, elle l’est également sur le second système.

De même pour une modification de ligne (Exemple avec la ligne « Facture 3 » du fichier FACTURES). Toute modification est enregistrée dans un poste de journal puis reportée à l’identique sur le second système.

En ce qui concerne les objets (Ex : *PGM, *FILE, *DTAARA, *USRPRF, *DEVD …), toute création, suppression ou modification est inscrite dans l’audit journal et les solutions logicielles reportent cette opération sur le système de secours (Exemple avec la création de l’objet de type *PGM COMPTA).

Résumé de la technologie

  • Journalisation des données
  • Audit journal sur les objets
  • Réplication des postes des journaux
  • Application des postes des journaux sur le Backup

Avantages

  • Granularité de la réplication
  • Utilisation du Backup possible en lecture
  • Sauvegarde déportée sur le Backup
  • Procédure de bascule simple
  • Ne nécessite pas de stockage externe
  • Bande passante réduite pour la réplication
  • Solutions très répandues
  • Ne nécessite pas l’utilisation d’ASP indépendants
  • Réplication synchrone et asynchrone (longue distance)
  • Cluster actif / passif
  • Compatible avec les ASP indépendants

Inconvénients

  • Risque d’oublis ou d’omissions de données dans le périmètre de réplication
  • Utilisation de ressources mémoire et processeur du serveur
  • Administration quotidienne nécessaire
  • Coût des licences élevé
  • Solution non IBM, donc non supportée par le Point Service
  • Faible vitesse de réplication lors des re-synchronisations
  • Pas de cohérence des espaces disque entre les deux serveurs
  • Retards de réplication importants lors de déploiement de grosses applications
  • Pas de continuité de la réplication pendant le changement de version du second serveur

Les solutions logicielles permettent d’obtenir des niveaux de disponibilité très élevés. Il s’agit d’une technologie très performante et extrêmement fiable. C’est également la solution de secours la plus utilisée au monde. Toutefois un arrêt de production de quelques minutes est inévitable en cas de panne de l’infrastructure principale avant de pouvoir basculer sur le Backup.

Ces solutions permettent d’atteindre un niveau de disponibilité de l’ordre de 99,99%, elles sont classées en catégorie Haute Disponibilité.

2 – Miroir IBM i (IBM i Mirroring)

Principes de la technologie

Dans cette solution, dite de miroir IBM i, c’est l’Operating System IBM i qui va se charger de dupliquer les données sur un second système de stockage. A la différence des architectures basées sur la réplication logicielle, le système de secours n’est pas démarré. Cela signifie qu’un démarrage du Backup sera nécessaire lors de la bascule avec les risques qui en découlent.

Le Backup n’est pas démarré car les disques sont sous contrôle de l’Operating System de la Production (miroir IBM i), il s’agit d’une copie intégrale de cette dernière avec les mêmes noms, adresses TCP/IP, paramétrages …

Le principe général est de présenter les deux SAN (Storage Area Network) à la partition IBM i et de mettre en œuvre du mirroring IBM i entre les disques du SAN de Prod et les disques du SAN de Backup.

les disques DD0nA sont en miroir avec leur homologue DD0nB (Ex : DD01A en miroir avec DD01B). Toutes les écritures sur disques (database comme programmes) sont effectuées en parallèle sur chaque disque du SAN A et son miroir sur le SAN B. On obtient ainsi une copie identique de la partition sur le SAN B.

En cas de bascule, il faudra alors démarrer le système B qui utilisera la copie des disques « B ». Si le SAN de Production est également en panne, la copie « A » ne sera plus visible, il n’y aura plus de miroir, la partition fonctionnera mais remontera de nombreuses erreurs liées à la perte des disques « A ».

S’il s’agit d’une permutation des rôles sans panne de la Production ou d’une panne du serveur de Production uniquement, les disques « A » seront bien vus et aucune erreur ne sera remontée.

Vue logique au niveau de l’Operating System.

Attention, en cas de panne, le système sera démarré en IPL anormal, ce qui pourra prendre du temps et on pourra même, dans certains cas, être amené à réinstaller le microcode (LIC) en IPL D et les PTF, pour pouvoir redémarrer correctement.

Résumé de la technologie

  • Réplication assurée par du miroir IBM i (double écriture)
  • Stockage externe obligatoire
  • Système de Backup non démarré
  • Copie intégrale de la Prod (full system)
  • IPL anomal sur le Backup en cas de panne de la Prod

Avantages

  • Solution full IBM
  • Copie intégrale de la Production
  • Pas d’administration à effectuer
  • Pas de coût lié à d’éventuelles licences de réplication

Inconvénients

  • IPL anormal en cas de bascule
  • Risque de ne pas pouvoir redémarrer
  • Cluster actif / inactif
  • Distance de réplication limitée à quelques centaines de mètres (pas de mode asynchrone possible)
  • Messages d’erreur présents si perte d’un système de stockage
  • Utilisation de CPU serveur pour effectuer le miroir

Cette solution entièrement gérée par l’Operating System IBM i est une solution permettant d’obtenir une copie parfaite et intégrale d’un environnement, mais elle n’est pas sans risque. Même si cela se passe généralement bien, le redémarrage du Backup peut s’avérer compliqué (longue durée), voire extrêmement difficile (réinstallation du microcode) dans quelques cas. Elle correspondra aux besoins de certaines sociétés, mais son niveau de disponibilité est inférieur à celui des solutions logicielles.

Cette solution permet d’obtenir un niveau de disponibilité de 99,9%, elle est classée en catégorie Disponibilité Modérée.

3 – Réplication hardware basée sur le SAN

Principes de la technologie

Cette technologie est très proche de la précédente (Miroir IBM i), à la différence près que c’est le SAN qui effectue la copie miroir et non pas l’Operating System IBM i. Les SAN possédant des fonctions de stockage très avancées, offrent également d’autres possibilités comme les réplications asynchrones qui permettent des distances largement supérieures.

Le principe de cette technologie, uniquement disponible avec du stockage externe (SAN), est de décomposer les disques virtuels, présentés à la partition de Prod, en secteurs de 512 octets. Le SAN de Backup dispose également de disques virtuels décomposés en secteurs de même taille, mais ces derniers sont vides lors de l’initialisation.

On s’appuie sur les fonctions de copie du SAN pour répliquer à l’identique, tous les secteurs de la Prod vers ceux du Backup.

Cette fois, la copie est assurée par le SAN en mode synchrone (plus sécurisé) ou asynchrone (plus grandes distances).

Attention, tout comme pour le miroir IBM i, en cas de panne, le système sera démarré en IPL anormal, ce qui pourra prendre du temps et on pourra même, dans certains cas, être amené à réinstaller le microcode (LIC) en IPL D et les PTF pour pouvoir redémarrer correctement.

Schéma d’une bascule sur le Backup après une panne du serveur de Production. Si le SAN de Prod est toujours opérationnel, la réplication MetroMirror (synchrone) ou GlobalMirror (asynchrone) entre les SAN se poursuit mais les rôles sont inversés.

Seuls les SAN IBM sont supportés par IBM, si un SAN d’un autre constructeur est utilisé, alors c’est ce dernier qui devra garantir le bon fonctionnement de la réplication.

Résumé de la technologie

  • Réplication assurée par le SAN (secteurs disque)
  • Stockage externe obligatoire
  • Réplication synchrone (MetroMirror) ou asynchrone (GlobalMirror)
  • Système de Backup non démarré
  • Copie intégrale de la Prod (full system)
  • IPL anormal sur le Backup en cas de panne de la Prod

Avantages

  • Solution full IBM si SAN IBM utilisé
  • Utilisation de la CPU du SAN pour effectuer la réplication
  • Copie intégrale de la Production
  • Pas d’administration à effectuer
  • Limites de distance très élevées
  • Pas de message d’erreur en cas de panne du stockage secondaire

Inconvénients

  • IPL anormal en cas de bascule
  • Risque de ne pas pouvoir redémarrer
  • Cluster actif / inactif
  • Licences nécessaires sur les SAN pour disposer des fonctions de copie

Cette solution permet d’obtenir une copie parfaite et intégrale d’un environnement, mais comme pour le miroir IBM i, elle n’est pas sans risque. Même si cela se passe généralement bien, le redémarrage du Backup peut s’avérer compliqué (longue durée), voire extrêmement difficile (réinstallation du microcode) dans quelques cas. Elle correspondra aux besoins de certaines sociétés, mais son niveau de disponibilité est inférieur à celui des solutions logicielles.

Cette solution permet d’obtenir un niveau de disponibilité de 99,9%, elle est classée en catégorie Disponibilité Modérée.

4 – IBM HyperSwap

Principes de la technologie

La solution IBM HyperSwap est techniquement très proche de la précédente (Réplication Hardware basée sur le SAN) puisqu’elle utilise les mêmes principes de réplication (MetroMirror), mais elle permet également de fortement sécuriser un système de stockage SAN.

Le principe de la technologie est de connecter le serveur de Production aux deux SAN (Prod et Backup) et de faire la même chose avec le serveur de Backup.

Etant donné qu’il s’agit d’une copie full système, le serveur de Backup est arrêté. Le serveur de Production fonctionne avec le SAN de Prod et ce dernier réplique les disques vers le SAN de Backup en synchrone (MetroMirror).

Si le serveur de Prod tombe en panne, il faut démarrer le serveur de Backup, qui utilisera les disques du SAN de Backup.

Attention, tout comme pour le miroir IBM i et pour la réplication hardware basée sur le SAN, en cas de panne, le système sera démarré en IPL anormal, ce qui pourra prendre du temps et on pourra même, dans certains cas, être amené à réinstaller le microcode (LIC) en IPL D ainsi que les PTF, pour pouvoir redémarrer correctement.

Le niveau de disponibilité du serveur avec la technologie HyperSwap est donc identique à celui du miroir IBM i et à celui de la réplication hardware basée sur le SAN, en revanche, l’HyperSwap apporte un niveau de disponibilité très élevé sur le SAN.

En effet, en cas de panne du SAN de Production, le lien qui était en « standby » entre le serveur de Production et le SAN de Backup est immédiatement activé et la copie des disques est aussitôt disponible. Ainsi, il n’y a aucun arrêt de Production lors d’une panne du stockage.

Résumé de la technologie

  • Réplication assurée par le SAN (secteurs disque)
  • Stockage externe IBM obligatoire
  • Réplication synchrone (MetroMirror)
  • Système de Backup non démarré
  • Copie intégrale de la Prod (full system)
  • IPL anormal sur le Backup en cas de panne de la Prod
  • Production ininterrompu en cas de panne du stockage

Avantages

  • Solution full IBM
  • Utilisation de la CPU du SAN pour effectuer la réplication
  • Copie intégrale de la Production
  • Pas d’administration à effectuer
  • Redondance complète et immédiate du stockage
  • Pas d’interruption de l’activité lors d’une panne du stockage

Inconvénients

  • IPL anormal en cas de bascule suite à une panne du serveur
  • Risque de ne pas pouvoir redémarrer après une panne du serveur
  • Cluster actif / inactif
  • Licences nécessaires sur les SAN pour disposer des fonctions de copie

La technologie IBM HyperSwap permet d’atteindre un niveau de disponibilité exceptionnel sur le stockage en maintenant la continuité de service en cas de panne du SAN. Toutefois elle ne permet pas d’assurer un niveau de Haute Disponibilité sur le serveur. Cette solution permet d’obtenir une copie parfaite et intégrale d’un environnement, mais comme pour le miroir IBM i et pour la réplication hardware basée sur le SAN, elle n’est pas sans risque. Elle a le même niveau de risques que ces deux autres solutions. Même si cela se passe généralement bien, le redémarrage du Backup peut s’avérer compliqué (longue durée), voire extrêmement difficile (réinstallation du microcode) dans quelques cas. Elle correspondra aux besoins de certaines sociétés, mais son niveau de disponibilité est inférieur à celui des solutions logicielles.

Si l’on veut profiter de l’excellent niveau de disponibilité de l’HyperSwap, il est recommandé de coupler cette technologie à une autre solution sécurisant mieux le serveur.

Cette solution permet d’obtenir un niveau de disponibilité de 99,9%, elle est classée en catégorie Disponibilité Modérée pour la partie serveur, mais si on ne prenait en compte que la partie stockage (SAN), elle aurait un niveau de disponibilité de 99,999% (5 étoiles – Haute Disponibilité avec Continuité d’Activité). Toutefois, c’est bien le serveur Power et les données qui nous intéressent.

5 – IBM VM Recovery (VMR)

Principes de la technologie

VM Recovery est une variante améliorée de la réplication hardware basée sur le SAN. En effet, cette fonctionnalité utilise la même technologie de réplication, mais intègre en plus, une automatisation de la bascule par la fonction VM Recovery Manager.

Cette solution est déclinée en deux versions VM Recovery HA (mono-site et stockage unique) et VM Recovery DR (multi-site et plusieurs stockages). Le schéma de fonctionnement de la réplication (DR) est similaire à celui de la réplication hardware basée sur le SAN.

L’automatisation des tâches est gérée par une VM nommé KSYS, il s’agit d’un AIX.

VM Recovery HA

VM Recovery DR

Résumé de la technologie

  • Réplication assurée par le SAN (secteurs disque) pour la version DR
  • Stockage externe obligatoire
  • Réplication synchrone (MetroMirror) ou asynchrone (GlobalMirror)
  • Système de Backup non démarré
  • Copie intégrale de la Prod (full system)
  • Automatisation du démarrage mais …
  • IPL anormal sur le Backup en cas de panne de la Prod
  • Redémarrage du secours non garanti

Avantages

  • Solution full IBM
  • Utilisation de la CPU du SAN pour effectuer la réplication
  • Copie intégrale de la Production (VM Recovery DR)
  • Peu d’administration à effectuer
  • Limites de distance très élevées
  • Pas de message d’erreur en cas de panne du stockage secondaire
  • Fonctions d’automatisation du démarrage et des bascules
  • Seul le serveur actif nécessite une licence VM Recovery

Inconvénients

  • IPL anormal en cas de bascule
  • Risque de ne pas pouvoir redémarrer
  • Cluster actif / inactif
  • Licences nécessaires sur les SAN pour disposer des fonctions de copie
  • Licences VM Recovery

A l’instar de la réplication hardware basée sur le SAN, cette solution permet d’obtenir une copie parfaite et intégrale d’un environnement, mais elle n’est pas sans risque. Même si cela se passe généralement bien et malgré l’automatisation de VM Recovery Manager, le redémarrage du Backup peut s’avérer compliqué (longue durée), voire extrêmement difficile (réinstallation du microcode) dans quelques cas.

Cette solution permet d’obtenir un niveau de disponibilité de 99,9%, elle est classée en catégorie Disponibilité Modérée.

6 – IBM Live Partition Mobility (LPM)

Principes de la technologie

Nous intégrons cette solution dans le comparatif afin d’expliquer son mode de fonctionnement car certaines personnes pensent qu’elle permet d’assurer la disponibilité des données, mais ce n’est pas le cas.

Live Partition Mobibility est une fonction permettant de changer de serveur à chaud, sans interruption de Production, mais cette opération doit être planifiée, elle ne fonctionne pas en cas de panne, c’est pour cette raison que bien que nous parlons de cette solution, elle n’est pas considérée comme une option de disponibilité. LPM est l’équivalent, adapté au monde Power d’IBM, de la technologie vMotion de VMWare.

Sur ce schéma, on constate qu’il y a deux serveurs mais un seul stockage, le principe va être de déplacer la VM IBM i de Prod sur le Backup en conservant le stockage de Prod.

Lorsque la bascule planifiée est terminée, c’est-à-dire que la VM s’exécute désormais sur le serveur de Backup, on constate bien que le stockage est toujours celui d’origine, il n’y a pas eu de déplacement du stockage car il n’y a qu’une seule copie des données.

C’est la raison pour laquelle cette solution ne peut pas entrer dans la catégorie de disponibilité des données. En revanche, elle apporte une possibilité de déplacer un environnement vers au second serveur sans stopper la production, et couplée à l’HyperSwap, qui permet le déplacement du stockage à chaud, on peut obtenir une solution permettant de déplacer la totalité d’une infra d’une salle vers une autre salle sans interruption de Production.

Résumé de la technologie

  • Technologie permettant de déplacer une VM IBM i à chaud d’un serveur vers un autre
  • Pas d’interruption de Production
  • Opération planifiée, ne peut pas être utilisée en cas de panne d’une infrastructure
  • Il n’y a pas de déplacement du stockage, seule la VM est déplacée

Avantages

  • Permet d’éviter un arrêt de Production en cas d’arrêt planifié d’un serveur

Inconvénients

  • Ne peut pas être utilisée comme solution de secours en cas de panne car il n’y a pas de réplication des données
  • Le LPM doit être planifié pour déplacer la VM IBM i sur un autre serveur
  • Le stockage utilisé par la VM reste celui de Production

Il ne s’agit pas d’une solution de disponibilité des données, cette technologie est en dehors du périmètre de l’article mais a été abordée car la question sur ses capacités de disponibilité revenait régulièrement.

7 – IBM PowerHA SystemMirror for i

Principes de la technologie

IBM PowerHA SystemMirror for i (ou tout simplement PowerHA pour faire plus court) est une solution full IBM permettant de sécuriser un serveur et ses données en s’appuyant sur une réplication hardware et en la couplant avec des fonctions de clustering.

Mais la grande différence avec la réplication hardware basée sur le SAN, c’est qu’avec PowerHA, seules les données sont répliquées. L’espace disque va être scindé en deux parties :

  • SYSBAS (ASP Système)
  • iASP (ASP indépendant)

Ainsi, les données (tous les objets nécessaires aux applications (tables, vues, programmes, *OUTQ, *DTAARA, *DTAQ …)) vont être positionnées dans l’ASP indépendant et l’ASP système ne contiendra que les objets systèmes (LIC, OS, LPP IBM …).

Cela permet d’avoir, comme pour la réplication logicielle, deux machines actives en simultané avec leur propre adresse TCP/IP.

Le principe de la réplication des données uniquement, se fonde sur la séparation de l’espace disque en deux entités (ASP). Dans le premier il ne reste que la partie Operating System et dans la seconde, il y aura tous les objets relatifs aux applications.

La réplication ne sera mise en œuvre que sur les disques correspondants à l’ASP indépendant. Le système de Backup est également pourvu de deux espaces disques, l’iASP source étant répliqué sur l’iASP cible. Lors de la mise en œuvre, il n’y a aucune donnée sur l’iASP cible (ou miroir).

Puis une fois la synchronisation effectuée en synchrone (MetroMirror) ou en asynchrone (GlobalMirror), les données sont strictement identiques sur les deux ASP indépendants.

Pour information, il existe d’autres variantes de configuration PowerHA, mais nous ne les aborderons pas dans cet article :

  • LUN Level Switching
  • Stretched Cluster
  • Stretched Cluster Enhanced
  • …

Toutes les modifications apportées par les utilisateurs vont se traduire par des modifications des secteurs disque de l’ASP indépendant source, en effet l’ajout d’un objet, d’une ligne de data, la modification d’une donnée ou la suppression d’une donnée correspondent à des écritures sur disque, et toute écriture sera immédiatement reportée sur l’ASP indépendant du système de Backup à l’identique.

En cas de perte du serveur de Prod, la bascule sur le serveur de Backup, qui n’a pas besoin d’être démarré puisqu’il est déjà opérationnel, s’effectue en mettant en fonction l’ASP indépendant (vary-on du device). Cette opération est très rapide puisqu’elle ne prend que quelques secondes. On se trouve alors sur le système de Backup avec les mêmes données que sur l’ancienne Production.

Dans le cas, comme sur le schéma ci-dessous, où seul le serveur de Prod est en panne, la réplication se poursuit entre le SAN de Backup et le SAN de Prod, même en l’absence du serveur de Prod. Toutefois, il faudra remettre le serveur de Prod en fonction pour utiliser les données, mais elles auront tout de même été sécurisées durant sa panne.

Si le SAN de Prod est également en panne, il n’y aura plus de réplication entre les deux SAN comme pour la réplication logicielle.

Ce sont les fonctions de clustering, intégrées dans l’Operating System IBM i, qui se chargent de la détection des pannes et d’automatiser la bascule. Elles peuvent être couplées aux HMC pour une meilleure finesse de détection des erreurs hardware.

Le clustering est également en charge de propager sur le Backup, les objets systèmes restés dans l’ASP système, comme les profils utilisateurs, les devices imprimantes, les valeurs systèmes, les objets *JOBD, *CLS, *SBSD …

Résumé de la technologie

  • Séparation des données dans un ASP indépendant
  • Réplication des données uniquement par le SAN
  • Intégration des serveurs dans un cluster
  • Propagation des objets système vers les différents nodes du cluster

Avantages

  • Toutes les données présentes dans l’ASP indépendant sont répliquées, pas de risque d’oublis ou d’omissions
  • Solution full IBM, supportée par le Point Service (support IBM)
  • Utilisation de la CPU du SAN pour effectuer la réplication
  • Pas d’administration à effectuer
  • Il n’y a pas d’IPL à effectuer pour basculer
  • Cluster actif / passif
  • Licences PowerHA peu coûteuses
  • Sauvegarde déportée possible sur un 3ème node
  • Procédure de bascule simple
  • Réplication synchrone et asynchrone (longue distance)
  • Cohérence des espaces disques entre les deux systèmes (même capacité)
  • Réplication ultra-rapide (copie binaire)
  • Pas d’objets alloués par l’OS car la réplication s’effectue au niveau hardware
  • Pas de retard sur la réplication synchrone quelles que soient les circonstances
  • Pas d’administration quotidienne nécessaire
  • Continuité de la réplication pendant le changement de version du second node

Inconvénients

  • Pas de granularité de la réplication, l’intégralité de l’ASP indépendant est répliquée
  • Migration des données en mode ASP indépendant
  • Licences nécessaires sur les SAN pour disposer des fonctions de copie
  • L’utilisation des données sur le Backup n’est pas autorisée
  • Pas de sauvegarde déportée sur le Backup
  • Bande passante nécessaire pour la réplication, plus importante que pour une solution logicielle
  • Stockage externe obligatoire (sauf si utilisation de la technologie Geographic Mirroring)
  • Nécessite un peu plus de hardware (ports fibre sur le serveur)

La solution PowerHA SystemMirror for i permet d’atteindre un niveau de disponibilité très élevé, identique à celui des solutions logicielles. Tout comme ces dernières, il s’agit d’une technologie fiable, robuste et performante, mais moins répandue. Précisons également, comme pour les solutions logicielles, qu’un arrêt de production de quelques minutes est inévitable en cas de panne de l’infrastructure principale avant de pouvoir basculer sur le Backup.

Cette technologie permet d’atteindre un niveau de disponibilité de l’ordre de 99,99%, elle est classée en catégorie Haute Disponibilité.

8 – IBM Db2 Mirror for i

Principes de la technologie

Nous allons désormais aborder la dernière technologie de disponibilité proposée par IBM. Uniquement disponible sur IBM i 7.4, Db2 Mirror for i est apparue il y a un an (juin 2019) lors de la sortie de la version 7.4. Ne le cachons pas, le niveau de disponibilité de cette solution est un niveau au dessus des autres. Nous allons expliquer brièvement son architecture générale.

Le principe de cette technologie est, contrairement à ce qui est proposé avec les autres solutions, de disposer d’une architecture à deux serveurs en actif / actif.

En effet, la majorité des solutions évoquées précédemment fonctionnent en actif / inactif, c’est-à-dire que le second serveur est arrêté, sauf pour les solutions logicielles et pour PowerHA qui fonctionnent en actif / passif, signifiant que le second serveur est démarré et disponible mais qu’il attend une éventuelle panne ou inversion volontaire des rôles pour être utilisé.

Dans le cas de Db2 Mirror for i, les deux serveurs sont disponibles, et la charge est répartie sur chacun. Il n’y a plus de notion de serveur de Production et de serveur de Backup, les deux serveurs sont considérés au même niveau. Les bases de données sont strictement identiques. Si une panne survient sur l’un des deux nodes du cluster, toute la charge est reportée sur le node restant avec pour conséquence de ne provoquer que la déconnexion des utilisateurs travaillant sur le serveur incriminé et qui seront automatiquement redirigés sur le serveur restant.

Une modification de la database sur l’un des serveurs est immédiatement synchronisée sur le second serveur, il n’y a pas de serveur primaire, les deux sont actifs en simultané.

A noter que la réplication Db2 Mirror for i n’a rien à voir avec toutes les autres modes de réplications, elle n’est ni hardware ni liée à la journalisation. Un nouveau process interne à l’Operating System a été spécifiquement développé par IBM Rochester.

Comme on peut le voir sur le schéma précédent, la réplication s’effectue directement par l’Operating System à travers une liaison dédiée de type RoCE (RDMA over Converged Ethernet ou plus exactement Remote Direct Memory Access over Converged Ethernet) à très haut débit et très faible latence.

Résumé de la technologie

  • Cluster de serveurs en actif / actif
  • La synchronisation des données est bi-directionnelle
  • Les données sont accessibles en simultané sur les deux serveurs
  • La réplication est effectuée par l’Operating System des deux serveurs à travers un liens RoCE à très haut débit et à faible latence
  • Disponibilité permanente des applications

Avantages

  • Cluster de serveurs en actif / actif
  • Les données sont constamment à jour sur les deux systèmes et disponibles en lecture / écriture (réplication bi-directionnelle)
  • Supporte les SAN et les disques internes (de type SSD ou NVMe)
  • Fonctions de synchronisation très avancées
  • Répartition de la charge sur les deux serveurs
  • Permet les mises à jour et le changement de version sans interruption de la Production en basculant alternativement d’un serveur à l’autre
  • Bascule d’un serveur à l’autre quasiment immédiatement
  • Compatible avec les ASP indépendants

Inconvénients

  • Distance entre les serveurs limitée à 200 m avec un switch RoCE ou 100 m sans switch (EDIT : une déclaration d’intention d’IBM précise que la distance maximale va être portée à 10 Km).
  • Les disques internes de type HDD ne sont pas supportés.
  • Un ajustement des applications peut-être nécessaire pour être conforme avec Db2 Mirror for i
  • Nécessite d’avoir le même nombre de licences (IBM et éditeurs de logiciels) sur les deux serveurs
  • Cartes RoCE nécessaires pour la réplication
  • Nécessite l’utilisation conjointe de PowerHA pour la réplication de l’IFS

Cette solution était attendue depuis des années, l’IBM i n’était pas capable de faire tourner des applications en actif / actif sur deux serveurs contrairement à certains concurrents d’IBM (Oracle RAC …). Ce défaut vient d’être corrigé 😉

Le niveau de disponibilité d’un cluster Db2 Mirror for i permet d’exécuter des applications en mode actif / actif avec garantie de la synchronisation bi-directionnelle des données, permettant ainsi d’éviter toute coupure de la Production en cas de panne d’un serveur. Seule une déconnexion avec reconnexion automatique sur le second serveur pourra être constatée pour les utilisateurs qui tournaient sur le node en panne.

Cette technologie permet d’atteindre un niveau de disponibilité de l’ordre de 99,999%, c’est-à-dire que l’indisponibilité est 10 fois plus faible que celle des solutions en 99,99% et 100 fois plus faible que celle des infrastructures à niveau 99,9%. Elle est classée en catégorie Haute Disponibilité avec Continuité d’Activité.

SYNTHÈSE GÉNÉRALE

En résumé, le but de cet article était de repositionner les différentes solutions en fonction de leur niveau de disponibilité sur les données et sur le serveur :

  • Solution de Disponibilité Modérée (99,9%)
    • Réplication hardware basée sur le SAN
    • Miroir IBM i
    • IBM HyperSwap
    • IBM VM Recovery
  • Solution de Haute Disponibilité (99,99%)
    • Réplication logicielle
    • IBM PowerHA SystemMirror for i
  • Solution de Haute Disponibilité avec Continuité d’Activité (99,999%)
    • IBM Db2 Mirror for i

Classification IBM

La notion importante à retenir pour différencier le niveau de disponibilité des solutions, est d’analyser ce qui est répliqué. Si la réplication est de type « full system », cela signifie que le serveur de Backup est OBLIGATOIREMENT ARRÊTÉ et que son démarrage est nécessaire pour un passage en secours. Et dans cette situation, le démarrage sera dans le meilleur des cas, plus au moins long et de type anormal, et dans le pire des cas, ne sera pas possible sans une intervention plus ou moins critique d’un spécialiste.

Toutes les solutions « full system » correspondent à des clusters actif / inactif, il est préférable de disposer d’un cluster actif / passif ou mieux encore, d’un cluster actif / actif, pour obtenir le meilleur niveau de disponibilité.

Chaque solution examinée peut avoir un intérêt en fonction des besoins, contraintes et spécificités d’une société, mais il était important d’expliquer les fondements de chacune, avec avantages et inconvénients, afin d’avoir une vision plus claire avant de s’engager vers une technologie qui ne correspondrait pas aux besoins de l’entreprise.