Сегодня банки всё активнее «оцифровывают» клиентские сервисы и каналы коммуникации со своими клиентами: персонализируют обслуживание на основе данных клиента, внедряют дистанционные сервисы самообслуживания, чат-боты, виртуальные ассистенты, в том числе системы с элементами искусственного интеллекта (AI) и технологиями распознавания речи. Всё это делается в ответ на желание самих клиентов быть на связи со своим банком в режиме онлайн 24/7. И в результате банки начинают всё теснее сотрудничать с мобильными операторами. У тех есть распределённая и сложная инфраструктура, которая необходима банкам для решения стоящих задач. И чем большая часть телеком-инфраструктуры находится в непосредственном распоряжении банка, тем эффективнее создавать современные клиентские сервисы. И здесь на помощь приходит технология мобильных виртуальных операторов связи — 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 года.
Автор: JetHabr
