CommuniGate Pro: Обробка Сигналів Реального Часу в кластері
- Балансувальник Навантаження - NAT з Одним IP
- Балансувальник навантаження - NAT з Кількома IP
- Балансувальник Навантаження DSR
- Метод з Одним IP
- Балансувальник Навантаження з Кількома IP без NAT
- Метод з Кількома IP з NAT
версія 6.2
PBX Завдання в CommuniGate Pro взаємодіють за допомогою відправки подій в описатели завдань. Описувач завдання - це об'єкт-посилання, що описує PBX Завдання, Сесію або Сигнали Реального Часу. У кластерному середовищі CommuniGate Pro Описувач завдання містить також адреса сервера - члена Кластера, на якому обробляється PBX Завдання, Сесія або Сигнал.
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. автоматично
- якщо цей Сервер не входить в Динамічний Кластер, то так само, як Виключено
- якщо цей Сервер є Frontend-му Динамічного Кластера, то так само, як Учасник
- якщо це - бекенд-Сервер Динамічного Кластера, то так само, як Передавати; якщо є інші члени Динамічного кластера налаштовані як Учасник, якщо немає - так само, як Виключено
Кластер 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 <-> F1: f
Де X: x є IP адресою віддаленого (відправляє) пристрої, а F1: f є IP адресою і номером порту фронтенда-Сервера, на яких спрямовується входить пакет.Коли вилучену програму пересилає запит, цей запис в таблиці дозволяє балансувальник Навантаження відправляти запит на той же фронтенда-Сервер (зверніть увагу, що це не потрібно для SIP-Ферми CommuniGate Pro). Ці балансувальник Навантаження зазвичай створюють "прив'язку до сесії" також і для вихідних UDP запитів: коли пакет відправляється з адреси / порту будь-якого фронтенда-Сервера F2: f на який-небудь віддалений доступ / порт Y: y, в таблиці Прив'язки балансувальник Навантаження створюється запис:
Y: y <-> F2: f
Коли вилучену програму відправляє пакет з відповіддю, цей запис в таблиці дозволяє балансувальник Навантаження відправити відповідь на "правильний" фронтенда-Сервер (зверніть увагу, що це не потрібно для SIP-Ферми CommuniGate Pro).
SIP-Ферма CommuniGate Pro розподіляє пакети SIP запитів, ретранслюючи їх між фронтенда-Серверами відповідно до алгоритмів роботи SIP-Ферми; такі алгоритми перенаправляють пакети з відповідями SIP на фронтенда-Сервер, який відправив відповідний SIP запит.
Ці можливості SIP-Ферми CommuniGate Pro роблять непотрібним використання таблиці "прив'язки сесії" балансувальник Навантаження (при використанні SIP UDP)
Відповіді 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
Для того, щоб уникнути появи вищеописаних проблем, треба запитати у виробника вашого балансувальник Навантаження що Балансувальник Навантаження дійсно не використовує "прив'язку до сесії" для 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
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
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, "всі адреси" і натисніть на кнопку Модифікувати
Повторіть ці зміни в налаштування для всіх фронтенда-серверів.
Кожен Медіа потік, термініруемий 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 і т.д.
Керівництво CommuniGate® Pro. Copyright © 1998-2019, Stalker Software, Inc.