Реплікація DFS через VPN: блокування — це не те, що ви отримуєте

Канал зашифрований, постійно ввімкнений і достатньо швидкий, тому спільна тека має поводитися як одна тека на обох майданчиках. Саме на цьому припущенні тримаються більшість проєктів реплікації DFS, які потім дивують людей. DFSR — багатомайстровий і асинхронний: кожна репліка незалежно відстежує версії, і ніщо в протоколі не утримує блокування між серверами. VPN передає трафік між ними і не додає нічого з тієї координації, якої потребує це припущення. Сплануйте модель запису й модель ємності, інакше перший справжній конфлікт стане інцидентом підтримки.

Міф: VPN перетворює репліки на одну файлову систему

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

Шифрування й доступність — властивості каналу; узгодженість — властивість рушія реплікації та вашого робочого процесу.

Що DFSR насправді реплікує

Кожен сервер зберігає власну копію та власні метадані версій. Зміни поширюються, коли дозволяють з’єднання і розклад, а рушій використовує віддалене диференціальне стиснення, щоб надсилати лише змінені частини файлу. Коли дві репліки змінюють той самий файл до надходження будь-якого оновлення, одна версія перемагає, а другу відсувають убік як конфліктну копію. Жоден сервер не заблокував другу правку, бо блокування вимагало б розподіленого блокування, якого DFSR не надає.

Шлях у просторі імен робить копії легко доступними і не робить їх узгодженими.

Місце під staging — це робоча ємність, а не резервна копія

Staging — це робоча область, яку реплікація використовує, поки збирає зміни. Настанови Microsoft щодо розміру беруть сумарний розмір 32 найбільших файлів у реплікованій теці як мінімум, а додаткове місце корисне під час початкової реплікації. Тому дереву дрібних документів і теці з кількома великими архівами потрібні різні форми staging. Коли staging вичерпується, реплікація зупиняється так, що це виглядає як збій мережі. Розрахуйте його за даними, а потім продовжуйте стежити, коли дані змінюються.

Staging не є резервною копією, а поширення змін не є історією версій.

Попереднє заповнення — це оптимізація, а не короткий шлях

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

Перевірте початковий стан до того, як користувачі покладуться на призначення, а не після першої скарги.

Виберіть вікно і визначте, що означає актуально

Розклад реплікації та обмеження пропускної здатності визначають, коли партнери можуть обмінюватися даними. Вузьке вікно після робочого дня — це законний проєкт, що залишає затримку протягом дня, за умови, що всі погодилися: віддалена копія має бути актуальною лише до ранку.

Запишіть це речення, бо «затримка — сорок хвилин» турбує лише тоді, коли мету ніхто не визначив.

Приймайте з робочим процесом, а не з одним файлом

Перевіряйте на файлах, якими люди справді користуються: великий документ, рутинна правка, видалення й навмисна одночасна правка на обох майданчиках. Переконайтеся, що поведінка під час конфлікту відповідає тому, що ви сказали бізнесу, і що шлях відновлення з резервної копії відокремлений від реплік. Потім кілька тижнів стежте за обсягом змін, зростанням черги та запасом staging щодо вікна обслуговування. Ємність VPN — одна з кількох меж, і вона рідко виявляється першою, до якої ви доходите.

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