原文地址：http://www-01.ibm.com/software/tw/sf/archive/vol1/article/t_tdsrepl.html
級別：中級
Darshan Donni ([email protected])，印度的 IBM Software Labs 系統軟體工程師 Neelam V Kulkarni ([email protected])，印度的 IBM Software Labs 系統軟體工程師
原始網頁: http://www-128.ibm.com/developerworks
/tivoli/library/t-tdsrepl/index.html
目錄伺服器隨附的 Web 管理工具是最簡單的抄寫拓蹼設定及管理方式。在某些情況下，管理者可能需要使用指令行執行Lightweight Directory Access Protocol (LDAP) 工具 來設定抄寫。本文旨在協助管理者瞭解使用指令行設定 TivoliR Directory Server (TDS) 抄寫的基本方法。
前言
Tivoli Directory Server 會隨附一個 Web 管理工具。此工具有許多用途，其中一個就是設定抄寫拓蹼。此工具不但提供管理者簡單的點按介面，以設定複雜的抄寫拓蹼，還具備認證管理視窗及拓蹼視覺化介面。但在某些情況下，卻必須使用指令行工具來設定抄寫。可能原因如下：
- 管理者沒有 Web 管理工具的存取權限。
- 對支援人員來說，說明指令行步驟比說明視覺化步驟容易。
- 相較於圖形使用者介面 (GUI)，使用者比較習慣使用指令行工具。
無論是上述哪一種情況，管理者都必須瞭解 TDS 抄寫的概念和資料結構，而本文恰好可以當作入門。我們刻意不將定義納入本文，而是採取由下而上的方法，仔細探討各項目(entries)，然後說明其在拓蹼中所扮演的角色。基於實用性考量，本文將為讀者逐步介紹三大常用設定方式。管理者可利用下文所提到建置步驟為範例設計自己的拓蹼。另一篇文章 "Debugging replication in IBM Tivoli Directory Server" 會詳細介紹抄寫的定義及基本概念。該文章的鏈結在「資源」一節。
拓蹼範例
圖 1. Master-Replica 拓蹼
Master-Replica 拓撲是最常用的拓蹼之一，也是最基本的拓蹼，設定方式非常簡單。此拓蹼有一臺讀寫伺服器及一臺唯讀伺服器。
圖 2. Peer-Peer 拓蹼
對等式(Peer to Peer) 拓蹼是第二種最常用的拓蹼，多數用於高可用性應用程式，因為它有兩臺讀寫伺服器。
圖 3. Master-Forwarder-Replica 拓蹼
雖然不常用，我們還是納入這個拓蹼，因為 Forwarder 是特殊的伺服器類型。Forwarder 是一臺唯讀伺服器，可當作一組抄本之上的「路由器」。
基礎架構
本節已備妥適當的主要資料。您必須假定主機名稱、IP 位址、通訊埠、伺服器 ID 及密碼，因為我們並不是在建置真正的拓蹼。在真實情況下，您必須從實際的基礎架構取得這些資料。
- 主機名稱和通訊埠：這些資訊可讓供應方(Supplier)者有足夠資訊來連接需求方(Consumer)。
- 伺服器 ID：這些 ID 字串可以讓 LDAP 伺服器分辨出拓蹼中其他 LDAP 伺服器。
- 連結 DN 及密碼：供應方會使用 LDAP 通訊協定連接需求方。以 LDAP 的專業術語來說是「連結」(bind)。這個連結需要連結識別名稱 (Bind Distinguished Name) 及密碼。
供應方(Supplier)及需求方(Consumer)：
在抄寫時，更新項目是透過抄寫佇列從某 LDAP 伺服器傳到另一伺服器。將更新項目送入抄寫佇列的伺服器叫供應方，而接受這些變更的伺服器則叫需求方。佇列的維護作業是在供應方上執行。
本文所提到的拓蹼需要最多三臺伺服器。
附註：供應方要能正確解析需求方的主機名稱，否則供應方會無法連到需求方，抄寫也會失敗。
| 伺服器 | 主機名稱 |
|---|---|
| 伺服器 1 | server1.in.ibm.com |
| 伺服器 2 | server2.in.ibm.com |
| 伺服器 3 | server3.in.ibm.com |
所有伺服器都需將 LDAP 伺服器設定在通訊埠 389 上接聽，這是 LDAP 的預設通訊埠。如果您使用 6.0 版且有多個實例，埠號可能會有所不同。
若要針對需求方執行 LDAP 連結，供應方需要連結 DN 及連結密碼。本文假設所有供應方及需求方協議的連結 DN 及密碼如下：
- DN: cn=bindtoconsumer
- 密碼：iamsupplier
每臺伺服器的伺服器 ID 是拓蹼中該伺服器的角色。也就是說，在 Master-Replica 拓蹼中，主要伺服器會將伺服器 ID 指定為 Master，而抄本則是 Replica。在 Peer-Peer 拓蹼中，一個端點是 Peer1，另一個是 Peer2。在 Master-Forwarder-Replica 拓蹼中，主要伺服器是 Master，轉送者是 Forwarder，而抄本則是 Replica。
何謂協議？
本文稍後談到定義抄寫拓蹼所需的各種項目時，會再探討協議 (Agreement)。
抄寫的相關項目
本節將探討用來建置抄寫拓蹼的不同項目類型。
附註：本文不討論進階的抄寫主題，如抄寫排程及 SSL 式的抄寫。因此，這些功能的項目在此不加以贅述。
供應方端：
- 抄寫環境定義：這是所抄寫的子樹狀結構項目。此項目必須具有名為 ibm-replicationContext 的物件類別。若要抄寫子樹狀結構 (o=ibm,c=in)，抄寫環境定義應如下列範例所示：
抄寫環境定義範例
dn: o=ibm, c=in
objectclass: top
objectclass: organization
objectclass: ibm-replicationContext
o: ibm
所有其他抄寫項目（除了認證和排程項目之外）都必須在抄寫環境定義下。認證和排程項目可在目錄資訊樹狀結構 (DIT) 的任何位置。 - 抄寫羣組：此項目的重要性僅在於所有抄寫相關項目都在這個項目之下。ibm-replicaGroup 物件類別必須在這個項目。
抄寫羣組範例
dn: ibm-replicaGroup=default, o=ibm, c=in
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default - 抄寫子項目：這些項目類型會宣告參與抄寫拓蹼的伺服器。每個參與拓蹼的伺服器都有一個子項目。該項目有 ibm-replicaSubentry 物件類別。
抄本子項目範例
dn: ibm-replicaServerId=Peer1,ibm-replicaGroup=default, o=ibm, c=in
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Peer1
ibm-replicationServerIsMaster: true
cn: Peer1
description: Peer1
誠如上述項目所示，該項目有參與伺服器的伺服器 ID，即 Peer1。其中還有 ibm-replicationServerIsMaster 屬性。當這個屬性設為 TRUE 時，即表示此伺服器會是讀寫複本。 - 協議：這些項目類型會出現在抄本子項目之下。當這些項目出現在特定伺服器的抄本子項目時，即定義了拓蹼中，從該伺服器到其他伺服器的抄寫協議。
抄寫協議範例
dn: cn=Peer2, ibm-replicaServerId=Peer1,
ibm-replicaGroup=default,o=ibm,c=in
objectclass: top
objectclass: ibm-replicationAgreement
cn: peer2
ibm-replicaConsumerId: Peer2
ibm-replicaUrl: ldap://server2.in.ibm.com:389
ibm-replicaCredentialsDN: cn=Peer1BindCredentials, cn=localhost
description: Replication agreement from Peer1 to Peer2
上述協議是從 Peer1 到 Peer2。供應方是 Peer1，因為協議出現在 Peer1 的子項目之下。需求方是 Peer2。伺服器 Peer2 是在 server2.in.ibm.com，並於通訊埠 389 上接聽。Peer1 會使用項目 (cn=Peer1BindCredentials,cn=localhost) 中定義的認證連結 Peer2。 - 認證：這些項目會定義連結 DN 及密碼，當有定義此關係的協議時，供應方就用它來連結需求方。這些項目中有 ibm-replicationCredentialsSimple 物件類別。
抄寫認證範例
dn: cn=Peer1BindCredentials, o=ibm, c=in
objectclass: ibm-replicationCredentialsSimple
cn: ReplicaBindCredentials
replicaBindDN: cn=bindtoconsumer
replicaCredentials: iamsupplier
description: Bind Credentials on Peer1 to be used to bind to other servers.
上述項目會將 replicaBindDN 定義為 cn=bindtoconsumer，密碼則定義為 iamsupplier。請注意其說明。相同的認證項目可用於多個抄寫協議。
需求方端：
- 在需求方端，只需要一個抄寫相關項目。供應方嘗試連結到需求方時，需求方會用此項目鑑別供應方身分，以便起始設定抄寫。有兩種認證項目可用於需求方端：需求方端抄寫認證範例：類別 1
dn: cn=Master server, cn=configuration
cn: master server
ibm-slapdMasterDN: cn=bindtoconsumer
ibm-slapdMasterPW: iamsupplier
ibm-slapdMasterReferral: ldap://localhost:1389
objectclass: ibm-slapdReplication
需求方端抄寫認證範例：類別 2
dn: cn=Supplier s1, cn=configuration
cn: Supplier s1
ibm-slapdMasterDN: cn=bindtoconsumer
ibm-slapdMasterPW: iamsupplier
ibm-slapdReplicaSubtree: o=ibm, c=in
objectclass: ibm-slapdSupplier
第二類需求方端認證項目會用在子樹狀目錄抄寫，這項認證僅限使用於 ibm-slapdReplicaSubtree。因此，連結使用者 ID "cn=bindtoconsumer" 及密碼 "iamsupplier" 的供應方只會供給 (o=ibm,c=in) 子樹狀結構，除非另一認證項目提供其他子樹狀結構權限。第一類認證項目在整個 LDAP 伺服器中都可使用。如果伺服器的配置檔已定義該類項目，只要供應方以使用者 ID "cn=bindtoconsumer" 及密碼 "iamsupplier" 進行連結，即可供應任何子樹狀結構。
附註：除了抄寫拓蹼以外，需求方端認證項目必須出現在需求方端。拓蹼項目是伺服器瞭解自己在整個拓蹼中所扮演角色的唯一方法，因此拓蹼中的所有伺服器都需要有這個項目。此外，需求方端認證項目是配置檔中唯一的抄寫相關項目類型。如果這些項目有所變更，您必須重新啟動伺服器，變更才會生效。
建置拓蹼 1 (Master-Replica)
下一步是建置所有拓蹼的最基礎形式：Master-Replica 拓蹼。建置拓蹼的第一步是定義下列各項：
1.抄寫環境定義：(o=ibm,c=in)
2.供應方：在 server1.in.ibm.com:389 上的 LDAP 伺服器是唯一的供應方。伺服器 ID 是 Master。它會提供更新項目到 server2.in.ibm.com:389 上的 LDAP 伺服器。
3.需求方：在 server2.in.ibm.com:389 上的 LDAP 伺服器是唯一的需求方。伺服器 ID 是 Replica。它會從 server1.in.ibm.com:389 上的 LDAP 伺服器取用更新項目。
4.讀寫伺服器：server1.in.ibm.com:389 上，ID 為 Master 的 LDAP 伺服器是唯一的讀寫伺服器。
5.讀寫伺服器：server2.in.ibm.com:389 上，ID 為 Replica 的 LDAP 伺服器是唯一的唯讀伺服器。
配置變更：主要和抄本伺服器必須進行一些配置變更，以便正確執行抄寫。
1.伺服器 ID：
- 開啟主要伺服器的 ibmslapd.conf 檔。搜尋 ibm-slapdServerId 屬性，將其改為 "Master"。
- 開啟抄本伺服器的 ibmslapd.conf 檔。搜尋 ibm-slapdServerId 屬性，將其改為 "Replica"。
2.需求方端認證項目：將此項目新增到抄本伺服器的 ibmslapd.conf 檔。
抄本伺服器的認證項目
dn: cn=Peer1BindCredentials, o=ibm, c=in
dn: cn=Master server, cn=configuration
cn: master server
ibm-slapdMasterDN: cn=bindtoconsumer
ibm-slapdMasterPW: iamsupplier
ibm-slapdMasterReferral: ldap://server1.in.ibm.com:389
objectclass: ibm-slapdReplication
3.重新啟動主要和抄本伺服器。
附註：請留意伺服器 ID。如果其他拓蹼正在使用某伺服器 ID，改變伺服器 ID 可能會導致不利後果。建議在這種情況下使用一般伺服器 ID。例如，使用 Server1，而不是 Master。本文會假設 (o=ibm,c=in) 是唯一會抄寫的子樹狀結構。因此，會使用特定拓蹼伺服器 ID。
下一步是建置拓蹼的 LDAP 資料交換格式 (LDIF) 檔案。此 LDIF 檔會命名為 masterreplica.ldif。直接將這些項目複製到 masterreplica.ldif，並針對子樹狀結構、伺服器 ID、主機名稱及通訊埠做必要變更：
1.抄寫環境定義：
- 若已有子樹狀結構項目：
從現有項目建立抄寫環境定義
dn: cn=Peer1BindCredentials, o=ibm, c=in
dn: o=ibm, c=in
changetype: modify
add: objectclass
objectclass: ibm-replicationContext - 若子樹狀結構項目不存在：
新增具有定義抄寫環境定義所需屬性的子樹狀結構項目
dn: cn=Peer1BindCredentials, o=ibm, c=in
dn: o=ibm, c=in
changetype: add
objectclass: top
objectclass: organization
objectclass: ibm-replicationContext
o: ibm
2. 抄本羣組：
新增抄本羣組
dn: cn=Peer1BindCredentials, o=ibm, c=in
dn: ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default
3. 抄本子項目：
由於拓蹼中有兩個 LDAP 伺服器，所以必須新增兩個抄本子項目：
主要伺服器的子項目
dn: cn=Peer1BindCredentials, o=ibm, c=in
dn: ibm-replicaServerId=Master,ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Master
ibm-replicationServerIsMaster: true
cn: Master
description: Master server of the topology.
抄本伺服器的子項目
dn: cn=Peer1BindCredentials, o=ibm, c=in
dn: ibm-replicaServerId=Replica,ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Replica
ibm-replicationServerIsMaster: false
cn: Replica
description: Replica server of the topology.
4. 認證：這個步驟可定義主要伺服器用來連結到抄寫伺服器的認證。依下列所示新增項目：
主要伺服器用來連結抄本的認證
dn: cn=Peer1BindCredentials, o=ibm, c=in
dn: cn=ReplicaBindCredentials, o=ibm, c=in
changetype: add
objectclass: ibm-replicationCredentialsSimple
cn: ReplicaBindCredentials
replicaBindDN: cn=bindtoconsumer
replicaCredentials: iamsupplier
description: Bind Credentials on master to bind to replica.
主要伺服器用來連結抄本的認證
dn: cn=ReplicaBindCredentials, o=ibm, c=in
changetype: add
objectclass: ibm-replicationCredentialsSimple
cn: ReplicaBindCredentials
replicaBindDN: cn=bindtoconsumer
replicaCredentials: iamsupplier
description: Bind Credentials on master to bind to replica.
請注意，其 DN 及密碼跟上述配置章節新增的那對一樣。
5. 抄寫協議：此拓蹼有一個供應方與需求方關係。Master 會提供抄本 (o=ibm,c=in) 子樹狀結構的更新項目，以便其使用變更。所以只會有一個協議：從主要伺服器到抄本伺服器。請注意，協議數目會因為拓蹼中的供應方與需求方關係數目而異。
從主要到抄本的抄寫協議
dn: cn=Replica,
ibm-replicaServerId=Master,ibm-replicaGroup=default,o=ibm,c=in
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Replica
ibm-replicaConsumerId: Replica
ibm-replicaUrl: ldap://server2.in.ibm.com:389
ibm-replicaCredentialsDN: cn=ReplicaBindCredentials, o=ibm, c=in
description: Replication agreement from master to replica.
上述項目位於主要伺服器的子項目之下，會供應至 ID 為 Replica 的需求方。抄本 URL 是 ldap://server2.in.ibm.com:389，即表示抄本是在 server2.in.ibm.com 的通訊埠 389 上接聽。此協議會使用上一個步驟所建立的認證，讓主要伺服器連結抄本。也就是說，主要伺服器會以 cn=bindtoconsumer 及密碼 iamsupplier 連結抄本。
請注意，抄本的子項目之下並沒有協議。這很正常，因為抄本是唯讀版本，無法接收任何用戶端更新項目，所以根本不需要協議（因為沒有更新要傳送）。
現已新增抄寫項目，masterreplica.ldif 的內容應該如下：
masterreplica.ldif 的內容
dn: o=ibm, c=in changetype: add
objectclass: top
objectclass: organization
objectclass: ibm-replicationContext
o: ibm
dn: ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default
dn: ibm-replicaServerId=Master,ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Master
ibm-replicationServerIsMaster: true
cn: Master
description: Master server of the topology.
dn: ibm-replicaServerId=Replica,ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Replica
ibm-replicationServerIsMaster: false
cn: Replica
description: Replica server of the topology.
dn: cn=ReplicaBindCredentials, o=ibm, c=in
changetype: add
objectclass: ibm-replicationCredentialsSimple
cn: ReplicaBindCredentials
replicaBindDN: cn=bindtoconsumer
replicaCredentials: iamsupplier
description: Bind Credentials on master to bind to replica.
dn: cn=Replica, ibm-replicaServerId=Master,ibm-replicaGroup=default,o=ibm,c=in
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Replica
ibm-replicaConsumerId: Replica
ibm-replicaUrl: ldap://server2.in.ibm.com:389
ibm-replicaCredentialsDN: cn=ReplicaBindCredentials, o=ibm, c=in
description: Replication agreement from master to replica.
請注意，如果抄寫環境定義已存在，LDIF 會有點不一樣。不會是以下內容：
dn: o=ibm, c=in
changetype: add
objectclass: top
objectclass: organization
objectclass: ibm-replicationContext
o: ibm
而是：
dn: o=ibm, c=in
changetype: modify
add: objectclass
objectclass: ibm-replicationContext
為方便說明，在下一個範例中，本文假設子樹狀結構根本不存在。
現在，將 masterreplica.ldif 檔載入主要伺服器。從建立 masterreplica.ldif 檔的位置，針對主要伺服器執行下列指令（整個指令要在同一行）：
ldapmodify -h server1.in.ibm.com -p 389 -D [administrator DN] -w [administrator password] -i masterreplica.ldif -k -l
-l 選項是 6.0 版的功能，指示伺服器現在不要抄寫拓蹼。-k 選項會將管理者控制傳送給伺服器，所以即使伺服器 ID 不符以致子樹狀結構變成唯讀，項目還是會持續新增。如果您是使用 5.2 版，使用 ldif2db 指令時，-r 需設為 NO。現在，也需要將拓蹼載入抄本伺服器。如果您是用 6.0 版，可執行下列指令：
ldapexop -h server1.in.ibm.com -p 389 -D [administrator DN] -w [administrator password]
-op repltopology -rc o=ibm,c=in
這個延伸作業稱為 repltopology。它會將拓蹼傳到 (o=ibm,c=in) 抄寫環境定義下所定義的所有需求方。若使用 5.2 版，讀者也需要在抄本上使用 ldif2db，並且將 -r 設為 NO。
順利執行上述兩個指令後，即完成 Master-Replica 拓蹼。主要伺服器會接收 (o=ibm,c=in) 子樹狀結構的更新項目，然後傳到抄本。抄本不會接受更新項目，但會轉介給主要伺服器，以免用戶端想要更新。不過，抄本可以處理搜尋。
建置拓蹼 2（對等式）
對等式抄寫拓蹼跟 Master-Replica
拓蹼差不多。同樣有兩臺伺服器，但這兩臺現在是讀寫伺服器，可彼此提供變更。一如往常，建置拓蹼的第一步是定義下列各項：
1.抄寫環境定義：(o=ibm,c=in)
2.供應方：server1.in.ibm.com:389 上，伺服器 ID 為 Peer1 的 LDAP 伺服器會提供更新項目給 server2.in.ibm.com:389 上，伺服器 ID 為 Peer2 的 LDAP 伺服器。server2.in.ibm.com:389 上，伺服器 ID 為 Peer2 的 LDAP 伺服器也會提供更新項目給 server1.in.ibm.com:389 上，伺服器 ID 為 Peer1 的 LDAP 伺服器。
3.需求方：server2.in.ibm.com:389 上，伺服器 ID 為 Peer2 的 LDAP 伺服器會取用 server1.in.ibm.com:389 上，伺服器 ID 為 Peer1 的 LDAP 伺服器提供的更新項目。server1.in.ibm.com:389 上，伺服器 ID 為 Peer1 的 LDAP 伺服器也會取用 server2.in.ibm.com:389 上，伺服器 ID 為 Peer2 的 LDAP 伺服器所提供之更新項目。
4.讀寫伺服器：server1.in.ibm.com 和 server2.in.ibm.com 上的 LDAP 伺服器 peer1 及 peer2 都是讀寫伺服器。
5.唯讀伺服器：本拓蹼沒有唯讀伺服器。
配置變更：peer1 和 peer2 伺服器都要進行一些變更，才能正確執行抄寫。我們假設剛完成伺服器配置。如果您是使用 Master-Replica 設定所用的相同伺服器，只要取消您在該節所做的變更即可。
1.伺服器 ID：
開啟 peer1 伺服器 (server1.in.ibm.com) 的 ibmslapd.conf 檔。搜尋 ibm-slapdServerId 屬性，將其改為 "Peer1"。
開啟 peer2 伺服器 (server2.in.ibm.com) 的 ibmslapd.conf 檔。搜尋 ibm-slapdServerId 屬性，將其改為 "Peer2"。
2.需求方端認證項目：
將此項目新增到 peer1 伺服器的 ibmslapd.conf 檔。
peer1上的認證項目
dn: cn=Master server, cn=configuration
cn: master server
ibm-slapdMasterDN: cn=bindtoconsumer
ibm-slapdMasterPW: iamsupplier
ibm-slapdMasterReferral: ldap://server2.in.ibm.com:389
objectclass: ibm-slapdReplication
將此項目新增到 peer2 伺服器的 ibmslapd.conf 檔。
peer2 上的認證項目
dn: cn=Master server, cn=configuration
cn: master server
ibm-slapdMasterDN: cn=bindtoconsumer
ibm-slapdMasterPW: iamsupplier
ibm-slapdMasterReferral: ldap://server1.in.ibm.com:389
objectclass: ibm-slapdReplication
3.重新啟動 peer1 和 peer2 伺服器。
現在來建置拓蹼的 LDIF 檔，稱為 peer2peer.ldif。直接將這些項目複製到 peer2peer.ldif，並針對子樹狀結構、伺服器 ID、主機名稱及通訊埠做必要變更：
1.抄寫環境定義：
新增抄寫環境定義。
dn: o=ibm, c=in changetype: add
add: objectclass
objectclass: ibm-replicationContext
2. 抄本羣組：
新增抄本羣組
dn: ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default
3. 抄本子項目：
由於拓蹼中有兩個 LDAP 伺服器，所以需要兩個抄本子項目：
peer1 的子項目
dn: ibm-replicaServerId=Peer1,ibm-replicaGroup=default, o=ibm, c=in changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Peer1
ibm-replicationServerIsMaster: true
cn: Peer1
description: Subentry for Peer1.
peer2 的子項目
dn: ibm-replicaServerId=Peer2,ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Peer2
ibm-replicationServerIsMaster: true
cn: Peer2
description: Subentry for Peer2.
peer1 子項目會將伺服器 ID 指定為 Peer1，並將伺服器宣告為主要伺服器。此伺服器可接收來自用戶端的更新項目。peer2 子項目會將伺服器 ID 指定為 Peer2，也將伺服器宣告為主要伺服器。此伺服器也會從跟其連結的 LDAP 用戶端接收更新項目。
4. 認證：若要定義 peer1 要用來連結 peer2 的認證，請新增下列項目：
peer1 和 peer2 用來連結彼此的認證
dn: cn=ReplicaBindCredentials, o=ibm, c=in
changetype: add
objectclass: ibm-replicationCredentialsSimple
cn: ReplicaBindCredentials
replicaBindDN: cn=bindtoconsumer
replicaCredentials: iamsupplier
description: Bind Credentials on peer1 and peer2 to bind to each other.
5. 抄寫協議：此拓蹼有兩個供應方與需求方關係。Peer1 會提供 Peer2 (o=ibm,c=in) 子樹狀結構的更新，以便其進行變更。另一方面，Peer2 也會接收來自用戶端的 (o=ibm,c=in) 子樹狀結構更新，然後再傳給 Peer1，以便進行變更。所以，會有兩個協議：Peer1 至 Peer2，以及 Peer2 至 Peer1。請注意，協議數目會因為拓蹼中的供應方與需求方關係數目而異。
peer1 至 peer2 的抄寫協議
dn: cn=Peer2, ibm-replicaServerId=Peer1,ibm-replicaGroup=default,o=ibm,c=in
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Peer2
ibm-replicaConsumerId: Peer2
ibm-replicaUrl: ldap://server2.in.ibm.com:389
ibm-replicaCredentialsDN: cn=ReplicaBindCredentials, o=ibm, c=in
description: Replication agreement from peer1 to peer2.
peer2 至 peer1 的抄寫協議
dn: cn=Peer1, ibm-replicaServerId=Peer2,ibm-replicaGroup=default,o=ibm,c=in
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Peer1
ibm-replicaConsumerId: Peer1
ibm-replicaUrl: ldap://server1.in.ibm.com:389
ibm-replicaCredentialsDN: cn=ReplicaBindCredentials, o=ibm, c=in
description: Replication agreement from peer2 to peer1.
此拓蹼的兩個協議如上所示。第一個協議是從 Peer1 到 Peer2，位於 Peer1 子項目之下。第二個協議是從 Peer2 到 Peer1，位於 Peer2 子項目之下。請注意，兩個協議都使用相同的認證項目，這是完全可行的。該認證項目會新增到 peer1 及 peer2。
現已新增抄寫項目，peer2peer.ldif 的內容應該如下：
peer2peer.ldif 的內容
dn: o=ibm, c=in
changetype: add
objectclass: top
objectclass: organization
objectclass: ibm-replicationContext
o: ibm
dn: ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default
dn: ibm-replicaServerId=Peer1,ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Peer1
ibm-replicationServerIsMaster: true
cn: Peer1
description: Subentry for Peer1.
dn: ibm-replicaServerId=Peer2,ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Peer2
ibm-replicationServerIsMaster: true
cn: Peer2
description: Subentry for Peer2.
dn: cn=ReplicaBindCredentials, o=ibm, c=in
changetype: add
objectclass: ibm-replicationCredentialsSimple
cn: ReplicaBindCredentials
replicaBindDN: cn=bindtoconsumer
replicaCredentials: iamsupplier
description: Bind Credentials on peer1 and peer2 to bind to each other.
dn: cn=Peer2, ibm-replicaServerId=Peer1,ibm-replicaGroup=default,o=ibm,c=in
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Peer2
ibm-replicaConsumerId: Peer2
ibm-replicaUrl: ldap://server2.in.ibm.com:389
ibm-replicaCredentialsDN: cn=ReplicaBindCredentials, o=ibm, c=in
description: Replication agreement from peer1 to peer2.
dn: cn=Peer1, ibm-replicaServerId=Peer2,ibm-replicaGroup=default,o=ibm,c=in
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Peer1
ibm-replicaConsumerId: Peer1
ibm-replicaUrl: ldap://server1.in.ibm.com:389
ibm-replicaCredentialsDN: cn=ReplicaBindCredentials, o=ibm, c=in
description: Replication agreement from peer2 to peer1.
現在，將 peer2peer.ldif 檔載入 peer1 伺服器。從建立peer2peer.ldif檔的位置，針對 peer1 伺服器執行下列指令（整個指令要在同一行）：
ldapmodify -h server1.in.ibm.com -p 389 -D [administrator DN] -w [administrator password]
-i peer2peer.ldif -k -l
現在，也將拓蹼載入抄本。若是 6.0 版，您可執行下列指令：
ldapexop -h server1.in.ibm.com -p 389 -D [administrator DN] -w [administrator password]
-op repltopology -rc o=ibm,c=in
若是 5.2 版，則針對抄本使用 ldif2db，並將 -r 設為 No。
順利執行上述兩個指令後，即完成 Peer-Peer 拓蹼。這兩個對等伺服器會接受更新項目，並傳送給彼此。
建置拓蹼 3 (Master-Forwarder-Replica)
接下來是 Master-Forwarder-Replica 複寫拓蹼。有關轉送者 (Forwarder) 的一些注意事項：這是特殊抄本。抄本是唯讀的，轉送者也是。抄本不會傳送他們所使用的變更。但轉送者會抄寫他們所使用的變更。為了將變更提供給整個拓蹼，轉送者的子項目下會有協議。試把轉送者當作是配電板，會從電源插座取得電源，然後再提供給兩個或以上的插座使用。
附註：閘道也很像配電板。唯一的差別是，轉送者是特殊抄本，而閘道是特殊主要伺服器。
掌握這些資訊後，現在來開始建置拓蹼。此拓蹼要再加入一臺伺服器：server3.in.ibm.com。同樣地，建置拓蹼的第一步是定義下列各項：
1.抄寫環境定義：(o=ibm,c=in)
2.供應方：server1.in.ibm.com:389 上，伺服器 ID 為 Master 的 LDAP 伺服器會提供更新項目給 server2.in.ibm.com:389 上，伺服器 ID 為 Forwarder 的 LDAP 伺服器。server2.in.ibm.com:389 上，伺服器 ID 為 Forwarder 的 LDAP 伺服器也會提供更新項目給 server1.in.ibm.com:389 上，伺服器 ID 為 Replica 的 LDAP 伺服器。
3.需求方：server2.in.ibm.com:389 上，伺服器 ID 為 Forwarder 的 LDAP 伺服器會取用 server1.in.ibm.com:389 上，伺服器 ID 為 Master 的 LDAP 伺服器提供的更新項目。server3.in.ibm.com:389 上，伺服器 ID 為 Replica 的 LDAP 伺服器也會取用 server2.in.ibm.com:389 上，伺服器 ID 為 Forwarder 的 LDAP 伺服器所提供之更新項目。
4.讀寫伺服器：只有伺服器 ID 為 Master 的 LDAP 伺服器纔是讀寫伺服器。
5.唯讀伺服器：伺服器 ID 為 Forwarder 及 Replica 的 LDAP 伺服器則是唯讀的。
配置變更：主要、轉送者及抄寫伺服器都要進行一些變更，才能正確執行抄寫。本節假設現在使用的伺服器剛好完成配置。若要重複使用 Master-Replica 設定所用的相同伺服器，只要取消該節所做的變更即可。若要重複使用 Peer-Peer 設定所用的相同伺服器，請取消該節所做的變更。
1.伺服器 ID：
開啟主要伺服器 (server1.in.ibm.com) 的 ibmslapd.conf 檔。搜尋 ibm-slapdServerId 屬性，將屬性改為 "Master"。
開啟轉送者伺服器 (server2.in.ibm.com) 的 ibmslapd.conf 檔。搜尋 ibm-slapdServerId 屬性，將屬性改為 "Forwarder"。
開啟抄本伺服器 (server3.in.ibm.com) 的 ibmslapd.conf 檔。搜尋 ibm-slapdServerId 屬性，將屬性改為 "Replica"。
2.需求方端認證項目：
將此項目新增到轉送者伺服器的 ibmslapd.conf 檔。
轉送者上的認證項目
dn: cn=Master server, cn=configuration
cn: master server
ibm-slapdMasterDN: cn=bindtoconsumer
ibm-slapdMasterPW: iamsupplier
ibm-slapdMasterReferral: ldap://server1.in.ibm.com:389
objectclass: ibm-slapdReplication
將此項目新增到抄本伺服器的 ibmslapd.conf 檔。
抄本伺服器的認證項目
dn: cn=Master server, cn=configuration
cn: master server
ibm-slapdMasterDN: cn=bindtoconsumer
ibm-slapdMasterPW: iamsupplier
ibm-slapdMasterReferral: ldap://server1.in.ibm.com:389
objectclass: ibm-slapdReplication
3.重新啟動主要、轉送者和抄本伺服器。
現在，開始建置拓蹼的 LDIF 檔，此 LDIF 檔稱為 mfr.ldif。直接將這些項目複製到 mfr.ldif，並針對子樹狀結構、伺服器 ID、主機名稱及通訊埠做必要變更：
1. 抄寫環境定義：
新增抄寫環境定義
dn: o=ibm, c=in
changetype: add
add: objectclass
objectclass: ibm-replicationContext
2.抄本羣組：
新增抄本羣組
dn: ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default
3.抄本子項目：
由於拓蹼中有三臺 LDAP 伺服器，所以需要三個抄本子項目：
主要伺服器的子項目
dn: ibm-replicaServerId=Master,ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Master
ibm-replicationServerIsMaster: true
cn: Master
description: Subentry for Master.
轉送者伺服器的子項目
dn: ibm-replicaServerId=Forwarder,ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Forwarder
ibm-replicationServerIsMaster: false
cn: Forwarder
description: Subentry for the Forwarder.
抄本伺服器的子項目
dn: ibm-replicaServerId=Replica,ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Replica
ibm-replicationServerIsMaster: false
cn: Replica
description: Subentry for the Replica.
主要伺服器子項目會將伺服器 ID 指定為 Master，並宣告此伺服器是主要伺服器，也就是說，伺服器可接受來自用戶端的更新項目。轉送者子項目會將伺服器 ID 指定為 Forwarder，並宣告為非主要伺服器，無法從用戶端取得更新項目。抄本子項目會將伺服器 ID 指定為Replica，並宣告為非主要伺服器，無法從用戶端取得更新項目。
4. 認證：現在，定義主要伺服器用來連結轉送者的認證。將類以下列內容的項目新增到 mfr.ldif：
主要伺服器用來連結轉送者的認證
dn: cn=ReplicaBindCredentials, o=ibm, c=in
changetype: add
objectclass: ibm-replicationCredentialsSimple
cn: ReplicaBindCredentials
replicaBindDN: cn=bindtoconsumer
replicaCredentials: iamsupplier
description: Bind Credentials on master to bind to forwarder.
5. 抄寫協議：此拓蹼有兩個供應方與需求方關係。Master 會提供 Forwarder (o=ibm,c=in) 子樹狀結構的更新，然後再將這些變更提供給 Replica。所以會有兩個協議：Master 至 Forwarder，以及Forwarder 至 Replica。請注意，協議數目會因為拓蹼中的供應方與需求方關係數目而異。 Master 至 Forwarder 的抄寫協議
dn: cn=Forwarder, ibm-replicaServerId=Master,ibm-replicaGroup=default,o=ibm,c=in
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Forwarder
ibm-replicaConsumerId: Forwarder
ibm-replicaUrl: ldap://server2.in.ibm.com:389
ibm-replicaCredentialsDN: cn=ReplicaBindCredentials, o=ibm, c=in
description: Replication agreement from Master to Forwarder.
Forwarder 至 Replica 的抄寫協議
dn: cn=Replica, ibm-replicaServerId=Forwarder,
ibm-replicaGroup=default,o=ibm,c=in
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Replica
ibm-replicaConsumerId: Replica
ibm-replicaUrl: ldap://server3.in.ibm.com:389
ibm-replicaCredentialsDN: cn=ReplicaBindCredentials, o=ibm, c=in
description: Replication agreement from Forwarder to Replica.
此拓蹼的兩個協議如上所示。第一個協議是從 Master到 Forwarder，位於 Master 子項目之下。第二個協議是從 Forwarder到 Replica，位於 Forwarder 子項目之下。請注意，兩個協議都使用相同的認證項目，這是完全可行的。我們會將認證項目新增到 Master 及 Forwarder。現已新增抄寫項目，mfr.ldif 的內容應該如下：
現已新增抄寫項目，mfr.ldif 的內容應該如下：
mfr.ldif 的內容 dn: o=ibm, c=in
changetype: add
objectclass: top
objectclass: organization
objectclass: ibm-replicationContext
o: ibm
dn: ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaGroup
ibm-replicaGroup: default
dn: ibm-replicaServerId=Master,
ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Master
ibm-replicationServerIsMaster: true
cn: Master
description: Subentry for Master.
dn: ibm-replicaServerId=Forwarder,
ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Forwarder
ibm-replicationServerIsMaster: false
cn: Forwarder
description: Subentry for the Forwarder.
dn: ibm-replicaServerId=Replica,ibm-replicaGroup=default, o=ibm, c=in
changetype: add
objectclass: top
objectclass: ibm-replicaSubentry
ibm-replicaServerId: Replica
ibm-replicationServerIsMaster: false
cn: Replica
description: Subentry for the Replica.
dn: cn=ReplicaBindCredentials, o=ibm, c=in
changetype: add
objectclass: ibm-replicationCredentialsSimple
cn: ReplicaBindCredentials
replicaBindDN: cn=bindtoconsumer
replicaCredentials: iamsupplier
description: Bind Credentials on master
to bind to forwarder.
dn: cn=Forwarder, ibm-replicaServerId=Master,ibm-replicaGroup=default,o=ibm,c=in
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Forwarder
ibm-replicaConsumerId: Forwarder
ibm-replicaUrl: ldap://server2.in.ibm.com:389
ibm-replicaCredentialsDN:
cn=ReplicaBindCredentials, o=ibm, c=in
description: Replication agreement from Master to Forwarder.
dn: cn=Replica, ibm-replicaServerId=Forwarder,
ibm-replicaGroup=default,o=ibm,c=in
changetype: add
objectclass: top
objectclass: ibm-replicationAgreement
cn: Replica
ibm-replicaConsumerId: Replica
ibm-replicaUrl: ldap://server3.in.ibm.com:389
ibm-replicaCredentialsDN: cn=ReplicaBindCredentials, o=ibm, c=in
description: Replication agreement from Forwarder to Replica.
現在將 mfr.ldif 檔載入 Forwarder 伺服器。從建立 mfr.ldif 檔的位置，針對 Master 伺服器執行下列指令（整個指令要在同一行）：
ldapmodify -h server1.in.ibm.com -p 389 -D [administrator DN] -w [administrator password] -i mfr.ldif -k -l
現在將 mfr.ldif 檔載入 Forwarder 伺服器。從建立 mfr.ldif 檔的位置，針對 Master 伺服器執行下列指令（整個指令要在同一行）：
ldapmodify -h server2.in.ibm.com -p 389 -D [administrator DN] -w [administrator password] -i mfr.ldif -k -l
現在，也將拓蹼載入抄本。若是 6.0 版，請在轉送者執行下列指令：
ldapexop -h server2.in.ibm.com -p 389 -D [administrator DN] -w [administrator password] -op repltopology -rc o=ibm,c=in
若是 5.2 版，必須針對轉送者及抄本上使用 ldif2db，並將 -r 設為 No。
順利執行上述指令後，即完成 Master-Forwarder-Replica 拓蹼。Master 會接受更新項目，然後傳給 Forwarder，再傳給 Replica。如果要將另一抄本新增到拓蹼，您只要在 Forwarder 之下新增另一個抄本子項目，並從轉送者將協議新增到該抄本。
一些基本定律
1.拓蹼中的所有對等式都必須供應其中的所有伺服器，除非它們用閘道隔開。若用閘道隔開，同一閘道下的所有對等式必須供應其他伺服器，包括閘道。這是因為對等伺服器並不會抄寫其他對等式提供的變更，以致對等式會接受本身起始的更新項目。
2.拓蹼中的所有閘道都需要彼此供應。一個拓蹼必須有至少兩個閘道纔有用。
唯讀伺服器的相關資訊
唯讀伺服器不會接收用戶端傳送的更新項目。如果不會，那些更新要求怎麼辦呢？ 請看下列圖解： 圖 4. 有轉介的認證項目（類型 1）
當用戶端傳送更新要求給唯讀伺服器時，該伺服器會將轉介傳回用戶端。然後，用戶端可追蹤該轉介，並將更新項目放到該伺服器上。轉介通常會指向唯讀伺服器的供應方。類型 2 的認證項目並沒有轉介。上述認證項目類型源自前版 TDS，其中並沒有使用子樹狀結構抄寫。只有 5.1 版採用的子樹狀結構抄寫纔有用到類型 2 的認證項目。
圖 5. 沒有轉介的認證項目（類型 2）
在這種情況下，抄寫環境定義會用作轉介的位置保留元。環境定義項目類似以下內容：
圖 6. 抄寫環境定義用作轉介的位置保留元
反向工程抄寫拓蹼
本文只探討三種抄寫拓蹼。但您可能想進一步瞭解複雜的拓蹼，或有興趣分析 Web 管理工具建立的拓蹼，使用本文提到的概念，即可輕鬆分析該工具建立的抄寫拓蹼。事實上，您甚至可以使用 Web 管理工具（在測試環境中）建置複雜的拓蹼，擷取必要項目和屬性，然後在目標環境上複製確切設定方法。
作者簡介
Darshan 是位於印度的 IBM Software Labs 系統軟體工程師。他是 IBM Tivoli Directory Server L2 支援團隊成員，過去曾服務於 Component Verification Team for TDS 將近一年時間。他的興趣涵蓋抄寫和分散式目錄。
Neelam 是位於印度的 IBM Software Labs TDS 測試團隊的系統軟體工程師。她操作過大部分目錄元件，興趣涵蓋抄寫及 Proxy 伺服器