Распределенная файловая система DFS ( Distributed File System) – это технология, обеспечивающая возможности упрощения доступа к общим файловым ресурсам и глобальной репликации данных. Благодаря DFS распределённые по различным серверам общие ресурсы (каталоги и файлы) можно объединить в единую логическую UNC структуру, которая для пользователя выглядит, как единый сетевой ресурс. Даже при изменении физического местоположения целевой папки, это не влияет на доступ пользователя к ней.
Реализация служб DFS в Windows Server 2012 отличается от предыдущих версиях Windows. В первую очередь отметим, что технологии DFS в Windows Server 2012 реализованы в виде двух отдельных, независимых друг от друга служб — DFS Namespaces и DFS Replication , включенных в роль файлового сервера (File and Storage Services).
- DFS Namespaces (DFSN или DFS-N) – пространство имен DFS. Позволяет объединять в единую логическую структуру общие папки, расположенные на различных серверах организации. Каждое пространство имен для пользователя выглядит как единая сетевая папка с подкаталогами. Реальная структура данного пространства имен DFS является скрытой от пользователя, и может включать в себя различные сетевые папки, расположенные на различных серверах и сайтах.
- DFS Replication (DFSR или DFS-R) — служба DFS репликации. Позволяет организовать эффективную службу репликации каталогов (в том числе включенных в пространство имен DFS) между различными серверами и сайтами AD. Данная служба для репликации использует специальный алгоритм удаленного разностного сжатия – RDC- remote differential compression. Благодаря RDC, которая отслеживает изменения в файлах, при репликации копируются не файлы целиком (как в случае с FRS репликацией), а только их блочные изменения.
Установка служб DFS в Windows Server 2012
Установить службы DFS можно с помощью консоли Server Manager или же при помощи Windows PowerShell.
Как мы уже говорили, службы DFS являются элементами роли Files and Storage Services:
Но проще и быстрее установить все DFS службы и консоль управления DFS с помощью PowerShell:
Install-WindowsFeature FS-DFS-Namespace, FS-DFS-Replication, RSAT-DFS-Mgmt-Con
, где FS-DFS-Namespace – служба DFS Namespaces
FS-DFS-Replication – служба репликации DFS Replication
RSAT-DFS-Mgmt-Con– mmc консоль управления службами DFS — DFS Management Tools (также входит в состав Remote Server Administration Tools для Windows 10)
Настройка пространства имен DFS в Windows Server 2012
Перейдем к описанию процедуры настройки пространство имен DFS, для чего необходимо открыть панель управления DFS Management tool.
Создадим новое пространство имен (New Namespace).
Необходимо указать имя сервера, который будет содержать пространство имен (это может быть как контроллер домена, так и рядовой сервер).
Затем следует указать имя создаваемого пространства имен DFS и перейти в расширенные настройки (Edit Settings).
Здесь следует указать имя пространства имен DFS и права доступа к данному каталогу. Обычно рекомендуется указать, что доступ к сетевой папке разрешен Всем (Everyone), в этом случае права доступа проверяются на уровне файловой системы NTFS.
Далее мастер предложит указать тип создаваемого пространства имен. Это может быть Domain-based namespace (доменное пространство имен) или Stand-alone namespace (отдельное пространство имен). Domain-based namespace обладает ряд преимуществ, но для его работы нужен, собственно домен Active Directory и права администратора домена (либо наличие делегированных прав на создание доменных пространств имен DFS).
После окончания работы мастера в ветке Namespaces консоли управления DFS появится созданное нами новое пространство имен DFS. Чтобы пользователи при доступе к DFS каталогам видели только те каталоги, к которым у них имеется доступ, включим для данного пространства DFS Access-Based Enumeration (подробнее о данной технологии в статье Access-Based Enumeration в Windows). Для этого откройте окно свойств созданного пространства имен.
И на вкладке Advanced включите опцию Enable access-based enumeration for this namespace.
Чтобы посмотреть содержимое нового пространства DFS, просто наберите в окне проводника UNC путь: \\имя_домена_или_сервера\DFS
Добавление дополнительного DFS сервера
В доменное пространство имен DFS можно добавить дополнительный сервер (пункт меню Add Namespace Server), который его будет поддерживать. Делается это для увеличения доступности пространства имен DFS и позволяет разместить сервер пространства имен в том же сайте, в котором находится пользователи.
Добавление нового каталога в существующее пространство имен DFS
Теперь нужно добавить новый сетевой каталог в иерархию созданного нами пространства имен DFS. Нажмите кнопку Add Folder Target.
Укажите наименование каталога в DFS пространстве и его реальное местоположение на существующем файловом сервере (Folder targets).
Настройка DFS-репликации на Windows Server 2012
Технология репликации DFS-R предназначена для организации отказоустойчивости пространства имен DFS и балансировки нагрузки между серверами. DFS-R автоматически балансирует трафик между репликами в зависимости от их загрузки и в случае недоступности одного из серверов перенаправляет клиентов на другой сервер-реплику. Но прежде, чем говорить о DFS репликации и ее настройке в Windows Server 2012перечислим основные системные требования и ограничения:
- Служба DFS Replication должна быть установлена на всех серверах, которые планируется включить в группу репликации
- Все сервера в группе репликации должны находиться в одном лесу AD
- Уровень леса Active Directory должен быть как минимум Windows Server 2003 R2 (при установке первого домена контроллера на Windows Server 2012 схема обновляется автоматически).
- Функциональный уровень домена — как минимум Windows Server 2008
- Необходимо убедиться, что антивирусное обеспечение на файловых серверах совместимо с технологией репликации DFS
- Реплицируемые каталоги должны располагаться на томах с файловой системой NTFS (файловые системы ReFS и FAT не поддерживаются). Также не поддерживается репликация данных, хранящихся на on Cluster Shared Volumes
В консоли DFS Managment выберите нужный вам DFS Namespace и щелкните ПКМ по каталогу, для которого необходимо создать реплику и выберите пункт Add Folder Target.
И укажите полный (UNC) путь к сетевому каталогу другого сервера, в котором и будет храниться реплика.
На вопрос хотите ли вы создать группу репликации отвечаем Yes.
Запускается мастер настройки репликации. Проверяем имя группы репликации и каталог.
Указываем первичный (Primary) сервер. Именно этот сервер будет источником данных при инициальной (первичной) репликации.
Затем выбираем тип топологии (соединения) между членами группы репликации. В нашем примере выбираем Full Mesh (все со всеми).
И, наконец, указываем расписание репликации и параметры bandwidth throttling – ограничение доступной для репликации полосы пропускания. 
После окончания работы мастера, запуститься первоначальная синхронизация.
В случае необходимости, настройки расширенных параметры расписания репликации и максимальную полосу пропускания под данный трафик, можно задать в ветке Replication.
А как дело обстоит с применением изменений файлов, произведенных на разных репликах?
Если разные пользователи одновременно изменят один и тот же файл на разных серверах, служба репликации DFS обнаруживает конфликт и будет использовать ту версию файла, которая была сохранена последней. Другой файл будет помещен в папку DfsrPrivate\ConflictandDeleted (на компьютере, разрешившим конфликт). Файл будет лежать в жтой папке до ее очистки, которая происходит при превышении заранее заданного размера папки ConflictandDeleted. Также при возникновении конфликта служба репликации DFS регистрирует данное событие в журнале событий репликации DFS. Стоит отметить, что папка ConflictandDeleted не реплицируется.
Здравствуйте! Спасибо за статью. Разъясните, пожалуйста, такую ситуацию
Допустим я использую два сервера DFS для хранения профилей пользователей и перенаправленных папок. При создании пространства имен DFS-сервер занесет в DNS-сервер локального домена адрес(а) нового пространства имен. Я настрою репликацию, чтобы все среплицировалось на второй DFS-сервер. Вот, собственно, вопрос, кто и какие записи сделает в DNS для пространства имен? И что произойдет, когда один из DFS-серверов выйдет из строя? В таком случае его запись необходимо убрать из DNS, чтобы клиенты не ломились в пустоту. В общем, мысли путаются, подскажите…
Добрый день!
В обще-то DFS не лучшее решение для организация перемещаемых профилей и поддерживается MS в весьма ограниченной конфигурации (ознакомьтесь со статьей http://support.microsoft.com/kb/2533009 ).
Создайте новое пространство имен и новую папку в нем. Для данной папки настройте репликацию данных межу двумя серверами DFS. При выходе из строя одного из серверов, клиенты автоматически будут обращаться к оставшемуся серверу. Ведь при обращении к ресурсам DFS используют не имя конкретного узла DFS, а доменный путь UNC к пространству имен DFS, который уже перенеарпавляет пользователя на доступный сервер.
исходя из устройства и принципа действия, понимаю, что само по себе DFS не лучшее решение. Для чего бы то ни было.
Могли бы вы подсказать альтернативный вариант? Ведь, для AD, профилей пользователей и всяких майкрософтных вещей нужен NTFS, чтобы всякие права соблюдались…
А, собственно, какова задача? Если нужно обеспечить отказоустойчивость файлового сервиса (в вашем случае на нем хранится ) то лучше смотрите в сторону кластера.
Вы, похоже, запутались. NTFS — это файловая система, а DFS — сетевой сервис для организации доступа к данным (данные все также хранятся на файловой системе с NTFS).
Нет, не запутался. 🙂 Я к тому, что профили пользователей с перечислением на основе доступа, правами и прочим должны находиться как раз на NTFS разделах. Если использовать другие решения отказоустойчивого файлового хранилища (не от Microsoft) соблюдение всех требования MS для профилей не гарантируется. В прочем, это уже совсем другая история.
К слову, удалось достаточно вменяемо настроить репликацию профилей в DFS, и это даже работает.
Подскажите пожалуйста, можно и правильно ли решать средствами DFS задачу резервного копирования, т.е. чтобы копии папок и файлов просто перекладывались на другой сервер если да, то какой тип топологии выбрать.
Вообще можно, и я так даже делаю. Только смотря что вы копируете… Если, например, это какая-то используемая в реалтайме база данных (sql или 1с) то актуальность данных на другом конце репликации не гарантируется.
А топология — это немного другое. Это скорее для направления, периодичности и количестве членов репликации.
Папки с файлами word/excel, по поводу баз sql понятно, там в них можно настроить репликацию. Топология, я имею в виду при настройке мастер спросит какую топологию использовать, получается для моей задачи это не важно?
Вопрос топологии — это вопрос кому с кем реплицироваться. Если нужно просто реплицировать из точки А в точку G, выбирайте «все со всеми».
Если это файлы с общим доступом, то проблем огребете по уши. Каждый открывает на своем сервере, а при сохранении возникает конфликт и сообщение о невозможности сохранения. не нашел ничего лучше, чем отключить все реплики, кроме одной. работа шла на одном сервере, на остальные только синхронизировалось. но если этот сервер отвалится, то включаешь любой другой и юзеры счастливы. при многосайтовой структуре вариант кривоват, но альтернативы не придумал.
DFS не является решением для резервного копирования. Представьте, что вы будете делать, если на каталоге-источнике был изменен важный файл… Все изменения в нем будут реплицированы по серверам-репликам. Таким образом вернуться к предыдущей версии файла не удастся…
В качестве альтернативы классическому резервному копированию можно посмотреть на Volume Shadow Copy (https://winitpro.ru/index.php/2013/09/05/sluzhba-shadow-copy-v-window-server-2012/)
Спасибо, интересно, жаль что нельзя делать теневые копии на сетевой диск!!!
В корне не верно, DFS это про отказоустойчивость, а не про бекапы.
Добрый день. Есть вопрос по ABE. В настройках пространства имён включил. Сделал несколько папок с разными правами, но всё равно продолжаю видеть их все, если захожу \\test.int\DFS
Можно как-то прояснить этот момент?
Вы видимо хотите скрыть таргеты, в таком случае в неймспейсе в настройке таргетов, на каждом из них должна стаять галочка брать права с NTFS и нужно прописать группы, соответственно если у человека этих групп не будет, то папка от него скроется.
Можно ли использовать DFS для терминальных UPD имея 2 ЦОДа без общего стореджа ???
Положить UPD в шару DFS — не проблема, у самого так сделано, главное — права на шару серверам RDSH дать корректно. А вот с вашими двумя ЦОД-ами непонятно немного.
А с реплкиой проблем нет? Ведь DFS живет по правилу «кто последний — тот и прав» Если вышел из строя один из серверов RDSH и юзер залогинился на другом сервер — проблем нет с файлом профиля ???
Какая реплика? Вы пишите про DFS, а подразумеваете DFSR.
Как я понял, у вас две территориально разнесенных ЦОД-а и вы между ними гоняете профили при помощи DFSR? При этом у вас RDSH сервера есть и в одном и в другом ЦОД-е? Вам в таком случае лучше держать две разные коллекции — каждая в совем ЦОД-е и направлять людей в тот или иной
Какая реплика? Вы пишите про DFS, а подразумеваете DFSR.
Как я понял, у вас две территориально разнесенных ЦОД-а и вы между ними гоняете профили при помощи DFSR? При этом у вас RDSH сервера есть и в одном и в другом ЦОД-е? Вам в таком случае лучше держать две разные коллекции — каждая в совем ЦОД-е и направлять людей в тот или иной ЦОд по территориальному признаку. В любом случа, гонять по DFSR UPD файлы — это плохою
Хочу отказоустойчивость на уровне ЦОДов 🙂 т.е. если один из серверов в ЦОД1 «умирает» то для пользователей это должно быть прозрачно. С RDSH все просто а вот с профилями ….
Диск профиля монтируется в папку с именем юзера при входе, монтируется он единожды и держится пока сессия юзера активна. Если сервер вышел из строя по сетевым проблемам (недоступен как для юзера так и для серверас с дисками профиля) или из-за BSODа, то юзер спокойно может подключаться заново к другому рабочему серверу и его диск примаунтится к другому серверу. Если сервер по каким-то иным причинам не принимает подключение, но сессия юзера висит и держит диск, подключиться с другого хоста не получится, потому что диск профиля занят.
Между ЦОДами у вас какая полоса сети?
1 gbit
А что будет если упавший хост с отключенным сеансом юзера снова появится в сети ?
С отключенным (висящим в фоне) сеансом сервер может остаться только ели полностью потеряет сеть, но сам устоит и будет работать. Когда сеть к нему придут снова — он попытается обновить дискрипторы к открытым дискам, у него это не получится, засыпет все логи ошибками и что будет в итоге предсказать трудно. Возвращение в строй такого сервера лучше сопроводить перезагрузкой.
Ситуация: имеется 2 файловых сервера. Один — основной, второй — реплика. Все изменения проходят на основном сервере и реплицируются на второй. В случае отказа основного сервера пространство имен тут же переключает пользователей на реплику.
Вопрос: при восстановлении основного файлового сервера (например через пару часов, где подверглись изменению 1 Гб данных) все изменения на реплике автоматически синхронизируются с основным сервером?
Если настроена двухсторонняя репликация, то да, все изменения будут на основном сервере после его возвращения в строй
Добрый день!
Перечисление на основе доступа или не работает или работает не полностью. Допустим у нас есть шара в ней включено перечисление на основе доступа. Пользователи не видят папки на которые не прав. Если эту шару скормить dfs, включить в нем галочку перечисление на основе доступа и зайти по дфсному пути — внутренние папки видно. Зайти в них нельзя, но видно. А по пути шары — не видно. В чем может быть проблема?
На практике ABE+DFS не использовал, поэтому какого-то практического опыта в этом плане у меня нет.
Но проверьте, что в консоли DFS Managment на корне вашего пространства имен DFS включена опция » Enable access-based enumeration for this namespace» (требование к мин уровню домена — Windows Server 2008). В этом случае пользователь не должен видеть недоступную иерархию пространства имен.
Походу для DFS действительно не работает именно для Target — папок, но работает для их содержимого.
Еще как вариант у target папок задать персональные DFS-пермишшены, а не наследовать из NTFS — возможно тогда ABE сработает, но я не пробовал
Люди помагите настройил дфс на двух серверах все вроди бы норм но реплику не делает кто может подсказать в чем может быть проблемо
Добрый день.
Имеется такая конфигурация:
-Server1 (DC1, DFS namespace)
-Server2(DC2)
-Server3(FileServer1, DFS replication)
-Server4(FileServer2, DFS replication)
Я правильно понял, что можно поставить DFS namespace на Server2 и тогда к пространству имен можно будет обраться даже если один из серверов (Server1, Server2) будет не доступен?
Можно ли использовать dfs, если на файловые сервера хранят постоянно изменяемые бинарные файлы (некая база данных)? Я в том плане, неизвестно же к какому файловому серверу обращается клиент через namespace?
1) Вы хотите добится отказоустойчивости пространство имен DFS или конкретных папок? В первом случае лучше использовать интегрированную в AD namespace, во втором — репликацию DFS между серверами.
2) Если вы не используете репликацию, то можно хранить на DFS что угодно. По сути она будет обеспечивать только единое пространство имен, удобное для пользователей.
Добрый день.
Я хочу добиться такого. Есть пространство имен. Через него программы пишут информацию в расшаренные папки. Эти расшаренные папки синхронизируются с помощью репликации DFS. Хочу, чтобы была возможность ставить обновления и перезагружать сервер, где расположено пространство имен, и при этом программы имели доступ по тому же пути, что и был. То есть не напрямую в расшаренную папку, а через namespace. Плюс DFS позволит в дальнейшем физически менять сервера, в случае выхода из строя.
Я правильно хочу?)
Да, все правильно.
Главный заковыка в том, что DFS хорош для хранения не слишком часто обновляемых данных. Если в один и тот же файл одновременно вносятся изменения на разных узлах репликации, вам придется потом руками разбирать конфликты, что очень утомительно.
Т.е. все зависит от профиля работы с DFS.
Добрый день.
От идеи репликации двоичной базы данных я отказался, слишком часто меняется.
Разобрался в dfs namespace и как добавлять еще один сервер для отказоустойчивости. Оказывается надо везде ставить службу dfs namespace.
Нашел утилиты для диагности dfs — dfsdiag.
Непонятным осталось:
-Сколько времени должно происходить переключение при отключении одного из серверов namespace, чтобы путь к dfs путь заработал? Один раз это заняло 10 минут.
-Как dns понимает unc путь? Например мне надо, чтобы из другого домена с доверительными отношениями люди заходили на мою dfs. В dns того домена достаточно прописать имена моих серверов с dfs namespace?
1) Лучше использовать интегрированное в AD пространство имен DFS. В этом случае, конфигурация namespace DFS будет хранится в схеме домена.
2) Да, нужно чтобы клиенты второго домена могли отрезолвить имена namespace
Кому приходилось реплицировать папки большого размера(более терабайта, с дудупликацией)?
Настроил для начала для маленькой папки, проверил, работает.
Настроил для больших папок и уже несколько суток на сервере назначения файлы не появились…
Это баг или фича?)
Как траблщутить?
DFS с большими папками/файлами работает тяжеловато, особенно если файлы часто меняются.
Попробуйте квоту Staging увеличить с 4 гб до суммарного размера 32-х самых больших файлов в каталоге репликации (рекомендации Microsoft). Размер 32-х файлов можно получить так:
Get-ChildItem C:\DFSfolder -recurse –force | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gbНу и изучайте лог %windir%\debug\DFSR*.log
здравствуйте. Как вам идея использовать DFS в 2016 сервере для репликации файлопомойки между филиалами через VPN ? В филиале планирую RODC и файловый сервер. Репликация нужна для обычных офисных файлов, CAD чертежей и т.п.
Добрый день.
DFS вполне подходит для таких задач, но имейте в виду вы будете постоянно сталкиваться с конфликтами, если один и тот же файл редактируется одновременно в головном офисе и в филиале.
Желательно заранее продумать структуру каталогов игруппу/права , чтобы у пользователей возникало как можно меньше возможностей редактирования файлов чужого филиала. В идеале чужие файлы должны быть доступны на read-only
здравствуйте. В том то и дело что файлы не чужие, они сидят в одних папках по сути. Да VPN есть VPN, может иногда и упасть. Прямая работа через VPN с сетевой папкой будет имхо не комфортна. Как лучше поступить? Спасибо!
Обычно самое простое решение — терминальный сервер в головном офисе. RDP трафик не требователен к ширине канала, если вы в RDP сесии не будете копировать большие файлы и печатать графические документы через Easy Print.
Здравствуйте.
Растолкуйте, пожалуйста, новичку в DFS пару непонятных моментов.
Есть созданный по вашей статье namespace (DFS), в нем есть Folder (Shara),
у шары есть 2 target folders (делалось по второй части статьи, для репликации). Репликация мне нужна односторонняя (FS1->FS2), поэтому в свойствах реплики для FS2 membership status выставлено read-only.
Теперь собственно вопросы: Т.к. для \\mydomain.local\DFS\Shara указано 2 таргета, не будут ли пользователи открывать файлы с обоих FS? А если все же будут, как будет себя вести репликация, если membership status у FS2 (read-only) ?
Все дело в том, что на FS2 в DfsrPrivate\ConflictAndDeleted\ я вижу кучу документов, с которыми каждый день работают пользователи (некоторые файлы по несколько раз за день попадают в ConflictAndDeleted) и не совсем понимаю откуда они тут берутся, если на FS2 они должны просто заменяться «свежими» копиями с FS1. Есть подозрение, что это как раз те файлы, которые перезаписываются новыми с FS1, но полной уверенности нет, зато полно опасений и холодка чуть ниже поясницы :))
И еще один момент требует уточнения.
Если на FS1 или FS2 настроено резервное архивирование (изменяется атрибут «архивный») у файла. Будет ли это триггером для репликации о том, что файл изменился и надо его заново отправить на FS2 ?
1. У вас FS1 и FS2 сервера находятся в разных сайтах AD?
2. Атрибуты файлов также должны реплицироваться между партнерами
В одном.
Насколько я пониманя, если у вас оба сервера с DFS папками в одном сайте, то при доступе черех DFS namespace у разных клиентов будет открываться папка то с первого, то со второго сервера (в одной сессии доступ только к одной папке, но после логофа/ребута, сервер, к которому подключится пользователь может смениться.
Это задается с помощью приоритетов. Но есть важный момент: если у вас таргеты расположены в разных сайтах AD, то решающее значение будет иметь вес сайт-линков. Т.е. вначале берутся ближайшие (согласно топологии AD-сайтов) таргеты, а уже из них выбирается таргет согласно приоритету, заданному в настройках DFSR.
Read-only потому и read-only, что там ничего изменить нельзя. Т.е. если пользователя забросит на такой таргет, то при попытке изменить содержимое он получит ошибку.
По умолчанию в эту папку попадают не только файлы, проигравшие в конфликтах, но и файлы, которые были удалены на других партнерах. О том, как это настроить, можете почитать тут, про типы конфликтов — тут. Т.е. конкретно в Вашем случае, каждый раз, когда файл будет удаляться из папки на FS1, он будет попадать в папку ConflictAndDeleted на FS2
«Методом научного тыка» было выяснено- Если просто изменить атрибут «Архивный» у файла на FS1, этот атрибут на на FS2 не перенёсся.
Подскажите как правильно должны быть настроены Referral? И как клиенты определяют с каком именно сервере имён они редактируют скажем какой-нибудь файл? Вот у меня получается что в одном пространстве имён в свойствах разных папках активны разные Referral в одной папке активен сервер имён fs-01 в свойствах другой папки активен fs-02. Я так понимаю это неправильно? Потом будут возникать конфликты и файлы будут помещаться в директорию …\DfsrPrivate\ConflictAndDeleted
Подскажите как правильно должны быть настроены Referral в свойствах папки.
Почитайте здесь и тут
Доброго времени суток. Подскажите, как сделать многоуровневую иерархию в дфс без применения репликации.
На данный момент смог добиться только такого вида:
server\dfs\конечный объект папки1, конечный объект папки2, … конечный объект папки n.
А есть необходимость сделать так:
server\dfs\папка1\конечный объект папки1, конечный объект папки2.
server\dfs\папка2\конечный объект папки3, конечный объект папки4.
Если через GUI, то тыкаете в оснастке «Управление DFS» ПКМ по пространству имен (в вашем примере это dfs) и создаёте папку БЕЗ конечного объекта.
Можно ещё через PowerShell:
New-DfsnFolder
Имейте в виду, что если у DFSN-папки уже есть конечный объект (т.е. шара, на которую она ссылается), то создать подпапку для нее не получится.
Недавно написал шаблон мониторинга DFSR для Zabbix. Взять можно здесь.
Здравствуйте, я правильно понимаю, что автоматом клиент должен коннектиться к ближайшему серверу и только при недоступности его уже к следующему, это при условии, что два сервера в разных филиалах за VPN. Как можно узнать к какому серверу DFS-N клиент подключен в данный момент?
А как можно исключить/удалить первый сервер из dfs?
К примеру, был первый физический сервер, на нем dfs, есть общие шары
Затем добавили второй (виртуальный) сервер, настроили репликацию dfs
Теперь нужно первый, физический, исключить/убрать из dfs, и пользователи будут ходить на второй, виртуальный
По всей видимости, нужно тех. окно чтобы не было открытых файлов в шарах? И как корректно это можно сделать
Здравствуйте. А как сделать что бы она была видна в тут: \\имя_домена_или_сервера\ ? Что бы человек смог пройти по указанному пути, а не набирать строчку целиком «\\имя_домена_или_сервера\DFS«?
Здравствуйте, возникла проблема такого характера, может кто-нибудь сталкивался, поднята роль Dfs реплицируется на 2-ой сервер, с недавнего времени возникла проблема, что некоторые пользователи не видят файл в папке, но некоторые в этой же папке видят,
Файлы не успевают среплицироваться? DFS сервера в разных сайтах, подключены медленными WAN link?
Да, файлы не успевают среплецирвоаться, файлы у некоторой части пользователей отображаются сразу, у некоторых спустя несколько дней, а у некоторых вообше не появляются, сеть стабильная, проверял с помощью сайтскоп
Несколько раз пытались внедрить репликацию DFS и так и не получалось. И вот почему. У разных пользователей будто работа велась с разными серверами и вот сидят коллеги в одной комнате и кидают шару. Один закинул, а второй не видит… Ждём-с. Хотя настройки вроде нормальные были..\
Потом файл поменял кто-то, а другой долго наблюдает старую версию.
Ну ок, не сразу отключили, но каково было потом удивление, сколько было «конфликтов» на пустом месте.. Хотя вроде файлы редактировали в разное время, но всё равно, были.
В итоге, плюнули и делаем бэкапы раз в сутки… Пока не пригождалось, да и ладно))
Ещё вспомнил, что когда выключали один из серверов DFS, что будто те, кто был привязан к нему, теряли вообще доступ к шаре, т.е. автоматическая работа с другим сервером не производилась.
Репликацию рассматривали как выход файлового сервера из строя и чтобы пользователи ничего не заметили… Может, это нужно для другого? Но зачем тогда? Куча есть кроссплатформенных решений для репликаций.. Или это свой велосипед от MS?)
Добрый день.
Столкнулся с такой проблемой:
Пробую настраивать в пределах одного сервера (srv1 — WinSrv2012).
— создано пространство имён — \\domain.local\dfs, включено перечисление на основе доступа
— в этом пространстве имён создана папка — share
— добавлены конечные объекты папки — \\srv1\share1, \\srv1\share2, \\srv1\share3, все они расположены на одном диске данного сервера
Не понятно почему, но при обращении по \\domain.local\dfs\share или \\srv1\dfs\share, видны и доступны только ресурсы из share1. При этом если подключаться на прямую, \\srv1\share1(share2, share3), ресурсы доступны в каждом каталоге.
— Сверял все права на директориях, share1, share2, share3 — идентичны.
— Пробовал как вариант, удалять конечные объекты папки, — share1, share2. Т.е. теоретически должны остаться доступны только ресурсы share3, но по прежнему остаются доступны ресурсы только share1. Что весьма странно, и мне совершенно не понятно такое поведение DFS… Пробовал другие комбинации share1, share2, share3, для конечного объекта папки, всё равно доступны ресурсы только share1.
— Пробовал полностью пересоздавать пространство имён. Аналогичная ситуация.
Ни чего не помогает.
Максимум, что удавалось, при создании нового пространства имён, и допустим конечном объекте папки share2, получить доступ к ресурсам данной директории через \\domain.local\dfs\share или \\srv1\dfs\share. Но дальше всё как и с share1, — доступны только ресурсы share2 при любых комбинациях конечных объектов, из share1, share2, share3.
Подскажите пожалуйста, что ещё можно попробовать сделать, что проверить?
Подскажите пожалуйста. Есть dfs на fs-srv1, сейчас настроил виртуальный сервер fs-srv2 скопировал все файлы с шарами и acl, и хочу в dns cname сделать с fs-srv1 на fs-srv2. Такое может прокатить или так не заработает? -Ну или fs-srv1 вывести из домена и новый сервер ввести под старым именем?
Если речь о standalone DFS, который не интегрирован в домен, тогда лучше вариант 2 с переименованием серверов.