Intégrer le mainframe au processus de continuité métier

En matière de planification de la continuité métier, les mainframes constituent un sérieux défi. Malgré la puissance de calcul et la résilience qui les caractérisent, ils peuvent en effet tomber en panne et il est difficile de mettre en place un environnement de récupération.

Les mainframes modernes, comme l'IBM zEnterprise EC12, peuvent servir à faire du Cloud computing, hébergent des traitements transactionnels ou sont utilisés pour de l'analytique Big Data. Toutefois, nombre de services qui utilisent des mainframes traitent encore leurs plans de continuité métier comme s’ils étaient restés scotchés en 1964. Les mainframes sont sophistiqués et résilients. Mais malgré ces caractéristiques, voire à cause de celles-ci, de nombreux déploiements sont mal préparés pour gérer les défaillances matérielles et restaurer rapidement un fonctionnement normal.

Un plan de continuité métier aidera les entreprises à identifier les défaillances potentielles, à prendre les mesures nécessaires pour s'y préparer et à définir un schéma pour récupérer et reprendre les opérations rapidement.

La continuité métier inclut l'intégralité de l'architecture informatique : du mainframe aux serveurs conventionnels, sans oublier les réseaux, le stockage, le fonctionnement des workloads, le personnel et les processus.

Tout processus de récupération élaboré dans les règles de l'art identifie à la fois les risques et ce qui doit être protégé (par exemple, des données ou des systèmes entiers).  Il détermine le niveau actuel de protection et ce en quoi il diffère de la protection requise en pratique. Et il prend les mesures nécessaires pour atténuer les risques ou combler les carences en protection.

Les principes de base du processus de planification liée à la continuité d’activité s'appliquent aux mainframes. Mais ces plateformes posent bien plus de défis que des serveurs x86 ou des applications Cloud de type « à la demande ».

Les options de sauvegarde vont de l’ajout d’un deuxième mainframe à la migration vers le Cloud, en passant par l’upgrade de l’existant applicatif vers des plateformes x86. Mais il existe encore d’autres options pour les entreprises.

Tout est question d'applications

Où s'exécuteront les workloads du mainframe si le système est endommagé ou détruit ? En effet, le vrai « hic » dans l'affaire, c'est qu'un système mainframe est si puissant et si fiable qu'il n'existe aucun autre endroit dans lequel restaurer ou transférer les workloads critiques qu'il gère.

Une entreprise typique détiendra des centaines, voire des milliers, de serveurs x86 « de commodité » ; une opportunité considérable pour mettre en place une redondance des systèmes à l'échelle de plusieurs sites. A titre de comparaison, d'autres entreprises déploieront rarement plusieurs mainframes ; une approche qui soulève de sérieuses questions quant à la récupération ou à la migration des workloads.

Les mainframes sont par essence différents des serveurs x86. Leurs applications reposent sur des langages tels que le COBOL qui impliquent des développements de longue haleine. Ainsi, en termes de continuité métier, il peut ne pas exister de plateforme de restauration simple ; difficile d'imaginer le transfert du workload d'un IBM EC12 vers un serveur Windows Dell PowerEdge R920.

Certaines entreprises investissent stratégiquement dans un deuxième mainframe qu'elles destinent à un site secondaire. Cette solution peut s'avérer censée dès lors que le coût du système supplémentaire est inférieur à celui d'une perte d'activité ou d'une infraction à la réglementation en cas de panne.

Pour disposer d'un tel système de secours, vous pouvez envisager un partenariat avec un prestataire en externalisation de mainframes. Cette approche nécessite une optimisation et des tests étendus pour garantir que vos workloads et vos données sont pleinement compatibles avec l'équipement du prestataire ; l'opération pouvant nécessiter des mises à jour et des révisions logicielles. Un fournisseur de mainframes peut garantir le niveau de sécurité et de vigilance requis, et ce sans l'investissement en capital que représente l'installation d'un mainframe supplémentaire sur votre site de reprise après désastre.

Redéfinir les workloads d'un mainframe pour les exploiter sur des serveurs x86 peut s'avérer difficile mais reste une option viable en termes de continuité métier. L'application est alors convertie pour s'exécuter sous Unix, Linux ou Windows et par ailleurs refondue pour des architectures de serveurs distribués.

Si certains outils de refonte peuvent aider, l'optimisation, l'ajustement et la correction des bogues n'iront pas sans impliquer un développement logiciel considérable. Les données stockées sur mainframe devront également être converties dans des formats adaptés au système d'exploitation et à l'application ré-architecturée.

Quelle que soit votre approche, la migration d'une application d'entreprise hors d'un système mainframe requiert du temps et de l'argent.

Doper la continuité métier du mainframe

La planification liée à la continuité d’activité constitue un projet de plus en plus complexe. Car il ne s'agit pas seulement d'exécuter et de contrôler des sauvegardes critiques.

Les mainframes hébergent généralement des applications critiques qui, lorsqu'il s'agit d'améliorer la redondance et de minimiser les interruptions, requièrent une planification supérieure à la moyenne. Les utilisateurs de mainframes, ou les clients et partenaires de l'entreprise, font fréquemment l'objet d'exigences de conformité réglementaire.

Les réglementations imposent des obligations en matière de stockage, de traitement et de sécurité des données, et exigent de connaître la manière dont une entreprise fonctionne et se protège.

Autant de considérations complexes qu'il est possible de rationaliser via des outils sésiés. Par exemple, IBM Tivoli Business Continuity Process Manager centralise la continuité des services informatiques, et aide les administrateurs à planifier, gérer et tester le degré d'aptitude d'une ressource. En outre, l'outil simule certains problèmes afin d'aider le personnel à s'entraîner sur le processus de conitnuité, puis mesure la réaction afin de garantir que les performances satisfont aux objectifs métiers.

D'autres outils, tels qu'IBM Tivoli System Automation (TSA), aident les entreprises à développer et à mettre en oeuvre des réactions automatisées à des problèmes prévisibles, favorisant ainsi une surveillance continue et différents processus de maintenance. Les outils comme TSA prennent en charge les applications, le stockage de données et les équipements réseau inter-plateformes, au moyen de procédures de gestion des workloads incluant à la fois les mainframes et les autres types de matériels.

Si un personnel expérimenté sait faire un usage productif de ces outils, les plans et réactions automatisées doivent faire l'objet d'examens et de révisions fréquents, incluant une prise en compte scrupuleuse de l'évolution des besoins métier. Ne vous servez pas de ces outils comme d'une excuse pour éviter de recruter, de former ou d'embaucher des experts en mainframe.

Aucun plan de continuité ne saurait être statique. Tous doivent être régulièrement révisés et testés de fond en comble. Le processus devra être mis à jour périodiquement ou en cas de changement de situation. Par exemple, votre datacenter était installé de longue date en terrain inondable, mais le risque n'était pas important... jusqu'à cette défaillance de la digue toute proche. Et même avec une attention régulière, le plan doit être réaliste et ne saurait tenir compte de toutes les situations possibles de manière économique.

En matière de planification de la continuité métier, les mainframes constituent un sérieux défi. Malgré la puissance de calcul et la résilience qui les caractérisent, ils peuvent en effet tomber en panne et il est difficile de mettre en place un environnement de récupération.Les mainframes modernes, comme l'IBM zEnterprise EC12, peuvent servir à faire du Cloud computing, hébergent des traitements transactionnels ou sont utilisés pour de l'analytique Big Data. Toutefois, nombre de services qui utilisent des mainframes traitent encore leurs plans de continuité métier comme s’ils étaient restés scotchés en 1964. Les mainframes sont sophistiqués et résilients. Mais malgré ces caractéristiques, voire à cause de celles-ci, de nombreux déploiements sont mal préparés pour gérer les défaillances matérielles et restaurer rapidement un fonctionnement normal.Un plan de continuité métier aidera les entreprises à identifier les défaillances potentielles, à prendre les mesures nécessaires pour s'y préparer et à définir un schéma pour récupérer et reprendre les opérations rapidement.La continuité métier inclut l'intégralité de l'architecture informatique : du mainframe aux serveurs conventionnels, sans oublier les réseaux, le stockage, le fonctionnement des workloads, le personnel et les processus.Tout processus de récupération élaboré dans les règles de l'art identifie à la fois les risques et ce qui doit être protégé (par exemple, des données ou des systèmes entiers).  Il détermine le niveau actuel de protection et ce en quoi il diffère de la protection requise en pratique. Et il prend les mesures nécessaires pour atténuer les risques ou combler les carences en protection.Les principes de base du processus de planification liée à la continuité d’activité s'appliquent aux mainframes. Mais ces plateformes posent bien plus de défis que des serveurs x86 ou des applications Cloud de type « à la demande ».Les options de sauvegarde vont de l’ajout d’un deuxième mainframe à la migration vers le Cloud, en passant par l’upgrade de l’existant applicatif vers des plateformes x86. Mais il existe encore d’autres options pour les entreprises.Tout est question d'applicationsOù s'exécuteront les workloads du mainframe si le système est endommagé ou détruit ? En effet, le vrai « hic » dans l'affaire, c'est qu'un système mainframe est si puissant et si fiable qu'il n'existe aucun autre endroit dans lequel restaurer ou transférer les workloads critiques qu'il gère.Une entreprise typique détiendra des centaines, voire des milliers, de serveurs x86 « de commodité » ; une opportunité considérable pour mettre en place une redondance des systèmes à l'échelle de plusieurs sites. A titre de comparaison, d'autres entreprises déploieront rarement plusieurs mainframes ; une approche qui soulève de sérieuses questions quant à la récupération ou à la migration des workloads.Les mainframes sont par essence différents des serveurs x86. Leurs applications reposent sur des langages tels que le COBOL qui impliquent des développements de longue haleine. Ainsi, en termes de continuité métier, il peut ne pas exister de plateforme de restauration simple ; difficile d'imaginer le transfert du workload d'un IBM EC12 vers un serveur Windows Dell PowerEdge R920.Certaines entreprises investissent stratégiquement dans un deuxième mainframe qu'elles destinent à un site secondaire. Cette solution peut s'avérer censée dès lors que le coût du système supplémentaire est inférieur à celui d'une perte d'activité ou d'une infraction à la réglementation en cas de panne.Pour disposer d'un tel système de secours, vous pouvez envisager un partenariat avec un prestataire en externalisation de mainframes. Cette approche nécessite une optimisation et des tests étendus pour garantir que vos workloads et vos données sont pleinement compatibles avec l'équipement du prestataire ; l'opération pouvant nécessiter des mises à jour et des révisions logicielles. Un fournisseur de mainframes peut garantir le niveau de sécurité et de vigilance requis, et ce sans l'investissement en capital que représente l'installation d'un mainframe supplémentaire sur votre site de reprise après désastre.Redéfinir les workloads d'un mainframe pour les exploiter sur des serveurs x86 peut s'avérer difficile mais reste une option viable en termes de continuité métier. L'application est alors convertie pour s'exécuter sous Unix, Linux ou Windows et par ailleurs refondue pour des architectures de serveurs distribués.Si certains outils de refonte peuvent aider, l'optimisation, l'ajustement et la correction des bogues n'iront pas sans impliquer un développement logiciel considérable. Les données stockées sur mainframe devront également être converties dans des formats adaptés au système d'exploitation et à l'application ré-architecturée.Quelle que soit votre approche, la migration d'une application d'entreprise hors d'un système mainframe requiert du temps et de l'argent.Doper la continuité métier du mainframeLa planification liée à la continuité d’activité constitue un projet de plus en plus complexe. Car il ne s'agit pas seulement d'exécuter et de contrôler des sauvegardes critiques.Les mainframes hébergent généralement des applications critiques qui, lorsqu'il s'agit d'améliorer la redondance et de minimiser les interruptions, requièrent une planification supérieure à la moyenne. Les utilisateurs de mainframes, ou les clients et partenaires de l'entreprise, font fréquemment l'objet d'exigences de conformité réglementaire.Les réglementations imposent des obligations en matière de stockage, de traitement et de sécurité des données, et exigent de connaître la manière dont une entreprise fonctionne et se protège.Autant de considérations complexes qu'il est possible de rationaliser via des outils sésiés. Par exemple, IBM Tivoli Business Continuity Process Manager centralise la continuité des services informatiques, et aide les administrateurs à planifier, gérer et tester le degré d'aptitude d'une ressource. En outre, l'outil simule certains problèmes afin d'aider le personnel à s'entraîner sur le processus de conitnuité, puis mesure la réaction afin de garantir que les performances satisfont aux objectifs métiers.D'autres outils, tels qu'IBM Tivoli System Automation (TSA), aident les entreprises à développer et à mettre en oeuvre des réactions automatisées à des problèmes prévisibles, favorisant ainsi une surveillance continue et différents processus de maintenance. Les outils comme TSA prennent en charge les applications, le stockage de données et les équipements réseau inter-plateformes, au moyen de procédures de gestion des workloads incluant à la fois les mainframes et les autres types de matériels.Si un personnel expérimenté sait faire un usage productif de ces outils, les plans et réactions automatisées doivent faire l'objet d'examens et de révisions fréquents, incluant une prise en compte scrupuleuse de l'évolution des besoins métier. Ne vous servez pas de ces outils comme d'une excuse pour éviter de recruter, de former ou d'embaucher des experts en mainframe.Aucun plan de continuité ne saurait être statique. Tous doivent être régulièrement révisés et testés de fond en comble. Le processus devra être mis à jour périodiquement ou en cas de changement de situation. Par exemple, votre datacenter était installé de longue date en terrain inondable, mais le risque n'était pas important... jusqu'à cette défaillance de la digue toute proche. Et même avec une attention régulière, le plan doit être réaliste et ne saurait tenir compte de toutes les situations possibles de manière économique.