Nätverkstopologi med hubb och ekrar

Hubb och eker är en nätverksmodell för effektiv hantering av vanliga kommunikations- eller säkerhetskrav. Det bidrar också till att undvika begränsningar i Azure-prenumerationen. Den här modellen riktar sig mot följande överväganden:

• Spara på kostnader och effektiv hantering: Centralisera tjänster som kan delas av flera arbetsbelastningar, till exempel virtuella nätverksinstallationer (NVA) och DNS-servrar. Med en enda plats för tjänster kan IT minimera redundanta resurser och hanteringsarbete.

• Övervinna prenumerationsgränser: Stora molnbaserade arbetsbelastningar kan kräva att du använder fler resurser än en enda Azure-prenumeration innehåller. Med peer-anslutning av arbetsbelastningar i virtuella nätverk från olika prenumerationer till en central hubb löser du dessa problem. Mer information finns i Begränsningar för Azure-prenumerationer.

• Skapa en uppdelning av problem: Du kan distribuera enskilda arbetsbelastningar mellan centrala IT-team och arbetsbelastningsteam.

Mindre molnegendomar har kanske inte nytta av den ökade strukturen och kapaciteten i den här modellen. Men större molnimplementeringar bör överväga att implementera ett hubb- och ekernätverk om de påverkas av några av ovanstående överväganden.

Kommentar

Webbplatsen för Azure-referensarkitekturer innehåller exempelmallar som du kan använda som grund för att implementera dina egna hub-and-spoke-nätverk:

• Implementera en nätverkstopologi av typen hubb/eker i Azure
• Implementera en nätverkstopologi av typen hubb/eker med delade tjänster i Azure

Översikt

Bild 1: Ett exempel på en nätverkstopologi för nav och eker.

Som du ser i diagrammet stöder Azure två typer av hubb- och eker-designer. Den första typen stöder kommunikation, delade resurser och centraliserad säkerhetsprincip. Den här typen är märkt som VNet-hubb i diagrammet. Den andra typen baseras på Azure Virtual WAN, som är märkt som Virtual WAN i diagrammet. Den här typen gäller för storskaliga kommunikationer från gren till gren och förgrening till Azure.

En hubb är en central nätverkszon som styr och kontrollerar inkommande eller utgående trafik mellan zoner: Internet, lokalt och ekrar. Hubb- och ekertopologin ger IT-avdelningen ett effektivt sätt att verkställa säkerhetsprinciper centralt. Det minskar också risken för felaktig konfiguration och exponering.

Hubben innehåller ofta de gemensamma tjänstkomponenter som ekrarna använder. Exempel på vanliga centrala tjänster är:

• En DNS-tjänst löser namngivning av arbetsbelastningen i ekrarna för att få åtkomst till resurser lokalt och på Internet om Azure DNS inte används.
• En offentlig nyckelinfrastruktur implementerar enkel inloggning för arbetsbelastningar.
• TCP- och UDP-trafikflödet styrs mellan ekernätverkszonerna och Internet.
• Flödet styrs mellan ekrarna och lokalt.
• Flödet styrs mellan en eker och en annan om det behövs.

Du kan minimera redundans, förenkla hanteringen och minska den totala kostnaden genom att använda den delade hubbinfrastrukturen för att stödja 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, mellanlagring och produktion.

Ekrarna kan också särskilja och aktivera olika grupper i din organisation. Ett exempel är Azure 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.

Application Gateway som visas i diagrammet ovan kan leva i eker med det program som den betjänar för bättre hantering och skalning. Företagspolicyn kan dock kräva att du placerar Application Gateway i hubben för centraliserad hantering och uppdelning av plikter.

Prenumerationsbegränsningar och flera hubbar

I Azure distribueras alla typer av komponenter 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 hub-and-spoke-implementering kan skala upp till ett stort antal ekrar, men precis som med alla IT-system finns det plattformsgränser. Hubb-distributionen är kopplad till en enskild Azure-prenumeration som har begränsningar. Ett exempel är ett maximalt antal peerings för virtuella nätverk. Mer information finns i Azure-prenumerations - och tjänstbegränsningar.

När gränser kan vara ett problem kan du skala upp arkitekturen genom att utöka modellen till ett kluster med hubbar och ekrar. Du kan ansluta flera hubbar i en eller flera Azure-regioner med hjälp av:

• Virtuell nätverkspeering
• Azure ExpressRoute
• Azure Virtual WAN
• Plats-till-plats-VPN

Bild 2: Ett kluster med hubbar och ekrar.

Introduktionen av flera hubbar ökar systemets kostnader och hantering. Den här ökningen motiveras endast av:

• Skalbarhet
• Systembegränsningar
• Redundans och regional replikering för användarprestanda 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

Det är möjligt att implementera komplexa arbetsbelastningar i en enda eker. Du kan implementera konfigurationer med flera nivåer med hjälp av undernät (en för varje nivå) i samma virtuella nätverk och genom att använda nätverkssäkerhetsgrupper för att filtrera flödena.

En arkitekt kanske vill distribuera en arbetsbelastning på flera nivåer i flera virtuella nätverk. Med peering av virtuella nätverk kan ekrar ansluta till andra ekrar i samma hubb eller i olika hubbar.

Ett typiskt exempel på det här scenariot när programbearbetningsservrar finns i en eker eller virtuellt nätverk. Databasen distribueras i en annan eker- eller ett virtuellt nätverk. I det här fallet är det enkelt att koppla ekrarna med peering av virtuella nätverk och undvika att överföra genom hubben. Gö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 bara finns i hubben.

Bild 3: Ett exempel på ekrar som ansluter till varandra och en hubb.

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 navet för lägre ekrar eller nivå 1 i hierarkin. Ekrarna krävs för att vidarebefordra trafiken till den centrala hubben. Det här kravet är så att trafiken kan 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 hubb-och-ekerrelation.

Kommentar

Du kan använda Azure Virtual Network Manager (AVNM) för att skapa nya eller registrera befintliga topologier för virtuella hubbar och ekrar för central hantering av anslutnings- och säkerhetskontroller.

Med en anslutningskonfiguration kan du skapa ett nät eller en nätverkstopologi för nav och eker, inklusive direktanslutning mellan virtuella ekernätverk.

Med en säkerhetskonfiguration kan du definiera en samling regler som du kan tillämpa på en eller flera nätverksgrupper på global nivå.

Nästa steg

Nu när du har utforskat metodtipsen för nätverk kan du lära dig hur du använder identitets- och åtkomstkontroller.

Metodtips för identitetshantering och åtkomstkontroll