Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

24.03.2017

Google
WWW CITForum.ru
С Новым годом!
2000 г

Системы балансировки нагрузки Web-серверов

Журнал "Windows 2000 Magazine", #03/2000

ТАО ЧЖОУ

Инструменты для настройки производительности Web-сереров

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

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

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

Распределение, или выравнивание нагрузок, приходящихся на несколько серверов, позволяет избежать такой ситуации, когда передаваемые по сети Web пакеты лавиной обрушиваются на один сервер, в то время как другие простаивают без дела. Для распределения нагрузки между Web-серверами обычно используется функция DNS, именуемая циклической выборкой (round-robin feature), которая предусматривает возможность круговой передачи IP-адреса любого Web-сервера, составляющего сайт, любому клиенту; в итоге все Web-серверы становятся в равной степени загружены трафиком. Однако этот механизм недостаточно эффективен в тех средах, где возможности аппаратных и программных компонентов отдельных Web-серверов неравнозначны. Понятно, что в среде с распределенной нагрузкой оснащенная двумя 450-мегагерцевыми процессорами Pentium III и памятью емкостью 1 Гбайт система под управлением Windows 2000 Server может взять на себя более тяжелую ношу, нежели система Windows NT Server с одним 300-мегагерцевым процессором Pentium II и 256 Мбайт памяти. Однако с точки зрения процедуры циклической выборки службы DNS между этими системами нет никакой разницы; более того, данная функция "не имеет представления" о доступности того или иного Web-сервера, поскольку не может определить, работоспособен компьютер или вышел из строя.

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

Что такое система балансировки нагрузки

ЭКРАН 1. Система балансировки для одного сайта.

Система балансировки нагрузки Web-серверов - это инструментальное средство, предназначенное для переадресации клиентских запросов на наименее загруженный или наиболее подходящий Web-сервер из группы машин, на которых хранятся зеркальные копии информационного ресурса. Клиент не подозревает о том, что обращается к целой группе серверов: все они представляются ему в виде некоего единого виртуального сервера. Предположим для примера, что мы обслуживаем один Web-сайт и имеем при этом два Web-сервера: web1.acme.com с IP-адресом 193.168.36.1 и web2.acme.com с IP-адресом 193.168.36.2. Эту конфигурацию иллюстрирует Рисунок 1. Представляя наш сайт пользователям Internet, система балансировки нагрузки использует имя виртуального компьютера (пусть это будет имя www.acme.com), а также виртуальный IP-адрес (VIP-адрес - скажем, 193.168.35.10). Чтобы связать имя виртуальной системы и соответствующий VIP-адрес с двумя нашими Web-серверами, мы должны опубликовать имя системы и ее VIP-адрес на сервере DNS. Система балансировки нагрузок постоянно контролирует нагрузки и степень готовности каждого из Web-серверов. Когда на узел www.acme.com заглядывает посетитель, его запрос поступает не на один из Web-серверов, а в систему балансировки нагрузки. Эта система и принимает решение о том, на какой сервер направить запрос. При этом она руководствуется такими критериями, как загрузка каждого подопечного сервера, а также соблюдает условия и правила, сформулированные администратором. Затем система балансировки нагрузки направляет запрос клиента соответствующему серверу (как правило, она же направляет ответ сервера клиенту, но это зависит от конкретной реализации).

Системы распределения нагрузки могут к тому же обеспечивать выравнивание нагрузок нескольких Web-сайтов. Напомню читателям, что применение нескольких сайтов позволяет размещать серверы-"дублеры" (зеркальные Web-серверы) ближе к посетителям сайта и сокращать задержки при обмене информацией между сайтом и клиентами. Кроме того, при наличии нескольких Web-сайтов появляется возможность равномерно распределять нагрузку между ними, а также обеспечивать высокую степень их готовности и отказоустойчивость в случае нарушений в работе сайта (будь то по причине сбоев в системе энергоснабжения или из-за потери связи с Internet в вычислительном центре). При наличии нескольких сайтов, как показано на Рисунке 2, все системы балансировки нагрузок на всех сайтах имеют одно общее имя виртуальной системы, но разные VIP-адреса. Так, системе балансировки 1 на сайте 1 в Нью-Йорке присвоено имя виртуальной главной машины www.acme.com с VIP-адресом 193.168 .35.10. А балансировщик 2 на сайте 2 в Лос-Анджелесе, пользующийся тем же именем виртуальной главной машины, имеет уже другой VIP-адрес - 193.200.1.10. Связи всех систем балансировки с локальными Web-серверами устанавливаются так же, как и в случае с одним сайтом. Наряду с мониторингом нагрузок локальных серверов системы балансировки обмениваются со своими "коллегами" на других сайтах информацией о конфигурации и загрузке; при этом проверяется и степень готовности сайта. В итоге все системы балансировки имеют в своем распоряжении общую картину распределения нагрузок и готовности к работе различных узлов. При наличии нескольких сайтов системы балансировки нагрузок часто параллельно выполняют еще одну задачу: берут на себя роль серверов DNS, обслуживающих имя виртуальной системы. Получив через DNS сигнал от клиента, указавшего данное имя, система балансировки возвращает клиенту VIP-адрес сайта, наиболее подходящего с учетом текущего уровня нагрузки, степени удаленности от клиента и других параметров. Затем клиент автоматически получает доступ к этому узлу.

ЭКРАН 2. Система балансировки для нескольких сайтов.

Системы балансировки нагрузок делятся на три категории: аппаратные устройства (hardware appliances), сетевые коммутаторы и программные решения. Системы балансировки на базе аппаратного устройства можно рассматривать как "черный ящик"; обычно это функционирующая под управлением UNIX или фирменной ОС машина с процессором Intel, на которой установлена разработанная поставщиком система балансировки нагрузки. Такие системы соответствуют спецификации Plug and Play (PnP), что облегчает работу администраторов узлов Web. Для реализации систем балансировки на базе сетевых коммутаторов используются коммутаторы второго и третьего уровня. В отличие от аппаратных решений эти системы не предусматривают установки дополнительных устройств, через которые Web-серверы подключаются к коммутатору. Если при организации службы распределения нагрузки в пуле Web-серверов используются программные продукты, то можно обойтись без модификации имеющихся сетевых средств и оборудования. Программные пакеты устанавливаются на существующих Web-серверах или на специальных серверах выравнивания нагрузки. Список поставщиков систем балансировки нагрузки и их изделий приводится во врезке "Дополнительная информация о системах балансировки". О решениях, предлагаемых корпорацией Microsoft, рассказано во врезке "Службы балансировки Load-Balancing Services компании Microsoft".

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

Мониторинг состояния серверов

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

При проведении внешнего мониторинга система балансировки нагрузки рассчитывает время отклика сервера, для чего направляет на сервер запрос и замеряет время ответа. Самая простая техника выполнения внешнего мониторинга сервера предполагает использование ping-тестов по протоколу управления сообщениями Internet Control Message Protocol (ICMP). Эти тесты позволяют системе убедиться в готовности сервера к работе и узнать, сколько времени необходимо для передачи информации с сервера на систему балансировки и обратно. Если система балансировки нагрузки не получает отклика от сервера после нескольких последовательных запросов, считается, что данный сервер недоступен. Как правило, администраторы подключают Web-серверы непосредственно к системе балансировки нагрузки, поэтому если время, затрачиваемое на передачу, слишком велико, система заключает, что сервер работает с большой нагрузкой.

Здесь, однако, надо отметить, что в ходе ping-тестов сервера по протоколу ICMP диагностируется только стек протоколов IP; описанный метод не дает представления о состоянии стека TCP, который используется протоколом передачи гипертекста HTTP. Чтобы убедиться в правильности функционирования стека TCP сервера, средство балансировки нагрузки предпринимает попытку установить соединение по протоколу TCP, для чего требуется осуществить состоящий из трех этапов обмен подтверждающими сообщениями. Делается это так. Сначала средство балансировки нагрузки направляет серверу TCP-пакет, в котором значение бита SYN установлено равным 1. Если после этого система балансировки получает от сервера TCP-пакет, в котором значение бита SYN равно 1, а значение бита ACK тоже установлено равным 1, она направляет серверу второй TCP-пакет со значением бита SYN равным 0 и значением бита ACK равным 1. Если обмен подтверждающими сообщениями завершился успешно, значит, TCP-стек сервера функционирует нормально. По завершении такого обмена средство балансировки нагрузки немедленно разрывает соединение с сервером, чтобы исключить непроизводительное использование его ресурсов. Качество TCP-соединения с сервером оценивается системой по такому показателю, как время, необходимое для выполнения всех трех этапов обмена подтверждающими сообщениями.

Наряду с тестированием стеков протоколов лучшие средства балансировки нагрузки могут обеспечивать мониторинг времени отклика и готовности как самого Web-сервера, так и установленных на нем приложений еще одним способом: на сервер направляется запрос по протоколу HTTP на получение информационных материалов или адреса URL. Пусть именем начальной страницы сервера web1.acme.com будет index.htm. Система балансировки нагрузки на Рисунке 1 может инициировать предусмотренную по протоколу HTTP команду Get, запрашивая тем самым у сервера web1.acme.com содержимое страницы index.htm. Если код возврата, направляемый системе Web-сервером, будет 200, значит, начальная страница на сервере web1.acme.com недоступна. Время отклика определяется системой балансировки нагрузки как время с момента отправки запроса на предоставление информации до момента получения кода возврата.

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

Выбор сервера

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

Современные системы балансировки нагрузки позволяют администратору определять правила выбора сервера по своему усмотрению. Можно, к примеру, включить в эти правила такие критерии, как коэффициент загрузки ЦП и памяти, число открытых соединений TCP и количество пакетов, поступающих на сетевую интерфейсную плату того или иного сервера. Формула, по которой система балансировки определяет уровень загруженности серверов, может выглядеть примерно так: (10 * уровень использования ЦП) + (3 * уровень использования памяти) + (6 * число открытых TCP-соединений) + (3* число переданных пакетов) = загрузка сервера. При получении запроса от клиента система балансировки нагрузки рассчитывает по этой формуле нагрузку каждого сервера и направляет запрос серверу с наименьшей нагрузкой.

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

При организации устойчивого соединения основная задача системы состоит в том, чтобы идентифицировать клиента и связать соответствующий идентификатор с сервером-получателем запроса. Как правило, системы балансировки нагрузки используют в качестве идентификатора клиента применяемый им IP-адрес отправителя. Но все дело в том, что адрес отправителя не обязательно совпадает с реальным IP-адресом клиента. Многие компании и провайдеры, стараясь удержать Web-трафик под контролем и скрыть от посторонних глаз IP-адреса своих пользователей, устанавливают серверы-посредники. И в случае, если на наш гипотетический узел Web поступят запросы от 500 клиентов службы America Online (AOL), а также от 10 клиентов, представляющих другую компанию, баланс нагрузок серверов будет нарушен. Система балансировки свяжет 500 клиентов из AOL, имеющих один и тот же адрес отправителя, с одним сервером, а 10 остальных клиентов - с другим. К счастью, эту проблему можно решить, если воспользоваться системой балансировки нагрузки, оснащенной средствами идентификации IP-адресов отправителей и номеров портов TCP. Подобные системы способны опознавать клиентов даже в том случае, когда последние выходят в Internet через один и тот же proxy-сервер. Такая идентификация возможна потому, что каждое TCP-соединение имеет уникальный IP-адрес отправителя и номер порта TCP. Еще один способ идентификации клиента, проводящего защищенный сеанс связи по протоколу HTTP, состоит в том, чтобы зафиксировать идентификационный номер сеанса связи пользователя по протоколу Secure Sockets Layer (SSL). Протокол SSL назначает каждому установленному сеансу связи специальный идентификатор, а прикладные программы для виртуальных магазинов часто пользуются этим протоколом. Самое современное средство поддержания устойчивых соединений - это распространяемые по сети Web cookie-файлы. Напомню, что эти файлы содержат как сведения о клиенте, так и другие данные (например, о том, с каким сервером клиент связывался в последний раз). Анализ содержимого cookie-файлов помогает системе балансировки нагрузки идентифицировать клиентов и подбирать для них наиболее подходящий сервер. В число поставщиков систем балансировки нагрузки, оснащенных средствами работы с cookie-файлами, входят такие компании, как Alteon WebSystems, ArrowPoint Communications, F5 Networks и Resonate.

Наконец, существует еще один способ выбора сервера - так называемое непосредственное связывание (immediate binding). В соответствии с этим методом системы балансировки нагрузки подбирают сервер для клиента и направляют запрос на него в тот самый момент, когда система получает от клиента пакет TCP SYN. При этом система балансировки выбирает сервер, руководствуясь заданными правилами распределения нагрузки серверов, а также IP-адресом, содержащимся в полученном от клиента пакете TCP SYN. Этот метод обеспечивает высокое быстродействие, но надо сказать, что при его применении система балансировки просто не успевает проанализировать другую информацию: в частности, идентификатор сеанса связи по протоколу SSL, содержимое cookie-файла, адрес URL и данные прикладной программы. Чтобы получить более подробные сведения о клиенте и, соответственно, точнее выбрать для него сервер, системе балансировки нагрузки требуется время для анализа информации уровня приложения. При выборе сервера по методу отложенного связывания система балансировки нагрузки принимает решение о назначении сервера лишь по завершении трехэтапного обмена подтверждающими сообщениями и после установки соединения между ней и клиентом. Система может учитывать содержимое публикуемых материалов, если исследует информацию уровня прикладной программы до выбора сервера для клиента.

Переадресация трафика

Системы балансировки нагрузки могут перенаправлять трафик клиентов на избранный сервер несколькими способами: по методу трансляции адресов с управлением доступом к среде передачи (media access control (MAC) address translation, MAT), по методу трансляции сетевых адресов (Network Address Translation, NAT), или - при использовании отложенного связывания - с помощью механизма шлюза TCP (TCP gateway). Рассмотрим, как реализуется каждый из этих методов перенаправления трафика средствами выравнивания нагрузки.

MAT. Этот метод может быть реализован системой балансировки нагрузки при том условии, что каждый Web-сервер наряду со своим физическим IP-адресом использует в качестве интерфейсного адреса обратной связи (loopback interface address) VIP-адрес системы балансировки. Получив от клиента пакет и назначив ему соответствующий сервер, система балансировки заменяет в этом пакете MAC-адрес получателя MAC-адресом соответствующего сервера, после чего направляет пакет на выделенный сервер. В пакете содержится IP-адрес клиента, так что для прямого ответа клиенту сервер использует в качестве IP-адреса получателя первоначальный IP-адрес клиента. Однако в качестве IP-адреса отправителя сервер указывает VIP-адрес системы балансировки нагрузки, как если бы трафик поступал клиенту именно от нее. Таким образом, следующий пакет от клиента направляется не ответившему ему серверу, а системе балансировки нагрузки.

NAT. При использовании этого метода система балансировки направляет полученный от клиента пакет назначенному серверу лишь после того, как выполнит над пакетом несколько операций: во-первых, она замещает в пакете адрес получателя (т. е. собственный VIP-адрес) IP-адресом назначенного сервера, а во-вторых, - меняет IP-адрес отправителя на свой VIP-адрес. Данный метод позволяет скрывать от клиентов IP-адреса Web-серверов, так что последние могут использовать любые IP-адреса, в том числе и частные. При этом Web-серверы не обязательно должны быть непосредственно соединены с системой балансировки (иначе говоря, входить в один и тот же сегмент ЛВС); достаточно, чтобы они могли устанавливать соединения по протоколам статической или сетевой маршрутизации.

Шлюз TCP. При установке непосредственного (немедленного) связывания системы балансировки нагрузки могут направлять трафик по методам MAT или NAT на уровнях 2 или 3. Но если речь идет об отложенном связывании, системы балансировки должны управлять трафиком на уровне TCP и на более высоких уровнях. Отложенное связывание предполагает, что система балансировки нагрузки и клиент устанавливают соединение по протоколу TCP так, чтобы система могла получить данные приложения еще до назначения сервера. Затем средство балансировки устанавливает TCP-соединение с назначенным сервером и передает ему клиентский запрос. Далее система балансировки передает клиенту ответ сервера, для чего опять-таки используется TCP-соединение "система балансировки - клиент". Описанная функция и называется шлюзом TCP. Специалисты компании Resonate реализуют ее в системе балансировки нагрузки с помощью специального агента (этот агент устанавливается на сервере, который обеспечивает прямое TCP-соединение между клиентом и сервером, выступающим в роли средства балансировки). По терминологии, предложенной компанией-поставщиком, данная реализация именуется системой с транзитом TCP-соединений (TCP connection hop).

Выбор сайта и управление трафиком на глобальном уровне

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

Чтобы лучше понять механизм данного процесса, вернемся к нашему примеру. Виртуальная система с именем www.acme.com представлена на двух сайтах. Функции серверов DNS для этой машины выполняют две системы балансировки нагрузки: одна - в Нью-Йорке, вторая - в Лос-Анджелесе. Разрешение имен для таких служб, как ftp и электронная почта, а также для других серверов и компьютеров в Internet осуществляется официальным сервером DNS домена acme.com. Так вот, администратор может делегировать имя поддомена www.acme.com, который является частью Internet-домена acme.com, обоим средствам балансировки, после чего обе системы выравнивания нагрузки станут серверами имен для поддомена www.acme.com. Чтобы получить подобную конфигурацию, нужно для каждой системы балансировки определить DNS-имя www.acme.com и поставить его в соответствии с ее собственным локальным VIP-адресом. Поскольку две системы балансировки обмениваются информацией о конфигурации и нагрузке, обе они "понимают", что виртуальная система www.acme.com имеет два VIP-адреса (т. е. представлена двумя узлами). И следовательно, обе имеют информацию о нагрузке и доступности каждого из сайтов.

Когда клиент службы AOL обращается по адресу www.acme.com, как показано на Рисунке 3, процедура вызова начинается с того, что клиент запрашивает у локального сервера DNS службы AOL IP-адрес компьютера www.acme.com. Если в кэше локального сервера DNS службы AOL не содержится данных о запрошенном IP-адресе, этот сервер направляет запрос официальному серверу DNS домена acme.com. Как мы помним, сервер DNS домена acme.com назначил имя www.acme.com двум системам балансировки нагрузки, поэтому домен acme.com возвращает локальному серверу DNS службы AOL IP-адреса двух систем балансировки нагрузки в качестве сервера имен www.acme.com. (Обратите внимание, что на Рисунке 3 я выделил интеллектуальную службу сервера DNS, обозначив ее отдельным прямоугольником, - некоторые поставщики реализуют эту технологию на отдельном сервере.) Затем локальный сервер DNS службы AOL направляет запрос на получение имени одной из двух систем балансировки нагрузки. Обе системы представляют собой серверы имен, поэтому, не получив ответа от первого сервера, локальный сервер DNS службы AOL направит повторный запрос уже второй машине. Система балансировки нагрузки выбирает на основе заданных для сайта критериев наиболее подходящий сервер и возвращает локальному серверу DNS службы AOL VIP-адрес сервера сайта. Получив от локального сервера DNS службы AOL VIP-адрес главной машины www.acme.com, клиент адресует свой HTTP-трафик системе балансировки нагрузки избранного сайта (например, нью-йоркского), и эта система выбирает для клиента один из локальных серверов. Поскольку локальный сервер DNS кэширует разрешенную запись DNS на срок, соответствующий указанному в записи параметру Time To Live (TTL), поставщики обычно рекомендуют не задавать больших значений TTL, чтобы клиент имел возможность быстро получить новый VIP-адрес и переключиться на другой доступный сайт.

ЭКРАН 3. Перенаправление DNS запросов для нескольких сайтов.

Системы балансировки нагрузки могут выбирать подходящий сайт, а также перенаправлять трафик и другим методом: с помощью переадресации средствами протокола HTTP. Данный метод не предусматривает использования DNS-функции системы балансировки нагрузки. Вместо этого (снова обращаюсь к нашему примеру) администратор определяет на сервере DNS запись о www.acme.com и соответствующие ей VIP-адреса. Когда клиент получает VIP-адрес www.acme.com и направляет по протоколу HTTP запрос системе балансировки нагрузки, последняя подбирает для него наиболее подходящий узел. Если избранный сайт не является удаленным (расположен не слишком далеко), система балансировки направляет браузеру клиента HTTP-команду на переадресацию, и браузер устанавливает соединение с указанным сайтом. Описанный метод дает системе балансировки нагрузки возможность еще до выбора узла получить о клиенте более подробные сведения (например, его IP-адрес). Однако клиент может воспользоваться VIP-адресом, возвращенным сервером DNS, и попытаться установить соединение с не отвечающим на запросы узлом.

Помимо метода динамического назначения клиенту того или иного узла системы балансировки нагрузки могут использовать для связывания конкретных клиентов с конкретными сайтами метод статического назначения (static mapping method). Допустим, у нас имеется зеркальный узел Web в Европе. Нам нужно, чтобы клиенты из Европы все время попадали именно на европейский сайт - за исключением тех случаев, когда он выходит из строя и система балансировки нагрузки направляет европейский трафик на узел, расположенный в США. Администратор имеет возможность настроить систему балансировки нагрузки так, чтобы любой запрос от клиента с европейским IP-адресом сначала направлялся на сайт в Европе. (Для выполнения соответствующих настроек необходимо ввести в систему балансировки весь блок европейских IP-адресов.) Получив такое указание, система балансировки нагрузки будет в первую очередь направлять на европейский узел любой запрос с европейским обратным адресом и лишь после этого принимать в расчет другие заданные критерии выбора сайта.

Избыточные системы балансировки

Системы балансировки нагрузки - не что иное, как средства доступа к серверам Web, и потому выход такого средства из строя может повлечь за собой полное прекращение работы узла. Отсюда вывод: при планировании и реализации инфраструктуры с выравниванием нагрузок важно принимать во внимание отказоустойчивость средств балансировки, а также выбирать решения с широкой полосой пропускания, способные обеспечить высокую производительность системы в целом. В распоряжении администратора имеются две схемы организации избыточных систем балансировки нагрузки: первая предполагает, что одна система балансировки функционирует в активном режиме, а другая - находится в состоянии ожидания (active-and-standby type); вторая же схема предусматривает одновременное функционирование обеих систем балансировки (active-and-active type). Обе схемы предполагают наличие на одном узле двух экземпляров систем балансировки нагрузки.

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

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

Больше, чем технология

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

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

Об авторе

Тао Чжоу - внештатный редактор журнала Windows NT Magazine и сервисный инженер, работающий в сфере Internet. Он имеет сертификаты MCSE и Master CNE, а также степень магистра компьютерных наук. С ним можно связаться по электронной почте по адресу taoz@ix.netcom.com.

Дополнительная информация о системах балансировки

Аппаратные решения

BIG/ip and 3DNS
F5 Networks . 206-505-0800 or 888-882-4447
http://www.f5.com

LocalDirector and DistributedDirector
Cisco Systems . 800-553-6387
http://www.cisco.com

Web Server Director product family
RADWARE . 888-234-5763
v

Коммутаторы

ACEdirector, Alteon 180, and Alteon 700 Series
Alteon WebSystems . 408-360-5500 or 888-258-3661
http://www.radware.com

CS-100 and CS-800
ArrowPoint Communications . 978-206-3000
http://www.arrowpoint.com

ServerIron
Foundry Networks . 408-586-1700
http://www.foundrynet.com

Программные решения

Central Dispatch and Global Dispatch
Resonate . 408-548-5500
http://www.resonate.com

IP Magic
Lightspeed Systems . 661-324-4291
http://www.lightspeedsystems.com

Windows NT Load Balancing Service, Network Load Balancing, AppCenter Server
Microsoft . 425-882-8080
http://www.microsoft.com

Отчеты

"The 2000 Internet Traffic Management Report"
Internet Research Group
http://www.itmcenter.com

"Virtual Resource Management: Key Technologies, Tricks of the Trade, and Application Requirements" and "Virtual Resource Management: Which Vendor is Right For You?"
Acuitive . 925-456-3210
http://www.acuitive.com

Службы балансировки Load-Balancing Services компании Microsoft

Программа Windows NT Load Balancing Service (WLBS) была приобретена Microsoft у компании Valence Research в 1998 г. На базе этой программы был создан модуль расширения Windows NT Server, Enterprise Edition (NTS/E). Ранее программа компании Valence была известна на рынке под названием Convoy Cluster. Специалисты Microsoft реализовали ее в операционных системах Windows 2000 Advanced Server и Windows 2000 Datacenter Server (Datacenter) и назвали службой Network Load Balancing (NLB). Службы WLDS и NLB обеспечивают функционирование в одном кластере от 2 до 32 серверов. Чаще всего администраторы используют WLBS и NLB для распределения по различным Web-серверам поступающих по каналам Internet клиентских запросов, однако оба продукта могут выполнять и другие функции, например выравнивать нагрузку различных серверов FTP.

Службу WLBS или NLB следует установить на всех серверах узла Web или кластера, после чего каждый узел будет представлен виртуальным IP-адресом (virtual IP address, VIP address), а кластер, соответственно, адресом кластера. Для нормального функционирования программ необходимо, чтобы все серверы принадлежали одной подсети. Кроме того, нужно иметь в виду, что для перенаправления трафика клиентов обе службы используют метод многоадресной передачи с управлением доступом к среде передачи (media access control multicast method). Установив соединение и получив клиентский запрос, маршрутизатор, к которому подключена подсеть сервера, передает запрос в кластер по методу многоадресной пересылки сообщений на уровне MAC. Сервер балансировки нагрузки по особому алгоритму определяет, на какой сервер перенаправить запрос клиента. Выбранный сервер откликается на вызов и обрабатывает клиентский запрос. Службу можно сконфигурировать так, что запросы будут распределяться по серверам равномерно или в соответствии с коэффициентами, отражающими мощность той или иной машины. Как и WLBS, NLB способна выбирать отвечающий заданным критериям сервер и перенаправлять трафик в соответствии с IP-адресом и номерами портов клиента. Наряду с этим обе программы могут обеспечивать постоянное соединение с IP-адресом клиента или с сетевым адресом класса C (Class C network address). К сожалению, ни одна из программ не предусматривает выполнения отложенного связывания (delayed binding).

Каждый сервер наделяется средствами аварийного переключения, которые активизируются в случае сбоя в работе любого другого сервера. Иными словами, службы обеспечивают избыточную балансировку нагрузки по принципу "активный-активный", т. е. функционирование в активном режиме всех имеющихся средств выравнивания нагрузки (active-and-active implementation). При этом важно отметить, что, хотя средства выравнивания нагрузки корпорации Microsoft могут быть установлены на нескольких узлах Web или в нескольких кластерах, эти службы не обеспечивают глобального перераспределения нагрузки (на уровне узлов или кластеров).

Если требуется перенаправлять трафик нескольким узлам (кластерам), то приходится пользоваться реализованной в DNS процедурой циклической выборки узла (round-robin feature), в которой не предусмотрены ни возможность передачи управления другому устройству в случае отказа аппаратуры, ни средства регулировки нагрузок на уровне серверов узла.

Службы WLBS и NLB хорошо справляются с задачей распределения трафика среди выполняющих интерфейсные функции Web-серверов. Для поддержания высокого уровня доступности таких серверных приложений, как Microsoft SQL Server, можно применять пакет Microsoft Cluster Server (MSCS) в двухузловом кластере под управлением NTS/E и в четырехузловом клaстере в среде Datacenter. Отмечу, кстати, что специалисты корпорации Microsoft в настоящее время разрабатывают службу распределения нагрузок на базе новой технологии COM+. Этот продукт, который будет называться Component Load Balancing (CLB), обеспечит регулировку нагрузок на среднем уровне, т. е. на уровне бизнес-логики многоуровневых приложений Windows. Первоначально планировалось интегрировать CLB в Windows 2000, но затем эту службу решили исключить из финальной версии операционной системы. CLB будет представлена в предназначенном для управления Web-приложениями Windows 2000 высокопроизводительном сервере AppCenter Server, который должен поступить на рынок в ближайшее время.

 

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...