ЧТО ТАКОЕ INTENT-BASED NETWORKING?
Intent-Based Networking (IBN) — один из многих терминов мира сетевых технологий, для которого пока не придумано адекватного перевода на русский язык. Кто-то переводит его как «сети, основанные на намерениях», некоторые — как «интенционно ориентированные сети», а иногда — как «интенционные сети». Мы же оставим дальше по тексту англо-язычный термин или будем использовать аббревиатуру IBN.
За последние пару лет понятие Intent-Based Networking стало «горячей» темой. Что же оно означает?
Корпоративные сети используются прежде всего для решения бизнес-задач, которые в данном контексте можно представить как совокупность намерений — высокоуровневых целей, сформулированных, как правило, без указания технических подробностей их достижения. Примером намерения можно считать цель «сделать так, чтобы сотрудники отдела X имели доступ только к ресурсам Y». Другой пример: «запустить приложение Z и обеспечить его качественную работу поверх сети».
При традиционном подходе подобные намерения реализуются вручную. Администраторы продумывают, какие технологии они будут использовать для решения поставленной задачи, какой функционал должен быть настроен, какие команды введены, на каких устройствах сети и т. д.
Новый подход, реализуемый в сетях IBN (рис. 1), предполагает, что администратор задает намерение в высокоуровневом виде и сеть реализует его «сама», используя средства автоматизации и искусственного интеллекта.
Рис. 1. Принцип работы сети IBN |
ЗАЧЕМ ЭТО НУЖНО?
Может возникнуть вопрос: а зачем этот подход нужен бизнесу, какую проблему он решает?
По данным Cisco, около 80% изменений в корпоративных сетях до сих пор производится вручную. Примерно 70% нарушений корпоративных политик связано с «человеческим фактором». И до 75% операционных расходов ИТ приходится на внесение изменений, поиск и устранение неисправностей, причем последние операции занимают почти половину (43%) рабочего времени обслуживающего персонала.
Кроме того, исследование Cisco показало, что ИТ-персонал обычно тратит на сбор данных вчетверо больше времени, чем на анализ проблемы. По мере дальнейшего роста и усложнения сетей эта проблема еще более усугубится.
По данным IDC, финансовые потери компаний из списка Fortune 1000 из-за незапланированных перерывов в работе сети ежегодно составляют 1,25–2,5 млрд долларов.
Таким образом, сегодняшний подход к построению и эксплуатации сетей нуждается в улучшении. Приведенные цифры также свидетельствуют о том, что решить проблему не помогают ни многочисленные (и обычно разрозненные) средства централизованного управления, ни изобилие данных, имеющихся у ИТ-персонала. Нужны новые инструменты и подходы. Возможность применения таких инструментов и подходов и предоставляют сети, реализующие концепцию IBN.
АРХИТЕКТУРА СЕТИ IBN
На практике сети IBN Cisco основаны на концепции сетевой фабрики (network fabric) и контроллера. Что они собой представляют и зачем нужны?
Сетевая фабрика включает в себя две сетевые топологии: опорную сеть IP, обеспечивающую передачу информации из точки А в точку Б, и работающую поверх этой IP-сети наложенную (overlay) сетевую топологию, на базе которой реализуются политики (рис. 2). По сложившейся терминологии под «сетевой фабрикой» обычно подразумевают наложенную топологию, реализованную поверх опорной.
Рис. 2. Концепция сетевой фабрики |
В кампусных сетях транспорт и политики традиционно реализовывались в рамках единой сетевой топологии. Практика показала, что попытки решить эти две задачи на уровне одной и той же сетевой топологии обычно приводят к тому, что эффективных результатов не удается получить ни в том ни в другом случае. Это происходит оттого, что к сети предъявляются противоречивые требования. Для организации надежного транспорта нужна высокая доступность сети и, как следствие, ее стабильность, то есть минимум изменений. В то же время применение политик и поддержание их в актуальном состоянии требует внесения изменений в сеть, что нарушает ее стабильность.
Более того, на практике при совмещении функций обеспечения транспорта и соблюдения принятой политики в единой топологии возникают взаимозависимости: изменения в функционале, связанном с решением одной задачи, меняют решение другой. Это усложняет сеть, затрудняет внедрение новых сервисов и политик, замедляет реализацию бизнес-инициатив.
Концепция сетевой фабрики позволяет преодолеть эти противоречия. Единая сложная задача, предполагающая одновременную реализацию и транспорта, и политик, характерная для сети с единой топологией, делится на две более простые: отдельная реализация транспорта и правил в опорной IP-сети и наложенной топологии сетевой фабрики.
Такое разделение логики позволяет создать оптимальные условия для решения этих задач: абстрагировать их, сведя взаимозависимости к минимуму. Вот почему на основе сетевой фабрики гораздо легче реализовать сквозные политики, автоматизацию и оркестрацию и в конечном счете обеспечить быструю реакцию сети на бизнес-инициативы. Они исполняются с помощью централизованного компонента — контроллера. Последний реализует плоскость управления (management plane) сети IBN, а также предоставляет средства мониторинга и аналитики.
В общем случае контроллер может работать с несколькими инфраструктурными доменами (например, с кампусной сетью, WAN и ЦОД), в частных случаях (типичных на сегодняшний день) — охватывать один из доменов.
Мы рассмотрели ключевые компоненты, на базе которых строится сеть IBN. Какие же основные логические функции они должны выполнять? С точки зрения Cisco, таких функций три (рис. 3). Во-первых, необходимо, чтобы сеть IBN предоставляла средства для трансляции бизнес-намерений в конкретные настройки оборудования. Затем эти настройки нужно внедрить в корпоративную ИТ-инфраструктуру. Наконец, следует убедиться в надлежащей реализации намерений и принять корректирующие меры в случае необходимости.
Ключевой функционал сети IBN |
Translation: трансляция бизнес-намерений. Трансляция включает в себя две ключевые функции. Во-первых, администратор должен иметь возможность задать желаемый результат, то есть бизнес-намерение. В общем случае это может быть сделано с помощью графического интерфейса пользователя, абстрагированной модели (например, на базе YANG или JSON/XML), специализированного языка или, возможно, посредством голосовых команд. Высокоуровневое задание команд и их абстрагирование от низкоуровневых деталей реализации — важное отличие концепции IBN от традиционного подхода к эксплуатации сетевой инфраструктуры.Рассмотрим эти задачи подробнее.
Во-вторых, необходимо иметь возможность преобразовать полученные намерения в набор политик, общих для всей сетевой инфраструктуры. В англо-язычной литературе такие политики носят название Model-Based Policy (MBP). Это фундаментально важный этап для обеспечения консистентности и автоматизации внедрения.
На практике бизнес-намерения обычно задаются с помощью интерфейсов контроллера — например, через его GUI и «северные» (northbound) API, которые могут быть ориентированы как на ИТ-сервисы, так и на бизнес-приложения. Политики MBP генерируются автоматически программным обеспечением контроллера.
Activation: активация бизнес-намерений в инфраструктуре. Задача активации — внедрить политики MBP, заданные на этапе трансляции, во все области сети, которых они касаются.
Активация должна обеспечивать генерацию соответствующих конфигураций элементов сетевой инфраструктуры. При этом предпочтительно, чтобы сведения об этих элементах, их функциональных возможностях и сетевой топологии предварительно коррелировались с данными MBP. Кроме того, конфигурации можно заранее проверить на консистентность.
На практике контроллер сети IBN обычно автоматически применяет конфигурации через свой «южный» (southbound) API.
Assurance: аналитика и обратная связь. Этот функционал предполагает создание обратной связи между инфраструктурой и контроллером. Идея заключается в том, чтобы контроллер не только реализовывал бизнес-намерения, но и проводил в дальнейшем мониторинг и анализ корректности их реализации, а в случае необходимости применял корректирующие воздействия автоматизированно или автоматически. Эта идея отражена в названии: assurance — от англ. «уверенность, гарантия».
Функционал Assurance является критически важным компонентом решения IBN. Используемый им контекстный анализ данных, получаемых от элементов сетевой инфраструктуры, позволяет убедиться в корректности реализации заданного намерения.
Существует три ключевых аспекта функционала Assurance:
1. Непрерывная верификация. Необходимо быть уверенным в том, что система правильно выполняет заданное бизнес-намерение в течение всего времени. Это предполагает постоянный мониторинг состояния и событий элементов сетевой инфраструктуры. Получаемая от них телеметрия позволяет убедиться в обеспечении требуемой производительности при реализации намерения. Инструментарий Assurance может использовать разные подходы — от формальных математических моделей до средств машинного обучения.
2. Формирование выводов на основе аналитики: в дополнение к верификации текущего состояния сети и его соответствия заданному намерению, Assurance может предоставлять выводы (insights), более глубокое видение (visibility) сетевой инфраструктуры и выполнять анализ тенденций. Например, он может предсказывать конкретные нарушения заданного намерения перед его применением, прогнозировать результаты развития текущих тенденций, выявлять аномалии и т.д.
3. Получение обратной связи для реализации корректирующих мер и улучшения сетевых настроек: нарушения правил, SLA, аномалии и прочие подобные ситуации, выявленные на предыдущем этапе, могут быть исправлены контроллером путем повторного применения необходимых функций из раздела Activation. Таким образом, сеть IBN получает механизм для автоматического устранения нарушений заданных бизнес-намерений, а также для постоянной автоматической оптимизации сети. Такой инструментарий помогает добиться надлежащего выполнения заданных намерений в течение всего времени работы сети IBN.
На практике обратная связь обычно обеспечивается путем получения контроллером информации от элементов сетевой инфраструктуры на базе разных протоколов и источников (например, NetFlow, syslog, SNMP, вывода show-команд интерфейса CLI, в том числе относящихся к функционалу IP SLA и AVC), а также от других систем (ISE, AppDynamics, CMX, DNS, DHCP, решений ITSM, IPAM и т. п.). Далее информация анализируется подсистемой аналитики, реализованной в программном обеспечении контроллера. Результаты анализа (в виде выводов с пояснениями и рекомендациями) либо предлагаются администратору для принятия им самостоятельных решений, либо применяются контроллером автоматически.
ТИПОВЫЕ СЦЕНАРИИ ПРИМЕНЕНИЯ
Концепция Intent-Based Networking находится пока на начальном этапе своего практического воплощения. Cisco активно работает над ней и уже реализовала имеющиеся наработки в коммерчески доступных продуктах. Так, сеть IBN для корпоративных кампусных сетей представлена решением Cisco Software-Defined Access (SD-Access) на базе контроллера DNA Center и сетевой инфраструктуры, объединенной в сетевую фабрику (рис. 4).
Рис. 4. Ключевые компоненты сети Cisco SD-Access |
Какие же типовые задачи, актуальные для корпоративных сетей, уже сегодня помогает решить сеть IBN? К таким задачам можно отнести ускоренное развертывание инфраструктуры, быстрое внедрение новых сетевых функций, а также дальнейшую автоматизацию мониторинга и диагностирования, подкрепленную средствами аналитики.
Рассмотрим некоторые из них.
Сегментация. Одна из актуальных типовых задач — сегментация. Соображения безопасности часто требуют разделить пользователей, устройства, ресурсы сети на отдельные группы (виртуальные сети) с возможностью фильтрации или полной блокировки трафика между ними в соответствии с заданными политиками.
Традиционно такая задача решалась путем создания виртуальных топологий Уровня 2 и/или Уровня 3 (VLAN, VRF, MPLS VPN и т. п.) с заданием правил фильтрации (обычно на базе пакетных фильтров ACL или межсетевых экранов). Более современный подход — применение технологии TrustSec для сегментации на базе меток SGT (Scalable Group Tag). Кроме того, пользователи и устройства должны пройти аутентификацию и авторизацию для работы в соответствующей виртуальной сети, что для большинства устройств осуществляют, как правило, динамически с помощью сервера RADIUS и протокола 802.1x.
Типовые трудности решения этой задачи заключаются в сложности создания и поддержания в актуальном виде виртуальных топологий и особенно списков контроля доступа. Эти препятствия можно преодолеть с помощью технологии TrustSec, но для оптимальной реализации TrustSec необходима сквозная поддержка технологии во всех элементах сетевой инфраструктуры.
В сети SD Access контроллер DNA Center позволяет задать политики сегментации (в том числе правила фильтрации трафика между виртуальными сетями) с помощью графического интерфейса. Далее контроллер реализует эти политики в сети автоматически, используя функционал VRF и TrustSec, а также интеграцию с сервером контроля доступа Cisco ISE через интерфейс pxGrid.
Политика реализуется на уровне логической топологии сетевой фабрики с применением инкапсуляции VXLAN-GPO, поэтому сквозной поддержки TrustSec со стороны промежуточных элементов сетевой инфраструктуры уже не требуется. В целом сеть IBN значительно ускоряет и облегчает решение задачи сегментации.
Политики приложений. Другая важная задача — обеспечить надлежащее качество работы корпоративных приложений в условиях конкуренции их трафика за общие сетевые ресурсы и с учетом разных требований приложений к ресурсам.
Такая задача решается в пакетных сетях с помощью механизмов обеспечения качества обслуживания (QoS). Проблема в том, что из-за большого объема работы, трудностей настройки политики QoS, а также разной реализации QoS в элементах сетевой инфраструктуры далеко не всегда удается получить нужные результаты.
В сети IBN для этого используются возможности контроллера. Он абстрагирует цели внедрения от деталей реализации, что позволяет задать требуемую политику через его Web-интерфейс. Далее через «южные» API контроллер автоматически сообщает правила элементам сетевой инфраструктуры, тем самым существенно ускоряя внедрение политик QoS.
Решение базовых задач автоматизации. К базовым задачам можно отнести автоматизацию развертывания новых элементов сетевой инфраструктуры (Plug & Play), управление образами ПО, задание нужных параметров в настройках сетевой инфраструктуры и беспроводных локальных сетей, определение шаблонов аутентификации и авторизации устройств при подключении к сети и т. д.
Традиционно такие задачи решаются без использования контроллера, хотя и не так эффективно, как хотелось бы: с помощью ручных операций в CLI, применения сценариев, централизованных средств управления или комбинации подобных средств. Но если в сети появляется контроллер, то весь необходимый функционал для решения задач автоматизации логично реализовать именно на его базе и тем самым оптимизировать количество средств управления в сети и процессы ее эксплуатации. Более того, идея реализации намерений и Intent-Based Network по умолчанию подразумевает возможность автоматизации. Таким образом, этот метод можно считать типовым для сетей IBN.
Функциональность Assurance. Другой типовой сценарий, в котором может помочь сеть IBN, — поиск причины возникновения проблем в сети. Локализация проблемы может занимать многие часы. Контроллер DNA Center способен сократить это время до нескольких минут. Он предоставляет исчерпывающую информацию о состоянии элементов сетевой инфраструктуры и клиентских устройств, их контекстный анализ, а при выявлении проблемы предлагает ее описание с конкретными рекомендациями относительно необходимых действий. В ряде случаев доступна возможность автоматизированного устранения проблемы по команде администратора.
Решением проблем, связанных с сетью или ее клиентскими устройствами, обычно начинают заниматься, когда они уже проявились. Зачастую проходят часы, а иногда и дни. При этом детальная информация о произошедшем доступна не всегда, а если речь идет о пользователях — крайне редко. Это затрудняет поиск и устранение причины неисправности.
Контроллер DNA Center собирает и до 14 дней хранит детальную информацию о состоянии сети и ее клиентов, а его функциональность позволяет получить не только подробные сведения о событиях, произошедших за это время, но и полезные рекомендации. Это значительно облегчает диагностирование, особенно если воспроизведение проблемы затруднительно, а информации о ней крайне мало.
Немало сложностей возникает при подключении клиентов к сети, особенно беспроводной. Это могут быть трудности аутентификации, проблемы с DHCP, нюансы радиосреды и т. д. Функционал Assurance DNA Center позволяет оперативно выявлять и устранять их, причем зачастую до того, как пользователь сообщит в службу ИТ.
И все же проблемы лучше предотвращать, чем решать. Контроллер сети IBN выявляет негативные тенденции в собираемой информации и заблаговременно направляет предупреждение администратору. Кроме того, он предоставляет информацию о производительности работы приложений на основе показаний сенсоров в проводной и беспроводной сети. Так, контроллер распознает приложения с помощью функционала NBAR2, экспортирует данные телеметрии посредством Flexible NetFlow и осуществляет мониторинг индикаторов производительности с использованием Application Response Time (ART). Затем контроллер предоставляет подробные данные о состоянии «здоровья» приложений, проблемах, задержках (в сети и на стороне серверов) и т. п.
Точки радиодоступа в сети IBN могут действовать в качестве сенсоров как клиентские устройства и позволяют реализовать 15 видов тестов, дающих исчерпывающую информацию об уровне сервиса, предоставляемого мобильным пользователям.
Приведенные примеры — только часть возможностей Assurance. По мере дальнейшего развития функционала контроллера DNA Center и выхода новых версий программного обеспечения можно ожидать появления новых возможностей и сценариев применения. Но уже сегодня Assurance позволяет существенно сократить затраты времени на поиск и устранение неисправностей, помогает повысить доступность сети и обеспечить надлежащую работу бизнес-сервисов.
ИТОГИ
Intent-Based Networking может стать важнейшим этапом эволюции сетевых технологий, помогая компаниям оптимизировать эксплуатацию сетей и повышать их доступность. Очевидно, что переход на новую технологию потребует времени, но можно ожидать, что концепция IBN постепенно придет на смену традиционному подходу и будет реализовываться во все большем числе корпоративных сетей. По результатам исследования, проведенного в 2018 году компанией Gartner, уже к 2020 году свыше 1000 крупных компаний будут использовать системы IBN в продуктивной эксплуатации.
Сергей Полищук, системный инженер Cisco
sepolisc@cisco.com