Pull to refresh
253.87
Инфосистемы Джет
российская ИТ-компания

Рождение виртуального мобильного оператора: проект «Банка Тинькофф»

Reading time5 min
Views16K


Сегодня банки всё активнее «оцифровывают» клиентские сервисы и каналы коммуникации со своими клиентами: персонализируют обслуживание на основе данных клиента, внедряют дистанционные сервисы самообслуживания, чат-боты, виртуальные ассистенты, в том числе системы с элементами искусственного интеллекта (AI) и технологиями распознавания речи. Стремясь расширить спектр клиентских услуг, банки осваивают и новые для себя сферы деятельности. Один из примеров – технология мобильных виртуальных операторов связи (MVNO, mobile virtual network operator). Сейчас мы совместно с «Теле2» участвуем в проекте «Банка Тинькофф» по созданию виртуального оператора «Тинькофф Мобайл».

Что такое «виртуальный мобильный оператор»?


На Хабре уже есть хорошие статьи, объясняющие суть «виртуального мобильного оператора». Здесь лишь скажем, что виртуальный мобильный оператор — это виртуальная (программная) сеть, управляемая одной компанией, использующая физическую сеть связи, принадлежащую другой компании.

«Тинькофф Мобайл» строится по схеме Full MVNO. Это означает, что, когда все компоненты будут введены в строй, с точки зрения создания клиентских услуг новый виртуальный оператор мало чем будет отличаться от оператора «настоящего». «Тинькофф Мобайл» будет арендовать ресурсы сети базовых станций у оператора-партнёра, в качестве которого выступает «Теле2», при этом инфраструктура ядра сети и бизнес-приложения у MVNO будут собственные. Весь клиентский трафик пойдет через виртуального оператора, который фактически является для абонентов точкой входа в интернет.

Архитектура виртуального оператора


Нашу компанию выбрали для построения элементов ядра мобильной сети. Для нас это был первый подобный проект — сегодня MVNO в мире мало, особенно в России. С момента старта проекта до совершения первого клиентского звонка прошло всего 4 месяца, это очень быстро по меркам телеком-индустрии. Система спроектирована так, чтобы можно было модернизировать её без остановки работы, просто добавляя вычислительные узлы.

Из каких «кубиков» состоит архитектура виртуального оператора? На текущий момент она выглядит следующим образом:



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

Все представленные на схеме компоненты являются программными, исполняемыми на обычных серийных серверах. В основном это решения не традиционных крупных телеком-вендоров, а новые продукты компаний, которые активно выходят на рынок телеком-решений и теснят старых игроков. В частности, использованы узлы PGW/GGSN производства компании Affirmed Networks, узлы PCEF (DPI) производства Procera Networks и узлы PCRF Oracle. Конечно, традиционные вендоры тоже начали двигаться в сторону виртуализированных программных решений, но у них пока не получается полностью «отвязаться» от своих старых технологий, в то время как новые компании не имеют такого наследия, и их решения могут исполняться на любых платформах, на любых серверах любых производителей.

В телеком-отрасли всё шире используется Network Functions Virtualization (NFV), технология виртуализации сетевых элементов телекоммуникационной сети, фактически — виртуализация компонентов, обеспечивающих сервис для абонентов оператора связи. Сегодня одна из главных тенденций — отказ от специализированного и очень дорогого оборудования традиционных вендоров в пользу серийных серверов (commercial off-the-shelf, COTS) архитектуры x86 с установленным на них специализированным ПО. Причём оно работает под управлением виртуальной инфраструктуры, то есть запускается внутри виртуальных машин.

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

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

Другой недостаток режима PCI Passthrough заключается в невысокой плотности размещения ресурсов из-за невозможности совместного использования одного устройства несколькими гостевыми ОС, потому что каждая гостевая ОС в таком режиме использует устройство монопольно. Поэтому мы предложили альтернативный подход — технологию Single Root I/O Virtualization (SR-IOV).

SR-IOV позволяет использовать устройство напрямую, как и в режиме PCI Passthrough, минуя гипервизор. Но при этом устройство доступно одновременно для нескольких виртуальных машин, независимая обработка прерываний и DMA для каждой машины выполняется с помощью технологии Virtualization Technology for directed I/O (VT-d).

При включении режима SR-IOV сетевое устройство «расщепляется» на одну физическую функцию (Physical Function или PF) и несколько виртуальных функций (Virtual Function или VF). Физическая функция (PF) остается на уровне гипервизора и под его управлением. Виртуальные функции (VF) передаются в гостевые ОС и становятся сетевыми интерфейсами виртуальных сетевых функций (NFV) для взаимодействия с внешним миром. Вопрос производительности VF внутри VNF решается за счет применения фреймворка Data Plane Development Kit (DPDK). Изначально он был разработан в Intel, а затем передан открытому сообществу. Фреймворк позволяет значительно повысить производительность NFV при обработке сетевого трафика. Использование комбинации DPDK и SR-IOV для виртуализации сетевых функций — обязательное требование при построении высокопроизводительного NFV-решения, поскольку от него зависит скорость работы «интернета» на смартфонах абонентов.

Итоги


Как уже говорилось, проект реализовали очень быстро. Состав оборудования необходимо было определить на самом первом этапе проекта, чтобы к моменту окончания работы над дизайном системы оборудование уже было доставлено на площадки и готово к монтажу. Задачу также усложняло использование решений разных вендоров, это потребовало скоординированной работы всех команд, работавших над проектом.

После запуска системы, первого звонка и первого выхода в сеть на смартфоне с SIM-картой нового виртуального мобильного оператора, ещё два месяца настраивались бизнес-правила, проводились приемо-сдаточные испытания. В итоге система вышла в коммерческий режим эксплуатации 14 декабря 2017 года.
Tags:
Hubs:
+22
Comments23

Articles

Information

Website
jet.su
Registered
Founded
1991
Employees
1,001–5,000 employees
Location
Россия