要約

  • RFC 2391は一つの仮想アドレスの背後にサーバープールを置き、新規セッションごとに選んだ一台を変換状態として固定した。
  • ラウンドロビン、セッション数、通信量、重み、経路コスト、死活確認は選択材料であり、アプリケーションの余力や処理成功を証明しなかった。
  • 障害サーバーへの新規割り当てを止めても、既存セッションは移せない。選択、同一性維持、切替、結果は別の証拠だった。

一つのアドレスが隠した二つの事実

クライアントから見える事実は単純だった。サービスには一つのアドレスがある。運用側の事実は違った。需要に耐えるために複数のサーバーがあり、どれに仕事を渡すかを到着のたびに決めなければならない。

RFC 2391は、RFC 1631のアドレス変換とリアルタイムの負荷分散を組み合わせた。LSNATは新しいセッションを受けると、プールから一台を選び、宛先を書き換える。クライアントやサーバーのソフトウェアを変更せず、メンバーの追加や交換を入口で吸収できた。

ただし、仮想アドレスはサーバー名ではなくなった。そのアドレスが示すのは、選択が行われる場所である。プールの構成、適用対象のサービス、採用する指標、除外条件は、見えないローカル判断に移った。

これはRFC 1546のanycastとは異なる。anycastでは、同じサービスアドレスが経路によって別の実体へ届くことが問題となる。RFC 2391では、変換装置が一度選んだ実体を記憶する。焦点はアドレスの多義性ではなく、選択後の表がセッションを拘束する点にある。

「選ぶ」が「覚える」に変わる瞬間

RFC 2391は処理をバインド、検索と変換、アンバインドに分けた。新規セッションのバインドでは、サーバーアドレスとの対応が作られ、その後の全データグラムに使う変換パラメーターが決まる。以後のパケットは表を検索して変換される。終了を検知すると責任を解除する。

往路では宛先アドレスや必要なポートが実サーバー向けに変わる。復路では送信元が仮想サービスに見えるように戻される。チェックサムも更新される。クライアントが一つの相手と話し続けているように見えるのは、途中の装置が毎回同じ記録を適用するからだ。

したがって、要求と応答は同じLSNATを通らなければならない。復路だけ別経路を通れば、期待する変換は起きない。別のLSNATへ経路を変えても、その装置が表を共有していなければ、どの実サーバーとどのポートを選んだか分からない。

文書は限界を明記した。一度ホストへ割り当てたセッションは、終了するまで他のホストへ動かせない。負荷分散は新規セッションを配る機能だった。進行中のTCP状態、認証後の文脈、未完了の処理を移す機能ではない。

観測できる負荷と、使える余力

ラウンドロビンは、最も安価な判断である。順番に割り当てるだけなので、ホスト負荷を考えない。均等な到着が均等な仕事になるには、セッションの費用とサーバー能力が似ている必要がある。

最少セッション方式は表にある件数を数える。だが、一時間ほぼ無通信の接続と、短時間に大量の計算を要求する接続も一件ずつである。数は正確でも、数が代理する負荷は不確かだった。

パケット数やバイト数を見れば、データ面の活動は分かる。それでもRFCは、システム負荷の近似だとした。小さな要求が重いデータベース処理を起動することも、大きな配信がキャッシュから軽く流れることもある。

重み付き方式では、運用者がセッション種別の費用やサーバー能力を数値にした。判断根拠が明示される利点はある。一方、重みは測定ではない。未来の仕事が過去の見積もりに従うという仮定である。

サーバー自身が空き資源を報告する方法も示された。より内側の状態に近づくが、報告周期、転送遅延、意味の統一、古い値という新しい問題が生じる。RFCが述べた通り、遠隔ホストの未使用能力をリアルタイムで正確に知るのは容易ではない。

選択器が持つのは、次を決めるのに十分かもしれない情報である。それは容量そのものでも、処理完了の保証でもない。

経路コストが無限大になっても

サーバーが地理的に分散する場合、経路表から到達コストを得て、割り当て済みセッションや通信量と組み合わせられた。ネットワーク障害で到達不能になったメンバーは、コストを無限大として今後の割り当てから外せる。

経路情報が答えるのは、選択器がどの道を知り、どう評価しているかである。帯域を予約したわけではない。アプリケーションプロセス、データベース、ストレージが正常だとも言っていない。到達可能性は処理可能性より狭い。

この点はRFC 2386の記事と重ならない。そちらはQoS資源地図が予約や配送の領収書にならないことを扱う。RFC 2391が固有に持つのは、その不完全な信号を使って一つのセッションを一台へ拘束する段階である。

仮想アドレス、プール構成、観測値、選択規則、バインド、双方向変換、サーバー応答、アプリケーション結果。それぞれが異なる層であり、前の層は後の層の証明を先取りできない。

死活判定が救ったのは次の到着だった

応答しないサーバーへ新規セッションを送り続ければ、分散装置は障害を増幅する。RFC 2391は、定期的なpingや、新しく割り当てたセッションに対する応答データグラムの観測を提案した。数秒反応がなければ、死んだと判定し、そのホストへ新しいセッションを渡さない。

復帰確認も試験的だった。しばらく待った後、再び新しいセッションを割り当て、反応時間を見る。死活状態は中央の永続的な真実ではなく、ローカルな証拠と閾値から作られる運用判断だった。

ping応答は、アプリケーションの準備完了を示さない。新規要求への無応答も、ホスト、経路、サービス、依存先のどこに原因があるかを一意に示さない。判定は必要でも、証拠の射程は限定されている。

ここから一つの推論が成立する。死活検知の節は、死んだホストに「新しいセッション」を割り当てないとする。別の節は、既存セッションを終了前に移動できないとする。ゆえに、この仕組みは次の誤配を防ぐが、すでに結び付いたセッションを救済しない。

プールとしてはサービス継続中でも、個々の利用者には中断が起きる。残りのサーバー数だけを可用性として表示すると、バインド単位の損失が見えなくなる。

RFC 3022は後に、NAT自体が故障した場合にも同じ依存があると述べた。別装置へ経路を切り替えるだけでは、共有状態がなければフローが失敗する。RFC 3234は、状態の複製があるfailoverと、最初からやり直すrestartを区別した。予備装置の存在と、継続可能な状態の存在は別である。

終了もまた、観測から作る決定だった

バインドは解放しなければ資源を使い続ける。TCPにはFINやRSTがあるが、相手の再起動やパケット損失で終了を観測できない場合がある。UDPには一般的な終了信号がない。アプリケーションが一つと考える会話が、NATには複数セッションに見えることもある。

そこでアイドルタイムアウトが使われる。短すぎれば、正当な沈黙の途中で表を消す。長すぎれば、消滅した会話を残してポートやメモリーを占有する。RFC 2663は、長い休止と終了を一般に見分けられず、NATとアプリケーションのセッション観が一致しないと整理した。

RFC 4787はUDPマッピングの最小時間や更新方向を後に定めたが、実装差が大きいことも記録した。共通下限は相互運用を助ける。沈黙の意味までは確定しない。

アンバインドは単なる掃除ではない。遅れて届いたパケットが同じ相手を見つけられるか、古い責任がいつ消えるか、有限の識別子をいつ再利用できるかを決める。中間装置は会話の始点だけでなく、終点も解釈していた。

LS-NAPTは場所の自由を状態で買った

基本構成では、往復が自然にLSNATを通る境界の内側へサーバープールを置いた。LS-NAPTは両側をさらに書き換え、クライアントとサーバーの双方が必ず変換装置へ戻るようにした。サーバーの配置制約を緩め、アクセス回線を増やしやすくした。

引き換えに変換が増え、処理は複雑になった。その構成はTCPとUDPに限られ、利用可能なクライアントポート数が同時セッション数を制約した。場所の制約は消えたのではなく、表、ポート、処理能力への制約に置き換わった。

これはNATの取引そのものだった。RFC 1631は、端末を変えずに導入できる利点とともに、IPアドレスのエンドツーエンドの意味を失い、ネットワーク内状態を増やす欠点を記した。LSNATはその性質をサーバー選択に利用した。

RFC 7098は後に、一つのクライアントセッションを同じサーバーで完了させることを「persistence」と呼んだ。RFC 2391の表を理解する良い言葉である。ただし、固定を保つことは、固定先を無停止で交換できることではない。

緑色の表示に畳まないために

仮想アドレスは入口を示す。プール設定は候補を示す。計測値は選択器が見た一断面を示す。アルゴリズムは判断規則を示す。バインドは実際の選択を示す。変換された往復は経路動作を示す。サーバー応答は稼働の一部を示す。最後のアプリケーション結果だけが、利用者の仕事の完了を示す。

設定済みだから生きている、pingが返るから処理できる、軽負荷だから正しい、表にあるから完了する、と読み替えてはならない。各事実には固有の所有者と限界がある。

Heng Luのノートは、最小の初期仕様、ローカルな将来判断、実装の稼働、任意採用という順序を重視し、記録が現実を作るわけではないと述べる。RFC 2391も、共通の変換意味を定めながら、選択の正しさや結果までは中央化しなかった。

空いているサーバーは次の利用者を助けられた。現在の利用者を助けるには、別の設計――状態複製、再試行、再構築、あるいはアプリケーション自身の回復――が必要だった。選択と移行の間にあるその距離こそ、RFC 2391が残した歴史である。

出典