Обеспечение надежного доступа к общим файлам и принтерам с помощью службы кластеров Windows 2000

Опубликовано: 1 апреля 2002 г. | Переведено: 31 августа 2006 г.

Аннотация

В данном официальном документе представлено руководство по обеспечению надежного доступа к общим файлам и принтерам с помощью службы кластеров ОС Microsoft® Windows® 2000. Данный документ не претендует на описание всех возможных сценариев использования службы кластеров. Тем не менее, он содержит достаточное количество примеров, которые помогут администраторам внедрить службу кластеров для решения поставленных в организации задач.

На этой странице:

Введение

Доступность службы печати считается важным фактором при развертывании компьютерной сети. В связи с этим обеспечение надежного доступа к общим принтерам является одной из основных возможностей, которую предоставляет администраторам служба кластеров ОС Microsoft® Windows® 2000 Advanced Server. Поскольку создание кластеров является новой возможностью в ОС Windows, администраторам необходимо изменить свое восприятие ОС Windows, как ОС, управляющей только одним компьютером.

В данном документе представлена основная информация, которая понадобится Вам для правильного использования службы кластеров Windows 2000. Здесь описывается используемая службой кластеров модель архитектуры (служба кластеров основана на так называемой модели архитектуры «с индивидуальным доступом» («shared-nothing»)), а также рассматривается структура групп и виртуальные серверы. В данном документе также подробно описывается процесс создания ресурсов «Диспетчера очереди печати», а в Приложении А приведено подробное иллюстрированное руководство по установке кластера, на которое даются ссылки на протяжении всего документа.

Наверх страницы

Основные термины и понятия

В данном разделе рассматриваются основные термины и понятия, которые используются в данном документе.

Соглашения об именовании

Если Вы не знакомы с созданием кластеров в Windows, Вы можете растеряться от того количества названий, которые используются для этой технологии. На стадии бета-тестирования служба кластеров носила кодовое название Wolfpack. Служба кластеров была выпущена под официальным названием Microsoft Cluster service, поэтому иногда ее еще называют MSCS. Кроме этого, в статьях базы знаний в качестве названия используется как «служба кластеров» (Cluster Server), так и «кластеры серверов» (Server Clustering). Независимо от используемого названия это одна и та же технология.

Примечание. Примите к сведению, что служба кластеров – это не одно и то же, что балансировка нагрузки сети (Network Load Balancing) или регулирование нагрузки компонентов (Component Load Balancing).

Модель архитектуры «с индивидуальным доступом» («shared-nothing»)

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

Ресурсы

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

Зависимости

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

Рисунок 1 – Типичное дерево зависимости для общего файлового ресурса

Принимая во внимание вышеизложенную информацию, может показаться, что связи между зависимостями являются строго односторонними. На самом деле, это не так. Наиболее яркий пример двусторонней связи – это наиболее полно описанный в данном документе ресурс "Диспетчер очереди печати". При добавлении принтера к виртуальном серверу необходимо запустить мастер приложений кластера (Cluster Application Wizard) под тем сетевым именем, от которого зависит диспетчер печати. Аналогичные зависимости существуют и для других приложений, ресурсов «Сетевое имя», а также различных служб.

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

Группы

Группы – это логическое объединение ресурсов кластера, которые для своего нормального функционирования должны работать на одном узле. Например, в случае, если банк сообщений (Information Store) и агент передачи сообщений (Message Transfer Agent, MTA) в Microsoft Exchange Server будут запущены на разных серверах, то это неизбежно приведет к возникновению некоторых проблем. Важно отчетливо понимать, что группа является единицей отказоустойчивости в кластере. В случае отказа с одного узла на другой перемещаются целые группы ресурсов, а не отдельно взятые ресурсы.

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

Восстановление после отказа и возврат после отказа

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

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

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

Виртуальный сервер

Рисунок 2 – Дерево зависимости для виртуального сервера

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

Примечание. Виртуальные серверы основаны на использовании NetBIOS, из-за чего имеют определенные ограничения.

Рисунок 3 – Пространства имен, предоставляемые клиенту узлами кластера

Создание виртуального сервера

Существует два способа создания виртуального сервера. Несмотря на то, что Вы можете сделать это вручную, самый простой способ – это воспользоваться мастером приложений кластера (Cluster Application Wizard). Мастер приложений кластера создает виртуальный сервер с возможностью настройки приложения сервера кластеров. При создании виртуального сервера вручную необходимо, чтобы в соответствующей группе были настроены ресурсы «IP-адрес» и «Сетевое имя». В Приложении Б рассматриваются оба способа создания виртуального сервера и подробно описываются шаги, которые необходимо для этого предпринять.

Наверх страницы

Общие принтеры

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

После создания ресурса «Диспетчер очереди печати» к нему необходимо добавить принтеры. В ОС Windows 2000 эта задача упрощена, поскольку в базе данных конфигурации кластера содержится необходимая информация о портах принтеров, входящих в кластер. Это избавляет от необходимости устанавливать порты дважды: по одному на каждый узел. Тем не менее, драйверы должны быть установлены на обоих узлах, поскольку драйверы принтера копируются на общий ресурс PRINT$ удаленного сервера.

Диспетчеры очереди печати кластера поддерживают только стандартные мониторы портов и принтеры, использующие протокол LPR (Line Printer Remote). LPR-порты не поддерживают двунаправленную печать. На данный момент никакие другие порты не поддерживаются.

В случае, если группа, в которой имеется ресурс «Диспетчер очереди печати», была перенаправлена на другой узел из-за отказа узла, то документ, который был направлен на печать на принтер отказавшего узла, будет распечатан на другом узле. Когда Вы переносите ресурс «Диспетчер очереди печати» или отключаете его, служба кластеров ожидает, пока не будет завершено помещение всех документов в очередь или пока установленное время ожидания не истечет. Документы, отправленные из приложения на ресурс «Диспетчер очереди печати» удаляются и должны быть повторно отправлены на печать на ресурс (т.е. повторно напечатаны), если сбой в группе произошел до того, как приложение завершило постановку документов в очередь печати.

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

Создание ресурса «Диспетчер очереди печати»

Ресурсу «Диспетчер очереди печати» необходимо наличие следующих зависимостей: сетевое имя и тип источника хранения. На Рисунке 2 изображено дерево зависимости для ресурса «Диспетчер очереди печати».

Рисунок 4 – Дерево зависимости для ресурса «Диспетчер очереди печати»

На странице параметров ресурса, отображаемой в мастере новых ресурсов (New Resource Wizard), имеются только два параметра, которые можно установить: расположение папки очереди печати (spool folder) и время ожидания завершения задания (job completion timeout). Мастер, использующий данные зависимости, устанавливает эти параметры автоматически, поэтому обычно нет необходимости в их изменении.

Рисунок 5 – Параметры диспетчера очереди печати

Установка принтеров

Создание виртуального сервера и настройка ресурса «Диспетчер очереди печати» - это лишь половина дела. Сам по себе «Диспетчер очереди печати» без наличия принтеров бесполезен. Для того, чтобы добавить принтер, Вам необходимо вначале определить узел-владелец виртуальных серверов, поскольку именно на него копирует драйверы мастер установки принтеров (Add Printers Wizard). После этого драйвер необходимо вручную установить на другом узле.

Мастер установки принтеров должен быть запущен на том виртуальном сервере, от сетевого имени которого зависит «Диспетчер очереди печати». После успешной установки принтера Вам необходимо добавить драйвер на другой узел. Несмотря на то, что для этого есть несколько способов, мастер установки принтеров (Add Printers Wizard) сразу запустит для этих целей командную строку с соответствующими параметрами, как показано ниже на Рисунке 6. Возможно, стоит создать ярлык в кластере файлов и принтеров для запуска этой командной строки.

Рисунок 6 – Командная строка мастера установки принтеров (Add Printers Wizard)

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

Добавление дополнительных драйверов

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

Сценарий

В домене Reskit.com имеется несколько серверов печати, которые необходимо объединить в один кластер с именем SEA-NA-CLUS-02. Общее количество принтеров приблизительно равно 200, при этом необходимо обеспечить высокую производительность.

Реализация

Для обеспечения лучшей производительности все принтеры необходимо приблизительно равномерно разделить между двумя виртуальными серверами SEA-NA-PRINT-01 и SEA-NA-PRINT-02. Каждый виртуальный сервер сконфигурирован в собственной группе с установленным ресурсом «Диспетчер очереди печати». Одна половина принтеров устанавливается на первом виртуальном сервере, а другая – на втором. Для каждой группы определены предпочитаемые владельцы (узлы). В соответствии с настройкой возврат после отказа должен происходить между 23.00 и 00.00.

Обзор необходимых действий:

Пошаговое руководство можно найти в Приложении Г.

Наверх страницы

Заключение

Поскольку службы печати очень важны для конечных пользователей, работающих в компьютерных сетях, ОС Windows 2000 Advanced Server предоставляет службу кластеров – мощное средство, обеспечивающее повышенную надежность и производительность служб печати. Однако, для того, чтобы Ваши пользователи смогли воспользоваться всеми преимуществами, предоставляемыми службой кластеров, её необходимо правильно настроить.

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

Более того, для создания общих файлов Вам необходимо использовать администратор кластеров (Cluster Administrator) из пакета администрирования (Administrative Tools), при этом может потребоваться назначить более сложные правила доступа к ним. Кроме того, при использовании кластеров для служб печати Вам необходимо сначала настроить зависимые ресурсы «Сетевое имя» и «Физический диск».

Наверх страницы

Связанные ресурсы

Для получения дополнительной информации о службе кластеров Windows 2000 обратитесь к следующим материалам:

Также обратитесь к следующим статьям базы знаний:

Наверх страницы