Comment calculez-vous le SLA (Service Level Agreement) composé pour les services cloud?

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.

— Richard Slater
source

SLA le plus bas de SPOF, en supposant que votre application est capable de faire face à la rupture de session?

— Tensibai

@Tensibai - Je ne pense pas que cela puisse être le cas, sur la base de mon premier exemple, si le SLA pour les deux services était disponible 23 heures sur 24, l'App Service pourrait être hors service entre 0100 et 0200 et la base de données entre 0500 et 0600, les deux composants sont dans leur SLA mais le système total n'était pas disponible pendant 2 heures sur 24. Est-ce logique?

— Richard Slater

Oui, c'est logique, mais dans ce cas, le résultat devrait être le produit de tous non?

— Tensibai

Je veux dire que l'application 99,95 x 99,95 sql devrait être la disponibilité globale du groupe

— Tensibai

Gardez également à l'esprit que vous pouvez créer un système plus fiable que ses composants, via des tentatives ou des basculements ou une dégradation au lieu d'une panne complète.

— Xiong Chiamiov

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é:

P(A)*P(B) = 0.0005 * 0.0005 = 0,00000025

La probabilité que l'un d'entre eux soit en panne est la somme de leur probabilité:

P(A)+P(B) = 0.001

Lorsque deux événements sont indépendants, la formule résultante pour prendre en compte la probabilité que les deux soient en baisse est:

P(A,B) = P(A) + P(B) - P(A)*P(B) = 0.001 - 0,00000025 = 0,00099975

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):

0.0416 + 0.0416 - (0.0416 * 0.0416) = 0,081597222

La probabilité d'être OK est donc 1 - 0.0816 = 0.9184en pourcentage:91,84%

24 * 0.0816 = 1.95 h

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%et 0,958333333 * 0,958333333 = 0,918402778qui est notre 91.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é OK P(G) = 0,99900025de

La 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:

0.9999 * 0,9999990004999375 = 0,99989900059988750625

La disponibilité globale est 99.989900 %

Une autre source comme explication est disponible sur les documents Azure (lien gracieuseté de Raj Rao )

— Tensibai
source

La disponibilité globale semble très faible - en fait, en ajoutant une région supplémentaire et un gestionnaire de trafic, le SLA est un ordre de grandeur inférieur à celui s'il ne s'agissait que d'une seule région. J'essaie de creuser comment je faisais cela pour les réseaux à l'arrière de mon cerveau.

— Richard Slater

Phew! J'étais sûr que je devenais fou.

— Richard Slater

@RichardSlater maths corrigé

— Tensibai

@BruceBecker probablement oui, car il semble certainement que l'IEEE a publié des recherches sur le sujet, je soupçonne cependant, étant donné le but du calcul de ces chiffres, il s'agit davantage d'avoir une "preuve" concrète que vous avez besoin ou non de capacités de haute disponibilité ajouté à un système - c'est-à-dire que nous utilisons ces chiffres pour conduire des décisions de rentabilité basées sur l'appétit pour le risque des entreprises. Construire un modèle bayésien peut ne pas représenter la meilleure utilisation de notre temps.

— Richard Slater

@BruceBecker Oui, une partie du problème est liée (le même centre de données tombe en panne et les deux services sont à l'intérieur, ce qui doit être faible), pour le reste, je pense que nous pouvons supposer en toute sécurité que les services d'application et les services SQL s'exécutent sur différents systèmes et sont peu susceptibles de échouer en même temps pour la même raison . Aller plus loin dans les mathématiques nécessiterait une documentation précise sur la façon dont l'architecture Azure est effectuée et ne peut donc être répondu que par quelqu'un de Microsoft.

— Tensibai

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

99,95% * 99,95% = 99,9%

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.

0,1% * 0,1% = 0,0001%
Reconvertissez cela en disponibilité

100% - 0,0001% = 99,9999%
Multipliez la disponibilité de Traffic Manager par la disponibilité des deux régions.

99,99% * 99,9999% = 99,9899%
Le résultat est la disponibilité complète du système.

99,9899% est proche de 99,99%

J'ai fini par utiliser Excel pour effectuer les calculs, voici les valeurs:

... et les formules ...

— Richard Slater
source

Voilà, d'une manière plus simple que la mienne (j'ai ressenti le besoin de démontrer les maths derrière :))

— Tensibai

D'accord, votre réponse est vraiment bonne pour les mathématiques.

— Richard Slater

SQL Azure est à 99,99% et non à 99,95%

— Jeffery Tang

@JefferyTang c'était (probablement) au moment de l'écriture de la question / réponse (je ne me souviens pas exactement) et la valeur réelle ne change pas la méthodologie pour obtenir la réponse à "Comment calculer le SLA composé à partir de SLA de pièces individuelles" qui est la vraie question.

— Tensibai