| Версия 5.2
Введение
Установка
Администрирование
Сеть
Объекты
Почта
Сигналы
Доступ
Услуги
Справочник
Кластеры
Программы
Разное
Лицензирование
Веб Почта
Pronto!
PBX
Кластеры | Статический | Динамический | Хранилище | Почта | Сигналы | Доступ | Задания
# Обработка Сигналов Реального Времени в Кластерах SIP Балансировщик Нагрузки - NAT с Одним IP Балансировщик нагрузки - NAT с Несколькими IP Балансировщик Нагрузки DSR Вызовы RTP Медиа Метод с Одним IP Балансировщик Нагрузки с Несколькими IP без NAT Метод с Несколькими IP с NAT Примеры Конфигураций В этом разделе объясняется, каким образом в кластерной среде CommuniGate Pro проводятся операции Сигналов Реального Времени.

## SIP

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

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

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

Обработка SIP
SIP-Ферма: |  |  |

`SIP-Ферма`
  Эта настройка указывает, как этот член Фермы должны обрабатывать запросы SIP.
  `Участник`
    Если выбрана опция Участник, то член Кластера участвует в SIP-Ферме. Он обрабатывает новые запросы локально или перенаправляет их другим членам SIP-Фермы, используя специальные алгоритмы распределения трафика в SIP-Ферме.
  `Выключено`
    Если выбрана опция Выключено, то этот член Кластера не является участником SIP-Фермы; он будет обрабатывать входящие запросы SIP локально.
  `Передавать`
    Если выбрана опция Передавать, то этот член Кластера не является участником SIP-Фермы; но, когда ему необходимо будет отправить запрос SIP, он будет ретранслировать его через любых доступных членов SIP-Фермы.
    Выберите эту опцию для тех Backend Серверов, которые не имеют прямого доступа в Интернет и, следовательно, не могут напрямую отправлять запросы SIP.
  Автомататически
    аналогично:
    `Участник`
      если этот Сервер является Frontend-ом Динамического Кластера;
    `Передавать`
      если этот Сервер является Backend-ом Динамического Кластера.
    `Выключено`
      если этот Сервер не входит в Динамический Кластер
  Обратите внимание: SIP запрос может быть явно направлен указанному члену Кластера (так обрабатывается большинство запросов внутри установленных диалогов). Эти запросы всегда перенаправляются на указанного члена Кластера и обрабатываются им независимо от установок в настройках SIP-Фермы.

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

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

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

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

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

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

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

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

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

Frontend Сервера имеют IP адреса F1,F2, F3, ...

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

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

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

Многие Балансировщики Нагрузки, даже если они и не используют никакую специфичную SIP технику, создают "привязку к сессии" для входящих UDP запросов, точно также, как они обрабатывают входящие TCP соединения.
Таблица Привязки для произвольного порта Балансировщика Нагрузки `v` (и VIP адреса Балансировщик Нагрузки) содержит пару из IP адреса и порта:
X:x <-> F1:f
Где X:x является IP адресом удалённого (отправляющего) устройства, а F1:f является IP адресом и номером порта Frontend Сервера, на которые направляется входящий пакет.
Когда удалённое устройство пересылает запрос, эта запись в таблице позволяет Балансировщику Нагрузки отправлять запрос на тот же Frontend Сервер (обратите внимание, что это не требуется для SIP-Фермы CommuniGate Pro).

Эти Балансировщики Нагрузки обычно создают "привязку к сессии" также и для исходящих UDP запросов: когда пакет отправляется с адреса/порта какого-либо Frontend Сервера F2:f на какой-нибудь удалённый адрес/порт Y:y, в таблице Привязки Балансировщика Нагрузки создаётся запись:
Y:y <-> F2:f
Когда удалённое устройство отправляет пакет с ответом, эта запись в таблице позволяет Балансировщику Нагрузки отправить ответ на "правильный" Frontend Сервер (обратите внимание, что это не требуется для SIP-Фермы CommuniGate Pro).

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

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

  Когда Балансировщик Нагрузки получает пакет с SIP запросом от адреса X:x и ретранслирует его на адрес/порт Frontend Сервера F1:5060, то SIP-Ферма может ретранслировать этот запрос далее на какой-либо другой Frontend Сервер (на адрес/порт F2:5060), где и будет создана транзакция SIP Сервера и обработан запрос.
  SIP отклики будут генерироваться на этом Frontend Сервере, а пакеты с 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

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

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

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

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

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

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

Solaris
  ifconfig lo0:1 plumb
  ifconfig lo0:1 VIP netmask VIP-mask up
  Для того, что бы сделать эту конфигурацию постоянной, создайте файл `/etc/hostname.lo0:1` с VIP-адресом в нём.
Linux
  ifconfig lo:0 VIP netmask VIP-mask up
  Для того, что бы сделать эту конфигурацию постоянной, создайте файл `/etc/sysconfig/network-scripts/ifcfg-lo:0`:
  DEVICE=lo
  IPADDR=VIP
  NETMASK=VIP-mask
  ONBOOT=yes

  Убедитесь, что ядро настроено так, что оно не расслает ARP для этого `lo` интерфейса (так что `VIP` адреса не связаны ни с каким Frontend Сервером в 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"
другие ОС
  уточните у производителя ОС

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

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

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

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

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

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

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

### Вызовы

Балансировщик нагрузки обычно отправляет некоторые запросы на сервера в своих "балансировочных пулах". При неполучении ответа Балансировщик Нагрузки удаляет сервер из пула и распределяет входящие запросы на оставшиеся в пуле сервера.

Если SIP-Ферма включена, собственные запросы Балансировщика Нагрузки могут передаваться на другие сервера, входящие в SIP-Ферму, и, таким образом, ответы будут поступать от других серверов. Это может привести к тому, что Балансировщик Нагрузки решит, что сервер, которому был послан запрос, не функционирует и исключит этот сервер из обслуживаемого набора серверов.
Для решения этой проблемы используйте следующие запросы SIP для "дёргания" Балансировщика Нагрузки:
OPTION sip:aaa.bbb.ccc.ddd:5060 SIP/2.0
Route: <sip:aaa.bbb.ccc.ddd:5060;lr>
другие поля пакетов SIP
где aaa.bbb.ccc.ddd - IP адрес тестируемого Сервера CommuniGate Pro.

Эти пакеты обрабатываются Сервером aaa.bbb.ccc.ddd , который генерирует ответы и отправляет их обратно Балансировщику Нагрузки (или тестирующему устройству).

## RTP Медиа

Каждый Медиа поток, терминируемый 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, а если используется видео (вместо с аудио), то такой Кластер не сможет обслуживать более чем 16,000 одновременных аудио/видео сессий.

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

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

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

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

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

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

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

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

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

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

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

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

## Примеры Конфигураций

Пример конфигурации:

- Маршрутизатор имеет адрес 64.173.55.161 (маска сети 255.255.255.224), DNS Сервер 64.173.55.167.
- 4 Frontend Сервера (fe5, fe6, fe7, fe8) с "реальными" IP адресами 64.173.55.{180,181,182,183}
- внутри-кластерная сеть 192.168.10.xxx, с "кластерными" адресами Frontend Серверов 192.168.10.{5,6,7,8}
- балансировщик нагрузки с адресом 64.173.55.164 (VIP адрес).
- на каждом Frontend Сервере на интерфейсе сетевой петли сконфигурирован псевдоним для адреса 64.173.55.164.

Используется метод RTP, Несколько IP без NAT.

Конфигурация CommuniGate Pro (область Установки в Веб Интерфейсе Администратора):

- страница Сеть->LAN->Общие для Кластера: IPv4 WAN Адрес: 64.173.55.164
- страница Сеть->LAN->Общие для Сервера (на каждом из Frontend Серверов): IPv4 WAN Адрес: 64.173.55.{180,181,182,183}
- страница Real-Time->SIP->Приём->UDP Приёмник (на каждом из Frontend Серверов): {порт 5060, адрес:64.173.55.164} и {порт: 5060, адрес: все адреса;}

Конфигурация "без NAT", с "нормальной" балансировкой нагрузки для POP, IMAP и "DSR" балансировкой нагрузки для SIP (UDP/TCP), SMTP, HTTPU (8100).

Конфигурация Балансировщика Нагрузки:

Foundry ServerIron® (его служебный адрес - 64.173.55.176)

      Startup configuration:
      !
      server predictor round-robin
      !
      server real fe5 64.173.55.180
       port pop3
       port pop3 keepalive
       port imap4
       port imap4 keepalive
       port 5060
       port 5060 keepalive
       port smtp
       port smtp keepalive
       port 8100
       port 8100 keepalive
      !
      server real fe6 64.173.55.181
       port pop3
       port pop3 keepalive
       port imap4
       port imap4 keepalive
       port 5060
       port 5060 keepalive
       port smtp
       port smtp keepalive
       port 8100
       port 8100 keepalive
      !
      server real fe7 64.173.55.182
       port pop3
       port pop3 keepalive
       port imap4
       port imap4 keepalive
       port 5060
       port 5060 keepalive
       port smtp
       port smtp keepalive
       port 8100
       port 8100 keepalive
      !
      server real fe8 64.173.55.183
       port pop3
       port pop3 keepalive
       port imap4
       port imap4 keepalive
       port 5060
       port 5060 keepalive
       port smtp
       port smtp keepalive
       port 8100
       port 8100 keepalive
      !
      !
      server virtual vip1 64.173.55.164
       predictor round-robin
       port pop3
       port imap4
       port 5060
       port 5060 dsr
       port smtp
       port smtp dsr
       port 8100
       port 8100  dsr
       bind pop3  fe5 pop3  fe6 pop3  fe7 pop3  fe8 pop3
       bind imap4 fe5 imap4 fe6 imap4 fe7 imap4 fe8 imap4
       bind 5060  fe8 5060  fe7 5060  fe6 5060  fe5 5060
       bind smtp  fe8 smtp  fe7 smtp  fe6 smtp  fe5 smtp
       bind 8100  fe5 8100  fe6 8100  fe7 8100  fe8 8100
      !
      ip address 64.173.55.176 255.255.255.224
      ip default-gateway 64.173.55.161
      ip dns server-address 64.173.55.167
      ip mu act
      end

  Обратите внимание: вы НЕ должны использовать `SIP-коммутатор для порта 5060`, `SIP прокси сервер для порта SIP` или другие "умные" (уровня приложений) возможности Балансировщика Нагрузки.
Alteon/Nortel AD3® (служебный адрес - 64.173.55.176, аппаратный порт 1 используется соединения с Интернет, к портам 5-8 присоединены Frontend Сервера)

      script start "Alteon AD3" 4  /**** DO NOT EDIT THIS LINE!
      /* Configuration dump taken 21:06:57 Mon Apr  9, 2007
      /* Version 10.0.33.4,  Base MAC address 00:60:cf:41:f5:20
      /c/sys
              tnet ena
              smtp "mail.communigate.com"
              mnet 64.173.55.160
              mmask 255.255.255.224
      /c/sys/user
              admpw "ffe90d3859680828b6a4e6f39ad8abdace262413d5fe6d181d2d199b1aac22a6"
      /c/ip/if 1
              ena
              addr 64.173.55.176
              mask 255.255.255.224
              broad 64.173.55.191
      /c/ip/gw 1
              ena
              addr 64.173.55.161
      /c/ip/dns
              prima 64.173.55.167
      /c/sys/ntp
              on
              dlight ena
              server 64.173.55.167
      /c/slb
              on
      /c/slb/real 5
              ena
              rip 64.173.55.180
              addport 110
              addport 143
              addport 5060
              addport 25
              addport 8100
              submac ena
      /c/slb/real 6
              ena
              rip 64.173.55.181
              addport 110
              addport 143
              addport 5060
              addport 25
              addport 8100
              submac ena
      /c/slb/real 7
              ena
              rip 64.173.55.182
              addport 110
              addport 143
              addport 5060
              addport 25
              addport 8100
              submac ena
      /c/slb/real 8
              ena
              rip 64.173.55.183
              addport 110
              addport 143
              addport 5060
              addport 25
              addport 8100
              submac ena
      /c/slb/group 1
              add 5
              add 6
              add 7
              add 8
              name "all-services"
      /c/slb/port 1
              client ena
      /c/slb/port 5
              server ena
      /c/slb/port 6
              server ena
      /c/slb/port 7
              server ena
      /c/slb/port 8
              server ena
      /c/slb/virt 1
              ena
              vip 64.173.55.164
      /c/slb/virt 1/service pop3
              group 1
      /c/slb/virt 1/service imap4
              group 1
      /c/slb/virt 1/service 5060
              group 1
              udp enabled
              udp stateless
              nonat ena
      /c/slb/virt 1/service smtp
              group 1
              nonat ena
      /c/slb/virt 1/service 8100
              group 1
              nonat ena
      /
      script end  /**** DO NOT EDIT THIS LINE!

F5 Big-IP® (его служебный адрес - 64.173.55.176)
  Используйте возможность nPath Routing для SIP UPD/TCP трафика. Это название, принятое в F5 Networks, Inc. для метода Прямого Ответа Сервера.
  Из-за того, что F5 BigIP не является коммутатором, вы должны использовать метод DSR (nPath Routing) для всех сервисов.
  `bigip_base.conf:`

      vlan external {
         tag 4093
         interfaces
            1.1
            1.2
      }
      stp instance 0 {
         vlans external
         interfaces
            1.1
               external path cost 20K
               internal path cost 20K
            1.2
               external path cost 20K
               internal path cost 20K
      }
      self allow {
         default
            udp snmp
            proto ospf
            tcp https
            udp domain
            tcp domain
            tcp ssh
      }
      self 64.173.55.176 {
         netmask 255.255.255.224
         vlan external
         allow all
      }

  `bigip.conf:`

      partition Common {
         description "Repository for system objects and shared objects."
      }
      route default inet {
         gateway 64.173.55.161
      }
      monitor MySMTP {
         defaults from smtp
         dest *:smtp
         debug "no"
      }
      profile fastL4 CGS_fastL4 {
         defaults from fastL4
         idle timeout 60
         tcp handshake timeout 15
         tcp close timeout 60
         loose initiation disable
         loose close enable
         software syncookie disable
      }
      pool Frontends {
         monitor all MySMTP and gateway_icmp
         members
            64.173.55.180:any
            64.173.55.181:any
            64.173.55.182:any
            64.173.55.183:any
      }
      node * monitor MySMTP

  `bigip_local.conf:`

      virtual address 64.173.55.164 {
         floating disable
         unit 0
      }
      virtual External {
         translate address disable
         pool Frontends
         destination 64.173.55.164:any
         profiles CGS_fastL4
      }

Руководство CommuniGate® Pro. Copyright © 1998-2009, Stalker Software, Inc.