Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Механизмы, балансирующие нагрузку Web-узлов

Грегори Йеркса

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

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

Для принятия аргументированных решений давайте проанализируем методы оптимизации структуры мультисерверного Web-узла, а именно: использование службы DNS, балансирование нагрузки на основе URL-ссылок и, наконец, глобальное балансирование нагрузки.

Дилемма DNS

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

Дополненный еще одним или несколькими физическими серверами Web-узел должен по-прежнему сохранять для внешнего мира вид единого целого. Обычно это осуществляется путем назначения службой DNS единственного доменного имени, например www.company.com,

нескольким серверным IP-адресам одновременно. Так, узлу, состоящему из двух серверов, будет соответствовать DNS-запись, включающая два IP-адреса: a.b.c.d и a.b.c.e. Данная запись используется клиентскими программами при обращении к Web-узлу посредством URL-ссылки на доменное имя www.company.com. В ответ на запрос DNS-сервер возвращает оба IP-адреса, хотя клиентские IP-стеки выбирают лишь один из них (какой именно, зависит от конкретной реализации). К тому же при последующих DNS-запросах возможно получение этих адресов либо в том же, либо совсем в другом порядке. Это приводит к тому, что пользователи не знают толком, по какому IP-адресу их браузеры осуществляют доступ к вашему Web-узлу. Для обеспечения корректного обслуживания клиентских запросов все серверы узла должны иметь абсолютно одинаковое информационное наполнение.

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

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

Снижение стоимости хранения информации

При втором варианте хранения информации с помощью сетевой файловой системы, например такой, как NFS (Network File System) или AFS (Andrew File System), обеспечивается совместный доступ к файлам или базам данных. Размещение информационного содержимого на одном центральном сервере резко снижает стоимость хранения данных, а использование полосы пропускания сетевых каналов ограничивается считыванием Web-сервером информации, хранящейся в сетевом разделяемом хранилище данных.

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

Разные узлы — разные потребности

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

Нагрузку на серверы Web-узла можно регулировать, используя специализированные серверы для размещения динамически генерируемых данных и другой ресурсоемкой информации. Применяя абсолютные URL-ссылки, такие, как www.scripts.company.com, вы обеспечите поступление всего динамического содержимого с отдельного IP-адреса или домена. Такой подход позволяет перенести интенсивные процессы обработки информации на серверы, оснащенные более мощными и более скоростными аппаратными средствами. Вы можете также поместить Web-ресурсы различных подразделений в отдельные домены. Конечно, это упрощает процедуру управления информационным наполнением Web-узла, но чревато повышением вероятности отказов и усложнением его администрирования в целом, так как дополнительно потребуется формировать пользовательские учетные записи и полномочия для серверов всех подразделений. Кроме того, каждый дополнительный сервер — это потенциальный источник отказов.

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

Балансирование нагрузки

Чтобы исключить необходимость заводить DNS-записи для каждого сервера вашего Web-узла и вместе с тем повысить эффективность его эксплуатации и отказоустойчивость, нужна технология, позволяющая использовать всего один IP-адрес для всех серверов узла и одновременно равномерно распределяющая нагрузку между ними. Распределители Web-нагрузки, или балансировщики TCP/IP-сервиса, с успехом решают подобные задачи для служб HTTP, TCP и UDP, включая SMTP, POP, IMAP и NNTP.

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

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

Затраты и приобретения

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

Чтобы обеспечить полное резервирование узла, все распределители нагрузки используют механизм восстановления, основанный на применении дополнительного распределителя и резервного кабеля. Учитывая важность обеспечения надежности Web-узла, затраты, связанные с приобретением второго распределителя, — а они составляют от 1000 до 30 000 долл., включая стоимость инсталляции и конфигурирования, — можно считать оправданными.

Балансирование нагрузки на основе URL

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

Используя средства распределения нагрузки на основе URL-ссылок, можно сегментировать содержимое Web-узла, не разбивая его на отдельные домены, а на основе указанного в ссылке маршрута. В этом случае кластер, ассоциируемый с отделом продаж, может обрабатывать все содержимое, находящееся по URL-адресу www.company.com/sales/. При этом данный кластер не ограничивается обслуживанием только одного URL-адреса, поэтому вы вполне можете “поручить” ему обработку информации как, например, хранящейся по адресу /information/sales_contacts/, так и другой, которая имеет отношение к продажам.

Распределение нагрузки на серверы Web-узла с помощью URL-ссылок реализуется различными способами. Чаще всего информационное наполнение узла, определяемое URL-ссылками, распределяется на основе указанных в них маршрутов. Например, при указании маршрута /sales вся хранящаяся по этому адресу информация перенаправляется серверу отдела продаж для обработки. Уникальные URL-запросы, такие, как /sales/receipts.html, также направляются на определенные серверы. Проанализировав файлы регистрации и все содержимое Web-узла, вы получите достаточно четкое представление о размещении наиболее часто запрашиваемой информации и определитесь с тем, как наиболее оптимально разделить ее на отдельные сегменты. Разместив крупные файлы на серверах, оснащенных дисковой памятью большого объема, а сценарии, интенсивно использующие ЦПУ, — на более быстродействующих мультипроцессорных системах, можно с помощью URL-балансировки оптимизировать использование ресурсов вашего Web-узла.

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

Думайте глобально

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

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


Купить ip-адреса ответы где купить.




  
5 '1999
СОДЕРЖАНИЕ

колонка редактора

• С компьютерным новым годом!

локальные сети

• Об NT по существу: «Ну перенесите же приложения на Linux!»

• Тестируем консолидированные серверные системы

• Эти разные, разные устройства FC-AL

• Комфорт для людей и машин

• Наведение порядка в распределительных шкафах

• Огнеупорные материалы — необходимый атрибут любой сетевой инфраструктуры

интернет и интрасети

• Его величество потребитель

• Четыре среды разработки Java для проектов уровня предприятия

• Механизмы, балансирующие нагрузку Web-узлов

защита данных

• Когда лекарство опаснее самой болезни

• Не слишком ли хороши биометрические устройства?

корпоративные сети

• Беда нечаянно нагрянет...

• Метасправочники обеспечат синхронизацию информации о пользователях

• Анализаторы протоколов АТМ и Gigabit Ethernet: главные баталии еще впереди

• Средства системного мониторинга уровня предприятия

услуги сетей связи

• Интегрированные сети — технологии и политика

• Службы многоадресной рассылки факсов: экономия плюс эффективность

• Системы LMDS: хороший шанс и

• Война параллельных миров: научная конференция под эгидой Госкомсвязи

новые продукты

• Новые анализаторы спектра новой измерительной компании; Драйвер персональной сетевой защиты IP-LIR; NSG-500 мал да удал!



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх