(Voor een handig SLA board zie: https://azurecharts.com/sla)
SLA Levels
Tijdens het schrijven van dit artikel is er slechts 1 Azure Service met een SLA van 100%. Azure DNS, één van de core componenten voor services zoals Azure AD. Microsoft garandeert dat ‘geldige DNS-aanvragen 100% van de tijd een reactie zullen ontvangen van ten minste één Azure DNS-naamserver’. Microsoft weet dit te bereiken door vier DNS servers in verschillende geo’s aan te bieden, met alle een andere top level domain: .com, .net, org en ns{x}-{xx}.azure-dns.net. Om gebruik te maken van de 100% SLA garantie moet je derhalve wel alle vier de DNS servers in je app of dienst instellen.
Percentages die van belang zijn
SLA uptime percentages zijn vaak hoge nummers. 99,5% klinkt als een hoog beschikbaar systeem en 99,999% (de magische 5 negens) lijkt daarom wellicht wat buitensporig. Maar als je vervolgens kijkt naar de maximale downtime veranderd dat. Slechts een zeer beperkt aantal klanten of gebruikers zullen nl. accepteren dat een app het soms even niet doet. Naar mijn bescheiden mening is het daarom niet verstandig om een productieomgeving te ontwerpen of gebruiken die minder dan 99,95% of 99,99% beschikbaarheid biedt.
Uptime percentage en maximale downtime:
99,5% = 7 minuten 12 seconden per dag
99,9% = 1 minuten 26 seconden per dag
99,95% = 43 seconden downtime per dag
99,99% = 8 seconden downtime per dag
99,999% = 0,8 seconden downtime per dag (6 seconden per week)
Bron
Samengestelde SLA in Azure
Wanneer je app gebruik maakt van meerdere (Azure) services, zal je de SLA elk van die services moeten controleren. Een voorbeeld, wat denk je dat de verwachte maximale downtime is van onderstaande app?
In dit voorbeeld zal de volledige app down gaan bij een storing op of de Web App of de SQL Database. De kans op het falen van elke service is onafhankelijk, dus de samengestelde SLA voor deze toepassing is:
- 95% (Web App) × 99.99% (Database) = 99.94%
Dat is lager dan de SLA van de individuele services
Door een onafhankelijke fallback optie toe te voegen kan je de beschikbaarheid aanzienlijk verbeteren. Wederom een voorbeeld, wat denk je dat er gebeurd als we een Queue Storage service toevoegen die is voorzien van een relatief lage 99,9% SLA in onderstaand voorbeeld:
In dit geval zal de Web App beschikbaar blijven, ook als deze niet kan verbinden met de SQL Database. De app zal pas falen als zowel de SQL Database als de Queue Storage down gaan, op dezelfde tijd. De verwachte kan op een dergelijke simultane storing is.0001 × 0.001, daarmee is de SLA van deze gecombineerde dienst:
- SQL Database of Queue Storage = 1.0 − (0.0001 × 0.001) = 99.99999%
De samengestelde SLA is daarmee:
- Web app en (database of queue) = 99.95% × 99.99999% = ~99.95%
U kunt dit voorbeeld en een berekening voor een multi-regio oplossing vinden in het Azure Architecture Center. U vindt daar ook een voorbeeld van een extreme hoog beschikbare oplossing die gebruik maakt van vier Azure regio’s met een 99,999999% SLA.
SLA Beperkingen
Zoals wellicht te verwachten valt, heeft Microsoft de nodige limieten en beperkingen gezet op wat de SLA daadwerkelijk dekt. In principe wordt alles buiten de controle van Microsoft zoals natuurrampen, oorlog, terrorisme, rellen of overheidsacties uitgesloten van de SLA. Ook worden netwerk en device problemen die buiten de Azure data centers optreden niet gedekt door de SLA. Dit betreft ook zaken in uw eigen omgeving (of klant omgeving) en het Azure data center.
Service Credits
De meeste SLAs bieden een diensttegoed of service credit. Dit betreft een percentage van de Toepasselijke Maandelijkse Servicekosten (Applicable Monthly Service Fees), die gecrediteerd kunnen worden na goedkeuring van Microsoft. Een aantal Azure services zoals Virtual Machines bieden tot 100% service credits wanneer de maandelijkse uptime onder de 95% komt en 25% wanneer de update onder de 99,99% komt. Maar andere Azure services zoals Azure Functions bieden slechts een maximale service credit van 25%, wanneer de maandelijkse uptime onder de 99% komt.
De Azure SLA dekt alleen uw Azure consumptie en dekt derhalve geen nevenschade die wellicht optreed bij uitval van uw app of dienst. Het is daarom geen alternatief voor een robuust en hoog beschikbaar Azure design.
Om een service credit aan te vragen dient er een claim te worden ingediend middels een support ticket met daarin alle relevante informatie, voor het einde van de volgende maand. Aan het ticket moet ook het zogenaamde Outage incident identifier van de Service Health pagina worden toegevoegd. Uw Cloud Solution Provider (CSP) partner kan helpen bij dit proces.
Verhoog je beschikbaarheid
De Azure SLA is een uitstekend vertrekpunt voor het maken van het een Azure design. Door naar de verschillende requirements voor een bepaalde Azure Service te kijken krijg je inzicht in de manier waarop een dienst is ontworpen en de manier waarop deze gebruikt dient te worden volgens Microsoft. Bijvoorbeeld bij het gebruik van Cosmos DB; de standaard SLA is al indrukwekkend met 99,99%. Echter als we meerdere Azure regios instellen als ‘writable endpoints’ voor een Database Account, gaat de Azure Cosmos DB SLA naar maar liefst 99,999%, voor zowel lees- als schrijfbeschikbaarheid.
Azure biedt ook diverse beschikbaarheids opties die aan een dienst toegevoegd kunnen worden, voor Virtual Machines kan bijvoorbeeld gebruik gemaakt worden van Availability Sets. Een availability set is een logische groepering van VM’s waarmee Azure kan begrijpen hoe uw app is ontworpen, om zo redundantie en beschikbaarheid te kunnen bieden.
Je kan ook Availability Zones gebruiken voor diverse Azure services zoals VM Scale Sets (gebruikt in bijvoorbeeld Azure Kubernetes Services), Azure Backup, Storage Accounts, Key Vaults en nog meer. Een Availability Zones is een optie waarmee hoge beschikbaarheid gerealiseerd kan worden voor applicaties en data door deze te beveiligen tegen Data Center-uitval. Availability Zones zijn unieke, fysieke locaties binnen een Azure-regio. Elke zone bestaat uit een of meer datacenters die zijn voorzien van onafhankelijke stroomvoorziening, koeling en netwerk.
Voor het wereldwijd schalen van apps is de Cross-region load balancer beschikbaar, hiermee zijn indrukwekkende geografisch redundante HA-scenario's te realiseren.
Monitor je beschikbaarheid
Middels de Azure Status page is de status van elke regio en service te raadplegen. Voor individuele Azure services zijn de Service Health en Resource Health pagina’s de locaties om inzicht te krijgen in de huidige en historische status van globale en individuele services. Service Health pagina bewaard een 90 dagen geschiedenis van gebeurtenissen.
Specifiek voor Web applicaties is het mogelijk om binnen Application Insights de behaalde SLA te berekenen door gebruik te maken van de Availability -> SLA Report option feature. De rapportage kan aangepast worden volgens eigen criteria zoals de web test parameters, de failure thresholds en eventuele outage windows. Binnen de SLA rapportage heeft u de mogelijkheid om in tijd of per locatie de beschikbaarheid weer te geven:
Leer meer over de SLA via Intercept
Vervolg de availability reis door het Azure Architecture Center te bezoeken.
