Домен даних: Файлова система DDFSY панікує, якщо реплікація MTREE налаштована для сховища Veeam DDBOOST

При використанні VEEAM або будь-якої іншої програми резервного копіювання, що використовує BOOST для виконання резервного копіювання, використовується функція Virtual Synthetics, вона створює нові резервні копії з існуючих, зшиваючи частини попередніх резервних копій на DD, а потім додає відмінності. Попередні резервні копії, які використовуються для зшивання, називаються «базовими файлами».

Більшість програм резервного копіювання читають, але не змінюють базові файли, які використовуються для синтезу нових образів резервних копій, однак VEEAM працює інакше, при виконанні резервного копіювання він перезаписує частини базових файлів, які вже знаходяться на диску.

Якщо для цього VEEAM LSU/MTree налаштована вихідна реплікація MTree, можливо, що один файл резервної копії, що реплікується, буде змінено за допомогою BOOST під час синтезу нових файлів резервних копій. Якщо вихідний DD працює під керуванням DDOS 6.x і ввімкнено реплікацію рецептів (параметр оптимізації швидкості/продуктивності в DDOS 6.x і пізніших версіях), це може призвести до отримання неправильних контрольних сум на цільову DD, що може призвести до багаторазового збою FS (файлової системи) з такими повідомленнями:

27 лютого 04:05:19 mtree-repl-dd.example.com ddfs[10654]: ПОМИЛКА: MSG-INTRNL-00001: ПАНІКА: ddr/repl/mrepl_replica.c: mrepl_finish_file_transfer_common: 3712: ! (orig_chksum == repl_chksum).

Подібно до того, як VEEAM синтезує нові резервні копії з існуючих, може бути перезапис деяких частин файлів, що реплікуються, коли вони використовуються як базовий файл для синтезу нових образів резервних копій. Це створює плутанину під час реплікації рецептів, коли VEEAM Storage Unit також налаштовано на використання як частини реплікації MTree, що може спричинити паніку цільового DD.

Зауважте, що цей дефект стосується кінцевого кінця для реплікації MTree лише тоді, коли джерело:

• Запуск DDOS 6.0.1.0 або ранішої версії (наприклад, це вплине на всі DDOS 6.0.0.x)
• Запуск DDOS 6.x раніше, ніж DDOS 6.0.2.0 або 6.1.1.1
• Запуск резервних копій VEEAM на LSU/MTree , і той самий MTree реплікується до цілі за допомогою реплікації MTree
• Резервне копіювання BOOST з увімкненою віртуальною синтетикою виконується на той самий LSU/MTree
•  Коли цей дефект виникає, це може призвести до того, що реплікований MTree призначення стане недоступним при багаторазовому перезапуску процесу FS. Тим, хто, можливо, використовує це налаштування або планує налаштувати свої системи таким чином, рекомендується або скористатися обхідним шляхом, описаним нижче, або оновитися до фіксованого DDOS 6.0.2.0 або 6.1.1.1 (або будь-якого пізнішого випуску).

Зауваження: можливо, що той самий рядок PANIC на кінцевому кінці для реплікації MTree може виникнути для проблем, відмінних від цієї, оскільки помилка просто вказує на те, що контрольна сума на знімку реплікації MTree не збігається. Якщо у вас виникли сумніви щодо описаної тут проблеми або того, як її обійти, зверніться до свого постачальника послуг підтримки, який уклав договір, і посилайтеся на номер статті бази знань 491049.

Компанія DD Engineering визначила першопричину паніки FS на цільовому вузлі та виправила її в наступних випусках:

• DDOS 6.0.2.0 і пізніші версії
• DDOS 6.1.1.1 і пізніших версій

Усім, хто постраждав від цього дефекту або планує налаштувати подібну конфігурацію, рекомендується якнайшвидше оновити ДД вихідного коду до згаданих релізів.

Для тих, хто не бажає оновлюватися, або тих, хто зіткнувся з проблемою до того, як виправлений випуск стане доступним, є обхідний шлях.
Він полягає у вимкненні оптимізації реплікації рецептів у вихідній системі DDOS 6.x.
Ця оптимізація присутня тільки в DDOS 6.x і пізніших версіях, єдиним недоліком її відключення було б зниження швидкості реплікації, щоб вона була рівною тій, що досягається на DDOS 5.7.

Перед розгортанням вам слід перевірити, чи можна застосувати цей обхідний шлях до поточної конфігурації:

1. Перевірте, чи використовує вихідний DD DDOS 6.x до випуску, який це виправив (помилку виправлено в DDOS 6.0.2.0 і 6.1.1.1 і пізніших версіях)
2. Переконайтеся, що DD, налаштований для резервних копій VEEAM, також налаштований на реплікацію MTree для суб'єкта LSU/MTree як джерела (перевірка нещодавнього ASUP була б найпростішим способом підтвердження), наприклад:

CTX: 20 Режим: джерело Призначення: mtree://destination-dd.example.com/data/col1/destination_MTree Увімкнено: так

 Якщо всі перераховані вище умови застосовуються, ця система може бути схильна до вищезгаданих дефектів і може призвести до збою цільової реплікації FS.

Щоб застосувати обхідний шлях, потрібно спочатку переконатися, що не запущено реплікацію або резервне копіювання BOOST, а потім змінити налаштування реєстру, що не вимагає простоїв. Перш ніж розпочати цей процес, будь ласка, прочитайте заяву УВАГА, розташовану під останнім кроком цієї процедури.

1. Переконайтеся, що реплікація DD в DD вимкнена на вихідному DD під керуванням DDOS 6.x:

# реплікація відключити все

2. Крім того, перш ніж застосовувати налаштування реєстру, переконайтеся, що немає поточних резервних копій BOOST або BOOST MFR до або з потенційно небезпечного VEEAM LSU/MTree. При необхідності тимчасово відключити резервне копіювання і МФР в або з цього ЛДУ:

# ddboost file-replication показати активні всі
# ddboost file-replication показати статистику

3. Для цієї зміни реєстру потрібні привілеї режиму SE.

4. У режимі SE змініть налаштування реєстру, щоб вимкнути використання реплікації рецептів:

# se sysparam set RECIPE_REPL_ENABLED=FALSE

5. Переконайтеся, що системний параметр встановлено правильно та відображається як "FALSE" (вимкнено)

# se sysparam show RECIPE_REPL_ENABLED
Опис назви Поточне типове перевизначення
-------------------   ------------------------------------------------   -------   -------   --------
RECIPE_REPL_ENABLED Увімкнути копіювання рецептів (застосовується лише до початкових кодів) FALSE TRUE rpc
-------------------   ------------------------------------------------   -------   -------   --------

6. Тепер ви можете повторно ввімкнути реплікацію DD на DD і відновити резервне копіювання BOOST і BOOST MFR до або з LSU:

# реплікація увімкнути всі

УВАГА: Якщо обробку рецептів було вимкнено у системі-джерелі домену даних, яку також налаштовано як кінцевий кінець для реплікації, у системах-джерелах для цих контекстів також потрібно буде виконати описаний вище процес (реплікацію рецептів вимкнено).

Крім того, зауважте, що після оновлення до фіксованого випуску (DDOS 6.0.2.0 або 6.1.1.1) параметр потрібно буде відновити, щоб можна було використовувати реплікацію рецептів, оновлення не призведе до скидання розділу реєстру. Після завершення оновлення знову ввімкніть реплікацію рецептів, увійшовши до ДД, увійдіть у режим привілеїв SE та запустіть:

  # se sysparam reset RECIPE_REPL_ENABLED

Якщо ви не впевнені в описаному вище процесі, зверніться до свого постачальника послуг підтримки, з яким укладено договір, і зверніться до цієї статті бази знань 491049 .

Завжди існує ймовірність того, що ПАНІКА пов'язана з іншою проблемою, і застосований обхідний шлях може не спрацювати, поки FS PANIC на DD призначення триває.

У такому випадку рекомендація полягає в тому, щоб як вихідний, так і цільовий DD були оновлені до безпечного коду (DDOS-релізи, згадані вище), а контекст(и) реплікації, що порушують, були зламані (неналаштовані), термін дії існуючих знімків закінчився, а контекст(и) реплікації були повторно додані та повторно ініціалізовані. Оскільки це потенційно трудомісткий процес і може бути кілька контекстів реплікації, які можуть бути причиною проблеми, зверніться по допомогу до свого постачальника послуг підтримки, з яким укладено договір підтримки, і зверніться за допомогою до цього номера статті бази знань та будь-яких дій, виконаних до цього часу.