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.

Restaurar dados de objetos para um volume de armazenamento, se necessário

Colaboradores

Se o sn-recovery-postinstall.sh script for necessário para reformatar um ou mais volumes de storage com falha, você deverá restaurar os dados de objeto para o volume de storage reformatado de outros nós de storage e nós de arquivamento. Essas etapas não são necessárias a menos que um ou mais volumes de armazenamento tenham sido reformatados.

O que você vai precisar
  • Você deve ter confirmado que o nó de armazenamento recuperado tem um estado de conexão de Connected*ícone alerta verde marca de verificação na guia *Nodes Overview no Gerenciador de Grade.

Sobre esta tarefa

Os dados de objetos podem ser restaurados de outros nós de storage, um nó de arquivamento ou um pool de storage de nuvem, supondo que as regras de ILM da grade tenham sido configuradas de modo que as cópias de objetos estejam disponíveis.

Importante Se uma regra ILM foi configurada para armazenar apenas uma cópia replicada e essa cópia existia em um volume de armazenamento que falhou, você não poderá recuperar o objeto.
Importante Se a única cópia restante de um objeto estiver em um pool de armazenamento em nuvem, o StorageGRID deverá emitir várias solicitações ao endpoint do pool de armazenamento em nuvem para restaurar os dados do objeto. Antes de executar esse procedimento, entre em Contato com o suporte técnico para obter ajuda na estimativa do período de tempo de recuperação e dos custos associados.
Observação Se a única cópia restante de um objeto estiver em um nó de arquivo, os dados do objeto serão recuperados do nó de arquivo. Devido à latência associada a recuperações de sistemas de storage de arquivamento externo, a restauração de dados de objetos para um nó de storage a partir de um nó de arquivamento demora mais do que a restauração de cópias de outros nós de storage.

Para restaurar os dados do objeto, execute o repair-data script. Este script inicia o processo de restauração de dados de objeto e trabalha com a digitalização ILM para garantir que as regras ILM sejam atendidas. Você usa opções diferentes com o repair-data script, com base se você está restaurando dados replicados ou apagando dados codificados, como segue:

  • Dados replicados: Dois comandos estão disponíveis para restaurar dados replicados, com base se você precisa reparar o nó inteiro ou apenas determinados volumes no nó:

    repair-data start-replicated-node-repair
    repair-data start-replicated-volume-repair
  • Dados codificados de apagamento (EC): Dois comandos estão disponíveis para restaurar dados codificados de apagamento, com base se você precisa reparar o nó inteiro ou apenas determinados volumes no nó:

    repair-data start-ec-node-repair
    repair-data start-ec-volume-repair

    As reparações de dados codificados de apagamento podem começar enquanto alguns nós de storage estão offline. O reparo será concluído depois que todos os nós estiverem disponíveis. Você pode rastrear reparos de dados codificados de apagamento com este comando:

    repair-data show-ec-repair-status
Observação O trabalho de reparação EC reserva temporariamente uma grande quantidade de armazenamento. Os alertas de armazenamento podem ser acionados, mas serão resolvidos quando o reparo for concluído. Se não houver armazenamento suficiente para a reserva, o trabalho de reparação EC falhará. As reservas de armazenamento são liberadas quando o trabalho de reparação EC é concluído, quer o trabalho tenha falhado ou sido bem-sucedido.

Para obter mais informações sobre como usar o repair-data script, digite repair-data --help a partir da linha de comando do nó Admin principal.

Passos
  1. Faça login no nó de administração principal:

    1. Introduza o seguinte comando: ssh admin@primary_Admin_Node_IP

    2. Introduza a palavra-passe listada no Passwords.txt ficheiro.

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

    4. Introduza a palavra-passe listada no Passwords.txt ficheiro.

      Quando você estiver conetado como root, o prompt mudará de $ para #.

  2. Use o /etc/hosts arquivo para encontrar o nome do host do nó de armazenamento para os volumes de armazenamento restaurados. Para ver uma lista de todos os nós na grade, digite o seguinte: cat /etc/hosts

  3. Se todos os volumes de armazenamento tiverem falhado, repare o nó inteiro. (Se apenas alguns volumes tiverem falhado, avance para o passo seguinte.)

    Importante Não é possível executar repair-data operações para mais de um nó ao mesmo tempo. Para recuperar vários nós, entre em Contato com o suporte técnico.
    • Se sua grade incluir dados replicados, use o repair-data start-replicated-node-repair comando com a --nodes opção para reparar todo o nó de armazenamento.

      Este comando repara os dados replicados em um nó de storage chamado SG-DC-SN3:

      repair-data start-replicated-node-repair --nodes SG-DC-SN3
      Observação À medida que os dados de objeto são restaurados, o alerta objetos perdidos é acionado se o sistema StorageGRID não conseguir localizar dados de objeto replicados. Os alertas podem ser acionados em nós de storage em todo o sistema. Você deve determinar a causa da perda e se a recuperação é possível. Consulte as instruções para monitoramento e solução de problemas do StorageGRID.
    • Se sua grade contiver dados codificados de apagamento, use o repair-data start-ec-node-repair comando com a --nodes opção para reparar todo o nó de armazenamento.

      Este comando repara os dados codificados de apagamento em um nó de storage chamado SG-DC-SN3:

      repair-data start-ec-node-repair --nodes SG-DC-SN3

      A operação retorna um único repair ID que identifica esta repair_data operação. Utilize esta repair ID opção para monitorizar o progresso e o resultado repair_data da operação. Nenhum outro feedback é retornado à medida que o processo de recuperação é concluído.

    Observação As reparações de dados codificados de apagamento podem começar enquanto alguns nós de storage estão offline. O reparo será concluído depois que todos os nós estiverem disponíveis.
    • Se a grade tiver dados replicados e codificados para apagamento, execute os dois comandos.

  4. Se apenas alguns dos volumes tiverem falhado, repare os volumes afetados.

    Introduza as IDs de volume em hexadecimal. Por exemplo, 0000 é o primeiro volume e 000F é o décimo sexto volume. Você pode especificar um volume, um intervalo de volumes ou vários volumes que não estão em uma sequência.

    Todos os volumes devem estar no mesmo nó de storage. Se precisar restaurar volumes para mais de um nó de storage, entre em Contato com o suporte técnico.

    • Se a grade contiver dados replicados, use o start-replicated-volume-repair comando com a --nodes opção para identificar o nó. Em seguida, adicione a --volumes opção ou --volume-range, como mostrado nos exemplos a seguir.

      • Volume único*: Este comando restaura dados replicados para o volume 0002 em um nó de armazenamento chamado SG-DC-SN3:

        repair-data start-replicated-volume-repair --nodes SG-DC-SN3 --volumes 0002

        Intervalo de volumes: Este comando restaura dados replicados para todos os volumes no intervalo 0003 para 0009 um nó de armazenamento chamado SG-DC-SN3:

        repair-data start-replicated-volume-repair --nodes SG-DC-SN3 --volume-range 0003-0009

        Vários volumes não em uma sequência: Este comando restaura dados replicados para volumes 0001, 0005 e 0008 em um nó de armazenamento chamado SG-DC-SN3:

      repair-data start-replicated-volume-repair --nodes SG-DC-SN3 --volumes 0001,0005,0008

      +

      Observação À medida que os dados de objeto são restaurados, o alerta objetos perdidos é acionado se o sistema StorageGRID não conseguir localizar dados de objeto replicados. Os alertas podem ser acionados em nós de storage em todo o sistema. Você deve determinar a causa da perda e se a recuperação é possível. Consulte as instruções para monitoramento e solução de problemas do StorageGRID.
    • Se sua grade contiver dados codificados de apagamento, use o start-ec-volume-repair comando com a --nodes opção para identificar o nó. Em seguida, adicione a --volumes opção ou --volume-range, como mostrado nos exemplos a seguir.

      • Volume único*: Este comando restaura os dados codificados de apagamento para o volume 0007 em um nó de armazenamento chamado SG-DC-SN3:

        repair-data start-ec-volume-repair --nodes SG-DC-SN3 --volumes 0007

        Intervalo de volumes: Este comando restaura os dados codificados de apagamento para todos os volumes no intervalo 0004 para 0006 um nó de armazenamento chamado SG-DC-SN3:

        repair-data start-ec-volume-repair --nodes SG-DC-SN3 --volume-range 0004-0006

        Vários volumes não em uma sequência: Este comando restaura dados codificados de apagamento para volumes 000A, 000C e 000E em um nó de armazenamento chamado SG-DC-SN3:

      repair-data start-ec-volume-repair --nodes SG-DC-SN3 --volumes 000A,000C,000E

      + A repair-data operação retorna um único repair ID que identifica esta repair_data operação. Utilize esta repair ID opção para monitorizar o progresso e o resultado repair_data da operação. Nenhum outro feedback é retornado à medida que o processo de recuperação é concluído.

    Observação As reparações de dados codificados de apagamento podem começar enquanto alguns nós de storage estão offline. O reparo será concluído depois que todos os nós estiverem disponíveis.
    • Se a grade tiver dados replicados e codificados para apagamento, execute os dois comandos.

  5. Monitore o reparo de dados replicados.

    1. Selecione nós nó de armazenamento a ser reparado ILM.

    2. Utilize os atributos na secção avaliação para determinar se as reparações estão concluídas.

      Quando os reparos estiverem concluídos, o atributo aguardando - todos indica objetos 0D.

    3. Para monitorar o reparo com mais detalhes, selecione suporte Ferramentas topologia de grade.

    4. Selecione Grid Storage Node a ser reparado LDR Data Store.

    5. Use uma combinação dos seguintes atributos para determinar, assim como possível, se as reparações replicadas estão concluídas.

      Observação As inconsistências do Cassandra podem estar presentes e as reparações falhadas não são rastreadas.
      • * Tentativas de reparos (XRPA): Use este atributo para rastrear o progresso de reparos replicados. Esse atributo aumenta cada vez que um nó de storage tenta reparar um objeto de alto risco. Quando este atributo não aumenta por um período superior ao período de digitalização atual (fornecido pelo atributo *período de digitalização — estimado), significa que a digitalização ILM não encontrou objetos de alto risco que precisam ser reparados em nenhum nó.

        Observação Objetos de alto risco são objetos que correm o risco de serem completamente perdidos. Isso não inclui objetos que não satisfazem sua configuração ILM.
      • Período de digitalização — estimado (XSCM): Use este atributo para estimar quando uma alteração de política será aplicada a objetos ingeridos anteriormente. Se o atributo Repairs tented não aumentar durante um período superior ao período de digitalização atual, é provável que sejam efetuadas reparações replicadas. Note que o período de digitalização pode mudar. O atributo período de digitalização — estimado (XSCM) aplica-se a toda a grade e é o máximo de todos os períodos de varredura de nós. Você pode consultar o histórico de atributos período de digitalização — estimado para a grade para determinar um período de tempo apropriado.

  6. Monitore o reparo de dados codificados de apagamento e tente novamente quaisquer solicitações que possam ter falhado.

    1. Determinar o status dos reparos de dados codificados de apagamento:

      • Use este comando para ver o status de uma operação específica repair-data:

        repair-data show-ec-repair-status --repair-id repair ID
      • Utilize este comando para listar todas as reparações:

        repair-data show-ec-repair-status

        A saída lista informações, `repair ID`incluindo , para todas as reparações anteriores e atualmente em execução.

      root@DC1-ADM1:~ # repair-data show-ec-repair-status
      
      Repair ID Scope Start Time End Time State Est Bytes Affected/Repaired Retry Repair
      ==================================================================================
      949283 DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:27:06.9 Success 17359 17359 No
      949292 DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:37:06.9 Failure 17359 0 Yes
      949294 DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:47:06.9 Failure 17359 0 Yes
      949299 DC1-S-99-10(Volumes: 1,2) 2016-11-30T15:57:06.9 Failure 17359 0 Yes
    2. Se a saída mostrar que a operação de reparo falhou, use a --repair-id opção para tentar novamente a reparação.

      Este comando tenta novamente um reparo de nó com falha, usando a ID de reparo 83930030303133434:

      repair-data start-ec-node-repair --repair-id 83930030303133434

      Este comando tenta novamente uma reparação de volume com falha, utilizando a ID de reparação 83930030303133434:

    repair-data start-ec-volume-repair --repair-id 83930030303133434
Informações relacionadas

"Administrar o StorageGRID"