Глава 3: Планирование Развертывания MetaFrame

В Главе 1 содержалось введение в MetaFrame XP, а в Главе 2 обсуждались некоторые ключевые концепции программного обеспечения. Подготавливая вас к обсуждению инсталляции MetaFrame XP в Главе 4, здесь мы обсудим вопросы планирования, которые вы должны решить для успешного развертывания MetaFrame. Какие аппаратные и программные средства вам необходимы для сервера MetaFrame XP и его приложений? Какие приложения вы можете запускать в общедоступной среде? Мы уже обсуждали фермы и зоны в Главе 2 - как вам следует организовать свои серверы MetaFrame, используя эту модель? И, наконец, многие будут переходить на MetaFrame XP с предыдущей версии, вероятно MetaFrame 1.8. Как мы уже говорили, MetaFrame 1.8 и MetaFrame XP использует разные протоколы связи. Как вы можете управлять обновлением гладко, без необходимости управления серверами в двух отдельных группах? (Или, может быть, лучше оставить двойное управление?) В этой главе, мы обратимся ко всем этим вопросам.

Аппаратные и программные требования для MetaFrame XP

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

Вы можете разбить требования для MetaFrame XP на три части: программное обеспечение для сервера MetaFrame, аппаратные средства, требуемые для поддержания этого программного обеспечения, и программное обеспечение и оборудование для выполнения Citrix Management Console (потому что консоль может работать на другом компьютере, отличном от сервера MetaFrame).

Планирование программной среды

При планировании сервера MetaFrame вы должны учитывать три вещи: поддержка MetaFrame и, возможно, NFuse; настройка среды сервера так, чтобы она не вызывала проблем в ферме; выбор базы данных для хранилища данных. Давайте сначала обсудим требования к операционной системе (ОС) для MetaFrame XP.

Требования для опеационной системы

MetaFrame XP может работать с любым семейством операционных систем Microsoft Windows, которые поддерживают терминальные службы, включая работы WTS с SP5 и позже, а также любой серверный продукт Windows 2000 (Win2K Server, Advanced Server или Datacenter Server) с терминальными службами, установленными в режиме Application Server. Datacenter Server должен иметь установленный SP1, но это требование не относится к другим продуктам Win2K Server. Terminal Services должны быть установлены в режиме Application Server. Если вы устанавливаете службу в режиме Remote Administration, то не сможете установить MetaFrame XP, и программа установки MetaFrame XP предложит переустановить Terminal Services. Поэтому MetaFrame нельзя установить на рабочую станцию Win2K Professional

В Windows XP Microsoft перенесла немного функционала терминальных служб на рабочую станцию в виде Remote Desktop. Remote Desktop позволяет вам запускать единственный удаленный сеанс на рабочей станции Windows XP, но ценой блокирования консоли. На форуме iForum 2001, Citrix представил продукт, который будет работать на Windows XP и дает возможность подключиться к Remote Desktop через ферму MetaFrame, вместо родного протокола RDP. Однако, этот продукт не превращает компьютер Windows XP в маленький терминальный сервер - он лишь обеспечивает более легкий способ соедининения с Remote Desktop.

Для использования NFuse с сервером MetaFrame XP, вам будет необходим Internet Information Services (IIS) 4.0 или более поздний, а также Java Virtual Machine (JVM), установленная с IIS. Это требование не должно сбить вас с толку - если вы не создали автоматическую установку, которая явно отключает службу, IIS на серверах Win2K всегда устанавливается по умолчанию .

Даже при том, что вы можете использовать MetaFrame XP с WTS, Citrix рекомендует использовать Win2K Terminal Services, а не WTS. Лучше следовать этой рекомендации, и вот почему. Во-первых, MetaFrame XP - система уровня предприятия и может извлекать выгоду от использования Active Directory. Хотя вы можете добавить поддержку AD в WTS, это не даст всего, например, WTS не может использовать принципальные имена пользователей (UPN).

В общих словах, UPN позволяет вам регистрироваться в домене (или, в нашем случае, подключаться к ферме или регистрироваться в Citrix Management Console), используя формат имени username@domainname.com. В схеме именования в домене NT 4.0 вы должны явно указать, в каком домене вы регистрируетесь. UPN предназначены для более сложной структуры AD, о которой я вкратце расскажу немного позже.

Сечас же важно обратить внимание, что WTS не поддерживает регистрацию в системе с использованием UPN, даже при добавлении AD. Поэтому если ферма содержит серверы и Win2K, и WTS, то вы должны использовать для входа имена в формате domainname\username.

Во вторых, Microsoft выпустил некоторые заплаты для Win2K Terminal Services, которые не относятся к WTS. В некоторых случаях эти заплаты не слишком будут вас затрагивать - недостатки лицензирования, о которых упомянуто в главе 2, могут вас не беспокоить, если вы используете WTS, поскольку WTS не пользуется услугами сервера лицензирования. Но с другими ОС, в том числе Windows 2000, они важны, т.к. Microsoft сосредоточила свои усилия на поддержке последних версий своей ОС.

Выбор ОС прост. Теперь обратимся к более сложной теме - к планированию сервера и домена.

Планирование сервера и структуры Домена

Успешная установка MetaFrame XP сводится не только к инсталляции программного обеспечения на сервер Win2K, установке лицензий и последующей раздачи клиентов ICA. Процесс гораздо более сложен, поскольку способ работы структуры домена может влиять на функционирование вашей фермы серверов MetaFrame XP.

Сервер-член или Контроллер Домена?

Хотя я уже не раз говорил, но все-таки повторюсь: не устанавливайте Terminal Services в режиме сервера приложений на контроллере домена. Во-первых, заданные по умолчанию разрешения для входа в систему не будут позволять членам группы Domain Users использовать терминальный сервер, если вы не дадите им права локального входа. Во-вторых, что более важно, сервер приложений потребляет много ресурсов процессора. Поэтому устанавливать терминалы на контроллере домена можно только в совсем крохотных сетях. Не стоит перегружать сервер функциями аутентификации, т.к. он и так занят поддержкой пользовательских приложений и данных. Единственный случай, когда стоит рассмотреть возможность создания сервера прилдожений на контроллере домена - это если у вас есть изолированный домен, поддерживающий очень небольшое число удаленных пользователей, но даже тогда я предложил бы использовать сервер-член не в домене.

Вернемся немного к лицензированию. Как я уже говорил в Главе 2, вам потребуются лицензии на подключения к MetaFrame XP и TSCAL. Если ваши серверы MetaFrame входят в домен Win2K, серверы лицензирования Terminal Services, которые могут быть находиться отдельно от серверов MetaFrame, должны находиться на контроллерах домена. Если они являются частю домена NT 4.0 или рабочей группы, то сервер лицензирования будет находиться на сервере-члене..

Наименование сервера

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

Планирование AD

Хотя это не обязательно, но для облегчения аутентификации доступа к Citrix Management Console, опубликованным приложениям и сетевым принтерам, Citrix рекомендует следовать следующим правилам при использовании MetaFrame XP с AD:

Эта глава - не место для детальной диссертации по Win2K AD. Однако, небольшое описание AD поможет вам понять эти рекомендации.

Важно понять то, что домены Win2K AD не эквивалентны доменам NT 4.0. Домены NT 4.0 являются монолитными объектами, которые не могут содержать никаких других контейнеров, кроме групп, и не могут сами входить в другие домены. Напротив, домены AD могут содержать подэлементы, называемые организационными единицами (OU), которые вы можете использовать для делегирования полномочий, назначая отдельным лицам полномочия к OU, а не ко всему домену. Домены AD сами могут входить в другие домены: домены AD могут быть самостоятельными элементами или соединяться друг с другом в логические группы, назваемые деревьями, которые в свою очередь логически группируются в леса и физически - в сайты, подобно фермам и зонам MetaFrame.

Ключом к пониманию структуры домена AD является то, что все домены в одном лесу автоматически доверяют друг другу. Если вы когда-либо работали с NT 4.0, то знаете, что домены NT 4.0 ревниво охраняют свое содержимое. Настройка системы, в которой один домен доверяет пользователям другого домена использовать свои ресурсы, довольно трудоемка. И при этом доверительные отношения не переходящие - если домен А доверяет домену Б, а домен Б доверяет домену B, то вам необходимо установить отдельное доверительное отношение между доменами А и В. Возникает также небольшой вопрос с добавлением глобальных групп к локальным группам во всех доверительных доменах, а также проблема, когда вручную установленные доверительные отношения имеют эту забавную привычку работать непоследовательно. В итоге, хотя система доверительных отношений NT 4.0 упрощает изоляцию доменов, достаточно тяжело заставить домены кооперировать друг с другом. Особенно это касается больших сетей, поскольку домены NT в действительности не могут содержать более 5000-10000 записей.

В отличие от этого, домены AD автоматически доверяют друг другу, если логически сгруппированы друг с другом. Одним из способов такой группировки является организация домена в иерархическую структуру, в которой, например, на самом верху находится домен citrix.com и подчиненные домены marketing.citrix.com и development.citrix.com. Даже эти домены могут содержать другие домены, например, sales.marketing.citrix.com и conferences.marketing.citrix.com..

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

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

А что если ферма сервера должна содержать домены, которые не доверяют друг другу? В таком случае вам необходима доверительная маршрутизация для определения, каким серверам позволено связываться друг с другом. В доверительной маршрутизации, которая показана на рисунке, запрос пуолучения списка пользователей, например при назначении приложения или аутентификации пользователя, направляется на сервер, который имеет нужное доверительное отношение, если его не имеет инициирующий сервер. Во время этого доверительного запроса , сервер MetaFrame XP регистрирует свои доверительные домены в хранилище данных фермы. Эта операция происходит при каждом запуске службы и происходит приблизительно каждые 6 часов, пока работает служба. Поэтому хранилище данных является центральным архивом всех доверительных данных для серверов в ферме. Когда сервер должен выполнить операцию для домена, которому он не доверяет, сервер определяет из хранилища данных, какие серверы могут выполнить эту операцию, а затем направляет запрос на самый доступный сервер. Например, на рисунке Домен А доверяет домену B, но не доверяет Домену C. Домен B доверяет и Домену А, и Домену C. Для сервера в Домене А, чтобы получить список пользователей в Домене C, серверу в Домене А необходимо обратиться к хранилищу данных, чтобы увидеть, какие серверы могут подключиться к Домену C за нужной информацией. В нашем примере, сервер в домене А для этого использует сервер в Домене B.

Планирование разрешений для учетных записей пользователей

Чтобы разрешить пользователям обращаться к ресурсам в ферме серверов, вы выбираете учетные записи группы пользователей. Например, когда вы публикуете приложение, то при выборе сервера, обслуживающего приложение, Citrix Management Console выводит список учетных записей пользователей из доверительного пересечения всех серверов (учетные записи, которым доверяют все серверы). Из этого списка вы выбираете пользователей и группы, которым вы хотите разрешить использовать приложение. После того, как вы выберете пользователей, изменение списка серверов может изменить доверительное пересечение, что может сделать приложение недоступным пользователям, которые больше не находятся в этом пересечении. При изменении доверительного пересечения, консоль сообщает вам об этом и удаляет из списка уполномоченных пользователей тех, которые больше не имеют право использовать ресурс.

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

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

Выбор типа базы данных

При установке MetaFrame XP вы должны выбрать тип базы данных, используемой для хранилища данных для вашей фермы серверов. Вы имеете три варианта: Microsoft Access, Microsoft SQL Server 7.0 SP2 или SQL Server 2000, а также Oracle - особенно OracleSi, (рекомендуется) версии 8.1.6; Oracle 7 (версия 7.3.4) или Oracle 8 (версия 8.0.6).

Хотя хранилище данных - это база данных ODBC, Citrix поддерживает не любые СУБД, поддерживающие ODBC, а только вышеперечисленные.

Microsoft Access

Microsoft Access - это простая база данных, включенная в состав сервера Windows 2000. Access лучше всего подходит для небольших ферм, содержащих до 50 серверов MetaFrame XP, работающих в "родном" режиме (native mode), хотя неплохо работают и в фермах среднего размера, с 50 и более серверами. Если вы используете Access, то хранилище создается на первом сервере, который вы устанавливаете в ферме. Access и драйвер ODBC для него по умолчанию входят в состав сервера WTS и Windows 2000, поэтому при выборе Access для хранилища данных вам не стоит беспокоиться об установке драйверов или настройке базы данных перед установкой MetaFrame XP. Это делает значительно упрщает установку хранилища на базе Access. Для поддержки хранилища данных Access, Citrix рекомендует минимум по 20 Мб дискового пространства на каждые 100 серверов фермы и 32Мб дополнительной оперативной памяти в том случае, если сервер будет обслуживать также соединения.

Microsoft SQL Server и Oracle - это базы данных с классической архитектурой клиент-сервер, которые предлагают устойчивую и масштабируемую поддержку доступа с нескольких серверов и одинаково хорошо работают в фермах любого размера. Если вы выбираете одну из этих СУБД, хранилище данных будет находиться на выделенном сервере, который вы должны установить до создания фермы серверов, а также вы должны установить драйверы ODBC на серверах в ферме, чтобы они могли обращаться к хранилищу данных.

Установите драйверы на серверах MetaFrame XP, а не на самой базе данных. Не пытайтесь разместить сервер SQL или Oracle на сервере MetaFrame. Поддержка базы данных будет серьезно влиять на производительность сервера MetaFrame.

SQL Server

Использование SQL Server требует, чтобы на каждом сервере MetaFrame, который будет иметь прямое соединение с хранилищем, была установлен драйвер ODBC для Microsoft SQL Server версии 3.70.08.20 или позже. Эти драйверы устанавливаются на серверы Win2K, но если вы используете WTS, то будете должны загрузить MDAC 2.6 с http://www.microsoft.com/Data/download.htm.

Установка MDAC модифицирует механизмы базы данных на WTS, поэтому если вы устанавливаете обновленный MDAC на сервере приложений WTS, выполняющем службу лицензирования Terminal Services, то сначала остановите эту службу. После установки MDAC очистите журнал событий и затем перезапустите сервер перед установкой MetaFrame XP.

Независимо от того, используете вы WTS или Win2K для MetaFrame, вам следует подумать о масштабировании:

Динамические диски в Windos 2000 позволяют вам создавать тома, простирающиеся на несколько физических дисков. Хотя это уменьшит проблему нехватки дискового пространства, дополнительное время, требуемое для поиска на нескольких физических дисках, будет влиять на производительность. Современные диски достаточно велики, чтобы разместить хранилище данных, поэтому возьмите диск с достаточно большим разделом.

При использовании SQL Server в реплицируемой среде, убедитесь, что используете одну и ту же учетную запись пользователя на каждом SQL Server.

Каждая ферма MetaFrame XP требует выделенной базы данных. Однако, несколько баз данных могут выполняться на одном сервере SQL Server.

Oracle

Если для хранилища данных вы планируете использовать Oracle , то перед установкой MetaFrame XP вы должны установить клиента Oracle Net8 версии 8.01.06.00 и драйверы ODBC для Oracle на каждом сервере, который непосредственно обращается к серверу базы данных. (Клиенты 8.1.5 и 8.1.7 не поддерживаются в MetaFrame XP 1.0.). Хранилище данных Citrix хранится как объект (схема), назначенный пользователю. Вам не нужна отдельная база данных для каждого хранилища данных. Во время установки вы можете либо запустить Net8 Easy Config, либо отменить инсталляцию в этом месте и скопировать файлы tnsnames.ora и sqlnet.ora с сервера Oracle в каталог %oracle home directory%\network\admin на каждом сервере. Перезапустите сервер после того, как установите клиента Oracle и перед установкой MetaFrame XP, в противном случае инсталляция MetaFrame XP не сможет соединиться с хранилищем данных.

Аппаратные требования для Oracle такие же, что и для SQL Server: Вам потребуется не менее 20 МБ дискового пространства для каждых 100 серверов в ферме, и даже больше, если ферма серверов содержит большое количество опубликованных приложений. Удостоверьтесь, что на диске достаточно свободного места для роста базы данных.

Создание отдельного пространства таблиц (tablespace) для хранилища данных упрощает операции резервирования и восстановления.

Что стоит учитывать при выборе типа базы данных

Что же лучше выбрать? Как обычно, все зависит от среды. Access намного легче в использования, чем SQL Server или Oracle, но не подходит для больших сетей. SQL Server и Oracle поддерживают репликацию баз данных, которую вы можете использовать для уменьшения нагрузки на хранилище данных. Из этих двух, SQL Server более популярен, поскольку сделан той же компанией, которая сделала ядро ОС, и поэтому содержит некоторые опции, не доступные в Oracle: если вы используете MetaFrame XP на базе Win2K, вам не нужно устанавливать драйверы. Кроме того, SQL Server при доступе к базе данных поддерживает аутентификацию NT или SQL Server; Oracle же поддерживает только аутентифкацию Oracle. Вообще говоря, выбор между SQL Server и Oracle в большей мере зависит от того, с какой СУБД вы больше знакомы. Работа с ними - не для новичков; Citrix рекомендует Access, если вы не знаете, как использовать SQL-базы.

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

Серверы в ферме соединяются с сервером хранилища данных через порт 2512. Если серверы находятся в разных подсетях, убедитесь, что этот порт открыт.

Использование SQL Server или Oracle означает, что серверы-члены будут обращаться к хранилищу данных непосредственно, т.е. в прямом режиме. Для маленьких ферм вполне подходит использование косвенного режима, но единственный сервер с хранилищем данных станет узким местом, если ферма разрастется и ее серверы будут вынуждены ждать доступа к хранилищу данных. Как показано на рисунке, сервер-посредник также представляет собой узкое место: если он выходит из строя, ни один из других серверов не сможет обратиться к хранилищу данных

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

Организация серверов в прямом режиме доступа к хранилищу гарантирует, что даже при потере одного соединения остальные серверы будут работать

Если вы хотите обеспечить прямое подключение к хранилищу данных, то должны установить драйверы ODBC на серверах, чтобы они могли общаться с SQL Server или Oracle. Косвенный режим требует наличия драйверов ODBC только на серверах с прямым доступом к хранилищу. Базы данных SQL Server поддерживают комбинацию прямого и косвенного доступа к хранилищу, поэтому вы можете просто принять это к сведению. Если вы решаете поступить таким образом, то установите первый сервер в ферме в прямом режиме доступа к хранилищу и настройте его так, чтобы он должным образом указывал на базу данных, а затем установите остальные серверы, указывая их на прямой сервер, который вы установили первым..

Репликация хранилища данных

MetaFrame XP поддерживает распределенные базы данных для хранилищ данных, поддерживаемые в SQL Server и Oracle, но не в Access. Citrix рекомендует, чтобы вы поддерживали одновременно только одно хранилище данных, но в некоторых случаях репликация хранилища может улучшить работу фермы, когда оно становится узким местом из-за слишком многих запросов чтения. В среде локальной сети использование репликации базы данных может уменьшить время запуска службы IMA и улучшить отклик серверов в больших фермах. В глобальной сети репликация хранилища данных может препятствовать возникновению тайм-аутов службы IMA при операциях записи.

MetaFrame XP должен быть уверен в непротиворечивости данных в нескольких базах данных, поэтому он использует механизм двухфазной фиксации - т.е. сначала пришет в основную базу данных, потом дает базе данных реплицировать эти данные, и после репликации получает подтверждение. Эту функциональность вы можете настроить в SQL Server и Oracle.

Чтобы использовать SQL Server для поддержки распределенной базы данных, Citrix рекомендует использовать модель Immediate Updating Subscriber, описанную в документации SQL Server. Для установки распределенной среды для существующей фермы MetaFrame XP, настройте Publisher (SQL Server, который держит хранилищеv данных), Distributor и Subscribers (удаленные сайты) на использованиеSQL Server Enterprise Manage, а затем выполните команду

 dsmaint publishsqlds

на существующем сервере фермы. Этот шаг создает статьи, публикуемые на текущем SQL Server Publisher. И наконец, сконфигурируйте удаленные сайты, для подписки на опубликованные статьи, которые вы создали на предыдущем этапе.

Чтобы использовать Oracle для распределенных баз данных, все участвующие базы данных должны выполнять Oracle в режиме MTS/Shared (а не в режиме Dedicated), а все серверы MetaFrame XP, соединяющиеся с хранилищем данных в прямом режиме, должны иметь SQL*Net версией 2 или Net8. Установите базу данных фермы сначала на главном сайте, затем сконфигурируйте репликацию на snapshot сайтах, настроив их на репликацию всех объектов, содержащихся в пользовательской схеме хранилища данных. Если производительность сайта реплицированной базы данных значительно меньше, то проверьте, что успешно скопировались все индексы для пользовательской схемы MetaFrame XP, а не только объекты.

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

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

Системные аппаратные требования

Вероятно, вы знаете аппаратные требования к WTS и Win2K. Согласно Microsoft, для WTS вам необходим сервер с процессором Pentium, 32 МБ оперативной памяти, жесткий диск не менее 128 МБ. Для Win2K Server или или Advanced Server требуется процессор Pentium 133MHz, 256 МБ оперативной памяти и жесткий диск 2GB. В дополнение к этим требованиям для ОС, Citrix рекомендует, чтобы вы резервировали дисковое пространство для стандартной инсталляции MetaFrame XP (85 МБ без программного обеспечения Клиентов ICA, 285 МБ вместе с клиентами), 20 МБ дискового пространства для службы NFuse, если она вам нужна, и 64 МБ оперативной памяти для служб MetaFrame XP, включая IMA.

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

Скорость Процессора

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

Люди и компьютеры похожи: что-то, что мы когда-то использовали, мы скорее всего будем в некоторый момент времени использовать снова. Процессор имеет кэш, в котором сохраняет информацию, которая, вероятно, в ближайшем будущем ему снова понадобится. Фактически существует два кэша. Старые процессоры имели только один кэш внутри процессора, который называется кэшем L1. Современные процессоры имеют этот кэш L1, а также большой внешний кэш, находящийся в статической оперативной памяти (SRAM) и называемый кэшем второго уровня L2. (Специально чтобы внести путаницу, некоторые процессоры начали включать кэш второго уровня в центральный процессор, и теперь имеют внешний кэш третьего уровня, но суть остается той же: один кэш находится в процессоре, а другой - снаружи)

SRAM хранит все со времени поступления данных в память вплоть до удаления этих данных или выключения компьютера. В отличие от динамической оперативной памяти (DRAM), из которой состоит основная системная память, SRAM не нуждается в обновлении каждые четыре миллисекунды, поэтому она намного быстрее, чем DRAM. Но также намного дороже.

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

Ключевым моментом здесь является то, что более быстрый чип не обязательно означает больший кэш. Например, процессоры Pentium 4 могут внутренне работать со скоростью 2ГГц, но имеют меньший кэш, чем Pentium III Xeon. Поэтому Pentium 4 может работать быстрее чем Xeon, но требует больше времени для сбора информации и поэтому замедляется из-за времени, требуемого для получения данных из памяти. Разница в скорости между 700МГц и 1.4ГГц на самом деле не так велика, чтобы уравновесить недостаточный размер кэша.

А как насчет числа процессоров? В многопользовательской среде, сервер будет пытаться делать несколько операций одновременно. Несколько процессоров означают, что конвейер каждого из процессоров будет короче, поэтому многопроцессорные системы являются в большинстве случаев хорошим выбором. Однако, не скорость центрального процессора самое узкое место на серверах MetaFrame, а оперативная память (RAM). 32-разрядные ОС типа Win2K могут адресовать до 4Гб RAM, поэтому в 4-процессорной системе легко может возникнуть нехватка оперативной памяти.

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

Обычно все приложения имеют одинаковый доступ к центральному процессору, в зависимости от приоритета их процесса. Начиная с FR1 для MetaFrame XP, вы можете назначить приложениям приоритет, определяя их доступ к процессору и таким образом предотвращая поедания циклов CPU интенсивно использующими его приложениями. Подробнее об этом я расскажу в главе 6.

Оперативная память

Если у вас есть выбор, что добавить к серверу MetaFrame для повышения его производительности, добавьте оперативную память. Сервер Win2K использует виртуальную память, адресное пространство до 4GB, в котором он сохраняет все используемые данные. Эта виртуальная память может находиться в либо в оперативной памяти, либо на диске - в файле, называемом файлом подкачки (paging file). В основном, виртуальная память работает приблизительно так: насколько можно, сервер Win2K пытается хранить все данные, которые он в настоящее время использует, в оперативной памяти, поскольку для перемещения данных в оперативной памяти требуется наносекунды, а из файла подкачки на диске - микросекунды . Большая часть данных может быть безболезненно сброшена на диск; любые данные, которые нельзя сбрасывать на диск (если требуется недопустимо долгое время для их получения оттуда в случае необходимости), сохраняются в неперемещаемой области пула виртуальной памяти и никогда не будут сохраняться в файле подкачки.

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

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

При выборе памяти для сервера MetaFrame учитывайте два фактора - скорость и надежность.

Соображения по поводу скорости памяти

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

Не путайте SDRAM с SRAM, которая используется для внешнего кэша процессора. SDRAM - это не статическая RAM, просто более быстрая динамическая RAM.

Обычная DRAM является асинхронной, т.е. она не зависит от системных часов. Весьма упрощенно, доступ к данным в DRAM работает приблизительно так: менеджер памяти, который знает соответствие виртуальных адресов и физического местоположения памяти, сообщает контроллеру памяти, к какому физическому адресу памяти надо обратиться. Затем контроллер памяти определяет, в каких чипах содержится этот адрес и определяет местонахождение чипов. Менеджер памяти заставляет чипы выдать данные в шину данных, откуда процессор или другое устройство, которое затребовало эти данные, могут их взять. Время, требуемое для завершения этого процесса, называется времением доступа к памяти, подобно времени доступа к жесткому диску. В асинхронной DRAM время доступа считается в наносекундах (ns), или биллионных долях секунды; большинство DRAM имеют время доступа от 50 до 70ns. Чем меньше, тем лучше, но даже 60ns RAM работает на частоте 33MHz, тогда как системная плата сервера может работать на частоте 100MHz.

Причина столь медленного доступа заключается в том, что DRAM не только требуется некоторое время для поиска места в физической памяти, но также и то, что она сбрасыает содержимое памяти в шину памяти под одному блоку за цикл, затем возвращается к поиску следующего куска данных - вместо того, чтобы найти данные и получить их за одну операцию. Тип DRAM, называемый EDO, ускоряет процесс, давая обычной DRAM помощника для поиска следующей части посылаемых в шину данных, чтобы данные были уже готовы к тому моменту, когда DRAM может их послать. Но даже память EDO намного медленнее, чем системная плата. Медленная память, которая не может справляться с запросами процессора, приводит к холостым циклам, когда когда процессор ничего не делает, а лишь ждет данных. Это состояние называется состоянием ожидания (wait states). В идеале вы должны иметь как можно меньше состояний ожиданий, потому что это время простоя процессора. Системная плата работает на 100MHz, а процессор может быть в 10 раз быстрее, поэтому у вас все равно будут циклы ожидания, но основная идея сводится к их уменьшению.

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

Покупая SDRAM, удостоверьтесь, что она подходит к вашей системной плате. Некоторый SDRAM предназначены для 100MHz или даже выше, а некоторые предназначены для более медленных частот (66Mhz).

SDRAM для поиска первого фрагмента физической памяти требует столько же времени, сколько DRAM. Однако, как только найдена отправная точка, с которой нужно взять данные, SDRAM может сразу прочитать несколько блоков этой памяти, вместо того чтобы найти одну часть данных, передать ее в шину, потом найти следующую и т.д. Эта способность значительно уменьшает время доступа к памяти. SDRAM часто имеют время доступа 12, 10 или даже 7 наносекунд. Эти числа могут ввести в заблуждение, т.к. не всегда относятся к фактическому времени доступа, а к максимальной скорости, с которой модуль SDRAM может передвать данные на шину. Это время не включает время, требуемое для нахождения первого блока памяти. SDRAM с номинальной скоростью 7ns не в десять раз быстрее чем DRAM с номинальной скоростью 70ns, он быстрее только после того, как найдет отправную точку.

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

Но даже SDRAM больше не чемпион. Rambus DRAM (RDRAM) имеет рекордную скорость около 800МГц, а будущая технология, nDRAM, как предполагается, будет поддерживать скорость передачи данных 1.6ГГц. Вам не обязательно ставить на свои серверы самую быструю в мире RAM, просто неплохо знать о доступных вариантах.

Надежность памяти: понимание проверки и исправления ошибок

Скорость - не единственное важное соображение при выборе памяти. Вы хотите, чтобы ваша память была точной, причем больше, чем вы хотите, чтобы она была быстрой. Почему она может быть неточной? Вспомните, что DRAM/SDRAM должны непрерывно освежать хранимые в себе данные каждые 4 ms. Данные хранятся в виде электрических зарядов, которые принимают значения либо 1 (есть) или 0 (нет). 1 регистрируется как электрический импульс, скажем, 5 вольт. Просто, правда? Если напряжение 5V, то это 1, а если 0V - то 0. Неприятность состоит в том, что напряжение не работает по принципу "все или ничего", как обычный выключатель лампочки, имеющий состояние вкл./выкл. Скорее, оно похоже на лампочку с регулятором освещенности, который имеет диапазон между "полный накал" и "выкл.". Если вы покрутите выключатель в сторону ослабления света, то вскоре затруднитесь сказать - есть свет или нет. Если датчик, читающий память, обнаруживает напряжение 4.9V, он предполагет, что это 1. Но если датчик обнаруживает более низкое напряжение, скажем, 1V, то даже если бит действительно должен быть 1, датчик может прочитать его как 0.

В двоичной системе замена 0 на 1 имеет большое различие. В качестве простого примера подумайте об адресе IP. Как вы знаете, адреса IP для удобства записывают в точечной нотации, но компьютер считает адрес IP строкой из 1 и 0. Перевернутый бит в последней четверке может изменить адрес IP 12.45.93.121 на 12.45.93.105. Это приведет только к неверной маршрутизации, но подумайте о перевернутом бите в команде, приказывающей вашему компьютеру отформтировать жесткий диск.

Перевороты битов могут случаться из-за тяжелых ошибок (hard errors) или нерегулярных ошибок (soft errors). Тяжелые ошибки означают, что аппарные средства повреждены и требуют замены. Нерегулярные ошибки могут быть вызваны самыми разными причинами: незначительным повреждением, статическим электричеством, проблемой с таймингом, блуждающими полтергейстами в системной плате... Продолжите сами. Нерегулярная ошибка может повториться, а может и нет. Это означает, что вы можете легко принять нерегулярные ошибки за ошибки в программном обеспечении. Ошибки в программном обеспечении действительно вызывают проблемы, но очевидно, что ошибки в аппаратных средствах также могут их взывать.

Для избежания проблем такого рода, вы можете достать память с обнаружением или исправлением ошибок. Есть три основных класса памяти. Память без контроля четности имеет достаточный размер для хранения данных, но не более. (8 бит для 1 байта данных). Память с контролем четности добавляет дополнительный бит четности так, что хранение 1 байта данных занимает 9 бит. Когда DRAM посылает данные в шину памяти, бит четности действует как своего рода индикатор правильности. Проверка четности обнаруживают ошибку в одном бите, но не обрабатывает несколько бит и не исправляет саму ошибку в памяти.

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

Улучшенный тип памяти с контролем четности под названием код исправления ошибок (ECC) может не только обнаруживать ошибки памяти, но и устранять их на компьютерах с набором микросхем, поддерживающим ECC (вам надо проверить, поддерживают ли ваши аппаратные средства ECC). ECC может обнаружить ошибки как в одном бите, так и в нескольких, и может исправить ошибки с одним битом. ECC дороже, чем память без контроля четности. Существуют особые модули памяти ECC, предназначенные специально для использования в режиме ECC, но самые современные системные платы, которые поддерживают ECC, будут поддерживать контроль четности и с обычными модулями памяти. Вы будете должны включить поддержку ECC в BIOS. Хотя ECC несколько замедляет скорость памяти, ее способность обрабатывать ошибки стоит того, чтобы использовать ее на серверах MetaFrame.

Действительно ли необходима память ECC?
В наши дни сложно сказать "конечно, она вам нужна", тем более что такая память дороже обычной. Многие скажут, что четность больше не важна. Почему? И правы ли они?
Годы назад, когда 486 считали довольно приличным сервером, память с контролем четности можно было легко достать (тогда она была дорогой, но доступной) и считалось, что ее надо ставить в любой компьютер, надежность которого должна быть на первом месте. С появлением процессора Pentium, многие стали утверждалть, что для памяти теперь контроль четности вообще не нужен, поскольку это может обрабатывать процессор. Поэтому память ECC вышла из моды. Однако, когда вы говорите о надежном сервере, этот аргумент неприемлим. Во-первых, сервер имеет много памяти, возможно, больше гигабайта, а чем больше памяти, тем более вероятно возникновение где-то ошибки четности. Во-вторых, при больших скоростях работы аппаратных средств возрастает вероятность появления ошибок по сравнению с более медленными скоростями. Хотя память без контроля четности дешевле памяти ECC, избегайте использования ее на серверах MetaFrame, более того, вы должны планировать память с исправлением ошибок, а не только с проверкой. Нельзя экномить на надежности - прикладной сервер не тот случай, чтобы экономить на аппаратном обепечении

Сколько нужно памяти?

Как я уже говорил, память склонна быть узким местом на сервере MetaFrame. Мало того, что вы должны поддерживать приложения в памяти, вы также должны поддерживать данные, которые эти приложения используют. Объем необходимой вам памяти зависит от того, используют ли люди Notepad для редактирования текстовых файлов, или запускают САПР или сложные бухгалтерские программы.

Согласно Citrix, вы должны планировать 16 МБ плюс по 4 МБ для каждого пользователя (запускающего единственное приложение, не считая копирования/вставки между приложениями), или по 8 МБ для каждого профессионального пользователя (запускающего три или более приложений, большой обмен данных). Однако, эти оценки слишком низкие. Лучше всего запустить пилотную систему, чтобы увидеть, как сервер MetaFrame справляется с несколькими типичными пользователями. Память никогда не бывает лишней. Планируйте возможное добавление памяти в будущем. Другими словами, не заполняйте сразу все слоты маленькими модулями памяти; устанавливайте большие модули и оставьте часть слотов свободными.

При расчете количества RAM, необходимого на сервере MetaFrame, не забудьте принять во внимание Citrix Management Console, если вы планируете управлять ею локально. Citrix выбрал Java из-за ее платформонезависимости, а отнюдь не из-за эффективного использования памяти. Я расскажу о требованиях к программному обеспечению и оборудованию для Citrix Management Console немного позже, а пока скушайте пилюлю: Citrix рекомендует минимум 64 МБ RAM только для поддержки Citrix Management Console, не говоря уже о чем-то еще.

Использование Java для Citrix Management Console было предназначено для того, чтобы позволить администраторам MetaFrame for Windows и MetaFrame for UNIX использовать единую консоль. Действительность же оказалась весьма печальной, ибо консоль на базе Java является настоящим "пожирателем" памяти, и требует ее тем больше, чем больше объектов в вашей ферме. На формуе iForum 2001 я узнал, что Citrix работает над оснасткой для MMC, чтобы работа консоли потребляла меньше памяти. Выполнение Citrix Management Console на удаленном компьютере, который не является сервером MetaFrame, является неплохой идеей.

Диски Сервера

Другой ключевой элемент быстрого и надежного сервера - быстрый и надежный диск. Хотя нынешний рынок предлагает две альтренативы - IDE и SCSI, выбор для MetaFrame очевиден: SCSI. Я буду рассматривать оба типа, чтобы вы поняли, почему.

Диски IDE

Жесткий диск состоит из двух важных частей: собственно диска и контроллера. Во времена молодости ПК, согласно стандарту ESDI, жесткий диск соединялся с двухканальным контроллером двумя ленточными кабелями. Хотя такой способ соединения диска и контроллера работал, кабели были чувствительны к электрическому воздействию. Компоненты внури компьютера - хороший источник электрических помех, поэтому ESDI мог привести к возникновению ошибок записи и чтения. В 1988 Western Digital и другие компании разработали стандарт IDE, который заключал контроллер диска и сам жесткий диск в единый блок. Если вы перевернете диск IDE, то увидите снизу плату контроллера. Контроллер все еще используется, но лишь для обслуживания коммуникации между системной платой и контроллером диска, а не для манипулирования данными. Контроллер идентифицирует каждое устройство, подключенное к нему, как первичное (master) или вторичное (secondary).

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

Расширение IDE, EIDE, позволило снять эти проблемы. К контроллерам EIDE можно подключить до четырех устройств, что сделало вещи более гибкими. EIDE могут иметь емкость до 90GB и более, я не берусь назвать верхний предел. Из этого вытекает, что поскольку EIDE удаляет ограничение размера дисков IDE, позволяя подключать целых четыре устройства к одной плате контроллера, вы на одной машине можете иметь большое дисковое пространство. Кроме того, диски EIDE сравнительно недорогие. Но поскольку объем дискового пространства и его стоимость не самые важные вещи для дисков сервера MetaFrame, я должен рекомендовать другую дисковую технологию: SCSI.

Диски SCSI

SCSI первоначально был разработан компанией Apple Computer. Как и EIDE, SCSI размещает контроллер диска и сам жесткий диск в едином модуле, который подключается к адаптеру на системной плате. Различие заключается в способе, которым контроллер диска связывается с адаптером. Адаптеры SCSI могут поддерживать любые SCSI-совместимые устройства, соединяемые в цепочку. К шлейфу SCSI можно подлючить целых семь устройств, не считая адаптера. Каждое устройство в цепочке имеет уникальный идентификатор (SCSI ID). ID 7 зарезервирован для адаптера, ID 0 и 1 - для жестких дисков (0 зарезервирован для загрузочного диска), а идентификаторы 2 - 6 могут использоваться любыми другими устройствами в SCSI цепочке. Идентификаторы не обязательно должны идти в том порядке, в котором устройства подключены к шлейфу и не обязательно должны все использоваться (т.е. не обязательно иметь все семь устройств в цепочке). Важно лишь, что зарезервированные идентификаторы должны использоваться тех целей, для которых предназначены, и вы должны завершить цепочку SCSI на обоих концах. Завершение достигается установкой перемычек; вы можете установить SCSI ID программно или аппаратно, в зависимости от устройства. Чтобы добавить новое устройство SCSI в систему, вы выключаете компьютер, подключаете устройство в конец цепочки и завершаете цепочку.

Существет несколько разновидностей SCSI, как показано в таблице. Citrix рекомендует выбирать SCSI-2 (также известный как Fast Narrow SCSI), Fast Wide SCSI, UltraWide SCSI (SCSI-3) или Ultra2 SCSI Wide.
Тип SCSI Описание
SCSI-2 Использует соединитель с 50 штырьками, 8-разрядную шину, поддерживает скорости передачи данных 4Mbps
Wide SCSI

Использует соединитель с 68 штырьками и имеет 16-разрядную шину

Fast SCSI Аналогичен обычному SCSI, но с удвоенной тактовой частотой. Поддерживает скорость передачи данных 10Mbps

Fast and Wide SCSI

Объединяет 16-разрядную шину Wide SCSI и удвоенную тактовую частоту Fast SCSI для скорости передачи данных 20Mbps

Ultra SCSI

Имеет 8-разрядную шину, но скорость передачи данных 20Mbps
Ultra Wide SCSI/SCSI-3 Имеет 16-разрядную шину и поддерживает скорость передачи данных 40Mbps

Ultra2 SCSI

Имеет 8-разрядную шину и поддерживает скорость передачи данных 40Mbps

Ultra2 SCSI Wide

Имеет 16-разрядную шину и поддерживает скорость передачи данных 80Mbps

SCSI-1, предшественник к SCSI-2, использовал соединитель с 25 штырьками и не поддерживал цепочки SCSI. Когда используется термин "SCSI" без уточнения, вероятнее всего он относится к не к SCSI-1, а к SCSI-2.

Скрорость передачи данных - не единственный аспект SCSI, которые делают его хорошим выбором для серверов MetaFrame. Ключевым является способ, которым он обрабатывает передачу данных. Контроллеры EIDE и SCSI могут иметь несколько подключенных к ним устройств. Но EIDE может одновременно слушать только одно устройство; т.е. быстрый жесткий диск может ждать завершения чтения из медленного CD-ROM. SCSI может быть многозадачным. Одно устройство, которое слушает контроллер EIDE, также занимает всю полосу пропускания кабеля, вытесняя любые другие устройства, которые ждут чтения или записи. Напротив, SCSI может обрабатывать коммуникации с несколькими устройствами одновременно, и устройства в цепочке SCSI могут совместно использовать полосу пропускания. Пока вращается диск CD-ROM в поиске нужных данных, адаптер может записывать данные на жесткий диск. Таким образом, при выборе интерфейса для серверов MetaFrame ориентируйтесь на SCSI.

Дисковые массивы

Размышляя от типе дисков, подумайте и о защите данных. Вы должны делать резевное копирование базы данных хранилища данных - это жизненно важно. Но диск, содержащий хранилище данных - не единственный важный диск в ферме серверов. Если отказывает системный диск сервера MetaFrame, то сервер MetaFrame станоится недоступным до тех пор, пока вы не устраните проблему.

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

Существует много разновидностей RAID, предназначенных для различных целей. В таблице описаны типы, которые могут быть вам полезны.
Уровень RAID Описание

Влияние на время доступа к диску

Минимальное кол-во требуемых дисков
0
Данные разбиваются на блоки и записываются на все диски в массиве. Этот тип не предоставляет отказоустойчивость - если ломается один из дисков диск в массиве, весь массив становится нечитабельным.

Повышение производительности для чтения и записи.

2
1

Разделы двух дисков составляют зеркальный набор и одинаково обрабатывают операции записи и чтения. Если один из дисков выходит из строя, вы можете читать с другой половины зеркального набора. Этот тип RAID требует 100-процентного дополнительного дискового пространства для избыточности. Зеркальное отражение диска, сделанное с двумя дисковыми контроллерами диска называют дуплексированием.

Та же производительность для чтения, что и для одного диска; запись чуть быстрее..
2 (максимум 2)

5

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

Хорошие скорости чтения из-за наличия нескольких источников данных, плохая скорость записи из-за накладных расходов на запись информации четности.

3
10
Массив RAID 0, состоящий из сегментов массива RAID 1, комбинирует надежность RAID 1 и производительностью RAID 0. Это дорогое и трудно осуществимое решение, поскольку диски должны быть синхронизированы и кроме того такую систему труднее масштабировать. Хорошая скорость ввода/вывода.
4

0+1

Массив RAID 1, состоящий из сегментов RAID 0. Если один из сегменто выодит из строя, RAID 0+1 прекращает быть отказоустойчивым. RAID 0+1 не идентичен RAID 10.

Высокая производительность передачи данных и та же надежность, как RAID 5.

4

Способ работы RAID зависит от того, говорите ли вы о зеркальном наборе или некоторой форме распределения (striping). Зеркальное отражение диска (RAID 1) - самая простая форма RAID; данные пишутся на тома, расположенных на двух разных дисках, поэтому в случае выхода одного из них из строя, данные были все еще доступны на другом диске. Если что-то случается с диском, хранящим ваши оригинальные данные, вы все еще имеете идентичную копию того потока данных на втором зеркальном диске. Оба тома вместе называются зеркальным набором. В случае сбоя одного из дисков зеркального набора, вы можете читать с другого диска и даже снова сделать зеркало отказоустойчивым, добавив новый физический диск и восстанавив на нем зеркальную информацию.

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

RAID 1 хорош тем, что слабо загружает процессор (потому что все, что должен сделать контроллер диска - это записать данные на два диска, а не на один, а время чтения уменьшается, потому что контроллер диска может втягивать данные из двух источников). Низкая загрузка процессора делает возможным программную реализацию RAID 1, более того, эдинственный тип программного RAID, который можно использовать в промышленной среде. RAID 1 также имеет низкую начальную стоимость, потому для работы требует толко двух дисков. Однако, он чрезвычайно неэффективен по отношению к дисковому пространству, поскольку требует 100-процентной избыточности. Зеркальный набор нуждается вдвое большем объеме для хранения данных. Его также трудно масштабировать, поскольку вы не можете изменить размер зеркального набора, а можете только сделать другой зеркальный набор. Поэтому RAID 5 является еще одним ценным вариантом, который при наличии небольшого числа собственных недостатков, компенсирует недостатки зеркального отражения дисков.

RAID 5, известный также как disk striping (распределение дисков), требует для массива минимум трех физических дисков, собираемых в массив. Разделы на всех дисках в массиве должны иметь одинаковые размеры. Пространство на каждом члене массива делится на полосы равного размера. При записи в массив данные распределяются по полосам. Помимо данных, RAID 5 также записывает в массив контрольную информацию, чтобы в случае выхода из строя одного из дисков массива можно было восстановить отсутствующие данные с помощью контрольной информации. Из-за наличия контрольной информации массив может продолжать работу даже при отказе одного из его дисков, хотя регенерация данных значительно замедлит чтение по сравнению с обычным режимом. Если же отказывает второй диск массива до того, как вы заменили первый, то весь массив становится нечитабельным. Число дисков, которые вы можете разместить в массиве, зависит от используемого контроллера RAID, но все равно достаточно велико - даже Windows 2000 может программно поддерживать до 32 дисков в массиве RAID 5. Чем больше дисков в наборе, тем больше эффективность хранения данных, поскольку RAID 5 будет использовать эквивалент одного диска массива для хранения контрольной информации. Следовательно, RAID 5 с тремя дисками будет использовать треть своего пространства для контрольной информации, но тома с пятью дисками будут использовать только одну пятую общего объема. RAID 5 имеет низкое время доступа в операциях чтения, потому что контроллер диска может читать более чем с одного диска одновременно, но одновременно имеет более высокое время доступа при записи, поскольку должен сгенерировать контрольную информацию и записать ее вместе с самими данными на все диски массива.

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

Cамый большой недостаток RAID 5 состоит в том, что он должен генерировать новую контрольную информацию всякий раз при операции записи на диск. Вычисления, требуемые для этого, потребляют очень много процессорной мощности. Хотя Win2K поддерживает RAID 5 программно, не используйте это на серверах MetaFrame. Вместо этого поставьте аппаратный контроллер RAID 5.

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

Чтобы использовать программный RAID, вам необходима операционная система, которая его поддерживает, а также достаточное количество дисков для поддержки желаемого уровня RAID (0, 1 или 5). В Win2K для создания тома RAID вы также должны преобразовать диски в динамические. Затем на поддерживающих дисках вы можете создать тома RAID аналогично обычным томам. Программный RAID просто установить, и если ОС его поддерживает, вы можете экспериментировать с RAID без дополнительных затрат, кроме затрат на диски. Однако, для серьезного прикладного программного обеспечения приложений вы должны учитывать:

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

Если вы серьезно относитесь к защите данных в Win2K, то вероятно обратите внимание на аппаратные средства RAID. Самые простые формы аппаратных средств RAID аналогичны обычным программным решениям. Простые контроллеры RAID - это адаптеры ATA/IDE, заменяющие контроллер диска. Они во многих смыслах и являются дисковыми контроллерами - модели IDE поддерживают два канала (всего до 4 дисков), как и в стандартных контроллерах, они используют стандартную шину для связи сцентральным процессором компьютера. Отличие состоит в том, что они включает в себя запросы о функциях RAID (обычно ограниченные RAID 0, 1 и 0+1), чтобы процессор смог сказать контроллеру, куда записывать данные. Их преимущество состоит в том, что они обеспечивают недорогую защиту данных в операционных системах, которые не поддерживают RAID программно. Однако, поскольку для всех своих вычислений они полагаются на процессор, они не идеальны для защиты нагруженного сервера. Они также имеют все недостатки IDE, которые мы обсуждали ранее. Они подходят для важных клиентских рабочих станций, но для серверов MetaFrame они не намного лучше, чем программный RAID.

Более мощные контроллеры RAID имеют встроенный микропроцессор, который разгружает центральный процессор компьютера. Обычно это контроллеры SCSI, они не нагружают центральный процессор компьютера и более пригодны для поддержки RAID 5. Они также поддерживают большее количество дисков. Более совершенные контроллеры RAID могут также поддерживать горячую замену в случае отказа диска, что недоступно с программным RAID. Аппаратные RAID обычно не совместимы между различными брэндами, марками и моделями; в случае сбоя контроллера RAID вы должны заменить его другим контроллером того же самого типа. Обособленные RAID делают следующий шаг после интеллектуальных контроллеров RAID, помещая диски в физический контейнер с собственным электропитанием и охлаждением, чтобы основной блок питания не перегружался питанием и охлаждением жестких дисков массива. Простые обособленные RAID соединяются с контроллером RAID, находщимся на системной плате сервера. Более сложные (и дорогие) модели продаются в виде внешних массивов RAID, могут иметь внутренний контроллер RAID. Жесткие диски могут использовать кабель SCSI или подключаться непосредственно к основной плате. Такие внешние массивы могут подключаться к серверу через сеть или через кабель SCSI.

Помимо RAID, вы можете можете использовать сетевое хранение данных (NAS) для защиты и распределения нагрузки между серверами. Подробнее о NAS см. руководство The Definitive Guide to High-Availability Network Attached Storage, которое находится на http://www.realtimepublishers.com.

Выбор файловой системы

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

Во-первых, NTFS предназначена для защиты системы (т.е. позволяет устанавливать права доступа к локальным файлам), чего не позволяют FAT и FAT32. Сервер MetaFrame отличается от других серверов Win2K тем, что на нем работают разные пользователи. При таком доступе вам необходимо думать о безопасности сервера и обеспечить сервер файловой системой, поддерживающей разрешения для локальных файлов, а не только права доступа к файлам на общедоступных дисках, которые поддерживают FAT и FAT32 .

Во вторых, только тома NTFS поддерживают шифрование файлов в Win2K, квотирование дискового пространства, монтирование томов и сжатие данных. Если вы хотите использовать любую из этих особенностей в Win2K, то вам необходима NTFS.

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

Наконец, NTFS намного более эффективна чем FAT или FATS2 на больших томах. Вы можете использовать FAT только на томах не более 4GB, что означает деление современных дисков на большое количество разделов, причем с большим размером кластера. FAT32 в этом отношении лучше, чем FAT16, но все равно испытывает недостаток в других особенностях, которые делают NTFS ценной.

Если вы боитесь использовать NTFS на системном разделе потому, что не сможете прочитать его при загрузки с дискеты, не волнуйтесь. Win2K содержит инструмент, называмый Консолью Восстановления ( Recovery Console ), которую (после ввода пароля администратора) вы можете использовать для обращения к локальным томам, даже к томам NTFS. Консоль Восстановления также содержит некоторый набор утилит, которые вы можете использовать для ремонта поврежденного сервера.

Другие компоненты сервера

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

Тип системной шины

ISA или PCI? На самом деле это не вопрос. Хотя теоретически вы можете использовать ISA (которую, впрочем, уже не так легко найти), не делайте этого. Она слишком медленная, чтобы использовать на сервере. PCI и никаких вопросов.

Сетевые платы

Протокол ICA использует сжатие и потребляет относительно небольшую полосу пропускания, но поскольку сервер MetaFrame XP обрабатывает все сетевые запросы, то в сервере MetaFrame вы должны использовать высокопроизводительную сетевую карту. Рассмотрите вопрос о выделении одной карты для обслуживания запросов ICA, а другой карты - для остального трафика. Также для сильно загруженного сервера MetaFrame можно использовать распределение нагрузки между сетевыми картами - они имеют разные адреса MAC, но совместно используют один адрес IP, чтобы новые подключения автоматически были сбалансированы через неколько серевых карт, использующих один адрес IP. Если вы устанавливаете многопортовый асинхронный адаптер для поддержки последовательных соединений ICA, убедитесь, что используете интеллектуальный адаптер (с микропроцессором), чтобы уменьшить перегрузку прерываний и повысить производительность. Иначе вы перегрузите центральный процессор обработкой последовательных соединений.

Модемы и многопортовые адаптеры

Помимо соединений ICA по сетевым протоколам, MetaFrame XP поддерживает асинхронные соединения ICA. Когда вы устанавливаете асинхронное соединение ICA на сервере MetaFrame XP, клиентские устройства с модемами могут звонить на модемы на сервере MetaFrame XP. После того, как они соединятся, клиент и сервер связывается непосредственно, без участия RAS и TCP/IP.

Если вы хотите настроить модемную связь, а модемы сконфигурированы для RAS, то удалите модемы из пула модемов RAS до того, как запустите инсталляцию MetaFrame XP. Вы не можете настроить модем или последовательный порт одновременно для RAS и для соединения ICA.

Для асинхронных соединений ICA, Citrix рекомендуют на сервере высокоскоростные последовательные порты или интеллектуальные мнопортовые адаптеры. Эти устройства эффективно используют процессор , освобождая его ресурсы, которые могут быть отданы выполнению пользовательских сеансов. Если у вас есть многопортовый асинхронный адаптер, установите его до запуска инсталляции MetaFrame XP. Вы можете выбрать установку модемов, подключенных к многопортовому адаптеру, до или во время инсталляции MetaFrame XP. Инсталляция MetaFrame XP распознает TAPI-модемы, установленные на сервере. Когда TAPI модем обнаружен, MetaFrame XP использует инсталляцию модема и утилиты конфигурации Windows для управления модемом. Если модемы на сервере не установлены, установка MetaFrame XP даст вам возможность установить их после завершения установки.

Вкратце о масштабировании сервера

Резюмируя вышесказанное, сделаем быстрый обзор нашего сервера:

Сколько нужно серверов?
Консолидация серверов недавно гневно осуждалась в некоторых кругах, но это не относится к серверам MetaFrame. Для этого есть много серьезных оснований. Меньшее количество серверов требует меньшего места, меньшего охлаждения и меньше лицензий (эта также не относится к MetaFrame XP, который лицензируется только на соединения, а больше относится к лицензированию Win2K Server). Однако, меньшее количество серверов также приводит к удорожанию добавления новых возможностей и приводят к большим негативным последствиям в случае выхода сервера из строя. Допустим, у вас есть два 4-процессорных сервера MetaFrame. Когда один из них ломается, то у вас остается лишь половина общей вычислительной мощности. Если же у вас четыре 2-процессорных сервера, то вы имеете то же самое число процессоров, обслуживающих пользователей, но потеря одного сервера уменьшает вычислительные возможности всего на четверть, а не на половину. Кроме того, при этом облегчается модернизация серверов.
Возьмите испытательный сервер MetaFrame, установите приложения, которые вы будете использовать, посадите 2 - 5 человек использовать сервер или запустите тестовые скрипты, чтобы проверить поведение сервера в промышленной среде. Запустите Системный Монитор, чтобы видеть, сколько памяти и циклов процессора потребляют эти пользователи, а затем линейно масштабируйте эти значения, чтобы выяснить, сколько памяти и мощности процессора вам необходимо для поддержки реального числа пользователей. Обратите особое внимание на процент от общего процессорного времени, число обращений к страницам памяти в секунду, процент использования сети, частота ввода-вывода на жесткий диск.

Планирование для Citrix Management Console

По умолчанию, Citrix Management Console устанавливается на всех серверах MetaFrame XP. Однако, используя CD-ROM MetaFrame XP, вы можете установить ее на компьютерах, которые не являются MetaFrame XP, даже на компьютерах, которые вообще не являются серверами . Серьезно рассмотрите этот вопрос. Хотя Citrix Management Console будет на всех серверах MetaFrame, ее запуск на других компьютерах будет препятствовать перегрузке сервера, давая ему возможность эффективно заниматься другой работой. Как я упоминал раньше, основанная на java Citrix Management Console - не самая эффективный по отношению к использованию памяти инструмент, и чем больше у вас объектов управления (серверы, приложения, принтеры), тем больше памяти ей требуется.

Для запуска консоли на отдельном компьютере, вам потребуется ОС, которая ее поддерживает. Согласно Citrix, это NT и Win2K, но я запускал Citrix Management Console на Windows 98. (Я не слишком проверял ее под нагрузкой, поскольку Win98 не является моей предпочтительной средой, но, по крайней мере, она установилась и работала. Поскольку консоль можно считать критическим приложением, вам следует запускать ее в более устойчивой ОС, например, Windows 2000 Pro или Windows XP.) Вам также необходима исполняемая среда Java от Sun (JRE), но если JRE еще не установлена, то при установке консоли вам будет предложено установить JRE..

Каковы аппаратные требования необходимы для запуска консоли? Подойдет любой компьютер, способный запускать у себя Win2K. Вам нужен процессор Pentium и 25 МБ дискового пространства. Вам также потребуется большое количество RAM для запуска Citrix Management Console - ей необходимо минимум 64 МБ RAM, помимо памяти, требуемой для ОС и других приложений.

Выбор приложений для MetaFrame

Не все приложения одинаково хорошо работают в среде терминального сервера.

Terminal Services работает лучше с приложениями Win32. Причина этого лежит в способе, которым Win2K выполняет приложения Win32 и Win16. Будучи 32-разрядной операционной системой, Windows 2000 не может самостоятельно выполнять приложения Win16. Вместо этого она создает виртуальную машину DOS (VDM), которая является 32-разрядным приложением и выполняет приложения Win16 внутри контекста этого VDM. Если приложения Win32, выполняющиеся обычно на Win2K, могут совместно использовать между собой файлы и структуры, то приложения, выполняющиеся в пределах VDM, не могут "видеть" друг друга для совместного использования файлов. Практический результат этого поведения, совместно с тем фактом, что трансляция 16-разрядных запросов к ОС в 32-разрядные запросы занимает некоторое время, означает, что приложения Win16 выполняются хуже, чем приложения Win32. Они будут работать (это хорошая новость), но будут использовать больше памяти и процессора, чем приложения Win32. Согласно Citrix, приложения Win16 на 20% больше нагружают процессор и на 25% больше требуют памяти..

Приложения DOS представляют другой вид проблемы. Фактически, они представляют два вида проблем. Во-первых, приложения DOS были написаны для однопользовательской однозадачной среды. Чтобы быть настолько чувствительными, насколько возможно, приложения DOS постоянно опрашивают буфер клавиатуры, ища предназначенный для них ввод. Это поведение означает, что приложение DOS, даже ничего не делая, расходует поразительное количество процессорного времени. Это потребление приемлемо в однопользовательской среде, но совершенно непримелимо, когда процессорное время должно быть разделено с дюжиной человек. Это потребление является проблемой не во всех приложениях DOS, но прежде чем вы развернете их на сервере MetaFrame, я строго рекомендую сначала проверить их на отдельном компьютере с запущенным System Monitor, чтобы увидеть, сколько процессорного времени они требуют.

WTS включает утилиту DOSKBD, которая изменяет опрос клавиатуры программы, чтобы улучшить производительность системы при выполнении приограмм DOS. По существу, DOSKBD помещает программу в "сон", если она опрашивает буфер клавиатуры слишком часто. Win32K не включают DOSKBD, а версия WTS не работает с Win2K Terminal Services, но вы можете использовать другой инструмент для настройки приложений DOS - TAME (http://www.mindsprinq.com/~dqthomas/tame.htm)

Кроме того, приложения DOS с графическим интерфейсом для отображения используют точечные рисунки (bitmaps), а не графику Windows. Точечные рисунки требуют больше времени для загрузки клиенту, чем команды GDI, от этого страдает отклик сеанса. Приложения, отображающие точечные рисунки в среде терминального сервера, в лучшем случае ведут себя судорожно, и большей частью полностью непригодны, особенно на медленных соединениях. Хорошей новостью является то, что вам не стоит беспокоиться о людях, пробующих запустить на сервере MetaFrame игру Diablo II. Даже если бы вам удалось ее запустить, люди бы отбросили ее с отвращением еще до того, как первый экран закончит сползать вниз на их дисплее.

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

Вы можете выполнять приложения DOS и Win16 в среде терминального сервера; только они не будут сотрудничать с другими приложениями, как приложения Win32. Приложения DOS вообще не будут работать так, как они работали бы локально на компьютере, выделенном одному человеку. В главе 6 содержится информация о настройке приложений, которая может повысить производительность..

Другие проблемы, которые затронут приложение, функционирующее в среде MetaFrame, могут применяться к любому классу приложений, будь то Win32, Win16 или DOS. Некоторые из этих проблем могут быть выявлены, но иногда вам либо придется к изготовителю приложения за справкой, либо признать поражение и запускать приложение локально. Вероятные виновники включают:

Такова среда сервера. Теперь давайте посмотрим, как лучше как лучше всего упорядочить серверы в фермы и зоны.

Организация ферм и зон MetaFrame XP

В Главе 2 объяснялость, что такое фермы и зоны. Здесь я хотел бы потратить некоторое время на объяснение, как их проектирование влияет на работу фермы и производительность вашей сети и серверов.

Проектирование фермы: одна ферма или несколько?

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

Однако, это не всегда лучший выбор. Если вы используете единственную ферму, то получаете следующие выгоды:

Если вы организовываете ваши серверы MetaFrame в несколько ферм, то получите следующие преимущества:

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

Работа с зонами

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

Во-первых, Citrix рекомендует, чтобы вы включали в одну зону не более 100 серверов. В зависимости от аппаратных средств сервера и активности фермы, коллектор данных может поддерживать более 100 серверов, но коллектор данных для каждой зоны может поддерживать около 70 запросов в секунду. При определении количества коллекторов данных, требуемых для вашей фермы, учтите число людей, использующих ферму в любой момент времени, и как долго они остаются работать (большое количество коротких сеансов создадут большую нагрузку на коллектор, чем небольшое количество продолжительных сеансов), число опубликованных приложений, использующих распределение нагрузки. Как вы можете видеть на вкладке "Использование Выделенного Коллектора Данных", один из способов заключается в том, чтобы позволить коллектору данных сосредоточиться исключительно на своих задачах и оставить обслуживание приложений другим серверам MetaFrame.

Использование Выделенного Коллектора Данных
Если ваша ферма серверов невелика и использует хранилище на базе Access, вам не нужен выделенный коллектор данных - он может быть рабочим сервером MetaFrame. Однако, если сервер, обеспечивающий доступ к хранилищу, сильно загружен, то вы заметите задержки при использовании Citrix Management Console при конфигурировании приложений или информации о лицензиях, долгое время обновления, задержки при запуске службы IMA на серверах-членах, поскольку служба не запустится до тех пор, пока сервер не установит соединение с хранилищем данных. Если вы сталкиваетесь с любой из этих проблем и мониторинг коллектора данных показывает его высокую загрузку, подумайте о выделение коллектора данных и запретите ему принимать соединения ICA. Планируйте выделить один сервер MetaFrame XP в качестве коллектора данных для каждой зоны, которая содержит более 50 серверов.

Используйте Системный Монитор (Performance Monitor на WTS) для наблюдения за использованием центрального процессора и памяти на коллекторе данных, чтобы предотвратить его перегрузку. Если вы ее заметили, то можете уменьшить нагрузку на текущий коллектор данных, разбив текущую зону.

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

Использование режима совместимости для обновлений

Если у вас не слишком много храбрости, вы вряд ли модернизируете всю ферму MetaFrame 1.8 на MetaFrame XP. Скорее всего вы будете делать обновление постепенно. Неприятность состоит в том, что MetaFrame XP и MetaFrame 1.8 использует разные протоколы. Кроме того, они используют разные инструменты - вы не можете управлять сервером MetaFrame 1.8 с помоью Citrix Management Console. Как же они общаются друг с другом?

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

Для совместимости в смешанном режиме Citrix рекомендует, чтобы вы установили последний сервисный пакет на сервер MetaFrame 1.8, доступный для загрузки с http://www.citrix.com/support/. Он вам необходим для получения правильных версий инструментальных средств и сделать работу службы Program Neighborhood должным образом в смешанном режиме.

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

Объединение лицензий MetaFrame for UNIX
Если ваша организация использует MetaFrame 1.8 for Windows и MetaFrame 1.x для ОС UNIX, то вы можете объединить лицензии на подключения для серверов MetaFrame для Windows и MetaFrame for UNIX в пределах одной подсети. Это объединение будет работать с серверами MetaFrame XP, работающих в смешанном режиме, но объединение лицензии не будет работать, если серверы MetaFrame XP работают в "родном" режиме. Когда вы завершаете преобразование в "родной" режим, объединение прекращается, и все лицензии в пуле фермы MetaFrame 1.8 перемещаются в пул лицензий новой фермы MetaFrame XP.
Вы можете обойти это поведение, если разобьете лицензии на две группы: одну для MetaFrame for UNIX, другую для MetaFrame для Windows. Если вы ранее объединили лицензии с MetaFrame for UNIX до миграции перед ваших серверов с MetaFrame 1.8 for Windows на MetaFrame XP, Citrix рекомендует, чтобы вы настроили свои серверы MetaFrame for UNIX в отдельной подсети с достаточным количеством лицензий на подключения, чтобы позволить подключения клиентов. Если вы хотите продолжить совместное использование лицензий с MetaFrame for UNIX после миграции MetaFrame 1.8 на MetaFrame XP, обратитесь к инженерам Citrix.

Резюме

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

 
Глава 2: Основные концепции серверных вычислений с MetaFrame XP  Содержание Глава4. Установка MetaFrame XP