Redigera

Dela via

Nätverkstopologi av typen hub-spoke i Azure

Azure Bastion
Azure Firewall
Azure Network Watcher
Azure Virtual Network
Azure VPN Gateway

Den här referensarkitekturen implementerar ett nav-ekernätverksmönster med kundhanterade hubbinfrastrukturkomponenter. En Infrastrukturlösning för Microsoft-hanterad hubb finns i Nätverkstopologi med Hub-spoke med Azure Virtual WAN.

Hub-spoke är en av de nätverkstopologier som rekommenderas av Cloud Adoption Framework. Se Definiera en Azure-nätverkstopologi för att förstå varför den här topologin anses vara bästa praxis för många organisationer.

Arkitektur

Diagram som visar en topologi för ett virtuellt nav-ekernätverk i Azure med ekernätverk som är anslutna via hubben eller direkt.

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

Hub-spoke-begrepp

Hub-spoke-nätverkstopologier innehåller vanligtvis många av följande arkitekturbegrepp:

  • Hub virtual network – Hubbens virtuella nätverk är värd för delade Azure-tjänster. Arbetsbelastningar som finns i de virtuella ekernätverken kan använda dessa tjänster. Det virtuella hubbnätverket är den centrala anslutningspunkten för lokala nätverk. Hubben innehåller din primära utgående punkt och tillhandahåller en mekanism för att ansluta en eker till en annan i situationer där trafik mellan virtuella nätverk behövs.

    En hubb är en regional resurs. Organisationer som har sina arbetsbelastningar i flera regioner bör ha flera hubbar, en per region.

    Hubben möjliggör följande begrepp:

    • korslokal gateway – Anslutning mellan platser är möjligheten att ansluta och integrera olika nätverksmiljöer till varandra. Den här gatewayen är vanligtvis en VPN- eller ExpressRoute-krets.

    • Utgående kontroll – Hantering och reglering av utgående trafik som kommer från de peerkopplade virtuella ekernätverken.

    • (valfritt) ingresskontroll – Hantering och reglering av inkommande trafik till slutpunkter som finns i peer-kopplade virtuella ekernätverk.

    • Fjärråtkomst – Fjärråtkomst är hur enskilda arbetsbelastningar i ekernätverk nås från en annan nätverksplats än ekerns eget nätverk. Detta kan vara för arbetsbelastningens data eller kontrollplan.

    • Fjärr ekeråtkomst för virtuella datorer – Hubben kan vara en bekväm plats för att skapa en fjärranslutningslösning mellan organisationer för RDP- och SSH-åtkomst till virtuella datorer som distribueras i ekernätverk.

    • Routning – Hanterar och dirigerar trafik mellan hubben och de anslutna ekrarna för att möjliggöra säker och effektiv kommunikation.

  • Virtuella ekernätverk – Virtuella ekernätverk isolerar och hanterar arbetsbelastningar separat i varje eker. Varje arbetsbelastning kan innehålla flera nivåer, med flera undernät anslutna via Azure-lastbalanserare. Ekrar kan finnas i olika prenumerationer och representera olika miljöer, till exempel produktion och icke-produktion. En arbetsbelastning kan till och med spridas över flera ekrar.

    I de flesta scenarier bör en eker endast peer-kopplas till ett enda hubbnätverk och hubbnätverket ska finnas i samma region som ekern.

    Dessa ekernätverk följer reglerna för standardutgående åtkomst. Ett centralt syfte med den här nätverkstopologin hub-spoke är att i allmänhet dirigera utgående Internettrafik via de kontrollmekanismer som erbjuds av hubben.

  • Virtuellt nätverk mellan anslutningar – Virtuell nätverksanslutning är den sökväg där ett isolerat virtuellt nätverk kan kommunicera med ett annat via en kontrollmekanism. Kontrollmekanismen tillämpar behörigheter och tillåten kommunikationsriktning mellan nätverk. En hubb ger ett alternativ för att stödja val av anslutningar mellan nätverk som ska flöda genom det centraliserade nätverket.

  • DNS- – Hub-spoke-lösningar ansvarar ofta för att tillhandahålla en DNS-lösning som ska användas av alla peer-kopplade ekrar, särskilt för routning mellan platser och för PRIVATA SLUTpunkts-DNS-poster.

Komponenter

  • Azure Virtual Network är den grundläggande byggstenen för privata nätverk i Azure. Med virtuellt nätverk kan många Azure-resurser, till exempel virtuella Azure-datorer, kommunicera säkert med varandra, lokala nätverk och Internet.

    Den här arkitekturen ansluter virtuella nätverk till hubben med hjälp av peering-anslutningar som inte är transitiva anslutningar med låg latens mellan virtuella nätverk. Peerkopplade virtuella nätverk kan utbyta trafik via Azure-stamnätet utan att behöva en router. I en hub-spoke-arkitektur är direkt peering av virtuella nätverk till varandra minimalt och reserverat för specialfallsscenarier.

  • Azure Bastion är en fullständigt hanterad tjänst som ger säkrare och smidigare fjärrskrivbordsprotokoll (RDP) och SSH-åtkomst (Secure Shell Protocol) till virtuella datorer utan att exponera sina offentliga IP-adresser. I den här arkitekturen används Azure Bastion som ett hanterat erbjudande för direkt åtkomst till virtuella datorer mellan anslutna ekrar.

  • Azure Firewall är en hanterad molnbaserad nätverkssäkerhetstjänst som skyddar virtuella nätverksresurser. Den här tillståndskänsliga brandväggstjänsten har inbyggd hög tillgänglighet och obegränsad skalbarhet i molnet som hjälper dig att skapa, framtvinga och logga program- och nätverksanslutningsprinciper i prenumerationer och virtuella nätverk.

    I den här arkitekturen har Azure Firewall flera potentiella roller. Brandväggen är den primära utgående punkten för Internetansluten trafik från de peerkopplade virtuella ekernätverken. Brandväggen kan också användas för att inspektera inkommande trafik med hjälp av IDPS-regler. Och slutligen kan brandväggen också användas som en DNS-proxyserver för att stödja FQDN-trafikregler.

  • VPN Gateway är en specifik typ av virtuell nätverksgateway som skickar krypterad trafik mellan ett virtuellt nätverk i Azure och ett annat nätverk via det offentliga Internet. Du kan också använda VPN Gateway för att skicka krypterad trafik mellan andra virtuella hubbar via Microsoft-nätverket.

    I den här arkitekturen skulle detta vara ett alternativ för att ansluta vissa eller alla ekrar till fjärrnätverket. Ekrar distribuerar vanligtvis inte sin egen VPN Gateway och använder i stället den centraliserade lösning som erbjuds av hubben. Du måste upprätta routningskonfiguration för att hantera den här anslutningen.

  • Azure ExpressRoute-gateway utbyter IP-vägar och dirigerar nätverkstrafik mellan ditt lokala nätverk och ditt virtuella Azure-nätverk. I den här arkitekturen skulle ExpressRoute vara det alternativa alternativet till en VPN Gateway för att ansluta vissa eller alla ekrar till ett fjärrnätverk. Ekrar skulle inte distribuera sin egen ExpressRoute, och i stället skulle dessa ekrar använda den centraliserade lösning som erbjuds av hubben. Precis som med en VPN Gateway måste du upprätta routningskonfiguration för att hantera den här anslutningen.

  • Azure Monitor kan samla in, analysera och agera på telemetridata från miljöer mellan olika platser, inklusive Azure och lokalt. Azure Monitor hjälper dig att maximera prestanda och tillgänglighet för dina program och proaktivt identifiera problem på några sekunder. I den här arkitekturen är Azure Monitor logg- och måttmottagaren för hubbresurserna och för nätverksmått. Azure Monitor kan även användas som loggningsmottagare för resurser i ekernätverk, men det är ett beslut för de olika anslutna arbetsbelastningarna och krävs inte av den här arkitekturen.

Alternativ

Den här arkitekturen omfattar skapande, konfiguration och underhåll av flera Azure-resurspri primitiver, nämligen: virtualNetworkPeerings, routeTablesoch subnets. Azure Virtual Network Manager är en hanteringstjänst som hjälper dig att gruppera, konfigurera, distribuera och hantera virtuella nätverk i stor skala mellan Azure-prenumerationer, regioner och Microsoft Entra-kataloger. Med Virtual Network Manager kan du definiera nätverksgrupper för att identifiera och segmentera dina virtuella nätverk logiskt. Du kan använda anslutna grupper som gör att virtuella nätverk i en grupp kan kommunicera med varandra som om de vore manuellt anslutna. Det här lagret lägger till ett abstraktionslager över dessa primitiver för att fokusera på att beskriva nätverkstopologin jämfört med att arbeta med implementeringen av topologin.

Vi rekommenderar att du utvärderar användning av Virtual Network Manager som ett sätt att optimera dina tidsutgifter med nätverkshanteringsåtgärder. Utvärdera kostnaden för tjänsten mot ditt beräknade värde/besparingar för att avgöra om Virtual Network Manger är en nettofördel för nätverkets storlek och komplexitet.

Information om scenario

Den här referensarkitekturen implementerar ett nav-ekernätverksmönster där det virtuella hubbnätverket fungerar som en central anslutningspunkt till många virtuella ekernätverk. De virtuella ekernätverken ansluter till hubben och kan användas för att isolera arbetsbelastningar. Du kan också aktivera scenarier mellan platser med hjälp av hubben för att ansluta till lokala nätverk.

Den här arkitekturen beskriver ett nätverksmönster med kundhanterade hubbinfrastrukturkomponenter. En Infrastrukturlösning för Microsoft-hanterad hubb finns i Nätverkstopologi med Hub-spoke med Azure Virtual WAN.

Fördelarna med att använda en kundhanterad hubb- och ekerkonfiguration är:

  • Kostnadsbesparingar
  • Överskrida prenumerationsgränser
  • Arbetsbelastningsisolering
  • Flexibilitet
    • Mer kontroll över hur virtuella nätverksinstallationer (NVA) distribueras, till exempel antal nätverkskort, antal instanser eller beräkningsstorlek.
    • Användning av NVA:er som inte stöds av Virtual WAN

Mer information finns i nätverkstopologin Hub-and-spoke.

Potentiella användningsfall

Vanliga användningsområden för en hubb- och ekerarkitektur är arbetsbelastningar som:

  • Ha flera miljöer som kräver delade tjänster. En arbetsbelastning kan till exempel ha utvecklings-, testnings- och produktionsmiljöer. Delade tjänster kan omfatta DNS-ID:n, NTP (Network Time Protocol) eller Active Directory-domän Services (AD DS). Delade tjänster placeras i det virtuella hubbnätverket och varje miljö distribueras till en annan eker för att upprätthålla isolering.
  • Kräv inte anslutning till varandra, men kräver åtkomst till delade tjänster.
  • Kräv central kontroll över säkerheten, till exempel en perimeternätverksbrandvägg (även kallat DMZ) i hubben med separat arbetsbelastningshantering i varje eker.
  • Kräv central kontroll över anslutningen, till exempel selektiv anslutning eller isolering mellan ekrar i vissa miljöer eller arbetsbelastningar.

Rekommendationer

Följande rekommendationer gäller för de flesta scenarier. Följ dessa rekommendationer om du inte har specifika krav som åsidosätter dem.

Resursgrupper, prenumerationer och regioner

I den här exempellösningen används en enda Azure-resursgrupp. Du kan också implementera hubben och varje eker i olika resursgrupper och prenumerationer.

När du peerkopplar virtuella nätverk i olika prenumerationer kan du associera prenumerationerna med samma eller olika Microsoft Entra-klienter. Den här flexibiliteten möjliggör decentraliserad hantering av varje arbetsbelastning samtidigt som delade tjänster i hubben upprätthålls. Se Skapa en peering för virtuella nätverk – Resource Manager, olika prenumerationer och Microsoft Entra-klienter.

Azure-landningszoner

Arkitekturen Azure-landningszonen baseras på topologin hub-spoke. I den arkitekturen hanteras hubbens delade resurser och nätverk av ett centraliserat plattformsteam, medan ekrar delar en samägarmodell med plattformsteamet och arbetsbelastningsteamet som använder ekernätverket. Alla hubbar finns i en "anslutningsprenumeration" för centraliserad hantering, medan virtuella ekernätverk finns i många enskilda arbetsbelastningsprenumerationer, så kallade prenumerationer på programlandningszoner.

Undernät för virtuellt nätverk

Följande rekommendationer beskriver hur du konfigurerar undernäten i det virtuella nätverket.

GatewaySubnet

Den virtuella nätverksgatewayen kräver det här undernätet. Du kan också använda en hub-spoke-topologi utan en gateway om du inte behöver nätverksanslutning mellan platser.

Skapa ett undernät med namnet GatewaySubnet med ett adressintervall på minst 26. Adressintervallet /26 ger undernätet tillräckligt med konfigurationsalternativ för skalbarhet för att förhindra att gatewayens storleksbegränsningar nårs i framtiden och för att hantera ett högre antal ExpressRoute-kretsar. Mer information om hur du konfigurerar gatewayen finns i Hybridnätverk med hjälp av en VPN-gateway.

AzureFirewallSubnet

Skapa ett undernät med namnet AzureFirewallSubnet med ett adressintervall på minst /26. Oavsett skala är adressintervallet /26 den rekommenderade storleken och täcker eventuella framtida storleksbegränsningar. Det här undernätet stöder inte nätverkssäkerhetsgrupper (NSG:er).

Azure Firewall kräver det här undernätet. Om du använder en virtuell nätverksinstallation för partnernätverk (NVA) följer du dess nätverkskrav.

Ekernätverksanslutning

Peering av virtuella nätverk eller anslutna grupper är icke-transitiva relationer mellan virtuella nätverk. Om du behöver virtuella ekernätverk för att ansluta till varandra lägger du till en peering-anslutning mellan ekrarna eller placerar dem i samma nätverksgrupp.

Ekeranslutningar via Azure Firewall eller NVA

Antalet peerings för virtuella nätverk per virtuellt nätverk är begränsat. Om du har många ekrar som behöver ansluta till varandra kan det ta slut på peeringanslutningar. Anslutna grupper har också begränsningar. Mer information finns i Nätverksgränser och Gränser för anslutna grupper.

I det här scenariot bör du överväga att använda användardefinierade vägar (UDR) för att tvinga ekertrafik att skickas till Azure Firewall eller en annan NVA som fungerar som en router på hubben. Denna ändring gör att ekrarna kan ansluta till varandra. För att stödja den här konfigurationen måste du implementera Azure Firewall med en konfiguration med framtvingad tunneltrafik aktiverad. Mer information finns i Framtvingad tunneltrafik i Azure Firewall.

Topologin i denna arkitekturdesign underlättar utgående flöden. Azure Firewall är främst för utgående säkerhet, men den kan även vara en ingresspunkt. Mer information om NVA-ingressroutning för hubb finns i Brandvägg och Application Gateway för virtuella nätverk.

Ekeranslutningar till fjärrnätverk via en hubbgateway

Om du vill konfigurera ekrar för att kommunicera med fjärrnätverk via en hubbgateway kan du använda peering för virtuella nätverk eller anslutna nätverksgrupper.

Om du vill använda peering för virtuella nätverk i konfigurationen av peering för virtuella nätverk:

  • Konfigurera peering-anslutningen i hubben till Tillåt gatewayöverföring.
  • Konfigurera peering-anslutningen i varje eker till Använd det virtuella fjärrnätverkets gateway.
  • Konfigurera alla peering-anslutningar till Tillåt vidarebefordrad trafik.

Mer information finns i Skapa en peering för virtuella nätverk.

Så här använder du anslutna nätverksgrupper:

  1. I Virtual Network Manager skapar du en nätverksgrupp och lägger till virtuella medlemsnätverk.
  2. Skapa en anslutningskonfiguration för hubbar och ekrar.
  3. För Ekernätverksgrupper väljer du Hub som gateway.

Mer information finns i Skapa en hubb- och ekertopologi med Azure Virtual Network Manager.

Ekernätverkskommunikation

Det finns två huvudsakliga sätt att tillåta att virtuella ekernätverk kommunicerar med varandra:

  • Kommunikation via en NVA som en brandvägg och router. Den här metoden medför ett hopp mellan de två ekrarna.
  • Kommunikation med hjälp av peering för virtuella nätverk eller direktanslutning mellan ekrar i Virtual Network Manager. Den här metoden orsakar inte ett hopp mellan de två ekrarna och rekommenderas för att minimera svarstiden.
  • Private Link kan användas för att selektivt exponera enskilda resurser för andra virtuella nätverk. Du kan till exempel exponera en intern lastbalanserare för ett annat virtuellt nätverk, utan att behöva skapa eller underhålla peering- eller routningsrelationer.

Mer information om nätverksmönster för eker till eker finns i spoke-to-spoke-nätverk.

Kommunikation via en NVA

Om du behöver anslutning mellan ekrar kan du överväga att distribuera Azure Firewall eller en annan NVA i hubben. Skapa sedan vägar för att vidarebefordra trafik från en eker till brandväggen eller NVA, som sedan kan dirigeras till den andra ekern. I det här scenariot måste du konfigurera peering-anslutningarna att tillåta vidarebefordrad trafik.

Diagram som visar routning mellan ekrar med hjälp av Azure Firewall

Du kan också använda en VPN-gateway för att dirigera trafik mellan ekrar, även om det här valet påverkar svarstid och dataflöde. Konfigurationsinformation finns i Konfigurera VPN Gateway-överföring för peering för virtuella nätverk.

Utvärdera de tjänster som du delar i hubben för att säkerställa att hubben skalar efter ett större antal ekrar. Om hubben till exempel tillhandahåller brandväggstjänster bör du överväga brandväggslösningens bandbreddsgränser när du lägger till flera ekrar. Du kan flytta några av dessa delade tjänster till en andra nivå av hubbar.

Direkt kommunikation mellan ekernätverk

Om du vill ansluta direkt mellan virtuella ekernätverk utan att passera det virtuella hubbnätverket kan du skapa peering-anslutningar mellan ekrar eller aktivera direktanslutning för nätverksgruppen. Det är bäst att begränsa peering eller direktanslutning till virtuella ekernätverk som ingår i samma miljö och arbetsbelastning.

När du använder Virtual Network Manager kan du lägga till virtuella ekernätverk i nätverksgrupper manuellt eller lägga till nätverk automatiskt baserat på villkor som du definierar.

Följande diagram visar hur du använder Virtual Network Manager för direkt anslutning mellan ekrar.

Diagram som visar hur du använder Virtual Network Manager för direkt anslutning mellan ekrar.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.

Använd tillgänglighetszoner för Azure-tjänster i hubben som stöder dem.

Som en allmän regel är det bäst att ha minst en hubb per region och endast ansluta ekrar till dessa hubbar från samma region. Den här konfigurationen hjälper bulkhead-regioner att undvika ett fel i en regions hubb som orsakar omfattande nätverksroutningsfel i orelaterade regioner.

För högre tillgänglighet kan du använda ExpressRoute plus ett VPN för redundans. Se Ansluta ett lokalt nätverk till Azure med Hjälp av ExpressRoute med VPN-redundans och följ anvisningarna för att utforma och skapa Azure ExpressRoute för återhämtning.

På grund av hur Azure Firewall implementerar FQDN-programregler kontrollerar du att alla resurser som går ut genom brandväggen använder samma DNS-provider som själva brandväggen. Utan detta kan Azure Firewall blockera legitim trafik eftersom brandväggens IP-upplösning för FQDN skiljer sig från trafikegenarens IP-upplösning för samma FQDN. Att införliva Azure Firewall-proxy som en del av en eker-DNS-matchning är en lösning för att säkerställa att FQDN är synkroniserade med både trafikegenaren och Azure Firewall.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i checklistan för Designgranskning för Security.

För att skydda mot DDoS-attacker aktiverar du Azure DDOS Protection- i alla virtuella perimeternätverk. Alla resurser som har en offentlig IP-adress är mottagliga för en DDoS-attack. Även om dina arbetsbelastningar inte exponeras offentligt har du fortfarande offentliga IP-adresser som måste skyddas, till exempel:

  • Offentliga IP-adresser i Azure Firewall
  • VPN-gatewayens offentliga IP-adresser
  • Offentlig IP-adress för ExpressRoute-kontrollplanet

För att minimera risken för obehörig åtkomst och framtvinga strikta säkerhetsprinciper anger du alltid explicita nekanderegler i nätverkssäkerhetsgrupper (NSG:er).

Använd Azure Firewall Premium-versionen för att aktivera TLS-inspektion, IDPS (Network Intrusion Detection and Prevention System) och URL-filtrering.

Säkerhet för Virtual Network Manager

Se till att du associerar säkerhetsadministratörsregler med virtuella nätverk i nätverksgrupper för att säkerställa en baslinjeuppsättning med säkerhetsregler. Säkerhetsadministratörsregler har företräde framför och utvärderas före NSG-regler. Precis som NSG-regler stöder säkerhetsadministratörsregler prioritering, tjänsttaggar och L3-L4-protokoll. Mer information finns i Säkerhetsadministratörsregler i Virtual Network Manager.

Använd Virtual Network Manager-distributioner för att underlätta kontrollerad distribution av potentiellt icke-bakåtkompatibla ändringar av säkerhetsregler för nätverksgrupper.

Kostnadsoptimering

Kostnadsoptimering handlar om sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i checklistan Designgranskning för kostnadsoptimering.

Tänk på följande kostnadsrelaterade faktorer när du distribuerar och hanterar hubb- och ekernätverk. Mer information finns i Priser för virtuella nätverk.

Kostnader för Azure Firewall

Den här arkitekturen distribuerar en Azure Firewall-instans i hubbnätverket. Om du använder en Azure Firewall-distribution som en delad lösning som används av flera arbetsbelastningar kan du avsevärt spara molnkostnader jämfört med andra NVA:er. Mer information finns i Azure Firewall jämfört med virtuella nätverksinstallationer.

Om du vill använda alla distribuerade resurser effektivt väljer du rätt Azure Firewall-storlek. Bestäm vilka funktioner du behöver och vilken nivå som passar bäst för din aktuella uppsättning arbetsbelastningar. Mer information om tillgängliga SKU:er för Azure Firewall finns i Vad är Azure Firewall?

Direkt peering

Selektiv användning av direkt peering eller annan icke-hubbbaserad kommunikation mellan ekrar kan undvika kostnaden för Bearbetning av Azure Firewall. Besparingar kan vara betydande för nätverk som har arbetsbelastningar med högt dataflöde, låg riskkommunikation mellan ekrar, till exempel databassynkronisering eller stora filkopieringsåtgärder.

Operational Excellence

Operational Excellence omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i checklistan för Designgranskning för Operational Excellence.

Aktivera diagnostikinställningar för alla tjänster, till exempel Azure Bastion, Azure Firewall och din lokala gateway. Ta reda på vilka inställningar som är meningsfulla för dina åtgärder. Inaktivera inställningar som inte är meningsfulla för att undvika onödiga kostnader. Resurser som Azure Firewall kan vara utförliga med loggning och du kan medföra höga övervakningskostnader.

Använd för övervakning från slutpunkt till slutpunkt för att identifiera avvikelser och för att identifiera och felsöka nätverksproblem.

Använd Azure Network Watcher- för att övervaka och felsöka nätverkskomponenter, inklusive att använda Traffic Analytics- för att visa systemen i dina virtuella nätverk som genererar mest trafik. Du kan identifiera flaskhalsar visuellt innan de blir problem.

Om du använder ExpressRoute använder du ExpressRoute Traffic Collector där du kan analysera flödesloggar för de nätverksflöden som skickas via dina ExpressRoute-kretsar. ExpressRoute Traffic Collector ger dig insyn i trafik som flödar över Microsoft Enterprise Edge-routrar.

Använd FQDN-baserade regler i Azure Firewall för andra protokoll än HTTP(er) eller när du konfigurerar SQL Server. Om du använder FQDN:er minskar hanteringsbelastningen jämfört med att hantera enskilda IP-adresser.

Planera för IP-adressering baserat på dina peeringkrav och se till att adressutrymmet inte överlappar varandra mellan platser och Azure-platser.

Automatisering med Azure Virtual Network Manager

Om du vill hantera anslutnings- och säkerhetskontroller centralt använder du Azure Virtual Network Manager- för att skapa nya topologier för virtuella nav- och ekernätverk eller registrera befintliga topologier. Med Virtual Network Manager ser du till att dina hubb- och ekernätverkstopologier förbereds för storskalig framtida tillväxt i flera prenumerationer, hanteringsgrupper och regioner.

Exempel på användningsfall för Virtual Network Manager är:

  • Demokratisering av hantering av virtuella ekernätverk till grupper som affärsenheter eller programteam. Demokratisering kan resultera i ett stort antal krav på anslutning mellan virtuella nätverk och nätverkssäkerhetsregler.
  • Standardisering av flera replikarkitekturer i flera Azure-regioner för att säkerställa ett globalt fotavtryck för program.

För att säkerställa enhetliga anslutnings- och nätverkssäkerhetsregler kan du använda nätverksgrupper för att gruppera virtuella nätverk i valfri prenumeration, hanteringsgrupp eller region under samma Microsoft Entra-klientorganisation. Du kan automatiskt eller manuellt registrera virtuella nätverk i nätverksgrupper via dynamiska eller statiska medlemskapstilldelningar.

Du definierar identifiering av de virtuella nätverk som Virtual Network Manager hanterar med hjälp av Omfång. Den här funktionen ger flexibilitet för ett önskat antal instanser av nätverkshanteraren, vilket möjliggör ytterligare hanteringsdemokratisering för virtuella nätverksgrupper.

Om du vill ansluta virtuella ekernätverk i samma nätverksgrupp till varandra använder du Virtual Network Manager för att implementera peering för virtuella nätverk eller direktanslutning. Använd det globala mesh-alternativet för att utöka mesh-direktanslutningen till ekernätverk i olika regioner. Följande diagram visar global mesh-anslutning mellan regioner.

Diagram som visar eker global mesh-direktanslutning över regioner.

Du kan associera virtuella nätverk i en nätverksgrupp med en baslinjeuppsättning med säkerhetsadministratörsregler. Säkerhetsadministratörsregler för nätverksgrupper hindrar virtuella nätverksägare från att skriva över säkerhetsregler för baslinjen, samtidigt som de kan lägga till sina egna uppsättningar säkerhetsregler och NSG:er separat. Ett exempel på hur du använder säkerhetsadministratörsregler i nav- och ekertopologier finns i Självstudie: Skapa ett skyddat nav- och ekernätverk.

För att underlätta en kontrollerad distribution av nätverksgrupper, anslutningar och säkerhetsregler hjälper virtual network manager-konfigurationsdistributioner dig att på ett säkert sätt släppa potentiellt icke-bakåtkompatibla konfigurationsändringar i hubb- och ekermiljöer. Mer information finns i Konfigurationsdistributioner i Azure Virtual Network Manager.

För att förenkla och effektivisera processen med att skapa och underhålla routningskonfigurationer kan du använda automatiserad hantering av användardefinierade vägar (UDR) i Azure Virtual Network Manager.

För att förenkla och centralisera hanteringen av IP-adresser kan du använda IP-adresshantering (IPAM) i Azure Virtual Network Manager. IPAM förhindrar ip-adressutrymmeskonflikter i lokala och molnbaserade virtuella nätverk.

Information om hur du kommer igång med Virtual Network Manager finns i Skapa en hubb- och ekertopologi med Azure Virtual Network Manager.

Prestandaeffektivitet

Prestandaeffektivitet är arbetsbelastningens förmåga att skala för att uppfylla användarnas krav på ett effektivt sätt. Mer information finns i översikt över grundpelare för prestandaeffektivitet.

För arbetsbelastningar som kommunicerar från lokala till virtuella datorer i ett virtuellt Azure-nätverk som kräver låg svarstid och hög bandbredd kan du överväga att använda ExpressRoute FastPath. Med FastPath kan du skicka trafik direkt till virtuella datorer i ditt virtuella nätverk från det lokala nätverket genom att kringgå den virtuella ExpressRoute-nätverksgatewayen, vilket ökar prestandan.

För eker-till-eker-kommunikation som kräver låg svarstid bör du överväga att konfigurera spoke-to-spoke-nätverk.

Välj lämplig gateway-SKU- som uppfyller dina krav, till exempel antal punkt-till-plats- eller plats-till-plats-anslutningar, nödvändiga paket per sekund, bandbreddskrav och TCP-flöden.

För svarstidskänsliga flöden, till exempel SAP eller åtkomst till lagring, bör du överväga att kringgå Azure Firewall eller till och med routning via hubben alls. Du kan testfördröjning som introduceras av Azure Firewall för att informera ditt beslut. Du kan använda funktioner som VNet-peering som ansluter två eller flera nätverk eller Azure Private Link- som gör att du kan ansluta till en tjänst via en privat slutpunkt i ditt virtuella nätverk.

Förstå att om du aktiverar vissa funktioner i Azure Firewall, till exempel intrångsidentifierings- och skyddssystem (IDPS), minskar ditt dataflöde. Mer information finns i Azure Firewall-prestanda.

Distribuera det här scenariot

Den här distributionen innehåller ett virtuellt hubbnätverk och två anslutna ekrar och distribuerar även en Azure Firewall-instans och En Azure Bastion-värd. Om du vill kan distributionen inkludera virtuella datorer i det första ekernätverket och en VPN-gateway. Du kan välja mellan virtuella nätverkspeeringsgrupper eller virtual network manager-anslutna grupper för att skapa nätverksanslutningarna. Varje metod har flera distributionsalternativ.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Avancerade scenarier

Din arkitektur kan skilja sig från den här enkla hub-spoke-arkitekturen. Följande är en lista med vägledning för vissa avancerade scenarier:

Utforska följande relaterade arkitekturer: