Кратко

  • После принятия <commit><confirmed/> содержимое candidate уже становится running. Таймер откладывает не исполнение, а снятие обязанности вернуть прежнюю конфигурацию.
  • В обычном режиме преждевременное завершение исходной сессии вызывает восстановление. С параметром persist процедура переживает сессию, а другое соединение с совпадающим persist-id может подтвердить, продлить или отменить её.
  • Ответ <ok>, валидация YANG и событие complete не доказывают синхронизацию startup, применение intended в operational, прохождение пакетов или атомарную смену нескольких устройств.

Успешный ответ перед потерей управления

Инженер меняет адрес управления удалённого маршрутизатора. Он собирает конфигурацию в candidate, проверяет её и отправляет confirmed commit. Сервер отвечает <ok>. Новая конфигурация становится running. Через несколько секунд SSH-сессия обрывается, а по новому адресу устройство недоступно.

Отправить команду возврата уже нельзя. Однако обычный confirmed commit заранее возложил её смысл на сервер. Если инициировавшая сессия закончилась до подтверждения, сервер обязан восстановить конфигурацию, действовавшую до процедуры. То же происходит при истечении срока. Если устройство перезагрузилось раньше подтверждения, оно также должно восстановить прежний вариант.

Здесь особенно легко неправильно прочитать слово commit. Изменение не ожидало второго разрешения вне рабочего контура. Оно уже вошло в running и могло перестроить маршруты, интерфейсы или контроль доступа. Временным было не исполнение, а право нового состояния остаться.

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

Candidate переходит в running до подтверждения

RFC 6241 задаёт операции и конфигурационные хранилища NETCONF. Сервер с возможностью :candidate позволяет собрать полный вариант конфигурации без немедленного изменения running. Операция <commit> устанавливает running по содержимому candidate. Зависимая от candidate возможность :confirmed-commit:1.1 добавляет после этого перехода условие окончательности.

Если confirm-timeout не задан, срок по умолчанию равен 600 секундам. Следующий подтверждающий commit завершает процедуру и снимает обязанность автоматического возврата. Новый confirmed commit может продлить открытую процедуру и назначить допустимый срок. <cancel-commit> прекращает её восстановлением прежней конфигурации. Истечение времени ведёт к тому же результату.

В журнале это не одна операция «применить», а несколько фактов:

  • candidate прошёл проверку при конкретном наборе моделей;
  • сервер принял provisional commit;
  • candidate стал running;
  • срок был продлён либо процедура завершилась подтверждением, отменой или timeout;
  • running получил определённый итоговый отпечаток;
  • startup и реальное состояние последовали этому итогу либо разошлись с ним.

RFC 6470 даёт полезные события start, extend, complete, cancel и timeout. Они позволяют сохранить фазы, но не создают финальность сами. Сборщик может пропустить уведомление, а после complete оборудование ещё может применять настройки. Нужна сквозная связь RPC, пользователя, сессии, отпечатков candidate и прежнего running, срока, уведомлений и наблюдаемого результата.

Кто управляет сроком, тот управляет частью решения

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

До выбора срока необходимо определить достаточные доказательства. Вернулось ли управление? Стабильны ли соседства? Выбраны и установлены ли нужные маршруты? Проходят ли пакеты в обоих направлениях? Отвечает ли сервис при независимой проверке? Кто может продлевать окно и сколько раз? Когда отсутствие доказательства требует отмены, а не очередного продления?

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

Продление — не техническая мелочь. Оно оставляет временное состояние в работе и потому должно иметь владельца, предел и причину.

persist переживает сессию, но не удостоверяет человека

В обычной форме процедура связана с инициировавшей NETCONF-сессией. Её потеря до завершения означает возврат. При изменении пути управления такая зависимость часто и является главным предохранителем.

Распределённая автоматизация иногда требует другого. Один процесс запускает изменение, другой проверяет, аварийная группа продолжает из нового соединения. Инициатор может передать непрозрачное значение persist. Тогда confirmed commit остаётся открытым после конца исходной сессии. Другое соединение предъявляет совпадающий persist-id при разрешённой операции подтверждения, продления или отмены.

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

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

Установленная SSH-сессия, совпадение persist-id и право менять конкретные узлы — независимые проверки.

Восстановление может захватить чужую работу

Rollback часто представляют обратным патчем только для строк конкретного автора. Confirmed commit хранит прежнее состояние конфигурации и восстанавливает его. RFC 6241 предупреждает: изменения, внесённые после provisional commit, при возврате могут быть изменены или удалены.

Пусть изменение A вошло в running с пятиминутным сроком. Через две минуты другая система внесла якобы независимое изменение B. Затем сессия A пропала. Сервер не знает организационной истории B; у него есть база до A. Без доказанной более узкой семантики слияния B может исчезнуть вместе с возвратом.

Блокировки ограничивают эту неопределённость. Глобальный NETCONF lock исключает другие сессии из покрытого datastore. RFC 5717 определяет частичные блокировки, но требует отказать в новой partial lock на running во время открытого confirmed commit: серверу может понадобиться восстановить более широкий диапазон.

Lock не подтверждает правильность конфигурации. Он доказывает исключение только в своём фактическом охвате и для путей записи, которые его соблюдают. Доказательство должно хранить владельца, область, получение и освобождение lock, конкурирующие попытки и отпечатки состояния до и после возврата. Фраза «у нас есть rollback» без этих данных остаётся названием функции.

RESTCONF может завершить решение, начатое NETCONF

Граница протокола не всегда совпадает с границей состояния. RFC 8040 описывает RESTCONF над концептуальными хранилищами, общими с расположенным рядом NETCONF-сервером. Если используется candidate, успешное редактирование RESTCONF автоматически committed получившийся candidate.

Когда открыт неперсистентный NETCONF confirmed commit, такой новый commit работает как подтверждение. Клиент RESTCONF может закрыть окно возврата, не вызывая команду с названием confirm и не зная намерения исходного оператора. Наблюдение только за NETCONF пропустит фактического финализатора.

С персистентной процедурой иначе. RESTCONF не имеет поля для persist-id. Если открытая операция требует этот идентификатор, редактирование должно завершиться HTTP 409 in-use, а не молча подтвердить или перекрыть её. NETCONF lock также может вызвать 409. Эти ответы следует связывать с владельцем commit или lock; это сигнал занятой власти над состоянием, а не просто шум API.

Startup тоже зависит от пути. Если совместный сервер поддерживает startup, RFC 8040 требует автоматически обновлять его после успешного RESTCONF-редактирования. Обычный NETCONF commit в running сам по себе этого не доказывает. Происхождение записи влияет на поведение после перезапуска.

SSH, NACM и YANG отвечают на разные вопросы

RFC 6242 переносит NETCONF по защищённому SSH-каналу. Аутентифицированная сторона необходима, но её наличие не означает права вызвать <commit> или изменить любой узел.

NACM из RFC 8341 разделяет доступ к операциям, узлам данных и уведомлениям. Аутентифицированная сессия может получить отказ на RPC. Разрешённая операция может затронуть запрещённый узел. Recovery-сессия может иметь исключительные права конкретной реализации. Каждая ступень должна иметь собственный результат в аудите.

Следующая ступень — модель. RFC 7950 определяет YANG 1.1, типы, структуры, ссылки и ограничения. Адрес может быть формально допустим и принадлежать неверной площадке. Политика может удовлетворять всем ссылкам и отключить сервис. Валидность означает соответствие объявленной схеме, а не правильность намерения.

RFC 8525 позволяет узнать модули, features, deviations, связь схем с datastore и серверный content-id. Проверка candidate должна быть привязана к этому точному состоянию. Изменение библиотеки между подготовкой и commit способно изменить смысл того же текста.

Финальный running может не стать operational

Архитектура NMDA из RFC 8342 разделяет running, intended и operational. Running содержит текущую полную конфигурацию. Система может преобразовать её, раскрыть шаблоны, убрать неактивные узлы или добавить управляемые значения, формируя intended. Operational показывает то, что реально используется в момент наблюдения.

Конфигурация для отсутствующего ресурса может остаться в running и intended и не появиться применённой в operational. Физические ограничения, внутренние зависимости, асинхронная работа или другие протоколы могут задержать либо изменить применение. Confirmed commit уже способен быть complete, а устройство — оставаться частично в другом состоянии.

Проверка должна следовать объекту. Интерфейс требует фактического состояния и пакетов. Маршрутная политика — соседств, кандидатов, выбора, установки и forwarding. Управляющий адрес — нового пути и независимой возможности восстановления. Сравнение конфигураций — доказательство datastore, не dataplane.

Согласованный тикет, SSH-аутентификация, решение NACM, YANG-валидность, финальный running, сформированный intended, применённый operational и работающий сервис — разные слои реальности. Предыдущий слой может быть истинным, пока следующий ложен.

Десять серверов не превращаются в один commit

RFC 6244 помещает NETCONF и YANG в более широкую архитектуру управления. Контроллер может строить сетевое изменение из confirmed commits, но каждый сервер сохраняет собственную базу, запускает собственный таймер и подчиняется своим возможностям, locks, перезагрузкам и аппаратному применению.

Запросы начинаются не одновременно. Одно устройство может перезагрузиться, другое отказать в lock, третье принять running и не применить ресурс. Если девять вернули <ok>, а десятое ошибку, возникло частичное состояние. Подтверждение девяти делает его финальным. Отмена девяти всё равно требует доказать возврат operational и трафика.

Распределённый уровень обязан построить оркестратор: общая идентичность транзакции, база каждого устройства, порядок запуска и подтверждения, критерии остановки, canaries, компенсация и сверка. Поэтапный rollout может быть честнее недостижимой атомарности. Называть набор зелёных RPC общим commit point нельзя.

Минимальное утверждение сильнее общего зелёного статуса

Реестр IANA координирует URN для candidate, confirmed commit, startup, validate и других возможностей. Общий слой намеренно узок. Выбор сроков, ролей, блокировок, доказательств и политики нескольких устройств остаётся локальным.

Защищаемый отчёт звучит так: этот пользователь и эта сессия при этой версии прав и схемы перевели этот candidate из этой базы в running; этот срок и правило сессии или токена управляли финальностью; такое событие завершило процедуру; running и startup получили такие состояния; intended, operational, пакеты и сервис показали такие результаты; все устройства были сверены.

Практическая власть принадлежит тому, кто может отправить RPC, сохранить токен, продлить срок, подтвердить, записать startup и решить, что наблюдения достаточно. Имя согласующего на диаграмме не создаёт этой возможности. Управление возникает, когда заявленные роли совпадают с исполнимыми ограничениями.

Confirmed commit ценен именно своей узостью. Он даёт серверу точный переход между временным исполнением и восстановлением. Все более широкие выводы организация должна заработать отдельными доказательствами.

Источники