要約

  • RFC 3512 は、管理上の要求値と実際の動作状態を同じ読み書き可能オブジェクトで表すと、SET 完了後も旧状態が返るような見かけの矛盾が生じると説明する。プロトコル成功と物理・論理遷移の完了は別の証拠である。
  • 変更記録は、要求者、MIB の意味、変更前後値、依存行、管理状態、動作状態、起動遅延、永続化、収束、サービス試験、外部変更、復元可能性を一つの識別子に結び付けなければならない。

管理アプリケーションは回転方向を反転する値を SET した。応答はエラーなしだった。ところが直後の GET は、まだ元の方向を返した。

RFC 3512 の例では、車輪は命令を無視していない。逆回転する前に減速し、停止しなければならない。一つのオブジェクトが「何をせよ」と「今どう動いているか」を同時に表したため、二つの時刻が衝突した。

RFC 3512 は 2003 年 4 月に Informational RFC として公開された。SNMP による設定の実践を扱うが、通信成功を運用成功に拡張しない。むしろ MIB、エージェント、下位サブシステム、管理アプリケーション、検証がそれぞれ証拠を持つべき理由を示している。

指示値と現在値を分ける

設定対象が瞬時に変わるとは限らない。プロセス起動、経路収束、ポリシー読み込み、資源割り当てには遷移がある。管理値が更新された瞬間と、実際の機能が新しい状態に達する瞬間は異なる。

RFC 3512 は、管理制御用オブジェクトと読み取り専用の動作状態を分ける設計を勧める。前者は要求を記録し、後者はサブシステムが現在何をしているかを示す。

この分離がなければ、監視は古い値を「失敗」と誤認するか、新しい値を「完了」と誤認する。どちらも時刻の違いを状態の真偽に変えてしまう。

証拠には遷移開始、途中状態、完了条件、観測完了時刻が必要だ。固定時間待ってから成功とするだけでは、遅延を測ったことにならない。

SET の応答範囲は狭い

RFC 3512 が目指すトランザクション完全性は、変更全体が実行されるか、されないかである。しかし変更は、一つのオブジェクトから複数表、複数装置まで広がり得る。SNMP プロトコル層だけの完全性では足りないと明記されている。

一つの PDU に多数の varbind を入れれば、往復を減らし、関連値をまとめて処理できる場合がある。それでも、参照先の準備、別表のコミット、サブシステムの起動、多装置の同期を自動的に保証しない。

成功の定義は MIB と管理アプリケーションにも存在しなければならない。何が準備済みか、どこまでコミットしたか、どのエラーが後段で発生したかをモデルが表せなければ、応答コードから復元することはできない。

noError は一つの処理境界の結果であり、サービス全体の判定ではない。

active は表の内側の言葉である

RFC 2579 の RowStatus は、概念行の作成、起動、停止、削除を管理する。RFC 3512 は、行を active にすることで、その表の定義に従ってコミットできると説明する。

ただし、設定が複数表に分かれる場合、別の制御行や起動オブジェクトが全体を確定することがある。表同士の fate sharing、つまり一方の作成・削除が他方に何を起こすかも明示されなければならない。

ある行が active でも、参照行が未準備、資源が未割当、サブシステムが停止中という組合せはあり得る。active はローカルなライフサイクル証拠であり、サービス結果を相続しない。

RowStatus を単純な有効・無効スイッチにすることにも危険がある。notInService に長く置かれた行は削除され得る。動作停止と設定保存は別の制御であるべきだ。

永続化は第三の時間軸である

現在の動作が変わっても、再起動後に同じ値が戻るとは限らない。RFC 3512 は、次の変更や再初期化までだけ有効な設定と、受理時に永続化される設定を区別する。

StorageType は volatile、nonVolatile、permanent などの意図を表せる。しかし実際の保存方法と時点は、下位システムとエージェント実装に支配される。

従って、受理、現在動作、再起動復元には別々の受領証がいる。現在値の GET は不揮発書き込みの完了を証明しない。

バックアップも復元証拠ではない。物理・論理インデックスが変われば、同じオブジェクト列が別の対象を指し得る。対象トポロジー上での復元試験が必要になる。

応答が消えても変更は消えない

RFC 3512 は、最初の SET がエージェントで成功したのに Response PDU が失われ、管理側が再送する例を示す。

タイムアウトは観測の欠落であって、未実行の証明ではない。二回目の成功も、一回目の下流効果を説明しない。

プロトコルや MIB 上は同じ値への代入でも、下位サブシステムが状態遷移中なら再実行の意味が異なり得る。エージェントが中間状態を管理したり、複数 SET を蓄えて一度に起動したりする必要がある。

再送前に現在状態を照会し、変更識別子と前後値を照合する。すべての再送が危険なのではない。実際の効果まで冪等かどうかを証明せず、同一メッセージを冪等と呼ぶことが危険なのである。

アプリケーションエラーは別の語彙を要する

RFC 3512 は、SET を受けるオブジェクトのアプリケーションエラーを SNMP のプロトコルエラーだけに依存して表現すべきでないとする。

badValue は入力誤り、資源不足、セキュリティポリシー、エージェント不具合、後段評価失敗を区別しない。一方、プロトコルが値を受理した後、起動段階で失敗することもある。

詳細エラーオブジェクト、完了通知、動作状態がなければ、変更を開始したアプリケーションは原因を持てない。通知には可能な限り開始した管理主体を含め、CLI や HTTP など別経路の変更も手段と利用者を記録すべきだ。

通知そのものは状態全体ではない。RFC 3512 は通知後に関連設定を再取得し、管理側の表現を同期する流れを示す。

設定は再試験で閉じる

RFC 3512 の pre-test、変更と収束待ち、re-test という手順は、検証を設定の一部に置く。

事前試験は既存不安定性を見つける。収束待ちは遷移を認める。事後試験は、値ではなく期待した機能を同じ観測で確認する。

それでも遅い障害は窓外に現れ、他装置が収束を妨げる場合がある。試験対象、時間幅、依存関係、成功条件を保存しなければならない。

サービスを作る変更なら、最終受領証はサービス側の独立試験が発行する。SET 応答や active 行は必要条件になっても、その試験を代行できない。

後続 RFC は境界に名前を与えた

2003 年 5 月の Informational RFC 3535 は、SNMP の監視能力を評価しつつ、書き込み可能 MIB の限定的配備、トランザクション実装、ロールバック、設定再生、運用タスクとデータ中心モデルのずれを記録した。

2011 年の Standards Track RFC 6241 は NETCONF を定義し、設定データと状態データを分けた。2018 年の Standards Track RFC 8342 は running、intended、operational を区別し、running から適用まで変換があり得ることを示す。

これらは後の比較語彙であり、RFC 3512 に遡って存在した機能ではない。また、新しいプロトコルを使うだけでサービス検証が完了するという証明でもない。

変わらない問いは、要求状態が実動状態になったことを誰が何で確かめるかである。

最小受領証

要求内容、開始者、アクセス文脈、request-id、装置・ソフトウェア、MIB と改訂、対応能力、変更前後値、関連行、参照、fate-sharing 規則を保存する。

管理状態、動作状態、起動時刻、サブシステム遅延、永続化先と完了、通知、詳細エラー、管理外変更、依存収束、サービス試験を同じ変更 ID に結ぶ。

複数装置では予定起動窓と実時刻を各装置ごとに残す。バックアップとロールバックは対象環境で試験する。再起動後の復元にも独立検証を置く。

この連鎖をたどれる場合に限り、「成功」はどの成功を要約したか説明できる。

証拠の境界

本稿は特定のベンダー、製品、装置、ネットワーク、顧客、変更、障害、事故を扱わない。現在の SNMP 設定利用率や、未知の実装動作を主張しない。

RFC 3512 は 2003 年 4 月の Informational な実践指針であり、Internet Standard やトランザクション保証ではない。RFC 3535 はワークショップ報告、RFC 6241 と RFC 8342 は後年の Standards Track 比較資料である。

Heng Lu の最小初期仕様と running-code primacy は、明示した編集上の分析視点であり、SNMP の測定データでも IETF の意図でもない。

結論は狭い。管理値が変わったことは、動作状態が追いついた証明ではない。

情報源