Services Cloud hébergés par Amazon Web Services , Azure , Google et la plupart des autres publient le S ervice L Evel A ccord , ou SLA, pour les services individuels qu'ils fournissent. Les architectes, les ingénieurs de plate-forme et les développeurs sont ensuite chargés de les assembler pour créer une architecture qui héberge une application.
Pris isolément, ces services fournissent généralement quelque chose dans la plage de trois à quatre neuf de disponibilité:
- Azure Traffic Manager: 99,99% ou «quatre neuf».
- SQL Azure: 99,99% ou «quatre neuf».
- Azure App Service: 99,95% ou «trois neuf cinq».
Cependant, lorsqu'ils sont combinés ensemble dans des architectures, il est possible qu'un composant quelconque subisse une panne entraînant une disponibilité globale qui n'est pas égale aux services des composants.
Disponibilité du composé série
Dans cet exemple, il existe trois modes de défaillance possibles:
- SQL Azure est en panne
- App Service est en panne
- Les deux sont en panne
La disponibilité globale de ce "système" doit donc être inférieure à 99,95%. Ma justification pour penser que c'est si le SLA pour les deux services était:
Le service sera disponible 23 heures sur 24
Ensuite:
- L'App Service pourrait être hors service entre 0100 et 0200
- La base de données entre 0500 et 0600
Les deux composants sont dans leur SLA mais le système total était indisponible pendant 2 heures sur 24.
Disponibilité en série et parallèle
Dans cette architecture, il existe cependant un grand nombre de modes de défaillance principalement:
- SQL Server dans RegionA est en panne
- SQL Server dans RegionB est en panne
- Le service d'application dans la région A est en panne
- Le service d'application dans la région B est en panne
- Traffic Manager est en panne
- Combinaisons de ci-dessus
Étant donné que Traffic Manager est un disjoncteur, il est capable de détecter une panne dans l'une ou l'autre région et d'acheminer le trafic vers la région de travail, mais il existe toujours un point de défaillance unique sous la forme de Traffic Manager, de sorte que la disponibilité totale du «système» ne peut pas être supérieur à 99,99%.
Comment la disponibilité composée des deux systèmes ci-dessus peut-elle être calculée et documentée pour l'entreprise, nécessitant potentiellement une réarchitecture si l'entreprise souhaite un niveau de service supérieur à celui que l'architecture est capable de fournir?
Si vous souhaitez annoter les diagrammes, je les ai intégrés dans Lucid Chart et créé un lien multi-usage, gardez à l'esprit que tout le monde peut le modifier afin que vous souhaitiez créer une copie des pages à annoter.
la source
Réponses:
Je prendrais cela comme un problème mathématique avec le SLA étant la probabilité d'être OK.
Dans ce cas, nous pouvons nous appuyer sur des règles de probabilité pour obtenir un total.
Pour votre premier cas, la probabilité que App Service (A) et Sql Service (B) tombent en même temps est le produit de leur probabilité:
La probabilité que l'un d'entre eux soit en panne est la somme de leur probabilité:
Lorsque deux événements sont indépendants, la formule résultante pour prendre en compte la probabilité que les deux soient en baisse est:
Donc, le SLA global serait
1 - 0,00099975 = 0,99900025dont le pourcentage est99.900025 %Une simplification est le produit de la première probabilité:
0.9995 * 0.9995 = 0,99900025.Appliqué à votre coupure 1h / 24h (4,166666% d'une journée) cela donne (les décimales sont abrégées):
La probabilité d'être OK est donc
1 - 0.0816 = 0.9184en pourcentage:91,84%C'est moins que le pire des cas de 2 heures car il y a une chance que les deux soient en panne en même temps.
En gardant cela à l'esprit, vous remarquerez peut-être la disponibilité de chacun est
95,84%et0,958333333 * 0,958333333 = 0,918402778qui est notre91.84%ci-dessus (désolé pour les décimales complètes ici, mais elles sont nécessaires pour la démonstration)Maintenant, pour votre deuxième cas, nous allons commencer à gagner de notre probabilité composée pour chaque région (Désolé, j'ai rejeté la modification pour SQL pour la garder raisonnable), en supposant qu'il n'y a pas de probabilité indépendante pour la région elle-même et que chaque région est isolée et en tant que telle une panne de base de données ne supprime que sa région.
Nous avons la probabilité OK du gestionnaire de trafic
P(T) = 0.9999et chaque couple app + DB avec une probabilité OKP(G) = 0,99900025deLa quantité de région que nous avons joue car nous devons appliquer le produit de la probabilité de défaillance uniquement pour obtenir la probabilité que les deux régions soient en baisse en même temps:
0,00099975 * 0,00099975 = 0,0000009995000625ce qui signifie une disponibilité globale d'au moins une région de99,049375 %Maintenant, nous avons la disponibilité globale des régions, le produit avec le gestionnaire de trafic nous donne la disponibilité globale du système:
La disponibilité globale est
99.989900 %Une autre source comme explication est disponible sur les documents Azure (lien gracieuseté de Raj Rao )
la source
Après avoir lu l'excellente réponse de Tensibai , j'ai réalisé que j'avais l'habitude de pouvoir calculer cela à des fins d'analyse de réseau. J'ai déterré ma copie des principes fondamentaux du réseau de haute disponibilité de Chris Oggerino et j'ai eu du mal à résoudre ce problème, pas tout à fait les premiers directeurs.
Prendre mon exemple en série directement dans la réponse de Tensibai consiste simplement à multiplier la probabilité que chaque composant soit disponible par l'autre:
Alors
Le calculer en parallèle est un peu plus compliqué car nous devons considérer quel sera le pourcentage de non disponibilité:
Le calcul se fait comme suit:
Multipliez ensemble la non disponibilité des deux régions.
Reconvertissez cela en disponibilité
Multipliez la disponibilité de Traffic Manager par la disponibilité des deux régions.
Le résultat est la disponibilité complète du système.
J'ai fini par utiliser Excel pour effectuer les calculs, voici les valeurs:
... et les formules ...
la source