要約

  • RFC 3384 は、マルチマスターのレプリカが一つの現行状態へ収束することに加え、競合解決で失われるディレクトリ情報を別に保存し、管理者へ通知し、必要なら覆せるよう求めた。
  • 変更の到着順は恒久的な権威を決められない。表示上の一致と、競合を後から検証できる証拠は別々の要件だった。

切断中の二台のマスターで、同じ属性が別々に変更されたとする。再接続後、クライアントに一つの答えを返すには、どちらかを現行値にしなければならない。しかし一方を選んだ瞬間に、もう一方が無意味になるわけではない。RFC 3384 は、勝者を決める処理と、敗者の存在を消してよいかという判断を切り離した。

文書は 2002 年 10 月、Informational RFC として公開された。対象は相互運用可能な LDAPv3 ディレクトリ複製に必要な基本要件であり、完成した複製プロトコルではない。特定製品の採用や実装実績も示さない。この境界を守らなければ、要件の歴史を導入事例の歴史へすり替えてしまう。

LDAP はクライアントとサーバーの通信を標準化していたが、サーバー間で状態を複製する問題は残った。複製は利用者に近い場所へ情報を置き、障害時にも読める可能性を高める。一方で、部分レプリカ、トポロジー、スキーマ、アクセス制御、再送、同時書き込みを一つの運用体系に持ち込む。

RFC 3384 がいう複製領域は、Directory Information Tree の設定可能な一部分である。領域は重なり、入れ子にもなり得る。その一つの実体がレプリカで、同じ領域を持つサーバーがレプリカグループを構成する。複製合意は領域、アクセス条件、資格情報、機密性、伝播の挙動を定める。「同期済み」という表示には、必ず対象範囲と合意が背後にある。

文書は五つの一貫性モデルを検討した。トランザクション一貫性は ACID を提供するが、分散二相コミットの複雑さから当時は追求されなかった。中心となったのは結果整合性と、限られた努力による結果整合性である。分断中に値が違うこと自体は許容されるが、違いが永久に放置されてよいわけではない。

M3 は、あるエントリーを持つすべてのレプリカで、属性が最終的に同じ値集合へ収束するよう求めた。MM6 もマルチマスターにおける属性とエントリーの収束を要求した。ネットワーク障害は共通状態を遅らせられるが、共通状態へ向かう責務を消すことはできない。

マルチマスターでは、複数のマスターが互いに確認せず更新を受け入れられる。これは局所的な可用性を守る一方、同じデータに二つの正当な変更が触れる可能性を作る。同期が再開すれば、複製機構は一つの現行結果を選ぶ必要がある。

そこで単純な「最後に届いたものを採用する」は危うい。二台のレプリカが同じ二更新を逆順で受け取れば、それぞれ別の最後を持つ。MM7 は、結果整合性を保証するための競合解決を、変更が順番どおり到着することに依存させてはならないとした。パケットの偶然の旅程に、ディレクトリの最終権限を渡さなかったのである。

文書は論理時計、タイムスタンプ、サーバー優先順位のいずれも一律には選ばない。求めたのは一段抽象的な性質だった。同じ変更集合を異なる順序で観測した独立レプリカが、対応するモデルの下で同じ結論へ到達できなければならない。後続設計の自由を残しながら、制御不能な到着列に正しさを預ける方式を除外した。

MM5 はさらに厳しい。マルチマスター複製は情報を失ってはならない。競合解決の結果、収束後のディレクトリから情報が失われるなら、その情報を保存し、競合と損失を管理者へ知らせ、管理上の上書きを可能にする仕組みを用意する必要があった。

これは二つの値を現行エントリーに並べ続ける要求ではない。互いに両立しない値を両方「現在」とすれば、判断をクライアントへ押し付けただけになる。要件は、運用に使う一つの現行面と、自動裁定で退けた内容を保持する証拠面を作った。管理者は後者を見て、前者を変えるべきか判断できる。

したがって、一致率だけでは十分な健全性指標にならない。すべてのレプリカが同じ値を示すことは、伝播と裁定が一つの表示を作った証拠である。しかし敗者が回収できるか、通知が届いたか、裁定が妥当かまでは証明しない。「緑」の同期表示は現在の見え方を示すだけで、履歴の説明責任を示さない。

M12 は再送に対する別の境界を置いた。同じ更新を複数回受け取っても、一度だけ受け取った場合と異なる結果になってはならない。適用後、確認応答前に接続が切れれば、供給側は処理済みか判断できず再送する。再送を新しい変更として数えれば、復旧手順そのものが破壊を生む。

P6 は LDAP 操作の原子性を複製でも維持するよう求めた。一つの操作に含まれる変更が、転送の都合で半分だけ露出してはならない。ただし、完全な二つの原子操作が競合することはある。原子性は途中状態を防ぐが、二つの完成した意思の優先順位までは決めない。

複製開始時の競合は別に扱われた。複数マスターが同じレプリカへ同時にサイクルを始めようとする場合、MM4 は自動的な解消または回避を要求した。ビジーなコンシューマー、失われた接続、再スケジュールはセッション調整の問題である。データ値の衝突と関係はあっても同一ではない。

管理可能性も相互運用性に含まれた。AM2 は各レプリカに、どのサーバーと複製したかの監査履歴を持たせる。AM4 と AM5 は二つのレプリカを比較し、新たな複製サイクルを起こさず差分修復できることを求めた。空のレプリカは完全更新で初期化できなければならない。整合は不可視の背景動作ではなく、確認と修復が可能な操作だった。

一般の到着順が勝者を決めない一方、明示的な因果順序は重要だった。AM6 はアクセス制御情報と、それが支配するデータの更新順を保つよう求めた。データが先に届き、保護規則が後から届けば、一時的に別のセキュリティ意味を持ち得る。偶然の順序と、政策上必要な順序は区別された。

スキーマ不一致は処理され、報告される必要があった。複製はスキーマ定義、属性名と値、アクセス制御、ナレッジ情報、名前空間情報を含むが、DSA 固有の運用属性そのものは除外した。部分レプリカは認められたものの、その部分がどの領域、エントリー、属性からなるかは合意で明確でなければならない。

セキュリティ要件も、認証、認可、完全性、機密性を別々に扱う。相互認証と相互の認可確認、保護された転送を支援しつつ、匿名の複製セッションも支援するよう求めた。匿名と認証済みを同価値としたのではなく、異なる政策条件を表現できるようにした。

後年の RFC は時系列を補うが、RFC 3384 の全要件が実装された証拠にはならない。RFC 4510、4511、4512 は LDAP 技術仕様を再編し、RFC 4533 は内容同期操作、RFC 5805 はトランザクションを定義した。隣接する仕組みを、マルチマスター要件一式の実現と同一視してはならない。

直前の RFC 3383 と比べると、二種類の衝突が見える。RFC 3383 は LDAP 拡張識別子の登録方針を整理し、共有名前空間での衝突を抑えた。RFC 3384 は別々の場所で受理された正当な変更が時間上衝突した後の扱いを問う。前者は名前の参入、後者は状態の異議を統治した。

Lu Heng の最小初期仕様という視点は、アルゴリズムを選ばない要件文書の効用を説明する。最初に固定すべきなのは、到着順への権威委譲、無言の情報消失、修正経路の欠如という許されない損害である。将来の実装は局所的に方法を選べるが、争点を破棄する自由までは得ない。

現実層の視点では、書き込み受理、更新伝播、競合検出、現行値決定、敗者保存、管理者通知、人間の上書きはそれぞれ別の事実になる。「同期済み」という一語でまとめれば、観測可能な技術状態が、説明責任まで果たしたという根拠のない主張へ変わる。

RFC 3384 の歴史的教訓は、きれいすぎる収束を疑うことだ。分散システムは、異論を消すことで一つの答えを作れてしまう。敗者の値を保存する要件は、無言の上書きを監査可能な決定へ変えた。レプリカは合意しても、かつて不一致だった事実を偽装してはならない。

出典