Общий взгляд на жизненный цикл оборудования¶
Вот мы купили сетевую железку. Что теперь? Проследим её жизнь с первого и до последнего дня.
- Day 0 - железка только появилась в наших руках. Сейчас самое важное - базовая настройка:
- Добавить IP-адрес управления и маршрут
- Включить SSH
- Создать пользователя с правами настройки
Иными словами задача Day0 конфигурации - организовать доступ на устройство. - Day 1 - Железка уже встала на позицию, определена его роль в сети и сервисы, которые она обслуживает.Теперь нужно настроить уже целевую конфигурацию, с которой устройство встанет в сеть под нагрузку.
Day N - Изменения конфигурации в процессе эксплуатации. | Бывает мы добавляем новый сервис, пересматриваем дизайн или на худой конец нужно ACL поправить. | Такие изменения нужно тоже уметь довозить до устройства.
Обслуживание - Помимо нормальной работы есть периоды, когда устройство нужно аккуратно вывести из под нагрузки, чтобы, например, поменять в нём плату, провести обновление ПО.
Отслеживание изменений - со всей сети следует собирать информацию о том, где и во сколько применялась новая конфигурация. Это позволит как скоррелировать жалобы клиентов с изменениями, так и знать, когда применялась новая конфигурация в обход процедуры.
Проверка соответствия эталонной конфигурации** - В течение всей жизни устройства нужно проверять, что его конфигурация не разошлась с целевой из-за сбоев в автоматике, обновлений ПО или прямого вмешательства чьих-то рук.
Бэкапы - Даже если мы в любой момент можем сгенерировать эталонную конфигурацию, чтобы применить её на устройство, бэкапы необходимы.
The Last Day - снятие нагрузки, удаление из всех систем, ритуальное сжигание. Под сжиганием я понимаю безопасную затирку конфигурации, чтобы хэши паролей (или, упаси Лейбниц, клиртекст), префикс-листы и ACL’и не оказались достоянием общественности.
Я намеренно обхожу вниманием в этой статье вопрос мониторингов операционного состояния и реакции на них, поскольку её лейтмотив - это всё же конфигурация.
Далее обсудим Day0 - DayN более детально.
Day0¶
Итак, поставщик привёз на склад новый свитч. Его нужно установить, настроить, проверить, запустить трафик, добавить во все системы: инвентарные, мониторинги, бэкапы, скрипты автоматизации всякой рутины.
Задачи Day 0 можно грубо разделить на две части:
- Завести устройство в системах
- Настроить базовый доступ
Говорить про них в отрыве друг от друга сложно, и делать мы так не будем.
Какие же есть способы?
- Бумер - вручную завести устройство в инвентарной системе и выделить свободный IP-адрес. Пусть это будет даже экселька.Подключить свитч к компьютеру и через консольный порт настроить IP-адрес, маршрут, включить SSH, создать пользователя.Отвезти свитч на позицию.+ Просто, не требует почти никакой инфраструктуры.- Склонно к ошибками, масштабируется человеко-часами.
- Бумер+ - автоматизируем заведение устройства в DCIM/IPAM. Мы только нажимаем кнопочку, а в системе появляется железка на правильной локации со всеми нужными портами, ей выделяется автоматически имя и следующий свободный IP-адрес. В итоге генерируется базовый конфиг в виде текстового файлика.Администратор подключает свитч к компьютеру и через консольный порт копипастит содержимое этого файлика в терминал.+ Ниже вероятность ошибок, значительно меньше ручной работы- Требуется уже какая-никакая инфраструктура: IPAM/DCIM с API, скрипт, всё ещё ручная работа, всё ещё настраивать на стенде и потом везти устройство на позицию.
- Миллениал - ZTP - Zero Touch Provisioning - подход, которому 100 лет в обед, но он почему-то всё ещё есть не везде. Идея в том, что устройство сразу же ставится на позицию и подключается в сеть управления, после чего по DHCP оно само получает свою конфигурацию.Для этого устройство должно быть уже заведено в IPAM/DCIM и предгенерирована конфигурация, которая и передаётся устройству.+ Устройство можно сразу везти на позицию, минимум ручного труда- Нужна уже продуманная связная инфраструктура: IPAM/DCIM, DHCP, (T)FTP, автогенерация конфигов. Классическую вендорскую реализацию сложно применить для распределённых сетей, вроде ритейла.
- Зумеры - SD-WAN. Кстати, как раз подходит для ритейлов, хотя в свою очередь не очень для датацентров. Подход разделяет идею ZTP - мы устройство включаем, а оно само настраивается.+ Меньше вероятность ошибок. На первый взгляд меньше работы- Однако SD-WAN - это преимущественно проприетарные решения вендоров, требующие мощной инфраструктуры, причём иногда только в облаке вендора. У нас, кстати, был целый подкаст про SD-WAN: telecom №91. SD-WAN.
- Пост-хипстеры - есть компании, где помимо Out of Band сети управления, есть ещё консольное соединение до абсолютно каждой железки. Для этого есть соответственно сеть консольных серверов внутри датацентров и точек присутствия.Каждое новое устройство после установки подключается отдельно в OOB-свитч по Ethernet и в консольный сервер консольным линком.Это позволяет реализовать схему, подобную описанной ниже:
- Устройство добавляется в IPAM/DCIM
- Устройство устанавливается и подключается по управлению
- Инженер в ДЦ создаёт задачу на сервер наливки: настроить свитч за консольными сервером №7, порт 3
- Сервер наливки подключается на указанный порт, забирает серийный номер, с которым идёт в IPAM, генерирует базовый конфиг и обратно через тот же консольный порт применяет данную конфигурацию
+ Всегда есть консольный доступ на устройство, какие бы шторма ни гуляли в сети трафика и управления. Нет проблем с вендорскими особенностями - консольный протокол у всех реализован одинаково (с поправкой на параметры порта)- Совсем непросто и в абсолютных цифрах недёшево реализовывать ещё одну сеть управления. Не подходит для географически распределённых сетей. Требуется серьёзная инфраструктура даже в минимальном варианте без использования сервера наливки.
Так или иначе эта часть автоматизирована у многих, потому что подходы понятны, инструменты в ассортименте.
Day 1¶
- Формализованный дизайн
- Заполненные данные в IPAM/DCIM
- Набор генераторов
- Ручной копипаст из файлика в терминал
- Применение команд последовательно через SSH из кода, используя тот же netmiko
- Копирование файла на флэшку устройства, установка его в качестве конфигурационного и ребут железки
- А-ля config replace
- Пульнуть через NETCONF весь конфиг в XML
- gNMI
Об этом тоже ещё поговорим.
С автоматизацией этой задачи большинство тоже справляются - один раз настроить железку без нагрузки - дело нехитрое.
Замечу, что если есть процесс и инструменты Configuration Management и версионирования конфигурации, то Day1 - это лишь частный случай DayN.
Day N¶
А вот применить этот конфиг на железку ещё и под продуктивной нагрузкой - цель для инженеров со стальными нервами.
Тут целый ком проблем, как очевидных, так и неявных.
Во-вторых, инструмент доставки: netmiko, ncclient, ansible (какой модуль), SaltStack?
В-третьих, как заливать вслепую? Отправляя полную конфигурацию, мы не знаем, как она изменит состояние устройства. Даже если мы видим дифф между файлами или в ветке в гите, это не говорит о том, какие команды фактически применятся на железке.
В-четвёртых, даже если мы видим будущие изменения (кандидат-конфиг на самом устройстве, к примеру), то это не говорит о том, что мы ничего не разломаем по своей неосмотрительности. Тут уже напрашивается сетевой CI/CD.
В-пятых, весь ворох вопросов мультивендорной взрослой сети: разный синтаксис, семантика даже между версиями софта, где-то есть коммиты, где-то нет, где-то можно увидеть кандидат, где-то нет.
Это область компромиссов.
А мы ведь всё же хотим
- Полную автоматизацию
- Универсальное решение
- Минимизацию рутины
- Безопасные выкатки конфигурации
- Формализованный дизайн
- Версионирование
- Транзакционность, а если быть точнее, то соответствие требованиям ACID
Поэтому давайте составим схему системы автоматизации, которая позволит нам решить все задачи. Но прежде расширим понятие «Инфраструктура как код» на сетевую инфраструктуру.