Netwerkintegratieplanning voor Azure Stack Hub

In dit artikel vindt u informatie over de netwerkinfrastructuur van Azure Stack Hub om te bepalen hoe u Azure Stack Hub het beste kunt integreren in uw bestaande netwerkomgeving.

Notitie

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

Fysiek netwerkontwerp

De Azure Stack Hub-oplossing vereist een robuuste en maximaal beschikbare fysieke infrastructuur ter ondersteuning van de werking en services. Voor het integreren van Azure Stack Hub met het netwerk zijn uplinks van de Top-of-Rack-switches (ToR) vereist naar de dichtstbijzijnde switch of router, die in deze documentatie wordt aangeduid als Border. De tors kunnen worden gekoppeld aan één of twee randen. De ToR is vooraf geconfigureerd door ons automatiseringsprogramma. Bij het gebruik van statische routering worden minimaal één verbinding tussen ToR en Border verwacht bij het gebruik van BGP-routering en minimaal twee verbindingen (één per ToR) tussen ToR en Border, met maximaal vier verbindingen op beide routeringsopties. Deze verbindingen zijn beperkt tot SFP+ of SFP28-media en minimaal één GB-snelheid. Neem contact op met de oem-hardwareleverancier (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 Communicatie tussen Opslagruimten Direct en de prestaties en schaal van de oplossing kan voldoen. De netwerkconfiguratie maakt gebruik van verkeersklassen om de op Spaces Direct gebaseerde, RDMA-communicatie 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, verandert Azure Stack Hub om een extra verkeersklasse of prioriteit te gebruiken om servercommunicatie verder te scheiden naar servercommunicatie ter ondersteuning van de communicatie van failoverclusteringbeheer. Deze nieuwe definitie van de verkeersklasse wordt geconfigureerd om 2% van de beschikbare fysieke bandbreedte te reserveren. Deze configuratie van verkeersklasse en bandbreedtereservering wordt bereikt door een wijziging in 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 randnetwerkapparaten van de klant. Deze wijzigingen bieden een betere tolerantie voor communicatie met failoverclusters en zijn bedoeld om situaties te voorkomen waarin de netwerkbandbreedte volledig wordt verbruikt en daardoor berichten over failoverclusterbeheer worden onderbroken. Houd er rekening mee dat de communicatie met failoverclusters een essentieel onderdeel van de Azure Stack Hub-infrastructuur is en als deze gedurende lange perioden wordt onderbroken, kan dit leiden tot instabiliteit in de Opslagruimten Direct-opslagservices of andere services die uiteindelijk van invloed zijn op de stabiliteit van tenant- of eindgebruikersworkloads.

Notitie

De beschreven wijzigingen worden toegevoegd op 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 bij de ToR-netwerkswitches. Deze ToR-wijziging kan worden uitgevoerd vóór het bijwerken naar de release van 2008 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 om netwerktoewijzingen voor hosts, virtuele machines (VM's) en services te organiseren en te vereenvoudigen. 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	Beschrijving	Grootte
Openbaar VIP	Azure Stack Hub gebruikt in totaal 31 adressen van dit netwerk en de rest wordt gebruikt door tenant-VM's. Vanaf de 31 adressen worden 8 openbare IP-adressen gebruikt voor een kleine set Azure Stack Hub-services. Als u van plan bent 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 zijn toegewezen aan de switch.	/26
Infrastructuur	Wordt gebruikt voor interne onderdelen van Azure Stack Hub om te 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 /20 Privé-IP-ruimte toe te voegen. Zie de sectie Privénetwerk in dit artikel voor meer informatie en richtlijnen over het selecteren van de /20 privé-IP-ruimte.

Netwerkinfrastructuur

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

BMC-netwerk

Dit netwerk is bedoeld voor het verbinden van alle basisbeheercontrollers (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 elk BMC-knooppunt. Indien aanwezig, bevindt de HLH (Hardware Lifecycle Host) zich in dit netwerk en kan OEM-specifieke software bieden voor hardwareonderhoud of bewaking.

De HLH host ook de Deployment 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 netwerk /20 (4096 IP's) is privé voor de Azure Stack Hub-regio (wordt niet gerouteerd buiten de randswitchapparaten van het Azure Stack Hub-systeem) en is onderverdeeld in meerdere subnetten. Hier volgen enkele voorbeelden:

• Storage netwerk: een /25 (128 IP-adressen) netwerk dat wordt gebruikt ter ondersteuning van het gebruik van SMB-opslagverkeer (Spaces Direct and Server Message Block) 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 waarop infrastructuurservices worden uitgevoerd.

Voor het Azure Stack Hub-systeem is een extra persoonlijke interne IP-ruimte van /20 vereist . Dit netwerk wordt privé naar 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 binnen 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 waarmee de Azure Stack Hub-infrastructuur op containers kan worden uitgevoerd. Bovendien biedt deze nieuwe privé-IP-ruimte doorlopende inspanningen 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 om het gebruik te optimaliseren en de prestaties te verbeteren. Bovendien wordt de /20 privé-IP-ruimte 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 Set-AzsPrivateNetwork PEP-cmdlet .

Notitie

De /20-invoer 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 /20-invoer niet hebt voltooid, zoals beschreven in de herstelstappen. Er wordt een waarschuwing weergegeven in de beheerportal totdat de bovenstaande herstelstappen zijn voltooid. Zie het artikel over de netwerkintegratie van datacenter om te begrijpen hoe deze nieuwe privéruimte wordt verbruikt.

Herstelstappen: Volg de instructies om een PEP-sessie te openen. 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 Internal Network-bereik dat is 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 uitwisselen. Dit subnet kan extern worden routeerbaar van de Azure Stack Hub-oplossing voor uw datacenter. Het is niet raadzaam om openbare of internetrouteerbare IP-adressen in dit subnet te gebruiken. Dit netwerk wordt geadverteerd naar de rand, maar de meeste IP-adressen worden beveiligd door Access Control Lijsten (ACL's). De IP-adressen die zijn toegestaan voor toegang, liggen binnen een klein bereik dat gelijk is aan 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 maakt gebruik van de adresgroep en wijst /32-netwerken toe voor tenantworkloads. In de routeringstabel van de switch 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 behoudt de eerste 31 adressen van dit openbare VIP-netwerk terwijl de rest wordt gebruikt door tenant-VM's. De netwerkgrootte in dit subnet kan variëren van minimaal /26 (64 hosts) tot maximaal /22 (1022 hosts). U wordt aangeraden 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 voor het verbinden van resources in het virtuele netwerk met on-premises/bedrijfsbronnen:

• Gebruik openbare IP-adressen van het openbare VIP-netwerk.
• Gebruik Virtual Network Gateway of Network Virtual Appliance (NVA).

Wanneer een S2S VPN-tunnel wordt gebruikt om resources te verbinden met of vanuit on-premises netwerken, kan er een scenario optreden waarin een resource ook een openbaar IP-adres heeft toegewezen en deze niet meer bereikbaar is via dat openbare IP-adres. Als de bron probeert toegang te krijgen tot het openbare IP-adres binnen hetzelfde subnetbereik dat is gedefinieerd in de routes van de lokale netwerkgateway (Virtual Network Gateway) of door de gebruiker gedefinieerde route voor NVA-oplossingen, probeert Azure Stack Hub het verkeer terug te leiden 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 VIRTUELE machine, in plaats van bron-NATed te zijn als het openbare IP-adres:

Er zijn twee oplossingen voor dit probleem:

• Routeer het verkeer dat wordt omgeleid naar het openbare VIP-netwerk naar internet.
• Voeg een NAT-apparaat toe aan NAT-subnet-IP-adressen die zijn gedefinieerd in de lokale netwerkgateway die zijn gericht op het openbare VIP-netwerk.

Schakelen tussen infrastructuurnetwerk

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

Schakelen tussen beheernetwerk

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

Toegestane netwerken

Het implementatiewerkblad heeft een veld waarmee de operator bepaalde ACL's (Access Control List) kan wijzigen om toegang te verlenen tot netwerkapparaatbeheerinterfaces en de HLH (Hardware Lifecycle Host) van een vertrouwd datacenternetwerkbereik. Wanneer de toegangsbeheerlijst wordt gewijzigd, kan de operator toestaan dat de vm's van hun beheer jumpbox binnen een specifiek netwerkbereik toegang hebben tot de interface voor switchbeheer, het HLH-besturingssysteem en de HLH BMC. De operator kan een of meerdere subnetten aan deze lijst opgeven, als deze leeg blijft, wordt de toegang standaard geweigerd. Deze nieuwe functionaliteit vervangt de noodzaak voor handmatige interventie na de implementatie, omdat deze wordt beschreven in de specifieke instellingen wijzigen in uw Azure Stack Hub-switchconfiguratie.

Volgende stappen

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