Назад в библиотеку

Масштабируемость гетерогенной диспетчерской архитектуры балансировки нагрузки веб-серверов

Авторы: Tsang-Long Pao, Jian-Bo Chen

Автор перевода: Петренко А.С.

Источник (англ.): Ming Chuan University

Аннотация

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


Введение

С бурным развитием World Wide Web, трафик популярных веб-сайтов выходит далеко за пределы возможностей одного сервера. Как правило, реализуется распределенная или параллельная архитектура с единым виртуальным интерфейсом. Эти сайты способны предоставлять более качественный сервис своим клиентам по более низкой цене. Архитектура балансировки нагрузки веб-сервера способна предоставлять высокопроизводительные сервисы для большого числа клиентов [1, 2]. Несмотря на то, что в состав архитектуры входит большое количество серверов, они выступают в роле единого объекта. Прозрачность для пользователя реализуется для того, чтобы позволить клиентам работать с несколькими серверами без специальной конфигурации [3].

Большинство алгоритмов балансировки нагрузки фокусируются на гомогенных веб-серверах – серверах с одной конфигурацией. Такие сервера имеют одинаковые вычислительные мощности, объем памяти, скорость сетевого соединения, I/O скорость и прочие [4]. В системе гомогенных серверов диспетчер может перенаправлять клиентские запросы наиболее подходящему серверу на основе многих хорошо известных критериев, таких как round robin(RR) или least connection (LC). В алгоритмах, учитывающих состояние серверов[5], каждый сервер должен сообщать информацию о своей загруженности диспетчеру. Диспетчер выбирает лучший сервер для обслуживания запроса[6, 7]. Но в гетерогенной системе диспетчер должен перенаправлять запрос подходящему серверу не только учитывая загрузку, но также и производительность сервера. Другими словами, мы используем остаточную производительность сервера.

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

В данной статье мы сравниваем алгоритм остаточной производительности с round robin и least connection алгоритмами в системе гетерогенных веб-серверов. Мы рассматриваем hit rate и утилизацию серверов различной производительности. Частота отказов также рассматривается. Из результатов моделирования мы находим, что алгоритм остаточной производительности эффективнее других. Для уменьшения стоимости системы балансировки нагрузки в среде с предсказанием пиков трафика мы сравниваем использование выделенного сервера с использованимем «временных» серверов для балансировки. В результатах моделирования мы находим, что в течении пикового трафика можно использовать остаточную производительность DNS сервера или почтового сервера для разделения загрузки, что может быть более эффективно, чем добавление выделенного сервера.

Эта статья организована следующим образом. В пункте 2, мы перечислим некоторые исследования, относящиеся к теме архитектуры балансировки нагрузки и решения данной проблемы. Предложенная модель рассматривается в пункте 3. Мы представим моделирование и анализ производительности в пункте 4. Выводы даются в пункте 5.

2. Связанные работы

2.1 Интеллектуальный подход к перенаправлению запросов

В [8] Paul, Wu-Chi Feng, Panda и Sadayappan разработали интеллектуальный метод перенаправления запросов, который учитывает текущую загруженность серверов и направляет запрос к наименее загруженному. Диспетчер в данном механизме играет роль агента балансировки нагрузки. Каждый сервер имеет дополнительный процесс, который периодически отправляет информацию о состоянии диспетчеру. Диспетчер использует эту информацию, чтобы решить, какому серверу запрос должен быть направлен. Диспетчер собирает объявления от серверов и поддерживает таблицу с различными состояниями серверов. Когда HTTP запрос от клиента приходит, диспетчер смотрит имя наименее загруженного сервера из списка и затем посылает клиенту HTTP ответ, включающий информацию о сервере, который его обслужит. Каждый запрос подвергается добавлению относительно небольшой дополнительной стоимости во время процесса поиска. Но в конце концов, общее время ответа становится лучше при доступе к этому менее загруженному серверу.

2.2 Диспетчерский алгоритм

Популярным диспетчерским алгоритмом является round robin. При его использовании новые соединения назначаются следующим образом: первое соединение назначается первому серверу, следующее – второму серверу, и так далее. Когда процесс проходит все сервера, процесс начинается с начала. Другой известный алгоритм – least connection. В данном алгоритме количество соединений открытых на каждом веб-сервере измеряется в реальном времени. Сервер с наименьшим текущим количеством открытых соединений рассматривается как лучший выбор для следующего запроса.

3. Алгоритм остаточной производительности

В предлагаемой нами модели система состоит из N гетерогенных серверов {S1,S2,S3…SN}. Модуль сообщения статуса каждого сервера периодически сообщает текущую информацию модулю сбора загрузки. Алгоритм балансировки нагрузки рассчитывает текущие производительности серверов {R1,R2,R3…RN}. После этого выбирается лучший сервер і, при условии что max(R1,R2,R3…RN)=Ri. Если запрос Т приходит на диспетчер, адрес сервера Si с максимальной остаточной производительностью Ri отвечает клиенту. Мы полагаем, что максимальная производительность, которая требуется запросу Т – Тk. Если максимальная остаточная производительность Ri меньше, чем Tk это означает, что все сервера не имеют достаточной остаточной производительности для обслуживания запроса. Диспетчер отбрасывает этот запрос и возвращает клинету страницу «занято». Когда веб-сервера заканчивают обработку предыдущих запросов, они высвобождают производительность для обслуживания последующих запросов.

Модуль сообщения статуса сервера і сообщает параметры текущей загрузки {ci,mi,ni,ti}, где сi – процент простоя процессора, mi – доступная память, ni – текущее количество соединений, ti – парметр сетевого соединения. В сервере на базе Unix мы можем получить данные 4 параметра, используя команды, показанные на рис.1. Затем остаточная производительность сервера Si вытекает из формулы (1).

Ri=α * ƒ1(Ci)*ci+β*ƒ2(mi)+γ*ƒ3(ni)+δ*ƒ4(ti)
(1)

где α, β, γ, δ - веса, причем α + β + γ + δ = 1. В нашем моделировании мы находим, что доступная память и текущее соединение имеют значительное влияние на загрузки сервера. В моделировании, которое представлено в пункте 4, используются значения α=0,1, β=0,4, γ=0,4, δ=0,1 в качестве весов.

Рис. 1 Информационные параметры загрузки сервера
Рис. 1 Информационные параметры загрузки сервера

4. Результаты моделирования и анализ производительности

Для вычисления производительности предложенного подхода мы выполняем моделирование, используя как алгоритмы round robin (RR) и least connection (LC), так и предложенный алгоритм остаточной производительности – remaining capacity (RC). Измерение производительности включает частоту отбрасывания запросов и масштабируемость.

4.1 Сравнение частоты отбрасывания

В нашей тестовой среде мы используем три веб-сервера, обозначенные как S1, S2, S3. Производительности этих серверов S1>S2>S3. Мы генерируем клиентские запросы с частотой от 100 до 1000 запросов в секунду. Когда сервер исчерпал свою производительность, но диспетчер продолжает направлять клиентские запросы этому серверу, запросы отбрасываются. Оптимальная система балансировки нагрузки должна иметь как можно меньшую частоту отбрасывания. Сейчас мы сравниваем частоту отбрасывания трех алгоритмов балансировки нагрузки. Как показано на рис.2, RR алгоритм начинает отбрасывать клиентские запросы начиная с 300 запросов в секунду, но LC и RC алгоритмы начинают делать это на 600 и 700 запросах в секунду соответственно. Поскольку LC алгоритм рассматривает только номер соединения, он перенаправляет запрос веб серверу в соответствии с текущим соединением. Но в RC алгоритме остаточная производительность учитывается, таким образом запрос будет передаваться серверу с максимальной остаточной производительностью. Следовательно частота отбрасывания меньше чем в LC алгоритме.

Рис. 2 Частота отбарсывания трёх алгоритмов
Рис. 2 Частота отбрасывания трех алгоритмов

4.2 Масштабируемость системы балансировки нагрузки

В нашей архитектуре мы можем масштабировать систему балансировки нагрузки, используя остаточную производительность прочих «временных» серверов. Рис. 3(а) являет собой утилизацию только одного веб-сервера. Веб-сервер не способен обрабатывать около 350 запросов в секунду. Если мы добавляем другой веб-сервер в систему, утилизация этих двух веб-серверов показана на рис. 3(в), который способен обслужить большее количество запросов в секунду. В предлагаемой нами архитектуре мы используем остаточные производительности прочих серверов, таких как DNS и почтовый. Рассматривая использование остаточной производительности DNS сервера, нам необходимо зарезервировать некоторую долю производительности для своих нужд. В данном моделировании мы резервируем 10% производительности DNS сервиса, а оставшаяся производительность может быть использована как веб-сервис. Утилизация одного веб-сервера плюс одного DNS сервера показана на рис. 3(б). Похоже, что производительность не такая высокая, как на рис. 3(в). Сейчас мы продолжаем использовать остаточную производительность почтового сервера. Мы должны зарезервировать больше производительности для почтового сервиса (приблизительно 50%), таким образом оставшиеся 50% производительности могут быть использованы для веб-сервиса. Утилизация одного веб-сервера, одного DNS-сервера и одного почтового сервера показана на рис. 3(г).

Утилизация различных серверов Утилизация различных серверов
Рис. 3 Утилизация различных серверов

Рисунок 4 показывает частоту успешных сообщений одного веб-сервера; двух веб-серверов; одного веб-сервера и одного DNS-сервера; одного веб-сервера, одного DNS-сервера и одного почтового сервера. Когда мы используем остаточную производительность как DNS, так и почтового сервера, частота успешных сообщений больше, чем частота успешных сообщений двух веб-серверов. Это означает, что если мы можем использовать остаточные производительности, производительность будет лучше, чем при использовании еще одного выделенного сервера. Частота отбрасывания также сравнивается на рис. 5. Когда используются остаточные производительности как DNS-сервера, так и почтового, система начинает отбрасывать запросы на частоте около 700 запросов в секунду, что также лучше, чем при использовании другого выделенного веб-сервера.

Рис. 4 Частота успешных сообщений
Рис. 4 Частота успешных сообщений
Рис. 5 Частота отбрасывания различных серверов
Рис. 5 Частота отбрасывания различных серверов

Заключение

В данной статье остаточная производительность гетерогенного веб-сервера используется в качестве критерия принятия решения диспетчером. Алгоритмам round robin и least connection не свойственно равномерное распределение нагрузки к серверам с различной производительностью. Сервер с наименьшей производительностью должен обрабатывать меньшее количество запросов в связи с недостаточной вычислительной мощностью. В противном случае время ответа будет значительно увеличиваться, и с ним будет увеличиваться частота отбрасывания.

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

Список литературы

  1. D. Mosedale, W. Foss, and R. McCool, “Lessons Learned Administering Netscape’s Internet Site”, IEEE Internet Computing, Vol. 1, No. 2, Mar-Apr. 1997.
  2. Eric Dean Katz, Michelle Butler, and Robert McGrath, “A Scalable HTTP Server: The NCSA Protocol”, Proc. First International Conference on the World-Wide Web, 1994.
  3. Cardellini, V., Colajanni, M., and Yu, P.S., ”Request redirection algorithms for distributed Web systems”, IEEETrans. Parallel and Distributed Systems, vol 14, no 4, Apr.2003.
  4. M. Colajanni, P.S. Yu, and D.M. Dias, “Analysis of Task Assignment Policies in Scalable Distributed Web-Server Systems,” IEEE Trans. Parallel and Distributed Systems, Vol. 9, No. 6, June 1998, pp. 585–600.
  5. Tsang-Long Pao, Jian-Bo Chen, I-Ching Cheng, “An Analysis of Server Load Balance Algorithms for Server Switching”, Proc. Ming-Chung University International Academic Conference, Mar, 2004.
  6. Xin Liu, Andrew A. Chien, “Traffic-based Load Balance for Scalable Network Emulation”, Proc. ACM/IEEE Supercomputing 2003, Nov. 2003.
  7. Schroeder, T., Goddard, S., and Ramamurthy, B., “Scalable Web server clustering technologies”, IEEE Network, vol. 14, no 3, May-June 2000.
  8. Paul, A., Wu-Chi Feng; Panda, D.K., Sadayappan, P, “Balancing Web server load for adaptable video distribution”, Proc. International Workshops on Parallel Processing, pp. 469-476, 21-24 Aug. 2000.