Проектирование фермы


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

Проектирование фермы предприятия

Первое что вы должны определить - следует ли создать одну ферму серверов MetaFrame XP, или несколько ферм. В этом разделе мы обсудим факторы, которые вы должны учитывать при выборе.

Проектирование одной фермы

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

Развертывание одной фермы дает следующие преимущества:

Преимущества нескольких ферм:

Развертывание нескольких ферм на одном сайте

Преимущества:

Архитектура IMA облегчает сопровождение нескольких ферм, обеспечивая централизованное управление ими с помощью Citrix Management Console. Все фермы можно администрировать с одного сервера, на котором инсталлирована консоль CMC (ее можно инсталлировать и на других серверах, отличных от MetaFrame). Администратор может указать ферму, к которой следует подключиться, введя имя сервера во время регистрации. Кроме того, можно открыть несколько экземпляров CMC одновременно.

Вы можете использовать Citrix NFuse для назначения пользователям единого интерфейса к приложениям нескольких ферм. Хотя Program Neighborhood создает отдельный набор приложений для каждой фермы, вы можете комбинировать эти приложения в один список NFuse.

Проектирование зон в ферме

Правильное размещение зон в MetaFrame XP очень важно для производительности конечного пользователя. После тщательного тестирования в лаборатории Citrix мы можем дать следующие рекомендации.

Коллектор данных на базе Pentium III 500МГц может поддерживать максимум 190 разрешений в секунду. Число разрешений в секунду напрямую связано с числом хост-серверов, предоставляющих приложения.

При проектирование зоны учитывайте следующее:

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

Развертывание зоны

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

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

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

Если вы устанавливаете серверы в разных подсетях в одной и той же зоне, не используйте имя зоны по умолчанию. Имя зоны по умолчанию основано на Security ID и может быть указано при инсталляции или в файле UnattendedTemplate.txt для быстрого развертывания. Вы можете изменить имя зоны с помощью Citrix Management Console, в Farm Properties.

Использование выделенного коллектора данных

Решение о выделении сервера MetaFrame XP для обслуживания исключительно данных зоны зависит от нескольких факторов:

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

Многоадресные серверы MetaFrame XP

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

Пример фермы с многадресными серверами

Не используйте серверы MetaFrame в качестве маршрутизаторов.

Для успешного запуска MetaFrame XP на многоадресных серверах вам следует вручную настроить локальные таблицы маршрутизации. Хотя Windows автоматически строит таблицу маршрутизации сервера, но полученный в результате порядок привязки сетевых карт и маршруты по умолчанию могут не соответствовать вашим требованиям. Более подробную информацию об изменении шлюза по умолчанию см. раздел "Изменение шлюза по умолчанию"

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

Сервер MetaFrame получает запрос на разрешение адреса от клиента ICA и сравнивает его с локальной таблицей маршрутизации, чтобы найти нужный сетевой интерфейс. Клиент ICA должн иметь машрут к адресу TCP/IP, который возвращает сервер MetaFrame. Это означает, что на многоадресном сервере MetaFrame должна быть правильно настроена таблица маршрутизации.

На рисунке показаны два многоадресных сервера MetaFrame, каждый в подсетях 10.8.1.0/24 и 172.16.1.0/24. Ни один из серверов не настроен на маршрутизацию траффика через свои сетевые интерфейсы.

Следующий процесс описывает то, что происходит при запросе клиента ICA.

  1. Клиент ICA с адресом 10.8.2.20 (ICA01) посылает запрос на разрешение адреса сервера MFSRV01.
  2. Этот сервер имеет адрес 10.8.1.3. Этот сервер имеет также вторую сетевую карту с адресом 172.16.1.3.
  3. ICA01 получил адрес сервера MFSRV01. Клиент ICA01 запрашивает у MFSRV01 приложение, настроенное на балансировку нагрузки.
  4. Теперь клиенту ICA01 надо сообщить адрес наименее загруженного сервера. MFSRV01 определяет, что наименее загружен сервер MFSRV02.
  5. MFSRV02 имеет два адреса - 10.8.1.4 и 172.16.1.4
  6. MFSRV02 определяет исходный адрес ICA01. Затем сервер MetaFrame использует свою таблицу маршрутизации для определения адреса сетевой карты, который следует вернуть клиенту. Если в таблице маршрутизации не нашлось подходящей записи, используется маршрут по умолчанию, автоматически сконфигурированный Windows.
  7. MFSRV01 использует локальную таблицу маршрутизации и выдает правильный ответ - адрес 10.8.1.4, адресуя клиента на сервер MFSRV02.

Настройка таблицы маршрутизации

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

Настройка шлюза по умолчанию

Хотя серверы Windows могут строить несколько маршрутов по умолчанию, используемый маршрут определяется порядком привязки сетевых карт. В нашем примере мы выбрали адрес 10.8.1.1 в качестве шлюза по умолчанию. Однако, в порядке привязки мы должны переместить сетевую карту, работающую на подсеть 10.8.1.0/24 в первую позицию списка.

Для настройки порядка привязки в Windows 2000:

  1. Откройте Start->Control Panel->Network Connections
  2. В меню Advances Settings выберите Advanced
  3. В меню Connections переместите сетевую карту, которая должна выполнять роль шлюза по умолчанию, в первую позицию списка.

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

Если в нашем примере сервер MetaFrame XP получает запрос на вторую сетевую карту (Network 2), которая не является шлюзом по умолчанию и не имеет записи в таблице маршрутизации, то ответ клиенту пойдет по сети Network 1 и вызовет неверный ответ клиенту.

Вы также можете удалить дополнительный шлюз по умолчанию со всех сетевых интерфейсов. Это делается в настройках TCP/IP сервера. Выберем в нашем примере шлюз 10.8.1.1 общим для обоих серверов MFSRV01 и MFSRV02 и удалим шлюз по умолчанию для сетевой карты на подсети 172.16.1.0/24.

Утилита IPCONFIG на сервере MFSRV01 показывает следующее:


Windows IP Configuration
Ethernet adapter Local Area Connection #1:
Connection-specific DNS Suffix . : IP Address. ...........:10.8.1.3 Subnet Mask ...........:255.255.255.0 Default Gateway . . ...:10.8.1.1
Ethernet adapter Local Area Connection #2:
Connection-specific DNS Suffix . : IP Address. ...........:172.16.1.3 Subnet Mask ...........:255.255.255.0 Default Gateway . . ...:
Утилита IPCONFIG на сервере MFSRV02 показывает следующее:

Windows IP Configuration
Ethernet adapter Local Area Connection #1:
Connection-specific DNS Suffix . : IP Address. ...........:10.8.1.4 Subnet Mask ...........:255.255.255.0 Default Gateway . . ...:10.8.1.1
Ethernet adapter Local Area Connection #2:
Connection-specific DNS Suffix . : IP Address. ...........:172.16.1.4 Subnet Mask ...........:255.255.255.0 Default Gateway . . ...:

Добавление статических маршрутов

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

Обратимся снова к рисунку. Без добавления статических маршрутов к MFSRV01 и MFSRV02, клиент ICA02 не сможет подключиться. Запуск команды ROUTE PRINT на сервере MFSRV01 показывает следующее:


==========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 a0 c9 2b f8 dc ...... Intel 8255x-based Integrated Fast Ethernet
0x3 ...00 c0 0d 01 12 f5 ...... Intel(R) PRO Adapter
==========================================================================
==========================================================================
Active Routes:
Network Destination     Netmask    Gateway  Interface Metric
        0.0.0.0         0.0.0.0   10.8.1.1   10.8.1.3 1
       10.8.1.0   255.255.255.0   10.8.1.3   10.8.1.3 1
       10.8.1.3 255.255.255.255  127.0.0.1  127.0.0.1 1
 10.255.255.255 255.255.255.255   10.8.1.3   10.8.1.3 1
      127.0.0.0       255.0.0.0  127.0.0.1  127.0.0.1 1
     172.16.1.0   255.255.255.0 172.16.1.3 172.16.1.3 1
     172.16.1.3 255.255.255.255  127.0.0.1  127.0.0.1 1
   172.16.1.255 255.255.255.255 172.16.1.3 172.16.1.3 1
      224.0.0.0       224.0.0.0   10.8.1.3   10.8.1.3 1
      224.0.0.0       224.0.0.0 172.16.1.3 172.16.1.3 1
255.255.255.255 255.255.255.255   10.8.1.3   10.8.1.3 1
Default Gateway: 10.8.1.1
==========================================================================
Persistent Routes:
None

Сервер MFSRV01 уже настроен со шлюзом по умолчанию 10.8.1.1. Обратите внимание, что когда клиент ICA02 (в сети 192.168.1.0/24) пытается обратиться к MFSRV01, он должен пройти маршрутизатор 172.16.1.1. Для избежания использования другого маршрута на сервере MFSRV01 необходимо настроить статический маршрут к сети 192.168.1.0/24

ROUTE -p ADD 192.168.1.0 MASK 255.255.255.0 172.16.1.1
Тогда ROUTE PRINT на сервере MFSRV01 покажет:
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 a0 c9 2b f8 dc ...... Intel 8255x-based Integrated Fast Ethernet
0x3 ...00 c0 0d 01 12 f5 ...... Intel(R) PRO Adapter
===========================================================================
===========================================================================
Active Routes:
Network Destination     Netmask    Gateway  Interface Metric
        0.0.0.0         0.0.0.0   10.8.1.1   10.8.1.3 1
       10.8.1.0   255.255.255.0   10.8.1.3   10.8.1.3 1
       10.8.1.3 255.255.255.255  127.0.0.1  127.0.0.1 1
 10.255.255.255 255.255.255.255   10.8.1.3   10.8.1.3 1
      127.0.0.0       255.0.0.0  127.0.0.1  127.0.0.1 1
     172.16.1.0   255.255.255.0 172.16.1.3 172.16.1.3 1
     172.16.1.3 255.255.255.255  127.0.0.1  127.0.0.1 1
   172.16.1.255 255.255.255.255 172.16.1.3 172.16.1.3 1
    192.168.1.0   255.255.255.0 172.16.1.1 172.16.1.3 1
      224.0.0.0       224.0.0.0   10.8.1.3   10.8.1.3 1
      224.0.0.0       224.0.0.0 172.16.1.3 172.16.1.3 1
255.255.255.255 255.255.255.255   10.8.1.3   10.8.1.3 1
Default Gateway: 10.8.1.1
===========================================================================
Persistent Routes:
Network Address Netmask       Gateway Address Metric
192.168.1.0     255.255.255.0 172.16.1.1      1

Аналогично настройте MFSRV02. Когда таблицы будут готовы, клиенты ICA могут сделать ping обоих серверов.

Теперь каждый сервер MetaFrame может правильно определять, какие сетевые интерфейсы использовать для соединений ICA. Клиент ICA01 получит адреса 10.8.1.3 и 10.8.1.4, а клиент ICA02 получит адреса 172.16.1.3 и 172.16.1.4

Рекомендации к хранилищу данных

Приведенные ниже рекомендации содержатся также в руководстве администратора MetaFrame XP.

  Небольшое Среднее Большое Предприятие
Число серверов 1-50 25-100 50-100 более 100
Пользователей < 150 < 3000 < 5000 > 3000
Приложений < 100 < 100 <500 < 2000

Выбор СУБД для хранилища данных также заисит от типа вашей среды. При выборе хранилища вы должны учитывать:

Для выбора базы данных в качестве хранилища данных учитыайте следующие аспекты:

Oracle Parallel Server включает дополнительные функции, такие как распределение нагрузки входящих запросов.

Хранилище данных следует расплагать на дисковых массивах RAID.

Использование реплицируемых хранилищ

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

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

Аспекты репликации

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

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

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

Репликация базы создает дополнительный траффик в сети. Частота обновлений определяется настройками базы данных, а не MetaFrame XP.

Требования к хранилищу данных

В этом разделе мы обсудим минимальные требования к четырем продуктам СУБД - Microsoft Access, Microsoft SQL Server, Oracle и IBM DB2. Хотя MetaFrame XP использует ODBC, остальные ODBC-совместимые СУБД не поддерживаются в MetaFrame XP.

В MetaFrame XP Feature Release 2 вы можете использовать следующие СУБД:

• Microsoft Access Jet Engine 4.x
• Microsoft SQL Server 7.0 with SP2 and SQL Server 2000
• Oracle Server 7 (7.3.4) for NT
• Oracle Server 8 (8.0.6) for NT
• Oracle Server 8i (8.1.5, 8.1.6) for NT and UNIX
• Oracle Server 9i (9.0.1) for NT
• IBM DB2 with FixPak 5 for NT

В следующей таблице приведены версии поддерживаемых клиентов

СУБД Версия драйвера
SQL 7.0 Enterprise for NT MDAC 2.5 SP1 3.70.0820
SQL 7.0 Enterprise for NT MDAC 3.70.0821
SQL 2000 Enterprise for NT MDAC 2.5 SP2 3.70.0961
SQL 2000 Enterprise for NT MDAC 2.7 2000.81.7713.00
SQL 2000 Enterprise for NT MDAC 2.6 SP1 2000.80.380.0

Важно. Oracle Client v.8.1.5 не поддерживается. Обновите его как минимум до 8.1.55

Кленты Oracle 8.1.7 и 8.1.7.2 нуждаются в изменении реестра до установки MetaFrame XP 1.0. Это не относится к MetaFrame XP Feature Release 2. См. статью CTX949726.

Microsoft Access

При выборе Use a local database as the data store во время инсталляции приводит к выбору в качестве СУБД Microsoft Access. ODBC использует для доступа к Access использует Microsoft Jet Engine 4.x.

Минимальные требования

Аутентификация
Имя пользователя и пароль для файла Mf20.mdb по умолчанию citrix/citrix. Чтобы сменить пароль к базе данных, используйте команду dsmaint config /pwd:newpassword при работающей службе IMA.

Автоматическое резервирование
При каждом успешном останове службы IMA существующий файл Mf20.mdb резервируется, упаковывается и копируется в Mf20.unk. При каждом успешном запуске службы IMA она проверяет существование Mf20.bak и переименовывает Mf20.unk в Mf20.bak. Таким образом Mf20.bak содержит правильную базу данных фермы. Этот файл используется при выполнении команды dsmaint recover. Файл Mf20.mdb и его резервные копии находятся в каталоге %ProgramFiles%\Citrix\Independent Management Architecture.

Важно.Всегда запускайте dsmaint backup перед выполнением dsmaint recover. Не запускайте dsmaint recover если не существует файл mf20.bak, поскольку эта команда удаляет mf20.mdb

Замечания

Microsoft SQL Server

Минимальные требования

Конфигурация сервера

Аутентификация и безопасность

Использование сокетов вместо именованных каналов

Для подключения к Microsoft SQL Server предпочительно использовать сокеты TCP/IP. Передача данных более прямолинейна, а нагрузка меньше.
Named Pipes является протоколом аутентификации. При попытке пользователя открыть соединение с сервером SQL с использованием Named Pipes, срабатывает аутентификация Windows NT. Сокеты TCP/IP не требуют аутентификации Windows NT для установления соединения, но предусматривают аутентификацию по имени пользователя и паролю с SQL после установления соединения. Это исключает возможность появления ошибки, когда SQL Server и сервер MetaFrame не имеют правильных доверительных отношений в домене. Для использования сокетов TCP/IP сделайте следующее:

Для создания источника данных при установке MetaFrameXP

При выборе в качестве СУБД Microsoft SQL, появится предложение создать новый источник данных.

  1. Введите описание источника данных и щелкните Next
  2. Выберите между NT Authentication и SQL Server Authentication.
  3. Щелкните Client Configuration.
  4. Выберите TCP/IP из доступных сетевых библиотек. Щелкните OK.

Для изменения имени источника данных (DSN) после установки:

  1. Откройте в панели управления ODBC Data Source Administrator.
  2. Выберите закладку File DSN.
  3. Ныберите C:\Program Files\Citrix\Independent Management Architecture.
  4. Выберите MetaFrame DSN, созданный перед установкой. Щелкните Configure
  5. В диалоге "Microsoft SQL Server DSN Configuration" щелкните Next. Выберите Client Configuration.
  6. Выберите из списка библиотек TCP/IP. Щелкните OK, затем Next, и затем Finish.
  7. Перезагрузите сервер MetaFrame XP

Распределенные базы данных

MetaFrame XP поддерживает распределенные базы данных. Они полезны в случае затора в БД из-за частых запросов на чтение. Для создания распределенных БД Microsoft SQL Server использует репликации. MetaFrame XP нуждается в целостности данных в нескольких БД. Для записи в базу используется алгоритм двухфазной записи. При настройке Microsoft SQL Server на двухфазную запись, вы должны использовать модель Immediate Updating Subscriber.

Для настройки распределенной среды в существующей ферме MetaFrame XP:

  1. Настройте Publisher, Distributor и Subscribers (удаленные сайты) с использованием Microsoft SQL Server Enterprise Manager.
  2. Выполните команду dsmaint publishsqlds. Это выполнит необходимые операторы SQL для создания опубликованных статей на текущем сервере Microsoft SQL Server (Publisher).
  3. Настройте удаленные сайты (Subscribers) на подписку на опубликованные статьи, созданные на предыдущем этапе.

Использование Oracle

Минимальные требования

Конфигурация сервера

При использование одного сервера Oracle для нескольких ферм, создавайте отдельный tablespace для каждой фермы, с собственной парой логин/пароль.

Настройка клиента
При использовании клиента Oracle 8.1.7 вы должны его настроить для правильной работы с MetaFrame XP. Драйвер Oracle 8.1.7.0 устанавливает функцию безопасности, называемую NT Security (NTS), которая использует учетные данные Windows NT для аутентификации на сервере Oracle. Поскольку служба IMA настроена на учетную запись "System", IMA не может подключиться к Oracle при включенной NTS. В этом случае IMA сообщает код ошибки 2147483649.

Эти шаги не нужны при использовании клиента Oracle 8.1.6, поскольку он не использует NTS
Сделайте следующее:
  1. Установите клиента Oracle 8.1.6.x, а затем обновите до 8.1.7.x.
  2. Запустите Net8 Assistant.
  3. Выберите Net8 Configuration > Local > Profile
  4. Выберите Oracle Advanced Security.
  5. Выберите закладку Authentication
  6. Удалите NTS из списка Selected Methods
  7. Установите MetaFrame XP

Если вы для миграции от Access к Oracle 8.1.7 используете DSMAINT, служба IMA не сможет запуститься, поскольку драйвер Oracle 8.1.7.0 заменяет метод аутентификации. Для избежания этого при переходе от Access к Oracle 8.1.7 запретите функцию Oracle NTS:

  1. Запустите Net8 Assistant.
  2. Выберите Configuration > Local > Profile
  3. Выберите Oracle Advanced Security.
  4. Выберите закладку Authentication
  5. Удалите NTS из списка Selected Methods, если он там есть.

Обратите внимание, что клиент Oracle 7.3.4 не поддерживается.

Аутентификация и безопасность

Устранение сбоев
Oracle позволяет поддерживать запасную базу данных для быстрого восстановления в случае сбоя. Запасная база данных содержит копию производственной. В случае поломки производственной базы, вы можете открыть запасную базу. Важные концепции восстановления:

Распределенные базы данных
MetaFrame XP поддерживает распределенные базы данных. Они полезны при возникновении узкого места из-за слишком частых запросов на чтение. Для создания распределенных баз Oracle исползует репликации.
Для уменьшения загрзузки одиночного сервера БД, установите реплики "чтение/запись" и расновмерно распределите серверы фермы по основной БД и репликам. MetaFrame XP требует целостности данных в нескольких базах данных. Для записи в БД используется двухфазный алгоритм. Использование Oracle для распределенных баз данных требует следующего:

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

Использование реплицируемого хранилища данных

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

Задержки в WAN

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

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

В случае задержек:

Оптимизация хранилища данных

Для повышения производительности сервера баз данных существуют несколько способов. В больших фермах с мощными серверами БД, узким местом может стать сеть. В этом случае Citrix рекомендует использовать адаптивную балансировку нагрузки. Подключайте сервер БД напрямую к коммутатору, а не к концентратору, для избежания коллизий. Тестирование показало, гигабайтный Ethernet показывает намного лучшую производительность, чем 100-Мбит.

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

При адаптивной балансировке нагрузки для увеличения пропускной способности используются несколько сетевых адаптеров. Все адаптеры должны быть подключены к одному коммутатору. После добавления адаптеров они собираются в группу (team) и представляют один виртуальный адаптер с повышенной пропускной способностью. Например, группа из 4-х карт Fast Ethernet, настроенные на full-duplex, дают максимальную скорость передачи 400Mbps и 100Mbps на прием, давая в общей сложности ширину канала 500Mbps. Один адаптер настраивается на прием и передачу, а остальные только на передачу.

Кроме адаптивной балансировки, вы можете настроить Fast Ether Channel (FEC) для повышения производительности как принимающего, так и передающего каналов между сервером и коммутатором. Например, группа FEC из четырех адаптеров Fast Ethernet full-duplex дают суммарную максимальную скорость передачи 400Mbps и суммарную скорость приема 400Mbps, что в результате дает пропускную способность 800Mbps. На прием/передачу настраиваются все адаптеры. FEC работает только со специальными FEC-коммутаторами, поддерживающими такую функцию. Программа коммутатора анализирует загрузку каждого адаптера и равномерно распределяет сетевой траффик по адаптерам.

Сети хранения данных (SAN)

SAN - это выделенная высокоскоростная сеть. Она отделена и отличается от LAN, которая предоставляет совместный доступ к данным, расположенным на внешних дисковых носителях. SAN несет траффик только между серверами и дисковыми массивами, в то время как LAN несет остальной траффик - почту, файлы, печать, веб.

Fibre Channel Technology Fibre Channel - это стандарт двунаправленных коммуникаций, включающий сериализацию SCSI через один кабель, соединяющий серверы, системы хранения данных, рабочие станции, коммутаторы и концентраторы. Fibre Channel имеет следующие ывозможности:

Технология Fibre channel может использовать одну из сетевых технологий:

SAN обычно включают в себя следующие аппаратные компоненты:

 

Сценарии развертывания ферм

Сокращения: DS означает (DataStore) (ХД - Хранилище данных); DC - Data Colletor (КД - коллектор данных).

Небольшая ферма. Локальное размещение

Этот сценарий описывает одну ферму, где все серверы находятся в одном месте и настроены следующим образом:

Citrix рекомендует следующее:

Большая ферма. Локальное размещение

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

Citrix рекомендует для этого сценария:

Небольшая ферма. Распределенные сайты

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

Citrix рекомендует:

Небольшая ферма. Удаленные сайты

 

Citrix рекомендует:

Большая ферма. Несколько центров данных

В этом сценарии мы имеем большую ферму, где все серверы находятся в большом центре данных.


Citrix рекомендует:

Большая ферма - региональные сайты

 

Citrix рекомендует:


В начало