要約

  • RFC 6643はSMIv2のMIBモジュールをYANGへ変換し、NETCONFによる読み取りを可能にする。元の書き込み属性だけで、新しい設定操作が自動的に成立するわけではない。
  • SNMPでは保存の意味が個々のオブジェクトや行に置かれる場合がある。NETCONFの設定ではデータストアの性質が関わるため、同じ値を表示できても保存契約は一致しないことがある。
  • 意味を維持できる一部のノードは、別の偏差モジュールで設定可能にできる。その限定的な対応と、管理業務全体の移行完了は区別する必要がある。

次に生成し直す人が、何を知らなければならないか

変換したモデルが一度動けば、作業は終わったように見える。だが運用の引き継ぎでは、別の問いが出てくる。新しい担当者が同じ元ファイルからモデルを生成し直したとき、現行機器で使われている意味まで再現できるだろうか。

誰かが生成後のファイルだけを調整していた場合、その変更は再生成で消えるかもしれない。元の定義と生成結果が残っていても、実装固有の偏差が記録されていなければ、担当者は実際とは異なる有効モデルを組み立てる可能性がある。これは特定の事故を報告するものではなく、保守上の仮想的な場面である。

RFC 6643は、生成したYANGを直接修正するより、元のSMIv2に必要な変更を加え、更新・改訂情報を整えて再生成することを勧めている。別モジュールによる拡張や偏差は利用できる。共通の生成基準と個別の違いを分けておく考え方だ。

この区別はファイル管理だけの問題ではない。変換が何を保持し、どの操作を実装側が追加したのかを説明できるかどうかに関わる。移行の成果を受け取る側に必要なのは、最後に動いたファイルだけではなく、そのファイルが引き受けている仕事の範囲である。

そもそも、何を渡すための橋だったのか

2012年7月に公表されたRFC 6643の目的は明確だ。SMIv2のMIBモジュールをYANGへ変換し、そのデータオブジェクトをNETCONFから読み取れるようにする。元のモデルで書き込みやインスタンス作成が定義されていても、変換結果が自動的に設定用モデルになるわけではない。

管理対象オブジェクトを収める生成時の最上位コンテナには、config falseが要求される。一方、元のMAX-ACCESSはsmiv2:max-accessという拡張文に対応づけられる。古い定義の「書ける」という情報は、新しいモデルの「設定ではない」という分類と同時に存在し得る。

ここで保存された属性を、新しいサーバーが実行する操作と取り違えてはならない。前者は出自を説明する情報であり、後者は対象実装が提供する振る舞いだ。同じ名前のオブジェクトが画面に現れたことは、元と同じ変更経路を手に入れた証拠ではない。

もちろん、意味がすべて失われるわけでもない。説明、参照、型、オブジェクト識別子などには変換規則がある。元の知識を残すことと、その知識を設定操作として実行可能にすることは別である。読み取り専用の変換は、この差を隠さずに提供できる機能を定めている。

観測の統合だけを求めるなら、その機能で十分な場合もある。既存の設定手段を残したまま、取得情報の利用方法を整理する設計は成立する。問題は、観測の統合に合格したという理由だけで、設定手段の廃止まで合格扱いにすることだ。

保存先が変われば、同じ値でも約束が変わる

自動的な設定化を妨げる理由を、RFC 6643の第11節は保存の意味の違いから説明している。SNMPでは、オブジェクトの説明文や所属する概念行の性質が永続性を決める場合がある。StorageTypeを使う列で管理する場合もある。NETCONFの設定データでは、入れ先であるデータストアの性質が関わる。

変換器が名前、型、値を扱えることと、この二つの約束を一致させられることは同じではない。保存の意味が元のどこに記されているかを探し、移行先で同じ意味を持たせられるかを判断する仕事が残る。

RFC 2579のStorageTypeを見ると、単に「残るか、消えるか」だけでは足りないことが分かる。揮発性の行は再起動で失われる。それ以外のいくつかの種類は安定した保存領域に支えられるが、変更規則は共通ではない。permanentの行は変更できるが削除できず、readOnlyの行は変更も削除もできない。

さらに、保存形式を示すオブジェクト自体の変更にも制約がある。したがって「永久」という名称を、行の中のすべての値が不変だという意味に広げてはならない。保存されることと、誰に変更権限があるかも別の問題だ。

移行先についても、NETCONFなら自動的に保存が保証されると考えるのは誤りである。RFC 6241の基本モデルには稼働中の設定であるrunningがあり、追加のデータストアは機器が表明する能力に依存する。runningへの直接書き込みも、対応する能力で扱われる。

独立した起動設定を持つ機器では、稼働中の設定を変更しても起動設定へ自動ではコピーされない。runningからstartupへの明示的なコピーが別の操作になる。同じ値を直後に読み返せたとしても、次の起動時に何が使われるかまでその観測だけでは説明できない。

ここで重要なのは、実機に再起動試験を行うよう求めることではない。移行を承認する資料が、どの保存先と能力を前提にしているかを明記することだ。試験や変更の必要性と安全な実施方法は、対象システムの運用判断に属する。

また、RFC 6241の設定編集やコピーは、任意の稼働状態を書き換える汎用操作ではない。読み取れる値の中には、設定として再投入するものではなく、機器の現状を表すものがある。書き込み移行を考える前に、何を変える行為なのかを分類する必要がある。

限定した例外を、全体の許可に広げない

RFC 6643は、両側の保存の意味が整合する一部のオブジェクトについて、生成されたノードを設定データとして実装する道を残している。その違いは、別のYANG偏差モジュールで正式に記述することが勧められる。

この変換規則では、他の意味を変えずにconfig falseをtrueへ変更する場合について、生成元のSMIv2モジュールとの適合性を損なわないという限定した扱いが示される。だが、その扱いから全オブジェクトの整合性が証明されるわけではない。どのノードなら条件を満たすかは、なお個別の判断だ。

仕様のRMON2制御表の例は、関係する階層やノードをそれぞれ示し、モジュール、改訂、偏差を能力表明に載せる形を説明する。偏差は対象ノードに作用するのであって、配下を一括して設定可能にする宣言ではないという注意もある。

これは、configを省略したときの通常の既定値継承とは区別しなければならない。後のYANG 1.1仕様であるRFC 7950は、親からの値の継承、状態ノード配下に設定ノードを置けないこと、表明された偏差を適用した後もモデルが有効でなければならないことを定めている。一行だけを見て実装の能力を判断することはできない。

限定的な追加は、必ずしも中途半端な成果ではない。意味を確認できた操作だけを移し、残りは明示的に旧経路で支えることができるからだ。すべてを同じ設定契約に押し込まなければ、一部の移行も認めないという考え方には根拠がない。

修正履歴が証明する範囲

公開された訂正も、範囲を区切って読む必要がある。検証済みの技術的な正誤表4786は、2016年8月に通知の変換規則を修正した。現在扱うオブジェクトがすでにインデックスの一部である場合、同じ葉ノードを重複して生成しないようにする訂正である。

この訂正から言えるのは、該当する生成規則を見直す必要があるということまでだ。書き込み権限や永続性の保証が増えたわけではない。変換結果の構造に関する修正を、管理業務全体の移行完了へ拡大解釈してはならない。

RFC Editorの文書記録も、公開時期や文書の位置づけを確認する資料である。そこに標準が存在することは、特定の機器がどの改訂と偏差を実装しているかを示さない。文書、生成物、実装、受け入れた業務の間には、なお確認すべき関係がある。

日常の画面と、例外時の道具

新しい画面は毎日使われる。旧管理ツールは、まれな設定変更のときだけ必要になる。このような構成は仮に選ばれたとしても、それ自体で不合理ではない。ただし、使用頻度が低いことと、維持責任がなくなったことは同じではない。

旧経路が仕事を引き受けている間は、権限、アクセス方法、担当者の知識、保存に関する前提を保つ必要がある。日々の読み取りがすべて移ったという数字では、この負担を測れない。実際に廃止できた機能に基づいて費用を評価することが重要になる。

読み取り専用だから安全性の判断が不要になるわけでもない。RFC 6643は元のMIBが扱う情報の機微性やNETCONFのアクセス制御を参照するよう促している。変更できない情報であっても、誰に開示してよいかは別に考えなければならない。

本稿は、Lu Hengによる象徴的な表現と実行可能な力の区別、および支配と結果責任の不均衡への視点を参照している。管理移行への適用はDaniel Kadeの分析であり、Lu Hengがこのプロトコルを評価したという意味ではない。

資料から確認できるのは規範上の仕組みと訂正であり、普及率、実測の費用削減、実機の適合性や事故ではない。本稿のために機器を変更したり、プロトコル試験を実施したりはしていない。旧システムを廃止できるかどうかは、対象業務と実装に固有の証拠で判断する必要がある。