Po povolení mezipaměti metadat FG začnou úložiště PowerFlex selhávat

Scénář

Po povolení mezipaměti metadat FG v určitých doménách ochrany začnou některé úložiště SDS selhávat a restartovat se. 

Příznaky

 - V doméně ochrany byla povolena mezipaměť metadat FG (z událostí MDM):

 2023-09-27 02:19:51.115000:4614824:CLI_COMMAND_SUCCEEDED            INFO     Command set_default_fgl_metadata_cache_size succeeded
2023-09-27 02:20:27.996000:4614851:MDM_CLI_CONF_COMMAND_RECEIVED    INFO     Command enable_fgl_metadata_cache received, User: 'admin'. Protection Domain: pd1

 - Ze souboru zpráv vidíme, že se služba SDS restartuje, protože ji zastavuje proces oom-killer:

 Sep 27 02:20:28 sds60 kernel: sds-3.6.700.103 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Sep 27 02:20:28 sds60 kernel: sds-3.6.700.103 cpuset=/ mems_allowed=0-1
Sep 27 02:20:28 sds60 kernel: CPU: 1 PID: 9615 Comm: sds-3.6.700.103 Kdump: loaded Tainted: G           OE  ------------   3.10.0-1160.80.1.el7.x86_64 #1
Sep 27 02:20:28 sds60 kernel: Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
Sep 27 02:20:28 sds60 kernel: Call Trace:
Sep 27 02:20:28 sds60 kernel: [] dump_stack+0x19/0x1f
Sep 27 02:20:28 sds60 kernel: [] dump_header+0x90/0x22d
Sep 27 02:20:28 sds60 kernel: [] ? ktime_get_ts64+0x52/0xf0
Sep 27 02:20:28 sds60 kernel: [] ? delayacct_end+0x8f/0xc0
Sep 27 02:20:28 sds60 kernel: [] oom_kill_process+0x2d5/0x4a0
Sep 27 02:20:28 sds60 kernel: [] ? oom_unkillable_task+0x93/0x120
Sep 27 02:20:28 sds60 kernel: [] out_of_memory+0x31a/0x500
Sep 27 02:20:28 sds60 kernel: [] __alloc_pages_nodemask+0xae4/0xbf0
Sep 27 02:20:28 sds60 kernel: [] alloc_pages_current+0x98/0x110
Sep 27 02:20:28 sds60 kernel: [] __page_cache_alloc+0x97/0xb0
Sep 27 02:20:28 sds60 kernel: [] filemap_fault+0x270/0x420
Sep 27 02:20:28 sds60 kernel: [] __xfs_filemap_fault+0x7e/0x1d0 [xfs]
Sep 27 02:20:28 sds60 kernel: [] xfs_filemap_fault+0x2c/0x40 [xfs]
Sep 27 02:20:28 sds60 kernel: [] __do_fault.isra.61+0x8a/0x100
Sep 27 02:20:28 sds60 kernel: [] do_read_fault.isra.63+0x4c/0x1b0
Sep 27 02:20:28 sds60 kernel: [] handle_mm_fault+0xa20/0xfb0
Sep 27 02:20:28 sds60 kernel: [] ? ep_scan_ready_list.isra.7+0x1b9/0x1f0
Sep 27 02:20:28 sds60 kernel: [] __do_page_fault+0x213/0x510
Sep 27 02:20:28 sds60 kernel: [] do_page_fault+0x35/0x90
Sep 27 02:20:28 sds60 kernel: [] page_fault+0x28/0x30

 Sep 27 02:20:28 sds60 kernel: Out of memory: Kill process 1262 (sds-3.6.700.103) score 240 or sacrifice child
Sep 27 02:20:28 sds60 kernel: Killed process 1262 (sds-3.6.700.103), UID 0, total-vm:75663912kB, anon-rss:9100672kB, file-rss:3944kB, shmem-rss:10796856kB
Sep 27 02:20:29 sds60 systemd: sds.service: main process exited, code=killed, status=9/KILL
Sep 27 02:20:29 sds60 systemd: Unit sds.service entered failed state.
Sep 27 02:20:29 sds60 systemd: sds.service failed.

 - Chybové ukončení SDS má dva uzly NUMA (Non-Uniform Memory Access). To lze vidět pomocí příkazu "numactl --hardware":

 available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6
node 0 size: 20923 MB
node 0 free: 1014 MB
node 1 cpus: 7 8 9 10 11 12 13
node 1 size: 21166 MB
node 1 free: 19481 MB

 - U ostatních SDS ve stejné doméně ochrany úložiště nedochází k chybě a mají pouze jeden uzel NUMA:

 available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13
node 0 size: 42089 MB
node 0 free: 19881 MB

Důsledky

To způsobí degradaci dat, což vede k opětovnému vytvoření, a pokud selhává dostatek SDS najednou, k nedostupnosti dat. 

Mezipaměť metadat FG umožňuje svazkům založeným na FG ukládat čtení do mezipaměti, což zvyšuje výkon. Potřebuje také více paměti z operačního systému pro ukládání čtení do mezipaměti, takže musí být k dispozici paměť pro převzetí z operačního systému. Pokud tato paměť není k dispozici, operační systém použije oom-killer (Out of Memory) k zastavení největšího uživatele paměti, což bude pravděpodobně služba SDS. 

V tomto případě byly SDS, které havarovaly a nehavarovaly, SVM. Všechny měly 40+ GB paměti RAM a 14 virtuálních procesorů přidělených od příslušných hostitelů ESXi. SDS může ve výchozím nastavení získat paměť pouze z uzlu NUMA 0. Pokud existuje více uzlů NUMA, SDS se nemůže načíst z uzlu NUMA 1, aby splňoval požadavky na paměť při povolování mezipaměti metadat FG.

Rozdíly v konfiguracích SVM s jedním nebo dvěma uzly NUMA je možné připsat základnímu hardwaru. V tomto případě mají SVM s jedním uzlem NUMA 18 jader na soket, a proto se všech 14 virtuálních procesorů vejde na jednu patici procesoru. SVM se dvěma uzly NUMA měly pouze 12 jader na soket, a proto se virtuální procesory nevešly všechny na jednu patici procesoru a musely být rozloženy mezi oba sockety. To vyžaduje potřebu dvou uzlů NUMA.  

Zástupné řešení

Ověřte, zda má SVM nebo operační systém dostatek paměti, aby vyhověl novým požadavkům na paměť. 

Existuje několik možných alternativních řešení. Stačí použít pouze jeden:

Přidejte do conf.txt SDS níže uvedený řádek pro uzly, které mají dva uzly NUMA, a restartujte proces SDS (postupujte podle všech postupů běžné údržby):

numa_memory_affinity=0 

Tento řádek v conf.txt umožňuje úložišti SDS používat paměť z obou uzlů NUMA. 
Další dokumentaci, která vysvětluje, proč je toto nastavení potřeba, najdete tady.
 
Snižte počet virtuálních procesorů tak, aby odpovídal základnímu hardwaru. V takovém případě, pokud by SVM měl 12 virtuálních procesorů, byla by veškerá paměť dostupná v jednom uzlu NUMA. 

Dotčené verze

PowerFlex 3.5.x
, PowerFlex 3.6.x
, PowerFlex 4.x

Opraveno ve verzi

Nejedná se o chybu, jde o naprogramované chování.