Metrische bedrijfsgegevens gebruiken om robuuste Azure-toepassingen te ontwerpen

Beschikbaarheidsdoelen voor workloads

Zijn beschikbaarheidsdoelen zoals Service Level Agreements (SLA's), Service Level Indicators (S SLA's) en Service Level Objectives (SLO's) gedefinieerd voor de toepassing of de belangrijkste scenario's?

Inzicht in de verwachtingen van de klantbeschikbaarheid is essentieel voor het beoordelen van de algemene bewerkingen voor de toepassing. Als een klant er bijvoorbeeld naar streeft om een SLO van de toepassing te bereiken, zal het niveau van inherente operationele activiteit dat door de toepassing wordt vereist veel hoger zijn dan wanneer een SLO van het doel 99.999% 99.9% was.

Definieer uw eigen doel-SLA's voor elke workload in uw oplossing, zodat u kunt bepalen of de architectuur voldoet aan de bedrijfsvereisten.

Kosten en complexiteit overwegen

Al het andere is gelijk, hogere beschikbaarheid is beter. Maar als u naar meer negens streeft, groeien de kosten en complexiteit. Een uptime van 99.99% is ongeveer vijf minuten downtime per maand. Is het de extra complexiteit en kosten waard om vijf negens te bereiken? Het antwoord hangt af van de bedrijfsvereisten.

Hier volgen nog enkele overwegingen bij het definiëren van een SLA:

  • Als u vier negens ( ) wilt bereiken, kunt u niet vertrouwen op 99.99% handmatige interventie om fouten te herstellen. De toepassing moet een automatisch diagnose- en herstelproces kunnen uitvoeren.
  • Meer dan vier negens is het lastig om uitval snel genoeg te detecteren om aan de SLA te voldoen.
  • Denk na over de periode waartegen uw SLA wordt afgemeten. Hoe korter deze periode, hoe nauwer de tolerantiegrenzen. Het is niet zinvol om uw SLA te definiëren in termen van uur- of dagelijkse uptime.
  • Houd rekening met de MBTF- en MTTR-waarden. Hoe hoger uw SLA, hoe minder vaak de service uit kan gaan en hoe sneller de service moet worden hersteld.
  • Ga akkoord met uw klanten voor de beschikbaarheidsdoelen van elk onderdeel van uw toepassing en documenteren dit. Anders voldoet uw ontwerp mogelijk niet aan de verwachtingen van de klant.

Afhankelijkheden identificeren

Voer oefeningen voor afhankelijkheidstoewijzing uit om interne en externe afhankelijkheden te identificeren. Voorbeelden zijn afhankelijkheden met betrekking tot beveiliging of identiteit, zoals Active Directory of services van derden, zoals een betalingsprovider of e-mailservice.

Let vooral op externe afhankelijkheden die een single point of failure kunnen zijn of knelpunten kunnen veroorzaken. Als een workload een uptime vereist, maar afhankelijk is van een service met een SLA, kan die service geen single 99.99% point of failure in het systeem 99.9% zijn. Een oplossing is om een terugvalpad te hebben voor het geval de service mislukt. U kunt ook andere maatregelen nemen om te herstellen van een fout in die service.

De volgende tabel toont de potentiële cumulatieve downtime voor diverse SLA's.

SLA Downtime per week Downtime per maand Downtime per jaar
99% 1.68 Uur 7.2 Uur 3.65 Dagen
99.9% 10.1 minuten 43.2 minuten 8.76 Uur
99.95% 5 minuten 21.6 minuten 4.38 Uur
99.99% 1.01 minuten 4.32 minuten 52.56 minuten
99.999% 6 Seconden 25.9 Seconden 5.26 minuten

Kritieke systeemstromen identificeren

Inzicht in kritieke systeemstromen is essentieel voor het beoordelen van de algehele operationele effectiviteit en moet worden gebruikt om een statusmodel voor de toepassing te informeren. Het kan ook zien of gebieden van de toepassing over- of onderbelegd zijn en moeten worden aangepast om beter te voldoen aan zakelijke behoeften en kostendoelen.

Kritieke subsystemen of paden via de toepassing hebben mogelijk hogere verwachtingen met betrekking tot beschikbaarheid, herstel en prestaties vanwege de complexiteit van gekoppelde bedrijfsscenario's en -functionaliteit. Dit helpt ook om te begrijpen of de kosten worden beïnvloed door deze hogere behoeften.

Minder kritieke onderdelen identificeren

Sommige minder kritieke onderdelen of paden via de toepassing hebben mogelijk lagere verwachtingen met het gaat om beschikbaarheid, herstel en prestaties. Minder kritieke onderdelen kunnen leiden tot kostenbesparingen door lagere SKU's met minder prestaties en beschikbaarheid te kiezen.

Metrische gegevens voor herstel

Haal deze waarden af door een risicoanalyse uit te voeren en zorg ervoor dat u de kosten en het risico van downtime en gegevensverlies begrijpt. Dit zijn niet-functionele vereisten van een systeem en moeten worden bepaald door bedrijfsvereisten.

  • Recovery Time Objective (RTO) is de maximaal acceptabele tijd dat een toepassing niet beschikbaar is na een incident.
  • Recovery Point Objective (RPO) is de maximale duur van gegevensverlies die acceptabel is tijdens een noodherstel.

Als de MTTR-waarde van een kritiek onderdeel in een maximaal beschikbare installatie de systeem-RTO overschrijdt, kan een fout in het systeem een onacceptabele bedrijfsonderbreking veroorzaken. Dat betekent dat u het systeem niet binnen de gedefinieerde RTO kunt herstellen.

Metrische beschikbaarheidsgegevens

Gebruik deze metingen om redundantie te plannen en klant-SLA's te bepalen.

  • Gemiddelde tijd om te herstellen (MTTR) is de gemiddelde tijd die nodig is om een onderdeel te herstellen na een storing.
  • Gemiddelde tijd tussen storingen (TBF) is hoe lang een onderdeel redelijk lang kan verwachten tussen storingen.

Serviceovereenkomsten begrijpen

In Azure worden Service Level Agreement toezeggingen van Microsoft voor uptime en connectiviteit beschreven. Als de SLA voor een bepaalde service 99.9% is, kunt u ervan uit gaan dat de service op dat moment 99.9% beschikbaar is. Verschillende services hebben verschillende SLA's.

De Azure SLA bevat ook bepalingen voor het verkrijgen van een servicetegoed als niet aan de SLA wordt voldaan, samen met specifieke beschikbaarheidsdefinities voor elke service. Dit aspect van de SLA fungeert als een afdwingingsbeleid.

Het Service Level Agreement Estimator laat zien hoe u de SLA van uw architectuur berekent.

Samengestelde SLA's

Samengestelde SLA's hebben betrekking op meerdere services die een toepassing ondersteunen, elk met verschillende beschikbaarheidsniveaus. Denk bijvoorbeeld aan een App Service web-app die naar de Azure SQL Database. Op het moment van publicatie hebben deze Azure-services de volgende SLA's:

  • App Service web-apps = 99.95%
  • SQL Database =99.99%

Wat is de maximale downtime die u voor deze toepassing verwacht? Als beide services uitvallen, valt de hele toepassing uit. De kans dat elke service mislukt, is onafhankelijk, dus de samengestelde SLA voor deze toepassing is 99.95% × 99.99% = 99.94% . Dat is lager dan de afzonderlijke SLA's, wat niet verrassend is omdat een toepassing die afhankelijk is van meerdere services, meer potentiële foutpunten heeft.

U kunt de samengestelde SLA verbeteren door onafhankelijke terugvalpaden te maken. Als de SQL Database niet beschikbaar is, kunt u bijvoorbeeld transacties in een wachtrij zetten om later te worden verwerkt.

Samengestelde SLA

Met dit ontwerp is de toepassing nog steeds beschikbaar, ook als er geen verbinding met de database mogelijk is. De toepassing werkt echter niet als zowel de database als de wachtrij tegelijk uitvallen. Het verwachte percentage tijd voor een gelijktijdige fout is , dus de 0.0001 × 0.001 samengestelde SLA voor dit gecombineerde pad is:

  • Database of wachtrij = 1.0 − (0.0001 × 0.001) = 99.99999%

De totale, samengestelde SLA is:

  • Web-app en (database of wachtrij) = 99.95% × 99.99999% = \~99.95%

Er zijn afwegingen met deze benadering. De toepassingslogica is complexer, u betaalt voor de wachtrij en u moet rekening houden met problemen met gegevensconsistentie.

SLA's voor implementaties in meerdere regio's

SLA's voor implementaties voor meerdere regio's hebben betrekking op een techniek met hoge beschikbaarheid om de toepassing in meer dan één regio te implementeren en Azure Traffic Manager gebruiken om een fail over te zetten als de toepassing in één regio uitvalt.

De samengestelde SLA voor een implementatie in meerdere regio's wordt als volgt berekend:

  • N is de samengestelde SLA voor de toepassing die in één regio is geïmplementeerd.
  • R is het aantal regio's waar de toepassing wordt geïmplementeerd.

De verwachte kans dat de toepassing in alle regio's tegelijk uitvalt, is ( (1 − N) \^ R ). Als de SLA voor één regio bijvoorbeeld 99.95% is:

  • De gecombineerde SLA voor twee regio's = (1 − (1 − 0.9995) \^ 2) = 99.999975%
  • De gecombineerde SLA voor vier regio's = (1 − (1 − 0.9995) \^ 4) = 99.999999%

De SLA voor Traffic Manager is ook een factor. Een failover wordt niet onmiddellijk in actief-passief-configuraties, wat kan leiden tot downtime tijdens een failover. Zie Eindpuntcontrole van Traffic Manager.