Si vous travaillez dans l’infra ou sous Azure vous avez forcément entendu parler de SLA (Service Level Agreement) ou entente de niveau de service.
Il s’agit d’une valeur qui définit la qualité d’un service en termes de disponibilité, c’est-à-dire que le service est disponible et peut répondre aux requêtes.
En général plus un SLA est élevé, plus le service vous sera facturé cher.
Dans cet article je vais rester dans un contexte Azure, mais je suis à peu près certain qu’il n’y aura rien de spécifique à Azure.
Je compte aborder 3 questions:
- Calcule d’un SLA simple
- Calcul d’un SLA composé
- La durabilité
Une dernière chose, dès que vous trouvez un lien vers un site Microsoft dans cet article, cela m’arrangerait que vous cliquiez dessus, merci d’avance!
Le SLA
Sous Azure le SLA d’un service est typiquement de l’ordre de 99.99 (on prononce quatre-neuf). Il est parfois un peu plus élevé.
Le SLA est donné sous la forme d’un pourcentage. Il s’interprète en disant que Microsoft s’engage à une disponibilité du service de 99.99% du temps. Pour garantir un tel niveau, en technologie on applique une règle empirique simple:
Si on veut du 4 9, alors on vise du 5 9.
Microsoft propose un site où on trouve le SLA de chaque service:
https://azure.microsoft.com/fr-fr/support/legal/sla/
Si je sélectionne une machine virtuelle, j’arrive à cette page:
On doit distinguer 3 cas, le SLA varie de 99.9% vers 99.99% selon la situation. On voit par exemple qu’avec un compte de stockage Premium, une VM, même avec une seule instance, peut avoir un SLA.
Les onglets qui suivent dépendent du service, mais pour l’essentiel ils précisent ce que Microsoft entend par SLA pour ce service ainsi que les conditions d’indemnisations (ne comptez pas trop être indemnisé au préjudice réel!).
Je vous suggère de les lire, on y trouve beaucoup d’informations intéressantes.
Un SLA de 99.5% cela correspond à quoi?
On trouve facilement des calculatrices sur Internet:
https://dastergon.gr/availability-calculator/
Par exemple la première fournit les statistiques suivantes:
On y apprend que sur 1 an on peut s’attendre à 4.38 heures d’indisponibilité.
Mais attention ce n’est pas si simple. Le calcul suppose un fonctionnement en continu H24 et 7/7. On a concrètement calculé:
T = 365*24 – 0.9995 * 365 * 24 = 8760 – 8755.62 = 4.38 heures
On retrouve évidemment le même résultat.
Mais si le serveur fonctionnait 20 heures par jour sauf le dimanche par exemple:
Puisque l’on a 52 semaines et 1 jour d’arrêt, alors sur une année on a (365-52)*20 heures « ouvrées », soit 6260 h.
On applique la méthode précédente et l’indisponibilité est:
T = 6260 * (1-0.9995) = 3.13 heures
Soit déjà moins.
Il faut donc faire très attention à la façon dont le SLA et le temps d’indisponibilité sont calculés.
SLA composé
Votre application est composée d’un certain nombre de services composés les unes avec les autres. Chaque service a son SLA, mais quel est le SLA total?
Supposons cette architecture:
Une Web App qui attaque une base de données pour assurer son service. La Web App (on l’appellera A) à un SLA de 99.95% et la base (on l’appellera B) de 99.99% quel est le SLA de l’ensemble?
On interprète le SLA en termes de probabilité:
SLA = Probabilité que le service fonctionne.
Dans ce montage en série, il est évident que pour que l’ensemble fonctionne, il est nécessaire que A ET B fonctionnent. On doit donc calculer la probabilité de l’événement P(A ET B).
En principe on a fait cela au lycée et:
P(A et B) = P(A).P(B)
Et donc:
P(A ET B) = 0.995 * 0.9999 = 99.94%
Il est un peu plus faible. C’est normal, car les services peuvent certes tomber l’un et pas l’autre, mais aussi l’un ET l’autre ce qui augmente le quota d’indisponibilité.
Soyez attentif à un aspect de ce calcul. La formule utilisée suppose que les deux SLA soient indépendants. Ce n’est pas forcément vrai. Par exemple le data center peut subir une inondation et l’ensemble du site devient indisponible.
N’attendez donc pas une trop forte précision dans ce genre de calcul. Le SLA exact se mesure plus qu’il ne se calcule. Mais on a déjà une bonne idée des choses.
Analysons un cas plus complexe:
Nous avons 3 services:
- A: une base de données avec un SLA de 99.99%
- B: une queue avec un SLA de 99.99%
- C: une Web App avec un SLA de 99.95%
Quel est le SLA de l’ensemble?
On va pour cela calculer le SLA de l’ensemble A/B, puis celui de l’ensemble total.
La grosse différence avec le cas qui précède est que l’application fonctionne, même si A OU B tombe. On doit donc calculer P(A OU B).
La probabilité que le bloc soit indisponible (Up) est:
P(Down) = P(A(Down) ET B(Down)) = P(A Down).P(B Down)
Vous devinez sans peine les notations.
Par conséquent la probabilité que l’ensemble soit Up est:
P(Up) = P(A OU B) = 1-P(A Down).P(B Down)
Et par définition:
P(A OU B) = SLA(ensemble du bloc)
En appliquant ce raisonnement:
P(A Down) = 1- P(A Up) = 1 – SLA(A) = 0.0001
P(B Down) = 1 – P(B Up) = 1- SLA(B) = 0.0001
Et donc:
P(A OU B) = 1 – 0.0001*0.0001 = 99.999999%
Le reste du calcul s’effectue en appliquant le raisonnement du premier cas ou les services sont en série et le SLA recherché est:
SLA = 99.999999 * 99.99 = 99.99%
Note: au passage on constate que la mise en place de redondance augmente considérablement le SLA.
Le SLA du bloc redondant est tellement bon, que le SLA de l’ensemble est quasiment celui du maillon le plus faible, la Web App.
Vous trouverez en bibliographie d’autres exemples de calculs un peu plus sophistiqués, mais vous avez là l’essentiel.
Durabilité
La durabilité est souvent associée au SLA dans les fiches techniques. C’est quoi la différence?
Le SLA nous informe sur la qualité du matériel. Il est très sensible à la redondance du matériel.
La durabilité est une statistique qui nous informe sur le risque de perte ou de corruption de données. Il est sensible à la redondance des données.
Une autre façon de les distinguer est de regarder leurs valeurs.
En SLA on a en général des choses comme 4 9, en durabilité c’est plutôt du 11 9 voire bien plus!
Faisons un petit calcul pour bien comprendre ce que cela signifie.
Supposons que notre système de stockage présente une durabilité en 11 9. Cela signifie qu’en moyenne je risque de perdre 
fichiers. Une durabilité est aussi un pourcentage, donc:
Si je sauvegarde 10 000 fichiers par an je vais donc en perdre en moyenne 
sur l’année.
Je peux donc m’attendre à en perdre 1 tous les 
ans.
Comme on le voit, à moins d’avoir de gros besoins en stockage, la durabilité est rarement un problème pratique.
Nouvelles Chroniques d'Amethyste 
Bonjour
Merci pour ‘explication.
Pour vos liens Microsoft vous devriez faire en sorte qu’ils s’ouvrent dans un nouvel onglet (pour faciliter la lecture et avoir plus de monde qui les ouvrent ^^)
Ah j’ai du les oublier, en général j’y fais attention.
Merci quand même