Главная #

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(количество серверов * время ожидания в секундах на каждый сервер (-t)) + 1

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

Затем создайте ферму LSLB > L4xNAT , например, с именем navigation_proxy , указав виртуальный IP-адрес и виртуальный порт , как показано на предыдущей схеме. После создания перейдите в расширенный режим редактирования и убедитесь, что тип протокола настроен как TCP , а тип NAT — как NAT.

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

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

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

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

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

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

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