PowerFlex: Feilsøking av ressursstrid
요약: Problemer og feilsøking for PowerFlex-ressursstrid og feilsøking
증상
Unormal oppførsel fra PowerFlex-prosessene fører til at PowerFlex-prosesser støter på ressurskonflikt med andre programvare- eller maskinvarekomponenter.
Symptomene her kan være mange og varierte. Dette er en delvis liste over symptomer og resultater
MDM-problemer:
- Failover for MDM-eierskap oppstår når MDM-prosesser setter seg fast og mister kommunikasjonen med de andre MDM-ene
From exp.0:
Panic in file /emc/svc_flashbld/workspace/ScaleIO-RHEL7/src/mos/umt/mos_umt_sched_thrd.c, line 1798, function mosUmtSchedThrd_SuspendCK, PID 36721.Panic Expression ALWAYS_ASSERT Scheduler guard seems to be dead.
From trc.*
24/02 15:54:16.087919 0:schedThrdGuard_SampleLivnes:01463: WARNING: pThread 0x106d9360(0) in scheduler 0x7fff580c4880, running UMT 0x7f39ad00ceb8, found to be stuck.
24/02 15:54:16.088226 ad417eb8:actorLoop_IsSchedThredStuck:10932: Stuck scheduler thread identified
24/02 15:54:16.088253 ad417eb8:actor_Loop:11257: Lost quorum. ourVoters: 0 votersOwnedByOther: [0,0]
24/02 15:54:16.088299 ---Planned crash, reason: Lost quorum, going down to let another MDM become master ---
- MDM-prosessen vil koble fra og koble til igjen hele tiden over noe tid
2017-02-23 14:00:43.241 MDM_CLUSTER_LOST_CONNECTION WARNING The MDM, ID 089012db4d536880, lost connection
2017-02-23 14:00:43.422 MDM_CLUSTER_CONNECTED INFO The MDM, ID 089012db4d536880, connected
2017-02-23 23:05:25.852 MDM_CLUSTER_LOST_CONNECTION WARNING The MDM, ID 089012db4d536880, lost connection
2017-02-23 23:05:26.422 MDM_CLUSTER_CONNECTED INFO The MDM, ID 089012db4d536880, connected
2017-02-24 15:54:16.141 MDM_CLUSTER_LOST_CONNECTION WARNING The MDM, ID 089012db4d536880, lost connection
2017-02-24 15:54:16.238 MDM_CLUSTER_CONNECTED INFO The MDM, ID 089012db4d536880, connected
SDS-problemer:
- SDS vil koble fra og koble til igjen hele tiden over noe tid
2017-02-15 13:18:16.881 SDS_RECONNECTED INFO SDS: siosds2 (ID 1eb052fe00000001) reconnected
2017-02-16 03:37:37.327 SDS_DECOUPLED ERROR SDS: siosds2 (id: 1eb052fe00000001) decoupled.
2017-02-16 03:39:54.300 SDS_RECONNECTED INFO SDS: siosds2 (ID 1eb052fe00000001) reconnected
2017-02-17 04:03:41.757 SDS_DECOUPLED ERROR SDS: siosds2 (id: 1eb052fe00000001) decoupled.
2017-02-17 04:09:13.604 SDS_RECONNECTED INFO SDS: siosds2 (ID 1eb052fe00000001) reconnected
- SDS kan vise oscillerende feil i trc-filer angående tilkoblingstap til andre SDS-noder:
14/02 19:13:24.096983 1be7eb8:contNet_OscillationNotif:01675: Con 1eb052fe00000005 - Oscillation of type 5 (RPC_LINGERED_1SEC) reported
14/02 19:13:24.196814 1be7eb8:contNet_OscillationNotif:01675: Con 1eb053000000000b - Oscillation of type 5 (RPC_LINGERED_1SEC) reported
14/02 19:13:24.296713 1be7eb8:contNet_OscillationNotif:01675: Con 1eb0530000000007 - Oscillation of type 5 (RPC_LINGERED_1SEC) reported
14/02 21:48:43.917218 afb28eb8:contNet_OscillationNotif:01675: Con 1eb052fe00000007 - Oscillation of type 1 (SOCKET_DOWN) reported
14/02 21:48:43.917296 afb28eb8:contNet_OscillationNotif:01675: Con 1eb052fe00000005 - Oscillation of type 1 (SOCKET_DOWN) reported
- SDS kan vise vranglåste eller fastlåste tråder i trc-filer:
14/02 19:13:24.147938 9aa4eeb8:netPath_IsKaNeeded:01789: DEBUG ASSERT, Reason:Socket deadlocked. Crashing.
14/02 19:13:24.148113 9aa4eeb8:netPath_IsKaNeeded:01789: DEBUG ASSERT, Reason:Socket deadlocked. Crashing.
14/02 19:13:24.148121 9aa4eeb8:netPath_IsKaNeeded:01789: DEBUG ASSERT, Reason:Socket deadlocked. Crashing.
14/02 20:52:54.097765 242f0eb8:kalive_StartIntr:00346: KA aborted due to stuck sched thread
14/02 21:48:43.510602 7fa30eb8:kalive_StartIntr:00346: KA aborted due to stuck sched thread
14/02 21:48:44.776713 1b67ceb8:kalive_StartIntr:00346: KA aborted due to stuck sched thread
14/02 02:44:41.532007 e2239eb8:contNet_OscillationNotif:01675: Con 1eb052fd00000001 - Oscillation of type 3 (RCV_KA_DISCONNECT) reported
14/02 02:44:43.799135 0:schedThrdGuard_SampleLivnes:01463: WARNING: pThread 0x1a0de10(0) in scheduler 0x7fff01bec400, running UMT 0x7f94e221eeb8, found to be stuck.
14/02 02:44:43.799155 0:schedThrdGuard_SampleLivnes:01463: WARNING: pThread 0x1a0e050(1) in scheduler 0x7fff01bec400, running UMT 0x7f94e2227eb8, found to be stuck.
14/02 02:44:43.799257 e0e38eb8:cont_IsSchedThredStuck:01678: Stuck scheduler thread identified
14/02 02:44:43.799267 e0e38eb8:kalive_StartIntr:00346: KA aborted due to stuck sched thread
- SDS kan vise "error forking" i trc-filer:
01/09 00:37:51.329020 0x7f1001c58eb0:mosDbg_BackTraceAllOsThreads:00673: Error forking.
- SDS kan ikke starte på grunn av manglende tildeling av nødvendig minne.
Følgende rapporteres i exp-loggfiler:
07/09 00:41:52.713502 Panic in file /data/build/workspace/ScaleIO-SLES12-2/src/mos/usr/mos_utils.c, line 235, function mos_AllocPageAlignedOrPanic, PID 25342.Panic Expression pMem != ((void *)0) .
- OS kan også ha noen symptomer i /var/log/messages eller systemhendelseslogger:
/var/log/messages:
Feb 14 13:25:08 ScaleIO-192-168-1-2 kernel: [7461116.683555] TCP: Possible SYN flooding on port 7072. Sending cookies.
Feb 14 13:25:08 ScaleIO-192-168-1-2 kernel: [7461116.683561] TCP: Possible SYN flooding on port 7072. Sending cookies.
Feb 14 13:25:08 ScaleIO-192-168-1-2 kernel: [7461116.683566] TCP: Possible SYN flooding on port 7072. Sending cookies.
Feb 14 13:25:08 ScaleIO-192-168-1-2 kernel: [7461116.683570] TCP: Possible SYN flooding on port 7072. Sending cookies.
Feb 14 13:27:39 ScaleIO-192-168-1-2 kernel: [7461266.566145] sched: RT throttling activated
Meldingene "SYN flooding on port 7072" betyr at nettverksdatapakker sendes til SDS på denne verten, og SDS kan ikke godta pakkene på den porten. SDS bruker port 7072 som standard.
"RT-gasspjeldet aktivert" er en melding om at OS-planleggeren har identifisert noen sanntidstråder som hogger CPUen og sulter andre tråder. Operativsystemet gjør dette i et forsøk på å strupe disse sanntidsoppgavene og forhindre at operativsystemet henger eller krasjer.
SDC kan også få I/O-feil når SDS-ene kobles fra ofte eller ikke kan svare på SDC raskt nok og fortsatt prøver å utføre service på I/O-blokkene den eier.
Innvirkning
Ovennevnte symptomer kan resultere i DATA_DEGRADED, DATA_FAILED hendelser samt CLUSTER_DEGRADED.
원인
Hvis alle symptomene ovenfor stemmer overens, er det mest sannsynlig et problem med CPU eller minneressurs sult. Se etter tredjepartsprogrammer eller -prosesser som kjører, som kan sulte CPU-en og minnet fra MDM- eller SDS-prosessene.
I et virtuelt miljø hadde CPUen et par ganger dårlig ytelse. Dette skyldes at SVM-ene defineres under samme ressursutvalg.
I slike tilfeller bør vi råde til ikke å sette SVM-ene under ressursutvalg, men å ha deres dedikerte ressurser som definert i SVM.
해결
Kontroller at PowerFlex-komponentene (MDM, SDS, SDC) er justert for ytelsesinnstillinger. Se veiledningene for ytelsesveiledningene "Finjustering" og "Feilsøking" som du finner her.
Konfigurasjonsgjennomgang:
- Først må du bekrefte at innstillingene for SVM-CPU og RAM er i henhold til anbefalte fremgangsmåter:
- Innstillinger for SVM CPU: (Kan settes på sparket)
- Kjerner per stikkontakt: alt i en kontakt, så "Stikkontakter" har verdien "1". (Det totale antallet kjerner bestemmes av behovene til SDS-en det er vert for: All-flash, FG, DASCache, Cloudlink, 3.5, etc., alle påvirker (øker) CPU-kravet.)
- Reservasjon: Velg "Maksimum" -verdien i rullegardinmenyen
- Aksjer: Høy
- Dette skal se slik ut:
- Innstillinger for SVM CPU: (Kan settes på sparket)

b. Innstillinger for SVM RAM: (Kan settes på sparket)
- Merk av for «Reserver alle gjesteminner (alle låst)»
- Aksjer: Høy
- Dette skal se slik ut:

c. Innstillinger for overcommit for SVM OS-minne i gjester: (Krever omstart)
-
- Kjør sysctl -a|grep overcommit for å bekrefte at overcommit-innstillingene er riktige:
# sysctl -a|grep overcommit vm.overcommit_memory = 2 vm.overcommit_ratio = 100 -
Hvis verdiene ovenfor ikke er angitt, vil noe SVM-minne ikke kunne brukes til SDS-prosessen. Korriger dette ved å redigere /etc/sysctl.conf og redigere/legge til verdiene ovenfor
- Sett SDS i vedlikeholdsmodus, og start SVM-en på nytt for å ta i bruk innstillingene
- Bekreft ved å kjøre "cat /etc/sysctl.conf|grep overcommit" etter omstart
- Avslutt vedlikeholdsmodus
- Kjør sysctl -a|grep overcommit for å bekrefte at overcommit-innstillingene er riktige:
- Slik finner du disse i logger:
- SVM-konfigurasjon (vmsupport):
-
En riktig konfigurert SVMs .vmx-fil vil inneholde følgende:
-
- SVM-konfigurasjon (vmsupport):
sched.cpu.units = "mhz"
sched.cpu.affinity = "all"
sched.cpu.min = "25930" (nonzero value that's equal to core speed * the # of cores allocated)
sched.cpu.shares = "high"
sched.mem.min = "24576" (nonzero value that's a full allocation of configured memory)
sched.mem.minSize = "24576" (nonzero value that's a full allocation of configured memory)
sched.mem.shares = "high"
cpuid.coresPerSocket = "10" (value equal to total # of cores allocated, so they're all in one socket)
sched.mem.pin = "TRUE"
- Feil (utdatert) SVMconfigs vil ha følgende:
sched.cpu.min = "0"
sched.cpu.shares = "normal"
sched.mem.pin = "FALSE"
sched.mem.shares = "normal"
cpuid.coresPerSocket = "4" (value less than total # of cores allocated, usually 1/2 or 1/4)
-
Korrekt konfigurert minneoverbelastning:
Filserveren/sysctl.txt inneholder:
vm.overcommit_memory = 2
vm.overcommit_ratio = 100
-
PowerFlex bruker en betydelig mengde RAM for hver av tjenestene for å kjøre i minnet og med høy hastighet. Dette er grunnen til at den ikke støtter bruk av swap som skal brukes til å avlaste noen av PowerFlex-tjenestene.
Standardinnstillingen som forventes for bare lagring og SVM-er i en HCI-løsning, er et overcommit-minne på 2. På denne måten vil ikke kjernen overabonnere minnet, og uten at innstillingene på ingen bytte brukes, sikrer at ingen commit_as verdi er større enn totalt ledig / tilgjengelig minne.
Forholdet på 100 sikrer at ingen swap også blir brukt, for mer kontroll for å blokkere bytte som brukes.
-
Feil konfigurert minneovercommit:
Filserveren/sysctl.txt inneholder:
vm.overcommit_memory = 0 (value not 2)
vm.overcommit_ratio = 50 (value less than 95)
Andre mulige løsninger:
- Stopp programmene som forårsaker sult av CPU / minneressurs eller sjekk med programleverandøren for oppdateringer for å lindre ressursen hogging.
- Bruk trendverktøy for CPU/minne (topp-/sar-/cron-jobber/osv.) for å finne ut hvilket program som tar ressursene. Intervaller på 1 sekund anbefales for å oppnå den granulariteten som er nødvendig for å vise når problemet skjer og hvem som er ansvarlig
- Oppgrader verts-CPU-en og/eller minnet for å gi den flere ressurser
- Bygg om til et tolags oppsett i stedet for et konvergert system (hvis SDS/SDC er på samme vert)