PowerScale: JWT- und PAPI-Timeouts auf PowerScale 9.5 und höher

Dies gilt für OneFS 9.5 und höher für Auswirkungen; Einige noch ältere Versionen von OneFS können diese Bedingungen jedoch manchmal sehen.
 Einige der Befehle in diesem Wissensdatenbank-Artikel funktionieren nicht auf Versionen von OneFS, die älter als 9.6 (nicht 9.5) sind, und werden wahrscheinlich nicht zurückportiert. Erwägen Sie ein Upgrade auf moderne Zielcodeebenen.

Im Zuge der Weiterentwicklung von OneFS werden die zugrunde liegenden API-Systeme regelmäßig aktualisiert. Ab Version 9.5 können bestimmte Workflows und Anwendungsfälle mit einem hohen Maß an häufigen oder gleichzeitigen API-/Webauthentifizierungssitzungen höhere Raten von Verbindungs-, PAPI-, API- und ähnlichen Timeouts aufweisen, die sich mit JWT-bezogenen Prozessen überschneiden können. JWT ist eines der Systeme, die an der Verwaltung von CSRF-Token für die API-Authentifizierung beteiligt sind, wie sie von unserem modernen Sicherheitsmodell gefordert wird.

Die Kerne, falls vorhanden, werden wie folgt angezeigt:

Powerscale-OneFS-27# isi_for_array -s ls -lah /var/crash/ | grep -i jwt
Powerscale-OneFS-12: -rw-rw----   1 root  daemon     167M Jul 14 23:39 jwt.core.gz
Powerscale-OneFS-13: -rw-rw----   1 root  daemon     214M Jul 15 12:19 jwt.core.gz
Powerscale-OneFS-17: -rw-rw----   1 root  daemon     181M Jul 15 14:03 jwt.core.gz
Powerscale-OneFS-21: -rw-rw----   1 root  daemon     172M Jul 24 14:20 jwt.core.gz
Powerscale-OneFS-22: -rw-rw----   1 root  daemon      37M Jul 24 14:23 jwt.core.gz
Powerscale-OneFS-27: -rw-rw----   1 root  daemon     165M Jul 24 10:08 jwt.core.gz
Powerscale-OneFS-28: -rw-rw----   1 root  daemon     181M Jul 24 13:35 jwt.core.gz
Powerscale-OneFS-29: -rw-rw----   1 root  daemon     181M Jul 24 13:10 jwt.core.gz

Dies kann ähnliche Protokollfehler wie diesen umfassen:

$ cat Powerscale-OneFS-*/varlog.tar/log/jwt.log | grep 2024-07 | less

2024-07-15T13:00:22.459910-05:00 <30.5> Powerscale-OneFS-66(id71) jwt[83869]: Logging started
2024-07-15T13:25:54.388061-05:00 <30.3> Powerscale-OneFS-66(id71) jwt[83869]: [jwt] Failed to update active session user index. errno: 12 - Cannot allocate memory
2024-07-15T13:25:54.495084-05:00 <30.3> Powerscale-OneFS-66(id71) jwt[83869]: [jwt] Failed to add session: 0801b74c-1abf-4b23-89a0-1e9daf429559 to active session user index identity: SID:S-1-22-1-0, zone: 1. STATUS_INVALID_PARAMETER (0xC000000D)
2024-07-15T14:05:56.869968-05:00 <30.3> Powerscale-OneFS-66(id71) jwt[83869]: [jwt] Failed to update active session user index. errno: 12 - Cannot allocate memory
2024-07-15T14:05:57.115920-05:00 <30.3> Powerscale-OneFS-66(id71) jwt[83869]: [jwt] Failed to add session: 08c173f1-60de-472d-a89d-1d6af2462a28 to active session user index identity: SID:S-1-22-1-0, zone: 1. STATUS_INVALID_PARAMETER (0xC000000D)

2024-07-15T14:28:28.441603-05:00 <30.5> Powerscale-OneFS-66(id71) jwt[2077]: Logging started
2024-07-15T14:52:08.794040-05:00 <30.3> Powerscale-OneFS-66(id71) jwt[2077]: [jwt] Failed to update active session user index. errno: 12 - Cannot allocate memory
2024-07-15T14:52:09.043575-05:00 <30.3> Powerscale-OneFS-66 syslogd: last message repeated 1 times
2024-07-15T14:52:09.070500-05:00 <30.3> Powerscale-OneFS-66(id71) jwt[2077]: [jwt] Failed to add session: a1164a8f-cd68-45bf-bc07-5d7beefe7ba3 to active session user index identity: SID:S-1-22-1-0, zone: 1. STATUS_INVALID_PARAMETER (0xC000000D)

Das Problem ist jedoch möglicherweise nicht auf JWT-Cores beschränkt. Die Probleme können in 9.5 oder früher auftreten, aber die Workarounds und Korrekturen sind in 9.6 OneFS und höher verfügbar.
Die Workarounds in diesem Wissensdatenbank-Artikel auf OneFS 9.6 und höher können Probleme mit dem Timeout im Zusammenhang mit der OneFS API beheben.

Diese Workarounds gelten nur für OneFS 9.6 und höher.
 

Wenden Sie sich bei niedrigeren Versionen, die nicht das Ende der Nutzungsdauer erreicht haben, direkt an den Support. Möglicherweise gibt es Optionen, die Sie verfolgen sollten, aber Sie müssen entweder ein Upgrade von OneFS durchführen oder mit dem API-/Drittanbieter zusammenarbeiten, um Ihre API-basierte Workload effizienter auf mehr Nodes und über mehr Zeit zu verteilen.


Einhaltung von vMemory-Limits für JWT:

Das aktuelle vmlimit für den JWT-Prozess beträgt 1 GB. Wir können es auf 2 GB einstellen und prüfen, ob es hilft. Anzeigen der 1-GB-Grenze für JWT:

9610-1# limits -P $(pgrep jwt)  -B
Resource limits (current):
  cputime              infinity secs
  filesize             infinity kB
  datasize             33554432 kB
  stacksize              524288 kB
  coredumpsize         infinity kB
  memoryuse            infinity kB
  memorylocked           131072 kB
  maxprocesses             7390
  openfiles               16384
  sbsize               infinity bytes
  vmemoryuse            1048576 kB  <----
  pseudo-terminals     infinity
  swapuse              infinity kB
  kqueues              infinity
  umtxp                infinity

So legen Sie sie stattdessen auf 2 GB fest:
 

# isi_for_array -s 'limits -P $(pgrep jwt)  -v 2g'

So bestätigen Sie das neue Limit:

# isi_for_array -s  'limits -P $(pgrep jwt) -B' | grep vmemoryuse
9610-1:   vmemoryuse            2097152 kB
9610-2:   vmemoryuse            2097152 kB
9610-3:   vmemoryuse            2097152 kB
9610-4:   vmemoryuse            2097152 kB
9610-5:   vmemoryuse            2097152 kB
9610-6:   vmemoryuse            2097152 kB

Sie können es zu cron hinzufügen, um es dauerhaft zu machen, wenn diese Ergebnisse zufriedenstellend sind, indem Sie die Informationen in Isilon verwenden. So bearbeiten Sie crontab

Um dies zu cronen, sollten Sie diesen Befehl so einstellen, dass er in einem angemessenen Intervall ausgeführt wird, damit er nach einem möglichen Neustart des Clusters oder Node zurückgesetzt wird, z. B. ein Cron, der alle paar Stunden ausgeführt wird:

isi_for_array -s 'limits -P $(pgrep jwt) -v 2g'

Wenden Sie sich bei Fragen zur Implementierung von cron an Ihr Dell System Engineering. Wenn Sie danach technische Schwierigkeiten haben, wenden Sie sich bitte an den technischen Support.



Einhaltung von gleichzeitigen PAPI-Limits:

Ein weiterer Faktor, der sich auf Ihren Betrieb auswirken kann, ist die Anzahl der gleichzeitig zulässigen PAPI/API-Sitzungen. Einige moderne Drittanbieter können eine regelrechte Flut von Aktivitäten für API-Anfragen an die Speicherplattform senden, was in Kombination mit unseren eigenen internen Vorgängen, die API verwenden, manchmal dazu führen kann, dass die maximale Anzahl von Sitzungen überschritten wird. Die Standardhöchstgrenze beträgt 80 mit einer Mindestuntergrenze von 40:

9610-1# isi_gconfig -t papi | grep -i child
proc.auto_configure_child_limit (bool) = true
proc.child_limit (int) = 80
proc.child_limit_ceiling (int) = 80
proc.child_limit_floor (int) = 40
proc.child_limit_extension (int) = 0

Der Grenzwert und die Obergrenze können somit für Tests/Korrekturen erhöht werden:

9610-1# isi_gconfig -t papi proc.child_limit=100; isi_gconfig -t papi proc.child_limit_ceiling=100

9610-1# isi_gconfig -t papi | grep child
proc.auto_configure_child_limit (bool) = true
proc.child_limit (int) = 100
proc.child_limit_ceiling (int) = 100
proc.child_limit_floor (int) = 40
proc.child_limit_extension (int) = 0

Beachten Sie, dass die oben genannten gconfigs eine globale Einstellung für alle Nodes sind. Es gibt keine lokale Option.

Wenn Sie diesen Wert erhöhen, kann es unerwartete Auswirkungen geben, z. B. höhere Kosten für zugehörige Systeme oder theoretische Leistungsauswirkungen, die nur für eine bestimmte Umgebung gelten, da wahrscheinlich keine zwei Storage-Cluster identische Performanceprofile aufweisen. Solche Überlegungen lassen sich in der Regel nicht im Voraus vorhersagen und sind nur reaktiv.

Wenden Sie sich bei Fragen hierzu an Ihren SE oder Support.