Werkbelastingen op carrierniveau in Azure

Missiekritieke systemen richten zich voornamelijk op het maximaliseren van de uptime en ze bestaan in veel branches. Binnen de telecommunicatie-industrie worden ze aangeduid als carrier-grade systemen. Deze systemen zijn ontwikkeld vanwege een of meer van de volgende stuurprogramma's:

• Het minimaliseren van het verlies van mensenlevens of letsel.
• Voldoen aan wettelijke vereisten met betrekking tot betrouwbaarheid om boetes te voorkomen.
• Het optimaliseren van de service voor klanten om het verloop naar concurrenten te minimaliseren.
• Voldoen aan contractuele Service Level Agreements (SLA's) met zakelijke of overheidsklanten.

In deze reeks artikelen wordt de ontwerpmethodologie voor bedrijfskritieke workloads toegepast om prescriptieve richtlijnen te bieden voor het bouwen en gebruiken van een zeer betrouwbare, tolerante en beschikbare telecommunicatieworkload in Azure.

Notitie

De artikelen in deze reeks zijn gericht op het bieden van aanvullende essentiële overwegingen bij het ontwerpen van betrouwbaarheidsniveaus voor 99,999% ('5 9s') binnen de telecommunicatie-industrie.

Wat is een workload op carrierniveau?

De term workload verwijst naar een verzameling toepassingsresources die ondersteuning bieden voor een gemeenschappelijk bedrijfsdoel of de uitvoering van een gemeenschappelijk bedrijfsproces, waarbij meerdere services, zoals API's en gegevensarchieven, samenwerken om specifieke end-to-end-functionaliteit te leveren.

De term bedrijfskritiek verwijst naar een classificatie van kritieken waarbij aanzienlijke financiële kosten (bedrijfskritiek) of menselijke kosten (veiligheidskritiek) zijn gekoppeld aan niet-beschikbaarheid of ondermaatse prestaties.

Een workload op carrier-grade draait om zowel bedrijfskritiek als veiligheidskritiek, waarbij er een fundamentele vereiste is om operationeel te zijn met slechts enkele minuten of zelfs seconden downtime per kalenderjaar. Als u niet aan deze uptime-vereiste voldoet, kan dit leiden tot veel levensverlies, aanzienlijke boetes of contractuele sancties.

Het operationele aspect van de workload omvat de wijze waarop betrouwbaarheid wordt gemeten en de doelen waaraan de workload moet voldoen of overschrijden. Uiterst betrouwbare systemen streven doorgaans naar een uptime van 99,999% (meestal aangeduid als '5 9s') of 0,001% downtime in een jaar (ongeveer 5 minuten). Sommige systemen streven naar 99,9999% uptime, of 30 seconden downtime per jaar, of zelfs hogere betrouwbaarheidsniveaus. Dit omvat alle vormen en oorzaken van storingen: gepland onderhoud, infrastructuurstoringen, menselijke fouten, softwareproblemen en zelfs natuurrampen.

Hoewel het gebruikte platform is geëvolueerd van toegewezen, eigen hardware via commerciële, standaardhardware tot OpenStack- of VMware-clouds, leveren telecommunicatiebedrijven consistent services met ≤ 5 minuten downtime per jaar en bereiken ze in veel gevallen ≤ 30 seconden downtime als gevolg van ongeplande storingen.

Wat zijn de veelvoorkomende uitdagingen?

Het bouwen van werkbelastingen op carrierniveau is een uitdaging om de volgende belangrijke redenen:

Lift-and-shift-benadering

Telecommunicatiebedrijven hebben goed ontworpen toepassingen die het verwachte gedrag op hun bestaande infrastructuur leveren. Wees echter voorzichtig voordat u ervan uitgaat dat het overzetten van deze toepassingen naar een openbare cloudinfrastructuur geen invloed heeft op hun tolerantie.

De bestaande toepassingen maken een reeks veronderstellingen over hun onderliggende infrastructuur, die waarschijnlijk niet waar blijven wanneer ze van on-premises naar de openbare cloud worden verplaatst. De architect moet controleren of de infrastructuur en het toepassingsontwerp nog steeds behouden blijven en aanpassen aan de nieuwe realiteit. De architect moet ook zoeken naar mogelijkheden waarbij de nieuwe infrastructuur beperkingen verwijdert die on-premises bestonden.

De upgrade van on-premises systemen moet bijvoorbeeld worden uitgevoerd omdat het niet haalbaar is om voldoende hardware te onderhouden om naast een nieuwe implementatie een nieuwe implementatie te maken en langzaam op een veilige manier over te stappen. Dit upgradepad genereert een groot aantal vereisten voor hoe upgrades en terugdraaiacties worden beheerd. Deze vereisten leiden tot complexiteit en betekenen dat upgrades zelden worden uitgevoerd en alleen worden toegestaan in zorgvuldig beheerde onderhoudsvensters.

In de openbare cloud is het echter redelijk om parallel met de bestaande implementatie een nieuwe implementatie te maken. Dit proces biedt de mogelijkheid voor grote vereenvoudigingen in het operationele ontwerp van de toepassing en verbeteringen in de gebruikerservaring en verwachtingen.

Monolithische oplossingen

Uit ervaring in verschillende bedrijfskritieke branches blijkt dat het niet realistisch is om te proberen een monolithische oplossing te bouwen die de gewenste beschikbaarheidsniveaus bereikt. Er zijn gewoon te veel mogelijke oorzaken van fouten in een complex systeem. In plaats daarvan bestaan succesvolle oplossingen uit afzonderlijke onafhankelijke en redundante elementen. Elke eenheid heeft een relatief eenvoudige beschikbaarheid (meestal ~99,9%), maar wanneer de totale oplossing wordt gecombineerd, worden de benodigde beschikbaarheidsdoelen bereikt. De kunst van carrier-grade engineering wordt er dan voor gezorgd dat de enige afhankelijkheden die de redundante elementen gemeen hebben, de afhankelijkheden zijn die absoluut noodzakelijk zijn, omdat ze de meest significante invloed uitoefenen op de algehele beschikbaarheid, vaak groter dan wat dan ook in het ontwerp.

Alleen zonegebonden redundantie bouwen

Het gebruik van Microsoft Azure Beschikbaarheidszones is de basiskeuze om het risico op storingen als gevolg van hardwarestoringen of gelokaliseerde omgevingsproblemen te verminderen. Het is echter niet voldoende om carrier-grade beschikbaarheid te bereiken, voornamelijk om de volgende redenen:

• Beschikbaarheidszones (AZ's) zijn zo ontworpen dat de netwerklatentie tussen twee zones in één regio ≤ 2 ms is. AZ's kunnen niet wijd en geografisch verspreid zijn. De AZ's delen dus een gecorreleerd risico op storingen als gevolg van natuurrampen, zoals overstromingen of enorme stroomuitval, waardoor meerdere AZ's binnen een regio kunnen worden uitgeschakeld.

• Veel Azure-services zijn expliciet ontworpen om zone-redundant te zijn, zodat de toepassingen die ze gebruiken geen expliciete logica nodig hebben om te profiteren van de beschikbaarheidswinst. Deze redundantiefunctie binnen de service vereist samenwerking tussen de elementen in elke zone. Er is vaak een onvermijdelijk risico op softwarefouten in de ene zone die gecorreleerde fouten in andere zones veroorzaakt. Elk probleem met een geheim of certificaat dat wordt gebruikt met de zone-redundante service kan bijvoorbeeld van invloed zijn op alle AZ's tegelijk.

Wat zijn de belangrijkste ontwerpgebieden?

Houd bij het ontwerpen van een werkbelasting op carriereniveau rekening met de volgende gebieden:

Ontwerpgebied	Description
Fouttolerantie	Het toepassingsontwerp moet onvermijdelijke fouten toestaan, zodat de toepassing als geheel op een bepaald niveau kan blijven werken. Het ontwerp moet storingspunten minimaliseren en een federatieve benadering hanteren.
Gegevensmodel	Het ontwerp moet voldoen aan de vereisten voor consistentie, beschikbaarheid en partitietolerantie van de database. Beschikbaarheid van carrier grade vereist dat de toepassing in meerdere regio's wordt geïmplementeerd. Voor deze implementatie moet zorgvuldig worden nagedacht over hoe de gegevens van de toepassing in deze regio's worden beheerd.
Statusmodellering	Een effectief statusmodel biedt waarneembaarheid van alle onderdelen, het platform en de toepassing, zodat problemen snel kunnen worden gedetecteerd en de reactie gereed is via zelfherstel of andere herstelbewerkingen.
Testen en valideren	Het ontwerp en de implementatie van de toepassing moeten grondig worden getest. Daarnaast moet de integratie en implementatie van de toepassing als een volledige oplossing worden getest.

Volgende stap

Begin met het beoordelen van de ontwerpprincipes voor scenario's voor carrier-grade toepassingen.

Ontwerpprincipes