Planning van netwerkintegratie voor Azure Stack Hub

Dit artikel bevat informatie over de netwerkinfrastructuur van Azure Stack Hub om u te helpen bepalen hoe u Azure Stack Hub het beste kunt integreren in uw bestaande netwerkomgeving.

Notitie

Als u externe DNS-namen van Azure Stack Hub wilt omzetten (bijvoorbeeld www.bing.com), moet u DNS-servers opgeven om DNS-aanvragen door te sturen. Zie Azure Stack Hub Datacenter Integration - DNS voor meer informatie over DNS-vereisten voor Azure Stack Hub.

Ontwerp van fysiek netwerk

De Azure Stack Hub-oplossing vereist een flexibele en maximaal beschikbare fysieke infrastructuur ter ondersteuning van de werking en services. Voor het integreren van Azure Stack Hub met het netwerk zijn uplinks vereist van de Top-of-Rack-switches (ToR) naar de dichtstbijzijnde switch of router, die in deze documentatie Border wordt genoemd. De tors kunnen worden ge-uplinkt naar één of twee randen. De ToR is vooraf geconfigureerd door ons automatiseringsprogramma. Bij het gebruik van statische routering wordt een minimum van één verbinding tussen ToR en Border verwacht en een minimum van twee verbindingen (één per ToR) tussen ToR en Border, met een maximum van vier verbindingen op beide routeringsopties. Deze verbindingen zijn beperkt tot SFP+- of SFP28-media en een snelheid van minimaal één GB. Neem contact op met de hardwareleverancier van uw OEM (Original Equipment Manufacturer) voor beschikbaarheid. In het volgende diagram ziet u het aanbevolen ontwerp:

Bandbreedtetoewijzing

Azure Stack Hub is gebouwd met behulp van Windows Server 2019-failovercluster- en Spaces Direct-technologieën. Een deel van de fysieke netwerkconfiguratie van Azure Stack Hub wordt uitgevoerd om gebruik te maken van verkeersscheiding en bandbreedtegaranties om ervoor te zorgen dat de Spaces Direct-opslagcommunicatie kan voldoen aan de prestaties en schaal die van de oplossing worden vereist. De netwerkconfiguratie maakt gebruik van verkeersklassen om de op Spaces Direct gebaseerde communicatie op basis van RDMA te scheiden van die van het netwerkgebruik door de Azure Stack Hub-infrastructuur en/of tenant. Om af te stemmen op de huidige aanbevolen procedures die zijn gedefinieerd voor Windows Server 2019, wordt Azure Stack Hub gewijzigd om een extra verkeersklasse of prioriteit te gebruiken voor het verder scheiden van server-naar-servercommunicatie ter ondersteuning van de communicatie van failoverclustering. Deze nieuwe definitie van de verkeersklasse wordt geconfigureerd om 2% van de beschikbare, fysieke bandbreedte te reserveren. Deze configuratie van de verkeersklasse en bandbreedtereservering wordt gerealiseerd door een wijziging op de ToR-switches (Top-of-Rack) van de Azure Stack Hub-oplossing en op de host of servers van Azure Stack Hub. Houd er rekening mee dat wijzigingen niet vereist zijn op de apparaten van het grensnetwerk van de klant. Deze wijzigingen bieden betere tolerantie voor communicatie met failoverclusters en zijn bedoeld om situaties te voorkomen waarin de netwerkbandbreedte volledig wordt verbruikt en als gevolg hiervan failoverclusterbeheerberichten worden onderbroken. Houd er rekening mee dat de communicatie met failoverclusters een essentieel onderdeel is van de Azure Stack Hub-infrastructuur en als deze gedurende lange perioden wordt onderbroken, kan leiden tot instabiliteit in de Opslagruimten Direct-opslagservices of andere services die uiteindelijk van invloed zijn op de stabiliteit van tenants of eindgebruikers.

Notitie

De beschreven wijzigingen worden toegevoegd op het hostniveau van een Azure Stack Hub-systeem in de release van 2008. Neem contact op met uw OEM om de vereiste wijzigingen aan te brengen op de ToR-netwerkswitches. Deze ToR-wijziging kan worden uitgevoerd vóór het bijwerken naar de 2008-release of na het bijwerken naar 2008. De configuratiewijziging in de ToR-switches is vereist om de communicatie van het failovercluster te verbeteren.

Logische netwerken

Logische netwerken vertegenwoordigen een abstractie van de onderliggende fysieke netwerkinfrastructuur. Ze worden gebruikt voor het organiseren en vereenvoudigen van netwerktoewijzingen voor hosts, virtuele machines (VM's) en services. Als onderdeel van het maken van een logisch netwerk worden netwerksites gemaakt om de VLAN's (Virtual Local Area Networks), IP-subnetten en IP-subnet-/VLAN-paren te definiëren die zijn gekoppeld aan het logische netwerk op elke fysieke locatie.

In de volgende tabel ziet u de logische netwerken en de bijbehorende IPv4-subnetbereiken waarvoor u moet plannen:

Logisch netwerk	Description	Grootte
Openbaar VIP	Azure Stack Hub gebruikt in totaal 31 adressen van dit netwerk en de rest wordt gebruikt door tenant-VM's. Van de 31 adressen worden 8 openbare IP-adressen gebruikt voor een kleine set Azure Stack Hub-services. Als u van plan bent om App Service en de SQL-resourceproviders te gebruiken, worden er nog 7 adressen gebruikt. De resterende 16 IP-adressen zijn gereserveerd voor toekomstige Azure-services.	/26 (62 hosts) - /22 (1022 hosts) Aanbevolen = /24 (254 hosts)
Schakelen tussen infrastructuur	Punt-naar-punt-IP-adressen voor routeringsdoeleinden, toegewezen switchbeheerinterfaces en loopback-adressen die aan de switch zijn toegewezen.	/26
Infrastructuur	Wordt gebruikt om interne onderdelen van Azure Stack Hub te laten communiceren.	/24
Privé	Wordt gebruikt voor het opslagnetwerk, privé VIP's, infrastructuurcontainers en andere interne functies. Raadpleeg de sectie Privénetwerk in dit artikel voor meer informatie.	/20
BMC	Wordt gebruikt om te communiceren met de BMC's op de fysieke hosts.	/26

Notitie

Een waarschuwing in de portal herinnert de operator eraan om de PEP-cmdlet Set-AzsPrivateNetwork uit te voeren om een nieuwe privé-IP-ruimte /20 toe te voegen. Zie de sectie Privénetwerk in dit artikel voor meer informatie en richtlijnen voor het selecteren van de privé-IP-ruimte /20.

Netwerkinfrastructuur

De netwerkinfrastructuur voor Azure Stack Hub bestaat uit verschillende logische netwerken die zijn geconfigureerd op de switches. In het volgende diagram ziet u deze logische netwerken en hoe ze kunnen worden geïntegreerd met de TOR-switches (top-of-rack), baseboard management controller (BMC) en randswitches (klantnetwerk).

BMC-netwerk

Dit netwerk is bedoeld voor het verbinden van alle baseboard-beheercontrollers (ook wel BMC of serviceprocessors genoemd) met het beheernetwerk. Voorbeelden zijn: iDRAC, iLO, iBMC, enzovoort. Er wordt slechts één BMC-account gebruikt om te communiceren met een BMC-knooppunt. Indien aanwezig, bevindt de HLH (Hardware Lifecycle Host) zich op dit netwerk en kan deze OEM-specifieke software bieden voor hardwareonderhoud of -bewaking.

De HLH fungeert ook als host voor de implementatie-VM (DVM). De DVM wordt gebruikt tijdens de implementatie van Azure Stack Hub en wordt verwijderd wanneer de implementatie is voltooid. De DVM vereist internettoegang in verbonden implementatiescenario's om meerdere onderdelen te testen, te valideren en te openen. Deze onderdelen kunnen zich binnen en buiten uw bedrijfsnetwerk bevinden (bijvoorbeeld: NTP, DNS en Azure). Zie de sectie NAT in Azure Stack Hub-firewallintegratie voor meer informatie over connectiviteitsvereisten.

Particulier netwerk

Dit /20 -netwerk (4096 IP's) is privé voor de Azure Stack Hub-regio (wordt niet gerouteerd buiten de grensswitchapparaten van het Azure Stack Hub-systeem) en is onderverdeeld in meerdere subnetten. Hier volgen enkele voorbeelden:

• Opslagnetwerk: een /25 -netwerk (128 IP's) dat wordt gebruikt ter ondersteuning van het gebruik van Opslagverkeer van Spaces Direct en Server Message Block (SMB) en livemigratie van VM's.
• Intern virtueel IP-netwerk: een /25-netwerk dat is toegewezen aan interne VIP's voor de software-load balancer.
• Containernetwerk: een /23 -netwerk (512 IP's) dat is toegewezen aan intern verkeer tussen containers met infrastructuurservices.

Het Azure Stack Hub-systeem vereist een extra /20 persoonlijke interne IP-ruimte. Dit netwerk is privé voor het Azure Stack Hub-systeem (wordt niet gerouteerd buiten de randswitchapparaten van het Azure Stack Hub-systeem) en kan opnieuw worden gebruikt op meerdere Azure Stack Hub-systemen in uw datacenter. Hoewel het netwerk privé is voor Azure Stack, mag het niet overlappen met andere netwerken in het datacenter. De /20 privé-IP-ruimte is onderverdeeld in meerdere netwerken die het uitvoeren van de Azure Stack Hub-infrastructuur op containers mogelijk maken. Bovendien maakt deze nieuwe privé-IP-ruimte het mogelijk om de vereiste routeerbare IP-ruimte vóór de implementatie te verminderen. Het doel van het uitvoeren van de Azure Stack Hub-infrastructuur in containers is het optimaliseren van het gebruik en het verbeteren van de prestaties. Daarnaast wordt de privé-IP-ruimte /20 ook gebruikt om doorlopende inspanningen mogelijk te maken die de vereiste routeerbare IP-ruimte vóór de implementatie verminderen. Voor hulp bij privé-IP-ruimte raden we u aan RFC 1918 te volgen.

Voor systemen die vóór 1910 zijn geïmplementeerd, is dit /20-subnet een extra netwerk dat moet worden ingevoerd in systemen na het bijwerken naar 1910. Het extra netwerk moet aan het systeem worden verstrekt via de PEP-cmdlet Set-AzsPrivateNetwork .

Notitie

De invoer /20 fungeert als een vereiste voor de volgende Azure Stack Hub-update na 1910. Wanneer de volgende Azure Stack Hub-update na 1910 wordt uitgebracht en u deze probeert te installeren, mislukt de update als u de invoer /20 niet hebt voltooid, zoals beschreven in de herstelstappen als volgt. Er is een waarschuwing aanwezig in de beheerdersportal totdat de bovenstaande herstelstappen zijn voltooid. Zie het artikel Datacentrumnetwerkintegratie voor meer informatie over hoe deze nieuwe privéruimte wordt gebruikt.

Herstelstappen: volg de instructies om een PEP-sessie te openen om dit te herstellen. Bereid een privé intern IP-bereik van grootte /20 voor en voer de volgende cmdlet uit in de PEP-sessie met behulp van het volgende voorbeeld: Set-AzsPrivateNetwork -UserSubnet 10.87.0.0/20. Als de bewerking is uitgevoerd, ontvangt u het bericht Azs Intern netwerkbereik toegevoegd aan de configuratie. Als dit is voltooid, wordt de waarschuwing gesloten in de beheerdersportal. Het Azure Stack Hub-systeem kan nu worden bijgewerkt naar de volgende versie.

Azure Stack Hub-infrastructuurnetwerk

Dit /24-netwerk is toegewezen aan interne Azure Stack Hub-onderdelen, zodat ze onderling kunnen communiceren en gegevens kunnen uitwisselen. Dit subnet kan extern van de Azure Stack Hub-oplossing worden routeerbaar naar uw datacenter. Het wordt afgeraden om openbare of routeerbare IP-adressen op internet te gebruiken in dit subnet. Dit netwerk wordt geadverteerd naar de rand, maar de meeste IP-adressen worden beveiligd door Access Control Lists (ACL's). De IP-adressen die zijn toegestaan voor toegang, bevinden zich binnen een klein bereik dat vergelijkbaar is met een /27-netwerk en hostservices zoals het bevoegde eindpunt (PEP) en Azure Stack Hub Backup.

Openbaar VIP-netwerk

Het openbare VIP-netwerk wordt toegewezen aan de netwerkcontroller in Azure Stack. Het is geen logisch netwerk op de switch. De SLB gebruikt de pool met adressen en wijst /32-netwerken toe voor tenantworkloads. In de switchrouteringstabel worden deze /32 IP-adressen geadverteerd als een beschikbare route via BGP. Dit netwerk bevat de extern toegankelijke of openbare IP-adressen. De Azure Stack Hub-infrastructuur reserveert de eerste 31 adressen van dit openbare VIP-netwerk, terwijl de rest wordt gebruikt door tenant-VM's. De netwerkgrootte op dit subnet kan variëren van minimaal /26 (64 hosts) tot een maximum van /22 (1022 hosts). We raden u aan een /24-netwerk te plannen.

Verbinding maken met on-premises netwerken

Azure Stack Hub maakt gebruik van virtuele netwerken voor klantresources, zoals virtuele machines, load balancers en andere.

Er zijn verschillende opties om vanuit resources in het virtuele netwerk verbinding te maken met on-premises/bedrijfsresources:

• Gebruik openbare IP-adressen van het openbare VIP-netwerk.
• Gebruik Virtual Network-gateway of virtueel netwerkapparaat (NVA).

Wanneer een S2S VPN-tunnel wordt gebruikt om resources te verbinden met of van on-premises netwerken, kan er een scenario optreden waarin aan een resource ook een openbaar IP-adres is toegewezen en het niet meer bereikbaar is via dat openbare IP-adres. Als de bronpogingen om toegang te krijgen tot het openbare IP-adres binnen hetzelfde subnetbereik vallen dat is gedefinieerd in de lokale netwerkgatewayroutes (Virtual Network Gateway) of door de gebruiker gedefinieerde route voor NVA-oplossingen, probeert Azure Stack Hub het uitgaande verkeer terug te sturen naar de bron via de S2S-tunnel, op basis van de routeringsregels die zijn geconfigureerd. Het retourverkeer maakt gebruik van het privé-IP-adres van de VM, in plaats van bron-NATed als het openbare IP-adres:

Er zijn twee oplossingen voor dit probleem:

• Het verkeer omleiden naar het openbare VIP-netwerk naar internet.
• Voeg een NAT-apparaat toe aan NAT alle subnet-IP's die zijn gedefinieerd in de lokale netwerkgateway die zijn omgeleid naar het openbare VIP-netwerk.

Schakelen tussen infrastructuurnetwerk

Dit /26-netwerk is het subnet dat de routeerbare punt-naar-punt-IP/30 (twee host-IP's) subnetten en de loopbacks bevat, die toegewezen /32-subnetten zijn voor in-band switchbeheer en BGP-router-id. Dit bereik van IP-adressen moet buiten de Azure Stack Hub-oplossing routeerbaar zijn naar uw datacenter. Dit kunnen privé- of openbare IP-adressen zijn.

Schakelen tussen beheernetwerk

Dit /29 (zes host-IP's) netwerk is gewijd aan het verbinden van de beheerpoorten van de switches. Het biedt out-of-band toegang voor implementatie, beheer en probleemoplossing. Deze wordt berekend op basis van het hierboven genoemde netwerk van de switchinfrastructuur.

Toegestane netwerken

Het implementatiewerkblad bevat een veld waarmee de operator bepaalde toegangsbeheerlijsten (ACL's) kan wijzigen om toegang te verlenen tot netwerkinterfaces voor apparaatbeheer en de HLH (Hardware Lifecycle Host) vanuit een netwerkbereik van een vertrouwd datacenter. Met de wijziging in de toegangsbeheerlijst kan de operator hun beheer-jumpbox-VM's binnen een specifiek netwerkbereik toegang geven tot de switchbeheerinterface en het HLH-besturingssysteem. De operator kan een of meer subnetten aan deze lijst leveren. Als deze leeg wordt gelaten, wordt de toegang standaard geweigerd. Deze nieuwe functionaliteit vervangt de noodzaak van handmatige interventie na de implementatie, zoals voorheen werd beschreven in de configuratie Specifieke instellingen wijzigen in uw Azure Stack Hub-switch.

Volgende stappen

• Routering van verkeer in virtuele netwerken
• Meer informatie over netwerkplanning: Grensconnectiviteit.