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 waarnaar DNS-aanvragen moeten worden doorgestuurd. Zie Azure Stack Hub Datacenter Integration - DNSvoor meer informatie over DNS-vereisten voor Azure Stack Hub.
Fysiek netwerkontwerp
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 van de Top-of-Rack-switches (ToR) vereist naar de dichtstbijzijnde switch of router, die in dit artikel wordt aangeduid als Border. De ToRs kunnen worden gekoppeld aan één of een paar border routers. De ToR is vooraf geconfigureerd door ons automatiseringsprogramma. Er wordt 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 bij het gebruik van statische routering, met een maximum van vier verbindingen op beide routeringsopties. Deze verbindingen zijn beperkt tot SFP+ of SFP28-media en minimaal één GB-snelheid. Neem contact op met de leverancier van de oem-hardware (Original Equipment Manufacturer) voor beschikbaarheid. In het volgende diagram ziet u het aanbevolen ontwerp:
Bandbreedtetoewijzing
Azure Stack Hub is gebouwd met windows Server 2019-failovercluster- en Spaces Direct-technologieën. Om ervoor te zorgen dat de communicatie met Opslagruimten Direct aan de prestaties en schaal van de oplossing kan voldoen, is een deel van de fysieke netwerkconfiguratie van Azure Stack Hub ingesteld voor het gebruik van verkeersscheiding en bandbreedtegaranties. 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 aan te sluiten bij de huidige best practices zoals gedefinieerd voor Windows Server 2019, past Azure Stack Hub zich aan om een extra verkeersklasse of prioriteit te gebruiken. Hiermee wordt de servercommunicatie verder gescheiden, specifiek ter ondersteuning van de besturing van failoverclustering. Deze nieuwe definitie van de verkeersklasse is 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 tussen failoverclusters en zijn bedoeld om situaties te voorkomen waarin de netwerkbandbreedte volledig wordt verbruikt en als gevolg hiervan berichten over failoverclusterbeheer worden onderbroken. Merk op dat communicatie in een failovercluster een cruciaal onderdeel is van de Azure Stack Hub-infrastructuur en dat wanneer deze langdurig wordt verstoord, dit kan leiden tot instabiliteit in de Spaces Direct-opslagservices of andere services, wat uiteindelijk invloed kan hebben op de stabiliteit van workloads van tenants of eindgebruikers.
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:
Notitie
Een waarschuwing in de portal herinnert de operator eraan om de PEP-cmdlet uit te voeren Set-AzsPrivateNetwork- 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 privé-IP-ruimte /20.
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 kunnen worden geïntegreerd met de TOR-switches (Top-Of-Rack), Baseboard Management Controller (BMC) en randswitches (klantnetwerk).
BMC-netwerk
Dit netwerk is gewijd aan het verbinden van alle beheercontrollers voor basisboards (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 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, valideren en openen. Deze onderdelen kunnen zich binnen en buiten uw bedrijfsnetwerk bevinden (bijvoorbeeld: NTP, DNS en Azure). Zie de sectie NAT in azure Stack Hub-firewallintegratievoor meer informatie over connectiviteitsvereisten.
Privénetwerk
Dit /20 -netwerk (4096 IP-adressen) is privé voor de Azure Stack Hub-regio (routeert niet 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 (512 IP)-netwerk dat is toegewezen aan intern verkeer tussen containers met infrastructuurservices.
Voor het Azure Stack Hub-systeem is een extra /20 persoonlijke interne IP-ruimte vereist. Dit netwerk is privé voor het Azure Stack Hub-systeem (wordt niet gerouteerd buiten de randswitchapparaten van het Azure Stack Hub-systeem) en kan worden hergebruikt 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 privé-IP-ruimte /20 is onderverdeeld in meerdere netwerken waarmee de Azure Stack Hub-infrastructuur op containers kan worden uitgevoerd. Bovendien maakt deze nieuwe privé-IP-ruimte doorlopende inspanningen 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 om het gebruik te optimaliseren en de prestaties te verbeteren. Daarnaast 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. Zie RFC 1918voor richtlijnen over privé-IP-adressen.
Azure Stack Hub-infrastructuurnetwerk
Dit /24-netwerk is gewijd aan interne onderdelen van Azure Stack Hub, zodat ze onderling kunnen communiceren en gegevens kunnen uitwisselen. Dit subnet kan extern worden routeerbaar vanuit de Azure Stack Hub-oplossing naar uw datacenter. Het wordt afgeraden om openbare of internetrouteerbare IP-adressen op dit subnet te gebruiken. Dit netwerk wordt geadverteerd tot aan de grens, maar de meeste IP-adressen worden beveiligd door ACL’s (Toegangscontrolelijsten). De IP-adressen die zijn toegestaan voor toegang, liggen binnen een klein bereik, vergelijkbaar met een /27-netwerk en hostservices zoals het bevoegde eindpunt (PEP) en Back-up van Azure Stack Hub.
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 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 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 de Virtual Network Gateway of de Network Virtual Appliance (NVA).
Wanneer een S2S VPN-tunnel wordt gebruikt om resources te verbinden met of van on-premises netwerken, kan er een scenario optreden waarin ook een resource 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 lokale netwerkgatewayroutes (virtuele netwerkgateway) of door de gebruiker gedefinieerde route voor NVA-oplossingen, probeert Azure Stack Hub het 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 virtuele machine, in plaats van bron-NATed te zijn als het openbare IP-adres:
Er zijn twee oplossingen voor dit probleem:
- Routeer het verkeer naar het openbare VIP-netwerk naar internet.
- Voeg een NAT-apparaat toe om alle subnet-IP's te NAT-ten die in de lokale netwerkgateway zijn gedefinieerd en doorgestuurd naar het openbare VIP-netwerk.
Schakel 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 naar uw datacenter. Ze kunnen privé- of openbare IP-adressen zijn.
Schakel 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 eerder genoemde switchinfrastructuurnetwerk.
Toegestane netwerken
Het implementatiewerkblad heeft een veld waarmee de operator bepaalde toegangsbeheerlijsten kan wijzigen om toegang te verlenen tot netwerkapparaatbeheerinterfaces en de HLH (Hardware Lifecycle Host) vanuit een netwerkbereik van een vertrouwd datacenter. Wanneer de toegangsbeheerlijst is gewijzigd, kan de operator toestaan dat hun beheer jumpbox-VM's binnen een specifiek netwerkbereik toegang hebben tot de switchbeheerinterface en het HLH-besturingssysteem. De operator kan één of meerdere subnetten aan deze lijst verstrekken; als deze optie leeg blijft, wordt standaard de toegang geweigerd. Deze nieuwe functionaliteit vervangt de noodzaak van handmatige interventie na de implementatie, omdat deze wordt beschreven in de Specifieke instellingen wijzigen in de configuratie van uw Azure Stack Hub-switch.
Volgende stappen
- routering van virtueel netwerkverkeer
- Meer informatie over netwerkplanning: Border-connectiviteit