Network Working Group E. Stokes
Request for Comments: 3384 IBM
Category: Informational R. Weiser
Digital Signature Trust
R. Moats
Lemur Networks
R. Huber
AT&T Laboratories
October 2002
Lightweight Directory Access Protocol (version 3)
Replication Requirements
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document discusses the fundamental requirements for replication of data accessible via the Lightweight Directory Access Protocol (version 3) (LDAPv3). It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories.
この文書では、ライトウェイトディレクトリアクセスプロトコル（バージョン3）（LDAPv3の）を介してアクセス可能なデータの複製のための基本的な要件について説明します。情報提供のディレクトリ間の相互運用性を提供するために必要な一般的なレプリケーションの要件のための集まる場所であることを意図しています。
Table of Contents
目次
1 Introduction...................................................2
2 Terminology....................................................3
3 The Models.....................................................5
4 Requirements...................................................7
4.1 General........................................................7
4.2 Model..........................................................8
4.3 Protocol.......................................................9
4.4 Schema........................................................10
4.5 Single Master.................................................10
4.6 Multi-Master..................................................11
4.7 Administration and Management.................................11
4.8 Security......................................................12
5 Security Considerations.......................................13
6 Acknowledgements..............................................13
7 References....................................................13
A Appendix A - Usage Scenarios..................................15
A.1 Extranet Example..............................................15
A.2 Consolidation Example.........................................15
A.3 Replication Heterogeneous Deployment Example..................16
A.4 Shared Name Space Example.....................................16
A.5 Supplier Initiated Replication................................16
A.6 Consumer Initiated Replication................................17
A.7 Prioritized attribute replication.............................17
A.8 Bandwidth issues..............................................17
A.9 Interoperable Administration and Management...................18
A.10 Enterprise Directory Replication Mesh.........................18
A.11 Failure of the Master in a Master-Slave Replicated Directory..19
A.12 Failure of a Directory Holding Critical Service Information...19
B Appendix B - Rationale........................................20
B.1 Meta-Data Implications........................................20
B.2 Order of Transfer for Replicating Data........................20
B.3 Schema Mismatches and Replication.............................21
B.4 Detecting and Repairing Inconsistencies Among Replicas........22
B.5 Some Test Cases for Conflict Resolution in Multi-Master
Replication...................................................23
B.6 Data Confidentiality and Data Integrity During Replication....27
B.7 Failover in Single-Master Systems.............................27
B.8 Including Operational Attributes in Atomic Operations.........29
Authors' Addresses............................................30
Full Copyright Statement......................................31
1 Introduction
1はじめに
Distributing directory information throughout the network provides a two-fold benefit: (1) it increases the reliability of the directory through fault tolerance, and (2) it brings the directory content closer to the clients using the data. LDAP's success as an access protocol for directory information is driving the need to distribute LDAP directory content within the enterprise and Internet. Currently, LDAP does not define a replication mechanism, and mentions LDAP shadow servers (see [RFC2251]) in passing. A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place.
ネットワーク全体のディレクトリ情報を配信することは二重の利点を提供する：（1）それはフォールトトレランスを介してディレクトリの信頼性を高め、そして（2）それが近いデータを用いて、クライアントにディレクトリの内容をもたらします。ディレクトリ情報へのアクセスプロトコルとしてLDAPの成功は、企業やインターネット内のLDAPディレクトリのコンテンツを配信する必要性を駆動しています。現在、LDAPを通過して（[RFC2251]を参照）複製メカニズムを定義し、LDAPシャドウサーバを言及しません。マルチベンダー環境でのディレクトリ・レプリケーションのための標準的なメカニズムは、市場でのLDAPの継続的な成功に不可欠です。
This document sets out the requirements for replication between multiple LDAP servers. While RFC 2251 and RFC 2252 [RFC2252] set forth the standards for communication between LDAP clients and servers there are additional requirements for server-to-server communication. Some of these are covered here.
この文書では、複数のLDAPサーバー間の複製のための要件を設定します。 RFC 2251およびRFC 2252 [RFC2252]はLDAPクライアントとサーバー間の通信のための基準を示しているが、サーバー間通信のための追加要件があります。これらのいくつかはここに覆われています。
This document first introduces the terminology to be used, then presents the different replication models being considered.
この文書では、最初に検討されている別のレプリケーションモデルを提示し、その後、使用する用語を紹介します。
Requirements follow, along with security considerations. The reasoning that leads to the requirements is presented in the Appendices. This was done to provide a clean separation of the requirements from their justification.
要件は、セキュリティ上の配慮とともに、従ってください。要件につながる理由は付録に提示されています。これは彼らの正当化の要件の明確な分離を提供するために行われました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、」、 "べきではありません"、 "推奨すべきである "ものと""、 "MAY"、 "OPTIONAL" はにあります[RFC2119]に記載されているように解釈されます。
2 Terminology
2用語
The following terms are used in this document:
次の用語はこの文書で使用されています。
Anonymous Replication - Replication where the endpoints are identified to each other but not authenticated. Also known as "unauthenticated replication".
匿名レプリケーション - エンドポイントが相互に識別が、認証されませんレプリケーション。また、「認証されていない複製」として知られています。
Area of replication - A whole or portion of a Directory Information Tree (DIT) that makes up a distinct unit of data to be replicated. An area of replication is defined by a replication base entry and includes all or some of the depending entries contained therein on a single server. It divides directory data into partitions whose propagation behavior may be independently configured from other partitions. Areas of replication may overlap or be nested. This is a subset of the definition of a "replicated area" in X.525 [X.525].
複製のエリア - データの別々のユニットを構成するディレクトリ情報ツリー（DIT）の全部または一部を複製します。複製の領域は、複製ベースエントリによって定義され、単一のサーバ上で、そこに含まれる依存エントリの全部または一部を含んでいます。それは、その伝播挙動独立他のパーティションから構成されていてもよいパーティションにディレクトリデータを分割します。レプリケーションのエリアが重複したり、入れ子にすること。これは、[X.525] X.525で「複製領域」の定義のサブセットです。
Atomic operation - A set of changes to directory data which the LDAP standards guarantee will be treated as a unit; all changes will be made or all the changes will fail.
アトミック操作 - LDAP標準の単位として扱われることを保証ディレクトリデータへの変更のセット。すべての変更が行われるか、すべての変更は失敗します。
Atomicity Information - Information about atomic operations passed as part of replication.
アトミック情報 - 複製の一部として渡されるアトミック操作に関する情報。
Conflict - A situation that arises when changes are made to the same directory data on different directory servers before replication can synchronize the data on the servers. When the servers do synchronize, they have inconsistent data - a conflict.
紛争 - 複製がサーバー上のデータを同期することができます前に、変更が別のディレクトリ・サーバー上の同じディレクトリデータに対して行われたときに発生する状況。紛争 - サーバが同期を行うとき、彼らは一貫性のないデータを持っています。
Conflict resolution - Deterministic procedures used to resolve change information conflicts that may arise during replication.
競合解決 - 複製中に発生する可能性のある情報の競合を変更解決するために使用する確定的な手順。
Critical OID - Attributes or object classes defined in the replication agreement as being critical to the operation of the system. Changes affecting critical OIDs cause immediate initiation of a replica cycle. An example of a critical OID might be a password or certificate.
クリティカルOID - 属性やシステムの動作にとって重要であるとして複製合意に定義されているオブジェクトクラス。重要なのOIDに影響を与える変更は、レプリカサイクルの即時開始を引き起こします。重要なOIDの例では、パスワードまたは証明書であるかもしれません。
Fractional replication - The capability to filter a subset of attributes for replication.
部分レプリケーション - レプリケーション用の属性のサブセットをフィルタリングする機能。
Incremental Update - An update that contains only those attributes or entries that have changed.
増分更新 - 変更されている属性のみまたはエントリが含まれている更新。
Master Replica - A replica that may be directly updated via LDAP operations. In a Master-Slave Replication system, the Master Replica is the only directly updateable replica in the replica-group.
マスターレプリカ - 直接LDAP操作を介して更新することができるレプリカ。マスタースレーブレプリケーションシステムでは、マスターレプリカはレプリカグループ内の唯一の直接更新可能レプリカです。
Master-Slave, or Single Master Replication - A replication model that assumes only one server, the master, allows LDAP write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication.
マスタ・スレーブ、またはシングルマスタレプリケーション - 一つだけのサーバを想定してレプリケーションモデル、マスターは、複製されたデータへのLDAP書き込みアクセスを許可します。マスタースレーブのレプリケーションは、マルチマスターレプリケーションの適切なサブセットとみなすことができることに注意してください。
Meta-Data - Data collected by the replication system that describes the status/state of replication.
メタデータ - レプリケーションの状態/状態を記述するレプリケーション・システムによって収集されたデータ。
Multi-Master Replication - A replication model where entries can be written and updated on any of several master replica copies without requiring communication with other master replicas before the write or update is performed.
マルチマスターレプリケーション - エントリは、書き込みや更新が実行される前に他のマスターレプリカとの通信を必要とすることなく、いくつかのマスターレプリカコピーのいずれかに書き込まれ、更新することができるレプリケーションモデル。
One-way Replication - The process of synchronization in a single direction where the authoritative source information is provided to a replica.
一方向レプリケーション - 信頼できるソース情報がレプリカに提供される単方向同期プロセス。
Partial Replication - Partial Replication is Fractional Replication, Sparse Replication, or both.
部分レプリケーション - 部分レプリケーションは、部分レプリケーション、スパース複製、またはその両方です。
Propagation Behavior - The behavior of the synchronization process between a consumer and a supplier.
伝播挙動 - 消費者とサプライヤー間の同期プロセスの振る舞い。
Replica - An instance of an area of replication on a server.
レプリカ - サーバー上のレプリケーションの面積のインスタンス。
Replica-Group - The servers that hold instances of a particular area of replication. A server may be part of several replica-groups.
レプリカ・グループ - 複製の特定の領域のインスタンスを保持するサーバ。サーバーは、複数のレプリカ・グループの一部であってもよいです。
Replica (or Replication) Cycle - The interval during which update information is exchanged between two or more replicas. It begins during an attempt to push data to, or pull data from, another replica or set of replicas, and ends when the data has successfully been exchanged or an error is encountered.
レプリカ（または複製）サイクル - 更新情報は、2つの以上のレプリカとの間で交換されている間の間隔。それはにデータをプッシュする、またはからデータを取得しようとすると、別のレプリカやレプリカのセットの間に開始され、データが正常に交換されたか、エラーが発生したときに終了します。
Replication - The process of synchronizing data distributed across directory servers and rectifying update conflicts.
レプリケーション - ディレクトリサーバーに分散データを同期して更新の競合を整流するプロセス。
Replication Agreement - A collection of information describing the parameters of replication between two or more servers in a replica-group.
レプリケーションアグリーメント - レプリカグループ内の2つの以上のサーバー間のレプリケーションのパラメータを記述した情報の収集。
Replication Base Entry - The distinguished name of the root vertex of a replicated area.
レプリケーションベースエントリ - 複製された領域のルート頂点の識別名。
Replication Initiation Conflict - A Replication Initiation Conflict is a situation where two sources want to update the same replica at the same time.
レプリケーションの開始対立 - レプリケーションの開始の競合は、二つのソースが同時に同じレプリカを更新したい状況です。
Replication Session - A session set up between two servers in a replica-group to pass update information as part of a replica cycle.
複製セッション - レプリカグループ内の2つのサーバー間で設定したセッションは、レプリカサイクルの一部として更新情報を渡すことができます。
Slave (or Read-Only) Replica - A replica that cannot be directly updated via LDAP requests. Changes may only be made via replication from a master replica. Read-only replicas may occur in both single-and multi-master systems.
スレーブ（または読み取り専用）のレプリカ - 直接LDAP要求を介して更新することができないレプリカ。変更は、マスターレプリカから複製を介して行うことができます。読み込み専用レプリカは、シングルおよびマルチマスタシステムの両方で発生する可能性があります。
Sparse Replication - The capability to filter some subset of entries (other than a complete collection) of an area of replication.
スパースレプリケーション - レプリケーションの面積の（完全なコレクション以外）のエントリのいくつかのサブセットをフィルタリングする機能。
Topology - The shape of the directed graph describing the relationships between replicas.
トポロジー - レプリカとの間の関係を記述する有向グラフの形状。
Two-way Replication - The process of synchronization where change information flows bi-directionally between two replicas.
双方向レプリケーション - 変更情報は、2つのレプリカの間で双方向に流れ、同期のプロセス。
Unauthenticated Replication - See Anonymous Replication.
非認証レプリケーション - 匿名レプリケーションを参照してください。
Update Propagation - Protocol-based process by which directory replicas are reconciled.
更新伝播 - ディレクトリのレプリカが調整されることにより、プロトコルベースのプロセス。
3 The Models
3モデル
The objective is to provide an interoperable, LDAPv3 directory synchronization protocol that is simple, efficient and flexible; supporting both multi-master and master-slave replication. The protocol must meet the needs of both the Internet and enterprise environments.
目的は、簡単、効率的で柔軟性のある相互運用性、LDAPv3ディレクトリ同期プロトコルを提供することです。マルチマスターとマスタースレーブレプリケーションの両方をサポートします。プロトコルは、両方のインターネットと企業環境のニーズを満たす必要があります。
There are five data consistency models.
5つのデータの一貫性モデルがあります。
Model 1: Transactional Consistency -- Environments that exhibit all four of the ACID properties (Atomicity, Consistency, Isolation, Durability) [ACID].
モデル1：トランザクションの一貫性 - ACID特性（原子性、一貫性、独立性、耐久性）[ACID]の4つのすべてを発揮する環境。
Model 2: Eventual (or Transient) Consistency -- Environments where definite knowledge of the topology is provided through predetermined replication agreements. Examples include X.500 Directories (the X.500 model is single-master only) [X.501, X.525], Bayou [XEROX], and NDS (Novell Directory Services) [NDS]. In this model, every update propagates to every replica that it can reach via a path of stepwise eventual connectivity.
モデル2：最終的に（または一過）整合 - トポロジーの明確な知識は、所定のレプリケーションアグリーメントを介して提供される環境。例は、X.500ディレクトリを含む（X.500モデルは、単一のマスタのみ）[X.501、X.525]、バイユー[XEROX]、およびNDS（ノベルディレクトリサービス）[NDS]。このモデルでは、すべての更新は、それが段階的に最終的な接続の経路を介して到達することができ、すべてのレプリカに伝播します。
Model 3: Limited Effort Eventual (or Probabilistic) Consistency -- Environments that provide a statistical probability of convergence with knowledge of topology. An example is the Xerox Clearinghouse [XEROX2]. This model is similar to "Eventual Consistency", except where replicas may purge updates. Purging drops propagation changes when some replica time boundary is exceeded, thus leaving some changes replicated to only a portion of the topology. Transactional consistency is not preserved, though some weaker constraints on consistency are available.
モデル3：リミテッド努力最終的な（または確率）一貫性 - トポロジーの知識を持つ収束の統計的確率を提供環境。例は、ゼロックスクリアリングハウス[XEROX2]です。このモデルは、レプリカが更新をパージする場合を除いて、「結果整合性」に似ています。いくつかのレプリカの時間境界を超えたときにパージは、このようにトポロジーの一部のみに複製いくつかの変更を残して、伝播の変化をドロップ。一貫性に関するいくつかの弱い制約が用意されていてもトランザクションの一貫性は、保存されません。
Model 4: Loosest Consistency -- Environments where information is provided from an opportunistic or simple cache until stale. Complete knowledge of topology may not be shared among all replicas.
モデル4：最も緩い一貫性 - 情報が古くなるまで日和見または単純なキャッシュから提供される環境。トポロジーの完全な知識は、すべてのレプリカ間で共有することはできません。
Model 5: Ad hoc -- A copy of a data store where no follow up checks are made for the accuracy/freshness of the data.
モデル5：アドホック - 何のフォローアップ検査がデータの精度/新鮮さのために作られていないデータストアのコピー。
Consistency models 1, 2 and 3 involve the use of prearranged replication agreements among servers. While model 1 may simplify support for atomicity in multi-master systems, the added complexity of the distributed 2-phase commit required for Model 1 is significant; therefor, model 1 will not be considered at this time. Models 4 and 5 involve unregistered replicas that "pull" updates from another directory server without that server's knowledge. These models violate a directory's security policies.
一貫性モデルは1、2及び3は、サーバー間で事前に決められたレプリケーションアグリーメントの使用を含みます。モデル1は、マルチマスタシステムで不可分のサポートを単純化することができるが、分散2相の添加複雑さは、モデル1に必要なコミット重要です。そのため、モデル1は、この時点では考慮されません。モデル4と5は、そのサーバーの知識がなくても、別のディレクトリ・サーバーから更新を「プル」未登録のレプリカを伴います。これらのモデルは、ディレクトリのセキュリティポリシーに違反します。
Models 2 and 3 illustrate two replication scenarios that must be handled: policy configuration through security management parameters (model 2), and hosting relatively static data and address information as in white-pages applications (model 3). Therefore, replication requirements are presented for models 2 and 3.
セキュリティ管理パラメータ（モデル2）を介してポリシー設定、および比較的静的なデータをホストと白ページアプリケーション（モデル3）のようにアドレス情報：モデル2及び3は、処理されなければならない2つの複製シナリオを示します。したがって、複製の要件は、モデル2と3のために提示されています。
Interoperability among directories using LDAP replication may be limited for implementations that add semantics beyond those specified by the LDAP core documents (RFC 2251-2256, 2829, 2830). In addition, the "core" specifications include numerous features which are not mandatory-to-implement (e.g., RECOMMENDED or OPTIONAL). There are also numerous elective extensions. Thus LDAP replication interoperability between independent implementations of LDAP which support different options may be limited. Use of applicability statements to improve interoperability in particular application spaces is RECOMMENDED.
LDAPレプリケーションを使用して、ディレクトリ間の相互運用性は、LDAPコア文書（RFC 2251から2256、2829、2830）で指定されたもの以外のセマンティクスを追加実装するために制限することができます。加えて、「コア」仕様（例えば、推奨またはオプション）強制的に実装されない多数の特徴を含みます。数多くの選択科目の拡張機能もあります。このようにさまざまなオプションをサポートするLDAPの独立した実装の間のLDAPレプリケーションの相互運用性が制限される場合があります。特定のアプリケーション空間での相互運用性を向上させるために適用可能文の使用を推奨します。
4 Requirements
4つの要件
G1. LDAP Replication MUST support models 2 (Eventual Consistency) and 3 (Limited Effort Eventual Consistency) above.
G1。 LDAPレプリケーションは、上記のモデル2（結果整合性）と3（限定努力結果整合性）をサポートしなければなりません。
G2. LDAP Replication SHOULD NOT preclude support for model 1 (Transactional Consistency) in the future.
G2。 LDAPレプリケーションは、将来的にはモデル1（トランザクションの一貫性）のためのサポートを排除すべきではありません。
G3. LDAP replication SHOULD have minimal impact on system performance.
G3。 LDAPレプリケーションは、システムのパフォーマンスへの影響を最小限に抑えるべきです。
G4. The LDAP Replication Standard SHOULD NOT limit the replication transaction rate.
G4。 LDAP複製標準複製トランザクション率を制限してはなりません。
G5. The LDAP replication standard SHOULD NOT limit the size of an area of replication or a replica.
G5。 LDAP複製標準複製またはレプリカの面積の大きさを制限してはなりません。
G6. Meta-data collected by the LDAP replication mechanism MUST NOT grow without bound.
G6。 LDAP複製メカニズムによって収集されたメタデータは際限なく増加しなければなりません。
G7. All policy and state data pertaining to replication MUST be accessible via LDAP.
G7。レプリケーションに関連するすべてのポリシーと状態データは、LDAP経由でアクセス可能でなければなりません。
G8. LDAP replication MUST be capable of replicating the following:
G8。 LDAPレプリケーションは、以下を複製することができなければなりません。
- all userApplication attribute types
- すべてのクラスタアプリケーションは、属性タイプ
- all directoryOperation and distributedOperation attribute types defined in the LDAP "core" specifications (RFCs 2251- 2256, 2829-2830)
- すべてのdirectoryOperationとdistributedOperationがLDAPで定義された属性タイプ「コア」仕様（RFCは2251- 2256年、2829年から2830年）
- attribute subtypes
- 属性のサブタイプ
- attribute description options (e.g., ";binary" and Language Tags [RFC2596])
- 属性記述オプション（例えば、「;バイナリー」と言語タグ[RFC2596]）
G9. LDAP replication SHOULD support replication of directoryOperation and distributedOperation attribute types defined in standards track LDAP extensions.
G9。 LDAPレプリケーションは、LDAP拡張を追跡する規格で定義された属性タイプdirectoryOperationとdistributedOperationの複製をサポートする必要があります。
G10. LDAP replication MUST NOT support replication of dsaOperation attribute types as such attributes are DSA-specific.
G10。 LDAPレプリケーションはdsaOperationの複製をサポートしてはならない、そのような属性はDSA固有のものとして属性タイプ。
G11. The LDAP replication system should limit impact on the network by minimizing the number of messages and the amount of traffic sent.
G11。 LDAP複製システムは、メッセージの数と送信されるトラフィックの量を最小限に抑えることにより、ネットワークへの影響を制限する必要があります。
M1. The model MUST support the following triggers for initiation of a replica cycle:
M1。モデルは、レプリカサイクルの開始のために、次のトリガをサポートしなければなりません：
a) A configurable set of scheduled times
予定時刻のa）の構成可能なセット
b) Periodically, with a configurable period between replica cycles
B）定期的に、複製サイクルの間に設定期間と
c) A configurable maximum amount of time between replica cycles
C）複製サイクル間の時間の構成可能な最大量を
d) A configurable number of accumulated changes
蓄積された変更のD）設定可能な数
e) Change in the value of a critical OID
重要なOIDの値でe）に変更
f) As the result of an automatic rescheduling after a replication initiation conflict
F）複製開始衝突後の自動再スケジュールの結果
g) A manual request for immediate replication
g）の即時複製のためのマニュアルのリクエスト
With the exception of manual request, the specific trigger(s) and related parameters for a given server MUST be identified in a well-known place defined by the standard, e.g., the Replication Agreement(s).
手動要求を除いて、特定のトリガー（S）と指定されたサーバのための関連するパラメータは、標準的な、例えば、レプリケーションアグリーメント（S）によって定義された周知の場所で識別されなければなりません。
M2. The replication model MUST support both master-slave and multi-master relationships.
M2。レプリケーションモデルは、マスタースレーブおよびマルチマスタ関係の両方をサポートしなければなりません。
M3. An attribute in an entry MUST eventually converge to the same set of values in every replica holding that entry.
M3。エントリの属性は、最終的にそのエントリを保持しているすべてのレプリカに同じ値のセットに収束しなければなりません。
M4. LDAP replication MUST encompass schema definitions, attribute names and values, access control information, knowledge information, and name space information.
M4。 LDAPレプリケーションは、スキーマ定義、属性名と値、アクセス制御情報、知識情報、および名前空間の情報を網羅しなければなりません。
M5. LDAP replication MUST NOT require that all copies of the replicated information be complete, but MAY require that at least one copy be complete. The model MUST support Partial Replicas.
M5。 LDAPの複製は、複製された情報のすべてのコピーが完了することを要求してはなりませんが、少なくとも1つのコピーが完了することを要求することができます。モデルは、部分レプリカをサポートしなければなりません。
M6. The determination of which OIDs are critical MUST be configurable in the replication agreement.
M6。 OIDが重要であるの決意は、レプリケーションアグリーメントで構成可能でなければなりません。
M7. The parameters of the replication process among the members of the replica-group, including access parameters, necessary authentication credentials, assurances of confidentiality (encryption), and area(s) of replication MUST be defined in a standard location (e.g., the replication agreements).
M7。アクセスパラメータ、必要な認証資格証明、機密性（暗号化）の保証、および複製の面積（S）を含む複製グループのメンバー間の複製プロセスのパラメータは、（標準の場所に、例えば、レプリケーションアグリーメントを定義しなければなりません）。
M8. The replication agreements SHOULD accommodate multiple servers receiving the same area of replication under a single predefined agreement.
M8。レプリケーションアグリーメントは、単一の事前に定義された契約に基づき、複製の同じ領域を受け、複数のサーバに対応する必要があります。
M9. LDAP replication MUST provide scalability to both enterprise and Internet environments, e.g., an LDAP server must be able to provide replication services to replicas within an enterprise as well as across the Internet.
M9。 LDAPレプリケーションは、例えば、LDAPサーバは、企業内だけでなく、インターネット経由でレプリカに複製サービスを提供できるようにする必要があり、企業とインターネットの両方の環境への拡張性を提供しなければなりません。
M10. While different directory implementations can support different/extended schema, schema mismatches between two replicating servers MUST be handled. One way of handling such mismatches might be to raise an error condition.
M10。別のディレクトリの実装が異なる/拡張スキーマをサポートすることができますが、2つの複製サーバー間でスキーマの不一致を処理する必要があります。そのような不整合を処理する一つの方法は、エラー状態を上げることがあるかもしれません。
M11. There MUST be a facility that can update, or totally refresh, a replica-group from a standard data format, such as LDIF format [RFC2849].
M11。更新、または完全にそのようなLDIF形式[RFC2849]などの標準的なデータ形式から、レプリカ・グループをリフレッシュすることができる施設が存在していなければなりません。
M12. An update received by a consumer more than once MUST NOT produce a different outcome than if the update were received only once.
M12。一度更新が一度だけ受けた場合とは異なる結果を生成してはならないよりも多くの消費者が受信した更新。
P1. The replication protocol MUST provide for recovery and rescheduling of a replication session due to replication initiation conflicts (e.g., consumer busy replicating with other servers) and or loss of connection (e.g., supplier cannot reach a replica).
P1。複製プロトコル（例えば、サプライヤがレプリカに到達できない）により、複製開始の競合（例えば、消費者忙しい他のサーバーとの複製）、およびまたは接続の損失にレプリケーションセッションの回復と再スケジューリングのために提供しなければなりません。
P2. LDUP replication SHOULD NOT send an update to a consumer if the consumer has previously acknowledged that update.
P2。消費者が以前にその更新を認めている場合LDUPレプリケーションは、消費者へのアップデートを送るべきではありません。
P3. The LDAP replication protocol MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized format such as LDIF [RFC2849] format.
P3。 LDAPレプリケーション・プロトコルは、レプリカの初期化を容易にし、そのようなLDIF [RFC2849]形式として標準化されたフォーマットを利用して負荷をリセットするために完全な更新を可能にしなければなりません。
P4. Incremental replication MUST be allowed.
P4。インクリメンタル複製が許可されなければなりません。
P5. The replication protocol MUST allow either a master or slave replica to initiate the replication process.
P5。複製プロトコルは、マスタまたはスレーブレプリカのいずれかがレプリケーションプロセスを開始することを可能にしなければなりません。
P6. The protocol MUST preserve atomicity of LDAP operations as defined in RFC2251 [RFC2251]. In a multi-master environment this may lead to an unresolvable conflict. MM5 and MM6 discuss how to handle this situation.
P6。 RFC2251 [RFC2251]で定義されるプロトコルは、LDAP操作のアトミック性を保持しなければなりません。マルチマスター環境では、これは解決できない紛争につながる可能性があります。 MM5とMM6は、この状況に対処する方法について説明します。
P7. The protocol MUST support a mechanism to report schema mismatches between replicas discovered during a replication session.
P7。プロトコルは、複製セッション中に発見されたレプリカの間でスキーマの不一致を報告するためのメカニズムをサポートしなければなりません。
SC1. A standard way to determine what replicas are held on a server MUST be defined.
SC1。サーバーに保持されているどのようなレプリカを決定する標準的な方法を定義する必要があります。
SC2. A standard schema for representing replication agreements MUST be defined.
SC2。レプリケーションアグリーメントを表現するための標準スキーマを定義する必要があります。
SC3. The semantics associated with modifying the attributes of replication agreements MUST be defined.
SC3。レプリケーションアグリーメントの属性を変更するに関連した意味論を定義する必要があります。
SC4. A standard method for determining the location of replication agreements MUST be defined.
SC4。レプリケーションアグリーメントの位置を決定するための標準的な方法を定義する必要があります。
SC5. A standard schema for publishing state information about a given replica MUST be defined.
SC5。所与のレプリカについての状態情報を公開するための標準スキーマを定義する必要があります。
SC6. A standard method for determining the location of replica state information MUST be defined.
SC6。レプリカ状態情報の位置を決定するための標準的な方法を定義する必要があります。
SC7. It MUST be possible for appropriately authorized administrators, regardless of their network location, to access replication agreements in the DIT.
SC7。これは、DITに複製に関する合意にアクセスするために、関係なく、彼らのネットワークの場所の、適切に承認された管理者のために可能でなければなりません。
SC8. Replication agreements of all servers containing replicated information MUST be accessible via LDAP.
SC8。複製された情報を含むすべてのサーバーの複製合意は、LDAP経由でアクセス可能でなければなりません。
SC9. An entry MUST be uniquely identifiable throughout its lifetime.
SC9。エントリは、その生涯を通じて一意に識別可能でなければなりません。
SM1. A Single Master system SHOULD provide a fast method of promoting a slave replica to become the master replica.
SM1。シングルマスタシステムは、マスターレプリカになるために、スレーブ複製を促進する高速な方法を提供する必要があります。
SM2. The master replica in a Single Master system SHOULD send all changes to read-only replicas in the order in which the master applied them.
SM2。シングルマスタシステムのマスタレプリカが読み取り専用レプリカをマスターがそれらを適用するために、すべての変更を送るべきです。
MM1. The replication protocol SHOULD NOT saturate the network with redundant or unnecessary entry replication.
MM1。複製プロトコルは、冗長または不要なエントリの複製とのネットワークを飽和状態にすべきではありません。
MM2. The initiator MUST be allowed to determine whether it will become a consumer or supplier during the synchronization startup process.
MM2。イニシエータは、同期起動処理中に消費者または供給者になるかどうかを決定することができなければなりません。
MM3. During a replica cycle, it MUST be possible for the two servers to switch between the consumer and supplier roles.
MM3。 2台のサーバーが消費者と供給者の役割を切り替えることのための複製サイクルの間に、それが可能でなければなりません。
MM4. When multiple master replicas want to start a replica cycle with the same replica at the same time, the model MUST have an automatic and deterministic mechanism for resolving or avoiding replication initiation conflict.
MM4。複数のマスターレプリカが同時に同じレプリカとレプリカサイクルを開始したい場合は、モデルは、複製開始の競合を解決または回避するための自動および決定論的メカニズムを持たなければなりません。
MM5. Multi-master replication MUST NOT lose information during replication. If conflict resolution would result in the loss of directory information, the replication process MUST store that information, notify the administrator of the nature of the conflict and the information that was lost, and provide a mechanism for possible override by the administrator.
MM5。マルチマスターレプリケーションでは、レプリケーション中に情報を失ってはなりません。紛争解決は、ディレクトリ情報の損失につながる場合は、レプリケーション・プロセスは、その情報を格納し、競合して失われた情報の性質の管理者に通知し、管理者が可能オーバーライドするためのメカニズムを提供しなければなりません。
MM6. Multi-master replication MUST support convergence of the values of attributes and entries. Convergence may result in an event as described in MM5.
MM6。マルチマスターレプリケーションでは、属性とエントリの値の収束をサポートしなければなりません。 MM5に記載されているように収束は、イベントをもたらし得ます。
MM7. Multi-master conflict resolution MUST NOT depend on the in-order arrival of changes at a replica to assure eventual convergence.
MM7。マルチマスタ競合解決は、最終的な収束を保証するレプリカにおける変更のインオーダー到着に依存してはなりません。
MM8. Multi-master replication MUST support read-only replicas as well as read-write replicas.
MM8。マルチマスターレプリケーションは、読み取り専用のレプリカだけでなく、読み書きレプリカをサポートしなければなりません。
AM1. Replication agreements MUST allow the initiation of a replica cycle to be administratively postponed to a more convenient period.
AM1。レプリケーション合意は、レプリカ・サイクルの開始は管理上より便利期間に延期することを許可する必要があります。
AM2. Each copy of a replica MUST maintain audit history information of which servers it has replicated with and which servers have replicated with it.
AM2。レプリカの各コピーは、それがで複製されており、どのサーバがそれを複製しているサーバの監査履歴情報を維持しなければなりません。
AM3. Access to replication agreements, topologies, and policy attributes MUST be provided through LDAP.
AM3。レプリケーションアグリーメント、トポロジ、およびポリシー属性へのアクセスは、LDAPを介して提供されなければなりません。
AM4. The capability to check the differences between two replicas for the same information SHOULD be provided.
AM4。同じ情報のための2つのレプリカの違いを確認するための機能が提供されるべきです。
AM5. A mechanism to fix differences between replicas without triggering new replica cycles SHOULD be provided.
AM5。新しいレプリカサイクルをトリガすることなくレプリカ間の相違を修正するためのメカニズムが提供されるべきです。
AM6. The sequence of updates to access control information (ACI) and the data controlled by that ACI MUST be maintained by replication.
AM6。制御情報にアクセスするための更新（ACI）とそのACIによって制御されるデータのシーケンスは、複製によって維持されなければなりません。
AM7. It MUST be possible to add a 'blank' replica to a replica-group, and force a full update from (one of) the Master(s), for the purpose of adding a new directory server to the system.
AM7。システムに新しいディレクトリサーバを追加する目的のために、レプリカグループに「ブランク」のレプリカを追加し、（の1つ）マスター（S）からの完全な更新を強制することは可能でなければなりません。
AM8. Vendors SHOULD provide tools to audit schema compatibility within a potential replica-group.
AM8。ベンダーは、潜在的なレプリカグループ内のスキーマの互換性を監査するためのツールを提供する必要があります。
The terms "data confidentiality" and "data integrity" are defined in the Internet Security Glossary [RFC2828].
用語「データの機密性」と「データの整合性は、」インターネットセキュリティ用語集[RFC2828]で定義されています。
S1. The protocol MUST support mutual authentication of the source and the replica directories during initialization of a replication session.
S1。プロトコルは、レプリケーションセッションの初期化時にソースとレプリカディレクトリの相互認証をサポートしなければなりません。
S2. The protocol MUST support mutual verification of authorization of the source to send and the replica to receive replicated data during initialization of a replication session.
S2。プロトコルは、送信するために、ソースとレプリケーションセッションの初期化中に複製されたデータを受信するためのレプリカの承認の相互認証をサポートしなければなりません。
S3. The protocol MUST also support the initialization of anonymous replication sessions.
S3。このプロトコルはまた、匿名のレプリケーションセッションの初期化をサポートしなければなりません。
S4. The replication protocol MUST support transfer of data with data integrity and data confidentiality.
S4。レプリケーションプロトコルは、データの整合性とデータの機密性とデータの転送をサポートしなければなりません。
S5. The replication protocol MUST support the ability during initialization of a replication session for an authenticated source and replica to mutually decide to disable data integrity and data confidentiality within the context of and for the duration of that particular replication session.
S5。レプリケーション・プロトコルは、相互のコンテキスト内で、その特定のレプリケーションセッションの間のデータの整合性とデータの機密性を無効にすることを決定するために認証ソースとレプリカの複製セッションの初期化時の能力をサポートしなければなりません。
S6. To promote interoperability, there MUST be a mandatory-to-implement data confidentiality mechanism.
S6。相互運用性を促進するために、実装に必須のデータの機密性メカニズムがあるに違いありません。
S7. The transport for administrative access MUST permit assurance of the integrity and confidentiality of all data transferred.
S7。管理アクセスのための輸送は、転送されたすべてのデータの整合性と機密性の確保を可能にしなければなりません。
S8. To support data integrity, there must be a mandatory-to-implement data integrity mechanism.
S8。データの整合性をサポートするために、実装に必須のデータの整合性のメカニズムが存在しなければなりません。
5 Security Considerations
5セキュリティに関する考慮事項
This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, interoperability may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Security-related and general LDAP interoperability will be significantly impacted by the degree of consistency with which implementations support existing and future standards detailing LDAP security models, such as a future standard LDAP access control model.
この文書では、レプリケーションモデルとプロトコルの（上記セクション4.8に記載されている）セキュリティ要件を含みます。第3節で述べたように、基本的なLDAPセマンティクスへの非標準の拡張機能を実装するサーバー間で複製するときに、相互運用性が影響を受ける可能性があります。セキュリティ関連、および一般的なLDAPの相互運用性が大幅に実装は、このような将来の標準のLDAPアクセス制御モデルとしてLDAPセキュリティモデルを、ディテール、既存および将来の規格をサポートしているとの整合性の程度によって影響を受けることになります。
6 Acknowledgements
6つの謝辞
This document is based on input from IETF members interested in LDUP Replication.
この文書はLDUPレプリケーションに興味がIETFメンバーからの入力に基づいています。
7 References
7つの参考文献
[ACID] T. Haerder, A. Reuter, "Principles of Transaction-Oriented Database Recovery", Computing Surveys, Vol. 15, No. 4 (December 1983), pp. 287-317.
、コンピューティング調査、巻[ACID] T. Haerder、A.ロイターは、「トランザクション指向データベースの回復の原則」。 15、第4号（1983年12月）、頁287から317。
[NDS] Novell, "NDS Technical Overview", 104-000223-001, http://developer.novell.com/ndk/doc/ndslib/dsov_enu/data/ h6tvg4z7.html, September, 2000.
[NDS]ノベル、 "NDS技術概要"、104-000223-001、http://developer.novell.com/ndk/doc/ndslib/dsov_enu/data/ h6tvg4z7.html、2000年9月。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol", RFC 2251, December 1997.
[RFC2251]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル"、RFC 2251、1997年12月。
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[RFC2252]ワール、M.、Coulbeck、A.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）：属性の構文定義"、RFC 2252、1997年12月。
[RFC2253] Kille, S., Wahl, M. and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[RFC2253] Kille、S.、ワール、M.とT.ハウズ、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：識別名のUTF-8文字列表現"、RFC 2253、1997年12月。
[RFC2254] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
[RFC2254]ハウズ、T.、 "LDAP検索フィルタの文字列表現"、RFC 2254、1997年12月。
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[RFC2255]ハウズ、T.およびM.スミス、 "LDAPのURLの形式"、RFC 2255、1997年12月。
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997.
[RFC2256]ワール、M.、 "のLDAPv3で使用するためのX.500（96）ユーザスキーマの概要"、RFC 2256、1997年12月。
[RFC2596] Wahl, M. and T. Howes, "Use of Language Codes in LDAP", RFC 2596, May 1999.
[RFC2596]ワール、M.とT.ハウズ、 "LDAPでの言語コードの使用"、RFC 2596、1999年5月。
[RFC2828] Shirey, R. "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[RFC2828] Shirey、R.、 "インターネットセキュリティ用語集"、FYI 36、RFC 2828、2000年5月。
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
[RFC2829]ワール、M.、Alvestrand、H.、ホッジス、J.とR.モルガン、 "LDAPのための認証方法"、RFC 2829、2000年5月。
[RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.
[RFC2830]ホッジス、J.、モルガン、R.とM.ワール、 "ライトウェイトディレクトリアクセスプロトコル（v3の）：トランスポート層セキュリティのための拡張"、RFC 2830、2000年5月。
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF)", RFC 2849, June 2000.
[RFC2849]グッド、G.、 "LDAPデータ交換フォーマット（LDIF）"、RFC 2849、2000年6月。
[X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993, Information Technology - Open Systems Interconnection - The Directory: Models.
[X.501] ITU-T勧告X.501（1993）| ISO / IEC 9594から2：1993、情報技術 - 開放型システム間相互接続 - ディレクトリ：モデル。
[X.525] ITU-T Recommendation X.525 (1997), | ISO/IEC 9594-9: 1997, Information Technology - Open Systems Interconnection - The Directory: Replication.
[X.525] ITU-T勧告X.525（1997）| ISO / IEC 9594から9：1997、情報技術 - 開放型システム間相互接続 - ディレクトリ：レプリケーション。
[XEROX] C. Hauser, "Managing update conflicts in Bayou, a weakly connected replicated storage system". Palo Alto, CA: Xerox PARC, Computer Science Laboratory; 1995 August; CSL-95-4.
[XEROX] C.ハウザー、「バイユー、弱連結複製ストレージシステム内の更新の競合を管理します」。カリフォルニア州パロアルト：ゼロックスPARC、コンピュータサイエンス研究所。 1995年8月; CSL-95-4。
[XEROX2] Alan D. Demers, Mark Gealy, Daniel Greene, Carl Hauser, Wesley Irish, John Larson, Sue Manning, Scott Shenker, Howard Sturgis, Daniel Swinehart, Douglas Terry, Don Woods, "Epidemic Algorithms for Replicated Database Maintenance". Palo Alto, CA, Xerox PARC, January 1989.
[XEROX2]アランD.デマーズ、マーク・Gealy、ダニエル・グリーン、カール・ハウザー、ウェスリーアイルランド、ジョン・ラーソン、スーマニング、スコット・シェンカー、ハワード・スタージス、ダニエルSwinehart、ダグラステリー、ドン・ウッズ、「複製されたデータベースのメンテナンスのための流行のアルゴリズム」。カリフォルニア州パロアルト、ゼロックスPARC、1989年1月。
A. APPENDIX A - Usage Scenarios
A.付録A - 使用シナリオ
The following directory deployment examples are intended to validate our replication requirements. A heterogeneous set of directory implementations is assumed for all the cases below. This material is intended as background; no requirements are presented in this Appendix.
次のディレクトリの展開例は、当社のレプリケーションの要件を検証することを意図しています。ディレクトリの実装の異種のセットは、以下のすべてのケースのために想定されます。この材料は、背景として意図されています。何の要件は、この付録で提示されていません。
A.1. Extranet Example
A.1。エクストラネットの例
A company has a trading partner with whom it wishes to share directory information. This information may be as simple as a corporate telephone directory, or as complex as an extranet workflow application. For performance reasons, the company wishes to place a replica of its directory within the Partner Company, rather than exposing its directory beyond its firewall.
同社は、それがディレクトリ情報を共有したい人と、取引先を持っています。この情報は、企業の電話帳のように、またはエクストラネットのワークフローアプリケーションなどの複雑なのと同じくらい簡単かもしれません。パフォーマンス上の理由から、同社ではなく、そのファイアウォールを越えてそのディレクトリをさらすよりも、パートナー企業内のディレクトリのレプリカを配置することを希望します。
The requirements that follow from this scenario are:
このシナリオから続く要件は次のとおりです。
- One-way replication, single mastered.
- 一方向レプリケーション、単一の習得。
- Authentication of clients.
- クライアントの認証。
- Common access control and access control identification.
- 一般的なアクセス制御やアクセス制御識別。
- Secure transmission of updates.
- アップデートの送信を固定します。
- Selective attribute replication (Fractional Replication), so that only partial entries can be replicated.
- 選択属性の複製（部分レプリケーション）、部分的にしかエントリが複製することができるようにします。
A.2. Consolidation Example
A.2。統合の例
Company A acquires company B. Each company has an existing directory.
A社は、各企業が既存のディレクトリを持っている会社Bを取得します。
During the transition period, as the organizations are merged, both directory services must coexist. Company A may wish to attach company B's directory to its own.
組織がマージされると、移行期間中は、両方のディレクトリサービスが共存しなければなりません。 A社は、独自に会社Bのディレクトリを添付することもできます。
The requirements that follow from this scenario are:
このシナリオから続く要件は次のとおりです。
- Multi-Master replication.
- マルチマスターレプリケーション。
- Common access control model. Access control model identification.
- 一般的なアクセス制御モデル。アクセス制御モデル同定。
- Secure transmission of updates.
- アップデートの送信を固定します。
- Replication between DITs with potentially differing schema.
- 潜在的に異なるスキーマを持つサイト間のレプリケーション。
A.3. Replication Heterogeneous Deployment Example
A.3。レプリケーションの異機種の展開例
An organization may choose to deploy directory implementations from multiple vendors, to enjoy the distinguishing benefits of each.
組織は、それぞれの特徴的なメリットを享受するために、複数のベンダーからディレクトリ実装を展開することもできます。
In this case, multi-master replication is required to ensure that the multiple replicas of the DIT are synchronized. Some vendors may provide directory clients, which are tied to their own directory service.
この場合、マルチマスタ複製はDITの複数のレプリカが同期されていることを確認する必要があります。一部のベンダーは、独自のディレクトリサービスに結び付けられているディレクトリクライアントを提供することができます。
The requirements that follow from this scenario are:
このシナリオから続く要件は次のとおりです。
- Multi-Master replication
- マルチマスターレプリケーション
- Common access control model and access control model identification.
- 一般的なアクセス制御モデルとアクセス制御モデル同定。
- Secure transmission of updates.
- アップデートの送信を固定します。
- Replication among DITs with potentially differing schemas.
- 潜在的に異なるスキーマを持つディレクトリ情報ツリーの間でのレプリケーション。
A.4. Shared Name Space Example
A.4。共有ネームスペースの例
Two organizations may choose to cooperate on some venture and need a shared name space to manage their operation. Both organizations will require administrative rights over the shared name space.
二つの組織は、いくつかのベンチャーに協力し、その動作を管理するために、共有名前空間を必要とすることもできます。両組織は、共有名前空間の上に管理者権限が必要になります。
The requirements that follow from this scenario are:
このシナリオから続く要件は次のとおりです。
- Multi-Master replication.
- マルチマスターレプリケーション。
- Common access control model and access control model identification.
- 一般的なアクセス制御モデルとアクセス制御モデル同定。
- Secure transmission of updates.
- アップデートの送信を固定します。
A.5. Supplier Initiated Replication
A.5。サプライヤー開始レプリケーション
This is a single master environment that maintains a number of replicas of the DIT by pushing changes based on a defined schedule.
これは、定義されたスケジュールに基づいて変更を押すことにより、DITの複製の数を維持する単一のマスター環境です。
The requirements that follow from this scenario are:
このシナリオから続く要件は次のとおりです。
- Single-master environment.
- シングルマスター環境。
- Supplier-initiated replication.
- サプライヤー主導の複製。
- Secure transmission of updates.
- アップデートの送信を固定します。
A.6. Consumer Initiated Replication
A.6。消費者主導のレプリケーション
Again a single mastered replication topology, but the slave replica initiates the replication exchange rather than the master. An example of this is a replica that resides on a laptop computer that may run disconnected for a period of time.
ここでも、単一の習得レプリケーショントポロジが、スレーブのレプリカは、レプリケーション交換ではなく、マスターを開始します。この例は、ある期間にわたって切断を実行することができるラップトップ・コンピュータ上に存在するレプリカです。
The requirements that follow from this scenario are:
このシナリオから続く要件は次のとおりです。
- Single-master environment.
- シングルマスター環境。
- Consumer initiated replication.
- 消費者は、レプリケーションを開始しました。
- Open scheduling (anytime).
- オープンスケジューリング（いつでも）。
A.7. Prioritized attribute replication
A.7。優先順位付け属性の複製
The password attribute can provide an example of the requirement for prioritized attribute replication. A user is working in Utah and the administrator resides in California. The user has forgotten his password. So the user calls or emails the administrator to request a new password. The administrator provides the updated password (a change).
パスワード属性は優先順位属性の複製のための要件の例を提供することができます。ユーザーは、ユタ州で働いていると、管理者はカリフォルニアにあります。ユーザーが自分のパスワードを忘れてしまいました。したがって、ユーザーの通話や電子メール管理者が新しいパスワードを要求します。管理者は、更新されたパスワード（変更）を提供します。
Under normal conditions, the directory replicates to a number of different locations overnight. But corporate security policy states that passwords are critical and the new value must be available immediately (e.g., shortly) after any change. Replication needs to occur immediately for critical attributes/entries.
通常の条件下では、ディレクトリは一晩多数の異なる位置に複製されます。しかし、企業のセキュリティポリシーでは、パスワードが重要であり、新しい値は変更後（例えば、まもなく）すぐに利用可能でなければならないと述べています。レプリケーションは、重要な属性/エントリのためにすぐに発生する必要があります。
The requirements that follow from this scenario are:
このシナリオから続く要件は次のとおりです。
- Incremental replication of changes.
- 変更のインクリメンタルレプリケーション。
- Immediate replication on change of certain attributes.
- 特定の属性の変更に即時複製。
- Replicate based on time/attribute semantics.
- 時間/属性のセマンティクスに基づいて複製します。
A.8. Bandwidth issues
A.8。帯域幅の問題
The replication of Server (A) R/W replica (a) in Kathmandu is handled via a dial up phone link to Paris where server (B) R/W replica of (a) resides. Server (C) R/W replica of (a) is connected by a T1 connection to server (B). Each connection has a different performance characteristic.
サーバーの複製（A）R / Wレプリカ（A）カトマンズのサーバ（B）R / Wレプリカパリにダイアルアップ電話リンクを介して処理される（a）が存在します。 （A）は、サーバ（B）へのT1接続によって接続されているのサーバー（C）R / Wレプリカ。各接続は異なるパフォーマンス特性を有しています。
The requirements that follow from this scenario are:
このシナリオから続く要件は次のとおりです。
- Minimize repetitive updates when replicating from multiple replication paths.
- 複数のレプリケーション・パスから複製するときに、反復更新を最小限に抑えます。
- Incremental replication of changes.
- 変更のインクリメンタルレプリケーション。
- Provide replication cycles to delay and/or retry when connections cannot be reached.
- 接続は到達できない場合、遅延および/または再試行する複製サイクルを提供します。
- Allowances for consumer initiated or supplier initiated replication.
- 開始、消費者やサプライヤーのための引当金は、レプリケーションを開始しました。
A.9. Interoperable Administration and Management
A.9。相互運用管理および管理
The administrator with administrative authority of the corporate directory which is replicated by numerous geographically dispersed LDAP servers from different vendors notices that the replication process is not completing correctly as the change log is continuing to grow and/or error messages inform him. The administrator uses his $19.95 RepCo LDAP directory replication diagnostic tools to look at Root DSE replica knowledge on server 17 and determines that server 42 made by LDAP'RUS Inc. is not replicating properly due to an object conflict. Using his Repco Remote repair tools he connects to server 42 and resolves the conflict on the remote server.
異なるベンダーからの多数の地理的に分散したLDAPサーバによって複製された企業ディレクトリの管理権限を持つ管理者は、変更ログが成長および/またはエラーメッセージが彼に知らせるために続けていると、レプリケーションプロセスが正しく完了していないことに気付きます。管理者は、サーバ17上のルートDSEのレプリカの知識を見て彼の$ 19.95レプコLDAPディレクトリ・レプリケーションの診断ツールを使用し、LDAP'RUS社製サーバ42が原因オブジェクトの競合に適切にレプリケートされていないと判断します。彼のレプコリモート修復ツールを使用して、彼は、サーバ42に接続し、リモートサーバー上の競合を解決します。
The requirements that follow from this scenario are:
このシナリオから続く要件は次のとおりです。
- Provide replication audit history.
- 複製監査履歴を提供します。
- Provide mechanisms for managing conflict resolution.
- 紛争解決を管理するためのメカニズムを提供します。
- Provide LDAP access to predetermined agreements, topology and policy attributes.
- 所定の契約、トポロジーおよびポリシー属性へのLDAPアクセスを提供します。
- Provide operations for comparing replica's content for validity.
- 有効性のためのレプリカの内容を比較するための操作を提供します。
- Provide LDAP access to status and audit information.
- ステータスと監査情報へのLDAPアクセスを提供します。
A.10. Enterprise Directory Replication Mesh
A.10。エンタープライズディレクトリの複製メッシュ
A Corporation builds a mesh of directory servers within the enterprise utilizing LDAP servers from various vendors. Five servers are holding the same area of replication. The predetermined replication agreement(s) for the enterprise mesh are under a single management, and the security domain allows a single predetermined replication agreement to manage the 5 servers' replication.
当社は、さまざまなベンダーからLDAPサーバを利用し、企業内のディレクトリサーバーのメッシュを作成します。 5台のサーバーは、レプリケーションの同じ領域を保持しています。企業のメッシュの所定の複製合意（S）は、単一の管理下にあり、セキュリティドメインは、5台のサーバのレプリケーションを管理するための単一の所定のレプリケーション承諾することができます。
The requirements that follow from this scenario are:
このシナリオから続く要件は次のとおりです。
- One predefined replication agreement that manages a single area of replication that is held on numerous servers.
- 多数のサーバ上に保持され、レプリケーションの単一の領域を管理して一つの事前に定義されたレプリケーションアグリーメント。
- Common support of replication management knowledge across vendor implementation.
- ベンダーの実装間でレプリケーション管理の知識の一般的なサポート。
- Rescheduling and continuation of a replication cycle when one server in a replica-group is busy and/or unavailable.
- 再スケジュールおよび複製サイクルの継続レプリカグループ内の1台のサーバがビジー状態および/または使用できません。
A.11. Failure of the Master in a Master-Slave Replicated Directory
A.11。マスタースレーブレプリケート・ディレクトリのマスターの失敗
A company has a corporate directory that is used by the corporate email system. The directory is held on a mesh of servers from several vendors. A corporate relocation results in the closing of the location where the master copy of the directory is located. Employee information (such as mailbox locations and employee certificate information) must be kept up to date or mail cannot be delivered.
同社は、企業の電子メールシステムで使用されている企業ディレクトリを持っています。ディレクトリは、いくつかのベンダーからのサーバのメッシュ上に保持されています。企業の移転は、ディレクトリのマスターコピーが置かれている場所の閉鎖につながります。 （例えば、メールボックスの場所と従業員の証明書情報など）従業員の情報を最新の状態に保たれなければならないか、メールが配信できません。
The requirements that follow from this scenario are:
このシナリオから続く要件は次のとおりです。
- An existing slave replica must be "promote-able" to become the new master.
- 既存の奴隷レプリカは「プロモート可能な」新しいマスターになるためにでなければなりません。
- The "promotion" must be done without significant downtime, since updates to the directory will continue.
- ディレクトリへの更新は継続されますので、「プロモーション」は、大幅なダウンタイムなしで実行する必要があります。
A.12. Failure of a Directory Holding Critical Service Information
A.12。ディレクトリ・ホールディングクリティカルサービス情報の失敗
An ISP uses a policy management system that uses a directory as the policy data repository. The directory is replicated in several different sites on different vendors' products to avoid single points of failure. It is imperative that the directory be available and be updateable even if one site is disconnected from the network. Changes to the data must be traceable, and it must be possible to determine how changes made from different sites interacted.
ISPは、ポリシーデータリポジトリとしてディレクトリを使用するポリシー管理システムを使用しています。ディレクトリは、単一障害点を避けるために、異なるベンダーの製品にはいくつかの異なるサイトに複製されます。ディレクトリが利用できるようにしてあるサイトがネットワークから切断された場合でも更新可能であることが不可欠です。データへの変更は、トレーサブルでなければならず、別のサイトからの変更は相互作用方法を決定することが可能でなければなりません。
The requirements that follow from this scenario are:
このシナリオから続く要件は次のとおりです。
- Multi-master replication.
- マルチマスターレプリケーション。
- Ability to reschedule replication sessions.
- レプリケーションセッションのスケジュールを変更する機能。
- Support for manual review and override of replication conflict resolution.
- マニュアルレビューとレプリケーションの紛争解決のオーバーライドをサポートします。
B. APPENDIX B - Rationale
B.付録B - 根拠
This Appendix gives some of the background behind the requirements. It is included to help the protocol designers understand the thinking behind some of the requirements and to present some of the issues that should be considered during design. With the exception of section B.8, which contains a suggested requirement for the update to RFC 2251, this Appendix does not state any formal requirements.
この付録では、要件の背景の一部を提供します。プロトコル設計者は、要件の一部の背後にある考え方を理解し、設計時に考慮すべき問題のいくつかを提示するのに役立つために含まれています。 RFC 2251へのアップデートのための提案の要件が含まれているセクションB.8を除き、この付録は正式な要件を述べるものではありません。
B.1. Meta-Data Implications
B.1。メタデータへの影響
Requirement G4 states that meta-data must not grow without bound. This implies that meta-data must, at some point, be purged from the system. This, in turn, raises concerns about stability. Purging meta-data before all replicas have been updated may lead to incomplete replication of change information and inconsistencies among replicas. Therefore, care must be taken setting up the rules for purging meta-data from the system while still ensuring that meta-data will not grow forever.
要件G4は、メタデータが際限なく増加しなければならないと述べています。これは、メタデータは、ある時点で、システムからパージされなければならないことを意味します。これは、順番に、安定性が懸念されます。すべてのレプリカはレプリカ間で変更情報と矛盾の不完全な複製につながる可能性が更新されました前に、メタデータをパージします。そのため、注意がまだメタデータは永遠に成長しないようにしながらシステムからメタデータをパージするためのルールを設定取らなければなりません。
B.2. Order of Transfer for Replicating Data
B.2。複製データの転送の順序
Situations may arise where it would be beneficial to replicate data out-of-order (e.g., send data to consumer replicas in a different order than it was processed at the supplier replica). One such case might occur if a large bulk load was done on the master server in a single-master environment and then a single change to a critical OID (a password change, for example) was then made. Rather than wait for all the bulk data to be sent to the replicas, the password change might be moved to the head of the queue and be sent before all the bulk data was transferred. Other cases where this might be considered are schema changes or changes to critical policy data stored in the directory.
アウトオブオーダー（例えば、それは、サプライヤレプリカで処理されたものとは異なる順序でコンシューマレプリカにデータを送信）データを複製することが有益である状況が生じ得ます。大きなバルク・ロードは、シングルマスター環境でマスターサーバー上で行われた、その後の重要なOID（たとえば、パスワードの変更、）への単一の変更は、その後行われた場合にはそのようなケースが発生する可能性があります。レプリカに送信されるすべてのバルクデータを待つのではなく、パスワードの変更は、キューの先頭に移動される可能性がありますし、すべてのバルクデータが転送される前に送信され。これは考えられるかもしれない他の例には、スキーマの変更またはディレクトリに保存された重要な政策データへの変更です。
While there are practical benefits to allowing out-of-order transfer, there are some negative consequences as well. Once out-of-order transfers are permitted, all receiving replicas must be prepared to deal with data and schema conflicts that might arise.
アウトオブオーダー転送できるように実用的なメリットがありますが、同様にいくつかのマイナスの影響があります。転送が許可されていたら、アウト・オブ・オーダー、全ての受信レプリカが生じる可能性のあるデータとスキーマの競合に対処する準備をしなければなりません。
As an example, assume that schema changes are critical and must be moved to the front of the replication queue. Now assume that a schema change deletes an attribute for some object class. It is possible that some of the operations ahead of the schema change in the queue are operations to delete values of the soon-to-be-deleted attribute so that the schema change can be done with no problems. If the schema change moves to the head of the queue, the consumer servers might have to delete an attribute that still has values, and then receive requests to delete the values of an attribute that is no longer defined.
例として、スキーマの変更が重要であり、複製キューの先頭に移動しなければならないことを前提としています。今、スキーマの変更は、いくつかのオブジェクトクラスの属性を削除することを前提としています。操作の一部が先行し、キュー内のスキーマ変更のスキーマ変更は問題なく行うことができるように、すぐツー・削除される属性の値を削除するために操作されている可能性があります。スキーマの変更は、キューの先頭に移動した場合は、コンシューマサーバは、まだ値を持つ属性を削除する必要があり、その後、もはや定義された属性の値を削除する要求を受け取ることがあります。
In the multi-master case, similar situations can arise when simultaneous changes are made to different replicas. Thus, multi-master systems must have conflict resolution algorithms in place to handle such situations. But in the single-master case conflict resolution is not needed unless the master is allowed to send data out-of-order. This is the reasoning behind requirement SM2, which recommends that data always be sent in order in single-master replication.
同時変更が異なるレプリカに作られている場合、マルチマスター場合、同様の状況が生じる可能性があります。このように、マルチマスタシステムでは、このような状況に対処するための場所で紛争解決アルゴリズムを持っている必要があります。マスターは、アウトオブオーダデータを送信することが許可されていない場合でも、単一マスターケースの紛争解決に必要とされていません。これは、データが常に単一マスター・レプリケーションに順番に送られることをお勧めします要件SM2、背後にある理由です。
Note that even with this restriction, the concept of a critical OID is still useful in single-master replication. An example of its utility can be found in section A.7.
でも、この制限で、重要なOIDの概念はまだシングルマスターレプリケーションに有用であることに注意してください。その有用性の例は、セクションA.7で見つけることができます。
B.3. Schema Mismatches and Replication
B.3。スキーマの不一致とレプリケーション
Multi-vendor environments are the primary area of interest for LDAP replication standards. Some attention must thus be paid to the issue of schema mismatches, since they can easily arise when vendors deliver slightly different base schema with their directory products. Even when both products meet the requirements of the standards [RFC2252], the vendors may have included additional attributes or object classes with their products. When two different vendors' products attempt to replicate, these additions can cause schema mismatches. Another potential cause of schema mismatches is discussed in section A.3.
マルチベンダー環境ではLDAPレプリケーション規格の関心の主要なエリアです。ベンダーがディレクトリ製品と多少異なるベースのスキーマを提供するとき、彼らは簡単に発生する可能性があるので、いくつかの注意は、このように、スキーマの不一致の問題に支払わなければなりません。両製品は、標準規格[RFC2252]の要件を満たす場合でも、ベンダーは自社製品で追加の属性またはオブジェクトクラスが含まれている可能性があります。二つの異なるベンダーの製品を複製しようとすると、これらの追加は、スキーマの不一致を引き起こす可能性があります。スキーマの不一致の別の潜在的な原因は、セクションA.3で説明されています。
There are only a few possible responses when a mismatch is discovered.
不一致が発見された少数の可能な応答があります。
- Raise an error condition and ignore the data. This should always be allowed and is the basis for requirement P8 and the comment on M10.
- エラー状態を上げてデータを無視します。これは、常に許可されると、要件P8とM10にコメントの基礎となるべきです。
- Map/convert the data to the form required by the consuming replica. A system may choose this course; requirement M10 is intended to allow this option. The extent of the conversion is up to the implementation; in the extreme it could support use of the replication protocol in meta-directories.
- 地図/消費するレプリカで必要な形式にデータを変換します。システムは、このコースを選んでもよいです。要件M10は、このオプションを可能にすることを意図しています。変換の程度は実装次第です。極端では、メタディレクトリ内のレプリケーション・プロトコルの使用をサポートすることができました。
- Quietly ignore (do not store on the consumer replica and do not raise an error condition) any data that does not conform to the schema at the consumer.
- 静か（コンシューマレプリカに保存していないと、エラー状態を上げていない）、消費者のスキーマに準拠していない任意のデータを無視します。
Requirement M10 is intended to exclude the last option.
要件M10は最後のオプションを排除することを意図しています。
Requirement AM8 suggests that vendors should provide tools to help discover schema mismatches when replication is being set up. But schema will change after the initial setup, so the replication system must be prepared to handle unexpected mismatches.
要件AM8は、ベンダーが、レプリケーションが設定されているときに、スキーマの不一致を発見するのに役立つツールを提供すべきであることを示唆しています。しかし、スキーマは、初期設定後に変更されますので、複製システムは、予想外の不一致を処理するために準備する必要があります。
Normal IETF practice in protocol implementation suggests that one be strict in what one sends and be flexible in what one receives. The parallel in this case is that a supplier should be prepared to receive an error notification for any schema mismatch, but a consumer may choose to do a conversion instead.
プロトコルの実装では、通常のIETFの練習は1つが1を送信するもので、厳密なこと、もう1つは受信するものでは柔軟であることを示唆しています。この場合の平行業者が任意のスキーマの不一致のためにエラー通知を受信するように準備されるべきことであるが、消費者は、代わりに、変換を実行することを選択することができます。
The other option that can be considered in this situation is the use of fractional replication. If replication is set up so only the common attributes are replicated, mismatches can be avoided.
この状況で考慮することができる他のオプションは、部分レプリケーションの使用です。レプリケーションがそのように設定されている場合のみ、共通の属性が複製され、不整合を回避することができます。
One additional consideration here is replication of the schema itself. M4 requires that it be possible to replicate schema. If a consumer replica is doing conversion, extreme care should be taken if schema elements are replicated since some attributes are intended to have different definitions on different replicas.
ここに一つの追加の考慮事項は、スキーマ自体の複製です。 M4は、スキーマを複製することは可能である必要があります。コンシューマレプリカが変換を行っている場合は、いくつかの属性が異なるレプリカで異なる定義を有することが意図されているので、スキーマ要素が複製されている場合は、細心の注意を払うべきです。
For fractional replication, the protocol designers and implementors should give careful consideration to the way they handle schema replication. Some options for schema replication include:
部分レプリケーションのために、プロトコル設計者と実装者は、彼らが、スキーマのレプリケーションを処理する方法に細心の配慮を与える必要があります。スキーマの複製のためのいくつかのオプションが含まれます：
- All schema elements are replicated.
- すべてのスキーマ要素が複製されます。
- Schema elements are replicated only if they are used by attributes that are being replicated.
- スキーマ要素は、それらが複製されている属性によって使用されている場合にのみ複製されます。
- Schema are manually configured on the servers involved in fractional replication; schema elements are not replicated via the protocol.
- スキーマを手動部分レプリケーションに関係するサーバー上に構成されています。スキーマ要素は、プロトコルを介して複製されません。
B.4. Detecting and Repairing Inconsistencies Among Replicas
B.4。レプリカ間の検出と修復不整合
Despite the best efforts of designers, implementors, and operators, inconsistencies will occasionally crop up among replicas in production directories. Tools will be needed to detect and to correct these inconsistencies.
デザイナー、実装、および演算子の最善の努力にもかかわらず、矛盾は時折、生産ディレクトリ内のレプリカ間までトリミングします。ツールが検出し、これらの不整合を修正するために必要とされるであろう。
A special client may accomplish detection through periodic comparisons of replicas. This client would typically read two replicas of the same replication base entry and compare the answers, possibly by BINDing to each of the two replicas to be compared and reading them both. In cases where the directory automatically reroutes some requests (e.g., chaining), mechanisms to force access to a particular replica should be supplied.
特別なクライアントは、レプリカの定期的な比較によって検出を達成することができます。このクライアントは通常、同じレプリケーションベースエントリの2つのレプリカを読んで、おそらく比較される2つのレプリカのそれぞれに結合し、それらの両方を読み込むことで、答えを比較します。ディレクトリは自動的にいくつかのリクエストを再ルーティングする場合（例えば、チェーン）において、機構は、特定のレプリカへのアクセスを強制することが供給されなければなりません。
Alternatively, the server could support a special request to handle this situation. A client would invoke an operation at some server. It would cause that server to extract the contents from some other server it has a replication agreement with and report the differences back to the client as the result.
また、サーバは、この状況に対処するための特別な要求をサポートすることができました。クライアントは、いくつかのサーバーでの動作を呼び出します。これは、そのサーバは、それが持つレプリケーション契約を締結しているいくつかの他のサーバからコンテンツを抽出し、その結果としてクライアントに差異を報告させるでしょう。
If an inconsistency is found, it needs to be repaired. To determine the appropriate repair, the administrator will need access to the replication history to figure out how the inconsistency occurred and what the correct repair should be.
矛盾が見つかった場合、それが修復する必要があります。適切な修復を判断するには、管理者は矛盾が発生したかを把握するために、正しい修理がどうあるべきか複製履歴にアクセスする必要があります。
When a repair is made, it should be restricted to the replica that needs to be fixed; the repair should not cause new replication events to be started. This may require special tools to change the local data store without triggering replication.
修理が行われた場合、それは修正する必要がレプリカに限定する必要があります。修理が開始される新しい複製イベントが発生することはありません。これは、レプリケーションをトリガすることなく、ローカルデータストアを変更するために特別なツールが必要な場合があります。
Requirements AM2, AM4, and AM5 address these needs.
要件AM2、AM4、およびAM5は、これらのニーズに対応しています。
B.5. Some Test Cases for Conflict Resolution in Multi-Master Replication
B.5。マルチマスターレプリケーションでの紛争解決のためのいくつかのテストケース
Use of multi-master replication inevitably leads to the possibility that incompatible changes will be made simultaneously on different servers. In such cases, conflict resolution algorithms must be applied.
マルチマスターレプリケーションを使用すると、必然的に互換性のない変更が異なるサーバーに同時に行われる可能性につながります。このような場合には、競合解決アルゴリズムが適用されなければなりません。
As a guiding principle, conflict resolution should avoid surprising the user. One way to do this is to adopt the principle that, to the extent possible, conflict resolution should mimic the situation that would happen if there were a single server where all the requests were handled.
基本理念として、紛争解決には、ユーザーを驚か避けるべきです。これを行う1つの方法は、可能な限り、紛争解決は、すべての要求が処理された単一のサーバーがあった場合にどうなる状況を模倣すべきである、という原則を採用することです。
While this is a useful guideline, there are some situations where it is impossible to implement. Some of these cases are examined in this section. In particular, there are some cases where data will be "lost" in multi-master replication that would not be lost in a single-server configuration.
これは便利なガイドラインですが、実現することは不可能であるいくつかの状況があります。これらの例のいくつかは、このセクションで検討されています。特に、データは、単一サーバー構成で失われることはないマルチマスターレプリケーションでは「失われた」ことになる場合があります。
In the examples below, assume that there are three replicas, A, B, and C. All three replicas are updateable. Changes are made to replicas A and B before replication allows either replica to see the change made on the other. In discussion of the multi-master cases, we assume that the change to A takes precedence using whatever rules are in force for conflict resolution.
以下の実施例では、すべての3つの複製が更新されている3つの複製、A、B、およびCが存在すると仮定する。変更は複製がレプリカのいずれかが、他の上で行われた変更を確認することができます前に、AとBのレプリカに作られています。マルチマスタ例の議論では、我々はAへの変更は、紛争解決のために施行されているものは何でも規則使用して優先されることを想定しています。
B.5.1. Create-Create
B.5.1。作成し、作成します。
A user creates a new entry with distinguished name DN on A. At the same time, a different user adds an entry with the same distinguished name on B.
ユーザーが同時にA.上の識別名DNで新しいエントリを作成し、別のユーザーは、Bで同じ識別名を持つエントリを追加します
In the single-server case, one of the create operations would have occurred before the other, and the second request would have failed.
単一サーバの場合は、作成操作の一方が他方の前に起こっているだろう、と2番目の要求は失敗しただろう。
In the multi-master case, each create was successful on its originating server. The problem is not detected until replication takes place. When a replication request to create a DN that already exists arrives at one of the servers, conflict resolution is invoked. (Note that the two requests can be distinguished even though they have the same DN because every entry has some sort of unique identifier per requirement SC9.)
マルチマスタの場合は、それぞれが作成し、その元のサーバー上で成功しました。レプリケーションが行われるまでの問題が検出されません。すでに存在するDNを作成するための複製要求がサーバーのいずれかに到着すると、紛争解決が呼び出されます。 （2つの要求は、すべてのエントリは、要件SC9ごとに一意の識別子のいくつかの並べ替えを持っているので、彼らは同じDNを持っているにもかかわらず区別できることに注意してください。）
As noted above, in these discussions we assume that the change from replica A has priority based on the conflict resolution algorithm. Whichever change arrives first, requirement MM6 says that the values from replica A must be those in place on all replicas at the end of the replication cycle. Requirement MM5 states that the system cannot quietly ignore the values from replica B.
上述したように、これらの議論では、我々は、レプリカAからの変更は、競合解決アルゴリズムに基づいて優先権を持っていることを前提としています。どちらの変更が最初に到着し、要件MM6は、レプリカAから値が複製サイクルの終了時にすべてのレプリカの場所のものでなければならないと述べています。要件MM5は、システムが静かにレプリカBから値を無視することはできませんと述べています
The values from replica B might be logged with some notice to the administrators, or they might be added to the DIT with a machine generated DN (again with notice to the administrators). If they are stored with a machine generated DN, the same DN must be used on all servers in the replica-group (otherwise requirement M3 would be violated). Note that in the case where the entry in question is a container, storage with a machine generated DN provides a place where descendent entries may be stored if any descendents were generated before the replication cycle was completed.
レプリカBからの値は、管理者に、いくつかの通知をログに記録されるかもしれない、またはそれらは、（管理者に再度通知して）DN発生機でDITに追加されるかもしれません。彼らはDN生成されたマシンに保存されている場合は、同じDNはレプリカグループ内のすべてのサーバ上で使用する必要があります（そうでない要件M3は、これを侵してしまいます）。当該エントリは、複製サイクルが完了する前に、任意の子孫が生成された場合、子孫エントリが格納されてもよい場所を提供DN発生機を有する容器、貯蔵の場合になお。
In any case, some mechanism must be provided to allow the administrator to reverse the conflict resolution algorithm and force the values originally created on B into place on all replicas if desired.
いずれの場合においても、いくつかのメカニズムは、管理者が競合解決アルゴリズムを逆にし、所望であれば、すべてのレプリカ上の所定の位置にBで最初に作成された値を強制することを可能にするために提供されなければなりません。
B.5.2. Rename-Rename
B.5.2。名前の変更、名前の変更
On replica A, an entry with distinguished name DN1 is renamed to DN. At the same time on replica B, an entry with distinguished name DN2 is renamed to DN.
レプリカAには、識別名DN1を持つエントリはDNに変更されます。レプリカB上同時に、識別名DN2を持つエントリはDNに変更されます。
In the single-server case, one rename operation would occur before the other and the second would fail since the target name already exists.
単一サーバの場合、1名の変更操作は、他の前に起こるであろうと、ターゲット名が既に存在するので、二つ目は失敗します。
In the multi-master case, each rename was successful on its originating server. Assuming that the change on A has priority in the conflict resolution sense, DN will be left with the values from DN1 in all replicas and DN1 will no longer exist in any replica. The question is what happens to DN2 and its original values.
マルチマスタの場合は、それぞれの名前の変更は、その元のサーバー上で成功しました。 A上の変更が競合解決の意味で優先度を有すると仮定すると、DNは、すべてのレプリカでDN1の値で残されるとDN1はもはやレプリカに存在しないであろう。質問は、DN2とその元の値に何が起こるかです。
Requirement MM5 states that these values must be stored somewhere. They might be logged, they might be left in the DIT as the values of DN2, or they might be left in the DIT as the values of some machine generated DN. Leaving them as the values of DN2 is attractive since it is the same as the single-server case, but if a new DN2 has already been created before the replica cycle finishes, there are some very complex cases to resolve. Any of the solutions described in this paragraph would be consistent with requirement MM5.
要件MM5は、これらの値をどこかに保存しなければならないと述べています。彼らはDN2の値としてDITに残されるかもしれませんが、ログに記録されるかもしれない、あるいはいくつかのマシンの値はDNを生成したとして、彼らはDITに残されている可能性があります。それは単一サーバの場合と同じですが、レプリカサイクルが終了する前に新しいDN2が既に作成されている場合、解決するためにいくつかの非常に複雑な場合があるので、DN2の値としてそれらを残すことは魅力的です。この段落で説明するソリューションのいずれかが要件MM5と一致するであろう。
B.5.3. Locking Based on Atomicity of ModifyRequest
B.5.3。 ModifyRequestの不可分性に基づいて、ロック
There is an entry with distinguished name DN that contains attributes X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is processed which includes modifications to change that value of X from 1 to 0 and to set the value of Y to "USER1". At the same time, replica B processes a ModifyRequest which includes modifications to change the value of X from 1 to 0 and to set the value of Y to "USER2" and the value of Z to 42. The application in this case is using X as a lock and is depending on the atomic nature of ModifyRequests to provide mutual exclusion for lock access.
Xの値は、レプリカA 1.あり、Y、およびZを属性Xを含有する識別名DNを持つエントリがあり、ModifyRequestは修正1から0にXの値を変更し、設定するを含む処理され「USER1」とYの値。これと同時に、レプリカBは、この場合には42に変更0 1からXの値を変更すると、「USER2」にYの値を設定し、Zの値を含むModifyRequestにアプリケーションを処理Xを使用していますロックなど、ロックアクセスのための相互排他を提供するために、ModifyRequestsの原子性質に応じています。
In the single-server case, the two operations would have occurred sequentially. Since a ModifyRequest is atomic, the entire first operation would succeed. The second ModifyRequest would fail, since the value of X would be 0 when it was attempted, and the modification changing X from 1 to 0 would thus fail. The atomicity rule would cause all other modifications in the ModifyRequest to fail as well.
単一サーバの場合は、2つの操作が順次発生しているだろう。 ModifyRequestがアトミックであるので、全体の最初の操作が成功するでしょう。それが試みられた、1から0へのXを変更する変更は、このように失敗したときにXの値が0になるので、第二ModifyRequestは、失敗するだろう。アトミックルールはModifyRequest内の他のすべての変更も同様に失敗する原因となります。
In the multi-master case, it is inevitable that at least some of the changes will be reversed despite the use of the lock. Assuming the changes from A have priority per the conflict resolution algorithm, the value of X should be 0 and the value of Y should be "USER1" The interesting question is the value of Z at the end of the replication cycle. If it is 42, the atomicity constraint on the change from B has been violated. But for it to revert to its previous value, grouping information must be retained and it is not clear when that information can be safely discarded. Thus, requirement G6 may be violated.
マルチマスタの場合、変化の少なくとも一部は、ロックを使用しても逆になることは避けられません。 Aからの変更が競合解決アルゴリズムごとに優先順位を持っていると仮定すると、Xの値が0であるべきであり、Yの値が「USER1」興味深い問題が複製サイクルの終了時のZの値であるべきです。それが42である場合、Bからの変更のアトミック性制約が違反しています。しかし、それはその前の値に戻すために、グループ化情報が保持されなければならないし、その情報を安全に廃棄することができたときに、それは明らかではありません。したがって、要件G6に違反することができます。
B.5.4. General Principles
B.5.4。一般原理
With multi-master replication there are a number of cases where a user or application will complete a sequence of operations with a server but those actions are later "undone" because someone else completed a conflicting set of operations at another server.
マルチマスターレプリケーションであり、ユーザやアプリケーションがサーバーとの一連の操作を完了します例数があるが、他の誰かが別のサーバーでの操作の競合セットを完了しているため、それらのアクションは、後に「元に戻す」です。
To some extent, this can happen in any multi-user system. If a user changes the value of an attribute and later reads it back, intervening operations by another user may have changed the value. In the multi-master case, the problem is worsened, since techniques used to resolve the problem in the single-server case won't work as shown in the examples above.
ある程度、これは任意のマルチユーザシステムで発生する可能性があります。ユーザーが後で属性の値を変更した場合は、別のユーザーによる操作を介在、それをリードバック値を変更している場合があります。上記の例に示すようにシングルサーバの場合に問題を解決するために使用される技術は、動作しませんので、マルチマスター場合に、問題が悪化します。
The major question here is one of intended use. In LDAP standards work, it has long been said that replication provides "loose consistency" among replicas. At several IETF meetings and on the mailing list, usage examples from finance where locking is required have been declared poor uses for LDAP. Requirement G1 is consistent with this history. But if loose consistency is the goal, the locking example above is an inappropriate use of LDAP, at least in a replicated environment.
ここでの主要な問題は、使用目的の一つです。 LDAPの標準化作業では、長い複製がレプリカの間で「緩やかな一貫性」を提供することを言われています。いくつかのIETF会合でメーリングリスト上で、ロックが必要とされる資金の使用例は、LDAPの貧用途が宣言されています。要件G1は、この歴史と一致しています。緩やかな一貫性が目標である場合でも、上記のロックの例では、少なくともレプリケートされた環境では、LDAPの不適切な使用です。
B.5.5. Avoiding the Problem
B.5.5。問題の回避
The examples above discuss some of the most difficult problems that can arise in multi-master replication. While they can be dealt with, dealing with them is difficult and can lead to situations that are quite confusing to the application and to users.
上記の例は、マルチマスターレプリケーションで発生する可能性が最も困難な問題のいくつかを議論します。彼らは対処することができますが、それらに対処することは困難であり、アプリケーションに、ユーザーに非常に混乱している状況につながることができます。
The common characteristics of the examples are:
例の共通の特徴は以下のとおりです。
- Several directory users/applications are changing the same data.
- いくつかのディレクトリユーザ/アプリケーションが同じデータを変更しています。
- They are changing the data before previous changes have replicated.
- 以前の変更が複製される前に、彼らはデータを変更しています。
- They are using different directory servers to make these changes.
- 彼らは、これらの変更を行うために別のディレクトリサーバを使用しています。
- They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request.
- 彼らは、識別名、または、それらの部品は単一の原子のリクエストで指定された属性値の読み取りと書き込みの両方ModifyRequestを使用しているされているデータを変更しています。
If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions does not occur. For cases where all four do occur, application designers should be aware of the possible consequences.
これらの条件のいずれかが逆になった場合は、上記の問題の種類は発生しません。上記の条件のうちの少なくとも1つが発生しないマルチマスタディレクトリの多くの有用な用途があります。 4つのすべてが発生した場合のために、アプリケーション設計者は、可能な結果に注意する必要があります。
B.6. Data Confidentiality and Data Integrity During Replication
B.6。レプリケーション中にデータの機密性とデータの整合性
Directories will frequently hold proprietary information. Policy information, name and address information, and customer lists can be quite proprietary and are likely to be stored in directories. Such data must be protected against intercept or modification during replication.
ディレクトリは頻繁に専有情報を保持します。ポリシー情報、名前と住所の情報、および顧客リストには、非常に独自のことやディレクトリに格納される可能性が高いことができます。このようなデータは、レプリケーション中に傍受や変更から保護されなければなりません。
In some cases, the network environment (e.g., a private network) may provide sufficient data confidentiality and integrity for the application. In other cases, the data in the directory may be public and not require protection. For these reasons data confidentiality and integrity were not made requirements for all replication sessions. But there are a substantial number of applications that will need data confidentiality and integrity for replication, so there is a requirement (S4) that the protocol allow for data confidentiality and integrity in those cases where they are needed. Typically, the policy on the use of confidentiality and integrity measures would be held in the replication agreement per requirement M7.
いくつかのケースでは、ネットワーク環境（例えば、プライベートネットワーク）は、アプリケーションのための十分なデータの機密性と完全性を提供することができます。他の例では、ディレクトリ内のデータは、公開することと保護を必要としなくてもよいです。これらの理由から、データの機密性と整合性は、すべてのレプリケーションセッションの要件を行いませんでした。しかし、レプリケーションのためのデータの機密性と整合性を必要とするアプリケーションのかなりの数がありますので、プロトコルは、彼らが必要とされるような場合には、データの機密性と完全性を可能にすることを要求（S4）があります。一般的に、機密性と完全性対策の使用に関するポリシーが要件M7あたりのレプリケーション承諾で開催されるだろう。
This leaves the question of what mechanism(s) to use. While this is ultimately a design/implementation decision, replication across different vendors' directory products is an important goal of the LDAP replication work at the IETF. If different vendors choose to support different data confidentiality and integrity mechanisms, the advantages of a standard replication protocol would be lost. Thus there is a requirement (S6) for mandatory-to-implement data confidentiality and integrity mechanisms.
これは、どのようなメカニズム（複数可）を使用するの疑問を残します。これは最終的には設計/実装上の決定であるが、異なるベンダーのディレクトリ製品間でのレプリケーションは、IETFでのLDAPレプリケーションの仕事の重要な目標です。異なるベンダーが異なるデータの機密性と整合性のメカニズムをサポートすることを選択した場合、標準のレプリケーション・プロトコルの利点が失われてしまいます。したがって強制的に実装データの機密性と完全性機構の要件（S6）があります。
Anonymous replication (requirement S3) is supported since it may be useful in the same sorts of situations where data integrity and data confidentiality protection are not needed.
それは、データの整合性とデータの機密保護が必要とされていない状況での同じ種類のに有用であるかもしれないので、匿名の複製（要件S3）がサポートされています。
B.7. Failover in Single-Master Systems
B.7。シングルマスタシステムでフェイルオーバー
In a single-master system, all modifications must originate at the master. The master is therefore a single point of failure for modifications. This can cause concern when high availability is a requirement for the directory system.
シングルマスタシステムでは、すべての変更は、マスタで発生しなければなりません。マスターは、したがって変更するための単一障害点です。高可用性は、ディレクトリシステムのための必要条件であるとき、これは懸念を引き起こす可能性があります。
One way to reduce the problem is to provide a failover process that converts a slave replica to master when the original master fails. The time required to execute the failover process then becomes a major factor in availability of the system as a whole.
問題を軽減する一つの方法は、元のマスターに障害が発生したときにマスターするスレーブレプリカを変換し、フェールオーバープロセスを提供することです。フェイルオーバー・プロセスを実行するのに必要な時間は、その後、システム全体の可用性における主要な要因となります。
Factors that designers and implementors should consider when working on failover include:
フェイルオーバーで作業する場合、設計者と実装者が考慮すべき要因は次のとおりです。
- If the master replica contains control information or meta-data that is not part of the slave replica(s), this information will have to be inserted into the slave that is being "promoted" to master as part of the failover process. Since the old master is presumably unavailable at this point, it may be difficult to obtain this data. For example, if the master holds the status information of all replicas, but each slave replica only holds its own status information, failover would require that the new master get the status of all existing replicas, presumably from those replicas. Similar issues could arise for replication agreements if the master is the only system that holds a complete set.
- マスターレプリカがスレーブレプリカ（S）の一部ではない情報またはメタデータを制御含まれている場合、この情報は、フェイルオーバー・プロセスの一部としてマスタに「昇格」されているスレーブに挿入されなければなりません。古いマスターは、この時点ではおそらく利用できないので、このデータを得ることは難しいかもしれません。マスターは、すべてのレプリカのステータス情報を保持しているが、各スレーブレプリカのみ、自身のステータス情報を保持している場合たとえば、フェイルオーバーは、新しいマスターは、これらのレプリカから、おそらく、すべての既存のレプリカのステータスを取得することを必要とするでしょう。マスターは完全なセットを保持している唯一のシステムであれば同様の問題がレプリケーションアグリーメントのために発生する可能性があります。
- If data privacy mechanisms (e.g., encryption) are in use during replication, the new master would need to have the necessary key information to talk to all of the slave replicas.
- データ・プライバシー・メカニズム（例えば、暗号化）レプリケーション中に使用されている場合は、新しいマスターはスレーブ・レプリカのすべてに話をするために必要な重要な情報を持っている必要があります。
- It is not only the new master that needs to be reconfigured. The slaves also need to have their configurations updated so they know where updates should come from and where they should refer modifications.
- それは、再設定する必要が新しいマスターだけではありません。奴隷も更新がから来るべきで、どこが変更を参照すべきであるところ、彼らは知っているので、その構成を更新する必要があります。
- The failover mechanism should be able to handle a situation where the old master is "broken" but not "dead". The slave replicas should ignore updates from the old master after failover is initiated.
- フェールオーバーメカニズムは、古いマスターが「壊れた」ではなく「死」である状況を処理することができるはずです。フェイルオーバーが開始された後、スレーブレプリカは古いマスターから更新を無視すべきです。
- The old master will eventually be repaired and returned to the replica-group. It might join the group as a slave and pick up the changes it has "missed" from the new master, or there might be some mechanism to bring it into sync with the new master and then let it take over as master. Some resynchronization mechanism will be needed.
- 古いマスターは最終的に修復し、レプリカ・グループに返されます。これは、スレーブとしてグループに参加し、それが新しいマスターから「見逃し」している変化を拾う、または新しいマスターと同期にそれを持参し、それをマスターとして引き継ぐようにするいくつかのメカニズムがあるかもしれないかもしれません。いくつかの再同期メカニズムが必要になります。
- Availability would be maximized if the whole failover process could be automated (e.g., failover is initiated by an external system when it determines that the original master is not functioning properly).
- 全体のフェイルオーバー・プロセスを自動化することができれば、可用性が最大化されるであろう（それは元のマスタが適切に機能していないと判断した場合、例えば、フェイルオーバーは、外部システムによって開始されます）。
B.8. Including Operational Attributes in Atomic Operations
B.8。アトミックオペレーションで操作属性を含みます
LDAPv3 [RFC2251] declares that some operations are atomic (e.g., all of the modifications in a single ModifyRequest). It also defines several operational attributes that store information about when changes are made to the directory (createTimestamp, etc.) and which ID was responsible for a given change (modifiersName, etc.). Currently, there is no statement in RFC2251 requiring that changes to these operational attributes be atomic with the changes to the data.
LDAPv3の[RFC2251]はいくつかの操作がアトミックであることを宣言し（例えば、単一ModifyRequestにおける修飾の全て）。また、変更がどのID与えられた変化（にmodifiersName、など）を担当したディレクトリ（createTimestamp、など）とに行われたときの情報を保存するいくつかの操作属性を定義します。現在、これらの操作属性への変更は、データへの変更と、原子することが必要とRFC2251には文はありません。
It is RECOMMENDED that this requirement be added during the revision of RFC2251. In the interim, replication SHOULD treat these operations as though such a requirement were in place.
この要件はRFC2251の改正時に追加することをお勧めします。そのような要件が所定の位置にあったかのように暫定では、レプリケーションは、これらの操作を扱うべきです。
Authors' Addresses
著者のアドレス
Russel F. Weiser Digital Signature Trust Co. 1095 East 2100 South Suite #201 Salt Lake City, UT 84106
ラッセルF.ワイザーデジタル署名トラスト株式会社1095東2100年南スイート＃201ソルトレイクシティ、ユタ州84106
Phone: +1 801 326 5421 Fax: +1 801 326 5421 EMail: rweiser@trustdst.com
電話：+1 801 326 5421ファックス：+1 801 326 5421 Eメール：rweiser@trustdst.com
Ellen J. Stokes IBM 11400 Burnet Rd. Austin, TX 78758
エレンJ.ストークスIBM 11400バーネットRdを。オースティン、TX 78758
Phone: +1 512 436 9098 Fax: +1 512 436 1193 EMail: stokese@us.ibm.com
電話：+1 512 436 9098ファックス：+1 512 436 1193 Eメール：stokese@us.ibm.com
Ryan D. Moats Lemur Networks 15621 Drexel Circle Omaha, NE 68135
ライアンD.堀キツネザルネットワーク15621ドレクセルサークルオマハ、ネブラスカ68135
Phone: +1 402 894 9456 EMail: rmoats@lemurnetworks.net
電話：+1 402 894 9456 Eメール：rmoats@lemurnetworks.net
Richard V. Huber Room C3-3B30 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748
リチャードV.フーバールームC3-3B30 AT＆T研究所200ローレルアベニュー南ミドルタウン、NJ 07748
Phone: +1 732 420 2632 Fax: +1 732 368 1690 EMail: rvh@att.com
電話：+1 732 420 2632ファックス：+1 732 368 1690 Eメール：rvh@att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。