Data Domain: DDFSY-filsystemet kraschar om MTREE-replikering konfigurerats för Veeam DDBOOST-lagringsenhet

När DU använder VEEAM, eller något annat säkerhetskopieringsprogram som använder BOOST för att utföra säkerhetskopiering, använder funktionen Virtual Syntetisering, skapar den nya säkerhetskopior från befintliga program genom att sammanfoga delar av de tidigare säkerhetskopiorna på DD och sedan lägger till skillnaderna. De tidigare säkerhetskopiorna som användes för sammanfogningen kallas "basfiler".

De flesta säkerhetskopieringsprogram läser men ändrar inte basfilerna som används för att skapa nya säkerhetskopieringsbilder, men VEEAM fungerar på olika sätt när du utför säkerhetskopieringar. När du utför säkerhetskopiering skrivs delar av basfilerna som redan finns på disken över.

När utgående MTree-replikering konfigureras för VEEAM LSU/MTree är det möjligt att en säkerhetskopia som replikeras ändras av BOOST under borttagningen av nya säkerhetskopieringsfiler. Om käll-DD kör DDOS 6.x och målreplikering är aktiverat (ett alternativ för hastighets-/prestandaoptimering i DDOS 6.x och senare) kan det leda till att felaktiga kontrollsummar levereras till mål-DD, vilket kan leda till att FS (File System) misslyckas upprepade gånger med meddelanden som följande:

27 feb 04:05:19 mtree-repl-dd.example.com ddfs[10654]: ERROR: MSG-INTRNL-00001: PANIC: ddr/repl/mrepl_replica.c: mrepl_finish_file_transfer_common: 3712: ! (orig_chksum == repl_chksum).

VEEAM ersätter nya säkerhetskopior från befintliga. Det kan finnas överskrivningar av vissa delar av filerna som replikeras när de används som basfiler för att skapa nya säkerhetskopior. Detta skapar förvirring för den nödvändiga replikeringen när VEEAM-lagringsenheten även är konfigurerad för att användas som en del av MTree-replikeringen, vilket kan orsaka att mål-DD KRASCHAR.

Observera att det här felet endast gäller målslutet för MTree-replikering när källan är:

• Om du kör DDOS 6.0.1.0 eller tidigare (t.ex. skulle alla DDOS 6.0.0.x påverkas)
• Köra DDOS 6.x tidigare än DDOS 6.0.2.0 eller 6.1.1.1
• Köra VEEAM-säkerhetskopieringar till ett LSU/MTree och samma MTree replikeras till målet med MTree-replikering
• BOOST-säkerhetskopieringar med virtuella syntetiska aktiverade utförs på samma LSU/MTree
•  När felet påträffas kan det leda till att det replikerade mål-MTree-trädet blir otillgängligt med flera omstarter av FS-processen. De som använder den här konfigurationen eller planerar att konfigurera sina system på det här sättet uppmuntras att antingen använda den tillfälliga lösning som beskrivs nedan eller uppgradera till den fasta DDOS 6.0.2.0 eller 6.1.1.1 (eller någon senare version).

Obs! Det är möjligt att samma PANIC-sträng på målsidan för MTree-replikering kan uppstå för andra problem än den här, eftersom felet bara indikerar att en kontrollsumma i MTree-replikeringsögonblicksbilden inte matchar. Om du är osäker på problemet som beskrivs här eller hur du kringgår ett problem kan du kontakta din supportleverantör och hänvisa till det här KB-artikelnumret 491049.

DD Engineering har identifierat grundorsaken till FS PANIC:erna på målnoden och har genomfört en korrigering i följande versioner:

• DDOS 6.0.2.0 och senare
• DDOS 6.1.1.1 och senare

Alla som är berörda av detta fel eller planerar att konfigurera en liknande konfiguration rekommenderas att uppgradera käll-DD till de nämnda versionerna så snart som möjligt.

För dem som vill uppgradera eller de som står inför problemet innan den fasta versionen blir tillgänglig finns det en tillfällig lösning.
Den består av att avaktivera optimeringen av replikering på käll-DDOS 6.x-systemet.
Den här optimeringen finns bara i DDOS 6.x och senare. Den enda nackdelen med att avaktivera den skulle vara lägre replikeringshastigheter som motsvarar de som uppnåddes på DDOS 5.7.

Innan distributionen bör du först kontrollera om den här lösningen är tillämplig för den aktuella konfigurationen:

1. Kontrollera om käll-DD kör DDOS 6.x före den version som har åtgärdats (fel åtgärdat i DDOS 6.0.2.0 och 6.1.1.1 och framåt)
2. Kontrollera att den DD som har konfigurerats för VEEAM-säkerhetskopiering även är konfigurerad för MTree-replikering för ämnet LSU/MTree som källa (att kontrollera en ny ASUP är det enklaste sättet att bekräfta), till exempel:

CTX: 20-läge: källdestination: mtree://destination-dd.example.com/data/col1/destination_MTree aktiverad: ja

 Om alla dessa villkor ovan gäller kan detta system vara föremål för de ovannämnda defekterna, och det kan leda till att målreplikerings-FS kraschar.

För att tillämpa den tillfälliga lösningen måste du först se till att det inte körs några replikerings- eller BOOST-säkerhetskopieringar och sedan ändra registerinställningen, vilket inte kräver några driftavbrott. Innan du påbörjar den här proceduren ska du läsa varningsmeddelandet som finns nedan som det sista steget i proceduren.

1. Kontrollera att DD till DD-replikering är inaktiverat på käll-DD som kör DDOS 6.x:

# replikering inaktivera alla

2. Se även till att det inte finns några pågående BOOST-säkerhetskopieringar eller BOOST MFR till eller från den potentiellt felaktiga VEEAM LSU/MTree innan du tillämpar registerinställningen. Om det behövs inaktiverar du tillfälligt säkerhetskopieringar och MFR till eller från det här LSU:et:

# ddboost file-replication show active all
# ddboost filreplikering visar statistik

3. Den här registerändringen kräver SE-lägesbehörigheter.

4. Från SE-läge ändrar du registerinställningen för att avaktivera användningen av replikering:

# se sysparam set RECIPE_REPL_ENABLED=FALSE

5. Bekräfta att systemparametern har ställts in korrekt och visas som "FALSE" (inaktiverad)

# se sysparam visa RECIPE_REPL_ENABLED
Namnbeskrivning aktuell standard åsidosättning
-------------------   ------------------------------------------------   -------   -------   --------
RECIPE_REPL_ENABLED Aktivera en allt-i-ett-replikering (gäller endast källa) FALSE TRUE rpc
-------------------   ------------------------------------------------   -------   -------   --------

6. Du kan nu återaktivera DD till DD-replikering och återuppta BOOST-säkerhetskopieringar och boosta MFR till eller från LSU:

# replikering aktiverar alla

VIKTIGT: Om hanteringen av detta har avaktiverats på ett Data Domain-källsystem som även är konfigurerat som målslut för replikering, måste källsystemen för dessa kontexter också utföra ovanstående process (aktivering av aktivering inaktiverad).

Obs! När du har uppgraderat till en korrigerad version (DDOS 6.0.2.0 eller 6.1.1.1) måste inställningen återställas så att en omedelbar replikering kan användas. Uppgraderingen återställer inte registernyckeln. När du har slutfört uppgraderingen återaktiverar du replikeringen genom att logga in på DD, gå in i SE-priviligierat läge och köra:

  # se sysparam reset RECIPE_REPL_ENABLED

Om du är osäker på processen som beskrivs ovan kontaktar du din supportleverantör och hänvisar till den här kunskapsbasartikeln i 491049 .

Det finns alltid en risk att krascherna beror på ett annat problem och den tillämpade lösningen kanske inte fungerar medan FS PANIC:er på mål-DD fortsätter.

I ett sådant fall är rekommendationen att uppgradera både käll-DD:er och mål-DD:erna till säker kod (DDOS-versioner som nämns ovan) och att de felaktiga replikeringskontexterna bryts (okonfigurerade), att befintliga snapshots förfaller och replikeringskontexten/replikeringskontexterna läggs till och ominitieras. Eftersom detta är en potentiellt tidskrävande process och det kan finnas flera replikeringskontexter som kan vara orsaken till problemet kontaktar du din supportleverantör och hänvisar till detta KB-artikelnummer och eventuella åtgärder som har utförts hittills för att få hjälp.