PowerScale: Baza danych aparatu zadań zgłasza blokadę lub długi czas oczekiwania na sukcesję

Zadania wielokrotnie przechodzą w stan oczekiwania.

Aktualizacje baz danych zajmują dużo czasu.

W isi_job_d.log i messages.log, często pojawiają się komunikaty o długim czasie oczekiwania, blokadach bazy danych i możliwych węzłach przeskakujących koordynatora zadań.

Objaw 1:
isi_job_d.log Zgłasza długi czas oczekiwania na pomyślną aktualizację:

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

Objaw 2:
isi_job_d.log Baza raportów jest zablokowana:

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

Objaw 3: 
Koordynator zadań często przełącza węzły:

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. Baza danych raportów aparatu zadań (reports.db) jest stale aktualizowany z powodu długotrwałego zadania, które generuje wiele aktualizacji.
2. Każda aktualizacja pliku jest wykonywana sześć razy w klastrze. Obniżenie poziomu zabezpieczenia wyraźnie przyczynia się do przyspieszenia aktualizacji.
3. W zależności od ilości czasu wstrzymanego w isi_papi_d, oczekuje się, że przekroczenie limitu czasu koordynatora zostanie wyświetlone podczas zapisu w bazie danych (rejestrowanie). Może się to również udać, ale rejestruj, że zapis trwał dłużej niż powinien, logując się do isi_job_d.log w obu przypadkach.

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

Inżynierowie firmy Dell badają ten problem. Ten artykuł jest aktualizowany w miarę pojawiania się nowych informacji.

Aby obejść ten problem, uruchom następujące polecenie w celu zmiany poziomu ochrony bazy danych raportów o zadaniach w następujący sposób:

1. Wstrzymaj wszystkie uruchomione zadania. Sprawdź, czy przy użyciu polecenia nie są uruchomione żadne zadania:

isi job status

2. Wyłącz mechanizm zadań i zweryfikuj isi_job_d jest martwy na wszystkich węzłach:

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

3. Zmień poziom ochrony reports.db Do 3 układów o dostępie swobodnym:

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

4. Kolejne uruchomienie poniższego polecenia powinno potwierdzić reports.db zmienił się:

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. włącz mechanizm zadań:

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

6. wznów zadania. Komunikaty w isi_job_d.log powinny zostać złagodzone.

Powyższe elementy powinny zostać ponownie rozłożone reports.db do 3x natychmiast. Niektórzy użytkownicy mogą jednak skonfigurować zadanie SmartPools tak, aby działało na "wszystkich" plikach, a nie "domyślnie".

• W pełnym dzienniku:

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

• W klastrze na żywo

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

Jeśli opcja "automatically manage" ma wartość all, następne zadanie SmartPools może zostać ponownie rozłożone reports.db Wróć do lustra 6x lub 8x.
Aby tego uniknąć, zasugeruj ustawienie opcji "Automatycznie zarządzaj ochroną" na "files_at_default".

Gdy ustawienie wartości to "files_at_default", zadania SmartPools pomijają ręcznie zarządzane pliki, co oznacza, że pozostawiają reports.db z dowolnym poziomem ochrony, który określiliśmy.

Poniżej przedstawiono niektóre polecane zasoby dotyczące tego tematu, które mogą Cię zainteresować:

• PowerScale: Jak uruchomić narzędzie do analizy klastrów IOCA 
• Isilon: PowerScale: OneFS: Rozwiązywanie problemów z wydajnością