Создание отказоустойчивого корпоративного файл-сервера на базе DFS
В большинстве организаций, даже прошедших путь оптимизации бизнес-процессов и автоматизации документооборота, до сих пор активно используются файловые серверы, служащие хранилищами важной корпоративной информации. Системный администратор, ответственный за сохранность данных на файл-серверах, должен позаботиться не только о развертывании надежной системы резервного копирования, но и о максимальном сокращении времени простоев. Я рассмотрю самый что ни на есть частный случай: организацию, размещенную в разных корпусах гипотетического делового центра, с сетью филиалов.
Итак, исходные данные: головной офис с размещением сотрудников в двух разных корпусах, один филиал. Файл-серверы установлены в обоих корпусах головного офиса и в филиале. Между корпусами лежит оптика, с филиалом установлен VPN-канал из первого корпуса головного офиса.
Задача: обеспечить гипотетическому сотруднику максимальную доступность данных вне зависимости от его местонахождения.
Для решения данной задачи мы будем использовать технологию компании Microsoft, метко названную Distributed File System (DFS). DFS была разработана для упрощения доступа к данным и управления ими. В Windows Server 2003 R2 к ней был добавлен механизм репликации, получивший вполне прогнозируемое название DFSR (Distributed File System Replication). Если вкратце описать схему работы DFS, то это будет выглядеть примерно так:
На рисунке условно изображены 3 файл-сервера, каждый из которых служит хранилищем разных общих директорий. Сервер DFS образует корень из этих директорий и открывает к ним общий доступ под именем Summary Data. Клиенты, в свою очередь, имея необходимость использовать данные со всех трех серверов, обращаются только к DFS, который обеспечивает им централизованный доступ к нужным ресурсам. Вполне логично: ни к чему пользователю помнить UNC-пути к отдельно взятым файл-серверам, он должен везде и всегда иметь привычную, удобную рабочую среду.
Вернемся к нашей задаче. Пока наша схема сети выглядит примерно так:
Для наведения порядка в этом бедламе нам потребуется установить службы DFS на серверах. В Windows 2003 это делается через оснастку Add/Remove Windows Components:
В Windows 2008 – через мастер добавления ролей:
После установки служб DFS, запускаем оснастку Distributed File System. Она работает в стандартной среде MMC, слева в меню жмем правой кнопкой мыши (далее – ПКМ) единственный пункт и выбираем New Root. Запустится мастер настройки корня DFS. Он может быть доменным, либо изолированным:
Выбираем доменный, после чего выбираем домен, в котором будет размещено дерево логических имен DFS:
После этого нам останется только выбрать сервер, на котором будет размещен корень…
…и мы приступим непосредственно к его созданию:
Свой корень я назову Corporate FS (сокращение от Corporate File Server) и помещу его в директорию C:Corporate FS
Корень готов. Приступим к присоединению к нему файл-серверов и установке реплик. На корневом DFS-сервере я создал на диске C: общую директорию Main Office Documents с данными, на сервере SRV2 – такую же, но пустую, и на сервере SRV3 директорию Branch Office Documents, тоже с данными.
Теперь жмем на наш корень ПКМ и выбираем New Link. Первым линком будет наш общий ресурс Main Office Documents:
Аналогично добавляем \Srv3Branch Office Documents. В конце концов мы получаем следующую DFS-структуру:
Чуть позже мы ее протестируем. Но пока мы еще не решили задачу резервирования данных. Я продемонстрирую простейшую схему репликации: данные из общей папки с SRV1 будут копироваться на SRV2. Полную репликацию всех сетевых ресурсов и корня DFS рассматривать не будем, так как настраивается она аналогичным образом. Одного примера будет вполне достаточно.
Жмем ПКМ на линк Main Office Documents и выбираем New Target. В появшившемся диалоговом окне выбираем сетевой ресурс с таким же именем на SRV2, ставим галочку в чекбоксе Add this target to the replication set и жмем Ок:
Появится окно с предложением сразу же сконфигурировать репликацию. Нажимаем Ок и попадаем в мастер настройки репликации. На первом этапе нам предложат выбрать директории для хранения временных файлов репликации:
Оставляем по умолчанию и жмем Next. На следующем шаге нам будет предложено выбрать топологию репликации. Вариантов всего 4:
— Ring (кольцо) – реплика будет обмениваться информацией с двумя соседними;
— Hub and spoke (звезда) — выделяется основная реплика, с которой обмениваются информацией все остальные;
— Full mesh (полносвязная сеть) — все реплики обмениваются информацией друг с другом;
— Custom (пользовательская) – каждая пара реплик настраивается вручную.
Мы создаем схему резервирования, при которой, в случае выхода из строя оптического канала связи между корпусами головного офиса, сотрудники из второго здания не потеряют доступ к файловым ресурсам, и результаты их трудов за время ремонта оптики тоже не пропадут, поэтому нам подходят полносвязная и кольцевая топологии. Выберем полносвязную, нажмем Ок и убеждаемся, что настойка применена:
Для наглядной проверки репликации я создал на сервере SRV1 в C:Main Office Documents несколько папок и файлов:
По умолчанию репликация происходит раз в 15 минут. По прошествии этого времени данные благополучно появились без моего вмешательства и на SRV2:
Можно выполнить принудительную репликацию командой:
Осталось опубликовать DFS в Active Directory и протестировать его доступность. Для публикации кликаем ПКМ по корню DFS, выбираем Properties и в открывшемся окне переходим на вкладку Publish:
Обратите внимание: так как наш корень DFS доменный, а не изолированный, при обращении к нему может использоваться конструкция UNC только с названием домена, без уточнения имени сервера. Кстати говоря, DFS с точки зрения клиентской ОС – не более чем обычная общая папка, то есть доступна по UNC и может быть подмонтирована как сетевой диск. Нажимаем Ок.
В качестве тестера может выступить любой доменный клиент. Я воспользуюсь сервером SRV3:
В корне Corporate FS, как и предполагалось, ссылки на файл-серверы головного офиса и филиала. Впрочем, по ссылкам мы попадаем туда же, куда и задумывали. Система работает, алиллуйя.
Итак, что же дает нам DFS?
1. Логическое представление общих ресурсов, находящихся на разных серверах/рабочих станциях, работающих под управлением разных ОС. Для администратора это рай: и централизованное управление, и упрощенное представление для пользователей, а значит меньше инструктажей и головной боли.
2. Организацию отказоустойчивых схем хранения информации. Для каждого общего ресурса DFS позволяет создать почти неограниченно много реплик, что не только снижает риск потери данных, но и обеспечивает горячее резервирование, когда выход из строя целого сервера никоим образом не отражается на работе пользователей: они просто переключаются на другой сервер, даже не подозревая об этом.
3. Балансировку нагрузки. В основном, на сетевые интерфейсы.
4. Прозрачность соответствия логического представления данных и их физического расположения. Сотрудник из офиса деревни Ольховка Кировской области может работать с файл-сервером, расположенном на Барбадосе, также, как если бы он стоял у него в соседнем кабинете. Впрочем, сотрудник наверняка и так в этом будет уверен, глядя на DFS.
Айс, не правда ли?