Ontwerpprincipes van een workload op carrierniveau in Azure

Werkbelasting op carrierniveau moet worden ontworpen volgens de leidende principes van de kwaliteitspijlers van het Well-Architected Framework:

• Betrouwbaarheid
• Prestatie-efficiëntie
• Operationele topprestaties
• Beveiliging
• Kostenoptimalisatie

In dit artikel worden de ontwerpprincipes op dragerniveau beschreven die de essentiële ontwerpprincipes resoneren en uitbreiden. Deze collectieve principes dienen als een roadmap voor latere ontwerpbeslissingen in de kritieke ontwerpgebieden. We raden u ten zeerste aan deze principes te leren kennen om meer inzicht te krijgen in de effecten ervan en de afwegingen die verband houden met niet-naleving.

Er zijn duidelijke kostennadelen verbonden aan het introduceren van een grotere betrouwbaarheid, die zorgvuldig moeten worden overwogen in de context van workloadvereisten.

Belangrijk

Dit artikel maakt deel uit van de azure Well-Architected reeks werkbelastingen op carrierniveau . Als u niet bekend bent met deze reeks, raden we u aan te beginnen met Wat is een workload op carrierniveau?

Houd rekening met dit architectuurmodel op hoog niveau wanneer u rekening houdt met deze punten.

Fout aannemen

Ga ervan uit dat alles kan en zal mislukken. Het toepassingsontwerp moet deze fouten met fouttolerantie toestaan, zodat een toepassing op een bepaald niveau kan blijven werken.

• Minimaliseer Single Points of Failure en implementeer een federatieve benadering.

• Implementeer de toepassing in meerdere regio's met correct gegevensbeheer in die regio's, zodat de gevolgen van de CAP-stelling kunnen worden meegemoed.

• Problemen automatisch detecteren en binnen enkele seconden reageren. Zie statuscontrole voor meer informatie.

• Test de volledige oplossing, inclusief de implementatie van de toepassing, platformintegratie en implementatie. Deze tests moeten chaostests op productiesystemen omvatten om te voorkomen dat er vooroordelen worden getest.

Niets delen

Niets delen is een algemene en eenvoudige benadering om hoge beschikbaarheid te bereiken. Gebruik deze methode wanneer een toepassing kan worden onderhouden door meerdere, afzonderlijke elementen, die uitwisselbaar zijn. De afzonderlijke elementen moeten een goed begrepen beschikbaarheidsmetriek hebben, maar deze hoeven niet hoog te zijn. De elementen moeten echter worden gecombineerd om onafhankelijk te blijven, zonder gedeelde infrastructuur of afhankelijkheden.

Niets delen is vaak onmogelijk. Als u wilt beginnen met de positie dat er niets moet worden gedeeld en alleen de kleinst mogelijke set gedeelde afhankelijkheden moet worden toegevoegd, moet dit resulteren in een optimale oplossing.

Voorbeeld

Gezien een enkel systeem met zes uur downtime per jaar (ongeveer 3,5*9s), zal een oplossing die vier systemen combineert waarbij de perioden van downtime niet gerelateerd zijn, minder dan 30s downtime per jaar ervaren. Zodra deze vier systemen afhankelijk zijn van een gemeenschappelijke service, zoals globale DNS, is hun downtime niet langer oncorreleerd. De resulterende downtime zal hoger zijn.

Volgende stap

Bekijk het ontwerpgebied voor fouttolerantie voor werkbelastingen op carrierniveau.

Ontwerpgebied: Fouttolerantie