Назад | Перейти на главную страницу

Эффективная балансировка нагрузки для клиентов за NAT

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

Облако <--> Балансировщик нагрузки <--> ИНТЕРНЕТ <--> NAT <--> 20 клиентов

Поскольку LB использует постоянство исходного IP-адреса, все веб-запросы от всех клиентов попадают в один и тот же узел в облаке. Это, конечно, связано с NAT, который гарантирует, что каждый пакет TCP / IP содержит один и тот же исходный IP-адрес.

Поскольку все запросы попадают в один и тот же узел в облаке, очень часто узел выдает ошибку 503: http://www.checkupdown.com/status/E503.html, потому что узел перегружен соединениями.

Как лучше всего решить эту проблему? Обратите внимание, что у нас нет контроля над балансировщиком нагрузки и узлами в облаке. У нас есть доступ только к оболочке для загрузки файлов для нашего веб-приложения.

  1. Установить веб-сервер в нашем местном офисе, который может обслуживать 20 клиентов? (На самом деле мы не хотим заниматься обслуживанием сервера.)
  2. Подключить каждого клиента к WAN так, чтобы каждый клиент получал свой IP-адрес? (Небезопасно и невозможно с IPv4, возможно, возможно с IPv6.)
  3. Посмотрите, сможет ли наш веб-хостинг настроить балансировщик нагрузки на использование балансировки нагрузки на основе DNS? (Решит ли это нашу проблему? Где будет находиться кеш DNS?)
  4. Посмотрите, может ли наш веб-хостинг настроить балансировщик нагрузки на использование HTTP-куки для балансировки нагрузки? (Вероятно, лучшее решение, если узлы имеют статический IP-адрес.)
  5. Еще одно решение вместе ...

Вариант 4 является «самым простым», потому что он означает (1) отсутствие нового сервера и (2) отсутствие перенастройки IP в вашей сети.

DNS может работать (вы говорите о циклическом переборе DNS, верно?), Но, вероятно, это больше работы, чем балансировка нагрузки на основе файлов cookie. Я хотел бы поговорить об этом с вашим хозяином.

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

Однако точны ли цифры ваших клиентов? 20 клиентов перегружают ваше веб-приложение? Возможно, вам стоит решить проблему, связанную с тем, что ваше приложение не может обрабатывать такое количество клиентов. Не зная НИЧЕГО о вашем приложении, 20 кажется довольно низким. Но я мог ошибаться. :)

Третья альтернатива: требует ли ваше приложение липкости? Если ваши клиенты могут без проблем переходить с веб-сервера на веб-сервер, тогда забудьте о балансировке нагрузки по IP и выполняйте циклический переход на каждое соединение или наименьшее количество соединений для каждого соединения.