Wdrażanie sieci
W tym temacie opisano uprawnienia dostępu do przełączników TOR, przypisań adresów IP i innych zadań wdrażania sieci.
Planowanie wdrożenia konfiguracji
W następnych sekcjach omówiono uprawnienia i przypisania adresów IP.
Lista kontroli dostępu przełącznika fizycznego
Aby chronić rozwiązanie Usługi Azure Stack, zaimplementowaliśmy listy kontroli dostępu (ACL) na przełącznikach TOR. W tej sekcji opisano sposób implementacji tych zabezpieczeń. W poniższej tabeli przedstawiono źródła i miejsca docelowe każdej sieci w rozwiązaniu usługi Azure Stack:
Poniższa tabela koreluje odwołania do listy ACL z sieciami usługi Azure Stack.
Sieć | Opis |
---|---|
Wewnętrzny mgmt kontrolera BMC | Ruch jest ograniczony tylko do ruchu wewnętrznego. |
BMC Mgmt External | Lista ACL umożliwia dostęp poza urządzeniem granicznym. |
Rozszerzona funkcja Mgmt magazynu | Dedykowane interfejsy zarządzania dla rozszerzonego systemu magazynowania |
Przełącznik Mgmt | Dedykowane interfejsy zarządzania przełącznikami. |
"Infrastruktura usługi Azure Stack" | Usługi infrastruktury usługi Azure Stack i sieci maszyn wirtualnych z ograniczeniami |
Publiczna infrastruktura usługi Azure Stack (PEP/ERCS) | Chroniony punkt końcowy usługi Azure Stack, serwer konsoli odzyskiwania awaryjnego. Klient może otworzyć listę ACL, aby zezwolić na ruch do sieci zarządzania centrum danych. |
Tor1,Tor2 RouterIP | Interfejs sprzężenia zwrotnego przełącznika używanego do komunikacji równorzędnej BGP między usługą SLB a przełącznikiem/routerem. Klient będzie miał dyskrecję, aby wyłączyć te adresy IP na granicy. |
Storage | Prywatne adresy IP nie są kierowane poza region |
Wewnętrzne adresy VIP | Prywatne adresy IP nie są kierowane poza region |
Publiczne adresy VIP | Przestrzeń adresowa sieci dzierżawy zarządzana przez kontroler sieci. |
Publiczne adresy VIP Administracja | Mały podzbiór adresów w puli dzierżaw, które są wymagane do komunikacji z Internal-VIPs i infrastrukturą usługi Azure Stack |
Dozwolone sieci | Sieć zdefiniowana przez klienta. |
0.0.0.0 | Z perspektywy usługi Azure Stack 0.0.0.0 jest urządzeniem obramowania. |
Zezwolenia | Zezwalaj na ruch jest włączony, ale dostęp SSH jest domyślnie blokowany. |
Brak trasy | Trasy nie są propagowane poza środowiskiem usługi Azure Stack. |
MUX ACL | Są używane listy ACL MUX usługi Azure Stack. |
Nie dotyczy | Nie jest częścią listy ACL sieci VLAN. |
Przypisania adresów IP
W arkuszu wdrażania zostanie wyświetlony monit o podanie następujących adresów sieciowych w celu obsługi procesu wdrażania usługi Azure Stack. Zespół wdrożeniowy używa narzędzia Arkusz wdrażania, aby podzielić sieci IP na wszystkie mniejsze sieci wymagane przez system.
W tym przykładzie wypełnimy kartę Ustawienia sieciowe arkusza wdrażania następującymi wartościami:
Sieć BMC: 10.193.132.0 /27
Sieć magazynu sieci prywatnej & wewnętrznych adresów VIP: 11.11.128.0 /20
Sieć infrastruktury: 12.193.130.0 /24
Sieć publicznych wirtualnych adresów IP (VIP): 13.200.132.0 /24
Przełącz sieć infrastruktury: 10.193.132.128 /26
Po uruchomieniu funkcji Generate narzędzia Arkusz wdrażania tworzy dwie nowe karty w arkuszu kalkulacyjnym. Pierwsza karta to Podsumowanie podsieci i pokazuje, jak zostały podzielone supersieci w celu utworzenia wszystkich sieci wymaganych przez system. W poniższym przykładzie na tej karcie znajduje się tylko podzbiór kolumn. Rzeczywisty wynik zawiera więcej szczegółów każdej sieci na liście:
Stojak | Typ podsieci | Nazwa | Podsieć IPv4 | Adresy IPv4 |
---|---|---|---|---|
Obramowanie | Łącze P2P | P2P_Border/Border1_To_Rack1/TOR1 | 10.193.132.128/30 | 4 |
Obramowanie | Łącze P2P | P2P_Border/Border1_To_Rack1/TOR2 | 10.193.132.132/30 | 4 |
Obramowanie | Łącze P2P | P2P_Border/Border2_To_Rack1/TOR1 | 10.193.132.136/30 | 4 |
Obramowanie | Łącze P2P | P2P_Border/Border2_To_Rack1/TOR2 | 10.193.132.140/30 | 4 |
Obramowanie | Łącze P2P | P2P_Rack1/TOR1_To_Rack1/BMC | 10.193.132.144/30 | 4 |
Obramowanie | Łącze P2P | P2P_Rack1/TOR2_To_Rack1/BMC | 10.193.132.148/30 | 4 |
Stojak1 | Pętla zwrotna (Loopback) | Loopback0_Rack1_TOR1 | 10.193.132.152/32 | 1 |
Stojak1 | Pętla zwrotna (Loopback) | Loopback0_Rack1_TOR2 | 10.193.132.153/32 | 1 |
Stojak1 | Pętla zwrotna (Loopback) | Loopback0_Rack1_BMC | 10.193.132.154/32 | 1 |
Stojak1 | Łącze P2P | P2P_Rack1/TOR1-ibgp-1_To_Rack1/TOR2-ibgp-1 | 10.193.132.156/30 | 4 |
Stojak1 | Łącze P2P | P2P_Rack1/TOR1-ibgp-2_To_Rack1/TOR2-ibgp-2 | 10.193.132.160/30 | 4 |
Stojak1 | Sieci vlan | BMCMgmt | 10.193.132.0/27 | 32 |
Stojak1 | Sieci vlan | SwitchMgmt | 10.193.132.168/29 | 8 |
Stojak1 | Sieci vlan | CL01-RG01-SU01-Storage | 11.11.128.0/25 | 128 |
Stojak1 | Sieci vlan | CL01-RG01-SU01-Infra | 12.193.130.0/24 | 256 |
Stojak1 | Inne | CL01-RG01-SU01-VIPS | 13.200.132.0/24 | 256 |
Stojak1 | Inne | CL01-RG01-SU01-InternalVIPS | 11.11.128.128/25 | 128 |
Druga karta to Użycie adresu IP i pokazuje, jak adresy IP są używane:
Sieć BMC
Supersieć dla sieci BMC wymaga sieci /26 co najmniej. Brama używa pierwszego adresu IP w sieci, a następnie urządzeń BMC w stojaku. Host cyklu życia sprzętu ma wiele adresów przypisanych do tej sieci i może służyć do wdrażania, monitorowania i obsługi stojaka. Te adresy IP są dystrybuowane do 3 grup: DVM, InternalAccessible i ExternalAccessible.
- Stojak: Rack1
- Nazwa: BMCMgmt
Assigned To | Adres IPv4 |
---|---|
Sieć | 10.193.132.0 |
Brama | 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 |
Emisja | 10.193.132.31 |
Sieć magazynu
Sieć magazynu jest siecią prywatną i nie ma być kierowana poza stojak. Jest to pierwsza połowa supersieci sieci prywatnej i jest używana przez przełącznik rozproszony, jak pokazano w poniższej tabeli. Brama jest pierwszym adresem IP w podsieci. Druga połowa używana dla wewnętrznych adresów VIP jest prywatną pulą adresów zarządzanych przez usługę Azure Stack SLB, nie jest wyświetlana na karcie Użycie adresu IP. Te sieci obsługują usługę Azure Stack i istnieją listy ACL na przełącznikach TOR, które uniemożliwiają anonsowane i/lub uzyskiwanie dostępu do tych sieci poza rozwiązaniem.
- Stojak: Stojak1
- Nazwa: CL01-RG01-SU01-Storage
Assigned To | Adres IPv4 |
---|---|
Sieć | 11.11.128.0 |
Brama | 11.11.128.1 |
TOR1 | 11.11.128.2 |
TOR2 | 11.11.128.3 |
Emisja | 11.11.128.127 |
Sieć infrastruktury usługi Azure Stack
Supersieć sieci infrastruktury wymaga sieci /24 i nadal jest to /24 po uruchomieniu narzędzia Arkusz wdrażania. Brama będzie pierwszym adresem IP w podsieci.
- Stojak: Stojak1
- Nazwa: CL01-RG01-SU01-Infra
Assigned To | Adres IPv4 |
---|---|
Sieć | 12.193.130.0 |
Brama | 12.193.130.1 |
TOR1 | 12.193.130.2 |
TOR2 | 12.193.130.3 |
Emisja | 12.193.130.255 |
Przełączanie sieci infrastruktury
Sieć infrastruktury jest podzielona na wiele sieci używanych przez infrastrukturę przełączników fizycznych. Różni się to od infrastruktury usługi Azure Stack, która obsługuje tylko oprogramowanie usługi Azure Stack. Sieć przełącznika infra obsługuje tylko infrastrukturę przełączników fizycznych. Sieci obsługiwane przez infrastrukturę to:
Nazwa | Podsieć IPv4 |
---|---|
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 |
Punkt-punkt (P2P): Te sieci umożliwiają łączność między wszystkimi przełącznikami. Rozmiar podsieci to sieć /30 dla każdego P2P. Najniższy adres IP jest zawsze przypisywany do urządzenia nadrzędnego (Północ) w stosie.
Sprzężenie zwrotne: te adresy to /32 sieci przypisane do każdego przełącznika używanego w stojaku. Urządzenia graniczne nie są przypisane do sprzężenia zwrotnego, ponieważ nie powinny być częścią rozwiązania usługi Azure Stack.
Przełącznik Mgmt lub Switch Management: Ta sieć /29 obsługuje dedykowane interfejsy zarządzania przełączników w stojaku. Adresy IP są przypisane w następujący sposób; tę tabelę można również znaleźć na karcie Użycie adresu IP arkusza wdrażania:
Stojak: Stojak1
Nazwa: SwitchMgmt
Assigned To | Adres IPv4 |
---|---|
Sieć | 10.193.132.168 |
Brama | 10.193.132.169 |
TOR1 | 10.193.132.170 |
TOR2 | 10.193.132.171 |
Emisja | 10.193.132.175 |
Przygotowywanie środowiska
Obraz hosta cyklu życia sprzętu zawiera wymagany kontener systemu Linux używany do generowania konfiguracji przełącznika sieci fizycznej.
Najnowszy zestaw narzędzi wdrażania partnera zawiera najnowszy obraz kontenera. Obraz kontenera na hoście cyklu życia sprzętu można zamienić, gdy konieczne jest wygenerowanie zaktualizowanej konfiguracji przełącznika.
Poniżej przedstawiono kroki aktualizacji obrazu kontenera:
Pobieranie obrazu kontenera
Zastąp obraz kontenera w następującej lokalizacji
Generowanie konfiguracji
W tym miejscu przeprowadzimy Cię przez kroki generowania plików JSON i plików konfiguracji przełącznika sieciowego:
Otwórz arkusz wdrażania
Wypełnij wszystkie wymagane pola na wszystkich kartach
Wywołaj funkcję "Generate" w arkuszu wdrażania.
Zostaną utworzone dwie dodatkowe karty z wygenerowanymi podsieciami IP i przypisaniami.Przejrzyj dane i po potwierdzeniu wywołaj funkcję "Export".
Zostanie wyświetlony monit o podanie folderu, w którym zostaną zapisane pliki JSON.Wykonaj kontener przy użyciu Invoke-SwitchConfigGenerator.ps1. Ten skrypt wymaga wykonania konsoli programu PowerShell z podwyższonym poziomem uprawnień i wymaga wykonania następujących parametrów.
ContainerName — nazwa kontenera, który wygeneruje konfiguracje przełącznika.
ConfigurationData — ścieżka do pliku ConfigurationData.json wyeksportowanego z arkusza wdrażania.
OutputDirectory — ścieżka do katalogu wyjściowego.
Offline — sygnały, że skrypt działa w trybie offline.
C:\WINDOWS\system32> .\Invoke-SwitchConfigGenerate.ps1 -ContainerName generalonrampacr.azurecr.io/master -ConfigurationData .\ConfigurationData.json -OutputDirectory c:\temp -Offline
Po zakończeniu działania skryptu utworzy plik zip z prefiksem używanym w arkuszu.
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}
Konfiguracja niestandardowa
Możesz zmodyfikować kilka ustawień środowiskowych dla konfiguracji przełącznika usługi Azure Stack. Możesz określić, które ustawienia można zmienić w szablonie. W tym artykule opisano każde z tych ustawień dostosowywalnych oraz sposób, w jaki zmiany mogą mieć wpływ na usługę Azure Stack. Te ustawienia obejmują aktualizację haseł, serwer dziennika systemu, monitorowanie SNMP, uwierzytelnianie i listę kontroli dostępu.
Podczas wdrażania rozwiązania Usługi Azure Stack producent oryginalnego sprzętu (OEM) tworzy i stosuje konfigurację przełącznika zarówno dla reguł ściągnięcia, jak i kontrolera BMC. OEM używa narzędzia automatyzacji usługi Azure Stack, aby sprawdzić, czy wymagane konfiguracje są prawidłowo ustawione na tych urządzeniach. Konfiguracja jest oparta na informacjach w arkuszu wdrażania usługi Azure Stack.
Uwaga
Nie zmieniaj konfiguracji bez zgody od producenta OEM lub zespołu inżynierów usługi Microsoft Azure Stack. Zmiana konfiguracji urządzenia sieciowego może znacząco wpłynąć na operację lub rozwiązywanie problemów z siecią w wystąpieniu usługi Azure Stack. Aby uzyskać więcej informacji o tych funkcjach na urządzeniu sieciowym, sposobie wprowadzania tych zmian, skontaktuj się z dostawcą sprzętu OEM lub pomocą techniczną firmy Microsoft. OEM zawiera plik konfiguracji utworzony przez narzędzie automatyzacji na podstawie arkusza wdrażania usługi Azure Stack.
Istnieją jednak pewne wartości, które można dodać, usunąć lub zmienić w konfiguracji przełączników sieciowych.
Aktualizacja hasła
Operator może w dowolnym momencie zaktualizować hasło dla dowolnego użytkownika w przełącznikach sieciowych. Nie trzeba zmieniać żadnych informacji w systemie usługi Azure Stack ani użyć kroków dotyczących rotacji wpisów tajnych w usłudze Azure Stack.
Serwer Syslog
Operatorzy mogą przekierowywać dzienniki przełączników do serwera dziennika systemu w centrum danych. Użyj tej konfiguracji, aby upewnić się, że dzienniki z określonego punktu w czasie mogą być używane do rozwiązywania problemów. Domyślnie dzienniki są przechowywane na przełącznikach; ich pojemność do przechowywania dzienników jest ograniczona. Zapoznaj się z sekcją Aktualizacje listy kontroli dostępu, aby zapoznać się z omówieniem konfigurowania uprawnień dostępu do zarządzania przełącznikami.
Monitorowanie protokołu SNMP
Operator może skonfigurować prosty protokół zarządzania siecią (SNMP) w wersji 2 lub 3, aby monitorować urządzenia sieciowe i wysyłać pułapki do aplikacji monitorowania sieci w centrum danych. Ze względów bezpieczeństwa należy użyć protokołu SNMPv3, ponieważ jest ona bezpieczniejsza niż wersja 2. Zapoznaj się z dostawcą sprzętu OEM pod kątem wymaganych mib i konfiguracji. Zapoznaj się z sekcją Aktualizacje listy kontroli dostępu, aby zapoznać się z omówieniem konfigurowania uprawnień dostępu do zarządzania przełącznikami.
Authentication
Operator może skonfigurować usługę RADIUS lub TACACS do zarządzania uwierzytelnianiem na urządzeniach sieciowych. Zapoznaj się z dostawcą sprzętu OEM, aby uzyskać obsługiwane metody i wymaganą konfigurację. Zapoznaj się z sekcją Aktualizacje listy kontroli dostępu, aby zapoznać się z omówieniem sposobu konfigurowania uprawnień dostępu do zarządzania przełącznikami.
Aktualizacje listy kontroli dostępu
Operator może zmienić niektóre listy kontroli dostępu (ACL), aby umożliwić dostęp do interfejsów zarządzania urządzeniami sieciowymi i hosta cyklu życia sprzętu (HLH) z zaufanego zakresu sieci centrum danych. Operator może wybrać, który składnik będzie dostępny i skąd. Za pomocą listy kontroli dostępu operator może zezwolić na zarządzanie maszynami wirtualnymi przesiadkowymi w określonym zakresie sieci w celu uzyskania dostępu do interfejsu zarządzania przełącznikiem oraz systemu HLH OS i HLH BMC.
Aby uzyskać więcej informacji, zobacz Lista kontroli dostępu przełącznika fizycznego.
TACACS, RADIUS i Syslog
Rozwiązanie Usługi Azure Stack nie zostanie dostarczone z rozwiązaniem TACACS lub RADIUS do kontroli dostępu urządzeń, takich jak przełączniki i routery, ani rozwiązanie Syslog do przechwytywania dzienników przełączników, ale wszystkie te urządzenia obsługują te usługi. Aby ułatwić integrację z istniejącym serwerem TACACS, RADIUS i/lub Syslog w Twoim środowisku, udostępnimy dodatkowy plik z konfiguracją przełącznika sieciowego, który umożliwi inżynierowi dostosowanie przełącznika do potrzeb klienta.
Następne kroki
Opinia
https://aka.ms/ContentUserFeedback.
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla