Skip to main content
Uma versão mais recente deste produto está disponível.
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Remontar e reformatar volumes de armazenamento do appliance StorageGRID (etapas manuais)

PDFs

Você deve executar manualmente dois scripts para remontar os volumes de armazenamento preservados e reformatar quaisquer volumes de armazenamento com falha. O primeiro script remonta os volumes que estão formatados corretamente como volumes de armazenamento StorageGRID. O segundo script reformata quaisquer volumes desmontados, reconstrói o banco de dados Cassandra, se necessário, e inicia os serviços.

Antes de começar

  • Você já substituiu o hardware de todos os volumes de armazenamento com falha que você sabe que precisam ser substituídos.

    Executar o sn-remount-volumes script pode ajudar você a identificar volumes de armazenamento adicionais com falha.

  • Você verificou que a desativação de um Storage Node não está em andamento ou pausou o procedimento de desativação do nó. (No Grid Manager, selecione Maintenance > Tasks > Decommission.)

  • Você verificou se não há nenhuma expansão em andamento. (No Grid Manager, selecione Manutenção > Tarefas > Expansão.)

Cuidado Contate o suporte técnico se mais de um Storage Node estiver offline. Não execute o sn-recovery-postinstall.sh script.
Sobre esta tarefa

Para concluir este procedimento, você executa estas tarefas de alto nível:

  • Faça login no nó de armazenamento recuperado.

  • Execute o sn-remount-volumes script para remontar volumes de armazenamento formatados corretamente. Quando este script é executado, ele faz o seguinte:

    • Monta e desmonta cada volume de armazenamento para reproduzir o journal XFS.

    • Executa uma verificação de consistência do sistema de arquivos XFS.

    • Se o sistema de arquivos for consistente, determina se o volume de armazenamento é um volume de armazenamento StorageGRID formatado corretamente.

    • Se o volume de armazenamento estiver formatado corretamente, remonta o volume de armazenamento. Todos os dados existentes no volume permanecem intactos.

  • Analise a saída do script e resolva quaisquer problemas.

  • Execute o sn-recovery-postinstall.sh script. Quando este script for executado, ele faz o seguinte.

    Cuidado Não reinicialize um Storage Node durante a recuperação antes de executar sn-recovery-postinstall.sh (etapa 4) para reformatar os volumes de storage com falha e restaurar os metadados dos objetos. Reinicializar o Storage Node antes de sn-recovery-postinstall.sh concluir causa erros nos serviços que tentam iniciar e faz com que os nós do dispositivo StorageGRID saiam do modo de manutenção.

    • Reformata quaisquer volumes de armazenamento que o sn-remount-volumes script não conseguiu montar ou que foram encontrados formatados incorretamente.

      Observação Se um volume de armazenamento for reformatado, todos os dados nesse volume serão perdidos. Você deve executar um procedimento adicional para restaurar os dados do objeto de outros locais na grid, assumindo que as regras do ILM foram configuradas para armazenar mais de uma cópia do objeto.

    • Recria o banco de dados Cassandra no nó, se necessário.

    • Inicia os serviços no Storage Node.

Passos

  1. Faça login no nó de armazenamento recuperado:

    1. Digite o seguinte comando: ssh admin@grid_node_IP

    2. Digite a senha listada no arquivo Passwords.txt.

    3. Digite o seguinte comando para alternar para root: su -

    4. Digite a senha listada no arquivo Passwords.txt.

    Quando você está logado como root, o prompt muda de $ para #.

  2. Execute o primeiro script para remontar quaisquer volumes de armazenamento formatados corretamente.

    Observação Se todos os volumes de armazenamento forem novos e precisarem ser formatados, ou se todos os volumes de armazenamento apresentarem falha, você pode ignorar esta etapa e executar o segundo script para reformatar todos os volumes de armazenamento desmontados.

    1. Execute o script: sn-remount-volumes

      Este script pode levar horas para ser executado em volumes de storage que contenham dados.

    2. À medida que o script é executado, revise a saída e responda a quaisquer prompts.

      Observação Conforme necessário, você pode usar o tail -f comando para monitorar o conteúdo do arquivo de log (/var/local/log/sn-remount-volumes.log. O arquivo de log contém informações mais detalhadas do que a saída da linha de comando. 
      root@SG:~ # sn-remount-volumes
The configured LDR noid is 12632740

====== Device /dev/sdb ======
Mount and unmount device /dev/sdb and checking file system consistency:
The device is consistent.
Check rangedb structure on device /dev/sdb:
Mount device /dev/sdb to /tmp/sdb-654321 with rangedb mount options
This device has all rangedb directories.
Found LDR node id 12632740, volume number 0 in the volID file
Attempting to remount /dev/sdb
Device /dev/sdb remounted successfully

====== Device /dev/sdc ======
Mount and unmount device /dev/sdc and checking file system consistency:
Error: File system consistency check retry failed on device /dev/sdc.
You can see the diagnosis information in the /var/local/log/sn-remount-volumes.log.

This volume could be new or damaged. If you run sn-recovery-postinstall.sh, this volume and any data on this volume will be deleted. If you only had two copies of object data, you will temporarily have only a single copy.
StorageGRID will attempt to restore data redundancy by making additional replicated copies or EC fragments, according to the rules in the active ILM policies.

Don't continue to the next step if you believe that the data remaining on this volume can't be rebuilt from elsewhere in the grid (for example, if your ILM policy uses a rule that makes only one copy or if volumes have failed on multiple nodes). Instead, contact support to determine how to recover your data.

====== Device /dev/sdd ======
Mount and unmount device /dev/sdd and checking file system consistency:
Failed to mount device /dev/sdd
This device could be an uninitialized disk or has corrupted superblock.
File system check might take a long time. Do you want to continue? (y or n) [y/N]? y

Error: File system consistency check retry failed on device /dev/sdd.
You can see the diagnosis information in the /var/local/log/sn-remount-volumes.log.

This volume could be new or damaged. If you run sn-recovery-postinstall.sh, this volume and any data on this volume will be deleted. If you only had two copies of object data, you will temporarily have only a single copy.
StorageGRID will attempt to restore data redundancy by making additional replicated copies or EC fragments, according to the rules in the active ILM policies.

Don't continue to the next step if you believe that the data remaining on this volume can't be rebuilt from elsewhere in the grid (for example, if your ILM policy uses a rule that makes only one copy or if volumes have failed on multiple nodes). Instead, contact support to determine how to recover your data.

====== Device /dev/sde ======
Mount and unmount device /dev/sde and checking file system consistency:
The device is consistent.
Check rangedb structure on device /dev/sde:
Mount device /dev/sde to /tmp/sde-654321 with rangedb mount options
This device has all rangedb directories.
Found LDR node id 12000078, volume number 9 in the volID file
Error: This volume does not belong to this node. Fix the attached volume and re-run this script.

      No exemplo de saída, um volume de armazenamento foi remontado com sucesso e três volumes de armazenamento apresentaram erros.

      • /dev/sdb passou na verificação de consistência do sistema de arquivos XFS e possuía uma estrutura de volume válida, portanto foi remontado com sucesso. Os dados nos dispositivos remontados pelo script são preservados.

      • `/dev/sdc`Falha na verificação de consistência do sistema de arquivos XFS porque o volume de armazenamento era novo ou estava corrompido.

      • `/dev/sdd`Não foi possível montar o volume porque o disco não foi inicializado ou o superbloco do disco estava corrompido. Quando o script não consegue montar um volume de armazenamento, ele pergunta se você deseja executar a verificação de consistência do sistema de arquivos.

        • Se o volume de armazenamento estiver conectado a um novo disco, responda N à solicitação. Você não precisa verificar o sistema de arquivos em um novo disco.

        • Se o volume de armazenamento estiver conectado a um disco existente, responda S à solicitação. Você pode usar os resultados da verificação do sistema de arquivos para determinar a origem da corrupção. Os resultados são salvos no /var/local/log/sn-remount-volumes.log arquivo de log.

      • /dev/sde passou na verificação de consistência do sistema de arquivos XFS e tinha uma estrutura de volume válida; no entanto, o ID do nó LDR no arquivo volID não corresponde ao ID deste Storage Node (o configured LDR noid exibido na parte superior). Esta mensagem indica que este volume pertence a outro Storage Node.

  3. Analise a saída do script e resolva quaisquer problemas.

    Cuidado Se um volume de armazenamento falhar na verificação de consistência do sistema de arquivos XFS ou não puder ser montado, revise cuidadosamente as mensagens de erro na saída. Você precisa entender as implicações de executar o sn-recovery-postinstall.sh script nesses volumes.

    1. Verifique se os resultados incluem uma entrada para todos os volumes que você esperava. Se algum volume não estiver listado, execute o script novamente.

    2. Analise as mensagens de todos os dispositivos montados. Certifique-se de que não haja erros indicando que um volume de armazenamento não pertence a este Storage Node.

      No exemplo, a saída para /dev/sde inclui a seguinte mensagem de erro:

      Error: This volume does not belong to this node. Fix the attached volume and re-run this script.
      Cuidado Se um volume de armazenamento for reportado como pertencente a outro Storage Node, entre em contato com o suporte técnico. Se você executar o sn-recovery-postinstall.sh script, o volume de armazenamento será reformatado, o que pode causar perda de dados.

    3. Caso algum dispositivo de armazenamento não possa ser montado, anote o nome do dispositivo e repare ou substitua o dispositivo.

      Observação Você deve reparar ou substituir quaisquer dispositivos de armazenamento que não puderam ser montados.

      Você usará o nome do dispositivo para localizar o ID do volume, que é uma entrada necessária ao executar o script repair-data para restaurar os dados do objeto no volume (o próximo procedimento).

    4. Após reparar ou substituir todos os dispositivos que não podem ser desmontados, execute o sn-remount-volumes script novamente para confirmar que todos os volumes de armazenamento que podem ser remontados foram remontados.

      Cuidado Se um volume de armazenamento não puder ser montado ou estiver formatado incorretamente, e você prosseguir para a próxima etapa, o volume e quaisquer dados no volume serão excluídos. Se você tinha duas cópias dos dados do objeto, terá apenas uma cópia até concluir o próximo procedimento (restaurar os dados do objeto).
    Cuidado Não execute o sn-recovery-postinstall.sh script se você acreditar que os dados restantes em um volume de storage com falha não podem ser reconstruídos a partir de outro local na grid (por exemplo, se sua política ILM usa uma regra que cria apenas uma cópia ou se volumes falharam em vários nós). Em vez disso, entre em contato com o suporte técnico para determinar como recuperar seus dados.

  4. Execute o sn-recovery-postinstall.sh`script: `sn-recovery-postinstall.sh

    Este script reformata quaisquer volumes de armazenamento que não puderam ser montados ou que foram considerados formatados incorretamente; reconstrói o banco de dados Cassandra no nó, se necessário; e inicia os serviços no Storage Node.

    Esteja ciente do seguinte:

    • O script pode levar horas para ser executado.

    • Em geral, você deve deixar a sessão SSH sozinha enquanto o script estiver em execução.

    • Não pressione Ctrl+C enquanto a sessão SSH estiver ativa.

    • O script será executado em segundo plano caso ocorra uma interrupção na rede e a sessão SSH seja encerrada, mas você pode acompanhar o progresso na página de recuperação.

    • Se o nó de armazenamento usar o serviço RSM, o script pode parecer travado por 5 minutos enquanto os serviços do nó são reinicializados. Esse atraso de 5 minutos é esperado sempre que o serviço RSM for inicializado pela primeira vez.

      Observação O serviço RSM está presente nos nós de armazenamento que incluem o serviço ADC.
    Observação Alguns procedimentos de recuperação do StorageGRID usam o Reaper para lidar com os reparos do Cassandra. Os reparos ocorrem automaticamente assim que os serviços relacionados ou necessários são iniciados. Você pode notar saídas de script que mencionam "reaper" ou "reparo do Cassandra". Se você vir uma mensagem de erro indicando que o reparo falhou, execute o comando indicado na mensagem de erro.

  5. À medida que o `sn-recovery-postinstall.sh`script é executado, monitore a página de recuperação no Grid Manager.

    A barra de progresso e a coluna Etapa na página de recuperação fornecem um status de alto nível do `sn-recovery-postinstall.sh`script.

    captura de tela mostrando o progresso da recuperação na Interface de Gerenciamento de Rede

  6. Após o script sn-recovery-postinstall.sh iniciar os serviços no nó, você pode restaurar os dados de objetos em quaisquer volumes de armazenamento que foram formatados pelo script.

    O script pergunta se você deseja usar o processo de restauração de volume do Grid Manager.

    • Na maioria dos casos, você deve "Restaurar dados de objetos usando o Grid Manager". Responda y para usar o Gerenciador de Grade.

    • Em casos raros, como quando instruído pelo suporte técnico ou quando você sabe que o nó de substituição tem menos volumes disponíveis para storage de objetos do que o nó original, você deve "restaurar dados de objetos manualmente" usando o repair-data script. Se um desses casos se aplicar, responda n.

      Observação

      Se você responder n ao uso do processo de restauração de volume do Grid Manager (restaurar dados de objeto manualmente):

      • Você não pode restaurar dados de objetos usando o Grid Manager.

      • Você pode monitorar o progresso das tarefas de restauração manual usando o Grid Manager.

      Após selecionar a opção desejada, o script é concluído e as próximas etapas para recuperar os dados do objeto são exibidas. Após revisar essas etapas, pressione qualquer tecla para retornar à linha de comando.