Reparar um servidor no Azure Stack HCI, versão 23H2

  • Artigo

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

Este artigo descreve como reparar um servidor no cluster do Azure Stack HCI.

Sobre servidores de reparo

O Azure Stack HCI é um sistema hiperconvergente que permite reparar servidores de clusters existentes. Talvez seja necessário reparar um servidor em um cluster se houver uma falha de hardware.

Antes de reparar um servidor, verifique com seu provedor de soluções quais componentes no servidor são unidades de substituição de campo (FRUs) que você mesmo pode substituir e quais componentes exigiriam que um técnico substituísse.

As peças que suportam hot swap normalmente não exigem que você recrie a imagem do servidor, ao contrário dos componentes não hot-swap, como a placa-mãe. Consulte o fabricante do hardware para determinar quais substituições de componentes exigiriam que você recriasse a imagem do servidor. Para obter mais informações, consulte Substituição de componentes.

Reparar o fluxo de trabalho do servidor

O diagrama de fluxo a seguir mostra o processo geral para reparar um servidor.

Diagrama que ilustra o processo do servidor de reparo.

*O servidor pode não estar em um estado em que o desligamento seja possível ou necessário

Para reparar um servidor existente, siga estas etapas de alto nível:

  1. Se possível, desligue o servidor que deseja reparar. Dependendo do estado do servidor, um desligamento pode não ser possível ou necessário.

  2. Recrie a imagem do servidor que precisa ser reparado.

  3. Execute a operação do servidor de reparo. O sistema operacional, os drivers e o firmware do Azure Stack HCI são atualizados como parte da operação de reparo.

    O armazenamento é rebalanceado automaticamente no servidor recriado. O rebalanceamento de armazenamento é uma tarefa de baixa prioridade que pode ser executada por vários dias, dependendo do número de servidores e do armazenamento usado.

Cenários com suporte

Reparar um servidor recria a imagem de um servidor e o traz de volta ao cluster com o nome e a configuração anteriores.

Reparar um único servidor resulta em uma reimplantação com a opção de persistir os volumes de dados. Somente o volume do sistema é excluído e provisionado novamente durante a implantação.

Importante

Certifique-se de sempre ter backups para suas cargas de trabalho e não dependa apenas da resiliência do sistema. Isso é especialmente crítico em cenários de servidor único.

Configurações de resiliência

Nesta versão, para reparar a operação do servidor, tarefas específicas não são executadas nos volumes de carga de trabalho que você criou após a implantação. Para a operação do servidor de reparo, apenas os volumes de infraestrutura necessários e os volumes de carga de trabalho são restaurados e exibidos como volumes compartilhados de cluster (CSVs).

Os outros volumes de carga de trabalho que você criou após a implantação ainda são retidos e você pode descobrir esses volumes executando Get-VirtuaDisk cmdlet. Você precisará desbloquear manualmente o volume (se o volume tiver o BitLocker habilitado) e criar um CSV (se necessário).

Requisitos de hardware

Ao reparar um servidor, o sistema valida o hardware do novo servidor de entrada e garante que o servidor atenda aos requisitos de hardware antes de ser adicionado ao cluster.

Componente Verificação de conformidade
CPU Valide se o novo servidor tem o mesmo número de ou mais núcleos de CPU. Se os núcleos da CPU no nó de entrada não atenderem a esse requisito, um aviso será apresentado. No entanto, a operação é permitida.
Memória Valide se o novo servidor tem a mesma quantidade ou mais de memória instalada. Se a memória no nó de entrada não atender a esse requisito, um aviso será apresentado. No entanto, a operação é permitida.
Unidades Valide se o novo servidor tem o mesmo número de unidades de dados disponíveis para Espaços de Armazenamento Diretos. Se o número de unidades no nó de entrada não atender a esse requisito, um erro será relatado e a operação será bloqueada.

Substituição do servidor

Você pode substituir todo o servidor:

  • Com um novo servidor que tem um número de série diferente em comparação com o servidor antigo.
  • Com o servidor atual depois de reimaginá-lo.

Os seguintes cenários são suportados durante a substituição do servidor:

Servidor Disco Com suporte
Novo servidor Novos discos Sim
Novo servidor Discos atuais Sim
Servidor atual (recriado) Discos atuais reformatados * Não
Servidor atual (recriado) Novos discos Sim
Servidor atual (recriado) Discos atuais Sim

**Os discos que foram usados por Espaços de Armazenamento Diretos exigem limpeza adequada. A reformatação não é suficiente. Veja como limpar unidades.

Importante

Se você substituir um componente durante o reparo do servidor, não precisará substituir ou redefinir as unidades de dados. Se você substituir uma unidade ou redefini-la, a unidade não será reconhecida depois que o servidor ingressar no cluster.

Substituição de componentes

No cluster do Azure Stack HCI, os componentes não hot-swap incluem os seguintes itens:

  • Placa-mãe/BMC (controlador BMC de gerenciamento da placa base)/placa de vídeo
  • Controlador de disco/adaptador de barramento de host (HBA)/backplace
  • Adaptador de rede
  • Unidade de processamento gráfico
  • Unidades de dados (unidades que não suportam o intercâmbio, por exemplo, placas de suplemento PCI-e)

As etapas de substituição reais para componentes não hot-swap variam de acordo com o fornecedor de hardware do fabricante do equipamento original (OEM). Consulte a documentação do fornecedor OEM se for necessário um reparo de servidor para componentes não hot-swap.

Pré-requisitos

Antes de reparar um servidor, você deve garantir que:

  • AzureStackLCMUser está ativo no Active Directory. Para obter mais informações, consulte Preparar o Active Directory.
  • Conectado como AzureStackLCMUser ou outro usuário com permissões equivalentes.
  • As credenciais para o AzureStackLCMUser não mudaram.

Reparar um servidor

Esta seção descreve como reparar um servidor usando o Repair-Server PowerShell, monitorar o status da operação e solucionar problemas, se houver algum problema.

Certifique-se de ter revisado os pré-requisitos.

Siga estas etapas no servidor que você está tentando reparar.

  1. Instale o sistema operacional e os drivers necessários. Siga as etapas em Instalar o sistema operacional Azure Stack HCI, versão 23H2.

    Observação

    Se o cluster estiver usando uma intenção ATC de Rede dedicada para armazenamento e você estiver usando IPs de armazenamento personalizados, deverá configurar os IPs nos adaptadores de rede de armazenamento antes de executar a operação Servidor de Reparo. Se o cluster estiver usando uma intenção ATC de rede compartilhada para armazenamento e outro tipo de tráfego, como computação e gerenciamento, você precisará configurar manualmente os IPs nos adaptadores de rede virtual de armazenamento depois que o servidor estiver sendo reparado.

  2. Registre o servidor no Arc. Siga as etapas em Registrar-se no Arc e configurar permissões.

    Observação

    Você deve usar os mesmos parâmetros que os nós existentes para se registrar no Arc. Por exemplo: nome do Grupo de Recursos, Região, Assinatura e Tentant.

  3. Atribua as seguintes permissões ao nó reparado:

    • Função de Gerenciamento de Dispositivos do Azure Stack HCI
    • Usuário de segredos do Key Vault Para obter mais informações, consulte Atribuir permissões ao servidor.

Siga estas etapas em outro servidor que seja membro do mesmo cluster do Azure Stack HCI.

  1. Antes de adicionar o servidor, certifique-se de obter um token de autenticação atualizado. Execute o comando a seguir:

     Update-AuthenticationToken

  2. Entre no servidor que já é membro do cluster, com as credenciais de usuário do domínio que você forneceu durante a implantação do cluster. Execute o seguinte comando para reparar o servidor de entrada:

    $Cred = Get-Credential 
Repair-Server -Name "< Name of the new server>" -LocalAdminCredential $Cred

    Observação

    O nome do servidor deve ser o nome NetBIOS.

  3. Anote a ID da operação como saída pelo Repair-Server comando. Você usa isso posteriormente para monitorar o progresso da Repair-Server operação.

Observação

Se você implantou o cluster do Azure Stack HCI usando IPs de armazenamento personalizados, deverá atribuir IPs manualmente aos adaptadores de rede de armazenamento depois que o servidor for reparado.

Monitore o progresso da operação

Para monitorar o progresso da operação de adição de servidor, siga estas etapas:

  1. Execute o cmdlet a seguir e forneça a ID da operação da etapa anterior.

    $ID = "<Operation ID>" 
Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID $ID

  2. Após a conclusão da operação, o trabalho de rebalanceamento de armazenamento em segundo plano continuará a ser executado. Aguarde a conclusão do trabalho de rebalanceamento de armazenamento. Para verificar o progresso desse trabalho de rebalanceamento de armazenamento, use o seguinte cmdlet:

    Get-VirtualDisk|Get-StorageJob

    Se o trabalho de rebalanceamento de armazenamento for concluído, o cmdlet não retornará uma saída.

Cenários de recuperação

Os seguintes cenários de recuperação e as etapas de mitigação recomendadas são tabulados para reparar um servidor:

Descrição do cenário Mitigação Com suporte?
Falha na operação do servidor de reparo. Para concluir a operação, investigue a falha.
Execute novamente a operação com falha usando Add-Server -Rerun.		 Sim
A operação do servidor de reparo foi parcialmente bem-sucedida, mas teve que começar com uma nova instalação do sistema operacional. Nesse cenário, o orquestrador (também conhecido como Lifecycle Manager) já atualizou seu armazenamento de conhecimento com o novo servidor. Use o cenário do servidor de reparo. Sim

Solução de problemas

Se você tiver falhas ou erros ao reparar um servidor, poderá capturar a saída das falhas em um arquivo de log.

  • Entre com as credenciais de usuário do domínio que você forneceu durante a implantação do cluster. Capture o problema nos arquivos de log.

    Get-ActionPlanInstance -ActionPlanInstanceID $ID |out-file log.txt

  • Para executar novamente a operação com falha, use o seguinte cmdlet:

    Repair-Server -Rerun

Próximas etapas

Saiba mais sobre como Adicionar um servidor.