Клъстериране на opensips и скриване на топологията в sip мрежата на оператора
Нашата мрежа е изградена на opensips 1.8. По-голямата част от натоварването при opensips е при обработката на регистрациите, за разлика от разговорите, които имат много по-малко натоварване. Следователно, когато броят на регистрациите в нашата мрежа премина определен праг, беше взето решение за хоризонтално мащабиране на opensips. Така се ражда проектът opensips cluster. Идеята беше да се създаде най-простият балансьор, който да разпределя повикванията между възлите на клъстера. Беше планирано обажданията да се обработват изцяло на възли.
В същото време възниква идеята за скриване на топологията. В opensips има два механизма за това.
Първата е наскоро въведената функция topology_hiding() в диалоговия модул.
Вторият е модулът b2b_logic, който реализира пълноценен b2b.
След тестване беше взето окончателното решение да се използва b2b_logic. Срещнахме обаче ограничения във функционалността му. Например, не беше възможно да се работи напълно с sip хедъри (премахване, добавяне, промяна), а също така нямаше прозрачен режим на удостоверяване. Удостоверяването беше възможно на b2b сървъра, но не можа да го препрати към следващия b2b сървър. В основния код бяха написани съответните пачове, които разработчиците на Opensips обещават да включат във версия 1.9.
Трябва също така да се отбележи, че opensips е изграден по такъв начин, че не можете да използвате b2b и прокси едновременно на едно и също работещо копие. В резултат на това се роди схема, която стана работеща за нас.
B2B се използва за балансиране на sip трафик между клъстерни възли, скрива топологията на мрежата в двете посоки, нормализира и филтрира някои sip хедъри, отговаря за откриването на NAT, поддържа SIP/UDP, SIP/TCP, SIP/TLS протоколи, както и STUN сървър.
INopensips се използва като възли в прокси режим, те отговарят за услугата за местоположение на клиента (местоположение), нормализират, коригират sip хедъри от клиенти, на които поддръжката на sip протокол е неправилно внедрена, управлява RTP прокси и обработва NAT.
В тази схема SIP пакетът пътува от клиента до софтсуич от клас 5, както следва: софтсуич -> балансьор -> възел -> балансьор -> клиент или обратно.
Всеки opensips се хоства на собствен хардуерен сървър, репликацията master-master postgresql е конфигурирана между сървърите.
Нашите конфигурационни файлове се генерират с помощта на m4. Всеки сървър има файл със специфични за сървъра статични променливи, а общите части на конфигурацията се съхраняват в git. В опростена форма давам конфигурацията тук.
В близко бъдеще се планира пускането в експлоатация на още един такъв клъстер. И двата клъстера ще бъдат географски разделени, трафикът ще се разпределя между тях чрез Round-Robbin DNS (SRV записи).
И също така: - използвайте cachedb за кеширане - добавете функционалност за автоматично блокиране на сканиращи ботове и прости атаки - добавете функционалност за блокиране на програми за разбиване на пароли