Referentiepatroon voor implementatienetwerk met één server voor opslag controleren voor Azure Local

Artikel
12/26/2024

Van toepassing op: Azure Local 2311.2 en hoger

In dit artikel wordt het referentiepatroon voor opslagnetwerk met één server beschreven dat u kunt gebruiken om uw lokale Azure-oplossing te implementeren. De informatie in dit artikel helpt u ook te bepalen of deze configuratie haalbaar is voor uw implementatieplanningsbehoeften. Dit artikel is gericht op de IT-beheerders die Azure Local implementeren en beheren in hun datacenters.

Zie Azure Local-netwerkimplementatiepatronen voor meer informatie over andere netwerkpatronen.

Inleiding

Implementaties met één server bieden kosten- en ruimtevoordelen en helpen uw infrastructuur te moderniseren en Azure Hybrid Computing naar locaties te brengen die de tolerantie van één machine kunnen verdragen. Azure Local die op één computer wordt uitgevoerd, gedraagt zich op dezelfde manier als Azure Local op een cluster met meerdere knooppunten: het brengt systeemeigen Azure Arc-integratie met zich mee, de mogelijkheid om servers toe te voegen om het systeem uit te schalen en bevat dezelfde Voordelen van Azure.

Het biedt ook ondersteuning voor dezelfde workloads, zoals AVD (Azure Virtual Desktop) en AKS op Azure Local, en wordt op dezelfde manier ondersteund en gefactureerd.

Scenario's

Gebruik het opslagpatroon met één server in de volgende scenario's:

Faciliteiten die een lager tolerantieniveau kunnen verdragen. Overweeg dit patroon te implementeren wanneer uw locatie of service die door dit patroon wordt geleverd, een lager tolerantieniveau tolereert zonder dat dit van invloed is op uw bedrijf.
Voedsel, gezondheidszorg, financiën, detailhandel, overheidsfaciliteiten. Sommige scenario's voor voedsel, gezondheidszorg, financiën en retail kunnen deze optie toepassen om hun kosten te minimaliseren zonder dat dit van invloed is op kernactiviteiten en zakelijke transacties.

Hoewel SDN-services (Software Defined Networking) Layer 3 (L3) volledig worden ondersteund op dit patroon, moeten routeringsservices zoals Border Gateway Protocol (BGP) mogelijk worden geconfigureerd voor het firewallapparaat op de TOR-switch (top-of-rack).

Voor netwerkbeveiligingsfuncties zoals microsegmentatie en QoS (Quality of Service) is geen extra configuratie vereist voor het firewallapparaat, omdat deze worden geïmplementeerd op de laag van de virtuele netwerkadapter. Zie Microsegmentatie met Azure Local voor meer informatie.

Notitie

Enkele servers mogen slechts één stationstype gebruiken: NVMe-stations (Non-volatile Memory Express) of SSD-stations (Solid-State).

Onderdelen van fysieke connectiviteit

Zoals wordt geïllustreerd in het onderstaande diagram, heeft dit patroon de volgende fysieke netwerkonderdelen:

Voor noord- en zuidwaarts verkeer wordt het Lokale Azure-exemplaar geïmplementeerd met behulp van één TOR L2- of L3-switch.
Twee gekoppelde netwerkpoorten voor het afhandelen van het beheer- en rekenverkeer dat is verbonden met de switch.
Twee niet-verbonden RDMA-NIC's die alleen worden gebruikt als u een tweede server aan uw systeem toevoegt voor uitschalen. Dit betekent geen verhoogde kosten voor bekabeling of fysieke switchpoorten.
(Optioneel) Een BMC-kaart kan worden gebruikt om extern beheer van uw omgeving mogelijk te maken. Voor beveiligingsdoeleinden kunnen sommige oplossingen gebruikmaken van een headless configuratie zonder de BMC-kaart.

De volgende tabel bevat enkele richtlijnen voor een implementatie met één server:

Netwerk	Beheer en rekenkracht	Storage	BMC
Snelheid van koppeling	Ten minste 1 Gbps als RDMA is uitgeschakeld, 10 Gbps aanbevolen.	Ten minste 10 Gbps.	Neem contact op met de hardwarefabrikant.
Interfacetype	RJ45, SFP+of SFP28	SFP+ of SFP28	RJ45
Poorten en aggregatie	Twee gekoppelde poorten	Optioneel om het toevoegen van een tweede server toe te staan; niet-verbonden poorten.	Eén poort
RDMA	Optioneel. Is afhankelijk van de vereisten voor rdma- en NIC-ondersteuning voor gasten.	N.v.t.	N.v.t.

Atc-intenties voor netwerken

Het patroon met één server maakt gebruik van slechts één netwerk-ATC-intentie voor beheer- en rekenverkeer. De RDMA-netwerkinterfaces zijn optioneel en verbroken.

Beheer- en rekenintentie

De beheer- en rekenintentie heeft de volgende kenmerken:

Intentietype: Beheer en berekening
In tentmodus: clustermodus
Koppeling: Ja - pNIC01 en pNIC02 zijn gekoppeld
Standaardbeheer-VLAN: Geconfigureerd VLAN voor beheeradapters is gewijzigd
PA VLAN en vNIC's: Netwerk-ATC is transparant voor PA vNICs en VLAN's
VLAN's en vNIC's berekenen: Netwerk-ATC is transparant voor het berekenen van VM-vNIC's en VLAN's

Opslagintentie

De opslagintentie heeft de volgende kenmerken:

Intentietype: Geen
In tentmodus: Geen
Koppeling: de verbinding met pNIC03 en pNIC04 is verbroken
Standaard-VLAN's: geen
Standaardsubnetten: Geen

Volg deze stappen om een netwerkintentie te maken voor dit referentiepatroon:

Voer PowerShell uit als administrator.

Voer de volgende opdracht uit:

Add-NetIntent -Name <management_compute> -Management -Compute -ClusterName <HCI01> -AdapterName <pNIC01, pNIC02>

Zie Hostnetwerken implementeren: Compute- en beheerintentie voor meer informatie.

Onderdelen van logisch netwerk

Zoals wordt geïllustreerd in het onderstaande diagram, heeft dit patroon de volgende onderdelen van het logische netwerk:

VLAN's voor opslagnetwerk

Optioneel: voor dit patroon is geen opslagnetwerk vereist.

OOB-netwerk

Het OOB-netwerk (Out of Band) is gewijd aan de ondersteuning van de 'lights-out' serverbeheerinterface, ook wel bekend als de BMC (Baseboard Management Controller). Elke BMC-interface maakt verbinding met een door de klant geleverde switch. De BMC wordt gebruikt om PXE-opstartscenario's te automatiseren.

Voor het beheernetwerk is toegang tot de BMC-interface vereist met behulp van UDP-poort 623 (Intelligent Platform Management Interface) User Datagram Protocol (UDP).

Het OOB-netwerk is geïsoleerd van rekenworkloads en is optioneel voor implementaties die niet op oplossingen zijn gebaseerd.

Beheer-VLAN

Voor alle fysieke rekenhosts is toegang tot het logische beheernetwerk vereist. Voor het plannen van IP-adressen moet aan elke fysieke rekenhost ten minste één IP-adres zijn toegewezen vanuit het logische beheernetwerk.

Een DHCP-server kan automatisch IP-adressen toewijzen voor het beheernetwerk of u kunt handmatig statische IP-adressen toewijzen. Wanneer DHCP de voorkeursmethode voor IP-toewijzing is, wordt u aangeraden DHCP-reserveringen zonder verlooptijd te gebruiken.

Het beheernetwerk ondersteunt de volgende VLAN-configuraties:

Systeemeigen VLAN : u hoeft geen VLAN-id's op te geven. Dit is vereist voor installaties op basis van oplossingen.
Gelabeld VLAN: u levert VLAN-id's op het moment van de implementatie. tenantverbindingen op elke gateway en schakelt netwerkverkeer over naar een stand-bygateway als een gateway mislukt.

Gateways gebruiken Border Gateway Protocol om GRE-eindpunten te adverteren en punt-naar-punt-verbindingen tot stand te brengen. SDN-implementatie maakt een standaardgatewaygroep die ondersteuning biedt voor alle verbindingstypen. In deze pool kunt u opgeven hoeveel gateways op stand-by zijn gereserveerd voor het geval een actieve gateway mislukt.

Zie Wat is RAS-gateway voor SDN voor meer informatie ?

Het beheernetwerk ondersteunt al het verkeer dat wordt gebruikt voor het beheer van het cluster, waaronder Extern bureaublad, Windows-beheercentrum en Active Directory.

Zie Een SDN-infrastructuur plannen: Beheer en HNV Provider voor meer informatie.

VLAN's berekenen

In sommige scenario's hoeft u geen SDN Virtual Networks te gebruiken met VXLAN-inkapseling (Virtual Extensible LAN). In plaats daarvan kunt u traditionele VLAN's gebruiken om uw tenantworkloads te isoleren. Deze VLAN's worden geconfigureerd op de poort van de TOR-switch in de trunk-modus. Wanneer u nieuwe VM's verbindt met deze VLAN's, wordt de bijbehorende VLAN-tag gedefinieerd op de virtuele netwerkadapter.

HNV Provider Address (PA) netwerk

Het Pa-netwerk (Hyper-V-netwerkvirtualisatie) provideradres (HNV) fungeert als het onderliggende fysieke netwerk voor tenantverkeer oost/west (intern intern) tenantverkeer, noord/zuid (extern-intern) tenantverkeer en om BGP-peeringgegevens uit te wisselen met het fysieke netwerk. Dit netwerk is alleen vereist wanneer er behoefte is aan het implementeren van virtuele netwerken met VXLAN-inkapseling voor een andere isolatielaag en voor netwerk multitenancy.

Zie Een SDN-infrastructuur plannen: Beheer en HNV Provider voor meer informatie.

Opties voor netwerkisolatie

De volgende opties voor netwerkisolatie worden ondersteund:

VLAN's (IEEE 802.1Q)

VLAN's staan apparaten toe die gescheiden moeten worden gehouden om de bekabeling van een fysiek netwerk te delen en toch te voorkomen dat ze rechtstreeks met elkaar communiceren. Dit beheerde delen levert voordelen op in eenvoud, beveiliging, verkeersbeheer en economie. Een VLAN kan bijvoorbeeld worden gebruikt om verkeer binnen een bedrijf te scheiden op basis van afzonderlijke gebruikers of groepen gebruikers of hun rollen, of op basis van verkeerskenmerken. Veel internethostingservices maken gebruik van VLAN's om privézones van elkaar te scheiden, zodat de servers van elke klant in één netwerksegment kunnen worden gegroepeerd, ongeacht waar de afzonderlijke servers zich in het datacenter bevinden. Sommige voorzorgsmaatregelen zijn nodig om te voorkomen dat verkeer 'ontsnappen' van een bepaald VLAN, een aanval die bekend staat als VLAN-hopping.

Zie Inzicht in het gebruik van virtuele netwerken en VLAN's voor meer informatie.

Standaardbeleid voor netwerktoegang en microsegmentatie

Standaardbeleid voor netwerktoegang zorgt ervoor dat alle virtuele machines (VM's) in uw Azure Stack HCI-cluster standaard worden beveiligd tegen externe bedreigingen. Met deze beleidsregels blokkeren we standaard binnenkomende toegang tot een virtuele machine, terwijl we de optie bieden om selectieve binnenkomende poorten in te schakelen en zo de VM's te beveiligen tegen externe aanvallen. Deze afdwinging is beschikbaar via beheerprogramma's zoals Windows Admin Center.

Microsegmentatie omvat het maken van gedetailleerd netwerkbeleid tussen toepassingen en services. Dit vermindert in wezen de beveiligingsperimeter tot een omheining rond elke toepassing of VM. Deze omheining maakt alleen noodzakelijke communicatie mogelijk tussen toepassingslagen of andere logische grenzen, waardoor het buitengewoon moeilijk is voor cyberdreigingen om lateraal van het ene systeem naar het andere te verspreiden. Microsegmentatie isoleert netwerken veilig van elkaar en vermindert het totale kwetsbaarheid voor aanvallen van een netwerkbeveiligingsincident.

Standaardbeleid voor netwerktoegang en microsegmentatie worden gerealiseerd als vijf tuple stateful (bronadresvoorvoegsel, bronpoort, doeladresvoorvoegsel, doelpoort en protocol) firewallregels op Azure Stack HCI-clusters. Firewallregels worden ook wel netwerkbeveiligingsgroepen (NSG's) genoemd. Deze beleidsregels worden afgedwongen op de vSwitch-poort van elke VIRTUELE machine. Het beleid wordt gepusht via de beheerlaag en de SDN-netwerkcontroller distribueert deze naar alle toepasselijke hosts. Deze beleidsregels zijn beschikbaar voor VM's in traditionele VLAN-netwerken en op SDN-overlaynetwerken.

Zie Wat is Datacenter Firewall? voor meer informatie.

QoS voor VM-netwerkadapters

U kunt QoS (Quality of Service) configureren voor een VM-netwerkadapter om de bandbreedte op een virtuele interface te beperken om te voorkomen dat een VM met veel verkeer te maken heeft met ander VM-netwerkverkeer. U kunt QoS ook configureren om een specifieke hoeveelheid bandbreedte voor een VIRTUELE machine te reserveren om ervoor te zorgen dat de VIRTUELE machine verkeer kan verzenden, ongeacht ander verkeer in het netwerk. Dit kan worden toegepast op vm's die zijn gekoppeld aan traditionele VLAN-netwerken en vm's die zijn gekoppeld aan SDN-overlaynetwerken.

Zie QoS configureren voor een VM-netwerkadapter voor meer informatie.

Virtuele netwerken

Netwerkvirtualisatie biedt virtuele netwerken naar VM's die vergelijkbaar zijn met de manier waarop servervirtualisatie (hypervisor) VM's aan het besturingssysteem biedt. Met netwerkvirtualisatie worden virtuele netwerken losgekoppeld van de fysieke netwerkinfrastructuur en worden de beperkingen van VLAN en hiërarchische IP-adrestoewijzing van VM-inrichting verwijderd. Dankzij deze flexibiliteit kunt u eenvoudig overstappen op IaaS-clouds (Infrastructuur als een service) en is het efficiënt voor hosters en datacenterbeheerders om hun infrastructuur te beheren en de benodigde isolatie van meerdere tenants, beveiligingsvereisten en overlappende IP-adressen van VM's te onderhouden.

Zie Hyper-V-netwerkvirtualisatie voor meer informatie.

Opties voor L3-netwerkservices

De volgende L3-netwerkserviceopties zijn beschikbaar:

Peering op virtueel netwerk

Met peering van virtuele netwerken kunt u naadloos twee virtuele netwerken verbinden. Zodra de peering is uitgevoerd, worden de virtuele netwerken weergegeven als één voor connectiviteitsdoeleinden. Enkele voordelen van peering van virtuele netwerken zijn:

Verkeer tussen VM's in de gekoppelde virtuele netwerken wordt alleen via de backbone-infrastructuur gerouteerd via privé-IP-adressen. Voor de communicatie tussen de virtuele netwerken is geen openbaar internet of gateways vereist.
Een verbinding met lage latentie en hoge bandbreedte tussen resources in verschillende virtuele netwerken.
De mogelijkheid voor resources in één virtueel netwerk om te communiceren met resources in een ander virtueel netwerk.
Geen downtime voor resources in een virtueel netwerk bij het maken van de peering.

Zie Peering voor virtuele netwerken voor meer informatie.

SDN-software load balancer

Cloudserviceproviders (CSP's) en ondernemingen die SDN (Software Defined Networking) implementeren, kunnen Software Load Balancer (SLB) gebruiken om klantnetwerkverkeer gelijkmatig over virtuele netwerkresources te verdelen. Met SLB kunnen meerdere servers dezelfde workload hosten, waardoor hoge beschikbaarheid en schaalbaarheid mogelijk zijn. Het wordt ook gebruikt om binnenkomende NAT-services (Network Address Translation) te bieden voor binnenkomende toegang tot VM's en uitgaande NAT-services voor uitgaande connectiviteit.

Met behulp van SLB kunt u uw taakverdelingsmogelijkheden uitschalen met behulp van SLB-VM's op dezelfde Hyper-V-rekenservers die u gebruikt voor uw andere VM-workloads. SLB biedt ondersteuning voor het snel maken en verwijderen van taakverdelingseindpunten, zoals vereist voor CSP-bewerkingen. Daarnaast biedt SLB ondersteuning voor tientallen gigabytes per cluster, biedt een eenvoudig inrichtingsmodel en is eenvoudig uit te schalen en in te schalen. SLB maakt gebruik van Border Gateway Protocol om virtuele IP-adressen te adverteren naar het fysieke netwerk.

Zie Wat is SLB voor SDN voor meer informatie ?

SDN VPN-gateways

SDN Gateway is een op software gebaseerde Border Gateway Protocol (BGP) router die is ontworpen voor CSP's en ondernemingen die virtuele netwerken met meerdere tenants hosten met hyper-V-netwerkvirtualisatie (HNV). U kunt RAS-gateway gebruiken om netwerkverkeer te routeren tussen een virtueel netwerk en een ander netwerk, lokaal of extern.

SDN-gateway kan worden gebruikt om:

Maak beveiligde site-naar-site IPsec-verbindingen tussen virtuele SDN-netwerken en externe klantnetwerken via internet.
Maak GRE-verbindingen (Generic Routing Encapsulation) tussen virtuele SDN-netwerken en externe netwerken. Het verschil tussen site-naar-site-verbindingen en GRE-verbindingen is dat de laatste geen versleutelde verbinding is.

Zie GRE-tunneling in Windows Server voor meer informatie over GRE-connectiviteitsscenario's.
Laag 3-verbindingen (L3) maken tussen virtuele SDN-netwerken en externe netwerken. In dit geval fungeert de SDN-gateway als een router tussen uw virtuele netwerk en het externe netwerk.

SDN-gateway vereist SDN-netwerkcontroller. Netwerkcontroller voert de implementatie van gatewaygroepen uit, configureert

Volgende stappen

Meer informatie over patronen met twee knooppunten: implementatiepatronen voor lokale Netwerken in Azure.

Delen via