Considerações sobre a rede para implantações de nuvem do Local do Azure

Aplica-se a: implantações hiperconvergadas do Azure Local

Este artigo discute como projetar e planejar uma rede de sistema Local do Azure para implantação na nuvem. Antes de continuar, familiarize-se com os vários padrões de rede Local do Azure e 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 do cluster, intenções de tráfego de rede, conectividade de gerenciamento e configuração do adaptador de rede. Cada decisão de design habilita ou permite as opções de design disponíveis nas etapas subsequentes:

Etapa 1: determinar o tamanho do cluster

Para ajudar a determinar o tamanho de sua instância do Local do Azure, use a Ferramenta de dimensionamento do Local do Azure, onde você pode definir seu perfil, como o número de máquinas virtuais (VMs), o tamanho das VMs e o uso de workload das VMs, como a Área de Trabalho Virtual do Azure, o SQL Server ou o AKS.

Conforme descrito no artigo Local do Azure requisitos do computador, o número máximo de máquinas suportadas na instância Local do Azure é 16. Depois de concluir o planejamento da capacidade de workload, você deverá ter uma boa compreensão do número de nós de máquina necessários para executar workloads na sua infraestrutura.

• Se seus workloads exigirem quatro ou mais nós: não é possível implantar e usar uma configuração sem comutador para o tráfego da rede de armazenamento. Você precisa incluir um comutador físico com suporte para RDMA (Acesso remoto à memória direta) 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 seus workloads exigirem três ou menos nós: você pode escolher configurações com ou sem comutador para conectividade de armazenamento.

• Se você planeja expandir posteriormente para mais de três nós: você precisa usar um comutador físico para o tráfego da rede de armazenamento. Qualquer operação de expansão para implantações sem comutador requer 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 Local do Azure.

Aqui estão as considerações resumidas para a decisão sobre o 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 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 requerem um comutador físico para o tráfego da rede de armazenamento.
Requisitos de expansão	Se você pretende fazer a escala horizontal no seu cluster usando o orquestrador, precisará usar um comutador físico para o tráfego de rede de armazenamento.

Etapa 2: determinar a conectividade do armazenamento do cluster

Conforme descrito em Requisitos físicos da rede, o Local do Azure oferece suporte a dois tipos de conectividade para o 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 uma 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.

Conforme 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ê poderá definir na próxima etapa.

Por exemplo, para configurações sem comutador, você precisa definir duas intenções de tráfego de rede. O tráfego de armazenamento para comunicações leste-oeste usando os cabos de cruzamento não tem conectividade norte-sul e está 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 do gerenciamento e para seus workloads 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 tolerância a falhas. Por isso, sempre recomendamos o uso de pelo menos duas portas de rede físicas para cada intenção de rede. Se decidir usar um comutador 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 configuração hiperconvergente ou totalmente convergente de host de rede.

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

Decisão	Consideração
Sem comutador para armazenamento	A configuração sem comutador via portal do Azure ou implantação de modelo do Resource Manager só é compatível com clusters de 1, 2 ou 3 nós. Clusters sem comutador de armazenamento de 1 ou 2 nós podem ser implantados usando o portal do Azure ou modelos do Resource Manager. Os clusters sem comutador de armazenamento de 3 nós só podem ser implementados usando modelos do Resource Manager . Operações de expansão não são suportadas com implantações sem switches. 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ários ao usar a configuração sem comutador de armazenamento.
Comutador de rede para armazenamento	Se você pretende fazer a escala horizontal no seu 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 do tráfego de rede

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

Esta seção explica as implicações da 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 implantar 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 em seu 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

O Network ATC 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 a largura de banda e a taxa de transferência de 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 intenção. O portal do Azure filtra automaticamente essa opção se você selecionar uma configuração sem comutador para conectividade de armazenamento.

• Recomenda-se pelo menos duas portas de adaptador de rede para garantir alta disponibilidade.

• São necessárias pelo menos interfaces de rede de 10 Gbps para dar suporte ao tráfego RDMA para armazenamento.

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

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

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

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

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

• São necessárias pelo menos interfaces de rede de 10 Gbps para dar suporte ao tráfego RDMA para armazenamento.

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

O Network ATC 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 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 intenção. 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.

• Recomenda-se pelo menos duas portas de adaptador de rede para garantir alta disponibilidade.

• Recomenda-se pelo menos interfaces de rede de 10 Gbps para que a intenção de computação e armazenamento ofereça suporte ao tráfego RDMA.

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

Intenção de 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 workloads.

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

• Use essa opção quando for necessária outra intenção de computação ou quando você 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.

• Recomenda-se pelo menos interfaces de rede de 10 Gbps para que a intenção de computação e armazenamento ofereça suporte ao 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 de 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 da sub-rede de infraestrutura devem ser planejados e definidos antes de começar a implantar, para que seja possível antecipar quaisquer requisitos de roteamento, firewall ou sub-rede.

Intervalos de IP reservados do Arc Resource Bridge que você mais evita para componentes de infraestrutura local do Azure

Quando você implanta o Azure Local, o sistema reserva automaticamente determinados intervalos de endereços IP para serviços internos do Kubernetes que alimentam o ARB (Azure Resource Bridge) e o AKS. Se a configuração local do Azure usar IPs que se sobrepõem a esses intervalos reservados, sua implantação poderá falhar ou enfrentar problemas de conectividade difíceis de solucionar.

Intervalos reservados – Não usar

Os seguintes intervalos de IP são reservados internamente para o Arc Resource Bridge não devem ser usados para nenhum componente de infraestrutura local do Azure, conforme listado abaixo:

Intervalo reservado	Para que é usado
10.96.0.0/12	Serviços internos do Kubernetes (IPs de cluster)
10.244.0.0/16	Rede de pods do Kubernetes

O que verificar antes da implantação

Verifique se nenhum dos seguintes IPs de infraestrutura local do Azure está dentro dos intervalos reservados acima:

Verifique isso	Exemplo de um problema
Seus IPs de servidor DNS	DNS em 10.96.1.10 entraria em conflito
Seu IP do servidor Proxy	O servidor proxy em 10.97.10.25 entraria em conflito
Pool de IP da sua infraestrutura	Pool começando em 10.100.0.1 está dentro de 10.96.0.0/12
IPs de gerenciamento de nós	Nó em 10.244.1.50 conflita com rede do pod
Seu gateway padrão	O Gateway em 10.96.0.1 entraria em conflito
Qualquer rede lógica para VMs	A sub-rede 10.244.100.0/24 da VM sobrepõe a rede de pods

Intervalos de IP seguros a serem usados

Aqui estão exemplos de intervalos de IP privados comumente usados que não entrarão em conflito:

Intervalo seguro	Anotações
192.168.x.x	Mais comum para implantações pequenas
172.16.x.x a 172.31.x.x	Bom para redes de médio porte
10.0.x.x a 10.95.x.x	Seguro – permanece abaixo do limite reservado 10.96.0.0
10.112.x.x e superior	Seguro – acima do limite reservado 10.111.255.255

Conteúdo relacionado

• Requisitos de planejamento de endereço IP para AKS
• Intervalos de IP designados para Arc Resource Bridge

Drivers de adaptador de rede

Depois de instalar o sistema operacional e antes de configurar a rede nos nós, é necessário garantir que os adaptadores de rede tenham o driver mais recente fornecido pelo OEM ou pelo fornecedor da 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 IPs consecutivos para os serviços de infraestrutura implantados por padrão.

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

Se você prevê a execução de outros serviços na rede de infraestrutura, recomendamos que atribua um buffer adicional 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 for esgotado.

Durante a implantação, o verificador de ambiente testará a conectividade do ICMP dos endereços do Pool de IP de Gerenciamento para o gateway padrão do Pool de IP de Gerenciamento. Verifique se o gateway padrão permite o tráfego ICMP da sub-rede de Gerenciamento Local do Azure.

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

#	Condição
1	O intervalo de IPs 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 dos seus nós.
3	O gateway padrão definido para o pool de IPs de gerenciamento deve fornecer conectividade de saída para 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.
6	O verificador de ambiente valida que o tráfego ICMP responde no gateway padrão do intervalo do pool de IP de gerenciamento local do Azure.

ID da VLAN de gerenciamento

Recomendamos que a sub-rede de gerenciamento de sua 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 da sua rede exigirem o uso de uma VLAN de gerenciamento específica para a rede de infraestrutura, ela deverá ser configurada nos adaptadores de rede físicos que você planeja usar para o tráfego de gerenciamento.

Se você planeja usar dois adaptadores de rede físicos para gerenciamento, é necessário 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 o ID da VLAN nos adaptadores de rede físicos, use o seguinte comando do PowerShell:

Este exemplo configura o ID de VLAN 44 no adaptador de rede física NIC1.

Set-NetAdapter -Name "NIC1" -VlanID 44

Depois que o ID da VLAN é definido e os IPs de seus nós são configurados nos adaptadores de rede físicos, o orquestrador lê esse valor de ID da VLAN do adaptador de rede físico 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 o ID da VLAN de gerenciamento durante a implantação da nuvem a partir do 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 comutador virtual

Em alguns cenários, é necessário 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 Hyper-V. Para obter mais informações, consulte Instalar a função necessária do Windows.

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

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

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

Recomendamos nomear seus 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 digitado 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 o tráfego de rede de gerenciamento e computação:

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

Observação

Depois que uma instância local do Azure é implantada, não há suporte para alterar o nome da intenção de gerenciamento ou o nome do comutador virtual. Você deve usar o mesmo nome de intenção e o nome do comutador virtual se precisar atualizar ou recriar a intenção após a implantação.

2. Configure o adaptador de rede virtual de gerenciamento usando a convenção de nomenclatura exigida pelo Network ATC para todos os nós

Depois que o comutador virtual e o adaptador de rede virtual de gerenciamento associado forem criados, certifique-se de que o nome do adaptador de rede esteja em conformidade com os padrões de nomenclatura do Network ATC.

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 intenção Mgmt.

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)"

Observação

Durante a validação de implantação, todos os vSwitches nos nós devem ter vNICs correspondentes. Se houver vSwitches presentes, mas nenhum vNICs correspondente, a operação falhará com o seguinte erro:
"Não foi possível concluir a operação. 200: Há vSwitches presentes nos nós, mas não há vnics, este cenário não tem suporte."
Verifique se os nomes dos adaptadores correspondem entre as saídas de Get-NetAdapter e Get-VMNetworkAdapter -ManagementOS. Se eles não corresponderem, renomeie as NICs antes de tentar novamente a implantação.

3. Configure 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 o ID de VLAN necessário para esse adaptador. Embora existam diferentes opções para atribuir um ID de VLAN a um adaptador de rede virtual, a única opção compatível é usar o comando Set-VMNetworkAdapterIsolation.

Depois que o ID de VLAN necessário for configurado, 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 o ID da VLAN 8 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 o propósito 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 Controle Automático 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 o objetivo 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 sobre o ID da VLAN:

#	Considerações
1	O ID da VLAN deve ser especificado no adaptador de rede física para gerenciamento antes de registrar as máquinas no Azure Arc.
2	Use etapas específicas quando for necessário um comutador virtual 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 implantação do portal do Azure ou para implantação de modelo do Resource Manager.
5	Todos os adaptadores que você pretende usar para gerenciamento devem ter a mesma ID de VLAN configurada.

IPs personalizados para armazenamento

Por padrão, o ATC de rede atribuirá automaticamente os IPs e as VLANs para armazenamento a partir da seguinte tabela:

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 os 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 falso.
• storageAdapterIPInfo: esse parâmetro depende do parâmetro "enableStorageAutoIP" e é sempre necessário quando o parâmetro IP automático do armazenamento é definido como falso. 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 Network ATC se você não precisar alterá-las. No entanto, se esses 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 de 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 com a 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.

• Há suporte para os protocolos DHCP (Dynamic Host Configuration Protocol) e estático.

• A atribuição correta do 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.

• As VMs e os serviços de infraestrutura, como a Ponte de recursos do Arc e o Controlador de Rede, continuam usando IPs estáticos do pool de IPs de gerenciamento. Isso significa que, mesmo que você decida usar o DHCP para atribuir os IPs aos seus 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 forem usados IPs estáticos 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 IP de gerenciamento. Os IPs do nó de 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 a 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 do DHCP usado para os nós e o IP do cluster.

Por exemplo, se o intervalo de IPs 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 do 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 IPs 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 é então 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ísico 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 DHCP para o IP de nó.

A lógica de validação de rede usada durante a implantação da nuvem falhará se detectar várias interfaces 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 incorporado de 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ó do cluster

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

#	Considerações
1	Os IPs de nó devem estar na mesma sub-rede do 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 dinâmica de IP for usada.
3	Use reservas DHCP para os nós o máximo possível.
4	Os endereços DHCP são compatíveis apenas com os IPs dos nós e o 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ísico é atribuído ao adaptador de rede virtual de gerenciamento assim que a intenção de rede de gerenciamento é criada.

Considerações do servidor DNS

As implantações locais do Azure com base no Active Directory exigem um servidor DNS que pode resolver o domínio local 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 da ponte de recursos do Azure 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.

Os servidores DNS usados para o Azure Local devem ser externos e operacionais antes da implantação. Não há suporte para executá-las como máquinas virtuais locais 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 da ponte de recursos do Azure 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 do Azure Local.
5	Ao definir uma matriz de vários servidores DNS em um modelo arm para a rede de infraestrutura, verifique se cada valor está entre aspas "" e separado por vírgulas, como no exemplo a seguir.
6	Não há suporte para executar os servidores DNS usados pela infraestrutura local do Azure em máquinas virtuais em execução dentro da instância local do Azure.
7	Todos os servidores DNS configurados devem resolver domínios locais necessários para a infraestrutura. Não há suporte para servidores DNS públicos, como 8.8.8.8.
8	Todos os servidores DNS configurados não devem se sobrepor aos intervalos de sub-rede ARB reservados (10.96.0.0/12 e 10.244.0.0/16)

"dnsServers": [
                        "10.250.16.124",
                        "10.250.17.232",
                        "10.250.18.107"
                    ]

Requisitos de proxy

É provável que seja necessário um proxy para acessar a Internet em sua infraestrutura local. O Local do Azure suporta apenas configurações de proxy não autenticadas. Como o acesso à Internet é necessário para registrar os nós no Azure Arc, a configuração do 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, confira Definir configurações de proxy.

O sistema operacional 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 é automaticamente transferida para a VM da Ponte de recursos do Arc e para o AKS, garantindo que eles tenham acesso à Internet durante a implantação.

Aqui estão as considerações resumidas sobre a configuração do 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 ao WinINET, ao WinHTTP e às variáveis de ambiente.
3	O Verificador de Ambiente garante que a configuração do proxy seja consistente em todos os componentes do 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.
8	O servidor proxy configurado para nós locais do Azure não deve se sobrepor aos intervalos de sub-rede ARB reservados (10.96.0.0/12 e 10.244.0.0/16)

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 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 se seus firewalls não estão bloqueando o tráfego enviado a esses pontos de extremidade. Para obter mais informações, consulte Verificador de ambiente do Local do Azure para avaliar a prontidão de implantação do Local do Azure.

Aqui estão as considerações resumidas sobre o 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 o qual são usados. Ao revisar 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 Local do Azure, 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 Local do Azure. 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 compatíveis.

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

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

Aqui estão as considerações resumidas sobre 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 Local do Azure.
3	Certifique-se de que seus adaptadores de rede sejam compatíveis com o Local do Azure usando o Catálogo do Windows Server.
4	Ao aceitar os padrões, o Network ATC configura automaticamente os IPs e as 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 o IP de cada adaptador de rede de armazenamento usando os modelos do Resource Manager.

Próximas etapas

• Sobre a implantação local do Azure.