Две главные цели.

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

Высокая доступность.
Другая важная цель - обеспечение высокой доступности. Ошибки систем или осуществление операций копирования и сопровождения не должны приводить к недоступности файлов.

Понятие файлового сервиса и файлового сервера .

Файловый сервис - это то, что файловая система предоставляет своим клиентам, т.е. интерфейс с файловой системой.
Файловый сервер - это процесс, который реализует файловый сервис.

Пользователь не должен знать, сколько файловых серверов имеется и где они расположены.

Так, как файловый сервер обычно является обычным пользовательским процессом, то в системе могут быть различные файловые серверы, предоставляющие различный сервис (например, UNIX файл сервис и MS-DOS файл сервис).

5.1 Архитектура распределенных файловых систем

Распределенная система обычно имеет два существенно отличающихся компонента - непосредственно файловый сервис и сервис директорий.

5.1.1 Интерфейс файлового сервера

Для любой файловой системы первый фундаментальный вопрос - что такое файл. Во многих системах, таких как UNIX и MS-DOS, файл - не интерпретируемая последовательность байтов. На многих централизованных ЭВМ (IBM/370) файл представляется последовательность записей, которую можно специфицировать ее номером или содержимым некоторого поля (ключом). Так, как большинство распределенных систем базируются на использовании среды UNIX и MS-DOS, то они используют первый вариант понятия файла.

Файл может иметь атрибуты (информация о файле, не являющаяся его частью). Типичные атрибуты - владелец, размер, дата создания и права доступа.

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

Защита обеспечивается теми же механизмами, что и в однопроцессорных ЭВМ - мандатами и списками прав доступа. Мандат - своего рода билет, выданный пользователю для каждого файла с указанием прав доступа. Список прав доступа задает для каждого файла список пользователей с их правами. Простейшая схема с правами доступа - UNIX схема, в которой различают три типа доступа (чтение, запись, выполнение), и три типа пользователей (владелец, члены его группы, и прочие).

Файловый сервис может базироваться на одной из двух моделей - модели загрузки/разгрузки и модели удаленного доступа . В первом случае файл передается между клиентом (памятью или дисками) и сервером целиком, а во втором файл сервис обеспечивает множество операций (открытие, закрытие, чтение и запись части файла, сдвиг указателя, проверку и изменение атрибутов, и т.п.). Первый подход требует большого объема памяти у клиента, затрат на перемещение ненужных частей файла. При втором подходе файловая система функционирует на сервере, клиент может не иметь дисков и большого объема памяти.

5.1.2 Интерфейс сервера директорий

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

Определяет алфавит и синтаксис имен. Для спецификации типа информации в файле используется часть имени (расширение) либо явный атрибут.

Все распределенные системы позволяют директориям содержать поддиректории - такая файловая система называется иерархической . Некоторые системы позволяют создавать указатели или ссылки на произвольные директории, которые можно помещать в директорию. При этом можно строить не только деревья, но и произвольные графы (разница между ними очень важна для распределенных систем, поскольку в случае графа удаление связи может привести к появлению недостижимых поддеревьев. Обнаруживать такие поддеревья в распределенных системах очень трудно).

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

Прозрачность именования .
Две формы прозрачности именования различают - прозрачность расположения (/server/d1/f1) и прозрачность миграции (когда изменение расположения файла не требует изменения имени).

Имеются три подхода к именованию:


• машина + путь;
• монтирование удаленных файловых систем в локальную иерархию файлов;
• единственное пространство имен, которое выглядит одинаково на всех машинах.

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

Двухуровневое именование .
Большинство систем используют ту или иную форму двухуровневого именования. Файлы (и другие объекты) имеют символические имена для пользователей, но могут также иметь внутренние двоичные имена для использования самой системой. Например, в операции открыть файл пользователь задает символическое имя, а в ответ получает двоичное имя, которое и использует во всех других операциях с данным файлом. Способы формирования двоичных имен различаются в разных системах:

• если имеется несколько не ссылающихся друг на друга серверов (директории не содержат ссылок на объекты других серверов), то двоичное имя может быть то же самое, что и в ОС UNIX;
• имя может указывать на сервер и файл;
• в качестве двоичных имен при просмотре символьных имен возвращаются мандаты, содержащие помимо прав доступа либо физический номер машины с сервером, либо сетевой адрес сервера, а также номер файла.

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

5.1.3 Семантика разделения файлов

UNIX-семантика
Естественная семантика однопроцессорной ЭВМ - если за операцией записи следует чтение, то результат определяется последней из предшествующих операций записи. В распределенной системе такой семантики достичь легко только в том случае, когда имеется один файл-сервер, а клиенты не имеют кэшей. При наличии кэшей семантика нарушается. Надо либо сразу все изменения в кэшах отражать в файлах, либо менять семантику разделения файлов.

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

Транзакции
Процесс выдает операцию НАЧАЛО ТРАНЗАКЦИИ, сообщая тем самым, что последующие операции должны выполняться без вмешательства других процессов. Затем выдает последовательность чтений и записей, заканчивающуюся операцией КОНЕЦ ТРАНЗАКЦИИ. Если несколько транзакций стартуют в одно и то же время, то система гарантирует, что результат будет таким, каким бы он был в случае последовательного выполнения транзакций (в неопределенном порядке). Пример - банковские операции.

5.2 Реализация распределенных файловых систем

Выше были рассмотрены аспекты распределенных файловых систем, которые видны пользователю. Ниже рассматриваются реализационные аспекты.

5.2.1 Использование файлов

Приступая к реализации очень важно понимать, как система будет использоваться. Приведем результаты некоторых исследований использования файлов (статических и динамических) в университетах. Очень важно оценивать представительность исследуемых данных.

• большинство файлов имеют размер менее 10К (следует перекачивать целиком).
• чтение встречается гораздо чаще записи (кэширование).
• чтение и запись последовательны, произвольный доступ редок (упреждающее кэширование, чтение с запасом, выталкивание после записи следует группировать).
• большинство файлов имеют короткое время жизни (создавать файл в клиенте и держать его там до уничтожения).
• мало файлов разделяются (кэширование в клиенте и семантика сессий).
• существуют различные классы файлов с разными свойствами (следует иметь в системе разные механизмы для разных классов).

5.2.2 Структура системы

Есть ли разница между клиентами и серверами ? Имеются системы, где все машины имеют одно и то же ПО и любая машина может предоставлять файловый сервис. Есть системы, в которых серверы являются обычными пользовательскими процессами и могут быть сконфигурированы для работы на одной машине с клиентами или на разных. Есть системы, в которых клиенты и серверы являются фундаментально разными машинами с точки зрения аппаратуры или ПО (требуют различных ОС, например).

Второй вопрос - должны ли быть файловый сервер и сервер директорий отдельными серверами или быть объединенными в один сервер. Разделение позволяет иметь разные серверы директорий (UNIX, MS-DOS) и один файловый сервер. Объединение позволяет сократить коммуникационные издержки.

В случае разделения серверов и при наличии разных серверов директорий для различных поддеревьев возникает следующая проблема. Если первый вызванный сервер будет поочередно обращаться ко всем следующим, то возникают большие коммуникационные расходы. Если же первый сервер передает остаток имени второму, а тот третьему, и т.д., то это не позволяет использовать RPC.

Возможный выход - использование кэша подсказок. Однако в этом случае при получении от сервера директорий устаревшего двоичного имени клиент должен быть готов получить отказ от файлового сервера и повторно обращаться к серверу директорий (клиент может не быть конечным пользователем!).

Последний важный вопрос - должны ли серверы хранить информацию о клиентах.

Серверы с состоянием . Достоинства.

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

Серверы без состояния . Достоинства.

• устойчивость к ошибкам.
• не требуется операций ОТКРЫТЬ/ЗАКРЫТЬ.
• не требуется память для таблиц.
• нет ограничений на число открытых файлов.
• нет проблем при крахе клиента.

5.2.3 Кэширование

В системе клиент-сервер с памятью и дисками есть четыре потенциальных места для хранения файлов или их частей.

Во-первых, хранение файлов на дисках сервера. Нет проблемы когерентности, так как одна копия файла существует. Главная проблема - эффективность, поскольку для обмена с файлом требуется передача информации в обе стороны и обмен с диском.

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

Коммуникационные издержки остаются.

Избавиться от коммуникаций позволяет кэширование в машине клиента.

Кэширование на диске клиента может не дать преимуществ перед кэшированием в памяти сервера, а сложность повышается значительно.

Поэтому рассмотрим подробнее организацию кэширования в памяти клиента.

• кэширование в каждом процессе. (Хорошо, если c файлом активно работает один процесс - многократно открывает и закрывает файл, читает и пишет, например в случае процесса базы данных).
• кэширование в ядре. (Накладные расходы на обращение к ядру).
• кэш-менеджер в виде отдельного процесса. (Ядро освобождается от функций файловой системы, но на пользовательском уровне трудно эффективно использовать память, особенно в случае виртуальной памяти. Возможна фиксация страниц, чтобы избежать обменов с диском).

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

Когерентность кэшей.

Алгоритм со сквозной записью .
Необходимость проверки, не устарела ли информация в кэше. Запись вызывает коммуникационные расходы (MS-DOS).

Алгоритм с отложенной записью .
Через регулярные промежутки времени все модифицированные блоки пишутся в файл. Эффективность выше, но семантика непонятная пользователю (UNIX).

Алгоритм записи в файл при закрытии файла .
Реализует семантику сессий. Не намного хуже случая, когда два процесса на одной ЭВМ открывают файл, читают его, модифицируют в своей памяти и пишут назад в файл.

Алгоритм централизованного управления .
Можно выдержать семантику UNIX, но не эффективно, ненадежно, и плохо масштабируется.

5.2.4 Размножение

Система может предоставлять такой сервис, как поддержание для указанных файлов нескольких копий на различных серверах. Главные цели:

1. Повысить надежность.
2. Повысить доступность (крах одного сервера не вызывает недоступность размноженных файлов.
3. Распределить нагрузку на несколько серверов.
4. Явное размножение (непрозрачно). В ответ на открытие файла пользователю выдаются несколько двоичных имен, которые он должен использовать для явного дублирования операций с файлами.
5. Ленивое размножение. Одна копия создается на одном сервере, а затем он сам автоматически создает (в свободное время) дополнительные копии и обеспечивает их поддержание.
6. Симметричное размножение. Все операции одновременно вызываются в нескольких серверах и одновременно выполняются.

Протоколы коррекции.
Просто посылка сообщений с операцией коррекции каждой копии является не очень хорошим решением, поскольку в случае аварий некоторые копии могут остаться не скорректированными. Имеются два алгоритма, которые решают эту проблему.

1. Метод размножения главной копии. Один сервер объявляется главным, а остальные - подчиненными. Все изменения файла посылаются главному серверу. Он сначала корректирует свою локальную копию, а затем рассылает подчиненным серверам указания о коррекции. Чтение файла может выполнять любой сервер. Для защиты от краха главного сервера до завершения всех коррекций, до выполнения коррекции главной копии главный сервер запоминает в стабильной памяти задание на коррекцию. Слабость - выход из строя главного сервера не позволяет выполнять коррекции.
2. Метод голосования. Идея - запрашивать чтение и запись файла у многих серверов (запись - у всех!). Запрос может получить одобрение у половины серверов плюс один. При этом должно быть согласие относительно номера текущей версии файла. Этот номер увеличивается на единицу с каждой коррекцией файла. Можно использовать различные значения для кворума чтения (Nr) и кворума записи (Nw). При этом должно выполняться соотношение Nr+Nw>N. Поскольку чтение является более частой операцией, то естественно взять Nr=1. Однако в этом случае для кворума записи потребуются все серверы.

5.2.5 Пример: Sun Microsystems Network File System (NFS)

Изначально реализована Sun Microsystem в 1985 году для использования на своих рабочих станций на базе UNIX. В настоящее время поддерживается также другими фирмами для UNIX и других ОС (включая MS-DOS). Интересны следующие аспекты NFS - архитектура, протоколы и реализация. Архитектура NFS. Позволяет иметь произвольное множество клиентов и серверов на произвольных ЭВМ локальной или широкомасштабной сети.

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

Клиент получает доступ к экспортированным директориям путем их монтирования. Если клиент не имеет дисков, то может монтировать директории в свою корневую директорию.

Если несколько клиентов одновременно смонтировали одну и ту же директорию, то они могут разделять файлы в общей директории без каких либо дополнительных усилий. Простота - достоинство NFS. Протоколы NFS. Поскольку одна из целей NFS - поддержка гетерогенных систем, клиенты и серверы могут работать на разных ЭВМ с различной архитектурой и различными ОС. Поэтому необходимо иметь строгие протоколы их взаимодействия. NFS имеет два таких протокола.
Первый протокол поддерживает монтирование . Клиент может послать серверу составное имя директории (имя пути) и попросить разрешения на ее монтирование. Куда будет монтировать директорию клиент для сервера значения не имеет и поэтому не сообщается ему. Если путь задан корректно и директория определена как экпортируемая, то сервер возвращает клиенту дескриптор директории. Дескриптор содержит поля, уникально идентифицирующие тип ЭВМ, диск, номер i-вершины (понятие ОС UNIX) для данной директории, а также информацию о правах доступа к ней. Этот дескриптор используется клиентом в последующих операциях с директорией.

Многие клиенты монтируют требуемые удаленные директории автоматически при запуске (используя командную процедуру shell-интерпретатора ОС UNIX).

Версия ОС UNIX, разработанная Sun (Solaris), имеет свой специальный режим автоматического монтирования. С каждой локальной директорией можно связать множество удаленных директорий. Когда открывается файл, отсутствующий в локальной директории, ОС посылает запросы всем серверам (владеющим указанными директориями). Кто ответит первым, директория того и будет смонтирована. Такой подход обеспечивает и надежность, и эффективность (кто свободнее, тот раньше и ответит). При этом подразумевается, что все альтернативные директории идентичны. Поскольку NFS не поддерживает размножение файлов или директорий, то такой режим автоматического монтирования в основном используется для директорий с кодами программ или других редко изменяемых файлов.

Второй протокол - для доступа к директориям и файлам. Клиенты посылают сообщения, чтобы манипулировать директориями, читать и писать файлы. Можно получить атрибуты файла. Поддерживается большинство системных вызовов ОС UNIX, исключая OPEN и CLOSE. Для получения дескриптора файла по его символическому имени используется операция LOOKUP, отличающаяся от открытия файла тем, что никаких внутренних таблиц не создается. Таким образом, серверы в NFS не имеют состояния (stateless). Поэтому для захвата файла используется специальный механизм.

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

Все ключи, используемые для контроля доступа, поддерживаются специальным сервисом (и серверами) - сетевым информационным сервисом (NIS). Храня пары (ключ, значение), сервис обеспечивает выдачу значения кода при правильном подтверждении ключей. Кроме того, он обеспечивает отображение имен машин на их сетевые адреса, и другие отображения. NIS-серверы используют схему главный -подчиненные для реализации размножения (ленивое размножение). Реализация NFS (XDR - External Data Represantation)

Задача уровня виртуальной файловой системы - поддерживать для каждого открытого файла строку в таблице (v-вершину), аналогичную i-вершине UNIX. Эта строка позволяет различать локальные файлы от удаленных. Для удаленных файлов вся необходимая информация хранится в специальной r-вершине в NFS-клиенте, на которую ссылается v-вершина. У сервера нет никаких таблиц.

Передачи информации между клиентом и сервером NFS производятся блоками размером 8К (для эффективности).

Два кэша - кэш данных и кэш атрибутов файлов (обращения к ним очень часты, разработчики NFS исходили из оценки 90%). Реализована семантика отложенной записи - предмет критики NFS.

Имеется также кэш подсказок для ускорения получения v-вершины по символическому имени. При использовании устаревшей подсказки NFS-клиент будет обращаться к NFS-серверу и корректировать свой кэш (пользователь об этом ничего не должен знать).

Лаборатория Параллельных Информационных Технологий, НИВЦ МГУ

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

Назначение и возможности DFS

Распределенная файловая система DFS (Distributed File System ) появилась как
стандартный компонент еще в Win2k. Ее задача — облегчить управление, доступ и
поиск данных в сети. Для этого файловые ресурсы, находящиеся на разных
компьютерах, объединяются в единое логическое пространство имен. Пользователь,
вместо того чтобы запоминать имена всех общих сетевых ресурсов (Universal Naming
Convention, UNC), вроде \\Server\Folder, будет обращаться к единому пространству
UNC-имен, в котором объединены все серверы и общие ресурсы сети. А на каком
конкретно компьютере находится запрашиваемый файл, уже забота DFS , пользователю
не нужно беспокоиться о реальном расположении файла. При обращении клиента он
просто перебрасывается на нужный ему каталог. На месте источника, на который
указывает ссылка, может быть любая операционная система, к ресурсам которой
можно обратиться, используя UNC (Windows, Linux, xBSD, NetWare). Физические
объекты, связанные ссылками с DFS , называются целевыми объектами (targets) или
репликами (replics).

Но удобство для пользователей и администраторов — далеко не самое важное из
основных преимуществ DFS . Дело в том, что с одним логическим именем может быть
связано несколько общих ресурсов, в которых хранится идентичная информация.
Такой набор альтернативных общих ресурсов, связанных с одним логическим именем
DFS , называется набором реплик. И если общие ресурсы находятся в одном
пространстве доменного корня DFS и располагаются на серверах Win2k или Win2k3,
есть возможность настроить автоматическую синхронизацию информации между ними.
Пользователь, обратившийся к DFS , обычно перенаправляется к ближайшей реплике, и
если она не доступна, он будет перенаправлен к альтернативному ресурсу. Для
уменьшения нагрузки на сервер DFS на стороне клиента данные кэшируются, поэтому
при частом обращении к одному и тому же ресурсу каждый запрос к DFS не
производится. Таким образом, автоматическое резервирование важной информации ,
реализованное в DFS , еще и повышает отказоустойчивость всей системы (выход
одного сервера или дискового устройства не повлияет на работу пользователей).
Хотя следует помнить, что DFS не создавалась для работы часто с обновляющимися
данными, и особенно для тех случаев, когда файл одновременно может обновляться в
нескольких местах (в DFS остается та версия файла, где были внесены последние
изменения).

В реализации DFS в Win2k можно было разместить только одно пространство имен,
в Win2k3 их может быть уже несколько. В Win2k3 R2 появилась новая версия этой
системы — DFS Namespaces , в которой многие вопросы уже решены. За репликацию
данных в Win2k3 SP1 и SP2 отвечает FRS (File Replication Server ), в Win2k3 R2 —
DFS Replicatio n. Главным их отличием является то, что в FRS самым маленьким
объектом, подлежащим репликации, является файл, в DFS Replication используется
более развитая технология RDC (Remote Differential Compression ), которая умеет
копировать только изменившиеся части файла, а функция cross-file RDC меньше
нагружает канал при копировании новых файлов. Таким образом, использование DFS
еще и уменьшает нагрузку на сеть, что особенно актуально для удаленных офисов с
недостаточной пропускной способностью. В службе DFS не используется никаких
дополнительных средств обеспечения безопасности. При обращении к targets
проверяются только права доступа файловой системы и установленные для этих
объектов разрешения в каталоге Active Directory.

Эти разные корни

Начальной точкой для всех имен дерева DFS служит корень распределенной
файловой системы. Фактически корень — это некоторый общий ресурс, находящийся на
сервере, все остальные логические имена системы DFS будут подключаться как
следующий иерархический уровень. Корни в DFS могут быть двух видов, каждый
отличается способами хранения данных и возможностями. Изолированный (автономный)
корень (Standalone DFS ) не связан с Active Directory, и все ссылки на сетевые
ресурсы хранятся в реестре самого сервера DFS . Такой корень не использует
DFS
Replication , то есть не предполагает дублирование информации на другие ресурсы,
и поэтому не обеспечивает отказоустойчивость. При выходе из строя сервера DFS
вся иерархия становится не доступной, хотя пользователи могут обращаться к
ресурсам напрямую. К слову, несколько Standalone DFS серверов способны работать
в кластере, поэтому эта проблема может быть решена. Если сервер DFS является
членом домена, используется доменный корень (Domain-based DFS ). При таком
варианте можно подключать несколько реплик и использовать DFS Replication для
репликации как самого корня, так и ссылок DFS . Если в Domain-based DFS корни
находятся на компьютерах под управлением Win2k и Win2k3, то такой корень
называется "Mixed mode domain DFS ".

При доменном DFS вся информация о пространстве имен находится на контроллере
домена, к которому периодически обращается сервер DFS . Учитывая синхронизацию
между DFS в домене, которая становится все более сложной при каждом изменении
структуры, эти запросы могут быть узким местом в системе, поэтому в этом случае
также есть некоторые ограничения. Так в Win2k существовало ограничение на 16
корней для одного пространства имен. В Win2k3 это ограничение снято, так как
сервер DFS теперь может обращаться к любому DC, а не только к эмулятору PDC.
Второе ограничение доменных корней связано с тем, что вся структура хранится в
специальном объекте, который также необходимо дублировать на всех DC при любом
малейшем изменении в структуре DFS . В документации рекомендуется ограничивать
максимальный размер объекта 5-тью Мб, что приблизительно соответствует 5000
ссылкам (каталогам). Эта величина зависит от многих параметров, длины имени
ссылок, наличия и размера комментариев, которые также хранятся в этом объекте.
Но в среднем DFS редко когда превышает 50-100 ссылок, и после первоначальной
настройки она остается в основном статичной, а значит, часто дублироваться не
будет, и этих ограничений достигнуть просто не удастся. Кстати, в будущей
Windows 2008 ограничение в 5000 ссылок уже снято, но для этого все серверы
должны работать под управлением Longhorn. Для Standalone DFS рекомендованный
лимит ссылок на порядок выше и составляет 50000 ссылок .

Настройка DFS

Для примера настроим DFS на компьютере под управлением Win2k3 с SP2, все
настройки в SP1 аналогичны. В настройках DFS в R2 и Win2k есть некоторые
отличия, но не настолько глобальные, чтобы не разобраться самостоятельно. Все
управление распределенной файловой системой выполняется централизованно с
помощью оснастки MMC "Распределенная файловая система DFS ", которую можно
вызвать во вкладке "Администрирование" Панели управления Windows. С ее помощью
можно создавать и удалять корни, подключаться к любым корням DFS . Удобно, что в
одной вкладке может отображаться несколько корней DFS . В случае работы корня в "Mixed
mode domain DFS ", то есть когда реплики и корни DFS располагаются на компьютерах
под управлением разных версий Windows, управление DFS необходимо производить с
компьютера, работающего под Win2k3. Как вариант, можно установить пакет Win2k3 Administration Tools Pack (adminpak.msi), который лежит в свободном доступе на
сайте корпорации. В этом случае для управления можно использовать и компьютеры с
WinXP. Информацию по этому пакету найдешь по адресу

support.microsoft.com/kb/304718 . Кроме этого, для работы с DFS также можно
использовать утилиты командной строки dfscmd.exe и dfsutil.exe. Последняя имеет
больше возможностей, но по умолчанию не включена в состав операционной системы,
чтобы ее использовать, необходимо установить пакет Win2k3 Support Tools. Обрати
внимание, что для успешной установки Support Tools требуется скачать два файла:
suptools.msi и support.cab.

Для создания нового корня вызываем оснастку, щелкаем мышкой по заголовку и в
контекстном меню выбираем "Создать корень" (New Root), как вариант, можно
выбрать аналогичный пункт в меню "Действие". Появляется Мастер создания нового
корня (New Root Wizard), следуем его подсказкам. На втором шаге выбираем тип
создаваемого корня (доменный или изолированный), указываем несущий домен и
сервер. После проверки соединения с выбранным сервером вводим имя корня. Обрати
внимание, как будет выглядеть UNC путь к новому корню, по умолчанию \\server\nameshare.
Так как на данный момент общего каталога не существует, на следующем шаге нужно
выбрать локальный каталог, который будет использоваться в качестве общего. Этот
каталог не содержит реальных данных, в нем будут находиться ссылки, указывающие
на физическое расположение данных. Мастер создает ресурсы, разрешающие чтение и
выполнение членам группы Пользователи. При необходимости следует скорректировать
разрешения. Теперь нажимаем кнопку Готово, новый корень появится в окне консоли.
Если сервер работает под управлением Win2k3, аналогичным образом создаем и
другие корни. С помощью команды Проверить статус (Check Status), вызываемую из
меню консоли или контекстного меню, можно проверить состояние реплики. Состояние
будет указано в одноименном столбце и рядом с именем появится кружок с отметкой.
Если она зеленого цвета, значит, все нормально. Для проверки можно зайти по
указанному UNC или использовать на локальном компьютере команду «net share» или
«net view computer_name» с удаленного. Команда «dfsutil /Root:\\server\share /View»
покажет информацию о DFS .

>dfsutil /Root:\\server.com\first /View
DFS Utility Version 5.2 (built on 5.2.3790.3959)
Domain Root with 0 Links
Root Name="\\SERVER\first" Comment="first Root" State="1" Timeout="300"
Target Server="GRINDERS" Folder="first" State="2"

После создания корня его можно опубликовать в Active Directory. Для этого в
контекстном меню выбираем Свойства, переходим на вкладку Публикация и
устанавливаем флажок "Опубликовать этот корень в Active Directory". Доменные
корни публикуются автоматически и в обязательном порядке.

Создание ссылок

После создания корня можно начинать подключать общие ресурсы. Для чего в том
же контекстном меню выбираем пункт Создать ссылку (New Link). В появившемся окне
"Новая ссылка", в поле "Имя ссылки", вводим имя ссылки, под которым она будет
доступна в DFS, затем чуть ниже UNC-путь к целевому каталогу (должен уже
существовать). Для поиска общих ресурсов можно использовать кнопку Обзор, чуть
ниже можно изменить время кэширования этой ссылки для клиентов DFS (по умолчанию
1800 сек). По окончании нажимаем кнопку ОК. Команда «dfsutil /view» должна
показать состояние всех подключенных ссылок и их свойства. Если в сети работает
несколько серверов, есть возможность добавить реплику, указывающую на
альтернативную ссылку. Реплика на корень или отдельный объект создается
аналогично, только в первом случае в контекстном меню выбираем пункт "Создать
корневую целевую папку", а во втором – "Создать папку".

Общие ресурсы, с которыми будет производиться репликация, должны
располагаться в разделах с файловой системой NTFS на компьютерах, работающих под
управлением серверных версий Windows от 2000 (лучше 2003). В поле "Путь к
целевой общей папке" появившегося окна вводим или при помощи кнопки Обзор
указываем общий ресурс, располагающийся на другом компьютере. В том случае если
для синхронизации информации между этими ресурсами планируется использовать
альтернативные программы (или синхронизация будет производиться вручную),
следует снять флажок "Добавить эту целевую папку к набору репликации" (Add this
target to the replication set). Нажимаем ОК, и появляется Мастер настройки
репликации (Configure Replication Wizard), который поможет выбрать
мастер-реплику и топологию репликации. На первом шаге указываем каталог, который
будет использоваться в качестве основного целевого, вся информация из этого
каталога затем будет скопирована в другую папку. Последняя должна быть пустой,
если в ней есть файлы, они будут скопированы во временный каталог, а затем
удалены. Если общий ресурс по каким-либо причинам не подходит для репликации
(например, расположен не в разделе с NTFS), он будет отмечен красным крестиком,
при попытке перейти к следующему шагу мастер предложит указать другую ссылку или
закончить работу.

Нажатием кнопки "Промежуточное хранение " (Staging Folder ) можно изменить
расположение каталога, который будет использоваться для временного хранения
реплицируемых данных. По умолчанию этот каталог размещается в разделе, отличном
от того, на котором находится общий ресурс, связанный с DFS . Далее мастер
предложит выбрать топологию репликации. Необходимо будет указать один из
следующих вариантов:

• Кольцо (Ring) - все реплики обмениваются информацией с двумя соседними;
• Звезда (Hub and spoke) - указывается основная ссылка, с которой и будут
  обмениваться информацией все остальные реплики;
• Полная сетка (Mesh) - все реплики обмениваются друг с другом;
• Особая (Custom) - позднее администратор самостоятельно настроит репликацию
  для каждой пары серверов.

Кольцевая топология установлена по умолчанию и подходит для большинства
случаев. В идеале выбранная топология репликации должна соответствовать схеме
сети. Например, если есть центральный офис, где располагаются основные ресурсы,
а многочисленные филиалы подключаются к ним по мере необходимости, то в этом
случае больше подойдет схема Звезда. Если ничего из предустановок не подходит,
следует обратиться к пункту Особая.

После создания реплики для ссылки соответствующий ей значок в окне оснастки
изменится. В контекстном меню также появятся два новых пункта: Отобразить/Скрыть
статус репликации и Остановить репликацию. В поле статуса репликации может быть
один из трех результатов. Если процесс репликации завершен нормально, на значках
будут зеленые флажки. Красный крестик на значке реплики укажет, что она в данный
момент недоступна, в поле Состояние подпись изменится на Автономный. Если в
проверяемой ссылке недоступны лишь некоторые реплики, в значке появится желтый
восклицательный знак.

Перед удалением одной из альтернативных реплик сначала следует запретить
репликацию. При возобновлении репликации тебя встретит тот же мастер. Если
сервер является контроллером домена, вместе со всеми данными DFS будет
реплицировать и содержимое тома SYSVOL. Поэтому следует помнить, что до тех пор,
пока не произойдет полная репликация всех реплик, начинать любые изменения в
конфигурации DFS очень рискованно, это может нарушить работоспособность всего
домена.

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

Для принудительной репликации информации, хранящейся на определенном сервере,
можно воспользоваться утилитой NtfrsUtl.exe, которая входит в состав пакета
Support Tools . Команда проста: «ntfrsutl poll /now server.com». Чтобы увидеть
установленные временные интервалы, через которые производится репликация,
следует ввести «ntfrsutl poll». Все установки доступны по команде «ntfrsutl sets
server.com».

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

Администратору для контроля следует почаще заглядывать в журнал
"Администрирование – Просмотр событий – Служба репликации файлов", где можно
найти информацию обо всех событиях, происходящих со службой FRS.

NFS - это самый известный механизм совместного доступа к файлам для Linux и других Unix-систем, потому что он присутствует во многих Unix-подобных системах и очень прост в настройке. NFS поддерживается ядром Linux, и утилиты, связанные с NFS, присутствуют в каждом дистрибутиве. Но в мире Linux существуют и более современные механизмы для совместного использования файлов и каталогов. Каждый из них имеет определенные преимущества в настройке или в использовании.

Распределенная файловая система OpenAFS - это Open Source-аналог известной коммерческой распределенной файловой системы AFS. Поддержка для распределенных файловых систем InterMezzo и Coda уже присутствует в новых ядрах Linux из серии 2.4. Новые механизмы совместного использования файлов, основанные на Web (например, WebDAV), тоже могут использоваться в качестве файловых систем.

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

Введение в распределенные файловые системы.

Сейчас сетевые файловые системы называют «распределенными». Этот термин отражает тот факт, что многие из этих файловых систем имеют гораздо больше возможностей, чем простая передача данных по сети. Носители данных, связанные с этими файловыми системами, не обязательно могут быть расположены на одном компьютере - они могут быть распределены между многими компьютерами.

Распределенные файловые системы OpenAFS и Coda имеют собственные механизмы управления разделами, которые упрощают возможности хранения общедоступной информации. Они так же поддерживают дублирование - способность делать копии разделов и сохранять их на других файловых серверах. Если один файловый сервер становится недоступным, то все равно к данным, хранящимся на его разделах, можно получить доступ с помощью имеющихся резервных копий этих разделов.

Самое главное различие между подходом Windows / MacOS (совместное использование каталогов и дисков) и подходом Linux, MacOS X и других Unix-подобных многопользовательских операционных систем - в том, как эти операционные системы используют и организовывают разделы. Windows / MacOS экспортируют разделы как отдельные каталоги или диски, и удаленные системы, которые хотят обратиться к общедоступным устройствам, должны обязательно подключить их к себе.

Когда самый высокий уровень организации в файловой системе - это раздел диска (например, как в файловых системах Windows), рабочие станции клиентов для получения доступа к этим данным должны обязательно подключиться к разделу и назначить ему отдельную букву в своей локальной раскладке (например, диск E, F, G, и т.д). Буквы могут быть назначены сетевым разделам в пользовательских и групповых профилях Windows (для стандартизации). Но, к сожалению, не на всех компьютерах расположение букв может быть одинаковым. Например, на компьютере с большим количеством жестких дисков и разделов нужные буквы могут быть заняты, и поэтому придется давать сетевым разделам другие обозначения.

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

Современные распределенные файловые системы типа OpenAFS или Coda включают в себя специальные сервисы для управления разделами. Это позволяет вам смонтировать разделы различных файловых серверов в центральную иерархию директорий, поддерживаемую файловыми системами. OpenAFS использует центральный каталог, называемый «/afs», а Coda использует «/coda». Эти иерархии директорий доступны всем клиентам распределенной файловой системы, и выглядят одинаково на любой из клиентских рабочих станций. Это дает возможность пользователям работать со своими файлами одинаково на любом компьютере. Если ваш настольный компьютер не работает, вы совершенно спокойно можете использовать любой другой - все ваши файлы находятся в безопасности на сервере.

Распределенные файловые системы, предоставляющие одни и те же данные многим различным компьютерным системам, дают пользователям возможность использовать любую операционную систему, лучше всего подходящую для их задач. Пользователи Macintosh могут пользоваться всеми преимуществами графических инструментальных средств, доступных в Mac OS, и одновременно хранить свои данные на централизованных файловых серверах. Пользователи Windows так же могут иметь доступ к устойчивой глобальной файловой системе. Распределенные файловые системы особенно привлекательны при попытке координации работы между группами, расположенными в различных городах, государствах, или даже в разных странах. Преимущество - общие данные всегда доступны по сети, независимо от вашего местонахождения.

Проблемы администрации распределенных файловых систем.

Использование распределенных файловых систем дает системным администраторам не только новые возможности, но и новые проблемы. Но распределенные системы способны упростить многие из стандартных административных задач. В сетевой среде пользователи должны иметь возможность зайти в сеть под своим именем с любого компьютера. Это значит, что механизм входа в сеть (или аутентификации) тоже должен быть сетевым. Поэтому в среде распределенной файловой системы файлы групп и паролей, расположенные на индивидуальных компьютерах, вторичны по отношению к сетевым механизмам аутентификации (таким, как Kerberos или NIS, которые предоставляют пользователям возможность работать на любом компьютере). Но стандартные локальные механизмы проверки пароля все же должны существовать, чтобы администраторы могли выполнять на локальных компьютерах необходимые задачи.

Сохранение общих данных на централизованных файловых серверах (а не на индивидуальных компьютерах) упрощает такие административные задачи, как резервирование и восстановление файлов и каталогов. Это так же централизует такие стандартные административные задачи, как контроль за использованием файловой системы, и представляет новые возможности управления хранением данных - например, балансирование загрузки. Распределенные файловые системы типа OpenAFS и Coda обеспечивают встроенные логические системы управления разделами, которые дают администраторам возможность переместить интенсивно используемые данные на более мощные или менее используемые компьютеры. Если распределенная файловая система поддерживает дублирование, копии интенсивно используемых данных могут распределяться между многими файловыми серверами. Это может уменьшить нагрузку на сеть, и облегчить работу серверов. Распределенные файловые системы используют логические разделы вместо физических дисковых разделов, и это позволяет легко добавить в сеть новую свободную память прямо во время работы. (Для добавления нового диска в локальный компьютер пришлось бы потратить некоторое время).

Использование распределенных файловых систем так же облегчает возможность совместного доступа к программному и аппаратному обеспечению. Но перед этим нужно удостовериться, что лицензии к используемым программам разрешают установку программного обеспечения в распределенной файловой системе. Сервера печати - одна из первоначальных причин появления среды «клиент-сервер». Распределенные файловые системы так же упрощают совместный доступ к специализированным аппаратным средствам, соединяясь по сети с компьютером, на котором установлены нужные аппаратные средства, и при этом все еще имея доступ к вашим данным.

Использование централизованной распределенной файловой системы может обеспечивать существенные преимущества в стоимости и быстродействии выполнения работы для клиентских систем. Распределенные файловые системы существенно уменьшают аппаратные затраты, минимизируя количество памяти на любом десктопе или ноутбуке. Использование распределенной файловой системы в качестве архива для пользовательских данных обычно означает более быструю загрузку клиентских машин, потому что большое количество данных больше не хранится локально и поэтому не нуждается в проверке после перезапуска клиента. Комбинация распределенной файловой системы и использования журналируемых файловых систем на клиентских компьютерах может дать значительное увеличение скорости запуска системы.

Поддержка автономной работы с данными.

Использование распределенной файловой системы увеличивает зависимость компьютерных систем от сети. Эта зависимость от данных, к которым люди могут обращаться только по сети, вызывает некоторые интересные проблемы для пользователей лаптопов/мобильных компьютеров, которые нуждаются в доступе к своим данным даже тогда, когда доступ к сети невозможен. Это называется «автономная работа» - система должна функционировать, если ресурсы, которые обычно присутствуют в сети (например, пользовательские данные), по каким-то причинам не доступны. Даже Windows обеспечивает графический интерфейс для возможности маркировки файлов, с которыми вы хотите работать, когда вы отключены от сети, и для синхронизации этих файлов, когда вы соединяетесь повторно.

Распределенные файловые системы Coda и InterMezzo, которые являются в настоящее время доступными для Linux, тоже обеспечивают интегрированную поддержку для автономной работы. Так же сейчас ведется работа над обеспечением этой возможности для файловых систем NFS. Coda и InterMezzo уже поддерживаются ядром Linux - поддержка Intermezzo встроена в ядро, начиная с версии 2.4.5, а Coda вообще была интегрирована в ядро 2.4 с самого начала.

Coda - распределенная файловая система с происхождением из OpenAFS, которая разрабатывается в университете Carnegie Mellon с 1987 года. InterMezzo - относительно новая распределенная файловая система, упор в разработке которой сделан на высокой доступности, гибком дублировании каталогов, поддержке автономных операций, и постоянном кэшировании. Создатели InterMezzo были вдохновлены CMU Coda, но этот проект не основан на исходном тексте Coda. Начальный создатель InterMezzo, Питер Браам, был главой проекта Coda в CMU в течение нескольких лет, и после этого он сам начал разрабатывать InterMezzo и несколько других проектов.

Расширение файловых систем с помощью Web.

До создания распределенных файловых систем совместное использование файлов через сеть ограничивалось простыми передачами файлов с помощью использования протокола передачи файлов - FTP (File Transfer Protocol). Появление Всемирной паутины в значительной степени упростила процесс работы с FTP - теперь не нужно знать команды, потому что протокол FTP интегрирован в большинство броузеров. Способность легко передавать файлы через Web также вела к расширению Паутины и существенному улучшению основного протокола передачи гипертекста - HTTP (HyperText Transfer Protocol), который сейчас является основанием для многих систем распределенного использования файлов.

Самая известная из них - это WebDAV, которая расшифровывается как «Web-система распределенной авторизации и контроля версий» (Web-enabled Distributed Authoring and Versioning). WebDAV - это набор расширений к протоколу HTTP, обеспечивающий совместную среду для пользователей, которая позволяет им скачивать, упорядочивать и редактировать файлы, хранящиеся на Web-серверах.

Поддержка WebDAV встроена во многие популярные Web-серверы, например - Apache, где это основывается на опознавательных механизмах сервера. (От простых файлов.htaccess до интегрированных NIS, LDAP, или даже механизма аутентификации Windows). Использование WebDAV для доступа и модификации файлов через Web встроено в операционные системы Mac OS X, в новые версии Microsoft Internet Explorer, а так же доступно и в Linux при использовании таких приложений, как менеджер файлов Nautilus. Хотя это и не файловая система в традиционном смысле, но вы можете даже смонтировать WebDAV в Линуксе, используя загружаемый модуль ядра под названием davfs.

WebDAV обеспечивает такие стандартные для распределенных систем возможности, как блокировка файлов, создание, переименование, копирование, удаление файлов, а так же поддерживает такие продвинутые возможности, как meta-данные файла (более подробная информация о файле - заголовок, тема, создатель, и т.д). В ближайшем будущем WebDAV будет включать интегрированную поддержку управления версиями, которая упростит работу многих пользователей над общими файлами, отслеживая изменения, авторов этих изменений, и другие аспекты общего использования документа. Эти возможности контроля над версиями обеспечиваются в соответствии с протоколом DeltaV, который активно разрабатывается Рабочей группой DeltaV - подразделением Проектировочной группы Интернета (IETF - Internet Engineering Task Force). Некоторые проекты, например, Subversion (WebDAV и DeltaV-основанная замена стандарту CVS), уже доступны в альфа-версии. Subversion обеспечивает систему контроля над версиями и сохранение архива файла на основе базы данных, имеющей API языка C, и моделирует версионную файловую систему, легко доступную через Web.

Вывод.

Многие IT-специалисты, ответственные за вычислительные системы предприятий, уже используют сетевые файловые системы (NFS), или адаптеры файловых систем (Samba, Netatalk, или Novell) для объединения своих сетей. Более новые и более функциональные распределенные файловые системы - такие, как OpenAFS, Coda, InterMezzo и WebDAV - могут стать альтернативой, потому что они имеют более высокое быстродействие, улучшенную защиту, и дополнительные возможности управления разделами и создания резервных копий.

Как мы увидим в дальнейших статьях из этой серии, современные распределенные файловые системы могут быть легко интегрированы в существующую сеть. Распределенные файловые системы могут обеспечить дополнительную гибкость сети, ускорить и упростить процесс совместной работы над файлами, уменьшить затраты и упростить жизнь администраторам. Современные распределенные файловые системы дают новую жизнь слогану Sun Microsystems «The Network is the computer», расширяя файловую систему по компьютерной сети.

Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Управление дисками и файловыми ресурсами. [Занятие 12]
Развертывание и администрирование сети с выделенным сервером на базе Windows Server 2003
vsit, Wednesday 25 October 2006 - 09:54:06

Занятие 12. Управление дисками и файловыми ресурсами.

Все вопросы связанные с администрированием дисковых и файловых ресурсов были подробно рассмотрены в разделе, посвященном Windows XP Professional (Курс "Системный администратор компьютерной сети" ). Управление этими ресурсами в семействе Windows Server 2003 осуществляется аналогично и в данном разделе рассматриваться не будет.

В этом разделе мы рассмотрим дополнительные возможности файловой системы, применяемые на серверах, и реализованные в операционной системе Windows Server 2003, предназначенные для работы с устройствами хранения информации. К таковым относятся: распределенная файловая система (Distributed file system, DFS), теневые копии дисков (Shadow Copies), технологии сжатия файлов.

С помощью Распределенной файловой системы (DFS) системный администратор может упростить для пользователей доступ к файлам, физически распределенным по сети, и управление ими. Система DFS дает возможность предоставить пользователям файлы, находящиеся на разных серверах, так как если бы они находились в едином месте. Для доступа к таким файлам пользователям не потребуется указывать их действительное физическое положение.

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

Основания для использования DFS

• Предполагается добавление файловых серверов или изменение расположения файлов.
• Пользователи обращаются к целевым папкам с разных узлов.
• Большинству пользователей необходим доступ к нескольким целевым папкам.
• Распределение целевых папок позволяет сделать загрузку сервера более эффективной.
• Пользователям требуется непрерывный доступ к целевым папкам.
• В организации есть веб-узлы для внутреннего и внешнего использования.

Типы DFS

Распределенная файловая система может быть реализована двумя путями:

• распределенная файловая система с изолированным корнем
• доменная распределенная файловая система.

Доступ к целевым папкам DFS с других компьютеров

Наряду с серверным компонентом DFS семейства Windows Server 2003 существует также клиентский компонент DFS. Клиент DFS выполняет кэширование обращений к корню DFS или к ссылке DFS в течение времени, заданного администратором и может работать с различными системами Windows.

Преимущества.

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

Простой доступ к файлам

Распределенная файловая система упрощает доступ к файлам. Пользователи используют единый сетевой ресурс для доступа к файлам, даже если эти файлы физически находятся на разных серверах. Даже если изменится физическое расположение целевой папки, это не повлияет на доступ пользователей к ней. Они смогут обращаться к папке как раньше, поскольку ее видимое расположение не изменится.

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

Доступность

Доменные DFS обеспечивают пользователям доступ к файлам двумя способами:

• Операционная система Windows Server 2003 автоматически публикует топологию DFS в Active Directory. Благодаря этому пространство имен DFS всегда видимо для пользователей всех серверов в домене.
• Администратор может реплицировать корень DFS и целевые папки. Репликация означает дублирование корней и целевых папок DFS на нескольких серверах домена. При этом пользователи всегда могут получить доступ к своим файлам, даже если один из физических серверов, на котором эти файлы находятся, становится недоступным.

Корень DFS может поддерживать несколько целевых папок DFS, которые физически распределены по сети. Например, это полезно, если есть файл, который активно используется пользователями. Пользователи будут обращаться к этому файлу не на одном сервере, сильно загружая его, а к файлу, распределенному системой DFS по разным серверам. Однако для пользователей этот файл будет виден в едином месте в сети.

Безопасность файлов и папок

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

Структура файловой системы.

Структура распределенной файловой системы DFS состоит из корня DFS, одной или нескольких ссылок DFS и указаний на одну или несколько целевых папок.

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

Для пользователей структура DFS предоставляет единый прозрачный интерфейс доступа к сетевым ресурсам. Для системных администраторов структура DFS - это простое пространство имен DNS: при использовании доменной DFS имена DNS корневых папок DFS разрешаются на узловые сервера для корня DFS.

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

Можно расширить структуру DFS, добавив ссылку DFS к корню DFS. Единственное ограничение на число иерархических уровней в структуре DFS определяется максимальной длиной пути к любому файлу, которая в семействе Windows Server 2003 равна 260 символам. Новая ссылка DFS может указывать на целевую папку, содержащую или не содержащую подпапки, а также на весь том семейства Windows Server 2003. Если у пользователя есть соответствующие разрешения, он может также обращаться к любым локальным папкам, существующим в целевой папке или добавляемым в нее.

Клиенты.

Для обеспечения доступа к структуре DFS вам необходимо установить на компьютеры пользователей клиентский компонент DFS. Ниже приведены типы клиентской поддержки DFS, предоставляемые различными операционными системами.

Автономный клиент DFS работает только с автономными серверами (входящими в состав рабочей группы), на которых расположен корень DFS.

Серверы.

Любая операционная система семейства Windows Server 2003, включая Windows Server 2003 Web Edition, а также Windows 2000 Server, может содержать корень DFS. При этом сервер, на котором расположен корень DFS, может работать как в составе домена, так и в автономном режиме (в составе рабочей группы).

Операционная система Windows NT 4 Server с установленным Service Pack 3 или более поздней версии, тоже может содержать корень DFS, но только в автономном режиме.

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

Дерево DFS.

Распределенная файловая система DFS является иерархической древовидной структурой, похожей на обычную файловую систему. Однако, иерархия DFS, в отличие от файловой системы, строится из трех основных элементов: корни DFS, ссылки DFS и цели (целевые папки).

Семейство Windows Server 2003 поддерживает целевые папки на следующих платформах.

Для поддержки синхронизации целевых папок ресурс для ссылки на них должен находиться в разделе NTFS семейства Windows Server 2003.

Корень DFS (DFS root)

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

Windows NT 4.0 и Windows 2000 поддерживают только один корень DFS на один сервер. Windows Server 2003 не имеет такого ограничения.

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

Ссылка не обязательно должна ссылаться на одну конкретную папку, она может представлять связь с несколькими идентичными папками (не более 32), которые называются целевыми, причем клиент DFS видит их как одну обычную папку.

Целевая папка или цель (target)

Поскольку цель (реплика) состоит из нескольких идентичных папок, клиент DFS выбирает цель случайным образом, что позволяет равномерно распределить нагрузку между серверами. При отключении одной из целей клиентом автоматически выбирается другая цел, обеспечивая тем самым отказоустойчивость и балансирование нагрузки. Можно задавать синхронизацию цели с со всеми другими целями, для этого обязательно корень DFS должен быть в домене, а цели должны размещаться на серверах Windows, с запущеной службой репликации файлов. Эта служба запускается автоматически на контроллерах доменов, а на рядовых серверах запускается вручную из консоли Сервисы (Services).

Создание структуры DFS.

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

Создание корня.

Корень DFS может быть создан на разделе NTFS, находящемся на компьютере под управлением ОС семейства Windows Server 2003. Можно создать изолированный или доменный корень DFS.

Изолированный корень DFS:

• не использует службу Active Directory;
• не может иметь несколько целевых папок корневого уровня;
• не поддерживает автоматическую репликацию файлов с использованием службы репликации файлов;
• поддерживает отказоустойчивость, используя кластеры серверов.

Доменный корень DFS:

• должен находиться на сервере домена;
• имеет собственное пространство имен DFS, автоматически публикуемое службой Active Directory;
• может иметь несколько целевых папок корневого уровня;
• поддерживает автоматическую репликацию файлов с использованием службы репликации файлов;
• поддерживает отказоустойчивость, используя службу репликации файлов.

С помощью средства администрирования DFS указывается целевая папка, которая сопоставляется корню DFS. Пользователи получают доступ к этой папке и ее подпапкам.

При использовании Windows Server 2003, Enterprise Edition или Windows Server 2003, Datacenter Edition на одном компьютере может размещаться несколько корней DFS. В серверных кластерах имя, назначенное корню DFS вне кластера на локальном запоминающем устройстве узла, должно отличаться от имени корня DFS в кластере на устройстве хранения данных кластера.

Большие доменные пространства имен DFS могут вызвать заметное увеличение сетевого трафика в связи с размером объекта DFS Active Directory. Поэтому рекомендуется использовать не более 5000 ссылок DFS для корня домена. Рекомендуемый размер пространства имен для изолированного корня - не более 50 000 ссылок на серверах под управлением Windows Server 2003.

Если в пространство имен DFS включены корни и корневые папки, которые размещены как на компьютерах под управлением ОС семейства Windows Server 2003, так и под управлением Windows 2000, необходимо выполнять администрирование этих корней с компьютера под управлением Windows Server 2003 или же с компьютера с установленным пакетом средств администрирования Windows Server 2003 Administration Tools Pack. Нельзя управлять этим пространством имен DFS с компьютера под управлением Windows 2000.

Чтобы вносить изменения в существующее пространство имен DFS, необходимо быть членом группы Администраторы на сервере, на котором оно размещено. При этом по соображениям безопасности рекомендуется использовать команду RunAs (Запуск от имени).

Чтобы создать корень DFS выполните следующие действия:

Созданный корень отобразится в консоли Распределенная файловая система DFS.

Добавление корневой целевой папки.

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

Чтобы добавить корневую целевую папку, выделите корень домена и в меню Действие выберите команду Создать корневую целевую папку . Будет запущен Мастер создания нового корня.

Добавление ссылок.

Ссылка распределенной файловой системы DFS - элемент пространства имен DFS, который находится под корнем и ссылается на одну или несколько целевых папок. Вместо реального имени и физического расположения целевой папки пользователи, работающие с пространством имен DFS, видят имя ссылки, показанное как папка, расположенная под корнем. Поскольку имена ссылок не ограничены именем или расположением целевой папки, можно делать их осмысленными для пользователей. Например, можно создать ссылку «Маркетинг», указывающую на одну или несколько целевых папок, содержащих сведения о маркетинге, независимо от их реальных имен и расположения.

• Откройте оснастку Распределенная файловая система DFS.
• В дереве консоли выделите корень DFS.
• В меню Действие выберите Создать ссылку .
• В поле Имя ссылки введите имя новой ссылки, в поле Путь к целевой общей папке укажите путь к новой ссылке или нажмите кнопку Обзор , чтобы выбрать имеющуюся общую папку из списка.

Введите комментарий, если требуется дальнейшая идентификация или описание этой ссылки. Введите длительность кэширования этой ссылки (время в секундах) для клиентов DFS и нажмите кнопку OK .

Добавление целевых папок.

Для каждой ссылки DFS можно создать набор целевых папок, на который указывает эта ссылка. Первая папка добавляется в этот набор при создании ссылки DFS. Последующие целевые папки добавляются из диалогового окна Новая целевая папка средства администрирования DFS.

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

• Задать политику репликации для целевых папок.
• Проверить состояние репликации.

Чтобы добавить целевую папку выполните следующие действия:

Резервное копирование и восстановление базы данных.

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

Для резервного копирования и восстановления базы данных DFS, работающей на автономном сервере, используется утилита командной строки dfscmd. Она создает пакетный (текстовый) файл, содержащий информацию о корне DFS.

Следующие примеры показывают применение утилиты dfscmd (замените Имя_домена и Имя_корня на соответствующие имена).

Для резервного копирования корня DFS используйте следующую запись:

dfscmd /view \\Имя_домена\Имя_корня /batch > dfs_backup.bat

Для резервного копирования корня DFS без проверки правильности ссылок и целей используйте следующую запись:

dfscmd /view \\Имя_домена\Имя_корня /batchrestore > dfs_backup.bat

Для восстановления структуры DFS используйте следующую запись:

dfscmd /view \\Имя_домена\Имя_корня /restore > dfs_backup.bat

Теневые копии общих папок.

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

Теневые копии используются для восстановления файлов, которые были случайно удалены или перезаписаны, а также для сравнения различных версий файлов.

Планирование теневого копирования.

Прежде чем включать теневые копии общих папок и задавать параметры расписания, спланируйте работу теневого копирования, пользуясь следующими рекомендациями:

• Выберите в качестве хранилища теневых копий том, для которого не выполняется теневое копирование. Использование отдельного тома или другого диска дает два преимущества. Во-первых, устраняется возможность удаления теневых копий из-за высокой загрузки ввода/вывода. Во-вторых, такая конфигурация обеспечивает лучшую производительность. Она рекомендуется для интенсивно используемых файловых серверов.
• Настройте расписание теневого копирования так, чтобы оно соответствовало расписанию работы клиентов.
• При создании теневых копий присоединенные диски копироваться не будут. Теневые копии следует включать только для томов без точек подключения или в тех случаях, когда копирование общих ресурсов на присоединенном томе нежелательно.
• Если включена возможность загрузки предыдущей версии Windows (например, Windows NT 4.0), при загрузке старой версии существующие теневые копии могут быть повреждены и могут оказаться непригодными для использования после того, как компьютер снова будет запущен под управлением Windows Server 2003.
• Теневые копии общих папок не могут служить заменой регулярной архивации. Для максимальной готовности к восстановлению данных следует использовать программу архивации в координации с теневым копированием общих папок.
• По умолчанию копирование выполняется в 7:00 и 12:00 с понедельника по пятницу. Если вы считаете, что оно должно производиться чаще, убедитесь, что выделено достаточно места и что производительность сервера не падает из-за слишком частого копирования. На томе можно сохранить до 64 копий, прежде чем самая старая копия будет удалена. Если теневое копирование выполняется слишком часто, этот предел может быть достигнуто очень скоро, что приведет к быстрой потере старых копий.
• Если том удален, а задача теневого копирования не удалена, она не будет выполнена и в журнал событий будет записано событие с кодом 7001. Удаление задачи позволит избежать заполнения журнала событий такими ошибками.
• Если планируется выполнять дефрагментацию исходного тома, для которого будут включены теневые копии общих папок, рекомендуется при его первом форматировании установить размер кластера не меньше 16 КБ. В противном случае количество изменений, вызванных дефрагментацией, приведет к удалению предыдущих версий файлов.
• Если на исходном томе должно применяться сжатие файлов NTFS, размер кластера не может быть больше 4 КБ. В этом случае, если выполняется дефрагментация очень фрагментированного тома, старые теневые копии могут потеряться быстрее, чем предполагалось.

Включение теневых копий общих папок.

Чтобы включить теневые копии общих папок выполните следующее:

Для выполнения этой процедуры необходимо входить в группу Администраторы на локальном компьютере или получить соответствующие полномочия путем делегирования. Если компьютер присоединен к домену, эту процедуру могут выполнять члены группы Администраторы домена.

Настройка параметров.

В следующей таблице перечислены параметры службы теневого копирования, которые можно настраивать:

Параметр	Описание
Место хранения	Задает том, на котором сохраняются теневые копии. По умолчанию это том, содержащий исходные файлы. Для повышения быстродействия на интенсивно используемых файловых серверах рекомендуется использовать отдельный том на другом диске. Смена тома хранилища возможна только при отсутствии теневых копий. Чтобы сменить том хранилища для тома, на котором уже включены теневые копии, необходимо сначала удалить все теневые копии на этом томе.
Максимальный размер	Задает максимальный объем на конкретном томе, который может использоваться для хранения теневых копий. По умолчанию размер хранилища составляет 10% от размера тома, содержащего исходные файлы, для которых создаются теневые копии. Если теневые копии и исходные файлы хранятся на разных томах, следует изменить этот стандартный параметр, чтобы он отражал размер хранилища, который требуется выделить для теневых копий. Максимальный размер должен быть не меньше 100 мегабайт (МБ); использование этого ограничения позволяет сохранять только одну теневую копию. Если установлено жесткое ограничение на объем, следует убедиться, что для запланированных теневых копий хватает места. Удаление теневых копий без возможности восстановления из-за ограничений хранилища делает бессмысленным включение теневых копий общих папок.. Чтобы сравнить объем дискового пространства, используемого на томе хранилища, с максимальными ограничениями хранилища, нажмите кнопку Сведения .
Расписание	Задает параметры создания расписания для регулярного выполнения теневого копирования. Следует планировать теневое копирование на время, наиболее удобное для пользователей. По умолчанию копирование выполняется в 7:00 и 12:00 с понедельника по пятницу.

Чтобы изменить параметры теневых копий общих папок выполните следующее:

На одном томе может быть сохранено не более 64 теневых копий. По достижении этого предела самые старые копии будут удаляться без возможности восстановления.

Технологии сжатия файлов на томах NTFS.

Сжатие файлов, папок и программ позволяет сократить их размер и уменьшить объем пространства, занимаемого ими на дисках или устройствах со съемными носителями. Сжатие диска приводит к уменьшению объема пространства, занимаемого всеми файлами и папками на этом диске.

Windows Server 2003 поддерживает два вида сжатия файлов: сжатие NTFS и ZIP-папки.

Сжатие NTFS

Сжатие файлов доступно только на дисках NTFS-формата. Чтобы определить, отформатирован ли диск в файловой системе NTFS, откройте папку Мой компьютер, щелкните диск правой кнопкой мыши и выберите команду Свойства . Файловая система будет показана на вкладке Общие .
*Средствами NTFS можно сжимать как отдельные файлы и папки, так и диски NTFS целиком.
*Можно сжать папку, не сжимая ее содержимого.
*С файлами, сжатыми средствами NTFS, можно работать, не распаковывая их.
*Имена файлов и папок, сжатых средствами NTFS, можно для удобства выделять на экране другим цветом.
*При работе с файлами, сжатыми средствами NTFS, может наблюдаться некоторое снижение быстродействия. При открытии сжатого файла Windows автоматически распаковывает его, а при закрытии снова сжимает. Эти действия могут неблагоприятно отразиться на производительности компьютера.
*Файлы и папки, сжатые средствами NTFS, остаются в сжатом виде только на то время, пока они хранятся на диске NTFS.
*Файл, сжатый средствами NTFS, нельзя шифровать.
*В Windows XP Home Edition не поддерживается шифрование файлов NTFS.

ZIP-папки

ZIP-папки не поддерживаются в Windows XP 64-Bit Edition и 64-разрядных версиях семейства продуктов Windows Server 2003.

Сжатие NTFS.

Чтобы сжать файл или папку на диске NTFS выполните следующие действия:

При копировании файла в сжатую папку он автоматически сжимается. Однако, при перемещении файла в сжатую папку, находящуюся на этом же диске, файл сохраняется в исходном состоянии (сжатом или несжатом). При перемещении файла с другого диска NTFS в сжатую папку, также производится его сжатие.

Файлы и папки, сжимаемые средствами NTFS, нельзя шифровать.

ZIP-папки.

Чтобы создать ZIP-папку выполните следующие действия:

• Откройте папку Мой компьютер.
• Дважды щелкните диск (папку).
• Щелкните правой кнопкой мыши файл (папку), который требуется сжать, и выберите команду Отправить -> Сжатая ZIP-папка.
• Запускается процесс сжатия файла (папки), в результате которого создается на том же диске (папке) новая папка с именем сжимаемого файла (папки), но с расширением.zip.

При перемещении или копировании файла в ZIP-папку он автоматически сжимается.

Создание общих веб-папок.

Если вы установили службу Internet Information Services (IIS), то вы можете предоставлять папки для общего доступа пользователям вашей сети через браузер (например, Internet Explorer). Для предоставления общего доступа к папке выполните следующее:

По завершении настройки пользователи вашей сети смогут осуществлять доступ к папке через веб-браузер вводя в адресной строке полный путь к папке:

http://win2003s.test.fio.ru/tools

Прежде чем давать общий доступ через веб к папке, поместите в нее файл Default.htm, который будет открываться первым при обращении к данной папке.

Распределенная файловая система (Distributed File System, DFS) настраивается в операционной системе Windows 2000 Server (Панель управления – Администрирование – Распределенная файловая система DFS ) и позволяет объединить файловые ресурсы, находящиеся на различных компьютерах, в одно пространство имен. Таким образом, вместо сети, состоящей из большого количества машин, пользователь видит структуру логических имен, связанных с общими ресурсами.

Преимущества DFS:

· возможность логического представления общих ресурсов, находящихся на различных серверах сети;

· удобное администрирование томов – общий ресурс, входящий в состав тома DFS, может быть отключен без какого-либо влияния на оставшуюся часть пространства имен;

· наличие графического инструмента администрирования;

· возможность организации отказоустойчивых схем хранения информации – одному логическому имени могут соответствовать несколько копий ресурса (реплик), наличие которых прозрачно для пользователя;

· сбалансированная нагрузка на общие ресурсы сети за счет связывания одного имени ресурса с разными репликами этого ресурса;

· прозрачность соответствия логического представления данных и их физического местоположения – пользователи не знают об изменениях физического местоположения ресурса;

· интегрирование с моделью безопасности Windows 2000 – используются единые учетные записи пользователей;

· интеллектуальное кэширование данных на стороне клиента;

· возможность взаимодействия с другими сетевыми файловыми системами.

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

Начальной точкой для логических имен дерева DFS служит корень распределенной файловой системы, для создания которого необходимо указать некоторый общий ресурс, находящийся на сервере. Все остальные имена DFS будут находиться на следующем иерархическом уровне. Общие ресурсы компьютерной сети в дереве DFS представляются с помощью логических имен, имеющих следующее место в полном имени ресурса в сети: \\Имя_Сервера\Логическое_Имя_DFS\ Путь\Файл.

Распределенная файловая система DFS обеспечивает подключение к одному логическому имени до 32 альтернативных общих ресурсов (реплик). Если реплики находятся в разделе NTFS 5.0 в распределенной файловой системе, созданной на серверах Windows 2000 и интегрированной с Active Directory, то для них можно настроить автоматическую синхронизацию – согласование данных (репликацию). В других случаях согласование реплик необходимо выполнять вручную .

Элементы системной интеграции

В распределенных вычислительных системах или общедоступных компьютерных сетях, например в Интернете, существует множество объектов, представляющих интерес – таких, как базы данных, принтеры, серверы службы факсов, приложения, пользователи. Пользователям желательно уметь находить и использовать эти объекты. Администраторам необходимо управлять использованием этих объектов.

Служба каталогов

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

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

Служба каталогов может решать следующие задачи:

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

· Распределять каталог по различным компьютерам сети.

· Выполнять репликацию каталога, чтобы обеспечить доступ к нему большему числу пользователей и повысить защищенность сети от сбоев.

· Разбивать каталог на несколько разделов для обеспечения возможности хранения большого количества объектов.

Служба каталогов является как средством администратора, так и средством конечного пользователя. По мере роста числа объектов в сети повышается значение службы каталогов. Служба каталогов – это та ось, вокруг которой вращается большая распределенная система.

Active Directory – это служба каталогов, включенная в операционную систему Windows 2000/2003 Server. Она является наглядным примером системной интеграции – расширяет возможности существовавших ранее служб каталогов на базе Windows и добавляет совершенно новые возможности.

Служба каталогов Active Directory обеспечивает безопасность, распределенность, возможность разбиения на разделы и возможность репликации. Она рассчитана на установку в системе любого размера – от одиночного сервера с несколькими сотнями объектов до системы из тысяч серверов с миллионами объектов. Служба каталогов Active Directory предоставляет много новых возможностей, облегчающих поиск и управление большими объемами данных и позволяющих экономить время как администраторам, так и конечным пользователям.

Служба каталогов Active Directory образует пространство имен, в котором имя объекта в каталоге разрешается в сам объект.

Объект – это отдельный именованный набор атрибутов, представляющий нечто конкретное – например, пользователя, принтер, приложение.

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

Класс объектов определяет тип информации, содержащейся в Active Directory для экземпляров (объектов) данного класса. Следовательно, каждый объект принадлежит, по крайней мере, к одному объектному классу, представляющему собой некоторое семейство объектов с определенными общими характеристиками.

Схема службы каталогов Active Directory реализована как набор экземпляров классов объектов, которые хранятся в каталоге. Следовательно, схема – совокупность (матрица) всех атрибутов и классов.

Контейнер подобен объекту в том, что у него есть атрибуты и он является частью пространства имен службы каталогов Active Directory. Но он, в отличие от объекта, не представляет собой нечто конкретное. Он лишь «оболочка» для группы объектов и других контейнеров.

Термин дерево используется для описания иерархии объектов и контейнеров. Вершины дерева обычно являются объектами. Узлы дерева (точки, где дерево ветвится) являются контейнерами. Дерево показывает связь между объектами или путь от одного объекта к другому. Простой каталог является контейнером. Компьютерная сеть или домен также являются контейнерами. Непрерывным поддеревом называется любой неразрывный путь в дереве, включая все составляющие каждого включенного в этот путь контейнера (рис. 3.5).

Рис 3.5. Непрерывное поддерево каталога файлов

Имя идентифицирует любой объект службы каталогов Active Directory. Имена бывают двух типов: различающееся имя и относительное различающееся имя.

Различающееся имя (DN – distinguished name) определяет домен, содержащий объект, а также полный путь по иерархии контейнеров, ведущий к данному объекту. Типичное DN может иметь вид:

/O=Internet/DC=COM/DC=Microsoft/CN=Users/CN=James Smith

Это DN определяет объект-пользователь «James Smith» в домене Microsoft.com. Здесь CN обозначает общее имя. (рис. 3.6)

Рис. 3.6. Графическое представление различающегося имени

Относительное различающееся имя (RDN – Relative Distinguished Name) объекта – это часть его имени, которая представляет собой атрибут самого объекта. В предыдущем примере RDN объекта-пользователя «James Smith» будет CN=James Smith. RDN его родительского объекта будет CN=Users.

Служба каталогов Active Directory обеспечивает эффективную работу сложной корпоративной среды, предоставляя следующие возможности.

· Единая регистрация в сети . Пользователи могут регистрироваться в сети с одним именем и паролем и получать при этом доступ ко всем сетевым ресурсам (серверам, принтерам, приложениям, файлам и т. д.) независимо от их расположения в сети.

· Безопасность информации . Средства аутентификации и управления доступом к ресурсам, встроенные в службу Active Directory, обеспечивают централизованную защиту сети. Права доступа можно определять не только для каждого объекта каталога, но и каждого свойства (атрибута) объекта.

· Централизованное управление . Администраторы могут централизованно управлять всеми корпоративными ресурсами. Рутинные задачи администрирования не нужно повторять для многочисленных объектов сети.

· Администрирование с использованием групповых политик. При загрузке компьютера или регистрации пользователя в системе выполняются требования групповых политик; их настройки хранятся в объектах групповых политик (GPO) и «привязываются» к сайтам, доменам или организационным единицам. Групповые политики определяют, например, права доступа к различным объектам каталога или ресурсам, а также множество других «правил» работы в системе.

· Гибкость изменений . Служба каталогов гибко следует за изменениями структуры компании или организации. При этом реорганизация каталога не усложняется, а может и упроститься. Кроме того, службу каталога можно связать с Интернетом для взаимодействия с деловыми партнерами и поддержки электронной коммерции.

· Интеграция с DNS . Служба Active Directory тесно связана с DNS. Этим достигается единство в именовании ресурсов локальной сети и глобальной сети Интернет, в результате чего упрощается подключение пользовательской сети к Интернету. Служба каталогов Active Directory использует систему DNS в качестве службы определения местоположения. Имена доменов Windows 2000/2003 являются именами доменов DNS.

· Расширяемость каталога . Администраторы могут добавлять в схему каталога новые классы объектов или добавлять новые атрибуты к существующим классам.

· Масштабируемость . Служба Active Directory может охватывать как один домен, так и множество доменов, один контроллер домена или множество контроллеров домена – т. е. она отвечает требованиям сетей любого масштаба. Несколько доменов можно объединить в дерево доменов, а несколько деревьев доменов можно связать в лес.

· Репликация информации . В службе Active Directory используется репликация служебной информации в схеме со многими ведущими (multi-master), что позволяет модифицировать каталог на любом контроллере домена. Наличие в домене нескольких контроллеров обеспечивает отказоустойчивость и возможность распределения сетевой нагрузки.

· Гибкость запросов к каталогу . Пользователи и администраторы сети могут быстро находить объекты в сети, используя свойства объекта (например, имя пользователя или адрес его электронной почты, тип принтера или его местоположение и т. п.). Это, в частности, можно сделать при помощи команды Пуск – Поиск папку Мое сетевое окружение или оснастку Active Directory – пользователи и компьютеры .Оптимальность процедуры поиска достигается благодаря использованию глобального каталога.

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

Основные компоненты любой службы каталога – база данных, содержащая нужную информацию, и один или несколько протоколов, обеспечивающих доставку данных пользователям. Active Directory обеспечивает хранение любой общедоступной информации. Как и другие службы каталогов, Active Directory обеспечивает некоторый механизм хранения информации и протоколы для доступа к ней.

Можно сказать, что служба Active Directory «стоит на трех китах»:

· Стандарт Х.500

· Служба DNS (Domain Name Service)

· Протокол LDAP (Lightweight Directory Access Protocol)

В Active Directory частично реализована модель данных, описываемая стандартом Х.500. Традиционная в сетях TCP/IP служба DNS используется, в частности, для поиска контроллеров домена, а благодаря протоколу LDAP клиенты могут по имени находить в каталоге Active Directory нужные объекты и получать доступ к их атрибутам.

Для понимания структуры Active Directory рассмотрим сначала отличия Windows 2000 от предыдущих версий серверных операционных систем Windows. Компьютеры на базе Windows 2000 по-прежнему объединяются в домены. Домены – это известное решение для администрирования групп, предоставляющее каждому пользователю учетную запись в конкретном домене. Однако, в отличие от Windows NT Server 4.0, где доменам давались простые строковые имена (имена NetBIOS), в среде Windows 2000 Server каждый домен должен иметь имя, отвечающее соглашениям именования доменов Domain Name System (DNS). Так, домен, имеющий имя NetBIOS MainOffice при обновлении может получить новое имя типа mainoffice.company.com.

В каждом домене один или несколько компьютеров должны выполнять функции контроллеров домена. В среде Windows 2000 Server каждый контроллер домена содержит полную копию базы данных Active Directory этого домена.

В Active Directory используются так называемое ядро Extended Storage Engine (ESE) и два различных протокола, обеспечивающих связь между клиентами и базой данных.

Для поиска контроллера домена клиент обращается к протоколу, описанному в DNS – «стандартной» службе каталогов, применяемой в настоящее время для сетей TCP/IP.

Для доступа к данным в Active Directory клиент использует протокол Lightweight Directory Access Protocol (LDAP) (рис. 3.7).

Рис 3.7. Доступ к данным с использованием LDAP

После того как с помощью DNS нужный контроллер домена обнаружен, для доступа к данным Active Directory используется протокол LDAP. Протокол LDAP работает поверх TCP/IP и – как следует из названия протокола – определяет способы доступа к каталогу со стороны клиентов.

Помимо механизма доступа данный протокол реализует соглашения по именованию информации в каталоге, в явном виде описывая структуру этой информации. Для клиента все данные, хранящиеся в базе LDAP, представляются в виде иерархического дерева. Каждый узел дерева (объект или элемент) может быть либо контейнером, либо листом. Различие между ними вполне очевидно: контейнеры могут содержать другие элементы, а листья – нет.

Каждый элемент (контейнер или лист) представляет собой некоторый объектный класс, определяющий атрибуты (называемые также свойствами) данного элемента. Поскольку атрибуты есть и у контейнеров, и у листьев, информация, хранящаяся в дереве каталога, распределена по всем узлам.

Тип информации (объектные классы и типы атрибутов), содержащейся в конкретной базе данных Active Directory, задается схемой, определенной для этого каталога. В Active Directory схема каждого каталога представлена элементами, хранящимися непосредственно в самом каталоге. Компания Microsoft определяет стандартную схему, однако пользователи и разработчики программных средств могут добавлять новые классы и типы атрибутов. Изменение схемы каталога – полезная возможность, которой нужно пользоваться очень осторожно, поскольку такие изменения могут иметь весьма значительные последствия.