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. U wordt aangeraden services te kiezen op basis van:

  • Niet-functionele vereisten voor betrouwbaarheid, beschikbaarheid, prestaties en beveiliging.
  • Beslissingsfactoren zoals schaalbaarheid, kosten, operabiliteit 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 in containers geplaatste toepassingen. Deze beperking heeft invloed op uw keuze voor het rekenplatform.

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

Dit ontwerpgebied bevat aanbevelingen met betrekking tot rekenselectie, ontwerp en configuratieopties. U wordt ook aangeraden vertrouwd te raken met de beslissingsstructuur Compute.

Belangrijk

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

Wereldwijde distributie van platformbronnen

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

Azure-services, die niet zijn beperkt tot een bepaalde Azure-regio, worden geïmplementeerd of geconfigureerd als globale resources. Sommige gebruiksvoorbeelden omvatten 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 architectuur voor schaaleenheden als wereldwijde distributie nodig hebt, kunt 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 meestal 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 heeft toegang tot de toepassing via een centraal globaal toegangspunt dat vervolgens aanvragen omleidt naar een geschikte regionale implementatiestempel:

Diagram met een bedrijfskritieke architectuur.

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

Niet elke workload ondersteunt of vereist dat meerdere regio's tegelijk worden uitgevoerd. 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 over meerdere zones beschikt en bestand is tegen een zonestoring. Deze configuraties bieden fouttolerantie tot het niveau van het datacenter.

Ontwerpoverwegingen

  • 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 beschikbaar in elke regio.

  • Regionale paren. Azure-regio's worden gegroepeerd in regionale paren die bestaan uit twee regio's in één geografie. Sommige Azure-services maken gebruik van gekoppelde regio's om bedrijfscontinuïteit te garanderen en om een niveau van beveiliging tegen gegevensverlies te bieden. Met azure geografisch redundante opslag (GRS) worden gegevens bijvoorbeeld automatisch gerepliceerd 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) in het Azure-platform een gefaseerde implementatie ondergaan. De status wordt geanalyseerd op degradatie tijdens de release. Nadat kanarie- en testfasen zijn voltooid, worden platformupdates geserialiseerd tussen regionale paren, dus er wordt op een bepaald moment slechts één regio in elk paar bijgewerkt.

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

Ontwerpaanaanvelingen

  • 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 nodig heeft. De mogelijkheden moeten voldoen aan prestatie- en beschikbaarheidsdoelen terwijl aan de vereisten voor gegevenslocatie en retentie wordt voldaan.

    Sommige vereisten voor gegevensnaleving kunnen bijvoorbeeld het aantal beschikbare regio's beperken en mogelijk ontwerpcompromittties afdwingen. In dergelijke gevallen raden we u ten zeerste aan extra investeringen toe te voegen in operationele wrappers om fouten te voorspellen, te detecteren en erop te reageren. Stel dat u beperkt bent tot een geografie met twee regio's en dat slechts één van deze regio's beschikbaarheidszones ondersteunt (3 + 1 datacentermodel). Maak een secundair implementatiepatroon met behulp van isolatie van foutdomeinen, 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 alle mogelijkheden bieden die u nodig hebt, moet u zich voorbereiden 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 een risico te beperken en gebruikt u beschikbaarheidszones om fouttolerantie op datacenterniveau te bieden. Een dergelijk aanzienlijk compromis in geografische distributie beperkt echter de haalbare samengestelde SLO en de algehele betrouwbaarheid aanzienlijk.

    Belangrijk

    Voor scenario's die zijn gericht op een SLO die groter is dan of gelijk is aan 99,99%, raden we minimaal drie implementatieregio's aan. Bereken de samengestelde SLO voor alle gebruikersstromen. Zorg ervoor dat deze doelen zijn afgestemd op bedrijfsdoelen.

  • Voor grootschalige toepassingsscenario's met aanzienlijke hoeveelheden verkeer ontwerpt u de oplossing om in meerdere regio's te schalen om potentiële capaciteitsbeperkingen binnen één regio te navigeren. Aanvullende regionale implementatiestempels kunnen een hogere samengestelde SLO bereiken. Zie voor meer informatie hoe u doelen voor meerdere regio's implementeert.

  • Definieer en valideer uw beoogde herstelpunten (RPO) en beoogde hersteltijd (RTO).

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

  • Geografisch colocate Azure-resources met gebruikers om de netwerklatentie te minimaliseren en end-to-endprestaties te maximaliseren.

  • Lijn de huidige beschikbaarheid van services af met productroadmaps wanneer u implementatieregio's kiest. Sommige services zijn mogelijk niet direct beschikbaar in elke regio.

Containervorming

Een container bevat toepassingscode en de gerelateerde configuratiebestanden, bibliotheken en afhankelijkheden die de toepassing moet uitvoeren. Containerisatie biedt een abstractielaag voor toepassingscode en de bijbehorende afhankelijkheden en maakt scheiding van het onderliggende hostingplatform. Het pakket met één software 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 over verschillende besturingssystemen, ongeacht runtimes of bibliotheekversies. 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 het opstarten van de toepassing, wat snelle schaalbaarheid biedt.

Ontwerpoverwegingen

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

  • Beveiliging. De kernel van het hostplatform-besturingssysteem wordt gedeeld tussen meerdere containers, waardoor er één aanvalspunt ontstaat. Het risico op toegang tot virtuele machines (VM's) van de host is echter beperkt omdat containers worden geïsoleerd van het onderliggende besturingssysteem.

  • Staat. 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. Bewaar in plaats daarvan gegevens door externe opslag te koppelen of door een externe database te gebruiken.

Ontwerpaanaanvelingen

Containerhosting en indeling

Verschillende Azure-toepassingsplatforms kunnen containers effectief hosten. Er zijn voor- en nadelen gekoppeld aan elk van deze platforms. Vergelijk de opties in de context van uw zakelijke vereisten. Optimaliseer echter altijd de betrouwbaarheid, schaalbaarheid en prestaties. Lees deze artikelen voor meer informatie:

Belangrijk

Azure Kubernetes Service (AKS) en Azure Container Apps moeten een van uw eerste keuzes zijn 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 dat complexe clusterbeheeractiviteiten nodig zijn 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 hiervan zijn de keuze tussen openbare en persoonlijke 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 distribueren in fysiek afzonderlijke datacenters. Als colocatielatentie echter een probleem is, kunt u AKS-implementatie in één zone uitvoeren of nabijheidsplaatsingsgroepen gebruiken om 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.

  • Als schaallimieten een beperking zijn, profiteert u van de strategie voor schaaleenheden en implementeert u meer eenheden met clusters.

  • Schakel automatische schaalaanpassing van clusters in om het aantal agentknooppunten automatisch aan te passen als reactie op resourcebeperkingen.

  • Gebruik de horizontale automatische schaalaanpassing van pods om het aantal pods in een implementatie aan te passen op basis van het CPU-gebruik of andere metrische gegevens.

  • Voor scenario's met hoge schaal en burst kunt u overwegen om virtuele knooppunten te gebruiken voor uitgebreide en snelle schaal.

  • Definieer podresourceaanvragen en -limieten in toepassingsimplementatiemanifesten. Als u dat niet doet, kunnen er prestatieproblemen optreden.

Isolatie

Houd grenzen tussen de infrastructuur die wordt gebruikt door de werkbelasting en systeemhulpprogramma's. Het delen van infrastructuur kan leiden tot hoog resourcegebruik en lawaaierige 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 moet u voorkomen dat u grote aantallen knooppuntgroepen implementeert om onnodige beheeroverhead te verminderen.

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

  • Evalueer toepassingsaffiniteit en antiaffiniteitsvereisten en configureer de juiste colocatie van containers op knooppunten.

Beveiliging

Standaard vanille Kubernetes vereist een aanzienlijke configuratie om een geschikt beveiligingspostuur te garanderen voor bedrijfskritieke scenario's. AKS behandelt verschillende beveiligingsrisico's uit de doos. 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 verwerken 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 roulatie van referenties te voorkomen. U kunt beheerde identiteiten toevoegen op clusterniveau. Op podniveau kunt u beheerde identiteiten gebruiken via Microsoft Entra Workload-ID.

  • Microsoft Entra-integratie gebruiken voor gecentraliseerd accountbeheer en wachtwoorden, toegangsbeheer voor toepassingen en verbeterde identiteitsbeveiliging. Gebruik Kubernetes RBAC met Microsoft Entra ID voor minimale bevoegdheden en minimaliseer beheerdersbevoegdheden om de toegang tot configuratie en geheimen te beveiligen. Beperk ook de toegang tot het Kubernetes-clusterconfiguratiebestand met behulp van op rollen gebaseerd toegangsbeheer van Azure. Beperk de toegang tot acties die containers kunnen uitvoeren, geef het minste aantal machtigingen op en vermijd het gebruik van escalatie van hoofdbevoegdheden.

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 opmerkingen bij de release op GitHub om op de hoogte te blijven van toekomstige wijzigingen, verbeteringen en, vooral, kubernetes-versiereleases en -afschaffingen.

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

  • 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 afbeeldingen worden wekelijks uitgebracht. AKS ondersteunt ook automatische upgradekanalen 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 over verkeer tussen pods nodig hebt. ondersteuning voor Azure s kubenet, Azure CNI en uw eigen CNI gebruiken voor specifieke gebruiksvoorbeelden.

Prioriter 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.

Controleren

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

  • Gebruik Azure Monitor en Application Insights om metrische gegevens, logboeken en diagnostische gegevens van AKS-resources te verzamelen voor probleemoplossing.

  • Kubernetes-resourcelogboeken inschakelen en controleren.

  • Configureer metrische prometheus-gegevens in Azure Monitor. Container insights in Monitor biedt onboarding, maakt bewakingsmogelijkheden out-of-the-box mogelijk en maakt geavanceerdere mogelijkheden mogelijk via ingebouwde Prometheus-ondersteuning.

Beheer

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

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

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

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

Notitie

Wanneer u implementeert in een Azure-landingszone, worden de Azure-beleidsregels gebruikt om ervoor te zorgen dat er consistente betrouwbaarheid en beveiliging worden geboden door de implementatie van de landingszone.

De essentiële referentie-implementaties bieden een reeks 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 overwegingen voor betrouwbaarheid voor App Service en operationele uitmuntendheid voor App Service voor een volledige set 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 voorspellen door belastingstests te testen tijdens het gebruik van Azure Diagnostics om poorten te bewaken. Als er SNAT-fouten optreden, moet u schalen over meer of grotere werkrollen of coderingsprocedures implementeren om SNAT-poorten te behouden en opnieuw te gebruiken. Voorbeelden van coderingsprocedures die u kunt gebruiken, zijn verbindingspooling en het luie laden van resources.

Uitputting van TCP-poort 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 groei van toepassingen, zodat u vanaf het begin passende aanbevelingen kunt toepassen. Door dit te doen, kunt u technische migratieschuld vermijden naarmate de oplossing groeit.

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

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

  • Regels voor automatisch schalen toepassen. Een App Service-plan wordt uitgeschaald als aan een regel binnen het profiel wordt voldaan, maar alleen wordt ingeschaald als aan alle regels binnen het profiel wordt voldaan. Gebruik een combinatie van uitschalen en inschalen om ervoor te zorgen dat automatisch schalen actie kan ondernemen om zowel uit te schalen als in te schalen. Meer informatie over 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 van het App Service-plan dat als host fungeert, kan worden geschaald. 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 worden gehost op hetzelfde exemplaar.

Controleren

Bewaak het toepassingsgedrag 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 zijn. Schakel Automatisch herstellen in om beschadigde werknemers automatisch te recyclen.

  • U moet de juiste statuscontroles gebruiken om alle kritieke downstreamafhankelijkheden te evalueren, wat helpt om de algehele status te waarborgen. We raden u ten zeerste aan health check in te schakelen om niet-responsieve werknemers te identificeren.

Implementatie

Als u de standaardlimiet van 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. U kunt een ondersteuningsticket 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 containerruntime-omgevingen, zoals AKS. U moet uw containerregisters zorgvuldig configureren voor bedrijfskritieke workloads. 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 de afwegingen die zijn gekoppeld aan gecentraliseerde en federatieve implementatiemodellen.

Ontwerpoverwegingen

  • Opmaak. Overweeg het gebruik van een containerregister dat afhankelijk is van de door Docker geleverde indeling en standaarden voor push- en pull-bewerkingen. Deze oplossingen zijn compatibel en voornamelijk 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 dit kan leiden tot verschillende problemen met betrekking tot de beschikbaarheid, beperking en exfiltratie van gegevens. Voor sommige toepassingsscenario's moet u openbare containerinstallatiekopieën in een privécontainerregister repliceren om uitgaand verkeer te beperken, de beschikbaarheid te verhogen of mogelijke beperking te voorkomen.

Ontwerpaanaanvelingen

  • Gebruik containerregisterexemplaren die zijn toegewezen aan de toepassingsworkload. Vermijd het maken van een afhankelijkheid van een gecentraliseerde service, tenzij organisatiebeschikbaarheid en betrouwbaarheidsvereisten volledig zijn afgestemd op de toepassing.

    In het aanbevolen kernarchitectuurpatroon zijn containerregisters globale resources die lang leven. Overweeg om één globaal containerregister per omgeving te gebruiken. Gebruik bijvoorbeeld een globaal productieregister.

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

  • Azure Container Registry prioriteren 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 containerbouw 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 afbeeldingsaanvragen verwerken. Wanneer de regio weer online is, worden wijzigingen in Container Registry hersteld en 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.

Afbeeldingsvergrendeling

Afbeeldingen kunnen worden verwijderd, bijvoorbeeld als gevolg van een handmatige fout. Container Registry ondersteunt het vergrendelen van een versie van een installatiekopie of een opslagplaats om wijzigingen of verwijderingen te voorkomen. Wanneer een eerder geïmplementeerde installatiekopieversie wordt gewijzigd, kunnen implementaties van dezelfde versie verschillende resultaten bieden 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 kunnen standaard worden gedempt, 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 geïntegreerde Microsoft Entra-verificatie om installatiekopieën te pushen en op te halen in plaats van te vertrouwen op toegangssleutels. Voor verbeterde beveiliging schakelt u het gebruik van de toegangssleutel voor beheerders 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 die nodig zijn om geïmplementeerde toepassingscode uit te voeren, te schalen en te beheren. 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 maakt Logic Apps gebruik van 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 ondersteunt, zoals voorwaardelijke voorwaarden en lussen.

  • Azure API Management. U kunt API Management gebruiken om API Management 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, wat waardevol kan zijn voor eenvoudige bedrijfsgebruiksscenario's. Deze eenvoud komt 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 platformen 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 die kortstondige processen hebben, 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 beveiligingsniveau voor het HTTP-eindpunt te bieden van algemene externe aanvalsvectoren.

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

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

Ontwerpoverwegingen en aanbevelingen voor Azure Logic Apps

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

Er zijn meerdere implementatiemodi beschikbaar. We raden de standaardmodus aan om een implementatie met één tenant te garanderen en scenario's met ruis te beperken. In deze modus wordt gebruikgemaakt van de Logic Apps-runtime met één tenant, die is gebaseerd op Azure Functions. In deze modus kan de logische app meerdere stateful en stateless werkstromen hebben. U moet rekening houden met de configuratielimieten.

Beperkte migraties via IaaS

Veel toepassingen met bestaande on-premises implementaties maken gebruik van virtualisatietechnologieën en redundante hardware om bedrijfskritieke betrouwbaarheidsniveaus te bieden. Modernisering wordt vaak belemmerd door zakelijke beperkingen die volledige afstemming met het cloudeigen basislijnarchitectuurpatroon (North Star) voorkomen dat wordt aanbevolen voor bedrijfskritieke workloads. Daarom gebruiken 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 IaaS-VM's (Infrastructure as a Service) is mogelijk vereist in bepaalde scenario's:

  • Beschikbare PaaS-services bieden niet de vereiste prestaties of het vereiste beheerniveau.
  • 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 leverancierondersteuning voor workloads van derden.

Deze sectie is gericht op de beste manieren om virtuele machines en bijbehorende services te gebruiken om de betrouwbaarheid van het toepassingsplatform te maximaliseren. Het markeert belangrijke aspecten van de bedrijfskritieke ontwerpmethodologie die cloudeigen en IaaS-migratiescenario's transponeert.

Ontwerpoverwegingen

  • De operationele kosten voor het gebruik van IaaS-VM's zijn aanzienlijk hoger dan de kosten voor het gebruik van PaaS-services vanwege de beheervereisten van de VM's en de besturingssystemen. Het beheren van VM's vereist de frequente implementatie van softwarepakketten en updates.

  • Azure biedt mogelijkheden om de beschikbaarheid van VM's te vergroten:

    • Met beschikbaarheidszones kunt u nog hogere betrouwbaarheidsniveaus bereiken door VM's te distribueren over fysiek gescheiden datacenters binnen een regio.
    • Virtuele-machineschaalsets van Azure bieden functionaliteit 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.
    • Schaalsets met flexibele indeling kunnen helpen beschermen tegen netwerk-, schijf- en stroomstoringen door vm's automatisch over foutdomeinen te distribueren.

Ontwerpaanaanvelingen

Belangrijk

Gebruik Waar mogelijk PaaS-services en -containers om de operationele complexiteit en kosten te verminderen. Gebruik iaaS-VM's alleen wanneer u dat nodig hebt.

  • Vm-SKU-grootten met de juiste grootte om effectief resourcegebruik te garanderen.

  • Implementeer drie of meer VM's 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 u niet in beschikbaarheidszones kunt implementeren, gebruikt u flexibele virtuele-machineschaalsets die drie of meer VM's bevatten. Zie Foutdomeinen beheren in schaalsets voor meer informatie over het configureren van het juiste aantal foutdomeinen.

  • Geef prioriteit aan het gebruik van virtuele-machineschaalsets voor schaalbaarheid en zoneredundantie. Dit punt is met name belangrijk voor workloads met verschillende belastingen. Als het aantal actieve gebruikers of aanvragen per seconde bijvoorbeeld een verschillende belasting is.

  • Toegang krijgen tot afzonderlijke VM's niet rechtstreeks. Gebruik indien mogelijk load balancers voor de load balancers.

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

    • Zie het ontwerpgebied voor netwerken en connectiviteit voor meer informatie over het optimaal routeren van verkeer tussen actieve implementatieregio'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 om wijzigingen in VM's te implementeren en uit te rollen, waardoor handmatige interventie wordt voorkomen. Zie IaaS-overwegingen in het ontwerpgebied Operationele procedures voor meer informatie.

  • Implementeer chaosexperimenten om toepassingsfouten in VM-onderdelen te injecteren en bekijk de beperking van fouten. Zie Continue validatie en testen voor meer informatie.

  • Bewaak VM's en zorg ervoor dat diagnostische logboeken en metrische gegevens worden opgenomen in een geïntegreerde gegevenssink.

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

Volgende stap

Bekijk de overwegingen voor het gegevensplatform.

Gegevensplatform