Implementação de rede
Este tópico aborda a permissão de acesso aos comutadores TOR, atribuições de endereços IP e outras tarefas de implementação de rede.
Planear a implementação da configuração
As secções seguintes abrangem permissões e atribuições de endereços IP.
Lista de controlo de acesso do comutador físico
Para proteger a solução do Azure Stack, implementámos listas de controlo de acesso (ACLs) nos comutadores TOR. Esta secção descreve como esta segurança é implementada. A tabela abaixo mostra as origens e destinos de cada rede dentro da solução do Azure Stack:
A tabela abaixo correlaciona as referências da ACL com as redes do Azure Stack.
| Rede | Description |
|---|---|
| BMC Mgmt Internal | O tráfego está limitado apenas a interno. |
| BMC Mgmt External | A ACL permite o acesso para além do dispositivo de limite. |
| Mgmt de Armazenamento Alargado | Interfaces de gestão dedicadas para o sistema de armazenamento alargado |
| Switch Mgmt | Interfaces de gestão dedicadas do Comutador. |
| "Infraestrutura do Azure Stack" | Serviços de Infraestrutura do Azure Stack e VMs, rede restrita |
| Infraestrutura Pública do Azure Stack (PEP/ERCS) | Ponto Final Protegido do Azure Stack, Servidor da Consola de Recuperação de Emergência. O cliente pode abrir a ACL para permitir o tráfego para a respetiva rede de gestão de datacenters. |
| Tor1,Tor2 RouterIP | Interface de loopback do comutador utilizado para peering BGP entre o SLB e o Comutador/Router. O cliente terá a discrição de firewall fora destes IPs no limite. |
| Armazenamento | IPs privados não encaminhados para fora da Região |
| VIPs internos | IPs privados não encaminhados para fora da Região |
| VIPs Públicos | Espaço de endereços de rede do inquilino gerido pelo controlador de rede. |
| VIPs de Administração Público | Pequeno subconjunto de endereços no Conjunto de inquilinos que são necessários para comunicar com o Internal-VIPs e a Infraestrutura do Azure Stack |
| Redes Permitidas | Rede definida pelo cliente. |
| 0.0.0.0 | Do ponto de vista do Azure Stack 0.0.0.0 é o dispositivo de limite. |
| Permitir | Permitir tráfego está ativado, mas o acesso SSH está bloqueado por predefinição. |
| Sem Rota | As rotas não são propagadas fora do ambiente do Azure Stack. |
| MUX ACL | As ACLs do MUX do Azure Stack são utilizadas. |
| N/D | Não faz parte de uma ACL de VLAN. |
Atribuições de endereços IP
Na Folha de Cálculo de Implementação, é-lhe pedido que forneça os seguintes endereços de rede para suportar o processo de implementação do Azure Stack. A equipa de implementação utiliza a ferramenta Folha de Cálculo de Implementação para dividir as redes IP em todas as redes mais pequenas exigidas pelo sistema.
Neste exemplo, iremos preencher o separador Definições de Rede da Folha de Cálculo de Implementação com os seguintes valores:
Rede BMC: 10.193.132.0 /27
Rede de Armazenamento de Rede Privada & VIPs Internos: 11.11.128.0 /20
Rede de Infraestrutura: 12.193.130.0 /24
Rede DE IP Virtual Público (VIP): 13.200.132.0 /24
Rede de Infraestrutura de Comutador: 10.193.132.128 /26
Quando executa a função Gerar da ferramenta Folha de Cálculo de Implementação, esta cria dois novos separadores na folha de cálculo. O primeiro separador é o Resumo da Sub-rede e mostra como as super-redes foram divididas para criar todas as redes necessárias para o sistema. No nosso exemplo abaixo, existe apenas um subconjunto das colunas encontradas neste separador. O resultado real tem mais detalhes de cada rede listada:
| Rack | Tipo de Sub-rede | Nome | Sub-rede IPv4 | Endereços IPv4 |
|---|---|---|---|---|
| Limite | Ligação P2P | P2P_Border/Border1_To_Rack1/TOR1 | 10.193.132.128/30 | 4 |
| Limite | Ligação P2P | P2P_Border/Border1_To_Rack1/TOR2 | 10.193.132.132/30 | 4 |
| Limite | Ligação P2P | P2P_Border/Border2_To_Rack1/TOR1 | 10.193.132.136/30 | 4 |
| Limite | Ligação P2P | P2P_Border/Border2_To_Rack1/TOR2 | 10.193.132.140/30 | 4 |
| Limite | Ligação P2P | P2P_Rack1/TOR1_To_Rack1/BMC | 10.193.132.144/30 | 4 |
| Limite | Ligação P2P | 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 | Ligação P2P | P2P_Rack1/TOR1-ibgp-1_To_Rack1/TOR2-ibgp-1 | 10.193.132.156/30 | 4 |
| Rack1 | Ligação P2P | 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 | Outro | CL01-RG01-SU01-VIPS | 13.200.132.0/24 | 256 |
| Rack1 | Outro | CL01-RG01-SU01-InternalVIPS | 11.11.128.128/25 | 128 |
O segundo separador é Utilização de Endereços IP e mostra como os IPs são consumidos:
Rede BMC
A super-rede para a rede BMC requer, no mínimo, uma rede /26. O gateway utiliza o primeiro IP na rede seguido dos dispositivos BMC no rack. O anfitrião do ciclo de vida do hardware tem vários endereços atribuídos nesta rede e pode ser utilizado para implementar, monitorizar e suportar o rack. Estes IPs são distribuídos em três grupos: DVM, InternalAccessible e ExternalAccessible.
- Rack: Rack1
- Nome: BMCMgmt
| Atribuído a | Endereço IPv4 |
|---|---|
| Rede | 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 |
| Difusão | 10.193.132.31 |
Rede de armazenamento
A rede de Armazenamento é uma rede privada e não se destina a ser encaminhada para além do rack. É a primeira metade da super-rede da Rede Privada e é utilizada pelo comutador distribuído, conforme mostrado na tabela abaixo. O gateway é o primeiro IP na sub-rede. A segunda metade utilizada para os VIPs Internos é um conjunto privado de endereços gerido pelo SLB do Azure Stack, que não é apresentado no separador Utilização de Endereços IP. Estas redes suportam o Azure Stack e existem ACLs nos comutadores TOR que impedem que estas redes sejam anunciadas e/ou acedidas fora da solução.
- Rack: Rack1
- Nome: CL01-RG01-SU01-Storage
| Atribuído a | Endereço IPv4 |
|---|---|
| Rede | 11.11.128.0 |
| Gateway | 11.11.128.1 |
| TOR1 | 11.11.128.2 |
| TOR2 | 11.11.128.3 |
| Difusão | 11.11.128.127 |
Rede de infraestrutura do Azure Stack
A super-rede de rede de infraestrutura requer uma rede /24 e esta continua a ser um /24 após a execução da ferramenta Folha de Cálculo de Implementação. O gateway será o primeiro IP na sub-rede.
- Rack: Rack1
- Nome: CL01-RG01-SU01-Infra
| Atribuído a | Endereço IPv4 |
|---|---|
| Rede | 12.193.130.0 |
| Gateway | 12.193.130.1 |
| TOR1 | 12.193.130.2 |
| TOR2 | 12.193.130.3 |
| Difusão | 12.193.130.255 |
Mudar de rede de infraestrutura
A rede de infraestrutura é dividida em várias redes utilizadas pela infraestrutura de comutador físico. Isto é diferente da Infraestrutura do Azure Stack que suporta apenas o software do Azure Stack. A Switch Infra Network suporta apenas a infraestrutura de comutador físico. As redes suportadas por infra são:
| Nome | Sub-rede 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 |
Ponto a ponto (P2P): estas redes permitem a conectividade entre todos os comutadores. O tamanho da sub-rede é uma rede /30 para cada P2P. O IP mais baixo é sempre atribuído ao dispositivo a montante (Norte) na pilha.
Loopback: estes endereços são redes /32 atribuídas a cada comutador utilizado no rack. Não é atribuído um loopback aos dispositivos de limite, uma vez que não se espera que façam parte da solução do Azure Stack.
Switch Mgmt ou Gestão de Comutadores: esta rede /29 suporta as interfaces de gestão dedicadas dos comutadores no rack. Os IPs são atribuídos da seguinte forma; esta tabela também pode ser encontrada no separador Utilização de Endereços IP da Folha de Cálculo de Implementação:
Rack: Rack1
Nome: SwitchMgmt
| Atribuído a | Endereço IPv4 |
|---|---|
| Rede | 10.193.132.168 |
| Gateway | 10.193.132.169 |
| TOR1 | 10.193.132.170 |
| TOR2 | 10.193.132.171 |
| Difusão | 10.193.132.175 |
Preparar o ambiente
A imagem do anfitrião do ciclo de vida do hardware contém o contentor do Linux necessário que é utilizado para gerar a configuração do comutador de rede física.
O toolkit de implementação de parceiros mais recente inclui a imagem de contentor mais recente. A imagem de contentor no anfitrião do ciclo de vida do hardware pode ser substituída quando for necessário gerar uma configuração de comutador atualizada.
Eis os passos para atualizar a imagem de contentor:
Transferir a imagem de contentor
Substitua a imagem de contentor na seguinte localização
Gerar configuração
Aqui, iremos guiá-lo através dos passos de geração dos ficheiros JSON e dos ficheiros de Configuração do Comutador de Rede:
Abrir a Folha de Cálculo de Implementação
Preencher todos os campos necessários em todos os separadores
Invoque a função "Gerar" na Folha de Cálculo de Implementação.
Serão criados dois separadores adicionais que apresentam as sub-redes e atribuições ip geradas.Reveja os dados e, uma vez confirmados, invoque a função "Exportar".
Ser-lhe-á pedido que forneça uma pasta na qual os ficheiros JSON serão guardados.Execute o contentor com o Invoke-SwitchConfigGenerator.ps1. Este script requer a execução de uma consola elevada do PowerShell e requer a execução dos seguintes parâmetros.
ContainerName – nome do contentor que irá gerar as configurações do comutador.
ConfigurationData – caminho para o ficheiro ConfigurationData.json exportado da Folha de Cálculo de Implementação.
OutputDirectory – Caminho para o diretório de saída.
Offline – sinaliza que o script é executado no modo offline.
C:\WINDOWS\system32> .\Invoke-SwitchConfigGenerate.ps1 -ContainerName generalonrampacr.azurecr.io/master -ConfigurationData .\ConfigurationData.json -OutputDirectory c:\temp -Offline
Quando o script for concluído, produzirá um ficheiro zip com o prefixo utilizado na folha de cálculo.
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}
Configuração personalizada
Pode modificar algumas definições ambientais para a configuração do comutador do Azure Stack. Pode identificar quais das definições que pode alterar no modelo. Este artigo explica cada uma dessas definições personalizáveis e como as alterações podem afetar o Azure Stack. Estas definições incluem a atualização de palavras-passe, o servidor syslog, a monitorização SNMP, a autenticação e a lista de controlo de acesso.
Durante a implementação da solução do Azure Stack, o fabricante de equipamento original (OEM) cria e aplica a configuração do comutador para TORs e BMC. O OEM utiliza a ferramenta de automatização do Azure Stack para validar que as configurações necessárias estão corretamente definidas nestes dispositivos. A configuração baseia-se nas informações na sua Folha de Cálculo de Implementação do Azure Stack.
Nota
Não altere a configuração sem o consentimento do OEM ou da equipa de engenharia do Microsoft Azure Stack. Uma alteração à configuração do dispositivo de rede pode afetar significativamente a operação ou a resolução de problemas de rede na instância do Azure Stack. Para obter mais informações sobre estas funções no seu dispositivo de rede, como efetuar estas alterações, contacte o fornecedor de hardware OEM ou o suporte da Microsoft. O OEM tem o ficheiro de configuração criado pela ferramenta de automatização com base na sua folha de cálculo de implementação do Azure Stack.
No entanto, existem alguns valores que podem ser adicionados, removidos ou alterados na configuração dos comutadores de rede.
Atualização de palavra-passe
O operador pode atualizar a palavra-passe de qualquer utilizador nos comutadores de rede em qualquer altura. Não existe um requisito para alterar quaisquer informações sobre o sistema do Azure Stack ou para utilizar os passos para Rodar segredos no Azure Stack.
Syslog server
Os operadores podem redirecionar os registos de comutadores para um servidor syslog no respetivo datacenter. Utilize esta configuração para garantir que os registos de um determinado ponto no tempo podem ser utilizados para a resolução de problemas. Por predefinição, os registos são armazenados nos comutadores; a capacidade para armazenar registos é limitada. Consulte a secção Atualizações da lista de controlo de acesso para obter uma descrição geral de como configurar as permissões para o acesso à gestão de comutadores.
Monitorização SNMP
O operador pode configurar o protocolo de gestão de rede simples (SNMP) v2 ou v3 para monitorizar os dispositivos de rede e enviar traps para uma aplicação de monitorização de rede no datacenter. Por motivos de segurança, utilize SNMPv3, uma vez que é mais seguro do que v2. Consulte o fornecedor de hardware OEM para obter as MIBs e a configuração necessárias. Consulte a secção Atualizações da lista de controlo de acesso para obter uma descrição geral de como configurar as permissões para o acesso à gestão de comutadores.
Autenticação
O operador pode configurar RADIUS ou TACACS para gerir a autenticação nos dispositivos de rede. Consulte o fornecedor de hardware OEM para obter os métodos suportados e a configuração necessária. Consulte a secção Atualizações da lista de controlo de acesso para obter uma descrição geral de como configurar as permissões para o acesso à Gestão de Comutadores.
Atualizações da lista de controlo de acesso
O operador pode alterar algumas listas de controlo de acesso (ACL) para permitir o acesso às interfaces de gestão de dispositivos de rede e ao anfitrião do ciclo de vida do hardware (HLH) a partir de um intervalo de rede de datacenter fidedigno. O operador pode escolher o componente que será acessível e a partir de onde. Com a lista de controlo de acesso, o operador pode permitir que as VMs de jumpbox de gestão dentro de um intervalo de rede específico acedam à interface de gestão de comutadores e ao SO HLH e ao BMC HLH.
Para obter mais detalhes, veja Lista de controlo de acesso de comutadores físicos.
TACACS, RADIUS e Syslog
A solução do Azure Stack não será enviada com uma solução TACACS ou RADIUS para controlo de acesso de dispositivos como os comutadores e routers, nem uma solução Syslog para capturar registos de comutadores, mas todos estes dispositivos suportam esses serviços. Para ajudar a integrar com um SERVIDOR TACACS, RADIUS e/ou Syslog existente no seu ambiente, iremos fornecer um ficheiro extra com a Configuração do Comutador de Rede que permitirá ao engenheiro no local personalizar a mudança para as necessidades do cliente.
Passos seguintes
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários