Considerações de rede para implantações de nuvem do Azure Local, versão 23H2

Aplica-se a: Azure Local, versão 23H2

Este artigo discute como projetar e planejar uma rede do sistema Azure Local, versão 23H2 para implantação de nuvem. Antes de continuar, familiarize-se com os vários padrões de rede local do Azure e as configurações disponíveis.

Estrutura de design de rede

O diagrama a seguir mostra as várias decisões e etapas que definem a estrutura de design de rede para sua instância local do Azure – tamanho do cluster, conectividade de armazenamento de cluster, intenções de tráfego de rede, conectividade de gerenciamento e configuração do adaptador de rede. Cada decisão de projeto permite ou permite as opções de projeto disponíveis nas etapas subsequentes:

Etapa 1: Determinar o tamanho do cluster

Para ajudar a determinar o tamanho da instância local do Azure, use a ferramenta de dimensionamento local do Azure, na qual você pode definir seu perfil, como o número de VMs (máquinas virtuais), o tamanho das VMs e o uso da carga de trabalho das VMs, como a Área de Trabalho Virtual do Azure, o SQL Server ou o AKS.

Conforme descrito no artigo Requisitos de computador do sistema local do Azure, o número máximo de computadores com suporte na instância local do Azure é 16. Depois de concluir o planejamento da capacidade de carga de trabalho, você deve ter uma boa compreensão do número de nós de computador necessários para executar cargas de trabalho em sua infraestrutura.

• Se suas cargas de trabalho exigirem quatro ou mais nós: você não pode implantar e usar uma configuração sem comutador para o tráfego de rede de armazenamento. Você precisa incluir um comutador físico com suporte para RDMA (Acesso Remoto Direto à Memória) para lidar com o tráfego de armazenamento. Para obter mais informações sobre a arquitetura de rede da instância local do Azure, consulte Visão geral dos padrões de referência de rede.

• Se suas cargas de trabalho exigirem três ou menos nós: você pode escolher configurações sem comutador ou comutadas para conectividade de armazenamento.

• Se você planeja escalar horizontalmente posteriormente para mais de três nós: você precisa usar um comutador físico para o tráfego de rede de armazenamento. Qualquer operação de expansão para implantações sem comutador requer a configuração manual do cabeamento de rede entre os nós que a Microsoft não está validando ativamente como parte de seu ciclo de desenvolvimento de software para o Azure Local.

Aqui estão as considerações resumidas para a decisão de tamanho do cluster:

Decisão	Consideração
Tamanho do cluster (número de nós por cluster)	A configuração sem comutador por meio do portal do Azure ou modelos do Azure Resource Manager só está disponível para clusters de 1, 2 ou 3 nós. Clusters com 4 ou mais nós exigem comutador físico para o tráfego da rede de armazenamento.
Requisitos de expansão	Se você pretende escalar horizontalmente o cluster usando o orquestrador, precisará usar um comutador físico para o tráfego de rede de armazenamento.

Etapa 2: Determinar a conectividade de armazenamento de cluster

Conforme descrito em Requisitos de rede física, o Azure Local dá suporte a dois tipos de conectividade para tráfego de rede de armazenamento:

• Use um comutador de rede física para lidar com o tráfego.
• Conecte diretamente os nós entre eles com rede cruzada ou cabos de fibra para o tráfego de armazenamento.

As vantagens e desvantagens de cada opção estão documentadas no artigo vinculado acima.

Como mencionado anteriormente, você só pode decidir entre as duas opções quando o tamanho do cluster for de três ou menos nós. Qualquer cluster com quatro ou mais nós é implantado automaticamente usando um comutador de rede para armazenamento.

Se os clusters tiverem menos de três nós, a decisão de conectividade de armazenamento influenciará o número e o tipo de intenções de rede que você pode definir na próxima etapa.

Por exemplo, para configurações sem switch, você precisa definir duas intenções de tráfego de rede. O tráfego de armazenamento para comunicações leste-oeste usando os cabos cruzados não tem conectividade norte-sul e é completamente isolado do restante da infraestrutura de rede. Isso significa que você precisa definir uma segunda intenção de rede para a conectividade de saída de gerenciamento e para suas cargas de trabalho de computação.

Embora seja possível definir cada intenção de rede com apenas uma porta de adaptador de rede física cada, isso não fornece nenhuma tolerância a falhas. Dessa forma, sempre recomendamos o uso de pelo menos duas portas de rede físicas para cada intent de rede. Se você decidir usar um comutador de rede para armazenamento, poderá agrupar todo o tráfego de rede, incluindo armazenamento, em uma única intenção de rede, que também é conhecida como configuração de rede de host hiperconvergente ou totalmente convergente.

Aqui estão as considerações resumidas para a decisão de conectividade de armazenamento de cluster:

Decisão	Consideração
Sem interruptor para armazenamento	A configuração sem comutador por meio do portal do Azure ou da implantação de modelo do Resource Manager só tem suporte para clusters de 1, 2 ou 3 nós. Os clusters sem comutador de armazenamento de 1 ou 2 nós podem ser implantados usando o portal do Azure ou os modelos do Resource Manager. Os clusters sem comutador de armazenamento de 3 nós podem ser implantados somente usando modelos do Resource Manager. Não há suporte para operações de expansão com as implantações sem comutador. Qualquer alteração no número de nós após a implantação requer uma configuração manual. Pelo menos 2 intents de rede são necessários ao usar a configuração sem switch de armazenamento.
Comutador de rede para armazenamento	Se você pretende escalar horizontalmente o cluster usando o orquestrador, precisará usar um comutador físico para o tráfego de rede de armazenamento. Você pode usar essa arquitetura com qualquer número de nós entre 1 e 16. Embora não seja imposto, você pode usar uma única intenção para todos os tipos de tráfego de rede (Gerenciamento, Computação e Armazenamento)

O diagrama a seguir resume as opções de conectividade de armazenamento disponíveis para várias implantações:

Etapa 3: Determinar as intenções de tráfego de rede

Para o Azure Local, todas as implantações dependem da ATC de Rede para a configuração de rede do host. As intenções de rede são configuradas automaticamente ao implantar o Azure Local por meio do portal do Azure. Para entender mais sobre as intenções de rede e como solucioná-las, consulte Comandos ATC de rede comuns.

Esta seção explica as implicações de sua decisão de design para intenções de tráfego de rede e como elas influenciam a próxima etapa da estrutura. Para implantações na nuvem, você pode selecionar entre quatro opções para agrupar o tráfego de rede em uma ou mais intenções. As opções disponíveis dependem do número de nós no cluster e do tipo de conectividade de armazenamento usado.

As opções de intenção de rede disponíveis são discutidas nas seções a seguir.

Intenção de rede: agrupar todo o tráfego

A ATC de Rede configura uma intenção exclusiva que inclui tráfego de rede de gerenciamento, computação e armazenamento. Os adaptadores de rede atribuídos a essa intenção compartilham largura de banda e taxa de transferência para todo o tráfego de rede.

• Essa opção requer um comutador físico para o tráfego de armazenamento. Se você precisar de uma arquitetura sem comutador, não poderá usar esse tipo de intent. O portal do Azure filtra automaticamente essa opção se você selecionar uma configuração sem comutador para conectividade de armazenamento.

• Pelo menos duas portas de adaptador de rede são recomendadas para garantir a alta disponibilidade.

• Pelo menos 10 Gbps de interfaces de rede são necessárias para suportar o tráfego RDMA para armazenamento.

Intenção de rede: gerenciamento de grupo e tráfego de computação

A ATC de Rede configura duas intenções. A primeira intenção inclui o tráfego de rede de gerenciamento e computação, e a segunda intenção inclui apenas o tráfego de rede de armazenamento. Cada intent deve ter um conjunto diferente de portas do adaptador de rede.

Você pode usar essa opção para conectividade de armazenamento comutada e sem comutador, se:

• Pelo menos duas portas de adaptador de rede estão disponíveis para cada intent para garantir alta disponibilidade.

• Um comutador físico será usado para RDMA se você usar o comutador de rede para armazenamento.

• Pelo menos 10 Gbps de interfaces de rede são necessárias para suportar o tráfego RDMA para armazenamento.

Intenção de rede: agrupar tráfego de computação e armazenamento

A ATC de Rede configura duas intenções. A primeira intenção inclui o tráfego de rede de computação e armazenamento, e a segunda intenção inclui apenas o tráfego de rede de gerenciamento. Cada intent deve usar um conjunto diferente de portas do adaptador de rede.

• Essa opção requer um comutador físico para o tráfego de armazenamento, pois as mesmas portas são compartilhadas com o tráfego de computação, que requer comunicação norte-sul. Se você precisar de uma configuração sem comutador, não poderá usar esse tipo de intent. O portal do Azure filtra automaticamente essa opção se você selecionar uma configuração sem comutador para conectividade de armazenamento.

• Essa opção requer um comutador físico para RDMA.

• Pelo menos duas portas de adaptador de rede são recomendadas para garantir alta disponibilidade.

• Pelo menos 10 Gbps

• Mesmo quando a intenção de gerenciamento é declarada sem uma intenção de computação, a ATC de Rede cria um switch virtual SET (Switch Embedded Teaming) para fornecer alta disponibilidade à rede de gerenciamento.

Intenção de rede: configuração personalizada

Defina até três intents usando sua própria configuração, desde que pelo menos um dos intents inclua tráfego de gerenciamento. Recomendamos que você use essa opção quando precisar de uma segunda intenção de computação. Os cenários para esse segundo requisito de intenção de computação incluem tráfego de armazenamento remoto, tráfego de backup de VMs ou uma intenção de computação separada para tipos distintos de cargas de trabalho.

• Use essa opção para conectividade de armazenamento comutada e sem comutador se a intenção de armazenamento for diferente das outras intenções.

• Use essa opção quando outra intenção de computação for necessária ou quando quiser separar totalmente os tipos distintos de tráfego em diferentes adaptadores de rede.

• Use pelo menos duas portas de adaptador de rede para cada intent para garantir alta disponibilidade.

• Pelo menos 10 Gbps

O diagrama a seguir resume as opções de intenção de rede disponíveis para várias implantações:

Etapa 4: Determinar a conectividade de rede de gerenciamento e armazenamento

Nesta etapa, você define o espaço de endereço da sub-rede da infraestrutura, como esses endereços são atribuídos ao cluster e se há algum requisito de proxy ou ID de VLAN para os nós para conectividade de saída com a Internet e outros serviços de intranet, como DNS (Sistema de Nomes de Domínio) ou Serviços do Active Directory.

Os seguintes componentes de sub-rede de infraestrutura devem ser planejados e definidos antes de iniciar a implantação para que você possa antecipar quaisquer requisitos de roteamento, firewall ou sub-rede.

Drivers de adaptador de rede

Depois de instalar o sistema operacional e antes de configurar a rede em seus nós, você deve garantir que seus adaptadores de rede tenham o driver mais recente fornecido pelo OEM ou fornecedor de interface de rede. Recursos importantes dos adaptadores de rede podem não aparecer ao usar os drivers padrão da Microsoft.

Pool de IPs de gerenciamento

Ao fazer a implantação inicial de sua instância local do Azure, você deve definir um intervalo de IP de IPs consecutivos para serviços de infraestrutura implantados por padrão.

Para garantir que o intervalo tenha IPs suficientes para serviços de infraestrutura atuais e futuros, você deve usar um intervalo de pelo menos seis endereços IP disponíveis consecutivos. Esses endereços são usados para - o IP do cluster, a VM do Azure Resource Bridge e seus componentes.

Se você antecipar a execução de outros serviços na rede de infraestrutura, recomendamos que você atribua um buffer extra de IPs de infraestrutura ao pool. É possível adicionar outros pools de IP após a implantação da rede de infraestrutura usando o PowerShell se o tamanho do pool planejado originalmente se esgotar.

As seguintes condições devem ser atendidas ao definir o pool de IPs para a sub-rede de infraestrutura durante a implantação:

#	Condição
1	O intervalo de IP deve usar IPs consecutivos e todos os IPs devem estar disponíveis dentro desse intervalo. Esse intervalo de IP não pode ser alterado após a implantação.
2	O intervalo de IPs não deve incluir os IPs de gerenciamento de nó de cluster, mas deve estar na mesma sub-rede que seus nós.
3	O gateway padrão definido para o pool de IPs de gerenciamento deve fornecer conectividade de saída com a Internet.
4	Os servidores DNS devem garantir a resolução de nomes com o Active Directory e a Internet.
5	Os IPs de gerenciamento exigem acesso de saída à Internet.

ID da VLAN de gerenciamento

Recomendamos que a sub-rede de gerenciamento da instância local do Azure use a VLAN padrão, que na maioria dos casos é declarada como ID de VLAN 0. No entanto, se os requisitos de rede forem usar uma VLAN de gerenciamento específica para sua rede de infraestrutura, ela deverá ser configurada nos adaptadores de rede física que você planeja usar para o tráfego de gerenciamento.

Se você planeja usar dois adaptadores de rede física para gerenciamento, é necessário definir a VLAN em ambos os adaptadores. Isso deve ser feito como parte da configuração de inicialização de seus computadores e antes de serem registrados no Azure Arc, para garantir que você registre com êxito os nós usando essa VLAN.

Para definir a ID da VLAN nos adaptadores de rede física, use o seguinte comando do PowerShell:

Este exemplo configura a VLAN ID 44 no adaptador NIC1de rede física.

Set-NetAdapter -Name "NIC1" -VlanID 44

Depois que a ID da VLAN é definida e os IPs dos nós são configurados nos adaptadores de rede física, o orquestrador lê esse valor de ID da VLAN do adaptador de rede física usado para gerenciamento e o armazena, para que ele possa ser usado para a VM do Azure Resource Bridge ou qualquer outra VM de infraestrutura necessária durante a implantação. Não é possível definir a ID da VLAN de gerenciamento durante a implantação da nuvem no portal do Azure, pois isso acarreta o risco de interromper a conectividade entre os nós e o Azure se as VLANs do comutador físico não forem roteadas corretamente.

ID de VLAN de gerenciamento com um switch virtual

Em alguns cenários, há um requisito para criar um comutador virtual antes do início da implantação.

Observação

Antes de criar um comutador virtual, certifique-se de habilitar a função Hype-V. Para obter mais informações, consulte Instalar a função necessária do Windows.

Se uma configuração de switch virtual for necessária e você precisar usar um ID de VLAN específico, siga estas etapas:

1. Crie um switch virtual com a convenção de nomenclatura recomendada

As implantações locais do Azure dependem da ATC de Rede para criar e configurar os comutadores virtuais e os adaptadores de rede virtual para intenções de gerenciamento, computação e armazenamento. Por padrão, quando a ATC de Rede cria o comutador virtual para as intenções, ela usa um nome específico para o comutador virtual.

Recomendamos nomear seus nomes de switch virtual com a mesma convenção de nomenclatura. O nome recomendado para os comutadores virtuais é o seguinte:

"ConvergedSwitch($IntentName)", onde $IntentName deve corresponder ao nome da intenção digitada no portal durante a implantação. Essa cadeia de caracteres também deve corresponder ao nome do adaptador de rede virtual usado para gerenciamento, conforme descrito na próxima etapa.

O exemplo a seguir mostra como criar o comutador virtual com o PowerShell usando a convenção de nomenclatura recomendada com $IntentName. A lista de nomes de adaptadores de rede é uma lista dos adaptadores de rede física que você planeja usar para gerenciamento e computação de tráfego de rede:

$IntentName = "MgmtCompute"
New-VMSwitch -Name "ConvergedSwitch($IntentName)" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true

2. Configurar o adaptador de rede virtual de gerenciamento usando a convenção de nomenclatura ATC de Rede necessária para todos os nós

Depois que o comutador virtual e o adaptador de rede virtual de gerenciamento associado forem criados, verifique se o nome do adaptador de rede está em conformidade com os padrões de nomenclatura da ATC de Rede.

Especificamente, o nome do adaptador de rede virtual usado para o tráfego de gerenciamento deve usar as seguintes convenções:

• O nome do adaptador de rede e o adaptador de rede virtual devem usar vManagement($intentname).
• Esse nome diferencia maiúsculas de minúsculas.
• $Intentname pode ser qualquer string, mas deve ser o mesmo nome usado para o comutador virtual. Certifique-se de usar essa mesma cadeia de caracteres no portal do Azure ao definir o nome da Mgmt intenção.

Para atualizar o nome do adaptador de rede virtual de gerenciamento, use os seguintes comandos:

$IntentName = "MgmtCompute"

#Rename VMNetworkAdapter for management because during creation, Hyper-V uses the vSwitch name for the virtual network adapter.
Rename-VmNetworkAdapter -ManagementOS -Name "ConvergedSwitch(MgmtCompute)" -NewName "vManagement(MgmtCompute)"

#Rename NetAdapter because during creation, Hyper-V adds the string “vEthernet” to the beginning of the name.
Rename-NetAdapter -Name "vEthernet (ConvergedSwitch(MgmtCompute))" -NewName "vManagement(MgmtCompute)"

3. Configure a ID da VLAN para o adaptador de rede virtual de gerenciamento para todos os nós

Depois que o comutador virtual e o adaptador de rede virtual de gerenciamento forem criados, você poderá especificar a ID de VLAN necessária para esse adaptador. Embora existam diferentes opções para atribuir uma ID de VLAN a um adaptador de rede virtual, a única opção com suporte é usar o Set-VMNetworkAdapterIsolation comando.

Depois que a ID de VLAN necessária estiver configurada, você poderá atribuir o endereço IP e os gateways ao adaptador de rede virtual de gerenciamento para validar se ele tem conectividade com outros nós, DNS, Active Directory e Internet.

O exemplo a seguir mostra como configurar o adaptador de rede virtual de gerenciamento para usar a ID 8 da VLAN em vez do padrão:

Set-VMNetworkAdapterIsolation -ManagementOS -VMNetworkAdapterName "vManagement($IntentName)" -AllowUntaggedTraffic $true -IsolationMode Vlan -DefaultIsolationID "8"

4. Adaptadores de rede física de referência para a intenção de gerenciamento durante a implantação

Embora o adaptador de rede virtual recém-criado seja mostrado como disponível ao implantar por meio do portal do Azure, é importante lembrar que a configuração de rede é baseada na ATC de Rede. Isso significa que, ao configurar o gerenciamento ou a intenção de gerenciamento e computação, ainda precisamos selecionar os adaptadores de rede física usados para essa intenção.

Observação

Não selecione o adaptador de rede virtual para a intenção de rede.

A mesma lógica se aplica aos modelos do Azure Resource Manager. Você deve especificar os adaptadores de rede física que deseja usar para as intenções de rede e nunca os adaptadores de rede virtual.

Aqui estão as considerações resumidas para o ID da VLAN:

#	Considerações
1	A ID DA VLAN deve ser especificada no adaptador de rede física para gerenciamento antes de registrar os computadores no Azure Arc.
2	Use etapas específicas quando um comutador virtual for necessário antes de registrar os computadores no Azure Arc.
3	A ID da VLAN de gerenciamento é transferida da configuração do host para as VMs de infraestrutura durante a implantação.
4	Não há nenhum parâmetro de entrada de ID de VLAN para implantação do portal do Azure ou para implantação de modelo do Resource Manager.

IPs personalizados para armazenamento

Por padrão, a ATC de rede atribuirá automaticamente os IPs e VLANs para armazenamento na tabela a seguir:

Adaptador de armazenamento	Endereço IP e sub-rede	VLAN
pNIC1	10.71.1.x	711
pNIC2	10.71.2.x	712
pNIC3	10.71.3.x	713

No entanto, se seus requisitos de implantação não se ajustarem a esses IPs e VLANs padrão, você poderá usar seus próprios IPs, sub-rede e VLANs para armazenamento. Essa funcionalidade só está disponível ao implantar clusters usando modelos do ARM e você precisará especificar os seguintes parâmetros em seu modelo.

• enableStorageAutoIP: esse parâmetro, quando não especificado, é definido como true. Para habilitar IPs de armazenamento personalizados durante a implantação, esse parâmetro deve ser definido como false.
• storageAdapterIPInfo: esse parâmetro tem uma dependência com o parâmetro "enableStorageAutoIP" e é sempre necessário quando o parâmetro IP automático de armazenamento é definido como false. Dentro do parâmetro "storageAdapterIPInfo" em seu modelo do ARM, você também precisará especificar os parâmetros "ipv4Address" e "subnetMask" para cada nó e adaptador de rede com seus próprios IPs e máscara de sub-rede.
• vlanId: conforme descrito acima na tabela, esse parâmetro usará as VLANs padrão da ATC de Rede se você não precisar alterá-las. No entanto, se essas VLANs padrão não funcionarem em sua rede, você poderá especificar suas próprias IDs de VLAN para cada uma de suas redes de armazenamento.

O modelo do ARM a seguir inclui um exemplo de uma instância local do Azure de dois nós com comutador de rede para armazenamento, em que os IPs de armazenamento são personalizados Implantação de 2 nós com IPs de armazenamento personalizados

Atribuição de IP de nó e cluster

Para a instância local do Azure, você tem duas opções para atribuir IPs para os nós do computador e para o IP do cluster.

• Os protocolos DHCP (Dynamic Host Configuration Protocol) e estático são suportados.

• A atribuição adequada de IP do nó é fundamental para o gerenciamento do ciclo de vida do cluster. Decida entre as opções estáticas e DHCP antes de registrar os nós no Azure Arc.

• As VMs e serviços de infraestrutura, como Arc Resource Bridge e Network Controller, continuam usando IPs estáticos do pool de IPs de gerenciamento. Isso implica que, mesmo que você decida usar o DHCP para atribuir os IPs aos nós e ao IP do cluster, o pool de IPs de gerenciamento ainda será necessário.

As seções a seguir discutem as implicações de cada opção.

Atribuição de IP estático

Se IPs estáticos forem usados para os nós, o pool de IPs de gerenciamento será usado para obter um IP disponível e atribuí-lo ao IP do cluster automaticamente durante a implantação.

É importante usar IPs de gerenciamento para os nós que não fazem parte do intervalo de IP definido para o pool de IPs de gerenciamento. Os IPs do nó do computador devem estar na mesma sub-rede do intervalo de IP definido.

Recomendamos que você atribua apenas um IP de gerenciamento para o gateway padrão e para os servidores DNS configurados para todos os adaptadores de rede física do nó. Isso garante que o IP não seja alterado depois que a intenção da rede de gerenciamento for criada. Isso também garante que os nós mantenham sua conectividade de saída durante o processo de implantação, inclusive durante o registro do Azure Arc.

Para evitar problemas de roteamento e identificar qual IP será usado para conectividade de saída e registro do Arc, o portal do Azure valida se há mais de um gateway padrão configurado.

Se um comutador virtual e um adaptador de rede virtual de gerenciamento tiverem sido criados durante a configuração do sistema operacional, o IP de gerenciamento do nó deverá ser atribuído a esse adaptador de rede virtual.

Atribuição de IP DHCP

Se os IPs dos nós forem adquiridos de um servidor DHCP, um IP dinâmico também será usado para o IP do cluster. As VMs e os serviços de infraestrutura ainda exigem IPs estáticos, e isso implica que o intervalo de endereços do pool de IPs de gerenciamento deve ser excluído do escopo DHCP usado para os nós e o IP do cluster.

Por exemplo, se o intervalo de IP de gerenciamento for definido como 192.168.1.20/24 a 192.168.1.30/24 para os IPs estáticos de infraestrutura, o escopo DHCP definido para a sub-rede 192.168.1.0/24 deverá ter uma exclusão equivalente ao pool de IPs de gerenciamento para evitar conflitos de IP com os serviços de infraestrutura. Também recomendamos que você use reservas DHCP para IPs de nó.

O processo de definição do IP de gerenciamento após a criação da intenção de gerenciamento envolve o uso do endereço MAC do primeiro adaptador de rede física selecionado para a intenção de rede. Esse endereço MAC é atribuído ao adaptador de rede virtual criado para fins de gerenciamento. Isso significa que o endereço IP que o primeiro adaptador de rede física obtém do servidor DHCP é o mesmo endereço IP que o adaptador de rede virtual usa como IP de gerenciamento. Portanto, é importante criar uma reserva de DHCP para o IP do nó.

A lógica de validação de rede usada durante a implantação do Cloud falhará se detectar vários adaptadores de rede física que tenham um gateway padrão em sua configuração. Se você precisar usar o DHCP para suas atribuições de IP de host, precisará pré-criar o comutador virtual SET (agrupamento inserido do comutador) e o adaptador de rede virtual de gerenciamento conforme descrito acima, para que somente o adaptador de rede virtual de gerenciamento adquira um endereço IP do servidor DHCP.

Considerações sobre o IP do nó de cluster

Aqui estão as considerações resumidas para os endereços IP:

#	Considerações
1	Os IPs de nó devem estar na mesma sub-rede do intervalo de pool de IPs de gerenciamento definido, independentemente de serem endereços estáticos ou dinâmicos.
2	O pool de IPs de gerenciamento não deve incluir IPs de nó. Use exclusões de DHCP quando a atribuição de IP dinâmico for usada.
3	Use reservas DHCP para os nós o máximo possível.
4	Os endereços DHCP só têm suporte para IPs de nó e IP do cluster. Os serviços de infraestrutura usam IPs estáticos do pool de gerenciamento.
5	O endereço MAC do primeiro adaptador de rede física é atribuído ao adaptador de rede virtual de gerenciamento depois que a intenção de rede de gerenciamento é criada.

Considerações sobre servidores DNS

As implantações locais do Azure com base no Active Directory exigem um servidor DNS capaz de resolver o domínio On-Prem e os pontos de extremidade públicos da Internet. Como parte da implantação, é necessário definir os mesmos servidores DNS para o intervalo de endereços IP de infraestrutura configurado nos nós. A VM do painel de controle do Azure Resource Bridge e o plano de controle do AKS usarão esses mesmos servidores DNS para resolução de nomes. Depois que a implantação for concluída, não há suporte para alterar os IPs de servidores DNS e não será possível atualizar os endereços na pilha da plataforma local do Azure.

Aqui estão as considerações resumidas para endereços de servidores DNS

#	Considerações
1	Os servidores DNS em todos os nós do cluster devem ser os mesmos.
2	Os servidores DNS do intervalo de endereços IP de infraestrutura devem ser os mesmos usados para os nós.
3	O plano de controle de VM do Azure Resource Bridge e o plano de controle do AKS usarão os servidores DNS configurados no intervalo de endereços IP da infraestrutura.
4	Não há suporte para alterar os servidores DNS após a implantação. Planeje sua estratégia de DNS antes de fazer a implantação local do Azure.

Requisitos de proxy

Um proxy provavelmente é necessário para acessar a Internet em sua infraestrutura local. O Azure Local dá suporte apenas a configurações de proxy não autenticadas. Considerando que o acesso à Internet é necessário para registrar os nós no Azure Arc, a configuração de proxy deve ser definida como parte da configuração do sistema operacional antes que os nós do computador sejam registrados. Para obter mais informações, confira Definir configurações de proxy.

O sistema operacional do Azure Stack HCI tem três serviços diferentes (WinInet, WinHTTP e variáveis de ambiente) que exigem a mesma configuração de proxy para garantir que todos os componentes do sistema operacional possam acessar a Internet. A mesma configuração de proxy usada para os nós é transportada automaticamente para a VM e o AKS do Arc Resource Bridge, garantindo que eles tenham acesso à Internet durante a implantação.

Aqui estão as considerações resumidas para a configuração de proxy:

#	Consideração
1	A configuração do proxy deve ser concluída antes de registrar os nós no Azure Arc.
2	A mesma configuração de proxy deve ser aplicada para WinINET, WinHTTP e variáveis de ambiente.
3	O Verificador de Ambiente garante que a configuração de proxy seja consistente em todos os componentes de proxy.
4	A configuração de proxy da VM da Ponte de Recursos do Arc e do AKS é feita automaticamente pelo orquestrador durante a implantação.
5	Somente os proxies não autenticados são suportados.

Requisitos de firewall

No momento, você precisa abrir vários pontos de extremidade da Internet em seus firewalls para garantir que o Azure Local e seus componentes possam se conectar a eles com êxito. Para obter uma lista detalhada dos endpoints necessários, consulte Requisitos de firewall.

A configuração do firewall deve ser feita antes de registrar os nós no Azure Arc. Você pode usar a versão autônoma do verificador de ambiente para validar se seus firewalls não estão bloqueando o tráfego enviado para esses pontos de extremidade. Para obter mais informações, consulte Verificador de Ambiente Local do Azure para avaliar a preparação da implantação para o Azure Local.

Aqui estão as considerações resumidas para firewall:

#	Consideração
1	A configuração do firewall deve ser feita antes de registrar os nós no Azure Arc.
2	O Verificador de ambiente no modo autônomo pode ser usado para validar a configuração do firewall.

Etapa 5: Determinar a configuração do adaptador de rede

Os adaptadores de rede são qualificados pelo tipo de tráfego de rede (gerenciamento, computação e armazenamento) com os quais são usados. À medida que você examina o Catálogo do Windows Server, a certificação do Windows Server 2022 indica para qual tráfego de rede os adaptadores estão qualificados.

Antes de comprar um computador para o Azure Local, você deve ter pelo menos um adaptador qualificado para gerenciamento, computação e armazenamento, pois todos os três tipos de tráfego são necessários no Azure Local. A implantação de nuvem depende da ATC de Rede para configurar os adaptadores de rede para os tipos de tráfego apropriados, portanto, é importante usar adaptadores de rede com suporte.

Os valores padrão usados pela ATC de Rede estão documentados nas configurações de rede do cluster. Recomendamos que você use os valores padrão. Com isso dito, as seguintes opções podem ser substituídas usando o portal do Azure ou modelos do Resource Manager, se necessário:

• VLANs de armazenamento: defina esse valor como as VLANs necessárias para armazenamento.
• Pacotes Jumbo: Define o tamanho dos pacotes jumbo.
• Network Direct: defina esse valor como false se quiser desabilitar o RDMA para seus adaptadores de rede.
• Tecnologia de Rede Direta: Defina esse valor como RoCEv2 ou iWarp.
• Prioridades de tráfego Datacenter Bridging (DCB): defina as prioridades que atendem às suas necessidades. É altamente recomendável que você use os valores DCB padrão, pois eles são validados pela Microsoft e pelos clientes.

Aqui estão as considerações resumidas para a configuração do adaptador de rede:

#	Consideração
1	Use as configurações padrão o máximo possível.
2	Os comutadores físicos devem ser configurados de acordo com a configuração do adaptador de rede. Consulte Requisitos de rede física para o Azure Local.
3	Verifique se os adaptadores de rede têm suporte para o Azure Local usando o Catálogo do Windows Server.
4	Ao aceitar os padrões, a ATC de Rede configura automaticamente os IPs e VLANs do adaptador de rede de armazenamento. Isso é conhecido como configuração de IP automático de armazenamento. Em alguns casos, não há suporte para o IP automático de armazenamento e você precisa declarar cada IP do adaptador de rede de armazenamento usando modelos do Resource Manager.

Próximas etapas

• Sobre a implantação do Azure Local, versão 23H2.