Basislijnarchitectuur van Azure Virtual Machines

Dit artikel bevat een fundamentele referentiearchitectuur voor een workload die is geïmplementeerd op virtuele Azure-machines.

De voorbeeldworkload die door deze architectuur wordt aangenomen, is een internetgerichte webtoepassing met meerdere lagen die wordt geïmplementeerd op afzonderlijke sets virtuele machines (VM's). VM's worden ingericht als onderdeel van azure Virtual Machine Scale Sets-implementaties. Deze architectuur kan worden gebruikt voor deze scenario's:

• Privétoepassingen. Deze toepassingen omvatten interne Line-Of-Business-toepassingen of commerciële off-the-shelf oplossingen.
• Openbare toepassingen. Deze toepassingen zijn internetgerichte toepassingen. Deze architectuur is niet bedoeld voor high-performance computing, bedrijfskritieke workloads, toepassingen die sterk worden beïnvloed door latentie of andere gespecialiseerde use cases.

De primaire focus van deze architectuur is niet de toepassing. In plaats daarvan biedt dit artikel richtlijnen voor het configureren en implementeren van de infrastructuuronderdelen waarmee de toepassing communiceert. Deze onderdelen omvatten reken-, opslag-, netwerk- en bewakingsonderdelen.

Deze architectuur fungeert als uitgangspunt voor een iaaS-workload (Infrastructure as a Service). De gegevenslaag wordt opzettelijk uitgesloten van deze richtlijnen om de focus op de rekeninfrastructuur te behouden.

Artikelindeling

Architectuur	Ontwerpbeslissing	Goed ontworpen frameworkbenadering
▪ Architectuurdiagram ▪ Workloadresources ▪ Ondersteunende resources ▪ Gebruikersstromen	▪ Keuzen voor VM-ontwerp ▪ Schijven ▪ Networking ▪ Monitoring ▪ Updatebeheer	▪ Betrouwbaarheid ▪ Veiligheid ▪ Kostenoptimalisatie

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Zie de Azure-productdocumentatie die wordt vermeld in gerelateerde resources voor meer informatie over deze resources.

Onderdelen

Deze architectuur bestaat uit verschillende Azure-services voor zowel workloadresources als ondersteunende resources voor workloads. De services voor elk en hun rollen worden beschreven in de volgende secties.

Workloadresources

• Azure Virtual Machines fungeert als de rekenresource voor de toepassing en wordt verdeeld over beschikbaarheidszones. Ter illustratie wordt een combinatie van zowel Windows- als Linux-VM's gebruikt.

  Virtuele-machineschaalsets in de flexibele indelingsmodus van Azure worden gebruikt voor het inrichten en beheren van de VM's.

  De voorbeeldtoepassing kan worden weergegeven in twee lagen, die elk een eigen rekenproces vereisen.

  • De front-end voert de webserver uit en ontvangt gebruikersaanvragen.
  • De back-end voert een andere webserver uit die fungeert als een web-API waarmee één eindpunt wordt weergegeven waarop de bedrijfslogica wordt uitgevoerd.

  Op de front-end-VM's zijn gegevensschijven (Premium_LRS) gekoppeld, die kunnen worden gebruikt om een staatloze toepassing te implementeren. De back-end-VM's behouden gegevens op Premium_ZRS lokale schijven als onderdeel van de bewerking. Deze indeling kan worden uitgebreid met een databaselaag voor het opslaan van de status van de front-end- en back-end-berekening. Deze laag valt buiten het bereik van deze architectuur.

• Azure Virtual Network biedt een particulier netwerk voor alle workloadresources. Het netwerk wordt gesegmenteerd in subnetten, die fungeren als isolatiegrenzen.

• Azure-toepassing Gateway is het single point of ingress waarmee aanvragen worden gerouteerd naar de front-endservers. De geselecteerde SKU bevat geïntegreerde Azure Web Application Firewall (WAF) voor extra beveiliging.

• Interne Azure Load Balancer routeert verkeer van de front-endlaag naar de back-endservers.

• Azure Load Balancer Standard SKU biedt uitgaande internettoegang tot de VM's met behulp van drie openbare IP-adressen.

• Azure Key Vault slaat de certificaten op die worden gebruikt voor end-to-end TLS-communicatie (Transport Layer Security). Het kan ook worden gebruikt voor toepassingsgeheimen.

Workload die resources ondersteunt

• Azure Bastion biedt operationele toegang tot de VM's via beveiligde protocollen.

• Application Insights verzamelt logboeken en metrische gegevens van de toepassing. Omdat de toepassing niet de focus van deze architectuur heeft, wordt logboekverzameling niet gedemonstreerd in de implementatie.

• Log Analytics is de sink voor bewakingsgegevens die logboeken en metrische gegevens verzamelt van de Azure-resources en Application Insights. Een opslagaccount wordt ingericht als onderdeel van de werkruimte.

Gebruikersstromen

Er zijn twee typen gebruikers die interactie hebben met de workloadresources: de workloadgebruiker en -operator. De stromen voor deze gebruikers worden weergegeven in het voorgaande architectuurdiagram.

Workloadgebruiker

1. De gebruiker heeft toegang tot de website met behulp van het weergegeven openbare IP-adres van Application Gateway.

2. Application Gateway ontvangt HTTPS-verkeer, ontsleutelt gegevens met behulp van een extern certificaat voor WAF-inspectie en versleutelt het opnieuw met behulp van het interne jokertekencertificaat voor transport naar de front-end.

3. Application Gateway verwijst naar een front-end-VM en stuurt de aanvraag door naar een front-end-VM.

4. De geselecteerde front-end-VM communiceert met een back-end-VM met behulp van het privé-IP-adres van de load balancer, niet het IP-adres van een afzonderlijke VM. Deze communicatie wordt ook versleuteld met behulp van het interne jokertekencertificaat.

5. De back-end-VM ontsleutelt de aanvraag met behulp van het interne certificaat. Nadat de back-end de aanvraag heeft verwerkt, wordt het resultaat geretourneerd naar de front-end, waarmee het resultaat wordt geretourneerd aan de toepassingsgateway en uiteindelijk het resultaat aan de gebruiker wordt geretourneerd.

Operator

De VM's in deze architectuur vereisen mogelijk directe toegang door operators, maar we raden u aan om externe toegang te minimaliseren via automatisering en dat de toegang wordt bewaakt. De toegang kan betrekking hebben op onderbrekingssituaties, probleemoplossing of onderdeel van een geautomatiseerd implementatieproces. Deze architectuur heeft geen openbare IP-adressen voor toegang tot het besturingsvlak. Azure Bastion fungeert als een serverloze gateway, waardoor bewerkingen toegang hebben tot VM's via SSH of RDP. Deze installatie zorgt voor veilig en efficiënt toegangsbeheer.

1. De operator meldt zich aan bij Azure Portal of Azure CLI.
2. De operator heeft toegang tot de Azure Bastion-service en maakt extern verbinding met de gewenste VM.

Keuzen voor VM-ontwerp

Wanneer u SKU's selecteert, is het belangrijk dat u een basislijnprestatieverwachting hebt. Verschillende kenmerken zijn van invloed op het besluitvormingsproces, waaronder:

• CPU-, geheugen- en schijfinvoer-/uitvoerbewerkingen per seconde (IOPS).
• Processorarchitectuur.
• Grootte van besturingssysteeminstallatiekopieën.

Als u bijvoorbeeld een workload migreert vanuit een on-premises omgeving waarvoor Intel-processormachines zijn vereist, kiest u VM-SKU's die Intel-processors ondersteunen.

Zie Grootten voor virtuele machines in Azure voor informatie over de ondersteunde VM-SKU's.

Bootstrapping

VM's moeten vaak worden opgestart. Dit is een proces waarin VM's worden voorbereid en afgestemd om de toepassing uit te voeren. Veelvoorkomende opstarttaken zijn onder andere het installeren van certificaten, het configureren van externe toegang, het installeren van pakketten, het afstemmen en beveiligen van de configuratie van het besturingssysteem en het opmaken en koppelen van gegevensschijven. Het is belangrijk om het opstartproces zoveel mogelijk te automatiseren, zodat de toepassing zonder vertraging of handmatige interventie kan worden gestart op de virtuele machine. Hier volgen de aanbevelingen voor automatisering:

• Extensies van virtuele machines. Deze extensies zijn Azure Resource Manager-objecten die worden beheerd via uw IaC-implementatie (Infrastructure-as-Code). Op deze manier wordt elke fout gerapporteerd als een mislukte implementatie waarvoor u actie kunt ondernemen. Als er geen extensie is voor uw opstartstrappingsbehoeften, maakt u aangepaste scripts. Het is raadzaam om de scripts uit te voeren via de aangepaste Scriptextensie van Azure.

  Hier volgen enkele andere extensies die kunnen worden gebruikt voor het automatisch installeren of configureren van functionaliteit op de VM's.

  • Azure Monitor Agent (AMA) verzamelt bewakingsgegevens van het gastbesturingssystemen en levert deze aan Azure Monitor.
  • De aangepaste Scriptextensie van Azure (Windows, Linux) versie 2 downloadt en voert scripts uit op virtuele Azure-machines (VM's). Deze extensie is handig voor het automatiseren van configuratie na implementatie, software-installatie of andere configuratie- of beheertaken.
  • Azure Key Vault-extensie voor virtuele machines (Windows, Linux) biedt automatische vernieuwing van certificaten die zijn opgeslagen in een Key Vault door wijzigingen te detecteren en de bijbehorende certificaten te installeren.
  • Toepassingsstatusextensie met virtuele-machineschaalsets is belangrijk wanneer Azure Virtual Machine Scale Sets automatische rolling upgrades uitvoert. Azure is afhankelijk van statuscontrole van de afzonderlijke exemplaren om de updates uit te voeren. U kunt de extensie ook gebruiken om de toepassingsstatus van elk exemplaar in uw schaalset te bewaken en exemplaarreparaties uit te voeren met behulp van automatische exemplaarreparaties.
  • Microsoft Entra ID en OpenSSH (Windows, Linux) kunnen worden geïntegreerd met Microsoft Entra-verificatie. U kunt nu Microsoft Entra ID gebruiken als een basisverificatieplatform en een certificeringsinstantie voor SSH in een Linux-VM met behulp van Microsoft Entra ID en OpenSSH-verificatie op basis van certificaten. Met deze functionaliteit kunt u de toegang tot VM's beheren met op rollen gebaseerd toegangsbeheer (RBAC) van Azure en beleid voor voorwaardelijke toegang.

• Configuratie op basis van agents. Linux-VM's kunnen een lichtgewicht systeemeigen gewenste statusconfiguratie gebruiken die beschikbaar is via cloud-init op verschillende door Azure geleverde VM-installatiekopieën. De configuratie wordt opgegeven en versiebeheer met uw IaC-artefacten. Het meenemen van uw eigen oplossing voor configuratiebeheer is een andere manier. De meeste oplossingen volgen een declaratieve eerste benadering voor bootstrapping, maar bieden wel ondersteuning voor aangepaste scripts voor flexibiliteit. Populaire opties zijn Desired State Configuration voor Windows, Desired State Configuration voor Linux, Ansible, Chef, Puppet en andere. Al deze configuratieoplossingen kunnen worden gekoppeld aan VM-extensies voor een optimale ervaring.

In de referentie-implementatie wordt alle bootstrapping uitgevoerd via VM-extensies en aangepaste scripts, inclusief een aangepast script voor het automatiseren van gegevensschijfopmaak en koppelen.

Raadpleeg Well-Architected Framework: RE:02 - Aanbevelingen voor automatiseringsontwerp.

VM-connectiviteit

Als u privécommunicatie tussen een virtuele machine en andere apparaten in een bepaald virtueel netwerk wilt inschakelen, is de netwerkinterfacekaart (NIC) van de VM verbonden met een van de subnetten van het virtuele netwerk. Als u meerdere NIC's voor uw virtuele machine nodig hebt, moet u weten dat er een maximum aantal NIC's is gedefinieerd voor elke VM-grootte.

Als de werkbelasting communicatie met lage latentie tussen VM's in het virtuele netwerk nodig heeft, kunt u overwegen versneld netwerken te gebruiken, die wordt ondersteund door NIC's van Azure-VM's. Zie Voordelen van versneld netwerken voor meer informatie.

Virtuele-machineschaalsets met flexibele indeling

VM's worden ingericht als onderdeel van virtuele-machineschaalsets met flexibele indeling. Virtuele-machineschaalsets zijn logische groeperingen van VM's die worden gebruikt om te voldoen aan de bedrijfsbehoeften. De typen VM's in een groepering kunnen identiek of verschillend zijn. Hiermee kunt u de levenscyclus van machines, netwerkinterfaces en schijven beheren met behulp van standaard Azure VM-API's en opdrachten.

De flexibele indelingsmodus vereenvoudigt bewerkingen op schaal en helpt bij gedetailleerde schaalbeslissingen.

Configuratie van foutdomein is nodig om het effect van fysieke hardwarestoringen, netwerkstoringen of stroomonderbrekingen te beperken. Met schaalsets verspreidt Azure instanties gelijkmatig over foutdomeinen voor tolerantie tegen één hardware- of infrastructuurprobleem.

We raden u aan foutdomeintoewijzing naar Azure te offloaden voor maximale verspreiding van exemplaren, waardoor de tolerantie en beschikbaarheid worden verbeterd.

Disks

Als u het besturingssysteem en de toepassingsonderdelen wilt uitvoeren, worden opslagschijven gekoppeld aan de virtuele machine. Overweeg het gebruik van tijdelijke schijven voor het besturingssysteem en beheerde schijven voor gegevensopslag.

Azure biedt een scala aan opties op het gebied van prestaties, veelzijdigheid en kosten. Begin met Premium SSD voor de meeste productieworkloads. Uw keuze is afhankelijk van de VM-SKU. SKU's die Premium SSD ondersteunen, bevatten een s in de resourcenaam, bijvoorbeeld Dsv4 , maar niet Dv4.

Zie De vergelijking van schijftypen voor meer informatie over de schijfopties met metrische gegevens, zoals capaciteit, IOPS en doorvoer.

Overweeg schijfkenmerken en prestatieverwachtingen bij het selecteren van een schijf.

• Beperkingen voor VM-SKU's. Schijven werken binnen de VM waaraan ze zijn gekoppeld, met IOPS- en doorvoerlimieten. Zorg ervoor dat de schijf de limieten van de VIRTUELE machine niet beperkt en omgekeerd. Selecteer de schijfgrootte, prestaties en VM-mogelijkheden (kern, CPU, geheugen) die het toepassingsonderdeel optimaal uitvoeren. Vermijd overprovisioning omdat dit van invloed is op de kosten.

• Configuratiewijzigingen. U kunt bepaalde schijfprestaties en capaciteitsconfiguraties wijzigen terwijl een VIRTUELE machine wordt uitgevoerd. Veel wijzigingen kunnen echter vereisen dat de schijfinhoud opnieuw wordt ingericht en opnieuw wordt opgebouwd, wat van invloed is op de beschikbaarheid van workloads. Plan daarom zorgvuldig schijf- en VM-SKU-selectie om de beschikbaarheidsimpact en het opnieuw te bewerken.

• Tijdelijke besturingssysteemschijven. Besturingssysteemschijven inrichten als tijdelijke schijven. Gebruik beheerde schijven alleen als besturingssysteembestanden moeten worden bewaard. Vermijd het gebruik van tijdelijke schijven voor het opslaan van toepassingsonderdelen en -status.

  De capaciteit van tijdelijke besturingssysteemschijven is afhankelijk van de gekozen VM-SKU. Zorg ervoor dat de schijfgrootte van uw besturingssysteeminstallatiekopieën kleiner is dan de beschikbare cache of tijdelijke schijf van de SKU. U kunt de resterende ruimte voor tijdelijke opslag gebruiken.

• Schijfprestaties. Het vooraf inrichten van schijfruimte op basis van piekbelasting is gebruikelijk, maar kan leiden tot onvoldoende gebruikte resources, omdat de meeste workloads geen piekbelasting ondersteunen.

  Bewaak de gebruikspatronen van uw workload, noteer pieken of aanhoudende bewerkingen met hoge leesbewerkingen en factor deze patronen in de selectie van uw VM en beheerde schijf-SKU.

  U kunt de prestaties op aanvraag aanpassen door prestatielagen te wijzigen of door de bursting-functies te gebruiken die worden aangeboden in sommige beheerde schijf-SKU's.

  Hoewel overprovisioning de behoefte aan bursting vermindert, kan dit leiden tot ongebruikte capaciteit waarvoor u betaalt. Combineer in het ideale voorbeeld beide functies voor optimale resultaten.

• Cache voor de workload afstemmen. Cache-instellingen configureren voor alle schijven op basis van het gebruik van toepassingsonderdelen.

  Onderdelen die voornamelijk leesbewerkingen uitvoeren, vereisen geen transactionele consistentie met hoge schijven. Deze onderdelen kunnen profiteren van alleen-lezen caching. Schrijfintensieve onderdelen waarvoor transactionele consistentie met hoge schijven is vereist, hebben vaak caching uitgeschakeld.

  Het gebruik van cache voor lezen/schrijven kan gegevensverlies veroorzaken als de VM vastloopt en niet wordt aanbevolen voor de meeste scenario's met gegevensschijven.

In deze architectuur:

• De besturingssysteemschijven van alle VM's zijn kortstondig en bevinden zich op de cacheschijf.

  De workloadtoepassing in de front-end (Linux) en back-end (Windows Server) zijn tolerant voor afzonderlijke VM-fouten en gebruiken zowel kleine installatiekopieën (ongeveer 30 GB). Dergelijke kenmerken zorgen ervoor dat ze in aanmerking komen voor het gebruik van tijdelijke besturingssysteemschijven die zijn gemaakt als onderdeel van de lokale VM-opslag (cachepartitie) in plaats van permanente besturingssysteemschijf die wordt opgeslagen in externe Azure-opslagresources. Deze situatie leidt tot geen opslagkosten voor besturingssysteemschijven en verbetert ook de prestaties door lagere latenties te bieden en de vm-implementatietijd te verminderen.

• Elke VIRTUELE machine heeft een eigen beheerde Premium SSD P1-schijf en biedt een basisdoorvoer die geschikt is voor de workload.

Netwerkindeling

Met deze architectuur wordt de workload in één virtueel netwerk geïmplementeerd. Netwerkbesturingselementen vormen een belangrijk onderdeel van deze architectuur en worden beschreven in de sectie Beveiliging .

Deze indeling kan worden geïntegreerd met een bedrijfstopologie. Dit voorbeeld wordt weergegeven in de basislijnarchitectuur van virtuele machines in een Azure-landingszone.

Virtueel netwerk

Een van uw eerste beslissingen over de netwerkindeling heeft betrekking op het netwerkadresbereik. Houd rekening met de verwachte netwerkgroei tijdens de fase van capaciteitsplanning. Het netwerk moet groot genoeg zijn om de groei te ondersteunen, die mogelijk extra netwerkconstructies nodig heeft. Het virtuele netwerk moet bijvoorbeeld de capaciteit hebben om te voorzien in de andere VM's die het gevolg zijn van een schaalbewerking.

Daarentegen past u uw adresruimte aan met de juiste grootte. Een overmatig groot virtueel netwerk kan leiden tot onderbezetting. Het is belangrijk om te weten dat nadat het virtuele netwerk is gemaakt, het adresbereik niet kan worden gewijzigd.

In deze architectuur is de adresruimte ingesteld op /21, een beslissing op basis van de verwachte groei.

Overwegingen voor subnetten

Binnen het virtuele netwerk worden subnetten verdeeld op basis van functionaliteit en beveiligingsvereisten, zoals hier wordt beschreven:

• Een subnet voor het hosten van de toepassingsgateway, die fungeert als de omgekeerde proxy. Application Gateway vereist een toegewezen subnet.
• Een subnet voor het hosten van de interne load balancer voor het distribueren van verkeer naar back-end-VM's.
• Subnetten voor het hosten van de workload-VM's, één voor front-end en één voor back-end. Deze subnetten worden gemaakt op basis van de lagen van de toepassing.
• Een subnet voor de Azure Bastion-host om operationele toegang tot de workload-VM's te vergemakkelijken. De Azure Bastion-host heeft standaard een toegewezen subnet nodig.
• Een subnet voor het hosten van privé-eindpunten die zijn gemaakt voor toegang tot andere Azure-resources via Azure Private Link. Hoewel toegewezen subnetten niet verplicht zijn voor deze eindpunten, raden we ze aan.

Net als bij virtuele netwerken moeten subnetten de juiste grootte hebben. U kunt bijvoorbeeld de maximale limiet toepassen van VM's die worden ondersteund door Flexibele indeling om te voldoen aan de schaalbehoeften van de toepassing. De subnetten van de werkbelasting moeten deze limiet kunnen opvangen.

Een ander gebruiksvoorbeeld om rekening mee te houden, is upgrades van HET BEsturingssysteem van vm's, waarvoor mogelijk tijdelijke IP-adressen zijn vereist. Met de juiste grootte krijgt u het gewenste segmentatieniveau door ervoor te zorgen dat vergelijkbare resources worden gegroepeerd, zodat zinvolle beveiligingsregels via netwerkbeveiligingsgroepen (NSG's) kunnen worden toegepast op de subnetgrenzen. Zie Beveiliging: Segmentatie voor meer informatie.

Inkomend verkeer

Er worden twee openbare IP-adressen gebruikt voor inkomend verkeer. Eén adres is voor Application Gateway die fungeert als de omgekeerde proxy. Gebruikers maken verbinding met dat openbare IP-adres. De omgekeerde proxytaakverdeling zorgt voor inkomend verkeer naar de privé-IP-adressen van de VM's. Het andere adres is voor operationele toegang via Azure Bastion.

Een Visio-bestand van deze architectuur downloaden.

Uitgaand verkeer

Deze architectuur maakt gebruik van standaard-SKU Load Balancer met uitgaande regels die zijn gedefinieerd vanuit de VM-exemplaren. Load Balancer is gekozen omdat deze zoneredundant is.

Een Visio-bestand van deze architectuur downloaden.

Met deze configuratie kunt u de openbare IP('s) van uw load balancer gebruiken om uitgaande internetverbinding te bieden voor de VM's. Met de uitgaande regels kunt u expliciet SNAT-poorten (Source Network Address Translation) definiëren. Met de regels kunt u deze mogelijkheid schalen en afstemmen via handmatige poorttoewijzing. Handmatig toewijzen van de SNAT-poort op basis van de grootte van de back-endpool en het aantal kan helpen bij het voorkomen van frontendIPConfigurations SNAT-uitputting.

U wordt aangeraden poorten toe te wijzen op basis van het maximum aantal back-endexemplaren. Als er meer exemplaren worden toegevoegd dan de resterende SNAT-poorten zijn toegestaan, kunnen schaalbewerkingen voor virtuele-machineschaalsets worden geblokkeerd of ontvangen de nieuwe VM's onvoldoende SNAT-poorten.

Poorten per exemplaar berekenen als: Number of front-end IPs * 64K / Maximum number of back-end instances.

Er zijn andere opties die u kunt gebruiken, zoals het implementeren van een Azure NAT Gateway-resource die is gekoppeld aan het subnet. Een andere optie is om Azure Firewall of een ander virtueel netwerkapparaat te gebruiken met een aangepaste door de gebruiker gedefinieerde route (UDR) als de volgende hop via de firewall. Deze optie wordt weergegeven in de basislijnarchitectuur van virtuele machines in een Azure-landingszone.

DNS-resolutie

Azure DNS wordt gebruikt als de basisservice voor alle gebruiksscenario's voor omzetting, bijvoorbeeld het omzetten van FQDN's (Fully Qualified Domain Names) die zijn gekoppeld aan de workload-VM's. In deze architectuur gebruiken de VM's de DNS-waarden die zijn ingesteld in de configuratie van het virtuele netwerk. Dit is Azure DNS.

Privé-DNS-zones van Azure worden gebruikt voor het omzetten van aanvragen voor de privé-eindpunten die worden gebruikt voor toegang tot de benoemde Private Link-resources.

Controleren

Deze architectuur heeft een bewakingsstack die is losgekoppeld van het hulpprogramma van de workload. De focus ligt voornamelijk op de gegevensbronnen en verzamelingsaspecten.

Metrische gegevens en logboeken worden gegenereerd in verschillende gegevensbronnen, waardoor waarneembaarheidsinzichten op verschillende hoogten worden geboden:

• Onderliggende infrastructuur en onderdelen worden overwogen, zoals VM's, virtuele netwerken en opslagservices. Azure-platformlogboeken bieden informatie over bewerkingen en activiteiten binnen het Azure-platform.

• Het toepassingsniveau biedt inzicht in de prestaties en het gedrag van de toepassingen die op uw systeem worden uitgevoerd.

De Log Analytics-werkruimte is de aanbevolen sink voor bewakingsgegevens die wordt gebruikt voor het verzamelen van logboeken en metrische gegevens van de Azure-resources en Application Insights.

In deze afbeelding ziet u de bewakingsstack voor de basislijn met onderdelen voor het verzamelen van gegevens uit de infrastructuur en toepassing, gegevenssinks en verschillende verbruikshulpprogramma's voor analyse en visualisatie. De implementatie implementeert enkele onderdelen, zoals Application Insights, diagnostische gegevens over VM-opstartbewerkingen en Log Analytics. Andere onderdelen worden weergegeven om de uitbreidbaarheidsopties weer te geven, zoals dashboards en waarschuwingen.

Een Visio-bestand van deze architectuur downloaden.

Bewaking op infrastructuurniveau

Deze tabel bevat koppelingen naar logboeken en metrische gegevens die zijn verzameld door Azure Monitor. De beschikbare waarschuwingen helpen u proactief problemen op te lossen voordat ze van invloed zijn op gebruikers.

Azure-resource	Metrische gegevens en logboeken	Waarschuwingen
Application Gateway	Beschrijving van metrische gegevens en logboeken van Application Gateway	Application Gateway-waarschuwingen
Analyses van toepassingen	Metrische gegevens en logboekregistratie-API voor Application Insights	Application Insights-waarschuwingen
Azure Bastion	Metrische gegevens van Azure Bastion
Key Vault	Beschrijvingen van metrische gegevens en logboeken van Key Vault	Key Vault-waarschuwingen
Standard Load Balancer	Load balancer-logboeken en metrische gegevens	Load Balancer-waarschuwingen
Openbaar IP-adres	Beschrijving van metrische gegevens en logboeken van openbaar IP-adres	Waarschuwingen voor metrische gegevens van openbare IP-adressen
Virtual Network	Naslaginformatie over metrische gegevens en logboeken voor virtueel netwerk	Waarschuwingen voor virtueel netwerk
Virtuele machines en virtuele-machineschaalsets	Naslaginformatie over metrische gegevens en logboeken voor VM's	VM-waarschuwingen en zelfstudies
Web Application Firewall	Beschrijving van metrische gegevens en logboeken van Web Application Firewall	Web Application Firewall-waarschuwingen

Zie Log Analytics-kostenberekeningen en -opties en -prijzen voor de Log Analytics-werkruimte voor meer informatie over de kosten van het verzamelen van metrische gegevens en logboeken. De aard van de workload en de frequentie en het aantal metrische gegevens en logboeken die zijn verzameld, zijn van grote invloed op de kosten voor metrische gegevens en logboekverzameling.

Virtuele machines

Diagnostische gegevens over Azure Boot zijn ingeschakeld om de status van de VM's tijdens het opstarten te observeren door seriële logboekgegevens en schermopnamen te verzamelen. In deze architectuur kunnen die gegevens worden geopend via De Azure-portal en de opdracht get-boot-log van azure CLI-VM-vm boot-log. De gegevens worden beheerd door Azure en u hebt geen controle of toegang tot de onderliggende opslagresource. Als uw bedrijfsvereisten echter meer controle vragen, kunt u uw eigen opslagaccount inrichten om diagnostische gegevens over opstarten op te slaan.

VM-inzichten bieden een efficiënte manier om VM's en schaalsets te bewaken. Het verzamelt gegevens uit Log Analytics-werkruimten en biedt vooraf gedefinieerde werkmappen voor trending van prestatiegegevens. Deze gegevens kunnen per VM worden weergegeven of worden samengevoegd op meerdere VM's.

Application Gateway en de interne load balancer gebruiken statustests om de eindpuntstatus van de VM's te detecteren voordat verkeer wordt verzonden.

Netwerken

In deze architectuur worden logboekgegevens verzameld van verschillende netwerkonderdelen die deelnemen aan de stroom. Deze onderdelen omvatten Application Gateway, load balancers en Azure Bastion. Ze omvatten ook netwerkbeveiligingsonderdelen zoals virtuele netwerken, NSG's, openbare IP-adressen en Private Link.

Beheerde schijven

Metrische schijfgegevens zijn afhankelijk van uw workload, waarvoor een combinatie van belangrijke metrische gegevens is vereist. Bewaking moet deze perspectieven combineren om problemen met de doorvoer van het besturingssysteem of de toepassing te isoleren.

• Het Perspectief van het Azure-platform vertegenwoordigt de metrische gegevens die de Azure-service aangeven, ongeacht de workload die eraan is gekoppeld. Metrische gegevens over schijfprestaties (IOPS en doorvoer) kunnen afzonderlijk of gezamenlijk worden weergegeven voor alle aan de VM gekoppelde schijven. Gebruik metrische gegevens over io-gebruik voor opslag voor probleemoplossing of waarschuwingen over mogelijke schijflimieten. Als u bursting gebruikt voor kostenoptimalisatie, controleert u metrische gegevens van het tegoedpercentage om verkoopkansen voor verdere optimalisatie te identificeren.

• Het perspectief van het gastbesturingssysteem vertegenwoordigt metrische gegevens die de workloadoperator zou weergeven, ongeacht de onderliggende schijftechnologie. VM-inzichten worden aanbevolen voor belangrijke metrische gegevens op gekoppelde schijven, zoals de gebruikte logische schijfruimte en het perspectief van de besturingssysteemkernel op schijf-IOPS en doorvoer.

Bewaking op toepassingsniveau

Hoewel de referentie-implementatie er geen gebruik van maakt, wordt Application Insights ingericht als application performance management (APM) voor uitbreidbaarheidsdoeleinden. Application Insights verzamelt gegevens van een toepassing en verzendt die gegevens naar de Log Analytics-werkruimte. Het kan ook die gegevens uit de workloadtoepassingen visualiseren.

De toepassingsstatusextensie wordt geïmplementeerd op VM's om de binaire status van elk VM-exemplaar in de schaalset te bewaken en voer indien nodig exemplaarreparaties uit met behulp van automatische exemplaarherstel van de schaalset. Er wordt getest op hetzelfde bestand als de Application Gateway en de interne statustest van de Azure Load Balancer om te controleren of de toepassing reageert.

Updatebeheer

VM's moeten regelmatig worden bijgewerkt en gepatcht, zodat ze de beveiligingspostuur van de workload niet verzwakken. We raden automatische en periodieke VM-evaluaties aan voor vroege detectie en toepassing van patches.

Infrastructuurupdates

Azure werkt het platform periodiek bij om de betrouwbaarheid, prestaties en beveiliging van de hostinfrastructuur voor virtuele machines te verbeteren. Deze updates omvatten het patchen van softwareonderdelen in de hostingomgeving, het upgraden van netwerkonderdelen of het buiten gebruik stellen van hardware en meer. Zie Onderhoud voor virtuele machines in Azure voor informatie over het updateproces.

Als een update geen herstart vereist, wordt de VIRTUELE machine onderbroken terwijl de host wordt bijgewerkt of wordt de VIRTUELE machine live gemigreerd naar een al bijgewerkte host. Als onderhoud opnieuw moet worden opgestart, wordt u op de hoogte gesteld van het geplande onderhoud. Azure biedt ook een tijdvenster waarin u het onderhoud kunt starten, op uw gemak. Zie Meldingen over gepland onderhoud verwerken voor informatie over het venster voor zelfonderhoud en het configureren van de beschikbare opties.

Sommige workloads tolereren mogelijk zelfs enkele seconden van het blokkeren of verbreken van een VM voor onderhoud niet. Zie Onderhoudsconfiguraties voor meer controle over alle onderhoudsactiviteiten, inclusief nul-impact en updates zonder opnieuw opstarten. Als u een onderhoudsconfiguratie maakt, kunt u alle platformupdates overslaan en de updates op uw gemak toepassen. Wanneer deze aangepaste configuratie is ingesteld, slaat Azure alle niet-nul-impact-updates over, inclusief updates zonder opnieuw opstarten. Zie Platformupdates beheren met onderhoudsconfiguraties voor meer informatie

Upgrades van installatiekopieën van besturingssysteem (OS)

Wanneer u besturingssysteemupgrades uitvoert, hebt u een gouden installatiekopieën die is getest. Overweeg om Azure Shared Image Gallery en Azure Compute Gallery te gebruiken voor het publiceren van uw aangepaste installatiekopieën. U moet een proces hebben dat batches van exemplaren op een rolling manier bijwerkt telkens wanneer een nieuwe installatiekopieën door de uitgever worden gepubliceerd.

Stel VM-installatiekopieën buiten gebruik voordat ze hun einde van de levensduur bereiken om het oppervlak te verminderen.

Uw automatiseringsproces moet rekening houden met overprovisioning met extra capaciteit.

U kunt Azure Updatebeheer gebruiken voor het beheren van besturingssysteemupdates voor uw virtuele Windows- en Linux-machines in Azure.Azure Update Manager biedt een SaaS-oplossing voor het beheren en beheren van software-updates voor Windows- en Linux-machines in Azure, on-premises en omgevingen met meerdere clouds.

Patchen voor gastbesturingssystemen

Virtuele Azure-machines bieden de mogelijkheid om automatische VM-gastpatching uit te voeren. Wanneer deze service is ingeschakeld, worden VM's periodiek geëvalueerd en worden beschikbare patches geclassificeerd. Het wordt aanbevolen dat de evaluatiemodus is ingeschakeld om dagelijkse evaluatie toe te staan voor patches die in behandeling zijn. Evaluatie op aanvraag kan echter worden uitgevoerd, waardoor de toepassing van patches niet wordt geactiveerd. Als de evaluatiemodus niet is ingeschakeld, moet u handmatige manieren hebben om wachtende updates te detecteren.

Alleen de patches die als kritiek of beveiliging zijn geclassificeerd, worden automatisch toegepast in alle Azure-regio's. Definieer aangepaste updatebeheerprocessen die andere patches toepassen.

Voor governance kunt u overwegen om automatische patching van installatiekopieën van besturingssystemen in Azure Policy voor virtuele-machineschaalsets te vereisen.

Automatische patching kan een belasting voor het systeem betekenen en kan verstorend zijn omdat VM's resources gebruiken en mogelijk opnieuw worden opgestart tijdens updates. Overinrichting wordt aanbevolen voor belastingbeheer. Implementeer VM's in verschillende Beschikbaarheidszones om gelijktijdige updates te voorkomen en ten minste twee exemplaren per zone te onderhouden voor hoge beschikbaarheid. VM's in dezelfde regio ontvangen mogelijk verschillende patches, die in de loop van de tijd moeten worden afgestemd.

Houd rekening met de afweging van de kosten die verband houden met overprovisioning.

Statuscontroles worden opgenomen als onderdeel van automatische VM-gastpatching. Deze controles controleren of de patchtoepassing is geslaagd en problemen detecteert.

Als er aangepaste processen zijn voor het toepassen van patches, gebruikt u privéopslagplaatsen voor patchbronnen. Hierdoor kunt u de patches beter controleren om ervoor te zorgen dat de update geen negatieve invloed heeft op de prestaties of beveiliging.

Zie Automatische VM-gastpatching voor Virtuele Azure-machines voor meer informatie.

Betrouwbaarheid

Deze architectuur maakt gebruik van beschikbaarheidszones als basiselement om problemen met betrouwbaarheid aan te pakken.

In deze installatie zijn afzonderlijke VM's gekoppeld aan één zone. Als er een fout optreedt, kunnen deze VM's gemakkelijk worden vervangen door andere VM-exemplaren met behulp van virtuele-machineschaalsets.

Alle andere onderdelen in deze architectuur zijn:

• Zone-redundant, wat betekent dat ze worden gerepliceerd in meerdere zones voor hoge beschikbaarheid, zoals Application Gateway of openbare IP-adressen.
• Zonetolerant, wat impliceert dat ze bestand zijn tegen zonefouten, zoals Key Vault.
• Regionale of wereldwijde resources die beschikbaar zijn in regio's of wereldwijd, zoals Microsoft Entra-id.

Het ontwerp van de workload moet betrouwbaarheidsgaranties bevatten in toepassingscode, infrastructuur en bewerkingen. In de volgende secties ziet u enkele strategieën om ervoor te zorgen dat de workload bestand is tegen fouten en kan worden hersteld als er storingen zijn op het niveau van de infrastructuur.

De strategieën die in architectuur worden gebruikt, zijn gebaseerd op de controlelijst voor betrouwbaarheidsontwerp die is opgegeven in Azure Well-Architected Framework. De secties worden geannoteerd met aanbevelingen van die controlelijst.

Omdat er geen toepassing is geïmplementeerd, valt tolerantie in toepassingscode buiten het bereik van deze architectuur. We raden u aan alle aanbevelingen in de controlelijst te bekijken en deze in uw workload te gebruiken, indien van toepassing.

Prioriteit geven aan de betrouwbaarheidsgaranties per gebruikersstroom

In de meeste ontwerpen zijn er meerdere gebruikersstromen, elk met een eigen set zakelijke vereisten. Niet al deze stromen vereisen het hoogste niveau van garanties, dus segmentering wordt aanbevolen als een betrouwbaarheidsstrategie. Elk segment kan onafhankelijk worden beheerd, zodat één segment geen invloed heeft op andere segmenten en het juiste tolerantieniveau in elke laag biedt. Deze aanpak maakt het systeem ook flexibel.

In deze architectuur implementeren toepassingslagen de segmentatie. Afzonderlijke schaalsets worden ingericht voor de front-end- en back-endlagen. Deze scheiding maakt onafhankelijk schalen van elke laag mogelijk, waardoor ontwerppatronen kunnen worden geïmplementeerd op basis van hun specifieke vereisten, en andere voordelen.

Raadpleeg goed ontworpen framework: RE:02 - Aanbevelingen voor het identificeren en beoordelen van stromen.

De mogelijke storingspunten identificeren

Elke architectuur is vatbaar voor fouten. Met de oefening van analyse van de foutmodus kunt u verwachte fouten verwachten en worden voorbereid met oplossingen. Hier volgen enkele mogelijke storingspunten in deze architectuur:

Onderdeel	Risico	Likelihood	Effect/beperking/opmerking	Uitval
Microsoft Entra ID	Onjuiste configuratie	Gemiddeld	Gebruikers van Ops kunnen zich niet aanmelden. Geen downstream-effect. Helpdesk rapporteert configuratieprobleem aan identiteitsteam.	Geen
Application Gateway	Onjuiste configuratie	Gemiddeld	Onjuiste configuraties moeten worden opgevangen tijdens de implementatie. Als deze fouten optreden tijdens een configuratie-update, moet het DevOps-team wijzigingen terugdraaien. Het inrichten van de meeste implementaties die gebruikmaken van de v2-SKU duurt ongeveer 6 minuten. Het kan echter langer duren, afhankelijk van het type implementatie. Implementaties in meerdere beschikbaarheidszones met veel exemplaren kunnen bijvoorbeeld langer dan 6 minuten duren.	Volledig
Application Gateway	DDoS-aanval	Gemiddeld	Potentieel voor onderbreking. Microsoft beheert DDoS-beveiliging (L3 en L4). Mogelijk risico op effect van L7-aanvallen.	Volledig
Virtuele-machineschaalsets	Service-onderbreking	Beperkt	Mogelijke workloadstoringen als er beschadigde VM-exemplaren zijn die automatisch opnieuw opstarten activeren. Afhankelijk van Microsoft om te herstellen.	Mogelijke storing
Virtuele-machineschaalsets	Storing in beschikbaarheidszone	Beperkt	Geen effect. Schaalsets worden geïmplementeerd als zone-redundant.	Geen

Raadpleeg Well-Architected Framework: RE:03 - Aanbevelingen voor het uitvoeren van analyse van de foutmodus.

Betrouwbaarheidsdoelen

Als u ontwerpbeslissingen wilt nemen, is het belangrijk om de betrouwbaarheidsdoelen te berekenen, zoals de samengestelde serviceniveaudoelstellingen (SLO's) van de workload. Hiervoor moet u inzicht krijgen in de service level agreements (SLA's) die worden geleverd door Azure-services die in de architectuur worden gebruikt. Sla's voor workloads mogen niet hoger zijn dan de SLA's die worden gegarandeerd door Azure. Bekijk elk onderdeel zorgvuldig, van VM's en hun afhankelijkheden, netwerken en opslagopties.

Hier volgt een voorbeeld van een berekening waarbij het belangrijkste doel is om een geschatte samengestelde SLO te bieden. Hoewel dit een ruwe richtlijn is, moet u iets soortgelijks bereiken. U moet geen hogere maximaal samengestelde SLO voor dezelfde stromen krijgen, tenzij u wijzigingen aanbrengt in de architectuur.

Bewerkingsstroom

Onderdeel	SLO
Microsoft Entra ID	99,99%
Azure Bastion	99,95%

Samengestelde SLO: 99,94% | Downtime per jaar: 0d 5h 15m 20s

App-gebruikersstroom

Onderdeel	SLO
Application Gateway	99,95%
Azure Load Balancer (intern)	99,99%
Front-end-VM's met premium-opslag (samengestelde SLO)	99.70%
Back-end-VM's met premium-opslag (samengestelde SLO)	99.70%

Samengestelde SLO: 99,34% | Downtime per jaar: 2d 9h 42m 18s

In het voorgaande voorbeeld zijn de betrouwbaarheid van VM's en de afhankelijkheden opgenomen, zoals schijven die zijn gekoppeld aan VM's. De SLA's die zijn gekoppeld aan schijfopslag zijn van invloed op de algehele betrouwbaarheid.

Er zijn enkele uitdagingen bij het berekenen van de samengestelde SLO. Het is belangrijk om te weten dat verschillende servicelagen kunnen worden geleverd met verschillende SLA's. Deze omvatten vaak garanties met financiële ondersteuning die betrouwbaarheidsdoelen instellen. Ten slotte zijn er mogelijk onderdelen van de architectuur waarvoor geen SLA's zijn gedefinieerd. In termen van netwerken, NIC's en virtuele netwerken hebben bijvoorbeeld geen eigen SLA's.

De bedrijfsvereisten en hun doelen moeten duidelijk worden gedefinieerd en in de berekening worden meegenomen. Houd rekening met de servicelimieten en andere beperkingen die door de organisatie worden opgelegd. Het delen van uw abonnement met andere workloads kan van invloed zijn op de resources die beschikbaar zijn voor uw VM's. De workload kan een beperkt aantal kernen gebruiken die beschikbaar zijn voor de VM's. Inzicht in het resourcegebruik van uw abonnement kan u helpen uw VM's effectiever te ontwerpen.

Raadpleeg Well-Architected Framework: RE:04 - Aanbevelingen voor het definiëren van betrouwbaarheidsdoelen.

Redundantie

Deze architectuur maakt gebruik van zoneredundantie voor verschillende onderdelen. Elke zone bestaat uit een of meer datacenters met onafhankelijke voeding, koeling en netwerken. Wanneer exemplaren in afzonderlijke zones worden uitgevoerd, wordt de toepassing beschermd tegen datacenterfouten.

• Virtual Machine Scale Sets wijst een opgegeven aantal exemplaren toe en distribueert ze gelijkmatig over beschikbaarheidszones en foutdomeinen. Deze verdeling wordt bereikt via de maximale spreidingsmogelijkheid , die we aanbevelen. Het verspreiden van VM-exemplaren in foutdomeinen zorgt ervoor dat alle VM's niet tegelijkertijd worden bijgewerkt.

  Overweeg een scenario waarin er drie beschikbaarheidszones zijn. Als u drie exemplaren hebt, wordt elk exemplaar toegewezen aan een andere beschikbaarheidszone en in een ander foutdomein geplaatst. Azure garandeert dat slechts één foutdomein tegelijk in elke beschikbaarheidszone wordt bijgewerkt. Er kan echter een situatie zijn waarin alle drie foutdomeinen die als host fungeren voor uw VM's in de drie beschikbaarheidszones tegelijkertijd worden bijgewerkt. Alle zones en domeinen worden beïnvloed. Als u ten minste twee exemplaren in elke zone hebt, beschikt u over een buffer tijdens upgrades.

• Beheerde schijven kunnen alleen worden gekoppeld aan een VIRTUELE machine in dezelfde regio. De beschikbaarheid is doorgaans van invloed op de beschikbaarheid van de virtuele machine. Voor implementaties met één regio kunnen schijven worden geconfigureerd voor redundantie om zonegebonden fouten te weerstaan. In deze architectuur worden gegevensschijven geconfigureerd voor zone-redundante opslag (ZRS) op de back-end-VM's. Hiervoor is een herstelstrategie vereist om te profiteren van beschikbaarheidszones. De herstelstrategie is het opnieuw implementeren van de oplossing. Rekenkracht in het ideale moment vooraf inrichten in alternatieve beschikbaarheidszones die gereed zijn om te herstellen na een zonegebonden fout.

• Een zoneredundante Application Gateway of standard load balancer kan verkeer routeren naar VM's tussen zones met behulp van één IP-adres, waardoor continuïteit wordt gegarandeerd, zelfs als er zonefouten optreden. Deze services gebruiken statustests om de beschikbaarheid van vm's te controleren. Zolang één zone in de regio operationeel blijft, wordt de routering voortgezet ondanks mogelijke storingen in andere zones. Routering tussen zones kan echter een hogere latentie hebben in vergelijking met binnenzoneroutering.

  Alle openbare IP-adressen die in deze architectuur worden gebruikt, zijn zone-redundant.

• Azure biedt zone-tolerante services voor betere betrouwbaarheid, zoals Key Vault.

• Globale Azure-resources zijn altijd beschikbaar en kunnen zo nodig overschakelen naar een andere regio, zoals de basisidentiteitsprovider, Microsoft Entra-id.

Raadpleeg Well-Architected Framework: RE:05 - Aanbevelingen voor het ontwerpen voor redundantie.

Schaalstrategie

Om verslechtering en storingen op serviceniveau te voorkomen, moet u betrouwbare schaalbewerkingen garanderen. Schaal de werkbelasting horizontaal (uitschalen), verticaal (omhoog schalen) of gebruik een combinatie van beide benaderingen. Gebruik Automatische schaalaanpassing van Azure Monitor om voldoende resources in te richten om de vraag op uw toepassing te ondersteunen zonder meer capaciteit toe te wijzen dan nodig is en onnodige kosten te maken.

Met automatische schaalaanpassing kunt u verschillende profielen definiëren op basis van verschillende gebeurtenistypen, zoals tijd, planning of metrische gegevens. Profielen op basis van metrische gegevens kunnen gebruikmaken van ingebouwde metrische gegevens (op basis van een host) of meer gedetailleerde metrische gegevens (metrische gegevens van gast-VM's) waarvoor de Azure Monitor-agent moet worden geïnstalleerd om ze te verzamelen. Elk profiel bevat regels voor uitschalen (vergroten) en inschalen (afname). Overweeg om alle verschillende schaalscenario's te verkennen op basis van ontworpen profielen en deze te evalueren op mogelijke lusvoorwaarden die een reeks tegengestelde schaalevenementen kunnen veroorzaken. Azure Monitor probeert deze situatie te verhelpen door te wachten op de afkoelperiode voordat deze opnieuw wordt geschaald.

Hoewel Schaalsets voor virtuele azure-machines in de flexibele modus heterogene omgevingen ondersteunen, wordt automatisch schalen van meerdere profielen niet ondersteund. Overweeg om verschillende schaalsets te maken om ze afzonderlijk te beheren als u van plan bent automatische schaalaanpassing te gebruiken met meer dan één type VIRTUELE machine.

Houd rekening met andere aspecten, zoals bootstrapping, respijtieve afsluitingen, het installeren van de workload en alle bijbehorende afhankelijkheden en schijfbeheer bij het maken of verwijderen van VM-exemplaren.

Stateful workloads vereisen mogelijk extra beheer voor beheerde schijven die zich buiten een workloadexemplaren moeten bevinden. Ontwerp uw workload voor gegevensbeheer onder het schalen van gebeurtenissen voor consistentie, synchronisatie, replicatie en integriteit van de gegevens van de werkbelasting. Voor deze scenario's kunt u vooraf ingevulde schijven toevoegen aan schaalsets. Voor gebruiksscenario's waarbij schalen wordt gebruikt om knelpunten te voorkomen bij het openen van gegevens, moet u het partitioneren en sharden plannen. Zie aanbevolen procedures voor automatisch schalen voor meer informatie.

Raadpleeg Well-Architected Framework: RE:06 - Aanbevelingen voor het ontwerpen van een betrouwbare schaalstrategie.

Zelfherstel en herstelbaarheid

Automatische exemplaarreparaties zijn ingeschakeld in de virtuele-machineschaalsets om herstel na VM-fouten te automatiseren. De toepassingsstatusextensie wordt geïmplementeerd op VM's ter ondersteuning van het detecteren van niet-reagerende VM's en toepassingen. Voor deze exemplaren worden herstelacties automatisch geactiveerd.

Raadpleeg Well-Architected Framework: Aanbevelingen voor zelfherstel en zelfbehoud.

Beveiliging

Deze architectuur illustreert enkele van de beveiligingsgaranties die worden gegeven in de controlelijst voor beveiligingsontwerp die is gegeven in Azure Well-Architected Framework. De secties worden geannoteerd met aanbevelingen van die controlelijst.

Beveiliging verwijst niet alleen naar technische controles. We raden u aan de volledige controlelijst te volgen om inzicht te hebben in de operationele aspecten van de beveiligingspijler.

Segmentatie

• Netwerksegmentatie. Workloadresources worden in een virtueel netwerk geplaatst, dat isolatie van internet biedt. Binnen het virtuele netwerk kunnen subnetten worden gebruikt als vertrouwensgrenzen. Gerelateerde resources colocate die nodig zijn voor het verwerken van een transactie in één subnet. In deze architectuur is het virtuele netwerk onderverdeeld in subnetten op basis van de logische groepering van de toepassing en het doel van verschillende Azure-services die worden gebruikt als onderdeel van de workload.

  Het voordeel van subnetsegmentatie is dat u beveiligingscontroles kunt plaatsen aan de perimeter waarmee het verkeer wordt gecontroleerd dat binnen en uit het subnet stroomt, waardoor de toegang tot de workloadresources wordt beperkt.

• Identiteitssegmentatie. Wijs afzonderlijke rollen toe aan verschillende identiteiten met just-enough machtigingen om hun taak uit te voeren. Deze architectuur maakt gebruik van identiteiten die worden beheerd door Microsoft Entra ID om toegang tot resources te segmenteren.

• Resourcesegmentatie. De toepassing wordt gesegmenteerd op lagen in afzonderlijke schaalsets, wat ervoor zorgt dat toepassingsonderdelen zich niet in een punt bevinden.

Raadpleeg Well-Architected Framework: SE:04 - Aanbevelingen voor het bouwen van een segmentatiestrategie.

Identiteits- en toegangsbeheer

We raden Microsoft Entra-id aan voor verificatie en autorisatie van zowel gebruikers als services.

Voor toegang tot VM's is een gebruikersaccount vereist dat wordt beheerd door Microsoft Entra ID-verificatie en wordt ondersteund door beveiligingsgroepen. Deze architectuur biedt ondersteuning door de verificatie-extensie voor Microsoft Entra ID te implementeren op alle VM's. Het is raadzaam dat menselijke gebruikers hun bedrijfsidentiteiten gebruiken in de Microsoft Entra ID-tenant van hun organisatie. Zorg er ook voor dat toegang op basis van een service-principal niet wordt gedeeld tussen functies.

Workloadresources, zoals VM's, verifiëren zichzelf met behulp van hun toegewezen beheerde identiteiten aan andere resources. Deze identiteiten, op basis van service-principals van Microsoft Entra ID, worden automatisch beheerd.

Key Vault-extensies worden bijvoorbeeld geïnstalleerd op VM's, waarmee de VM's met certificaten worden opgestart. In deze architectuur worden door de gebruiker toegewezen beheerde identiteiten gebruikt door Application Gateway, front-end-VM's en back-end-VM's voor toegang tot Key Vault. Deze beheerde identiteiten worden geconfigureerd tijdens de implementatie en worden gebruikt voor verificatie met Key Vault. Toegangsbeleid voor Key Vault is zo geconfigureerd dat alleen aanvragen van de voorgaande beheerde identiteiten worden geaccepteerd.

De basislijnarchitectuur maakt gebruik van een combinatie van door het systeem toegewezen en door de gebruiker toegewezen beheerde identiteiten. Deze identiteiten zijn vereist voor het gebruik van Microsoft Entra-id voor autorisatiedoeleinden bij het openen van andere Azure-resources.

Raadpleeg Well-Architected Framework: SE:05 - Aanbevelingen voor identiteits- en toegangsbeheer.

Netwerkbediening

• Inkomend verkeer. De workload-VM's worden niet rechtstreeks blootgesteld aan het openbare internet. Elke VIRTUELE machine heeft een privé-IP-adres. Workloadgebruikers maken verbinding met behulp van het openbare IP-adres van Application Gateway.

  Er wordt meer beveiliging geboden via Web Application Firewall die is geïntegreerd met Application Gateway. Het bevat regels die binnenkomend verkeer inspecteren en de juiste actie kunnen ondernemen. WAF houdt OWASP-beveiligingsproblemen (Open Web Application Security Project) bij die bekende aanvallen voorkomen.

• Uitgaand verkeer. Er zijn geen besturingselementen voor uitgaand verkeer, behalve de uitgaande NSG-regels op de VM-subnetten. We raden u aan om al het uitgaande internetverkeer via één firewall te laten stromen. Deze firewall is meestal een centrale service die wordt geleverd door een organisatie. Deze use case wordt weergegeven in de basislijnarchitectuur van virtuele machines in een Azure-landingszone.

• Oost-west verkeer. De verkeersstroom tussen de subnetten wordt beperkt door gedetailleerde beveiligingsregels toe te passen.

  Netwerkbeveiligingsgroepen (NSG's) worden geplaatst om verkeer tussen subnetten te beperken op basis van parameters zoals IP-adresbereik, poorten en protocollen. Toepassingsbeveiligingsgroepen (ASG) worden op front-end- en back-end-VM's geplaatst. Ze worden gebruikt met NSG's om verkeer van en naar de VM's te filteren.

• Operationeel verkeer. Het is raadzaam om operationele toegang tot een workload te beveiligen via Azure Bastion, waardoor er geen openbaar IP-adres meer nodig is. In deze architectuur is deze communicatie via SSH en wordt ondersteund door zowel Windows- als Linux-VM's. Microsoft Entra ID is geïntegreerd met SSH voor beide typen VM's met behulp van de bijbehorende VM-extensie. Met deze integratie kan de identiteit van een operator worden geverifieerd en geautoriseerd via Microsoft Entra-id.

  U kunt ook een afzonderlijke VIRTUELE machine gebruiken als een jumpbox, geïmplementeerd in een eigen subnet, waar u uw keuze aan hulpprogramma's voor beheer en probleemoplossing kunt installeren. De operator opent de jumpbox via de Azure Bastion-host. Vervolgens melden ze zich aan bij de VM's achter de load balancer vanuit de jumpbox.

  In deze architectuur wordt operationeel verkeer beveiligd met behulp van NSG-regels om verkeer te beperken, en JIT-VM-toegang (Just-In-Time) is ingeschakeld op de VM's. Met deze functie van Microsoft Defender voor Cloud is tijdelijke binnenkomende toegang tot geselecteerde poorten toegestaan.

  Gebruik Microsoft Entra Privileged Identity Management (PIM) voor verbeterde beveiliging. PIM is een service in Microsoft Entra ID waarmee u de toegang tot belangrijke resources in uw organisatie kunt beheren, beheren en bewaken. PIM biedt op tijd gebaseerde en op goedkeuring gebaseerde rolactivering om de risico's van overmatige, onnodige of verkeerd gebruikte toegangsmachtigingen te beperken voor resources die u belangrijk vindt.

• Privéconnectiviteit met PaaS-services (Platform as a Service). Communicatie tussen de VM's en Key Vault verloopt via Private Link. Voor deze service zijn privé-eindpunten vereist, die in een afzonderlijk subnet worden geplaatst.

• DDoS-beveiliging. Overweeg Om Azure DDoS Protection in te schakelen op de openbare IP-adressen die worden weergegeven door Application Gateway en de Azure Bastion-host om bedreigingen te detecteren. DDoS Protection biedt ook waarschuwingen, telemetrie en analyses via Monitor. Zie Azure DDoS Protection: Best practices en referentiearchitecturen voor meer informatie.

Raadpleeg Well-Architected Framework: SE:06 - Aanbevelingen voor netwerken en connectiviteit.

Versleuteling

• Gegevens die onderweg zijn. Gebruikersverkeer tussen gebruikers en het openbare IP-adres van Application Gateway wordt versleuteld met behulp van het externe certificaat. Verkeer tussen de toepassingsgateway en de front-end-VM's en tussen de front-end- en back-end-VM's wordt versleuteld met behulp van een intern certificaat. Beide certificaten worden opgeslagen in Key Vault:

  • app.contoso.com: Een extern certificaat dat door clients en Application Gateway wordt gebruikt voor het beveiligen van openbaar internetverkeer.
  • *.workload.contoso.com: Een jokertekencertificaat dat door de infrastructuuronderdelen wordt gebruikt voor het beveiligen van intern verkeer.

• Data-at-rest. Logboekgegevens worden opgeslagen op een beheerde schijf die is gekoppeld aan VM's. Deze gegevens worden automatisch versleuteld met behulp van door het platform geleverde versleuteling in Azure.

Raadpleeg Well-Architected Framework: SE:07 - Aanbevelingen voor gegevensversleuteling.

Geheimenbeheer

Een Visio-bestand van deze architectuur downloaden.

Key Vault biedt veilig beheer van geheimen, waaronder TLS-certificaten. In deze architectuur worden de TLS-certificaten opgeslagen in key vault en opgehaald tijdens het inrichtingsproces door de beheerde identiteiten van Application Gateway en de VM's. Na de eerste installatie hebben deze resources alleen toegang tot Key Vault wanneer de certificaten worden vernieuwd.

De VM's gebruiken de Key Vault-VM-extensie om de bewaakte certificaten automatisch te vernieuwen. Als er wijzigingen worden gedetecteerd in het lokale certificaatarchief, haalt de extensie de bijbehorende certificaten op uit Key Vault en installeert deze. De extensie ondersteunt certificaatinhoudstypen PKCS #12 en PEM.

Raadpleeg Well-Architected Framework: SE:09 - Aanbevelingen voor het beveiligen van toepassingsgeheimen.

Kostenoptimalisatie

Aan de vereisten voor workloads moet worden voldaan, rekening houdend met de kostenbeperkingen. De strategieën die in de architectuur worden gebruikt, zijn gebaseerd op de controlelijst voor ontwerpbeoordeling van Cost Optimization die is opgegeven in Azure Well-Architected Framework. In deze sectie worden enkele opties beschreven voor het optimaliseren van kosten en wordt geannoteerd met aanbevelingen uit die controlelijst.

Kosten van onderdelen

Selecteer VM-installatiekopieën die zijn geoptimaliseerd voor de workload in plaats van installatiekopieën voor algemeen gebruik te gebruiken. In deze architectuur worden relatief kleine VM-installatiekopieën gekozen voor zowel Windows als Linux, die elk 30 GB zijn. Met kleinere installatiekopieën zijn VM-SKU's met schijven ook kleiner, wat leidt tot lagere kosten, minder resourceverbruik en snellere implementatie- en opstarttijden. Een voordeel is verbeterde beveiliging vanwege het verminderde oppervlak.

Het implementeren van logboekrotatie met groottelimieten is een andere kostenbesparende strategie. Het maakt het gebruik van kleine gegevensschijven mogelijk, wat kan leiden tot lagere kosten. De implementatie van deze architectuur maakt gebruik van schijven van 4 GB.

Het gebruik van tijdelijke besturingssysteemschijven kan ook leiden tot kostenbesparingen en verbeterde prestaties. Deze schijven zijn ontworpen voor het gebruik van VM-resources waarvoor u al betaalt, omdat ze zijn geïnstalleerd op de cacheschijf die is ingericht met de VIRTUELE machine. Het elimineert opslagkosten die zijn gekoppeld aan traditionele permanente schijven. Omdat deze schijven tijdelijk zijn, zijn er geen kosten verbonden aan langetermijngegevensopslag.

Raadpleeg Well-Architected Framework: CO:07 - Aanbevelingen voor het optimaliseren van onderdeelkosten.

Stroomkosten

Kies rekenresources op basis van de ernst van de stroom. Voor stromen die zijn ontworpen om een onbepaalde lengte te tolereren, kunt u overwegen spot-VM's te gebruiken met de flexibele indelingsmodus van virtuele-machineschaalsets. Deze aanpak kan effectief zijn voor het hosten van stromen met lage prioriteit op VM's met een lagere prioriteit. Deze strategie maakt kostenoptimalisatie mogelijk en voldoet nog steeds aan de vereisten van verschillende stromen.

Raadpleeg Well-Architected Framework: CO:09 - Aanbevelingen voor het optimaliseren van stroomkosten.

Kosten schalen

Als het belangrijkste kostenstuurprogramma het aantal exemplaren is, is het mogelijk rendabeler om omhoog te schalen door de grootte of prestaties van de VM's te vergroten. Deze aanpak kan leiden tot kostenbesparingen op verschillende gebieden:

• Softwarelicenties. Grotere VM's kunnen meer werkbelasting verwerken, waardoor het aantal vereiste softwarelicenties mogelijk wordt verminderd.
• Onderhoudstijd: Minder grotere VM's kunnen operationele kosten verlagen.
• Taakverdeling: minder VM's kunnen leiden tot lagere kosten voor taakverdeling. In deze architectuur zijn er bijvoorbeeld meerdere lagen taakverdeling, zoals een toepassingsgateway aan de voorzijde en een interne load balancer in het midden. De kosten voor taakverdeling zouden toenemen als een hoger aantal exemplaren moet worden beheerd.
• Schijfopslag. Als er stateful toepassingen zijn, hebben meer exemplaren meer gekoppelde beheerde schijven nodig, waardoor de opslagkosten toenemen.

Raadpleeg goed ontworpen framework: CO:12 - Aanbevelingen voor het optimaliseren van schaalkosten.

Bedrijfskosten

Automatische VM-gastpatching vermindert de overhead van handmatig patchen en de bijbehorende onderhoudskosten. Deze actie helpt niet alleen het systeem veiliger te maken, maar optimaliseert ook de toewijzing van resources, wat bijdraagt aan de algehele kostenefficiëntie.

Raadpleeg Well-Architected Framework: CO:13 - Aanbevelingen voor het optimaliseren van personeelstijd.

Dit scenario implementeren

Een implementatie voor deze referentiearchitectuur is beschikbaar op GitHub.

Verwante resources

Raadpleeg de productdocumentatie voor meer informatie over specifieke Azure-services:

• Azure Virtual Machines
• Azure-schaalvergrotingssets voor virtuele machines
• Azure Virtual Network
• Azure-toepassing Gateway-Standard_v2
• Azure-belastingsverdeling
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

Volgende stap

Bekijk de IaaS-referentiearchitecturen met opties voor de gegevenslaag:

• Windows N-tier-toepassing met behulp van SQL Server in Azure