Новую организационную модель
Реорганизация ферм и введения зон не является только косметическими нововведениями. Целью этого является обеспечение более эффективной коммуникации между серверами MetaFrame.
MetaFrame 1.8 для поддержки данных о серверах и опубликованых приложениях в ферме использовал ICA Browser. Эта служба состояла из трех частей: главный броузер, подчиненные броузеры и клиентские системы. Все серверы MetaFrame выполняли службу ICA Browser; броузер использовал направленные пакеты (UDP для сетей TCP/IP) для связи со службами ICA Browser, выполнявшихся на других серверах MetaFrame. Главный броузер поддерживал список обзора, т.е. центральный банк сообщений для фермы. Главный броузер получал его информацию из информации, посылаемой ему подчиненными броузерами фермы, как показано на рисунке:
Пока все серверы, которые должны связываться, находятся в одной подсети, все прекрасно работает. Трудность возникает тогда, когда одни серверы MetaFrame должны связаться с другими серверами, находящимися в другой подсети. Как отмечено ранее, броузеры MetaFrame связываются через UDP, широковещательный протокол без установления соединения. Термин "без установления соединения" UDP означает, что сообщения, посланные с использованием этого протокола, не подтверждаются. Особенно через маршрутизатор - UDP то работает, то нет. (Для работы браузеров вы должны или установить шлюз ICA или открыть на маршрутизаторе порт 1604)
Со вводом FR1 для MetaFrame 1.8 и NFuse отпала необходимость открывать на межсетевом экране порт 1604.
Существуют обходные пути, чтобы сделать более надежной работу браузеров в нескольких подсетях, включая редактирование файла .ICA для указания адреса IP сервера, но эти решения далеки от совершенства. UDP имеет и другой недостаток: он является широковещательным сетевым протоколом, т.е. достаточно "шумным". Сообщение получает один сервер, а слышат его все. Наконец, каждая подсеть в сети MetaFrame должна иметь собственную ферму, которая усложняет управление серверами и опубликованными приложениями, потому что вы не всегда можете поместить все доступные ресурсы в одном месте.
Чтобы улучшить работу своего ПО в больших и распределенных сетях, Citrix в MetaFrame XP изменил способ, которым серверы MetaFrame общаются друг с другом. Во-первых, при работе в "родном" режиме, серверы MetaFrame XP обычно используют для связи службу IMA, ориентированной на использование TCP/IP. Использование TCP/IP не только уменьшает трафик, обеспечивая прямую связь между серверами - связь между серверами-членами и коллекторами данных или между коллекторами данных в различных зонах является двухточечной, но также использует подтверждения приема пакетов. (Я перейду к коллекторам данных буквально через минуту, а пока важно отметить то, что трафик IMA является прямым, в отличии от UDP). Во вторых, серверы MetaFrame больше не полагаются на главный броузер своей фермы для получения информации о других серверах MetaFrame. Вместо этого они полагаются на коллектор данных для своей зоны. Коллектор данных - это функциональный эквивалент главного броузера MetaFrame 1.8. В третьих, из-за введения зон и их коллекторов данных, фермы MetaFrame могут теперь охватывать несколько подсетей и даже разные сети, значительно упрощая управление серверами и пользователями. Конечный результат работает подобно следующей иллюстрации. Ферма, расположенная в отдельном месте, может иметь единственную зону, а широко распределенная ферма может иметь несколько зон, поскольку это сокращает траффик по медленным каналам связи
Как видно, сетевая архитектура MetaFrame XP включает фермы, зоны, коллекторы данных и серверы-члены. В следующих разделах вы увидите, как разные части взаимодействуют друг с другом и что именно они делают..
