Балансировка нагрузки и высокая доступность прокси-сервисов веб-навигации

СООБЩЕНИЕ ОТ Zevenet | 2 марта 2021 г.

Главная

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

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

Иногда прокси-сервера недостаточно для управления количеством одновременно работающих пользователей, или прокси сам по себе единая точка отказа то, что необходимо решить, тогда полностью требуется АЦП.

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

Архитектура прокси-сети

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

балансировщик нагрузки прокси-кластера zevenet

Различные клиенты (ноутбуки, компьютеры, мобильные телефоны и планшеты) настраивают навигационный браузер, указывающий на корпоративный прокси, например https://proxy.company.com:3128. Все подключения клиентов к прокси-серверу веб-навигации в простой форме. HTTP or SSL будет TCP на основе, поэтому он будет использоваться для создания нашей фермы балансировки нагрузки.

Разрешение IP для proxy.company.com - это Виртуальный IP уже настроен в балансировщике нагрузки. В контроллере доставки приложений ZEVENET есть ферма поверх такого виртуального IP, например 192.168.103.34 и виртуальный порт 3128 in NAT режим для TCP протокол.

Ферма настроена со всеми бэкэндами, которые создают пул прокси навигации, в нашем примере 192.168.103.253 и 192.168.103.254 через порт TCP 3128. Как только клиент попытается подключиться к настроенному прокси-серверу, ADC получит соединение и будет перенаправлено на один из доступных навигационных прокси-серверов в пуле, разделяющих пользователей между всеми доступными внутренними прокси-серверами.

Конфигурация высокой доступности прокси веб-навигации

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

Проверка работоспособности прокси-сервера для веб-навигации

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

Перейти в раздел МОНИТОРИНГ> Хранитель фермы, создайте нового стража фермы с именем check_tcp_navigation_proxy и скопировать из check_tcp и внесите небольшие изменения в таймауты, как показано ниже:

В разделе Command поле добавить флаг -t 5, это тайм-аут на серверную часть для ответа на TCP-соединение от балансировщика нагрузки. В Интервал В поле настроено значение 11 секунд на бэкэнд + 5 дополнительная секунда, чтобы избежать рекурсии. Мы рекомендуем использовать следующую формулу для установки оптимального Интервал значения.

(number of backends * timeout seconds per backend (-t) ) + 1

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

Затем создайте LSLB> L4xNAT ферма, например, с названием navigation_proxy, В том числе Виртуальный IP и Виртуальный порт как показано на предыдущей диаграмме. Как только он будет создан, перейдите к редактированию в Дополнительно режим и убедитесь, что Тип протокола настроен в TCP и Тип NAT настроен в NAT Режим.

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

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

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

Теперь виртуальная служба с балансировкой нагрузки может быть протестирована перед настройкой клиентов.

Конфигурация клиентов

Последний шаг - настроить параметры прокси в веб-браузере клиента, указывающие на Виртуальный IP и Виртуальный порт используется в балансировщике нагрузки, или введите Виртуальный IP в кооперативе DNS и использовать Имя и фамилия вместо этого в клиентах, в нашем примере proxy.example.com указывает на виртуальный IP-адрес 192.168.103.34).

Наконец, наслаждайтесь высокодоступным прокси-сервером веб-навигации с балансировкой нагрузки!

Поделись:

Документация в соответствии с условиями GNU Free Documentation License.

Была ли эта статья полезна?

Статьи по теме