[要約] 要約： RFC 3384は、Lightweight Directory Access Protocol（LDAP）のバージョン3のレプリケーション要件に関する規格です。目的： このRFCの目的は、LDAPバージョン3のレプリケーションに関する要件を定義し、ディレクトリサービスの信頼性と可用性を向上させることです。
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
軽量ディレクトリアクセスプロトコル（バージョン3）レプリケーション要件
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.
Copyright（c）The Internet Society（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.
このドキュメントでは、Lightweight Directory Access Protocol（バージョン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.
ネットワーク全体にディレクトリ情報を配布すると、2つの利点が得られます。（1）フォールトトレランスを介してディレクトリの信頼性を向上させ、（2）データを使用してクライアントにディレクトリコンテンツを近づけます。ディレクトリ情報のアクセスプロトコルとしてのLDAPの成功は、エンタープライズおよびインターネット内でLDAPディレクトリコンテンツを配布する必要性を促進することです。現在、LDAPは複製メカニズムを定義しておらず、通過時にLDAPシャドウサーバー（[RFC2251を参照]を参照）に言及しています。マルチベンダー環境でのディレクトリレプリケーションの標準メカニズムは、市場での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].
キーワード「必須」、「そうしない」、「必須」、「必要」、「しなければ」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
マスタースレーブ、またはシングルマスターレプリケーション - 1つのサーバーのみを想定するレプリケーションモデルであるマスターは、複製されたデータへのLDAP書き込みアクセスを許可します。マスタースレーブレプリケーションは、マルチマスターレプリケーションの適切なサブセットと見なすことができることに注意してください。
Meta-Data - Data collected by the replication system that describes the status/state of replication.
Meta -Data-複製のステータス/状態を記述する複製システムによって収集されたデータ。
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.
複製開始の競合 - 複製開始の競合は、2つのソースが同じレプリカを同時に更新したい状況です。
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：トランザクションの一貫性 - 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]、Bayou [Xerox]、およびNDS（Novell Directory Services）[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：最終的な（または確率的）一貫性の限られた努力 - トポロジーの知識と収束の統計的確率を提供する環境。例は、Xeroxクリアリングハウス[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は、マルチマスターシステムにおける原子性のサポートを簡素化する可能性がありますが、モデル1に必要な分散2相コミットの追加の複雑さは重要です。したがって、現時点ではモデル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
- すべてのuserapplication属性タイプ
- all directoryOperation and distributedOperation attribute types defined in the LDAP "core" specifications (RFCs 2251- 2256, 2829-2830)
- LDAP「コア」仕様で定義されているすべてのDirectoryOperationおよび分散型属性属性（RFCS 2251-2256、2829-2830）
- attribute subtypes
- 属性サブタイプ
- attribute description options (e.g., ";binary" and Language Tags [RFC2596])
- 属性説明オプション（例： "; binary"および言語タグ[rfc2596]）
G9. LDAP replication SHOULD support replication of directoryOperation and distributedOperation attribute types defined in standards track LDAP extensions.
G9。LDAPレプリケーションは、標準を追跡したLDAP拡張機能で定義されているディレクトリオペレーションおよび分散型属性のタイプの複製をサポートする必要があります。
G10. LDAP replication MUST NOT support replication of dsaOperation attribute types as such attributes are DSA-specific.
G10。LDAPレプリケーションは、DSA固有であるため、DSAOPERATION属性タイプの複製をサポートしてはなりません。
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
e) 重要なOIDの価値の変化
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).
手動要求を除き、特定のサーバーの特定のトリガーと関連するパラメーターは、標準で定義されたよく知られている場所、たとえば複製契約で識別する必要があります。
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。アクセスパラメーター、必要な認証資格情報、機密性の保証（暗号化）、およびレプリケーションの領域を含む、レプリカグループのメンバー間のレプリケーションプロセスのパラメーターは、標準の場所（例：レプリケーション契約）で定義する必要があります。）。
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つの複製サーバー間のスキーマミスマッチを処理する必要があります。このような不一致を処理する1つの方法は、エラー条件を上げることです。
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つ）から完全な更新を強制することが可能である必要があります。
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.
[酸] T. Haerder、A。Reuter、「トランザクション指向のデータベース回復の原則」、Computing Surveys、Vol。15、No。4（1983年12月）、pp。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] Novell、「NDS Technical概要」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol", RFC 2251, December 1997.
[RFC2251] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol」、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] Wahl、M.、Coulbeck、A.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（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.、Wahl、M。、およびT. Howes、「Lightweight Directory Access Protocol（V3）：UTF-8文字列名の表現」、RFC 2253、1997年12月。
[RFC2254] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
[RFC2254] Howes、T。、「LDAP検索フィルターの文字列表現」、RFC 2254、1997年12月。
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[RFC2255] Howes、T。およびM. Smith、「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] Wahl、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] Wahl、M。およびT. Howes、「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] Wahl、M.、Alvestrand、H.、Hodges、J。and R. Morgan、「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] Hodges、J.、Morgan、R。、およびM. Wahl、「Lightweight Directory Access Protocol（V3）：輸送層のセキュリティの拡張」、RFC 2830、2000年5月。
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF)", RFC 2849, June 2000.
[RFC2849] Good、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. Hauser、「弱く接続された複製されたストレージシステムであるBayouの更新競合の管理」。カリフォルニア州パロアルト：ゼロックスパーク、コンピューターサイエンス研究所。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.デマーズ、マークギーリー、ダニエルグリーン、カールハウザー、ウェスリーアイリッシュ、ジョンラーソン、スーマニング、スコットシェンカー、ハワードスタージス、ダニエルスワインハート、ダグラステリー、ドンウッズ、「複製されたデータベースメンテナンスのための流行性アルゴリズム」。カリフォルニア州パロアルト、ゼロックスパーク、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 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.
- 選択的属性複製（分数複製）。これにより、部分的なエントリのみを複製できるようにします。
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.
- 潜在的に異なるスキーマを持つDIT間の複製。
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.
- 潜在的に異なるスキーマを持つDIT間の複製。
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.
2つの組織は、いくつかのベンチャーに協力することを選択し、運用を管理するために共有名のスペースが必要です。どちらの組織でも、共有名のスペースに対する管理上の権利が必要です。
The requirements that follow from this scenario are:
このシナリオから続く要件は次のとおりです。
- Multi-Master replication.
- マルチマスターレプリケーション。
- Common access control model and access control model identification.
- 一般的なアクセス制御モデルとアクセス制御モデルの識別。
- Secure transmission of updates.
- 更新のセキュアな送信。
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.
- 更新のセキュアな送信。
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).
- スケジューリングを開く（いつでも）。
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.
- 時間/属性セマンティクスに基づいて複製します。
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）のレプリケーションは、（a）のサーバー（b）R/Wレプリカが存在するパリへのダイヤルアップ電話リンクを介して処理されます。（a）のサーバー（c）R/wレプリカは、サーバー（b）へのT1接続によって接続されています。各接続には異なるパフォーマンス特性があります。
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.
- 消費者の開始またはサプライヤーが複製を開始したための手当。
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サーバーによって複製されるコーポレートディレクトリの管理者を持つ管理者は、変更ログが成長し続けており、/またはエラーメッセージが通知しているため、複製プロセスが正しく完了していないことに気付きます。管理者は、19.95ドルのREPCO LDAPディレクトリレプリケーション診断ツールを使用して、サーバー17のルートDSEレプリカの知識を調べ、LDAP'rus Inc.によって作成されたサーバー42がオブジェクトの競合のために適切に複製されていないと判断します。彼のRepcoリモート修理ツールを使用して、彼はサーバー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.
- Replicaのコンテンツを有効性について比較するための操作を提供します。
- Provide LDAP access to status and audit information.
- ステータスおよび監査情報へのLDAPアクセスを提供します。
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つのサーバーが同じ複製領域を保持しています。エンタープライズメッシュの所定の複製契約は単一の管理下にあり、セキュリティドメインは、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.
- 多数のサーバーで保持されている単一の複製領域を管理する1つの事前定義された複製契約。
- 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 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.
- ディレクトリの更新が継続するため、「プロモーション」は大幅なダウンタイムなしで行う必要があります。
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は、ディレクトリをポリシーデータリポジトリとして使用するポリシー管理システムを使用します。ディレクトリは、単一の障害点を避けるために、異なるベンダーの製品のいくつかの異なるサイトで複製されます。1つのサイトがネットワークから切断されていても、ディレクトリが利用可能で更新可能であることが不可欠です。データの変更は追跡可能である必要があり、異なるサイトからの変更がどのように相互作用したかを判断することが可能である必要があります。
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を除き、この付録は正式な要件を記載していません。
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は、メタデータが縛らずに成長してはならないと述べています。これは、メタデータがある時点でシステムからパージされなければならないことを意味します。これは、安定性に関する懸念を引き起こします。すべてのレプリカが更新される前にメタデータをパージすると、レプリカ間の変更情報と矛盾の不完全な複製につながる可能性があります。したがって、メタデータが永遠に成長しないようにしながら、システムからメタデータをパージするためのルールを設定する注意が必要です。
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.
状況が発生する場合があります（たとえば、サプライヤーのレプリカで処理されたものとは異なる順序でデータを消費者のレプリカに送信すること）。そのようなケースの1つは、シングルマスター環境でマスターサーバーで大きなバルクロードが行われ、その後、重要な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にあります。
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]、ベンダーには製品に追加の属性またはオブジェクトクラスが含まれている可能性があります。2つの異なるベンダーの製品が複製しようとすると、これらの追加がスキーマの不一致を引き起こす可能性があります。スキーマの不一致のもう1つの潜在的な原因については、セクション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プラクティスは、送信するものに厳密であり、受け取るものに柔軟であることを示唆しています。この場合の類似点は、サプライヤーがスキーマのミスマッチのエラー通知を受信する準備をする必要があることですが、消費者は代わりにコンバージョンを行うことを選択できます。
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.
この状況で考慮できるもう1つのオプションは、分数複製の使用です。複製が設定されているため、共通属性のみが複製されると、ミスマッチを回避できます。
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.
ここでの追加の考慮事項の1つは、スキーマ自体の複製です。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.
- スキーマは、分数複製に関与するサーバーで手動で構成されています。スキーマ要素は、プロトコルを介して複製されません。
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はこれらのニーズに対応しています。
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つのレプリカ、A、B、およびCがあると仮定します。3つのレプリカすべてが更新可能です。レプリカAとBに変更が加えられます。レプリケーションにより、いずれかのレプリカが他のレプリカに変更された変更を確認できます。マルチマスターのケースについての議論では、紛争解決のために有効なルールを使用して、Aへの変更が優先されると想定しています。
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.
シングルサーバーの場合、作成操作の1つがもう1つの前に発生し、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を作成するための複製要求がサーバーの1つに到着すると、競合解決が呼び出されます。（すべてのエントリが要件SC9ごとに何らかの一意の識別子を持っているため、同じDNを持っているにもかかわらず、2つの要求を区別できることに注意してください。）
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の値は、管理者にある程度通知して記録されるか、それらを生成したマシンでDITに追加される可能性があります（再度管理者に通知して）。生成された機械で保存されている場合、レプリカグループ内のすべてのサーバーで同じ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に作成された値を強制するために、いくつかのメカニズムを提供する必要があります。
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に変更されます。Replica 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つの変更操作がもう1つの前に操作が発生し、2番目の名前が失敗します。
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と一致します。
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、y、zを含むdridingued名DNを持つエントリがあります。xの値は1です。レプリカAでは、xの値を1から0に変更して設定するための変更を含む修正が処理されます。Yの値「user1」。同時に、レプリカBは、xの値を1から0に変更し、yの値を「user2」に、zの値を42に設定するための変更を含む変更を処理します。この場合のアプリケーションは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つの操作は順次発生していました。ModieRequestはAtomicであるため、最初の操作全体が成功します。xの値は試行されたときに0になり、xが1に0に変更されるため、xの値が0になるため、2番目のModieRequestは失敗します。Atomicityルールは、ModieRequestの他のすべての変更も失敗します。
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に違反する可能性があります。
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.
ここでの主な問題は、使用の1つです。LDAP標準の仕事では、複製がレプリカ間で「ゆるい一貫性」を提供すると長い間言われてきました。いくつかのIETF会議およびメーリングリストでは、ロックが必要な金融の使用例は、LDAPの貧弱な用途と宣言されています。要件G1はこの履歴と一致しています。しかし、一貫性のゆるい一貫性が目標である場合、上記のロック例は、少なくとも複製された環境では、LDAPの不適切な使用です。
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.
- 彼らは、著名な名前の一部であるデータを変更しているか、ModieRequestを使用して、単一の原子要求で特定の属性値を読み取りおよび書き込みます。
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人全員が発生する場合、アプリケーション設計者は考えられる結果を認識する必要があります。
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）は、データの整合性とデータの機密保護が必要ないのと同じ種類の状況で役立つ可能性があるため、サポートされています。
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.
問題を軽減する1つの方法は、元のマスターが失敗したときに奴隷レプリカをマスターに変換するフェイルオーバープロセスを提供することです。フェールオーバープロセスを実行するのに必要な時間は、システム全体の可用性の主要な要因になります。
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.
- マスターレプリカに、スレーブレプリカの一部ではない制御情報またはメタデータが含まれている場合、この情報は、フェイルオーバープロセスの一部としてマスターに「促進」されている奴隷に挿入する必要があります。古いマスターはこの時点ではおそらく利用できないと思われるため、このデータを取得することは難しいかもしれません。たとえば、マスターがすべてのレプリカのステータス情報を保持しているが、各スレーブレプリカが独自のステータス情報のみを保持している場合、フェイルオーバーは、おそらくそれらのレプリカから、新しいマスターが既存のすべてのレプリカのステータスを取得する必要があります。マスターが完全なセットを保持している唯一のシステムである場合、複製契約についても同様の問題が発生する可能性があります。
- 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).
- フェイルオーバープロセス全体を自動化できれば、可用性は最大化されます（たとえば、元のマスターが適切に機能していないと判断した場合、フェールオーバーは外部システムによって開始されます）。
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]は、一部の操作がアトミックであると宣言しています（たとえば、単一の修正のすべての変更）。また、ディレクトリ（CreateTimestampなど）に変更が加えられた時期に関する情報を保存するいくつかの運用属性と、どのIDが特定の変更（ModifiersNameなど）に責任があるかを定義します。現在、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
Russel F. Weiser Digital Signature Trust Co. 1095 East 2100 South Suite＃201 Salt Lake City、UT 84106
Phone: +1 801 326 5421
Fax: +1 801 326 5421
EMail: rweiser@trustdst.com
Ellen J. Stokes IBM 11400 Burnet Rd. Austin, TX 78758
エレンJ.ストークスIBM 11400 Burnet Rd。テキサス州オースティン78758
Phone: +1 512 436 9098
Fax: +1 512 436 1193
EMail: stokese@us.ibm.com
Ryan D. Moats Lemur Networks 15621 Drexel Circle Omaha, NE 68135
ライアンD.モートレムールネットワーク15621ドレクセルサークルオマハ、NE 68135
Phone: +1 402 894 9456
EMail: rmoats@lemurnetworks.net
Richard V. Huber Room C3-3B30 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748
リチャードV.フーバールームC3-3B30 AT＆T Laboratories 200 Laurel Avenue South Middletown、NJ 07748
Phone: +1 732 420 2632
Fax: +1 732 368 1690
EMail: rvh@att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。