Философия распределения нагрузки

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

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

Тем не менее я должен признаться, что не собирался писать статью о распределителях нагрузки. Я взялся за эту тему, только чтобы поддержать сложившиеся у меня превосходные отношения с Network Magazine и его редакцией. Однако статей об определенных категориях продуктов я обычно сторонюсь, как чумы. Мне больше по душе рассмотрение передовых современных тенденций бизнеса или подробное изучение чьего-либо практического опыта. А тут какие-то распределители нагрузки! Кому интересно писать (а тем более читать) 3,5 тысячи слов о железяке, вся работа которой состоит в доставке пакетов на наилучший из доступных серверов?

Однако, вопреки моим сомнениям, эта тема оказалась действительно интересной.

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

Например, распределение нагрузки не ограничивается одной группой серверов. Многие распределители нагрузки способны теперь осуществлять глобальное (в противовес локальному) распределение, а также переводить трафик на множество тиражируемых узлов в других точках Internet — нечто подобное точкаком реализуют в рамках своих стратегий обеспечения отказоустойчивости и производительности. Кроме того, распределители нагрузки можно развернуть на 180о, иными словами, они позволяют эффективно распределять запросы от внутренних пользователей сети между брандмауэрами и посредниками. Они позволяют также предоставить приоритетное обслуживание важным клиентам. (Краткую классификацию распределителей нагрузки смотри во врезке «Таксономия распределителей нагрузки».)

По сути, разнообразие и функциональность современных технологий распределения нагрузки делают сам термин «распределение нагрузки» несколько устаревшим. Марк Гувер, ведущий эксперт в занимающейся анализом рынка компании Acuitive, предпочитает термин «виртуальное управление ресурсами» (Virtual Resource Management, VRM). Как он формулирует: «Если вы хотите, чтобы шесть серверов Windows NT и два сервера Solaris выглядели как один большой сервер Web, или чтобы три маршрутизатора выглядели как один большой маршрутизатор, или чтобы несколько брандмауэров, устройств VPN либо кэширующих proxy-серверов выглядели как одно большое устройство, то решением является VRM».

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

Распределители нагрузки появились потому, что сети оказались быстрее систем, которые они связывают. Их применение позволяет «мультиплексировать» вычислительные ресурсы систем и таким образом устранить узкие места, возникающие, когда несметное количество проносящихся по быстрому соединению Ethernet пакетов обрушивается на сервер Web. Распределители нагрузки первого поколения представляли собой, по сути, циклические реализации DNS для распределения сеансов HTTP между несколькими хостами IP. Благодаря наличию некоторых базовых возможностей ping эти решения позволяли избегать направления запросов об открытии сеансов на отказавшие серверы — таким образом, они вносили элемент отказоустойчивости в многосерверные инсталляции.

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

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

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

ПРИНЦИПЫ РАСПРЕДЕЛЕНИЯ

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

Правильный баланс. Распределители нагрузки могут узнать о состоянии внутренних ресурсов посредством: 1) оценки быстроты ответа сервера на реальные запросы и генерируемые самим распределителем тестовые запросы; 2) получения данных от резидентного агента управления на сервере; 3) получения данных и предупреждений от программного обеспечения управления независимых разработчиков и/или «доморощенных» сценариев.

Однако, как говорило пугало в «Волшебнике страны Оз», «одни люди выбирают одну дорогу, а другие — другую». «Благодаря использованию своей собственной технологии агентов мы имеем постоянную возможность расширять получаемую информацию о характеристиках работы систем и приложений», — говорит Рей Шарма, президент и исполнительный директор HydraWeb Technologies. По словам Шарма, благодаря тесному сотрудничеству с ведущими разработчиками приложений, предлагаемые его компанией агенты способны осуществлять тщательный мониторинг прикладных процессов и таким образом обеспечивать маршрутизацию запросов на самую производительную из доступных машин.

С другой стороны, Radware тесно сотрудничает с такими специализирующимися в области управления компаниями, как BMC Software, для получения данных, которые, как утверждает вице-президент по маркетингу Майкл Лонг, распределители нагрузки никогда не будут в состоянии добыть сами по себе. «Сервер может работать просто прекрасно, но у него может быть отказавший вентилятор, — объясняет он. — Это то, чего мы сами не могли бы установить и о чем нам сообщает BMC».

Алистер Кролл, исполнительный директор консалтингового агентства, еще более скептически относится к применению системной диагностики разработчиков распределителей нагрузки. «Применение агентов разработчика привязывает вас к нему, — предостерегает он. — API, с помощью которых имеющийся инструментарий управления мог бы взаимодействовать с распределителем нагрузки, представляются гораздо лучшим выбором, если они надежны и не открывают еще одну дверь для проникновения на ваш узел». Со своей стороны Cisco Systems предложила протокол распределенной обратной связи (Distributed Feedback Protocol, DFP). Он вполне может претендовать на роль стандарта для такого рода взаимодействия между управлением системами и распределителями нагрузки.

Персонал точкаком гордится своим накопленным за долгое время опытом диагностики узла — поэтому они обычно весьма скептически относятся к способности распределителей нагрузки предоставлять аналогичные возможности прямо из коробки. «Мы осуществляем внутренний мониторинг, на который ни один распределитель нагрузки не способен, в особенности это касается разработанных нами методов прогнозирования, — объясняет Серж Уилсон, исполнительный директор провайдера услуг электронной коммерции Freemerchant.com. — Поэтому все, что нам надо, — это решение, с помощью которого мы могли бы по возможности наиболее простым способом использовать свои наработки для сообщения распределителю нагрузки, что ему следует делать». Freemerchant.com выбрала в качестве распределителя нагрузки Equalizer компании Coyote Point вследствие его открытости и экономичности.

Уилсон говорит также, что технология распределения нагрузки имеет важное значение для поддержания работоспособности узла во время текущего обслуживания. «Мы написали для Equalizer сценарий, благодаря которому распределитель нагрузки знает, когда мы выполняем могущую повлиять на работу узла задачу, — рассказывает он. — Такая автоматизация чрезвычайно важна, если вы постоянно работаете над совершенствованием своего узла, но при этом должны поддерживать его высокую доступность». Совместно со своими партнерами, такими, как NSI Software, Radware делает нечто подобное с помощью SNMP. Например, если администратор узла обращается к инструментарию NSI для осуществления тиражирования, то сообщение SNMP заранее предупредит распределитель нагрузки Radware о необходимости изменить маршрут трафика до выполнения задачи.

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

Джон Пакетт, технический директор ToySmart.com, соглашается с Уилсоном относительно важности наличия способного быстро адаптироваться к изменяющейся ситуации распределителя нагрузки. Однако он считает, что возможность быстро и просто реконфигурировать его CS-100 от ArrowPoint Communications не менее важна, нежели любая автоматизация. «Мы следим за множеством атрибутов — очередями страниц, загруженностью ЦПУ, доступом к диску и т. д., — поясняет он. — Для анализа всех этих данных и определения нужных нам тенденций требуется достаточно интеллектуальное программное обеспечение. Поэтому нам необходима возможность менять кое-что на лету так, чтобы это не затрагивало работу сети».

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

КОНТЕКСТНО-ЗАВИСИМЫЙ

Весь вопрос выявления потенциальных проблем производительности в сложной исполнительной инфраструктуре и «маршрутизации» запросов в обход них может рассматриваться в контексте оборонительной стратегии избежания проблем. Однако распределители нагрузки способны на большее, чем просто реагирование на проблемы с выполнением. Теперь они могут избирательно направлять трафик в зависимости от информационного наполнения внутренних серверов. Это осуществляется с помощью так называемого метода «отложенного связывания», в соответствии с которым поступающие запросы на открытие сеанса TCP подтверждаются и задерживаются (буферизуются) распределителем нагрузки, пока со следующим запросом HTTP не поступят сведения о том, какое информационное наполнение необходимо клиенту. В этот момент распределитель нагрузки и принимает решение о том, куда маршрутизировать запрос.

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

Коммутация в зависимости от информационного наполнения может также помочь справиться с пиками спроса — особенно когда эти пики приходятся на разное информационное наполнение и разное время. Некоторые разработчики, в частности HydraWeb, назначают определенные серверы ответственными за специфическое информационное наполнение, в то время как остальным серверам отводится резервная роль. Таким образом, если серверы потокового видео на узле оказываются в некоторый момент перегружены, а устройства Secure Sockets Layer (SSL) имеют свободные мощности, то избыточный поток видеозапросов может временно направляться на устройства SSL, и наоборот.

Некоторые распределители нагрузки, например CS-100 от ArrowPoint Communications, идут еще дальше, реально тиражируя при необходимости информационное наполнение в зависимости от уровня спроса. Как и в случае мониторинга исполнительных систем, некоторые наблюдатели высказывают сомнения относительно тиражирования с помощью распределителей нагрузки вместо специализированного программного обеспечения.

ИДУТ!

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

Однако этого невозможно добиться при учете одного только IP-адреса пользователя. Клиенты провайдеров Internet с коммутируемыми соединениями получают каждый раз при регистрации различные адреса. Пользователи таких услуг, как AOL и WebTV, работают через proxy-серверы, а те предоставляют другие IP-адреса при переходе пользователей с одной ссылки на другую. Таким образом, сам по себе P-адрес не дает надежного решения.

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

Администраторы узлов могут множеством способов использовать перенаправление на основании «плюшек» для достижения своих конкретных технических и/или коммерческих целей. Например, платные подписчики узла могут направляться на наиболее надежное подмножество серверов — даже если они запрашивают то же самое информационное наполнение, что и обычные посетители. Аналогично, соответствующим определенным критериям пользователям может предоставляться приоритетное обслуживание. «Если у вас есть заказчик, с которым у вас дела на миллионы долларов, то вам наверняка не жалко будет выделить ему отдельный сервер», — говорит Шарма из HydraWeb.

«Плюшки» могут также пригодиться при решении так досаждающих многим узлам электронной коммерции вопросов сохранения и учета состояния (см. врезку «Сохранение состояния для SSL»). В случае так называемой проблемы покупательской корзины при переводе на другой сервер покупатели теряют содержимое своей виртуальной корзины. Хотя с помощью инструментария разработки приложений наподобие Enterprise JavaBeans состояние можно сохранить даже при переходе пользователя с сервера на сервер, печальная реальность состоит в том, что лишь немногие узлы им пользуются. Кроме того, многие узлы выросли из небольших пилотных проектов, и со временем на них просто устанавливалось дополнительное оборудование. «Рождество наступает слишком быстро, — размышляет по этому поводу Кролл, — и у многих компаний просто не доходят руки до полной реструктуризации своих приложений». Вместе с тем правильно сконфигурированный распределитель нагрузки способен гарантировать, что посетителя не будут перекидывать с сервера на сервер, после того как он нажмет кнопку «купить».

В зависимости от типа предоставляемого информационного наполнения пользователей может иметь смысл ранжировать в соответствии с типом доступа: коммутируемый, DSL/кабельный модем, корпоративная локальная сеть и т. д. В результате посетители с высокоскоростным доступом могут быть соединены с наиболее быстрыми серверами и каналами, и таким образом возможности последних не будут понапрасну тратиться на пользователей со скоростью доступа менее 56 Кбит/с. «В настоящее время люди пытаются увеличить производительность за счет приобретения дополнительной пропускной способности на стороне клиента, — замечает Уилсон из Freemerchant.com. — Однако со временем те же самые люди станут платить за увеличение производительности на стороне сервера, в особенности когда дело касается таких вещей, как потоковые данные. Предоставление подобных услуг будет, вероятно, осуществляться с помощью распределения нагрузки на основании «плюшек».

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

Конечно, такой анализ «плюшек», чтобы он не сказывался на производительности, когда пакеты так и снуют туда-сюда, проще осуществить на словах, чем на деле. Производительность распределителей нагрузки зависит от множества параметров, в том числе от того, насколько «глубоко» он должен заглядывать в содержащиеся в «плюшке» данные, в частности от возможности поиска определенной последовательности бит. Администраторы узлов, естественно, хотят, чтобы их распределители нагрузки принимали решения о маршрутизации с необходимой степенью детализации, что может дать преимущество таким производителям коммутаторов, как ArrowPoint Communications, чьи распределители нагрузки способны анализировать URL (включая названия и типы файлов) объемом до 256 байт данных — тогда как обычно другие производители ограничиваются 40.

Таким образом, общая производительность узла и его способность к саморегулированию будут все в большей мере зависеть от состава URL/«плюшек» и функциональности распределителя нагрузки. «О чем это говорит? О том, что дизайнерам узлов и сетевым инженерам придется намного теснее сотрудничать друг с другом, если они хотят, чтобы клиенты получили благоприятное впечатление от узла», — отмечает Кролл.

СТАТУС QOS

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

Не надо быть ясновидящим, чтобы дать прогноз, что распределители нагрузки будут применяться в механизмах реализации QoS в рамках Internet, хотя в настоящее время совершенно не ясно, какие именно механизмы в конечном итоге получат повсеместное распространение и сделают сквозное предоставление QoS наконец-то возможным. Роль распределителей нагрузки в уравнении QoS будет, по всей видимости, ограничена ролью пассивной «точки приведения в исполнение» требований к QoS, так как сами параметры QoS, скорее всего, будут определяться приложениями и/или контролирующими узлами Internet. Однако в некоторых особых ситуациях распределители нагрузки, по-видимому, также будут выступать в качестве «задатчиков параметров» QoS.

QoS — не единственная область, где применимы принципы сквозной политики. Кроме того, администраторы ИТ хотели бы иметь возможность определять правила защиты в рамках всей сети и для всех системных ресурсов. Этот потенциальный спрос не остался незамеченным разработчиками распределителей нагрузки; большинство из них уже приняли вызов и включили ряд функций по типу брандмауэров в свои продукты, в частности способность распознавать классические атаки по типу «отказ в обслуживании».

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

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

Разработчикам распределителей нагрузки предстоит столкнуться с некоторыми сложными техническими задачами для удовлетворения требований нарождающегося рынка электронной коммерции. Например, провайдеры приложений (Application Service Provider, APS) будут для них, вероятно, весьма привлекательной целью, так как они предоставляют критические приложения по Internet. Однако, по очевидным соображениям безопасности, трафик ASP будет, скорее всего, доставляться по шифруемым виртуальным частным сетям. Шифрование является настоящим камнем преткновения для распределителей нагрузки, так как им необходимо прочесть заголовок данных для определения пути доставки.

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

Ленни Либман — консультант и автор, специализирующийся на применении сетевых технологий в бизнесе. С ним можно связаться по адресу: LL@exit109.com.

Таксономия распределителей нагрузки

Сохранение состояния для SSL

Рассматриваемые продукты