Compartilhar via


Solucionar problemas de relatórios de validação de cluster

Aplica-se a: Azure Stack HCI, versões 22H2 e 21H2; Windows Server 2022, Windows Server 2019

Importante

O Azure Stack HCI agora faz parte do Azure Local. A renomeação da documentação do produto está em andamento. No entanto, as versões mais antigas do Azure Stack HCI, por exemplo, 22H2, continuarão a fazer referência ao Azure Stack HCI e não refletirão a alteração de nome. Saiba mais.

Este tópico ajuda você a solucionar problemas de relatórios de validação de cluster para configurações de QoS (qualidade de serviço) de rede e armazenamento entre servidores em um cluster do Azure Stack HCI e verificar se regras importantes estão definidas. Para conectividade e desempenho ideais, o processo de validação de cluster verifica se a configuração de QoS do Data Center Bridging (DCB) é consistente e, se definida, contém regras apropriadas para as classes de tráfego Clustering de Failover e SMB/SMB Direct.

O DCB é necessário para redes RDMA sobre Ethernet Convergente (RoCE) e é opcional (mas recomendado) para redes iWARP (Internet Wide Area RDMA Protocol).

Instalar a ponte do data center

O Data Center Bridging deve ser instalado para usar cmdlets específicos de QoS. Para verificar se o recurso Data Center Bridging já está instalado em um servidor, execute o seguinte cmdlet no PowerShell:

Get-WindowsFeature -Name Data-Center-Bridging -ComputerName Server1

Se o Data Center Bridging não estiver instalado, instale-o executando o seguinte cmdlet em cada servidor no cluster:

Install-WindowsFeature –Name Data-Center-Bridging -ComputerName Server1

Executar um teste de validação de cluster

Use o recurso Validar no Windows Admin Center selecionando o cluster Ferramentas > Servidores > de Validação de Inventário > ou execute o seguinte comando do PowerShell:

Test-Cluster –Node Server1, Server2

Entre outras coisas, o teste validará se a configuração de QoS do DCB é consistente e se todos os servidores no cluster têm o mesmo número de classes de tráfego e regras de QoS. Ele também verificará se todos os servidores têm regras de QoS definidas para as classes de tráfego Clustering de Failover e SMB/SMB Direct.

Você pode exibir o relatório de validação no Windows Admin Center ou acessando um arquivo de log no diretório de trabalho atual. Por exemplo: C:\Users<username>\AppData\Local\Temp\

Próximo à parte inferior do relatório, você verá "Validar configuração de configurações de QoS" e um relatório correspondente para cada servidor no cluster.

Para entender quais classes de tráfego já estão definidas em um servidor, use o Get-NetQosTrafficClass cmdlet.

Para saber mais, confira Validar um cluster do Azure Stack HCI.

Validar regras de QoS de rede

Valide a consistência das configurações de status de disponibilidade do DCB e status de controle de fluxo de prioridade entre servidores no cluster.

Status de disposição do DCB

Os adaptadores de rede que suportam o protocolo Data Center Bridging Capability Exchange (DCBX) podem aceitar configurações de um dispositivo remoto. Para habilitar esse recurso, o bit de disposição do DCB no adaptador de rede deve ser definido como true. Se o bit willing for definido como false, o dispositivo rejeitará todas as tentativas de configuração de dispositivos remotos e imporá apenas as configurações locais. Se você estiver usando adaptadores RDMA sobre Ethernet Convergente (RoCE), o bit disposto deverá ser definido como false em todos os servidores.

Todos os servidores em um cluster do Azure Stack HCI devem ter o bit de disponibilidade do DCB definido da mesma maneira.

Use o Set-NetQosDcbxSetting cmdlet para definir o bit de disponibilidade do DCB como true ou false, como no exemplo a seguir:

Set-NetQosDcbxSetting –Willing $false

Status do controle de fluxo DCB

O controle de fluxo baseado na prioridade é essencial quando o protocolo de camada superior, como o Fibre Channel, presume um transporte subjacente sem perda. O controle de fluxo DCB pode ser habilitado ou desabilitado globalmente ou para adaptadores de rede individuais. Se habilitado, ele permite a criação de políticas de QoS que priorizam determinado tráfego de aplicativos.

Para que as políticas de QoS funcionem perfeitamente durante o failover, todos os servidores em um cluster do Azure Stack HCI devem ter as mesmas configurações de status de controle de fluxo. Se você estiver usando adaptadores RoCE, o controle de fluxo de prioridade deverá ser habilitado em todos os servidores.

Use o Get-NetQosFlowControl cmdlet para obter a configuração atual do controle de fluxo. Todas as prioridades estão desativadas por padrão.

Use os cmdlets e Disable-NetQosFlowControl com o parâmetro -priority para ativar ou desativar o Enable-NetQosFlowControl controle de fluxo de prioridade. Por exemplo, o comando a seguir habilita o controle de fluxo no tráfego marcado com prioridade 3:

Enable-NetQosFlowControl –Priority 3

Validar regras de QoS de armazenamento

Valide se todos os nós têm uma regra de QoS para clustering de failover e para SMB ou SMB Direct. Caso contrário, podem ocorrer problemas de conectividade e problemas de desempenho.

Regra de QoS para clustering de failover

Se alguma regra de QoS de armazenamento for definida em um cluster, uma regra de QoS para clustering de failover deverá estar presente ou poderão ocorrer problemas de conectividade. Para adicionar uma nova regra de QoS para clustering de failover, use o New-NetQosPolicy cmdlet como no exemplo a seguir:

New-NetQosPolicy "Cluster" -Cluster -Priority 6

Regra de QoS para SMB

Se alguns ou todos os nós tiverem regras de QOS definidas, mas não tiverem uma regra de QOS para SMB, isso poderá causar problemas de conectividade e desempenho para SMB. Para adicionar uma nova regra de QoS de rede para SMB, use o New-NetQosPolicy cmdlet como no exemplo a seguir:

New-NetQosPolicy -Name "SMB" -SMB -PriorityValue8021Action 3

Regra de QoS para SMB Direct

O SMB Direct ignora a pilha de rede, em vez de usar métodos RDMA para transferir dados. Se alguns ou todos os nós tiverem regras de QOS definidas, mas não tiverem uma regra de QOS para SMB Direct, isso poderá causar problemas de conectividade e desempenho para SMB Direct. Para criar uma nova política de QoS para SMB Direct, emita os seguintes comandos:

New-NetQosPolicy "SMB Direct" –NetDirectPort 445 –Priority 3

Próximas etapas

Para informações relacionadas, confira também: