Data Domain: System plików DDFSY zgłasza błąd, jeśli replikacja MTREE skonfigurowana dla jednostki pamięci masowej Veeam DDBOOST

W przypadku korzystania z pamięci VEEAM lub dowolnej innej aplikacji do tworzenia kopii zapasowych za pomocą boost do wykonywania kopii zapasowych korzysta się z funkcji Virtual Synthetics, tworzy ona nowe kopie zapasowe z istniejących poprzez zszywanie części poprzednich kopii zapasowych na DD, a następnie dodanie różnic. Wcześniejsze kopie zapasowe używane do zszycia nazywa się "plikami podstawowymi".

Większość aplikacji do tworzenia kopii zapasowych odczytuje, ale nie modyfikuje plików podstawowych używanych do syntetyzacji nowych obrazów kopii zapasowych, jednak veeam działa inaczej, podczas wykonywania kopii zapasowych nadpisuje części plików podstawowych już na dysku.

Po skonfigurowaniu replikacji wychodzącej MTree dla tego veeam LSU/MTree możliwe jest, że jeden plik kopii zapasowej jest modyfikowany przez BOOST podczas powielania nowych plików kopii zapasowych. Jeśli źródłowa DD korzysta z DDOS 6.x, a replikacja przepisów jest włączona (opcja optymalizacji szybkości/wydajności w DDOS 6.x i nowszych), może to spowodować, że do docelowej bazy danych docierają nieprawidłowe sumy kontrolne, co może spowodować wielokrotne niepowodzenie FS (systemu plików) z komunikatami takimi jak:

27 lutego 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).

Sposób, w jaki veeam syntetyzuje nowe kopie zapasowe z istniejących, może spowodować zastąpienie niektórych części plików replikowanych, gdy są używane jako plik podstawowy do syntetyzacji nowych obrazów kopii zapasowych. Powoduje to dezorientację replikacji przepisów, gdy moduł pamięci masowej VEEAM jest również skonfigurowany do użytku jako część replikacji MTree, co prawdopodobnie powoduje, że docelowy DD to PANIC.

Należy pamiętać, że ta usterka ma zastosowanie tylko do docelowego końca replikacji MTree tylko wtedy, gdy źródłem jest:

• Uruchamianie systemu DDOS w wersji 6.0.1.0 lub starszej (na przykład wszystkie wersje DDOS 6.0.0.x mogą mieć wpływ)
• Uruchamianie systemu DDOS w wersji 6.x starszej niż DDOS 6.0.2.0 lub 6.1.1.1
• Uruchamianie kopii zapasowych VEEAM do LSU/MTree i tego samego M-drzewa jest replikowane do celu przy użyciu replikacji MTree
• Kopie zapasowe BOOST z włączoną funkcją Virtual Synthetics są wykonywane w tym samym LSU/MTree
•  W przypadku napotkania tej usterki może doprowadzić do tego, że zreplikowane docelowe MTree stanie się niedostępne po ponownym uruchomieniu wielu procesów FS. Osoby, które mogą korzystać z tej konfiguracji lub planują skonfigurować swoje systemy w ten sposób, zachęcamy do zastosowania obejścia opisanego poniżej lub aktualizacji do stałej wersji DDOS 6.0.2.0 lub 6.1.1.1 (lub dowolnej nowszej wersji).

Uwaga: możliwe jest, że ten sam ciąg PANIC na końcu docelowym dla replikacji MTree może wystąpić w przypadku problemów innych niż ten, ponieważ błąd wskazuje jedynie, że suma kontrolna w migawce replikacji MTree nie jest zgodna. W przypadku wątpliwości dotyczących opisanego tutaj problemu lub sposobu obejścia problemu należy skontaktować się z zakontraktowanym dostawcą pomocy technicznej i zapoznać się z tym numerem artykułu bazy wiedzy 491049.

Dział inżynieryjny DD zidentyfikował główną przyczynę dla KONTROLERÓW FS PANIC w węźle docelowym i opublikował poprawkę w następujących wersjach:

• DDOS w wersji 6.0.2.0 lub nowszej
• DDOS w wersji 6.1.1.1 lub nowszej

Osobom, których dotyczy ta usterka lub planuje skonfigurować podobną konfigurację, zaleca się jak najszybsze uaktualnienie źródłowego DD do wymienionych wersji.

W przypadku tych, którzy nie chcą uaktualnić lub którzy napotykają problem przed udostępnieniem stałej wersji, istnieje obejście problemu.
Obejmuje ona wyłączenie optymalizacji replikacji przepisów na źródłowym systemie DDOS 6.x.
Ta optymalizacja jest obecna tylko w DDOS 6.x i nowszych, jedyną wadą wyłączenia tej funkcji jest obniżenie szybkości replikacji w taki sam sposób, jak w przypadku systemu DDOS 5.7.

Przed wdrożeniem należy najpierw potwierdzić, czy to obejście będzie miało zastosowanie do bieżącej konfiguracji:

1. Sprawdź, czy źródłowy DD korzysta z DDOS 6.x przed wydaniem, które zostało naprawione (błąd naprawiony w DDOS 6.0.2.0 i 6.1.1.1 lub nowszej)
2. Upewnij się, że DD skonfigurowany dla kopii zapasowych VEEAM jest również skonfigurowany do replikacji MTree dla podmiotu LSU/MTree jako źródła (sprawdzanie niedawnego ASUP byłoby najprostszym sposobem potwierdzenia), na przykład:

CTX: Tryb 20: źródłowy cel docelowy: mtree://destination-dd.example.com/data/col1/destination_MTree włączone: tak

 Jeśli zastosowano wszystkie powyższe warunki, ten system może podlegać wyżej wymienionym defektom i spowodować awarię docelowego FS replikacji.

Aby zastosować obejście problemu, należy najpierw upewnić się, że nie uruchomiono replikacji ani kopii zapasowych BOOST, a następnie wprowadzić zmianę ustawień rejestru, która nie wymaga przestoju. Przed rozpoczęciem tego procesu należy przeczytać oświadczenie CAUTION zamieszczone poniżej ostatniego kroku tej procedury.

1. Upewnij się, że replikacja DD do DD jest wyłączona w źródłowej DD z DDOS 6.x:

# replikacja wyłącz wszystkie

2. Przed zastosowaniem ustawienia rejestru należy także upewnić się, że nie ma żadnych bieżących kopii zapasowych BOOST lub BOOST MFR do lub z potencjalnie powodujących problemy z VEEAM LSU/MTree. W razie potrzeby tymczasowo wyłącz kopie zapasowe i MFR do lub z tego LSU:

# ddboost file-replication show active all
# ddboost file-replication show stats

3. Ta zmiana rejestru wymaga uprawnień trybu SE.

4. W trybie SE zmień ustawienie rejestru, aby wyłączyć korzystanie z replikacji przepisów:

# se sysparam set RECIPE_REPL_ENABLED=FALSE

5. Sprawdź, czy parametr systemu został prawidłowo ustawiony i wyświetla się jako "FALSE" (wyłączony)

# se sysparam show RECIPE_REPL_ENABLED
Opis nazwy — bieżące zastąpienie domyślne
-------------------   ------------------------------------------------   -------   -------   --------
RECIPE_REPL_ENABLED Włącz replikację przepisów (dotyczy tylko źródła) FALSE TRUE rpc
-------------------   ------------------------------------------------   -------   -------   --------

6. Teraz można ponownie włączyć replikację DD do DD i wznowić tworzenie kopii zapasowych BOOST oraz boost MFR do LSU lub z poziomu LSU:

# replikacja włącz wszystkie

PRZESTROGA: Jeśli przetwarzanie przepisów zostało wyłączone w systemie źródłowym Data Domain, który jest również skonfigurowany jako docelowy koniec replikacji, systemy źródłowe dla tych kontekstów również będą musiały wykonać powyższy proces (replikacja przepisów wyłączona).

Należy również pamiętać, że po uaktualnieniu do stałej wersji (DDOS 6.0.2.0 lub 6.1.1.1) należy przywrócić ustawienie, aby można było wykorzystać replikację przepisu, uaktualnienie nie spowoduje zresetowania klucza rejestru. Po zakończeniu aktualizacji ponownie włącz replikację przepisów, logując się do DD, wejdź w tryb uprawnień SE i uruchom:

  Resetowanie sysparam # sysparam RECIPE_REPL_ENABLED

Jeśli nie masz pewności co do procesu opisanego powyżej, skontaktuj się z zakontraktowanym dostawcą pomocy technicznej i zapoznaj się z tym artykułem 491049 bazy wiedzy.

Zawsze istnieje możliwość, że KONTROLERY PANIC wynikają z innego problemu, a zastosowane obejście może nie działać, podczas gdy panice FS w docelowym DD nadal działają.

W takim przypadku zaleca się uaktualnienie źródłowych i docelowych dysków DD do kodu bezpiecznego (wspomnianych powyżej wersji DDOS) oraz ponowne dodawanie i inicjowanie kontekstów replikacji powodujących problemy. Jest to potencjalnie czasochłonny proces i może istnieć kilka kontekstów replikacji, które mogą być przyczyną problemu, skontaktuj się z zakontraktowanym dostawcą pomocy technicznej i odwołaj się do tego numeru artykułu bazy wiedzy oraz wszelkich wykonanych do tej pory działań w celu uzyskania pomocy.