PowerScale: Jobmotordatabasen rapporterer låst eller lang ventetid til succession

Job går i ventetilstand flere gange.

Databaseopdateringer tager lang tid at fuldføre.

I isi_job_d.log og messages.log, ses meddelelser om lange ventetider, databaselåse og mulige jobkoordinatorspringnoder hyppigt.

Symptom 1:
isi_job_d.log Rapporterer en lang ventetid på en fuldført opdatering:

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

Symptom 2:
isi_job_d.log Rapportdatabasen er låst:

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

Symptom 3: 
Job coordinator switches nodes on a frequent basis:

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. Databasen med rapporter om jobprogrammet (reports.db) opdateres konstant på grund af et langvarigt job, der genererer mange opdateringer.
2. Hver opdatering af filen udføres seks gange på tværs af klyngen. Sænkning af beskyttelsesniveauet gør tilsyneladende opdateringerne hurtigere.
3. Afhængigt af den tid, der er sat på pause isi_papi_d, forventer du at se koordinatorens timeout i sin skrivning til databasen (logning). Det kan også lykkes, men log, at skrivningen tog længere tid end ønsket, logge til isi_job_d.log i begge tilfælde.

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

Dells tekniker undersøger problemet. Denne artikel opdateres, efterhånden som flere oplysninger bliver tilgængelige.

Du kan løse problemet ved at køre følgende kommando for at ændre beskyttelsesniveauet for jobrapportdatabasen på følgende måde:

1. Sæt alle kørende job på pause. Kontroller, at der ikke er nogen job, der kører med kommandoen:

isi job status

2. Deaktiver jobprogrammet, og bekræft isi_job_d Er død på alle noder:

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

3. Skift beskyttelsesniveauet for reports.db Til 3x layoutet for vilkårlig adgang:

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

4. En anden kørsel af nedenstående kommando bør bekræfte reports.db har ændret sig:

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. Aktivér jobprogrammet:

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

6. Genoptag job. Meddelelserne i isi_job_d.log bør aftage.

Ovenstående skal hvile reports.db til 3x straks. Nogle brugere kan dog konfigurere deres SmartPools-job til at arbejde på 'alle' filer i stedet for 'standard'.

• I den fulde logfil:

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

• På en live-klynge

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

Med "Administrer automatisk" indstillet til alle, kan det næste SmartPools-job blive genopbygget reports.db Tilbage til 6x eller 8x spejl.
For at undgå dette foreslår du at indstille 'Administrer automatisk beskyttelse' til 'files_at_default'.

Når den er indstillet til 'files_at_default', omgår SmartPools-job manuelt administrerede filer, hvilket betyder, at den forlader reports.db med det beskyttelsesniveau, vi har angivet.

Her er nogle anbefalede ressourcer relateret til dette emne, som kan være af interesse:

• PowerScale: Sådan køres IOCA-klyngeanalyseværktøjet 
• Isilon: PowerScale: OneFS: Fejlfinding af problemer med ydeevnen