Содержание
Главная
A Прокси-сервер может быть описан как серверное устройство или приложение, которое выполняет посредничество для запросов от клиентов или клиентов, пытающихся найти ресурсы с нескольких серверов, предоставляющих эти ресурсы. Как было объяснено, это означает, что прокси-сервер работает от имени клиента или клиента, когда запрашивается услуга, и, возможно, потенциально скрывает реальное происхождение или источник запроса к серверу.
Процесс заключается в том, что клиент делает запрос непосредственно к прокси-серверу, вместо того, чтобы подключаться только к конкретному серверу, который может предоставить запрошенный ресурс, например файлы или веб-сайты, а затем прокси-сервер оценивает этот запрос и разрабатывает соответствующую и требуемую сеть. сделки. Это способ упростить или лучше контролировать сложность запроса, и, кроме того, он обеспечивает другие преимущества, такие как безопасность, ускорение содержимого или конфиденциальность. Прокси-серверы предназначены для инкапсуляции и структурирования существующих распределенных систем. Некоторые из наиболее часто используемых прокси-серверов для веб-навигации: Кальмар, Privoxy или SwiperProxy.
Иногда прокси-сервера недостаточно для управления количеством одновременно работающих пользователей, или прокси сам по себе единая точка отказа то, что необходимо решить, тогда полностью требуется АЦП.
В следующей статье описывается способ обеспечения высокой доступности и масштабируемости для службы прокси-сервера навигации. В случае отказа одного из прокси-серверов балансировщик нагрузки, реализованный с помощью контроллера доставки приложений 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).
Наконец, наслаждайтесь высокодоступным прокси-сервером веб-навигации с балансировкой нагрузки!