UserGate позволяет осуществлять балансировку нагрузки на различные сервисы, находящиеся внутри локальной сети. Балансировка может быть предоставлена:
* Для внутренних серверов, публикуемых в интернете (DNAT).
* Для внутренних серверов без публикации.
* Для балансировки трафика, пересылаемого на внешние серверы (ферму) ICAP-серверов.
* Для балансировки трафика на серверы, публикуемые через reverse-прокси.
Балансировщик распределяет запросы, поступающие на IP-адрес виртуального сервера, на IP-адреса реальных серверов, используя при этом различные методы балансировки. Чтобы настроить балансировку, необходимо в разделе Политики сети-->Балансировка нагрузки создать правила балансировки.
Для создания правила балансировки для серверов TCP/IP необходимо выбрать пункт Добавить балансировщик TCP/IP и указать следующие параметры:
|
Наименование |
Описание |
|
Включен |
Включает или отключает данное правило. |
|
Название |
Название правила балансировки. |
|
Описание |
Описание правила балансировки. |
|
IP-адрес виртуального сервера |
Необходимо выбрать из списка IP-адресов, назначенных на сетевые интерфейсы. При необходимости администратор может добавить дополнительные IP-адреса на желаемый интерфейс. |
|
Порт |
Порт, для которого необходимо производить балансировку нагрузки. |
|
Протокол |
Протокол - TCP или UDP - для которого необходимо производить балансировку нагрузки. |
|
Метод балансировки |
Возможны 4 различных метода распределения нагрузки на реальные серверы: * Round robin - каждое новое подключение передается на следующий сервер в списке, равномерно загружая все серверы . * Weighted round robin - работает аналогично Round robin, но загрузка реальных серверов осуществляется с учетом весовых коэффициентов, что позволяет распределить нагрузку с учетом производительности каждого сервера. * Least connections - новое подключение передается на сервер, на который в данный момент установлено наименьшее число соединений. * Weighted least connections - работает аналогично Least connections, но загрузка реальных серверов осуществляется с учетом весовых коэффициентов, что позволяет распределить нагрузку с учетом производительности каждого сервера. |
|
Реальные серверы |
Добавляется пул реальных серверов, на которые перенаправляется трафик. Для каждого из серверов необходимо указать: * IP-адрес сервера. * Порт сервера. Порт, на который пересылать запросы пользователей. * Вес. Данный коэффициент используется для неравномерного распределения нагрузки на реальные серверы для режимов балансировки weighted round robin и weighted least connections. Чем больше вес, тем больше будет нагрузка на сервер. * Режим. Может быть два варианта: |
|
Аварийный режим |
Аварийный режим используется, когда не доступен ни один из реальных серверов. Для активации аварийного режима необходимо включить его и указать: * IP-адрес сервера. * Порт сервера. Порт, на который пересылать запросы пользователей. * Вес. Данный коэффициент используется для неравномерного распределения нагрузки на реальные серверы для режимов балансировки weighted round robin и weighted least connections. Чем больше вес, тем больше будет нагрузка на сервер. * Режим. Может быть два варианта: |
|
Мониторинг |
С помощью мониторинга можно настроить проверку реальных серверов на определение их работоспособности. Если проверка прошла неуспешно для реального сервера, он исключается из балансировки. |
|
Режим |
Способ мониторинга реальных серверов. Возможны варианты: * ping - проверить доступность узла с помощью утилиты ping. * connect - проверить работоспособность узла, установив TCP-соединение на определенный порт. * negotiate - проверить работоспособность узла посылкой определенного HTTP- или DNS-запроса и сравнением полученного ответа с ожидаемым ответом. Для настройки этого режима следует выбрать тип сервиса (HTTP или DNS), строки Запрос и Ожидаемый ответ. |
|
Интервал проверки |
Интервал времени, через которое должна выполняться проверка. |
|
Время ожидания |
Интервал времени ожидания ответа на проверку . |
|
Число неудачных попыток |
Количество попыток проверки реальных серверов, по истечению которого сервер будет считаться неработоспособным и будет исключен из балансировки. |
Важно! Правила балансировки имеют более высокий приоритет и применяются до правил NAT/DNAT/Маршрутизации.
Балансировщик серверов ICAP позволяет распределить нагрузку на внешние серверы или ферму серверов ICAP, например, на внешнюю ферму серверов с антивирусным ПО. Данный балансировщик затем может быть использован в правилах ICAP. Для создания балансировщика серверов ICAP необходимо выбрать пункт Добавить балансировщик ICAP и указать следующие параметры:
|
Наименование |
Описание |
|
Включен |
Включает или отключает данное правило. |
|
Название |
Название правила балансировки. |
|
Описание |
Описание правила балансировки. |
|
ICAP-профили |
Выбрать ICAP-профили серверов, на которые будет распределяться нагрузка. Более подробно о работе с серверами ICAP читайте в разделе Работа с внешними ICAP-серверами. |
Балансировщик серверов reverse-прокси позволяет распределить нагрузку на внутренние серверы или ферму серверов, публикуемую с помощью правил reverse-прокси. Данный балансировщик затем может быть использован в правилах reverse-прокси. Для создания балансировщика reverse-прокси необходимо выбрать пункт Добавить балансировщик reverse-прокси и указать следующие параметры:
|
Наименование |
Описание |
|
Включен |
Включает или отключает данное правило. |
|
Название |
Название правила балансировки. |
|
Описание |
Описание правила балансировки. |
|
Reverse-прокси профили |
Выбрать reverse-прокси профили серверов, на которые будет распределяться нагрузка). Более подробно о публикации с помощью reverse-прокси читайте в разделе Первое правило в списке - блокировка с помощью DNSBL. Рекомендуется оставить списки исключений по Envelop from/Envelop to пустыми. В этом случае DNSBL будет отбрасывать подключения SMTP-серверов, замеченных в распространении спама, еще на этапе коннекта. При наличии e-mail адресатов в исключениях система будет вынуждена принимать сообщения целиком для анализа этих полей, что увеличит нагрузку на сервер и ухудшит производительность проверки почтового трафика. * Второе правило - маркировка писем с помощью антиспама UserGate. Здесь можно использовать любые исключения, в том числе и по Envelop from/Envelop to. Для протокола POP3(S): * Действие - Маркировать. * Проверка - Антиспам UserGate. Публикация HTTP/HTTPS-ресурсов с помощью reverse-прокси. |