Главная | Контакты | Настройки СМЕНИТЬ ПАЛИТРУ:

Главная > Операционные системы > Windows > Windows Server 2003

Глава 3. Каталог сеансов и распределение нагрузки

Если у вас есть больше пользователей, чем может поддерживать один терминальный сервер, или если вы хотите иметь возможность отключить сервер для профилактики, но продолжать предоставлять доступ к приложениям, то вы можете использовать распределение нагрузки, которая встроена в архитектуру Terminal Services. В этой главе мы рассмотрим службу Microsoft Network Load Balancing (NLB), а также новую особенность WS2K3 - каталог сеансов (Session Directory), который позволяет следить за сеансами пользователей на нескольких серверах.

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

Конфигурация аппаратного обеспечения терминального сервера

Вообще говоря, терминальные серверы больше похожи на рабочие станции, чем на серверы. Много ли вы встречали серверов, на которых инсталлирован Microsoft Office? Системные интеграторы должны учитывать это при конфигурировании аппаратных средств для терминального сервера.

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

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

Если вы хотите отделить приложения от операционной системы, переместив папку Program Files на диск D и измените в реестре значение HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir, чтобы он отражал новое место.

Конфигурация жесткого диска

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

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

RAID1, или зеркалирование, встречается наиболее часто. Его просто реализовать, он требует всего 2 диска, а также является отказоустойчивым . RAID1 удваивает скорость чтения, но не увеличивает скорость записи, поскольку данные пишутся на оба диска. Если один из дисков выходит из строя, сервер продолжает работу, используя второй диск. Это хороший выбор, если у вас ограниченное число дисков.

RAID5, чередование дисков с паритетом, также часто используется. Как и в RAID0, данные распределяются по дискам, но в RAID5 добавляются контрольные блоки. Эти контрольные блоки позволяют вычислить пропущенный блок в случае выхода одного из дисков из строя. Поэтому RAID5 является отказоустойчивым при выходе из строя одного диска. Поскольку данные разнесены по разным дискам, скорость чтения данных очень высокая, но скорость записи небольшая, поскольку помимо записи самих данных надо вычислить и записать контрольный блок. Для RAID5 необходимо минимум 3 диска; это хороший выбор для терминальных серверов.

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

RAID 10 (иногда называемый RAID 1+0) комбинирует скорость RAID0 и отказоустойчивость RAID1. В нем каждым элементом массива RAID0 является зеркало из двух дисков. RAID 10 обеспечивает самый быстрый доступ к данным из всех RAID, одновременно поддерживая отказоустойчивость. Вы даже можете потерять несколько дисков, и сервер все равно будет продолжать функционировать (если эти диски не формируют одно зеркало). Недостатком RAID 10 является то, что вы теряете половину дискового пространства под отказоустойчивость; однако, поскольку для терминального сервера не требуется большого дискового пространства, этот потенциальный недостаток можно не принимать во внимание. RAID 10 является лучшим выбором для терминальных среверов, имеющих минимум 4 диска.

На первый взгляд, RAID 0+1 выглядит аналогичным RAID 10. Разница состоит в том, как контроллер обрабатывает массив. Вместо того, чтобы считать его массивом RAID0 зеркальных дисков, RAID 0+1 считает зеркалом весь массив. Поэтому, в отличие от RAID 10, RAID 0+1 может потерять только один диск и продолжать функционировать. Это прекрасный выбор для терминального сервера, поскольку позволяет значительно повысить скорость дисковых операций, одновременно обеспечивая отказоустойчивость.

Память

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

В первую очередь вам необходимо учесть ограничения материнской платы и BIOS. Также примите во внимание число доступных слотов памяти. На максимальный объем памяти влияет также редакция WS2K3:

Редакция

Максимум RAM

Максимальное число процессоров

Standard Edition

4GB

4

Enterprise Edition (32-bit)

32GB

8

Datacenter Edition (32 bit)

64GB

32

Перед тем, как устанавливать в сервер память, необходимо определить, сколько ее нужно для ваших пользователей. Для этого есть несколько ресурсов, которые помогут вам оценить требуемый объем RAM:

Microsoft рекомендует начать отсчет памяти с 128MB RAM для ОС. После этого определите тип работы, которая будет осуществляться на терминальном сервере. Пользователей можно разбить на три категории:

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

Определив типы пользователей, вы можете оценить объем требуемой памяти, воспользовавшись следующей таблицей:

Тип пользователя

Объем памяти

Системная память

Обычный пользователь

9.3MB

128MB

Опытный пользователь

8.5MB

128MB

Ввод данных

3.5MB

128MB

Hewlett Packard рекомендует увеличить объем памяти, если используются 16-разрядные приложения. 16-разрядные приложения требуют дополнительной памяти - на 25% больше, чем 32-разрядные.

Процессор

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

Как вы видели ранее, разные редакции WS2K3 поддерживают разное число процессоров. Эти ограничения такие же, как и для Win2K Server, но в W2K3 встроена поддержка технологии Intel HyperThreading. Эта технология позволяет одним процессором параллельно обрабатывать два потока (threads), виртуально удваивая вычислительную мощность процессора.

WS2K3 может корректно различать физические процессоры и виртуальные, создаваемые HyperThreading. При загрузке Windows, она подсчитывает количество процессоров в системе. Если процессоров больше, чем поддерживает эта лицензированная ОС, то отсчет заканчивается на лимите ОС. Это важно, поскольку BIOS подсчитывает физические процессоры перед виртуальными. Такое поведение предотвращает Win2K использовать виртуальные процессоры, если есть доступные физические. На рисунке показан порядок, в котором процессоры подсчитываются в ОС при использовании HyperThreading.

Давайте сравним процессорные ограничения стандартной редакции каждой ОС - каждая из них ограничена 3 процессорами. Поскольку Win2K не может различать физические и логические процессоры, ОС останавливается на четвертом процессоре. В нашем примере есть 4 физических процессора с HyperThreading, Win2K остановится на 4-м процессоре и будет размещять на каждом процессоре по одному потоку. Если бы было только 2 процессора с HyperThreading, то Win2K тоже остановилась бы на четвертом, но в этом случае разместила бы по два потока на каждый процессор, используя преимущества HyperThreading.

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

Что это означает для терминальных серверов? В большинстве случаев, поддержка HyperThreading в WS2K3 позволит вам повысить производительность без добавления процессоров в систему или обновления ОС до Enterprise Edition.

Нижняя граница

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

Начнем с двухпроцессорной системы 2.4GHz Xeon с включенным HyperThreading. Добавим 2GB RAM и 4 диска SCSI в конфигурации RAID 10. Такой сервер будет стоить около $6000 и будет поддерживать до 200 обычных пользователей. Если вы используете этот же сервер для предоставления доступа не к рабочему столу, а к одиночному опубликованному приложению, то он может поддерживать и 400 параллельных пользователей (в зависимости от требований приложения).

Если ваш терминальный сервер содержит стандартный набор приложенй - Microsoft Office, Outlook, Internet Explorer (IE) и т.д. - то ограничивающим фактором будет память; два процессора с HyperThreading не будут полностью загружены. Поэтому удвоив память до 4GB вы сможете удвоить число поддерживаемых пользователей.,

Есть утилиты, например, Wyse Expedian (http://www.wyse.com), которые оптимизируют использование памяти на терминальных серверах, позволяя еще больше увеличить емкость вашего сервера.

Отказоустойчивость

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

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

  • Отказоусточивость сервера - Этот уровень определяет способность продолжать поддерживать пользователей в случае потери одного из серверов. Для этого определите число необходимых серверов и добавьте еще один - запасной.

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

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

Допустим, есть 1200 критических пользователей. Для обеспечения отказоустойчивости сервера, это число пользователей требуют 4 сервера, каждый из которых может поддерживать 400 пользователей. В обычных условиях на каждом сервере по 300 пользователей, но в случае поломки сервера остальные серверы способны вынести нагрузку. Для обеспечения отказоустойчивости метоположения с 4 серверами в двух зданиях, вам потребуется 6 х 400 серверов. Если здание 1 будет недоступным, три сервера в здании 2 продолжат поддерживать пользователей.
(Прим. перев.: наверное, навеяно событиями 11 сентября)

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

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

Распределение нагрузки

В базовом варианте распределение нагрузки делается вручную. Вы создаете файлы соединений для каждого из ваших серверов и распространяете их среди пользователей, указывая определенному проценту пользователей их предпочтительное соединение. Вернемся к нашему примеру. Если у вас есть 1200 пользователей и 4 сервера, вы создаете 4 файла и распространяете их среди пользователей, но инструктируете 400 пользователей подключаться к серверу А, еще 400 - к серверу B и т.д. Если один из серверов перестает функционировать, пользователи могут использовать другой файл соединения в качестве резерва. Если вы хотите сделать автоматическое распределение нагрузки и отказоустойчивость без вмешательства пользователя, вам нужно реализовать распределение нагрузки.

Microsoft Network Load Balancing (NLB)

NLB позволяет разместить группу серверов за виртуальным адресом IP (VIP). NLB распределяет соединения, делаемые к VIP, среди серверов кластера и поддерживает межсерверные коммуникации, чтобы в случае выхода одного из серверов из строя NLB прекратила направлять к нему клиентов.

В WS2K3 Microsoft улучшила балансировщик нагрузки. В Win2K, NLB был доступен только в редакции Advanced или Datacenter. WS2K3 включает NLB во все редакции. Microsoft сделала следующие улучшения:

  • NLB Manager - В Win2K вы должны вручную конфигурировать каждый сервер в кластере. WS2K3 включает новый инструмент администрирования, который позволяет централизованно создавать, конфигурировать и управлять кластерами NLB.
  • Виртуальные кластеры - При использовании NLB для кластеризации веб-серверов, вы можете создавать множественные кластеры на одном и том же наборе серверов, используя несколько адресов IP на каждом сервере . Каждому виртуальному кластеру присваивается свой VIP.
  • Подержка нескольких сетевых адаптеров - WS2K3 позволяет привязать NLB к каждому сетевому адаптеру сервера. Win2K позволяла привязать NLB только к одному адаптеру.
  • Поддержка широковещания - Кластеры WS2K3 можно настроить на использование multicast для межсерверных коммуникаций.

Но даже со всеми этими улучшениями NLB все еще имеет ограничения, которые вы должны учитывать. Во первых, все члены кластера NLB должны находиться в одной подсети. Во вторых, NLB считает только число активных соединений с сервером при определении того сервера, к которому следует направить соединение; он не учитывает потребление памяти или процессора. В третьих, при использовании совместно с Каталогом Сеансов, NLB требует, чтобы адреса IP терминальных серверов должны быть видимыми клиенту. И NLB ограничен 32 узлами в кластере.

В NLB Manager, Microsoft называет группу серверов, связанных распределением нагрузки, кластером. Не путайте этот термин с настоящим кластером, который позволяет серверам совместно использовать процессы и запоминающие устройства как единый сервер. Во многих документах о распределении нагрузки, включая статьи Microsoft, группы серверов с распределением нагрузки называются фермами. Тем не менее, в этой книге я буду использовать термин "кластер", чтобы не противоречить NLB Manager.

Настройка NLB

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

  • Адрес VIP, который вы выбрали для кластера
  • Уникальные адреса IP каждого из серверов фермы
  • Алиас DNS, который вы хотите использовать для кластера
  • Сетевой протокол и порт, который вы хотите использовать для распределения нагрузки (для RDP это TCP и порт 3389).
  • Доменная учетная запись с правами администратора ко всем серверам кластера, или локальные учетные записи администраторов каждого сервера

Собрав эту информацию, вы должны запустить NLB Manager. Вы можете это сделать с любой системы WS2K3 или с клиента Windows XP, на котором установлен WS2K3 Administrative Tools.

NLB Manager позволяет создавать, конфигурировать и управлять кластерами NLB в сети. Для создания нового кластера выберите New из меню Cluster.

В окне Cluster Parameters введите адрес VIP и имя DNS нового кластера. Если вы планируете администрировать кластер с помощью NLB Manager, то не нужно разрешать удаленное управление или устанавливать пароль. NLB Manager использует Windows Management Interface (WMI), т.е. использует учетную запись пользователя.

Вы также можете выбрать, какой режим должна использовать межсерверная коммуникация - однонаправленный (unicast) или широковещательный (multicast). Если ваши терминальные серверы имеют по одному сетевому адаптеру, и ваша сеть поддерживает мультикастинг в подсети, вы должны разрешить широковещательный режим (multicast). Это позволит вам управлять кластером с помощью NLB Manager с любого сервера кластера. Заполнив параметры кластера, щелкните Next.

Дополнительную информацию см. статью “Technical Overview of Windows Server 2003 Clustering Services”

 

Следующее окно NLB Manager предлагает ввести дополнительные адреса IP, используемые в кластере. Эта информация обычно используется веб-серверами с распределением нагрузки, когда каждый сервер обслуживает несколько веб-сайтов, каждый из которых представлен уникальным адресом IP. Для терминальных серверов вы можете оставить это окно пустым и щелкнуть Next для вызова окна Port Rules.

Правила портов определяют, как должны обрабатываться соединения к VIP. По умолчанию весь траффик TCP и UDP равномерно распределяется по узлам кластера. Для терминальных серверов вам необходимо балансировать только RDP, поэтому подсветите правило default и щелкните Remove для его удаления. Затем щелкните Add для вызова окна Add/Edit Port Rule.

В этом окне укажите диапазон портов с 3389 по 3389 и выберите протокол TCP. Эта конфигурация создаст распределение нагрузки только для протокола RDP. Ограничив правила только протоколом RDP, вы снизите нагрузку на службу NLB и на серверы, защитив их от ошибочных запросов, посылаемых на адрес VIP на другие порты.

Оставьте режим фильтрации по умолчанию (multiple host, single affinity), смысл остальных опций следующий:

  • Multiple host — Если выбрано, то соединение, выполняемое на указанный диапазон портов, будет распределяться среди нескольких узлов. В этом случае вы должны выбрать режим родственности (affinity). Родственность обеспечивает, что после того, как клиент будет направлен на указанный узел, клиент в течении сеанса будет продолжать направляться на тот же узел во всех коммуникациях.
    Опции родственности:
    • None - родственность не используется
    • Single - Родственность основывается на адресе IP клиента, балансировка выполняется на базе клиента
    • Class C - Родственность основана на подсети класса С клиентов. Когда один клиент устанавливает соединение к некоторому узлу, все соединения от той подсети будут направлены на тот же узел.
    • Single host - Соединения на указанынй диапазон портов будут направлены на один узел, а если этот узел недоступен - то на следующий узел, вычисляемый по номеру Handling Priority (приоритет обработки). Приоритет присваивается узлу при добавлении сервера в кластер.

Вы также можете запретить правило в этом окне. Это временно отключит разпределение нагрузки для указанного диапазона портов..

После настройки правил портов, щелкните Next для перехода к окну Connect. Введите в нем имя первого сервера, добавляемого к кластеру. NLB Manager установит соединение с этим сервером и выдаст список сконфигурированных сетевых адаптеров. Вы должны выбрать адаптер, на котором вы хотите принимать входящие соединения с VIP, и щелкнутьNext.

В последнем окне, Host Parameters, вы настраиваете конкретный сервер, выбранный для присоединения к кластеру. Здесь вы сначала должны установить номер приоритета, который одновременно используется как уникальный идентификатор узла. Вы можете изменить физический адрес IP сервера и маску подсети, а также установить начальное значение состояния службы распределения нагрузки после загрузки сервера.

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

Завершив добавление терминальных серверов в кластер, вы можете опробовать NLB, используя клиент Remote Desktop Connection, указав в нем адрес VIP или имя DNS кластера. Ваше соединение должно быть направлено на один из серверов кластера.

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

Другие балансировщики нагрузки

Хотя служба Microsoft NLB проста в настройке и администрировании, а также бесплатна во всех редакциях WS2K3, есть много причин присмотреться к балансировщикам нагрузки других производителей. Особенно если ваши серверы находятся в разных подсетях или вам необходимо поддерживать более 32 серверов.

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

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

Помимо балансировщиков нагрузки есть продукты, специально предназначенные для расширения возможностей Terminal Services. Эти продукты не только включают в себя средства распределение нагрузки, но и позволяют публиковать приложения, позволяя пользователям подключаться к приложениям, а не к рабочему столу. Лидерами в этой области являются Citrix MetaFrame (http://www.citrix.com) и New Moon Canaveral iQ (http://www.newmoon.com).

Каталог Сеансов (Session Directory)

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

Эти настройки хорошо работают в среде с одним сервером. При повторном подключении пользователя, Session Manager подключает его к существующему сеансу. Однако, в случае кластера с распределением нагрузки, Session Manager ничего не знает о сеансах на других серверах. Поэтому Microsoft ввела понятие Каталога Сеансов (Session Directory).

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

Настройка каталога сеансов

Чтобы получить преимущества каталога сеансов, все терминальные серверы в кластере должны иметь редакцию Enterprise или Datacenter. Session Directory может использовать любую редакцию WS2K3. Вы даже можете создать Session Directory на одном терминальном сервере в кластере, хотя это не рекомендуется, поскольку остановка этого сервера для осблуживания или установки ПО может затронуть весь кластер.

Для настройки Каталога Сеансов, начните с сервера, на котором будет храниться база данных сеансов. На этом сервере откройте Computer Management or Services для доступа к Terminal Services Session Directory. Откройте свойства службы, настройте ее на автоматический запуск и запустите ее.

При первом запуске службы Session Directory она создает новую локальную группу Session Directory Computers. Чтобы терминальные серверы информировали сервер каталога сеансов о своих сеансах или запрашивали каталог сеансов с других серверов, терминальный сервер должен быть членом этой группы. Вы можете добавить в эту группу индивидуальные компьютеры в кластере или создать доменную группу, содержащую терминальные серверы, и добавить эту группу в Session Directory Computers.

После того, как вы создали сервер каталога сеансов, необходимо настроить терминальные серверы. Вы можете использовать либо утилиту Terminal Services Configuration, либо редактор групповых политик. В редакциях WS2K3 Enterprise или Datacenter, узел Server Settings в Terminal Services Configuration имеет дополнительную опцию - Session Directory.

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

При использовании Microsoft NLB вы должны выбрать редирект адреса IP, поскольку NLB не поддерживает маркеры маршрутизации.

Если вы решили использовать Terminal Services Configuration, то вам необходимо сделать эти настройки вручную на всех терминальных серверах. Если вы используете Active Directory, то используйте групповые политики. Для этого создайте или отредактируйте GPO и примените их ко всем серверам кластера. Затем откройте редактор групповых политик, найдите Computer Configuration, Administrative Templates, Windows Components, Terminal Services, Session Directory. Там содержатся все настройки, доступные в Terminal Services Configuration. Разрешите все четыре параметра и введите необходимую информацию. При следующем обновлении политик все серверы кластера будут использовать каталог сеансов.

При использовании Session Directory, сервер, содержащий базу данных, становится критическим для функционирования терминальных серверов. Вы можете использовать кластеры Windows, чтобы сделать каталог сеансов отказоустойчивым. Microsoft написала инструкции для этого в статье “Session Directory and Load Balancing Using Terminal Server”

Как работает каталог сеансов

Здесь приведен пример работы каталога сеансов. Утром пользователь Joe User использует клиента Remote Desktop Connection для подключения к TSCluster.Domain.Com. Служба NLB направляет это соединение на сервер TServer02, наименее загруженный сервер в это время. Джо регистрируется на TServer02, и поскольку он еще не имеет существующего сеанса на TServer02, сервер запрашивает службу Session Directory на предмет существующих сеансов, принадлежащих Joe User на любом сервере в кластере. Joe не имеет никаких других сеансов, поэтому TServer02 принимает соединение и Джо начинает работу.

В 3:00, Джо решает поехать домой и продолжить работу оттуда. Он уже напечатал половину документа и открыл три окна веб-браузера со справочным материалом, поэтому от отключился, но не завершил сеанс, чтобы продолжить работу с того места, где он ее оставил. Когда Джо отключается от сеанса, TServer02 информирует сервер каталога сеансов о разъединенном сеансе. Сервер каталога сеансов создает запись в своей базе данных, включая имя пользователя и домен для Джо, имя сервера, время создания и отключения сеанса, а также разрешение и глубину цвета сеанса.

Придя домой, Joe устанавливает соединение VPN с корпоративной сетью. Он запускает на своем домашнем компьютере клиента Remote Desktop Connection и указывает имя TSCluster.Domain.Com. Служба NLB направляет соединение на уникальный адрес IP сервера с наименьшим числом соединений - на этот раз это TServer01. Джо вводит свое имя и пароль для TServer01.

TServer01 сначала проверяет свои разъединенные сеансы Джо. Если таковых не найдено, он запрашивает базу данных каталога сеансов. База данных находит сеанс Джо на сервере TServer02 и сообщает клиенту Remote Desktop Connection адрес IP сервера TServer02, а также шифрованные имя и пароль Джо. Клиент Remote Desktop Connection автоматически подключается к TServer02 и посылает учетные данные. TServer02 находит существующий сеанс Джо и подключает к нему Джо, который начинает продолжать работу над своим документом.

Глава 2
Администрирование терминального сервера

Содержание Глава 4
Администрирование терминального сервера

главная > операционные системы > Windows > Полное руководство по терминальным службам Windows Server > Глава 3. Каталог сеансов и распределение нагрузки

Главная > Операционные системы > Windows > Windows Server 2003