Avamar: Partizioni sospese, stripe ed errori hfscheck su Avamar

1. Il seguente errore potrebbe essere visualizzato nell'interfaccia utente di Avamar Administrator Server. Il messaggio può generare una richiesta di servizio Dial Home (SR):

Symptom Code: 22632, Desc: A server disk has become suspended.

2. Messaggi WARN relativi a perfbeat vengono segnalati sui nodi di storage dei dati nel /data01/cur/gsan.log:

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66
WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended
WARN: <1084> changing disk 0 on node 0.3 to suspended state

3. La colonna status.dpn l'output mostra che un disco ha stripes suspended:
(questo output viene prodotto solo quando si verifica "WARN <1084>".)

Esempio:

0.8 10.10.10.10 7.3.1-125 ONLINE fullaccess mhpu+0hpu+0hpu 1 false 7.36 16350564 3401334 56.0% 66%(onl:1,SUS:2374) 50%(onl:2439) 50%(onl:2433) 

Questo output mostra che ci sono 2.374 stripe sospese.

4. La colonna hfscheck fallisce se una partizione viene sospesa mentre il hfscheck è in esecuzione. Un esempio di errore tratto da /data01/hfscheck/err.log oppure /data01/cur/err.log sono: 

ERROR: <0001> indexstripe::hfschecksweepbody stripe=0.0-1209 proxy=0.0-1209 indexelem([hash=ee9b2fe66b4bd472e28c4f41c5097dbeaba7131a stripe=0.1-DF8 offset=1285]) goodowner=true goodelem=false

Periodicamente, ogni cinque minuti per impostazione predefinita, il gsan "testa" il I/O eseguendo piccole letture dalle partizioni dati.

Verifica se le prestazioni di lettura sono pari al 10% rispetto alle prestazioni normali.

Nell'esempio riportato di seguito il messaggio indica che, nel nodo specifico che ha generato il messaggio di avviso, le prestazioni medie di lettura in un numero esteso di prove mentre hfscheck era in esecuzione è di circa 54,03 MB/secondo. Tuttavia, in questo particolare test, le prestazioni effettive sono state di 0,57 MB/secondo, che è al di sotto del "limite" del 10% del valore medio, o 5,4029 MB/secondo.

Event Summary = perfbeat::outoftolerance mask=[hfscheck] average=54.03 limit=5.4029 mbpersec=0.57

Lo scopo originale di questo test era quello di avvisare che c'era qualche problema con il I/O Sottosistema che causa un eccessivo rallentamento delle prestazioni di lettura. 

In questo caso, più lento del 10% del disco "medio" I/O Prestazione.

La colonna perftriallimit Specifica il numero di test consecutivi di lettura del disco che devono essere fuori tolleranza prima di perfbeat Sospetta che un disco possa essere danneggiato.

La colonna perfinterval (impostazione predefinita: 300 secondi o 5 minuti) Specifica il tempo di attesa tra un operazione e l'altra. perftriallimit test.

Quando perfbeat sospetta che un disco sia danneggiato, lo dice al gsan per raggiungere uno stato inattivo (interrompere tutte le attività relative al disco). 

Attende al massimo 20 minuti (cablato) per il gsan per raggiungere questo stato prima del timeout e non sospendere il disco.

Se viene raggiunto lo stato a freddo, perfbeat Esegue perfcoldtriallimit (Impostazione predefinita 4) Più test di lettura distanziati perfcoldinterval (impostazione predefinita: 30) secondi di distanza.

Solo se tutti questi test indicano che il disco è ancora danneggiato, il disco verrà sospeso.

Possibili cause dei dischi sospesi:

• Quando si tenta di raggiungere uno stato freddo, il gsan attende sempre almeno un minuto (cablato). Attende anche tutti i dischi gsan in sospeso I/O attività connesse per completarne o sospenderne il funzionamento. Tuttavia, dopo aver raggiunto uno stato di raffreddamento, il sistema operativo potrebbe continuare a funzionare su disco I/O, come ad esempio svuotare la sua cache. Questa attività di svuotamento è una possibile spiegazione del motivo per cui i dischi vengono sospesi inutilmente. Con le maggiori quantità di memoria, possono esserci molti più dati della cache da svuotare.

• Un'altra possibile spiegazione è che le informazioni sulla cronologia delle prestazioni non prevedono in modo accurato quali dovrebbero essere le prestazioni di lettura del disco previste durante vari periodi di gsan attività in quanto il gsan's Il comportamento è cambiato troppo rapidamente perché la cronologia possa rifletterlo (la cronologia è una media degli ultimi 10 giorni di misurazioni delle prestazioni).

• Un'altra possibile spiegazione è che potrebbe esserci un problema, come la mancata attesa di tutti gsan disco I/O attività per completarne o sospenderne il funzionamento prima di raggiungere uno stato di raffreddamento.

Inoltre, la ricerca ha dimostrato che durante il hfscheck ".indexsweep" (quando tutti gli hash negli stripe di indice vengono letti e quindi si eseguono scritture casuali massicce su molti file DRL (Data Referenced Log)) il test I/O Le prestazioni calano per un periodo di tempo significativo.

Su Avamar Data Store Gen4, Gen4s e Gen4T, le operazioni di scrittura hanno avuto la priorità rispetto alle operazioni di lettura e l'importanza di testare le prestazioni di lettura di I/O sottosistema è molto più basso. Inoltre, alcune unità (come Seagate Megalodon utilizzare alcune tecniche diverse che possono confondere i test eseguiti con quelli del perfbeat filo.

Informazioni preliminari:

In genere ci sono tre diversi messaggi di avvertenza visualizzati nella finestra gsan Registri:

WARN: <0968> perfbeat::outoftolerance mbpersec=0.31 average=5.66

L'avviso <0968> indica che c'era un individuo gsan I/O test che era lento.

Questo errore può essere tranquillamente ignorato.

WARN: <1051> tperfstatechanger::execute server_exception(MSG_ERR_UNNECESSARY) diskid=0 newstate=suspended

L'avviso <1051> indica che le letture lente sono state sufficienti gsan Si è preso in considerazione l'inserimento della partizione dati nello stato Suspended, ma si è deciso di non farlo. Questo è ciò che indica MSG_ERR_UNNECESSARY.

Questo errore può essere tranquillamente ignorato.

WARN: <1084> changing disk 0 on node 0.3 to suspended state

L'avviso <1084> indica che gsan ha messo la partizione dati in uno "stato sospeso".

Questo messaggio non deve essere ignorato.

Risoluzione:

Se gli stripe vengono messi in uno stato di sospensione, utilizzare le seguenti linee guida per analizzare e correggere i seguenti scenari:

Effettuare le seguenti operazioni per identificare la posizione della partizione sospesa:

1. Accedere ad Avamar Utility Node come amministratore.

2. Eleva al privilegio root.

3. Caricare le chiavi root per Avamar: Come accedere a un Avamar Server e caricare varie chiavi. (In inglese)

4. Eseguire il seguente comando per identificare la posizione della partizione sospesa:

mapall --noerror 'grep -i "suspended" /data01/cur/err.log'

5. Esamina gli scenari in base ai risultati riportati sopra:

• • Non sono necessarie altre operazioni. Gli Stripe tornano online automaticamente. È molto probabile che hfscheck stavano correndo. 

• • Se gli stripe tornano online automaticamente, è molto probabile che la garbage collection o hfscheck stavano correndo.
  • IMPORTANTE: Potrebbe trattarsi di un problema del disco o di un problema sottostante.
  • Anche se l'unità non è ancora guasta, è comunque necessario verificarla utilizzando la procedura riportata di seguito:

1. Determinare quali dischi fisici sono associati al disco sospeso da Avamar. I problemi con la sospensione del disco fisico all'interno di un disco virtuale potrebbero essere una root cause di una sospensione:

avsysreport pdisk vdisk=x 

Dove x è il numero del disco virtuale (partizione dati) che è stato sospeso. Ad esempio, se la prima partizione di dati mostra stripe sospese, eseguire una query vdis=0.

2. Verificare che non vi siano errori del disco, errori previsti o altri errori a livello di disco fisico.

3. Verificare che non siano presenti errori SCSI sui dischi fisici che rappresentano il disco virtuale sul nodo in questione (determinato nel passaggio 1). 

grep -i "MRMON\|scsi|Adaptec" /var/log/messages

4. I dischi virtuali in modalità Write Through possono causare sospensioni del disco a causa di I/O. Controllare la policy di scrittura sul controller:

mapall --noerror --all+ 'avsysreport vdisk | grep "Write Policy"'  

Se nei passaggi da 2 a 4 vengono rilevati problemi, aprire una SR con il supporto Dell Technologies Avamar per ulteriori indagini.

Scenario# 3: Rivedere l'impostazione predefinita perftriallimit Impostazioni:

1. Verificare che la cartella perftriallimit è impostato su 0:

avmaint config --ava | grep perftriallimit 

perftriallimit="0"

2. Se perftriallimit è diverso da zero:

avmaint config --ava perftriallimit=0

avmaint config --ava | grep perftriallimit 

perftriallimit="0"