Planejamento de integração de rede para o Azure Stack Hub

Este artigo fornece informações de infraestrutura de rede do Azure Stack Hub para ajudá-lo a decidir como integrar melhor o Azure Stack Hub ao ambiente de rede existente.

Observação

Para resolve nomes DNS externos do Azure Stack Hub (por exemplo, www.bing.com), você precisa fornecer servidores DNS para encaminhar solicitações DNS. Para obter mais informações sobre os requisitos de DNS do Azure Stack Hub, consulte Integração de datacenter do Azure Stack Hub – DNS.

Design de rede física

A solução do Azure Stack Hub requer uma infraestrutura física resiliente e altamente disponível para dar suporte a sua operação e serviços. Para integrar o Azure Stack Hub à rede, ele requer uplinks das opções Top-of-Rack (ToR) para o comutador ou roteador mais próximo, que nesta documentação é chamado de Borda. Os ToRs podem ser uplinked para um único ou um par de Bordas. O ToR é pré-configurado por nossa ferramenta de automação, ele espera um mínimo de uma conexão entre ToR e Border ao usar o Roteamento BGP e um mínimo de duas conexões (uma por ToR) entre ToR e Border ao usar o Roteamento Estático, com um máximo de quatro conexões em qualquer uma das opções de roteamento. Essas conexões são limitadas à mídia SFP+ ou SFP28 e a uma velocidade mínima de um GB. Marcar com seu fornecedor de hardware OEM (fabricante de equipamento original) para disponibilidade. O diagrama a seguir apresenta o design recomendado:

Alocação de largura de banda

O Azure Stack Hub é criado usando as tecnologias Cluster de Failover do Windows Server 2019 e Espaços Diretos. Uma parte da configuração de rede física do Azure Stack Hub é feita para utilizar a separação de tráfego e as garantias de largura de banda para garantir que as comunicações de armazenamento do Spaces Direct possam atender ao desempenho e à escala necessários da solução. A configuração de rede usa classes de tráfego para separar as comunicações baseadas em RDMA do Spaces Direct da utilização de rede pela infraestrutura e/ou locatário do Azure Stack Hub. Para se alinhar às práticas recomendadas atuais definidas para o Windows Server 2019, o Azure Stack Hub está mudando para usar uma classe de tráfego adicional ou prioridade para separar ainda mais a comunicação do servidor para o servidor em suporte à comunicação de controle de Clustering de Failover. Essa nova definição de classe de tráfego será configurada para reservar 2% da largura de banda física disponível. Essa configuração de reserva de classe de tráfego e largura de banda é realizada por uma alteração nos comutadores de ToR (topo de rack) da solução do Azure Stack Hub e no host ou servidores do Azure Stack Hub. Observe que as alterações não são necessárias nos dispositivos de rede de borda do cliente. Essas alterações fornecem melhor resiliência para a comunicação do Cluster de Failover e servem para evitar situações em que a largura de banda de rede é totalmente consumida e, como resultado, as mensagens de controle do Cluster de Failover são interrompidas. Observe que a comunicação do Cluster de Failover é um componente crítico da infraestrutura do Azure Stack Hub e, se interrompida por longos períodos, pode levar à instabilidade nos serviços de armazenamento do Spaces Direct ou em outros serviços que eventualmente afetarão a estabilidade da carga de trabalho do locatário ou do usuário final.

Observação

As alterações descritas são adicionadas no nível do host de um sistema do Azure Stack Hub na versão de 2008. Entre em contato com o OEM para organizar a realização das alterações necessárias nas opções de rede do ToR. Essa alteração de ToR pode ser executada antes da atualização para a versão de 2008 ou após a atualização para 2008. A alteração de configuração para as opções de ToR é necessária para melhorar as comunicações do Cluster de Failover.

Redes lógicas

As redes lógicas representam uma abstração da infraestrutura de rede física subjacente. Eles são usados para organizar e simplificar as atribuições de rede para hosts, VMs (máquinas virtuais) e serviços. Como parte da criação de rede lógica, os sites de rede são criados para definir os pares VLANs (redes de área local virtual), sub-redes IP e sub-rede IP/VLAN associados à rede lógica em cada local físico.

A tabela a seguir mostra as redes lógicas e os intervalos de sub-rede IPv4 associados para os quais você deve planejar:

Rede lógica	Descrição	Tamanho
VIP público	O Azure Stack Hub usa um total de 31 endereços dessa rede e o restante é usado por VMs de locatário. Dos 31 endereços, 8 endereços IP públicos são usados para um pequeno conjunto de serviços do Azure Stack Hub. Se você planeja usar Serviço de Aplicativo e os provedores de recursos do SQL, mais 7 endereços serão usados. Os 16 IPs restantes são reservados para futuros serviços do Azure.	/26 (62 hosts) – /22 (hosts 1022) Recomendado = /24 (254 hosts)
Alternar infraestrutura	Endereços IP ponto a ponto para fins de roteamento, interfaces de gerenciamento de comutador dedicadas e endereços de loopback atribuídos à opção.	/ 26
Infraestrutura	Usado para os componentes internos do Azure Stack Hub se comunicarem.	/24
Privado	Usado para a rede de armazenamento, VIPs privados, contêineres de infraestrutura e outras funções internas. Para obter mais detalhes, consulte a seção Rede privada neste artigo.	/20
BMC	Usado para se comunicar com os BMCs nos hosts físicos.	/ 26

Observação

Um alerta no portal lembrará o operador de executar o cmdlet PEP Set-AzsPrivateNetwork para adicionar um novo espaço ip privado /20. Para obter mais informações e diretrizes sobre como selecionar o espaço IP privado /20, consulte a seção Rede privada neste artigo.

Infraestrutura da rede

A infraestrutura de rede do Azure Stack Hub consiste em várias redes lógicas configuradas nas opções. O diagrama a seguir mostra essas redes lógicas e como elas se integram aos comutadores TOR (top-of-rack), BMC (controlador de gerenciamento de placa base) e borda (rede do cliente).

Rede BMC

Essa rede é dedicada a conectar todos os controladores de gerenciamento de placa base (também conhecidos como BMC ou processadores de serviço) à rede de gerenciamento. Os exemplos incluem: iDRAC, iLO, iBMC e assim por diante. Apenas uma conta do BMC é usada para se comunicar com qualquer nó BMC. Se presente, o HLH (Host do Ciclo de Vida de Hardware) está localizado nessa rede e pode fornecer software específico do OEM para manutenção ou monitoramento de hardware.

O HLH também hospeda a DVM (VM de Implantação). O DVM é usado durante a implantação do Azure Stack Hub e é removido quando a implantação é concluída. O DVM requer acesso à Internet em cenários de implantação conectados para testar, validar e acessar vários componentes. Esses componentes podem estar dentro e fora da rede corporativa (por exemplo: NTP, DNS e Azure). Para obter mais informações sobre os requisitos de conectividade, consulte a seção NAT na integração do firewall do Azure Stack Hub.

Rede privada

Essa rede /20 (4096 IPs) é privada para a região do Azure Stack Hub (não roteia além dos dispositivos comutador de borda do sistema do Azure Stack Hub) e é dividida em várias sub-redes, aqui estão alguns exemplos:

• Rede de armazenamento: uma rede /25 (128 IPs) usada para dar suporte ao uso do tráfego de armazenamento SMB (Bloco de Mensagens diretas e de servidor) do Spaces e da migração dinâmica da VM.
• Rede IP virtual interna: uma rede /25 dedicada a VIPs somente internos para o balanceador de carga de software.
• Rede de contêineres: uma rede /23 (512 IPs) dedicada ao tráfego somente interno entre contêineres que executam serviços de infraestrutura.

O sistema do Azure Stack Hub requer um espaço IP interno privado /20 adicional. Essa rede será privada para o sistema do Azure Stack Hub (não roteia além dos dispositivos comutador de borda do sistema do Azure Stack Hub) e pode ser reutilizado em vários sistemas do Azure Stack Hub em seu datacenter. Embora a rede seja privada para o Azure Stack, ela não deve se sobrepor a outras redes no datacenter. O espaço de IP privado /20 é dividido em várias redes que permitem a execução da infraestrutura do Azure Stack Hub em contêineres. Além disso, esse novo espaço de IP privado permite esforços contínuos para reduzir o espaço de IP roteável necessário antes da implantação. O objetivo de executar a infraestrutura do Azure Stack Hub em contêineres é otimizar a utilização e melhorar o desempenho. Além disso, o espaço de IP privado /20 também é usado para habilitar esforços contínuos que reduzirão o espaço ip roteável necessário antes da implantação. Para obter diretrizes sobre o espaço ip privado, recomendamos seguir o RFC 1918.

Para sistemas implantados antes de 1910, essa sub-rede /20 será uma rede adicional a ser inserida em sistemas após a atualização para 1910. A rede adicional precisará ser fornecida ao sistema por meio do cmdlet PEP Set-AzsPrivateNetwork .

Observação

A entrada /20 serve como um pré-requisito para a próxima atualização do Azure Stack Hub após 1910. Quando a próxima atualização do Azure Stack Hub após as versões de 1910 e você tentar instalá-la, a atualização falhará se você ainda não tiver concluído a entrada /20, conforme descrito nas etapas de correção conforme mostrado a seguir. Um alerta estará presente no portal do administrador até que as etapas de correção acima sejam concluídas. Consulte o artigo Integração de rede do Datacenter para entender como esse novo espaço privado será consumido.

Etapas de correção: para corrigir, siga as instruções para abrir uma Sessão PEP. Prepare um intervalo de IP interno privado de tamanho /20 e execute o seguinte cmdlet na sessão PEP usando o seguinte exemplo: Set-AzsPrivateNetwork -UserSubnet 10.87.0.0/20. Se a operação for executada com êxito, você receberá a mensagem Intervalo de Rede Interna do Azs adicionado à configuração. Se concluído com êxito, o alerta será fechado no portal do administrador. O sistema do Azure Stack Hub agora pode ser atualizado para a próxima versão.

Rede de infraestrutura do Azure Stack Hub

Essa rede /24 é dedicada a componentes internos do Azure Stack Hub para que eles possam se comunicar e trocar dados entre si. Essa sub-rede pode ser roteável externamente da solução do Azure Stack Hub para o datacenter, não recomendamos usar endereços IP roteáveis públicos ou da Internet nesta sub-rede. Essa rede é anunciada para a Borda, mas a maioria de seus IPs são protegidos por ACLs (Listas de Controle de Acesso). Os IPs permitidos para acesso estão dentro de um pequeno intervalo equivalente em tamanho a uma rede /27 e serviços de host, como o PEP (ponto de extremidade privilegiado) e o Backup do Azure Stack Hub.

Rede VIP pública

A rede VIP pública é atribuída ao controlador de rede no Azure Stack. Não é uma rede lógica no comutador. O SLB usa o pool de endereços e atribui redes /32 para cargas de trabalho de locatário. Na tabela de roteamento de comutador, esses IPs /32 são anunciados como uma rota disponível por meio do BGP. Essa rede contém os endereços IP públicos ou acessíveis externamente. A infraestrutura do Azure Stack Hub reserva os primeiros 31 endereços dessa rede VIP pública, enquanto o restante é usado por VMs de locatário. O tamanho da rede nessa sub-rede pode variar de um mínimo de /26 (64 hosts) a um máximo de /22 (1022 hosts). Recomendamos que você planeje uma rede /24.

Conectando-se a redes locais

O Azure Stack Hub usa redes virtuais para recursos do cliente, como máquinas virtuais, balanceadores de carga e outros.

Há várias opções diferentes para se conectar de recursos dentro da rede virtual a recursos locais/corporativos:

• Use endereços IP públicos da rede VIP pública.
• Use Rede Virtual Gateway ou NVA (Solução de Virtualização de Rede).

Quando um túnel VPN S2S é usado para conectar recursos de ou para redes locais, você pode encontrar um cenário no qual um recurso também tem um endereço IP público atribuído e ele não é mais acessível por meio desse endereço IP público. Se a origem tentar acessar o IP público dentro do mesmo intervalo de sub-rede definido nas Rotas de Gateway de Rede Local (gateway de Rede Virtual) ou na rota definida pelo usuário para soluções NVA, o Azure Stack Hub tentará rotear o tráfego de volta para a origem por meio do túnel S2S, com base nas regras de roteamento configuradas. O tráfego de retorno usa o endereço IP privado da VM, em vez de ser NATed de origem como o endereço IP público:

Há duas soluções para esse problema:

• Encaminhe o tráfego direcionado para a rede VIP pública para a Internet.
• Adicione um dispositivo NAT à NAT quaisquer IPs de sub-rede definidos no gateway de rede local direcionado para a rede VIP pública.

Alternar rede de infraestrutura

Essa rede /26 é a sub-rede que contém as sub-redes IP /30 (dois IPs de host) roteáveis e os loopbacks, que são sub-redes /32 dedicadas para gerenciamento de comutadores em banda e ID do roteador BGP. Esse intervalo de endereços IP deve ser roteável fora da solução do Azure Stack Hub para o datacenter. Eles podem ser IPs privados ou públicos.

Alternar rede de gerenciamento

Essa rede /29 (seis IPs de host) é dedicada à conexão das portas de gerenciamento dos comutadores. Ele permite acesso fora de banda para implantação, gerenciamento e solução de problemas. Ele é calculado a partir da rede de infraestrutura de comutador mencionada acima.

Redes permitidas

A Planilha de Implantação tem um campo que permite que o operador altere algumas ACL (lista de controle de acesso) para permitir o acesso a interfaces de gerenciamento de dispositivos de rede e o host do ciclo de vida de hardware (HLH) de um intervalo de rede de datacenter confiável. Com a alteração da lista de controle de acesso, o operador pode permitir que suas VMs de jumpbox de gerenciamento dentro de um intervalo de rede específico acessem a interface de gerenciamento do comutador e o sistema operacional HLH. O operador pode fornecer uma ou várias sub-redes para essa lista, se deixado em branco, o padrão será negar acesso. Essa nova funcionalidade substitui a necessidade de intervenção manual pós-implantação, pois costumava ser descrita na configuração Modificar configurações específicas do Azure Stack Hub.

Próximas etapas

• Roteamento de tráfego de rede virtual
• Saiba mais sobre o planejamento de rede: conectividade de borda.