La Haute Disponibilité et les environnements Oracle – partie 7

Dans la cinquième partie de notre dossier La Haute Disponibilité et les environnements Oracle, nous avons examiné les Solutions Oracle de Haute Disponibilité pour les ARRETS DE PRODUCTION PLANIFIES. Voici la septième partie de ce dossier dans laquelle nous allons examiner comment définir les besoins en Solutions Oracle de Haute Disponibilité.

Article précédent : La Haute Disponibilité et les environnements Oracle – partie 6 : Solutions pour arrêts de production non planifiés.

Déterminer les besoins en haute Disponibilité

Une entreprise qui veut mettre en œuvre une stratégie de Haute Disponibilité doit commencer par analyser attentivement ses processus métiers nécessitant la Haute Disponibilité. Voici quelques étapes indispensable dans la mise en œuvre de la haute Disponibilité :

• Remplacements des systèmes existants
• Investir dans des systèmes plus performants et robustes
• Reconcevoir l'ensemble de l'architecture informatique et des procédures pour atteindre une solution de Haute Disponibilité
• Reconcevoir les processus métiers
• Faire monter en compétence les membres du système informatique ou procéder à des embauches

Il est nécessaire d'utiliser une méthodologie pour définir correctement les besoins en Haute Disponibilité d'une activité. En combinant les besoins métiers et une connaissance des coûts d'investissement liés aux différentes solutions de Haute Disponibilité, vous pourrez concevoir et mettre en oeuvre une architecture de Haute Disponibilité qui répondra aux objectifs métiers et techniques. Voici la démarche proposée :

1. Entreprendre une analyse d'impact métier
2. Identifier et classer les processus métier critiques qui ont des exigences de haute disponibilité
3. Calculer le coût de la non-disponibilité du système informatique
4. Définir les objectifs d'utilisation, de RTO (Recovery Time Objective), de RPO (Recovery Point Objective) pour les différents processus métiers.
5. Comprendre les objectifs de gestion, de coût total de possession (TCO), et de retour sur investissement (ROI)

Cette méthodologie permet de définir des SLA (Service-Level Agreements) liés à la Haute Disponibilité pour les aspects critiques des processus métiers. Voici par exemple une répartition des processus métiers en plusieurs catégories :

• Catégorie 1 : ces processus métiers ont le plus grand impact sur l'activité. Ils ont les exigences les plus strictes de Haute Disponibilité, avec un RTO et un RPO proche de zéro, et nécessitent des systèmes disponibles en permanence. Exemple : système d'e-Commerce construit sur un site Web.
• Catégorie 2 : ces processus métiers ont des exigences de RTO et RPO moins rigoureux. Il peut s'agir de la chaîne d'approvisionnement par exemple.
• Catégorie 3 : ces processus métiers peuvent être liés au développement interne et aux processus d'assurance qualité. Ces processus n'ont pas besoin des systèmes de  Haute Disponibilité utilisés dans les catégories 1 et 2.

Méthodologie pour définir les besoins en haute Disponibilité

Cette méthode est basée sur les 6 aspects suivants :

• Etude d'impact métier
• Coût d'arrêt du système
• RTO (Recovery Time Objective)
• RPO (Recovery Point Objective)
• Niveau de compétences nécessaire
• TCO (Total Cost of Ownership, coût total de possession) et ROI (Return on Investment ou retour sur investissement)

1. Etude d'impact métier

3. RTO (Recovery Time Objective)

L'analyse d'impact permettra de déterminer votre objectif de temps de récupération (RTO). Le RTO est la durée maximale d'indisponibilité que peut supporter un processus métier avant que l'entreprise ne commence à souffrir de conséquences inacceptables (pertes financières, l'insatisfaction des clients, la réputation, etc.). Le RTO indique la tolérance à l'indisponibilité d'un processus métier ou d'une organisation en général. Les exigences RTO sont liées à la nature des missions principales de l'entreprise. Ainsi, pour un système exécutant une application boursière, le RTO est nul ou très proche de zéro. Une entreprise peut avoir différents RTO en fonction de ses différents processus métiers. Ainsi, pour un site Web stratégique d'e-commerce, pour lequel les clients s'attendent à des temps de réponse rapide, le RTO est souvent proche de zéro. Par contre, le RTO des systèmes qui exécutent des opérations de back-office, comme l'expédition et la facturation, peut être plus élevé. Si ces systèmes de back-office sont moins disponibles, l'entreprise pourra probablement recourir à des opérations manuelles temporairement sans impact significatif visible. La capacité à prendre des commandes via le site Web d'e-Commerce est souvent associée à un RTO très faible. par contre, le RPO pourra être plus important et  les données perdues peuvent éventuellement être rechargées plus tard (si elles ont été stockées par ailleurs).

4. RPO (Recovery Point Objective)

L'analyse d'impact permettra également de déterminer votre objectif de point de récupération (RPO). RPO définit la quantité de données qu'un processus métier informatisé peut perdre sans nuire à l'organisation. RPO indique la tolérance de perte de données d'un processus métier ou d'une organisation en général. Cette perte de données est souvent mesurée en termes de temps, par exemple, 5 heures ou 2 jours de perte de données. Une application boursière où des millions de dollars de transactions se produisent chaque minute ne peut pas se permettre de perdre des données. Ainsi, son RPO doit être zéro. Le système basé sur le Web de vente dans l'exemple du commerce électronique n'a pas strictement besoin d'un RPO de zéro, même si un faible RPO est essentiel pour la satisfaction du client. Cependant, le Back Office et le système de mise à jour des stocks peut avoir un RPO plus élevée, étant donné que la perte de données peut souvent peuvent être ressaisie.

5. Niveau de compétences nécessaire

Le niveau de compétences nécessaire doit être pris en compte en plus du RTO et du RPO. Il s'agit d'évaluer de façon objective les compétences et la gestion des ressources disponibles dans une entreprise, et de définir si l'entreprise pourra gérer avec succès tous les éléments d'une architecture de haute disponibilité. Tout comme le RPO et le RTO définissent la tolérance d'une entreprise aux pertes de données et aux arrêts, de même il est nécessaire le seuil de complexité du système informatique à ne pas dépasser en fonction des ressources internes, à moins de faire appel à des consultants externes. S'il est nécessaire de limiter la complexité, il sera alors nécessaire de méthodes plus simples pour atteindre des objectifs de Haute Disponibilité acceptables, au prix de RTO et RPO plus élevés si nécessaire.

6. TCO (Total Cost of Ownership, coût total de possession) et ROI (Return on Investment ou retour sur investissement)

Il est essentiel de comprendre le coût total de possession (TCO) et le retour sur investissement (ROI) pour pouvoir sélectionner une architecture de Haute Disponibilité qui permet d'atteindre également les objectifs d'affaires de votre entreprise. Le TCO inclut tous les coûts supportés durant la duré de vie de la solution choisie (tels que l'acquisition, la mise en œuvre, les systèmes, les réseaux, les installations, le personnel, la formation et le support). De même, le calcul du ROI prend en compte tous les avantages financiers liés à une architecture de Haute Disponibilité. Par exemple, considérons une architecture de haute disponibilité dans lesquelles il existe un site distant de secours qui n'a aucune autre fonction : il reste en veille jusqu'à une éventuelle panne. Le retour sur investissement pour le site de secours est lié au coût d'immobilisation rapporté à son utilisation dans un scénario de basculement. Cette configuration contraste avec une architecture de Haute Disponibilité qui en plus de fournir une solution de basculement utilisable en cas de panne du site principale, est également utilisée de façon productive (par exemple, pour les lancer des rapports ou pour décharger le système principal de la surcharge de requêtes des utilisateurs finaux). Le retour sur investissement d'une telle architecture comprend à la fois le coût d'immobilisation évités et les bénéfices financiers associés à son utilisation productive autre que dans le rôle de base de veille.

Autres critères de choix

Une solution de Haute Disponibilité doit finalement répondre aux besoins de l'entreprise. Par exemple, une entreprise peut utiliser une solution zéro perte de données qui propage de manière synchrone chaque transaction effectuée sur la base de données principale vers une base de données distante. Toutefois, un délai supplémentaire peut s'ensuivre en fonction des limites physiques associées au réseau. Ces retards augmentent avec la distance et en fonction de la bande passante du réseau, de la congestion du trafic, des latences du routeur, etc... Par suite, si cette mise en miroir synchrone est effectuée sur de grands réseaux étendus (WAN), un ralentissement peut se produire sur le site primaire. Les clients peuvent remarquer ces latences du système et être frustré par de longs temps de réponse du système, et par voie de conséquence aller ailleurs pour effectuer leurs achats. C'est un exemple où l'entreprise doit réaliser un compromis entre avoir une solution zéro perte de données et maximiser les performances du système. Inversement, si les responsables de l'entreprise peuvent justifier des investissements pour éviter cette situation, une architecture multi-sites peut être mise en œuvre avec une réplication synchrones zéro perte de données sur un site de secours à proximité du site primaire et un deuxième site asynchrone située à des milliers de km et subissant quant à lui potentiellement quelques secondes d'attente. Les solutions de Haute Disponibilité doivent également être fondées sur des considérations financières et des estimations de croissance future. Il est tentant de construire des systèmes redondants dans toute l'infrastructure informatique et d'affirmer ensuite que l'infrastructure est totalement protégée. Il est essentiel de mettre en œuvre l'infrastructure procurant la plus grande haute Disponibilité possible tout en ne dépassant pas les budgets acceptable ou en ne mettant pas en œuvre des architectures trop complexes par rapport aux compétences disponible (à moins de faire appel à des consultants externes). Voici d'autres critères à prendre en compte : privilégier des solutions  sont bien intégrées, basées sur les standards, simples à mettre en œuvre, à maintenir et à gérer, et qui ont une architecture évolutive permettant de répondre à la croissance de l'activité future.