9. Сеть#

Автоматизация VLAN три недели работала в лаборатории. Три коммутатора, по одному каждого вендора, все рабочие процессы проходят. Команда была уверена в результате. На первом production-прогоне 23 из 800 коммутаторов кампуса дали сбой. Все HPE. Все работающие на версии прошивки, которую никто не задокументировал.

Плейбук проверял ответ об ошибке от каждого устройства после отправки конфигурации VLAN. На современной прошивке HPE уже существующий VLAN возвращает код ошибки duplicate-vlan. На этой старой версии прошивки то же условие возвращало vlan-exists. Плейбук был написан так, чтобы обрабатывать duplicate-vlan как сигнал идемпотентности, означающий “это уже существует, всё в порядке”. Он не был написан для обработки vlan-exists, поэтому воспринимал этот ответ как сбой. Треть парка HPE сообщила об ошибке. Откат выполнился чисто. Тикет прикладной команды оставался открытым ещё три часа, пока сетевая команда вручную проверяла, какие коммутаторы были реально настроены, а какие нет.

Автоматизация была правильной. У сети было мнение, которое никто не задокументировал.

Шесть месяцев спустя та же команда имела топологию containerlab, отражающую корпус B: 24 коммутатора, соответствующие образы вендоров, с узлами HPE, закреплёнными на версии production-прошивки, записанной в Source of Truth (SoT). На первом тестовом прогоне рабочего процесса VLAN против этой топологии 8 узлов HPE дали сбой ровно с тем кодом ошибки. Команда добавила vlan-exists в список идемпотентных ответов в адаптере HPE. Повторный запуск: все 24 узла прошли. Развёртывание в production: 800 коммутаторов, ноль сбоев.

Разница была не в лучшем коде. Это была тестовая среда, отражающая реальность.

Эта глава рассматривает блок, который всегда был неявным на протяжении всей Части 2: саму сеть. Каждый созданный ранее строительный блок был спроектирован командой автоматизации и ведёт себя согласно задокументированным интерфейсам. Сеть была унаследована. У неё есть особенности, разнообразные интерфейсы, несоответствия прошивок и возможности, варьирующиеся в зависимости от вендора, платформы и поколения программного обеспечения. Глава 9 отвечает на два вопроса: что нам нужно от сети, чтобы автоматизация была надёжной, и как безопасно проверить логику автоматизации до того, как она затронет production?

9.1. Основы#

9.1.1. Контекст#

Глава 3 представила Сеть как один из семи блоков NAF Framework: единственный блок, которым команда автоматизации не “владеет” (он находится в сфере ответственности сетевой инженерии). Они настраивают её, наблюдают за ней и моделируют её намерение, но они не создавали операционную систему, модель данных или интерфейс API. Эта зависимость определяет каждое проектное решение на платформе выше.

Глава 5 подробно рассматривала путь записи Executor: как работают роли автоматизации, параметризованные задачи и проверки идемпотентности. То, что Глава 5 принимает как данность - что устройство на другом конце предоставляет надёжный, согласованный интерфейс. Глава 9 рассматривает, выполняется ли это предположение, и что делать, если нет.

Глава 6 рассматривала путь чтения Collector: потоковую телеметрию gRPC Network Management Interface (gNMI), опрос SNMP и конвейер нормализации данных. Глава 9 охватывает предварительные условия на стороне устройства для этих путей: что должно быть верно в отношении сетевого устройства, чтобы сборщик мог стабильно читать из него.

Глава 9 завершает Часть 2. Предыдущие шесть глав создали платформу автоматизации: место для хранения намерения, способ его выполнения, способ наблюдения за результатами, движок для координации всего и поверхности для предоставления доступа потребителям. Эта глава рассматривает то, на что платформа всегда была направлена.

9.1.2. Цели#

Три цели определяют вклад блока Сети в платформу автоматизации:

1. Понимать весь спектр сетевой инфраструктуры и работать с ним. Любая крупномасштабная платформа автоматизации может одновременно взаимодействовать с коммутаторами кампуса, фабриками центров обработки данных, облачными VPC, наложенными сетями Kubernetes, контроллерами оверлея и унаследованным оборудованием. Каждый тип предоставляет разные программируемые интерфейсы. Платформа должна обрабатывать их все, не сводясь к единственной абстракции наименьшего общего знаменателя.

2. Проверять логику автоматизации и поддерживать проектирование новых сетевых архитектур до воздействия на production. Среды моделирования служат двум целям: они являются предварительным шлюзом перед production, где логические ошибки, нарушения контракта интерфейса и специфические особенности устройств выявляются ценой минут в лаборатории, а не часов в production-инциденте, и они являются средой проектирования, где новые сетевые архитектуры исследуются и проверяются до заказа какого-либо оборудования.

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

9.1.3. Столпы#

Три столпа поддерживают эти цели, по одному на каждую функцию:

1. Спектр сетевой инфраструктуры и программируемые интерфейсы: полный диапазон типов сетей, которые должна автоматизировать платформа, и интерфейс, который каждый тип предоставляет исполнителю и сборщику.
2. Среды моделирования и тестирования: инструментарий для предварительной проверки перед production. Где применяются разные типы лабораторных сред, как они связаны с паттерном Saga из Главы 7, и как их масштабировать.
3. Стратегии абстракции: структурные подходы, позволяющие платформе автоматизации оставаться стабильной по мере изменения базовой сети, независимо от вендора, поколения платформы или протокола интерфейса.

9.1.4. Область применения#

В области применения:

• Интерфейсы, через которые исполнитель и сборщик достигают сетевых устройств. Оба NETCONF и gNMI поддерживают операции конфигурации и телеметрии; выбор между ними для каждого случая использования зависит от операционных преимуществ, а не от исключительности протокола. Протокол часто общий для блоков; тип операции отличается.
• Среды тестирования и методологии, проверяющие автоматизацию перед production
• Стратегии абстракции для управления гетерогенностью нескольких вендоров и платформ
• Последствия облачных, Kubernetes и наложенных сетей для проектирования автоматизации

Вне области применения:

• Генерация конфигурации и рендеринг шаблонов (Source of Truth (SoT), Глава 4)
• Механика выполнения: как инструментарий автоматизации выполняет задачу (исполнитель, Глава 5)
• Конвейер сбора телеметрии: как метрики поступают в базу данных временных рядов (Observability, Глава 6)

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

9.2. Функции#

Блок Сети - единственный строительный блок фреймворка NAF, который платформа автоматизации не контролирует. Она может только взаимодействовать с сетью так, как сеть это позволяет. Каждое проектное решение в предыдущих пяти главах - как хранится намерение, как выполняется исполнение, как собирается телеметрия, как координируются рабочие процессы, как обслуживаются потребители - в конечном счёте сводится к вопросу о том, что поддерживает сетевое устройство на другом конце соединения. Эта глава напрямую рассматривает это ограничение.

graph LR

    subgraph Goals
        direction TB
        A1[Navigate the full network infrastructure spectrum]
        A2[Validate automation before production]
        A3[Keep the platform stable as the network evolves]
    end

    subgraph Pillars
        direction TB
        B1[Network infrastructure spectrum and programmable interfaces]
        B2[Simulation and testing environments]
        B3[Abstraction strategies]
    end

    subgraph Functionalities
        direction TB
        C1[Programmable Interfaces]
        C2[Simulation and Testing Environments]
        C3[Abstraction Strategies]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;

9.2.1. Программируемые интерфейсы#

Сеть по своей природе гетерогенна. Это не одна вещь. Это спектр типов инфраструктуры, накопленных за годы, зачастую создававшихся параллельно разными командами (владение и организационные границы рассматриваются в Главе 13), каждый со своей моделью интерфейса, уровнем абстракции и зрелостью автоматизации. Современная платформа автоматизации может одновременно охватывать коммутаторы кампуса, фабрики центров обработки данных, облачные VPC, контроллеры оверлея, кластеры Kubernetes, WAN-инфраструктуру сервис-провайдеров и гиперскейлерские управляемые плоскости пересылки. Платформа должна справляться со всеми ними. Тип инфраструктуры определяет доступный интерфейс; платформа автоматизации адаптируется к этой реальности, а не требует единого интерфейса.

9.2.1.1. Спектр сетевой инфраструктуры#

Это краткое изложение различных сценариев сетевой инфраструктуры, с которыми, возможно, придётся столкнуться в зависимости от характера вашей компании:

• Коммутация кампуса и филиалов - базовый сценарий, использованный в качестве примера на протяжении всей Части 2: физические коммутаторы нескольких вендоров (Cisco, Arista, HPE, Extreme). Современное оборудование кампуса одновременно предоставляет Command Line Interface (CLI), NETCONF и gRPC Network Management Interface (gNMI). Зрелость автоматизации высока для оборудования последних пяти-семи лет; она неоднородна для унаследованного оборудования, всё ещё работающего на прошивках десятилетней давности.

• Фабрика центра обработки данных обычно имеет топологию “лист-хребет”, часто от меньшего набора вендоров: Arista, Cisco Nexus или платформы открытых сетей, ориентированные на автоматизацию. Унификация интерфейсов выше, чем в кампусе; управление изменениями строже. Оверлеи EVPN/VXLAN добавляют плоскость управления над фабрикой, у которой может быть собственный API, отдельный от интерфейса отдельного устройства. Платформы на базе SONiC (Cisco 8000, Nvidia Spectrum) всё активнее присутствуют в развёртываниях ЦОД под влиянием гиперскейлеров; их интерфейс конфигурации представляет собой структурированную базу данных, а не CLI или NETCONF, и рассматривается далее в разделе стратегий абстракции.

• Инфраструктура сервис-провайдера и WAN (операторские маршрутизаторы, MPLS-сети, фабрики сегментной маршрутизации) имеет собственные задачи автоматизации: масштаб, сложность протоколов и двойная задача конфигурации плоскости управления и политики трафик-инжиниринга. NETCONF и модели YANG хорошо зарекомендовали себя в этой области; вендоры, такие как Cisco IOS-XR и Junos, имеют зрелое покрытие YANG. Платформа автоматизации часто нацелена на контроллер (SR-PCE, Crosswork, NSO), а не на отдельные устройства.

• Облачные сети: AWS VPC, Azure VNet, GCP VPC и другие. REST API с семантикой eventual consistency. Нет концепции “отправить конфиг” и ждать синхронного подтверждения. Исполнитель обрабатывает асинхронные операции: создать, опросить, проверить. Инструментарий инфраструктуры как кода подходит для этой модели естественно. Платформа автоматизации должна учитывать другую модель согласованности, а не предполагать синхронную семантику применения и подтверждения.

• SD-WAN и наложенные сети (Cisco SD-WAN, Versa, VMware VeloCloud) управляются контроллером. Цель автоматизации - API контроллера, а не отдельное устройство. Физический underlay по-прежнему существует, но управляется полностью через абстракцию оверлея. Это влияет как на исполнение, так и на наблюдаемость: исполнитель записывает политику в контроллер; телеметрия о трафике, выборе пути и применении политики также поступает через северный интерфейс контроллера, а не непосредственно с устройств физического underlay.

• Сети Kubernetes на уровне CNI полностью меняют модель устройства. Сеть определяется через объекты Kubernetes API: NetworkPolicy, Services, Ingress и пользовательские ресурсы от CNI-плагинов, таких как Cilium, Calico или Flannel. Устройство исчезает как цель автоматизации. Kubernetes API является интерфейсом. Сетевые политики - это код, а не конфигурация устройства. Это модель, к которой сходятся остальные: декларативное намерение, состояние, согласованное контроллером, без прямого доступа к устройству.

• DPU и SmartNIC (Nvidia BlueField, Intel IPU, Marvell Octeon) представляют собой сдвиг в том, где происходит сетевая обработка. В современных центрах обработки данных DPU устанавливаются рядом с CPU на каждом сервере для выгрузки сетевых функций: инкапсуляция VXLAN, шифрование, применение политик межсетевого экрана, балансировка нагрузки и микросегментация. Это разгружает от этих функций хостовый CPU и сетевые устройства в пользу прошивки SmartNIC. Следствие для автоматизации: “сетевое устройство” больше не только коммутатор или маршрутизатор в стойке. Функции, ранее управлявшиеся через специализированные API сетевых устройств, теперь управляются через плоскость управления DPU и её вендорский SDK - новую категорию интерфейса, которую стандартный инструментарий NETCONF и gRPC Network Management Interface (gNMI) пока ещё не охватывает чисто.

• Открытые сети (SONiC, DENT, OPX) работают на программном обеспечении Network Operating System (NOS) на серийном оборудовании. Интерфейс конфигурации SONiC представляет собой базу данных Redis со структурированной Yet Another Next Generation (YANG) схемой, структурно отличающейся от CLI или NETCONF, и по замыслу программируемой. Всё активнее присутствует в центрах обработки данных предприятий, находящихся под влиянием гиперскейлеров, и в крупномасштабных корпоративных развёртываниях ЦОД. SONiC примечателен тем, что был разработан для автоматизации с самого начала: интерфейс представляет собой структурированную базу данных, а не CLI, адаптированный для программного доступа.

• Виртуальные сетевые функции сосуществуют с физической инфраструктурой во многих средах. Программный межсетевой экран, вставляющий трафик через пути, определённые политикой, виртуальный балансировщик нагрузки, управляющий распределением трафика по кластерам приложений, программный BGP-рефлектор маршрутов - всё это цели автоматизации, использующие интерфейсы управления от вендорских REST API до NETCONF. Они часто управляются вместе с физическим инвентарём, используя те же источник истины и исполнитель, но требуют отдельных адаптерных путей, поскольку их модели интерфейсов отличаются от физических устройств.

• Беспроводные контроллеры (Cisco DNA, Aruba Central, Juniper Mist) основаны на контроллере; цель автоматизации - API контроллера. Актуально всякий раз, когда подготовка VLAN распространяется на беспроводные SSID наряду с проводными портами коммутатора, как это было бы в сценарии кампуса.

Смысл не в исчерпывающем перечислении каждого типа инфраструктуры. Цель - установить, что платформа, автоматизирующая любую нетривиальную сеть, одновременно взаимодействует с несколькими типами. Исполнитель и сборщик должны направлять каждую операцию к правильному типу интерфейса. Source of Truth (SoT) должен моделировать намерение на уровне выше отдельного интерфейса. Сложность сети является проектным ограничением, для поглощения которого была создана платформа.

9.2.1.2. Типы интерфейсов#

Каждый тип инфраструктуры предоставляет платформе автоматизации один или несколько типов интерфейсов. Один и тот же физический коммутатор может одновременно предоставлять все три. Платформа адаптируется к тому, что доступно, с предпочтениями, отражающими надёжность, структурированность и масштабируемость. Ни один тип интерфейса не является универсальным мандатом; правильный выбор зависит от того, что поддерживает устройство и что требует операция.

• Command Line Interface (CLI) через Secure Shell (SSH) универсален, унаследован и ненадёжен. Экранный скрейпинг и разбор текста ломаются, когда прошивка меняет форматирование вывода или добавляет новые поля. Коды ошибок непоследовательны между вендорами и версиями прошивок. CLI по-прежнему является единственным вариантом для старого оборудования. Рекомендация - минимизировать его использование и избегать создания рабочих процессов, зависящих от него для чего-либо большего, чем устройства, у которых нет альтернативы (крайняя мера). Задание описания интерфейса выглядит так:

interface GigabitEthernet0/1
 description uplink-to-core

• NETCONF структурирован, транзакционен и корректен, когда работает. Он поддерживает атомарные операции и откат, а его модель данных поддаётся машинному анализу. Транспортный уровень обычно надёжен; уровень модели данных - там, где находятся пробелы. Качество моделей YANG вендоров значительно варьируется: устройство может заявлять о поддержке NETCONF, но иметь неполные или собственные модели для функций, которые нужны платформе. Модели YANG от IETF и OpenConfig стандартизируют уровень намерения; модели YANG вендоров заполняют пробелы. То же описание интерфейса через NETCONF:

<config>
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name>GigabitEthernet0/1</name>
      <description>uplink-to-core</description>
    </interface>
  </interfaces>
</config>

• RESTCONF является HTTP-эквивалентом NETCONF, использующим те же модели YANG, но предоставленным через семантику REST. Полезен, когда команды более удобны в работе с HTTP-инструментарием, чем с транспортом XML/SSH NETCONF. Модель данных та же; отличается только транспорт. Поддержка вендоров менее однородна, чем у NETCONF. То же описание интерфейса через RESTCONF:

PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F1
Content-Type: application/yang-data+json

{
  "ietf-interfaces:interface": {
    "name": "GigabitEthernet0/1",
    "description": "uplink-to-core"
  }
}

• gRPC Network Management Interface (gNMI) и gNOI - протоколы на основе gRPC Remote Procedure Call (gRPC). gRPC Network Management Interface (gNMI) обрабатывает чтение/запись телеметрии и конфигурации; gNOI обрабатывает операционные команды. Современны и удобны для масштабирования. Поддержка вендоров зрела на Arista и новых платформах Cisco; неоднородна на HPE и унаследованном оборудовании. Глава 6 рассматривала gNMI с точки зрения сборщика. Глава 9 охватывает предварительные условия на стороне устройства: устройство должно поддерживать подписки gNMI на версии ОС, на которую нацелена платформа. Коммутаторы Nvidia Spectrum под управлением SONiC предоставляют gNMI нативно наряду с интерфейсом CONFIG_DB, делая их одними из наиболее дружелюбных к автоматизации платформ как для конфигурации, так и для телеметрии. То же описание интерфейса через gNMI SetRequest:

path:  /interfaces/interface[name=GigabitEthernet0/1]/config/description
value: "uplink-to-core"

• Вендорские REST API (eAPI, NX-API, Cumulus NVUE и аналогичные) читаемы машиной, но не стандартизированы между вендорами. Полезны как заменители, когда NETCONF или gNMI отсутствуют или неполны для конкретной операции. Коммутаторы Nvidia Cumulus предоставляют NVUE (структурированный REST API с согласованной схемой JSON) в качестве основного программного интерфейса; Arista и Cisco Nexus предоставляют eAPI и NX-API соответственно как альтернативы NETCONF. Относитесь к ним как к задачам адаптерного уровня, а не как к фундаменту для платформы, не привязанной к вендору. То же описание интерфейса через Arista eAPI (JSON-RPC через HTTPS):

{
  "jsonrpc": "2.0",
  "method": "runCmds",
  "params": {
    "version": 1,
    "cmds": [
      "interface GigabitEthernet0/1",
      "description uplink-to-core"
    ],
    "format": "json"
  },
  "id": "1"
}

• Облачные и контроллерные API следуют паттернам REST с eventual consistency. Асинхронная модель операций является требованием к проектированию, а не ограничением для обхода. Для SD-WAN, беспроводных и плоскостей управления DPU контроллерный API часто является единственным доступным интерфейсом. Добавление описания к AWS VPC иллюстрирует паттерн: обновление тегированного ресурса, отправляемое асинхронно, без синхронного подтверждения применения изменения:

POST https://ec2.eu-west-1.amazonaws.com/ HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AWS4-HMAC-SHA256 ...

Action=CreateTags
&ResourceId.1=vpc-0a1b2c3d4e5f67890
&Tag.1.Key=Description
&Tag.1.Value=uplink-to-core
&Version=2016-11-15

• Kubernetes API декларативен, согласован контроллером и одинаков у всех вендоров. NetworkPolicy, Services и пользовательские ресурсы CNI являются целями автоматизации. Нет прямого доступа к устройству; API-сервер является единственным интерфейсом. Политика изоляции сети для сервиса app-payments:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: app-payments-isolation
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: app-payments
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: app-payments

• SONiC CONFIG_DB (Redis) является нативным интерфейсом для платформ на базе SONiC. Это не протокол, наложенный поверх ОС, а собственное хранилище конфигурации ОС: база данных Redis со структурированной схемой YANG. Автоматизация записывает записи JSON непосредственно в CONFIG_DB; внутренний демон SONiC orchagent согласовывает намерение с таблицами пересылки оборудования. gNMI доступен параллельно для чтения телеметрии. Это архитектурно отличается от CLI, NETCONF или REST: интерфейс является самим хранилищем данных. Раздел 9.2.3.4 рассматривает это подробнее. То же описание интерфейса, записанное в CONFIG_DB через JSON-патч (применяется с помощью config load):

{
  "PORT": {
    "Ethernet0": {
      "description": "uplink-to-core",
      "admin_status": "up"
    }
  }
}

9.2.1.3. Выбор интерфейса для каждого устройства#

Когда устройство предоставляет несколько интерфейсов, платформа должна выбрать один для каждого типа операции и последовательно придерживаться этого выбора. Коммутатор кампуса, одновременно предоставляющий Command Line Interface (CLI), NETCONF и gRPC Network Management Interface (gNMI), требует принятия решения, а не подхода “смешать и подобрать”, меняющегося от рабочего процесса к рабочему процессу или от инженера к инженеру.

Рекомендуемая иерархия, применяемая для каждого типа операции. Оба gRPC Network Management Interface (gNMI) и NETCONF поддерживают запись конфигурации и чтение телеметрии; приоритет ниже отражает операционные преимущества, а не эксклюзивность протокола:

• gRPC Network Management Interface (gNMI) предпочтителен для сбора телеметрии (потоковые подписки, структурированные, удобные для масштабирования; gNMI Set также является действительным путём конфигурации)
• NETCONF предпочтителен для конфигурации (транзакционный, с возможностью отката; NETCONF get и get-config одинаково действительны для чтения состояния)
• RESTCONF или вендорский REST API как запасной вариант, когда NETCONF неполный для конкретной функции
• Command Line Interface (CLI) как крайняя мера только для унаследованного оборудования

Что нужно исполнителю от интерфейса: Идемпотентность или хотя бы надёжные коды ошибок, различающие “уже существует” от “сбой”, структурированные ответы об ошибках и возможность верификации состояния после применения. Проблема HPE vlan-exists vs duplicate-vlan была именно сбоем второго условия: семантика кода ошибки изменилась между версиями прошивки.

Что нужно сборщику: структурированное чтение, подписки на потоковую телеметрию и согласованные модели данных, чтобы уровню наблюдаемости не требовались парсеры для каждого устройства. gRPC Network Management Interface (gNMI) является предпочтительным протоколом подписки там, где он поддерживается: он структурирован, иерархичен и имеет валидацию схемы на устройстве, что устраняет текстовый разбор для каждого устройства, доминировавший в сборе эпохи SNMP. Но любой механизм подписки, доставляющий структурированные, своевременные данные, выполняет ту же функцию. Опрос SNMP остаётся действительным для унаследованных устройств, где gNMI недоступен. Syslog предоставляет структурированные события для наблюдаемости на основе журналов. OpenTelemetry (OTel) - это развивающийся стандарт, заслуживающий внимания: изначально разработанный для наблюдаемости приложений, он завоёвывает признание как вендорно-нейтральный транспорт для сетевой телеметрии, метрик и трасс. Выбор протокола сборщика является функцией того, что поддерживает устройство; уровень наблюдаемости не должен знать, какой транспорт использовался.

Source of Truth (SoT) записывает предполагаемое состояние для каждого атрибута устройства, которым управляет платформа: предполагаемая конфигурация VLAN, предполагаемые отношения соседства BGP, предполагаемые описания интерфейсов и предполагаемая версия ОС. Версия ОС заслуживает особого упоминания, поскольку влияет не только на обнаружение дрейфа конфигурации, но и на выбор адаптерного пути: исполнитель ветвится по версии ОС, когда прошивка одного и того же вендора ведёт себя по-разному между выпусками. Это не особый случай для версии ОС; это тот же паттерн намерение-против-реальности, применяемый к каждому атрибуту, которым управляет платформа. Желаемая версия ОС - то, что утвердила операционная команда; работающая версия - то, что наблюдает наблюдаемость. Когда они расходятся, это расхождение является сигналом: устройство может отставать от запланированного обновления, или произошло незапланированное изменение. Платформе нужны оба элемента данных, чтобы решить, продолжать ли выполнение или заблокировать его.

Это различие имеет практическое значение. Источник истины говорит, что устройство должно работать на AOS-CX 10.13. Сборщик сообщает, что оно работает на 10.12.1006. У платформы есть два варианта: заблокировать выполнение до согласования версии ОС или продолжить, используя адаптерный путь 10.12. Правильный ответ зависит от политики управления изменениями команды, но платформе нужны оба элемента данных для принятия решения. Источник истины предоставляет намерение; наблюдаемость предоставляет реальность.

9.2.2. Среды моделирования и тестирования#

Сеть является production-инфраструктурой. В отличие от серверного приложения, здесь нет промежуточного сервера для тестирования по умолчанию. Построить его - задача данной функции.

Тестирование сетевой автоматизации всегда было сложнее, чем тестирование кода приложений. Сеть - это распределённая система со многими компонентами, которые команда автоматизации не контролирует: соседние автономные системы в точках пиринга, вышестоящие транзитные провайдеры, CPE под управлением клиентов, беспроводные клиенты и облачная инфраструктура, эксплуатируемая третьими сторонами. Сервис-провайдер, тестирующий изменение политики маршрутизации, не может поднять mock BGP-пир от транзитного провайдера для проверки полного поведения. Предприятие, тестирующее рабочий процесс аварийного переключения WAN, не может контролировать поведение MPLS-провайдера. Описанные в этом разделе среды моделирования являются лучшим доступным заменителем: они воспроизводят то, что контролирует команда, принимают ограничения того, что они не могут, и фокусируют проверку на уровне логики, где реально живут ошибки.

Пирамида тестирования из Главы 2 (модульные, интеграционные, сквозные тесты) напрямую применима здесь. Модульные тесты проверяют отдельные модули автоматизации изолированно, обычно с mock-ответами устройств. Интеграционные тесты проверяют многошаговые взаимодействия: API источника истины возвращает ожидаемую структуру данных, исполнитель правильно её преобразует, ответ устройства обрабатывается правильно. Сквозные тесты проверяют полный рабочий процесс против чего-то, ведущего себя как реальное сетевое устройство. Среды моделирования являются слоем сквозного тестирования.

9.2.2.1. Типы сред#

Правильная среда зависит от того, что нужно проверить тесту. Существует спектр от сред с низкой точностью и низкой стоимостью, подходящих для рутинных конвейеров CI/CD, до сред с высокой точностью, в которые стоит инвестировать для тестирования с production-уверенностью.

• Эмуляция на основе контейнеров использует лёгкие образы сетевых ОС, работающих как контейнеры, соединённых виртуальными линками. Запуск топологии занимает секунды. Это практический стандарт по умолчанию для рутинного CI/CD: команда автоматизации запускает тот же код рабочего процесса против контейнеризированной топологии при каждом изменении, выявляя логические ошибки до production. Поведение плоскости данных не воспроизводится, но поведение плоскости управления и поведение интерфейса управления достаточны для тестирования логики автоматизации.

• Эмуляция на основе VM запускает полные образы NOS в виде виртуальных машин. Она обеспечивает более широкое покрытие вендоров, более реалистичное поведение NOS, включая плоскость данных, и подходит для тестирования протокольного дизайна и сценариев совместимости нескольких вендоров. Компромисс: более высокие ресурсные затраты, медленный запуск и ограниченная интеграция с автоматизированными конвейерами. Нецелесообразно для рутинного тестирования на уровне коммитов.

• Физические аппаратные лаборатории поддерживаются многими крупными организациями: стойка настоящих коммутаторов и маршрутизаторов, часто отражающих архитектурные паттерны production. Это обеспечивает максимальную точность для аппаратно-специфических поведений, тестирования производительности и сценариев, где эмуляция не воспроизводит поведение устройства точно. Стоимость значительна: капиталовложения, потребление электроэнергии и пространства, и операционные накладные расходы на синхронизацию топологии лаборатории с производственной архитектурой. Лаборатории, отстающие от production-паттернов, дают ложную уверенность. Ценность реальна; проблема - поддерживающая дисциплина.

• Цифровые двойники - живые реплики production-топологии, питаемые источником истины (те же модели устройств, топология и текущая предполагаемая конфигурация) и текущим состоянием из наблюдаемости. Цифровой двойник отражает то, как production выглядит прямо сейчас, а не приближение. Операционная стоимость значительна: поддержание синхронизации между цифровым двойником и production требует непрерывного согласования. Это инвестиция уровня зрелости, подходящая для команд, уже проверивших свою платформу в масштабе и нуждающихся в наивысшем уровне pre-production уверенности.

Эмуляция на основе контейнеров является практической отправной точкой для большинства команд. Запускается за секунды, нативно интегрируется с конвейерами CI/CD и охватывает современное оборудование кампуса и центра обработки данных, используемое в большинстве случаев применения автоматизации. Инвестиции в создание этой среды окупаются на первом же инциденте, который она предотвращает.

9.2.2.2. Инструментарий для эмуляции на основе контейнеров и VM#

Экосистема на основе контейнеров имеет несколько инструментов с различными ролями, которые часто путают:

• containerlab создаёт и соединяет образы сетевых ОС на основе контейнеров. Созданный Романом Додиным и широко принятый сообществом сетевой автоматизации, containerlab стал де-факто стандартом для сетевых лабораторий на основе контейнеров. Он напрямую оркестрирует Docker-контейнеры (Arista cEOS, FRR, SONiC, VyOS и другие) и соединяет их виртуальными линками, определёнными в файле топологии. containerlab запускает топологию и предоставляет работающую лабораторию за секунды. Минимальный файл топологии для трёх узлов выглядит так:

  По мере масштабирования команд запуск containerlab на одной машине становится узким местом. clabernetes распределяет топологии containerlab по кластеру Kubernetes, позволяя выполнять несколько прогонов моделирования параллельно и давая командам возможность масштабировать свой pre-production шлюз по мере роста платформы.

name: building-b-sim
topology:
  nodes:
    cisco-1:
      kind: ceos
      image: ceos:17.9.4
    arista-1:
      kind: ceos
      image: ceos:4.31.2F
    hpe-1:
      kind: vr-aoscx
      image: vrnetlab/vr-aoscx:10.12.1006
  links:
    - endpoints: ["cisco-1:eth1", "arista-1:eth1"]
    - endpoints: ["arista-1:eth2", "hpe-1:eth1"]

• netlab абстрагирует определение топологии над containerlab. Созданный Иваном Пепельняком, netlab позволяет инженеру описывать, чего должна достичь топология, а не как её соединить: “эти три узла работают на BGP”, “эти узлы находятся в одной VLAN”. netlab интерпретирует это описание и рендерит его в файл топологии containerlab плюс начальные конфигурации устройств для каждого вендора. Думайте о нём как о декларативном описании лаборатории: инженер определяет сервис; netlab генерирует определение инфраструктуры. Когда цель - тестирование логики автоматизации против топологии, отражающей production-сетевую модель, netlab является правильной отправной точкой; containerlab - то, что её запускает. Минимальная топология netlab для того же трёхузлового сценария:

nodes:
  cisco-1:
    device: iosxe
    image: ceos:17.9.4
  arista-1:
    device: eos
  hpe-1:
    device: aoscx

links:
  - cisco-1:
    arista-1:
  - arista-1:
    hpe-1:

vlans:
  app-payments:
    id: 210
    links: [ cisco-1, arista-1, hpe-1 ]

• vrnetlab соединяет эмуляцию на основе контейнеров и VM. Некоторые вендоры не предоставляют нативные образы контейнеров. vrnetlab оборачивает вендорские образы VM внутри контейнеров, делая их пригодными для использования внутри топологии containerlab. Так можно тестировать против Cisco IOS-XR или Junos устройства в среде containerlab, не переходя на платформу на основе VM.

• EVE-NG и GNS3 - платформы эмуляции на основе VM с широким охватом вендоров, GUI-проектированием топологии и полным поведением NOS, включая пересылку плоскости данных. Компромисс: более высокое потребление ресурсов, медленный запуск и ограниченная интеграция с CI/CD. Это правильный выбор для тестирования протоколов и дизайна, унаследованных платформ и сценариев совместимости нескольких вендоров.

• Cisco Modeling Labs - коммерческая VM-лабораторная платформа Cisco с REST API для частичной интеграции с CI/CD. Правильный выбор для Cisco-ориентированных сред, нуждающихся в доступе к VM IOS-XE, IOS-XR и NX-OS в управляемой общей лаборатории.

9.2.2.3. Фреймворки валидации#

Проверка того, что устройство правильно поддерживает данный протокол интерфейса или путь YANG, является частью работы, описанной в Главе 5 (Исполнение) и Главе 6 (Наблюдаемость): глава об исполнении охватывает проверку интерфейсов конфигурации до их использования в production-рабочих процессах; глава о наблюдаемости охватывает проверку путей сбора и подтверждение того, что подписки возвращают данные в ожидаемом формате.

Один сценарий заслуживает специального рассмотрения в контексте моделирования: волновая валидация. После успешного прохождения моделирования, но до принятия обязательств по полному production-охвату, некоторые команды выполняют структурированный проверочный проход против первой волны. pyATS предоставляет фреймворк тестирования для написания структурированных тестов взаимодействия с устройствами с богатым разбором и сравнением состояний. Robot Framework - более широкий фреймворк автоматизации тестирования на основе ключевых слов с сетевыми библиотеками. Оба позволяют команде кодировать ожидаемое состояние после изменения как выполнимые утверждения: после развёртывания VLAN 210 на Волне 1 подтвердить, что VLAN 210 существует на всех коммутаторах, подтвердить правильность ассоциаций интерфейсов и подтвердить, что уровень наблюдаемости видит ожидаемое состояние. Это напрямую связано с разделом 9.2.2.4: структурированный уровень валидации, отделяющий успешный прогон моделирования от реальной операционной уверенности перед переходом к следующей волне.

Минимальный тест pyATS, утверждающий наличие VLAN после развёртывания:

from pyats import aetest

class VlanValidation(aetest.Testcase):
    @aetest.test
    def verify_vlan_exists(self, device):
        output = device.parse('show vlan brief')
        assert 210 in output['vlans'], f"VLAN 210 missing on {device.name}"

    @aetest.test
    def verify_vlan_name(self, device):
        output = device.parse('show vlan brief')
        assert output['vlans'][210]['name'] == 'app-payments'

Та же проверка в Robot Framework с использованием библиотеки NAPALM, с явной настройкой и понятными именами ключевых слов:

*** Settings ***
Library    Collections
Library    napalm    WITH NAME    NAPALM

*** Variables ***
@{DEVICES}    cisco-1    arista-1    hpe-1

*** Test Cases ***
VLAN 210 Is Present On All Switches After Deployment
    FOR    ${hostname}    IN    @{DEVICES}
        Connect And Check VLAN    ${hostname}    210    app-payments
    END

*** Keywords ***
Connect And Check VLAN
    [Arguments]    ${hostname}    ${vlan_id}    ${vlan_name}
    NAPALM.Open    ${hostname}
    ${vlans}=    NAPALM.Get VLANs
    Dictionary Should Contain Key    ${vlans}    ${vlan_id}
    Should Be Equal    ${vlans}[${vlan_id}][name]    ${vlan_name}
    [Teardown]    NAPALM.Close

9.2.2.4. Моделирование как предварительный шлюз Saga#

Глава 7 описала паттерн Saga: многошаговый рабочий процесс, где каждый шаг имеет соответствующее компенсирующее действие, выполняемое при сбое последующего шага. Saga обрабатывает сбои в production. Моделирование добавляет шаг до начала Saga: сначала запустить рабочий процесс против среды моделирования. Если прогон моделирования проваливается, никаких production-изменений не происходит. Только когда моделирование проходит, рабочий процесс переходит к production-цели.

flowchart LR
    SoT["SoT export (topology + OS versions)"]
    Lab["Simulation environment (containerlab topology)"]
    Workflow["Workflow execution (same code as production)"]
    Pass{Pass?}
    Prod["Production execution (Orchestrator: full scope)"]
    Fix["Investigate and fix (no production impact)"]

    SoT --> Lab --> Workflow --> Pass
    Pass -- Yes --> Prod
    Pass -- No --> Fix --> Workflow

Это предварительный шлюз: моделирование как первая проверка до начала production Saga-охвата. Сбой в моделировании выявляется до того, как затронуто какое-либо production-устройство.

Практическая реализация:

1. Источник истины экспортирует определение топологии для целевого охвата, включая версии ОС для каждого устройства.
2. Среда моделирования создаётся с соответствующими образами вендоров, с версиями ОС, зафиксированными для соответствия предполагаемому состоянию источника истины.
3. Тот же рабочий процесс, который будет выполняться в production, сначала запускается против цели моделирования.
4. Любой шаг, провалившийся в моделировании, вызывает расследование до начала production-выполнения.

Прогрессивные волны развёртывания

Успешное прохождение моделирования не означает развёртывания во всём production-охвате сразу. Для крупномасштабных развёртываний моделирование является первым шлюзом в серии прогрессивно увеличивающихся волн, каждая со своей собственной проверкой перед переходом к следующей волне. Это один из моих любимых паттернов для получения доверия при критических развёртываниях, аналогичный популярному паттерну Canary из разработки программного обеспечения.

Команда, развёртывающая новый рабочий процесс на 100 центрах обработки данных, могла бы структурировать это так: моделирование (виртуальная топология) → 1 пилотный сайт → 2 сайта → 4 → 8 → 16 → оставшиеся сайты. Каждая волна проверяет, что рабочий процесс правильно вёл себя на предыдущей волне, прежде чем расширяться. Если Волна 4 обнаруживает сбой, который моделирование не выявило (аппаратно-специфическое поведение, специфическое для сайта состояние), развёртывание останавливается, проблема исправляется, и последовательность волн возобновляется с точки сбоя.

flowchart LR
    Sim["Simulation"] --> W1["Wave 1 (1 site)"] --> W2["Wave 2 (2 sites)"] --> W3["Wave 3 (4 sites)"] --> W4["Wave N (full scope)"]
    W1 -- Fail --> Fix["Investigate + fix"]
    W2 -- Fail --> Fix
    W3 -- Fail --> Fix
    Fix --> Sim

Оркестратор управляет прогрессией волн. Источник истины ограничивает каждую волну по сайту, корпусу или группе устройств. Шлюзы валидации между волнами являются явными шагами рабочего процесса: оркестратор проверяет уровень наблюдаемости на предмет ожидаемого состояния перед продолжением. Этот паттерн применяется независимо от того, охватывает ли область 100 центров обработки данных или 800 коммутаторов кампуса: принцип состоит в ограничении зоны поражения любого непредвиденного сбоя при наращивании уверенности с каждой успешной волной.

Ограничения моделирования: образы контейнеров не воспроизводят все поведения прошивки. Образ контейнера обычно работает на новом коде NOS; специфические особенности более старых прошивок могут быть невоспроизводимы, если образ не зафиксирован на конкретной версии. Моделирование выявляет логические ошибки, нарушения контракта интерфейса, пробелы в моделях Yet Another Next Generation (YANG) и сбои на уровне топологии. Оно не гарантирует, что каждое возможное состояние устройства, встречаемое в production, было протестировано. Цель - значительное снижение рисков, а не нулевой риск.

Проблема “снежинок”: моделирование наиболее надёжно, когда production-сеть следует согласованным архитектурным паттернам. Сеть с сотнями индивидуально настроенных конфигураций, каждая с уникальным состоянием и историей, сложнее точно представить в моделировании. Это одна из причин, по которым принципы архитектуры автоматизации (стандартизированные паттерны проектирования, золотые шаблоны, конфигурация на основе источника истины) делают тестирование более эффективным: хорошо спроектированная сеть более поддаётся моделированию. Ценность моделирования возрастает вместе с качеством проектирования сети, которое оно представляет. Создание этой воспроизводимости требует тесного партнёрства с сетевыми инженерами, а не только с инженерами по автоматизации: сетевой инженер, который понимает, какие сайты действительно идентичны, а какие несут скрытые исключения, является тем, кто может сделать моделирование репрезентативным. Качество моделирования - это совместный результат дисциплины проектирования сети и платформы автоматизации.

9.2.3. Стратегии абстракции#

Сеть по своей природе гетерогенна, и не только в том смысле, что вендоры различаются. Любая платформа автоматизации, работающая в масштабе, одновременно охватывает физическую коммутацию, облачную инфраструктуру, контроллеры оверлея, WAN-инфраструктуру сервис-провайдеров и унаследованное оборудование. Каждый говорит на своём языке. Платформа автоматизации не должна перестраиваться каждый раз при добавлении нового типа инфраструктуры.

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

Современные платформы автоматизации одновременно охватывают несколько инфраструктурных доменов. Архитектура, чисто справляющаяся с этим, применима независимо от того, является ли оператор крупным предприятием, сервис-провайдером, управляющим WAN и клиентским оборудованием одновременно, или гиперскейлером, эксплуатирующим фабрику центра обработки данных наряду с наложенными облачными сетями. Ключевой момент: исполнитель пишет, а сборщик читает через один и тот же интерфейс устройства (gRPC Network Management Interface (gNMI)/NETCONF для физического оборудования, REST для облака и контроллеров), поэтому протокол интерфейса является общей задачей для обоих блоков, а не отдельным проектным решением для каждого блока.

flowchart LR
    SoT["Source of Truth"]
    Orch["Orchestrator"]
    Obs["Observability"]

    subgraph Physical["Physical domain"]
        PhysIF["Network interface (NETCONF/gNMI)"]
        PhysNet["Campus, DC fabric, WAN gear"]
        PhysIF --- PhysNet
    end

    subgraph Cloud["Cloud domain"]
        CloudIF["Network interface (async REST)"]
        CloudNet["Cloud VPCs / networking"]
        CloudIF --- CloudNet
    end

    subgraph Overlay["Overlay domain"]
        OvIF["Network interface (controller API)"]
        OvNet["SD-WAN / MPLS PCE / overlay"]
        OvIF --- OvNet
    end

    SoT --> Orch
    Orch -->|Executor write| PhysIF
    Orch -->|Executor write| CloudIF
    Orch -->|Executor write| OvIF
    PhysIF -->|Collector read| Obs
    CloudIF -->|Collector read| Obs
    OvIF -->|Collector read| Obs

Источник истины моделирует полное намерение по всем типам топологии как единую сервисную модель. Orchestrator содержит ветви по сетевым доменам. Исполнитель маршрутизирует к правильному адаптеру на основе данных источника истины. Наблюдаемость охватывает все уровни, питая один и тот же конвейер данных независимо от базового типа инфраструктуры.

Ключевая архитектурная дисциплина: ветвление происходит в исполнителе и оркестраторе, а не в источнике истины. Источник истины хранит единую модель намерения для сервиса. То, как это намерение реализуется на разных типах инфраструктуры, является задачей исполнителя.

9.2.3.1. Измерения гетерогенности#

Прежде чем выбирать стратегию абстракции, полезно понять ось гетерогенности, которую должна поглотить эта стратегия. Не вся гетерогенность является одним и тем же видом проблемы.

Каждая строка - это ось различия, которую платформа должна обрабатывать, не требуя от источника истины кодировать её. Модель намерения остаётся единой; исполнитель и оркестратор поглощают вариации. Стратегии в следующих разделах описывают, как.

9.2.3.2. Паттерн адаптера в исполнителе и сборщике#

Наиболее распространённая отправная точка и наиболее широко реализованная стратегия. Один модуль автоматизации на вендора, все принимающие одну и ту же входную структуру данных из источника истины. Источник истины хранит намерение, нейтральное по отношению к вендору; адаптерный уровень исполнителя переводит его для каждого вендора во время выполнения. Тот же принцип применяется к сборщику: один модуль сбора на вендора или протокол, все доставляющие нормализованную структуру данных в конвейер наблюдаемости. Вендор, говорящий на gNMI, использует один адаптер; вендор, требующий опроса SNMP или проприетарного REST, использует другой. Уровень наблюдаемости видит одну и ту же схему данных независимо от метода сбора выше по потоку.

flowchart LR
    SoT["SoT intent (vendor-neutral): vlan_id=210, vlan_name=app-payments"]
    Exec["Executor"]
    CiscoA["Cisco adapter: IOS-XE NETCONF"]
    AristaA["Arista adapter: eAPI / EOS"]
    HPEA["HPE adapter: NETCONF + OS-version error handling"]
    CiscoD["Cisco Catalyst"]
    AristaD["Arista 7050"]
    HPED["HPE Aruba 6300"]

    CollGNMI["Collector: gNMI adapter"]
    CollSNMP["Collector: SNMP adapter"]
    Obs["Observability pipeline (normalized schema)"]

    SoT --> Exec
    Exec --> CiscoA --> CiscoD
    Exec --> AristaA --> AristaD
    Exec --> HPEA --> HPED

    CiscoD --> CollGNMI --> Obs
    AristaD --> CollGNMI
    HPED --> CollSNMP --> Obs

Практична в создании и хорошо изучена. Нагрузка по обслуживанию растёт по мере диверсификации инвентаря устройств: каждый новый вендор или версия ОС требует нового или обновлённого адаптера. Паттерн адаптера хорошо масштабируется для определённого набора вендоров; он становится обременительным, когда платформа должна поддерживать большой и часто меняющийся каталог устройств.

9.2.3.3. Разработанные сообществом и индустрией модели YANG#

Два отраслевых органа публикуют нейтральные по отношению к вендору модели YANG, которые сокращают работу по адаптации для каждого вендора. Модели IETF (публикуемые в виде RFC и Internet-Drafts) определяют базовые структуры данных: ietf-interfaces, ietf-routing, ietf-bgp. Модели OpenConfig, разработанные консорциумом операторов (Google, AT&T, Deutsche Telekom и другими), охватывают схожую область с более операционно-ориентированной схемой и более быстрым циклом итерации. Оба позволяют платформе автоматизации однократно записывать намерение против стандартной модели и ожидать её работы на любом совместимом устройстве.

Модуль YANG, определяющий интерфейс, выглядит так (упрощённо из ietf-interfaces):

module ietf-interfaces {
  container interfaces {
    list interface {
      key "name";
      leaf name      { type string; }
      leaf description { type string; }
      leaf enabled   { type boolean; default true; }
    }
  }
}

Та же структура появляется в OpenConfig (openconfig-interfaces) и в нативных моделях вендоров, но с разными путями, разными именами листьев и разной семантикой значений по умолчанию. Модуль YANG определяет схему; протокол (NETCONF или gNMI) транспортирует данные; адаптерный уровень отображает стандарт на реальность вендора.

Практическая реальность OpenConfig: реализации вендоров различаются по полноте. Устройство может заявлять поддержку OpenConfig, но реализовывать только подмножество модели: чтение работает, запись нет; или модель интерфейса работает, но модель BGP отсутствует.

Помимо отсутствующих путей, более коварная проблема - несогласованные данные. Устройство возвращает значение для пути OpenConfig, но в неправильном юните, с другим типом или с полями, которые должны быть null, заполненными значениями по умолчанию вендора. Подписка gRPC Network Management Interface (gNMI), работающая в режиме SAMPLE, может молча завершиться с ошибкой в режиме ON_CHANGE на том же устройстве.

Это не редкие крайние случаи. Это повседневная реальность эксплуатации многовендорной платформы, опирающейся на OpenConfig в production. Стандарт работает на бумаге; реализация вендора требует того же исследования для каждого устройства, которое стандарт должен был устранить. OpenConfig значительно сокращает эту работу, но не устраняет её. Планируйте тестирование для конкретного устройства до использования нового пути OpenConfig в production-автоматизации.

Заметка о семействах моделей YANG

Три семейства моделей Yet Another Next Generation (YANG) сосуществуют в production-сетях, и понимание этого различия важно для выбора целевых моделей:

• Модели IETF разрабатываются через процесс стандартизации IETF и публикуются в виде RFC или Internet-Drafts. Это базовые стандарты: ietf-interfaces, ietf-routing, ietf-bgp. Принятие широкое, но медленное; процесс тщательный, но занимает годы. Реализации вендоров часто появляются через два-четыре года после публикации.
• Модели OpenConfig разрабатываются консорциумом OpenConfig, группой под руководством операторов (Google, AT&T, Deutsche Telekom и других). OpenConfig итерирует быстрее, чем IETF, и более операционно-ориентирован. Он охватывает многие из тех же функциональных областей, что и модели IETF, но с другими схемными решениями. Большинство production-развёртываний gNMI используют пути OpenConfig.
• Нативные модели вендоров - собственные расширения каждого вендора: cisco-ios-xe-native, junos-conf-root, arista-eos-augments. Они раскрывают функции, которые стандартные модели не охватывают, и часто необходимы для чего-либо помимо функций наименьшего общего знаменателя, которые охватывают IETF и OpenConfig. Nokia является крайним случаем: почти все оперативные данные на SR OS доступны только через Nokia-специфические модели YANG (nokia-conf, nokia-state). Стандартные модели охватывают тонкую поверхность; нативные модели вендора обязательны для любой значимой автоматизации на этой платформе.

Абстракция покупает однородность ценой доступа к функциям. У каждого вендора есть проприетарные возможности без аналогов в стандартных моделях. Команда, использующая OpenConfig, должна выбрать: игнорировать функцию, добавить расширение вендора или поддерживать специфический для вендора путь переопределения. Чёткого ответа нет. На практике большая часть работы по автоматизации сосредоточена в функциях, хорошо охваченных стандартными моделями (VLAN, BGP, интерфейсы); проприетарные функции важны, но редко являются основным случаем использования. Стандарты также поставляются с задержкой принятия: вендор может реализовать модуль IETF через два-четыре года после публикации и только на новых платформах. Ограничивайте использование функций версией ОС, записанной в источнике истины, а не предполагайте однородную поддержку.

9.2.3.4. SONiC и открытые сети#

Интерфейс конфигурации SONiC - это база данных Redis со структурированной схемой YANG: однородная, программируемая и разработанная для автоматизации с самого начала. Работа по адаптации для конкретного вендора, потребляющая усилия в многовендорных физических средах, здесь не применяется. Та же логика автоматизации работает на всех платформах на базе SONiC независимо от базового вендора оборудования.

Запись VLAN в SONiC CONFIG_DB выглядит так:

{
  "VLAN": {
    "Vlan210": {
      "vlanid": "210"
    }
  },
  "VLAN_MEMBER": {
    "Vlan210|Ethernet0": {
      "tagging_mode": "untagged"
    }
  }
}

Этот JSON записывается напрямую в Redis через sonic-cfggen или REST API управления SONiC. Нет CLI для разбора, нет XML для конструирования. Платформа автоматизации записывает структурированные данные; orchagent SONiC согласовывает их с таблицами пересылки оборудования.

Это направление проектирования, которое отстаивают открытые сети: сетевой интерфейс, разработанный для автоматизации, а не адаптированный к ней. Команды, вводящие платформы на базе SONiC наряду с традиционным оборудованием, обнаружат, что адаптер SONiC является самым простым в написании и наиболее надёжным в эксплуатации.

• Предложения вендоров: SONiC далеко вышел за рамки своего происхождения в Microsoft Azure. Большинство крупных вендоров коммутаторов теперь предлагают платформы на базе SONiC: Microsoft Azure SONiC (эталонный upstream), Arista с совместимыми с SONiC API управления на некоторых платформах, Cisco серии 8000 с поддержкой SONiC на базе Broadcom, Dell OS10 (использующий архитектуру, производную от SONiC), платформы Nvidia Spectrum, работающие на SONiC как первоклассной опции, и растущее число ODM-вендоров (Edgecore, Celestica, UfiSpace), поставляющих брендированные платформы SONiC. Экосистема созрела до уровня, когда платформа на базе SONiC коммерчески доступна в каждом ценовом и производительном диапазоне.

• Зрелые случаи применения: фабрики “лист-хребет” центров обработки данных являются наиболее устоявшимся развёртыванием. Гиперскейлеры работают на SONiC в масштабе более десяти лет; корпоративные центры обработки данных теперь следуют за ними. Оверлей EVPN/VXLAN, маршрутизация BGP, балансировка нагрузки ECMP и поддержка интерфейсов 400G/800G хорошо проверены. История автоматизации сильна: gNMI, YANG и CONFIG_DB на основе Redis являются нативными интерфейсами. Парком SONiC можно управлять теми же инструментами, что и любой другой платформой с поддержкой gNMI.

• Новые направления: SONiC начинает появляться за пределами традиционной DC-фабрики. Дезагрегированные маршрутизаторные платформы (где SONiC работает на маршрутизаторах с большим количеством портов, а не только на коммутаторах) расширяют модель открытой NOS до случаев использования маршрутизации. SONiC теперь включает поддержку сегментной маршрутизации: SRv6 (Segment Routing over IPv6) доступен в upstream SONiC и используется в production сервис-провайдерами на платформах на базе SONiC для трафик-инжиниринга и сетевого слайсинга. Некоторые сервис-провайдеры также оценивают SONiC для граничного пиринга и агрегации широкополосного доступа. Развёртывания SONiC в кампусе остаются редкими, но технически осуществимы; аппаратная экосистема для форм-факторов кампуса менее зрела. Для команд, создающих новые платформы сегодня, вопрос больше не в том, готов ли SONiC к production в ЦОД: он готов. Открытый вопрос состоит в том, останется ли форк SONiC вендора и кадентность выпусков согласованными с upstream на протяжении жизненного цикла платформы.

9.2.3.5. Управление сосуществованием во время миграции прошивок#

Паттерн адаптера предполагает известную, стабильную версию ОС для каждого устройства. Во время поэтапного обновления прошивки это предположение нарушается: устройства в одной роли, управляемые одной платформой автоматизации, одновременно работают на разных версиях ОС на протяжении дней или недель. Уровень абстракции, работавший вчера на прошивке 10.12, может не работать на прошивке 10.13 до добавления нового адаптерного пути.

Источник истины должен записывать предполагаемую версию ОС (целевую после миграции), а сборщик должен отображать текущую версию ОС как оперативное состояние. Прежде чем исполнитель применяет конфигурацию, он должен читать текущую версию ОС из сборщика или конвейера наблюдаемости и выбирать соответствующий адаптерный путь, а не предполагать, что предполагаемая версия уже развёрнута.

Конкретный механизм: исполнитель запрашивает блок наблюдаемости (или лёгкую предварительную проверку перед выполнением непосредственно на устройстве) для работающей версии ОС. Реестр адаптеров сопоставляет диапазоны версий ОС с реализациями адаптеров. Исполнитель вызывает правильный адаптер на основе текущего состояния, а не намерения источника истины. После обновления устройства и совпадения работающей версии с намерением выбор адаптера стабилизируется. В течение периода миграции два адаптерных пути для одного вендора могут быть активны одновременно.

Пример реализации в разделе 9.3 непосредственно демонстрирует этот паттерн: ошибка адаптера HPE была вызвана тем, что одна версия прошивки возвращала vlan-exists, а другая - duplicate-vlan для того же условия. Исправлением стала обработка ошибок для каждой версии ОС в реестре адаптеров. Любая платформа автоматизации, управляющая парком с несколькими версиями, столкнётся с этим классом проблем. Кодирование логики адаптера для каждой версии, управляемой текущей версией ОС, считанной из сборщика, является систематическим митигированием. Глава 11 рассматривает, как поддерживать сопоставления версий ОС как каталог на уровне платформы, а не как константы для каждого плейбука.

Организационное следствие: кто-то должен владеть отслеживанием версий ОС в источнике истины, реестром версий адаптеров и рабочим процессом последовательности обновлений. Эти три артефакта образуют систему автоматизации обновлений. Без явного владения они дрейфуют независимо, и надёжность платформы деградирует с каждым выпуском прошивки.

9.2.4. Сеть как ограничение для каждого блока#

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

Возможности интерфейса сети ограничивают то, что может делать исполнитель: устройство, поддерживающее только CLI, вынуждает адаптер исполнителя к хрупкому экранному скрейпингу; устройство с зрелой поддержкой gNMI обеспечивает надёжную конфигурацию и потоковую телеметрию. Поддержка сбора в сети ограничивает то, что сборщик может принимать: устройство, не реализующее нужный путь OpenConfig, требует специфического для вендора обходного пути или пробела в сборе. Топология сети ограничивает то, что оркестратор может безопасно распараллеливать: размер пакета, безопасный для плоского уровня доступа, может быть катастрофическим для фабрики “хребет-лист”, где одновременные изменения нескольких узлов хребта могут разбить сеть.

Модель данных источника истины отражает эти ограничения. Поля версий ОС открывают доступ к выбору адаптера. Поля типов интерфейса открывают доступ к методу сбора. Топологические отношения открывают доступ к правилам параллелизма оркестратора. Источник истины, записывающий инвентарь устройств без записи атрибутов, значимых для автоматизации (возможности интерфейса, версия ОС, топологическая роль), является неполным в способах, которые проявляются только во время выполнения.

Каждое архитектурное решение в Части 2 имеет соответствующее ограничение на уровне сети, которое поверхностно раскрывает эта глава. Сеть - это не просто цель автоматизации. Она формирует каждый блок, действующий на неё, и эти ограничения должны быть закодированы в модели данных платформы, логике адаптеров и конфигурации рабочего процесса. Автоматизация, рассматривающая сеть как однородную поверхность, будет открывать гетерогенность по одному неудавшемуся развёртыванию за раз.

9.3. Пример реализации#

9.3.1. От моделирования к production#

Рабочий процесс VLAN для кампуса готов. Восемь недель разработки, три смоделированных вендора, тест идемпотентности против трёхузловой лаборатории. Команда хочет развернуть его в production: 800 коммутаторов, корпуса с A по F. Прежде чем это произойдёт, они запускают его против моделирования.

Этот пример следует последовательности предварительного шлюза, описанной в разделе 9.2.2.4, используя охват корпуса B в качестве цели моделирования: 24 коммутатора, 8 Cisco, 8 Arista, 8 HPE.

Шаг 1: Экспорт топологии из источника истины

Источник истины хранит инвентарь коммутаторов корпуса B с предполагаемыми версиями ОС:

• 8 Cisco Catalyst 9300: IOS-XE 17.9.4
• 8 Arista 7050: EOS 4.31.2F
• 8 HPE Aruba 6300: AOS-CX 10.12.1006 (старая линейка прошивок, до 10.13)

Экспорт источника истины создаёт определение топологии netlab: типы узлов, теги образов, специфичных для вендора и сопоставленных с предполагаемыми версиями ОС, и состояние VLAN, с которого должно начинаться моделирование (существующие VLAN 100, 150 и 200, уже настроенные на всех коммутаторах, соответствующие production-состоянию).

Шаг 2: Создание среды моделирования

netlab рендерит экспорт источника истины в файл топологии containerlab. containerlab работает на общем Linux-хосте моделирования в CI-среде команды (сервер bare-metal с 64 ГБ ОЗУ, достаточным для 24 лёгких контейнеров cEOS/vrnetlab одновременно). Узлы HPE используют образ AOS-CX, обёрнутый в vrnetlab и закреплённый на версии 10.12.1006, соответствующей предполагаемой версии ОС из источника истины. containerlab запускает топологию. Все 24 узла работают и отвечают на NETCONF и gRPC Network Management Interface (gNMI) в течение девяноста секунд.

Шаг 3: Запуск рабочего процесса VLAN из Главы 7 против цели моделирования

Оркестратор запускает рабочий процесс с инвентарём моделирования в качестве целевого охвата, а не production-инвентарём. Первые четыре шага рабочего процесса завершаются без проблем:

• Получен вебхук ServiceNow, разобран, проверен против схемы источника истины
• Предварительная проверка: VLAN 210 не существует в моделировании (правильно)
• Источник истины обновлён намерением VLAN 210
• Шлюз утверждения: автоматически утверждён в режиме моделирования

Пятый шаг рабочего процесса, разветвлённое выполнение на всех 24 виртуальных коммутаторах через исполнитель, возвращает сбои.

Результаты: 8 узлов Cisco проходят. 8 узлов Arista проходят. 8 узлов HPE дают сбой.

Ошибка от узлов HPE: vlan-exists. Проверка идемпотентности в адаптере HPE обрабатывала duplicate-vlan как холостую операцию, но не имела обработчика для vlan-exists. Исполнитель вернул сбой, запустив компенсацию Saga: VLAN 210 удалён со всех узлов, получивших его.

Production-изменений не произошло. Стоимость сбоя - время запуска контейнера и тридцатиминутное расследование.

Шаг 4: Диагностика и исправление

Команда проверяет примечания к выпуску AOS-CX 10.12. Ошибка vlan-exists была введена в версии 10.11.1, заменив duplicate-vlan для обнаружения дублирующихся VLAN. Выпуск 10.13 вернулся к duplicate-vlan для обеспечения согласованности с остальной линейкой продуктов Aruba.

Исправление: добавить vlan-exists в список идемпотентных кодов ошибок в адаптере HPE. Источник истины обновлён примечанием о границе версии ОС (от 10.11 до 10.12.x возвращает vlan-exists; 10.13+ возвращает duplicate-vlan).

Перед повторным запуском команда кодирует ожидаемое состояние после изменения как тест pyATS или Robot Framework: после завершения рабочего процесса утверждать, что VLAN 210 существует на всех 24 узлах моделирования и что компенсация Saga не была запущена. Это утверждение добавляется к критериям прохождения моделирования: шлюз моделирования закрывается только тогда, когда и рабочий процесс завершается, и утверждения валидации проходят.

Шаг 5: Повторный запуск в моделировании

Исправленный адаптер запускается против той же топологии containerlab. Все 24 узла проходят. Saga завершается без компенсации. Источник истины показывает VLAN 210 на всех узлах корпуса B.

Шаг 6: Production-развёртывание

Оркестратор запускает тот же рабочий процесс против полного production-охвата: 800 коммутаторов, корпуса с A по F. Каждый шаг проходит через тот же паттерн Saga, проверенный в моделировании. Ноль сбоев на узлах HPE. Тикет ServiceNow прикладной команды закрывается автоматически при завершении оркестратором. Уровень наблюдаемости проверяет наличие VLAN 210 на всех интерфейсах в ожидаемом временном окне.

Что это демонстрирует

Среда моделирования - это не проверочный шаг, который можно пропустить, когда команда уверена в результате. Это предварительный шлюз в паттерне Saga. Топология моделирования, отражающая production-топологию и версии ОС, является минимально жизнеспособной средой тестирования для команды, развёртывающей автоматизацию в масштабах кампуса. Инвестиции - настройка containerlab, образы с закреплёнными версиями ОС и механизм экспорта из источника истины. Отдача - возможность выявлять ошибки, специфичные для устройств, до того, как они превращаются в инциденты.

Моделирование выявило эту ошибку не из-за экзотического тестирования, а потому что версия ОС в моделировании соответствовала production и платформа запустила ровно тот же код рабочего процесса против неё. Точность среды моделирования относительно production-состояния - это то, что делает выявление возможным. Среда моделирования, работающая на последних образах вендоров, пропустила бы эту ошибку.

Глава 10 охватывает операционализацию сред моделирования как части платформы: поддержание топологий containerlab в системе контроля версий, синхронизация их с экспортами источника истины по расписанию и интеграция их в конвейеры CI/CD так, чтобы шлюз моделирования запускался автоматически при каждом изменении рабочего процесса.

9.4. Итоги#

Глава 9 завершает Часть 2, рассматривая блок, на который всегда была направлена платформа автоматизации: саму сеть.

Три идеи являются основой главы.

Сеть не однородна. Любая крупномасштабная платформа автоматизации взаимодействует одновременно с коммутацией кампуса, фабрикой центра обработки данных, облачными VPC, наложенными сетями Kubernetes, контроллерами оверлея и унаследованным оборудованием. Каждый предоставляет разный интерфейс, работает под разной семантикой согласованности и имеет разную зрелость автоматизации. Платформа поглощает эту гетерогенность через иерархию выбора интерфейса (gRPC Network Management Interface (gNMI) для телеметрии, NETCONF для конфигурации, Command Line Interface (CLI) как крайняя мера), отслеживание версий ОС в источнике истины и вендорно-специфические адаптеры в исполнителе.

Среды моделирования являются предварительным шлюзом. Эмуляция на основе контейнеров обеспечивает реалистичные, быстрые, интегрированные с CI/CD среды, где логика автоматизации тестируется против топологии и версий ОС, отражающих production. Сбои в моделировании дёшевы. Сбои в production дороги. Точность среды моделирования относительно production-состояния - это то, что делает шлюз значимым.

Стратегии абстракции продлевают срок службы платформы. Паттерн адаптера обрабатывает сегодняшнюю многовендорную физическую среду. OpenConfig и перевод YANG продвигают к нейтральным по отношению к вендору моделям, которые сокращают долгосрочное обслуживание адаптеров. SONiC полностью устраняет работу по адаптации для поддерживающих его платформ. Ни одна из этих стратегий не даёт идеального ответа; каждая предполагает компромисс между однородностью и доступом к функциям. Правильный выбор зависит от каталога устройств команды, операционных возможностей и того, насколько большая часть их работы по автоматизации попадает в стандартное покрытие функций.

С Главой 9 Часть 2 завершена. Шесть глав охватили все семь строительных блоков фреймворка NAF: источник истины, сборщик и наблюдаемость (вместе в Главе 6), исполнение, оркестрацию, представление и Сеть. Это не независимые инструменты. Источник истины питает исполнителя намерением, которое ему нужно, и сборщика ожидаемым состоянием для проверки. Оркестратор последовательно выполняет оба, обрабатывает сбои и отображает прогресс уровню представления. Сеть находится под всеми ними: ограничение, сформировавшее проектирование каждого другого блока, и место, где автоматизация в конечном итоге производит результат или терпит неудачу.

Часть 3 переходит от построения блоков к эксплуатации платформы в масштабе: проектирование для надёжности, проектирование для безопасности и соответствия требованиям, и отношение к платформе автоматизации как к продукту с собственным жизненным циклом и операционными требованиями.

Ссылки и дополнительное чтение#

• Network Programmability and Automation, Мэтт Освальт, Кристиан Адель, Скотт Лоу, Джейсон Эдельман (O’Reilly, 2-е изд. 2023). Наиболее полное практическое руководство по инструментарию сетевой автоматизации, охватывающее NETCONF, gNMI, модели YANG и фреймворки автоматизации в глубину.
• Network Programmability with YANG, Бенуа Клез, Лое Кларк, Ян Линдблад (Pearson, 2019). Исчерпывающий справочник по моделированию данных YANG: как структурированы модели IETF и OpenConfig, как читать и писать модули YANG, и как NETCONF и RESTCONF их используют.
• Cisco pyATS: Network Test and Automation Solution, Джон Капобьянко, Дэн Уэйд (Cisco Press). Полное руководство по pyATS и Genie для автоматизации тестирования сети: тестовые скрипты, парсеры, структурированная валидация состояния и интеграция с конвейером CI/CD.
• Infrastructure as Code, Киф Моррис (O’Reilly, 2-е изд. 2021). Не специфично для сетей, но является основополагающим для понимания того, как принципы воспроизводимой, тестируемой, контролируемой по версиям инфраструктуры напрямую применяются к проектированию платформ сетевой автоматизации.

💬 Found something to improve? Send feedback for this chapter