RFC3384 日本語訳
3384 Lightweight Directory Access Protocol (version 3) ReplicationRequirements. E. Stokes, R. Weiser, R. Moats, R. Huber. October 2002. (Format: TXT=66871 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
ストークがコメントのために要求するワーキンググループE.をネットワークでつないでください: 3384年のIBMカテゴリ: 情報のR.のワイザーデジタル署名信頼R.堀のキツネザルはAT&T研究所2002年10月にR.ヒューバーをネットワークでつなぎます。
Lightweight Directory Access Protocol (version 3)
Replication Requirements
ライトウェイト・ディレクトリ・アクセス・プロトコル(バージョン3)模写要件
Status of this Memo
この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)インターネット協会(2002)。 All rights reserved。
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
1つの序論…2 2用語…3 3、モデル…5 4の要件…7 4.1一般…7 4.2 モデル化してください…8 4.3 議定書を作ってください…9 4.4図式…10 4.5 マスターを選抜してください…10 4.6マルチマスター…11 4.7の政権と管理…11 4.8セキュリティ…12 5 セキュリティ問題…13 6つの承認…13
Stokes, et. al. Informational [Page 1] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [1ページ]情報のRFC3384LDAPv3模写要件2002年10月
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
7つの参照箇所…13 付録A--用法シナリオ…15A.1エクストラネットの例…15A.2強化の例…15のA.3の模写の異種の展開の例…16 A.4は名前スペースの例を共有しました…16A.5供給者は模写を開始しました…16A.6消費者は模写を開始しました…17 A.7は属性模写を最優先させました…17 A.8帯域幅問題…17 A.9の共同利用できる政権と管理…18 A.10エンタープライズディレクトリ模写メッシュ…18 マスター奴隷というマスターのA.11の故障はディレクトリを模写しました。19 重要なサービス情報を保持するディレクトリのA.12の故障…19B付録B--、原理…20 B.1メタデータ含意…20 データを模写するための転送のB.2注文…20のB.3図式ミスマッチと模写…レプリカの中で矛盾を検出して、修理する21B.4…22B.5、マルチマスター模写における紛争解決のためのいくつかのテストケース…模写の間の23B.6データの機密性とデータの保全…独身のマスターシステムの27B.7フェイルオーバー…原子操作に操作上の属性を含む27B.8…29人の作者のアドレス…30 完全な著作権宣言文…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は模写メカニズムを定義しないで、通る際に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サーバの間の模写のための要件を出します。 RFC2251とRFC2252[RFC2252]はLDAPクライアントとサーバとのコミュニケーションの規格について詳しく説明しますが、サーバからサーバへのコミュニケーションのための追加要件があります。 これらの或るものはここにカバーされています。
This document first introduces the terminology to be used, then presents the different replication models being considered.
このドキュメントは、最初に、使用されるために用語を紹介して、考えられて、次に、異なった模写モデルを提示します。
Stokes, et. al. Informational [Page 2] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [2ページ]情報のRFC3384LDAPv3模写要件2002年10月
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.
要件はセキュリティ問題と共に続きます。 要件につながる推理はAppendicesに提示されます。 彼らの正当化から要件の清潔な分離を提供するためにこれをしました。
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"、「必須NOT」が「必要です」、“SHALL"、「」、」、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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".
匿名の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].
模写の領域--模写されるためにデータの異なったユニットを作るディレクトリ情報Tree(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規格が保証するディレクトリデータへの1セットの変化は一体にして扱われるでしょう。 すべての変更が行われるだろうか、またはすべての変化が失敗するでしょう。
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--模写合意でシステムの操作に重要であると定義された属性かオブジェクトのクラス。 重要なOIDsに影響する変化がレプリカサイクルの即座の開始を引き起こします。 重要なOIDに関する例は、パスワードか証明書であるかもしれません。
Stokes, et. al. Informational [Page 3] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [3ページ]情報のRFC3384LDAPv3模写要件2002年10月
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.
増加のUpdate--それらの属性だけを含むアップデートか変化したエントリー。
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.
Replicaをマスタリングしてください--LDAP操作で直接アップデートされるかもしれないレプリカ。 Master-奴隷Replicationシステムでは、Master Replicaはレプリカグループで唯一の直接アップデート可能なレプリカです。
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.
または、マスターして身を粉にして働いてください、Single Master Replication--あるサーバ(マスター)だけがLDAPを許容すると仮定する模写モデルは複製データへのアクセスを書きます。 マルチマスター模写の真部分集合であるとMaster-奴隷模写を考えることができることに注意してください。
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.
マルチMaster Replication、--、書くことができて、いずれでも数個についてアップデートされたエントリーがレプリカをマスタリングする模写モデルが以前他のマスターレプリカとのコミュニケーションを必要としないでコピーする書いてください。さもないと、アップデートは実行されます。
One-way Replication - The process of synchronization in a single direction where the authoritative source information is provided to a replica.
一方向Replication--権威筋情報がレプリカに提供されるただ一つの方向との同期のプロセス。
Partial Replication - Partial Replication is Fractional Replication, Sparse Replication, or both.
部分的なReplication--部分的なReplicationはFractional Replication、Sparse Replication、または両方です。
Propagation Behavior - The behavior of the synchronization process between a consumer and a supplier.
伝播Behavior--消費者と供給者の間の同期プロセスの振舞い。
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.
レプリカ(または、Replication)サイクル--どれが情報をアップデートしているか間、2つ以上のレプリカの間で間隔を交換します。 それはレプリカかもうの1セットのレプリカからデータを押すか、またはデータを引く試み、および首尾よくデータを交換したか、または誤りに遭遇する終わりの間、始まります。
Replication - The process of synchronizing data distributed across directory servers and rectifying update conflicts.
模写--ディレクトリサーバとアップデートを正すことの向こう側に連動データのプロセスは闘争を広げました。
Stokes, et. al. Informational [Page 4] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [4ページ]情報のRFC3384LDAPv3模写要件2002年10月
Replication Agreement - A collection of information describing the parameters of replication between two or more servers in a replica- group.
模写Agreement--レプリカグループにおける2つ以上のサーバの間の模写のパラメタについて説明する情報の収集。
Replication Base Entry - The distinguished name of the root vertex of a replicated area.
模写基地のEntry--模写された領域の根の頂点の分類名。
Replication Initiation Conflict - A Replication Initiation Conflict is a situation where two sources want to update the same replica at the same time.
模写Initiation Conflict--Replication Initiation Conflictは2つのソースが同時に同じレプリカをアップデートしたがっている状況です。
Replication Session - A session set up between two servers in a replica-group to pass update information as part of a replica cycle.
模写Session--セッションは、レプリカサイクルの一部としてアップデート情報を通過するためにレプリカグループにおける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.
奴隷(または、Read専用)レプリカ--LDAP要求で直接アップデートできないレプリカ。 変更はマスターレプリカからの模写で行われるだけであるかもしれません。 書き込み禁止レプリカはシングルとマルチマスターシステムの両方に起こるかもしれません。
Sparse Replication - The capability to filter some subset of entries (other than a complete collection) of an area of replication.
まばらな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.
ツーウェイReplication--変化情報が2つのレプリカの間を2方向に流れる同期のプロセス。
Unauthenticated Replication - See Anonymous Replication.
Unauthenticated模写--匿名の模写を見てください。
Update Propagation - Protocol-based process by which directory replicas are reconciled.
Propagationをアップデートしてください--ディレクトリレプリカが和解しているプロトコルベースのプロセス。
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: 取引のConsistency--すべての4つのACIDの特性(最小単位、Consistency、Isolation、Durability)[ACID]を示す環境。
Stokes, et. al. Informational [Page 5] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [5ページ]情報のRFC3384LDAPv3模写要件2002年10月
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: 最後(または、Transient)の一貫性--トポロジーに関する明確な知識が提供される環境は模写協定を予定しました。 例はX.500ディレクトリ(X.500モデルは独身のマスター専用です)[X.501、X.525]、Bayou[ゼロックス]、および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: 株式会社Effort Eventual(または、Probabilistic)の一貫性--トポロジーに関する知識を集合の統計的確率に提供する環境。 例はゼロックスClearinghouse[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: 最もゆるいConsistency--情報が便宜主義的であるか簡単なキャッシュから聞き古したである提供される環境。 トポロジーに関する完全な知識はすべてのレプリカの中で共有されないかもしれません。
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がマルチマスターシステムの最小単位のサポートを簡素化しているかもしれない間、Model1が重要であるので、分散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つの模写シナリオを例証します: セキュリティ管理パラメタを通した方針構成(モデル2)と、ホワイトページアプリケーションのように比較的静的なデータとアドレス情報をホスティングします(モデル3)。 したがって、模写要件はモデル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
LDAP模写を使用するディレクトリの中の相互運用性がLDAPコアドキュメントによって指定されたもので意味論を加える実装のために制限されるかもしれない、(RFC、2251-2256 2829、2830)。 さらに、「コア」仕様は実装するために義務的でない多数の特徴(例えば、RECOMMENDEDかOPTIONAL)を含んでいます。 また、大幅な選挙の拡大があります。 したがって、異なったオプションをサポートするLDAPの独立している実装の間のLDAP模写相互運用性は制限されるかもしれません。 適用性の使用
Stokes, et. al. Informational [Page 6] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [6ページ]情報のRFC3384LDAPv3模写要件2002年10月
statements to improve interoperability in particular application spaces is RECOMMENDED.
特定用途空間で相互運用性を改良する声明はRECOMMENDEDです。
4 Requirements
4つの要件
4.1 General
4.1 一般
G1. LDAP Replication MUST support models 2 (Eventual Consistency)
and 3 (Limited Effort Eventual Consistency) above.
G1。 LDAP Replicationは上の(最後のConsistency)と3(株式会社Effort Eventual Consistency)をモデル2にサポートしなければなりません。
G2. LDAP Replication SHOULD NOT preclude support for model 1
(Transactional Consistency) in the future.
G2。 LDAP Replication SHOULDは将来、モデル1(取引のConsistency)のサポートを排除しません。
G3. LDAP replication SHOULD have minimal impact on system
performance.
G3。 LDAP模写SHOULDはシステム性能に最小量の影響力を持っています。
G4. The LDAP Replication Standard SHOULD NOT limit the replication
transaction rate.
G4。 LDAP Replication Standard SHOULDは模写トランザクション率を制限しません。
G5. The LDAP replication standard SHOULD NOT limit the size of an
area of replication or a replica.
5ヵ国蔵相会議。 LDAP模写の標準のSHOULD NOTは模写の領域かレプリカのサイズを制限します。
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とdistributedOperation属性タイプ(RFCs2251- 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。 directoryOperationとdistributedOperation属性タイプのLDAP模写SHOULDサポート模写は標準化過程でLDAP拡張子を定義しました。
G10. LDAP replication MUST NOT support replication of dsaOperation
attribute types as such attributes are DSA-specific.
10ヵ国蔵相会議。 そのような属性がDSA特有であるときに、LDAP模写はdsaOperation属性タイプの模写をサポートしてはいけません。
Stokes, et. al. Informational [Page 7] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [7ページ]情報のRFC3384LDAPv3模写要件2002年10月
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模写システムはネットワークでメッセージの数を最小にすることによって、影響を制限するはずです、そして、トラフィックの量は発信しました。
4.2 Model
4.2 モデル
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).
手動要求を除いて、規格(例えば、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部が完全であることを必要とするかもしれません。 モデルはPartial Replicasをサポートしなければなりません。
M6. The determination of which OIDs are critical MUST be
configurable in the replication agreement.
M6。 OIDsが重要である決断は模写合意で構成可能であるに違いありません。
Stokes, et. al. Informational [Page 8] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [8ページ]情報のRFC3384LDAPv3模写要件2002年10月
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。 模写協定SHOULDは、ただ一つの事前に定義された協定で模写の同じ領域を受けながら、複数のサーバを収容します。
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。 アップデートが一度異なった結果を作り出してはいけないより消費者のそばで受信された、一度だけアップデートを受けたなら。
4.3 Protocol
4.3 プロトコル
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模写SHOULD NOTはアップデートを消費者に送ります。
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。 模写プロトコルで、マスターか奴隷レプリカが模写プロセスを開始できなければなりません。
Stokes, et. al. Informational [Page 9] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [9ページ]情報のRFC3384LDAPv3模写要件2002年10月
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。 プロトコルは、模写セッションの間に発見されたレプリカの間の図式ミスマッチを報告するためにメカニズムをサポートしなければなりません。
4.4 Schema
4.4 図式
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。 エントリーは生涯の間中ときに唯一身元保証可能でなければなりません。
4.5 Single Master
4.5 独身のマスター
SM1. A Single Master system SHOULD provide a fast method of
promoting a slave replica to become the master replica.
SM1。 SHOULDがマスターレプリカになる奴隷レプリカを促進する速いメソッドを供給するSingle Masterシステム。
Stokes, et. al. Informational [Page 10] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [10ページ]情報のRFC3384LDAPv3模写要件2002年10月
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。 SHOULDがすべてを送るSingle Masterシステムのマスターレプリカはマスターがそれらを適用したオーダーにおける書き込み禁止レプリカに変化します。
4.6 Multi-Master
4.6 マルチマスター
MM1. The replication protocol SHOULD NOT saturate the network with
redundant or unnecessary entry replication.
MM1。 模写プロトコルSHOULD NOTは余分であるか不要なエントリー模写にネットワークを浸します。
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。 マルチマスター模写は、書き込み禁止がレプリカであるとサポートして、レプリカを読書して書かなければなりません。
4.7 Administration and Management
4.7 政権と管理
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。 レプリカの各コピーはどのサーバで模写するか、そして、どのサーバがそれで模写してあるかに関する監査履歴情報を維持しなければなりません。
Stokes, et. al. Informational [Page 11] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [11ページ]情報のRFC3384LDAPv3模写要件2002年10月
AM3. Access to replication agreements, topologies, and policy
attributes MUST be provided through LDAP.
AM3。 LDAPを通して模写協定、topologies、および方針属性へのアクセスを提供しなければなりません。
AM4. The capability to check the differences between two replicas
for the same information SHOULD be provided.
AM4。 能力、同じ情報SHOULDがないかどうか2つのレプリカの違いをチェックするには、提供してください。
AM5. A mechanism to fix differences between replicas without
triggering new replica cycles SHOULD be provided.
AM5。 新しいレプリカの引き金とならないでレプリカの違いを修理するメカニズムはSHOULDを循環させます。提供します。
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 MUSTがある制御情報にアクセスするアップデートの系列。
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つ、)、新しいディレクトリサーバをシステムに追加する目的のためのMaster(s)。
AM8. Vendors SHOULD provide tools to audit schema compatibility
within a potential replica-group.
AM8。 ベンダーSHOULDは、潜在的レプリカグループの中で図式の互換性を監査するためにツールを提供します。
4.8 Security
4.8 セキュリティ
The terms "data confidentiality" and "data integrity" are defined in the Internet Security Glossary [RFC2828].
用語「データの機密性」と「データ保全」はインターネットSecurity Glossary[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。 相互運用性を促進するために、aがあるに違いない、義務的である、-、道具データの機密性メカニズムに。
Stokes, et. al. Informational [Page 12] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [12ページ]情報のRFC3384LDAPv3模写要件2002年10月
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。 データ保全をサポートするために、aがあるに違いない、義務的である、-、道具データ保全メカニズムに。
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で、記載されています)。 基本的なLDAP意味論に標準的でない拡大を実装するサーバの中で模写するとき、セクション3に述べられるように、相互運用性に影響を与えるかもしれません。 どの実装サポートが存在しているか、そして、将来の規格がLDAP機密保護モデルについて詳述している状態で、一貫性の度合いでセキュリティ関連的、そして、一般的なLDAP相互運用性にかなり影響を与えるでしょう、将来の標準のLDAPアクセス制御モデルのように。
6 Acknowledgements
6つの承認
This document is based on input from IETF members interested in LDUP Replication.
このドキュメントはLDUP Replicationに興味を持っている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.ロイター通信、「トランザクション指向のデータベース回復のプリンシプルズ」、Computing Surveys、Vol.15、No.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のキーワード」、BCP14、RFC2119、1997年3月。
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol", RFC 2251, December 1997.
[RFC2251] ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC2251、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)について議定書の中で述べます」。 「属性構文定義」、RFC2252、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ストリング表現」、RFC2253、1997年12月。
[RFC2254] Howes, T., "The String Representation of LDAP Search
Filters", RFC 2254, December 1997.
[RFC2254] ハウズ、T.、「LDAP検索フィルタのストリング表現」、RFC2254、1997年12月。
Stokes, et. al. Informational [Page 13] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [13ページ]情報のRFC3384LDAPv3模写要件2002年10月
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
December 1997.
[RFC2255] ハウズとT.とM.スミス、「LDAP URL形式」、RFC2255、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"、RFC2256、1997年12月との使用のためのX.500(96)ユーザSchemaのSummary。」
[RFC2596] Wahl, M. and T. Howes, "Use of Language Codes in LDAP", RFC
2596, May 1999.
[RFC2596] ウォール、M.、およびT.ハウズ(「LDAPにおける言語コードの使用」、RFC2596)は1999がそうするかもしれません。
[RFC2828] Shirey, R. "Internet Security Glossary", FYI 36, RFC 2828,
May 2000.
[RFC2828]Shirey(R.「インターネットセキュリティ用語集」、FYI36、RFC2828)は2000がそうするかもしれません。
[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のための認証方法」、RFC2829)は2000がそうするかもしれません。
[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)について議定書の中で述べます」。 「トランスポート層セキュリティのための拡大」(RFC2830)は2000がそうするかもしれません。
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF)", RFC
2849, June 2000.
[RFC2849] いいぞ、G.、「LDAPデータ置き換え形式(LDIF)」、RFC2849、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/IEC9594-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/IEC9594-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.
[ゼロックス]C.ハウザー、「アップデートを管理するのはBayou、弱々しく接続された模写されたストレージシステムで闘争します」。 パロアルト(カリフォルニア): ゼロックス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.Demers、マークGealy、ダニエル・グリーン、カール・ハウザー、ウエスリーIrish、ジョン・ラーソン、スー・マニング、スコットShenker、ハワード・スタージス、ダニエルSwinehart(ダグラス・テリー)はウッズ、「模写されたデータベースメインテナンスのための流行のアルゴリズム」を身につけます。 1989年1月のパロアルト(カリフォルニア)ゼロックスPARC。
Stokes, et. al. Informational [Page 14] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [14ページ]情報のRFC3384LDAPv3模写要件2002年10月
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.
以下のディレクトリ展開の例が私たちの模写要件を有効にすることを意図します。 種々雑多なセットのディレクトリ実装は以下のすべてのケースのために想定されます。 この材料はバックグラウンドとして意図します。 要件は全くこの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.
会社には、それとディレクトリ情報を共有したい貿易相手国があります。 この情報は、法人の電話帳と同じくらい簡単であるか、エクストラネット作業フローアプリケーションとまたは同じくらい複雑であるかもしれません。 性能理由で、会社はファイアウォールを超えてディレクトリを暴露するよりPartner社の中にむしろディレクトリのレプリカを置きたがっています。
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.
- 部分的なエントリーしか模写できないための選択している属性模写(断片的なReplication)。
A.2. Consolidation Example
A.2。 強化の例
Company A acquires company B. Each company has an existing directory.
A社は会社B.を買収します。Each会社には、既存のディレクトリがあります。
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社は会社のビーズディレクトリをそれ自身のものに添付したがっているかもしれません。
The requirements that follow from this scenario are:
このシナリオから続く要件は以下の通りです。
- Multi-Master replication.
- マルチMaster模写。
- Common access control model. Access control model identification.
- 一般的なアクセス制御モデル。 コントロールモデル識別にアクセスしてください。
- Secure transmission of updates.
- アップデートの送信を保証してください。
- Replication between DITs with potentially differing schema.
- 潜在的に異なった図式があるDITsの間の模写。
Stokes, et. al. Informational [Page 15] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [15ページ]情報のRFC3384LDAPv3模写要件2002年10月
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
- マルチMaster模写
- Common access control model and access control model
identification.
- 一般的なアクセス制御モデルとアクセスはモデル同定を制御します。
- Secure transmission of updates.
- アップデートの送信を保証してください。
- Replication among DITs with potentially differing schemas.
- 潜在的に異なったschemasとDITsの中の模写。
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.
2つの組織が、彼らの操作を管理するために何らかのベンチャーと協力して、共有された名前スペースを必要とするのを選ぶかもしれません。 両方の組織はスペースという共有された名前に関して施政権を必要とするでしょう。
The requirements that follow from this scenario are:
このシナリオから続く要件は以下の通りです。
- Multi-Master replication.
- マルチMaster模写。
- 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.
- アップデートの送信を保証してください。
Stokes, et. al. Informational [Page 16] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [16ページ]情報のRFC3384LDAPv3模写要件2002年10月
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.
カトマンズでのServer(A)R/Wレプリカ(a)の模写は(a)のサーバ(B)R/Wレプリカがあるパリへのダイヤルアップ電話リンクを通して扱われます。 (a)のサーバ(C)R/Wレプリカはサーバ(B)とのT1接続によって接続されます。 各接続は異なった性能を独特にします。
Stokes, et. al. Informational [Page 17] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [17ページ]情報のRFC3384LDAPv3模写要件2002年10月
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でRoot DSEレプリカ知識を見る彼の19.95ドルのRepCo LDAPディレクトリ模写診断用道具を使用して、オブジェクト闘争のためLDAP'RUS Inc.によって作られたサーバ42が適切に模写されていないと決心しています。 彼のRepco Remote修理ツールを使用して、彼は、サーバ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つのサーバが模写の同じ領域を保持しています。 企業メッシュのための予定された模写協定がただ一つの管理であります、そして、セキュリティー領域は5つのサーバの模写を管理するただ一つの予定された模写協定を許します。
Stokes, et. al. Informational [Page 18] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [18ページ]情報のRFC3384LDAPv3模写要件2002年10月
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.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は方針データ倉庫としてディレクトリを使用する政策管理システムを使用します。 ディレクトリは、単一のポイントの失敗を避けるために異なったベンダーの製品に関するいくつかの異なったサイトで模写されます。 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.
- 模写のマニュアルレビューとオーバーライドには、闘争が解決であるとサポートしてください。
Stokes, et. al. Informational [Page 19] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [19ページ]情報のRFC3384LDAPv3模写要件2002年10月
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.
このAppendixはバックグラウンドのいくつかを要件の後ろに与えます。 プロトコルデザイナーが要件のいくつか後ろの考えを理解しているのを助けて、デザインの間に考えられるべきである問題のいくつかを提示するのは含まれています。 セクションB.8以外に、このAppendixはどんな正式な要件も述べません。(B.8はアップデートのための提案された要件をRFC2251に含みます)。
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.
状況がデータを模写するのが有益であるところに故障していた状態で起こるかもしれない、(例えば、発信してください、aで異なった消費者レプリカへのデータがそれが供給者レプリカで処理されたより注文される、) 独身のマスター環境におけるマスターサーバで大きいばら荷をして、次に、次に、重要な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
例として、図式変化を重要であり、模写待ち行列の前部に動かさなければならないと仮定してください。 今度は、図式変化が何らかのオブジェクトのクラスのために属性を削除すると仮定してください。 もうすぐ削除にされるのの値を削除するのは待ち行列における図式変化の前での操作のいくつかが操作であることが可能です。
Stokes, et. al. Informational [Page 20] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [20ページ]情報のRFC3384LDAPv3模写要件2002年10月
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の後ろの推理です。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]に関する必要条件を満たすときさえ、ベンダーはそれらの製品がある追加属性かオブジェクトのクラスを含めたかもしれません。 2つの異なったベンダーの製品が、模写するのを試みるとき、これらの追加は図式ミスマッチを引き起こす場合があります。 セクション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.
- 静かに消費者で図式に従わないデータを少しの無視してください(消費者レプリカのどんな店もしないで、またエラー条件を上げません)。
Stokes, et. al. Informational [Page 21] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [21ページ]情報のRFC3384LDAPv3模写要件2002年10月
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つが送るもので厳しく、ものが受けるものでフレキシブルであると示唆します。 この場合、平行線は供給者がどんな図式ミスマッチのためのエラー通知も受け取る用意ができているべきであるということですが、消費者は、代わりに変換するのを選ぶかもしれません。
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.
ここでの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.
- 図式は断片的な模写にかかわるサーバで手動で構成されます。 図式要素はプロトコルで模写されません。
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.
デザイナー、作成者、およびオペレータの最善の努力にもかかわらず、矛盾は生産ディレクトリのレプリカの中に時折現れるでしょう。 ツールはあるために検出して、修正するのに必要な状態で望んでいます。これらの矛盾。
Stokes, et. al. Informational [Page 22] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [22ページ]情報のRFC3384LDAPv3模写要件2002年10月
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つのレプリカを通常読み込んで、ことによるとBINDingによる答えをそれぞれの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.
これは役に立つガイドラインですが、いくつかの状況がそれが実行するのが不可能であるところにあります。 これらのいくつかのケースがこのセクションで調べられます。 特に、いくつかのケースがデータがただ一つのサーバ構成で失われていないマルチマスター模写で「失われる」ところにあります。
Stokes, et. al. Informational [Page 23] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [23ページ]情報のRFC3384LDAPv3模写要件2002年10月
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.All3つのレプリカがアップデート可能です。 どちらのレプリカも、模写で変更がもう片方で行われるのを見ることができる前に変更をレプリカ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.Atの上の分類名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、もう片方の前に起こって、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からの値が何らかの通知で管理者に登録されるかもしれませんか、または彼らはマシンの発生しているDN(再び管理者への通知がある)と共にDITに加えられるかもしれません。 マシンがDNで、同じ状態で発生している状態でそれらが格納されるなら、レプリカグループにおけるすべてのサーバでDNを使用しなければなりません(さもなければ、要件M3は違反されるでしょう)。 問題のエントリーが容器である、マシンによる格納がDNを発生させた場合におけるそれが模写サイクルが完了する前に何かdescendentsが発生したなら下降のエントリーが格納されるかもしれない場所を提供することに注意してください。
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で作成された値を場所に力づくで押すのを許容するために何らかのメカニズムを提供しなければなりません。
Stokes, et. al. Informational [Page 24] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [24ページ]情報のRFC3384LDAPv3模写要件2002年10月
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.
ただ一つのサーバ場合では、人は操作を改名します。既にという目標名が存在しているのでもう片方と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と一致しているでしょう。
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.
Z.属性Xを含む分類名DNとのエントリーがあります、Y、Xの値は1です。 レプリカAに、1〜0までのXのその値を変えて、"USER1""にYの値を設定するために変更を含んでいるModifyRequestは処理されます。 同時に、レプリカBは1〜0までのXの値を変えて、「42へのZのUSER2"と値」にYの値を設定するために変更を含んでいる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が原子であるので、全体の最初の操作は成功するでしょう。 第2ModifyRequestは失敗するでしょう、それが試みられたとき、Xの値が0でしょう、そして、その結果、1〜0までのXを変える変更は失敗するでしょう。 また、最小単位規則は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
マルチマスター場合では、錠の使用にもかかわらず、少なくともいくつかの変化が逆にされるのは、必然です。 Aからの変化には紛争解決アルゴリズムあたりの優先権があると仮定する場合、Xの値が0であるべきであり、Yの値が0であるべきである、「USER1"、」
Stokes, et. al. Informational [Page 25] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [25ページ]情報のRFC3384LDAPv3模写要件2002年10月
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.
面白い質問は模写サイクルの終わりの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.
ここの重要な問題は1です。意図している使用について。 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を使用しています。
Stokes, et. al. Informational [Page 26] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [26ページ]情報のRFC3384LDAPv3模写要件2002年10月
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.
これはどんなメカニズムの問題を使用する(s)に残すか。 結局、これはデザイン/実現決定ですが、異なった業者のディレクトリ製品の向こう側の模写は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.
独身のマスターシステムに、すべての変更がマスターで由来しなければなりません。 したがって、マスターは変更のための失敗の1ポイントです。 高い有用性がディレクトリシステムのための要件であるときに、これは心配をかけることができます。
Stokes, et. al. Informational [Page 27] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [27ページ]情報のRFC3384LDAPv3模写要件2002年10月
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).
- 全体のフェイルオーバーの過程を自動化できるなら(オリジナル・マスタが適切に機能していないことを決定すると、例えばフェイルオーバーは外的システムによって開始されます)、有用性は最大にされるでしょうに。
Stokes, et. al. Informational [Page 28] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [28ページ]情報のRFC3384LDAPv3模写要件2002年10月
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での変更のすべて)宣言します。 また、それはいつ変更をディレクトリ(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の改正の間加えられるのは、RECOMMENDEDです。 その間、まるでそのような要件が適所にあるかのように模写SHOULDはこれらの操作を扱います。
Stokes, et. al. Informational [Page 29] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [29ページ]情報のRFC3384LDAPv3模写要件2002年10月
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、5421Fax: +1 5421年の801 326メール: rweiser@trustdst.com
Ellen J. Stokes IBM 11400 Burnet Rd. Austin, TX 78758
エレンJ.ストークスIBM11400Burnet通り オースチン、テキサス 78758
Phone: +1 512 436 9098 Fax: +1 512 436 1193 EMail: stokese@us.ibm.com
以下に電話をしてください。 +1 512 436、9098Fax: +1 1193年の512 436メール: stokese@us.ibm.com
Ryan D. Moats Lemur Networks 15621 Drexel Circle Omaha, NE 68135
ライアンD.モウツキツネザルネットワーク15621ドレクセルはオマハ、Ne68135を旋回します。
Phone: +1 402 894 9456 EMail: rmoats@lemurnetworks.net
以下に電話をしてください。 +1 9456年の402 894メール: 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ローレルアベニュー南部ミドルタウン、ニュージャージー 07748
Phone: +1 732 420 2632 Fax: +1 732 368 1690 EMail: rvh@att.com
以下に電話をしてください。 +1 732 420、2632Fax: +1 1690年の732 368メール: rvh@att.com
Stokes, et. al. Informational [Page 30] RFC 3384 LDAPv3 Replication Requirements October 2002
etストークス、アル。 [30ページ]情報のRFC3384LDAPv3模写要件2002年10月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Stokes, et. al. Informational [Page 31]
etストークス、アル。 情報[31ページ]
一覧
スポンサーリンク
