Freigeben über

Überprüfen des Netzwerkreferenzmusters für die Bereitstellung von Einzelservern für Azure Local

  • Artikel

Gilt für: Azure Local, Versionen 23H2 und 22H2

In diesem Artikel wird das Referenzmuster des Speichernetzwerks mit einem Server beschrieben, mit dem Sie Ihre lokale Azure-Lösung bereitstellen können. Anhand der Informationen in diesem Artikel können Sie auch ermitteln, ob diese Konfiguration für Ihre Bereitstellungsplanungsanforderungen geeignet ist. Dieser Artikel richtet sich an die IT-Administratoren, die Azure Local in ihren Rechenzentren bereitstellen und verwalten.

Informationen zu anderen Netzwerkmustern finden Sie unter Azure Local network deployment patterns.

Einführung

Bereitstellungen mit einem einzigen Server bieten Kosten- und Platzvorteile und helfen dabei, Ihre Infrastruktur zu modernisieren und Azure Hybrid Computing an Standorte zu bringen, die die Ausfallsicherheit eines einzelnen Computers tolerieren können. Azure Local, das auf einem einzelnen Computer ausgeführt wird, verhält sich ähnlich wie Azure Local auf einem Multi-Node-Cluster: Es bietet native Azure Arc-Integration, die Möglichkeit, Server zum Skalieren des Systems hinzuzufügen und umfasst dieselben Azure-Vorteile.

Sie unterstützt auch dieselben Workloads, z. B. Azure Virtual Desktop (AVD) und AKS auf Azure Local, und wird auf die gleiche Weise unterstützt und in Rechnung gestellt.

Szenarien

Verwenden Sie das Speichermuster mit einem Server in den folgenden Szenarien:

  • Einrichtungen, die ein geringeres Maß an Resilienz tolerieren können. Erwägen Sie die Implementierung dieses Musters, wenn Ihr Standort oder Dienst, der von diesem Muster bereitgestellt wird, ein niedrigeres Maß an Resilienz tolerieren kann, ohne dass sich dies auf Ihr Unternehmen auswirkt.

  • Lebensmittel, Gesundheitswesen, Finanzen, Einzelhandel, staatliche Einrichtungen. Einige Lebensmittel-, Gesundheits-, Finanz- und Einzelhandelsszenarien können diese Option anwenden, um ihre Kosten zu minimieren, ohne dass sich dies auf Kernvorgänge und Geschäftstransaktionen auswirkt.

Obwohl Software Defined Networking (SDN) Layer 3 (L3)-Dienste für dieses Muster vollständig unterstützt werden, müssen Routingdienste wie das Border Gateway Protocol (BGP) möglicherweise für das Firewallgerät auf dem ToR-Switch (Top-of-Rack) konfiguriert werden.

Netzwerksicherheitsfeatures wie Mikrosegmentierung und Quality of Service (QoS) erfordern keine zusätzliche Konfiguration für das Firewallgerät, da sie auf der Ebene des virtuellen Netzwerkadapters implementiert werden. Weitere Informationen finden Sie unter Microsegmentation mit Azure Local.

Hinweis

Einzelserver dürfen nur einen einzigen Laufwerkstyp verwenden: NVMe (Non-Volatile Memory Express) oder SSD (Solid State Drive).

Physische Verbindungskomponenten

Wie im folgenden Diagramm dargestellt, weist dieses Muster die folgenden physischen Netzwerkkomponenten auf:

  • Für ausgehenden/südgebundenen Datenverkehr wird die lokale Azure-Instanz mit einem einzelnen TOR L2- oder L3-Switch implementiert.
  • Zwei teamierte Netzwerkports, um die Verwaltung zu verarbeiten und den mit dem Switch verbundenen Datenverkehr zu berechnen.
  • Zwei getrennte RDMA-NICs, die nur verwendet werden, wenn Sie Ihrem System einen zweiten Server zum Skalieren hinzufügen. Dies bedeutet keine erhöhten Kosten für Kabel- oder physische Switchports.
  • (Optional) Eine BMC-Karte kann verwendet werden, um die Remoteverwaltung Ihrer Umgebung zu ermöglichen. Für Sicherheitszwecke können einige Lösungen eine headless-Konfiguration ohne die BMC-Karte verwenden.

Diagramm mit einem Physischen Konnektivitätslayout mit einem Einzelnen Server.

In der folgenden Tabelle sind einige Richtlinien für eine Bereitstellung mit einem einzigen Server aufgeführt:

Network Verwaltung und Berechnung Storage BMC
Verbindungsgeschwindigkeit Mindestens 1 Gb/s, wenn RDMA deaktiviert ist, wird empfohlen, 10 Gb/s. Mindestens 10 Gb/s. Wenden Sie sich an den Hardwarehersteller.
Schnittstellentyp RJ45, SFP+, oder SFP28 SFP+ oder SFP28 RJ45
Ports und Aggregation Zwei teamierte Ports Optional zum Hinzufügen eines zweiten Servers; getrennte Ports. Ein Port
RDMA Optional. Hängt von den Anforderungen für die RDMA- und NIC-Unterstützung des Gasts ab. – –

AtC-Netzwerkabsichten

Das Einzelservermuster verwendet nur eine Netzwerk-ATC-Absicht für die Verwaltung und Berechnung von Datenverkehr. Die RDMA-Netzwerkschnittstellen sind optional und getrennt.

Diagramm mit Netzwerk-ATC-Absichten für das Switchless-Muster mit einem Server.

Verwaltungs- und Computeabsicht

Die Verwaltungs- und Berechnungsabsicht weist die folgenden Merkmale auf:

  • Intent-Typ: Verwaltung und Berechnung
  • In Zelt-Modus: Clustermodus
  • Teaming: Ja - pNIC01 und pNIC02 sind teamiert
  • Standardverwaltungs-VLAN: Konfiguriertes VLAN für Verwaltungsadapter wird ummodifiziert
  • PA VLAN und vNICs: Network ATC ist transparent für PA vNICs und VLANs
  • Berechnen von VLANs und vNICs: Netzwerk-ATC ist transparent für die Berechnung von VM-vNICs und VLANs

Speicherabsicht

Die Speicherabsicht weist die folgenden Merkmale auf:

  • Intent-Typ: Keine
  • In Zelt-Modus: Keine
  • Teamerstellung: pNIC03 und pNIC04 werden getrennt
  • Standard-VLANs: Keine
  • Standardsubnetze: Keine

Führen Sie die folgenden Schritte aus, um eine Netzwerkabsicht für dieses Referenzmuster zu erstellen:

  1. Führen Sie PowerShell als Administrator aus.

  2. Führen Sie den folgenden Befehl aus:

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

Weitere Informationen finden Sie unter Bereitstellen von Hostnetzwerken: Berechnungs- und Verwaltungsabsicht.

Logische Netzwerkkomponenten

Wie im folgenden Diagramm dargestellt, weist dieses Muster die folgenden logischen Netzwerkkomponenten auf:

Diagramm, das das logische Verbindungslayout mit einem Server zeigt.

Speichernetzwerk-VLANs

Optional – Für dieses Muster ist kein Speichernetzwerk erforderlich.

OOB-Netzwerk

Das Out of Band(OOB)-Netzwerk dient zur Unterstützung der "Lights-out"-Serververwaltungsschnittstelle, die auch als Baseboard-Verwaltungscontroller (Baseboard Management Controller, BMC) bezeichnet wird. Jede BMC-Schnittstelle stellt eine Verbindung mit einem vom Kunden bereitgestellten Switch her. Der BMC wird verwendet, um PXE-Startszenarien zu automatisieren.

Das Verwaltungsnetzwerk erfordert Zugriff auf die BMC-Schnittstelle mithilfe von IPMI-Port 623 (User Datagram Protocol) (User Datagram Protocol, UDP).

Das OOB-Netzwerk ist von Computeworkloads isoliert und ist optional für nicht lösungsbasierte Bereitstellungen.

Verwaltungs-VLAN

Alle physischen Computehosts benötigen Zugriff auf das logische Verwaltungsnetzwerk. Für die IP-Adressplanung muss jeder physische Computehost mindestens eine IP-Adresse aus dem logischen Verwaltungsnetzwerk zugewiesen haben.

Ein DHCP-Server kann automatisch IP-Adressen für das Verwaltungsnetzwerk zuweisen, oder Sie können statische IP-Adressen manuell zuweisen. Wenn DHCP die bevorzugte IP-Zuweisungsmethode ist, empfiehlt es sich, DHCP-Reservierungen ohne Ablauf zu verwenden.

Das Verwaltungsnetzwerk unterstützt die folgenden VLAN-Konfigurationen:

  • Natives VLAN – Sie müssen keine VLAN-IDs bereitstellen. Dies ist für lösungsbasierte Installationen erforderlich.

  • Tagged VLAN – Sie geben VLAN-IDs zum Zeitpunkt der Bereitstellung an. Mandantenverbindungen auf jedem Gateway und wechselt Netzwerkdatenverkehr zu einem Standbygateway, wenn ein Gateway fehlschlägt.

Von Gateways wird das Border Gateway Protocol verwendet, um GRE-Endpunkte anzukündigen und Point-to-Point-Verbindungen herzustellen. Bei der SDN-Bereitstellung wird ein Standardgatewaypool erstellt, der alle Verbindungstypen unterstützt. Innerhalb dieses Pools können Sie angeben, wie viele Gateways im Standby für den Fall vorgehalten werden sollen, dass ein aktives Gateway ausfällt.

Weitere Informationen finden Sie unter Was ist RAS-Gateway für SDN?

Das Verwaltungsnetzwerk unterstützt den gesamten Datenverkehr, der für die Verwaltung des Clusters verwendet wird, einschließlich Remotedesktop, Windows Admin Center und Active Directory.

Weitere Informationen finden Sie unter Planen einer SDN-Infrastruktur: Verwaltung und HNV-Anbieter.

Berechnen von VLANs

In einigen Szenarien müssen Sie keine VIRTUELLEN SDN-Netzwerke mit VXLAN-Kapselung (Virtual Extensible LAN, VXLAN) verwenden. Stattdessen können Sie herkömmliche VLANs verwenden, um Ihre Mandantenarbeitslasten zu isolieren. Diese VLANs sind im Trunkmodus auf dem PORT des TOR-Switches konfiguriert. Beim Verbinden neuer VMs mit diesen VLANs wird das entsprechende VLAN-Tag auf dem virtuellen Netzwerkadapter definiert.

HNV Provider Address (PA)-Netzwerk

Das Hyper-V Network Virtualization (HNV)-Anbieteradresse (PA)-Netzwerk dient als zugrunde liegendes physisches Netzwerk für ost-/westinternen Mandantendatenverkehr, Nord-/Süd-Mandantendatenverkehr (extern-intern) und zum Austauschen von BGP-Peeringinformationen mit dem physischen Netzwerk. Dieses Netzwerk ist nur erforderlich, wenn virtuelle Netzwerke mithilfe der VXLAN-Kapselung für eine andere Isolationsebene und für netzwerkübergreifende Mandanten bereitgestellt werden müssen.

Weitere Informationen finden Sie unter Planen einer SDN-Infrastruktur: Verwaltung und HNV-Anbieter.

Optionen für die Netzwerkisolation

Die folgenden Netzwerkisolationsoptionen werden unterstützt:

VLANs (IEEE 802.1Q)

VLANs ermöglichen Es Geräten, die getrennt gehalten werden müssen, um die Verkabelung eines physischen Netzwerks freizugeben und dennoch daran gehindert zu werden, direkt miteinander zu interagieren. Durch diese verwaltete Freigabe werden Einfachheit, Sicherheit, Verkehrsmanagement und Wirtschaft erzielt. Beispielsweise kann ein VLAN verwendet werden, um den Datenverkehr innerhalb eines Unternehmens basierend auf einzelnen Benutzern oder Benutzergruppen oder rollen oder basierend auf den Datenverkehrseigenschaften zu trennen. Viele Internethostingdienste verwenden VLANs, um private Zonen voneinander zu trennen, sodass die Server jedes Kunden in einem einzigen Netzwerksegment gruppiert werden können, unabhängig davon, wo sich die einzelnen Server im Rechenzentrum befinden. Einige Vorsichtsmaßnahmen sind erforderlich, um den Datenverkehr von einem bestimmten VLAN zu verhindern, einem Exploit, der als VLAN-Hopping bezeichnet wird.

Weitere Informationen finden Sie unter "Grundlegendes zur Verwendung virtueller Netzwerke und VLANs".

Standardmäßige Netzwerkzugriffsrichtlinien und Mikrosegmentierung

Standardmäßige Netzwerkzugriffsrichtlinien stellen sicher, dass alle virtuellen Computer (VMs) in Ihrem Azure Stack HCI-Cluster standardmäßig von externen Bedrohungen geschützt sind. Mit diesen Richtlinien blockieren wir standardmäßig den eingehenden Zugriff auf einen virtuellen Computer, während die Möglichkeit gegeben wird, selektive eingehende Ports zu aktivieren und so die VMs vor externen Angriffen zu schützen. Diese Erzwingung ist über Verwaltungstools wie Windows Admin Center verfügbar.

Die Mikrosegmentierung umfasst die Erstellung präziser Netzwerkrichtlinien zwischen Anwendungen und Diensten. Dies reduziert im Wesentlichen den Sicherheitsperimeter auf einen Zaun um jede Anwendung oder VM. Dieser Zaun erlaubt nur die notwendige Kommunikation zwischen Anwendungsstufen oder anderen logischen Grenzen, wodurch es für Cyberthreats äußerst schwierig ist, sich lateral von einem System auf ein anderes auszubreiten. Die Mikrosegmentierung isoliert Netzwerke sicher voneinander und reduziert die gesamte Angriffsfläche eines Netzwerksicherheitsvorfalls.

Standardmäßige Netzwerkzugriffsrichtlinien und Mikrosegmentierung werden als Fünf-Tupel-Zustand (Quelladresspräfix, Quellport, Zieladresspräfix, Zielport und Protokoll)-Firewallregeln für Azure Stack HCI-Cluster realisiert. Firewallregeln werden auch als Netzwerksicherheitsgruppen (Network Security Groups, NSGs) bezeichnet. Diese Richtlinien werden am vSwitch-Port jeder VM erzwungen. Die Richtlinien werden über die Verwaltungsebene übertragen, und der SDN-Netzwerkcontroller verteilt sie an alle anwendbaren Hosts. Diese Richtlinien sind für VMs in herkömmlichen VLAN-Netzwerken und sdN-Überlagerungsnetzwerken verfügbar.

Weitere Informationen finden Sie unter Was ist die Rechenzentrumsfirewall?.  

QoS für VM-Netzwerkadapter

Sie können Quality of Service (QoS) für einen VM-Netzwerkadapter konfigurieren, um die Bandbreite auf einer virtuellen Schnittstelle zu begrenzen, um zu verhindern, dass eine VM mit hohem Datenverkehr mit anderen VM-Netzwerkdatenverkehr zu kämpfen hat. Sie können QoS auch so konfigurieren, dass eine bestimmte Bandbreite für einen virtuellen Computer reserviert wird, um sicherzustellen, dass der virtuelle Computer Unabhängig vom anderen Datenverkehr im Netzwerk Datenverkehr senden kann. Diese Konfiguration kann sowohl auf an herkömmliche VLANs angeschlossene VMs als auch auf an SDN-Überlagerungsnetzwerke angeschlossene VMs angewendet werden.

Weitere Informationen finden Sie unter Konfigurieren von QoS für einen VM-Netzwerkadapter.

Virtuelle Netzwerke

Die Netzwerkvirtualisierung stellt virtuelle Netzwerke für virtuelle Computer bereit, ähnlich wie servervirtualisierung (Hypervisor) VMs für das Betriebssystem bereitstellt. Die Netzwerkvirtualisierung entkoppelt virtuelle Netzwerke von der physischen Netzwerkinfrastruktur und entfernt die Einschränkungen von VLAN und hierarchischer IP-Adresszuweisung von der VM-Bereitstellung. Diese Flexibilität erleichtert Es Ihnen, zu IaaS-Clouds (Infrastructure-as-a-Service) zu wechseln und ist für Hoster und Rechenzentrumsadministratoren effizient, um ihre Infrastruktur zu verwalten und die erforderliche Mehrinstanzenisolation, Sicherheitsanforderungen und überlappende VM-IP-Adressen aufrechtzuerhalten.

Weitere Informationen finden Sie unter Hyper-V-Netzwerkvirtualisierung.

L3-Netzwerkdiensteoptionen

Die folgenden L3-Netzwerkdienstoptionen sind verfügbar:

Peering von virtuellen Netzwerken

Über das Peering virtueller Netzwerke können Sie zwei virtuelle Netzwerke nahtlos verbinden. Nach dem Peering werden die virtuellen Netzwerke zu Konnektivitätszwecken als ein Netzwerk angezeigt. Die Verwendung von VNET-Peering bietet unter anderem folgende Vorteile:

  • Datenverkehr zwischen virtuellen Computern in den virtuellen Peernetzwerken wird nur über die Backbone-Infrastruktur über private IP-Adressen weitergeleitet. Die Kommunikation zwischen den virtuellen Netzwerken erfordert keine öffentlichen Internet- oder Gateways.
  • Niedrige Latenz, Verbindung mit hoher Bandbreite zwischen Ressourcen in unterschiedlichen virtuellen Netzwerken
  • Die Möglichkeit zur Kommunikation für Ressourcen in einem virtuellen Netzwerk mit Ressourcen in einem anderen virtuellen Netzwerk.
  • Keine Downtime für Ressourcen in beiden virtuellen Netzwerken beim Erstellen des Peerings

Weitere Informationen finden Sie unter Peering in virtuellen Netzwerken.

SDN-Softwarelastenausgleich

CloudDienstanbieter (CSPs) und Unternehmen, die Software Defined Networking (SDN) bereitstellen, können Software Load Balancer (SLB) verwenden, um den Kundennetzwerkdatenverkehr gleichmäßig zwischen virtuellen Netzwerkressourcen zu verteilen. SLB ermöglicht es Ihnen, mehrere Server zum Hosten derselben Workload zu aktivieren, um hohe Verfügbarkeit und Skalierbarkeit bereitzustellen. Es wird auch verwendet, um eingehende Nat-Dienste (Network Address Translation) für eingehenden Zugriff auf VMs und ausgehende NAT-Dienste für ausgehende Verbindungen bereitzustellen.

Mithilfe von SLB können Sie Ihre Lastenausgleichsfunktionen mithilfe von SLB-V-Computern auf denselben Hyper-V-Computeservern skalieren, die Sie für Ihre anderen VM-Workloads verwenden. SLB unterstützt die schnelle Erstellung und Löschung von Lastenausgleichsendpunkten nach Bedarf für CSP-Vorgänge. Darüber hinaus unterstützt SLB zehn Gigabyte pro Cluster, bietet ein einfaches Bereitstellungsmodell und ist einfach zu skalieren und ein. Beim SLB wird das Border Gateway Protocol verwendet, um dem physischen Netzwerk virtuelle IP-Adressen anzukündigen.

Weitere Informationen finden Sie unter Was ist SLB für SDN?

SDN-VPN-Gateways

SDN-Gateway ist ein softwarebasierter Border Gateway Protocol (BGP)-fähiger Router, der für CSPs und Unternehmen entwickelt wurde, die virtuelle Multimandantennetzwerke mit Hyper-V-Netzwerkvirtualisierung (HNV) hosten. Sie können RAS-Gateways verwenden, um Netzwerkdatenverkehr zwischen einem virtuellen Netzwerk und einem anderen Netzwerk (lokal oder remote) weiterzuleiten.

DAS SDN-Gateway kann verwendet werden, um:

  • Erstellen sicherer Site-to-Site-IPsec-Verbindungen zwischen virtuellen SDN-Netzwerken und externen Kundennetzwerken über das Internet

  • Erstellen von GRE-Verbindungen (Generic Routing Encapsulation) zwischen virtuellen SDN-Netzwerken und externen Netzwerken. Der Unterschied zwischen Standort-zu-Standort-Verbindungen und GRE-Verbindungen besteht darin, dass letztere keine verschlüsselte Verbindung ist.

    Weitere Informationen zu GRE-Konnektivitätsszenarien finden Sie unter GRE-Tunneling in Windows Server 2016.

  • Erstellen Sie Layer 3 (L3)-Verbindungen zwischen virtuellen SDN-Netzwerken und externen Netzwerken. In diesem Fall fungiert das SDN-Gateway einfach als Router zwischen Ihrem virtuellen Netzwerk und dem externen Netzwerk.

SDN-Gateway erfordert SDN-Netzwerkcontroller. Der Netzwerkcontroller führt die Bereitstellung von Gatewaypools durch, konfiguriert

Nächste Schritte

Erfahren Sie mehr über Muster mit zwei Knoten – Azure Local network deployment patterns.