Skip to main content
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Rimontare e riformattare i volumi di archiviazione (passaggi manuali)

PDF

È necessario eseguire manualmente due script per rimontare i volumi di archiviazione conservati e riformattare eventuali volumi di archiviazione non riusciti. Il primo script rimonta i volumi formattati correttamente come volumi di archiviazione StorageGRID . Il secondo script riformatta tutti i volumi non montati, ricostruisce Cassandra, se necessario, e avvia i servizi.

Prima di iniziare

  • Hai già sostituito l'hardware per tutti i volumi di archiviazione guasti che sai che necessitano di essere sostituiti.

    Esecuzione del sn-remount-volumes potrebbe aiutarti a identificare ulteriori volumi di archiviazione non riusciti.

  • Hai verificato che non è in corso la dismissione di un nodo di archiviazione oppure hai sospeso la procedura di dismissione del nodo. (Nel Grid Manager, seleziona MANUTENZIONE > Attività > Dismissione.)

  • Hai verificato che non è in corso un'espansione. (Nel Grid Manager, seleziona MANUTENZIONE > Attività > Espansione.)

  • Hai"esaminati gli avvisi per il ripristino dell'unità di sistema del nodo di archiviazione" .

    Avvertenza Contattare l'assistenza tecnica se più di un nodo di archiviazione è offline o se un nodo di archiviazione in questa griglia è stato ricostruito negli ultimi 15 giorni. Non eseguire il sn-recovery-postinstall.sh sceneggiatura. La ricostruzione di Cassandra su due o più nodi di archiviazione a distanza di 15 giorni l'uno dall'altro potrebbe comportare la perdita di dati.
Informazioni su questo compito

Per completare questa procedura, è necessario eseguire le seguenti attività di alto livello:

  • Accedere al nodo di archiviazione recuperato.

  • Esegui il sn-remount-volumes script per rimontare i volumi di archiviazione formattati correttamente. Quando questo script viene eseguito, esegue le seguenti operazioni:

    • Monta e smonta ciascun volume di archiviazione per riprodurre il journal XFS.

    • Esegue un controllo di coerenza del file XFS.

    • Se il file system è coerente, determina se il volume di archiviazione è un volume di archiviazione StorageGRID formattato correttamente.

    • Se il volume di archiviazione è formattato correttamente, rimonta il volume di archiviazione. Tutti i dati esistenti sul volume rimangono intatti.

  • Esaminare l'output dello script e risolvere eventuali problemi.

  • Esegui il sn-recovery-postinstall.sh sceneggiatura. Quando questo script viene eseguito, esegue le seguenti operazioni.

    Avvertenza Non riavviare un nodo di archiviazione durante il ripristino prima dell'esecuzione sn-recovery-postinstall.sh per riformattare i volumi di archiviazione danneggiati e ripristinare i metadati degli oggetti. Riavvio del nodo di archiviazione prima sn-recovery-postinstall.sh completa causa errori per i servizi che tentano di avviarsi e fa sì che i nodi dell'appliance StorageGRID escano dalla modalità di manutenzione. Vedi il passaggio perscript post-installazione .

    • Riformatta tutti i volumi di archiviazione che sn-remount-volumes script che non è stato possibile montare o che sono stati trovati formattati in modo non corretto.

      Nota Se un volume di archiviazione viene riformattato, tutti i dati presenti su quel volume andranno persi. È necessario eseguire una procedura aggiuntiva per ripristinare i dati degli oggetti da altre posizioni nella griglia, presupponendo che le regole ILM siano state configurate per archiviare più di una copia dell'oggetto.

    • Se necessario, ricostruisce il database Cassandra sul nodo.

    • Avvia i servizi sul nodo di archiviazione.

Passi

  1. Accedi al nodo di archiviazione recuperato:

    1. Immettere il seguente comando: ssh admin@grid_node_IP

    2. Inserisci la password elencata nel Passwords.txt file.

    3. Immettere il seguente comando per passare alla root: su -

    4. Inserisci la password elencata nel Passwords.txt file.

    Quando si accede come root, il prompt cambia da $ A # .

  2. Eseguire il primo script per rimontare tutti i volumi di archiviazione formattati correttamente.

    Nota Se tutti i volumi di archiviazione sono nuovi e devono essere formattati, oppure se tutti i volumi di archiviazione sono guasti, è possibile saltare questo passaggio ed eseguire il secondo script per riformattare tutti i volumi di archiviazione non montati.

    1. Esegui lo script: sn-remount-volumes

      L'esecuzione di questo script su volumi di archiviazione contenenti dati potrebbe richiedere ore.

    2. Durante l'esecuzione dello script, rivedere l'output e rispondere a eventuali richieste.

      Nota Se necessario, è possibile utilizzare il tail -f comando per monitorare il contenuto del file di registro dello script(/var/local/log/sn-remount-volumes.log ) . Il file di registro contiene informazioni più dettagliate rispetto all'output della riga di 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.

      Nell'output di esempio, un volume di archiviazione è stato rimontato correttamente e tre volumi di archiviazione presentavano errori.

      • `/dev/sdb`ha superato il controllo di coerenza del file system XFS e aveva una struttura del volume valida, quindi è stato rimontato correttamente. I dati sui dispositivi rimontati dallo script vengono conservati.

      • `/dev/sdc`il controllo di coerenza del file system XFS non è riuscito perché il volume di archiviazione era nuovo o danneggiato.

      • `/dev/sdd`non è stato possibile montarlo perché il disco non è stato inizializzato o il superblocco del disco è danneggiato. Quando lo script non riesce a montare un volume di archiviazione, chiede se si desidera eseguire il controllo di coerenza del file system.

        • Se il volume di archiviazione è collegato a un nuovo disco, rispondere N al prompt. Non è necessario controllare il file system su un nuovo disco.

        • Se il volume di archiviazione è collegato a un disco esistente, rispondere Y al prompt. È possibile utilizzare i risultati del controllo del file system per determinare l'origine del danneggiamento. I risultati vengono salvati nel /var/local/log/sn-remount-volumes.log file di registro.

      • /dev/sde`ha superato il controllo di coerenza del file system XFS e aveva una struttura del volume valida; tuttavia, l'ID del nodo LDR nel file volID non corrispondeva all'ID per questo nodo di archiviazione (il `configured LDR noid visualizzato in alto). Questo messaggio indica che questo volume appartiene a un altro nodo di archiviazione.

  3. Esaminare l'output dello script e risolvere eventuali problemi.

    Avvertenza Se un volume di archiviazione non ha superato il controllo di coerenza del file system XFS o non è stato possibile montarlo, esaminare attentamente i messaggi di errore nell'output. È necessario comprendere le implicazioni dell'esecuzione del sn-recovery-postinstall.sh sceneggiatura su questi volumi.

    1. Verificare che i risultati includano una voce per tutti i volumi previsti. Se non sono elencati volumi, eseguire nuovamente lo script.

    2. Esaminare i messaggi per tutti i dispositivi montati. Assicurarsi che non vi siano errori che indicano che un volume di archiviazione non appartiene a questo nodo di archiviazione.

      Nell'esempio, l'output per /dev/sde include il seguente messaggio di errore:

      Error: This volume does not belong to this node. Fix the attached volume and re-run this script.
      Avvertenza Se un volume di archiviazione viene segnalato come appartenente a un altro nodo di archiviazione, contattare l'assistenza tecnica. Se esegui il sn-recovery-postinstall.sh script, il volume di archiviazione verrà riformattato, il che potrebbe causare la perdita di dati.

    3. Se non è stato possibile montare un dispositivo di archiviazione, prendere nota del nome del dispositivo e ripararlo o sostituirlo.

      Nota È necessario riparare o sostituire tutti i dispositivi di archiviazione che non è stato possibile montare.

      Utilizzerai il nome del dispositivo per cercare l'ID del volume, che è un input obbligatorio quando esegui il repair-data script per ripristinare i dati dell'oggetto nel volume (procedura successiva).

    4. Dopo aver riparato o sostituito tutti i dispositivi non montabili, eseguire il sn-remount-volumes script di nuovo per confermare che tutti i volumi di archiviazione che possono essere rimontati siano stati rimontati.

      Avvertenza Se un volume di archiviazione non può essere montato o non è formattato correttamente e si procede con il passaggio successivo, il volume e tutti i dati in esso contenuti verranno eliminati. Se si dispone di due copie dei dati dell'oggetto, sarà disponibile una sola copia finché non si completa la procedura successiva (ripristino dei dati dell'oggetto).
    Avvertenza Non eseguire il sn-recovery-postinstall.sh script se ritieni che i dati rimanenti su un volume di archiviazione non riuscito non possano essere ricostruiti da nessun'altra parte nella griglia (ad esempio, se la policy ILM utilizza una regola che crea una sola copia o se i volumi sono falliti su più nodi). Contatta invece l'assistenza tecnica per scoprire come recuperare i tuoi dati.

  4. Esegui il sn-recovery-postinstall.sh sceneggiatura: sn-recovery-postinstall.sh

    Questo script riformatta tutti i volumi di archiviazione che non è stato possibile montare o che sono stati trovati formattati in modo non corretto; ricostruisce il database Cassandra sul nodo, se necessario; e avvia i servizi sul nodo di archiviazione.

    Siate consapevoli di quanto segue:

    • L'esecuzione dello script potrebbe richiedere ore.

    • In generale, è consigliabile lasciare inalterata la sessione SSH mentre lo script è in esecuzione.

    • Non premere Ctrl+C mentre la sessione SSH è attiva.

    • Lo script verrà eseguito in background se si verifica un'interruzione della rete e termina la sessione SSH, ma è possibile visualizzare l'avanzamento dalla pagina Ripristino.

    • Se il nodo di archiviazione utilizza il servizio RSM, lo script potrebbe bloccarsi per 5 minuti quando i servizi del nodo vengono riavviati. Questo ritardo di 5 minuti è previsto ogni volta che il servizio RSM viene avviato per la prima volta.

      Nota Il servizio RSM è presente sui nodi di archiviazione che includono il servizio ADC.
    Nota Alcune procedure di ripristino StorageGRID utilizzano Reaper per gestire le riparazioni di Cassandra. Le riparazioni vengono eseguite automaticamente non appena vengono avviati i servizi correlati o richiesti. Potresti notare che nell'output dello script viene menzionato "reaper" o "Cassandra repair". Se viene visualizzato un messaggio di errore che indica che la riparazione non è riuscita, eseguire il comando indicato nel messaggio di errore.

  5. Come il sn-recovery-postinstall.sh quando lo script viene eseguito, monitorare la pagina Ripristino in Grid Manager.

    La barra di avanzamento e la colonna Fase nella pagina Ripristino forniscono uno stato di alto livello del sn-recovery-postinstall.sh sceneggiatura.

    screenshot che mostra l'avanzamento del ripristino nell'interfaccia di gestione della griglia

  6. Dopo il sn-recovery-postinstall.sh Una volta che lo script ha avviato i servizi sul nodo, è possibile ripristinare i dati dell'oggetto su qualsiasi volume di archiviazione formattato dallo script.

    Lo script chiede se si desidera utilizzare il processo di ripristino del volume di Grid Manager.

    • Nella maggior parte dei casi, dovresti"ripristinare i dati degli oggetti utilizzando Grid Manager" . Risposta y per utilizzare Grid Manager.

    • In rari casi, ad esempio quando richiesto dal supporto tecnico o quando si sa che il nodo sostitutivo ha meno volumi disponibili per l'archiviazione degli oggetti rispetto al nodo originale, è necessario"ripristinare manualmente i dati dell'oggetto" utilizzando il repair-data sceneggiatura. Se si verifica uno di questi casi, rispondi n .

      Nota

      Se rispondi n per utilizzare il processo di ripristino del volume di Grid Manager (ripristinare manualmente i dati degli oggetti):

      • Non è possibile ripristinare i dati degli oggetti utilizzando Grid Manager.

      • È possibile monitorare l'avanzamento dei lavori di ripristino manuale utilizzando Grid Manager.

      Dopo aver effettuato la selezione, lo script viene completato e vengono visualizzati i passaggi successivi per recuperare i dati dell'oggetto. Dopo aver esaminato questi passaggi, premere un tasto qualsiasi per tornare alla riga di comando.