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 de sistema Azure Local, versão 23H2 para implantação em 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 de adaptador de rede. Cada decisão de conceção permite ou permite as opções de conceção disponíveis nas etapas subsequentes:

Etapa 1: Determinar o tamanho do cluster

Para ajudar a determinar o tamanho da sua instância Local do Azure, use a ferramenta Azure Local sizer, onde você pode definir seu perfil, como o número de máquinas virtuais (VMs), 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 máquina do sistema Local do Azure, o número máximo de máquinas 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 máquina necessários para executar cargas de trabalho em sua infraestrutura.

• Se suas cargas de trabalho exigirem quatro ou mais nós: não é possível implantar e usar uma configuração sem switch para o tráfego da 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 switch ou comutadas para conectividade de armazenamento.

• Se você planeja expandir posteriormente para mais de três nós: você precisa usar um switch físico para o tráfego da rede de armazenamento. Qualquer operação de expansão para implantações sem switch 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 opção por meio do portal do Azure ou dos 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 switch físico para o tráfego da rede de armazenamento.
Requisitos de expansão	Se você pretende expandir seu cluster usando o orchestrator, precisará usar um switch físico para o tráfego da 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 cabos de rede cruzada ou fibra para o tráfego de armazenamento.

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

Como dito 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 switch 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 está completamente isolado do resto da sua infraestrutura de rede. Isso significa que você precisa definir uma segunda intenção de rede para gerenciar a conectividade de saída 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. Como tal, recomendamos sempre o uso de pelo menos duas portas de rede físicas para cada intenção de rede. Se você decidir usar um switch de rede para armazenamento, poderá agrupar todo o tráfego de rede, incluindo o armazenamento, em uma única intenção de rede, que também é conhecida como uma 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 em cluster:

Decisão	Consideração
Sem interruptor para armazenamento	A configuração sem opção por meio do portal do Azure ou da implantação de modelo do Gerenciador de Recursos só é suportada para clusters de 1, 2 ou 3 nós. Os clusters sem opção de armazenamento de 1 ou 2 nós podem ser implantados usando o portal do Azure ou os modelos do Gerenciador de Recursos. Os clusters sem switch de armazenamento de 3 nós só podem ser implantados usando modelos do Resource Manager. As operações de expansão não são suportadas com as implantações sem switch. Qualquer alteração no número de nós após a implantação requer uma configuração manual. Pelo menos 2 intenções de rede são necessárias ao usar a configuração sem switch de armazenamento.
Comutador de rede para armazenamento	Se você pretende expandir seu cluster usando o orchestrator, precisará usar um switch físico para o tráfego da rede de armazenamento. Você pode usar essa arquitetura com qualquer número de nós entre 1 e 16. Embora não seja imposta, 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 do 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 da rede e como solucioná-las, consulte Comandos ATC comuns da rede.

Esta seção explica as implicações de sua decisão de design para as 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 da rede: agrupar todo o tráfego

O ATC de rede configura uma intenção exclusiva que inclui gerenciamento, computação e tráfego de rede de 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.

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

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

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

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

O 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 da rede de armazenamento. Cada intenção deve ter um conjunto diferente de portas de adaptador de rede.

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

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

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

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

Intenção da rede: Tráfego de computação e armazenamento de grupo

O 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 intenção deve usar um conjunto diferente de portas de adaptador de rede.

• Essa opção requer um switch 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 switch, não poderá usar esse tipo de intenção. O portal do Azure filtra automaticamente essa opção se você selecionar uma configuração sem opção para conectividade de armazenamento.

• Esta 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 interfaces de rede são recomendadas para a intenção de computação e armazenamento para suportar o tráfego RDMA.

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

Intenção da rede: Configuração personalizada

Defina até três intenções usando sua própria configuração, desde que pelo menos uma das intenções 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 esta opção para conectividade de armazenamento comutado e sem comutador se a intenção de armazenamento for diferente das outras intenções.

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

• Use pelo menos duas portas de adaptador de rede para cada intenção para garantir alta disponibilidade.

• Pelo menos 10 Gbps interfaces de rede são recomendadas para a intenção de computação e armazenamento para suportar o tráfego RDMA.

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 da 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 Ative 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 do 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 seu 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 IP 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ê prevê executar outros serviços na rede de infraestrutura, recomendamos atribuir um buffer extra de IPs de infraestrutura ao pool. É possível adicionar outros pools IP após a implantação para a rede de infraestrutura usando o PowerShell se o tamanho do pool planejado originalmente se esgotar.

As seguintes condições devem ser atendidas ao definir seu pool de IP 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 do nó do cluster, mas deve estar na mesma sub-rede que os nós.
3	O gateway padrão definido para o pool de IP de gerenciamento deve fornecer conectividade de saída para a Internet.
4	Os servidores DNS devem garantir a resolução de nomes com o Ative Directory e a Internet.
5	Os IPs de gerenciamento exigem acesso de saída à Internet.

ID de VLAN de gerenciamento

Recomendamos que a sub-rede de gerenciamento da sua instância Local do Azure use a VLAN padrão, que na maioria dos casos é declarada como VLAN ID 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, precisará definir a VLAN em ambos os adaptadores. Isso deve ser feito como parte da configuração de inicialização de suas máquinas e antes que elas sejam registradas 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 ID de VLAN 44 no adaptador NIC1de rede físico.

Set-NetAdapter -Name "NIC1" -VlanID 44

Depois que a ID de VLAN é definida e os IPs de seus nós são configurados nos adaptadores de rede física, o orquestrador lê esse valor de ID de VLAN do adaptador de rede física usado para gerenciamento e o armazena, para que 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 na nuvem do portal do Azure, pois isso acarreta o risco de interromper a conectividade entre os nós e o Azure se as VLANs do switch físico não forem roteadas corretamente.

ID de VLAN de gerenciamento com um comutador virtual

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

Nota

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

Se uma configuração de comutador virtual for necessária e você deve usar uma ID de VLAN específica, siga estas etapas:

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

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

Recomendamos nomear os nomes dos comutadores virtuais 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ísicos 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. Configure 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 é compatível com os padrões de nomenclatura ATC de rede.

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

• Nome do adaptador de rede e o adaptador de rede virtual deve usar vManagement($intentname).
• Esse nome diferencia maiúsculas de minúsculas.
• $Intentname pode ser qualquer cadeia de caracteres, 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. Configurar o 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 um ID de VLAN a um adaptador de rede virtual, a única opção suportada é 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, Ative Directory e a Internet.

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

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

4. Referenciar adaptadores de rede física para a intenção de gerenciamento durante a implantação

Embora o adaptador de rede virtual recém-criado apareça como disponível ao implantar por meio do portal do Azure, é importante lembrar que a configuração de rede é baseada no 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.

Nota

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 de VLAN deve ser especificada no adaptador de rede física para gerenciamento antes de registrar as máquinas com o Azure Arc.
2	Use etapas específicas quando um comutador virtual for necessário antes de registrar as máquinas no Azure Arc.
3	O ID da VLAN de gerenciamento é transferido 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 a implantação do portal do Azure ou para a implantação do modelo do Gerenciador de Recursos.

IPs personalizados para armazenamento

Por padrão, o ATC de rede atribuirá automaticamente os IPs e VLANs para armazenamento a partir da 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-redes e VLANs para armazenamento. Essa funcionalidade só está disponível ao implantar clusters usando modelos ARM e você precisará especificar os seguintes parâmetros em seu modelo.

• enableStorageAutoIP: Este 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: Este 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 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 do 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 das suas redes de armazenamento.

O modelo ARM a seguir inclui um exemplo de uma instância local do Azure de dois nós com switch de rede para armazenamento, onde 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 da máquina e para o IP do cluster.

• Os protocolos estático e DHCP (Dynamic Host Configuration Protocol) 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ática e DHCP antes de registrar os nós no Azure Arc.

• VMs de infraestrutura e serviços como Arc Resource Bridge e Network Controller continuam usando IPs estáticos do pool de IP de gerenciamento. Isso implica que, mesmo se você decidir usar o DHCP para atribuir os IPs aos seus nós e ao IP do cluster, o pool de IP 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 IP 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 IP de gerenciamento. Os IPs do nó da máquina 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 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 foram criados durante a configuração do sistema operacional, o IP de gerenciamento para o nó deve ser atribuído a esse adaptador de rede virtual.

Atribuição de IP DHCP

Se IPs para os nós são adquiridos de um servidor DHCP, um IP dinâmico também é 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 IP 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 IP 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ísico selecionado para a intenção de rede. Esse endereço MAC é então atribuído ao adaptador de rede virtual que é 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 reserva DHCP para o IP do nó.

A lógica de validação de rede usada durante a implantação da nuvem falhará se detetar várias interfaces de rede físicas que tenham um gateway padrão em sua configuração. Se você precisar usar DHCP para suas atribuições de IP de host, precisará pré-criar o comutador virtual SET (switch embedded teaming) e o adaptador de rede virtual de gerenciamento conforme descrito acima, para que apenas o adaptador de rede virtual de gerenciamento adquira um endereço IP do servidor DHCP.

Considerações sobre o IP do nó do 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 do pool de IP de gerenciamento definido, independentemente de serem endereços estáticos ou dinâmicos.
2	O pool de IP de gerenciamento não deve incluir IPs de nó. Use exclusões DHCP quando a atribuição de IP dinâmico for usada.
3	Use reservas DHCP para os nós tanto quanto possível.
4	Os endereços DHCP são suportados apenas para IPs de nó e IP de 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ísico é atribuído ao adaptador de rede virtual de gerenciamento assim que a intenção da rede de gerenciamento é criada.

Considerações sobre servidores DNS

As implantações locais do Azure baseadas no Active Directory exigem um servidor DNS que possa resolver queries para o domínio On-Premises 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 da infraestrutura configurado nos nós. O plano de controle da Ponte de Recursos do Azure VM e o plano de controle AKS usarão esses mesmos servidores DNS para resolução de nomes. Quando a implantação estiver concluída, não há suporte para alterar os IPs dos 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 da 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 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. Certifique-se de planejar sua estratégia de DNS antes de fazer a implantação do Azure Local.

Requisitos de procuração

Um proxy provavelmente é necessário para acessar a Internet em sua infraestrutura local. O Azure Local suporta apenas configurações de proxy não autenticadas. Dado 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 da máquina sejam registrados. Para obter mais informações, consulte Definir configurações de proxy.

O sistema operacional HCI do Azure Stack 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 é automaticamente transferida para a VM e 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 de 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 do Arc Resource Bridge e do AKS é feita automaticamente pelo orquestrador durante a implantação.
5	Apenas os proxies não autenticados são suportados.

Requisitos de firewall

No momento, é necessário abrir vários pontos de extremidade da Internet em seus firewalls para garantir que o Azure Local e seus componentes possam se conectar com êxito a eles. Para obter uma lista detalhada dos pontos de extremidade 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 que seus firewalls não estão bloqueando o tráfego enviado para esses pontos de extremidade. Para obter mais informações, consulte Azure Local Environment Checker para avaliar a prontidão da implantação do 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ê analisa 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 uma máquina 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 na nuvem depende do ATC de rede para configurar os adaptadores de rede para os tipos de tráfego apropriados, por isso é importante usar adaptadores de rede suportados.

Os valores padrão usados pelo ATC de rede estão documentados em Configurações de rede do cluster. Recomendamos que você use os valores padrão. Dito isso, as seguintes opções podem ser substituídas usando o portal do Azure ou modelos do Gerenciador de Recursos, se necessário:

• VLANs de armazenamento: defina esse valor como as VLANs necessárias para armazenamento.
• Jumbo Packets: Define o tamanho dos pacotes jumbo.
• Network Direct: defina esse valor como false se quiser desabilitar o RDMA para seus adaptadores de rede.
• Tecnologia Network Direct: defina este valor como RoCEv2 ou iWarp.
• DCB (Traffic Priorities Datacenter Bridging): 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 tanto quanto 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 seus adaptadores de rede têm suporte para o Azure Local usando o Catálogo do Windows Server.
4	Ao aceitar os padrões, o 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, o IP automático de armazenamento não é suportado e você precisa declarar cada IP do adaptador de rede de armazenamento usando modelos do Gerenciador de Recursos.

Próximos passos

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