Обработка Сигналов Реального Времени в Кластерах

PBX Задачи в CommuniGate Pro взаимодействуют при помощи отправки событий в описатели задач. Описатель задачи - это объект-ссылка, описывающий PBX Задачу, Сессию или Сигналы Реального Времени. В Кластерной среде CommuniGate Pro Описатель задачи содержит также адрес сервера - члена Кластера, на котором обрабатывается PBX Задача, Сессия или Сигнал.

Когда событие должно быть передано другому члену кластера, оно доставляется при помощи внтутрикластерного протокола CLI/API. Получатель события может ответить, используя описатель задачиотправителя; в этом случае снова будет задействован внутрикластерный протокол CLI/API для доставки события-ответа.

PBX Задачи обычно задействуют Медиа Каналы. Чтобы обеспечить возможность обмена медиа с внешними участникам, Задачи PBX должны запускаться только на тех членах Кластера, которые имеют непосредственный доступ к Интернет.

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

Когда компонент Сигнал направляет входящий звонок в сессию XIMSS, он создаёт объект Плечо Звонка на том же члене Кластера, который обрабатывает Сигнал с запросом на входящий звонок. Объект Плечо Звонка затем "присоединяется" к сессии XIMSS (запущенной на каком-либо Бэкенд-Сервере, который может быть другим членом Кластера).

Если сессия XIMSS и её Плечо Звонка запущено на другом члене Кластера, то они взаимодействуют через специальные события, доставляемые при помощи внутрикластерного протокола CLI/API.

Обработка Сигналов Реального Времени требует обращения к DNS Клиенту , создания запросов SIP and XMPP.
Когда Кластер настроен так, что только фронтенды имеют соединения с публичной сетью, некоторые услуги могут осуществляться только через фронтенды.

Даже когда Приложения Реального Времени и Плечи Звонков настроены для обработки только на Фронтенд-Серверах, Сигналы Реального Времени могут генерироваться ми на других членах кластера: Сессии XIMSS и XMPP, Автоматические Правила и другие компоненты могут отправлять Мгновенные сообщения, Наборы Событий могут создавать Сигналы уведомлений и так далее.

Когда Сигнал Реального Времени обрабатывается на Фронтенд-Сервере, он использует внутрикластерный протокол CLI/API для получения данных Пользователя (например, регистрации SIP) или для выполнения запрошенных действий (по доставки запроса SUBSCRIBE или XMPP IQ, или для начала звонка).

Для настройки Создания Плечей Звонков откройте через Веб Интерфейс Администратора в области Установки страницу Общее и нажмите на ссылку Кластеры:

Сигнализация

Создание Плеч Звонков:	АвтомататическиУдалённоЛокальноЛокально для Других
Обработка Сигналов:	АвтомататическиУдалённоЛокальноЛокально для Других

Создание Плеч Звонков

Эта настройка указывает, каким образом Плечи Звонков должны обрабатываться этим членом Кластера.

Локально

запросы на создание Задачи Реального Времени или Плеча Звонка выполняются на том же Сервере (это обычный, односерверный режим обработки).

Локально для Других

Задачи Реального Времени и Плечи Звонков создаются на том же Сервере.
Контроллер Динамического Кластера информируется о том, что этот Сервер может создавать Задачи Реального Времени и Плечи Звонков для других членов Кластера.
Контроллер Динамического Кластера собирает и распространяет информацию обо всех активных членах Кластера, у которых выбрана эта опция.

Удалённо

запросы на создание Задач Реального Времени и Плкеч Звонков передаются для выполнения тому члену Кластера, у которого эта настройка имеет значение Локально для Других.

Автоматически

аналогично:

Локально

если этот Сервер не входит в Динамический Кластер.

Локально для Других

если это - Фронтенд-Сервер Динамического Кластера.

Удалённо

если это - Бэкенд-Сервер Динамического Кластера.

Обработка Сигналов

Эта настройка указывает, каким образом Сигналы Реального Времени должны обрабатываться этим членом Кластера. Значения этой настройки имеют тот же смысл, что и для настройки Создание Плеч Звонков.

Возможности SIP Farm® CommuniGate Pro позволяют нескольким членам Кластера обрабатывать пакеты с SIP запросами, распределяемыми для них случайным образом Балансировщиком Нагрузки.

Настройте Балансировщик Нагрузки на распределение входящих SIP UDP пакетов (по умолчанию, порт номер 5060) на порты SIP выбранных членов Кластера, входящих в SIP-Ферму.
Если в Кластере есть Фронтенд-Серверы, то все или некоторые из них могут использоваться как члены SIP-Фермы.

Настройте членов SIP-Фермы: через Веб Интерфейс Администратора откройте в области Установки страницу Общее и нажмите на ссылку Кластеры:

Сигнализация

SIP-Ферма:

АвтомататическиВыключеноПередаватьУчастник

SIP-Ферма

Эта настройка указывает, как этот член Фермы должны обрабатывать запросы SIP.

Участник

Если выбрана опция Участник, то член Кластера участвует в SIP-Ферме. Он обрабатывает новые запросы локально или перенаправляет их другим членам SIP-Фермы, используя специальные алгоритмы распределения трафика в SIP-Ферме.

Выключено

Если выбрана опция Выключено, то этот член Кластера не является участником SIP-Фермы; он будет обрабатывать входящие запросы SIP локально.

Передавать

Если выбрана опция Передавать, то этот член Кластера не является участником SIP-Фермы; но, когда ему необходимо будет отправить запрос SIP, он будет ретранслировать его через любые доступные члены SIP-Фермы.
Выберите эту опцию для тех Бэкенд-Серверов, которые не имеют прямого доступа в Интернет и, следовательно, не могут напрямую отправлять запросы SIP.

Автоматически

• если этот Сервер не входит в Динамический Кластер, то так же, как Выключено
• если этот Сервер является Frontend-ом Динамического Кластера, то так же, как Участник
• если это - Бэкенд-Сервер Динамического Кластера, то так же, как Передавать; если есть другие члены Динамического кластера настроенные как Участник, если нет - так же, как Выключено

Обратите внимание: SIP запрос может быть явно направлен указанному члену Кластера (так обрабатывается большинство запросов внутри установленных диалогов). Эти запросы всегда перенаправляются на указанного члена Кластера и обрабатываются им независимо от установок в настройках SIP-Фермы.

Кластер CommuniGate Pro учитывает информацию обо всех своих Серверах, у которых опция SIP-Ферма установлена в значение Участник. Входящие UDP пакеты и TCP соединения распределяются по этим Серверам при помощи обычных Балансировщиков Нагрузки.

Получающий Сервер определяет, должен ли полученный пакет обрабатываться на конкретном Сервере Фермы: он проверяет, не содержит ли пакет ответ или подтверждением (ACK) существующей транзакции и не направляется ли он на Узел, созданный на конкретном Сервере. В этом случае пакет ретранслируется правильному члену Кластера:

Пакеты, не направленные конкретным членам Кластера при помощи алгоритмов SIP-Фермы CommuniGate Pro, распределяются по всем доступным в настоящее время Членам Фермы.

Для обработки Сигнала членам Кластера может потребоваться получение определённой информации Пользователя (регистрация, настройки и т.п.). Если член Кластера не может открыть Пользователя (из-за того, что этот член Кластера является Фронтенд-Сервером или по причине того, что Пользователь открыт другим Бэкенд-Сервером), то он использует Внутри-Кластерный Интерфейс Командной Строки CLI/API для получения информации от соответствующего Бэкенд-Сервера.

Для реализации SIP-Фермы могут использоваться различные конфигурации сети и Балансировщиков Нагрузки:

Балансировщик Нагрузки - NAT с Одним IP

Этот метод используется для небольших внедрений Кластеров в ситуациях, когда Фронтенд-Серверы не имеют прямого доступа к Интернет, и Трансляцию Сетевых Адресов для них выполняет сам Балансировщик Нагрузки.

Сначала выберите "виртуальный" IP адрес (VIP) - это единственный адрес, который будут "видеть" пользователи SIP вашего Кластера:

• назначьте VIP адрес Балансировщику Нагрузки
• выберите имя в DNS для "SIP услуг" (такое, как sip.mysystem.com) и создайте для этого имени в DNS A- или AAAA- записи, указывающие на VIP адрес.
• создайте DNS SIP SRV запись для всех Доменов Кластера, указывающую на доменное имя, выбранное для "SIP услуг".
• откройте в Веб Интерфейс Администратора CommuniGate Pro в разделе Установки страницу Сеть и укажите VIP адрес как Общекластерный IP адрес WAN; оставьте поле Общесерверного IP адреса WAN пустым.

Фронтенд-Серверы имеют IP адреса F1,F2, F3, ...

Настройте Балансировщик Нагрузки на обработку входящих UDP пакетов, получаемых на этот VIP адрес и порт номер 5060:

• входящие пакеты должна равномерно распределяться на адреса Фронтенд-Серверов F1, F2, F3, везде на порт 5060.
• Балансировщик Нагрузки не должен использовать никакую специфическую для SIP логику обработки таких пакетов; если ваш Балансировщик Нагрузки имеет какие-либо специфические опции для обработки SIP трафика, то убедитесь, что они выключены. Некоторые Балансировщики Нагрузки по умолчанию обрабатывают порт 5060 с учётом специфики SIP: уточните этот момент у производителя вашего Балансировщика Нагрузки.
• входящие пакеты не должны создавать "сессию" в Балансировщике Нагрузки, то есть, он не должен хранить информацию об UDP пакете после того, как пакет был направлен на какой-либо Фронтенд-Сервер.

Специфические для SIP техники, реализованные в некоторых Балансировщиках Нагрузки, позволяют им отправлять "связанные" между собой запросы на один сервер. Обычно такие техники основываются на поле запроса Call-ID и очень часто работают некорректно. Технология SIP-Фермы, используемая в CommuniGate Pro, гарантирует правильную обработку запросов, если запрос или пакет с ответом получены любым из членов SIP-Фермы. Следовательно, CommuniGate Pro не требует использования в Балансировщике Нагрузки специфических для SIP техник.

Многие Балансировщики Нагрузки, даже если они и не используют никакую специфичную SIP технику, создают "привязку к сессии" для входящих UDP запросов, точно также, как они обрабатывают входящие TCP соединения.
Таблица Привязки для произвольного порта Балансировщика Нагрузки v (и VIP адреса Балансировщик Нагрузки) содержит пару из IP адреса и порта:

Где X:x является IP адресом удалённого (отправляющего) устройства, а F1:f является IP адресом и номером порта Фронтенд-Сервера, на которые направляется входящий пакет.
Когда удалённое устройство пересылает запрос, эта запись в таблице позволяет Балансировщику Нагрузки отправлять запрос на тот же Фронтенд-Сервер (обратите внимание, что это не требуется для SIP-Фермы CommuniGate Pro).

Эти Балансировщики Нагрузки обычно создают "привязку к сессии" также и для исходящих UDP запросов: когда пакет отправляется с адреса/порта какого-либо Фронтенд-Сервера F2:f на какой-нибудь удалённый адрес/порт Y:y, в таблице Привязки Балансировщика Нагрузки создаётся запись:

Когда удалённое устройство отправляет пакет с ответом, эта запись в таблице позволяет Балансировщику Нагрузки отправить ответ на "правильный" Фронтенд-Сервер (обратите внимание, что это не требуется для SIP-Фермы CommuniGate Pro).

SIP-Ферма CommuniGate Pro распределяет пакеты SIP запросов, ретранслируя их между Фронтенд-Серверами в соответствии с алгоритмами работы SIP-Фермы; такие алгоритмы перенаправляют пакеты с ответами SIP на Фронтенд-Сервер, отправивший соответствующий SIP запрос.
Эти возможности SIP-Фермы CommuniGate Pro делают бесполезным использование таблицы "привязки сессии" Балансировщика Нагрузки (при использовании SIP UDP)

"Привязка к сессии" Балансировщика Нагрузки должна быть выключена (для SIP UDP), потому что это не только создаёт излишнюю нагрузку, но и зачастую портит адрес исходящего SIP пакета:

Когда Балансировщик Нагрузки получает пакет с SIP запросом от адреса X:x и ретранслирует его на адрес/порт Фронтенд-Сервера F1:5060, то SIP-Ферма может ретранслировать этот запрос далее на какой-либо другой Фронтенд-Сервер (на адрес/порт F2:5060), где и будет создана транзакция SIP Сервера и обработан запрос.
Ответы SIP будут генерироваться на этом Фронтенд-Сервере, и пакеты с ответами SIP будут отправляться на X:x с адреса/порта F2:5060 (через Балансировщик Нагрузки).
Если Балансировщик Нагрузки не использует "привязку к сессии", то он должен просто изменить адрес источника пакета с F2:5060 на VIP:5060 и направить пакет на адрес X:x.

Если Балансировщик Нагрузки использует "привязку к сессии" для UDP, то он ожидает увидеть пакет с откликом только с адреса F1:5060; затем он, изменив адрес источника пакета с откликом с F1:5060 на VIP:5060, отправит его на X:x.
Пакеты от других серверов (которые не имеют "привязки к сессии") обрабатываются как "исходящие пакеты", и Балансировщик Нагрузки для них строит новую "привязку к сессии" (смотрите выше). В нашем случае, когда Балансировщик Нагрузки отправляет запрос от X:x на F1:5060, а ответ получает с F2:5060, он создаст вторую "привязку к сессии":

X:x <-> F1:5060
X:x <-> F2:5060

Для большинства Балансировщиков Нагрузки это приведёт к конфликтам "привязки к сессии", и для разрешения таких конфликтов Балансировщик Нагрузки будет использовать техники NAT и изменять не только адрес источника исходящего пакета, но также и порт источника и, таким образом, пакет на X:x будет отправляться с адресом источника не VIP:5060, а VIP:5061 (или любым другим портом, используемым Балансировщиком Нагрузки для NAT). Многие SIP устройства, и почти все SIP устройства, находящиеся за межсетевыми экранами не будут принимать ответы с адреса/порта VIP:5061 если они ранее отправляли запросы на адрес/порт VIP:5060.

Для того, чтобы избежать появления вышеописанных проблем, уточните у производителя вашего Балансировщика Нагрузки что Балансировщик Нагрузки действительно не использует "привязку к сессии" для UDP порта 5060.

Балансировщик нагрузки - NAT с Несколькими IP

В этой конфигурации Фронтенд-Серверы имеют прямой доступ к Интернет (у них есть IP адреса, напрямую "видимые" из Интернет).

• Балансировщик Нагрузки перенаправляет запросы на эти реальные F1, F2, F3... Адреса Фронтенд-Серверов.
• Балансировщик Нагрузки должен быть реализован как коммутатор, так, чтобы исходящий с Фронтенд-Серверов трафик проходил через Балансировщик Нагрузки.
• Балансировщик Нагрузки должен изменять источник IP адресов всех исходящих SIP UDP пакетов, приходящих от Фронтенд-Серверов (от Fn:5060) на VIP:5060.

Балансировщики Нагрузки с "привязкой к сессии" UDP будут иметь такие же проблемы, как описано выше.

Балансировщик Нагрузки DSR

DSR (Direct Server Response, Прямой Ответ Сервера) является наиболее предпочтительным методом Балансировки Нагрузки при крупных установках.

Для использования DSR метода создайте "псевдоним" для сетевого интерфейса "внутренней петли" (loopback network interface) каждого Фронтенд-Сервера. Стандартным адресом для внутренней петли является 127.0.0.1; создайте для неё псевдоним с VIP адресом и маской сети 255.255.255.255:

Solaris

ifconfig lo0:1 plumb
ifconfig lo0:1 VIP netmask 255.255.255.255 up

Для того, чтобы сделать эту конфигурацию постоянной, создайте файл /etc/hostname.lo0:1 с VIP-адресом в нём.

Linux

ifconfig lo:0 VIP netmask 255.255.255.255 up

Для того, чтобы сделать эту конфигурацию постоянной, создайте файл /etc/sysconfig/network-scripts/ifcfg-lo:0:

DEVICE=lo
IPADDR=VIP
NETMASK=255.255.255.255
ONBOOT=yes

Убедитесь, что ядро настроено так, что оно не рассылает ARP для этого lo интерфейса (так что VIP адреса не связаны ни с каким Фронтенд-Сервером в arp-таблицах). В зависимости от версии ядра Linux, следующие в файл /etc/sysctl.conf должны быть добавлены следующие команды:

# ARP: reply only if the target IP address is
# a local address configured on the incoming interface
net.ipv4.conf.all.arp_ignore = 1
#
# When an arp request is received on eth0, only respond
# if that address is configured on eth0.
net.ipv4.conf.eth0.arp_ignore = 1
#
# Enable configuration of arp_announce option
net.ipv4.conf.all.arp_announce = 2
# When making an ARP request sent through eth0, always use an address
# that is configured on eth0 as the source address of the ARP request.
net.ipv4.conf.eth0.arp_announce = 2
#
# Repeat for eth1, eth2 (if exist)
#net.ipv4.conf.eth1.arp_ignore = 1
#net.ipv4.conf.eth1.arp_announce = 2
#net.ipv4.conf.eth2.arp_ignore = 1
#net.ipv4.conf.eth2.arp_announce = 2

FreeBSD

Для того, чтобы сделать эти изменения в конфигурации постоянными, добавьте следующую строку в файл /etc/rc.conf:

ifconfig_lo0_alias0="inet VIP netmask 255.255.255.255"

Другие ОС

уточните у производителя ОС

• Если создаётся "псевдоним", то Фронтенд-Серверы не отвечают на "arp" запросы на этот VIP адрес и все пакеты, направляемые на VIP адрес, будут перенаправлены на Балансировщик Нагрузки.
• Если Балансировщик нагрузки использует DSR метод, то он не изменяет IP адрес назначения (VIP) у входящих пакетов. Вместо этого, Балансировщик Нагрузки перенаправляет пакеты при помощи адреса физического уровня сети (MAC) выбранного Фронтенд-Сервера.
• По причине того, что у Фронтенд-Сервера на одном из его сетевых интерфейсов задан VIP адрес (на интерфейсе внутренней петли), он принимает эти пакеты как локальные и передаёт их приложению, "слушающее" указанные TCP или UDP порт.
• Из-за того, что у Фронтенд-Сервера на одном из его сетевых интерфейсов задан VIP адрес, ответы и другие исходящие пакеты могут быть отправлены с использованием VIP адреса в качестве адреса источника. Если эти пакеты проходят через Балансировщик Нагрузки (а они могут не проходить через него), то он не должен их изменять никаким образом.

Обратите внимание: Из-за того, что для перенаправления входящих пакетов используются MAC адреса, Балансировщик Нагрузки и все Фронтенд-Сервера должны входить в один сегмент сети; между Балансировщиком Нагрузки и Фронтенд-Серверами не должно быть Маршрутизатора.

Обратите внимание: при создании сетевого "псевдонима", откройте через Веб Интерфейс Администратора CommuniGate Pro в разделе Общее страницу Информация и нажмите на кнопку Обновить, чтобы сервер мог обнаружить добавленный IP адрес.

DSR метод прозрачен для всех сервисов, работающих через TCP (включая SIP через TCP/TLS) и для него не требуются никакие дополнительные настройки Сервера CommuniGate Pro: когда на локальный VIP адрес принимается TCP соединение, исходящие пакеты для такого соединения будут всегда иметь в качестве адреса источника тот же самый VIP адрес.

Для того, чтобы использовать DSR метод для SIP UDP, конфигурация Фронтенд-Серверов CommuniGate Pro должна быть изменена:

• через Веб Интерфейс Администратора откройте раздел Установки. В разделе Real-Time откройте страницу SIP, затем откройте страницу Транспорт
• нажмите на ссылку UDP Приёмник, для того чтобы открыть страницу Приёмника
• по умолчанию Приёмник SIP UDP имеет один сокет: он принимает "все адреса" на порту 5060.
• измените настройку, изменив значение "все адреса" на значение VIP (адрес VIP должен быть доступен для выбора из меню).
• нажмите на кнопку Модифицировать
• создайте дополнительный сокет для получения входящих пакетов на порт 5060, "все адреса" и нажмите на кнопку Модифицировать

Теперь у вас есть два сокета - первый для VIP:5060, а второй для все адреса:5060; при необходимости Фронтенд-Сервер может использовать первый сокет для отправки пакетов с VIP адресом в качестве адреса источника.
Повторите эти изменения в настройке для всех Фронтенд-Серверов.

Каждый Медиа поток, терминируемый CommuniGate Pro (поток, ретранслируемый при помощи медиа прокси или поток, обрабатываемый в канале медиа миксера) связывается с конкретным членом Кластера. Балансировщик Нагрузки должен гарантировать, что все входящие Медиа пакеты доставляются надлежащему члену Кластера.

Метод с Одним IP

Метод "с Одним IP" целесообразно применять при небольших и средних установках.
Члены Кластера имеют внутренние адреса L1, L1, L3 и т.д.
Балансировщик Нагрузки имеет внешний адрес G0.
Сетевые Настройки каждого Члена Кластера изменяются таким образом, чтобы Медиа Порты, используемые каждым Членом, были различны: порты 10000-19999 у Члена L1, порты 20000-29999 у Члена L2, порты 30000-39999 у Члена L2 и т.д.
Все пакеты, приходящие на адрес G0 на стандартный порт (5060 для SIP) распределяются по адресам L1, L2, L3, на эти же порты.
Все пакеты, приходящие на адрес G0 на медиа порты распространяются в соответствии с диапазоном портов:

• пакеты, приходящие на порты 10000-19999 направляются на адрес L1 (без изменения номеров портов)
• пакеты, приходящие на порты 20000-29999 направляются на адрес L2 (без изменения номеров портов)
• пакеты, приходящие на порты 30000-39999 направляются на адрес L3 (без изменения номеров портов)

Настойка Общесерверного Адреса WAN IP должна быть пустой у всех Членов Кластера.
Настройка Общекластерного Адреса WAN IP должна быть установлена в адрес G0.

Этот метод не должен использоваться при больших установках (за исключением случаев, когда сервер не терминирует медиа вообще или терминирует очень в небольших количествах): он позволяет вам разместить только 64000 портов для всех медиа потоков Кластера (каждый AVP поток забирает 2 порта, так что общее число аудио потоков ограничено 32000, а если используется видео (вместе с аудио), то такой Кластер не сможет обслуживать более чем 16000 одновременных аудио/видео сессий.

Балансировщик Нагрузки с Несколькими IP без NAT

Метод "с Несколькими IP" полезен в случае крупных установок. Каждый Фронтенд-Сервер имеет свой собственный IP адрес и при создании на Фронтенд-Сервере Медиа Канала или Медиа Прокси, этот уникальный IP адрес используется для прямой коммуникации между Сервером и клиентским устройством (или удалённым сервером).

Сетевые Настройки каждого Члена Кластера могут использовать одинаковые диапазоны Медиа Портов, и, таким образом, число одновременных потоков не ограничивается 64000 портами.

В простейшем случае все Фронтенд-Серверы имеют "реальные" IP адреса, то есть они соединены непосредственно с Интернет.

Если Балансировщик Нагрузки использует DSR метод (смотрите выше), то он не должен заботится о пакетах, отправляемых не с VIP адресов Фронтенд-Серверов: эти пакеты должны либо проходить мимо Балансировщика Нагрузки, либо он не должен модифицировать их и должен доставлять "как есть".

Если Балансировщик Нагрузки использует "нормальный" метод, то он должен быть настроен на обработку только тех портов, по которым производится "балансировка нагрузки"; пакеты, поступающие от/на "других портов" (такие, как порты из диапазона Медиа Портов) должны передаваться Балансировщиком Нагрузки без каких бы то ни было модификаций.

Метод с Несколькими IP с NAT

Можно использовать метод с Несколькими IP даже если Фронтенд-Серверы не имеют "реальных" IP адресов, а используют адреса "локального типа" L1, L1, L3 и т.д.

Настройте Балансировщик Нагрузки на использование реальных адресов G1, G2, G3, ... - в дополнение к VIP IP адресу, используемому для доступа к сервисам CommuniGate Pro.

Настройте Балансировщик Нагрузки на "отображение" его внешнего IP адреса G1 на адрес Фронтенд-Сервера L1, так, чтобы все пакеты, приходящие на IP адрес G1, порт g (G1:g) направлялись на Фронтенд-Сервер с адресом L1 и тот же самый порт g (L1:g). Балансировщик Нагрузки может изменять пакеты для адреса назначения на L1 или оставлять их как есть (G1); когда Балансировщик Нагрузки получает пакет от адреса L1, порт l (L1:l) и этот порт не используется в операциях, по которым балансируется нагрузка (SMTP, POP, IMAP, SIP и т.д), то Балансировщик Нагрузки должен перенаправлять этот пакет наружу, заменяя адрес источника L1 на G1: L1:l->G1:l.

Настройте Балансировщик Нагрузки аналогичным образом на "отображение" его внешних IP адресов G2, G3, ... на другие IP адреса Фронтенд-Серверов L2, L3, ...

В разделе Установки в Веб Интерфейсе Администратора произведите соответствующие настройки Фронтенд-Серверов CommuniGate Pro. Откройте страницы Сеть, и укажите там "отображаемые" IP адреса как Общесерверные WAN IP Адреса: G1 для Фронтенд-Сервера, имеющего IP адрес L1, G2 для Фронтенд-Сервера, имеющего IP адрес L2 и т.д.