Delen via

Overwegingen voor toepassingsplatforms voor bedrijfskritieke workloads in Azure

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. We raden ook aan dat u zich vertrouwd maakt met de Compute-beslissingsstructuur.

Belangrijk

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

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, overweeg dan hoe middelen optimaal worden verdeeld of gerepliceerd over Azure-regio's.

Andere middelen worden regionaal ingezet. 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 that shows a mission-critical architecture.Diagram met een bedrijfskritieke architectuur.

Voor de missiekritische 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 compromissen om tot een optimale ontwerpbeslissing te komen. Voor bepaalde toepassingsscenario's met lagere betrouwbaarheidsdoelen kunnen actieve/passieve of sharding geschikte alternatieven zijn.

Beschikbaarheidszones kunnen hoog beschikbare regionale implementaties bieden via 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 in elke regio beschikbaar.

  • Regiokoppels. Azure-regio's worden gegroepeerd in regionale paren, die uit twee regio's in dezelfde geografische locatie bestaan. 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 Azure Safe Deployment Practice (SDP)-framework zorgt ervoor dat alle code- en configuratiewijzigingen (gepland onderhoud) in het Azure-platform een gefaseerde implementatie ondergaan. Gezondheid wordt geanalyseerd op degradatie tijdens de release. Nadat kanarie- en testfasen succesvol zijn voltooid, worden platformupdates geserialiseerd over regionale paren, zodat er tegelijkertijd slechts één regio in elk paar wordt 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 multiregiodoelen 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.

  • Plaats geografisch Azure-resources dichter bij gebruikers om de netwerklatentie te minimaliseren en de end-to-end prestaties 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 containerimages vooraf zijn gebouwd, kunt u het opstarten beperken tot alleen tijdens de initialisatie van de toepassing, wat snelle schaalbaarheid biedt.

Ontwerpoverwegingen

  • Bewaking. Het kan moeilijk zijn voor monitoringsdiensten om toegang te krijgen 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

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

  • Geef waar mogelijk prioriteit aan op Linux gebaseerde containerruntimes. De afbeeldingen zijn lichter en nieuwe functies voor Linux-knooppunten/containers worden regelmatig uitgebracht.

  • Maak containers onveranderbaar en vervangbaar, met korte levenscycluss.

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

  • Containerafbeeldingen opslaan in Azure Container Registry. Gebruik geo-replicatie om containerafbeeldingen in alle regio's te repliceren. Schakel Microsoft Defender voor containerregisters in om kwetsbaarhedenscanning te bieden voor containerafbeeldingen. Zorg ervoor dat de toegang tot het register wordt beheerd door Microsoft Entra ID.

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

Afhankelijk van uw vereisten moeten Azure Kubernetes Service (AKS) en Azure Container Apps een van uw eerste keuzes zijn voor containerbeheer. 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 schaaleenheid om de betrouwbaarheid en beschikbaarheid te maximaliseren. Gebruik beschikbaarheidszones om de veerkracht binnen een Azure-regio te maximaliseren door het AKS-controlevlak en agentknooppunten te distribueren over fysiek gescheiden datacenters. Echter, als colocatielatentie een probleem is, kunt u de AKS-implementatie in één zone uitvoeren of nabijheidsplaatsingsgroepen gebruiken om de latentie tussen knooppunten te minimaliseren.

  • Gebruik de AKS Uptime SLA voor productieclusters om garanties voor de beschikbaarheid van 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 vormen, maakt u gebruik van de strategie voor schaaleenheden en implementeert u meer eenheden door middel van clusters.

  • Schakel cluster autoscaler in om het aantal agentknooppunten automatisch aan te passen als reactie op resourcebeperkingen.

  • Gebruik de horizontale automatische schaler van pods om het aantal pods in een deployment aan te passen op basis van het CPU-gebruik of andere meetgegevens.

  • Voor scenario's met grote schaal en piekbelasting kunt u overwegen om virtuele knooppunten te gebruiken voor het uitgebreid en snel opschalen.

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

Isolatie

Handhaaf grenzen tussen de infrastructuur die wordt gebruikt door de werklast en systeemhulpprogramma's. Het delen van infrastructuur kan leiden tot hoog resourcegebruik en lawaaierige scenario's.

  • Gebruik afzonderlijke knooppuntgroepen voor systeem- en workloadservices. Toegewijde knooppuntgroepen voor workloadonderdelen moeten gebaseerd zijn op vereisten voor gespecialiseerde infrastructuurresources, zoals GPU-VM's met veel 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 standaard verschillende beveiligingsrisico's. Functies zijn onder andere privéclusters, auditing en logregistratie in Log Analytics, beveiligde knooppuntinstallatiekopieën en beheerde identiteiten.

  • Volg de configuratierichtlijnen 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.

  • Gebruik de Microsoft Entra-integratie voor het gecentraliseerd beheer van accounts en wachtwoorden, het beheer van toegang tot applicaties, en verbeterde identiteitsbescherming. Gebruik Kubernetes RBAC met Microsoft Entra ID voor minste bevoegdheden, en minimaliseer het verstrekken van beheerdersbevoegdheden om te helpen de toegang tot configuratie en geheimen te beschermen. Beperk ook de toegang tot het Kubernetes-clusterconfiguratiebestand met behulp van rolgebaseerde toegangscontrole van Azure. Beperk de toegang tot acties die containers kunnen uitvoeren, verleen het minimale aantal machtigingen en vermijd het gebruik van root privilege-escalatie.

Verbeteringen

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 release-opmerkingen op GitHub om op de hoogte te blijven van toekomstige wijzigingen, verbeteringen en, vooral, het releasen van versies en afschaffingen van Kubernetes.

  • Wees bewust van de verschillende door AKS ondersteunde methoden voor het bijwerken van knooppunten en/of clusters. Deze methoden kunnen handmatig of geautomatiseerd zijn. U kunt "Gepland Onderhoud" gebruiken om onderhoudsperiodes 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 knooppuntafbeeldingen 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. Azure ondersteunt kubenet, Azure CNI en uw eigen CNI 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 mogelijk om Azure of Calico netwerkbeleid te gebruiken voor het beheersen van verkeer binnen het cluster.

Controleren

Uw bewakingshulpprogramma's moeten logboeken en metrische gegevens kunnen vastleggen van draaiende 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 metriek, logboeken en diagnostische gegevens van AKS-resources te verzamelen voor troubleshooting.

  • Schakel Kubernetes-resourcelogboeken in en controleer ze.

  • Configureer Prometheus-metrics in Azure Monitor. Container insights in Monitor biedt onboarding, verleent rechtstreeks bewakingsmogelijkheden en maakt meer geavanceerde mogelijkheden mogelijk via ingebouwde Prometheus-ondersteunende functies.

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 aan pods worden verleend en controleer of het gebruik in strijd is met het beleid door Azure Policy te gebruiken. Deze toegang wordt gedefinieerd via ingebouwd beleid dat wordt geleverd door de Azure Policy-invoegtoepassing voor AKS.

  • Stel een consistente basislijn voor betrouwbaarheid en beveiliging in voor AKS-cluster- en pod-configuraties met behulp van Azure Policy.

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

Notitie

Wanneer u een Azure-landingszone implementeert, zorgt de implementatie van de landingszone voor de Azure-beleidsregels die consistente betrouwbaarheid en beveiliging waarborgen.

De missie-kritische referentie-implementaties bieden een reeks basisbeleidsregels om aanbevolen configuraties voor betrouwbaarheid en veiligheid te bevorderen.

Ontwerpoverwegingen en aanbevelingen voor Azure-app Service

Voor web- en API-gebaseerde workloadscenario's kan App Service mogelijk een haalbaar alternatief voor AKS zijn. Het biedt een containerplatform met lage wrijving zonder de complexiteit van Kubernetes. Voor een volledige set aanbevelingen, zie Betrouwbaarheidsoverwegingen voor App Service en Operationele uitmuntendheid voor App Service.

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 codepraktijken die u kunt gebruiken, zijn verbindingspooling en het uitgestelde laden van resources.

Uitputting van TCP-poort is een ander foutscenario. Dit gebeurt wanneer de som van uitgaande verbindingen van een bepaalde werkkracht de capaciteit overschrijdt. Het aantal beschikbare TCP-poorten hangt af van de grootte van de worker. 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 per-app schaalinstellingen voor high-density hosting op App Service.

  • Houd er rekening mee dat App Service een standaard, zachte limiet van instanties 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 uitschaal- en inschaalregels om ervoor te zorgen dat automatische schaalvergroting actie kan ondernemen om zowel uit te schalen als in te schalen. Begrijp 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 Auto Heal in om ongezonde werkprocessen automatisch te recyclen.

  • U moet de juiste gezondheidscontroles gebruiken om alle kritieke downstreamafhankelijkheden te evalueren, wat helpt om de algehele gezondheid 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 beschikbaarheidszoneconfiguratie om ervoor te zorgen dat werkknooppunten over zones binnen een regio worden verdeeld. U kunt een supportaanvraag indienen om het maximale aantal medewerkers te verhogen tot tweemaal het aantal instanties dat u nodig hebt om de normale piekbelastingen te kunnen verwerken.

Containerregistratie

Containerregisters hosten afbeeldingen die worden ingezet in containerruntime-omgevingen zoals AKS. U moet uw containerregisters zorgvuldig configureren voor bedrijfskritieke workloads. Een storing mag geen vertragingen veroorzaken bij het ophalen van images, met name tijdens schaalvergrotingen. 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. Containerafbeeldingen worden opgeslagen in Docker Hub of andere openbare registers die buiten Azure en een specifiek 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 containerafbeeldingen in een privé containerregister repliceren om uitgaand verkeer te beperken, de beschikbaarheid te verhogen of mogelijke throttling 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 meegaan. 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.

  • Prioriteer Azure Container Registry voor het hosten van containerbeelden.

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 door middel van geo-replicatie naar meerdere geconfigureerde regio's, waardoor veerkracht tegen regionale storingen wordt geboden. 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 beschikbaarheidszoneondersteuning bieden, zorgt de Premium Container Registry-laag met zoneredundantie voor bescherming 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 afbeelding of een repository om wijzigingen of verwijderingen te voorkomen. Wanneer een eerder geïmplementeerde installatiekopieversie ter plaatse wordt gewijzigd, kunnen implementaties van dezelfde versie verschillende resultaten leveren, afhankelijk van of ze voor of na de wijziging worden uitgevoerd.

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

Getagde afbeeldingen

Tagged Container Registry-images zijn standaard veranderlijk, wat betekent dat dezelfde tag kan worden gebruikt voor meerdere images die naar de registry 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 images te uploaden en downloaden in plaats van te vertrouwen op toegangssleutels. Voor verbeterde beveiliging schakelt u het gebruik van de toegangssleutel voor beheerders volledig uit.

Serverloze computing

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 verbeterde beveiligings-API's 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 het betrouwbaarheidsniveau van de applicatie. 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.

Meerdere implementatiemodi zijn 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 werkstromen hebben, zowel stateful als stateless. 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:

    • Beschikbaarheidszones kunnen u helpen om nog hogere betrouwbaarheidsniveaus te bereiken door VM's te distribueren over fysiek gescheiden datacenters binnen een gebied.
    • 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 gezondheid van exemplaren en het automatisch herstellen van ongezonde exemplaren.
    • Schaalsets met flexibele orchestratie kunnen helpen beschermen tegen netwerk-, schijf- en stroomstoringen door vm's automatisch over foutdomeinen te verspreiden.

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 optimaliseren om effectief gebruik van resources te garanderen.

  • Implementeer drie of meer VM's in beschikbaarheidszones om een fouttolerantie op datacenterniveau te realiseren.

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

  • Gebruik voor workloads die u niet in beschikbaarheidszones kunt implementeren, flexibele virtuele machineschaalsets die drie of meer VM's bevatten. Voor meer informatie over het configureren van het juiste aantal foutdomeinen, zie Foutdomeinen beheren in schaalsets.

  • 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 wisselende belasting vormt.

  • Benader afzonderlijke VM's niet rechtstreeks. Gebruik indien mogelijk load balancers aan de voorkant ervan.

  • 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 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. Voor meer informatie, zie Continue validatie en testen.

  • Bewaak virtuele machines en zorg ervoor dat diagnostische logboeken en meetwaarden worden doorgestuurd naar een unificated gegevensopslag.

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

Volgende stap

Bekijk de overwegingen voor het gegevensplatform.

Gegevensplatform