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

1. Сценарии. Оператор использует язык сценариев, такой как Python, для написания программ, которые отправляют команды по сети на отдельные устройства. Команды можно отправлять с использованием языка конфигурации устройства (командная строка, REST API, SNMP и т. д.). Обычно этого достаточно для небольших сетей. Однако код необходимо поддерживать по мере изменения устройств и появления новых устройств. . Оператор обычно не является профессиональным программистом и не работает в соответствии с принципами жизненного цикла разработки программного обеспечения. Ошибки распространены, особенно в сценариях сбоя.

2. Автоматизация на основе шаблонов. Инструменты автоматизации, такие как Ansible, были разработаны для развертывания программного обеспечения, но теперь они расширены и позволяют управлять устройствами. Ansible позволяет указывать этапы настройки устройства в повторно используемом шаблоне YAML, называемом плейбуками. Здесь общие задачи, такие как подключение к устройству, обработка сбоев и правильная последовательность, скрыты инструментом. Поставщики устройств предоставляют подключаемые модули, которые абстрагируют эти задачи для своих устройств. Повторяющиеся задачи (например, подключение приложения к сети) абстрагируются в шаблоны для заполнения пробелов. Задачи конфигурации выполняются путем заполнения пробелов (например, адрес целевого устройства, адрес компьютера, на котором размещено приложение). Задачи могут быть объединены в многоэтапные процессы. Это огромный шаг вперед по сравнению со сценариями, поскольку для написания очень мало кода. Несколько типов устройств могут обрабатываться в одном процессе. Конфигурация сети может быть выполнена синхронно с другими изменениями, такими как развертывание программного обеспечения. (В таких инструментах, как Ansible, используется императивная автоматизация: автор учебника указывает последовательность шагов). Однако все еще могут быть задачи, которые трудно автоматизировать с помощью шаблонов (например, сложные многоэтапные процессы на нескольких устройствах с большим количеством условной логики). В зависимости от подключаемого модуля инструмент может быть чувствителен к текущей конфигурации сетевого устройства, что затрудняет прогнозирование влияния запуска инструмента.

3. Оркестровка. Инструменты оркестрации, такие как Terraform, аналогичны автоматизации на основе шаблонов в том смысле, что они также имеют шаблоны, пробелы в которых могут быть заполнены входными данными, и скрывают логику подключения/выполнения команд. Кроме того, они могут автоматически определять зависимости между шагами и выполнять шаги параллельно (если между шагами нет зависимостей) или последовательно (отсюда: оркестровка). Terraform также может исключить шаги, если определит, что устройство уже находится в состоянии, определенном в шаблоне. Terraform и подобные инструменты используют так называемую декларативную автоматизацию: желаемое состояние конфигурации объявляется в файле шаблона и, независимо от текущего состояния конфигурации устройства, инструмент определяет шаги, необходимые для приведения текущей конфигурации к желаемой. государство. На самом высоком уровне сложности операторы могут удалить все состояние конфигурации сети и мгновенно воссоздать его с нуля. Эти инструменты также могут проверять дрейф конфигурации — разницу между желаемым состоянием и фактическим состоянием конфигурации. Выполняя инструмент в замкнутом цикле настройки/обнаружения дрейфа/настройки, операторы могут гарантировать, что состояние сети всегда максимально близко к желаемому состоянию.

4. Создание сетей на основе намерений. Хотя оркестраторы обладают большими возможностями, язык, используемый для указания состояния конфигурации сети, обычно соответствует языку сетевого устройства (например, маршруты, политики балансировки нагрузки, списки контроля доступа). Что, если бы можно было сгенерировать состояние конфигурации непосредственно из бизнес-требований (намерение)? Если должна быть развернута новая версия приложения, бизнес-требование может быть выражено как Развернуть версию 8.2 приложения X, не прерывая текущих пользователей текущей версии. Если новая версия не работает так же хорошо, как старая, откатите развертывание до версии 8.1. Это можно перевести в такую ​​стратегию, как сине-зеленое развертывание или канареечное развертывание, что приводит к настройке устройств управления трафиком, таких как балансировщики нагрузки. Нет ни одного инструмента с открытым исходным кодом, который можно было бы описать как управляемый намерениями, но нишевыми примерами являются: горизонтальное автомасштабирование pod в Kubernetes, группы безопасности в Apache CloudStack и OpenStack, а также структура намерений в OpenDaylight.

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

Эволюция сетевой автоматизации в замкнутые системы, основанные на машинном обучении и больших данных, мало чем отличается от эволюции автономных транспортных средств («автономное вождение»). Самоуправляемые транспортные средства принимают такие инструкции, как «безопасно ехать из точки А в точку Б». Они обрабатывают большие объемы данных датчиков, используя алгоритмы машинного обучения, чтобы постоянно корректировать курс транспортного средства и реагировать на внешние и внутренние события. Точно так же беспилотные сети будут получать тонны телеметрии из различных частей сети и анализировать данные для реализации высокоуровневых намерений, таких как «гарантировать, что по крайней мере 99% пользователей испытают задержку менее 1 секунды при использовании сети». наименьшее количество ресурсов». Самоуправляемые сети не за горами, но стремление к большей автоматизации делает их неизбежными.