Один из важных вопросов, который стоит перед администратором DFSR является правильный выбор топологии для репликации. В этом посте я хочу рассказать о часто используемых топологиях и об их применении.

Самой простой топологией является полностью связанная сеть (full mesh), когда есть двухсторонне соединение между любыми двумя серверами в репликационной группе. Эта топология отличается большой надежностью и устойчивостью к сбоям. Даже если половина серверов станет недоступна, то оставшиеся серверы будут продолжать работать и реплицировать данные.

Недостатком этой топологии является сложность в администрировании и мониторинге репликации в случае, если репликационная группа содержит более 10 серверов.

Для больших репликационных групп широкое распространение получила центрально-радиальная топология (Hub and spoke). В этом случае существует единый центральный сервер репликации – хаб, который соединен со всеми остальными серверами в группе. Естественно, в данном случае на центральный узел ложится очень большая ответственность. Ведь в случае проблемы на центральном сервере репликация остановится для всей группы. Для предотвращения этой ситуации устанавливают два или более хаба, которые соединены между собой в виде связанной сети. Все остальные серверы имеют соединение с каждым хабом из этой центральной группы.

Другой подход к топологии репликации – это повторение топологии сети, с целью консолидации трафика и экономии на сетевых расходах. Например, если у компании есть серверы в двух городах. Часто имеет смысл конфигурировать топологию так, что есть только одно (или два для большей надежности) соединения между серверами в разных городах. Таким образом репликация всех изменения в репликационных группах будут проходить через это соединение.

На этой неделе был выпущен “Microsoft Windows DFS Replication Service Management Pack for Microsoft Operations Manager 2005” (длинное, однако же, название).

Этот Management Pack приносит такие возможности:

• Сообщения о проблемах с репликацией данных
• Цветовой статус (красный, желтый, зеленый) для репликационных групп и серверов.
• Сообщения о конфликтах репликации

Management Pack доступен для скачивания на сайте Microsoft:

http://www.microsoft.com/downloads/details.aspx?FamilyId=651E7C4A-484B-4AA2-9FBF-F3538075B9E8&displaylang=en

Ну а теперь пост про одну из самых важных новых технологий в релизе Windows Server 2003 R2.

Как известно, администраторы файловых серверов тратят много усилий на синхронизацию Фазиловых серверов в организации. Какие только приемы не используются – от ручного копирования новых файлов или xcopy, до скриптов, которые выполняются по определенному расписанию.

Представьте, что есть возможность автоматизировать этот процесс, и сделать его более удобным для администратора. Звучит заманчиво, не так ли? В Windows Server R2, такая возможность есть – все это можно сделать с помощью DFS Replication.

DFS Replication позволяет синхронизировать реплицируемые файловые директории (replicated folders) между серверами, которые входят в репликационную группу (replication group). Серверы в репликационной группе связаны между собой соединениями (connections), так что существует путь между любыми двумя серверами.

Данные можно реплицировать как в пределах локальной сети, так и через глобальную WAN сеть. Технология DFSR была спроектирована с расчетом на медленные WAN сети и работает столь же надежно через Интернет, как и в пределах одного здания. Репликация данных устойчива к проблемам с сетью. Если связь с удаленной машиной прервется, то репликация, разумеется, остановится. Но как только сеть будет снова работать, то репликация начнется с того места, где она прервалась. Поэтому DFSR – это очень полезный инструмент для синхронизации данных между дата-центром компании и удаленными офисами в регионах.

К тому же репликация может происходить в удобное для организации время, чтобы не занимать сеть тогда, когда она нужна для других целей. Для этого можно устанавливать расписание синхронизации, и для каждого слота в расписании можно существовать лимит использования сети. Например: днем передавать данные со скоростью не более 128Кб/сек, а ночью передавать данные со скоростью 1Мб/сек.

DFSR это мульти-мастерная система репликации. Это означает, что реплицируемый файл может быть изменен на любой машине, и эти изменения будут распостранены на все машины, участвующие в репликации.

Одним из главных достоинств DFSR является компрессия данных при репликации. Используется два вида компрессии:

• Обычное сжатие данных, похожее на то, которое применяется в архиваторах
• Алгоритм дифференциальной компрессии -- Remote differential compression algorithm (RDC), который применяется для репликации изменений. Основная идея этого алгоритма состоит в том, что реплицируются только измененные части файла. Например, если есть большой текстовый документ, и мы добавили несколько страниц в середину документа, то только эти несколько страниц и будут переданы по сети во время следующего сеанса синхронизации.

Кроме того, модификация алгоритма RDC, cross-file RDC, используется и для репликации различных файлов, похожих между собой. Например, если у нас есть текстовый документ, который получен путем изменения другого документа, то cross-file RDС перешлет по сети ссылку на исходный файл вместе с информацией о различиях между файлами.

Таким образом, во многих ситуациях DFSR дает значительную экономию сетевого трафика, по сравнению с обычным копированием, за счет выигрыша от компрессии данных.

Хотя в названии технологии DFSR присутствует упоминание распределенной файловой системы, репликация может использоваться и без добавления реплицируемых директорий в пространство имен какого-либо DFS корня. Однако в большинстве случаев, DFSR используется вместе с пространством имен DFS. Это позволяет обеспечить прозрачный доступ к файловым ресурсам и безотказную работу (так как если один из серверов становится недоступным, то пользователь будет автоматически перенаправлен на другой сервер).

Когда разговор заходит о DFS, многие говорят о том, что DFS помогает пользователям быстро находить файлы, не заботясь об их физическом местоположении. Это возможно благодаря виртуальному пространству имен (virtual namespace). Возможность сделать структуру директорий прозрачной для конечного пользователя является самым известным преимуществом DFS. Однако, использования DFS может принести ряд других выгод, которые я перечислю ниже.

Более легкое администрирование файлового сервера.

Так как расположение файлов скрыто от конечного пользователя, то следовательно можно легко перенести файлы на другой сервер, не затрагивая пользователя. Рассмотрим сценарий директорий пользователей (Users folders), который популярен во многих компаниях. Пусть у нас есть следующая иерархия DFS:

\\FILESRV\Users <- локальный корень DFS

\\FILESRV\Users\Alex <- DFS ссылка указывающая на \\STORAGE1\Folders\Alex

\\FILESRV\Users\Tom <- DFS ссылка указывающая на \\STORAGE1\Folders\Tom

В один прекрасный день администратор обнаружил, что на сервере STORAGE1 мало места, и решил перевести часть пользователей на новый сервер NEWSTORAGE. Если бы не было DFS, то администратор должен был бы сказать пользователю об этом новом сервере. Если же какие-то программы автоматически используют данные из директории пользователя, то надо еще и изменить настройки программ.

Однако, с DFS можно просто изменить DFS ссылку (например \\FILESRV\Users\Alex теперь показывает на \\NEWSTORAGE\Folders\Alex). И конечный пользователь может даже не знать о том, что его данные теперь хранятся на другом файловом сервере.

Бесперебойная работа файлового сервера

Одна виртуальная директория в DFS может иметь несколько ссылок. Например:

\\FILESRV\Programs\Office2003  ->

                                                \\SERVER1\Programs\Office2003

                                                \\BACKUPSERVER\Programs\Office2003

Теперь, в случае если SERVER1 станет недоступен, например из-за проблем с сетью, пользователь будет автоматически перенаправлен к серверу SERVER1.

Балансировка нагрузки (load balancing)

В предыдущем примере, можно настроить DFS так, чтобы пользователи направлялись сразу на оба сервера, обеспечивая их равномерную нагрузку. Это ведет к более быстрой работе с файлами.

Автоматический доступ к наиболее близкому серверу

Если у компании есть два офиса в разных районах города, то было бы разумно направлять пользователя к серверу, который расположен в его офисе, а не к серверу в другом районе. Это тоже можно сделать с помощью DFS.

\\FILESRV\Programs\Office2003  ->

                                                \\CENTER-SRV\Programs\Office2003

                                                \\WEST-SRV\Programs\Office2003

Теперь пользователи в центральном офисе будут использовать сервер CENTER, a пользователи в западной части города будут обращаться к серверу WEST-SRV. Если же пользователь локальный сервер становится недоступен, то пользователь автоматически переключается на другой сервер. А когда локальный сервер снова работает, dfs клиент снова переключится на более близкий сервер. (Стоит заметить, что авто-переключение на локальный сервер требует конфигурации Windows Server R2 + клиент на XP SP2 с установленным обновлением KB898900. Подробнее об авто переключении на локальный сервер я напишу в одном из следующих постов).

Кроме удобства и более высокой скорости работы с файлами, это позволяет экономить деньги на сетевом трафике.

Я думаю, что достоинства DFS очевидны. Однако в связке с репликацией данных DFS Replication, мы получаем еще более гибкую систему управления файловыми серверами. Мой следующий пост будет посвящен DFS Replication.