Глава 2: Основные концепции серверных вычислений с MetaFrame XP

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

Логическая структура сети MetaFrame XP: Фермы, Зоны и IMA

Если ваша сеть содержит единственный терминальный сервер, легко можно понять, как клиенты находят приложения: клиенты соединяются с терминальным сервером и используют приложения, установленные на этом сервере. Если сервер не имеет достаточного количества лицензий для Terminal Services или MetaFrame для всех клиентов, клиенты не смогут подключиться к серверу. На сервере должен быть установлены драйверы для любых клиентских принтеров, которые будут использоваться в терминальных сеансах. Если вы хотите управлять сервером, вам нужно либо зарегистрироваться в консоли сервера, либо запустить Citrix Management Console, которую мы обсуждали в Главе 1.

Но люди не всегда используют MetaFrame на единственном сервере. Если ваша сеть содержит более одного сервера MetaFrame, то как клиенты узнают, который из них использовать? Можете ли вы гарантировать, что клиентские машины смогут используют сервер MetaFrame, который доступен через высокоскоростную сеть, по более медленным соединениям WAN? Сможете ли вы управлять всеми серверами MetaFrame из единого места, даже если некоторые серверы расположены в другом здании? Что случится, если один сервер потеряет связь с другими серверами?

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

Почему MetaFrame XP содержит новую организационную модель

Реорганизация ферм и введения зон не является только косметическими нововведениями. Целью этого является обеспечение более эффективной коммуникации между серверами MetaFrame.

MetaFrame 1.8 для поддержки данных о серверах и опубликованых приложениях в ферме использовал ICA Browser. Эта служба состояла из трех частей: главный броузер, подчиненные броузеры и клиентские системы. Все серверы MetaFrame выполняли службу ICA Browser; броузер использовал направленные пакеты (UDP для сетей TCP/IP) для связи со службами ICA Browser, выполнявшихся на других серверах MetaFrame. Главный броузер поддерживал список обзора, т.е. центральный банк сообщений для фермы. Главный броузер получал его информацию из информации, посылаемой ему подчиненными броузерами фермы, как показано на рисунке:

Пока все серверы, которые должны связываться, находятся в одной подсети, все прекрасно работает. Трудность возникает тогда, когда одни серверы MetaFrame должны связаться с другими серверами, находящимися в другой подсети. Как отмечено ранее, броузеры MetaFrame связываются через UDP, широковещательный протокол без установления соединения. Термин "без установления соединения" UDP означает, что сообщения, посланные с использованием этого протокола, не подтверждаются. Особенно через маршрутизатор - UDP то работает, то нет. (Для работы браузеров вы должны или установить шлюз ICA или открыть на маршрутизаторе порт 1604)

Со вводом FR1 для MetaFrame 1.8 и NFuse отпала необходимость открывать на межсетевом экране порт 1604.

Существуют обходные пути, чтобы сделать более надежной работу браузеров в нескольких подсетях, включая редактирование файла .ICA для указания адреса IP сервера, но эти решения далеки от совершенства. UDP имеет и другой недостаток: он является широковещательным сетевым протоколом, т.е. достаточно "шумным". Сообщение получает один сервер, а слышат его все. Наконец, каждая подсеть в сети MetaFrame должна иметь собственную ферму, которая усложняет управление серверами и опубликованными приложениями, потому что вы не всегда можете поместить все доступные ресурсы в одном месте.

Чтобы улучшить работу своего ПО в больших и распределенных сетях, Citrix в MetaFrame XP изменил способ, которым серверы MetaFrame общаются друг с другом. Во-первых, при работе в "родном" режиме, серверы MetaFrame XP обычно используют для связи службу IMA, ориентированной на использование TCP/IP. Использование TCP/IP не только уменьшает трафик, обеспечивая прямую связь между серверами - связь между серверами-членами и коллекторами данных или между коллекторами данных в различных зонах является двухточечной, но также использует подтверждения приема пакетов. (Я перейду к коллекторам данных буквально через минуту, а пока важно отметить то, что трафик IMA является прямым, в отличии от UDP). Во вторых, серверы MetaFrame больше не полагаются на главный броузер своей фермы для получения информации о других серверах MetaFrame. Вместо этого они полагаются на коллектор данных для своей зоны. Коллектор данных - это функциональный эквивалент главного броузера MetaFrame 1.8. В третьих, из-за введения зон и их коллекторов данных, фермы MetaFrame могут теперь охватывать несколько подсетей и даже разные сети, значительно упрощая управление серверами и пользователями. Конечный результат работает подобно следующей иллюстрации. Ферма, расположенная в отдельном месте, может иметь единственную зону, а широко распределенная ферма может иметь несколько зон, поскольку это сокращает траффик по медленным каналам связи


Как видно, сетевая архитектура MetaFrame XP включает фермы, зоны, коллекторы данных и серверы-члены. В следующих разделах вы увидите, как разные части взаимодействуют друг с другом и что именно они делают..

Хранение данных сервера в MetaFrame XP

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

Использование Хранилища данных

Постоянная информация всей фермы (информация об публикуемых приложениях, доступных серверах, уполномоченных администраторах Citrix, доверительных отношениях, доступных лицензиях) хранится на коллекторах данных в хранилище данных. Для этого используется некоторая база данных (Oracle, Microsoft SQL Server, Access), но эта база данных недоступна для запросов со стороны клиентов базы данных; вы не можете менять или запрашивать информацию из базы данных, не используя Citrix Management Console. Серверы-члены для чтения из хранилища данных используют службу IMA. Серверы пытаются соединяться с хранилищем данных при запуске, и периодически делают запросы ( по умолчанию с интервалом 10 минут), чтобы видеть любые сделанные изменения. При запуске Citrix Management Console, она подключается к службе IMA, чтобы обратиться к хранилищу данных фермы.

Способ получения серверами данных из хранилища зависит от того, как вы настроили сбор данных при установке MetaFrame. Я буду обсуждать логику независимо от способа сбора данных (см. Главу 3) и способа установки MetaFrame XP (см. Главу 4), а пока лишь скажу, что при установке программного обеспечения на первом сервере в зоне, у вас будет запрошено местоположение базы данных хранилища. Если вы выбираете опцию по умолчанию - базу данных Access, то этот сервер будет единственным сервером с прямым доступом к хранилищу данных; все остальные серверы в зоне должны будут делать запросы к службе IMA первого сервера. (Как я объясню чуть позже, первый сервер в зоне всегда является предпочтительным коллектором данных, если вы явно не сделаете коллектором другой сервер. Таким образом, этот сервер является логическим размещением хранилища данных.) Этот процесс запроса данных называют обращением к серверу в косвенном (непрямом) режиме. Однако, если вы используете для хранилища данных Microsoft SQL или Oracle, серверы-члены могут обращаться к хранилищу данных без помощи сервера-посредника, т.е. напрямую. Этот последний метод обращения к хранилищу данных называют прямым режимом. По меньшей мере один сервер всегда будет обращаться к хранилищу данных напрямую.

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

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

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

dsmaint failover имя_сервера

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

dsmaint failover server1

Что случается, когда само хранилище данных становится недоступным, или сервер с хранилищем останавливается на долгое время? Хороший вопрос. Ферма серверов не может полноценно функционировать без ее хранилища данных. Она продолжит работу в течение 48 часов, но никакие изменения конфигурации не вступят в силу, пока ее хранилище данных не вернется в рабочий режим.

Ферма серверов без централизованного хранилища данных представляет собой просто набор независимых серверов. Однако, сервер может фактически запуститься без подключения к хранилищу данных. Хотя все серверы в ферме будут пытаться сделать запрос к хранилищу данных, вы можете установить в реестре сервера опцию, которая определяет, должен ли сервер при загрузке устанавливать соединение с хранилищем. На сервере MetaFrame ищите в реестре ключ HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\Runtime и параметр PSRequired. Если его значение 1, то служба IMA не будет запущена, если сервер не сможет установить прямое или косвенное соединение с хранилищем данных. Если значение 0 (устанавливается после первого успешного запуска службы IMA), то служба IMA может запуститься, даже если сервер не может соединиться с хранилищем данных.

Не редактируйте значение PSRequired. Значение 1 не повысит надежность сервера; оно будет только препятствовать серверу функционировать в случае временной ситуации, когда сервер не может обратиться к хранилищу данных при загрузке (это может случится при одновременной перезагрузке всех серверов MetaFrame). Если вы редактируете это значение, то должны будете вручную запустить службу IMA после того, как хранилище данных станет доступным.

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

Использование Локального Кэша

Если сервер некоторое время не может соединиться с хранилищем данных, то откуда он берет свою информацию? Я уже говорил раньше, что информация фермы может находиться либо в хранилище данных (которое мы обсудили), либо в локальном кэше. Локальный кэш - это база данных Access, расположенная на каждом сервере-члене в папке %Program Files%\Citrix\Independent Management Architecture. Локальный кэш важен как резервная копия на тот случай, когда сервер-член временно теряет доступ к хранилищу данных, но он также полезен и в нормальных условиях - сервер-член может читать или записывать информацию в свой локальный кэш вместо того, чтобы обращаться к хранилищу данных всякий раз, когда ему что-то нужно. Кэш заполняется при запуске службы IMA во время загрузки сервера, а затем периодически (обычно с интервалом 10 минут; вы настроить это значение для улучшения производительности) собирает изменения в процессе работы сервера. Тем самым серверу не требуется обращаться к хранилищу постоянно.

Локальный кэш хранит в хранилище не всю информацию, а лишь ее подмножество, которое полезно для индивидуального сервера: основную информацию о всех серверах в ферме, об опубликованных приложениях в ферме и их свойствах, о доверительных отношениях между контроллерами доменов Windows (DC), о драйверах принтеров, а также любую локальную информацию о программном обеспечении, например, серийные номера. Таким образом, локальный кэш не заменяет хранилище данных. Он не содержит информацию о распределении нагрузки, и если сервер-член не может войти непосредственно в контакт с хранилищем данных в течение 48 часов, сервер-член прекратит принимать соединения, поскольку не сможет прочитать из хранилища информацию о лицензиях.. Локальный кэш удобен в случае кратковременной остановки хранилища данных, но для нормальной работы вам необходимо обеспечить надежную связь серверов-членов с хранилищем данных.

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

KB read = 275 + (5 x Srvs) + (0.5 x Apps) + (92 x PrintD)

В этой формуле
• Srvs = число серверов в ферме
• Apps = число опубликованных приложений в ферме
• PrintD = число драйверов печати, установленных на сервер-члене

Например, в ферме, которая содержит, 100 серверов, 25 публикуемых приложений и 20 принтеров, заполнение локального кэша требует посылки на сервер-член 2740KB данных (275 + 5х100 + 0.5х25 +92х20)). Чем больше ферма, тем больше изменений передается в локальный кэш. В маленьких фермах задержка запуска службы IMA невелика - всего несколько секунд. Но в больших фермах она весьма заметна и может достигать нескольких минут, особенно при одновременном запуске большого числа серверов, которые все сразу пытаются загрузить себе большие объемы данных.

Зоны, Хранилища данных и Коллекторы Данных

Если хранилище данных принадлежит ферме, целиком расположенной в единой высокоскоростной сети, то модифицирование серверов-членов в этой ферме не представляет больших проблем. Однако, MetaFrame XP спроектирован для поддержки ферм, которые могут распространяться на несколько зданий, городов и даже потенциально на несколько стран. Если ферма сильно рассредоточена, заполнение хранилища данных будет либо использовать большую полосу пропускания, либо хранилище данных будет содержать устаревшие данные (вероятно, оба варианта сразу). Чтобы поддерживать такие большие фермы, MetaFrame XP вводит понятие зон. Зоны являются физическими группировками серверов MetaFrame XP, каждая со своим собственным коллектором данных для сбора и распространения данных серверам-членам. Поскольку единственные компьютеры, совместно использующие информацию - это коллекторы данных, а они обмениваются информацией по протоколу TCP/IP, то становится возможным для нескольких серверов-членов иметь доступ к той же самой информации даже на относительно медленных соединениях. Вся информация, специфичная для зоны (например, используемые в настоящий момент приложения), совместно используется с остальной частью фермы посредством ее коллекторов данных. Вы должны делать резервную копию хранилища данных - если вы его потеряете, то потеряете всю информацию о всей ферме. Использование коллекторов данных межзональных коммуникаций делает географически распределенные фермы более практичными.

Ферма может иметь несколько зон, но всегда имеет минимум одну зону Когда вы устанавливаете MetaFrame, вам предлагается создать новую зону или присоединиться к существующей.

Обычно, зоны могут поддержать до 256 серверов-членов (хотя Citrix рекомендует, чтобы зона включала не более 100). Если ваша зона имеет более 256 серверов, вы можете изменить параметр в реестре на коллекторе данных: добавьте новый ключ HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\lMA\Runtime\MaxHostAddressCacheEntries, тип DWORD. Значение по умолчанию - 0x100 (256 десятичное). Вы можете его увеличить, но не больше 1-2, чем количество серверов, чтобы не тратить понапрасну ресурсы коллектора.

Использование коллекторов данных для сбора информации о ресурсах

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

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

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

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

Понимание выборов в MetaFrame XP

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

  1. Самый высокий основной номер версии (1 для сервера MetaFrame XP 1.0)
  2. Самый низкий ранг (от 1 (Самый предпочтительный) до 4 (не предпочтительный)
  3. Самый высокий идентификатор хоста (от 0 до 65 536, назначается при инсталляции случайным образом)

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

Если Вы планируете остановить текущий сервер коллектора данных, то можете заранее указать, чтобы коллектором стал другой наиболее подходящий сервер, сделав того "Most Preferred" перед выключением текущего коллектора данных. Эта установка доступна от закладке Zones диалогового окна свойств сервера в Citrix Management Console. Сервер MetaFrame редко бывает контроллером домена, и даже в самых малых сетях он никогда не должен им быть, поскольку двойная нагрузка обслуживания приложений и безпасность аутентификации в домене замедлят обе задачи до невозможности. Однако, в чрезвычайно маловероятном случае, если у вас есть сервер MetaFrame, который является также DC, то вы должны сделать тот сервер как "Not Preferrd" (не предпочтительный), чтобы избежать его перегрузки.

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

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

Обычно серверы MetaFrame XP не могут совместно использовать данные с серверами MetaFrame 1.8; эти два сервера, как отмечено ранее, используют различные протоколы связи и поэтому не могут "слышать" друг друга. Однако, вы можете запустить сервер MetaFrame в смешанном режиме. Позже мы обсудим, когда и как это делать. Пока просто примите к сведению, что работа в смешанном режиме меняет способ проведения выборов. Фермы в смешанном режиме должны проводить выборы не только коллекторов данных, но и главных броузеров для службы ICA Browser. Выборы главного броузера происходят в том случае, когда текущий главный броузер не в состоянии отвечать другому броузеру ICA или клиенту, при запуске сервера MetaFrame, или когда в одной и той же подсети обнаружены два главных броузера. В любом из этих случаев сервер вызывается на выборы широковещательной рассылкой критериев (в следующем порядке):

  1. Сервер, сконфигурированный как главный броузер
  2. Сервер с самым последним номером версии ICA Browser
  3. Сервер, который одновременно является контроллером домена (хотя это плохая идея)
  4. Сервер, который дольше всего работал
  5. Сервер, чье имя стоит раньше по алфавиту

Серверы MetaFrame XP сообщают свой номер версии ICA Browser как 20, поэтому в ферме смешанного режима сервер MetaFrame XP всегда будет главным броузером.

Фермы в MetaFrame XP

После знакомства с зонами легче понять, что такое фермы. Как и в MetaFrame 1.8, организационная модель MetaFrame XP основана на фермах. Как вы видели, данные собираются по зонам коллектором данных каждой зоны и распределяются в другие зоны в ферме. По умолчанию, отношение зон к фермам составляет 1:1, но вы можете создать в одной ферме несколько зон и управлять всеми серверами в этих зонах с единой Citrix Management Console.

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

Как работает ICA

Клиент ICA является частью MetaFrame, которая позволяет приложениям работать на сервере MetaFrame, а на машине клиента отображает и принимает ввод пользователя. ICA состоит из двух частей: клиента на компьютере, соединяющимся с сервером MetaFrame, и серверной частью непосредственно на сервере MetaFrame . Эти две части взаимосвязаны; клиентская часть посылает пользовательский ввод (щелчки мыши и нажатия клавиш) на сервер, а сервер посылает визуализированный вывод клиенту. Для знакомых с UNIX это немного похоже на работу X.11, используемого для удаленного доступа к компьютеру; но хотя возможности их сходные, эти два протокола работают по-разному.

В ICA устройством отображения является клиент, а главной вычислительной машиной - сервер. Когда пользователь посылает серверу свой ввод (по протоколу ICA, имеющего канал для приема ввода), сервер принимает этот ввод и формирует изображение для изменения экрана. Затем сервер передает эту графику (сжимая ее) клиенту по другому каналу ICA. Как только клиентская машина сформировала основное изображение экрана терминального сеанса, сервер начинает передавать только изменения этого экрана, экономя полосу пропускания. Поскольку единственная информация, передвавемая между клиентом и сервером, представляет собой обновления экрана, события мыши и ввод с клавиатуры, а не логику приложений, соединения ICA могут работать при низкой полосе пропускания. Соединения ICA не зависят от клиента, т.е. один и от же приемник ICA на стороне сервера может связываться с клиентами ICA на платформах DOS, Macintosh, UNIX, Linux, Win16 и Win32. Более того, один и тот же клиент ICA может связаться как с MetaFrame for Windows, так и с MetaFrame for UNIX. Логика работы приложения и логика отображения полностью отделены друг от друга.

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

ICA против X.11

Кроме конечного результата выполнения прикладных программ на одном компьютере и отображения их вывода на другом, X.11 не слишком отличается от ICA. В X.11 устройством отображения, которое берет на себя работу отрисовки окон и графики, представляющих пользовательский сеанс, является сервер. Сервер также должен быть настроен для работы с клиентом, выполняющим приложения - X.11 не всегда является коробочным решением. Кроме того, поскольку сервер нуждается во всей информации для формирования выходного изображения, между клиентом и сервером должен быть довольно хороший канал для передачи всей графической информации. До MetaFrame 1.8 FR1 и его поддержки high-color, одним из больших преимуществ X.11 перед ICA состояло в цветном разрешении.

Во-вторых, удаленный дисплей UNIX и ICA предназначены для разных вещей, и эти отличия дают ICA некоторые преимущества перед X.11 в низкоскоростных и мобильных соединениях. Компонент ICA, который идет с клиентом, почти не требует никакой настройки независимо от приложения, которое вы запускаете. Напротив, X.11 часто требуют существенной настройки для оптимальной работы. Протокол ICA прекрасно работает на низкоскоростных соединениях, а X.11 требует для работы слишком много полосы пропускания, чтобы использовать его через модем или WAN. ICA поддерживает теневые сеансы, т.е. один человек может видеть экран чужого терминального сеанса и даже взаимодействовать с ним. Наконец, ICA полностью изолирует компонент отображения вывода приложения от логики работы приложения, разрешая вам отключиться от работающего терминального сеанса, оставив данные в памяти, а позже повторно подключиться к этому сеансу даже с другого компьютера, и вернуться в то место, откуда ушли. Одна эта особенность сделала MetaFrame весьма популярным среди разработчиков, потому что это позволило им уходя с работы отключить сеанс, оставив файлы открытыми, а потом повторно подключиться к сеансу с домашнего компьютера, вернувшись точно в то место, где они оставили свою работу.

Лицензирование доступа к серверу MetaFrame

Когда вы используете MetaFrame вместе с Windows Terminal Services, лицензирование может усложниться, поскольку придется покупать лицензии для обоих продуктов, но схемы их лицензирования разные. В этом разделе я объясню, как они оба работают и сколько это будет для вас стоить (имея ввиду розничные цены).

Лицензирование Windows Terminal Services

Давайте сначала обсудим лицензирование Windows Terminal Services. Для использования любого терминального сервера Windows, независимо от протокола отображения, используемого для соединения с этим сервером, компьютеру необходимо две лицензии - Лицензия на клиента (Client Access License, CAL) и Лицензия на доступ к терминальным службам (Terminal Services Client Access Licenses,TSCAL). Это очень важный момент. Многие думают, что использование MetaFrame означает, что вы должны заплатить только за лицензии MetaFrame, но это не совсем так. (Это неверное представление будет продолжаться недолго; терминальный сервер Windows через некоторое время прекратит принимать соединения , если вы не установите сервер лицензирования и лицензии). Кроме того, для терминальных служб Windows лицензирование осуществлятся "per-seat" (по месту), а не по подключениям или пользователям. Т.е. на каждой машине, которая будет соединяться с сервером MetaFrame, необходимо наличие отдельной TSCAL. Другие модели лицензирования не применимы для доступа к терминальному серверу Windows.

Лицензии TSCAL предназначены для входа в систему под именованными учетными записями пользователей в домене и выпускаются "на место" (per-seat). TSCAL продаются в розницу пакетами по 5 и 20 штук. Для Win2K розничная стоимость пакета из 5 лицензий составляет 749$, а обновление с WTS - 349$. Способ приобретения TSCAL определяет цену, которую вы за них заплатите. Если вы покупаете розничную лицензию, то покупаете Microsoft License Pack (MLP). MLP для TSCAL в Win2K включает в себя код лицензии и алфавитно-цифровой код из 25 символов, определяющий тип лицензии и количество (поэтому вы не сможете прикинуться, что у вас 20 лицензий, хотя вы купили всего 5). Вы можете установить MLP только один раз. Те, кто получает свои приложения через Microsoft Open License, могут купить заданное пользователем количество лицензий, после чего Microsoft выдаст Open License Authorization (разрешение на использование) и предоставит номера лицензий. Вы можете устанавливать такие лицензии любое число раз. Для больших организаций удобно соглашение Enterprise Agreement; оно аналогично предыдущему за исключением того, что пользователь вместо номеров Open License предоставляет свой номер Enrollment Agreement (регистрационный номер).

Win2K Terminal Services имеют дополнительный тип лицензии: Лицензия на соединение через Internet (Internet Connection License, ICL). Не беспокойтесь по поводу ICL. Эти лицензии, доступные только избранным клиентам Microsoft, разрешают до 200 одновременных анонимных соединений через Internet, не давая терминальному серверу использовать TSCAL. Поскольку эти лицензии могут испольовать только анонимные учетные записи при соединении с терминальным сервером через Internet, они бесполезны, если только вы не собираетесь предоставлять доступ к приложениям через Internet. Таким образом, я сконцентрируюсь здесь только на TSCAL.

Некоторые утверждают, что компьютеры Win2K Professional не нуждаются в TSCAL или идут с собственным TSCAL. Это не совсем так. Win2K Pro способен вытягивать лицензии из неограниченного пула на сервере лицензий Win2K Terminal Services, поэтому любая машина Win2K Pro, подключающаяся к терминалам Win2K, не расходует лицензии из установленных пакетов лицензий. Однако, вам все равно необходим сервер лицензий для использования Win2K TSCAL. Без сервера лицензирования, с помощью которого получаются неограниченные лицензии, клиенты Win2K Pro будут использовать временные лицензии, срок действия которых в конечном счете истечет.

Независимо от того, могут ли люди, соединяющиеся с терминальным сервером Win2K, использовать встроенные лицензии, или должны извлекать их из обычного пула лицензий, вы должны установить сервер лицензирования терминальных служб (Terminal Server Licensing). Выбор машины для сервера лицензий будет зависеть от конфигурации вашей сети. Если вы используете домены Win2K, сервер лицензии должен находиться на контроллере домена (DC), чтобы сервер лицензирования мог связаться с другими DC. Если ваша сеть организована как рабочая группа или домен NT, сервер лицензии может находиться на сервере-члене. Главное, в домене Win2K сервер лицензирования никогда не должен быть терминальным сервером, потому что и DC, и Terminal Services потребляют слишком много ресурсов, чтобы эффективно выполнять обе задачи одновременно. Однако, в рабочей группе или домене NT терминальный сервер может быть одновременно сервером лицензирования..

Что происходит, если вы не установили сервер лицензирования? Будет ли это препятствовать использованию терминального сервера? Не вполне. В этом случае будут выдаваться временные лицензии. Если клиентская машина без TSCAL пытается соединяться с терминальным сервером, а сервер лицензирования недоступен или не имеет установленных пакетов лицензий, терминальный сервер выдаст этой клиентской машине временную лицензию. Эта временная лицензия истечет через 90 дней, и машина больше не сможет соединиться с терминальным сервером.

Установка заплаты лицензирование для Win2K

Если вы используете Win2K Terminal Services, установите заплату Q287687 на все ваши серверы лицензирования и терминальные серверы. Эта заплата решает две проблемы с лицензированием терминального сервера Windows. Во-первых, после установки этой заплаты клиенты получат лицензию только после успешной регистрации на терминальном сервере, а не после установления соединения и появления экрана регистрации в домене. Во-вторых, заплата позволит неиспользованным лицензиям через некоторое время вернуться в общий пул доступных лицензий. Обратите внимание, что эти изменения касаются только тех лицензий, которые выпущены после применения заплаты.

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

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

Linux также противоречив в способе использования TSCAL. Говорят, что некоторые дистрибутивы Linux берут лицензии из неограниченного пула, как будто они являются рабочими станциями Win2K Pro. Я также видел машины Linux (Red Hat в данном случае), которым было выдано по две лицензии на каждую машину: одна для имени машины прописными буквами, а вторая - для имени машины строчными буквами.

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

Заплата от Microsoft не позволяет вам лично вернуть TSCAL обратно в пул лицензий, но позволяет неиспользованным лицензиям самим туда вернуться, хотя и через некоторое время. Вместо того, чтобы постоянно назначать TSCAL клиентам, после применения заплаты ко всем терминальным серверам и серверам лицензирования, сервер лицензирования выдаст новым клиентам TSCAL с тайм-аутом (который случайно выбирается в интервале от 52 до 89 дней). При регистрации пользователя на терминальном сервере тот сообщает серверу лицензирования, что лицензия была подтверждена (т.е. используется кем-то, кому разрешено регистрироваться на терминальном сервере). Тогда TSCAL назначается на эту машину. Каждый раз, когда кто-то соединяется с терминальным сервером с этой машины, терминальный сервер проверяет дату истечения срока хранения TSCAL. Если дата истечения срока хранения меньше 7 дней, терминальный сервер обновляет назначение TSCAL на машину еще на 52 - 89 дней. Если клиентская машина не регистрируется на терминальном сервере до истечения срока действия ее TSCAL, то эта TSCAL возвращается в пул доступных лицензий. Хотя это не делает службу лицензирования терминальных служб Windows совершенной, возможность возвращать лицензии (и выдавать лицензии только уполномоченным на это лицам) - большой шаг в правильном направлении.

Лицензия на подключение (connection license) - это лицензия для соединений Клиента ICA с серверами MetaFrame XP. Ферма серверов должна иметь лицензию на подключение - по одной лицензии на каждое соединение ICA с серверами MetaFrame XP в ферме. Каждая лицензия на продукт (product license) MetaFrame XP обеспечивает одну льготную (бесплатную) лицензию на подключение для администратора, чтобы позволить ему подключиться к консоли. Льготная лицензия (grace license) не дает серверу сообщать об ошибках лицензирования, если вы не установили никаких лицензий на подключение. Серийные номера лицензий, которые вы получаете с MetaFrame XP, могут обеспечивать лицензии на подключение сами по себе или в комбинации с лицензией на продукт MetaFrame XP. Если вы добавляете больше пользователей, то можете купить дополнительные лицензии на подключение с тем количеством, которое нужно.

Номера лицензий MetaFrame XP

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

Каждый пакет программ Citrix включает код продукта (product code). Он представляет собой номер, что-то вроде OE11-0923 и находится под запечатанным клапаном конверта. (Открывая пакет, вы соглашаетесь с лицензионным соглашеним конечного пользователя.) Этот номер идентифицирует тип установленного MetaFrame XP; различает розничную версию, оценочную, "не-для-продажи"; а также определяет лицензию на продукт, которую сервер должен взять из пула для функционирования продукта. Идентификация сервера кодом продукта ограничивает сервер приемом только типов лицензий, доступных для этого типа.Например, сервер MetaFrame XPa не может взять из пула лицензии для MetaFrame XPe, а оценочная копия MetaFrame XP должна брать из пула только оценочные лицензии на соединения.

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

Серийный номер продукта находится под тем же запечатанным откидным клапаном, что и код продукта. Серийный номер представляет купленные вами лицензии (в отличие от кода продукта, который представляет тип лицензий). Серийный номер сервера представляет собой строку из 25 символов, собранных в 5 групп по 5 символов в каждой. Чтобы лицензировать MetaFrame XP и другие продукты Citrix на базе EVIA, вы используете номер лицензии, который получается из каждого серийного номера, который вы вводите в ферму серверов. Citrix Management Console отображает номер каждой лицензии. Этот номер состоит из оригинального серийного номера плюс дополнительные символы; эти дополнительные символы называются машинным кодом.

Миграция лицензий на MetaFrame XP

А если у вас есть лицензии для предыдущих версий MetaFrame? Нужно ли забыть про них и ставить новые? К счастью, нет. Хотя MetaFrame XP не может использовать лицензии более ранних версий MetaFrame и WinFrame, вы можете купить лицензию миграции (migration license) для обновления этих лицензий до MetaFrame XP. Вводите лицензии обновления таким же образом, как и обычные лицензии MetaFrame XP - во время установки или в Citrix Management Console. Если вы устанавливаете MetaFrame XP на сервере, уже выполняющим предыдущую версию MetaFrame, программа установки может автоматически мигрировать активизированные лицензии. Если вы переформатировали жесткий диск перед установкой MetaFrame XP, то должны сначала вернуть первоначальные номера лицензий и активировать их. В главе 4 мы поговорим о том, как модернизировать MetaFrame 1.8 до MetaFrame XP.

Резюме

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

Глава 1: Введение в сервер приложений Citrix MetaFrame XP Содержание Глава 3: Планирование Развертывания MetaFrame