Thursday, November 23rd, 2017

Основные понятия о среде Терминального сервера

Published on Февраль 19, 2009 by   ·   Комментариев нет

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

Вступление

Что же так осложняет процесс администрирования Терминального сервера? Большинство подобных убеждений основываются на историях, в которых в среде Терминального сервера используются непригодные приложения или принтеры. В таких ситуациях это может привести к ошибке приложений, неисправности работы принтеров, или же — к печально известному «голубому экрану смерти» (BSOD).

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

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

Правило Номер 1: Автоматизация установки и конфигурации

Почему серверы должны быть идентичными на 100%? Если я покупаю новый сервер, то практически невозможно купить еще один абсолютно такой же! Говоря об идентичности серверов, мы не имеем в виду идентичность аппаратных частей, а подразумеваем идентичность установки и конфигурирования всех компонентов программного обеспечения на указанных серверах.

Как Вы можете удостовериться в идентичности всех серверов в области программного обеспечения? Существует только один выход: полная автоматизация построения и конфигурирования сервера. Сервер должен быть создан и сконфигурирован без какого-либо ручного вмешательства в процесс.

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

Если Вы используете Citrix Presentation Server (или другой продукт SBC), то данный инструмент также должен быть установлен по умолчанию. Я коснусь вопроса об автоматической установке Citrix в другой статье на данном сайте несколько позже.

Установка другого программного обеспечения (инструменты мониторинга, антивирусы) должна быть также автоматизирована. Это сравнимо с использованием приложений, которые будут опубликованы для пользователей. Наилучший способ использования также будет описан в другой статье в самом скором времени.

Хронология установки приложения

Только одна вещь касательно приложений важна в этой статье, и ее следует описать для понимания следующих правил.

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

Таким образом, если Вы устанавливаете новое приложение на свой существующий Терминальный сервер, то Вы не сможете узнать, какие файлы, используемые другими приложениями, будут переписаны. Таким образом, некоторые из функционирующих приложений окажутся более нерабочими, либо произойдут серьезные изменения в их поведении. Давайте поподробнее остановимся на данных изменениях! Если мы по-разному установим приложения на различных машинах, то и поведение приложений должно быть (и чаще всего — будет) различным. Это как раз и объясняет, почему большинство ошибок оказываются невоспроизводимыми. Ошибки существуют только на одной машине, поскольку на других процесс установки был различным. Для предотвращения подобных различий в поведении все приложения должны быть установлены одним и тем же способом на всех компьютерах. Порядок установки должен быть протестирован, чтобы Вы были уверены в правильности функционирования приложений и идентичности их работы. В SBC это называется «хронологией установки приложения». Как уже говорилось выше, лучший метод для достижений данной цели — использование пакетов автоматической установки для указанных приложений.

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

Разделение установки и конфигурирования

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

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

Разделение пользователя и машины

Гораздо более важным выглядит разделение пользователя и машины. Каждое приложение состоит из части пользователя и машинной части. Машинная часть обычно устанавливается на один из локальных дисков сервера и определяется ключом HKEY_LOCAL_MACHINE в реестре и/или корневом каталоге. Следующие параметры характеризуют машинную часть: данные неизменны, большая восприимчивость к ошибкам, 20% всех изменений соотносятся с машинной частью без необходимости перезагрузки системы. Управление машинной частью приложение осуществляется через Политику машины, автоматизированную установку и список параметров конфигурации (к примеру, лист загрузки и окончания работы).

Пользовательская часть приложения располагается в профайлах пользователей, их домашних директориях, в реестре на HKEY_CURRENT_USER. Данные являются постоянно меняющимися, малая соотносимость с ошибками, 80% всех изменений происходят в данной части (они требуют перезагрузки системы). Управление пользовательской частью осуществляется посредством Политики пользователей, а также соответствующего программного обеспечения и инструментов.

Ключ затенения

Если приложение необходимо установить на Терминал, то это обычно производится через пункт Установка и удаление программ, либо посредством внесения изменений в команды установки. Так, вы приведете Терминальный сервер в режим установки. Когда приложение в режиме установки записывает ключ реестра к HKEY_CURRENT_USER, то Microsoft также вносит данный ключ в следующую директорию: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software. Данные, внесенные в этот ключ, называющийся также «Ключом затенения», применяются к пользователю, когда последний подключается к Терминальному серверу, если никакие ключи с временной меткой не находятся в его учетной записи. Из-за проверки временной метки, Вы можете стать свидетелем необычного поведения при добавлении нового сервера в уже существующую инфраструктуру. Это случается из-за того, что изменения в ключе затенения имеют временную метку, соотносимую со временем установки ключа. Пользователи могут располагать различными параметрами установки своих профилей, но с более старыми временными метками. При подключении таких «старых» пользователей к новому серверу установки Ключа затенения вносятся в их профили, поскольку дата создания ключа позже даты создания их профиля, что логически неприемлемо. Microsoft определяет характер данного поведения в Статья основополагающих познаний 297379. В данной статье предполагается три решения.

  1. Использовать Sysprep и новые «видовые» серверы. Так, новые серверы «унаследуют» временные метки реестра от старых серверов.
  2. Указать путь к HKEY_CURRENT_USER\Software в Режиме установки с системными часами, установленными ранее.
  3. Удалить Теневые ключи, которые могут переписать преференции пользователей

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

Использование среды DTAP

DTAP обозначает Развитие, Тестирование, Принятие и Исполнение (Develop, Test, Accept, Produce). Наша цель—гарантирование 100% идентичности серверов при дополнительных установках, поэтому приложения должны быть хорошо протестированы. Для этого необходимо несколько сред. Иногда среда развития и Среда проверки могут быть соединены воедино для Терминального сервера. В зависимости от общей конструкции серверной инфраструктуры, некоторые дополнительные механизмы (файловая системы, механизм обмена, функции базы данных) могут также быть объединены, однако лучше попробовать их разделение по меньшей мере на две части. Одна — для Развития и Тестирования, а другая — для Принятия и Исполнения.

Профили и драйвера принтеров

Последние два правила — ограничение использования профилей и драйверов принтеров. Несколько статей на MSTerminalServices.org уже рассказывают об этом: «Терминальный сервер и вызов профиля» и «Может ли программное обеспечение решить проблемы принтеров на Терминальных серверах?» Поэтому не стоит вдаваться в подробности данной темы в настоящей статье.

Заключение

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

www.windowsnetworking.com


Смотрите также:

Tags:

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]