Considerações de rede para implementações na cloud do Azure Stack HCI, versão 23H2

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

Este artigo aborda como conceber e planear uma rede de sistema do Azure Stack HCI, versão 23H2 para implementação na cloud. Antes de continuar, familiarize-se com os vários padrões de rede do Azure Stack HCI e configurações disponíveis.

Estrutura de conceção de rede

O diagrama seguinte mostra as várias decisões e passos que definem a estrutura de conceção de rede para o seu sistema Azure Stack HCI – tamanho do cluster, conectividade de armazenamento de clusters, intenções de tráfego de rede, conectividade de gestão e configuração da placa de rede. Cada decisão de conceção ativa ou permite as opções de conceção disponíveis nos passos seguintes:

Passo 1: determinar o tamanho do cluster

Para ajudar a determinar o tamanho do sistema HCI do Azure Stack, utilize a ferramenta de dimensionamento do Azure Stack HCI, onde pode definir o seu perfil, como o número de máquinas virtuais (VMs), o tamanho das VMs e a utilização da carga de trabalho das VMs, como o Azure Virtual Desktop, SQL Server ou AKS.

Conforme descrito no artigo Requisitos do servidor de sistema do Azure Stack HCI, o número máximo de servidores suportados no sistema Azure Stack HCI é 16. Depois de concluir o planeamento da capacidade de carga de trabalho, deverá compreender bem o número de nós de servidor necessários para executar cargas de trabalho na sua infraestrutura.

• Se as cargas de trabalho precisarem de quatro ou mais nós: não pode implementar e utilizar uma configuração sem comutadores para o tráfego de rede de armazenamento. Tem de incluir um comutador físico com suporte para o Acesso Remoto Direto à Memória (RDMA) para processar o tráfego de armazenamento. Para obter mais informações sobre a arquitetura de rede do cluster do Azure Stack HCI, veja Descrição geral dos padrões de referência de rede.

• Se as cargas de trabalho exigirem três ou menos nós: pode escolher configurações sem comutadores ou comutados para conectividade de armazenamento.

• Se planear aumentar horizontalmente mais tarde para mais de três nós: tem de utilizar um comutador físico para o tráfego de rede de armazenamento. Qualquer operação de aumento horizontal para implementações sem comutadores requer a configuração manual da cablagem de rede entre os nós que a Microsoft não está a validar ativamente como parte do ciclo de desenvolvimento de software do Azure Stack HCI.

Seguem-se 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 comutação através do portal do Azure ou dos modelos de Resource Manager do Azure só está disponível para 1, 2 ou 3 clusters de nós. Os clusters com 4 ou mais nós necessitam de um comutador físico para o tráfego de rede de armazenamento.
Requisitos de aumento horizontal	Se pretender aumentar horizontalmente o cluster com o orquestrador, tem de utilizar um comutador físico para o tráfego de rede de armazenamento.

Passo 2: determinar a conectividade do armazenamento de clusters

Conforme descrito em Requisitos de rede física, o Azure Stack HCI suporta dois tipos de conectividade para o tráfego de rede de armazenamento:

• Utilize um comutador de rede física para processar o tráfego.
• Ligue diretamente os nós entre eles com a rede de cruzamento ou cabos de fibra para o tráfego de armazenamento.

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

Conforme indicado anteriormente, só pode decidir entre as duas opções quando o tamanho do cluster é de três ou menos nós. Qualquer cluster com quatro ou mais nós é implementado automaticamente através de um comutador de rede para armazenamento.

Se os clusters tiverem menos de três nós, a decisão de conectividade de armazenamento influencia o número e o tipo de intenções de rede que pode definir no próximo passo.

Por exemplo, para configurações sem comutadores, tem de definir duas intenções de tráfego de rede. O tráfego de armazenamento para comunicações este-oeste com os cabos de cruzamento não tem conectividade norte-sul e está completamente isolado do resto da sua infraestrutura de rede. Isto significa que tem de definir uma segunda intenção de rede para a conectividade de saída de gestão e para as cargas de trabalho de computação.

Embora seja possível definir cada intenção de rede com apenas uma porta de placa de rede física cada, isso não fornece tolerância a falhas. Como tal, recomendamos sempre a utilização de, pelo menos, duas portas de rede físicas para cada intenção de rede. Se decidir utilizar um comutador de rede para armazenamento, pode agrupar todo o tráfego de rede, incluindo o armazenamento numa única intenção de rede, que também é conhecida como uma configuração de rede anfitriã hiperconvergida ou totalmente convergida .

Seguem-se as considerações resumidas para a decisão de conectividade do armazenamento do cluster:

Decisão	Consideração
Sem comutador para armazenamento	A configuração sem comutação através de portal do Azure ou Resource Manager implementação de modelos só é suportada para 1, 2 ou 3 clusters de nós. 1 ou 2 clusters sem comutadores de armazenamento de nós podem ser implementados com os modelos portal do Azure ou Resource Manager. Os clusters sem comutadores de armazenamento de 3 nós só podem ser implementados com Resource Manager modelos. As operações de aumento horizontal não são suportadas com as implementações sem comutadores. Qualquer alteração ao número de nós após a implementação requer uma configuração manual. São necessárias pelo menos 2 intenções de rede ao utilizar a configuração sem comutador de armazenamento.
Comutador de rede para armazenamento	Se pretender aumentar horizontalmente o cluster com o orquestrador, tem de utilizar um comutador físico para o tráfego de rede de armazenamento. Pode utilizar esta arquitetura com qualquer número de nós entre 1 e 16. Embora não seja imposta, pode utilizar uma única intenção para todos os tipos de tráfego de rede (Gestão, Computação e Armazenamento)

O diagrama seguinte resume as opções de conectividade de armazenamento disponíveis para várias implementações:

Passo 3: determinar as intenções de tráfego de rede

Para o Azure Stack HCI, todas as implementações dependem do ATC de Rede para a configuração da rede do anfitrião. As intenções de rede são configuradas automaticamente ao implementar o Azure Stack HCI através do portal do Azure. Para saber mais sobre as intenções de rede e como resolvê-las, veja Comandos ATC de rede comuns.

Esta secção explica as implicações da decisão de conceção das intenções de tráfego de rede e como influenciam o próximo passo da arquitetura. Para implementações na cloud, pode selecionar entre quatro opções para agrupar o tráfego de rede numa 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 utilizado.

As opções de intenção de rede disponíveis são abordadas nas secções seguintes.

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

O ATC de Rede configura uma intenção exclusiva que inclui o tráfego de rede de gestão, computação e armazenamento. Os adaptadores de rede atribuídos a esta intenção partilham largura de banda e débito para todo o tráfego de rede.

• Esta opção requer um comutador físico para o tráfego de armazenamento. Se precisar de uma arquitetura sem comutadores, não pode utilizar este tipo de intenção. portal do Azure filtra automaticamente esta opção se selecionar uma configuração sem comutador para conectividade de armazenamento.

• Recomenda-se, pelo menos, duas portas de placa de rede para garantir a Elevada Disponibilidade.

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

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

O ATC de Rede configura duas intenções. A primeira intenção inclui tráfego de rede de computação e gestão e a segunda intenção inclui apenas tráfego de rede de armazenamento. Cada intenção tem de ter um conjunto diferente de portas de placa de rede.

Pode utilizar esta opção para conectividade de armazenamento comutado e sem comutadores, se:

• Estão disponíveis pelo menos duas portas de placa de rede para cada intenção para garantir a elevada disponibilidade.

• É utilizado um comutador físico para RDMA se utilizar o comutador de rede para armazenamento.

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

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

O ATC de Rede configura duas intenções. A primeira intenção inclui tráfego de rede de computação e armazenamento e a segunda intenção inclui apenas o tráfego de rede de gestão. Cada intenção tem de utilizar um conjunto diferente de portas de placa de rede.

• Esta opção requer um comutador físico para o tráfego de armazenamento, uma vez que as mesmas portas são partilhadas com o tráfego de computação, que requer comunicação norte-sul. Se precisar de uma configuração sem comutação, não poderá utilizar este tipo de intenção. portal do Azure filtra automaticamente esta opção se selecionar uma configuração sem comutador para conectividade de armazenamento.

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

• Recomenda-se, pelo menos, duas portas de placa de rede para garantir a elevada disponibilidade.

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

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

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

Defina até três intenções com a sua própria configuração, desde que pelo menos uma das intenções inclua tráfego de gestão. Recomendamos que utilize esta opção quando precisar de uma segunda intenção de computação. Os cenários para este segundo requisito de intenção de computação incluem tráfego de armazenamento remoto, tráfego de cópia de segurança de VMs ou uma intenção de computação separada para tipos distintos de cargas de trabalho.

• Utilize esta opção para conectividade de armazenamento comutado e sem comutadores se a intenção de armazenamento for diferente das outras intenções.

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

• Utilize, pelo menos, duas portas de placa de rede para cada intenção para garantir uma elevada disponibilidade.

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

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

Passo 4: Determinar a conectividade da rede de gestão

Neste passo, vai definir o espaço de endereços da sub-rede da infraestrutura, como estes endereços são atribuídos ao cluster e se existe algum requisito de ID de proxy ou VLAN para os nós para conectividade de saída à Internet e outros serviços da intranet, como o Sistema de Nomes de Domínio (DNS) ou os Serviços do Active Directory.

Os seguintes componentes de sub-rede de infraestrutura têm de ser planeados e definidos antes de iniciar a implementação, para que possa antecipar quaisquer requisitos de encaminhamento, firewall ou sub-rede.

Controladores de placa de rede

Depois de instalar o sistema operativo e antes de configurar a rede nos nós, tem de garantir que os adaptadores de rede têm o controlador mais recente fornecido pelo fornecedor da interface de rede ou OEM. As funcionalidades importantes dos adaptadores de rede podem não surgir ao utilizar os controladores predefinidos da Microsoft.

Conjunto IP de gestão

Ao efetuar a implementação inicial do seu sistema Azure Stack HCI, tem de definir um intervalo de IP de IPs consecutivos para serviços de infraestrutura implementados por predefinição.

Para garantir que o intervalo tem IPs suficientes para os serviços de infraestrutura atuais e futuros, tem de utilizar um intervalo de, pelo menos, seis endereços IP disponíveis consecutivos. Estes endereços são utilizados para o IP do cluster, a VM do Azure Resource Bridge e os respetivos componentes.

Se antecipar a execução de outros serviços na rede de infraestrutura, recomendamos que atribua uma memória intermédia adicional de IPs de infraestrutura ao conjunto. É possível adicionar outros conjuntos IP após a implementação para a rede de infraestrutura com o PowerShell se o tamanho do conjunto que planeou ficar originalmente esgotado.

As seguintes condições têm de ser cumpridas ao definir o conjunto IP para a sub-rede da infraestrutura durante a implementação:

#	Condição
1	O intervalo de IP tem de utilizar IPs consecutivos e todos os IPs têm de estar disponíveis nesse intervalo. Este intervalo de IP não pode ser alterado após a implementação.
2	O intervalo de IPs não pode incluir os IPs de gestão de nós de cluster, mas tem de estar na mesma sub-rede que os nós.
3	O gateway predefinido definido para o conjunto IP de gestão tem de fornecer conectividade de saída à Internet.
4	Os servidores DNS têm de garantir a resolução de nomes com o Active Directory e a Internet.
5	Os IPs de gestão requerem acesso à Internet de saída.

ID da VLAN de Gestão

Recomendamos que a sub-rede de gestão do cluster do Azure HCI utilize a VLAN predefinida, que na maioria dos casos é declarada como ID de VLAN 0. No entanto, se os seus requisitos de rede forem utilizar uma VLAN de gestão específica para a sua rede de infraestrutura, tem de ser configurada nas placas de rede físicas que planeia utilizar para o tráfego de gestão.

Se planear utilizar dois adaptadores de rede físicos para gestão, tem de definir a VLAN em ambos os adaptadores. Isto tem de ser feito como parte da configuração do bootstrap dos seus servidores e, antes de serem registados no Azure Arc, para garantir que regista com êxito os nós com esta VLAN.

Para definir o ID de VLAN nas placas de rede físicas, utilize o seguinte comando do PowerShell:

Este exemplo configura o ID VLAN 44 na placa NIC1de rede física .

Set-NetAdapter -Name "NIC1" -VlanID 44

Assim que o ID da VLAN estiver definido e os IPs dos nós estiverem configurados nos adaptadores de rede físicos, o orquestrador lê este valor de ID de VLAN a partir da placa de rede física utilizada para gestão e armazena-o, para que possa ser utilizado para a VM do Azure Resource Bridge ou qualquer outra VM de infraestrutura necessária durante a implementação. Não é possível definir o ID de VLAN de gestão durante a implementação da cloud a partir de portal do Azure uma vez que isto corre o risco de interromper a conectividade entre os nós e o Azure se as VLANs do comutador físico não forem encaminhadas corretamente.

ID de VLAN de gestão com um comutador virtual

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

Nota

Antes de criar um comutador virtual, certifique-se de que ativa a função Hype-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 tiver de utilizar um ID de VLAN específico, siga estes passos:

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

As implementações do Azure Stack HCI dependem do ATC de Rede para criar e configurar os comutadores virtuais e adaptadores de rede virtual para as intenções de gestão, computação e armazenamento. Por predefinição, quando o ATC de Rede cria o comutador virtual para as intenções, utiliza um nome específico para o comutador virtual.

Recomendamos que atribua um nome aos nomes dos comutadores virtuais com a mesma convenção de nomenclatura. O nome recomendado para os comutadores virtuais é o seguinte:

"ConvergedSwitch($IntentName)", em que $IntentName tem de corresponder ao nome da intenção digitada no portal durante a implementação. Esta cadeia de carateres também tem de corresponder ao nome da placa de rede virtual utilizada para gestão, conforme descrito no passo seguinte.

O exemplo seguinte mostra como criar o comutador virtual com o PowerShell através da convenção de nomenclatura recomendada com $IntentName. A lista de nomes de adaptadores de rede é uma lista dos adaptadores de rede físicos que planeia utilizar para gestão e tráfego de rede de computação:

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

2. Configurar o adaptador de rede virtual de gestão com a convenção de nomenclatura atc de rede necessária para todos os nós

Assim que o comutador virtual estiver configurado, a placa de rede virtual de gestão tem de ser criada. O nome do adaptador de rede virtual utilizado para o tráfego de Gestão tem de utilizar a seguinte convenção de nomenclatura:

• Nome da placa de rede e da placa de rede virtual: vManagement($intentname).
• O nome é sensível às maiúsculas e minúsculas.
• $Intentname pode ser qualquer cadeia, mas tem de ser o mesmo nome utilizado para o comutador virtual.

Para atualizar o nome do adaptador de rede virtual de gestão, utilize o seguinte comando:

$IntentName = "MgmtCompute"
Add-VMNetworkAdapter -ManagementOS -SwitchName "ConvergedSwitch($IntentName)" -Name "vManagement($IntentName)"

#NetAdapter needs to be renamed because during creation, Hyper-V adds the string "vEthernet " to the beginning of the name

Rename-NetAdapter -Name "vEthernet (vManagement($IntentName))" -NewName "vManagement($IntentName)"

3. Configurar o ID de VLAN para gerir a placa de rede virtual para todos os nós

Assim que o comutador virtual e a placa de rede virtual de gestão forem criados, pode especificar o ID de VLAN necessário para este adaptador. Embora existam diferentes opções para atribuir um ID de VLAN a uma placa de rede virtual, a única opção suportada é utilizar o Set-VMNetworkAdapterIsolation comando .

Assim que o ID de VLAN necessário estiver configurado, pode atribuir o endereço IP e os gateways à placa de rede virtual de gestão para validar que tem conectividade com outros nós, DNS, Active Directory e Internet.

O exemplo seguinte mostra como configurar o adaptador de rede virtual de gestão para utilizar o ID 8 de VLAN em vez da predefinição:

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

4. Referenciar adaptadores de rede físicos para a intenção de gestão durante a implementação

Embora a placa de rede virtual recém-criada seja apresentada como disponível ao implementar através de portal do Azure, é importante lembrar que a configuração de rede se baseia no ATC de Rede. Isto significa que, ao configurar a gestão ou a intenção de gestão e computação, ainda temos de selecionar os adaptadores de rede físicos utilizados para essa intenção.

Nota

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

A mesma lógica aplica-se aos modelos do Azure Resource Manager. Tem de especificar os adaptadores de rede físicos que pretende utilizar para as intenções de rede e nunca os adaptadores de rede virtual.

Eis as considerações resumidas para o ID da VLAN:

#	Considerações
1	O ID de VLAN tem de ser especificado na placa de rede física para gestão antes de registar os servidores no Azure Arc.
2	Utilize passos específicos quando for necessário um comutador virtual antes de registar os servidores no Azure Arc.
3	O ID de VLAN de gestão é transportado da configuração do anfitrião para as VMs de infraestrutura durante a implementação.
4	Não existe nenhum parâmetro de entrada de ID de VLAN para implementação de portal do Azure ou para implementação de modelo Resource Manager.

Atribuição de IP de nó e cluster

Para o sistema Azure Stack HCI, tem duas opções para atribuir IPs para os nós de servidor e para o IP do cluster.

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

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

• As VMs e serviços de infraestrutura, como a Ponte de Recursos do Arc e o Controlador de Rede, continuam a utilizar IPs estáticos do conjunto IP de gestão. Tal implica que, mesmo que decida utilizar o DHCP para atribuir os IPs aos nós e ao IP do cluster, o conjunto IP de gestão ainda é necessário.

As secções seguintes abordam as implicações de cada opção.

Atribuição de IP estático

Se os IPs estáticos forem utilizados para os nós, o conjunto ip de gestão é utilizado para obter um IP disponível e atribuí-lo automaticamente ao IP do cluster durante a implementação.

É importante utilizar IPs de gestão para os nós que não fazem parte do intervalo de IP definido para o conjunto IP de gestão. Os IPs do nó do servidor têm de estar na mesma sub-rede do intervalo de IP definido.

Recomendamos que atribua apenas um IP de gestão para o gateway predefinido e para os servidores DNS configurados para todos os adaptadores de rede físicos do nó. Isto garante que o IP não é alterado quando a intenção de rede de gestão é criada. Isto também garante que os nós mantêm a conectividade de saída durante o processo de implementação, incluindo durante o registo do Azure Arc.

Para evitar problemas de encaminhamento e identificar que IP será utilizado para conectividade de saída e registo do Arc, portal do Azure valida se existe mais do que um gateway predefinido configurado.

Se tiver sido criado um comutador virtual e um adaptador de rede virtual de gestão durante a configuração do SO, o IP de gestão do nó tem de ser atribuído a essa placa de rede virtual.

Atribuição de IP DHCP

Se os IPs dos nós forem adquiridos a partir de um servidor DHCP, também é utilizado um IP dinâmico para o IP do cluster. As VMs e os serviços de infraestrutura ainda necessitam de IPs estáticos, o que implica que o intervalo de endereços do conjunto DE IP de gestão tem de ser excluído do âmbito DHCP utilizado para os nós e o IP do cluster.

Por exemplo, Se o intervalo de IP de gestão estiver definido como 192.168.1.20/24 a 192.168.1.30/24 para os IPs estáticos da infraestrutura, o âmbito DHCP definido para a sub-rede 192.168.1.0/24 tem de ter uma exclusão equivalente ao conjunto IP de gestão para evitar conflitos de IP com os serviços de infraestrutura. Também recomendamos que utilize reservas DHCP para IPs de nós.

O processo de definição do IP de gestão após a criação da intenção de gestão envolve a utilização do endereço MAC da primeira placa de rede física selecionada para a intenção de rede. Em seguida, este endereço MAC é atribuído à placa de rede virtual que é criada para fins de gestão. Isto 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 utiliza como IP de gestão. Por conseguinte, é importante criar uma reserva DHCP para o IP do nó.

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

Seguem-se as considerações resumidas para os endereços IP:

#	Considerações
1	Os IPs de nós têm de estar na mesma sub-rede do intervalo de conjuntos IP de gestão definido, independentemente de serem endereços estáticos ou dinâmicos.
2	O conjunto IP de gestão não pode incluir IPs de nós. Utilize exclusões DHCP quando for utilizada a atribuição de IP dinâmico.
3	Utilize reservas DHCP para os nós o máximo possível.
4	Os endereços DHCP só são suportados para IPs de nós e o IP do cluster. Os serviços de infraestrutura utilizam IPs estáticos do conjunto de gestão.
5	O endereço MAC da primeira placa de rede física é atribuído à placa de rede virtual de gestão assim que a intenção de rede de gestão for criada.

Requisitos de proxy

É provável que seja necessário um proxy para aceder à Internet na sua infraestrutura no local. O Azure Stack HCI suporta apenas configurações de proxy não autenticadas. Dado que o acesso à Internet é necessário para registar os nós no Azure Arc, a configuração do proxy tem de ser definida como parte da configuração do SO antes de os nós do servidor serem registados. Para obter mais informações, veja Configurar definições de proxy.

O SO do Azure Stack HCI tem três serviços diferentes (WinInet, WinHTTP e variáveis de ambiente) que requerem a mesma configuração de proxy para garantir que todos os componentes do SO podem aceder à Internet. A mesma configuração de proxy utilizada para os nós é automaticamente transmitida para a VM e o AKS da Bridge de Recursos do Arc, garantindo que têm acesso à Internet durante a implementação.

Eis as considerações resumidas sobre a configuração do proxy:

#	Consideração
1	A configuração do proxy tem de ser concluída antes de registar os nós no Azure Arc.
2	A mesma configuração de proxy tem de ser aplicada para winINET, WinHTTP e variáveis de ambiente.
3	O Verificador de Ambiente garante que a configuração do proxy é consistente em todos os componentes proxy.
4	A configuração do proxy da VM do Arc Resource Bridge e do AKS é feita automaticamente pelo orquestrador durante a implementação.
5	Apenas os proxies não autenticados são suportados.

Requisitos da firewall

Atualmente, tem de abrir vários pontos finais da Internet nas firewalls para garantir que o Azure Stack HCI e os respetivos componentes se podem ligar aos mesmos com êxito. Para obter uma lista detalhada dos pontos finais necessários, veja Requisitos da firewall.

A configuração da firewall tem de ser feita antes de registar os nós no Azure Arc. Pode utilizar a versão autónoma do verificador de ambiente para confirmar que as firewalls não estão a bloquear o tráfego enviado para estes pontos finais. Para obter mais informações, veja Verificador de Ambiente do Azure Stack HCI para avaliar a preparação da implementação para o Azure Stack HCI.

Seguem-se as considerações resumidas para a firewall:

#	Consideração
1	A configuração da firewall tem de ser feita antes de registar os nós no Azure Arc.
2	O Verificador de Ambiente no modo autónomo pode ser utilizado para validar a configuração da firewall.

Passo 5: Determinar a configuração da placa de rede

Os adaptadores de rede são qualificados pelo tipo de tráfego de rede (gestão, computação e armazenamento) com que são utilizados. À medida que revê o Catálogo do Windows Server, a certificação do Windows Server 2022 indica para que tráfego de rede os adaptadores são qualificados.

Antes de comprar um servidor para o Azure Stack HCI, tem de ter, pelo menos, um adaptador qualificado para gestão, computação e armazenamento, uma vez que os três tipos de tráfego são necessários no Azure Stack HCI. A implementação na cloud depende do ATC de Rede para configurar os adaptadores de rede para os tipos de tráfego adequados, pelo que é importante utilizar placas de rede suportadas.

Os valores predefinidos utilizados pelo ATC de Rede estão documentados nas definições de rede de Cluster. Recomendamos que utilize os valores predefinidos. Dito isto, as seguintes opções podem ser substituídas através de modelos de portal do Azure ou Resource Manager, se necessário:

• VLANs de Armazenamento: defina este valor para as VLANs necessárias para armazenamento.
• Jumbo Packets: define o tamanho dos pacotes jumbo.
• Rede Direta: defina este valor como falso se quiser desativar o RDMA para os adaptadores de rede.
• Tecnologia Direta de Rede: defina este valor como RoCEv2 ou iWarp.
• Prioridades de Tráfego Datacenter Bridging (DCB): defina as prioridades que se adequam aos seus requisitos. Recomendamos vivamente que utilize os valores predefinidos do DCB, uma vez que estes são validados pela Microsoft e pelos clientes.

Seguem-se as considerações resumidas sobre a configuração da placa de rede:

#	Consideração
1	Utilize as configurações predefinidas tanto quanto possível.
2	Os comutadores físicos têm de ser configurados de acordo com a configuração da placa de rede. Veja Requisitos de rede física para o Azure Stack HCI.
3	Certifique-se de que os adaptadores de rede são suportados para o Azure Stack HCI com o Catálogo do Windows Server.
4	Ao aceitar as predefinições, o ATC de Rede configura automaticamente os IPs e VLANs da placa de rede de armazenamento. Isto é conhecido como configuração do IP Automático de Armazenamento. Em alguns casos, o IP Automático de Armazenamento não é suportado e tem de declarar cada IP da placa de rede de armazenamento com Resource Manager modelos.

Passos seguintes

• Acerca do Azure Stack HCI, versão 23H2 da implementação.