要約

  • RFC 3532は、稼働中の仮想スイッチング要素を動的に再分割するとき既存状態を維持するよう求める。一方、すべての制御プロトコルに事前通知を必須とはしておらず、コントローラは後の要求失敗と資源照会で初めて減額を知り得る。
  • 「再分割成功」という一語では、権限、使用中資源、凍結と排出、認識経路、パーティション間サービス、未変更パーティション、データ面、アプリケーション結果を証明できない。

動的変更の魅力は、停止を見せないことにある。RFC 3532が対比する静的な再分割では、影響を受けるパーティションのコントローラを切断し、通常は構成状態を解放し、仮想スイッチング要素を停止してから状態を作り直す。動的方式では稼働したまま資源を変え、既存状態を維持しなければならない。

しかし、停止が見えないことと、変化が存在しないことは別である。制御セッションが継続していても、コントローラの内部モデルが更新されたとは限らない。転送状態が残っていても、縮小後のキュー、バッファ、帯域、接続数で同じサービスを続けられるとは限らない。再起動を避けたことで、証拠の必要がなくなるのではなく、証拠の境界が細かくなる。

この文書は2003年5月のInformational RFCであり、いかなる種類のインターネット標準も規定しないと明記する。完成したプロトコルではなく要件文書である。主な対象はGSMPスイッチの分割で、非GSMPスイッチや最長一致転送装置には必要かもしれないが十分とは主張していない。

一つの装置に見えても権限は四層に分かれる

スイッチング要素（SE）はパケットを転送し、分割可能な資源を提供する。パーティション、すなわち仮想SEは、その資源の一組である。コントローラが稼働中パーティションを操作し、パーティションマネージャ（PM）が仮想SEの数と各割り当てを決める。

PMからSEへの操作は割り当てを変える。コントローラからパーティションへの操作は実行状態を作る。PMとコントローラの対話は、稼働中の資源変更を交渉する。この三つを「設定変更」という一件に畳むと、誰が決定し、誰が実施し、誰がまだ知らず、誰が利用していたかを失う。

これらは論理エンティティであり、同じ物理システムに同居することも別のシステムに分散することもできる。論理分離は物理的隔離や独立障害領域の証拠ではない。同居も権限の差を消さない。記録には論理的役割と、その時点で役割を担った実体の双方が必要である。

RFCは、所有者がSEを分け、第三者に仮想SEの制御を貸す例を示す。これは特定の商取引の証拠ではない。賃貸契約上の権利、PMの再分割権限、コントローラの操作権限、SEが実際に強制する上限は別々の事実である。

時刻は少なくとも四つある

最初は割り当て時刻である。認可されたPMの要求をSEが適用し、資源台帳が変わる。次は認識時刻であり、コントローラが新しい上限を知る。さらに適応時刻があり、内部スケジューラや要求生成が新しいモデルを使い始める。最後にサービス観測時刻があり、データ面とアプリケーション結果を測る。

事前通知があれば、割り当て時刻と認識時刻の距離は短くできる。それでも通知の送信、到着、処理、モデル更新は同じ事実ではない。通知がなければ、その距離は次の要求まで伸びる。その要求が汎用エラーだけを返す場合、原因を確定する資源照会までさらに伸びる。

この時間差の中では、SEが新上限を正しく強制しながら、コントローラが古い上限に対して内部的には一貫した判断をすることがある。結果だけ見れば「時々起きる資源不足」に見える。時刻と因果型を保存すれば、割り当て故障、通知遅延、モデル更新失敗、正当な上限到達を区別できる。

運用画面は一つの最終状態だけでなく、これら四時刻を並べるべきである。緑の「変更済み」は割り当てだけを示すのか、コントローラ確認まで示すのか、サービス検証まで示すのかを明示しなければならない。

使用中の資源は縮小要求を拒否させる

SEは、コントローラが現在の割り当てを超えて資源を使うことを防がなければならない。ただし、新しい上限を作るために使用中資源を黙って消してよいという意味ではない。

PMが稼働中パーティションから資源を解放しようとし、その対象のどれかが使用中なら、SEは要求を拒否しなければならない。この拒否は正しい保護動作である。未使用資源の移動と、稼働中接続の破壊を同じ「回収」にしないための境界である。

拒否の後、PMはパーティションを凍結するか、コントローラに利用量低減を求めるか、その両方を行うことが望ましい。凍結パーティションは未使用資源を手放し、既存接続を残し、それらが閉じるたびに資源を返す。通常稼働でも即時停止でもない。新規拡張を抑えながら既存作業を排出する状態である。

コントローラが必要量を返さない場合、PMは仮想電源オフによりパーティションを非稼働にし、コントローラを切断できる。永久占有を避ける最後の手段だが、非破壊の成功ではない。最終的に資源が空いたという結果だけで、動的縮小が平滑に完了したと報告してはならない。

証拠には旧割り当て、実使用量、要求値、資源種別、拒否または適用、凍結開始、接続ごとの排出、強制切断の有無を残す。現在値だけでは、どの仕事を犠牲にしてその値を得たのか分からない。

通知は事前、明示的事後、暗黙的事後、直接連絡に分かれる

制御プロトコルは、SEが再割り当てを非同期に知らせる事前通知を備えてもよい。しかしRFC 3532は、反応的通知が必須であることを理由に、事前通知を一律の必須要件にはしていない。

明示的な反応通知では、後続要求が失敗し、資源が再割り当てされたことを示す専用エラーを返す。暗黙的な反応通知では、一般、未知、または資源関連のエラーだけが返る。コントローラは利用可能資源を問い合わせ、再割り当てが不足の原因か判断しなければならない。

PMがコントローラへ直接伝える方法もある。この経路には送信者の権限、宛先、配送、受領、内部モデル更新の証拠が必要である。「メッセージ送信済み」は認識済みではない。「専用エラー返信済み」も正しい適応の証明ではない。

各経路は記録上区別する。事前通知ID、明示エラー型、暗黙エラーと後続照会、または認証されたPM連絡を保存する。その後にコントローラのモデル版、確認、再試行結果を結ぶ。認識経路が空欄なら、SE台帳が正しくてもコントローラ認識は不明である。

SEの在庫照会はコントローラの記憶を読めない

PMはSEの資源、構成済みパーティション、各割り当てを照会できなければならない。PMとコントローラの自動対話のため、仮想SEに接続したコントローラのアドレスもSEから取得できなければならない。制御プロトコルと版を得られる場合もある。

この情報はSE側の台帳として重要である。どの資源がどのパーティションにあるか、誰に連絡すべきかを示す。しかし、コントローラが通知を受けたか、新上限を採用したか、不要な要求を止めたか、サービスを維持したかは示さない。

PMの希望とSEの報告が違えば、まず適用または調停の問題である。両者が同じでもコントローラが旧上限を使えば、認識または適応の問題である。三者が一致しても利用者が失敗すれば、データ面やアプリケーションへ調査を進める。一つの「同期異常」でまとめるべきではない。

照会結果には観測時刻がある。SE、パーティション、資源スキーマ、応答ダイジェスト、各値を固定し、後の照会で上書きしない。事故後の最新値は、失敗要求が出た瞬間の旧認識を再現できない。

パーティション間サービスは影響範囲を横断する

SEは仮想SEから別の仮想SEへ、仮想リンクのようなサービスを提供できる。SEは利用可能なパーティション間サービスを公開し、PMはそれを構成できなければならない。仮想ポートの追加や削除が起き、制御プロトコルが通知を支える場合、SEは接続コントローラへ通知しなければならない。

そのため、台帳上は一つのパーティションだけが変更されても、別のパーティションが利用する依存サービスは変わり得る。直接の再分割対象でないことは、結果まで無関係である証拠ではない。

検証は二方向に行う。影響集合外の代表的パーティションについて、割り当てとプロセス識別子が維持されたことを確認する。同時に、変更境界をまたぐサービスを列挙し、仮想ポート、容量、到達性を試験する。前者は不要な全体停止を防ぎ、後者は実在する依存を見落とさない。

同じ筐体、管理設定、プロトコルを共有するだけで、すべてを再起動対象にしてはならない。実際に変わる割り当て、実行入力、直接依存、必要移行から影響を導く。

認証は安全な容量を保証しない

動的再分割を行えるのは認可されたPMだけである。SEは、認可された主体が制御PMを選ぶ安全な手続きを備えなければならない。選択は明示的でも、認可された発見機構でもよい。コントローラに資源削減を求めたり増加を知らせたりできるのも、そのPMまたは認可代理だけである。

逆方向では、PMは資源変更要求が指定仮想SEを操作する権限を持つコントローラから来たことを認証しなければならない。別のテナントが他者の割り当てを動かすことを防ぐ境界である。

認証は、設定された信頼手続きの下で誰が資格情報を示したかを答える。認可は、その主体がこのパーティションでこの操作をしてよいかを答える。商業上の権利、容量の安全性、SEでの適用、利用者結果は答えない。

PM選択記録は変更時点ごとに保存する。後で有効になった管理者が、以前の未認可要求を遡って正当化してはならない。要求を当時の選択状態、資格情報、方針版、パーティション、内容ダイジェストに結び付ける。

後続RFCは運用証拠ではない

RFC 3654とRFC 3746は、転送要素と制御要素の分離について後の要件と枠組みを述べた。RFC 5810とRFC 5812はForCESプロトコルと転送要素モデルを規定し、RFC 7121はForCESの高可用性を扱う。設計史の文脈にはなる。

しかし、これらはRFC 3532を標準に変えず、欠けた運用収票を補わず、ある装置がForCESを使ったことも証明しない。RFC 3654とRFC 3746はInformational、RFC 5810、RFC 5812、RFC 7121はProposed Standardであり、それぞれの範囲と日付を保つ。

書誌メタデータ、履歴、正誤表も文書識別には役立つが、稼働パーティションを観測しない。系譜は採用証明ではない。

変更の順序を失わない収票を作る

まずSE、PM、コントローラ、パーティション、物理配置、PM選択、資格情報、方針版、要求ダイジェストを記録する。決定的資源の種類、旧割り当て、観測利用、新しい希望値を添える。

次にSEの判断を記録する。未使用分の即時解放、使用中による拒否、凍結、コントローラとの解放交渉、仮想電源オフを区別する。維持した状態と、新上限での強制動作を確認する。

その次に認識を記録する。事前通知、明示的反応エラー、暗黙エラーと照会、直接PM連絡のいずれかを示し、コントローラのモデル更新と再試行を結ぶ。変更後のSE照会は必要だが、コントローラ確認の代わりではない。

最後にパーティション間サービス、変更外パーティション、データ面容量、アプリケーション結果を調べる。PMは要求、SEは割り当て、コントローラは内部モデル、サービス所有者は動作、アプリケーション所有者は利用者結果だけを証明する。

短い報告が必要なら、「認可PMが未使用のこの資源をこの時刻に変更し、SEはこの状態を維持し、コントローラはこの経路で知って新モデルを採用し、依存と結果を後で観測した」とする。まだ観測していない部分を成功語で埋めない。

Evidence boundary

本稿は、実装、ベンダー、運用者、SE、PM、コントローラ、テナント、契約、資源プール、パーティション、展開、障害、停止、セキュリティ事象、顧客結果を特定しない。現在の採用、容量、利用率、損失、遅延、サービス結果も報告しない。

RFC 3532は2003年5月のInformational要件文書として扱い、インターネット標準や完成プロトコルとは扱わない。決定的分割の前提を統計共有や過剰予約へ一般化しない。後のGSMP、Megaco、ForCES資料は各自の日付、状態、範囲を保ち、実システムの適合を証明しない。

開示したHeng Luのノートは、権限を制御対象に限定し、稼働コードの証拠で結果を閉じるという編集上の視点を与える。IETFの意図、実装動作、展開事実を確立するものではない。

限定された結論は、稼働中パーティションが再起動なしに再割り当てされても、コントローラの認識は後の通知、エラー、照会、直接連絡まで遅れ得るということだ。状態維持と新在庫はいずれも必要だが、サービス結果ではない。

Sources