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.

Risolvere i problemi relativi ai metadati

Collaboratori

È possibile eseguire diverse attività per determinare l'origine dei problemi relativi ai metadati.

Avviso di spazio di archiviazione dei metadati insufficiente

Se viene attivato l'avviso Low metadata storage, è necessario aggiungere nuovi nodi di storage.

Prima di iniziare
A proposito di questa attività

StorageGRID riserva una certa quantità di spazio sul volume 0 di ciascun nodo di storage per i metadati dell'oggetto. Questo spazio è noto come spazio riservato effettivo e viene suddiviso nello spazio consentito per i metadati dell'oggetto (lo spazio consentito per i metadati) e nello spazio richiesto per le operazioni essenziali del database, come la compattazione e la riparazione. Lo spazio consentito per i metadati regola la capacità complessiva degli oggetti.

Volume spazio consentito metadati 0

Se i metadati degli oggetti consumano più del 100% dello spazio consentito per i metadati, le operazioni del database non possono essere eseguite in modo efficiente e si verificano errori.

È possibile "Monitorare la capacità dei metadati degli oggetti per ciascun nodo di storage" per aiutarti a prevenire gli errori e correggerli prima che si verifichino.

StorageGRID utilizza la seguente metrica Prometheus per misurare la quantità di spazio consentito per i metadati:

storagegrid_storage_utilization_metadata_bytes/storagegrid_storage_utilization_metadata_allowed_bytes

Quando l'espressione Prometheus raggiunge determinate soglie, viene attivato l'avviso Low metadata storage.

  • Minore: I metadati degli oggetti utilizzano almeno il 70% dello spazio consentito per i metadati. È necessario aggiungere nuovi nodi di storage il prima possibile.

  • Major: I metadati degli oggetti utilizzano almeno il 90% dello spazio consentito per i metadati. È necessario aggiungere immediatamente nuovi nodi di storage.

    Importante Quando i metadati dell'oggetto utilizzano almeno il 90% dello spazio consentito per i metadati, viene visualizzato un avviso sul dashboard. Se viene visualizzato questo avviso, è necessario aggiungere immediatamente nuovi nodi di storage. Non è mai necessario consentire ai metadati degli oggetti di utilizzare più del 100% dello spazio consentito.
  • Critico: I metadati degli oggetti utilizzano almeno il 100% dello spazio consentito e stanno iniziando a consumare lo spazio necessario per le operazioni essenziali del database. È necessario interrompere l'acquisizione di nuovi oggetti e aggiungere immediatamente nuovi nodi di storage.

Nell'esempio seguente, i metadati degli oggetti utilizzano oltre il 100% dello spazio consentito per i metadati. Si tratta di una situazione critica, che può causare errori e operazioni inefficienti del database.

Allarme dashboard metadati
Importante Se la dimensione del volume 0 è inferiore all'opzione di storage Metadata Reserved Space (ad esempio, in un ambiente non in produzione), il calcolo dell'avviso Low metadata storage potrebbe essere impreciso.
Fasi
  1. Selezionare ALERTS > current.

  2. Dalla tabella degli avvisi, espandere il gruppo di avvisi Low metadata storage, se necessario, e selezionare l'avviso specifico che si desidera visualizzare.

  3. Esaminare i dettagli nella finestra di dialogo degli avvisi.

  4. Se è stato attivato un avviso importante o critico Low metadata storage, eseguire un'espansione per aggiungere immediatamente i nodi di storage.

    Nota Poiché StorageGRID conserva copie complete di tutti i metadati degli oggetti in ogni sito, la capacità dei metadati dell'intera griglia è limitata dalla capacità dei metadati del sito più piccolo. Se devi aggiungere capacità di metadati a un sito, dovresti anche "espandere qualsiasi altro sito" Dello stesso numero di nodi di storage.

    Dopo aver eseguito l'espansione, StorageGRID ridistribuisce i metadati degli oggetti esistenti nei nuovi nodi, aumentando così la capacità complessiva dei metadati della griglia. Non è richiesta alcuna azione da parte dell'utente. L'avviso Low metadata storage viene cancellato.

Servizi: Stato - allarme Cassandra (SVST)

L'allarme servizi: Stato - Cassandra (SVST) indica che potrebbe essere necessario ricostruire il database Cassandra per un nodo di storage. Cassandra viene utilizzato come archivio di metadati per StorageGRID.

Prima di iniziare
  • È necessario accedere a Grid Manager utilizzando un "browser web supportato".

  • È necessario disporre di autorizzazioni di accesso specifiche.

  • È necessario disporre di Passwords.txt file.

A proposito di questa attività

Se Cassandra viene arrestato per più di 15 giorni (ad esempio, il nodo di storage viene spento), Cassandra non si avvia quando il nodo viene riportato in linea. È necessario ricostruire il database Cassandra per il servizio DDS interessato.

È possibile "eseguire la diagnostica" per ottenere ulteriori informazioni sullo stato corrente della griglia.

Importante Se due o più servizi di database Cassandra rimangono inutilizzati per più di 15 giorni, contattare il supporto tecnico e non procedere con la procedura riportata di seguito.
Fasi
  1. Selezionare SUPPORT > Tools > Grid topology.

  2. Selezionare Site > Storage Node > SSM > Services > Alarms > Main per visualizzare gli allarmi.

    Questo esempio mostra che l'allarme SVST è stato attivato.

    Allarmi: SSM: Pagina dei servizi

    La pagina principale dei servizi SSM indica inoltre che Cassandra non è in esecuzione.

    Panoramica: SSM: Pagina dei servizi
  3. prova a riavviare Cassandra dal nodo di storage:

    1. Accedere al nodo Grid:

      1. Immettere il seguente comando: ssh admin@grid_node_IP

      2. Immettere la password elencata in Passwords.txt file.

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

      4. Immettere la password elencata in Passwords.txt file. Una volta effettuato l'accesso come root, il prompt cambia da $ a. #.

    2. Inserire: /etc/init.d/cassandra status

    3. Se Cassandra non è in esecuzione, riavviarlo: /etc/init.d/cassandra restart

  4. Se Cassandra non si riavvia, determinare per quanto tempo Cassandra è rimasto inattivo. Se Cassandra è rimasto inattivo per più di 15 giorni, è necessario ricostruire il database Cassandra.

    Importante Se due o più servizi di database Cassandra non sono disponibili, contattare il supporto tecnico e non procedere con la procedura riportata di seguito.

    È possibile determinare per quanto tempo Cassandra è rimasta inattiva, inserendolo nella cartella o esaminando il file servermanager.log.

  5. Per inserire il grafico Cassandra:

    1. Selezionare SUPPORT > Tools > Grid topology. Quindi selezionare Site > Storage Node > SSM > servizi > Report > grafici.

    2. Selezionare attributo > Servizio: Stato - Cassandra.

    3. Per Data di inizio, immettere una data che sia almeno 16 giorni prima della data corrente. Per Data di fine, inserire la data corrente.

    4. Fare clic su Aggiorna.

    5. Se il grafico mostra Cassandra come inattivo per più di 15 giorni, ricostruire il database Cassandra.

      L'esempio seguente mostra che Cassandra è rimasta inattiva per almeno 17 giorni.

    Panoramica: SSM: Pagina dei servizi
  6. Per esaminare il file servermanager.log sul nodo di storage:

    1. Accedere al nodo Grid:

      1. Immettere il seguente comando: ssh admin@grid_node_IP

      2. Immettere la password elencata in Passwords.txt file.

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

      4. Immettere la password elencata in Passwords.txt file. Una volta effettuato l'accesso come root, il prompt cambia da $ a. #.

    2. Inserire: cat /var/local/log/servermanager.log

      Viene visualizzato il contenuto del file servermanager.log.

      Se Cassandra rimane inattivo per più di 15 giorni, nel file servermanager.log viene visualizzato il seguente messaggio:

    "2014-08-14 21:01:35 +0000 | cassandra | cassandra not
    started because it has been offline for longer than
    its 15 day grace period - rebuild cassandra
    1. Assicurarsi che la data e l'ora del messaggio siano quelle in cui si è tentato di riavviare Cassandra, come indicato al punto Riavviare Cassandra dal nodo di storage.

      Per Cassandra possono essere presenti più voci; è necessario individuare la voce più recente.

    2. Se Cassandra è rimasto inattivo per più di 15 giorni, è necessario ricostruire il database Cassandra.

    3. Contattare il supporto tecnico se gli allarmi non vengono disattivati dopo la ricostruzione di Cassandra.

Errori di memoria esaurita di Cassandra (allarme SMTT)

Un allarme SMTT (Total Events) viene attivato quando il database Cassandra presenta un errore di memoria esaurita. Se si verifica questo errore, contattare il supporto tecnico per risolvere il problema.

A proposito di questa attività

Se si verifica un errore di memoria insufficiente per il database Cassandra, viene creato un dump heap, viene attivato un allarme SMTT (Total Events) e il conteggio degli errori Cassandra Heap out of Memory viene incrementato di uno.

Fasi
  1. Per visualizzare l'evento, selezionare SUPPORT > Tools > Grid topology > Configuration.

  2. Verificare che il conteggio degli errori di memoria esaurita di Cassandra sia pari o superiore a 1.

    È possibile "eseguire la diagnostica" per ottenere ulteriori informazioni sullo stato corrente della griglia.

  3. Passare a. /var/local/core/, comprimere Cassandra.hprof e inviarla al supporto tecnico.

  4. Eseguire un backup di Cassandra.hprof ed eliminarlo da /var/local/core/ directory.

    Questo file può avere una dimensione massima di 24 GB, quindi è necessario rimuoverlo per liberare spazio.

  5. Una volta risolto il problema, selezionare la casella di controllo Reset (Ripristina) per il conteggio degli errori Cassandra Heap out of Memory (heap Cassandra fuori memoria). Quindi selezionare Apply Changes (Applica modifiche).

    Nota Per reimpostare i conteggi degli eventi, è necessario disporre dell'autorizzazione di configurazione della pagina topologia griglia.