Delen via

Overwegingen voor toepassingsplatforms voor bedrijfskritieke workloads in Azure

  • Artikel

Azure biedt veel rekenservices voor het hosten van maximaal beschikbare toepassingen. De services verschillen in mogelijkheden en complexiteit. We raden u aan services te kiezen op basis van:

  • Niet-functionele vereisten voor betrouwbaarheid, beschikbaarheid, prestaties en beveiliging.
  • Beslissingsfactoren zoals schaalbaarheid, kosten, bruikbaarheid en complexiteit.

De keuze van een platform voor het hosten van toepassingen is een kritieke beslissing die van invloed is op alle andere ontwerpgebieden. Verouderde of bedrijfseigen ontwikkelsoftware kan bijvoorbeeld niet worden uitgevoerd in PaaS-services of containertoepassingen. Deze beperking is van invloed op uw keuze van het rekenplatform.

Een bedrijfskritieke toepassing kan meer dan één rekenservice gebruiken ter ondersteuning van meerdere samengestelde workloads en microservices, elk met verschillende vereisten.

Dit ontwerpgebied bevat aanbevelingen met betrekking tot rekenopties voor selectie, ontwerp en configuratie. We raden u ook aan om vertrouwd te raken met de beslissingsstructuur Rekenproces.

Belangrijk

Dit artikel maakt deel uit van de serie bedrijfskritieke workloads van Azure Well-Architected Framework . Als u niet bekend bent met deze reeks, raden we u aan te beginnen met Wat is een bedrijfskritieke workload? .

Wereldwijde distributie van platformresources

Een typisch patroon voor een bedrijfskritieke workload omvat globale resources en regionale resources.

Azure-services, die niet beperkt zijn tot een bepaalde Azure-regio, worden geïmplementeerd of geconfigureerd als globale resources. Sommige gebruiksvoorbeelden zijn het distribueren van verkeer over meerdere regio's, het opslaan van een permanente status voor een hele toepassing en het opslaan van globale statische gegevens in de cache. Als u zowel een schaaleenheidarchitectuur als globale distributie nodig hebt, moet u overwegen hoe resources optimaal worden gedistribueerd of gerepliceerd in Azure-regio's.

Andere resources worden regionaal geïmplementeerd. Deze resources, die worden geïmplementeerd als onderdeel van een implementatiestempel, komen doorgaans overeen met een schaaleenheid. Een regio kan echter meer dan één stempel hebben en een stempel kan meer dan één eenheid hebben. De betrouwbaarheid van regionale resources is van cruciaal belang omdat ze verantwoordelijk zijn voor het uitvoeren van de hoofdworkload.

In de volgende afbeelding ziet u het ontwerp op hoog niveau. Een gebruiker opent de toepassing via een centraal globaal toegangspunt dat aanvragen vervolgens omleidt naar een geschikte regionale implementatiestempel:

Diagram met een essentiële architectuur.

De bedrijfskritieke ontwerpmethodologie vereist een implementatie in meerdere regio's. Dit model zorgt voor regionale fouttolerantie, zodat de toepassing beschikbaar blijft, zelfs wanneer een hele regio uitvalt. Wanneer u een toepassing voor meerdere regio's ontwerpt, moet u rekening houden met verschillende implementatiestrategieën, zoals actief/actief en actief/passief, samen met toepassingsvereisten, omdat er aanzienlijke compromissen zijn voor elke benadering. Voor bedrijfskritieke workloads raden we ten zeerste het actieve/actieve model aan.

Niet elke workload ondersteunt of vereist het uitvoeren van meerdere regio's tegelijk. U moet specifieke toepassingsvereisten afwegen tegen afwegingen om een optimale ontwerpbeslissing te bepalen. Voor bepaalde toepassingsscenario's met lagere betrouwbaarheidsdoelen kunnen actieve/passieve of sharding geschikte alternatieven zijn.

Beschikbaarheidszones kunnen regionale implementaties met hoge beschikbaarheid bieden in verschillende datacenters binnen een regio. Bijna alle Azure-services zijn beschikbaar in een zonegebonden configuratie, waarbij de service wordt gedelegeerd aan een specifieke zone, of een zone-redundante configuratie, waarbij het platform er automatisch voor zorgt dat de service zich over meerdere zones uitstrekt en een zonestoring kan weerstaan. Deze configuraties bieden fouttolerantie tot op datacenterniveau.

Overwegingen bij het ontwerpen

  • Regionale en zonegebonden mogelijkheden. Niet alle services en mogelijkheden zijn beschikbaar in elke Azure-regio. Deze overweging kan van invloed zijn op de regio's die u kiest. Bovendien zijn beschikbaarheidszones niet in elke regio beschikbaar.

  • Regionale paren. Azure-regio's zijn gegroepeerd in regionale paren die uit twee regio's in één geografie bestaan. Sommige Azure-services maken gebruik van gekoppelde regio's om bedrijfscontinuïteit te garanderen en om een niveau van bescherming tegen gegevensverlies te bieden. Azure Geografisch redundante opslag (GRS) repliceert bijvoorbeeld gegevens automatisch naar een secundaire gekoppelde regio, zodat gegevens duurzaam zijn als de primaire regio niet kan worden hersteld. Als een storing van invloed is op meerdere Azure-regio's, krijgt ten minste één regio in elk paar prioriteit voor herstel.

  • Gegevensconsistentie. Voor consistentieproblemen kunt u overwegen om een wereldwijd gedistribueerd gegevensarchief, een gestempelde regionale architectuur en een gedeeltelijk actieve/actieve implementatie te gebruiken. In een gedeeltelijke implementatie zijn sommige onderdelen actief in alle regio's, terwijl andere zich centraal in de primaire regio bevinden.

  • Veilige implementatie. Het SDP-framework (Safe Deployment Practice) van Azure zorgt ervoor dat alle code- en configuratiewijzigingen (gepland onderhoud) aan het Azure-platform gefaseerd worden geïmplementeerd. De status wordt geanalyseerd op verslechtering tijdens de release. Nadat de canary- en testfasen zijn voltooid, worden platformupdates geserialiseerd over regionale paren, zodat slechts één regio in elk paar op een bepaald moment wordt bijgewerkt.

  • Platformcapaciteit. Net als elke cloudprovider heeft Azure eindige resources. Niet-beschikbaarheid kan het gevolg zijn van capaciteitsbeperkingen in regio's. Als er een regionale storing is, neemt de vraag naar resources toe naarmate de workload probeert te herstellen binnen de gekoppelde regio. De storing kan een capaciteitsprobleem creëren, waarbij het aanbod tijdelijk niet aan de vraag voldoet.

Ontwerpaanbeveling

  • Implementeer uw oplossing in ten minste twee Azure-regio's om u te beschermen tegen regionale storingen. Implementeer deze in regio's met de mogelijkheden en kenmerken die de workload vereist. De mogelijkheden moeten voldoen aan de prestatie- en beschikbaarheidsdoelen en tegelijkertijd voldoen aan de vereisten voor gegevenslocatie en -retentie.

    Sommige vereisten voor gegevensnaleving kunnen bijvoorbeeld het aantal beschikbare regio's beperken en mogelijk ontwerpcompromittaties afdwingen. In dergelijke gevallen raden we u ten zeerste aan extra te investeren in operationele wrappers om fouten te voorspellen, detecteren en erop te reageren. Stel dat u beperkt bent tot een geografie met twee regio's en slechts één van deze regio's ondersteunt beschikbaarheidszones (3 + 1 datacentermodel). Maak een secundair implementatiepatroon met behulp van foutdomeinisolatie zodat beide regio's in een actieve configuratie kunnen worden geïmplementeerd en zorg ervoor dat de primaire regio meerdere implementatiestempels bevat.

    Als geschikte Azure-regio's niet allemaal mogelijkheden bieden die u nodig hebt, moet u bereid zijn om in te leveren op de consistentie van regionale implementatiestempels om prioriteit te geven aan geografische distributie en de betrouwbaarheid te maximaliseren. Als slechts één Azure-regio geschikt is, implementeert u meerdere implementatiestempels (regionale schaaleenheden) in de geselecteerde regio om risico's te beperken en gebruikt u beschikbaarheidszones om fouttolerantie op datacenterniveau te bieden. Een dergelijk aanzienlijk compromis in de geografische verdeling beperkt echter de haalbare samengestelde SLA en de algehele betrouwbaarheid aanzienlijk.

    Belangrijk

    Voor scenario's die gericht zijn op een SLO die groter is dan of gelijk is aan 99,99%, raden we aan minimaal drie implementatieregio's te gebruiken om de samengestelde SLA en de algehele betrouwbaarheid te maximaliseren. Bereken de samengestelde SLA voor alle gebruikersstromen. Zorg ervoor dat de samengestelde SLA is afgestemd op bedrijfsdoelen.

  • Voor grootschalige toepassingsscenario's met aanzienlijke verkeersvolumes ontwerpt u de oplossing om te schalen tussen meerdere regio's om potentiële capaciteitsbeperkingen binnen één regio te doorlopen. Aanvullende regionale implementatiestempels zorgen voor een hogere samengestelde SLA. Het gebruik van globale resources beperkt de toename van samengestelde SLA die u bereikt door meer regio's toe te voegen.

  • Definieer en valideer uw RPO (Recovery Point Objectives) en RTO (Recovery Time Objectives).

  • Binnen één geografie geeft u prioriteit aan het gebruik van regionale paren om te profiteren van geserialiseerde SDP-implementaties voor gepland onderhoud en regionale prioriteitsbepaling voor ongepland onderhoud.

  • Plaats Azure-resources geografisch samen met gebruikers om netwerklatentie te minimaliseren en end-to-end-prestaties te maximaliseren.

  • Stem de beschikbaarheid van de huidige service af op productroadmaps wanneer u implementatieregio's kiest. Sommige services zijn mogelijk niet onmiddellijk beschikbaar in elke regio.

Containerisatie

Een container bevat toepassingscode en de bijbehorende configuratiebestanden, bibliotheken en afhankelijkheden die de toepassing moet uitvoeren. Containerisatie biedt een abstractielaag voor toepassingscode en de bijbehorende afhankelijkheden en zorgt voor een scheiding van het onderliggende hostingplatform. Het softwarepakket is zeer draagbaar en kan consistent worden uitgevoerd op verschillende infrastructuurplatforms en cloudproviders. Ontwikkelaars hoeven geen code te herschrijven en kunnen toepassingen sneller en betrouwbaarder implementeren.

Belangrijk

U wordt aangeraden containers te gebruiken voor bedrijfskritieke toepassingspakketten. Ze verbeteren het gebruik van de infrastructuur omdat u meerdere containers op dezelfde gevirtualiseerde infrastructuur kunt hosten. Omdat alle software is opgenomen in de container, kunt u de toepassing ook verplaatsen tussen verschillende besturingssystemen, ongeacht runtimes of bibliotheekversies. Het beheer is ook eenvoudiger met containers dan met traditionele gevirtualiseerde hosting.

Bedrijfskritieke toepassingen moeten snel worden geschaald om prestatieknelpunten te voorkomen. Omdat containerinstallatiekopieën vooraf zijn gebouwd, kunt u het opstarten beperken tot alleen tijdens bootstrapping van de toepassing, wat snelle schaalbaarheid biedt.

Overwegingen bij het ontwerpen

  • Bewaking. Het kan lastig zijn voor bewakingsservices om toegang te krijgen tot toepassingen die zich in containers bevinden. Doorgaans hebt u software van derden nodig om indicatoren voor de status van de container te verzamelen en op te slaan, zoals CPU- of RAM-gebruik.

  • Beveiliging. De besturingssysteemkernel van het hostingplatform wordt gedeeld in meerdere containers, waardoor er één aanvalspunt ontstaat. Het risico van toegang tot host-VM's is echter beperkt omdat containers zijn geïsoleerd van het onderliggende besturingssysteem.

  • Status. Hoewel het mogelijk is om gegevens op te slaan in het bestandssysteem van een actieve container, blijven de gegevens niet behouden wanneer de container opnieuw wordt gemaakt. In plaats daarvan kunt u gegevens behouden door externe opslag te koppelen of een externe database te gebruiken.

Ontwerpaanbeveling

  • Plaats alle toepassingsonderdelen in een container. Gebruik containerinstallatiekopieën als het primaire model voor toepassingsimplementatiepakketten.

  • Geef, indien mogelijk, prioriteit aan op Linux gebaseerde containerruntimes. De installatiekopieën zijn lichter en er worden regelmatig nieuwe functies voor Linux-knooppunten/containers uitgebracht.

  • Maak containers onveranderbaar en vervangbaar, met korte levenscyclus.

  • Zorg ervoor dat u alle relevante logboeken en metrische gegevens verzamelt van de container, containerhost en het onderliggende cluster. Verzend de verzamelde logboeken en metrische gegevens naar een geïntegreerde gegevenssink voor verdere verwerking en analyse.

  • Containerinstallatiekopieën opslaan in Azure Container Registry. Gebruik geo-replicatie om containerinstallatiekopieën te repliceren in alle regio's. Schakel Microsoft Defender in voor containerregisters om beveiligingsproblemen te scannen op containerinstallatiekopieën. Zorg ervoor dat de toegang tot het register wordt beheerd door Microsoft Entra-id.

Containerhosting en indeling

Verschillende Azure-toepassingsplatforms kunnen effectief containers hosten. Elk van deze platforms heeft voor- en nadelen. Vergelijk de opties in de context van uw bedrijfsvereisten. Optimaliseer echter altijd de betrouwbaarheid, schaalbaarheid en prestaties. Raadpleeg deze artikelen voor meer informatie:

Belangrijk

Azure Kubernetes Service (AKS) en Azure Container Apps behoren tot uw eerste keuzes voor containerbeheer, afhankelijk van uw vereisten. Hoewel Azure App Service geen orchestrator is, is het als containerplatform met lage wrijving nog steeds een haalbaar alternatief voor AKS.

Ontwerpoverwegingen en aanbevelingen voor Azure Kubernetes Service

AKS, een beheerde Kubernetes-service, maakt snelle clusterinrichting mogelijk zonder complexe clusterbeheeractiviteiten en biedt een functieset met geavanceerde netwerk- en identiteitsmogelijkheden. Zie Azure Well-Architected Framework review - AKS voor een volledige set aanbevelingen.

Belangrijk

Er zijn enkele fundamentele configuratiebeslissingen die u niet kunt wijzigen zonder het AKS-cluster opnieuw te implementeren. Voorbeelden zijn de keuze tussen openbare en privé-AKS-clusters, het inschakelen van Azure Network Policy, Microsoft Entra integratie en het gebruik van beheerde identiteiten voor AKS in plaats van service-principals.

Betrouwbaarheid

AKS beheert het systeemeigen Kubernetes-besturingsvlak. Als het besturingsvlak niet beschikbaar is, ondervindt de workload downtime. Profiteer van de betrouwbaarheidsfuncties van AKS:

  • Implementeer AKS-clusters in verschillende Azure-regio's als een schaaleenheid om de betrouwbaarheid en beschikbaarheid te maximaliseren. Gebruik beschikbaarheidszones om de tolerantie binnen een Azure-regio te maximaliseren door het AKS-besturingsvlak en agentknooppunten te verdelen over fysiek gescheiden datacenters. Als colocatielatentie echter een probleem is, kunt u AKS-implementatie binnen één zone uitvoeren of nabijheidsplaatsingsgroepen gebruiken om de latentie tussen knooppunten te minimaliseren.

  • Gebruik de SLA voor AKS-uptime voor productieclusters om de beschikbaarheidsgaranties voor Kubernetes API-eindpunten te maximaliseren.

Schaalbaarheid

Houd rekening met AKS-schaallimieten, zoals het aantal knooppunten, knooppuntgroepen per cluster en clusters per abonnement.

Isolatie

Behoud grenzen tussen de infrastructuur die wordt gebruikt door de workload en systeemhulpprogramma's. Het delen van infrastructuur kan leiden tot hoog resourcegebruik en luidruchtige scenario's.

  • Gebruik afzonderlijke knooppuntgroepen voor systeem- en workloadservices. Toegewezen knooppuntgroepen voor workloadonderdelen moeten zijn gebaseerd op vereisten voor gespecialiseerde infrastructuurresources, zoals GPU-VM's met hoog geheugen. Over het algemeen kunt u voorkomen dat u een groot aantal knooppuntgroepen implementeert om onnodige beheeroverhead te verminderen.

  • Gebruik taints en toleranties om toegewezen knooppunten te bieden en resource-intensieve toepassingen te beperken.

  • Evalueer de vereisten voor toepassingsaffiniteit en anti-affiniteit en configureer de juiste colocatie van containers op knooppunten.

Beveiliging

Standaard vanille Kubernetes vereist een aanzienlijke configuratie om een geschikte beveiligingspostuur te garanderen voor bedrijfskritieke scenario's. AKS pakt verschillende beveiligingsrisico's standaard aan. Functies zijn onder andere privéclusters, controle en aanmelding bij Log Analytics, beperkte knooppuntinstallatiekopieën en beheerde identiteiten.

  • Pas configuratierichtlijnen toe die zijn opgegeven in de AKS-beveiligingsbasislijn.

  • Gebruik AKS-functies voor het afhandelen van clusteridentiteit en toegangsbeheer om operationele overhead te verminderen en consistent toegangsbeheer toe te passen.

  • Gebruik beheerde identiteiten in plaats van service-principals om beheer en rotatie van referenties te voorkomen. U kunt beheerde identiteiten toevoegen op clusterniveau. Op podniveau kunt u beheerde identiteiten gebruiken via Microsoft Entra Workload-ID.

  • Gebruik Microsoft Entra-integratie voor gecentraliseerd accountbeheer en wachtwoorden, toegangsbeheer voor toepassingen en verbeterde identiteitsbeveiliging. Gebruik Kubernetes RBAC met Microsoft Entra-id voor minimale bevoegdheden en minimaliseer het verlenen van beheerdersbevoegdheden om configuratie- en geheimentoegang te beveiligen. Beperk ook de toegang tot het configuratiebestand van het Kubernetes-cluster met behulp van op rollen gebaseerd toegangsbeheer van Azure. Beperk de toegang tot acties die containers kunnen uitvoeren, geef het minste aantal machtigingen en voorkom het gebruik van escalatie van basisbevoegdheden.

Upgrades

Clusters en knooppunten moeten regelmatig worden bijgewerkt. AKS ondersteunt Kubernetes-versies in overeenstemming met de releasecyclus van systeemeigen Kubernetes.

  • Abonneer u op de openbare AKS-roadmap en releaseopmerkingen op GitHub om op de hoogte te blijven van aanstaande wijzigingen, verbeteringen en, belangrijker nog, Kubernetes-versiereleases en -afschaffingen.

  • Pas de richtlijnen in de AKS-controlelijst toe om te zorgen voor afstemming met best practices.

  • Houd rekening met de verschillende methoden die door AKS worden ondersteund voor het bijwerken van knooppunten en/of clusters. Deze methoden kunnen handmatig of geautomatiseerd zijn. U kunt Gepland onderhoud gebruiken om onderhoudsvensters voor deze bewerkingen te definiëren. Nieuwe installatiekopieën worden wekelijks uitgebracht. AKS ondersteunt ook kanalen voor automatische upgrade voor het automatisch upgraden van AKS-clusters naar nieuwere versies van Kubernetes en/of nieuwere knooppuntinstallatiekopieën wanneer deze beschikbaar zijn.

Netwerken

Evalueer de netwerkinvoegtoepassingen die het beste bij uw gebruiksscenario passen. Bepaal of u gedetailleerde controle nodig hebt over het verkeer tussen pods. Azure ondersteunt kubenet, Azure CNI en Bring Your Own CNI voor specifieke gebruiksvoorbeelden.

Geef prioriteit aan het gebruik van Azure CNI na het beoordelen van de netwerkvereisten en de grootte van het cluster. Azure CNI maakt het gebruik van Azure - of Calico-netwerkbeleid mogelijk voor het beheren van verkeer binnen het cluster.

Bewaking

Uw bewakingshulpprogramma's moeten logboeken en metrische gegevens van actieve pods kunnen vastleggen. U moet ook informatie verzamelen van de Kubernetes Metrics-API om de status van actieve resources en workloads te bewaken.

Beheer

Gebruik beleidsregels om gecentraliseerde beveiligingen op een consistente manier toe te passen op AKS-clusters. Pas beleidstoewijzingen toe met een abonnementsbereik of hoger om consistentie tussen ontwikkelteams te stimuleren.

  • Bepaal met behulp van Azure Policy welke functies aan pods worden verleend en of uitvoering in strijd is met het beleid. Deze toegang wordt gedefinieerd via ingebouwd beleid dat wordt geleverd door de Azure Policy-invoegtoepassing voor AKS.

  • Stel een consistente betrouwbaarheids- en beveiligingsbasislijn voor AKS-cluster- en podconfiguraties in met behulp van Azure Policy.

  • Gebruik de Azure Policy-invoegtoepassing voor AKS om podfuncties te beheren, zoals hoofdmachtigingen, en om pods die niet aan het beleid voldoen, niet toe te staan.

Notitie

Wanneer u implementeert in een Azure-landingszone, moet het Azure-beleid om u te helpen zorgen voor consistente betrouwbaarheid en beveiliging worden geleverd door de implementatie van de landingszone.

De essentiële referentie-implementaties bieden een pakket basislijnbeleidsregels om aanbevolen betrouwbaarheids- en beveiligingsconfiguraties te stimuleren.

Ontwerpoverwegingen en aanbevelingen voor Azure App Service

Voor workloadscenario's op basis van web en API is App Service mogelijk een haalbaar alternatief voor AKS. Het biedt een containerplatform met lage wrijving zonder de complexiteit van Kubernetes. Zie Betrouwbaarheidsoverwegingen voor App Service en Operationele uitmuntendheid voor App Service voor een volledige reeks aanbevelingen.

Betrouwbaarheid

Evalueer het gebruik van TCP- en SNAT-poorten. TCP-verbindingen worden gebruikt voor alle uitgaande verbindingen. SNAT-poorten worden gebruikt voor uitgaande verbindingen met openbare IP-adressen. SNAT-poortuitputting is een veelvoorkomend foutscenario. U moet dit probleem voorspellend detecteren door belastingstests uit te voeren terwijl u Azure Diagnostics gebruikt om poorten te bewaken. Als er SNAT-fouten optreden, moet u schalen tussen meer of grotere werkrollen of coderingsprocedures implementeren om SNAT-poorten te behouden en opnieuw te gebruiken. Voorbeelden van coderingsprocedures die u kunt gebruiken, zijn groepsgewijze verbindingen en het luie laden van resources.

Tcp-poortuitputting is een ander foutscenario. Dit gebeurt wanneer de som van uitgaande verbindingen van een bepaalde werkrol de capaciteit overschrijdt. Het aantal beschikbare TCP-poorten is afhankelijk van de grootte van de werkrol. Zie TCP- en SNAT-poorten voor aanbevelingen.

Schaalbaarheid

Plan toekomstige schaalbaarheidsvereisten en toepassingsgroei, zodat u vanaf het begin de juiste aanbevelingen kunt toepassen. Hiermee kunt u technische migratieschulden voorkomen naarmate de oplossing groeit.

  • Schakel automatische schaalaanpassing in om ervoor te zorgen dat er voldoende resources beschikbaar zijn voor serviceaanvragen. Evalueer de schaalaanpassing per app voor high-densityhosting op App Service.

  • Houd er rekening mee dat App Service een standaard, zachte limiet voor exemplaren per App Service-abonnement heeft.

  • Regels voor automatische schaalaanpassing toepassen. Een App Service-plan wordt uitgeschaald als aan een regel binnen het profiel wordt voldaan, maar wordt alleen ingeschaald als aan alle regels binnen het profiel wordt voldaan. Gebruik een combinatie van regels voor uitschalen en inschalen om ervoor te zorgen dat automatische schaalaanpassing actie kan ondernemen om uit te schalen en in te schalen. Inzicht in het gedrag van meerdere schaalregels in één profiel.

  • Houd er rekening mee dat u schaalaanpassing per app kunt inschakelen op het niveau van het App Service-plan, zodat een toepassing onafhankelijk kan worden geschaald van het App Service-abonnement dat als host fungeert. Apps worden toegewezen aan beschikbare knooppunten via een best-effort-benadering voor een gelijkmatige distributie. Hoewel een gelijkmatige distributie niet wordt gegarandeerd, zorgt het platform ervoor dat twee exemplaren van dezelfde app niet op hetzelfde exemplaar worden gehost.

Bewaking

Bewaak het gedrag van toepassingen en krijg toegang tot relevante logboeken en metrische gegevens om ervoor te zorgen dat uw toepassing werkt zoals verwacht.

  • U kunt diagnostische logboekregistratie gebruiken om logboeken op toepassingsniveau en platformniveau op te nemen in Log Analytics, Azure Storage of een hulpprogramma van derden via Azure Event Hubs.

  • Bewaking van toepassingsprestaties met Application Insights biedt uitgebreide inzichten in de prestaties van toepassingen.

  • Bedrijfskritieke toepassingen moeten de mogelijkheid hebben om zichzelf te herstellen als er fouten optreden. Schakel Automatisch herstellen in om beschadigde werkrollen automatisch te recyclen.

  • U moet de juiste statuscontroles gebruiken om alle kritieke downstreamafhankelijkheden te beoordelen, wat helpt om de algehele status te garanderen. U wordt ten zeerste aangeraden de statuscontrole in te schakelen om niet-responsieve werknemers te identificeren.

Implementatie

Als u de standaardlimiet voor exemplaren per App Service plan wilt omzeilen, implementeert u App Service-plannen in meerdere schaaleenheden in één regio. Implementeer App Service plannen in een configuratie van een beschikbaarheidszone om ervoor te zorgen dat werkknooppunten worden verdeeld over zones binnen een regio. Overweeg om een ondersteuningsticket te openen om het maximum aantal werkrollen te verhogen tot tweemaal het aantal exemplaren dat u nodig hebt om de normale piekbelasting te verwerken.

Containerregister

Containerregisters hostinstallatiekopieën die zijn geïmplementeerd in runtime-omgevingen voor containers, zoals AKS. U moet uw containerregisters voor bedrijfskritieke workloads zorgvuldig configureren. Een storing mag geen vertragingen veroorzaken bij het ophalen van installatiekopieën, met name tijdens schaalbewerkingen. De volgende overwegingen en aanbevelingen zijn gericht op Azure Container Registry en verkennen van de afwegingen die zijn gekoppeld aan gecentraliseerde en federatieve implementatiemodellen.

Overwegingen bij het ontwerpen

  • Opmaak. Overweeg het gebruik van een containerregister dat afhankelijk is van de door Docker geleverde indeling en standaarden voor zowel push- als pull-bewerkingen. Deze oplossingen zijn compatibel en grotendeels uitwisselbaar.

  • Implementatiemodel. U kunt het containerregister implementeren als een gecentraliseerde service die wordt gebruikt door meerdere toepassingen binnen uw organisatie. U kunt het ook implementeren als een toegewezen onderdeel voor een specifieke toepassingsworkload.

  • Openbare registers. Containerinstallatiekopieën worden opgeslagen in Docker Hub of andere openbare registers die buiten Azure en een bepaald virtueel netwerk bestaan. Dit is niet noodzakelijkerwijs een probleem, maar het kan leiden tot verschillende problemen die betrekking hebben op de beschikbaarheid van de service, beperking en gegevensexfiltratie. Voor sommige toepassingsscenario's moet u openbare containerinstallatiekopieën repliceren in een privécontainerregister om uitgaand verkeer te beperken, de beschikbaarheid te verhogen of mogelijke beperking te voorkomen.

Ontwerpaanbeveling

  • Gebruik containerregisterexemplaren die zijn toegewezen aan de workload van de toepassing. Vermijd het maken van een afhankelijkheid van een gecentraliseerde service, tenzij de vereisten voor de beschikbaarheid en betrouwbaarheid van de organisatie volledig zijn afgestemd op de toepassing.

    In het aanbevolen basisarchitectuurpatroon zijn containerregisters globale resources met een lange levensduur. Overweeg het gebruik van één globaal containerregister per omgeving. Gebruik bijvoorbeeld een globaal productieregister.

  • Zorg ervoor dat de SLA voor het openbare register is afgestemd op uw betrouwbaarheids- en beveiligingsdoelen. Let vooral op beperkingslimieten voor gebruiksvoorbeelden die afhankelijk zijn van Docker Hub.

  • Geef prioriteit aan Azure Container Registry voor het hosten van containerinstallatiekopieën.

Ontwerpoverwegingen en aanbevelingen voor Azure Container Registry

Deze systeemeigen service biedt een scala aan functies, waaronder geo-replicatie, Microsoft Entra verificatie, geautomatiseerde containerbuilding en patching via Container Registry-taken.

Betrouwbaarheid

Configureer geo-replicatie naar alle implementatieregio's om regionale afhankelijkheden te verwijderen en latentie te optimaliseren. Container Registry ondersteunt hoge beschikbaarheid via geo-replicatie naar meerdere geconfigureerde regio's, wat tolerantie biedt tegen regionale storingen. Als een regio niet meer beschikbaar is, blijven de andere regio's aanvragen voor installatiekopieën verwerken. Wanneer de regio weer online is, wordt containerregister hersteld en worden wijzigingen naar de regio gerepliceerd. Deze mogelijkheid biedt ook registercolocatie binnen elke geconfigureerde regio, waardoor netwerklatentie en kosten voor gegevensoverdracht tussen regio's worden verminderd.

In Azure-regio's die ondersteuning bieden voor beschikbaarheidszones, ondersteunt de Premium Container Registry-laag zoneredundantie om bescherming te bieden tegen zonefouten. De Premium-laag ondersteunt ook privé-eindpunten om onbevoegde toegang tot het register te voorkomen, wat kan leiden tot betrouwbaarheidsproblemen.

Hostinstallatiekopieën dicht bij de verbruikende rekenresources, binnen dezelfde Azure-regio's.

Afbeelding vergrendelen

Afbeeldingen kunnen worden verwijderd, bijvoorbeeld als gevolg van een handmatige fout. Container Registry ondersteunt het vergrendelen van een installatiekopieversie of een opslagplaats om wijzigingen of verwijderingen te voorkomen. Wanneer een eerder geïmplementeerde installatiekopieversie wordt gewijzigd, kunnen implementaties van dezelfde versie verschillende resultaten opleveren voor en na de wijziging.

Als u het Container Registry-exemplaar wilt beveiligen tegen verwijdering, gebruikt u resourcevergrendelingen.

Getagde afbeeldingen

Gelabelde Container Registry-installatiekopieën zijn standaard veranderlijk, wat betekent dat dezelfde tag kan worden gebruikt voor meerdere installatiekopieën die naar het register worden gepusht. In productiescenario's kan dit leiden tot onvoorspelbaar gedrag dat van invloed kan zijn op de uptime van toepassingen.

Identiteits- en toegangsbeheer

Gebruik Microsoft Entra geïntegreerde verificatie om installatiekopieën te pushen en op te halen in plaats van te vertrouwen op toegangssleutels. Schakel voor verbeterde beveiliging het gebruik van de beheerderstoegangssleutel volledig uit.

Serverloze compute

Serverloze computing biedt resources op aanvraag en elimineert de noodzaak om infrastructuur te beheren. De cloudprovider richt automatisch de resources in, schaalt en beheert de resources die nodig zijn om geïmplementeerde toepassingscode uit te voeren. Azure biedt verschillende serverloze rekenplatforms:

  • Azure Functions. Wanneer u Azure Functions gebruikt, wordt toepassingslogica geïmplementeerd als afzonderlijke codeblokken of functies die worden uitgevoerd als reactie op gebeurtenissen, zoals een HTTP-aanvraag of wachtrijbericht. Elke functie wordt zo nodig geschaald om aan de vraag te voldoen.

  • Azure Logic Apps. Logic Apps is het meest geschikt voor het maken en uitvoeren van geautomatiseerde werkstromen die verschillende apps, gegevensbronnen, services en systemen integreren. Net als Azure Functions gebruikt Logic Apps ingebouwde triggers voor gebeurtenisgestuurde verwerking. In plaats van toepassingscode te implementeren, kunt u echter logische apps maken met behulp van een grafische gebruikersinterface die codeblokken zoals voorwaardelijk en lussen ondersteunt.

  • Azure API Management. U kunt API Management gebruiken om API's met verbeterde beveiliging te publiceren, transformeren, onderhouden en bewaken met behulp van de verbruikslaag.

  • Power Apps en Power Automate. Deze hulpprogramma's bieden een ontwikkelervaring met weinig of geen code, met eenvoudige werkstroomlogica en integraties die kunnen worden geconfigureerd via verbindingen in een gebruikersinterface.

Voor bedrijfskritieke toepassingen bieden serverloze technologieën vereenvoudigde ontwikkeling en bewerkingen, die waardevol kunnen zijn voor eenvoudige zakelijke gebruiksvoorbeelden. Deze eenvoud gaat echter ten koste van flexibiliteit in termen van schaalbaarheid, betrouwbaarheid en prestaties, en dat is niet haalbaar voor de meeste bedrijfskritieke toepassingsscenario's.

De volgende secties bevatten ontwerpoverwegingen en aanbevelingen voor het gebruik van Azure Functions en Logic Apps als alternatieve platforms voor niet-kritieke werkstroomscenario's.

Ontwerpoverwegingen en aanbevelingen voor Azure Functions

Bedrijfskritieke workloads hebben kritieke en niet-kritieke systeemstromen. Azure Functions is een haalbare keuze voor stromen die niet dezelfde strenge bedrijfsvereisten hebben als kritieke systeemstromen. Het is zeer geschikt voor gebeurtenisgestuurde stromen met processen met een korte levensduur, omdat functies verschillende bewerkingen uitvoeren die zo snel mogelijk worden uitgevoerd.

Kies een Azure Functions hostingoptie die geschikt is voor de betrouwbaarheidslaag van de toepassing. We raden het Premium-abonnement aan, omdat u hiermee de grootte van het rekenproces kunt configureren. Het Dedicated-abonnement is de minst serverloze optie. Het biedt automatische schaalaanpassing, maar deze schaalbewerkingen zijn langzamer dan die van de andere plannen. U wordt aangeraden het Premium-abonnement te gebruiken om de betrouwbaarheid en prestaties te maximaliseren.

Er zijn enkele beveiligingsoverwegingen. Wanneer u een HTTP-trigger gebruikt om een extern eindpunt beschikbaar te maken, gebruikt u een Web Application Firewall (WAF) om een niveau van beveiliging voor het HTTP-eindpunt te bieden tegen algemene externe aanvalsvectoren.

U wordt aangeraden privé-eindpunten te gebruiken om de toegang tot virtuele particuliere netwerken te beperken. Ze kunnen ook risico's voor gegevensexfiltratie beperken, zoals schadelijke beheerscenario's.

U moet hulpprogramma's voor codescans gebruiken voor Azure Functions code en deze hulpprogramma's integreren met CI/CD-pijplijnen.

Ontwerpoverwegingen en aanbevelingen voor Azure Logic Apps

Net als Azure Functions gebruikt Logic Apps ingebouwde triggers voor gebeurtenisgestuurde verwerking. In plaats van toepassingscode te implementeren, kunt u echter logische apps maken met behulp van een grafische gebruikersinterface die ondersteuning biedt voor blokken zoals voorwaardelijk, lussen en andere constructies.

Er zijn meerdere implementatiemodi beschikbaar. We raden de standaardmodus aan om een implementatie met één tenant te garanderen en scenario's met luidruchtige buren te beperken. Deze modus maakt gebruik van de logic apps-runtime met één tenant in een container, die is gebaseerd op Azure Functions. In deze modus kan de logische app meerdere stateful en stateless werkstromen hebben. Houd rekening met de configuratielimieten.

Beperkte migraties via IaaS

Veel toepassingen met bestaande on-premises implementaties maken gebruik van virtualisatietechnologieën en redundante hardware om essentiële niveaus van betrouwbaarheid te bieden. Modernisering wordt vaak belemmerd door zakelijke beperkingen die volledige afstemming met het cloudeigen basislijnarchitectuurpatroon (North Star) verhinderen dat wordt aanbevolen voor bedrijfskritieke workloads. Daarom hanteren veel toepassingen een gefaseerde benadering, met initiële cloudimplementaties met behulp van virtualisatie en Azure Virtual Machines als het primaire model voor het hosten van toepassingen. Het gebruik van virtuele IaaS-machines kan in bepaalde scenario's vereist zijn:

  • Beschikbare PaaS-services bieden niet de vereiste prestaties of het controleniveau.
  • De workload vereist toegang tot het besturingssysteem, specifieke stuurprogramma's of netwerk- en systeemconfiguraties.
  • De workload biedt geen ondersteuning voor het uitvoeren in containers.
  • Er is geen ondersteuning van leveranciers voor workloads van derden.

Deze sectie is gericht op de beste manieren om Azure Virtual Machines en bijbehorende services te gebruiken om de betrouwbaarheid van het toepassingsplatform te maximaliseren. Het belicht de belangrijkste aspecten van de bedrijfskritieke ontwerpmethodologie die cloudeigen en IaaS-migratiescenario's transponeert.

Overwegingen bij het ontwerpen

  • De operationele kosten van het gebruik van virtuele IaaS-machines zijn aanzienlijk hoger dan de kosten van het gebruik van PaaS-services vanwege de beheervereisten van de virtuele machines en de besturingssystemen. Voor het beheren van virtuele machines moeten softwarepakketten en updates regelmatig worden geïmplementeerd.

  • Azure biedt mogelijkheden om de beschikbaarheid van virtuele machines te verhogen:

    • Beschikbaarheidssets kunnen helpen beschermen tegen netwerk-, schijf- en stroomstoringen door virtuele machines te distribueren over foutdomeinen en updatedomeinen.
    • Met beschikbaarheidszones kunt u nog hogere betrouwbaarheidsniveaus bereiken door VM's te distribueren over fysiek gescheiden datacenters binnen een regio.
    • Virtual Machine Scale Sets functionaliteit bieden voor het automatisch schalen van het aantal virtuele machines in een groep. Ze bieden ook mogelijkheden voor het bewaken van de status van exemplaren en het automatisch herstellen van beschadigde exemplaren.

Ontwerpaanbeveling

Belangrijk

Gebruik waar mogelijk PaaS-services en -containers om de operationele complexiteit en kosten te verminderen. Gebruik virtuele IaaS-machines alleen wanneer dat nodig is.

  • De grootte van de VM-SKU's aanpassen om effectief resourcegebruik te garanderen.

  • Implementeer drie of meer virtuele machines in beschikbaarheidszones om fouttolerantie op datacenterniveau te bereiken.

    • Als u commerciële off-the-shelf software implementeert, raadpleegt u de softwareleverancier en test u de software adequaat voordat u de software in productie implementeert.

  • Voor workloads die niet kunnen worden geïmplementeerd in beschikbaarheidszones, gebruikt u beschikbaarheidssets die drie of meer VM's bevatten.

    • Overweeg beschikbaarheidssets alleen als beschikbaarheidszones niet voldoen aan de workloadvereisten, zoals voor spraakmakende workloads met vereisten met lage latentie.

  • Geef prioriteit aan het gebruik van Virtual Machine Scale Sets voor schaalbaarheid en zoneredundantie. Dit punt is met name belangrijk voor workloads met verschillende belastingen. Bijvoorbeeld als het aantal actieve gebruikers of aanvragen per seconde een wisselende belasting is.

  • U hebt niet rechtstreeks toegang tot afzonderlijke virtuele machines. Gebruik indien mogelijk load balancers vóór de load balancers.

  • Als u zich wilt beschermen tegen regionale storingen, implementeert u toepassings-VM's in meerdere Azure-regio's.

  • Voor workloads die geen ondersteuning bieden voor actieve/actieve implementaties in meerdere regio's, kunt u overwegen actieve/passieve implementaties te implementeren met behulp van dynamische/warme stand-by-vm's voor regionale failover.

  • Gebruik standaardinstallatiekopieën van Azure Marketplace in plaats van aangepaste installatiekopieën die moeten worden onderhouden.

  • Implementeer geautomatiseerde processen voor het implementeren en implementeren van wijzigingen op virtuele machines, waarbij handmatige interventie wordt vermeden. Zie IaaS-overwegingen in het ontwerpgebied Operationele procedures voor meer informatie.

  • Implementeer chaos-experimenten om toepassingsfouten in onderdelen van virtuele machines te injecteren en de beperking van fouten te observeren. Zie Continue validatie en testen voor meer informatie.

  • Bewaak virtuele machines en zorg ervoor dat diagnostische logboeken en metrische gegevens worden opgenomen in een geïntegreerde gegevenssink.

  • Implementeer beveiligingsprocedures voor essentiële toepassingsscenario's, indien van toepassing, en de aanbevolen beveiligingsprocedures voor IaaS-workloads in Azure.

Volgende stap

Bekijk de overwegingen voor het gegevensplatform.

Gegevensplatform