Hub-and-spoke-netwerktopologie
Hub en spoke is een netwerkmodel voor het efficiënt beheren van algemene communicatie- of beveiligingsvereisten. Het helpt ook om de beperkingen van het Azure-abonnement te voorkomen. In dit model worden de volgende problemen opgelost:
Besparen op kosten en efficiënt beheer: centraliseer services die kunnen worden gedeeld door meerdere workloads, zoals virtuele netwerkapparaten (NVA's) en DNS-servers. Met één locatie voor services kan IT redundante resources en beheerinspanningen minimaliseren.
Abonnementslimieten overschrijden: voor grote cloudworkloads is het mogelijk dat er meer resources nodig zijn dan één Azure-abonnement bevat. Het kan zijn dat deze limieten worden weggenomen door het peeren van de workload van virtuele netwerken verschillende abonnementen op een centrale hub. Zie Limieten voor Azure-abonnementen voor meer informatie.
Een scheiding van zorgen: u kunt afzonderlijke workloads implementeren tussen centrale IT-teams en workloadteams.
Het kan zijn dat kleinere clouds niet profiteren van de toegevoegde structuur en mogelijkheden die dit model biedt. Maar grotere implementaties in de cloud moeten overwegen een hub-and-spoke-netwerkarchitectuur te implementeren als ze een van de eerder genoemde problemen hebben.
Notitie
De azure-referentiearchitecturensite bevat voorbeeldsjablonen die u kunt gebruiken als basis voor het implementeren van uw eigen hub-and-spoke-netwerken:
Overzicht
Afbeelding 1: Een voorbeeld van een hub-and-spoke-netwerktopologie.
Zoals in het diagram wordt weergegeven, ondersteunt Azure twee typen hub-and-spoke-ontwerp. Het eerste type ondersteunt communicatie, gedeelde resources en gecentraliseerd beveiligingsbeleid. Dit type is gelabeld als VNet-hub in het diagram. Het tweede type is gebaseerd op Azure Virtual WAN, dat is gelabeld als Virtual WAN in het diagram. Dit type is bedoeld voor grootschalige communicatie tussen vertakkingen en vertakkingen naar Azure.
Een hub is een centrale netwerkzone waarmee inkomend of uitgaand verkeer tussen zones: internet, on-premises en spokes wordt beheerd en geïnspecteerd. De hub-and-spoke-topologie biedt uw IT-afdeling een efficiënte manier om beveiligingsbeleid op een centrale locatie af te dwingen. Dit vermindert ook de mogelijkheden voor onjuiste configuratie en blootstelling.
De hub bevat vaak de algemene serviceonderdelen die door de spokes worden gebruikt. Voorbeelden van algemene centrale services zijn:
- Een DNS-service zet de naamgeving van de workload in de spokes om toegang te krijgen tot resources on-premises en op internet als Azure DNS niet wordt gebruikt.
- Een openbare-sleutelinfrastructuur implementeert eenmalige aanmelding voor workloads.
- De TCP- en UDP-verkeersstroom wordt beheerd tussen de spoke-netwerkzones en internet.
- De stroom wordt beheerd tussen de spokes en on-premises.
- De stroom wordt, indien nodig, tussen de ene spaak en de andere beheerd.
U kunt de redundantie beperken, het beheer vereenvoudigen en de totale kosten verlagen door de infrastructuur van de gedeelde hub te gebruiken voor de ondersteuning van meerdere spokes.
De rol van elke spoke kan verschillende typen workloads hosten. De spokes bieden ook een modulaire benadering voor herhaalbare implementaties van dezelfde workloads. Voorbeelden hiervan zijn dev/test, gebruikersacceptatietests, fasering en productie.
Met de spokes kunnen ook verschillende groepen in uw organisatie worden gescheiden en ingeschakeld. Een voorbeeld zijn Azure DevOps-groepen. Binnen een spoke is het mogelijk om een eenvoudige workload of complexe workload met meerdere lagen te implementeren met verkeerscontrole tussen de lagen.
De Toepassingsgateway die in het bovenstaande diagram wordt weergegeven, kan live zijn in spoke met de toepassing die het biedt voor beter beheer en betere schaal. Het bedrijfsbeleid kan echter dicteren dat u Application Gateway in de hub plaatst voor gecentraliseerd beheer en scheiding van rechten.
Abonnementslimieten en meerdere hubs
In Azure wordt elk type onderdeel geïmplementeerd in een Azure-abonnement. De isolatie van Azure-onderdelen in verschillende Azure-abonnementen kan voldoen aan de vereisten van verschillende bedrijfsregels, zoals het instellen van gedifferentieerde niveaus voor toegang en autorisatie.
Eén hub-and-spoke-implementatie kan omhoog schalen naar een groot aantal spokes, maar net als bij elk IT-systeem zijn er platformlimieten. De implementatie van de hub is gebonden aan een specifiek Azure-abonnement dat beperkingen en limieten heeft. Een voorbeeld hiervan is een maximum aantal peerings voor virtuele netwerken. Zie Azure-abonnements- en servicelimieten voor meer informatie.
Wanneer limieten een probleem kunnen zijn, kunt u de architectuur omhoog schalen door het model uit te breiden naar een cluster met hubs en spokes. U kunt meerdere hubs in een of meer Azure-regio's verbinden met behulp van:
- Peering op virtueel netwerk
- Azure ExpressRoute
- Azure Virtual WAN
- Site-naar-site-VPN
Afbeelding 2: Een cluster met hubs en spokes.
Door de introductie van meerdere hubs worden de kosten- en beheersoverhead van het systeem verhoogd. Deze toename is alleen gerechtvaardigd door:
- Schaalbaarheid
- Systeemlimieten
- Redundantie en regionale replicatie voor gebruikersprestaties of herstel na noodgevallen
In scenario's waarvoor meerdere hubs zijn vereist, moeten alle hubs streven naar dezelfde set services voor operationeel gemak.
Interconnectie tussen spokes
Het is mogelijk om complexe workloads met meerdere lagen te implementeren in één spoke. U kunt configuraties met meerdere lagen implementeren met behulp van subnetten (één voor elke laag) in hetzelfde virtuele netwerk en door netwerkbeveiligingsgroepen te gebruiken om de stromen te filteren.
Een architect kan een workload met meerdere lagen implementeren in verschillende virtuele netwerken. Met peering voor het virtuele netwerk kunnen spokes verbinding maken met andere spokes in dezelfde hub of in verschillende hubs.
Een typisch voorbeeld van dit scenario is het geval waarin de verwerkingsservers van de toepassing zich in één spoke of virtueel netwerk bevinden. De database wordt geïmplementeerd in een andere spoke of virtueel netwerk. In dit geval is het eenvoudig om de spokes te verbinden met de peering van het virtuele netwerk en doorvoer via de hub te voorkomen. Voer een zorgvuldige architectuur en beveiligingsbeoordeling uit om ervoor te zorgen dat het omzeilen van de hub geen belangrijke beveiligings- of controlepunten overzeilt die alleen in de hub staan.
Afbeelding 3: Een voorbeeld van spokes die verbinding maken met elkaar en een hub.
Spokes kunnen ook worden gekoppeld aan een spoke die fungeert als een hub. Met deze benadering wordt een hiërarchie met twee niveaus gemaakt: de spoke op het hogere niveau, niveau 0, wordt de hub van lagere spokes of niveau 1 van de hiërarchie. De spokes zijn vereist om het verkeer door te sturen naar de centrale hub. Deze vereiste is zodanig dat het verkeer naar de bestemming in het on-premises netwerk of het openbare internet kan worden doorgegeven. Een architectuur met twee niveaus van hubs introduceert complexe routering waarmee de voordelen van een eenvoudige hub-and-spoke-relatie worden verwijderd.
Notitie
U kunt AVNM (Azure Virtual Network Manager) gebruiken om nieuwe hub- en spoke-topologieën voor virtuele netwerken te maken of onboarden voor centraal beheer van connectiviteits- en beveiligingscontroles.
Met een connectiviteitsconfiguratie kunt u een mesh- of een hub-and-spoke-netwerktopologie maken, inclusief directe connectiviteit tussen virtuele spoke-netwerken.
Met een beveiligingsconfiguratie kunt u een verzameling regels definiëren die u kunt toepassen op een of meer netwerkgroepen op globaal niveau.
Volgende stappen
Nu u de aanbevolen procedures voor netwerken hebt verkend, leert u hoe u identiteits- en toegangsbeheer kunt benaderen.