Azure Virtual Machines-baslinjearkitektur

Den här artikeln innehåller en grundläggande referensarkitektur för en arbetsbelastning som distribueras på virtuella Azure-datorer.

Exempelarbetsbelastningen som antas av den här arkitekturen är ett internetuppkopplad webbprogram med flera nivåer som distribueras på separata uppsättningar med virtuella datorer (VM). Virtuella datorer etableras som en del av distributioner av Skalningsuppsättningar för virtuella Azure-datorer. Den här arkitekturen kan användas för följande scenarier:

• Privata program. Dessa program omfattar interna verksamhetsspecifika program eller kommersiella färdiga lösningar.
• Offentliga program. Dessa program är internetuppkopplade program. Den här arkitekturen är inte avsedd för databehandling med höga prestanda, verksamhetskritiska arbetsbelastningar, program som påverkas mycket av svarstid eller andra specialiserade användningsfall.

Det primära fokuset för den här arkitekturen är inte programmet. I stället innehåller den här artikeln vägledning för att konfigurera och distribuera de infrastrukturkomponenter som programmet interagerar med. Dessa komponenter omfattar komponenter för beräkning, lagring, nätverk och övervakning.

Den här arkitekturen fungerar som utgångspunkt för en IaaS-värdbaserad arbetsbelastning (infrastruktur som en tjänst). Datanivån undantas avsiktligt från den här vägledningen för att behålla fokus på beräkningsinfrastrukturen.

Artikellayout

Arkitektur	Designbeslut	Metod för välarkitekterat ramverk
▪ Arkitekturdiagram ▪ Arbetsbelastningsresurser ▪ Stödresurser ▪ Användarflöden	▪ Designval för virtuella datorer ▪ Diskar ▪ Nätverkande ▪ Övervakning ▪ Uppdateringshantering	▪ Tillförlitlighet ▪ Säkerhet ▪ Kostnadsoptimering

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Information om dessa resurser finns i Azure-produktdokumentationen i Relaterade resurser.

Komponenter

Den här arkitekturen består av flera Azure-tjänster för både arbetsbelastningsresurser och stödresurser för arbetsbelastningar. Tjänsterna för var och en av deras roller beskrivs i följande avsnitt.

Arbetsbelastningsresurser

• Azure Virtual Machines fungerar som beräkningsresurs för programmet och distribueras mellan tillgänglighetszoner. I illustrativa syften används en kombination av både virtuella Windows- och Linux-datorer.

  Skalningsuppsättningar för virtuella Azure-datorer i flexibelt orkestreringsläge används för att etablera och hantera de virtuella datorerna.

  Exempelprogrammet kan representeras på två nivåer, var och en kräver sin egen beräkning.

  • Klientdelen kör webbservern och tar emot användarbegäranden.
  • Serverdelen kör en annan webbserver som fungerar som ett webb-API som exponerar en enda slutpunkt där affärslogik körs.

  De virtuella datorerna på klientsidan har datadiskar (Premium_LRS) anslutna, som kan användas för att distribuera ett tillståndslöst program. De virtuella serverdelsdatorerna bevarar data för att Premium_ZRS lokala diskar som en del av åtgärden. Den här layouten kan utökas till att omfatta en databasnivå för lagring av tillstånd från klientdelen och serverdelsberäkningen. Den nivån ligger utanför omfånget för den här arkitekturen.

• Azure Virtual Network tillhandahåller ett privat nätverk för alla arbetsbelastningsresurser. Nätverket är indelat i undernät, som fungerar som isoleringsgränser.

• Azure Application Gateway är den enda ingresspunkten som dirigerar begäranden till klientdelsservrarna. Den valda SKU:n innehåller integrerad Azure Web Application Firewall (WAF) för ökad säkerhet.

• Intern Azure Load Balancer dirigerar trafik från klientdelsnivån till serverdelsservrarna.

• Azure Load Balancer Standard SKU ger utgående Internetåtkomst till de virtuella datorerna med tre offentliga IP-adresser.

• Azure Key Vault lagrar de certifikat som används för TLS-kommunikation (End-to-End Transport Layer Security). Det kan också användas för programhemligheter.

Stödresurser för arbetsbelastning

• Azure Bastion ger driftåtkomst till de virtuella datorerna via säkra protokoll.

• Application Insights samlar in loggar och mått från programmet. Eftersom programmet inte är i fokus för den här arkitekturen visas inte loggsamlingen i implementeringen.

• Log Analytics är den övervakningsdatamottagare som samlar in loggar och mått från Azure-resurser och Application Insights. Ett lagringskonto etableras som en del av arbetsytan.

Användarflöden

Det finns två typer av användare som interagerar med arbetsbelastningsresurserna: arbetsbelastningsanvändaren och operatören. Flödena för dessa användare visas i föregående arkitekturdiagram.

Arbetsbelastningsanvändare

1. Användaren kommer åt webbplatsen med hjälp av den offentliga IP-adressen för Application Gateway.

2. Application Gateway tar emot HTTPS-trafik, dekrypterar data med hjälp av ett externt certifikat för WAF-inspektion och krypterar om den med hjälp av det interna jokerteckencertifikatet för transport till klientdelen.

3. Application Gateway balanserar trafik mellan virtuella datorer på klientsidan och vidarebefordrar begäran till en virtuell klientdelsdator.

4. Den valda virtuella klientdatorn kommunicerar med en virtuell serverdelsdator med hjälp av lastbalanserarens privata IP-adress, inte IP-adressen för en enskild virtuell dator. Den här kommunikationen krypteras också med hjälp av det interna jokerteckencertifikatet.

5. Den virtuella serverdelsdatorn dekrypterar begäran med hjälp av det interna certifikatet. När serverdelen har bearbetat begäran returneras resultatet till klientdelen, vilket returnerar resultatet till programgatewayen och slutligen returnerar resultatet till användaren.

Operator

De virtuella datorerna i den här arkitekturen kan kräva direkt åtkomst av operatörer, men vi rekommenderar att fjärråtkomst minimeras genom automatisering och att åtkomst övervakas. Åtkomsten kan vara för felkorrigeringssituationer, felsökning eller en del av en automatiserad distributionsprocess. Den här arkitekturen har inte offentliga IP-adresser för åtkomst till kontrollplanet. Azure Bastion fungerar som en serverlös gateway som gör det möjligt att komma åt virtuella datorer via SSH eller RDP. Den här konfigurationen säkerställer säker och effektiv åtkomsthantering.

1. Operatören loggar in på Azure-portalen eller Azure CLI.
2. Operatören ansluter till Azure Bastion-tjänsten och ansluter via fjärranslutning till önskad virtuell dator.

Designval för virtuella datorer

När du väljer SKU:er är det viktigt att ha en förväntad baslinjeprestanda. Flera egenskaper påverkar beslutsprocessen, bland annat:

• CPU-, minnes- och diskindata-/utdataåtgärder per sekund (IOPS).
• Processorarkitektur.
• Avbildningsstorlek för operativsystem (OS).

Om du till exempel migrerar en arbetsbelastning från en lokal miljö som kräver Intel-processordatorer väljer du VM-SKU:er som stöder Intel-processorer.

Information om de vm-SKU:er som stöds finns i Storlekar för virtuella datorer i Azure.

Bootstrapping

Virtuella datorer måste ofta startas, vilket är en process där virtuella datorer förbereds och finjusteras för att köra programmet. Vanliga bootstrapping-uppgifter är att installera certifikat, konfigurera fjärråtkomst, installera paket, justera och härda OS-konfigurationen samt formatera och montera datadiskar. Det är viktigt att automatisera bootstrappingprocessen så mycket som möjligt, så att programmet kan starta på den virtuella datorn utan fördröjning eller manuella åtgärder. Här är rekommendationerna för automatisering:

• Tillägg för virtuella datorer. Dessa tillägg är Azure Resource Manager-objekt som hanteras via din IaC-distribution (Infrastruktur som kod). På så sätt rapporteras eventuella fel som en misslyckad distribution som du kan vidta åtgärder på. Om det inte finns något tillägg för dina bootstrapping-behov skapar du anpassade skript. Vi rekommenderar att du kör skripten via Azure Custom Script Extension.

  Här följer några andra tillägg som kan användas för att automatiskt installera eller konfigurera funktioner på de virtuella datorerna.

  • Azure Monitor Agent (AMA) samlar in övervakningsdata från gästoperativsystemet och levererar dem till Azure Monitor.
  • Azure Custom Script Extension (Windows, Linux) Version 2 laddar ned och kör skript på virtuella Azure-datorer (VM). Det här tillägget är användbart för att automatisera efterdistributionskonfiguration, programvaruinstallation eller andra konfigurations- eller hanteringsuppgifter.
  • Azure Key Vault-tillägget för virtuella datorer (Windows, Linux) ger automatisk uppdatering av certifikat som lagras i ett Nyckelvalv genom att identifiera ändringar och installera motsvarande certifikat.
  • Application Health-tillägget med VM-skalningsuppsättningar är viktigt när Skalningsuppsättningar för virtuella Azure-datorer utför automatiska löpande uppgraderingar. Azure förlitar sig på hälsoövervakning av de enskilda instanserna för att göra uppdateringarna. Du kan också använda tillägget för att övervaka programhälsan för varje instans i skalningsuppsättningen och utföra instansreparationer med hjälp av automatiska instansreparationer.
  • Microsoft Entra ID och OpenSSH (Windows, Linux) integreras med Microsoft Entra-autentisering. Nu kan du använda Microsoft Entra-ID som en grundläggande autentiseringsplattform och en certifikatutfärdare till SSH till en virtuell Linux-dator med hjälp av Microsoft Entra-ID och OpenSSH-certifikatbaserad autentisering. Med den här funktionen kan du hantera åtkomst till virtuella datorer med rollbaserad åtkomstkontroll i Azure (RBAC) och principer för villkorsstyrd åtkomst.

• Agentbaserad konfiguration. Virtuella Linux-datorer kan använda en enkel inbyggd önskad tillståndskonfiguration som är tillgänglig via cloud-init på olika Azure-tillhandahållna VM-avbildningar. Konfigurationen har angetts och versionshanterats med dina IaC-artefakter. Att ta med en egen konfigurationshanteringslösning är ett annat sätt. De flesta lösningar följer en deklarativ-första metod för bootstrapping, men stöder anpassade skript för flexibilitet. Populära alternativ är Desired State Configuration för Windows, Desired State Configuration for Linux, Ansible, Chef, Puppet med flera. Alla dessa konfigurationslösningar kan paras ihop med VM-tillägg för bästa möjliga upplevelse.

I referensimplementeringen utförs all bootstrapping via VM-tillägg och anpassade skript, inklusive ett anpassat skript för att automatisera datadiskformatering och montering.

Se Well-Architected Framework: RE:02 – Rekommendationer för automatiseringsdesign.

VM-anslutning

För att aktivera privat kommunikation mellan en virtuell dator och andra enheter i ett visst virtuellt nätverk är den virtuella datorns nätverkskort (NIC) anslutet till ett av undernäten i det virtuella nätverket. Om du behöver flera nätverkskort för den virtuella datorn ska du veta att ett maximalt antal nätverkskort har definierats för varje VM-storlek.

Om arbetsbelastningen behöver kommunikation med korta svarstider mellan virtuella datorer i det virtuella nätverket kan du överväga accelererat nätverk, vilket stöds av nätverkskort för virtuella Azure-datorer. Mer information finns i Fördelar med accelererat nätverk.

Vm-skalningsuppsättningar med flexibel orkestrering

Virtuella datorer etableras som en del av VM-skalningsuppsättningar med flexibel orkestrering. Vm-skalningsuppsättningar är logiska grupper av virtuella datorer som används för att uppfylla affärsbehov. Typerna av virtuella datorer i en gruppering kan vara identiska eller olika. De låter dig hantera livscykeln för datorer, nätverksgränssnitt och diskar med hjälp av standard-API:er och kommandon för virtuella Azure-datorer.

Flexibelt orkestreringsläge underlättar åtgärder i stor skala och hjälper till med detaljerade skalningsbeslut.

Konfiguration av feldomäner krävs för att begränsa effekten av fysiska maskinvarufel, nätverksavbrott eller strömavbrott. Med skalningsuppsättningar sprider Azure jämnt instanser över feldomäner för motståndskraft mot ett enskilt maskinvaru- eller infrastrukturproblem.

Vi rekommenderar att du avlastar feldomänallokering till Azure för maximal spridning av instanser, vilket ökar motståndskraften och tillgängligheten.

Diskar

För att köra operativsystemet och programkomponenterna är lagringsdiskar anslutna till den virtuella datorn. Överväg att använda tillfälliga diskar för operativsystemet och hanterade diskar för datalagring.

Azure erbjuder en rad olika alternativ när det gäller prestanda, mångsidighet och kostnad. Börja med Premium SSD för de flesta produktionsarbetsbelastningar. Ditt val beror på den virtuella datorns SKU. SKU:er som stöder Premium SSD innehåller en s i resursnamnet, till exempel Dsv4 men inte Dv4.

Mer information om diskalternativ med mått som kapacitet, IOPS och dataflöde finns i Jämförelse av disktyp.

Överväg diskegenskaper och prestandaförväntningar när du väljer en disk.

• SKU-begränsningar för virtuella datorer. Diskar fungerar inom den virtuella dator som de är anslutna till, som har IOPS- och dataflödesgränser. Se till att disken inte överskrider den virtuella datorns gränser och vice versa. Välj de diskstorlekar, prestanda och VM-funktioner (kärna, PROCESSOR, minne) som optimalt kör programkomponenten. Undvik överetablering eftersom det påverkar kostnaden.

• Konfigurationsändringar. Du kan ändra vissa diskprestanda och kapacitetskonfigurationer när en virtuell dator körs. Många ändringar kan dock kräva ometablering och återskapande av diskinnehåll, vilket påverkar arbetsbelastningens tillgänglighet. Planera därför noggrant disk- och VM SKU-val för att minimera tillgänglighetspåverkan och omarbeta.

• Tillfälliga OS-diskar. Etablera OS-diskar som tillfälliga diskar. Använd endast hanterade diskar om OS-filer behöver sparas. Undvik att använda tillfälliga diskar för att lagra programkomponenter och tillstånd.

  Kapaciteten för tillfälliga OS-diskar beror på den valda virtuella datorns SKU. Kontrollera att storleken på operativsystemavbildningsdisken är mindre än SKU:ns tillgängliga cacheminne eller temporära disk. Du kan använda återstående utrymme för tillfällig lagring.

• Diskprestanda. Företablering av diskutrymme baserat på hög belastning är vanligt, men det kan leda till underutnyttjade resurser eftersom de flesta arbetsbelastningar inte har hög belastning.

  Övervaka arbetsbelastningens användningsmönster, notera toppar eller ihållande högläsningsåtgärder och ta med dessa mönster i valet av virtuell dator och SKU för hanterade diskar.

  Du kan justera prestanda på begäran genom att ändra prestandanivåer eller med hjälp av de bursting-funktioner som erbjuds i vissa SKU:er för hanterade diskar .

  Även om överetablering minskar behovet av burst-användning kan det leda till outnyttjad kapacitet som du betalar för. Kombinera gärna båda funktionerna för optimala resultat.

• Justera cachelagring för arbetsbelastningen. Konfigurera cacheinställningar för alla diskar baserat på användning av programkomponenter.

  Komponenter som huvudsakligen utför läsåtgärder kräver inte transaktionskonsekvens med hög disk. Dessa komponenter kan dra nytta av skrivskyddad cachelagring. Skrivintensiva komponenter som kräver transaktionskonsekvens med hög disk har ofta cachelagring inaktiverats.

  Om du använder cachelagring med lässkrivning kan det orsaka dataförlust om den virtuella datorn kraschar och inte rekommenderas för de flesta datadiskscenarier.

I den här arkitekturen:

• OS-diskarna för alla virtuella datorer är tillfälliga och finns på cachedisken.

  Arbetsbelastningsprogrammet i klientdelen (Linux) och serverdelen (Windows Server) är toleranta mot enskilda vm-fel och använder båda små avbildningar (cirka 30 GB). Sådana attribut gör dem berättigade till användning av tillfälliga OS-diskar som skapats som en del av den virtuella datorns lokala lagring (cachepartition) i stället för beständiga OS-diskar som sparas i fjärranslutna Azure Storage-resurser. Den här situationen medför ingen lagringskostnad för OS-diskar och förbättrar även prestandan genom att ge lägre svarstider och minska distributionstiden för den virtuella datorn.

• Varje virtuell dator har en egen Premium SSD P1-hanterad disk, vilket ger ett basetablerad dataflöde som lämpar sig för arbetsbelastningen.

Nätverkslayout

Den här arkitekturen distribuerar arbetsbelastningen i ett enda virtuellt nätverk. Nätverkskontroller är en viktig del av den här arkitekturen och beskrivs i avsnittet Säkerhet .

Den här layouten kan integreras med en företagstopologi. Det exemplet visas i baslinjearkitekturen för virtuell dator i en Azure-landningszon.

Virtuellt nätverk

Ett av dina första beslut om nätverkslayout gäller nätverksadressintervallet. Tänk på den förväntade nätverkstillväxten under kapacitetsplaneringsfasen. Nätverket bör vara tillräckligt stort för att upprätthålla tillväxten, vilket kan behöva extra nätverkskonstruktioner. Det virtuella nätverket bör till exempel ha kapacitet för att hantera de andra virtuella datorerna som är resultatet av en skalningsåtgärd.

Omvänt kan du ange rätt storlek på adressutrymmet. Ett alltför stort virtuellt nätverk kan leda till underutnyttjande. Observera att adressintervallet inte kan ändras när det virtuella nätverket har skapats.

I den här arkitekturen är adressutrymmet inställt på /21, ett beslut baserat på den beräknade tillväxten.

Överväganden vid underanpassning

I det virtuella nätverket delas undernäten upp baserat på funktioner och säkerhetskrav, enligt beskrivningen här:

• Ett undernät som är värd för programgatewayen, som fungerar som omvänd proxy. Application Gateway kräver ett dedikerat undernät.
• Ett undernät som är värd för den interna lastbalanseraren för att distribuera trafik till virtuella serverdelsdatorer.
• Undernät som ska vara värdar för de virtuella arbetsbelastningsdatorerna, ett för klientdelen och ett för serverdelen. Dessa undernät skapas enligt programmets nivåer.
• Ett undernät för Azure Bastion-värden för att underlätta driftåtkomsten till de virtuella arbetsbelastningsdatorerna. Som design behöver Azure Bastion-värden ett dedikerat undernät.
• Ett undernät som ska vara värd för privata slutpunkter som skapats för åtkomst till andra Azure-resurser via Azure Private Link. Även om dedikerade undernät inte är obligatoriska för dessa slutpunkter rekommenderar vi dem.

På samma sätt som virtuella nätverk måste undernäten ha rätt storlek. Du kanske till exempel vill använda den maximala gränsen för virtuella datorer som stöds av flexibel orkestrering för att uppfylla programmets skalningsbehov. Arbetsbelastningsundernäten bör kunna ta emot den gränsen.

Ett annat användningsfall att tänka på är VM OS-uppgraderingar, vilket kan kräva tillfälliga IP-adresser. Med höger storleksändring får du önskad segmenteringsnivå genom att se till att liknande resurser är grupperade så att meningsfulla säkerhetsregler via nätverkssäkerhetsgrupper (NSG:er) kan tillämpas på undernätsgränserna. Mer information finns i Säkerhet: Segmentering.

Inkommande trafik

Två offentliga IP-adresser används för inkommande flöden. En adress är för Application Gateway som fungerar som omvänd proxy. Användare ansluter med den offentliga IP-adressen. Den omvända proxybelastningen balanserar inkommande trafik till de privata IP-adresserna för de virtuella datorerna. Den andra adressen är för driftåtkomst via Azure Bastion.

Ladda ned en Visio-fil med den här arkitekturen.

Utgående trafik

Den här arkitekturen använder standard-SKU Load Balancer med utgående regler som definierats från VM-instanserna. Load Balancer valdes eftersom det är zonredundant.

Ladda ned en Visio-fil med den här arkitekturen.

Med den här konfigurationen kan du använda de offentliga IP-adresserna för lastbalanseraren för att tillhandahålla utgående Internetanslutning för de virtuella datorerna. Med utgående regler kan du uttryckligen definiera SNAT-portar (source network address translation). Med reglerna kan du skala och finjustera den här möjligheten via manuell portallokering. Om du manuellt allokerar SNAT-porten baserat på serverdelspoolens storlek och antal frontendIPConfigurations kan du undvika SNAT-överbelastning.

Vi rekommenderar att du allokerar portar baserat på det maximala antalet serverdelsinstanser. Om fler instanser läggs till än vad återstående SNAT-portar tillåter kan skalningsåtgärder för vm-skalningsuppsättningar blockeras eller så får de nya virtuella datorerna inte tillräckligt med SNAT-portar.

Beräkna portar per instans som: Number of front-end IPs * 64K / Maximum number of back-end instances.

Det finns andra alternativ som du kan använda, till exempel att distribuera en Azure NAT Gateway-resurs som är kopplad till undernätet. Ett annat alternativ är att använda Azure Firewall eller en annan virtuell nätverksinstallation med en anpassad användardefinierad väg (UDR) som nästa hopp genom brandväggen. Det alternativet visas i baslinjearkitekturen för virtuell dator i en Azure-landningszon.

DNS-upplösning

Azure DNS används som grundläggande tjänst för alla lösningsanvändningsfall, till exempel för att matcha fullständigt kvalificerade domännamn (FQDN) som är associerade med de virtuella arbetsbelastningsdatorerna. I den här arkitekturen använder de virtuella datorerna DE DNS-värden som angetts i konfigurationen för det virtuella nätverket, som är Azure DNS.

Privata DNS-zoner i Azure används för att matcha begäranden till de privata slutpunkter som används för att komma åt de namngivna Private Link-resurserna.

Övervakning

Den här arkitekturen har en övervakningsstack som är frikopplad från verktyget för arbetsbelastningen. Fokus ligger främst på datakällor och insamlingsaspekter.

Mått och loggar genereras vid olika datakällor, vilket ger observerbarhetsinsikter på olika höjder:

• Underliggande infrastruktur och komponenter beaktas, till exempel virtuella datorer, virtuella nätverk och lagringstjänster. Azure-plattformsloggar innehåller information om åtgärder och aktiviteter på Azure-plattformen.

• Programnivån ger insikter om prestanda och beteende för de program som körs i systemet.

Log Analytics-arbetsytan är den rekommenderade övervakningsdatamottagaren som används för att samla in loggar och mått från Azure-resurser och Application Insights.

Den här bilden visar övervakningsstacken för baslinjen med komponenter för att samla in data från infrastrukturen och programmet, datamottagare och olika förbrukningsverktyg för analys och visualisering. Implementeringen distribuerar vissa komponenter, till exempel Application Insights, startdiagnostik för virtuella datorer och Log Analytics. Andra komponenter visas för att visa alternativ för utökningsbarhet, till exempel instrumentpaneler och aviseringar.

Ladda ned en Visio-fil med den här arkitekturen.

Övervakning på infrastrukturnivå

Den här tabellen länkar till loggar och mått som samlas in av Azure Monitor. De tillgängliga aviseringarna hjälper dig att proaktivt åtgärda problem innan de påverkar användarna.

Azure-resurs	Mått och loggar	Aviseringar
Application Gateway	Beskrivning av Application Gateway-mått och loggar	Application Gateway-aviseringar
Programinsikter	Application Insights-mått och loggnings-API	Application Insights-aviseringar
Azure Bastion	Azure Bastion-mått
Key Vault	Key Vault-mått och loggbeskrivningar	Key Vault-aviseringar
Standard Load Balancer	Loggar och mått för lastbalanserare	Load Balancer-aviseringar
Offentlig IP-adress	Beskrivning av mått och loggar för offentliga IP-adresser	Aviseringar om offentliga IP-adressmått
Virtual Network	Referens för mått och loggar för virtuella nätverk	Aviseringar för virtuellt nätverk
Vm-datorer och VM-skalningsuppsättningar	Referens för VM-mått och loggar	VM-aviseringar och självstudier
Brandvägg för webbaserade program	Beskrivning av mått och loggar för brandväggen för webbaserade program	Brandväggsaviseringar för webbaserade program

Mer information om kostnaden för att samla in mått och loggar finns i Log Analytics kostnadsberäkningar och alternativ och priser för Log Analytics-arbetsytan. Arbetsbelastningens natur och frekvensen och antalet mått och loggar som samlas in påverkar i hög grad kostnaderna för mått- och logginsamling.

Virtuella datorer

Azure Boot Diagnostics är aktiverat för att observera de virtuella datorernas tillstånd under start genom att samla in seriell logginformation och skärmbilder. I den här arkitekturen kan dessa data nås via Azure-portalen och kommandot Azure CLI vm boot-diagnostics get-boot-log. Data hanteras av Azure och du har ingen kontroll eller åtkomst till den underliggande lagringsresursen. Men om dina affärskrav kräver mer kontroll kan du etablera ditt eget lagringskonto för att lagra startdiagnostik.

Vm-insikter är ett effektivt sätt att övervaka virtuella datorer och skalningsuppsättningar . Den samlar in data från Log Analytics-arbetsytor och tillhandahåller fördefinierade arbetsböcker för prestandadatatrender. Dessa data kan visas per virtuell dator eller aggregeras över flera virtuella datorer.

Application Gateway och den interna lastbalanseraren använder hälsoavsökningar för att identifiera slutpunktsstatusen för de virtuella datorerna innan trafik skickas.

Nätverk

I den här arkitekturen samlas loggdata in från flera nätverkskomponenter som deltar i flödet. Dessa komponenter omfattar Application Gateway, lastbalanserare och Azure Bastion. De omfattar även nätverkssäkerhetskomponenter som virtuella nätverk, NSG:er, offentliga IP-adresser och Private Link.

Hanterade diskar

Diskmått beror på din arbetsbelastning, vilket kräver en blandning av nyckelmått. Övervakningen bör kombinera dessa perspektiv för att isolera problem med operativsystemet eller programmets dataflöde.

• Azure-plattformsperspektivet representerar de mått som anger Azure-tjänsten, oavsett vilken arbetsbelastning som är ansluten till den. Mått för diskprestanda (IOPS och dataflöde) kan visas individuellt eller kollektivt för alla VM-anslutna diskar. Använd mått för lagrings-I/O-användning för felsökning eller aviseringar om potentiella disktak. Om du använder bursting för kostnadsoptimering övervakar du krediter i procent för att identifiera möjligheter till ytterligare optimering.

• Gästoperativsystemets perspektiv representerar mått som arbetsbelastningsoperatorn skulle visa, oavsett den underliggande disktekniken. VM-insikter rekommenderas för viktiga mått på anslutna diskar, till exempel logiskt diskutrymme som används och OS-kernelns perspektiv på disk-IOPS och dataflöde.

Övervakning på programnivå

Även om referensimplementeringen inte använder den etableras Application Insights som en programprestandahantering (APM) i utökningssyfte. Application Insights samlar in data från ett program och skickar dessa data till Log Analytics-arbetsytan. Den kan också visualisera dessa data från arbetsbelastningsprogram.

Programmets hälsotillägg distribueras till virtuella datorer för att övervaka binärt hälsotillstånd för varje VM-instans i skalningsuppsättningen och utföra instansreparationer om det behövs med hjälp av automatisk instansreparation för skalningsuppsättningen. Den testar för samma fil som Application Gateway och den interna hälsoavsökningen för Azure-lastbalanseraren för att kontrollera om programmet svarar.

Hantering av uppdateringar

Virtuella datorer måste uppdateras och korrigeras regelbundet så att de inte försvagar arbetsbelastningens säkerhetsstatus. Vi rekommenderar automatiska och periodiska VM-utvärderingar för tidig identifiering och tillämpning av korrigeringar.

Infrastrukturuppdateringar

Azure uppdaterar sin plattform regelbundet för att förbättra tillförlitligheten, prestandan och säkerheten för värdinfrastrukturen för virtuella datorer. Dessa uppdateringar omfattar korrigering av programvarukomponenter i värdmiljön, uppgradering av nätverkskomponenter eller avaktivering av maskinvara med mera. Information om uppdateringsprocessen finns i Underhåll för virtuella datorer i Azure.

Om en uppdatering inte kräver en omstart pausas den virtuella datorn medan värden uppdateras, eller så direktmigreras den virtuella datorn till en redan uppdaterad värd. Om underhåll kräver en omstart meddelas du om det planerade underhållet. Azure tillhandahåller också ett tidsfönster där du kan starta underhållet när det passar dig. Information om självunderhållsfönstret och hur du konfigurerar tillgängliga alternativ finns i Hantera meddelanden om planerat underhåll.

Vissa arbetsbelastningar kanske inte tolererar några sekunder av att en virtuell dator fryser eller kopplas från för underhåll. Mer kontroll över alla underhållsaktiviteter, inklusive uppdateringar utan påverkan och omstartslösa uppdateringar finns i Underhållskonfigurationer. När du skapar en underhållskonfiguration kan du hoppa över alla plattformsuppdateringar och tillämpa uppdateringarna när det passar dig. När den här anpassade konfigurationen har angetts hoppar Azure över alla icke-nollpåverkande uppdateringar, inklusive omstartslösa uppdateringar. Mer information finns i Hantera plattformsuppdateringar med underhållskonfigurationer

Operativsystemavbildningsuppgraderingar

När du gör OS-uppgraderingar ska du ha en gyllene avbildning som testas. Överväg att använda Azure Shared Image Gallery och Azure Compute Gallery för att publicera dina anpassade avbildningar. Du bör ha en process på plats som uppgraderar batchar med instanser på ett löpande sätt varje gång en ny avbildning publiceras av utgivaren.

Dra tillbaka VM-avbildningar innan de når sin livslängd för att minska ytan.

Automatiseringsprocessen bör ta hänsyn till överetablering med extra kapacitet.

Du kan använda Azure Update Management för att hantera OS-uppdateringar för dina virtuella Windows- och Linux-datorer i Azure.Azure Update Manager tillhandahåller en SaaS-lösning för att hantera och styra programuppdateringar till Windows- och Linux-datorer i Azure, lokalt och i miljöer med flera moln.

Korrigering av gästoperativsystem

Virtuella Azure-datorer ger möjlighet till automatisk uppdatering av vm-gäst. När den här tjänsten är aktiverad utvärderas virtuella datorer regelbundet och tillgängliga korrigeringar klassificeras. Vi rekommenderar att utvärderingsläget är aktiverat för att tillåta daglig utvärdering för väntande korrigeringar. Utvärdering på begäran kan dock göras som inte utlöser program för korrigeringar. Om utvärderingsläget inte är aktiverat kan du ha manuella sätt att identifiera väntande uppdateringar.

Endast de korrigeringar som klassificeras som kritiska eller säkerhetsrelaterade tillämpas automatiskt i alla Azure-regioner. Definiera anpassade uppdateringshanteringsprocesser som tillämpar andra korrigeringar.

För styrning bör du överväga azure policyn Kräv automatisk os-avbildningskorrigering på vm-skalningsuppsättningar .

Automatisk korrigering kan belasta systemet och kan vara störande eftersom virtuella datorer använder resurser och kan startas om under uppdateringar. Överetablering rekommenderas för belastningshantering. Distribuera virtuella datorer i olika tillgänglighetszoner för att undvika samtidiga uppdateringar och underhålla minst två instanser per zon för hög tillgänglighet. Virtuella datorer i samma region kan få olika korrigeringar, som bör stämmas av över tid.

Tänk på kompromissen med kostnader i samband med överetablering.

Hälsokontroller ingår som en del av den automatiska gästkorrigeringen för virtuella datorer. Dessa kontroller verifierar lyckade korrigeringsprogram och identifierar problem.

Om det finns anpassade processer för att tillämpa korrigeringar använder du privata lagringsplatser för korrigeringskällor. På så sätt får du bättre kontroll när du testar korrigeringarna för att se till att uppdateringen inte påverkar prestanda eller säkerhet negativt.

Mer information finns i Automatisk gästkorrigering av virtuella datorer för virtuella Azure-datorer.

Tillförlitlighet

Den här arkitekturen använder tillgänglighetszoner som ett grundläggande element för att hantera tillförlitlighetsproblem.

I den här konfigurationen är enskilda virtuella datorer knutna till en enda zon. Om ett fel inträffar kan dessa virtuella datorer enkelt ersättas med andra VM-instanser med hjälp av VM-skalningsuppsättningar.

Alla andra komponenter i den här arkitekturen är antingen:

• Zonredundant, vilket innebär att de replikeras över flera zoner för hög tillgänglighet, till exempel Application Gateway eller offentliga IP-adresser.
• Zontålig, vilket innebär att de kan motstå zonfel, till exempel Key Vault.
• Regionala eller globala resurser som är tillgängliga i flera regioner eller globalt, till exempel Microsoft Entra-ID.

Arbetsbelastningsdesign bör innehålla tillförlitlighetsgarantier i programkod, infrastruktur och åtgärder. I följande avsnitt visas några strategier för att se till att arbetsbelastningen är motståndskraftig mot fel och kan återställas om det uppstår avbrott på infrastrukturnivå.

De strategier som används i arkitekturen baseras på checklistan för granskning av tillförlitlighetsdesign som anges i Azure Well-Architected Framework. Avsnitten kommenteras med rekommendationer från den checklistan.

Eftersom inget program har distribuerats ligger återhämtning i programkoden utanför den här arkitekturens omfång. Vi rekommenderar att du granskar alla rekommendationer i checklistan och antar dem i din arbetsbelastning, om tillämpligt.

Prioritera tillförlitlighetsgarantierna per användarflöde

I de flesta designerna finns det flera användarflöden, var och en med sin egen uppsättning affärskrav. Alla dessa flöden kräver inte den högsta nivån av garantier, så segmentering rekommenderas som en tillförlitlighetsstrategi. Varje segment kan hanteras oberoende av varandra, vilket säkerställer att ett segment inte påverkar andra och ger rätt återhämtningsnivå på varje nivå. Den här metoden gör också systemet flexibelt.

I den här arkitekturen implementerar programnivåerna segmenteringen. Separata skalningsuppsättningar etableras för klientdels- och serverdelsnivåer. Den här separationen möjliggör oberoende skalning av varje nivå, vilket möjliggör implementering av designmönster baserat på deras specifika krav, bland andra fördelar.

Se Well-Architected Framework: RE:02 – Rekommendationer för att identifiera och klassificera flöden.

Identifiera potentiella felpunkter

Varje arkitektur är känslig för fel. Med analys av felläge kan du förutse fel och förbereda dig med åtgärder. Här följer några möjliga felpunkter i den här arkitekturen:

Komponent	Risk	Sannolikhet	Effekt/minskning/anmärkning	Avbrott
Microsoft Entra ID	Felaktig konfiguration	Medium	Ops-användare kan inte logga in. Ingen nedströmseffekt. Supportavdelningen rapporterar konfigurationsproblem till identitetsteamet.	Ingen
Application Gateway	Felaktig konfiguration	Medium	Felkonfigurationer bör fångas under distributionen. Om dessa fel inträffar under en konfigurationsuppdatering måste DevOps-teamet återställa ändringarna. De flesta distributioner som använder V2 SKU:n tar cirka 6 minuter att etablera. Det kan dock ta längre tid beroende på typen av distribution. Distributioner över flera tillgänglighetszoner med många instanser kan till exempel ta mer än 6 minuter.	Fullständig
Application Gateway	DDOS-attack	Medium	Risk för avbrott. Microsoft hanterar DDoS-skydd (L3 och L4). Potentiell risk för effekt från L7-attacker.	Fullständig
Virtual Machine Scale Sets	Tjänstavbrott	Låg	Potentiellt avbrott i arbetsbelastningen om det finns instanser av virtuella datorer som inte är felfria som utlöser automatisk förfall. Beroende av Microsoft för att åtgärda.	Potentiellt avbrott
Virtual Machine Scale Sets	Avbrott i tillgänglighetszonen	Låg	Ingen effekt. Skalningsuppsättningar distribueras som zonredundanta.	Ingen

Se Well-Architected Framework: RE:03 – Rekommendationer för analys av felläge.

Tillförlitlighetsmål

För att fatta designbeslut är det viktigt att beräkna tillförlitlighetsmålen, till exempel arbetsbelastningens sammansatta servicenivåmål (SLO). Det innebär att förstå de serviceavtal (SLA) som tillhandahålls av Azure-tjänster som används i arkitekturen. Serviceavtal för arbetsbelastningar får inte vara högre än de serviceavtal som garanteras av Azure. Granska noggrant varje komponent, från virtuella datorer och deras beroenden, nätverk och lagringsalternativ.

Här är en exempelberäkning där huvudmålet är att tillhandahålla ett ungefärligt sammansatt SLO. Även om detta är en grov riktlinje bör du komma fram till något liknande. Du bör inte få ett högre maximalt sammansatt SLO för samma flöden om du inte gör ändringar i arkitekturen.

Åtgärdsflöde

Komponent	Servicenivåmål
Microsoft Entra ID	99,99 %
Azure Bastion	99,95 %

Sammansatt SLO: 99,94 % | Stilleståndstid per år: 0d 5h 15m 20s

Appanvändarflöde

Komponent	Servicenivåmål
Application Gateway	99,95 %
Azure Load Balancer (intern)	99,99 %
Virtuella datorer på klientsidan med premiumlagring (sammansatt SLO)	99.70%
Virtuella serverdelsdatorer med premiumlagring (sammansatt SLO)	99.70%

Sammansatt SLO: 99,34 % | Stilleståndstid per år: 2d 9h 42m 18s

I föregående exempel ingår tillförlitlighet för virtuella datorer och beroenden, till exempel diskar som är associerade med virtuella datorer. Serviceavtalen som är associerade med disklagring påverkar den övergripande tillförlitligheten.

Det finns vissa utmaningar när du beräknar det sammansatta SLO:et. Det är viktigt att observera att olika tjänstnivåer kan komma med olika serviceavtal, och dessa omfattar ofta ekonomiskt säkerhetskopierade garantier som anger tillförlitlighetsmål. Slutligen kan det finnas komponenter i arkitekturen som inte har definierat serviceavtal. När det till exempel gäller nätverk har nätverkskort och virtuella nätverk inte egna serviceavtal.

Affärskraven och deras mål måste vara tydligt definierade och vägas in i beräkningen. Tänk på tjänstbegränsningarna och andra begränsningar som organisationen har infört. Att dela din prenumeration med andra arbetsbelastningar kan påverka de resurser som är tillgängliga för dina virtuella datorer. Arbetsbelastningen kan tillåtas använda ett begränsat antal tillgängliga kärnor för de virtuella datorerna. Att förstå resursanvändningen för din prenumeration kan hjälpa dig att utforma dina virtuella datorer mer effektivt.

Se Well-Architected Framework: RE:04 – Rekommendationer för att definiera tillförlitlighetsmål.

Redundans

Den här arkitekturen använder zonredundans för flera komponenter. Varje zon består av ett eller flera datacenter med oberoende ström, kylning och nätverk. Om instanser körs i separata zoner skyddas programmet mot datacenterfel.

• Vm-skalningsuppsättningar allokerar ett angivet antal instanser och distribuerar dem jämnt mellan tillgänglighetszoner och feldomäner. Den här fördelningen uppnås genom den maximala spridningsfunktionen , vilket vi rekommenderar. Om du sprider virtuella datorinstanser mellan feldomäner ser du till att alla virtuella datorer inte uppdateras samtidigt.

  Tänk dig ett scenario där det finns tre tillgänglighetszoner. Om du har tre instanser allokeras varje instans till en annan tillgänglighetszon och placeras i en annan feldomän. Azure garanterar att endast en feldomän uppdateras i taget i varje tillgänglighetszon. Det kan dock finnas en situation där alla tre feldomänerna som är värdar för dina virtuella datorer i de tre tillgänglighetszonerna uppdateras samtidigt. Alla zoner och domäner påverkas. Om du har minst två instanser i varje zon får du en buffert under uppgraderingarna.

• Hanterade diskar kan bara anslutas till en virtuell dator i samma region. Deras tillgänglighet påverkar vanligtvis tillgängligheten för den virtuella datorn. För distributioner med en region kan diskar konfigureras för redundans för att klara zonfel. I den här arkitekturen konfigureras datadiskar zonredundant lagring (ZRS) på de virtuella serverdelsdatorerna. Det kräver en återställningsstrategi för att dra nytta av tillgänglighetszoner. Återställningsstrategin är att distribuera om lösningen. Helst företablera beräkning i alternativa tillgänglighetszoner som är redo att återställas från ett zonfel.

• En zonredundant Application Gateway eller standardlastbalanserare kan dirigera trafik till virtuella datorer mellan zoner med hjälp av en enda IP-adress, vilket säkerställer kontinuitet även om zonfel inträffar. Dessa tjänster använder hälsoavsökningar för att kontrollera tillgängligheten för virtuella datorer. Så länge en zon i regionen fortfarande är i drift fortsätter routningen trots potentiella fel i andra zoner. Routning mellan zoner kan dock ha högre svarstid jämfört med routning inom zonen.

  Alla offentliga IP-adresser som används i den här arkitekturen är zonredundanta.

• Azure erbjuder zontåliga tjänster för bättre tillförlitlighet, till exempel Key Vault.

• Globala Azure-resurser är alltid tillgängliga och kan växla till en annan region om det behövs, till exempel den grundläggande identitetsprovidern, Microsoft Entra-ID.

Se Well-Architected Framework: RE:05 – Rekommendationer för att utforma för redundans.

Skalningsstrategi

För att förhindra försämring och fel på tjänstnivå säkerställer du tillförlitliga skalningsåtgärder. Skala arbetsbelastningen vågrätt (skala ut), vertikalt (skala upp) eller använd en kombination av båda dessa metoder. Använd Autoskalning i Azure Monitor för att etablera tillräckligt med resurser för att stödja efterfrågan i ditt program utan att allokera mer kapacitet än vad som behövs och medföra onödiga kostnader.

Med autoskalning kan du definiera olika profiler baserat på olika händelsetyper, till exempel tid, schema eller mått. Måttbaserade profiler kan använda inbyggda mått (värdbaserade) eller mer detaljerade mått (mått för virtuella gästdatorer) som kräver installation av Azure Monitor-agenten för att samla in dem. Varje profil innehåller regler för utskalning (ökning) och inskalning (minskning). Överväg att utforska alla olika skalningsscenarier baserat på utformade profiler och utvärdera dem för potentiella loopvillkor som kan orsaka en rad motsatta skalningshändelser. Azure Monitor försöker åtgärda den här situationen genom att vänta på nedkylningsperioden innan den skalar igen.

Även om Azure Virtual Machine Scale Sets i flexibelt läge stöder heterogena miljöer stöds inte automatisk skalning av flera profiler. Överväg att skapa olika skalningsuppsättningar för att hantera dem separat om du planerar att använda autoskalning med mer än en typ av virtuell dator.

Tänk på andra aspekter som bootstrapping, graciösa avstängningar, installation av arbetsbelastningen och alla dess beroenden och diskhantering när du skapar eller tar bort virtuella datorer.

Tillståndskänsliga arbetsbelastningar kan kräva extra hantering för hanterade diskar som behöver leva utanför en arbetsbelastningsinstans. Utforma din arbetsbelastning för datahantering under skalningshändelser för konsekvens, synkronisering, replikering och integritet för arbetsbelastningens data. För dessa scenarier bör du överväga att lägga till förifyllda diskar i skalningsuppsättningar. För användningsfall där skalning används för att förhindra flaskhalsar vid åtkomst till data, planera för partitionering och horisontell partitionering. Mer information finns i Metodtips för autoskalning.

Se Well-Architected Framework: RE:06 – Rekommendationer för att utforma en tillförlitlig skalningsstrategi.

Självåterställning och återställning

Automatiska instansreparationer aktiveras i VM-skalningsuppsättningar för att automatisera återställning från vm-fel. Programhälsotillägget distribueras till virtuella datorer för att stödja identifiering av virtuella datorer och program som inte svarar. För dessa instanser utlöses reparationsåtgärder automatiskt.

Se Well-Architected Framework: Rekommendationer för självåterställning och självbevarande.

Säkerhet

Den här arkitekturen illustrerar några av säkerhetsgarantierna i checklistan för granskning av säkerhetsdesign som anges i Azure Well-Architected Framework. Avsnitten kommenteras med rekommendationer från den checklistan.

Säkerhet refererar inte bara till tekniska kontroller. Vi rekommenderar att du följer hela checklistan för att förstå de operativa aspekterna av säkerhetspelare.

Segmentering

• Nätverkssegmentering. Arbetsbelastningsresurser placeras i ett virtuellt nätverk, vilket ger isolering från Internet. I det virtuella nätverket kan undernät användas som förtroendegränser. Samlokalisera relaterade resurser som behövs för att hantera en transaktion i ett undernät. I den här arkitekturen är det virtuella nätverket indelat i undernät baserat på den logiska gruppering av programmet och syftet med olika Azure-tjänster som används som en del av arbetsbelastningen.

  Fördelen med segmentering av undernät är att du kan placera säkerhetskontroller i perimetern som styr trafik som flödar in och ut ur undernätet, vilket begränsar åtkomsten till arbetsbelastningsresurserna.

• Identitetssegmentering. Tilldela distinkta roller till olika identiteter med tillräcklig behörighet för att utföra sina uppgifter. Den här arkitekturen använder identiteter som hanteras av Microsoft Entra-ID för att segmentera åtkomsten till resurser.

• Resurssegmentering. Programmet segmenteras efter nivåer i separata skalningsuppsättningar, vilket säkerställer att programkomponenterna inte samallokeras.

Se Well-Architected Framework: SE:04 – Rekommendationer för att skapa en segmenteringsstrategi.

Identitets- och åtkomsthantering

Vi rekommenderar Microsoft Entra-ID för autentisering och auktorisering av både användare och tjänster.

Åtkomst till virtuella datorer kräver ett användarkonto som styrs av Microsoft Entra-ID-autentisering och som backas upp av säkerhetsgrupper. Den här arkitekturen ger stöd genom att distribuera Microsoft Entra ID-autentiseringstillägget till alla virtuella datorer. Vi rekommenderar att mänskliga användare använder sina företagsidentiteter i organisationens Microsoft Entra ID-klientorganisation. Se också till att all tjänsthuvudnamnsbaserad åtkomst inte delas mellan funktioner.

Arbetsbelastningsresurser, till exempel virtuella datorer, autentiserar sig själva med hjälp av sina tilldelade hanterade identiteter till andra resurser. Dessa identiteter, baserade på Microsoft Entra ID-tjänstens huvudnamn, hanteras automatiskt.

Key Vault-tillägg installeras till exempel på virtuella datorer som startar de virtuella datorerna med certifikat på plats. I den här arkitekturen används användartilldelade hanterade identiteter av Application Gateway, virtuella datorer på klientsidan och virtuella serverdelsdatorer för att få åtkomst till Key Vault. Dessa hanterade identiteter konfigureras under distributionen och används för autentisering mot Key Vault. Åtkomstprinciper i Key Vault är konfigurerade för att endast acceptera begäranden från föregående hanterade identiteter.

Baslinjearkitekturen använder en blandning av systemtilldelade och användartilldelade hanterade identiteter. Dessa identiteter krävs för att använda Microsoft Entra-ID för auktoriseringsändamål vid åtkomst till andra Azure-resurser.

Se Well-Architected Framework: SE:05 – Rekommendationer för identitets- och åtkomsthantering.

Nätverkskontroller

• Inkommande trafik. De virtuella arbetsbelastningsdatorerna exponeras inte direkt för det offentliga Internet. Varje virtuell dator har en privat IP-adress. Arbetsbelastningsanvändare ansluter med hjälp av den offentliga IP-adressen för Application Gateway.

  Mer säkerhet ges via brandväggen för webbprogram som är integrerad med Application Gateway. Den har regler som inspekterar inkommande trafik och kan vidta lämpliga åtgärder. WAF spårar OWASP-sårbarheter (Open Web Application Security Project) som förhindrar kända attacker.

• Utgående trafik. Det finns inga kontroller för utgående trafik förutom de utgående NSG-reglerna på de virtuella datorundernäten. Vi rekommenderar att all utgående Internettrafik flödar genom en enda brandvägg. Den här brandväggen är vanligtvis en central tjänst som tillhandahålls av en organisation. Det användningsfallet visas i baslinjearkitekturen för virtuell dator i en Azure-landningszon.

• Öst-västlig trafik. Trafikflödet mellan undernäten begränsas genom att detaljerade säkerhetsregler tillämpas.

  Nätverkssäkerhetsgrupper (NSG:er) placeras för att begränsa trafiken mellan undernät baserat på parametrar som IP-adressintervall, portar och protokoll. Programsäkerhetsgrupper (ASG) placeras på virtuella datorer på klientsidan och serverdelen. De används med NSG:er för att filtrera trafik till och från de virtuella datorerna.

• Driftstrafik. Vi rekommenderar att säker driftåtkomst till en arbetsbelastning tillhandahålls via Azure Bastion, vilket tar bort behovet av en offentlig IP-adress. I den här arkitekturen är kommunikationen via SSH och stöds av både virtuella Windows- och Linux-datorer. Microsoft Entra ID är integrerat med SSH för båda typerna av virtuella datorer med hjälp av motsvarande VM-tillägg. Med den integreringen kan en operatörs identitet autentiseras och auktoriseras via Microsoft Entra-ID.

  Du kan också använda en separat virtuell dator som en hoppruta, distribuerad till ett eget undernät, där du kan installera ditt val av administratörs- och felsökningsverktyg. Operatorn kommer åt hopprutan via Azure Bastion-värden. Sedan loggar de in på de virtuella datorerna bakom lastbalanseraren från hopprutan.

  I den här arkitekturen skyddas drifttrafik med hjälp av NSG-regler för att begränsa trafiken, och just-in-time-åtkomst (JIT) för virtuella datorer aktiveras på de virtuella datorerna. Den här funktionen i Microsoft Defender för molnet tillåter tillfällig inkommande åtkomst till valda portar.

  För förbättrad säkerhet använder du Microsoft Entra Privileged Identity Management (PIM). PIM är en tjänst i Microsoft Entra-ID som gör att du kan hantera, kontrollera och övervaka åtkomst till viktiga resurser i din organisation. PIM tillhandahåller tidsbaserad och godkännandebaserad rollaktivering för att minska risken för överdriven, onödig eller missbrukad åtkomstbehörighet för resurser som du bryr dig om.

• Privat anslutning till PaaS-tjänster (plattform som en tjänst). Kommunikationen mellan de virtuella datorerna och Key Vault sker via Private Link. Den här tjänsten kräver privata slutpunkter som placeras i ett separat undernät.

• DDoS-skydd. Överväg att aktivera Azure DDoS Protection på offentliga IP-adresser som exponeras av Application Gateway och Azure Bastion Host för att identifiera hot. DDoS Protection tillhandahåller även aviseringar, telemetri och analys via Monitor. Mer information finns i Azure DDoS Protection: Metodtips och referensarkitekturer.

Se Well-Architected Framework: SE:06 – Rekommendationer för nätverk och anslutning.

Kryptering

• Data under överföring. Användartrafik mellan användare och den offentliga IP-adressen för Application Gateway krypteras med hjälp av det externa certifikatet. Trafik mellan programgatewayen och de virtuella datorerna på klientsidan och mellan de virtuella datorerna i klientdelen och serverdelen krypteras med hjälp av ett internt certifikat. Båda certifikaten lagras i Key Vault:

  • app.contoso.com: Ett externt certifikat som används av klienter och Application Gateway för säker offentlig Internettrafik.
  • *.workload.contoso.com: Ett jokerteckencertifikat som används av infrastrukturkomponenterna för säker intern trafik.

• Vilande data. Loggdata lagras på en hanterad disk som är ansluten till virtuella datorer. Dessa data krypteras automatiskt med hjälp av plattformsbaserad kryptering i Azure.

Se Well-Architected Framework: SE:07 – Rekommendationer för datakryptering.

Hemlighetshantering

Ladda ned en Visio-fil med den här arkitekturen.

Key Vault tillhandahåller säker hantering av hemligheter, inklusive TLS-certifikat. I den här arkitekturen lagras TLS-certifikaten i Key Vault och hämtas under etableringsprocessen av de hanterade identiteterna för Application Gateway och de virtuella datorerna. Efter den första installationen kommer dessa resurser bara åt Key Vault när certifikaten uppdateras.

De virtuella datorerna använder tillägget för den virtuella Key Vault-datorn för att automatiskt uppdatera de övervakade certifikaten. Om några ändringar identifieras i det lokala certifikatarkivet hämtar och installerar tillägget motsvarande certifikat från Key Vault. Tillägget stöder certifikatinnehållstyperna PKCS #12 och PEM.

Se Well-Architected Framework: SE:09 – Rekommendationer för att skydda programhemligheter.

Kostnadsoptimering

Arbetsbelastningskraven måste uppfyllas med tanke på kostnadsbegränsningarna. De strategier som används i arkitekturen baseras på checklistan för kostnadsoptimeringsdesign som anges i Azure Well-Architected Framework. I det här avsnittet beskrivs några alternativ för att optimera kostnader och kommenteras med rekommendationer från checklistan.

Komponentkostnad

Välj VM-avbildningar som är optimerade för arbetsbelastningen i stället för att använda allmänna avbildningar. I den här arkitekturen väljs relativt små VM-avbildningar för både Windows och Linux, som är 30 GB vardera. Med mindre avbildningar är vm-SKU:er med diskar också mindre, vilket leder till lägre kostnader, minskad resursförbrukning och snabbare distributions- och starttider. En fördel är förbättrad säkerhet på grund av den minskade ytan.

Att implementera loggrotation med storleksgränser är en annan strategi för kostnadsbesparande. Det möjliggör användning av små datadiskar, vilket kan leda till lägre kostnader. Implementeringen av den här arkitekturen använder 4 GB diskar.

Användningen av tillfälliga OS-diskar kan också leda till kostnadsbesparingar och bättre prestanda. Dessa diskar är utformade för att använda virtuella datorresurser som du redan betalar för eftersom de är installerade på cachedisken som har etablerats med den virtuella datorn. Det eliminerar lagringskostnader som är associerade med traditionella beständiga diskar. Eftersom dessa diskar är tillfälliga finns det inga kostnader som är kopplade till långsiktig datalagring.

Se Well-Architected Framework: CO:07 – Rekommendationer för att optimera komponentkostnader.

Flödeskostnad

Välj beräkningsresurser baserat på hur kritiskt flödet är. För flöden som är utformade för att tolerera en obestämd längd bör du överväga att använda virtuella datorer med oanvänd kapacitet med flexibel orkestreringsläge för vm-skalningsuppsättningar. Den här metoden kan vara effektiv för att hantera lågprioriterade flöden på virtuella datorer med lägre prioritet. Den här strategin möjliggör kostnadsoptimering samtidigt som kraven för olika flöden uppfylls.

Se Well-Architected Framework: CO:09 – Rekommendationer för att optimera flödeskostnader.

Skalningskostnad

Om den huvudsakliga kostnadsdrivande faktorn är antalet instanser kan det vara mer kostnadseffektivt att skala upp genom att öka storleken eller prestandan för de virtuella datorerna. Den här metoden kan leda till kostnadsbesparingar på flera områden:

• Programvarulicensiering. Större virtuella datorer kan hantera mer arbetsbelastning, vilket kan minska antalet programvarulicenser som krävs.
• Underhållstid: Färre, större virtuella datorer kan minska driftskostnaderna.
• Belastningsutjämning: Färre virtuella datorer kan leda till lägre kostnader för belastningsutjämning. I den här arkitekturen finns till exempel flera lager av belastningsutjämning, till exempel en programgateway längst fram och en intern lastbalanserare i mitten. Belastningsutjämningskostnaderna skulle öka om ett högre antal instanser behöver hanteras.
• Disklagring. Om det finns tillståndskänsliga program behöver fler instanser fler anslutna hanterade diskar, vilket ökar kostnaden för lagring.

Se Well-Architected Framework: CO:12 – Rekommendationer för att optimera skalningskostnader.

Driftskostnader

Automatisk gästkorrigering av virtuella datorer minskar kostnaderna för manuell korrigering och tillhörande underhållskostnader. Den här åtgärden hjälper inte bara till att göra systemet säkrare, utan även optimerar resursallokering, vilket bidrar till den totala kostnadseffektiviteten.

Se Well-Architected Framework: CO:13 – Rekommendationer för att optimera personaltiden.

Distribuera det här scenariot

En distribution för denna referensarkitektur finns på GitHub.

Relaterade resurser

Mer information om specifika Azure-tjänster finns i produktdokumentationen:

• Azure Virtual Machines
• Skalningsuppsättningar för virtuella Microsoft Azure-datorer
• Azure Virtual Network
• Azure Application Gateway-Standard_v2
• Azure Load Balancer
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

Gå vidare

Granska IaaS-referensarkitekturerna som visar alternativ för datanivån:

• Windows N-nivåprogram med SQL Server i Azure