Пожалуй, стоит начать с того, что, изначально, в 2011 году, проект «PBX-Sphere» планировался как серверное проприетарное программное обеспечение для СМБ, которое должно было решить проблему имплементации и сопровождения сложных VoIP технологий в простом и понятном программном продукте. И, вот, 1 июля 2011 года, вышел первый стабильный релиз PBX-Sphere Enterprise 1.0. Тогда мы получили много бета-тестеров по всему миру и несколько крупных клиентов. Вплоть до 15 октября 2013 года, мы выпустили еще 3 стабильные версии PBX-Sphere Enterprise, включая последнюю — 2.2.0. Еще, в течение полугода, мы активно продвигали наш продукт крупным клиентам. В итоге, по состоянию на середину 2014 года, у нас было менее 1000 активных конечных пользователей. Нельзя сказать, что это был провал, но мы ожидали гораздо лучшего результата.
И тогда, проанализировав с лихвой изменившийся за несколько лет рынок, мы поняли, что нужно переходить к моделе «Software as a Service» (SaaS), к облачным технологиям. За несколько месяцев мы разработали новый концепт продукта и приступили к рефакторингу PBX-Sphere Enterprise в PBX-Sphere Online.
Первым же вопросом стал выбор платформы развертывания системы. После некоторых исследований и экспериментов, мы решили выбирать из трех: Hetzner Dedicated Servers, Microsoft Azure, кластер из собственных серверов.
Расскажу подробнее:
Hetzner Dedicated Servers
Казалось, это идеальное решение… Физические сервера с Intel Core i7, 48 Гб RAM, 2 x 2 Tb HDD в RAID1 и FlexiPack — за 75 евро в месяц с гарантированной пропускной способностью в 200 Мбит/с. Чего еще желать?! Мы начали развертывание. По-началу, все было отлично. Мы развернули десятки серверов с CentOS 7 под разные роли продакшн деплоймента PBX-Sphere Online. Нагрузочное тестирование показало отличнейшие результаты. Воодушевленные таким положением дел, мы открыли PBX-Sphere Online 1.0 на такой конфигурации для промышленного использования для одного крупного клиента. Работало все отлично. Было несколько жалоб на то, что во время разговора могут наблюдаться кратковременные «замирания» звука. Мы это списывали на нестабильность интернет-подключения пользователей, так как никаких потерь в канале с нашей стороны не было обнаружено, да и Load Average на наших серверах был минимальным, как и размер использованной оперативной памяти и Swap. Но, вскоре, мы начали замечать, что кратковременные «замирания» звука наблюдаются почти всегда при использовании интернета по 3G сети, причем несколько раз за минуту, независимо от используемых кодеков. Мы решили разобраться в чем дело, ведь такой проблемы никогда не возникало при использовании тестовых серверов, расположенных у нас в офисе. Каково же было наше удивление, когда мы обнаружили, что пограничное оборудование Hetzner некорректно использует шейпирование, в результате чего, RTP пакеты ставятся в очередь на доставку к нашим серверам и обратно с задержкой, которая выше TTL пакетов RTP. Получается, что если у пользователя хороший интернет-канал и выбран TCP протокол обмена, то никакой проблемы, как-бы, нет. Неделя переговоров с саппортом Hetzner не дала никаких результатов. Дальше — больше. В течение 3 дней на наших серверах отказали 5 жестких дисков! Причем, 2 из них — на центральном SQL сервере. Благо, был дублирующий SQL сервер, так что для пользователей это прошло незаметно. На вопрос «WTF?» саппорт Hetzner ответил, что это нормально и в порядке вещей. После смерти еще двух жестких дисков и непрекращающихся сетевых проблем, стало понятно, что нужно искать другую платформу.
Microsoft Azure
Первые впечатления от Microsoft Azure можно описать тремя словами: круто, необычно, дорого. Это не просто виртуальные машины в привычном понимании этого слова, а целая отдельная среда со своими законами и тонкостями. Мы решили попробовать. Развернули PBX-Sphere Online и запустили ее в тестовом режиме. Долго присматривались, делали множество как нагрузочных тестов всех систем, так и тестировали в реальных условиях. Ждали когда же проявятся проблемы, с которыми мы столкнулись на Hetzner. Этого не произошло, никаких «замираний» звука не было. Но сразу была очевидна потенциальная проблема с IP-адресами. Как известно, в Azure есть 3 типа IP-адресов: локальный IP-адрес экземпляра и 2 внешних IP-адреса (VIP и PIP). Работа VIP-адреса похожа на работу домашнего роутера, когда на WAN интерфейс приходит внешний IP-адрес и чтобы «из мира» попасть во внутреннюю сеть, нужно «пробросить» определенный порт. Такой же механизм для VIP в Azure. Это приемлемо для всех экземпляров развертывания PBX-Sphere Online, кроме серверов Backend, в работе которых нужен весь диапазон портов для непосредственной передачи голоса во время звонка (RTP). Azure допускает «проброс» максимум 150 портов на 1 экземпляр. Поэтому, для RTP нужно использовать другой тип внешнего IP-адреса — PIP, все порты которого попадают в экземпляр. Это работает. Но VIP и PIP-адреса — динамические, по-умолчанию. То есть, после перезагрузки сервера VIP/PIP адрес может измениться. И если VIP-адрес легко определить по DNS, то PIP адрес можно определить только изнутри сервера, выполнив внешний запрос. Как же тогда настроить свою доменную зону?! Для авторизации конечного оборудования пользователя можно использовать доменное имя, которое является псевдонимом (CNAME) хоста экземпляра. Но PIP адрес Azure в DNS не предоставляет. Поэтому, один и тот же экземпляр производит авторизацию пользователей с использованием VIP-адреса, а голос (RTP) направляется через PIP-адрес. Для такой реализации, после каждой перезагрузки каждый backend-экземпляр должен запрашивать извне свой PIP-адрес и уже потом производить перенастройку для RTP. Благо, для RTP отдельная запись в DNS не требуется. Вообще, такой механизм ужасно неудобен, т.к. сервер напрямую зависит от внешнего ресурса, который сообщает IP-адрес. Как закрепить за экземпляром PIP-адрес, я не нашел. Еще один неприятный момент, это когда Microsoft выполняет техническое обслуживание в своих дата-центрах и, как следствие, часть серверов становится недоступной. Спасает избыточное резервирование вычислительных ресурсов в разных регионах, благодаря чему такие действия остаются прозрачными для наших пользователей и без потери качества. Но достигается это за счет наших прямых затрат, поскольку, мы должны обеспечить такое резервирование за свой счет. Во всем остальном, качество сервиса просто отличное, но, как я уже упоминал, довольно дорогое.
Собственный кластер
Этот вариант просчитывался только теоретически. Дело в том, что большая часть команды PBX-Sphere находится в Украине, а остальная — в России и Болгарии. PBX-Sphere ориентируется не только на страны СНГ, но, в большей части, на США и страны ЕС. Поэтому, как вы понимаете, ни Россия, ни Украина, ни Болгария для размещения серверов не подходит. А размещать сервера в других странах и обеспечивать их поддержку частыми перелетами технических специалистов очень накладно, даже с учетом возможного хеджирования валютных рисков. Возможно, в будущем мы вернемся к рассмотрению этого варианта.
Благодаря поддержке Microsoft, мы стали участниками программы BizSpark, по которой, в числе прочего, нам предоставляются сервисы Azure бесплатно на сумму 750$ в месяц, сроком на 2 года. Благодаря этой поддержке, а также прямым контактам с инженерами Azure, мы выбрали именно эту платформу для нашей PBX-Sphere Online. И, пока что, очень довольны этим.
Резюме
27 августа 2015 года мы обновили PBX-Sphere Online на платформе Microsoft Azure до версии 2.0.0 для всех пользователей и впервые открыли публичную регистрацию. Сейчас каждому новому аккаунту предоставляется 25 бесплатных лицензий пожизненно.
И тогда, проанализировав с лихвой изменившийся за несколько лет рынок, мы поняли, что нужно переходить к моделе «Software as a Service» (SaaS), к облачным технологиям. За несколько месяцев мы разработали новый концепт продукта и приступили к рефакторингу PBX-Sphere Enterprise в PBX-Sphere Online.
Первым же вопросом стал выбор платформы развертывания системы. После некоторых исследований и экспериментов, мы решили выбирать из трех: Hetzner Dedicated Servers, Microsoft Azure, кластер из собственных серверов.
Расскажу подробнее:
Hetzner Dedicated Servers
Казалось, это идеальное решение… Физические сервера с Intel Core i7, 48 Гб RAM, 2 x 2 Tb HDD в RAID1 и FlexiPack — за 75 евро в месяц с гарантированной пропускной способностью в 200 Мбит/с. Чего еще желать?! Мы начали развертывание. По-началу, все было отлично. Мы развернули десятки серверов с CentOS 7 под разные роли продакшн деплоймента PBX-Sphere Online. Нагрузочное тестирование показало отличнейшие результаты. Воодушевленные таким положением дел, мы открыли PBX-Sphere Online 1.0 на такой конфигурации для промышленного использования для одного крупного клиента. Работало все отлично. Было несколько жалоб на то, что во время разговора могут наблюдаться кратковременные «замирания» звука. Мы это списывали на нестабильность интернет-подключения пользователей, так как никаких потерь в канале с нашей стороны не было обнаружено, да и Load Average на наших серверах был минимальным, как и размер использованной оперативной памяти и Swap. Но, вскоре, мы начали замечать, что кратковременные «замирания» звука наблюдаются почти всегда при использовании интернета по 3G сети, причем несколько раз за минуту, независимо от используемых кодеков. Мы решили разобраться в чем дело, ведь такой проблемы никогда не возникало при использовании тестовых серверов, расположенных у нас в офисе. Каково же было наше удивление, когда мы обнаружили, что пограничное оборудование Hetzner некорректно использует шейпирование, в результате чего, RTP пакеты ставятся в очередь на доставку к нашим серверам и обратно с задержкой, которая выше TTL пакетов RTP. Получается, что если у пользователя хороший интернет-канал и выбран TCP протокол обмена, то никакой проблемы, как-бы, нет. Неделя переговоров с саппортом Hetzner не дала никаких результатов. Дальше — больше. В течение 3 дней на наших серверах отказали 5 жестких дисков! Причем, 2 из них — на центральном SQL сервере. Благо, был дублирующий SQL сервер, так что для пользователей это прошло незаметно. На вопрос «WTF?» саппорт Hetzner ответил, что это нормально и в порядке вещей. После смерти еще двух жестких дисков и непрекращающихся сетевых проблем, стало понятно, что нужно искать другую платформу.
Microsoft Azure
Первые впечатления от Microsoft Azure можно описать тремя словами: круто, необычно, дорого. Это не просто виртуальные машины в привычном понимании этого слова, а целая отдельная среда со своими законами и тонкостями. Мы решили попробовать. Развернули PBX-Sphere Online и запустили ее в тестовом режиме. Долго присматривались, делали множество как нагрузочных тестов всех систем, так и тестировали в реальных условиях. Ждали когда же проявятся проблемы, с которыми мы столкнулись на Hetzner. Этого не произошло, никаких «замираний» звука не было. Но сразу была очевидна потенциальная проблема с IP-адресами. Как известно, в Azure есть 3 типа IP-адресов: локальный IP-адрес экземпляра и 2 внешних IP-адреса (VIP и PIP). Работа VIP-адреса похожа на работу домашнего роутера, когда на WAN интерфейс приходит внешний IP-адрес и чтобы «из мира» попасть во внутреннюю сеть, нужно «пробросить» определенный порт. Такой же механизм для VIP в Azure. Это приемлемо для всех экземпляров развертывания PBX-Sphere Online, кроме серверов Backend, в работе которых нужен весь диапазон портов для непосредственной передачи голоса во время звонка (RTP). Azure допускает «проброс» максимум 150 портов на 1 экземпляр. Поэтому, для RTP нужно использовать другой тип внешнего IP-адреса — PIP, все порты которого попадают в экземпляр. Это работает. Но VIP и PIP-адреса — динамические, по-умолчанию. То есть, после перезагрузки сервера VIP/PIP адрес может измениться. И если VIP-адрес легко определить по DNS, то PIP адрес можно определить только изнутри сервера, выполнив внешний запрос. Как же тогда настроить свою доменную зону?! Для авторизации конечного оборудования пользователя можно использовать доменное имя, которое является псевдонимом (CNAME) хоста экземпляра. Но PIP адрес Azure в DNS не предоставляет. Поэтому, один и тот же экземпляр производит авторизацию пользователей с использованием VIP-адреса, а голос (RTP) направляется через PIP-адрес. Для такой реализации, после каждой перезагрузки каждый backend-экземпляр должен запрашивать извне свой PIP-адрес и уже потом производить перенастройку для RTP. Благо, для RTP отдельная запись в DNS не требуется. Вообще, такой механизм ужасно неудобен, т.к. сервер напрямую зависит от внешнего ресурса, который сообщает IP-адрес. Как закрепить за экземпляром PIP-адрес, я не нашел. Еще один неприятный момент, это когда Microsoft выполняет техническое обслуживание в своих дата-центрах и, как следствие, часть серверов становится недоступной. Спасает избыточное резервирование вычислительных ресурсов в разных регионах, благодаря чему такие действия остаются прозрачными для наших пользователей и без потери качества. Но достигается это за счет наших прямых затрат, поскольку, мы должны обеспечить такое резервирование за свой счет. Во всем остальном, качество сервиса просто отличное, но, как я уже упоминал, довольно дорогое.
Собственный кластер
Этот вариант просчитывался только теоретически. Дело в том, что большая часть команды PBX-Sphere находится в Украине, а остальная — в России и Болгарии. PBX-Sphere ориентируется не только на страны СНГ, но, в большей части, на США и страны ЕС. Поэтому, как вы понимаете, ни Россия, ни Украина, ни Болгария для размещения серверов не подходит. А размещать сервера в других странах и обеспечивать их поддержку частыми перелетами технических специалистов очень накладно, даже с учетом возможного хеджирования валютных рисков. Возможно, в будущем мы вернемся к рассмотрению этого варианта.
Благодаря поддержке Microsoft, мы стали участниками программы BizSpark, по которой, в числе прочего, нам предоставляются сервисы Azure бесплатно на сумму 750$ в месяц, сроком на 2 года. Благодаря этой поддержке, а также прямым контактам с инженерами Azure, мы выбрали именно эту платформу для нашей PBX-Sphere Online. И, пока что, очень довольны этим.
Резюме
27 августа 2015 года мы обновили PBX-Sphere Online на платформе Microsoft Azure до версии 2.0.0 для всех пользователей и впервые открыли публичную регистрацию. Сейчас каждому новому аккаунту предоставляется 25 бесплатных лицензий пожизненно.
