Netzwerkbereitstellung für Azure Stack Hub Ruggedized
In diesem Thema werden die Zugriffsberechtigung für die ToR-Switches, IP-Adresszuweisungen und andere Netzwerkbereitstellungsaufgaben behandelt.
Planen der Konfigurationsbereitstellung
In den nächsten Abschnitten werden Berechtigungen und IP-Adresszuweisungen behandelt.
Zugriffssteuerungsliste für den physischen Switch
Zum Schutz der Azure Stack-Lösung haben wir auf den ToR-Switches Zugriffssteuerungslisten (Access Control Lists, ACLs) implementiert. In diesem Abschnitt wird die Implementierung dieser Sicherheit beschrieben. Die folgende Tabelle enthält die Quellen und Ziele jedes Netzwerks innerhalb der Azure Stack-Lösung:
In der folgenden Tabelle werden die Verweisbezeichnungen aus den ACLs den Azure Stack-Netzwerken gegenübergestellt.
| BMC Mgmt | IP-Adressen von Bereitstellungs-VM, BMC-Schnittstelle, HLH-Server, NTP-Server und DNS-Server sind auf Grundlage von Protokoll und Port als zulässig enthalten. |
|---|---|
| HLH Internal Accessible (PDU) | Datenverkehr ist auf den BMC-Switch beschränkt |
| HLH External Accessible (OEM Tool VM) | Die ACL ermöglicht den Zugriff auf über das Grenzgerät hinaus. |
| Switch Mgmt | Dedizierte Verwaltungsschnittstellen für den Switch |
| Spine Mgmt | Dedizierte Verwaltungsschnittstellen für Spine |
| Azure Stack | Azure Stack-Infrastrukturdienste und VMs, eingeschränktes Netzwerk |
| Infrastruktur | |
| Azure Stack | Geschützter Azure Stack-Endpunkt, Konsolenserver für die Notfallwiederherstellung |
| Infrastruktur | |
| Public (PEP/ERCS) | |
| Tor1, Tor2 RouterIP | Die Loopback-Schnittstelle am Switch für das BGP-Peering zwischen SLB und Switch/Router. |
| Storage | Private IP-Adressen, die nicht außerhalb der Region weitergeleitet werden |
| Internal VIPs | Private IP-Adressen, die nicht außerhalb der Region weitergeleitet werden |
| Public-VIPs | Vom Netzwerkcontroller verwalteter Netzwerkadressraum des Mandanten. |
| Public-Admin-VIPs | Kleine Teilmenge der Adressen im Mandantenpool, die für die Kommunikation mit internen VIPs und der Azure Stack-Infrastruktur erforderlich sind |
| Kunde/Internet | Vom Kunden definiertes Netzwerk. Aus Sicht von Azure Stack ist „0.0.0.0“ das Grenzgerät. |
| 0.0.0.0 | |
| Deny (Verweigern) | Der Kunde hat die Möglichkeit, dieses Feld so zu aktualisieren, dass zusätzliche Netzwerke zugelassen werden, um Verwaltungsfunktionen zu aktivieren. |
| Permit | Das Zulassen des Datenverkehrs ist aktiviert, aber SSH-Zugriff ist standardmäßig deaktiviert. Der Kunde hat die Möglichkeit, den SSH-Dienst zu aktivieren. |
| No Route | Routen werden nicht außerhalb der Azure Stack-Umgebung weitergegeben. |
| MUX ACL | Azure Stack-MUX-ACLs werden verwendet. |
| N/V | Nicht Teil einer VLAN-ACL. |
IP-Adresszuweisungen
Sie werden im Bereitstellungsarbeitsblatt aufgefordert, die folgenden Netzwerkadressen anzugeben, um den Azure Stack-Bereitstellungsprozess zu unterstützen. Das Bereitstellungsteam verwendet das Bereitstellungsarbeitsblatt, um die IP-Netzwerke in die kleineren vom System benötigten Netzwerke aufzuteilen. Ausführliche Beschreibungen zu den einzelnen Netzwerken finden Sie im Abschnitt „Netzwerkentwurf und -infrastruktur“ weiter oben.
In diesem Beispiel füllen Sie die Registerkarte „Netzwerkeinstellungen“ des Bereitstellungsarbeitsblatts mit den folgenden Werten aus:
BMC-Netzwerk: 10.193.132.0 /27
Privates Netzwerk für den Netzwerkspeicher und interne VIPs: 11.11.128.0 /24
Infrastrukturnetzwerk: 12.193.130.0 /24
Öffentliche virtuelle IP-Adresse (VIP) des Netzwerks: 13.200.132.0 /24
Switchinfrastrukturnetzwerk: 10.193.132.128 /26
Wenn Sie die Funktion „Generieren“ im Bereitstellungsarbeitsblatt ausführen, werden in der Tabelle zwei neue Registerkarten erstellt. Die erste Registerkarte enthält die Subnetzzusammenfassung und zeigt, wie die übergeordneten Netzwerke aufgeteilt wurden, um alle vom System benötigten Netzwerke zu erstellen. In Beispiel unten enthält diese Registerkarte nur einen Teil der Spalten. Das tatsächliche Ergebnis enthält mehr Details zu jedem aufgelisteten Netzwerk:
| Rack | Subnetztyp | Name | IPv4-Subnetz | IPv4-Adressen |
|---|---|---|---|---|
| Rahmen | P2P-Link | P2P_Border/Border1_To_Rack1/TOR1 | 10.193.132.128/30 | 4 |
| Rahmen | P2P-Link | P2P_Border/Border1_To_Rack1/TOR2 | 10.193.132.132/30 | 4 |
| Rahmen | P2P-Link | P2P_Border/Border2_To_Rack1/TOR1 | 10.193.132.136/30 | 4 |
| Rahmen | P2P-Link | P2P_Border/Border2_To_Rack1/TOR2 | 10.193.132.140/30 | 4 |
| Rahmen | P2P-Link | P2P_Rack1/TOR1_To_Rack1/BMC | 10.193.132.144/30 | 4 |
| Rahmen | P2P-Link | P2P_Rack1/TOR2_To_Rack1/BMC | 10.193.132.148/30 | 4 |
| Rack1 | Loopback | Loopback0_Rack1_TOR1 | 10.193.132.152/32 | 1 |
| Rack1 | Loopback | Loopback0_Rack1_TOR2 | 10.193.132.153/32 | 1 |
| Rack1 | Loopback | Loopback0_Rack1_BMC | 10.193.132.154/32 | 1 |
| Rack1 | P2P-Link | P2P_Rack1/TOR1-ibgp-1_To_Rack1/TOR2-ibgp-1 | 10.193.132.156/30 | 4 |
| Rack1 | P2P-Link | P2P_Rack1/TOR1-ibgp-2_To_Rack1/TOR2-ibgp-2 | 10.193.132.160/30 | 4 |
| Rack1 | VLAN | BMCMgmt | 10.193.132.0/27 | 32 |
| Rack1 | VLAN | SwitchMgmt | 10.193.132.168/29 | 8 |
| Rack1 | VLAN | CL01-RG01-SU01-Storage | 11.11.128.0/25 | 128 |
| Rack1 | VLAN | CL01-RG01-SU01-Infra | 12.193.130.0/24 | 256 |
| Rack1 | Sonstiges | CL01-RG01-SU01-VIPS | 13.200.132.0/24 | 256 |
| Rack1 | Sonstiges | CL01-RG01-SU01-InternalVIPS | 11.11.128.128/25 | 128 |
Die zweite Registerkarte mit der IP-Adressnutzung zeigt, wie die IP-Adressen verwendet werden:
BMC-Netzwerk
Für das übergeordnete Netzwerk des BMC-Netzwerks ist mindestens ein Netzwerk der Größe /26 erforderlich. Das Gateway verwendet die erste IP-Adresse im Netzwerk, gefolgt von den BMC-Geräten im Rack. Dem HLH (Hardware Lifecycle Host) sind mehrere Adressen in diesem Netzwerk zugewiesen, die zum Bereitstellen, Überwachen und Warten des Racks verwendet werden können. Diese IP-Adressen sind in drei Gruppen unterteilt: DVM, InternalAccessible und ExternalAccessible.
- Rack: Rack1
- Name: BMCMgmt
| Zugewiesen zu | IPv4-Adresse |
|---|---|
| Netzwerk | 10.193.132.0 |
| Gateway | 10.193.132.1 |
| HLH-BMC | 10.193.132.2 |
| AzS-Node01 | 10.193.132.3 |
| AzS-Node02 | 10.193.132.4 |
| AzS-Node03 | 10.193.132.5 |
| AzS-Node04 | 10.193.132.6 |
| ExternalAccessible-1 | 10.193.132.19 |
| ExternalAccessible-2 | 10.193.132.20 |
| ExternalAccessible-3 | 10.193.132.21 |
| ExternalAccessible-4 | 10.193.132.22 |
| ExternalAccessible-5 | 10.193.132.23 |
| InternalAccessible-1 | 10.193.132.24 |
| InternalAccessible-2 | 10.193.132.25 |
| InternalAccessible-3 | 10.193.132.26 |
| InternalAccessible-4 | 10.193.132.27 |
| InternalAccessible-5 | 10.193.132.28 |
| CL01-RG01-SU01-DVM00 | 10.193.132.29 |
| HLH-OS | 10.193.132.30 |
| Übertragen | 10.193.132.31 |
Speichernetzwerk
Das Speichernetzwerk ist ein privates Netzwerk, das nicht über das Rack hinaus weitergeleitet werden sollte. Es umfasst die erste Hälfte des übergeordneten privaten Netzwerks und wird vom Switch wie in der folgenden Tabelle gezeigt verteilt. Der Gateway entspricht der ersten IP-Adresse im Subnetz. Die zweite Hälfte wird für die internen VIPs verwendet. Sie bildet einen privaten Adresspool, der vom Azure Stack-SLB verwaltet und daher auf der Registerkarte mit der IP-Adressnutzung nicht angezeigt wird. Diese Netzwerke dienen zur Unterstützung von Azure Stack. ACLs auf den ToR-Switches verhindern, dass diese Netzwerke angekündigt werden oder dass von außerhalb der Lösung darauf zugegriffen werden kann.
- Rack: Rack1
- Name: CL01-RG01-SU01-Storage
| Zugewiesen zu | IPv4-Adresse |
|---|---|
| Netzwerk | 11.11.128.0 |
| Gateway | 11.11.128.1 |
| TOR1 | 11.11.128.2 |
| TOR2 | 11.11.128.3 |
| Übertragen | 11.11.128.127 |
Azure Stack-Infrastrukturnetzwerk
Das übergeordnete Infrastrukturnetzwerk erfordert ein Netzwerk der Größe /24, das auch nach dem Ausführen des Bereitstellungsarbeitsblatts die Größe /24 beibehält. Das Gateway erhält die erste IP-Adresse im Subnetz.
- Rack: Rack1
- Name: CL01-RG01-SU01-Infra
| Zugewiesen zu | IPv4-Adresse |
|---|---|
| Netzwerk | 12.193.130.0 |
| Gateway | 12.193.130.1 |
| TOR1 | 12.193.130.2 |
| TOR2 | 12.193.130.3 |
| Übertragen | 12.193.130.255 |
Switchinfrastrukturnetzwerk
Das Infrastrukturnetzwerk ist in mehrere Netzwerke aufgeteilt, die von der physischen Switchinfrastruktur verwendet werden. Diese unterscheidet sich von der Azure Stack-Infrastruktur, die nur die Azure Stack-Software unterstützt. Das Netzwerk für die Switchinfrastruktur unterstützt ausschließlich die physische Switchinfrastruktur. Folgende Netzwerke werden von der Infrastruktur unterstützt:
| Name | IPv4-Subnetz |
|---|---|
| P2P_Border/Border1_To_Rack1/TOR1 | 10.193.132.128/30 |
| P2P_Border/Border1_To_Rack1/TOR2 | 10.193.132.132/30 |
| P2P_Border/Border2_To_Rack1/TOR1 | 10.193.132.136/30 |
| P2P_Border/Border2_To_Rack1/TOR2 | 10.193.132.140/30 |
| P2P_Rack1/TOR1_To_Rack1/BMC | 10.193.132.144/30 |
| P2P_Rack1/TOR2_To_Rack1/BMC | 10.193.132.148/30 |
| Loopback0_Rack1_TOR1 | 10.193.132.152/32 |
| Loopback0_Rack1_TOR2 | 10.193.132.153/32 |
| Loopback0_Rack1_BMC | 10.193.132.154/32 |
| P2P_Rack1/TOR1-ibgp-1_To_Rack1/TOR2-ibgp-1 | 10.193.132.156/30 |
| P2P_Rack1/TOR1-ibgp-2_To_Rack1/TOR2-ibgp-2 | 10.193.132.160/30 |
| SwitchMgmt | 10.193.132.168/29 |
Point-to-Point (P2P): Diese Netzwerke ermöglichen Konnektivität zwischen allen Switches. Die Subnetzgröße lautet für jede P2P-Verbindung /30. Die niedrigste IP-Adresse wird immer dem Upstreamgerät (Norden) im Stapel zugewiesen.
Loopback: Bei diesen Adressen handelt es sich um Netzwerke der Größe /32, die jedem im Rack verwendeten Switch zugewiesen werden. Den Grenzgeräten wird kein Loopback zugewiesen, da sie keinen Teil der Azure Stack-Lösung darstellen.
Switchverwaltung (Switch Mgmt): Dieses Netzwerk der Größe /29 unterstützt die dedizierten Verwaltungsschnittstellen der Switches im Rack. Die IP-Adressen werden wie in der folgenden Tabelle gezeigt zugewiesen. Sie finden diese Tabelle auch auf der Registerkarte zur IP-Adressnutzung im Bereitstellungsarbeitsblatt:
Rack: Rack1
Name: SwitchMgmt
| Zugewiesen zu | IPv4-Adresse |
|---|---|
| Netzwerk | 10.193.132.168 |
| Gateway | 10.193.132.169 |
| TOR1 | 10.193.132.170 |
| TOR2 | 10.193.132.171 |
| Übertragen | 10.193.132.175 |
Vorbereiten der Umgebung
Das HLH-Image (Hardware Lifecycle Host) enthält den erforderlichen Linux-Container zum Generieren der Konfiguration für den physischen Netzwerkswitch.
Das aktuelle Toolkit für Partnerbereitstellungen umfasst das neueste Containerimage. Das Containerimage auf dem HLH (Hardware Lifecycle Host) kann ersetzt werden, wenn eine aktualisierte Switchkonfiguration generiert werden soll.
Im Folgenden finden Sie die Schritte zum Aktualisieren des Containerimages:
Herunterladen des Containerimages
Ersetzen des Containerimages am folgenden Speicherort
Generieren der Konfiguration
Im Folgenden finden Sie die Schritte zum Erstellen der JSON-Dateien und der Konfigurationsdateien für den Netzwerkswitch:
Öffnen des Bereitstellungsarbeitsblatts
Ausfüllen aller erforderlichen Felder auf allen Registerkarten
Aufrufen der Funktion „Generieren“ im Bereitstellungsarbeitsblatt.
Es werden zwei zusätzliche Registerkarten erstellt, auf denen die generierten IP-Subnetze und -Zuweisungen angezeigt werden.Überprüfen der Daten und nach der Bestätigung Aufrufen der Funktion „Exportieren“.
Sie werden aufgefordert, einen Ordner anzugeben, in dem die JSON-Dateien gespeichert werden.Ausführen des Containers mithilfe von „Invoke-SwitchConfigGenerator.ps1“. Für dieses Skript muss eine PowerShell-Konsole mit erhöhten Rechten ausgeführt werden. Außerdem müssen bei der Ausführung die folgenden Parameter angegeben werden.
ContainerName: Name des Containers, der die Switchkonfigurationen generiert
ConfigurationData: Pfad zur Datei „ConfigurationData.json“, die aus dem Bereitstellungsarbeitsblatt exportiert wurde
OutputDirectory: Pfad zum Ausgabeverzeichnis
Offline: signalisiert, dass das Skript im Offlinemodus ausgeführt wird
C:\\WINDOWS\\system32\> .\\Invoke-SwitchConfigGenerate.ps1 -ContainerName generalonrampacr.azurecr.io/master -ConfigurationData .\\ConfigurationData.json -OutputDirectory c:\\temp -Offline
Wenn das Skript abgeschlossen wurde, erstellt es eine ZIP-Datei mit dem im Arbeitsblatt verwendeten Präfix.
C:\WINDOWS\system32> .\Invoke-SwitchConfigGenerate.ps1 -ContainerName generalonrampacr.azurecr.io/master -ConfigurationData .\ConfigurationData.json -OutputDirectory c:\temp -Offline
Seconds : 2
Section : Validation
Step : WindowsRequirement
Status : True
Detail : @{CurrentImage=10.0.18363.0}
Seconds : 2
Section : Validation
Step : DockerService
Status : True
Detail : @{Status=Running}
Seconds : 9
Section : Validation
Step : DockerSetup
Status : True
Detail : @{CPU=4; Memory=4139085824; OS=Docker Desktop; OSType=linux}
Seconds : 9
Section : Validation
Step : DockerImage
Status : True
Detail : @{Container=generalonrampacr.azurecr.io/master:1.1910.78.1}
Seconds : 10
Section : Run
Step : Container
Status : True
Detail : @{ID=2a20ba622ef9f58f9bcd069c3b9af7ec076bae36f12c5653f9469b988c01706c; ExternalPort=32768}
Seconds : 38
Section : Generate
Step : Config
Status : True
Detail : @{OutputFile=c:\temp\N22R19.zip}
Seconds : 38
Section : Exit
Step : StopContainer
Status : True
Detail : @{ID=2a20ba622ef9f58f9bcd069c3b9af7ec076bae36f12c5653f9469b988c01706c}
Benutzerdefinierte Konfiguration
Sie können einige Umgebungseinstellungen für Ihre Azure Stack-Switchkonfiguration ändern. Sie können ermitteln, welche der Einstellungen Sie in der Vorlage ändern können. In diesem Artikel werden die einzelnen anpassbaren Einstellungen beschrieben. Zudem wird erläutert, wie sich die Änderungen auf Azure Stack auswirken können. Zu diesen Einstellungen gehören die Aktualisierung von Kennwörtern, Syslog-Server, SNMP-Überwachung, Authentifizierung und die Zugriffssteuerungsliste.
Während der Bereitstellung der Azure Stack-Lösung erstellt der Originalgerätehersteller (Original Equipment Manufacturer, OEM) die Switchkonfiguration sowohl für TOR-Instanzen als auch für BMC. Der OEM verwendet das Azure Stack-Automatisierungstool, um zu überprüfen, ob die erforderlichen Konfigurationen auf diesen Geräten ordnungsgemäß festgelegt sind. Die Konfigurationen basieren auf den Informationen in Ihrem Bereitstellungsarbeitsblatt für Azure Stack.
Hinweis
Ändern Sie die Konfiguration nicht ohne Zustimmung des OEM oder des Microsoft Azure Stack-Technikteams. Eine Änderung an der Netzwerkgerätekonfiguration kann sich erheblich auf den Betrieb oder die Behebung von Netzwerkproblemen in ihrer Azure Stack-Instanz auswirken. Weitere Informationen zu diesen Funktionen in Ihrem Netzwerkgerät und dazu, wie diese Änderungen vorgenommen werden, erhalten Sie bei Ihrem OEM-Hardwareanbieter oder beim Microsoft-Support. Der OEM hat die Konfigurationsdatei mithilfe des Automatisierungstools auf der Grundlage Ihres Bereitstellungsarbeitsblatts für Azure Stack erstellt.
Es gibt jedoch einige Werte, die in der Konfiguration der Netzwerkswitches hinzugefügt, entfernt oder geändert werden können.
Aktualisieren von Kennwörtern
Der Operator kann das Kennwort jedes Benutzers auf den Netzwerkswitches jederzeit aktualisieren. Es ist nicht erforderlich, Informationen im Azure Stack-System zu ändern oder die Schritte zum Rotieren von Geheimnissen in Azure Stack auszuführen.
Syslog-Server
Operatoren können die Switchprotokolle an einen Syslog-Server in Ihrem Datencenter umleiten. Stellen Sie mit dieser Konfiguration sicher, dass die Protokolle für einen bestimmten Zeitpunkt für die Problembehandlung verwendet werden können. In der Standardeinstellung werden die Protokolle auf den Switches gespeichert. Deren Kapazität zum Speichern von Protokollen ist jedoch beschränkt. Im Abschnitt Aktualisierungen von Zugriffssteuerungslisten finden Sie eine Übersicht dazu, wie die Berechtigungen für den Verwaltungszugriff auf Switches konfiguriert werden.
SNMP-Überwachung
Der Operator kann das Simple Network Management Protocol (SNMP) v2 oder v3 konfigurieren, um die Netzwerkgeräte zu überwachen und Traps an eine Netzwerküberwachungsanwendung im Datencenter zu senden. Verwenden Sie aus Sicherheitsgründen SNMPv3, da es höhere Sicherheit als v2 bietet. Informationen zu den MIBs und der erforderlichen Konfiguration erhalten Sie bei Ihrem OEM-Hardwareanbieter. Im Abschnitt Aktualisierungen von Zugriffssteuerungslisten finden Sie eine Übersicht dazu, wie die Berechtigungen für den Verwaltungszugriff auf Switches konfiguriert werden.
Authentifizierung
Der Operator kann entweder RADIUS oder TACACS konfigurieren, um die Authentifizierung auf den Netzwerkgeräten zu verwalten. Informationen zu den unterstützten Methoden und der erforderlichen Konfiguration erhalten Sie bei Ihrem OEM-Hardwareanbieter. Im Abschnitt Aktualisierungen von Zugriffssteuerungslisten finden Sie eine Übersicht dazu, wie die Berechtigungen für den Verwaltungszugriff auf Switches konfiguriert werden.
Aktualisierungen von Zugriffssteuerungslisten
Der Operator kann einige Zugriffssteuerungslisten (ACLs) so ändern, dass der Zugriff auf Verwaltungsschnittstellen für Netzwerkgeräte und den Hardwarelebenszyklus-Host (HLH) von einem Netzwerkbereich vertrauenswürdiger Datencenter gestattet wird. Der Operator kann auswählen, welche Komponente von welchem Ort aus zugänglich ist. Mithilfe der Zugriffssteuerungsliste kann der Operator seinen Jumpbox-VMs für die Verwaltung innerhalb eines bestimmten Netzwerkbereichs den Zugriff auf die Schnittstelle für die Switch-Verwaltung, das HLH-Betriebssystem und den HLH-BMC gewähren.
Weitere Informationen finden Sie unter Zugriffssteuerungsliste für den physischen Switch.
TACACS, RADIUS und Syslog
Die Azure Stack-Lösung wird nicht mit einer TACACS- oder RADIUS-Lösung für die Zugriffssteuerung von Geräten wie Switches und Routern ausgeliefert. Sie umfasst auch keine Syslog-Lösung zum Erfassen von Switchprotokollen. Allerdings unterstützen alle Geräte diese Dienste. Zur Unterstützung der Integration eines vorhandenen TACACS-, RADIUS- oder Syslog-Servers in Ihrer Umgebung wird eine zusätzliche Datei mit der Konfiguration für den Netzwerkswitch bereitgestellt, die es dem Techniker vor Ort ermöglicht, den Switch an die Anforderungen des Kunden anzupassen.
Nächste Schritte
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für