Во второй день работы конференции Cisco Connect 2019 участники сосредоточились на технологических потоках. В этом году их было десять: «Информационная безопасность», «Решения для операторов связи», «Центры обработки данных» (ЦОД), «Инфраструктура корпоративной сети», «Гибридные облака и бизнес-приложения», «Технологии для совместной работы», «Интернет вещей», CX – Customer Experience (пользовательский опыт), бизнес-мероприятия и DevNet (разработка).
Разумеется, охватить все направления было бы попросту невозможно, поэтому мы решили отобрать наиболее интересных спикеров Cisco, которые делали доклады по направлениям, коррелирующим с центральной тематикой текущих номеров журнала «Коннект» – это корпоративные и коммерческие ЦОДы и сотовые сети 5-го поколения.
Переход от программно-центричной к дата-центричной модели
Дмитрий Хороших, менеджер по развитию бизнеса ЦОД Cisco, рассказал о построении ЦОДа с решениями Cisco.
В любом дата-центре можно выделить три ключевых компонента: приложение, данные и инфраструктуру. Примерно 15 лет назад приложение и данные были плотно привязаны друг к другу, под них строилась классическая трехуровневая выделенная инфраструктура: хранилище, SAN-сеть и сервер. Где-то с 2015 года появилась виртуализация, которая дала возможность вытащить инфраструктуру за пределы приложения – при этом данные все еще оставались внутри приложения (каждое приложение работало со своими данными), но уже можно было разместить множество приложений на общей виртуализированной инфраструктуре. Такая модель позволила развязать цикл обновления приложений и цикл обновления инфраструктуры: стало возможным обновлять отдельные элементы железа, не затрагивая работу самих приложений.
В настоящее время, как считает Дмитрий Хороших, мы находимся на пороге следующего фундаментального сдвига, когда данные начинают выноситься из приложения, которое оказывается чем-то внешним по отношению к своим данным. Тогда за один жизненный цикл этих данных с ними успевают поработать несколько приложений.
На собственном опыте работы с заказчиками Cisco убедилась в том, что клиенты сегодня уже не хотят перетаскивать в облако приложение с данными – они предпочитают поднять в облаке новое приложение, а уже к нему переносить данные, с которыми работало старое. Такая модель понятна и оправдана: любое приложение, просуществовав какое-то время, накапливает груз проблем, поэтому заказчику проще начать работу в облаке с новым приложением, чем пытаться как-то подлатать и исправить на новый лад старое. Поэтому решение Cisco, позволявшее клиентам перетаскивать в облако приложение с данными оказалось невостребованным.
Если мы посмотрим на эту ситуацию с точки зрения возможности обновлений, то увидим, что при разделении инфраструктуры, приложения и данных мы получаем самый длинный жизненный цикл именно у данных. На втором месте обычно стоит приложение, а вот инфраструктура, как правило, обладает самым коротким жизненным циклом.
Второй ключевой тренд заключается в требовании преемственности конфигурации при смене поколений оборудования. Решение этой проблемы Cisco видит в использовании профилей (сетевых, сервисных) в качестве основного подхода к управлению. Каждая функция сервера, каждая функция приложения на уровне сети описывается какой-то законченной конфигурационной единицей, которая называется «профилем». Далее эта конфигурационная единица загружается на конфигурационный контроллер, который прописывает все необходимые настройки в инфраструктуре ЦОДа.
Какие бонусы дает такой подход с профилями? Во-первых, вы получаете автоматизацию рутинных операций, с которыми раньше приходилось возиться системщикам. Во-вторых, резко уменьшается количество точек управления. Третье, и самое главное, данная модель позволяет отвязать конфигурацию от смены поколений оборудования – в результате, один и тот же сервисный профиль будет одинаково хорошо работать на серверах Cisco второго, третьего, четвертого и пятого поколений.
Кроме того, использование модели доступа через API позволяет легко интегрироваться с внешними инструментами управления, например, с UCS Director. Не говоря уже о том, что профили позволяют существенно упростить миграцию между облаками (с помощью специального инструмента Cloud Center).
Как правильно строить ЦОД? Дмитрий Хороших считает, что необходимо начинать с анализа данных, которые заказчик сбирается держать в ЦОДе. Статистика показывает, что при типовом раскладе около 40% СХД сегодня составляют диски виртуальных машин. Примерно 30% занимают файловые хранилища. Далее, порядка 20% объема занимают резервные копии. А вот нагруженные базы данных Oracle, SQL (это то, собственно говоря, из-за чего тяжелые СХД изначально и создавались) занимают лишь 10% от всего объема.
И вот для всех этих типовых случаев хранения данных у компании Cisco на сегодняшний день имеются хорошо отработанные решения. Так, для виртуальных машин предлагается универсальная платформа виртуализации Cisco HyperFlex (гиперконвергентное решение). Для так называемой «файловой помойки» предлагается два решения – Scality и Cohesity (последнее, кстати, появилось в прайс-листе Cisco буквально неделю назад). Наконец, для резервного копирования у Cisco есть решения от Commvault и Veeam.
Что же касается «тяжелых» СУБД, то в этом сегменте у Cisco имеется порядка десятка партнерских решений (типовые валидированные дизайны): NetApp, EMC, IBM, Hitachi, Cloudera, Red Hat, Pure Storage и др.
Кроме традиционных типов данных, перечисленных выше, у компаний сегодня все чаще появляются данные новых типов, связанные с Big Data и объектным хранением. Так, для работы с Big Data компания Cisco предлагает готовые типовые кластеры под Hadoop – все три основных дистрибутива доступны в прайс-листе. Для объектного хранения имеются решения от Scality и Cohesity (с разным масштабированием кластеров).
А ко всему перечисленному выше предлагается Cisco ACI (сейчас актуальной является 4-я версия) в качестве универсальной сети ядра ЦОД.
Архитектура сети мобильного Интернета вещей
Михаил Бухтеев, старший системный инженер Cisco, представил новые возможности трансформации сети оператора связи для оказания услуг IoT с помощью решений Cisco.
Докладчик начал с типовой LTE-сети сотового оператора связи, которая включает в себя такие базовые элементы, как SON (Self-Organizing Network – самоорганизующуюся сеть), MME (Mobility Management Entity – узел управления мобильностью сети сотовой связи стандарта LTE) и S/PGV (Packet Data Network Gateway – пакетный шлюз, основная задача которого заключается в маршрутизации трафика сети LTE к другим сетям передачи данных, таким как Интернет, а также к сетям GSM и UMTS).
На начальном этапе к этой стандартной конфигурации начинают добавлять M2M (этот первый сервис IoT появился примерно пять лет назад) – подключенные автомобили, платежные терминалы и т.д. На первый взгляд, может показаться, что от базовой сети каких-то изменений вообще не требуется, но большинство операторов вполне разумно начинали добавлять в свою сетевую инфраструктуру выделенный шлюз PGV, который был предназначен для IoT-устройств. Почему бы нам не терминировать эти сессии на обычном PGV? Во-первых, для IoT-устройств необходимы специфические настройки; во-вторых, это упрощает проведение апгрейда ПО на узлах; в-третьих, у IoT-устройств есть существенно отличная от смартфонов модель трафика – ограничителем здесь оказывается на объем трафика, а количество подключаемых устройств. В классической сотовой сети на S/PGV операторы считают гигабиты на сервер, а в случае со шлюзом для M2M они считают количество устройств.
Далее, примерно три года назад был стандартизован NB-IoT/Cat M1 (Narrow Band Internet of Things) – стандарт сотовой связи для устройств телеметрии с низкими объемами обмена данными. Он решал следующие основные задачи: улучшение покрытия LTE, уменьшение энергопотребления, чтобы датчики могли работать от одной батарейки годами. При этом ставить новые базовые станции не требовалось – достаточно было изменения ПО, которое обеспечивало поддержку новой функциональности. Однако же, большинство операторов ставят в сети отдельный узел C-SGN (Cellular IoT Serving Gateway Node), который, по сути дела, представляет собой объединение в едином элементе узлов MME, SGW и PGW.
Кроме C-SGN, в сети появляется новый элемент – SCEF (Service Capability Exposure Function – узел экспонирования сервисных возможностей). SCEF снимает с разработчиков приложений необходимость в идентификации и аутентификации мобильных устройств (UE), предоставляя возможность серверам приложений (AS) получать данные и управлять устройствами через единый API-интерфейс. Идентификатором UE становится не обычный телефонный номер (MSISDN) или IP-адрес, как это было в классической сети 2G/3G/LTE, а так называемый external ID.
На следующем этапе к классической сотовой LTE-сети операторы начинают добавлять технологии, которые не относятся к 3GPP – речь идет о стандартах LoRa и Wi-Fi. Это делается, чтобы обогатить предложения в плане возможностей работы в сфере IoT: парковки, ЖКХ, освещение, умное С/Х, навигация и отслеживание объектов внутри помещений и т.д.
Наконец, в сети оператора связи появляются пилотные секторы 5G, которые позволяют существенно обогатить IoT-сервисы, добавляя услуги со сверхнизкими задержками для беспилотных автомобилей, промышленного IoT, тактильного Интернета и т.д.
В сетях 5G появляется возможность нарезать слайсы (сегменты, отдельные виртуальные подсети) под такие секторы, как, например: обычный Интернет (5G slice eMBB – Enhanced Mobile Broadband), под сервисы со сверхнизкими задержками (5G slice URLCC – Ultra-Reliable Low-Latency Communication), под больших клиентов и т.д.
Михаил Бухтеев также отдельно выделил такую популярную область IoT-кейсов, которая связана с проектом «Умный город». Если сотовый оператор ориентируется на такие вертикальные IoT-проекты, связанные с «умным городом», «умным производством», нефтегазовым сектором, транспортом и т.д., то для этих целей он может в своей сети использовать специализированные платформы, например, такие как Cisco Kinetic.
Далее в своем выступлении Михаил Бухтеев проанализировал перечисленные выше технологии и выделил их ключевые преимущества для продвижения IoT-сервисов.
Особо стоит отметить следующий момент, касающийся сетей LPWAN. 24 декабря на заседании Государственной комиссии по радиочастотам (протокол №18-48) было принято решение о внесении изменений в решение ГКРЧ от 7 мая 2007 года, которое регулирует применение на территории РФ устройств малого радиуса действия. В приложении №11 к решению ГКРЧ от 07.05.2007 №07-20-03-001 столбец «Дополнительные условия использования» для полос радиочастот 864-865 МГц, 866-868 МГц, 868,7-869,2 МГц решено дополнить следующими положениями:
«Применение базовых станций в сетях связи для сбора и обработки телематической информации осуществляется при условии: регистрации базовых станций в установленном в РФ порядке; ввода в эксплуатацию сетей связи в установленном в РФ порядке; с 1 декабря 2020 года допускается использование базовых станций, произведенных на территории Российской Федерации, которым присвоен статус телекоммуникационного оборудования российского происхождения (условие не распространяется на базовые станции, зарегистрированные до 1 декабря 2020 года)».
