Det virtuella datacentret: Ett nätverksperspektiv

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

Microsoft Azure levererar tjänster och infrastruktur i hyperskala med funktioner i företagsklass och tillförlitlighet. Dessa tjänster och infrastrukturer erbjuder många alternativ i hybridanslutningar, så kunder kan välja att komma åt dem via Internet eller en privat nätverksanslutning. Microsoft-partner kan också erbjuda 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 olika platser.

Vad är ett virtuellt datacenter?

Molnet började som en plattform för att vara värd för offentliga program. Företag kände igen molnets värde och började migrera interna affärsprogram. Dessa program gav ytterligare säkerhets-, tillförlitlighets-, prestanda- och kostnadsöverväganden som krävde ytterligare flexibilitet vid leverans av molntjänster. Nya infrastruktur- och nätverkstjänster har utformats för att ge den här flexibiliteten och nya funktioner för 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. Den här metoden fungerade bra i några år. När fördelarna med molnlösningar blev tydliga fanns det flera storskaliga arbetsbelastningar i molnet. Att hantera säkerhets-, tillförlitlighets-, prestanda- och kostnadsproblem för distributioner i en eller flera regioner blev avgörande under molntjänstens livscykel.

I exemplet på molndistributionsdiagram nedan visar den röda rutan ett säkerhetsgap. Den gula rutan visar en möjlighet att optimera virtuella nätverks installationer mellan arbetsbelastningar.

Virtuella datacenter hjälper till att uppnå den skala som krävs för företagsarbetsbelastningar. Den här skalan måste hantera de utmaningar som introduceras vid körning av storskaliga program i det offentliga molnet.

Implementeringen av ett virtuellt datacenter (VDC) omfattar mer än programarbetsbelastningarna i molnet. Den tillhandahåller även nätverk, säkerhet, hantering och annan infrastruktur, till exempel DNS- och Active Directory-tjänster. När företag migrerar ytterligare arbetsbelastningar till Azure bör du överväga den infrastruktur och de objekt som stöder dessa arbetsbelastningar. Genom att noggrant strukturera dina resurser kan du undvika spridning av hundratals separat hanterade "arbetsbelastningsöarna" med oberoende dataflöden, säkerhetsmodeller och efterlevnadsutmaningar.

Konceptet med virtuella datacenter ger rekommendationer och design på hög nivå för implementering av 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 minska kostnaderna från stordriftsfördelar, optimerad säkerhet via centralisering av komponenter och dataflöden och enklare drift, hantering och efterlevnadsgranskningar.

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

• Vara 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 du implementera ett virtuellt datacenter?

Alla kunder som har valt att börja använda Azure kan dra nytta av effektiviteten med att konfigurera en uppsättning resurser för gemensam användning av alla program. Beroende på storleken kan även enskilda program dra nytta av 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. Implementering av en VDC kan hjälpa till att genomdriva princippunkter, separata ansvarsområden och säkerställa konsekvensen för de underliggande gemensamma komponenterna. Programteam kan behålla den frihet och kontroll som passar deras krav.

Organisationer med en DevOps-metod kan också använda VDC-koncept för att tillhandahålla auktoriserade azure-resurser. Den här metoden kan se till att DevOps-grupperna har fullständig kontroll inom den gruppgruppen, antingen på prenumerationsnivå eller inom resursgrupper i en gemensam prenumeration. Samtidigt förblir nätverks- och säkerhetsgränserna kompatibla enligt definitionen av en centraliserad princip i navnätverket och centralt hanterad resursgrupp.

Att tänka på när du implementerar ett virtuellt datacenter

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

Identitets- och katalogtjänst

Identitets- och katalogtjänster är viktiga funktioner i både lokala och molnbaserade datacenter. Identitet omfattar alla aspekter av åtkomst och auktorisering till tjänster i 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, inklusive kontolösenord, kryptografiska nycklar, digitala signaturer och certifikat. Azure Multi-Factor Authentication ger ett extra säkerhetslager för åtkomst till Azure-tjänster med stark autentisering med en mängd enkla verifieringsalternativ (telefonsamtal, SMS eller mobilappsavisering) som gör att kunderna kan välja den metod de föredrar.

Stora företag måste definiera en identitetshanteringsprocess som beskriver hanteringen av enskilda identiteter, deras autentisering, auktorisering, roller och behörigheter inom eller över deras VDC. Målet med den här processen bör vara att öka säkerheten och produktiviteten samtidigt som kostnaderna, stilleståndstiden och repetitiva manuella uppgifter minskar.

Företagsorganisationer kan behöva en krävande blandning av tjänster för olika verksamheter, och anställda har ofta olika roller när de är involverade i olika projekt. VDC kräver ett bra samarbete mellan olika team, var och en med specifika rolldefinitioner, för att få igång system med bra styrning. Matrisen med ansvarsområden, åtkomst och rättigheter kan vara komplex. Identitetshantering i VDC implementeras via Azure Active Directory (Azure AD) och rollbaserad åtkomstkontroll i Azure (Azure RBAC).

En katalogtjänst är en delad informationsinfrastruktur som hittar, hanterar, administrerar och organiserar dagliga objekt och nätverksresurser. Dessa resurser kan vara volymer, mappar, filer, skrivare, användare, grupper, enheter och andra objekt. Varje resurs i nätverket anses vara ett objekt av katalogservern. Information om en resurs lagras som en samling attribut som är associerade med resursen eller objektet.

Alla Microsofts onlineföretagstjänster använder Azure Active Directory (Azure AD) för inloggning och andra identitetsbehov. Azure Active Directory är en omfattande molnlösning för identitets- och åtkomsthantering med hög tillgänglighet som kombinerar viktiga katalogtjänster, avancerad identitetsstyrning och programåtkomsthantering. Azure AD kan integreras med lokal Active Directory för att aktivera enkel inloggning för alla molnbaserade och lokalt värdbaserade lokala program. Användarattributen för lokal Active Directory synkroniseras automatiskt till Azure AD.

En enda global administratör krävs inte för att tilldela alla behörigheter i en VDC-implementering. I stället kan varje avdelning, grupp av användare eller tjänster i katalogtjänsten ha de behörigheter som krävs för att hantera sina egna resurser i en VDC-implementering. Struktureringsbehörigheter kräver balansering. För många behörigheter kan påverka prestandaeffektiviteten, och för få eller lösa behörigheter kan öka säkerhetsriskerna. Rollbaserad åtkomstkontroll i Azure (Azure RBAC) hjälper till att lösa det här problemet genom att erbjuda mer information om åtkomsthantering för resurser i en VDC-implementering.

Säkerhetsinfrastruktur

Säkerhetsinfrastruktur syftar på uppdelningen av trafik i en VDC-implementerings specifika segment för virtuella nätverk. Den här infrastrukturen anger hur in- och utgående trafik styrs i en VDC-implementering. Azure baseras på en arkitektur för flera användare som förhindrar obehörig och oavsiktlig trafik mellan distributioner genom att använda isolering av virtuella nätverk, åtkomstkontrolllistor, lastbalanserare, IP-filter och trafikflödesprinciper. NAT (Network Address Translation) separerar intern nätverkstrafik från extern trafik.

Azure-infrastrukturen allokerar infrastrukturresurser till klientarbetsbelastningar och hanterar kommunikationen till och från virtuella datorer (VM). Azure-hypervisorn tillämpar minnes- och processavskiljning mellan virtuella datorer och dirigerar nätverkstrafik på ett säkert sätt till gästoperativsystemklienter.

Anslutning till molnet

Ett virtuellt datacenter kräver anslutning till externa nätverk för att kunna 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.

Kunder styr vilka 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ätverksutrustning (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 Internetriktade resurser också skyddas av Azure DDoS Protection Standard.

Företag kan behöva ansluta sina 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 koppling: överföring via Internet eller via privata direktanslutningar.

Ett azure-VPN för plats-till-plats ansluter lokala nätverk till ditt virtuella datacenter i Azure. Länken upprättas via säkra krypterade anslutningar (IPsec-tunnlar). Azures VPN-anslutningar för plats-till-plats är flexibla, snabba att skapa och kräver vanligtvis ingen ytterligare 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 alla 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 dig fördelarna med efterlevnadsregler som är associerade med privata anslutningar. Med ExpressRoute Directkan 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 börja snabbt är det vanligt att initialt använda plats-till-plats-VPN för att upprätta en anslutning mellan ett virtuellt datacenter och lokala resurser. När den fysiska anslutningen till tjänstleverantören är klar migrerar du anslutningen via ExpressRoute-anslutningen.

För ett stort antal VPN- eller ExpressRoute-Azure Virtual WAN är en nätverkstjänst som tillhandahåller optimerad och automatiserad gren-till-gren-anslutning via Azure. Virtual WAN kan du ansluta till och konfigurera grenenheter för att kommunicera med Azure. Du kan ansluta och konfigurera antingen manuellt eller genom att använda prioriterade providerenheter via en Virtual WAN partner. Genom att använda prioriterade providerenheter kan du enkelt använda, förenkla anslutningen och hantera konfigurationen. Den inbyggda instrumentpanelen i Azure WAN ger omedelbara felsökningsinsikter som kan hjälpa dig att spara tid och ger dig ett enkelt sätt att visa storskalig plats-till-plats-anslutning. Virtual WAN tillhandahåller även säkerhetstjänster med valfria Azure Firewall och Firewall Manager i Virtual WAN hubben.

Anslutning i molnet

Virtuella Azure-nätverkoch 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 gör det möjligt att skapa en relation mellan olika virtuella nätverk i samma Azure-region, mellan regioner och till och med mellan nätverk i olika prenumerationer. Både i och mellan virtuella nätverk kan trafikflöden styras av uppsättningar säkerhetsregler som anges för nätverkssäkerhetsgrupper, brandväggsprinciper (Azure Firewall eller virtuella nätverkstillverk )och anpassade användardefinierade vägar.

Virtuella nätverk är också fästpunkter för integrering av PaaS-produkter (plattform som en tjänst) som Azure Storage,Azure SQLoch andra integrerade offentliga tjänster som har offentliga slutpunkter. Med tjänstslutpunkteroch Azure Private Linkkan du integrera dina offentliga tjänster med ditt privata nätverk. Du kan även ta dina offentliga tjänster privata, men ändå dra nytta av fördelarna med Azure-hanterade PaaS-tjänster.

Översikt över virtuellt datacenter

Topologier

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

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

I en Mesh-topologiansluter 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 scenarier för avdelningskontor och globala WAN-tjänster.

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

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

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

• Den Windows Active Directory-infrastrukturen, som 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 ekrarna. Det inkluderar relaterade Active Directory Federation Services (AD FS).
• En DNS-tjänst (Distributed Name System) för att matcha namn på arbetsbelastningen i ekrarna för att få åtkomst till resurser lokalt och på Internet om Azure DNS inte används.
• En PKI (Public Key Infrastructure) för att implementera enkel inloggning på arbetsbelastningar.
• Flödeskontroll av TCP- och UDP-trafik mellan ekrarnas nätverkszoner och Internet.
• Flödeskontroll mellan ekrar och lokalt.
• Vid behov, flödeskontroll mellan två ekrar.

Ett virtuellt datacenter minskar den totala kostnaden genom att använda 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 utveckling/testning, testning av användargodkännande, förproduktion och produktion. Ekrarna kan också särskilja och aktivera olika grupper i din organisation. Ett exempel är DevOps-grupper. 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

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 till ett stort antal ekrar, men precis som för alla IT-system finns det plattformsgränser. Hubbdistributionen är bunden till en specifik Azure-prenumeration som har begränsningar (till exempel ett maximalt antal peer-program för virtuella nätverk). Mer information finns i Azure-prenumeration och tjänstbegränsningar, 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 nav och ekrar. Flera hubbar i en eller flera Azure-regioner kan anslutas med hjälp av peering för virtuella nätverk, ExpressRoute, Virtual WAN eller PLATS-till-plats-VPN.

Införandet av flera hubbar ökar systemets kostnader och hantering. Den är endast berättigad på grund av skalbarhet, systemgränser, redundans, regional replikering för slutanvändares 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 drift.

Samtrafik mellan ekrar

I en enda eker, eller en platt nätverksdesign, är det möjligt att implementera komplexa arbetsbelastningar på flera olika plan. Konfigurationer med flera nivåer kan implementeras med hjälp av undernät, ett 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 när programbearbetningsservrar finns i en eker eller ett virtuellt nätverk. Databasen distribueras i en annan eker eller ett virtuellt nätverk. I det här fallet är det enkelt att sammankoppla ekrarna med peering för virtuella nätverk och på så sätt undvika att passera genom hubben. En noggrann arkitektur- och säkerhetsgranskning bör göras för att säkerställa att förbikoppling av hubben inte kringgår viktiga säkerhets- eller granskningspunkter som kanske bara finns i hubben.

Ekrar kan också vara sammankopplade till en eker som fungerar som hubb. Den här metoden skapar en hierarki på två nivåer: ekern på den högre nivån (nivå 0) blir hubb för nedre ekrar (nivå 1) i hierarkin. Ekrarna för en VDC-implementering krävs för att vidarebefordra trafiken till den centrala hubben så att trafiken kan överförs 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 hanteringsinsatsen ä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,Arbetsbelastningaroch Ö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 slutligen skapa VDC.

Föregående översiktliga arkitektur för VDC visar olika komponenttyper som används i olika zoner i topologin av typen hub-spokes. Diagrammet visar infrastrukturkomponenter i olika delar av arkitekturen.

Som bästa praxis i allmänhet bör åtkomsträttigheter och behörigheter vara gruppbaserade. Att hantera grupper i stället för enskilda användare underlättar underhållet av åtkomstprinciper, genom att tillhandahålla ett konsekvent sätt att hantera det mellan team och bidrar 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 specifik användare uppdaterade.

Varje rollgrupp ska ha ett unikt prefix på sina namn. Det här prefixet gör det enkelt att identifiera vilken grupp som är associerad med vilken arbetsbelastning. En arbetsbelastning som är värd för en autentiseringstjänst kan till exempel ha grupper med namnet AuthServiceNetOps,AuthServiceSecOps,AuthServiceDevOpsoch 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 större uppdelning av roller:

• Det centrala IT-teamet som heter Corp har ägarskapsbehörighet för att kontrollera infrastrukturkomponenter. Exempel är nätverk och säkerhet. Gruppen måste ha rollen deltagare i prenumerationen, kontroll av hubben och nätverksdeltagares rättigheter i ekrarna. Stora organisationer delar ofta upp dessa hanteringsansvar mellan flera team. Exempel är en CorpNetOps-grupp för nätverksåtgärder med exklusivt fokus på nätverk och en corpSecOps-säkerhetsgrupp som ansvarar för brandväggen och säkerhetsprincipen. I det här specifika fallet måste två olika grupper skapas för tilldelning av dessa anpassade roller.
• Dev/test-gruppen med namnet AppDevOps ansvarar för att distribuera app- eller tjänstarbetsbelastningar. Den här gruppen har rollen virtuell datordeltagare för IaaS-distributioner eller en eller flera PaaS-deltagares roller. Mer information finns i Inbyggda roller i Azure. Alternativt 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 deltagare för arbetsbelastningar behöver den här gruppen även rollen som nätverksläsare.
• Åtgärds- och underhållsgruppen CorpInfraOps eller AppInfraOps ansvarar för att hantera arbetsbelastningar i produktion. Den här gruppen måste vara prenumerationsdeltagare för arbetsbelastningar i produktionsprenumerationer. Vissa organisationer kan också utvärdera om de behöver ytterligare en eskaleringssupportgrupp med rollen prenumerationsdeltagare i produktion och prenumerationen på den centrala hubben. Den ytterligare gruppen åtgärdar potentiella konfigurationsproblem i produktionsmiljön.

VDC är utformat så att grupper som skapats för det centrala IT-teamet, som hanterar hubben, har motsvarande grupper på arbetsbelastningsnivå. Förutom att bara hantera hubbresurser kan det centrala IT-teamet kontrollera extern åtkomst och toppnivåbehörigheter för prenumerationen. Arbetsbelastningsgrupper kan också styra resurser och behörigheter för sina virtuella nätverk oberoende av det centrala IT-teamet.

Det virtuella datacentret är partitionerat för att på ett säkert sätt vara värd för flera projekt i olika affärsområden. 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 och grupper samt de miljöer där Azure-komponenterna distribueras.

Vanligtvis 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 ofta åtskilda, ofta med flera mellanlagringsmiljöer däremellan för att tillåta fasad distribution (distribution), testning och återställning om problem uppstår. Distributionsarkitekturer 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 miljöer består av DevOps för utveckling och testning, UAT för mellanlagrings- och produktionsmiljöer. Organisationer kan använda en eller flera Azure AD-klientorganisationer för att definiera åtkomst och rättigheter till dessa miljöer. I föregående diagram visas ett fall där två olika Azure AD-klienter används: en för DevOps och UAT och den andra exklusivt för produktion.

Förekomsten av olika Azure AD-klienter framtvingar uppdelningen mellan miljöer. Samma grupp användare, till exempel det centrala IT-teamet, måste autentisera med hjälp av en annan URI för att få åtkomst till en annan Azure AD-klientorganisation för att ändra roller eller behörigheter för antingen DevOps- eller produktionsmiljöer för ett projekt. Förekomsten av olika användarautentiseringar för att få åtkomst till olika miljöer minskar möjliga avbrott och andra problem som orsakas av mänskliga fel.

Komponenttyp: Infrastruktur

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

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

En av de viktigaste uppgifterna för IT-infrastrukturteamet är att garantera konsekvensen för IP-adressscheman i hela företaget. Det privata IP-adressutrymmet som är tilldelat till 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 lägger till problem i infrastrukturkomponenterna. Enkelheten i hanteringen är ett av de viktigaste målen för VDC, så att använda NAT för att hantera IP-problem, medan en giltig lösning, inte är en rekommenderad lösning.

Infrastrukturkomponenter har följande funktioner:

• Identitets- och katalogtjänster. Åtkomst till alla resurstyper i Azure styrs av en identitet som lagras i en katalogtjänst. Katalogtjänsten lagrar inte bara listan över användare, utan även åtkomstbehörigheten till resurser i en specifik Azure-prenumeration. Dessa tjänster kan endast finnas i molnet, eller så kan de synkroniseras med lokala identiteter som lagras i Active Directory.
• Virtual Network. 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, vart och ett med ett specifikt IP-nätverksprefix (ett undernät, Antingen IPv4 eller dubbel stack-IPv4/IPv6). 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 med virtuella datorer (och PaaS-tjänster) i ett annat virtuellt nätverk, även om båda virtuella nätverken skapas av samma kund, under samma prenumeration. Isolering är en kritisk egenskap som säkerställer att kundens virtuella datorer och kommunikation förblir privat i ett virtuellt nätverk. I de fall där anslutning mellan nätverk önskas beskriver följande funktioner hur detta kan utföras.
• 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, antingen via Azures datacenternätverk eller genom att använda Azures globala stamnät mellan regioner.
• Virtual Network tjänstslutpunkter. Tjänstslutpunkter utökar det privata adressutrymmet för det virtuella nätverket så att det omfattar 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 till endast dina virtuella nätverk.
• Private Link. Azure Private Link ger dig åtkomst till Azure PaaS-tjänster (till exempel Azure Storage,Azure Cosmos DBoch Azure SQL Database) och Azure-värdtjänster för kunder/partner 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 Service 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å systemets routningstabell. 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 systemrdirigeringstabellen och definiera en kommunikationssökväg i ett virtuellt nätverk. Förekomsten av användardefinierade vägar garanterar att utgående trafik från ekerövergången via specifika anpassade virtuella datorer eller virtuella nätverksutrustning och lastbalanserare finns i både navet och ekrarna.
• Nätverkssäkerhetsgrupper. En nätverkssäkerhetsgrupp är en lista över säkerhetsregler som fungerar som trafikfiltrering för IP-källor, IP-mål, protokoll, IP-källportar och IP-målportar (kallas även layer 4 med fem tuppeln). Nätverkssäkerhetsgruppen kan tillämpas på ett undernät, ett virtuellt nätverkskort som är associerat med en virtuell Azure-dator eller både och. Nätverkssäkerhetsgrupperna är nödvändiga för att implementera en korrekt flödeskontroll i navet och ekrarna. Den säkerhetsnivå som nätverkssäkerhetsgruppen ger är en funktion för vilka portar du öppnar och i vilket syfte. Kunder bör använda ytterligare filter per virtuell dator med värdbaserade brandväggar, till exempel iptables eller Windows Firewall.
• DNS. DNS tillhandahåller namnmatchning för resurser i ett virtuellt datacenter. Azure tillhandahåller DNS-tjänster för både offentlig ochprivat namnmatchning. Privata zoner tillhandahåller namnmatchning både i ett virtuellt nätverk och mellan virtuella nätverk. Du kan ha privata zoner som inte bara sträcker sig över virtuella nätverk i samma region, utan även mellan regioner och prenumerationer. För offentlig lösning tillhandahåller Azure DNS värdtjänst för DNS-domäner, vilket ger 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.
• Hanteringsgrupp,prenumerationoch resursgruppshantering. En prenumeration definierar en naturlig gräns för att skapa flera grupper av resurser i Azure. Den här uppdelningen kan vara för funktion, rollseparering eller fakturering. Resurser i en prenumeration sammanställs 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 kan det behövas ett effektivt sätt att hantera åtkomst, principer och efterlevnad för prenumerationerna. Azure-hanteringsgrupper ger en omgångsnivå som omfattar prenumerationer. Du ordnar 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 se Organisera dina resurser i Cloud Adoption Framework.
• Rollbaserad åtkomstkontroll i Azure (Azure RBAC). Azure RBAC kan mappa organisationsroller och rättigheter för åtkomst till specifika Azure-resurser, så att du kan begränsa användare till endast en viss delmängd av åtgärder. Om du synkroniserar Azure Active Directory med en lokal 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 tilldelas i ett överordnat omfång ger också åtkomst till de underordnade objekt som finns i den. Med Azure RBAC kan du åtseger uppgifter och endast bevilja den mängd åtkomst till användare som de behöver för att utföra sitt arbete. En anställd kan till exempel hantera virtuella datorer i en prenumeration, medan en annan kan hantera SQL Server i samma prenumeration.

Komponenttyp: Perimeternätverk

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

Inkommande paket ska flöda genom säkerhetsutrustningen i hubben innan de når serversidans servrar och tjänster i ekrarna. Exempel är brandväggen, IDS och IPS. Innan de lämnar nätverket bör internetbundna paket från arbetsbelastningarna också flöda genom säkerhetsutrustningen i perimeternätverket. Det här flödet möjliggör principtvingande, inspektion och granskning.

Perimeternätverkskomponenter omfattar:

• 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 webbaserade program (WAF)
• Offentliga IP-adresser
• Azure Front Door med brandvägg för webbaserade program (WAF)
• Azure Firewall och Azure Firewall Manager
• Standard DDoS Protection

Det centrala IT-teamet och säkerhetsteamen ansvarar vanligtvis för kravdefinitionen och driften av perimeternätverken.

Föregående diagram visar tillämpningen av två perimeterer med åtkomst till Internet och ett lokalt nätverk, som båda finns i DMZ-hubben. I DMZ-hubben kan perimeternätverket till Internet skalas upp för att stödja många affärsområden med hjälp av flera webbprogrambrandväggsgrupper (WAF) eller Azure Firewalls. Hubben möjliggör även lokal anslutning via VPN eller ExpressRoute efter behov.

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

Användardefinierade vägar. Med hjälp av användardefinierade vägar kan kunder distribuera brandväggar, ID:n/IPS och andra virtuella installationer och dirigera nätverkstrafik genom dessa säkerhetskontroller för tillämpning, granskning och inspektion av säkerhetsgränser. Användardefinierade vägar kan skapas i både navet och ekrarna för att garantera att trafiken överförs via de specifika anpassade virtuella datorerna, virtuella nätverkstillverkare och lastbalanserare som används av en VDC-implementering. För att garantera att trafik som genereras från virtuella datorer som finns i ekerövergångarna till rätt virtuella installationer, måste en användardefinierad väg anges i ekerundernäten genom att ange frontend-IP-adressen 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 tjänst för nätverkssäkerhet som skyddar dina Azure Virtual Network resurser. Det är en tillståndsstyrd hanterad brandvägg med hög tillgänglighet och molnskalbarhet. 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äkerhets perimeterer. Den fungerar med Azure Virtual WAN Hub, en Microsoft-hanterad resurs som gör att du enkelt kan skapa nav- och ekerarkitekturer. När säkerhet och routningsprinciper är associerade med en sådan hubb kallas det för en skyddad virtuell hubb.

Virtuella nätverksapparater. I hubben hanteras perimeternätverket med åtkomst till Internet vanligtvis via en Azure Firewall instans eller en servergrupp med brandväggar eller brandväggar för webbaserade program (WAF).

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

En Azure Firewall- eller NVA-brandvägg använder både ett gemensamt administrationsplan, med en uppsättning säkerhetsregler för att skydda arbetsbelastningarna som finns i ekrarna och kontrollera åtkomsten till lokala nätverk. Den 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 BRANDVÄGG, men har ett bredare programomfång för att filtrera och inspektera all typ av trafik i utgående och ingående trafik. 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 utgör en säkerhetsrisk eftersom det inte ger någon säkerhets perimeter mellan de två uppsättningarna med nätverkstrafik. Att använda separata brandväggslager minskar komplexiteten med att kontrollera säkerhetsregler och gör det tydligt vilka regler som motsvarar vilken inkommande nätverksbegäran.

Azure Load Balancer erbjuder en layer 4-tjänst (TCP/UDP) med hög tillgänglighet som kan distribuera inkommande trafik mellan tjänstinstanser som definierats i en belastningsutjämnad uppsättning. Trafik som skickas till lastbalanseraren från klientslutpunkter (offentliga IP-slutpunkter eller privata IP-slutpunkter) kan distribueras om med eller utan adressöversättning till en uppsättning serversidans IP-adresspool (till exempel virtuella nätverkstillverk eller virtuella datorer).

Azure Load Balancer också av hälsotillståndet för de olika serverinstanserna, och när en instans inte svarar på en avsökning slutar lastbalanseraren att skicka trafik till den felaktiga instansen. I ett virtuellt datacenter distribueras en extern lastbalanserare till navet och ekrarna. I hubben används lastbalanserare för att effektivt dirigera trafik över brandväggsinstanser, och i ekrarna används lastbalanserare för att hantera programtrafik.

Azure Front Door (AFD) är Microsofts hög tillgängliga och skalbara plattform för webbprogramacceleration, Global HTTP-Load Balancer, programskydd och Content Delivery Network. Med AFD på fler än 100 platser vid gränsen till Microsofts globala nätverk kan du skapa, använda och skala ut ditt dynamiska webbprogram och statiskt innehåll. AFD förser ditt program med slutanvändarprestanda i världsklass, enhetlig regional/stämpelunderhållsautomatisering, BCDR-automatisering, enhetlig klient-/användarinformation, cachelagring och tjänstinsikter. Plattformen erbjuder:

• Prestanda, tillförlitlighet och stöd för serviceavtal (SLA).
• Efterlevnadscertifieringar.
• Auditable security practices that are developed, operated, and natively supported by Azure.

Azure Front Door också en brandvägg för webbaserade program (WAF) som skyddar webbprogram mot vanliga säkerhetsrisker och exponeringar.

Azure Application Gateway är en dedikerad virtuell installation som tillhandahåller en hanterad programleveranskontrollant. Det erbjuder olika Layer 7-belastningsutjämningsfunktioner för ditt program. Det gör att du kan optimera webbservergruppens prestanda genom att avlasta CPU-intensiv SSL-avslutning till programgatewayen. Den tillhandahå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 Application Gateway. 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 Internetuppriktad gateway, endast intern gateway eller en kombination av båda.

Offentliga IP-adresser. Med vissa Azure-funktioner kan du associera tjänstslutpunkter med en offentlig IP-adress så att din resurs kan nås 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 Standard ger ytterligare skyddsfunktioner över basic-tjänstnivån som är särskilt anpassad efter Azure Virtual Network resurser. DDoS Protection Standard är enkelt att aktivera och kräver inga ändringar i programmet. 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 Load Balancer, Azure Application Gateway och Azure Service Fabric instanser. Systemgenererade loggar är nästan i realtid tillgängliga via Azure Monitor under en attack och för historik. Skydd på programlager kan läggas till via den Azure Application Gateway brandväggen för webbaserade program. Skydd tillhandahålls för offentliga IP-adresser för IPv4 och IPv6 i Azure.

Topologin av nav och ekrar 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 ekrarna till brandväggen innan den passerar lokalt 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 bör ha åtkomst till övervakning av de komponenter och tjänster som de har åtkomst till. Om du har ett centralt support- 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 levererar dessa tjänster en heltäckande 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å användas för att övervaka kritiska lokala resurser så att du får 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 lätta och kan stödja scenarier i nära realtid. För många Azure-resurser ser du data som samlas in av Azure Monitor direkt på översiktssidan i Azure Portal. Titta till exempel på en virtuell dator så ser du flera diagram som visar prestandamått. Välj något av diagrammen för att öppna data i Metrics Explorer i Azure Portal, vilket gör att du kan visa 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 som är 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 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 Log Analytics i Azure Portal och sedan antingen 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 i nivåer från ditt program, alla operativsystem och de tjänster som det förlitar sig på, ned till själva Azure-plattformen. Azure Monitor samlar in data från följande nivåer:

• Programövervakningsdata: Data om prestanda och funktioner i koden som du har skrivit, oavsett plattform.
• Övervakningsdata för gästoperativsystem: Data om operativsystemet som programmet körs på. Det här operativsystemet kan köras i Azure, ett annat moln eller lokalt.
• Övervakningsdata för Azure-resurser: Data om driften av en Azure-resurs.
• Övervakningsdata för Azure-prenumerationer: Data om driften och hanteringen av en Azure-prenumeration, samt data om hälsotillståndet och driften av själva Azure.
• Övervakningsdata för Azure-klientorganisation: Data om driften av Azure-tjänster på klientorganisationsnivå, till exempel Azure Active Directory.
• 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ätverksenhet.

Ö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 paketerade uppsättningar 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.

När alla dessa omfattande data samlas in är det viktigt att vidta proaktiva åtgärder för händelser som inträffar i din miljö där det inte räcker med enbart manuella frågor. Aviseringar i Azure Monitor meddela dig proaktivt om kritiska villkor och eventuellt försöka vidta lämpliga åtgärder. Aviseringsregler som baseras på mått ger aviseringar i nära realtid baserat på numeriska värden, medan regler som baseras på loggar möjliggör komplex logik över 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. Utifrån dina krav kan åtgärdsgrupper utföra åtgärder som att använda webhooks som gör att aviseringar startar externa åtgärder eller integrerar med dina ITSM-verktyg.

Azure Monitor 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 Portal. Du kan också dela instrumentpanelen med andra Azure-användare. Element i 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 företagsanalys som tillhandahåller interaktiva visualiseringar över en mängd olika datakällor och är ett effektivt sätt att göra data tillgängliga för andra inom och utanför organisationen. Du kan konfigurera Power BI att automatiskt importera loggdata från Azure Monitor att dra nytta av dessa ytterligare 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 multifacetterad tjänst som tillåter följande funktioner och mycket mer:

• Ö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 den plats där dina faktiska program och tjänster finns. Det är där dina programutvecklingsteam ägnar det mesta av sin tid.

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

Interna program: Verksamhetskritiska program är viktiga för företagsdriften. Dessa program har några gemensamma egenskaper:

• Interaktiva: 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 (Internetuppriktade 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 Web Apps 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 dirigerbara adresser från det privata virtuella nätverket.

Stordataanalys: När data behöver skalas upp till större volymer kanske relationsdatabaser inte presterar bra under den extrema belastningen eller ostrukturerade 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 som Hadoop, Apache Spark, Apache Hive, LLAP, Apache Kafka, Apache Storm och R. HDInsight stöder distribution till ett platsbaserat virtuellt nätverk och 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ändelseinmatningstjänst. Den kan ta emot och behandla miljoner händelser per sekund. Det ger korta svarstider och konfigurerbar tidsbevarande, så att du kan mata in stora mängder data i Azure och läsa dem från flera program. En enda dataström har stöd för både realtids- och batchbaserade pipelines.

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

De här exemplen skrapar på ytan av de typer av arbetsbelastningar som du kan skapa i Azure – allt från en grundläggande webb- och SQL-app till den senaste i IoT, stordata, maskininlärning, AI och 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:er, tillgänglighetszoner, tillgänglighetsuppsättningar, skalningsuppsättningar och andra funktioner som hjälper dig att inkludera solida SLA-nivåer i dina produktionstjänster.

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

Utöver SLA-problem kan flera vanliga scenarier dra nytta av att köra flera virtuella datacenter:

• Regional eller global närvaro för dina slutanvändare eller partner.
• Krav på 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 tänka på två relaterade faktorer: geografiska avstånd och svarstid. För att optimera användarupplevelsen utvärderar du avståndet mellan varje virtuellt datacenter samt 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 regelkrav för alla juridiska jurisdiktioner som din organisation verkar under.

Haveriberedskap

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

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

• Kommunikation mellan hubbar som är inbyggd i Azure Virtual WAN mellan regioner i samma Virtual WAN.
• Peering för virtuella nätverk för att ansluta hubbar mellan regioner.
• Privat ExpressRoute-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 flera VDC-implementeringar som är anslutna till ExpressRoute-kretsarna.
• PLATS-till-plats-VPN-anslutningar mellan navzonen för dina VDC-implementeringar i varje Azure-region.

Vanligtvis är Virtual WAN-hubbar, peering för virtuella nätverk eller ExpressRoute-anslutningar att föredra för nätverksanslutning, på grund av högre bandbredd och konsekventa svarstidsnivåer när de passerar genom Microsofts stamnät.

Kör nätverkskvalificeringstester för att verifiera svarstiden och bandbredden för dessa anslutningar och avgör om synkron eller asynkron datareplikering är lämplig baserat på resultatet. Det är också viktigt att väga dessa resultat mot bakgrund av 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 regelbundet tjänsthälsan för lyssnande slutpunkter i olika VDC-implementeringar och, om dessa slutpunkter misslyckas, dirigeras automatiskt till nästa närmaste VDC. Traffic Manager använder användarmått i realtid och DNS för att dirigera användare till närmaste (eller närmast under fel). Azure Front Door är en omvänd proxy på över 100 Microsoft-stamnätsnätverksplatser som använder anycast för att dirigera användare till den närmaste lyssnande slutpunkten.

Sammanfattning

Ett virtuellt datacenter för datacentermigrering skapar en skalbar arkitektur som optimerar användningen av Azure-resurser, sänker kostnaderna och förenklar systemstyrningen. Det virtuella datacentret baseras vanligtvis på nätverks topologier med nav och ekrar (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 även strukturen för företagsroller, där olika avdelningar som central IT, DevOps och drift och underhåll fungerar tillsammans samtidigt som de utför sina specifika roller. Det virtuella datacentret stöder migrering av befintliga lokala arbetsbelastningar till Azure, men ger även många fördelar med molnbaserade distributioner.

Referenser

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

Nästa steg

• Läs mer om peering för virtuella nätverk, kärntekniken för nav- och eker-topologier.
• Implementera Azure Active Directory att använda rollbaserad åtkomstkontroll i Azure.
• Utveckla en prenumerations- och resurshanteringsmodell med hjälp av 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 första modeller för att säkerställa att du kan skala för att uppfylla framtida behov och tillväxt.