В настоящее время мы работаем над реализацией стратегии аварийного восстановления. Вместо репликации SAN-SAN было решено использовать 2 живых файловых сервера, реплицируемых через DFSR. Однако я не знаю, хорошая это идея или нет.
Пример: DFS не реплицирует заблокированные файлы. Допустим, у пользователя есть открытая таблица неделями. Они периодически сохраняются, но файл остается открытым. Затем активный файловый сервер отключается, и пользователи перенаправляются на другой сервер, где файл не был реплицирован.
Есть ли способ смягчить этот сценарий? Я что-то не понимаю? Или DFSR не предназначен для использования в качестве технологии аварийного восстановления?
Изменить: Какие еще недостатки есть у DFSR в контексте DR, кроме моего примера выше?
Я только что отказался от среды DFS-R по той причине, которую вы описали выше. С заблокированными файлами невозможно справиться, и они вызывают всевозможные конфликты, особенно если оба сервера используются в качестве надлежащего аварийного переключения (поэтому пользователи обращаются к обоим серверам одновременно).
На мой взгляд, DFS-R подходит для репликации через WAN / VPN-соединения в удаленные офисы, а не как решение аварийного восстановления. Я настоятельно рекомендую получить какое-то общее хранилище и использовать отказоустойчивые кластеры, которые значительно улучшились в 2012 R2 (я все еще использую 2008 R2, но пока он нам хорошо служил).
Он не предназначен для DR. Не так - в данном случае проблема заключается в пользователе. Я не уверен, что что-нибудь с этим справится.
DR также является дрянным сценарием: он с радостью воспроизводит вирус, шифруя ваши файлы (или удаляя их).
Да и нет, сохраняйте задержку между синхронизацией, чтобы быть уверенным, что не синхронизируется стирание или повреждение. Это всего лишь хороший способ сохранить файл, который вы не хотите терять, но это минимальный сценарий «резервного копирования».
Я бы разместил этот сервер в другом месте и в локальном хранилище. (так как я не знаю вашу топологию SAN)