Денис Коденцев, инженер-консультант Cisco
Уже два десятка лет сетевые технологии развиваются в единой парадигме: сетевые устройства, прежде чем быть установленными в инфраструктуру, настраиваются высококвалифицированным персоналом, который зачастую использует командную строку как самый надежный способ конфигурирования. Трансляция бизнес-цели в функционирующую нужным образом сеть представляет собой задачу, посильную разве что CCIE, JNCIE или специалисту любого другого экспертного уровня – выберите согласно вашим технологическим убеждениям и верованиям. К тому же с точки зрения сетевого инженера сложно себе представить ситуацию, когда устройство, только полученное с завода, может быть сразу подключено в сеть и начать выполнять задачи без предварительной вдумчивой и долгой настройки. Бизнес, который использует сети для зарабатывания денег и/или обеспечения внутренних сервисов, уже смирился с этим и по большому счету не ждет и не верит, что парадигма может измениться.
Постановка задачи
Этому есть объективные и субъективные причины. Во-первых, универсальный ответ: так исторически сложилось. Действительно, многие годы автоматизация сетей сводилась к внедрению очередной системы управления, которая, обладая очевидными преимуществами, не давала службам эксплуатации нужной степени контроля над сетью и по мере внедрения новых решений и технологий становилась все более узкой с точки зрения применимости. В конечном итоге вытеснить CLI (Command-line interface) стало практически невозможно. Во-вторых, эксплуатация современной сети – это фактически поиск баланса между сложностью самой сети и технологиями, ее управляемостью и минимальным вмешательством в ее работу. Наконец, технологии, которые используются сегодня, зачастую требуют не только специализированного высшего образования, но и последующей многолетней работы в индустрии, что необходимо для понимания фундаментальных проблем, связанных с построением и эксплуатацией сетей, и возможных путей их решения.
Индустрия находится в постоянном поиске более эффективных решений. Одним из перспективных направлений, способных ответить на указанные вызовы, видится концепция автономных сетей (Autonomic Networking), цель которой – сделать сетевые элементы более самостоятельными при первоначальном включении, самодостаточными и самовосстанавливающимися в процессе функционирования, а формирование сетевых услуг и сервисов – более абстрактным и приближенным к сформулированным потребностям бизнеса.
Концепция не является совершенно новой. Еще в 2001 г. компания IBM представила свое видение автономных систем c элементами, способными к самостоятельному конфигурированию, оптимизации работы и восстановлению после сбоя. Однако только в последние годы автономность вновь завладела умами.
Следует сразу обрисовать область интереса автономных сетей (АС), так как на первый взгляд может показаться, что концепция АС конкурирует с популярным подходом программно-определяемых сетей (Software Defined Networking). На самом деле АС дополняет SDN, обеспечивая, в частности, механизмы автоматического запуска нового устройства и программные интерфейсы для взаимодействия с внешними системами, которыми, в свою очередь, могут быть системы оркестрации сервисов или SDN-контроллеры.
С учетом сказанного автономные сети призваны ответить на несколько ключевых вопросов:
- как реализовать автоматическую настройку нового устройства в сети с минимальным вмешательством со стороны служб эксплуатации;
- как обеспечить безопасность такой сети и возможность корректирующих действий со стороны администратора;
- как использовать подход автономных сетей для уже существующих сетевых инфраструктур.
Архитектура автономных сетей
В основе предлагаемой индустрией архитектуры автономных сетей лежит базовая идея, что сетевое устройство способно при подключении самостоятельно определить свое местонахождение в сети и принять решение о наилучшем способе функционирования, соответствующем текущим бизнес-задачам. По мере изучения своего сетевого окружения или возникающих в сети изменений устройство самостоятельно адаптирует поведение по умолчанию.
Первое, что предлагается архитектурой, – это создание дополнительного процесса управления внутри каждого сетевого элемента (устройства) (рис. 1). Взаимодействие таких процессов на разных устройствах образуют виртуальную шину – Autonomic Control Plane (ACP), фактически являющуюся наложенной сигнальной сетью и обеспечивающей автоматическое обнаружение и взаимодействие устройств, поддерживающих технологию АС. Помимо указанных функций в задачи ACP-процесса входит взаимодействие с вышестоящими системами управления и оркестрации, формирующими запросы на предоставление сетевых сервисов на высокоуровневом языке (Intent).
Рис. 1. ACP-процесс
ACP-процесс также обязан иметь возможность «конфигурировать» устройство. Для этого он взаимодействует с нижестоящим процессом сетевой операционной системы, используя специальные программные интерфейсы API. Таким образом, ACP-процесс фактически транслирует намерения (Intent) системы управления в понятный устройству язык (CLI).
Следует обратить внимание, что устройство, обладая определенной самостоятельностью в принятии решения в вопросе, как лучше реализовать запрошенный набор услуг, предоставляет механизм влияния на конечную конфигурацию со стороны системы управления и/или системного администратора, обеспечивая тем самым механизм контроля.
Техническая реализация шины ACP (рис. 2) основана на использовании IPv6 link-local-адресов, которые назначаются автоматически всем интерфейсам, на которых активирован стек протоколов IPv6.
Рис. 2. Техническая реализация шины ACP
Следующий ключевой элемент концепции – процесс и механизмы, реализующие автоматическое обнаружение сетевого окружения и надежную идентификация узла в таком окружении (рис. 3). Очевидно, что устройство, не обладающее первоначальными настройками и подключаемое потенциально в любую точку сети, должно иметь возможность, с одной стороны, автоматически обнаружить соседние устройства, относящиеся к АС-домену, с другой – однозначно и безопасно себя идентифицировать.
В результате процесса обнаружения соседних узлов устройство формирует таблицы, определяющие, в частности, какие интерфейсы связывают этот узел с АС-доменом и считаются доверенными, а какие не содержат известных АС соседей – в таком случае устройство способно самостоятельно запросить идентификацию соседа, который пока не является частью АС-домена, и в случае неудачи определить такой интерфейс как недоверенный. Это позволяет сформировать безопасный периметр АС-домена.
Для первоначальной идентификации устройства используется идентификатор UDI (Unique Device Identifier), зафиксированный в устройстве производителем, или в случае использования незащищенных каналов SUDI (Secure Unique Device Identifier). Узел, который осуществляет идентификацию нового устройства в АС, называется Registrar (регистр). Этот же узел в результате успешной идентификации выдает устройству подписанный сертификат, позволяющий устройству взаимодействовать с остальной частью АС-домена через шину ACP. Очевидно, что далеко не всегда новое устройство подключается к регистру напрямую. Это означает, что любой полноправный узел АС-домена должен поддерживать функционал прокси (Proxy), обеспечивающий взаимодействие нового узла с удаленным регистром. Результат работы процесса идентификации устройства может также использоваться для единообразной аутентификации стандартных протоколов – BGP, OSPF, ISIS, PIM и т. п.
Рис. 3. Обнаружение сетевого окружения
После успешной идентификации и получения сертификата устройство может получить базовую конфигурацию, а также набор описаний требуемых сервисов от вышестоящей системы управления. Процесс ACP транслирует полученный набор в настройки конфигурации сетевой ОС, обеспечивая создание целевого сервиса на новом устройстве. С этого момента устройство полностью интегрировано в сеть и готово предоставлять требуемые сервисы.
Ограничения применения
Как и любая существующая технология, концепция автономных сетей представляет собой удачный компромисс, решающий поставленные задачи, но обладая при этом рядом ограничений.
Так, концепция АС предполагает модификацию системного ПО сетевых устройств для поддержки всех описанных выше механизмов. В настоящее время не все устройства известных производителей сетевого оборудования поддерживают механизмы АС, и это основное ограничение распространения технологии.
Еще один ограничивающий фактор – стандартизация автономных сетей еще не завершена. Большая часть работ проводится в рамках рабочей группы ANIMA в IETF (http://tools.ietf.org/wg/anima/). Несмотря на то что индустрия в целом пришла к общему пониманию, как должны реализовываться основные механизмы и технологии в рамках АС, многие производители продолжают самостоятельные изыскания в этой области, что может приводить к несовместимости в мульти-вендорных сетях.
Наконец, очевидно, что в большинстве случаев невозможно использовать самый простой сценарий внедрения – новая сеть на базе устройств, полностью поддерживающих механизмы и протоколы АС. Как правило, речь идет о внедрении на существующей сети, что предполагает ограниченность применения технологии только на части сети.
Преимущества
Однако, несмотря на перечисленные ограничения, технологии автономных сетей привлекают все больше внимания, во многом благодаря удачной интеграции в SDN-концепцию и наглядных бизнес-преимуществ для заказчиков, в том числе:
- снижение операционных затрат на эксплуатацию сетевой инфраструктуры;
- уменьшение времени на расширение сети и запуск новых услуг;
программируемость сети – возможность заказа сетевых услуг за счет использования описания на высокоуровневом языке.
