Det virtuella datacentret: Ett nätverksperspektiv

Program som migreras lokalt kan dra nytta av Azures säkra kostnadseffektiva infrastruktur, även med minimala programändringar. Företag kanske vill anpassa sina arkitekturer för att förbättra flexibiliteten och dra nytta av Azures funktioner.

Microsoft Azure levererar hyperskalatjänster och infrastruktur med funktioner och tillförlitlighet i företagsklass. Dessa tjänster och infrastruktur erbjuder många alternativ inom hybridanslutning, vilket gör att kunderna kan komma åt dem via Internet eller en privat nätverksanslutning. Microsoft-partner kan också tillhandahålla förbättrade funktioner genom att erbjuda säkerhetstjänster och virtuella installationer som är optimerade för att köras i Azure.

Kunder kan använda Azure för att sömlöst utöka sin infrastruktur till molnet och skapa arkitekturer på flera nivåer.

Vad är ett virtuellt datacenter?

Molnet började som en plattform för att hantera offentliga program. Företag kände igen molnets värde och började migrera interna verksamhetsspecifika program. Dessa program medförde mer säkerhets-, tillförlitlighets-, prestanda- och kostnadsöverväganden som krävde mer flexibilitet vid leverans av molntjänster. Nya infrastruktur- och nätverkstjänster har utformats för att ge flexibilitet. Nya funktioner ger elastisk skalning, haveriberedskap och andra överväganden.

Molnlösningar utformades ursprungligen för att vara värdar för enskilda, relativt isolerade program i det offentliga spektrumet, som fungerade bra under några år. När fördelarna med molnlösningar blev tydliga fanns flera storskaliga arbetsbelastningar i molnet. Att hantera säkerhets-, tillförlitlighets-, prestanda- och kostnadsproblem är avgörande för distributionen och livscykeln för din molntjänst.

I exempeldiagrammet för molndistribution nedan visar den röda rutan ett säkerhetsgap. Den gula rutan visar en möjlighet att optimera virtuella nätverksinstallationer mellan arbetsbelastningar.

Virtuella datacenter bidrar till att uppnå den skala som krävs för företagsarbetsbelastningar. Skalan måste hantera de utmaningar som uppstår när storskaliga program körs i det offentliga molnet.

En implementering av virtuella datacenter innehåller mer än programarbetsbelastningarna i molnet. Den tillhandahåller även nätverks-, säkerhets-, hanterings-, DNS- och Active Directory-tjänster. När företag migrerar fler arbetsbelastningar till Azure bör du överväga den infrastruktur och de objekt som stöder dessa arbetsbelastningar. Bra resurshantering hjälper till att undvika att separat hanterade "arbetsbelastningsöar" ökar med oberoende dataflöden, säkerhetsmodeller och efterlevnadsutmaningar.

Det virtuella datacenterkonceptet innehåller rekommendationer och design på hög nivå för att implementera en samling separata men relaterade entiteter. Dessa entiteter har ofta vanliga stödfunktioner, funktioner och infrastruktur. Genom att visa dina arbetsbelastningar som ett virtuellt datacenter kan du dra nytta av minskade kostnader från stordriftsfördelar. Det hjälper också till med optimerad säkerhet via komponent- och dataflödescentralisering samt enklare åtgärder, hantering och efterlevnadsgranskningar.

Kommentar

Ett virtuellt datacenter är inte en specifik Azure-tjänst. I stället kombineras olika Azure-funktioner för att uppfylla dina krav. Ett virtuellt datacenter är ett sätt att tänka på dina arbetsbelastningar och Azure-användning för att optimera dina resurser och funktioner i molnet. Det ger en modulär metod för att tillhandahålla IT-tjänster i Azure, samtidigt som företagets organisationsroller och ansvarsområden respekteras.

Ett virtuellt datacenter hjälper företag att distribuera arbetsbelastningar och program i Azure i följande scenarier:

• Värd för flera relaterade arbetsbelastningar.
• Migrera arbetsbelastningar från en lokal miljö till Azure.
• Implementera delade eller centraliserade säkerhets- och åtkomstkrav för arbetsbelastningar.
• Blanda DevOps och centraliserad IT på rätt sätt för ett stort företag.

Vem ska implementera ett virtuellt datacenter?

Alla kunder som bestämmer sig för att införa Azure kan dra nytta av effektiviteten i att konfigurera en uppsättning resurser för gemensamt bruk av alla program. Beroende på storleken kan även enskilda program dra nytta av att använda de mönster och komponenter som används för att skapa en VDC-implementering.

Vissa organisationer har centraliserade team eller avdelningar för IT, nätverk, säkerhet eller efterlevnad. Genom att implementera en VDC kan du framtvinga princippunkter, separata ansvarsområden och säkerställa konsekvensen för underliggande gemensamma komponenter. Programteam kan behålla den frihet och kontroll som är lämplig för deras krav.

Organisationer med en DevOps-metod kan också använda VDC-begrepp för att tillhandahålla auktoriserade fickor med Azure-resurser. Den här metoden säkerställer att DevOps-grupperna har total kontroll inom den grupperingen, antingen på prenumerationsnivå eller i resursgrupper i en gemensam prenumeration. Samtidigt är nätverks- och säkerhetsgränser kompatibla. Efterlevnad definieras av en centraliserad princip i hubbnätverket och en centralt hanterad resursgrupp.

Överväganden för att implementera ett virtuellt datacenter

När du utformar ett virtuellt datacenter bör du tänka på följande viktiga problem:

Identitets- och katalogtjänst

Identitets- och katalogtjänster är viktiga funktioner för både lokala datacenter och molndatacenter. Identiteten omfattar alla aspekter av åtkomst och auktorisering till tjänster inom en VDC-implementering. För att säkerställa att endast behöriga användare och processer får åtkomst till dina Azure-resurser använder Azure flera typer av autentiseringsuppgifter för autentisering, inklusive kontolösenord, kryptografiska nycklar, digitala signaturer och certifikat. Microsoft Entra multifaktorautentisering ger ett extra säkerhetslager för åtkomst till Azure-tjänster. Med en stark autentisering med en rad enkla verifieringsalternativ (telefonsamtal, sms eller mobilappsavisering) kan kunderna välja den metod de föredrar.

Stora företag måste definiera identitetshanteringsprocesser som beskriver hanteringen av enskilda identiteter, deras autentisering, auktorisering, roller och privilegier inom eller över deras VDC. Målen med den här processen kan öka säkerheten och produktiviteten, samtidigt som kostnader, stilleståndstid och repetitiva manuella uppgifter minskar.

Företagsorganisationer kan kräva en krävande blandning av tjänster för olika verksamhetsgrenar. Anställda har ofta olika roller när de arbetar med olika projekt. VDC kräver bra samarbete mellan olika team, var och en med specifika rolldefinitioner för att få system att köras med god styrning. Matrisen med ansvarsområden, åtkomst och rättigheter kan vara komplex. Identitetshantering i VDC implementeras via Microsoft Entra-ID och rollbaserad åtkomstkontroll i Azure (Azure RBAC).

En katalogtjänst är en infrastruktur för delad information som letar upp, hanterar, administrerar och organiserar vardagliga objekt och nätverksresurser. Dessa resurser kan omfatta volymer, mappar, filer, skrivare, användare, grupper, enheter och andra objekt. Varje resurs i nätverket betraktas som ett objekt av katalogservern. Information om en resurs lagras som en samling attribut som är associerade med den resursen eller objektet.

Alla Microsofts online-företagstjänster förlitar sig på Microsoft Entra-ID för inloggning och andra identitetsbehov. Microsoft Entra ID är en omfattande molnlösning för identitets- och åtkomsthantering med hög tillgänglighet som kombinerar kärnkatalogtjänster, avancerad identitetsstyrning och hantering av programåtkomst. Microsoft Entra-ID kan integreras med lokalni Active Directory för att aktivera enkel inloggning för alla molnbaserade och lokalt värdbaserade lokala program. Användarattributen för lokalni Active Directory kan synkroniseras automatiskt med Microsoft Entra-ID.

Varje specifik avdelning, grupp av användare eller tjänster i katalogtjänsten måste ha de minsta behörigheter som krävs för att hantera sina egna resurser inom en VDC-implementering. Att strukturera behörigheter kräver balansering. För många behörigheter kan hindra prestandaeffektiviteten och för få eller lösa behörigheter kan öka säkerhetsriskerna. Rollbaserad åtkomstkontroll i Azure (Azure RBAC) hjälper dig att lösa problemet genom att erbjuda detaljerad åtkomsthantering för resurser i en VDC-implementering.

Säkerhetsinfrastruktur

Säkerhetsinfrastruktur avser uppdelning av trafik i ett VDC-implementerings specifika segment för virtuella nätverk. Den här infrastrukturen anger hur ingress och utgående styrs i en VDC-implementering. Azure baseras på en arkitektur med flera klienter som förhindrar obehörig och oavsiktlig trafik mellan distributioner. Detta görs med hjälp av isolering av virtuella nätverk, åtkomstkontrollistor, lastbalanserare, IP-filter och trafikflödesprinciper. NAT (Network Address Translation) separerar intern nätverkstrafik från extern trafik.

Azure Fabric allokerar infrastrukturresurser till klientarbetsbelastningar och hanterar kommunikation till och från virtuella datorer . Azure-hypervisor-programmet framtvingar minnes- och processavgränsning mellan virtuella datorer och dirigerar nätverkstrafik på ett säkert sätt till gästoperativsystemsklientorganisationer.

Anslutning till molnet

Ett virtuellt datacenter kräver anslutning till externa nätverk för att erbjuda tjänster till kunder, partner eller interna användare. Det här behovet av anslutning avser inte bara Internet, utan även lokala nätverk och datacenter.

Kunderna styr de tjänster som kan kommas åt och nås från det offentliga Internet. Den här åtkomsten styrs med hjälp av Azure Firewall eller andra typer av virtuella nätverksinstallationer (NVA), anpassade routningsprinciper med hjälp av användardefinierade vägar och nätverksfiltrering med hjälp av nätverkssäkerhetsgrupper. Vi rekommenderar att alla internetuppkopplade resurser skyddas av Azure DDoS Protection.

Företag kan behöva ansluta sitt virtuella datacenter till lokala datacenter eller andra resurser. Den här anslutningen mellan Azure och lokala nätverk är en viktig aspekt när du utformar en effektiv arkitektur. Företag har två olika sätt att skapa denna sammanlänkning: överföring via Internet eller via privata direktanslutningar.

Ett AZURE-plats-till-plats-VPN ansluter lokala nätverk till ditt virtuella datacenter i Azure. Länken upprättas via säkra krypterade anslutningar (IPsec-tunnlar). Vpn-anslutningar för Plats-till-plats i Azure är flexibla, snabba att skapa och kräver vanligtvis inte mer maskinvaruanskaffning. Baserat på branschstandardprotokoll kan de flesta aktuella nätverksenheter skapa VPN-anslutningar till Azure via Internet eller befintliga anslutningsvägar.

ExpressRoute möjliggör privata anslutningar mellan ditt virtuella datacenter och eventuella lokala nätverk. ExpressRoute-anslutningar går inte via det offentliga Internet och erbjuder högre säkerhet, tillförlitlighet och högre hastigheter (upp till 100 Gbit/s) tillsammans med konsekvent svarstid. ExpressRoute ger fördelarna med efterlevnadsregler som är associerade med privata anslutningar. Med ExpressRoute Direct kan du ansluta direkt till Microsoft-routrar på antingen 10 Gbit/s eller 100 Gbit/s.

Att distribuera ExpressRoute-anslutningar innebär vanligtvis att interagera med en ExpressRoute-tjänstleverantör (ExpressRoute Direct är undantaget). För kunder som behöver starta snabbt är det vanligt att först använda plats-till-plats-VPN för att upprätta anslutning mellan ett virtuellt datacenter och lokala resurser. När din fysiska sammankoppling med tjänstleverantören är klar migrerar du anslutningen via Din ExpressRoute-anslutning.

För ett stort antal VPN- eller ExpressRoute-anslutningar är Azure Virtual WAN en nätverkstjänst som tillhandahåller optimerade och automatiserade förgrenings-till-gren-anslutningar via Azure. Med Virtual WAN kan du ansluta till och konfigurera grenenheter så att de kommunicerar med Azure. Du kan ansluta och konfigurera antingen manuellt eller genom att använda önskade providerenheter via en Virtual WAN-partner. Med önskade providerenheter kan du enkelt använda, förenkla anslutningen och konfigurationshanteringen. Den inbyggda Azure WAN-instrumentpanelen ger direkt felsökningsinsikter som kan hjälpa dig att spara tid och ger dig ett enkelt sätt att visa storskaliga plats-till-plats-anslutningar. Virtual WAN tillhandahåller även säkerhetstjänster med en valfri Azure Firewall och Firewall Manager i din Virtual WAN-hubb.

Anslutning i molnet

Azure Virtual Networks och peering för virtuella nätverk är de grundläggande nätverkskomponenterna i ett virtuellt datacenter. Ett virtuellt nätverk garanterar en isoleringsgräns för virtuella datacenterresurser. Peering möjliggör kommunikation mellan olika virtuella nätverk i samma Azure-region, mellan regioner och även mellan nätverk i olika prenumerationer. Trafikflöden kan styras i och mellan virtuella nätverk genom uppsättningar med säkerhetsregler som anges för nätverkssäkerhetsgrupper, brandväggsprinciper (Azure Firewall eller virtuella nätverksinstallationer) och anpassade användardefinierade vägar.

Virtuella nätverk är fästpunkter för integrering av PaaS-produkter (Plattform som en tjänst) som Azure Storage, Azure SQL och andra integrerade offentliga tjänster som har offentliga slutpunkter. Med tjänstslutpunkter och Azure Private Link kan du integrera dina offentliga tjänster med ditt privata nätverk. Du kan till och med ta dina offentliga tjänster privat, men ändå dra nytta av fördelarna med Azure-hanterade PaaS-tjänster.

Översikt över virtuellt datacenter

Topologier

Ett virtuellt datacenter kan skapas med någon av dessa topologier på hög nivå baserat på dina behov och skalningskrav:

I en platt topologi distribueras alla resurser i ett enda virtuellt nätverk. Undernät möjliggör flödeskontroll och uppdelning.

I en Mesh-topologi ansluter peering för virtuella nätverk alla virtuella nätverk direkt till varandra.

En peering-hubb- och ekertopologi passar bra för distribuerade program och team med delegerat ansvar.

En Azure Virtual WAN-topologi kan stödja storskaliga avdelningskontorsscenarier och globala WAN-tjänster.

Topologin peering hub and spoke och Azure Virtual WAN-topologin använder både en hubb- och ekerdesign, vilket är optimalt för kommunikation, delade resurser och centraliserad säkerhetsprincip. Hubbar skapas med antingen en peering-hubb för virtuella nätverk (märkt som Hub Virtual Network i diagrammet) eller en Virtual WAN-hubb (märkt som Azure Virtual WAN i diagrammet). Azure Virtual WAN är utformat för storskalig kommunikation från gren till gren och förgrening till Azure, eller för att undvika komplexiteten i att skapa alla komponenter individuellt i en virtuell nätverkspeeringshubb. I vissa fall kan dina krav kräva en virtuell nätverkspeeringshubbdesign, till exempel behovet av virtuella nätverksinstallationer i hubben.

I nav- och ekertopologier är hubben den centrala nätverkszonen som styr och inspekterar all trafik mellan olika zoner, till exempel Internet, lokalt och ekrarna. Nav- och ekertopologin hjälper IT-avdelningen att centralt framtvinga säkerhetsprinciper. Det minskar också risken för felaktig konfiguration och exponering.

Hubben innehåller ofta vanliga tjänstkomponenter som används av ekrarna. Följande exempel är gemensamma centrala tjänster:

• Windows Active Directory-infrastrukturen krävs för användarautentisering av tredje part som kommer åt från ej betrodda nätverk innan de får åtkomst till arbetsbelastningarna i ekern. Den innehåller de relaterade Active Directory usluge za ujedinjavanje (AD FS)
• En DNS-tjänst (Distributed Name System) används för att lösa namngivning för arbetsbelastningen i ekrarna och för att komma åt resurser lokalt och på Internet om Azure DNS inte används
• En offentlig nyckelinfrastruktur (PKI) används för att implementera arbetsbelastningar med enkel inloggning
• Flödeskontroll av TCP- och UDP-trafik mellan ekernätverkszonerna och Internet
• Flödeskontroll mellan ekrarna och den lokala miljön
• Vid behov, flödeskontroll mellan en eker och en annan

Ett virtuellt datacenter minskar den totala kostnaden med hjälp av den delade hubbinfrastrukturen mellan flera ekrar.

Rollen för varje eker kan vara värd för olika typer av arbetsbelastningar. Ekrarna ger också en modulär metod för upprepningsbara distributioner av samma arbetsbelastningar. Exempel är dev/test, testning av användargodkännande, förproduktion och produktion. Ekrarna kan också särskilja och aktivera olika grupper i din organisation. DevOps-grupper är ett bra exempel på vad ekrar kan göra. I en eker är det möjligt att distribuera en grundläggande arbetsbelastning eller komplexa arbetsbelastningar på flera nivåer med trafikkontroll mellan nivåerna.

Prenumerationsbegränsningar och flera hubbar

Viktigt!

Baserat på storleken på dina Azure-distributioner kan du behöva en strategi för flera hubbar. När du utformar din nav- och ekerstrategi frågar du "Kan den här designskalan använda ett annat virtuellt navnätverk i den här regionen?" och "Kan den här designskalan rymma flera regioner?" Det är mycket bättre att planera för en design som skalar och inte behöver den, än att inte planera och behöva den.

När du ska skala till en sekundär (eller mer) hubb beror på flera faktorer, vanligtvis baserat på inbyggda skalningsgränser. Se till att granska gränserna för prenumeration, virtuellt nätverk och virtuella datorer när du utformar för skalning.

I Azure distribueras alla komponenter, oavsett typ, i en Azure-prenumeration. Isolering av Azure-komponenter i olika Azure-prenumerationer kan uppfylla kraven på olika affärslinjer, till exempel att ställa in differentierade nivåer av åtkomst och auktorisering.

En enda VDC-implementering kan skala upp ett stort antal ekrar. Även om det, precis som med alla IT-system, finns plattformsgränser. Hubbdistributionen är bunden till en specifik Azure-prenumeration, som har begränsningar och begränsningar (till exempel ett maximalt antal peerings för virtuella nätverk. Mer information finns i Azure-prenumerations - och tjänstgränser, kvoter och begränsningar). I fall där gränser kan vara ett problem kan arkitekturen skalas upp ytterligare genom att utöka modellen från en enda hubb-eker till ett kluster med hubbar och ekrar. Flera hubbar i en eller flera Azure-regioner kan anslutas med peering för virtuella nätverk, ExpressRoute, Virtual WAN eller plats-till-plats-VPN.

Införandet av flera hubbar ökar systemets kostnads- och hanteringsarbete. Det är bara motiverat på grund av skalbarhet, systemgränser, redundans, regional replikering för slutanvändarens prestanda eller haveriberedskap. I scenarier som kräver flera hubbar bör alla hubbar sträva efter att erbjuda samma uppsättning tjänster för att underlätta driften.

Samtrafik mellan ekrar

I en enda eker eller en plan nätverksdesign är det möjligt att implementera komplexa arbetsbelastningar med flera nivåer. Flertierskonfigurationer kan implementeras med hjälp av undernät, som är en för varje nivå eller program i samma virtuella nätverk. Trafikkontroll och filtrering utförs med hjälp av nätverkssäkerhetsgrupper och användardefinierade vägar.

En arkitekt kan vilja distribuera en arbetsbelastning på flera nivåer i flera virtuella nätverk. Med peering för virtuella nätverk kan ekrar ansluta till andra ekrar i samma hubb eller olika hubbar. Ett typiskt exempel på det här scenariot är fallet där programbearbetningsservrar finns i en eker eller ett virtuellt nätverk. Databasen distribueras i ett annat ekernätverk eller ett virtuellt nätverk. I det här fallet är det enkelt att koppla samman ekrarna med peering för virtuella nätverk, vilket förhindrar överföring via hubben. Slutför en noggrann arkitektur och säkerhetsgranskning för att säkerställa att förbikoppling av hubben inte kringgår viktiga säkerhets- eller granskningsplatser som kanske bara finns i hubben.

Ekrar kan också ansluta till en eker som fungerar som en hubb. Den här metoden skapar en hierarki på två nivåer. Ekern på den högre nivån (nivå 0) blir navet för lägre ekrar (nivå 1) i hierarkin. Ekrarna för en VDC-implementering krävs för att vidarebefordra trafiken till den centrala hubben. Trafiken kan sedan skickas till målet i antingen det lokala nätverket eller det offentliga Internet. En arkitektur med två nivåer av hubbar introducerar komplex routning som tar bort fördelarna med en enkel hub-spoke-relation.

Även om Azure tillåter komplexa topologier är en av huvudprinciperna i VDC-konceptet repeterbarhet och enkelhet. För att minimera hanteringsarbetet är den enkla hub-spoke-designen den VDC-referensarkitektur som vi rekommenderar.

Komponenter

Det virtuella datacentret består av fyra grundläggande komponenttyper: infrastruktur, perimeternätverk, arbetsbelastningar och övervakning.

Varje komponenttyp består av olika Azure-funktioner och resurser. VDC-implementeringen består av instanser av flera komponenttyper och flera varianter av samma komponenttyp. Du kan till exempel ha många olika, logiskt avgränsade arbetsbelastningsinstanser som representerar olika program. Du använder dessa olika komponenttyper och instanser för att skapa VDC.

Den föregående konceptuella arkitekturen på hög nivå i VDC visar olika komponenttyper som används i olika zoner i topologin hub-spokes. Diagrammet visar infrastrukturkomponenter i olika delar av arkitekturen.

Som god praxis i allmänhet kan åtkomsträttigheter och behörigheter vara gruppbaserade. Att hantera grupper snarare än enskilda användare underlättar underhållet av åtkomstprinciper genom att tillhandahålla ett konsekvent sätt att hantera det mellan team, vilket hjälper till att minimera konfigurationsfel. Genom att tilldela och ta bort användare till och från lämpliga grupper kan du hålla behörigheterna för en viss användare uppdaterade.

Varje rollgrupp kan ha ett unikt prefix för sina namn. Det här prefixet gör det enkelt att identifiera vilken arbetsbelastning en grupp är associerad med. En arbetsbelastning som är värd för en autentiseringstjänst kan till exempel ha grupper med namnet AuthServiceNetOps, AuthServiceSecOps, AuthServiceDevOps och AuthServiceInfraOps. Centraliserade roller, eller roller som inte är relaterade till en specifik tjänst, kan föregås av Corp. Ett exempel är CorpNetOps.

Många organisationer använder en variant av följande grupper för att ge en stor uppdelning av roller:

• Det centrala IT-teamet med namnet Corp har ägarrättigheter för att kontrollera infrastrukturkomponenter. Exempel är nätverk och säkerhet. Gruppen måste ha rollen deltagare i prenumerationen, kontrollen över hubben och nätverksdeltagarens rättigheter i ekrarna. Stora organisationer delar ofta upp dessa hanteringsansvar mellan flera team. Exempel är en corpnetops-grupp för nätverksdrift med exklusivt fokus på nätverk och en CorpSecOps-grupp för säkerhetsåtgärder som ansvarar för brandväggs- och säkerhetsprincipen. I det här specifika fallet måste två olika grupper skapas för tilldelning av dessa anpassade roller.
• Utvecklings-/testgruppen Med namnet AppDevOps ansvarar för att distribuera app- eller tjänstarbetsbelastningar. Den här gruppen tar rollen som virtuell datordeltagare för IaaS-distributioner eller en eller flera PaaS-deltagares roller. Mer information finns i Inbyggda roller i Azure. Om du vill kan utvecklings-/testteamet behöva insyn i säkerhetsprinciper (nätverkssäkerhetsgrupper) och routningsprinciper (användardefinierade vägar) i hubben eller en specifik eker. Förutom rollen som deltagare för arbetsbelastningar skulle den här gruppen också behöva rollen som nätverksläsare.
• Drift- och underhållsgruppen CorpInfraOps eller AppInfraOps ansvarar för att hantera arbetsbelastningar i produktion. Den här gruppen måste vara en prenumerationsdeltagare för arbetsbelastningar i alla produktionsprenumerationer. Vissa organisationer kan också utvärdera om de behöver en eskaleringssupportgrupp med rollen prenumerationsdeltagare i produktion och den centrala hubbprenumerationen. Den andra gruppen åtgärdar potentiella konfigurationsproblem i produktionsmiljön.

VDC är utformad så att centrala IT-teamgrupper som hanterar hubben har motsvarande grupper på arbetsbelastningsnivå. Förutom att hantera hubbresurser kan det centrala IT-teamet styra extern åtkomst och behörigheter på den översta nivån för prenumerationen. Arbetsbelastningsgrupper kan också styra resurser och behörigheter för sitt virtuella nätverk oberoende av det centrala IT-teamet.

Det virtuella datacentret partitioneras för att på ett säkert sätt vara värd för flera projekt i olika affärslinjer. Alla projekt kräver olika isolerade miljöer (dev, UAT och produktion). Separata Azure-prenumerationer för var och en av dessa miljöer kan ge naturlig isolering.

Föregående diagram visar relationen mellan en organisations projekt, användare, grupper och de miljöer där Azure-komponenterna distribueras.

Normalt inom IT är en miljö (eller nivå) ett system där flera program distribueras och körs. Stora företag använder en utvecklingsmiljö (där ändringar görs och testas) och en produktionsmiljö (vad slutanvändarna använder). Dessa miljöer är avgränsade, ofta med flera mellanlagringsmiljöer däremellan, för att tillåta stegvis distribution (distribution), testning och återställning om problem uppstår. Distributionsarkitekturerna varierar avsevärt, men vanligtvis följs fortfarande den grundläggande processen att börja vid utveckling (DEV) och sluta vid produktion (PROD).

En vanlig arkitektur för dessa typer av miljöer med flera nivåer inkluderar DevOps för utveckling och testning, UAT för mellanlagring och produktionsmiljöer. Organisationer kan använda en eller flera Microsoft Entra-klienter för att definiera åtkomst och rättigheter till dessa miljöer. Det föregående diagrammet visar ett fall där två olika Microsoft Entra-klienter används: en för DevOps och UAT och den andra uteslutande för produktion.

Förekomsten av olika Microsoft Entra-klienter framtvingar separationen mellan miljöer. Samma grupp med användare, till exempel det centrala IT-teamet, måste autentiseras med hjälp av en annan URI för att få åtkomst till en annan Microsoft Entra-klientorganisation. På så sätt kan teamet ändra roller eller behörigheter för antingen DevOps- eller produktionsmiljöerna i ett projekt. Förekomsten av olika användarautentiseringar för åtkomst till olika miljöer minskar eventuella avbrott och andra problem som orsakas av mänskliga fel.

Komponenttyp: infrastruktur

Den här komponenttypen är den plats där merparten av den stödjande infrastrukturen finns. Det är också där dina centraliserade IT-, säkerhets- och efterlevnadsteam tillbringar större delen av sin tid.

Infrastrukturkomponenter ger en sammankoppling för de olika komponenterna i en VDC-implementering och finns i både hubben och ekrarna. Ansvaret för att hantera och underhålla infrastrukturkomponenterna tilldelas vanligtvis till det centrala IT-teamet eller säkerhetsteamet.

En av it-infrastrukturteamets primära uppgifter är att garantera konsekvensen i IP-adressscheman i hela företaget. Det privata IP-adressutrymme som tilldelats en VDC-implementering måste vara konsekvent och inte överlappa med privata IP-adresser som tilldelats i dina lokala nätverk.

Nat på lokala gränsroutrar eller i Azure-miljöer kan undvika IP-adresskonflikter, men det medför komplikationer för dina infrastrukturkomponenter. Enkelhet i hanteringen är ett av de viktigaste målen för VDC. Att använda NAT för att hantera IP-problem, även om det är en giltig lösning, är inte en rekommenderad lösning.

Infrastrukturkomponenter har följande funktioner:

• Identitets- och katalogtjänster: Åtkomst till varje resurstyp i Azure styrs av en identitet som lagras i en katalogtjänst. Katalogtjänsten lagrar inte bara listan över användare, utan även åtkomsträttigheterna till resurser i en specifik Azure-prenumeration. Dessa tjänster kan finnas i molnet, eller så kan de synkroniseras med en lokal identitet som lagras i Active Directory.
• Virtuella nätverk: Virtuella nätverk är en av huvudkomponenterna i VDC och gör att du kan skapa en gräns för trafikisolering på Azure-plattformen. Ett virtuellt nätverk består av ett enskilt eller flera virtuella nätverkssegment, var och en med ett specifikt IP-nätverksprefix (ett undernät, antingen IPv4 eller IPv4/IPv6 med dubbla staplar). Det virtuella nätverket definierar ett internt perimeterområde där virtuella IaaS-datorer och PaaS-tjänster kan upprätta privat kommunikation. Virtuella datorer (och PaaS-tjänster) i ett virtuellt nätverk kan inte kommunicera direkt till virtuella datorer (och PaaS-tjänster) i ett annat virtuellt nätverk. Detta gäller även om båda de virtuella nätverken skapas av samma kund under samma prenumeration. Isolering är en viktig egenskap som säkerställer att kundens virtuella datorer och kommunikation förblir privat i ett virtuellt nätverk. Där anslutningar mellan nätverk önskas beskriver följande funktioner hur det kan åstadkommas.
• Peering för virtuella nätverk: Den grundläggande funktionen som används för att skapa infrastrukturen för en VDC är peering för virtuella nätverk, som ansluter två virtuella nätverk i samma region. Den här anslutningen sker via Azures datacenternätverk eller med hjälp av den globala Azure-stamnätet mellan regioner.
• Tjänstslutpunkter för virtuellt nätverk: Tjänstslutpunkter utökar det privata adressutrymmet för det virtuella nätverket till att omfatta ditt PaaS-utrymme. Slutpunkterna utökar även identiteten för ditt virtuella nätverk till Azure-tjänsterna via en direktanslutning. Med slutpunkter kan du skydda dina kritiska Azure-tjänstresurser i dina virtuella nätverk.
• Private Link: Med Azure Private Link kan du komma åt Azure PaaS Services (till exempel Azure Storage, Azure Cosmos DB och Azure SQL Database) och Azure-värdbaserade kund-/partnertjänster via en privat slutpunkt i ditt virtuella nätverk. Trafik mellan ditt virtuella nätverk och tjänsten passerar över Microsofts stamnätverk, vilket eliminerar exponering från det offentliga Internet. Du kan också skapa en egen Private Link-tjänst i ditt virtuella nätverk och leverera den privat till dina kunder. Konfigurations- och förbrukningsupplevelsen med Azure Private Link är konsekvent i Azure PaaS, kundägda och delade partnertjänster.
• Användardefinierade vägar: Trafik i ett virtuellt nätverk dirigeras som standard baserat på systemroutningstabellen. En användardefinierad väg är en anpassad routningstabell som nätverksadministratörer kan associera till ett eller flera undernät för att åsidosätta beteendet för systemroutningstabellen och definierar en kommunikationssökväg i ett virtuellt nätverk. Förekomsten av användardefinierade vägar garanterar trafik från ekeröverföringen via specifika anpassade virtuella datorer eller virtuella nätverksinstallationer och lastbalanserare som finns i både hubben och ekrarna.
• Nätverkssäkerhetsgrupper: En nätverkssäkerhetsgrupp är en lista över säkerhetsregler som fungerar som trafikfiltrering på IP-källor, IP-mål, protokoll, IP-källportar och IP-målportar (kallas även för en Layer 4-femtupplare). Nätverkssäkerhetsgruppen kan tillämpas på ett undernät, ett virtuellt nätverkskort som är associerat med en virtuell Azure-dator eller båda. Nätverkssäkerhetsgrupperna är viktiga för att implementera en korrekt flödeskontroll i hubben och i ekrarna. Den säkerhetsnivå som tillhandahålls av nätverkssäkerhetsgruppen är en funktion för vilka portar du öppnar och i vilket syfte. Kunder kan använda fler filter per virtuell dator med värdbaserade brandväggar, till exempel iptables eller Windows-brandväggen.
• DNS: DNS tillhandahåller namnmatchning för resurser i ett virtuellt datacenter. Azure tillhandahåller DNS-tjänster för både offentlig och privat namnmatchning. Privata zoner ger namnmatchning i ett virtuellt nätverk och mellan virtuella nätverk. Privata zoner kan sträcka sig över virtuella nätverk i samma region och mellan regioner och prenumerationer. För offentlig lösning tillhandahåller Azure DNS en värdtjänst för DNS-domäner som tillhandahåller namnmatchning med hjälp av Microsoft Azure-infrastrukturen. 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.
• Hantering av hanteringsgrupp, prenumeration och resursgrupp . En prenumeration definierar en naturlig gräns för att skapa flera grupper av resurser i Azure. Den här separationen kan vara för funktion, rollsegregering eller fakturering. Resurser i en prenumeration monteras tillsammans i logiska containrar som kallas resursgrupper. Resursgruppen representerar en logisk grupp för att organisera resurserna i ett virtuellt datacenter. Om din organisation har många prenumerationer kanske du behöver ett sätt att effektivt hantera åtkomst, principer och efterlevnad för dessa prenumerationer. Azure-hanteringsgrupper ger en omgångsnivå som omfattar prenumerationer. Du organiserar prenumerationer i containrar som kallas hanteringsgrupper och tillämpar dina styrningsvillkor på hanteringsgrupperna. Alla prenumerationer i en hanteringsgrupp ärver automatiskt de villkor som tillämpas för hanteringsgruppen. Om du vill se dessa tre funktioner i en hierarkivy kan du läsa Organisera dina resurser i Cloud Adoption Framework.
• Rollbaserad åtkomstkontroll i Azure (Azure RBAC): Azure RBAC kan mappa organisationsroller och behörigheter för åtkomst till specifika Azure-resurser. På så sätt kan du begränsa användare till endast en viss delmängd av åtgärder. Om du synkroniserar Microsoft Entra-ID med en lokalni Active Directory kan du använda samma Active Directory-grupper i Azure som du använder lokalt. Med Azure RBAC kan du bevilja åtkomst genom att tilldela lämplig roll till användare, grupper och program inom relevant omfång. Omfånget för en rolltilldelning kan vara en Azure-prenumeration, en resursgrupp eller en enskild resurs. Azure RBAC tillåter arv av behörigheter. En roll som tilldelats ett överordnat omfång ger också åtkomst till de underordnade som finns i den. Med Azure RBAC kan du separera uppgifter och endast bevilja den mängd åtkomst till användare som de behöver för att utföra sina jobb. En anställd kan till exempel hantera virtuella datorer i en prenumeration, medan en annan kan hantera SQL Server-databaser i samma prenumeration.

Komponenttyp: Perimeternätverk

Komponenter i ett perimeternätverk (kallas ibland ett DMZ-nätverk) ansluter dina lokala eller fysiska datacenternätverk, tillsammans med eventuella internetanslutningar. Perimetern kräver vanligtvis en betydande tidsinvestering från ditt nätverk och säkerhetsteam.

Inkommande paket kan flöda genom säkerhetsenheterna i hubben innan de når serverdelsservrarna och tjänsterna i ekrarna. Exempel är brandväggen, IDS och IPS. Innan de lämnar nätverket kan internetbundna paket från arbetsbelastningarna också flöda genom säkerhetsinstallationerna i perimeternätverket. Det här flödet möjliggör principframtvingande, inspektion och granskning.

Perimeternätverkskomponenter inkluderar:

• Virtuella nätverk, användardefinierade vägar och nätverkssäkerhetsgrupper
• Virtuella nätverksinstallationer
• Azure Load Balancer
• Azure Application Gateway med brandvägg för webbprogram (WAF)
• Offentliga IP-adresser
• Azure Front Door med brandvägg för webbprogram (WAF)
• Azure Firewall och Azure Firewall Manager
• Standard DDoS-skydd

Vanligtvis har det centrala IT-teamet och säkerhetsteamen ansvar för kravdefinitionen och driften av perimeternätverken.

Föregående diagram visar tillämpningen av två perimeterr med åtkomst till Internet och ett lokalt nätverk, som båda är bosatta i DMZ-hubben. I DMZ-hubben kan perimeternätverket till Internet skalas upp för att stödja många affärslinjer, med hjälp av flera servergrupper med brandväggar för webbaserade program (WAFs) eller Azure Firewalls. Hubben möjliggör även lokal anslutning via VPN eller ExpressRoute efter behov.

Kommentar

I föregående diagram DMZ Hubkan många av följande funktioner paketeras i en Azure Virtual WAN-hubb (till exempel virtuella nätverk, användardefinierade vägar, nätverkssäkerhetsgrupper, VPN-gatewayer, ExpressRoute-gatewayer, Azure Load Balancers, Azure Firewalls, Firewall Manager och DDOS). Att använda Azure Virtual WAN-hubbar kan göra skapandet av det virtuella hubbnätverket och VDC mycket enklare, eftersom det mesta av den tekniska komplexiteten hanteras åt dig av Azure när du distribuerar en Azure Virtual WAN-hubb.

Virtuella nätverk. Hubben bygger vanligtvis på ett virtuellt nätverk med flera undernät som är värdar för olika typer av tjänster. Dessa tjänster filtrerar och inspekterar trafik till eller från Internet via Azure Firewall, NVA, WAF och Azure Application Gateway-instanser.

Användardefinierade vägar. Genom att använda användardefinierade vägar kan kunder distribuera brandväggar, IDS/IPS och andra virtuella enheter. De kan dirigera nätverkstrafik via dessa säkerhetsinstallationer för att säkerställa efterlevnad, granskning och inspektion av säkerhetsgränser. Användardefinierade vägar kan skapas i både hubben och ekrarna för att garantera att trafiken överförs via specifika anpassade virtuella datorer, virtuella nätverksinstallationer och lastbalanserare som används av en VDC-implementering. För att garantera att trafik som genereras från virtuella datorer i ekeröverföringarna till rätt virtuella enheter måste en användardefinierad väg anges i ekerns undernät. Detta görs genom att ange klientdelens IP-adress för den interna lastbalanseraren som nästa hopp. Den interna belastningsutjämnaren distribuerar den interna trafiken till de virtuella datorerna (belastningsutjämnarens serverdelspool).

Azure Firewall är en hanterad nätverkssäkerhetstjänst som skyddar dina Azure Virtual Network-resurser. Det är en tillståndskänslig hanterad brandvägg med hög tillgänglighet och skalbarhet i molnet. Du kan centralt skapa, framtvinga och logga principer för tillämpning och nätverksanslutning över prenumerationer och virtuella nätverk. Azure Firewall använder en statisk offentlig IP-adress för dina virtuella nätverksresurser. Det gör att externa brandväggar kan identifiera trafiken från ditt virtuella nätverk. Tjänsten är helt integrerad med Azure Monitor för loggning och analys.

Om du använder Azure Virtual WAN-topologin är Azure Firewall Manager en säkerhetshanteringstjänst som tillhandahåller central säkerhetsprincip och väghantering för molnbaserade säkerhetsperimeter. Det fungerar med Azure Virtual WAN Hub, en Microsoft-hanterad resurs som gör att du enkelt kan skapa hubb- och ekerarkitekturer. När säkerhets- och routningsprinciper associeras med en hubb kallas det för en säker virtuell hubb.

Virtuella nätverksinstallationer. I hubben hanteras perimeternätverket med åtkomst till Internet normalt via en Azure Firewall-instans eller en servergrupp med brandväggar eller brandväggar för webbprogram (WAF).

Olika verksamhetsområden använder ofta många webbprogram, som tenderar att drabbas av olika sårbarheter och potentiella sårbarheter. Brandväggar för webbprogram är en särskild typ av produkt som används för att identifiera attacker mot webbprogram och HTTP/HTTPS effektivare än en allmän brandvägg. Jämfört med tradition av brandväggsteknik har WAF:er en uppsättning specifika funktioner för att skydda interna webbservrar mot hot.

En Azure Firewall- eller NVA-brandvägg använder ett vanligt administrationsplan med en uppsättning säkerhetsregler för att skydda arbetsbelastningarna i ekrarna och styra åtkomsten till lokala nätverk. Azure Firewall har inbyggd skalbarhet, medan NVA-brandväggar kan skalas manuellt bakom en lastbalanserare. I allmänhet har en brandväggsgrupp mindre specialiserad programvara jämfört med en WAF, men har ett bredare programomfång för att filtrera och inspektera alla typer av trafik i utgående och inkommande. Om en NVA-metod används kan de hittas och distribueras från Azure Marketplace.

Vi rekommenderar att du använder en uppsättning Azure Firewall-instanser, eller NVA:er, för trafik som kommer från Internet. Använd en annan för trafik som kommer från en lokal plats. Att bara använda en uppsättning brandväggar för båda är en säkerhetsrisk eftersom det inte ger någon säkerhetsperimeter mellan de två uppsättningarna nätverkstrafik. Om du använder separata brandväggslager minskar komplexiteten med att kontrollera säkerhetsregler, vilket gör det tydligt vilka regler som motsvarar vilken inkommande nätverksbegäran.

Azure Load Balancer erbjuder en tjänst med hög tillgänglighet för Layer 4 (TCP/UDP), som kan distribuera inkommande trafik mellan tjänstinstanser som definierats i en belastningsutjämningsuppsättning. Trafik som skickas till lastbalanseraren från klientdelsslutpunkter (offentliga IP-slutpunkter eller privata IP-slutpunkter) kan distribueras om med eller utan adressöversättning till en uppsättning serverdels-IP-adresspooler (till exempel virtuella nätverksinstallationer eller virtuella datorer).

Azure Load Balancer kan avsöka hälsotillståndet för olika serverinstanser. När en instans inte svarar på avsökningen slutar belastningsutjämnaren att skicka trafik till de ohälsosamma instanserna. I ett virtuellt datacenter distribueras en extern lastbalanserare till hubben och ekrarna. I hubben används lastbalanseraren för att effektivt dirigera trafik över brandväggsinstanser. I ekrarna används lastbalanserarna för att hantera programtrafik.

Azure Front Door (AFD) är Microsofts högtillgängliga och skalbara plattform för webbprogramacceleration, global HTTP-lastbalanserare, programskydd och innehållsleveransnätverk. AfD körs på mer än 100 platser i utkanten av Microsofts globala nätverk och gör att du kan skapa, använda och skala ut ditt dynamiska webbprogram och statiska innehåll. AFD ger ditt program prestanda för slutanvändare i världsklass, enhetlig regional/stämpelunderhållsautomation, BCDR-automatisering, enhetlig klient-/användarinformation, cachelagring och tjänstinsikter.

Plattformen erbjuder:

• Serviceavtal (SLA) för prestanda, tillförlitlighet och support.
• Efterlevnadscertifieringar.
• Granskningsbara säkerhetsrutiner som utvecklas, drivs och stöds internt av Azure.

Azure Front Door tillhandahåller också en brandvägg för webbprogram (WAF), som skyddar webbprogram från vanliga sårbarheter och exponeringar.

Azure Application Gateway är en dedikerad virtuell installation som tillhandahåller en hanterad programleveranskontrollant. Den erbjuder olika layer 7-belastningsutjämningsfunktioner för ditt program. Det gör att du kan optimera webbgruppens prestanda genom att avlasta CPU-intensiv SSL-avslutning till programgatewayen. Den innehåller även andra Layer 7-routningsfunktioner, till exempel resursallokeringsdistribution av inkommande trafik, cookiebaserad sessionstillhörighet, URL-sökvägsbaserad routning och möjligheten att vara värd för flera webbplatser bakom en enda programgateway. En brandvägg för webbaserade program (WAF) ingår också som en del av programgatewayens WAF SKU. Den här SKU:n skyddar webbprogram mot vanliga säkerhetsrisker och sårbarheter på webben. Application Gateway kan konfigureras som internetuppkopplad gateway, intern gateway eller en kombination av båda.

Offentliga IP-adresser. Med vissa Azure-funktioner kan du associera tjänstslutpunkter till en offentlig IP-adress så att din resurs är tillgänglig från Internet. Den här slutpunkten använder NAT för att dirigera trafik till den interna adressen och porten i det virtuella nätverket i Azure. Den här vägen är det primära sättet för extern trafik att skickas till det virtuella nätverket. Du kan konfigurera offentliga IP-adresser för att avgöra vilken trafik som skickas och hur och var den översätts till det virtuella nätverket.

Azure DDoS Protection ger fler minskningsfunktioner över den grundläggande tjänstnivån som är specifikt anpassad till azure-resurser för virtuella nätverk. DDoS Protection är enkelt att aktivera och kräver inga programändringar. Skyddsprinciperna justeras via särskilda algoritmer för trafikövervakning och maskininlärning. Principer tillämpas på offentliga IP-adresser som är kopplade till resurser som har distribuerats i virtuella nätverk. Exempel är Azure-lastbalanserare, Azure-programgateway och Azure Service Fabric-instanser. Nästan i realtid är systemgenererade loggar tillgängliga via Azure Monitor-vyer under en attack och för historik. Skydd på programnivå kan läggas till via brandväggen för Azure Application Gateway-webbprogram. Skydd tillhandahålls för offentliga IP-adresser för IPv4 och IPv6 Azure.

Nav- och ekertopologin använder peering för virtuella nätverk och användardefinierade vägar för att dirigera trafiken korrekt.

I diagrammet ser den användardefinierade vägen till att trafiken flödar från ekern till brandväggen innan den skickas till en lokal plats via ExpressRoute-gatewayen (om brandväggsprincipen tillåter det flödet).

Komponenttyp: övervakning

Övervakningskomponenter ger synlighet och aviseringar från alla andra komponenttyper. Alla team kan ha åtkomst till övervakning för de komponenter och tjänster som de har åtkomst till. Om du har en centraliserad supportavdelning eller driftteam behöver de integrerad åtkomst till de data som tillhandahålls av dessa komponenter.

Azure erbjuder olika typer av loggnings- och övervakningstjänster för att spåra beteendet för Azure-värdbaserade resurser. Styrning och kontroll av arbetsbelastningar i Azure baseras inte bara på insamling av loggdata, utan även på möjligheten att utlösa åtgärder baserat på specifika rapporterade händelser.

Azure Monitor. Azure innehåller flera tjänster som utför en specifik roll eller aktivitet individuellt i övervakningsutrymmet. Tillsammans ger dessa tjänster en omfattande lösning för att samla in, analysera och agera på systemgenererade loggar från dina program och de Azure-resurser som stöder dem. De kan också arbeta med att övervaka kritiska lokala resurser för att tillhandahålla en hybridövervakningsmiljö. Att förstå de verktyg och data som är tillgängliga är det första steget i att utveckla en fullständig övervakningsstrategi för dina program.

Det finns två grundläggande typer av loggar i Azure Monitor:

• Mått är numeriska värden som beskriver någon aspekt av ett system vid en viss tidpunkt. De är enkla och kan stödja scenarier i nära realtid. För många Azure-resurser visas data som samlas in av Azure Monitor direkt på översiktssidan i Azure-portalen. Som ett exempel kan du titta på alla virtuella datorer så visas flera diagram som visar prestandamått. Välj någon av graferna för att öppna data i Metrics Explorer i Azure-portalen, vilket gör att du kan kartlägga värdena för flera mått över tid. Du kan visa diagrammen interaktivt eller fästa dem på en instrumentpanel för att visa dem med andra visualiseringar.

• Loggar innehåller olika typer av data ordnade i poster med olika uppsättningar egenskaper för varje typ. Händelser och spårningar lagras som loggar tillsammans med prestandadata, som alla kan kombineras för analys. Loggdata som samlas in av Azure Monitor kan analyseras med frågor för att snabbt hämta, konsolidera och analysera insamlade data. Loggar lagras och efterfrågas från Log Analytics. Du kan skapa och testa frågor med hjälp av logganalys i Azure-portalen och direkt analysera data med hjälp av dessa verktyg eller spara frågor för användning med visualiseringar eller aviseringsregler.

Azure Monitor kan samla in data från olika källor. Du kan tänka dig att övervaka data för dina program på nivåer som sträcker sig från ditt program, valfritt operativsystem och de tjänster som det förlitar sig på, ned till själva Azure-plattformen. Azure Monitor samlar in data från var och en av följande nivåer:

• Programövervakningsdata: Data om prestanda och funktioner i den kod som du har skrivit, oavsett plattform.
• Övervakningsdata för gästoperativsystem: Data om det operativsystem som programmet körs på. Det här operativsystemet kan köras i Azure, ett annat moln eller lokalt.
• Azure-resursövervakningsdata: Data om driften av en Azure-resurs.
• Övervakningsdata för Azure-prenumerationer: Data om drift och hantering av en Azure-prenumeration samt hälsotillstånd och drift av Själva Azure.
• Övervakningsdata för Azure-klientorganisationen: Data om driften av Azure-tjänster på klientnivå, till exempel Microsoft Entra-ID.
• Anpassade källor: Loggar som skickas från lokala källor kan också inkluderas. Exempel är lokala serverhändelser eller syslog-utdata för nätverksenheter.

Övervakning av data är bara användbart om det kan öka din insyn i driften av din databehandlingsmiljö. Azure Monitor innehåller flera funktioner och verktyg som ger värdefulla insikter om dina program och andra resurser som de är beroende av. Övervakningslösningar och funktioner som application insights och Azure Monitor för containrar ger djupgående insikter om olika aspekter av ditt program och specifika Azure-tjänster.

Övervakningslösningar i Azure Monitor är paketerade uppsättningar med logik som ger insikter för ett visst program eller en viss tjänst. De innehåller logik för att samla in övervakningsdata för programmet eller tjänsten, frågor för att analysera dessa data och vyer för visualisering. Övervakningslösningar är tillgängliga från Microsoft och partner för att tillhandahålla övervakning för olika Azure-tjänster och andra program.

Med en sådan samling omfattande data är det viktigt att vidta proaktiva åtgärder för händelser som inträffar i din miljö, särskilt där manuella frågor inte räcker. Aviseringar i Azure Monitor meddelar dig proaktivt om kritiska villkor och kan försöka vidta korrigerande åtgärder. Aviseringsregler baserade på mått ger nästan realtidsaviseringar baserat på numeriska värden. Aviseringsregler baserade på loggar möjliggör komplex logik mellan data från flera källor. Aviseringsregler i Azure Monitor använder åtgärdsgrupper som innehåller unika uppsättningar mottagare och åtgärder som kan delas mellan flera regler. Baserat på dina krav kan åtgärdsgrupper använda webhooks som gör att aviseringar startar externa åtgärder eller integreras med dina ITSM-verktyg.

Med Azure Monitor kan du också skapa anpassade instrumentpaneler. Med Azure-instrumentpaneler kan du kombinera olika typer av data, inklusive både mått och loggar, i ett enda fönster i Azure-portalen. Du kan också dela instrumentpanelen med andra Azure-användare. Element i Hela Azure Monitor kan läggas till på en Azure-instrumentpanel utöver utdata från alla loggfrågor eller måttdiagram. Du kan till exempel skapa en instrumentpanel som kombinerar paneler som visar ett diagram med mått, en tabell med aktivitetsloggar, ett användningsdiagram från application insights och utdata från en loggfråga.

Slutligen är Azure Monitor-data en intern källa för Power BI. Power BI är en tjänst för affärsanalys som tillhandahåller interaktiva visualiseringar mellan olika datakällor. Det är också ett effektivt sätt att göra data tillgängliga för andra inom och utanför organisationen. Du kan konfigurera Power BI för att automatiskt importera loggdata från Azure Monitor för att dra nytta av dessa fler visualiseringar.

Azure Network Watcher innehåller verktyg för att övervaka, diagnostisera och visa mått och aktivera eller inaktivera loggar för resurser i ett virtuellt nätverk i Azure. Det är en mångfacetterad tjänst som tillåter följande funktioner med mera:

• Övervaka kommunikationen mellan en virtuell dator och en slutpunkt.
• Visa resurser i ett virtuellt nätverk och deras relationer.
• Diagnostisera problem med filtrering av nätverkstrafik till eller från en virtuell dator.
• Diagnostisera problem med nätverksroutning från en virtuell dator.
• Diagnostisera utgående anslutningar från en virtuell dator.
• Samla in paket till och från en virtuell dator.
• Diagnostisera problem med en virtuell nätverksgateway och anslutningar.
• Fastställa relativa svarstider mellan Azure-regioner och internetleverantörer.
• Visa säkerhetsregler för ett nätverksgränssnitt.
• Visa nätverksmått.
• Analysera trafik till eller från en nätverkssäkerhetsgrupp.
• Visa diagnostikloggar för nätverksresurser.

Komponenttyp: Arbetsbelastningar

Arbetsbelastningskomponenter är där dina faktiska program och tjänster finns. Det är där dina programutvecklingsteam tillbringar större delen av sin tid.

Arbetsbelastningsmöjligheterna är oändliga. Följande är bara några av de möjliga arbetsbelastningstyperna:

Interna program: Verksamhetsspecifika program är viktiga för företagsåtgärder. Dessa program har några vanliga egenskaper:

• Interaktiv: Data anges och resultat eller rapporter returneras.
• Datadriven: Dataintensiv med frekvent åtkomst till databaser eller annan lagring.
• Integrerad: Erbjuda integrering med andra system inom eller utanför organisationen.

Kundriktade webbplatser (internetuppkopplade eller internt riktade): De flesta internetprogram är webbplatser. Azure kan köra en webbplats via antingen en virtuell IaaS-dator eller en Azure Web Apps-webbplats (PaaS). Azure-webbappar integreras med virtuella nätverk för att distribuera webbappar i en ekernätverkszon. Internt riktade webbplatser behöver inte exponera en offentlig Internetslutpunkt eftersom resurserna är tillgängliga via privata icke-Internet-routbara adresser från det privata virtuella nätverket.

Stordataanalys: När data behöver skalas upp till större volymer kanske relationsdatabaser inte fungerar bra under extrem belastning eller ostrukturerad typ av data. Azure HDInsight är en hanterad analystjänst med fullständigt spektrum med öppen källkod i molnet för företag. Du kan använda ramverk med öppen källkod, till exempel Hadoop, Apache Spark, Apache Hive, LLAP, Apache Kafka, Apache Storm och R. HDInsight. Detta stöder distribution till ett platsbaserat virtuellt nätverk som kan distribueras till ett kluster i en eker av det virtuella datacentret.

Händelser och meddelanden: Azure Event Hubs är en plattform för stordataströmning och händelseinmatning. Den kan ta emot och behandla miljoner händelser per sekund. Det ger låg svarstid och konfigurerbar tidsbevarande, så att du kan mata in enorma mängder data i Azure och läsa dem från flera program. En enda ström kan stödja både realtids- och batchbaserade pipelines.

Du kan implementera en mycket tillförlitlig molnmeddelandetjänst mellan program och tjänster via Azure Service Bus. Den erbjuder asynkrona asynkrona asynkrona asynkrona meddelanden mellan klient och server, strukturerade FIFO-meddelanden (first-in-first-out) och publicerar och prenumererar funktioner.

De här exemplen skrapar knappt ytan på de typer av arbetsbelastningar som du kan skapa i Azure. Du kan skapa allt från en grundläggande webb- och SQL-app till den senaste i IoT, stordata, maskininlärning, AI och så mycket mer.

Hög tillgänglighet: flera virtuella datacenter

Hittills har den här artikeln fokuserat på utformningen av en enda VDC, som beskriver de grundläggande komponenter och arkitekturer som bidrar till återhämtning. Azure-funktioner som Azure Load Balancer, NVA, tillgänglighetszoner, tillgänglighetsuppsättningar, skalningsuppsättningar och andra funktioner som hjälper dig att inkludera solida serviceavtalsnivåer i dina produktionstjänster.

Men eftersom ett virtuellt datacenter vanligtvis implementeras i en enda region kan det vara sårbart för avbrott som påverkar hela regionen. Kunder som kräver hög tillgänglighet måste skydda tjänsterna genom distributioner av samma projekt i två eller flera VDC-implementeringar som distribueras till olika regioner.

Förutom problem med serviceavtal har flera vanliga scenarier nytta av att köra flera virtuella datacenter:

• Regional eller global närvaro av dina slutanvändare eller partner.
• Krav för haveriberedskap.
• En mekanism för att omdirigera trafik mellan datacenter för belastning eller prestanda.

Regional/global närvaro

Azure-datacenter finns i många regioner över hela världen. När du väljer flera Azure-datacenter bör du överväga två relaterade faktorer: geografiska avstånd och svarstid. För att optimera användarupplevelsen utvärderar du avståndet mellan varje virtuellt datacenter och avståndet från varje virtuellt datacenter till slutanvändarna.

En Azure-region som är värd för ditt virtuella datacenter måste uppfylla regelkraven för alla juridiska jurisdiktioner som din organisation är verksam under.

Haveriberedskap

Utformningen av en haveriberedskapsplan beror på vilka typer av arbetsbelastningar och möjligheten att synkronisera tillståndet för dessa arbetsbelastningar mellan olika VDC-implementeringar. Helst vill de flesta kunder ha en snabb redundansmekanism, och det här kravet kan behöva programdatasynkronisering mellan distributioner som körs i flera VDC-implementeringar. När du utformar planer för haveriberedskap är det dock viktigt att tänka på att de flesta program är känsliga för svarstiden som kan orsakas av den här datasynkroniseringen.

Synkronisering och pulsslagsövervakning av program i olika VDC-implementeringar kräver att de kommunicerar via nätverket. Flera VDC-implementeringar i olika regioner kan anslutas via:

• Hub-to-hub-kommunikation inbyggd i Azure Virtual WAN-hubbar mellan regioner i samma Virtual WAN.
• Peering för virtuella nätverk för att ansluta hubbar mellan regioner.
• ExpressRoute privat peering, när hubbarna i varje VDC-implementering är anslutna till samma ExpressRoute-krets.
• Flera ExpressRoute-kretsar som är anslutna via företagets stamnät och dina flera VDC-implementeringar anslutna till ExpressRoute-kretsarna.
• Plats-till-plats-VPN-anslutningar mellan hubbzonen för dina VDC-implementeringar i varje Azure-region.

Virtuella WAN-hubbar, peering för virtuella nätverk eller ExpressRoute-anslutningar föredras vanligtvis för nätverksanslutningar på grund av högre bandbredd och konsekventa svarstidsnivåer vid överföring via Microsofts stamnät.

Kör testerna för nätverkskvalificering för att verifiera svarstiden och bandbredden för dessa anslutningar och avgöra om synkron eller asynkron datareplikering är lämplig baserat på resultatet. Det är också viktigt att väga dessa resultat med tanke på det optimala målet för återställningstid (RTO).

Haveriberedskap: omdirigera trafik från en region till en annan

Både Azure Traffic Manager och Azure Front Door kontrollerar regelbundet tjänstens hälsotillstånd för lyssnande slutpunkter i olika VDC-implementeringar. Om dessa slutpunkter misslyckas dirigerar Azure Traffic Manager och Azure Front Door automatiskt till nästa närmaste VDC. Traffic Manager använder användarmätningar i realtid och DNS för att dirigera användare till närmaste (eller närmaste vid fel). Azure Front Door är en omvänd proxy på över 100 Microsoft-stambrytarwebbplatser med anycast för att dirigera användare till den närmast lyssnande slutpunkten.

Sammanfattning

Den virtuella datacentermetoden för migrering är att skapa en skalbar arkitektur som optimerar användningen av Azure-resurser, sänker kostnaderna och förenklar systemstyrningen. Det virtuella datacentret är typiskt baserat på nav- och ekernätverkstopologier (med antingen peering för virtuella nätverk eller Virtual WAN-hubbar). Vanliga delade tjänster som tillhandahålls i hubben och specifika program och arbetsbelastningar distribueras i ekrarna. Det virtuella datacentret matchar också strukturen för företagsroller, där olika avdelningar som central IT, DevOps och drift och underhåll arbetar tillsammans samtidigt som de utför sina specifika roller. Det virtuella datacentret stöder migrering av befintliga lokala arbetsbelastningar till Azure, men ger också många fördelar med molnbaserade distributioner.

Referenser

Läs mer om De Azure-funktioner som beskrivs i det här dokumentet.

Nätverksfunktioner
Azure Virtual Networks
Nätverkssäkerhetsgrupper
Tjänstslutpunkter
Private Link
Användardefinierade vägar
Virtuella nätverksinstallationer
Offentliga IP-adresser
Azure DNS

Belastningsutjämning
Azure Front Door
Azure Load Balancer (Lager 4)
Application Gateway (Layer 7)
Azure Traffic Manager

Anslutning
Peering för virtuella nätverk
Virtuellt privat nätverk
Virtual WAN
ExpressRoute
ExpressRoute Direct

Identitet
Microsoft Entra ID
Microsoft Entra multifaktorautentisering
Rollbaserad Azure-åtkomstkontroll
Inbyggda roller i Azure

Övervakning
Network Watcher
Azure Monitor
Log Analytics

Bästa praxis
Hanteringsgrupp
Prenumerationshantering
Resursgruppshantering
Azure-prenumerationsgränser

Säkerhet
Azure Firewall
Brandväggshanteraren
Application Gateway WAF
Front Door WAF
Azure DDoS

Andra Azure-tjänster
Azure Storage
Azure SQL
Azure Web Apps
Azure Cosmos DB
HDInsight
Event Hubs
Service Bus
Azure IoT
Azure Machine Learning

Nästa steg

• Läs mer om peering för virtuella nätverk, kärntekniken för hubb- och ekertopologier.
• Implementera Microsoft Entra-ID för att använda rollbaserad åtkomstkontroll i Azure.
• Utveckla en prenumerations- och resurshanteringsmodell med rollbaserad åtkomstkontroll i Azure som passar organisationens struktur, krav och principer. Den viktigaste aktiviteten är planering. Analysera hur omorganiseringar, sammanslagningar, nya produktlinjer och andra överväganden påverkar dina ursprungliga modeller för att säkerställa att du kan skala för att uppfylla framtida behov och tillväxt.