PowerFlex 3.x: vTree-migrering kan forårsake at SDS får panikk eller henger

Under en planlagt vTree-migrering i PowerFlex versjon 3.6.7 får flere SDS-er panikk, noe som fører til at systemet går inn i en utilgjengelighetstilstand for data.

Som et resultat av overføringsforsinkelsene øker kapasitetsforbruket i lagringsbassenget (SP) raskt og kan nå full utnyttelse innen kort tid.

MDM-hendelser:

2026-06-30 07:27:19.340 SDS_DECOUPLED ERROR SDS: SDS11 (id: 64cb920800000006) decoupled.
2026-06-30 07:27:19.465 MDM_DATA_DEGRADED ERROR The system is now in DEGRADED state
....
2026-06-30 07:32:20.638 SDS_DECOUPLED ERROR SDS: SDS9 (id: 64cb920b00000009) decoupled.
2026-06-30 07:32:20.638 SDS_DECOUPLED ERROR SDS: SDS12 (id: 64cb920a00000008) decoupled.
2026-06-30 07:32:21.842 MDM_DATA_FAILED CRITICAL The system is now in DATA FAILURE state. Some data is unavailable
...
2026-06-30 07:32:23.538 DEV_CAPACITY_USAGE_CRITICAL ERROR Capacity usage on Protection Domain PD1, Storage Pool FGSP_01 is CRITICAL.
2026-06-30 07:32:23.605 DEV_CAPACITY_USAGE_FULL ERROR Capacity usage on Protection Domain PD1, Storage Pool FGSP_02 is FULL.

Sporingslogger på alle berørte SDS-noder gir samme panikkstakksporing:

2026/07/01 17:45:33.506630 Panic in file /data/build/workspace/ScaleIO-Common-Job/src/mos/mos_timer.c, line 437, function mosTimerReq_AddByQ, PID 1291427.Panic Expression pReq->state == MOS_TIMER_REQ_STATE__IDLE .
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(mosDbg_PanicPrepare+0xe5) [0x932ce5]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(mosTimerReq_AddByQ+0x143) [0x917043]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(vaeCleaner_CleanVae+0x64) [0x668904]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(head_removeVae+0x170) [0x545e00]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(head_Update+0x373) [0x546363]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contHead_UpdateFull+0x69) [0x4db689]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contCmd_AddHead+0x18a) [0x60d85a]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contCmd_AddHeadGroup+0x100) [0x61b630]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contCmd_NewRequest+0x15fd) [0x62b96d]
/opt/emc/scaleio/sds/bin/sds-3.6.7000.123(contNet_RecvRequest+0xd0) [0x4ce880]

I PowerFlex-versjoner som er eldre enn 3.6.7, under en planlagt vTree-migrering, henger migreringsfremdriften seg og fullføres aldri.

I PowerFlex Manager-brukergrensesnittet > som kjører lagringsjobber, viser den Laster inn i det uendelige:

query_vtree_migration output viser at fremdriftsprosenten aldri endres:

scli --query_vtree_migration --volume_id 53b80e00000000d1
VTree ID: ba46bf57000000d1 Name: PDC-GC-LNX-N-01-PFSP01-01-V043
    Storage Pool 5f2f4acc00000000 Name: PDC-FLEX-LNX-SP01
    Protection Domain 908ff43700000000 Name: PDC-FLEX-LNX-PD01
    Data layout: Medium granularity
    Provisioning: Thin
    Total capacity in use: 504.7 GB (516787 MB)
    Total user data: 504.7 GB (516787 MB)
            Total base user data: 504.7 GB (516787 MB)
            Total snapshots user data: 0 Bytes
    VTree migration info:
            Migration status: Migrating
            Source:      Storage Pool: PDC-FLEX-LNX-SP01 ID: 5f2f4acc00000000 Protection Domain: PDC-FLEX-LNX-PD01 ID: 908ff43700000000
            Destination: Storage Pool: PDC-FLEX-LNX-SP03 ID: 5f2fe70d00000004 Protection Domain: PDC-FLEX-LNX-PD03 ID: 9090907800000003
            Conversion type: No conversion
            Queue position: 1
            Progress percentage : 34%

Innvirkning

På versjoner som er eldre enn 3.6.7, slutter volummigreringen aldri, SP-kapasitetsutnyttelsen er kritisk eller høyere, og det kan oppstå I/O-feil i applikasjoner.

På versjon 3.6.7, data utilgjengelighet.

Dette problemet skyldes en kappløpstilstand med flere tråder som involverer en delt tidtakermekanisme i den renere komponenten Volume Allocation Element (VAE) under volummigreringsoperasjoner.

I tidligere versjoner av PowerFlex enn 3.6.7 ble det brukt en asynkron oppryddingsprosess for å slette data fra gamle SP-plasseringer etter en migrering. I sjeldne tilfeller, for eksempel samtidige volumbehandlingsoperasjoner, samtidige volumslettinger, høy I/O-belastning eller ustabilitet i nettverket, kan denne prosessen oppleve en kappløpssituasjon som førte til at migreringer ble sittende fast i det uendelige.

For å løse dette ble det innført en forbedret overvåkingsmekanisme i versjon 3.6.7. Denne sikkerhetsmekanismen inneholdt en tidtaker designet for å oppdage en fastlåst VAE-renere tråd og proaktivt få panikk i SDS-tjenesten for å forhindre datakorrupsjon eller langvarige stopper, på samme måte som systemet håndterer fastlåste I/O- eller MDM-kommandoer.

I den første implementeringen av denne løsningen ble imidlertid overvåkingstidtakeren initialisert bare én gang under migreringsdatakonstruksjon og ble delt globalt på tvers av alle påfølgende VAE-rengjøringsanrop. Når flere bakgrunnstråder prøver å få tilgang til denne ene delte tidtakeren samtidig under tunge overføringsarbeidsbelastninger, utløses en ny kappløpstilstand. Denne samtidige tilgangen fører til at sporingsmekanismen feilaktig flagger VAE-renseren som fastlåst, noe som resulterer i utilsiktede SDS-tjenestekrasj og lokalisert forstyrrelse av datatilgjengeligheten, noe som resulterer i at data blir utilgjengelig.

Permanent løsning (anbefales)

Oppgrader klyngen til PowerFlex 3.6.7.1 eller nyere. Reparasjonen for både VAE-renser og timerløpsforhold er inkludert.

Løsning (hvis oppgraderingen ikke kan utføres umiddelbart)

På versjoner som er eldre enn 3.6.7

1. På primær MDM går du til sporingsloggkatalogen på /opt/emc/scaleio/mdm/logs/. Hvis du vil finne gjeldende sporingslogg, kjører du ls -ltr, så det siste trc.z.* Loggen er oppført nederst på listen.
2. Siden loggene er komprimert, bruker du trace_decompress verktøyet ligger på /opt/emc/scaleio/mdm/bin/

tail -f <current_trace_log> | /opt/emc/scaleio/mdm/bin/trace_decompress

3. Filter etter SDS-ID (for eksempel TGT) oppføringer. Trykk på grep Kommando for å finne:

tail -f <current_trace_log> | /opt/emc/scaleio/mdm/bin/trace_decompress | grep volumeBlock_HandleQueryCleanVaeResponse

4. Identifiser TGT. Se etter linjer som ligner på følgende i de filtrerte utdataene:

TGT 41a903f100000036 not done yet

Hvis TGT ID forblir konsistent over tid, det tilsvarer sannsynligvis SDS-noden som er involvert. Kjør trinn 3 på nytt for å bekrefte at den forblir konsekvent.

5. Kjør følgende kommando for å liste opp alle SDS-noder og matche TGT ID med SDS-navn/IP-adresse:

scli --query_all_sds

6. Når du har den nødvendige informasjonen, kan du SSH til det SDS og start SDS-tjenesten på nytt ved å kjøre:

pkill sds

På versjon 3.6.7

• Serialiser volumbehandlingsoperasjoner – kjør bare én sletting, endring av størrelse eller overføring om gangen.
• Reduser I/O-belastningen på de berørte beskyttelsesdomenene mens migreringer kjører.
• Unngå massemigrering av vTree. Batch dem i små grupper.
• Ikke pause eller avbryt en migrering når nettverket viser ustabilitet.

Disse handlingene reduserer sannsynligheten for samtidig timerbruk og reduserer dermed panikkhendelser.

Berørte versjoner

PowerFlex-kjerne 3.x.x.x

Løst i versjon

PowerFlex Core 3.6.7.1