PowerProtect DD: Filsystemet er deaktivert hvis det er et kritisk miljøvarsel på DD

PowerProtect DDOS inkluderer en sikkerhetsforanstaltning som deaktiverer DD File System (DDFS) hvis

1: Systemtiden hopper tilbake med mer enn 60 s. Hvis en slik endring i systemtid oppstår,, og/eller 

2: Hvis det oppstår andre maskinvarekomponenter og systemet angir en kritisk miljøvarsling for kabinett 1

Følgende finner sted:   

• DDFS er deaktivert og starter ikke automatisk på nytt
• Et varsel (EVT-ENVIRONMENT-00052) legges ut, det vil si:    

Event posted: p0-32 -EVT-ENVIRONMENT-00052: File system is disabled due to a critical condition.EVT-OBJ::Enclosure=1 EVT-INFO::Cause=System Time backward jumped
Event posted: p0-32 -EVT-ENVIRONMENT-00052: File system is disabled due to a critical condition.EVT-OBJ::Enclosure=1 EVT-INFO::Cause=System has Critical alert

Når dette problemet oppstår:    

• DDFS kan ikke starte på nytt manuelt (det får panikk under oppstart)
• Gjenoppretting av dato og klokkeslett (for å reversere hoppet bakover) tillater ikke at DDFS starter
• Å løse maskinvareproblemet tillater ikke at DDFS starter

Data Domain-filsystemet kan ikke aktiveres før vi utbedrer den kritiske miljøtilstanden, bare for å beskytte DD og andre applikasjoner som er integrert i DD

Denne sikringen ble implementert fordi et hopp bakover i systemtiden kan ha negativ innvirkning på visse sikkerhetskopieringsapplikasjoner som lagrer data på DDR. Som et resultat av dette, er den utformet slik at administratoren for DDR må tillate endring i systemtid før DDFS kan aktiveres på nytt.

Merk: Når dette problemet oppstår, kan ikke DDFS aktiveres fordi det ikke starter for eksempel:    

# filesys enable
Please wait...
01/01 20:32:10.217 (tid 0xxxxxxx): INFO: Event posted: m0-28 (2100001c:553648156): EVT-FILESYS-00008: Filesystem has encountered an error and is restarting.
**** There was a problem bringing up the filesystem. Status: The filesystem is aborting due to a problem.

Hvis du reverserer hoppet bakover i systemtiden, kan du heller ikke aktivere DDFS på nytt (problemet vedvarer).

Følg denne fremgangsmåten for å aktivere DDFS. Hvis den berørte DD-en er den aktive noden i et DD HA-par, må du utføre disse trinnene på begge nodene før du aktiverer filsystemet (FS).

Fra brukergrensesnittet:

1. Kontroller at systemets dato og klokkeslett er riktig. Hvis du endrer tidssonen, kan DDR be om en omstart.
    Utfør denne omstarten umiddelbart for å sikre at alle prosesser gjenkjenner den nye tidssonen. Gå til Administrasjonsinnstillinger>>KLOKKESLETT OG DATO

• Hvis du har NTP aktivert, deaktiver det midlertidig for å korrigere klokken. Gå til FLERE OPPGAVER>Konfigurere tidsinnstillinger

• Konfigurer deretter tidsinnstillingene igjen for å aktivere NTP på nytt om nødvendig

2. Fjern nødvarselet som tilsvarer feilen 'filsystem deaktivert på grunn av en kritisk tilstand'. Gå til Tilstandsvarsler >> GJELDENDE VARSLER

• Vent ett minutt til varselet er slettet og systemstatusen oppdateres. Hvis du ikke gjør det, kan det hende at systemstatusen ikke oppdateres fullstendig før DDFS-prosessen starter, noe som kan føre til engangs FS-krasj og -varsel.

3. Aktiver filsystemet hvis det ikke allerede er aktivert etter at du har fjernet varselet. Gå til Filsammendrag >> for databehandling > Klikk på Aktiver mot bunnen av siden.

• DDFS skal nå starte opp / kjøre som normalt. Hvis du ikke klarte å vente tilstrekkelig tid etter at du fjernet varselet før du startet FS-prosessen, kan det hende du får et varsel på CLI om at FS har oppdaget et problem. FS vil imidlertid fortsette å prøve å starte opp, og hvis problemet var som beskrevet i denne KB-en, vil FS-prosessen til slutt aktiveres.

Fra CLI:

1a. Kontroller at systemets dato og klokkeslett er riktig. Hvis du endrer tidssonen, kan DDR be om en omstart.
    Utfør denne omstarten umiddelbart for å sikre at alle prosesser gjenkjenner den nye tidssonen.

1b. Kontroller at alle maskinvarekomponentene i DD er i god stand

2. Fjern nødvarselet som tilsvarer feilen 'filsystem deaktivert på grunn av en kritisk tilstand':    

# alert clear alert-id [alert id]

     For eksempel, hvis dette var varsel p0-32 (som vist ovenfor):    
 

# alert clear alert-id p0-32

3. Vent ett minutt til varselet er slettet og systemstatusen oppdateres. Hvis du ikke gjør det, kan det hende at systemstatusen ikke oppdateres fullstendig før FS-prosessen starter, noe som kan føre til engangs FS-krasj og -varsel.

4. Nå DDFS skal automatisk komme på nettet, kan du sjekke statusen til filsystemet med "# filesys status". Hvis ikke, aktiverer du DDFS:    

# filesys enable

• DDFS skal nå starte opp / kjøre som normalt. Hvis du ikke klarte å vente tilstrekkelig tid etter at du fjernet varselet før du startet FS-prosessen, kan det hende du får et varsel på CLI om at FS har oppdaget et problem. FS vil imidlertid fortsette å prøve å starte opp, og hvis problemet var som beskrevet i denne KB-en, vil FS-prosessen til slutt aktiveres.

Hvis du vil ha mer informasjon om denne sikkerhetsforanstaltningen eller noe av informasjonen i denne artikkelen, kan du kontakte Dells tekniske kundestøtte.

Et eksempel på problemet er vist nedenfor:    

• DDFS kjører i utgangspunktet som normalt:    

# filesys status
The filesystem is enabled and running.

• DDR har en systemdato, klokkeslett på 13:28 den 7. mars 2017:    

# date
Sun Mar  7 13:28:24 PST 2017

• Datoen er manuelt satt bakover til 1. januar 2017 (nettverkstidsprotokollen / NTP må deaktiveres før denne endringen er mulig):    

# system set date 01012017

• Logger på DDR (messages.engineering) angir at systemdatoen eller -klokkeslettet ble endret bakover, og at DDFS deaktiveres:

Mar  7 13:28:24 rtp-ddr30 ddsh: NOTICE: MSG-DDSH-00009: (tty=ttyS0, session=15703) root: command "system set date 01012017"
...
Jan  1 20:17:04 rtp-ddr30 ddr_stated: Availability stats: Invalid time interval -5591476. Probably the system clock was changed.
Jan  1 20:17:51 rtp-ddr30 platmon: INFO: Found a system time jump: -5591485
Jan  1 20:17:51 rtp-ddr30 platmon: INFO: Before Jump: system time: Tue Mar  7 13:28:15 2017 , rtc time: Tue Mar  7 13:28:16 2017 , ntp last sync time: Unknown
Jan  1 20:17:51 rtp-ddr30 platmon: INFO: After  Jump: system time: Sun Jan  1 20:17:51 2017 , rtc time: Sun Jan  1 20:17:51 2017 , ntp last sync time: Unknown
...
Jan  1 20:17:51 rtp-ddr30 platmon: NOTICE: post_alert: Generating alert EVT-ENVIRONMENT-00052
Jan  1 20:17:52 rtp-ddr30 platmon: INFO: Event posted: p0-32 (11000020:285212704): EVT-ENVIRONMENT-00052: File system is disabled due to a critical condition.EVT-OBJ::Enclosure=1 EVT-INFO::Cause=System Time backward jumped
Jan  1 20:17:52 rtp-ddr30 platmon: NOTICE: evaluate_symbol_node: taking action(s) on error_indict(1)
Jan  1 20:17:52 rtp-ddr30 platmon: INFO: System time jumped, needs service now
Jan  1 20:17:52 rtp-ddr30 platmon: ERROR: Fatal error in platform monitor, DDFS shall be disabled
...
Jan  1 20:17:55 rtp-ddr30 ddr_procmon: ERROR: Critical error is detected by platform monitoring, filesystem is shutdown.
...
Jan  1 20:17:55 rtp-ddr30 ddr_stated: INFO: change_state(): shutdown requested
Jan  1 20:17:55 rtp-ddr30 ddfs[3761]: NOTICE: MSG-DDR-00003: Shutting down ddfs

• Det er lagt ut et nødvarsel som indikerer at DDFS er deaktivert «på grunn av en kritisk tilstand»:    

Når DD-en er en del av eller koblet til en Windows Active Directory, bruker den domenekontrolleren (DC) som systemtidskilde. DD synkroniserer dato og klokkeslett med DC med jevne mellomrom. Hvis dato og klokkeslett i Windows DC endres, sendes oppdateringer til DD via CIFS. Et tidshopp bakover 60 s utløser denne oppførselen.

Hvis du vil finne ut om dette kan være tilfelle, kan du begynne med å sjekke om DD-en er konfigurert for CIFS og bundet til eller koblet til et bestemt Active Directory-område:   

# cifs show config
Mode                 Active-Directory
Realm                realm.example.com
Domain Controllers   *
WINS Server          not specified
NB Hostname          DD9300
Max Connections      Not Available
Max Open Files       Not Available

• Hvis ja, sjekk "cifs.log" -filen for oppføringer som de nedenfor:   

# log view debug/cifs/cifs.log
Mar 28 22:03:16 DD9300 lsass: ALWAYS: [24497/1585429396.001947087] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Sat Mar 28 22:03:16 2020 ] to [Sat Mar 28 22:54:38 2020 ]
Mar 28 23:44:38 DD9300 lsass: ALWAYS: [24497/1585435478.001799190] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Sat Mar 28 23:44:38 2020 ] to [Sat Mar 28 22:53:15 2020 ]
Mar 29 22:04:38 DD9300 lsass: ALWAYS: [24497/1585512278.002014016] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Sun Mar 29 22:04:38 2020 ] to [Sun Mar 29 22:55:53 2020 ]
Mar 29 23:25:53 DD9300 lsass: ALWAYS: [24499/1585517153.001946740] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Sun Mar 29 23:25:53 2020 ] to [Sun Mar 29 22:34:37 2020 ]
Mar 29 23:25:53 DD9300 lsass: ALWAYS: [24497/1585517153.001946645] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Sun Mar 29 23:25:53 2020 ] to [Sun Mar 29 22:34:37 2020 ]
Mar 30 22:00:53 DD9300 lsass: ALWAYS: [24497/1585598453.002161373] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Mon Mar 30 22:00:53 2020 ] to [Mon Mar 30 22:52:01 2020 ]
Mar 30 23:12:01 DD9300 lsass: ALWAYS: [24497/1585602721.002275775] [lsass] ADSyncTimeToDC: Attempting to change System Time, from [Mon Mar 30 23:12:01 2020 ] to [Mon Mar 30 22:20:52 2020 ]