Когда я впервые услышал о сделке Microsoft и Citrix, предусматривающей лицензирование Citrix WinFrame и создание Windows NT Server 4.0, Terminal Server Edition, мне было непонятно, как новый продукт изменит мир NT. Новая ОС обещала объединить лучшие многопользовательские возможности WinFrame с функциями и интерфейсом NT 4.0. Меня также интересовало, когда я смогу протестировать работу Terminal Server в реальных условиях и что же этот программный продукт действительно способен делать. Недавно мне представилась такая возможность, когда один из моих заказчиков попал в затруднительное положение. Читайте дальше, и я расскажу вам о том, как Terminal Server помог решить серьезную проблему.

Заказчик — инженерно-строительная фирма недавно обратилась к моей компании с просьбой помочь с планированием и развертыванием распределенной сети, связывающей офисы филиалов с ее центральным отделением. В каждом из офисов филиалов работает примерно по 10 человек, а в центральном офисе — около 30. Решение, которое мы развернули, представляло собой выделенные каналы frame relay на 128 Кбит/с между филиалом и штаб-квартирой фирмы и канал доступа в Internet на 384 Кбит/с для центрального офиса.

Я предполагал реализовать новые соединения к удаленным офисам для того, чтобы предоставить доступ к ресурсам центрального узла, в том числе к почтовой системе Microsoft Exchange Server и службам файлов и печати. Кроме того, пользователи удаленных офисов использовали proxy-сервер центрального офиса для доступа в Internet со схемой IP-адресации, согласующейся с центральным офисом. Эта конфигурация предусматривает одну точку доступа в Internet, обеспечивая возможность централизованно управлять доступом в Internet и уменьшить сложности конфигурирования. На рисунке представлена архитектура сети заказчика.

После организации каналов frame relay я установил NT-сервер в каждом из удаленных офисов для выполнения локальной аутентификации и централизованных сервисов файлов и печати. Когда офисы начали, как и предполагалось, работать в новой среде глобальной сети, я подумал о том, что все нужды компании наконец удовлетворены. Однако примерно через неделю в моем кабинете раздался телефонный звонок, и расстроенный представитель заказчика сообщил, что все изменилось. Выяснилось, что во время обсуждения плана реализации системы представители заказчика забыли упомянуть об очень важной детали. Пользователям в удаленных офисах был нужен доступ к бухгалтерскому приложению, которое использует базу данных Microsoft Access, размещенную в центральном офисе. Вскоре после моего отъезда из компании ее специалисты по информационным системам сконфигурировали доступ так, что пользователи в удаленных офисах смогли обращаться к бухгалтерскому приложению.

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

Существовало два возможных пути: настроить систему так, чтобы она могла справляться с имеющимся трафиком, или сократить трафик до приемлемого уровня. Одно из решение предусматривало увеличение пропускной способности портов каналов frame relay для того, чтобы они смогли пропускать дополнительный трафик. Решение, которое со своей стороны предлагал заказчик, предусматривало модернизацию бухгалтерской системы до новой версии на базе SQL Server (эта модернизация уже рассматривалась руководством компании). Вместе с представителями заказчика мы обсудили возможное объединение двух этих предложений.

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

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

Я предложил заказчику приобрести новый сервер для работы Terminal Server в центральном офисе и установить в филиалах клиентское программное обеспечение Terminal Server на настольных системах, которым требовался доступ к бухгалтерскому приложению. Компания уже применяла коммутируемый доступ RAS через пулы модемов и PPTP, поэтому я рассчитывал воспользоваться этими соединениями для того, чтобы предоставить доступ Terminal Server на базе RAS.

Основным преимуществом этого решения была его расширяемость. Поскольку клиентам Terminal Server необходима определенная полоса пропускания, добавление приложений к клиенту Terminal Server незначительно увеличивает требуемую для клиентского сеанса пропускную способность. (Клиенты Terminal Server аналогичны приложениям удаленного управления, таким как pcANYWHERE32, Remotely Possible/32, которые в основном передают между клиентом и сервером только изменения изображения на экране и события, поступающие от клавиатуры.) Эти сеансы требуют практически постоянной полосы пропускания.

Хотя я разрабатывал схему использования Terminal Server для решения проблем доступа к бухгалтерскому приложению и базе данных, довольно быстро стали очевидны и другие преимущества Terminal Server. Для организации моего заказчика таковыми преимуществами решения в архитектуре тонкого клиента были следующие.

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

Возможность применять Terminal Server для дополнительных приложений центрального узла стала весьма популярной. После того как представители заказчика в полной мере осознали преимущества этого нового ресурса, их аппетит разгорелся. Заказчик захотел организовать через Terminal Server доступ к своему приложению базы данных для управления контактами (то есть к Symantec ACT!) и Microsoft Office 97. Таким образом, вместо обслуживания одного приложения система Terminal Server стала выполнять роль постоянного шлюза к основным корпоративным данным. В итоге, один раз купив необходимое программное и аппаратное обеспечения, компания смогла избежать ежемесячного и значительного роста затрат, которое предусматривало решение, направленное на увеличение пропускной способности. Если бы заказчик все время наращивал скорость сети, чтобы удовлетворить растущие требования приложений, в конечном счете он оказался бы в той же ситуации, с которой все началось. Благодаря Terminal Server заказчик может предоставить большее количество приложений клиентам Terminal Server, особо не беспокоясь о производительности глобальной сети, по крайней мере до тех пор, пока приложения не будут генерировать значительный трафик, связанной с экранными изображениями (например, браузеры и графические приложения). Еще одно преимущество Terminal Server состоит в том, что он позволяет значительно снизить общую стоимость владения, поскольку резко сокращается объем операций по установке и поддержке приложений. Неожиданным достоинством решения Terminal Server стала возможность использовать различное аппаратное обеспечение для настольных клиентских ПК. Заказчик хотел установить полнофункциональные персональные компьютеры в качестве большинства настольных рабочих станций, поскольку многие пользователи создавали чертежи и схемы с помощью AutoCAD, и им требовались машины, обладающие значительными локальными ресурсами. Но Terminal Server позволил предоставить маломощные и недорогие системы, такие как унаследованные ПК, рабочие станции в архитектуре тонкого клиента и устройства с Windows CE, сотрудникам, занимавшимся офисной работой, и другим служащим компании, которым не были нужны мощные персональные компьютеры.

После того как заказчик согласился на реализацию решения Terminal Server, дальше было нужно определить аппаратные требования для новой системы Terminal Server. Если вы анализируете возможность использования Terminal Server, советую для начала посетить Web-узел Microsoft Terminal Server. Я обнаружил здесь ряд полезных документов, посвященных развертыванию Terminal Server, в том числе материалы, касающиеся вопросов администрирования и планирования емкости. Самым полезным, пожалуй, был документ Windows NT Server 4.0, Terminal Server Edition Capacity Planning, расположенный по адресу http://www.microsoft.com/ntserver/terminalserver/deployment/capacplan/tscapacity.asp, и Deployment Guide, который можно найти по адресу http://www.microsoft.com/ntserver/terminalserver/deployment/map/tsdguidewp.asp. В таблице приведены выжимки из предлагаемых в этих материалах рекомендаций относительно планирования емкости для аппаратного обеспечения системы Terminal Server.

Минимальные требования, которые Microsoft предъявляет к различным продуктам (в том числе и к NT), в прошлом не раз меня подводили, поэтому я воспользовался рекомендациями производителей программного обеспечения относительно требований к аппаратуре, значительно их подправив. Я предпринял определенные шаги с тем, чтобы гарантировать адекватность сервера. Во-первых, я выбрал базовую серверную платформу так, чтобы она поддерживала серьезное масштабирование в том, что касается процессоров и памяти. Затем я увеличил цифры Microsoft на 15 — 20% (формула, которая себя уже не раз оправдала, будучи применена к указываемым производителями минимальным требованиям). Наконец, я протестировал производительность приложений на свободном от рабочей нагрузки сервере с Terminal Server. Этот тест был просто необходим, поскольку документация указывала рекомендации по планированию емкости, основываясь на весьма расплывчатой формулировке уровней использования клиентов (как указано в таблице): низкий (для пользователей, выполняющих конкретную задачу), средний (для администраторов) и высокий (для специалистов). По всей видимости, пользователи моего заказчика попадали в категорию между средним и высоким, но мне очень не хотелось делать неверные предположения.

После завершения теста я был уверен, что серверная конфигурация (сервер, рассчитанный на четыре процессора Pentium II Xeon, но пока имеющий два процессора Xeon с тактовой частотой 400 МГц и оперативной памятью емкостью 512 Мбайт) был способен выдержать нагрузку, на которую я рассчитывал. Вполне возможно, что уровень нагрузки на сервер может значительно вырасти, если предлагаемые им возможности будут популярны у пользователей. Однако я знал, что в случае необходимости без особого труда мог бы увеличить пропускную способность сервера.

Последний этап планирования емкости состоит в оценке уровня использования сети. Я хотел определить среднюю полосу пропускания для каждого сеанса клиента Terminal Server. Чтобы собрать необходимые данные в компании заказчика, я установил на сервере инструментарий Network Monitor и агент Network Monitor Agent, который добавил объект Network Segment в Performance Monitor. Затем с помощью Performance Monitor я смоделировал предполагаемый у заказчика уровень использования Terminal Server. Для этого мне потребовались два основных счетчика Network Segment, позволившие выполнить необходимые оценки: %Network utilization, который определяет долю всей полосы пропускания, используемую конкретным сетевым сегментом, и Total bytes received/second, который показывает количество полученных в секунду байтов в сегменте. После того как я получил эти данные, я был уверен, что канал глобальной сети удовлетворяет требованиям к емкости сети, предъявляемым моим заказчиком. Я был готов к продолжению.

Тест также показал, удовлетворяет ли протокол RDP, используемый в Terminal Server, требованиям среды заказчика как с точки зрения производительности, так и с административной. Перед тем как я начал напрямую работать с Terminal Server, я слышал из нескольких источников (в том числе и от менеджера по продуктам Terminal Server), что RDP намного медленнее и не столь функционален, как его конкурент — Independent Computing Architecture (ICA), используемый в MetaFrame компании Citrix. Фактически некоторые из моих собеседников прямо заявили, что они однозначно отказались от RDP в пользу MetaFrame и ICA.

ICA (который требует, чтобы вы приобрели и MetaFrame) — несомненно совершеннее, чем RDP, но добавление этой функциональности к вашей системе Terminal Server требует немалых усилий. Использовать ли продукты Citrix — это зависит только от ваших нужд. Если RDP удовлетворяет вашим требованиям к совместимости, производительности и администрированию, вам совершенно не нужно тратить дополнительные средства на MetaFrame. Но MetaFrame предлагает такие возможности, как поддержка дополнительных клиентов (например, клиентов на базе Web, Macintosh, UNIX и Windows 3.1); возможность для администраторов удаленно просматривать и управлять клиентскими сессиями Terminal Server; балансировка нагрузки на серверах; печать с локальных принтеров и определение соответствия томов; автоматическое обновление клиентов.

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

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

Я подумал, что поскольку Terminal Server — это по сути решение уровня мэйнфреймов, лицензированное программное обеспечение на системе Terminal Server было просто вопросом лицензирования системы Terminal Server (с помощью лицензий для каждого рабочего места Client Access License — CAL) и клиентских приложений. Однако в тот момент, когда это решение приобретал мой заказчик, ситуация была совсем иной. Когда я начал заниматься вопросами лицензирования, для Terminal Server не предусматривалась схема лицензирования, позволяющая работать нескольким пользователям одновременно. (Отметим, что MetaFrame поддерживает лицензии на клиенты ICA, допускающие работу нескольких пользователей одновременно.) Кроме того, каждому клиенту, получающему доступ к системе Terminal Server, необходима стандартная лицензия NT Server CAL или лицензия на NT Workstation 4.0.

Недавно Microsoft внесла серьезные изменения в схему лицензирования Terminal Server. Теперь Microsoft предлагает лицензии Terminal Server CAL по цене около 109 долл. (т. е. значительно дешевле, чем NT Workstation, которая стоит 319 долл.). Microsoft по-прежнему требует, чтобы пользователи приобретали дополнительно лицензию NT Server CAL, которая стоит около 40 долл., таким образом общая стоимость не превышает 150 долл. (а не 360 долл.).

Компания Microsoft также предлагает лицензию Terminal Server CAL для работы дома, которая стоит намного дешевле (примерно вдвое по сравнению со стандартной лицензией Terminal Server CAL), имея которую пользователи могут получать доступ к корпоративным серверам Terminal Server из дома. (Нужно подчеркнуть, что лицензия CAL для работы дома требует, чтобы у вас уже была стандартная лицензия Terminal Server CAL.)

Наконец, Microsoft добавила подключаемый модуль, который используется одновременно с Terminal Server, получивший название Internet Connector (стоимостью около 9995 долл.). Internet Connector способен поддерживать до 200 одновременно работающих пользователей Internet (например, потенциальных пользователей, просматривающих демонстрационный ролик по продукту, подключающихся к системе Terminal Server через Internet). Представители Microsoft признали правоту пользователей, жаловавшихся на сложность первоначальной схемы лицензирования, и предложили новую схему, которая не вызовет таких мучений у компаний, планирующих развернуть систему Terminal Server. (Более подробную информацию о лицензировании Terminal Server можно найти в материалах Understanding Terminal Server Licensing, расположенных по адресу http://www.microsoft.com/ntserver/terminalserver/exec/eomap/pricingdetails.asp.)

Я по достоинству оценил тот факт, что при установке Terminal Server у меня практически не возникло никаких проблем. Новые (или модифицированные) версии операционной системы Microsoft зачастую просто кишат ошибками, но в случае с Terminal Server ничего подобного не было. Очевидный процесс установки Terminal Server и относительная легкость, с которой мне удалось открыть и использовать обеспечивающий полную функциональность сеанс клиента и запустить приложения, меня приятно поразили.

Несмотря на общий успех, нельзя сказать, что процедура установки прошла абсолютно гладко. Фактически я столкнулся с несколькими проблемами, потребовавшими тщательной диагностики и восстановления после сбоя. Первая из этих проблем возникла, когда бухгалтерское приложение моего заказчика не смогло получить доступ к определенным файлам Terminal Server и ключам Registry, имеющим важное значение для операций этого приложения. Чтобы выяснить, в чем проблема, я воспользовался двумя утилитами набора инструментальных средств для NT: Regmon и Filemon, разработанными компанией Systems Internals.

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

Другие проблемы возникли после установки Terminal Server Zero Administration Kit. Эта программа работает как не интерактивный пакетный процесс, маскируя и защищая файлы, доступ к которым вы хотите закрыть, например к таким, как файлы операционной системы. Такой подход сокращает число задач, которые приходится решать администраторам, и увеличивает уровень защиты. Некоторым из серверных приложений «не понравился» тот факт, что файлы были скрыты, и они отказались работать. Чтобы удовлетворить требования приложений, мне пришлось ослабить некоторые из наиболее строгих ограничений в ACL, которые ZAK наложил на отдельные системные каталоги. Однако я воспользовался утилитами мониторинга компании Systems Internals с тем, чтобы внести небольшие изменения, и легко выяснил, с чем связаны проблемы.

Исходя из собственного опыта, я хочу дать несколько советов тем, кто решит развернуть систему Terminal Server. Во-первых, устанавливайте Terminal Server как автономный или как сервер — член домена, а не как PDC или BDC. Во многом как и Internet Information Server (IIS), система Terminal Server позволяет намного проще обеспечить защиту за счет применения локальной базы данных с учетными записями, управляющей доступом к ресурсам Terminal Server. Если вы назначите систему Terminal Server контроллером домена, единственная база данных, которая будет доступна серверу, — это база данных с учетными записями домена. Таким образом, вы не можете обойтись при регистрации только пользовательскими учетными записями клиентов системы Terminal Server для локальной машины, в этом случае вам придется применять доменные пользовательские учетные записи.

Есть и иные причины использовать Terminal Server как автономный сервер или как член домена. Это причины, связанные с производительностью, при такой конфигурации сервер будет освобожден от необходимости выполнять еще и обязанности контроллера домена, и сможет сконцентрироваться только на обслуживании терминалов. По этой причине я рекомендую минимизировать число служб, которые вы запускаете на системе Terminal Server. Если представляется возможным, перенесите такие службы, как WINS, IIS, DNS и DHCP, с системы Terminal Server и разместите их на других NT-серверах.

Наконец, если вы развертываете Terminal Server ZAK, предварительно убедитесь, что отдаете себе отчет, как именно ZAK влияет на конфигурацию. Лучше всего понять, каким образом ZAK изменит среду Terminal Server, — это сначала внимательно прочитать документацию, а затем протестировать ZAK на непроизводственном сервере, где работают приложения, используемые в организации. Кроме того, перед инсталляцией ZAK вам нужно сделать полную резервную копию системы Terminal Server, в том числе Registry. В некоторых случаях вам придется удалить атрибуты каталога ZAK и внести изменения в ACL для того, чтобы определенные приложения смогли корректно работать.

Для моего заказчика Terminal Server стал тем секретом, который позволил решить серьезную проблему. Учитывая, что этот продукт имеет низкую общую стоимость владения, требует очень простое администрирование и позволяет создавать гомогенную настольную среду на гетерогенном массиве клиентского аппаратного обеспечения, Terminal Server безусловно является продуктом, достойным вашего внимания. Кто знает? Возможно, и в вашей организации возникнет ситуация, когда пригодится Terminal Server.

Шон Дейли — сертифицированный инженер Microsoft и президент iNTellinet Solutions, консалтинговой компании, занимающейся вопросами сетей и системной интеграцией. Дейли ведет рубрику в журнале Windows NT Magazine и является автором книг Optimizing Windows NT (IDG Books) и Migrating to Windows NT 4.0 (29th Street Press). С ним можно связаться по адресу sean@ntsol.com.