Webmasterpro.com.ua - первый украинский сайт о поисковых системах. Оптимизация сайта в поисковиках, поисковая раскрутка. Хостинг


8590 seo-документов в поиске, с 2001 года



Реклама на сайте

 Хостинг
Платный хостинг
Бесплатный хостинг

Регистрация доменов

 Статьи
Яндекс
Google
Все поисковые системы
Оптимизация - основы
Баннерная реклама
Общие вопросы рекламы
Реклама в интернет
Маркетинг в интернет
Website management
Email-маркетинг
Почтовые рассылки
Спам и борьба с ним
Разработка сайта
Веб-дизайн
Usability
Каскадные таблицы стилей
HTML
Базы данных
Таблицы
MySQL
CGI
xDSL
Партнерские программы
Электронная коммерция
Выбор хостинга
Доменные имена
Провайдеры
Сервера
А также
Пресс-релизы
Каталог сайтов
Партнерские программы
Платный хостинг
Регистрация доменов
Раскрутка сайта
High-Tech портал

 Партнерские программы:
Продажа хостинга, регистрация доменов 
% от первого и последующих платежей клиентов за хостинг и регистрацию доменов
ZenBroker - продажа ссылок, реклы есть
Добавляем все сайты в систему и получаем доход

добавить рекламный блок

Смешанные решения распределения нагрузки во многомашинной системе

Раздел: Сервера 07-12-2004 FAQ оптимизатору на форуме ZenBroker


Автор - Александр Качанов сайт Webmascon

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

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

Балансировка

Используя смешанную схему мы можем превысить предел в 32 машины, устанавливаемый программным распределителем. По сути, если предположить, что аппаратный распределитель способен работать с 256 отдельными узлами (вполне реальное предположение), то мы можем расширять мощность своего сайта вплоть до безумного количества машин: 8192 серверов.

Отказоустойчивость

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

Администрирование

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

Пару слов о "привязке" Несмотря на то, что HTTP это stateless протокол, уже изобретено множество хитростей и уловок, что бы сохранять состояние приложения между запросами одного и того же клиента. Например с помощью сессий можно сохранить все переменные и их значения для данного клиента и потом восстановить их при следующем запросе. При использовании одной машины под web-сервер никаких проблем нет, разве что при пиковой нагрузке она может упасть, о чем мы уже рассуждали выше.

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

Для устранения этого недостатка была придумана технология, которая называется "привязка" (affinity). Она отсутствует в переключателях нагрузки (load director), но есть в распределителях (load balancer) как в аппаратных, так и в программных. "Привязка" означает, что по началу сессии клиент направляется на любую машину, и на протяжении всей сессии поддерживает соединение только с ней.

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

Рассмотрим следующий пример. Предположим, что четыре пользователя (A-D) подключатся к Web-сайту, и их запросы равномерно раскладываются между двумя машинами. Теперь предположим, что пользователи C и D тут же отключились, а пользователи A и B продолжают работать в течение длительного времени и выполняют сложные операции. Если мы будем использовать "привязку", все HTTP-запросы сделанные пользователями A и B, будут направляться на сервер А. для пользователей A и B сервер будет работать медленно, в то время как сервер B будет простаивать в ожидании работы.

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

Большинство аппаратных и программных распределителей нагрузки предлагают решение этой проблемы. Они позволяют делать привязку для всего пространства адресов класса С, или 256 различных IP-адресов. Предполагается что большинство клиентов работают через прокси-сервера, у которых адреса располагаются в одном и том же адресном пространстве. Но и здесь есть недостаток: если к вам на web-сайт пожалует группа пользователей из одного сегмента сети, они все будут направлены (из-за привязки к пространству адресов) на одну машину, которая может из-за высокой нагрузки рухнуть.









 

Новости, статьи и пресс-релизы присылайте на news@webmasterpro.com.ua 
При перепечатке материалов ссылка на WebmasterPro обязательна

Rambler's Top100

Rating@Mail.ru


Copyright © 1999-2006 webmaster@webmasterpro.com.ua