Общий взгляд на жизненный цикл оборудования

https://fs.linkmeup.ru/images/adsm/4/life_cycle.png

Вот мы купили сетевую железку. Что теперь? Проследим её жизнь с первого и до последнего дня.

  1. Day 0 - железка только появилась в наших руках. Сейчас самое важное - базовая настройка:
    • Добавить IP-адрес управления и маршрут
    • Включить SSH
    • Создать пользователя с правами настройки
    Иными словами задача Day0 конфигурации - организовать доступ на устройство.
  2. Day 1 - Железка уже встала на позицию, определена его роль в сети и сервисы, которые она обслуживает.
    Теперь нужно настроить уже целевую конфигурацию, с которой устройство встанет в сеть под нагрузку.
  3. Day N - Изменения конфигурации в процессе эксплуатации. | Бывает мы добавляем новый сервис, пересматриваем дизайн или на худой конец нужно ACL поправить. | Такие изменения нужно тоже уметь довозить до устройства.

  4. Обслуживание - Помимо нормальной работы есть периоды, когда устройство нужно аккуратно вывести из под нагрузки, чтобы, например, поменять в нём плату, провести обновление ПО.

  5. Отслеживание изменений - со всей сети следует собирать информацию о том, где и во сколько применялась новая конфигурация. Это позволит как скоррелировать жалобы клиентов с изменениями, так и знать, когда применялась новая конфигурация в обход процедуры.

  6. Проверка соответствия эталонной конфигурации** - В течение всей жизни устройства нужно проверять, что его конфигурация не разошлась с целевой из-за сбоев в автоматике, обновлений ПО или прямого вмешательства чьих-то рук.

  7. Бэкапы - Даже если мы в любой момент можем сгенерировать эталонную конфигурацию, чтобы применить её на устройство, бэкапы необходимы.

  8. The Last Day - снятие нагрузки, удаление из всех систем, ритуальное сжигание. Под сжиганием я понимаю безопасную затирку конфигурации, чтобы хэши паролей (или, упаси Лейбниц, клиртекст), префикс-листы и ACL’и не оказались достоянием общественности.

Я намеренно обхожу вниманием в этой статье вопрос мониторингов операционного состояния и реакции на них, поскольку её лейтмотив - это всё же конфигурация.

Далее обсудим Day0 - DayN более детально.

Day0

Итак, поставщик привёз на склад новый свитч. Его нужно установить, настроить, проверить, запустить трафик, добавить во все системы: инвентарные, мониторинги, бэкапы, скрипты автоматизации всякой рутины.

Задачи Day 0 можно грубо разделить на две части:

  • Завести устройство в системах
  • Настроить базовый доступ

Говорить про них в отрыве друг от друга сложно, и делать мы так не будем.

Какие же есть способы?

  1. Бумер - вручную завести устройство в инвентарной системе и выделить свободный IP-адрес. Пусть это будет даже экселька.
    Подключить свитч к компьютеру и через консольный порт настроить IP-адрес, маршрут, включить SSH, создать пользователя.
    Отвезти свитч на позицию.
    + Просто, не требует почти никакой инфраструктуры.
    - Склонно к ошибками, масштабируется человеко-часами.
  2. Бумер+ - автоматизируем заведение устройства в DCIM/IPAM. Мы только нажимаем кнопочку, а в системе появляется железка на правильной локации со всеми нужными портами, ей выделяется автоматически имя и следующий свободный IP-адрес. В итоге генерируется базовый конфиг в виде текстового файлика.
    Администратор подключает свитч к компьютеру и через консольный порт копипастит содержимое этого файлика в терминал.
    + Ниже вероятность ошибок, значительно меньше ручной работы
    - Требуется уже какая-никакая инфраструктура: IPAM/DCIM с API, скрипт, всё ещё ручная работа, всё ещё настраивать на стенде и потом везти устройство на позицию.
  3. Миллениал - ZTP - Zero Touch Provisioning - подход, которому 100 лет в обед, но он почему-то всё ещё есть не везде. Идея в том, что устройство сразу же ставится на позицию и подключается в сеть управления, после чего по DHCP оно само получает свою конфигурацию.
    Для этого устройство должно быть уже заведено в IPAM/DCIM и предгенерирована конфигурация, которая и передаётся устройству.
    + Устройство можно сразу везти на позицию, минимум ручного труда
    - Нужна уже продуманная связная инфраструктура: IPAM/DCIM, DHCP, (T)FTP, автогенерация конфигов. Классическую вендорскую реализацию сложно применить для распределённых сетей, вроде ритейла.
  4. Зумеры - SD-WAN. Кстати, как раз подходит для ритейлов, хотя в свою очередь не очень для датацентров. Подход разделяет идею ZTP - мы устройство включаем, а оно само настраивается.
    + Меньше вероятность ошибок. На первый взгляд меньше работы
    - Однако SD-WAN - это преимущественно проприетарные решения вендоров, требующие мощной инфраструктуры, причём иногда только в облаке вендора. У нас, кстати, был целый подкаст про SD-WAN: telecom №91. SD-WAN.
  5. Пост-хипстеры - есть компании, где помимо Out of Band сети управления, есть ещё консольное соединение до абсолютно каждой железки. Для этого есть соответственно сеть консольных серверов внутри датацентров и точек присутствия.
    Каждое новое устройство после установки подключается отдельно в OOB-свитч по Ethernet и в консольный сервер консольным линком.
    Это позволяет реализовать схему, подобную описанной ниже:
    • Устройство добавляется в IPAM/DCIM
    • Устройство устанавливается и подключается по управлению
    • Инженер в ДЦ создаёт задачу на сервер наливки: настроить свитч за консольными сервером №7, порт 3
    • Сервер наливки подключается на указанный порт, забирает серийный номер, с которым идёт в IPAM, генерирует базовый конфиг и обратно через тот же консольный порт применяет данную конфигурацию
    + Всегда есть консольный доступ на устройство, какие бы шторма ни гуляли в сети трафика и управления. Нет проблем с вендорскими особенностями - консольный протокол у всех реализован одинаково (с поправкой на параметры порта)
    - Совсем непросто и в абсолютных цифрах недёшево реализовывать ещё одну сеть управления. Не подходит для географически распределённых сетей. Требуется серьёзная инфраструктура даже в минимальном варианте без использования сервера наливки.
Как видите, любые решения по автоматизации Day 0 требуют чего-то больше, чем просто скриптик на питоне. К этому процессу нужно подходить системно с точки зрения выстраивания инфраструктуры.
Кстати, вот классный доклад от фейсбука про их Вендинговые Машины по выдаче новых локаций: Scaling the Facebook backbone through Zero Touch Provisioning (ZTP)

Так или иначе эта часть автоматизирована у многих, потому что подходы понятны, инструменты в ассортименте.

Day 1

Дальше на железку нужно накатить уже рабочую конфигурацию и пустить на неё нагрузку.
Тут уже заметно интереснее. Одно дело - сгенерировать простейший конфиг на 20 строчек, одинаковый для всех типов устройств, как было в Day 0, и совсем другое - целевой конфиг на пару тысяч строк, который может радикально отличаться от железки к железке в зависимости от её роли и необходимых сервисов. Например, конфигурации двух экземпляров одной и той же модели свитча, установленных в качестве лифа и спайна, будут различаться как минимум настройками даунлинк интерфейсов.
Основная идея здесь в том, что мы описываем дизайн сети в том или ином формальном виде и отдаём его генераторам. Генераторы берут этот дизайн, роль устройства, локацию, переменные из IPAM/DCIM, всё это перемешивают, а на выходе получается специфический для данной коробки конфиг.
То есть основных компонента здесь три:
  • Формализованный дизайн
  • Заполненные данные в IPAM/DCIM
  • Набор генераторов
Здесь подробно останавливаться не будем - формализации дизайна я посвящу отдельный (и скорее всего не один) выпуск.
Итак, имеем конфиг Day1. Осталось всего ничего - применить его на железку.
И тут все средства хороши в разных комбинациях: консоль, SSH, netmiko, NETCONF, GNMI, REST API, SNMP (я сейчас не шучу - лично видел), FTP, SCP.
В целом на нерабочую пока железку применить конфиг действительно можно разными способами:
  • Ручной копипаст из файлика в терминал
  • Применение команд последовательно через SSH из кода, используя тот же netmiko
  • Копирование файла на флэшку устройства, установка его в качестве конфигурационного и ребут железки
  • А-ля config replace
  • Пульнуть через NETCONF весь конфиг в XML
  • gNMI

Об этом тоже ещё поговорим.

С автоматизацией этой задачи большинство тоже справляются - один раз настроить железку без нагрузки - дело нехитрое.

Замечу, что если есть процесс и инструменты Configuration Management и версионирования конфигурации, то Day1 - это лишь частный случай DayN.

Day N

И вот теперь - ежедневная эксплуатация и периодические реконфигурации.
А вот с этим дела обстоят туго чуть менее, чем у всех. Говоря это, я не шучу. Тут всё плохо.
Дело в том, что нагенерить конфигурацию - действительно несложно. Пусть это будет даже циклопический jinja-шаблон с циклами и каунтерами.

А вот применить этот конфиг на железку ещё и под продуктивной нагрузкой - цель для инженеров со стальными нервами.

Тут целый ком проблем, как очевидных, так и неявных.

Во-первых, интерфейс: CLI, NETCONF, GNMI, SCP/FTP.
Если CLI - то как быть с особенностями реализации каждого вендора? Режимы контекстов, интерактивные диалоги, порядок выполнения команд.
Если NETCONF или gNMI - то его не все вендоры поддерживают. А те, кто поддерживает, делают это сильно по-разному, и зачастую не в полной мере. А если в полной мере, то, конечно, же в своей схеме, а не в OpenConfig.
А если файлик подложить - то не все на лету умеют заменять, а значит с ребутом - только кому он нужен при добавлении BGP-пира?

Во-вторых, инструмент доставки: netmiko, ncclient, ansible (какой модуль), SaltStack?

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

В-четвёртых, даже если мы видим будущие изменения (кандидат-конфиг на самом устройстве, к примеру), то это не говорит о том, что мы ничего не разломаем по своей неосмотрительности. Тут уже напрашивается сетевой CI/CD.

В-пятых, весь ворох вопросов мультивендорной взрослой сети: разный синтаксис, семантика даже между версиями софта, где-то есть коммиты, где-то нет, где-то можно увидеть кандидат, где-то нет.

Это область компромиссов.

Но давайте будем честны сами с собой: восьми компаниям из десяти не нужен выстроенный процесс версионирования конфигурации, конвейер CI/CD, автоматическая выкатка, а возможно, и вообще весь этот ваш DevOps в сети.
Скорее всего, вам действительно достаточно залить первичный конфиг, а дальше изменения накатывать всю жизнь элементарными плейбуками, составленными вручную. И для этого, включая мониторинги и внутренние инструменты, достаточно 2-5 человек, а не целый штат разработчиков.
И большинство компаний именно так и делает.
Можно добавить GitLab, TeamCity, AWX, аппаратную лабораторию с набором специфических тестов (FIB, QoS). Это всё мощные улучшайзеры, которые сделают процесс выкатки новой конфигурации значительно безопаснее. Но они не переведут управление конфигурацией на принципиально новый уровень.
https://fs.linkmeup.ru/images/adsm/4/deploy.gif

А мы ведь всё же хотим

  • Полную автоматизацию
  • Универсальное решение
  • Минимизацию рутины
  • Безопасные выкатки конфигурации
  • Формализованный дизайн
  • Версионирование
  • Транзакционность, а если быть точнее, то соответствие требованиям ACID

Поэтому давайте составим схему системы автоматизации, которая позволит нам решить все задачи. Но прежде расширим понятие «Инфраструктура как код» на сетевую инфраструктуру.