Partilhar via

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 HCI do Azure Stack.

Sobre os 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 FRUs (unidades de substituição de campo) que você mesmo pode substituir e quais componentes exigiriam a substituição de um técnico.

As peças que suportam hot swap normalmente não exigem que você crie uma nova imagem do servidor, ao contrário dos componentes não hot-swappable, 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 ilustrando o processo do servidor de reparo.

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

Para reparar um servidor existente, siga estes passos 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, drivers e firmware do Azure Stack HCI são atualizados como parte da operação de reparo.

    O armazenamento é rebalanceado automaticamente no servidor recriado. O reequilíbrio 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.

Nota

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

Cenários suportados

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

A reparação de 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 recém-provisionado durante a implantação.

Importante

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

Configurações de resiliência

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

Os outros volumes de carga de trabalho criados após a implantação ainda são retidos e você pode descobrir esses volumes executando Get-VirtuaDisk o 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 de 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 de ou mais 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 recriar a imagem.

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

Servidor Disk Suportado
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 utilizados pelo Storage Spaces Direct, requerem uma 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 unidades de dados. Se você substituir uma unidade ou redefini-la, a unidade não será reconhecida quando o servidor ingressar no cluster.

Substituição de componentes

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

  • Placa-mãe/controladora de gerenciamento da placa base (BMC)/placa de vídeo
  • Controlador de disco/adaptador de barramento de host (HBA)/backplace
  • Ao adaptador de rede
  • Unidade de processamento gráfico
  • Unidades de dados (unidades que não suportam hot swap, por exemplo, placas de expansão PCI-e)

As etapas reais de substituição para componentes que não podem ser trocados a quente 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-swappable.

Pré-requisitos

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

  • AzureStackLCMUser está ativo no Ative Directory. Para obter mais informações, consulte Preparar o Ative Directory.
  • Entrou como AzureStackLCMUser ou outro usuário com permissões equivalentes.
  • As credenciais do AzureStackLCMUser não foram alteradas.

Reparar um servidor

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

Certifique-se de que reviu os pré-requisitos.

Siga estes passos no servidor que está a tentar reparar.

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

  2. Registre o servidor com Arc. Siga as etapas em Registrar com Arc e configure as permissões.

    Nota

    Você deve usar os mesmos parâmetros dos 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:

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

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

     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

    Nota

    O nome do servidor deve ser o nome NetBIOS.

  3. Anote o ID da operação como saída pelo Repair-Server comando. Use isso mais tarde para monitorar o progresso da Repair-Server operação.

Nota

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

Monitorar o progresso da operação

Para monitorar o progresso da operação adicionar servidor, execute 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 reequilíbrio de armazenamento. Para verificar o progresso desse trabalho de rebalanceamento de armazenamento, use o seguinte cmdlet:

    Get-VirtualDisk|Get-StorageJob

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

Cenários de recuperação

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

Descrição do cenário Mitigação Suportado?
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 -Reruno .		 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 orchestrator (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

Resoluçã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 fornecidas 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óximos passos

Saiba mais sobre como Adicionar um servidor.