3.3 Méthode de calcul de disponibilité
Les travaux de Tsai et Sang [23] décrivent une méthode d’analyse de solutions, basée sur les risques d'indisponibilité des systèmes qui la composent. Les systèmes sont alors interconnectés de l’une de deux façons : en série ou en parallèle. Les systèmes sont pondérés selon leur risque d’indisponibilité, permettant ainsi d’en évaluer la disponibilité, tel que décrit dans la section 1.3.2. Cette évaluation permet alors d’évaluer la disponibilité pour la solution.
La disponibilité d’une solution est le résultat du calcul de disponibilité des systèmes sériels et parallèles la constituant, ou du calcul de disponibilité du seul composant la constituant, le cas échéant. Ce calcul découle de l’implémentation de la couche logique par la couche physique des systèmes eux-mêmes.
Le présent essai ne quantifie pas la disponibilité des composants logiques de la solution. La disponibilité interne des composants logiques est connue d’avance, lors de la conception de la solution, et une disponibilité de est alors utilisée dans cette analyse. Le cadre actuel met en relief les manières d’augmenter la disponibilité en ne modifiant que l’architecture de la solution (le nombre de composants logiques, le nombre de composants virtuels, ainsi que leurs dépendances et leurs liens de communication), sans en modifier la conception (l’implémentation interne des composants logiques).
La disponibilité des composants virtuels dont un composant logique dépend a une incidence directe sur le système composé d’un composant logique et des composants virtuels dont il dépend. Étant donné que la disponibilité des composants virtuels est pratiquement toujours inférieure à , tel que discuté dans la section 1.3.2, et que le composant logique lui-même est supposé totalement disponible, la disponibilité des composants virtuels ne peut que diminuer la disponibilité totale du système.
3.3.1 Traduction terminologique
La terminologie utilisée dans la méthode d’analyse de Tsai et Sang [5] est légèrement différente de celle utilisée dans cet essai. Le contexte de la présente analyse doit non seulement tenir compte de la disponibilité des composants logiques, mais aussi de la disponibilité des composants virtuels dont chaque composant logique dépend. Les composants logiques, et les composants virtuels sont considérés comme des équivalents aux systèmes et aux sous-systèmes de la méthode Tsai et Sang [5].
Les systèmes sont des entités entièrement dépendantes de sous-systèmes, et ces sous-systèmes peuvent être en série ou en parallèle. Dans le même sens, une solution est composée de composants logiques qui dépendent eux-mêmes de composants virtuels qui peuvent être dupliqués ou non.
De ce fait, un composant logique et les composants virtuels dont il dépend constituent une combinaison de systèmes permettant d’établir la disponibilité de ce composant. La Figure 3.2 illustre les dépendances entre des composants logiques et virtuels, et les dépendances d’un modèle basé sur des systèmes.

Figure 3.2 — Couche de virtualisation et systèmes
Après avoir identifié les composants logiques et les composants virtuels, on peut alors les composer en série ou en parallèle comme les systèmes de Tsai et Sang.
3.3.2 Calcul de disponibilité d’un composant virtuel
Les composants virtuels dont dépend un composant logique ont une implémentation dans la vue physique de l’architecture. Afin de calculer la disponibilité de l’un de ces composants virtuels, il faut connaitre la disponibilité de l’implémentation physique. Les fournisseurs de composants physiques ont habituellement des statistiques permettant l’extrapolation de la disponibilité.
Le temps moyen de recouvrement est le temps nécessaire à la remise en route d’une solution suite à la panne d’un périphérique. Ce temps moyen de recouvrement (Mean Time to Recover, MTTR) combiné au temps moyen entre les pannes (Mean Time Between Failure, MTBF) donne la disponibilité réelle d’un du composant logiciel. La disponibilité d’un composant est donc calculée comme suit :

Par exemple, basé sur un échantillon d’une année :
Les disques durs Velociraptor de Western Digital ont une disponibilité de 99,99942% basé sur un temps de recouvrement de huit heures. [25]
Les cartes maitresses Intel S500PSL ont une disponibilité de 99,95081% basé sur un temps moyen de recouvrement de 48 heures. [11]
Les contrôleurs Rocket Raid de Highpoint ont une disponibilité de 99,99739% basé sur un temps moyen de recouvrement de 24 heures. [9]
3.3.3 Pondération des composants logiques et virtuels
Toujours selon Tsai et Sang [5], une solution dont la disponibilité des systèmes est pondérée peut avoir une certaine disponibilité, tout en n’adressant pas la façon dont la disponibilité des systèmes peut-être évaluée. Contrairement aux dépendances d’un composant, le cadre de la présent essai fait abstraction de la disponibilité du composant comme tel et présume que celui-ci est toujours disponible.
Les composants virtuels ont une disponibilité que l’on ne connaît pas dans la couche de virtualisation. On ne peut pas prédire leur disponibilité puisqu’on ne connaît pas l’environnement dans lequel chaque composant sera déployé. Le but de cette essai étant de mettre en avant plan les composants les plus à risque, la disponibilité inconnue d’un composant virtuel a un impact majeur sur l’analyse de disponibilité totale de la solution. Une disponibilité pessimiste doit être utilisée.
Cette disponibilité est déterminée en ayant à titre d’hypothèse pessimiste qu’une panne par mois, sur une période d’un an. Le MTBF est alors de 12 pannes par période de 365,25 jours, ce qui donne un MTBF de 731 heures. Une deuxième hypothèse est émise selon laquelle 48 heures seront nécessaires afin de remédier à ces pannes. Basée sur le calcul de disponibilité, la disponibilité pessimiste qui sera utilisée sera de 0,9384%.

Puisque les composants virtuels ont des dépendances entrantes provenant directement d’un composant logique, la disponibilité d’un tel composant peut alors être précalculée à partir des composants virtuels dont il dépend, permettant ainsi la simplification du plus bas niveau d’abstraction de la vue de virtualisation.
3.3.4 Hypothèse de disponibilité
Malgré qu’à ce stade, la disponibilité des composants virtuels est inconnue, certaines hypothèses peuvent être formulées afin que la disponibilité générique soit plus représentative de l’environnement ciblé. Le développement logiciel se fait habituellement en ciblant un environnement physique typique pourvu de contraintes permettant de formuler des hypothèses.
Un logiciel pourrait cibler une plateforme spécifique afin d’utiliser une API simplifiant le développement de la solution logicielle. Cette API peut n’être déployée que pour certains jeux d’instructions, par exemple un jeu d’instructions Intel x86, réduisant ainsi les possibilités de déploiement de ce logiciel. Les composants virtuels de traitement peuvent aussi reposer sur des composants physiques ayant des restrictions, par exemple un jeu d’instructions spécifique. Dans ce cas, on peut ajouter une hypothèse à l’essai, et supposer, par exemple, que tous les composants virtuels de traitement ont une disponibilité reflétant l’implémentation de ces composants virtuels, utilisant par exemple une disponibilité de , en remplacement de l’hypothèse de .
Dans le but de simplifier les calculs, l’explication de la méthodologie de ce chapitre se fait sur la base d’une disponibilité pessimiste de , tout en sachant que cette disponibilité n’est pas réaliste et ne devrait pas être utilisée dans le cadre d’une analyse.
3.3.5 Connexions séries ou parallèles
La disponibilité des systèmes reliés en série peut être calculée en multipliant la disponibilité des sous-systèmes qui les relient. Par exemple, pour une solution comprenant deux composants , , la solution aurait une disponibilité de . En utilisant la disponibilité fixe de la section précédente, aurait une disponibilité de , soit .

Figure 3.3 — Connexions sérielles
Lorsqu’il y a un duplicata de système, tous les duplicatas sont reliés au reste de la solution, en parallèle. La disponibilité du composant peut alors être calculée en appliquant la fonction :

Alors un composant , comprenant deux dépendances en parallèle et , le composant aurait une disponibilité de :

Figure 3.4 — Connexions parallèles
Le calcul de disponibilité de la figure 3.4 va comme suit :

3.3.6 Systèmes complexes
Le cadre de l’analyse découpe une solution en systèmes parallèles et sériels. Par contre, une solution pourrait être plus complexe et utiliser une combinaison de systèmes parallèles et sériels. Dans le cas de ces solutions complexes, la solution doit être divisée en isolant des systèmes simples, afin de pouvoir utiliser la méthode d’analyse se basant sur des systèmes parallèles et sériels uniquement. Par exemple :

Figure 3.5 — Système complexe, série et parallèle
La disponibilité doit être calculée en isolant les sous-systèmes et , les sous-systèmes et , puis en calculant la disponibilité du composant avec le résultat des deux derniers calculs par un calcul de système sériel.
La complexité d’un système fait de la séquence des composants est


où est soit une constante (composant tel quel), soit un produit de la disponibilité (séquence de composants), soit le fruit du calcul de la disponibilité des duplicatas.
Table des matières · 18/26
Conception pour la haute disponibilité
- Conception pour la haute disponibilité
- Introduction
- 1 Abstraction du matériel
- 1.1 Isolation des niveaux d’abstraction
- 1.2 Catégorie de composants physiques
- 1.3 Couche de virtualisation
- 1.4 Abstraction des composants virtuels
- 1.5 Caractéristiques des composants virtuels
- 2 Les mécanismes sous-jacents à la haute disponibilité
- 2.1 Cadre d'analyse des mécanismes et hypothèses
- 2.2 Interface publique d’une solution
- 2.3 Contrôle du risque
- 2.4 Une approche : la duplication
- 2.5 Limites de la réplication de composant virtuel d’immuabilité
- 3 Évaluation des risques d’indisponibilité
- 3.1 Hiérarchie de dépendances
- 3.2 Goulots d’étranglement
- 3.3 Méthode de calcul de disponibilité
- 3.4 Méthodologie d’analyse
- 4 Évaluation dans des cas réels
- 4.1 Solution logicielle de base
- 4.2 Analyse sans hypothèses
- 4.3 Évaluation avec ajout d’hypothèses de disponibilité
- 4.4 Hypothèse dans un scénario infonuagique
- Conclusion
- Liste des références