Comments 8
1) У dfs есть выбор приоритетного сервера
2) Опытным путем установлен лучший вариант:
Включаются оба конечных объекта. репликация настраивается одностороняя. второй(резервный) сервер ставится в режим только-чтение.
Схема позволяет избежать конфликтов при репликации, и в случае падения первого сохрянет доступ хотя бы на чтение и переключение незаметно для пользователей
Ну и как бонус, со второго резервного сервера можно настроить бекап, не затрагивая производительность первого.
2) Опытным путем установлен лучший вариант:
Включаются оба конечных объекта. репликация настраивается одностороняя. второй(резервный) сервер ставится в режим только-чтение.
Схема позволяет избежать конфликтов при репликации, и в случае падения первого сохрянет доступ хотя бы на чтение и переключение незаметно для пользователей
Ну и как бонус, со второго резервного сервера можно настроить бекап, не затрагивая производительность первого.
Эти нюансы позволяют смоделировать ситуацию, когда пользователь А обратится на реплику А и будет работать там с данными, а пользователь Б обратится на реплику Б и будет там работать с данными. В результате будут образованы ДВЕ ветки измененных данных, и DFS не будет знать какие данные правильные, а просто выберет те, которые последние по времени изменения. Можете себе представить что будет твориться в этой ситуации с файловым хранилищем, или того хуже, с базами данных
Вообще у баз данных есть свои механизмы репликации, потому вряд ли кто-то надумает использовать DFS для этого, да и микрософт сама позиционирует DFS для хранения данных пользователей http://technet.microsoft.com/en-us/library/cc779627%28WS.10%29.aspx, а не файлов БД.
В подобной ситуации файл будет скопирован в папку ConflictandDeleted и на моей памяти я ни разу конфликтов не видел (хотя это и не означает что их может не быть). Так что информация не совсем теряется, но чтобы достать её без помощи системного администратора, надо постараться (хотя я этот вопрос глубоко не разбирал).
Сам я DFS использовал для поддержания консистентности данных (профили и личные файлы пользователей) в разных отделениях (т.е. физически в разных местах), почти никаких проблем не встретил (пришлось добавить ключ в реестр чтобы система начала видеть правильно обновление файлов в шаре). Всё устроило.
Вообще у баз данных есть свои механизмы репликации, потому вряд ли кто-то надумает использовать DFS для этого, да и микрософт сама позиционирует DFS для хранения данных пользователей http://technet.microsoft.com/en-us/library/cc779627%28WS.10%29.aspx, а не файлов БД.
В подобной ситуации файл будет скопирован в папку ConflictandDeleted и на моей памяти я ни разу конфликтов не видел (хотя это и не означает что их может не быть). Так что информация не совсем теряется, но чтобы достать её без помощи системного администратора, надо постараться (хотя я этот вопрос глубоко не разбирал).
Сам я DFS использовал для поддержания консистентности данных (профили и личные файлы пользователей) в разных отделениях (т.е. физически в разных местах), почти никаких проблем не встретил (пришлось добавить ключ в реестр чтобы система начала видеть правильно обновление файлов в шаре). Всё устроило.
Я несколько раз встречал людей, которые клали 1С базы(DBF) в DFS и реплицировали их. А потом удивлялись чудесам которые начинали там происходить.
У вас не было конфликтов и проблем, т.к. вы использовали репликацию для разных отделений (могу ручаться что и для разных сайтов в домене), и это правильно. DFS для этого и создавалась.
Здесь же конфликты более вероятны, т.к. две реплики находятся в пределах одного сайта, а значит они практически равноправны для DFS.
У вас не было конфликтов и проблем, т.к. вы использовали репликацию для разных отделений (могу ручаться что и для разных сайтов в домене), и это правильно. DFS для этого и создавалась.
Здесь же конфликты более вероятны, т.к. две реплики находятся в пределах одного сайта, а значит они практически равноправны для DFS.
Да у меня серверы в разных сайтах были.
Но для отказоустойчивости в пределах одного сайта есть ведь кластеризация, почему бы её не использовать, это ведь более логично?
Но для отказоустойчивости в пределах одного сайта есть ведь кластеризация, почему бы её не использовать, это ведь более логично?
да. это единственный правильный выход.
Но не забываем про редакции серверов которые кластеризацию поддерживают и цены на них.
Да я и не предлагаю кластеризацию — это так… отчасти онлайн-бэкап, отчасти игрища с DFS.
Все равно автоматически не переключается, будет простой, ну и куча других минусов — см пост.
Я лично такое не использую, но решил описать как вариант, который дешев и прост в настройке, тем более, что ранее я обещал это сделать (написать) — вот и написал :)
Но не забываем про редакции серверов которые кластеризацию поддерживают и цены на них.
Да я и не предлагаю кластеризацию — это так… отчасти онлайн-бэкап, отчасти игрища с DFS.
Все равно автоматически не переключается, будет простой, ну и куча других минусов — см пост.
Я лично такое не использую, но решил описать как вариант, который дешев и прост в настройке, тем более, что ранее я обещал это сделать (написать) — вот и написал :)
Если я ничего не путаю, то размеры подпапок DfsrPrivate можно настраивать… Staging и ConflictAndDeleted уж точно. Это хоть как-то уменьшит потребности в дисковой емкости.
Как известно, помимо синхронизации, DFS дает большой огромный плюс в получении сетевого ресурса непривязанного к конкретному серверу/имени.
Даже только из-за этого стоит поднять DFS. Т.к. контроллера обычно 2, то поднимая на них корень DFS мы практически ничего не теряя в надежности (правда, чуть теряя в скорости первого доступа к ресурсу) получаем единое дерево сетевых ресурсов. На хабре уже была статья на этот счет. Мы этим подходом пользуемся еще с 2000 винды (правда, со своими ньюансами).
+ На серверах нужны сервисные утилитки (стандартные для всех, вроде sysinternals) — для этого dfs подходит идеально. изменил на одном — изменилось на всех (+распределенное хранилище логов серверов получается).
Даже только из-за этого стоит поднять DFS. Т.к. контроллера обычно 2, то поднимая на них корень DFS мы практически ничего не теряя в надежности (правда, чуть теряя в скорости первого доступа к ресурсу) получаем единое дерево сетевых ресурсов. На хабре уже была статья на этот счет. Мы этим подходом пользуемся еще с 2000 винды (правда, со своими ньюансами).
+ На серверах нужны сервисные утилитки (стандартные для всех, вроде sysinternals) — для этого dfs подходит идеально. изменил на одном — изменилось на всех (+распределенное хранилище логов серверов получается).
вы не поверите, но с этого все и началось. И именно там поднялся вопрос о плюсах и минусах синхронизации, который плавно переродился в этот пост.
Sign up to leave a comment.
Опытные мелочи-10, или «DFS и отказоустойчивость»