Den här referensarkitekturen visar hur du distribuerar virtuella datorer och ett virtuellt nätverk som konfigurerats för ett N-nivåprogram med hjälp av SQL Server på Windows för datanivån. Distribuera den här lösningen.
Ladda ned en Visio-fil med den här arkitekturen.
Arkitektur
Arkitekturen har följande komponenter:
Allmänt
Resursgrupp. Resursgrupper används för att gruppera Azure-resurser så att de kan hanteras efter livslängd, ägare eller andra kriterier.
Tillgänglighetszoner. Tillgänglighetszoner är fysiska platser i en Azure-region. Varje zon består av ett eller flera datacenter med oberoende strömförsörjning, kylning och nätverk. Genom att placera virtuella datorer mellan zoner blir programmet motståndskraftigt mot fel i en zon.
Nätverk och belastningsutjämning
Virtuellt nätverk och undernät. Varje virtuell Azure-dator distribueras till ett virtuellt nätverk som kan delas upp i undernät. Skapa ett separat undernät för varje nivå.
Application Gateway. Application Gateway är en Layer 7-lastbalanserare. I den här arkitekturen dirigeras HTTP-begäranden till webb-frontend. Application Gateway också en brandvägg för webbaserade program (WAF) som skyddar programmet mot vanliga kryphål och säkerhetsproblem.
Lastbalanserare. Använd Azure Standard Load Balancer för att distribuera nätverkstrafik från webbnivån till affärsnivån och från affärsnivån till SQL Server.
Nätverkssäkerhetsgrupper (NSG:er). Använd NSG:er för att begränsa nätverkstrafiken i det virtuella nätverket. I arkitekturen med tre nivåer som visas här accepterar till exempel inte databasnivån trafik från webbwebbdelen, endast från affärsnivån och hanteringsundernätet.
DDoS Protection. Även om Azure-plattformen ger grundläggande skydd mot DDoS-attacker (Distributed Denial of Service) rekommenderar vi att du använder DDoS Protection Standard, som har förbättrade DDoS-skyddsfunktioner. Se Säkerhetsöverväganden.
Azure DNS. Azure DNS är en värdtjänst för DNS-domäner. Den tillhandahåller namnmatchning med hjälp Microsoft Azure infrastruktur. Genom att använda Azure som värd för dina domäner kan du hantera dina DNS-poster med samma autentiseringsuppgifter, API:er, verktyg och fakturering som för dina andra Azure-tjänster.
Virtuella datorer
SQL Server Always On-tillgänglighetsgrupp. Ger hög tillgänglighet på datanivån, genom att aktivera replikering och redundans. Den använder Windows Server Failover Cluster (WSFC)-teknik för redundans.
Active Directory Domain Services-servrar (AD DS-servrar). Datorobjekten för redundansklustret och dess associerade klustrade roller skapas i Active Directory Domain Services (AD DS).
Molnvittne. Ett redundanskluster kräver att mer än hälften av noderna körs, vilket kallas kvorum. Om klustret bara har två noder kan en nätverkspartition göra så att varje nod tror att det är den primära noden. I så fall behöver du ett vittne för att bryta oavgjort och upprätta kvorum. Ett vittne är en resurs, till exempel en delad disk som kan fungera som en oavgjord brytare för att upprätta kvorum. Molnvittne är en typ av vittne som använder Azure Blob Storage. Mer information om kvorumbegreppet finns i Förstå kluster- och poolkvorum. Mer information om molnvittne finns i Distribuera ett molnvittne för ett redundanskluster.
Jumpbox. Kallas även för en skyddsmiljö-värd. Traditionellt sett en säker virtuell dator i nätverket som administratörer använder för att ansluta till andra virtuella datorer. Jumpboxen har en NSG som endast tillåter fjärrtrafik från offentliga IP-adresser på en säker lista. NSG:n bör tillåta Remote Desktop Protocol (RDP)-trafik. Azure erbjuder den hanterade lösningen Azure Bastion att uppfylla detta behov.
Rekommendationer
Dina krav kan vara annorlunda från den arkitektur som beskrivs här. Använd de här rekommendationerna som utgångspunkt.
Virtuella datorer
Rekommendationer om hur du konfigurerar de virtuella datorerna finns i Köra en Windows virtuell dator på Azure.
Virtuellt nätverk
När du skapar det virtuella nätverket ska du bestämma hur många IP-adresser dina resurser i varje undernät kräver. Ange en nätmask och ett nätverksadressintervall som är tillräckligt stort för de IP-adresser som krävs, med hjälp av CIDR-notation. Använd ett adressutrymme som ligger inom standarden för privata IP-adressblock, som är 10.0.0.0/8, 172.16.0.0/12 och 192.168.0.0/16.
Välj ett adressintervall som inte överlappar ditt lokala nätverk om du behöver konfigurera en gateway mellan det virtuella nätverket och ditt lokala nätverk senare. När du har skapat det virtuella nätverket kan du inte ändra adressintervallet.
Utforma undernät och ha både funktionalitet och säkerhetskrav i åtanke. Alla virtuella datorer inom samma nivå eller roll bör ingå i samma undernät, vilket kan vara en säkerhetsgräns. Mer information om hur du utformar virtuella nätverk och undernät finns i Planera och utforma virtuella Azure-nätverk.
Application Gateway
Information om hur du konfigurerar Application Gateway finns i Application Gateway översikt över konfiguration.
Lastbalanserare
Exponera inte de virtuella datorerna direkt på Internet, utan ge i stället varje virtuell dator en privat IP-adress. Klienter ansluter med den offentliga IP-adress som är associerad med Application Gateway.
Definiera regler för lastbalanseraren för att dirigera nätverkstrafik till de virtuella datorerna. Om du till exempel vill aktivera HTTP-trafik mappar du port 80 från frontend-konfigurationen till port 80 på serversidans adresspool. När en klient skickar en HTTP-begäran till port 80 väljer lastbalanseraren en serverdels-IP-adress med hjälp av en hash-algoritm som innehåller källans IP-adress. Klientbegäranden distribueras över alla virtuella datorer i backend-adresspoolen.
Nätverkssäkerhetsgrupper
Använd NSG-regler för att begränsa trafiken mellan nivåer. I arkitekturen med tre nivåer som visas ovan kommunicerar webbnivån inte direkt med databasnivån. För att framtvinga den här regeln ska databasnivån blockera inkommande trafik från undernätet på webbnivå.
- Neka all inkommande trafik från det virtuella nätverket. (Använd taggen
VIRTUAL_NETWORKi regeln.) - Tillåt inkommande trafik från undernätet på företagsnivå.
- Tillåt inkommande trafik från själva undernätet på databasnivå. Den här regeln tillåter kommunikation mellan databasens virtuella datorer, vilket krävs för databasreplikering och redundans.
- Tillåt RDP-trafik (port 3389) från jumpbox-undernätet. Den här regeln låter administratörer ansluta till databasnivån från jumpbox.
Skapa regler 2–4 med högre prioritet än den första regeln, så de åsidosätter den.
SQL Server Always On-tillgänglighetsgrupper
Vi rekommenderar Always On-tillgänglighetsgrupper för SQL Server med hög tillgänglighet. Före Windows Server 2016 kräver Always On-tillgänglighetsgrupper en domänkontrollant, och alla noder i tillgänglighetsgruppen måste ingå i samma AD-domän.
Andra nivåer ansluts till databasen via en lyssningsfunktion för tillgänglighetsgrupp. Genom lyssningsfunktionen kan en SQL-klient ansluta utan att känna till namnet på den fysiska instansen av SQL-servern. Virtuella datorer med åtkomst till databasen måste vara anslutna till domänen. Klienten (i det här fallet en annan nivå) använder DNS för att omvandla namnet på lyssningsfunktionens virtuella nätverk till IP-adresser.
Konfigurera SQL Server Always On-tillgänglighetsgruppen på följande sätt:
Skapa ett WSFC-kluster (Windows Server Failover Clustering), en SQL Server Always On-tillgänglighetsgrupp och en primär replik. Mer information finns i Komma igång med SQL Server Always On-tillgänglighetsgrupper.
Skapa en intern lastbalanserare med en statisk, privat IP-adress.
Skapa en lyssningsfunktion för tillgänglighetsgrupp och mappa lyssningsfunktionens DNS-namn till IP-adressen för en intern lastbalanserare.
Skapa en lastbalanseringsregel för SQL Server-lyssningsporten (TCP-port 1433 som standard). Lastbalanseringsregeln måste aktivera flytande IP, även kallat direkt serverreturnering. Det här gör att den virtuella datorn svarar direkt på klienten, vilket möjliggör en direkt anslutning till den primära repliken.
Anteckning
När flytande IP är aktiverat måste portnumret för klientdelen vara samma som backend-portnumret i lastbalanseringsregeln.
När en SQL-klient försöker ansluta dirigerar lastbalanseraren anslutningsbegäran till den primära repliken. Om det finns en redundans till en annan replik dirigerar lastbalanseraren automatiskt nya begäranden till en ny primär replik. Mer information finns i Konfigurera en ILB-lyssnare för SQL Server AlwaysOn-tillgänglighetsgrupper.
Befintliga klientanslutningar stängs under en redundansväxling. När redundansväxlingen är klar vidarebefordras nya anslutningar till den nya primära repliken.
Om din tillämpning utför betydligt fler läsningar än skrivningar kan du omfördela några av de skrivskyddade frågorna till en sekundär replik. Se Ansluta till en skrivskyddad sekundär replik (skrivskyddad routning) med en lyssnare.
Testa distributionen genom att framtvinga en manuell redundansväxling av tillgänglighetsgruppen.
Jumpbox
När du kör virtuella datorer i ett privat virtuellt nätverk, som i den här arkitekturen, finns det ett behov av att komma åt virtuella datorer för programinstallation, korrigering och så vidare. Men att göra dessa datorer tillgängliga för det offentliga Internet är inte en bra idé eftersom det ökar attackytan avsevärt. I stället används en jumpbox som ett mellanåtkomstlager.
Tidigare kan en virtuell dator som hanteras av kunden användas som en jumpbox. I det scenariot gäller följande rekommendationer:
- Tillåt inte RDP-åtkomst från det offentliga Internet till de virtuella datorer som kör programarbetsbelastningen. I stället bör all RDP-åtkomst till dessa virtuella datorer gå via jumpboxen. En administratör loggar in på jumpboxen och loggar sedan in på den andra virtuella datorn från jumpboxen. Jumpbox tillåter RDP-trafik från Internet, men endast från kända, säkra IP-adresser.
- Jumpboxen har minimala prestandakrav, så välj en liten VM-storlek. Skapa en offentlig IP-adress för jumpbox. Placera jumpboxen i samma virtuella nätverk som de andra virtuella datorerna, men i ett separat hanteringsundernät.
- För att skydda jumpboxen lägger du till en NSG-regel som endast tillåter RDP-anslutningar från en säker uppsättning offentliga IP-adresser. Konfigurera NSG:er för andra undernät så att RDP-trafik från hanteringsundernätet tillåts.
För en kund hanterad virtuell dator gäller alla dessa regler. Den aktuella rekommendationen är dock att använda Azure Bastion, en hanterad jumpbox-lösning som tillåter HTML5-åtkomst till RDP eller SSH bakom Azure AD-skydd. Det här är en mycket enklare lösning som i slutänden har en lägre total ägandekostnad (TCO) för kunden.
Skalbarhetsöverväganden
Skalningsuppsättningar
För webb- och affärsnivåer bör du överväga att använda VM-skalningsuppsättningar i stället för att distribuera separata virtuella datorer. En skalningsuppsättning gör det enkelt att distribuera och hantera en uppsättning identiska virtuella datorer och autoskala de virtuella datorerna baserat på prestandamått. När belastningen på de virtuella datorerna ökar läggs ytterligare virtuella datorer automatiskt till i lastbalanseraren. Överväg skalningsuppsättningar om du snabbt behöver skala upp virtuella datorer eller behöver använda autoskalning.
Det finns två grundläggande sätt att konfigurera virtuella datorer som har distribueras i en skalningsuppsättning:
Använd tillägg för att konfigurera den virtuella datorn när den har distribuerats. Nya VM-instanser kan ta längre tid att starta än en virtuell dator utan tillägg med den här metoden.
Distribuera en hanterad disk med en anpassad diskavbildning. Det här alternativet kan gå snabbare att distribuera. Det kräver dock att du håller avbildningen uppdaterad.
Mer information finns i Designöverväganden för skalningsuppsättningar.
Tips
När du använder en autoskalningslösning bör du testa den med arbetsbelastningar på produktionsnivå i förväg.
Prenumerationsgränser
Varje Azure-prenumeration har standardgränser, inklusive ett maximalt antal virtuella datorer per region. Du kan höja gränsen genom att arkivera en supportbegäran. Läs mer i dokumentationen om Azure-prenumeration och tjänstbegränsningar, kvoter och krav.
Application Gateway
Application Gateway har stöd för fast kapacitet eller autoskalningsläge. Läget för fast kapacitet är användbart för scenarier med konsekventa och förutsägbara arbetsbelastningar. Överväg att använda autoskalningsläge för arbetsbelastningar med variabel trafik. Mer information finns i Autoskalning och Zonredundant Application Gateway v2
Överväganden för tillgänglighet
Tillgänglighetszoner ger bästa möjliga återhämtningsförmåga inom en enda region. Om du behöver ännu högre tillgänglighet bör du överväga att replikera programmet mellan två regioner med hjälp Azure Traffic Manager för redundans. Mer information finns i N-nivåprogram med flera regioner för hög tillgänglighet.
Alla regioner stöder inte tillgänglighetszoner, och alla VM-storlekar stöds inte i alla zoner. Kör följande Azure CLI-kommando för att hitta de zoner som stöds för varje VM-storlek inom en region:
az vm list-skus --resource-type virtualMachines --zone false --location <location> \
--query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table
Om du distribuerar den här arkitekturen till en region som inte stöder tillgänglighetszoner ska du placera de virtuella datorerna för varje nivå i en tillgänglighetsuppsättning. Virtuella datorer i samma tillgänglighetsuppsättning distribueras över flera fysiska servrar, beräkningsrack, lagringsenheter och nätverksväxlar för redundans. Skalningsuppsättningar använder automatiskt placeringsgrupper, som fungerar som en implicit tillgänglighetsuppsättning.
När du distribuerar till tillgänglighetszoner använder du standard-SKU för Azure Load Balancer och v2-SKU för Application Gateway. Dessa SKU:er stöder redundans mellan zoner. Mer information finns i:
- Standard Load Balancer och tillgänglighetszoner
- Automatisk skalning och zonredundant Application Gateway v2
- Hur stöder Application Gateway hög tillgänglighet och skalbarhet?
En enda Application Gateway kan köra flera instanser av gatewayen. För produktionsarbetsbelastningar kör du minst två instanser.
Hälsotillståndsavsökningar
Application Gateway och Load Balancer använder både hälsoavsökningar för att övervaka tillgängligheten för VM-instanser.
- Application Gateway använder alltid en HTTP-avsökning.
- Load Balancer kan testa HTTP eller TCP. Om en virtuell dator kör en HTTP-server använder du i allmänhet en HTTP-avsökning. Annars använder du TCP.
Om en avsökning inte kan nå en instans inom en tidsgräns, slutar gatewayen eller lastbalanseraren att skicka trafik till den virtuella datorn. Avsökningen fortsätter att kontrollera och returnerar den virtuella datorn till backend-poolen om den virtuella datorn blir tillgänglig igen.
HTTP-avsökningar skickar en HTTP GET-begäran till en angiven sökväg och lyssnar efter ett HTTP 200-svar. Den här sökvägen kan vara rotsökvägen ("/") eller en slutpunkt för hälsoövervakning som implementerar anpassad logik för att kontrollera hälsotillståndet för programmet. Slutpunkten måste tillåta anonyma HTTP-begäranden.
Mer information om hälsoavsökningar finns i:
Överväganden om hur du utformar en slutpunkt för hälsoavsökning finns i Health Endpoint Monitoring pattern (Övervakningsmönster för slutpunktshälsa).
Kostnadsöverväganden
Använd Priskalkylatorn för Azure för att beräkna kostnader. Här är några andra överväganden.
Skalningsuppsättningar för virtuella datorer
VM-skalningsuppsättningar är tillgängliga på alla Windows VM-storlekar. Du debiteras bara för de virtuella Azure-datorer som du distribuerar och eventuella ytterligare underliggande infrastrukturresurser som förbrukas, till exempel lagring och nätverk. Det finns inga inkrementella avgifter för vm-skalningsuppsättningar-tjänsten.
Prisalternativ för enskilda virtuella datorer finns i Windows för virtuella datorer
SQL-server
Om du väljer Azure SQL DBaas kan du spara på kostnader eftersom du inte behöver konfigurera en Always On-tillgänglighetsgrupp och domänkontrollantdatorer. Det finns flera distributionsalternativ från enkel databas upp till hanterad instans eller elastiska pooler. Mer information finns i Priser för Azure SQL .
Prisalternativ SQL server-VM:ar finns i SQL för virtuella datorer.
Lastbalanserare
Du debiteras endast för antalet konfigurerade regler för belastningsutjämning och utgående trafik. Ingående NAT-regler är kostnadsfria. Det debiteras ingen timkostnad för Standard Load Balancer inga regler har konfigurerats.
Mer information finns i kostnadsavsnittet i Microsoft Azures välstrukturerade ramverk.
Säkerhetsöverväganden
Virtuella nätverk utgör en gräns för isolering av trafik i Azure. Som standard kan virtuella datorer i ett virtuellt nätverk inte kommunicera direkt med virtuella datorer i ett annat virtuellt nätverk. Du kan dock uttryckligen ansluta virtuella nätverk med hjälp av peering för virtuella nätverk.
NSG:er. Använd nätverkssäkerhetsgrupper (NSG:er) för att begränsa trafiken till och från Internet. Mer information finns i Microsofts molntjänster och nätverkssäkerhet.
DMZ. Överväg att lägga till en virtuell nätverksinstallation (NVA) för att skapa en DMZ mellan det offentliga Internet och det virtuella Azure-nätverket. NVA är ett allmänt begrepp för en virtuell installation som kan utföra nätverksrelaterade uppgifter, till exempel för brandväggen, paketinspektion, granskning och anpassad routning. Mer information finns i Implementera en DMZ mellan Azure och Internet.
Kryptering. Kryptera känsliga, vilande data och hantera krypteringsnycklar för databasen med Azure Key Vault. Key Vault kan lagra krypteringsnycklar i maskinvarusäkerhetsmoduler (HSM:er). Mer information finns i Konfigurera Azure Key Vault-integrering för SQL Server på Azure Virtual Machines. Vi rekommenderar också att du lagrar programhemligheter, till exempel databasanslutningssträngar, i Key Vault.
DDoS-skydd. Azure-plattformen tillhandahåller grundläggande DDoS-skydd som standard. Det här grundläggande skyddet är riktat mot att skydda Azure-infrastrukturen som helhet. Även om grundläggande DDoS-skydd aktiveras automatiskt rekommenderar vi att du använder DDoS Protection Standard. Standardskydd använder anpassningsbar justering, baserat på programmets nätverkstrafikmönster, för att identifiera hot. På så sätt kan den tillämpa åtgärder mot DDoS-attacker som kan gå obemärkt förbi av de infrastrukturomfattande DDoS-principerna. Standardskydd ger även aviseringar, telemetri och analys via Azure Monitor. Mer information finns i Azure DDoS Protection: Metodtips och referensarkitekturer.
DevOps-överväganden
I den här arkitekturen använder du [Azure-byggblockmallar][azbb-template] för att etablera Azure-resurserna och dess beroenden. Eftersom alla huvudresurser och deras beroenden finns i samma virtuella nätverk är de isolerade i samma grundläggande arbetsbelastning, vilket gör det enklare att associera arbetsbelastningens specifika resurser till ett team, så att teamet kan hantera alla aspekter av dessa resurser oberoende av varandra. Den här isoleringen gör att DevOps kan utföra kontinuerlig integrering och kontinuerlig leverans (CI/CD).
Du kan också använda olika distributionsmallar och integrera dem med Azure DevOps Services för att etablera olika miljöer på några minuter, till exempel för att replikera produktion som scenarier eller belastningstestmiljöer endast när det behövs, vilket sparar kostnader.
I den här sceanario konfigureras dina virtuella datorer med hjälp av Tillägg för virtuella datorer, eftersom de erbjuder möjligheten att installera viss ytterligare programvara, till exempel program mot skadlig kod och säkerhetsagenter. VM-tillägg installeras och körs endast när den virtuella datorn skapas. Det innebär att om operativsystemet konfigureras felaktigt i ett senare skede, kräver det en manuell åtgärd för att flytta tillbaka det till rätt tillstånd..
Konfigurationshanteringsverktyg, särskilt Desired State Configuration (DSC), används i den här arkitekturen för att konfigurera Active Directory och en SQL Server Always On-tillgänglighetsgrupp.
Överväg att använda Azure Monitor för att analysera och optimera prestanda för din infrastruktur samt övervaka och diagnostisera nätverksproblem utan att logga in på dina virtuella datorer. Program Insights är i själva verket en av komponenterna i Azure Monitor, vilket ger dig omfattande mått och loggar för att verifiera tillståndet för ditt fullständiga Azure-landskap. Azure Monitor hjälper dig att följa infrastrukturens tillstånd.
Se inte bara till att övervaka dina beräkningselement som stöder din programkod, utan även din dataplattform, särskilt dina databaser, eftersom en låg prestanda för datanivån för ett program kan få allvarliga konsekvenser.
För att testa Azure-miljön där programmen körs bör den vara versionsstyrd och distribuerad via samma mekanismer som programkoden. Sedan kan den testas och valideras med hjälp av DevOps-testparadigm.
Mer information finns i avsnittet Operational Excellence i Azure Well-Architected Framework.
Distribuera lösningen
En distribution för denna referensarkitektur finns på GitHub. Hela distributionen kan ta upp till en timme, vilket innefattar att köra skripten för att konfigurera AD DS, Windows Server-redundansklustret och SQL Server tillgänglighetsgruppen.
Om du anger en region som stöder tillgänglighetszoner distribueras de virtuella datorerna till tillgänglighetszoner. Annars distribueras de virtuella datorerna till tillgänglighetsuppsättningar. En lista över regioner som stöder tillgänglighetszoner finns i Tjänstsupport efter region.
Förutsättningar
Klona, förgrena eller ladda ned ZIP-filen för GitHub-lagringsplatsen för referensarkitekturer.
Installera Azure CLI 2.0.
Installera Node och NPM
Installera npm-paketet Azure-byggblock.
npm install -g @mspnp/azure-building-blocksLogga in på ditt Azure-konto från en kommandotolk, bash-kommandotolk eller PowerShell-kommandotolk enligt följande:
az login
Distributionssteg
Navigera till mappen
virtual-machines\n-tier-windowsför referensarkitekturerna på GitHub lagringsplats.Öppna filen
n-tier-windows.json.I filen
n-tier-windows.jsonsöker du efter alla instanser av och[replace-with-password][replace-with-safe-mode-password]ersätter dem med ett starkt lösenord. Spara filen.Anteckning
Om du ändrar administratörens användarnamn måste du även uppdatera
extensionsblocken i JSON-filen.Kör följande kommando för att distribuera arkitekturen.
azbb -s <your subscription_id> -g <resource_group_name> -l <location> -p n-tier-windows.json --deployNär distributionen är klar öppnar du Azure Portal och går till resursgruppen. Hitta det lagringskonto som börjar med "sqlcw". Det här är det lagringskonto som ska användas för klustrets molnvittne. Navigera till lagringskontot, välj Åtkomstnycklaroch kopiera värdet för . Kopiera även namnet på lagringskontot.
Öppna filen
n-tier-windows-sqlao.json.I filen
n-tier-windows-sqlao.jsonsöker du efter alla instanser av och[replace-with-password][replace-with-sql-password]ersätter dem med ett starkt lösenord.Anteckning
Om du ändrar administratörens användarnamn måste du även uppdatera
extensionsblocken i JSON-filen.I filen
n-tier-windows-sqlao.jsonsöker du efter alla instanser av och[replace-with-storageaccountname][replace-with-storagekey]ersätter dem med värdena från steg 5. Spara filen.Kör följande kommando för att konfigurera SQL Server Always On.
azbb -s <your subscription_id> -g <resource_group_name> -l <location> -p n-tier-windows-sqlao.json --deploy