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

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

С приобретением серверами Web существенно важного значения для все большего числа бизнес-процессов производительность и готовность этих средств становятся обстоятельством наиважнейшим. Улучшить и то и другое можно, в частности, за счет средств распределения нагрузки.

Что касается производительности, такие продукты позволяют постепенно наращивать мощность узлов Web. Но альтернатива - покупка высокопроизводительного сервера, рассчитанного на пиковые нагрузки, - может оказаться слишком дорогой. К тому же эти расходы не оправдывают себя, особенно если уровень нагрузки сильно колеблется во времени. Так, например, в период проведения специальных рекламных акций количество обращений к узлу Web увеличивается от 100 до 1000 раз по сравнению со среднестатистическим значением. Сервер старшего класса, а только такой способен справиться с подобным наплывом посетителей, может стоить сотни тысяч (если не миллионы) долларов. Однако этот монстр будет практически бездействовать, когда трафик снова войдет в нормальное русло.

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

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

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

Как известно, Domain Name System (DNS) позволяет до известной степени абстрагироваться от численных IP-адресов за счет имен хостов, а примитивное распределение нагрузки можно реализовать путем соответствующей настройки DNS и BIND. Все данные исходного сервера следует просто скопировать на несколько серверов и поставить их

IP-адреса в соответствие одному имени хоста. Тогда DNS (по крайней мере в ее сегодняшних вариантах) будет обрабатывать все IP-адреса последовательно.

Такую схему часто называют DNS с циклическим обслуживанием. На практике она создает больше сложностей, чем дает преимуществ. Так как DNS не имеет обратной связи с серверами, нередко она предоставляет адрес занятого или отключенного сервера. Записи DNS часто кэшируются или тиражируются в Internet, поэтому удаленные клиенты могут разрушить систему распределения нагрузки в результате использования запомненного IP-адреса. Кроме того, пакеты могут направляться на отключенный сервер (пока испорченные данные не переполнят Internet).

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

Более многообещающим подходом к распределению нагрузки является установка на пути входного трафика устройства трансляции адресов. В этом случае вовне (и DNS в том числе) известен своего рода виртуальный IP-адрес, и устройство распределения нагрузки перенаправляет поступающие запросы на обслуживание реальному серверу в соответствии с некоторыми настраиваемыми правилами (см. Рисунок 1).

Рисунок 1.
Большинство средств распределения нагрузки предлагает окружающему миру некий виртуальный IP-адрес и затем распределяет трафик по реальным IP-адресам.

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

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

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

Некоторые интегрированные аппаратные средства распределения нагрузки представляют собой ни что иное как выделенные центральные процессоры общего назначения, работающие под ОС UNIX с двумя интерфейсами Ethernet 10/100 Мбит/с. Другие - это коммутаторы на базе ASIC, оснащенные центральным процессором для выполнения маршрутизации в соответствии с принятыми правилами. Во многих случаях устройство распределения нагрузки является самой уязвимой частью всего узла Web независимо от того, что оно собой представляет - выделенное устройство или сервер общего назначения, поэтому наличие дополнительных источников питания и вентиляторов приобретает немаловажное значение.

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

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

Требование однородности близко связано с так называемой единицей обслуживания (unit-of-service), запросы на которое распределитель нагрузки переадресует серверам. Если такими единицами являются индивидуальные IP-пакеты, и они распределяются между действительными (а не виртуальными) IP-адресами, то все серверы должны иметь идентичные данные. Если это TCP-соединения (а пункт назначения определяется как конкретный порт данного IP-адреса), тогда некоторые сервисы, например http, ftp или smtp, могут направляться только на конкретные серверы, в то время как другие - распределяться по множеству оставшихся серверов сети. Копировать на все серверы одни и те же данные вовсе не обязательно, однако при этом все различия в данных на разделяемых серверах должны быть учтены в предопределенных правилах, дабы избежать направления запросов на те машины, где они не могут быть выполнены.

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

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

Кроме того, если распределитель нагрузки манипулирует TCP-соединениями или сеансами HTTP, то он может не справиться с пакетами UDP, какими оперируют многие приложения потокового аудио и видео. SNMP и Network File System (NFS) также зависят от UDP.

Помимо всех перечисленных разработчикам распределителей нагрузки предстоит решить проблему учета состояний. Просмотр страницы Web, состоящей из многочисленных текстовых и графических файлов, предполагает установку TCP-соединений для каждого файла. Мультимедийные файлы, исполняемые коды, сценарии CGI также требуют собственного TCP-соединения. Если речь идет о статических файлах и данные тиражируются на несколько серверов, то неважно, какой из серверов ответит на запрос. Однако некоторые приложения предполагают сохранение сервером Web определенного состояния для ряда соединений. Так, если пользователь заполняет и посылает форму, сервер может ответить, что требуемое поле отсутствует. Так как требовать от клиентов заполнять одну и ту же форму по несколько раз вряд ли разумно, информация о ней должна храниться на сервере, пока транзакция не будет окончательно завершена. Если браузер пользователя соединяется с другим сервером, а не с тем, кому он передал неверно заполненную форму, то данных по форме на нем не будет.

Кроме того, сохранение состояния необходимо при поддержке таких протоколов, как Transport Layer Security (TLS), или SSL (Secure Sockets Layer), как он назывался ранее. Шифрованные соединения требуют, чтобы при повторном запросе браузер связывался с тем же сервером.

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

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

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

Дольше других средствами распределения нагрузки занимается Cisco Systems. Компания контролирует, пожалуй, наибольшую долю рынка, а настоящим его долгожителем является продукт LocalDirector. Cisco по праву считается ведущим поставщиком маршрутизаторов, благодаря чему, в частности, и получила преимущество над другими производителями таких продуктов. Это, однако, нельзя понимать так, что продукт Cisco для распределения нагрузки лучше работает с маршрутизаторами. Конечно, администраторам, знакомым с предлагаемым интерфейсом командной строки и Internetwork Operating System (IOS), проще справиться с задачами конфигурирования, чем их неосведомленным коллегам, однако операции распределения нагрузки LocalDirector прозрачны для маршрутизаторов, которые, собственно, и поставляют им пакеты.

LocalDirector представляет собой программный и аппаратный комплекс на базе микропроцессоров Intel Pentium и работает под управлением разновидности IOS компании Cisco. Устройство имеет два интерфейса: порты Ethernet 10/100 Мбит/с, которыми оно оборудуется по умолчанию, и, кроме того, по желанию, интерфейс FDDI. Одному из интерфейсов присваивается один (или более) виртуальный IP-адрес. (На самом деле вы можете даже задать сочетание TCP-порт/IP-адрес так, чтобы трафик для определенного порта, например порта 80 в случае HTTP, направлялся бы на одну группу серверов, в то время как остальной трафик переключался бы на другую.) В качестве виртуального адреса выступает тот, что зарегистрирован в DNS, на этот адрес приходит весь трафик узла. На другом интерфейсе определяется реальный IP-адрес для каждого из серверов. Затем виртуальный адрес (или адреса) связывается с реальными адресами.

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

Так как LocalDirector служит в качестве моста для трафика, все действительные IP-адреса должны находиться в одной подсети; это значит, что LocalDirector не может обслуживать несколько узлов. Для выхода из положения Cisco предлагает DistributedDirector. Этот сервер DNS выдает разные IP-адреса в ответ на запрос о разрешении имени в соответствии с определяемыми по таблице маршрутизации расстояниями между пользователем и потенциальным местом назначения.

Кроме того, при работе с LocalDirector необходимо иметь в виду, что эта система игнорирует направленные на виртуальный адрес UDP-пакеты, поэтому продукт не годится для разделения мультимедийной нагрузки. С другой стороны, адресованный на реальный IP-адрес трафик UDP передается нормально. При цене в 14 тыс. долларов LocalDirector относится скорее к разряду продуктов старшего класса.

HolonTech - это начинающая компания, 40% акций которой владеет NEC. Первым продуктом новичка стал скоростной маршрутизатор на базе ASIC, получивший название HyperFlow SP800. Он имеет восемь полнодуплексных портов 10/100 Мбит/с. Внешнему миру система предоставляет один виртуальный IP-адрес, а пакеты распределяются между тиражируемыми серверами по выделенным линиям. Таким образом, продукт может обеспечивать значительно большую совокупную пропускную способность, чем те, в которых серверы разделяют 100-мегабитное соединение. (По заявлениям представителей компании, их система может обеспечивать совокупную пропускную способность, в девять раз превышающую по аналогичному показателю любую другую систему распределения нагрузки.)

Благодаря тому что единицей обслуживания являются IP-пакеты, а не TCP-соединения, HyperFlow SP800 автоматически обрабатывает UDP (и другие отличные от TCP протоколы семейства IP) без каких-либо затруднений. Серверы могут работать под любой ОС, если на них загружены одинаковые данные. HyperFlow SP800 стоит 25 тыс. долларов.

Программно-аппаратное устройство Big/ip, предлагаемое компанией F5 Labs, подобно LocalDirector производства Cisco, имеет два интерфейса Ethernet 10/100 Мбит/с и возможность подключения FDDI. Стоимость Big/ip 25 тыс. долларов для неограниченного числа пользователей.

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

Существенное различие между Big/ip и LocalDirector состоит в том, что Big/ip может обрабатывать трафик UDP; практически он представляет собой маршрутизатор, в то время как LocalDirector - мост. Общим для продуктов всех трех компаний является отказ от агентов, работающих на серверах.

С другой стороны, LocalDirector выгодно отличается от Big/ip тем, что он может отображать несколько виртуальных IP-адресов в один действительный IP-адрес, благодаря чему один сервер может содержать несколько доменов. Big/ip поддерживает лишь циклический алгоритм и принцип "наименьшего числа соединений".

Продукт компании RADWARE под названием Web Server Director Pro также представляет собой IP-маршрутизатор. Подобно другим маршрутизаторам, он обслуживает серверы в разделяемом пуле, даже если они не находятся в локальной подсети. Он может иметь два/четыре порта Ethernet на 10 Мбит/с или два порта Ethernet на 100 Мбит/с, а несколько устройств можно подключить последовательно друг за другом. Продукт выделяется своей высокой производительностью, удобной графической утилитой управления, а также интеграцией на базе SNMP с OpenView компании HP и TME NetView, предлагаемой Tivoli. Кроме того, этот продукт чрезвычайно дешев - версия с Fast Ethernet стоит 10 990 долларов. (Web Server Director Pro признан нашим изданием продуктом года в категории "Оборудование распределения нагрузки".)

Кроме того, RADWARE предлагает Web Server Director for Distributed Sites для распределения доступа между несколькими узлами из любой точки глобальной сети.

Аппаратный продукт компании HydraWeb Technologies, названный Load Manager (практически ни что иное, как маршрутизатор), может перенаправлять любой трафик TCP или UDP на действительные IP-адреса тиражированных серверов. Он единственный из аппаратных средств балансировки предусматривает в качестве дополнительной возможности агентов на серверах для сбора подробной информации об их загруженности. Благодаря удобству использования и простоте конфигурации Load Manager позволяет администраторам легко добавлять весовые коэффициенты в правила распределения нагрузки. Load Manager для четырех серверов стоит 7990 долларов.

Компания Flying Fox Computer Systems представляет свой продукт Fox Box как шлюз доступа в Internet и распределитель нагрузки. В зависимости от конфигурации, он может выполнять функции монитора трафика, а также фильтра пакетов и брандмауэра - и все это наряду с распределением нагрузки. В сущности это ПК с процессором Pentium/133 МГц и оперативной памятью объемом 32 Мбайт, сконфигурированный как маршрутизатор между двумя интерфейсами Ethernet на 10/100 Мбит/с. Как большинство аппаратных устройств, он может перенаправлять трафик TCP и UDP на действительные IP-адреса групп серверов. Средств передачи своих функций другому распределителю нагрузки на случай сбоя он не имеет. Стоимость продукта - 7450 долларов.

Компания Resonate Software выпускает три продукта, каждый из которых олицетворяет собой определенный уровень распределения нагрузки.

Система Central Dispatch - это программный продукт, работающий на любых серверах NT или Solaris. С точки зрения архитектуры - это не мост, коммутатор или маршрутизатор, как рассмотренные выше продукты. Central Dispatch определяет виртуальный IP-адрес, рекламируемый с помощью DNS, но после того, как Central Dispatch Primary Scheduler перенаправляет входящий трафик на действительный IP-адрес (на основании некоторых правил), сервер взаимодействует непосредственно с пользователем в продолжении соединения (в течение сеанса или транзакции, если соединение задано как "липкое").

Таким образом, в отличие от аппаратных средств, Primary Scheduler не входит в маршрут данных, после того как он перенаправит трафик на конкретный сервер. Primary Scheduler может быть и сервером данных, и диспетчером. Secondary Scheduler обеспечивает защиту от сбоев, принимая на себя функции Primary Scheduler.

Для получения исчерпывающей информации с целью наиболее рационального распределения нагрузки Central Dispatch опирается на агентов на каждом сервере. Эти агенты могут собирать такую информацию, как сведения о загрузке центрального процессора, и учитывать ее при распределении нагрузки. Продукты, использующие только информацию на базе протоколов, не столь хороши для распределения нагрузки, как задействующие агентов. Кроме того, Central Dispatch может перенаправлять трафик на основании конкретных URL. Поскольку программное обеспечение настроено на работу с URL, серверы необязательно должны содержать идентичные данные, так что вы можете тиражировать только наиболее часто посещаемые страницы и хранить только одну копию редко запрашиваемых материалов.

Второй программный продукт компании Resonate, названный Application Dispatch, перенаправляет запросы с сервера Web на ряд внутренних устройств, таких как серверы базы данных и обработки транзакций (см. Рисунок 2). Он способен обрабатывать вызовы всех наиболее распространенных API, в том числе CGI, Netscape API (NSAPI), Internet Services API (ISAPI) и Apache. Кроме того, Application Dispatch может устанавливать приоритеты обслуживания.

Рисунок 2.
При обращении серверов Web к внутренним серверам за данными или другими ресурсами, распределители нагрузки специального назначения позволяют повысить производительность.

Global Dispatch - третий продукт, предлагаемый Resonate, - это DNS-сервер для организации обратной связи с узлами, где работает Central Dispatch, и разрешения доменных имен в зависимости от доступности серверов (см. Рисунок 3). Стоит повторить, что узлы, располагающие агентами, предоставляют более качественную информацию о готовности, нежели та, что базируется на метрике маршрутизаторов и числе промежуточных устройств.

Рисунок 3.
Global Dispatch компании Resonate представляет собой динамически обновляемую в соответствии с нагрузкой серверов DNS.

Продукты стоят соответственно: Central Dispatch - 10 тыс. долларов, Application Dispatch - 4 тыс. долларов, а цены на Global Dispatch начинаются с 35 тыс. долларов.

Продукт WebSpective компании Atreve Software по архитектуре подобен Central Dispatch. Он работает на серверах Windows NT или Solaris и использует агентов на каждом сервере Web для получения информации о таких параметрах, как загрузка центрального процессора, свободное дисковое пространство, использование потоков и т. п. для управления компонентом, задачей которого является формирование динамических таблиц критериев трафика. В отличие от Central Dispatch, продукт располагает модулем Interceptor (не являющимся частью менеджера) для направления сеансов HTTP на сервер Web в соответствии с определенными правилами.

Где Central Dispatch назначает серверам TCP-соединения, там WebSpective манипулирует только сеансами HTTP; эта процедура бессмысленна для других протоколов, таких как ftp. WebSpective использует NSAPI или ISAPI для взаимодействия с серверами Web, поэтому этот продукт годится только для Web-серверов, использующих API компаний Microsoft или Netscape. Еще одно различие с Central Dispatch состоит в возможности задействовать перенаправление HTTP. По существу браузер клиента получает сообщение, что файл не найден, но этот браузер может соединиться через другой адрес. В принципе данный процесс не столь эффективен, как подход Resonate, при котором система пытается непосредственно установить соединение TCP. Цена WebSpective - 20 тыс. долларов.

Продукт компании IBM, названный Interactive Network Dispatcher, цена которого составляет всего 1500 долларов за каждый обслуживаемый сервер, занимает нижнюю часть ценового спектра - по крайней мере для узлов с числом серверов не более десяти. Разумеется, это чисто программный продукт, и, оценивая стоимость всей системы, вам следует учесть еще и стоимость сервера, на котором продукт будет работать. Подобно Central Dispatch, он передает соединения TCP и UDP серверу Web, и на этом его работа заканчивается - обратный трафик через Interactive Network Dispatcher не проходит. Как и в случае HydraWeb Load Manager, вы можете, при желании, использовать агентов, однако и без них продукт сделает все, на что способен. IBM предлагает версии Interactive Network Dispatcher для AIX, Solaris и Windows NT.

Компания Silicon Graphics представляет WebForce Director для распределения сеансов HTTP. Подобно Central Dispatch продукт распознает URL и определяет, к чему относится запрос - к статичной странице или к исполняемому событию, если это, к примеру, вызов CGI. В отличие от Central Dispatch продукт SGI может выполнять эту работу без помощи агентов на серверах Web. К сожалению, высокая производительность, которую продукт демонстрирует на статичных файлах, вовсе не свойственна ему при обслуживании вызовов на исполнение приложений.

Продукт представляет собой программный пакет, но работает только на серверах SGI. Его стоимость составляет 5000 долларов на Origin 200 и 7500 долларов на Origin 2000.

Есть и еще один продукт этого рода, ClusterCATS (CATS расшифровывается как интеллектуальное содержимое, приложения и транзакции - Content, Application & Transaction Smart), который поставляет компания Bright Tiger. Это также ПО, однако во многом оно непохоже на уже рассмотренные продукты. Распределение нагрузки - это только одна из его многочисленных функций. Кроме того, продукт обеспечивает поиск ресурсов, распространение и синхронизацию информационного наполнения. ClusterCATS работает только на Windows NT и манипулирует только HTTP.

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

В отличие от всех других распределителей нагрузки, ClusterCATS не имеет единого виртуального IP-адреса для внешнего мира. Составляющие ClusterCATS серверы являются равноправными, причем каждый из них ведет таблицу загрузки всех остальных серверов. Представители Bright Tiger утверждают, что эта децентрализованная модель масштабируется до "десятков серверов", однако очевидно, что чем больше кластер, тем большая нагрузка по контролю возлагается на каждый сервер. В то время как большинство производителей стараются по мере возможности отказаться от DNS с циклическим обслуживанием, ClusterCATS отлично дополняет данный алгоритм.

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

Хотя ClusterCATS может произвести впечатление не слишком элегантного и эффективного распределителя нагрузки, это хорошее решение для тех узлов, где требуется управление информационным обеспечением и приложениями, а также трафиком, поскольку решает все эти задачи сразу. ClusterCATS признан нашим изданием лучшим продуктом года в категории "Корпоративное управление Web".

Когда заходит речь о кластерах, часто имеются в виду системы общего назначения, распределяющие исполняемые потоки между индивидуальными компьютерами в сети в целях повышения производительности и готовности. Таким системам общего назначения необходимы ориентированные на кластеры ОС и специально разработанные приложения. благодаря свойствам TCP/IP, HTTP и программного обеспечения серверов Web, рассмотренные выше продукты можно использовать для создания кластеров специального назначения, способных справиться со значительными колебаниями нагрузки и позволяющими добиться отказоустойчивости Web. Эта группа продуктов появилась всего два года назад, но, несмотря на свою историю, она отличается не только большой представительностью, но и наличием замечательных, многофункциональных продуктов.

Стив Штайнке - старший редактор Network Magazine. С ним можно связаться по адресу: ssteinke@mfi.com.

Cisco Systems http://www.cisco.com
HolonTech http://www.holontech.com
F5 Labs http://www.f5labs.com
RADWARE http://www.radware.co.il
HydraWeb Technologies http://www.hydraweb.com
Flying Fox Computer Systems http://www.flyingfox.com
Resonate http://www.resonate.com
Atreve Software http://www.atreve.com
IBM http://www.ibm.ru
Silicon Graphics http://www.sgi.com
Bright Tiger Technologies http://www.brighttiger.com