1.3 Couche de virtualisation
Afin d’isoler les couches d’abstraction de l’architecture, en évitant la modification des couches d’abstractions actuelles, une nouvelle couche s’interpose entre la couche logique et la couche physique : la couche de virtualisation, qui est une couche implémentant la vue logique en utilisant des composants virtuels, tel qu’illustré dans la Figure 1.6. La vue de virtualisation permet de faire abstraction des composants physiques, tout en ayant un niveau de granularité suffisant pour mettre en évidence les caractéristiques des composants physiques utilisées lors de l’implémentation des composants logiques.
Une solution répartie intègre dans la solution logicielle des liens servant à la communication entre deux composants logiques. Seuls ces liens de communication permettent à un composant de consommer les services d’un autre composant. Puisque la consommation est dans une seule direction, et qu’un lien représente cette consommation logique d’un service, un tel lien est unidirectionnel. La caractéristique unidirectionnelle d’un lien n’empêche pas la communication bidirectionnelle entre deux composants. Cela est possible en établissant deux liens unidirectionnels représentant la consommation mutuelle des services, comme le montre la section 1.4.
La couche de virtualisation est faite de composants logiques offrant des services. Ces composants logiques dépendent de composants virtuels. Les dépendances entre composants logiques sont connues grâce aux liens de communication unidirectionnels liant les composants virtuels servant à la communication entre les composants logiques.
Puisque les dépendances sont unidirectionnelles, du point de vue d’un composant spécifique, une dépendance peut être entrante ou sortante. Par exemple, lorsqu’un composant dépend d’un composant , a une dépendance sortante et à une dépendance entrante.

Figure 1.6 — Vue de virtualisation
1.3.1 Un paradigme différent
Une solution logicielle répartie introduit un paradigme différent de celui d’une solution monolithique. Plusieurs composants logiques composent la solution, ces composants sont reliés par des liens de communication.
Un composant logique relié à un autre composant logique par l’intermédiaire d’un lien provoque un graphe unidirectionnel acyclique de composants (Directed Acyclic Graph, DAG). Un composant logique parent dépend donc de composants logiques enfants. Par contre, un composant logique peut avoir plus d’une dépendance entrante, ce qui change la structure pour en faire un graphe unidirectionnel.

Figure 1.7 — Graphe de composants logiques
La figure 1.7 donne un exemple où l’augmentation du nombre de composants logiques dans une solution entraîne une augmentation du nombre de liens de communication. Puisque ces liens de communication lient des composants virtuels, l’ajout de liens de communication peut multiplier le nombre de composants virtuels, entrainant ainsi un accroissement des risques d’inaccessibilité. Le nombre de composants logiques peut être arbitrairement élevé (par exemple : des dizaines, des centaines), et un composant logique peut être relié à plusieurs autres. La notion de dépendance prend tout son sens : un graphe de dépendances a un effet multiplicateur sur le risque d’inaccessibilité d’une solution logicielle. Le dernier chapitre en évalue l’effet dans un cas réel.
Les dépendances d’un composant logique sont donc la totalité des composants logiques et des composants virtuels dont un composant logique a besoin pour offrir la totalité des services pour lesquels il a été conçu. Un composant logique ne peut pas communiquer avec un autre composant logique sans la médiation de composants virtuels de transition.

Figure 1.8 — Graphe de dépendances entre composants logiques et virtuels
1.3.2 Disponibilité d’une solution
Dans l’analyse actuelle, la disponibilité se mesure dans un intervalle ; si est l’indisponibilité, la disponibilité se calcule alors .
Une solution n’est disponible que lorsque tous les services fournis par les composants logiques de cette solution offrent le service pour lequel ils ont été conçus. La disponibilité de la solution est si la solution est disponible en tout temps, du démarrage de la solution jusqu’à son arrêt volontaire.
Puisqu’une solution représente un graphe de dépendances entre des composants logiques, la disponibilité de tous les composants logiques et virtuels impacte la disponibilité de la solution. Si, par exemple, un composant logique dépend d’un autre composant logique , la disponibilité de se calcule non seulement en tenant compte de la disponibilité de , mais aussi par la disponibilité des composants virtuels permettant la communication de vers . Aussi, le lien entre le composant logique et le composant virtuel fait partie intégrante du composant virtuel, et ce lien a un impact sur la disponibilité de ce composant.
Étant donné que la solution répartie repose nécessairement sur des composants logiques ayant des dépendances, cette disponibilité peut tendre vers , sans pour autant l’atteindre, à moins que chacune des dépendances de chacun des composants n’offre aussi une disponibilité de .
1.3.3 Criticité d’un composant logique
L’amélioration de la disponibilité d’une solution logicielle peut se faire de plusieurs façons. L’une d’elles cible les composants logiques les plus critiques et en améliore la disponibilité, ceci permet d’avoir une solution partiellement fonctionnelle, mais disponible pour les services les plus critiques de la solution logicielle. Quantifier la criticité du service offert par un composant logique permet de faire cela.
L’objectif du présent essai est d’améliorer la disponibilité d’une solution logicielle, il faut que tous les composants de la solution soient disponibles, peu importe l’importance de leurs services pour la solution. Considérant l’équation :

avec la disponibilité du composant , il est clair que si est indisponible, donc si , alors .
La criticité d’un composant logique est donc superflue dans le cadre de la présente analyse. L’information échangée ne sert alors qu’au traitement interne d’un composant de la solution. C’est pourquoi les composants logiques d’une solution peuvent être considérés comme des boîtes noires.
1.3.4 Caractéristiques spécifiques à la vue de virtualisation
Les composants virtuels sont reliés aux composants logiques. Tel que mentionné à la section 1.3.2, la disponibilité de ces liens fait partie intégrante du composant virtuel. Par contre, lorsqu’un composant logique doit consommer le service d’un autre composant logique, un lien de communication doit être établi. C’est alors que des composants virtuels s’ajoutent à la couche de virtualisation, et qu’un lien de communication doit être ajouté entre chaque paire de composants connectés l’un à l’autre des deux composants virtuels pour permettre cette communication.
Lors de l'analyse des différentes interactions d'une solution logicielle répartie ainsi que de leurs dépendances, tous les composants logiques doivent être reliés, soit par un lien direct (à travers des composants virtuels ayant un lien de communication), soit à travers un ou plusieurs autres composants logiques de la solution interposés (toujours avec de composants virtuels ayant un lien de communication entre chacun des composants logique). Si aucun lien ne relie un composant ou un ensemble de composants avec le reste de la solution logicielle, c’est qu’ils n’ont rien en commun, ou qu’ils n’ont en commun que des composants virtuels, sans lien de communication entre les deux ensembles de composants. Dans chaque cas, ces deux ensembles de composants sont deux solutions logicielles indépendantes l’une de l’autre.
D’autres solutions logicielles peuvent être accédées via une solution donnée. Ces solutions sont des solutions logicielles externes. Elles exposent des interfaces permettant l’accès aux services qu’elles offrent et sont dépendantes d’une couche logicielle externe. Chacune de ces solutions peut donc être analysée en tant que composant logique à part entière.
Le composant logique offre des services ne pouvant pas être abstraits lors de la conception de la solution. Les composants virtuels, peuvent être abstraits, apportant ainsi une flexibilité lors de l’implémentation de la solution.
Table des matières · 6/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