Причины поиска альтернативы существующему оборудованию

Проблемы с коммутатором Huawei SoftX3000 копились постепенно и были обусловлены разными факторами:

• Физическое устаревание оборудования. На момент замены оборудование работало без замены более 12 лет. ЗИПа не было.

• Сбои серверов управления. В системе использовались несколько серверов: основной и резервный сервера предварительного биллинга, основной и резервный сервера управления конфигурацией, сервер взаимодействия с СОРМ. Все они работали на ОС Windows 2000 Server, установочные пакеты ПО для серверов невозможно было установить на более свежую версию ОС. Виртуализировать эти сервера корректно у нас также не получилось. Кроме того, при работе в одной сети с машинами на ОС Windows 7 сервера на Windows 2000 регулярно выдавали BSOD. Предпринимались попытки изменить защиту установочных файлов серверного ПО и установить его на Windows Server 2003, но стабильной работы добиться не удалось.

• Сбои и ошибки на транковом шлюзе UMG8900. Регулярно получали сообщения о кратковременном сбое/восстановлении на субмодулях потоков E1. Какого-либо влияния на сервис замечено не было, но определить причины и риски данных сообщений не удалось.

• Ограничения в функционале. На данной АТС все функции ограничены лицензией: количество абонентов, количество транков, количество абонентов, которым доступно определенная опция (ДВО). По большинству из этих параметров мы начали подбираться к максимальным значениям. Некоторые современные функции были вообще недоступны.

• Ограниченный выбор голосовых шлюзов. Основное количество абонентских лицензий было закуплено для протоколов MGCP и H.248. Выбор оборудования, работающего по этим протоколам, на рынке сильно ограничен. Шлюзы и телефоны, работающие по протоколу SIP, более распространены. Но количество таких лицензий у нас было резко ограничено.

• Отсутствие персонала, который имел бы ясное понимание, как вся эта система собрана, настроена и работает. Люди, которые проходили обучение по работе со станцией или участвовали в ее запуске, отошли от дел по разным причинам: кто-то перешел в другие направления, кто-то уволился.

• Отсутствие технической поддержки. В случае необходимости решить какую-то нестандартную задачу помощи ждать было неоткуда. Не говоря уже о каких-то экстренных ситуациях.

Для устранения всех описанных выше проблем предлагалось единственное решение — полное обновление станции за очень внушительный ценник. Руководство стремилось минимизировать затраты и запрашивало альтернативные варианты. Решений по системам коммутации такого уровня не так много в мире, а в РФ тем более. Наши поиски привели нас к системе от российского производителя «Элтекс».

Причины выбора Eltex

После рассмотрения различных предложений на рынке выбор пал на продукт от российского разработчика — ECSS-10 Eltex. Основным решающим фактором для руководства стала стоимость решения — примерно в 3 раза ниже других предложений, которые мы получали. Также у нас был опыт работы с VoIP-оборудованием данного производителя и опыт взаимодействия с технической поддержкой: всегда можно было получить нужную информацию по функционалу и методам настройки устройств. Да и при выявлении критичных багов разработчики реагировали оперативно.

Из других особенностей для себя мы можем выделить:

• Большое количество ДВО без дополнительной платы за лицензии (самая интересная нам — multiline).

• Ядро станции — полностью программный продукт. Не нужно каких-то специализированных корзин, плат и модулей, просто установили ОС и ПО на нее.

• Снижение энергозатрат и количества оборудования. Вместо 4 полноразмерных 19” стоек всё уместилось в одну. Хотя, возможно, это заслуга технического прогресса.

• Наличие в открытом доступе подробной технической документации.

• Русскоязычная техническая поддержка.

В дальнейшем после начала эксплуатации выявились ещё некоторые моменты:

• Графический интерфейс. Конечно, это «не круто» и вначале отношение было довольно скептическое. Но на деле интерфейс оказался весьма удобным и достаточным для большинства повседневных задач.

• Довольно простая и логичная настройка маршрутизации вызовов. Всегда понятно, откуда приходит вызов, по каким точкам он проходит и как обрабатывается.

• Простая настройка «нетелефонных» параметров. Так как станция установлена на обычный Linux, настроить IP-адреса, маршрутизацию или фильтрацию трафика довольно просто.

• Стандартные инструменты доступа к оборудованию. Не нужно устанавливать какие-то специальные терминалы для управления станцией или её мониторинга. Нужны только WinSCP, Putty и web-браузер.

Существующая конфигурация

Для подбора конфигурации оборудования необходимо оценить существующую схему сети. Итак, что мы имели изначально:

• Ядро станции Huawei SoftX3000. Оборудование состоит из корзины с платами и четырех коммутаторов Ethernet, которые связывают всё воедино.

• Сервера управления. В той же стойке установлены: основной сервер управления (BAM), основной сервер предварительного биллинга (IGWB0), резервный сервер предварительного биллинга (IGWB1). Отдельно установлен резервный сервер управления станцией (EWS), а также стойка оборудования СОРМ, включающая в себя сервер взаимодействия со станцией (XPTU) и кучу разных конвертеров.

• Транковый шлюз Huawei miniUMG8900. Предназначен для подключения к станции транков E1. Наша конфигурация позволяла подключить до 32 потоков. Лицензиями было ограничено количество присоединений (только 10 присоединений) и только по ОКС7 (каждое присоединение может включать несколько потоков).

• Два пограничных контроллера сессий (SBC). В работе был только один, второй не был корректно сконфигурирован и использовался для различных тестов. В последующем наличие свободного SBC очень облегчило задачу миграции: использовали его для предварительных тестов и в итоге как основной SBC в новой схеме.

• Абонентские шлюзы, работающие по протоколу MGCP. Таких устройств было много, но хотелось в итоге прийти к единой схеме, поэтому решено было перевести их на работу по протоколу SIP (такая возможность была заложена на всех устройствах).

• Абонентские устройства SIP (шлюзы и телефоны).

• Очень мутно настроенная схема прохождения голоса. В существующей станции за обработку голоса и обработку сигнализации отвечали разные платы, которые к тому же работали в разных подсетях. Если между ядром и транковым шлюзом это нормальная схема работы, то при взаимодействии с внешними абонентами через SBC, видимо, были какие-то проблемы с прохождением голоса. В результате родилась схема, где кроме самой станции и SBC участвовали четыре коммутатора L3, 7 разных подсетей, 3 роутера OSPF и один Junniper MX480. Для чего это сделано и как оно работало, я так до конца и не разобрался.

В итоге было решено поэтапно перенастроить абонентские устройства MGCP, переводя их на работу по SIP-протоколу. Также сохранили существующие SBC от Huawei, сконфигурировав под новую схему с нуля. Всё остальное было запланировано на замену.

Ожидаемые проблемы

• Большое количество голосовых шлюзов подлежит перенастройке (смена режима с MGCP на SIP).

• Вероятность большого простоя при миграции (особенно, присоединений к операторам).

• Необходимость настройки и сдачи СОРМ.

• Необходимость настройки сопряжения с биллингом.

• Вопрос совместимости с SBC от Huawei.

Подбор конфигурации оборудования

Согласно конфигурации нашей существующей сети и требованиям по минимизации затрат у нас получилось следующее:

• Сервера использовали собственные, закупленные ранее под другой проект. Предварительно согласовали это с производителем.

• К серверам приобретена лицензия (прислали токены) на необходимое нам количество абонентов для системы с резервированием (два сервера в кластере).

• Для присоединения к операторам по E1 (стыки ОКС7) использовали 2 единицы транковых шлюзов Eltex SMG-1016 в полной комплектации (закуплены ранее как альтернатива Huawei miniUMG8900, но полноценно их интегрировать с SoftX3000 не получилось).

• Для сопряжения с пультом СОРМ закуплена лицензия на SMG-1016, а также комплекс работ по настройке и сдаче. Таким образом, большая часть работ по этому этапу настройки выполнена технической поддержкой производителя.

• SBC оставили существующие, от Huawei (с прицелом на обновление в будущем). На данный момент функционал этих железок устраивает. Вопрос по надёжности остается открытым. В будущем нужно искать альтернативу этому оборудованию.

• Лицензии на подключение шлюзов MGCP закупать не стали. Решили перенастроить существующие шлюзы (поддержка протокола SIP есть на всех устройствах).

• Закуплены два коммутатора MES3324 и стекирующие DAC-кабели к ним, для подключения всего оборудования.

Начальное конфигурирование

Обычно производитель присылает предварительно настроенное и работоспособное оборудование — сервера на Ubuntu Server и установленное на них ПО Eltex ECSS-10. В нашем случае мы подготовили сервера самостоятельно (установили на них ОС), после чего предоставили удалённый доступ техническим специалистам производителя, которые уже подняли софтсвитч. В итоге мы получили две полностью работоспособные несконфигурированные АТС, с которыми начали работать и осваиваться.

Первым делом создали на станции несколько тестовых абонентов и настроили SIP-транк с существующей станции. Таким образом, наш новый софтсвитч заработал в роли учрежденческой АТС. И в такой роли он проработал фактически до последнего этапа миграции, но обо всем по порядку.

План миграции

После тестирования работоспособности и ознакомления с интерфейсом управления составили примерный план действий, которому следовали в дальнейшем:

1. Соединение новой станции с основной по SIP-транку. На этом этапе выделили несколько номеров из основной ёмкости и завели их в новый софтсвитч, проверили входящие и исходящие вызовы, потренировались в настройке различных параметров абонентов и настройке маршрутизации. В этот момент ECSS-10 являлась как бы внутренней мини-АТС по отношению к SoftX3000.

2. Настройка работы станции в паре с SBC, чтобы можно было подключать к ней абонентов из основной сети и тестировать в реальных условиях. Как уже указывалось ранее, в распоряжении был незадействованный SBC с какими-то тестовыми настройками. SBC был сброшен к заводским настройкам и поэтапно настроен по аналогии с основным. Этот этап помог лучше понять принцип работы и настройки SBC. Просто перенести настройки с рабочего устройства на новое не получилось, нужно было понимать, что именно выполняет каждая команда и как её изменить под новую конфигурацию.

3. Перевод нескольких абонентов в новую станцию. Это абоненты нашего офиса, чтобы не влиять на основных клиентов.

4. Тестирование и сбор статистики по проблемам.

5. «Заворот» трафика от одного из операторов на новую станцию. Все входящие вызовы с этого оператора сразу транзитом направляются в новую станцию. В новой станции, если вызов предназначен абонентам, зарегистрированным в этой станции, вызов «приземляется». Иначе возвращается по тому же транку в старую станцию, где маршрутизация происходит по старой схеме.

6. «Заворот» всего внешнего трафика на новую станцию для проверки стабильности работы (нагрузка) и корректности маршрутизации.

7. Работы по настройке выгрузки CDR и подготовке к интеграции с биллингом.

8. Работы по настройке СОРМ и подготовке к переключению на новую систему. Приемо-сдаточные испытания и получение всех согласований.

9. Перевод всех абонентов (кроме абонентов, работающих через SIP-транки) на новую станцию. Ночные работы с перерывом связи. Одновременно с этим переходим на новый СОРМ.

10. Биллинг пока остался на старой станции. Так как все внешние стыки идут через неё, то это некритично.

11. Перенос абонентских sip-транков на новую станцию (через второй SBC).

12. После сопряжения биллинга с новой станцией, по одному, с перерывами сервиса, перенесли внешние стыки с операторами с miniUMG8900 на SMG-1016.