要約

  • サーバーが confirmed commit を受理すると、candidate はすでに running になる。確認タイマーが保留するのは実行ではなく確定であり、未確認ならサーバーが直前の設定を復元する。
  • 通常形では開始セッションの切断が復元条件になる。persist を使う形では手続きがセッションを越え、正しい persist-id を持つ別セッションが確認、延長、取消しを行える。
  • <ok>、YANG 検証、complete 通知、running の一致は、それぞれ狭い事実にすぎない。startup、intended、operational、パケット、そして複数装置の最終状態は別に確かめなければならない。

通信を失った後、装置だけが約束を覚えていた

遠隔拠点の管理経路を変更する。オペレーターは candidate に設定を作り、検証し、confirmed commit を送る。装置は <ok> を返す。新しい running 設定が動き始めた直後、SSH セッションが落ちる。新経路からも戻れない。

この場面で人間は回復コマンドを送れない。しかし通常の confirmed commit なら、装置はすでに次の行動を約束している。開始セッションが確認前に終了すれば、変更前の設定を復元する。確認期限が尽きても復元する。確定前に再起動しても復元する。

重要なのは、<ok> の時点で設定変更そのものは仮想的ではなかったことだ。candidate は running に入り、ルーティングやインターフェース、アクセス制御を変え得る。仮だったのは、その状態を残してよいという決定である。

confirmed commit は、オペレーターが自分で管理経路を切る事故に対して、装置側に戻り道を持たせる。だが装置が覚えているのは設定復元の契約であって、組織の承認理由でも、データプレーンの成功でも、ネットワーク全体の原状回復でもない。この範囲を狭く保つほど、機構は信頼しやすくなる。

candidate から running へは、確認前に渡っている

RFC 6241 で :candidate を広告するサーバーは、稼働中の設定を直接変えずに完全な候補を組み立てる場所を提供する。通常の <commit> は candidate の内容を running にする。:confirmed-commit:1.1 は、このコピーの後に復元条件を加える能力であり、candidate の前で待つ承認ゲートではない。

confirm-timeout が省略された場合、既定値は 600 秒である。後続の commit で手続きを完了でき、再度 confirmed commit を送れば規則に従って期限を延長できる。<cancel-commit> は明示的に旧状態へ戻す。期限切れも同じ復元責務を発生させる。

そのため、運用記録は少なくとも以下を区別する必要がある。

  • candidate がモデルに適合した時点
  • candidate が running に入った時点
  • confirmed commit が完了した時点
  • 取消し、期限切れ、切断、再起動で復元した時点
  • final running が startup に保存された時点
  • 実装とネットワークの挙動が確認された時点

すべてを「適用済み」という一語にすると、安全機構が残した差異を監視側が消してしまう。

RFC 6470 は confirmed commit の通知に start、extend、complete、cancel、timeout というイベントを定める。開始と延長では期限も扱える。この語彙は有効だが、通知は決定を実行する主体ではない。収集側が取り逃すこともあり、complete の後にハードウェア適用が続くこともある。RPC、セッション、ユーザー、候補と旧 running のフィンガープリント、期限、通知、最終状態を一つの時系列にしなければ証拠にならない。

600 秒を安全値と呼べない理由

標準の既定値は相互運用のための初期値であって、全変更に共通するリスク判断ではない。アクセスリストの変更、巨大なルートポリシーの再評価、物理リソースの再構成では、異常が見えるまでの時間が違う。短い期限は有害状態の寿命を抑える一方、遅い障害を観測する前に戻ってしまう。長い期限は十分な観測を可能にする一方、暫定状態と並行変更の時間を延ばす。

期限の設計には、何を確認すれば確定してよいかが先に必要である。管理接続が戻っただけでよいのか。隣接関係、経路選択、FIB、双方向パケット、サービス応答まで待つのか。誰が延長でき、何回まで許すのか。観測が得られない場合は延長するのか、取り消すのか。

複数装置ではタイマー開始もそろわない。コントローラーが順番に RPC を送るため、最初の装置と最後の装置で期限がずれる。画面に一つのカウントダウンしかなければ、共有されていない確定時刻を共有しているように見せる。装置ごとのサーバー時刻と受理時点を証拠にする必要がある。

セッションを越えると、決定権の所在が変わる

通常形は開始セッションに手続きを結び付ける。切断を検出すれば復元するため、開始者が接続を保てること自体が確認前の条件になる。遠隔管理経路の変更では、この性質が強い安全策になる。

一方、分散した自動化では、同じセッションを維持することが適切とは限らない。開始ジョブと検証ジョブを分けたい。障害対応者が別回線から引き継ぎたい。そこで開始者が不透明な persist 値を渡すと、confirmed commit はセッション終了後も存続する。別セッションは一致する persist-id を用いて、該当する確認、延長、取消しを実行できる。

ここで移転するのはプロトコル上の継続能力であって、人物の身元や独立承認ではない。サーバーは値の一致を調べる。二人目が一人目と別組織か、変更内容を読んだか、承認権を持つかまでは証明しない。一つのオーケストレーターが別セッションから自己確認しても仕様上は成立する。

提案者と確認者を分離したいなら、別の認証主体、NACM 権限、職務割当て、監査保管が必要になる。生の persist 値をログに広く残すのも危険である。監査用には保護されたハッシュを残し、使用可能な値は限定された保管経路に置くべきだ。証拠がそのまま権限になってはならない。

復元は「自分が触った行だけ」を知らない

confirmed commit の rollback を、編集差分の逆パッチだと考えると並行変更を見誤る。サーバーが担うのは、手続き開始前の設定状態を復元することである。RFC 6241 は、confirmed commit 後に行われた他の設定変更が、その復元で変更または削除され得ると警告している。

たとえば変更 A が五分の期限で running に入り、二分後に別システムが変更 B を追加する。A が timeout したとき、装置は組織上の「B は無関係」という説明を知らない。保持している旧状態へ戻すなら、B も失われる可能性がある。

排他制御はこの境界を明示する。NETCONF の全体ロックは対象 datastore への他セッションの書込みを排除する。RFC 5717 の部分ロックは範囲を絞れるが、running で confirmed commit が進行中なら、新たな部分ロックを拒否しなければならない。サーバーがより広い状態を復元する必要があるからだ。

ロックは正しさを認定しない。実際に覆った範囲について排他を与えるだけである。他 API、内部エージェント、緊急アカウントが同じ境界を尊重するかも別問題だ。ロックの所有者、対象ノード、取得と解放、競合した書込み、復元前後の状態まで記録して初めて「安全に戻れる」という主張になる。

RESTCONF の書込みが NETCONF の確定を終わらせる

同じ装置上では、プロトコルの境界と状態の境界が一致しない場合がある。RFC 8040 は、NETCONF と概念上の datastore を共有する RESTCONF を定める。candidate を用いる構成では、RESTCONF の編集は candidate を自動的に commit する。

非永続の NETCONF confirmed commit が未完了なら、この新しい commit は確認として作用する。RESTCONF クライアントは「確認」という RPC を送らなくても、NETCONF が残していた復元窓を閉じ得る。別チーム、別 API、別目的の書込みが、同じ running の確定権限に参加している。

永続形では扱いが変わる。RESTCONF には persist-id を渡す場所がない。未完了手続きがその値を要求するなら、編集は HTTP 409 in-use で失敗しなければならない。NETCONF ロックが datastore を塞いでいる場合も 409 になり得る。このエラーは単なる競合ではなく、確定権限または排他権限がまだ別の手続きにあることを示す。

startup の扱いにも経路差がある。RFC 8040 は、同居サーバーが startup をサポートするとき、成功した RESTCONF 編集で startup も自動更新すると定める。通常の NETCONF <commit> から同じ結果を推測してはいけない。どの API が書いたかは、再起動後の結果に関わる証拠である。

認証、認可、モデル適合は同じ緑ではない

RFC 6242 の NETCONF over SSH は、通信路を保護し、導入した方針に従って相手を認証する。しかし、そのユーザーが <commit> を呼べるか、特定インターフェースを変えられるかは決めない。

RFC 8341 の NACM は、プロトコル操作、データノード、通知へのアクセスを分けて評価する。認証済みセッションが操作を拒否されることも、許可された操作が禁止ノードに達することもある。復旧用セッションに実装固有の例外があるなら、その強い権限こそ追跡が必要だ。

RFC 7950 の YANG 1.1 は型、構造、参照、制約を定義する。検証合格は、そのモデルに照らして候補が整合するという意味である。正しい型のアドレスが誤った拠点のものでも合格し得る。完全な参照を持つポリシーがサービスを停止させることもある。

さらに、検証したモデルの版と実装状態を固定する必要がある。RFC 8525 の YANG Library は、モジュール、feature、deviation、datastore との関連、サーバー固有の content-id を公開する。準備と commit の間にこの状態が変われば、同じ文字列でも解釈契約が変わり得る。

running が確定しても operational は追いつかないことがある

RFC 8342 の NMDA は、running を complete な現在設定、intended を変換後にシステムが適用しようとする設定、operational を実際に使用中の設定と状態として区別する。

存在しないリソース向けの設定は running と intended に残りながら、operational の適用済み設定には現れないことがある。物理的制限、内部依存、非同期処理、他プロトコルの状態により、適用が遅れたり差が生じたりする。confirmed commit が complete になっても、この差は自動的には消えない。

確認方法は変更対象に合わせる。インターフェースなら実効状態とパケット、ルーティングなら隣接、候補経路、選択、インストール、転送、管理経路なら新旧の到達性を確認する。running の差分は設定権限の証拠であり、データプレーンの証拠ではない。

承認チケット、SSH 認証、NACM 認可、YANG 検証、running 確定、intended 生成、operational 適用、ネットワーク成功は、順番に並ぶ別の現実層である。前の層が正しくても次の層は失敗できる。

装置を増やしても二相コミットにはならない

RFC 6244 は NETCONF と YANG を用いたネットワーク管理の全体像を説明する。コントローラーは confirmed commit を複数装置変更の材料にできる。しかし、同じ RPC を十台に送っても分散トランザクションにはならない。

各サーバーが別々の旧状態を保存し、別々のタイマーを始め、別々のロック、権限、再起動、ハードウェア制約に従う。九台から <ok>、一台からエラーが返れば、その瞬間に部分状態が生じる。九台を先に確認すれば部分状態を確定する。九台を取り消しても、元の operational と転送が戻った証拠は別に必要だ。

上位のオーケストレーターが、共通トランザクション ID、装置ごとの基準状態、開始と確認の順序、中止条件、カナリア、補償、照合を定義しなければならない。段階展開を選ぶことも、厳しい全台条件を選ぶこともできる。選べないのは、複数の <ok> を一つの確定時刻と呼ぶことである。

狭い仕様を、狭い主張のまま使う

IANA の NETCONF Capability URN は、candidate、confirmed commit、startup、validate などの共通名を登録する。共通仕様が薄いのは弱さではない。異なる実装が最低限の意味を共有し、期限、職務分離、ロック、観測、複数装置方針を現場が選ぶ余地を残している。

信頼できる報告は、こう限定される。このユーザーとセッションが、この schema と認可の下で、この candidate を、この基準状態から running に置いた。この期限とセッションまたはトークンが確定を支配し、このイベントで終了した。startup はこの状態、intended と operational はこの状態、パケットとサービスはこの結果だった。複数装置なら各結果を照合した。

図面上の承認者ではなく、実際に RPC を送り、トークンを保持し、期限を延ばし、確認し、startup を書き、観測基準を決められる主体が実務上の権限を持つ。その実行可能な権限を分けて見せることが、confirmed commit を儀式ではなく統治にする。

出典