PowerScale: Job-Engine-Datenbank meldet Sperrung oder lange Wartezeit auf die Nachfolge

Jobs wechseln mehrmals in den Wartestatus.

Die Datenbankaktualisierungen nehmen viel Zeit in Anspruch.

Im isi_job_d.log und messages.logwerden häufig Meldungen zu langen Wartezeiten, Datenbanksperren und möglichen Job-Coordinator-Jumping-Nodes angezeigt.

Symptom 1:
isi_job_d.log meldet eine lange Wartezeit auf ein erfolgreiches Update:

isi_job_d[45179]: Reports database update (job state) succeeded but took 11272 ms

Symptom 2:
isi_job_d.log Berichtsdatenbank ist gesperrt:

isi_job_d[97274]: Failed to update Jobs (state): database is locked

Symptom 3: 
Der Job Coordinator wechselt regelmäßig die Nodes:

2018-05-02T02:00:48Z <24.5> cluster01-39(id58) cluster01-39 isi_job_d[31517]: Becoming job engine coordinator
2018-05-02T02:11:26Z <24.5> cluster01-33(id52) cluster01-33 isi_job_d[36865]: Becoming job engine coordinator
2018-05-02T02:25:39Z <24.5> cluster01-33(id52) cluster01-33 isi_job_d[37310]: Becoming job engine coordinator
2018-05-02T02:36:25Z <24.5> cluster01-37(id56) cluster01-37 isi_job_d[77098]: Becoming job engine coordinator
2018-05-02T02:38:24Z <24.5> cluster01-37(id56) cluster01-37 isi_job_d[77167]: Becoming job engine coordinator
2018-05-02T02:43:33Z <24.5> cluster01-39(id58) cluster01-39 isi_job_d[32917]: Becoming job engine coordinator
2018-05-02T02:59:58Z <24.5> cluster01-39(id58) cluster01-39 isi_job_d[33518]: Becoming job engine coordinator
2018-05-02T03:02:44Z <24.5> cluster01-39(id58) cluster01-39 isi_job_d[33782]: Becoming job engine coordinator
2018-05-02T03:08:02Z <24.5> cluster01-39(id58) cluster01-39 isi_job_d[33969]: Becoming job engine coordinator

1. Die Job-Engine-Berichtsdatenbank (reports.db) wird aufgrund eines lang andauernden Auftrags, der viele Aktualisierungen generiert, ständig aktualisiert.
2. Jede Aktualisierung der Datei erfolgt sechsmal im gesamten Cluster. Durch das Senken des Schutzlevels werden die Updates anscheinend schneller.
3. Abhängig von der Dauer der Pause in isi_papi_dwählen, erwarten Sie, dass der Koordinator beim Schreiben in die Datenbank (Protokollierung) ein Timeout aufweist. Es kann auch erfolgreich sein, aber protokollieren, dass der Schreibvorgang länger als gewünscht gedauert hat, protokollieren bei isi_job_d.log in beiden Fällen.

isi get -DD /ifs/.ifsvar/modules/jobengine/reports.db

cluster01-16# isi get -DD /ifs/.ifsvar/modules/jobengine/reports.db
POLICY   W   LEVEL PERFORMANCE COAL  ENCODING      FILE              IADDRS
8x        8     6x concurrency off   UTF-8         reports.db        <25,14,1575794508288:512>, <26,17,484528026624:512>, <26,31,924241684480:512>, <27,31,145164204544:512>, <28,30,2451893562880:512>, <29,29,6440579584:512> ct: 1506750730 rt: 0
*************************************************
* IFS inode: [ 25,14,1575794508288:512, 26,17,484528026624:512, 26,31,924241684480:512, 27,31,145164204544:512, 28,30,2451893562880:512, 29,29,6440579584:512 ]
*************************************************
...
*  Protection Policy:  8x
*  Target Protection:  6x                  <-- six times protection

Die technische Abteilung von Dell untersucht das Problem. Dieser Artikel wird aktualisiert, sobald weitere Informationen verfügbar sind.

Um dieses Problem zu umgehen, führen Sie den folgenden Befehl aus, um das Schutzlevel der Jobberichtsdatenbank wie folgt zu ändern:

1. Halten Sie alle ausgeführten Jobs an. Stellen Sie sicher, dass keine Jobs mit dem folgenden Befehl ausgeführt werden:

isi job status

2. Deaktivieren Sie die Job-Engine und überprüfen Sie, ob isi_job_d ist auf allen Nodes inaktiv:

isi services -a isi_job_d disable
isi_for_array -sX 'ps auxww |grep -i isi_job_d |grep -v grep'

3. Ändern des Schutzlevels der reports.db Bis zu 3x Direktzugriffslayout:

isi set -r -g reprotect -a random -p 3x -F /ifs/.ifsvar/modules/jobengine/reports.db

4. Eine weitere Ausführung des folgenden Befehls sollte bestätigen, dass reports.db hat sich geändert:

isi get -DD /ifs/.ifsvar/modules/jobengine/reports.db

cluster01-16# isi get -DD /ifs/.ifsvar/modules/jobengine/reports.db
POLICY   W   LEVEL PERFORMANCE COAL  ENCODING      FILE              IADDRS
3x       3      3x random off   UTF-8         reports.db        <25,14,1575794508288:512>, <26,31,924241684480:512>, <29,16,157594713088:512> ct: 1506750730 rt: 0
*************************************************
* IFS inode: [ 25,14,1575794508288:512, 26,31,924241684480:512, 29,16,157594713088:512 ]
*************************************************
*...
*  Protection Policy:  3x
*  Target Protection:  3x

5. Aktivieren Sie die Job-Engine:

isi services -a isi_job_d enable
isi_for_array -sX 'ps auxww |grep -i isi_job_d |grep -v grep'

6. Jobs fortsetzen. Die Meldungen in isi_job_d.log abklingen sollte.

Das oben Gesagte sollte restriping reports.db auf 3x sofort. Einige Nutzer konfigurieren ihren SmartPools-Job jedoch so, dass er mit "allen" Dateien statt mit "default" funktioniert.

• Im vollständigen Protokoll:

[xus25@elvis 2021-09-24-003]$ cat local/isi_storagepool_settings
     Automatically Manage Protection: all  <<<<
Automatically Manage Io Optimization: all 

• Auf einem Live-Cluster

steven-8220-1# isi storagepool settings view
     Automatically Manage Protection: all  <<<<
Automatically Manage Io Optimization: all 

Wenn "automatically manage" auf "all" festgelegt ist, wird möglicherweise beim nächsten SmartPools-Job ein Restriping durchgeführt reports.db Zurück zu 6-facher oder 8-facher Spiegelung.
Um dies zu vermeiden, schlagen Sie vor, "Schutz automatisch managen" auf "files_at_default" festzulegen.

Wenn er auf "files_at_default" festgelegt ist, umgehen SmartPools-Jobs manuell gemanagte Dateien, was bedeutet, dass sie reports.db Mit dem von uns angegebenen Schutzlevel.

Nachfolgend finden Sie empfohlene Ressourcen zu diesem Thema, die von Interesse sein könnten:

• PowerScale: So führen Sie das IOCA-Clusteranalysetool aus 
• Isilon: PowerScale: OneFS: Troubleshooting bei Performanceproblemen