| Works
「389 Directory Server」のレプリケーション
前回の続きです。
サーバごとに独立したインスタンスを作成したので、今回はマルチマスターレプリケーションを構成します。
ちなみにRed Hat Directory Serverのドキュメントだとマスターではなくサプライヤー(Supplier)と呼んでますね。読み取りのみのサーバはコンシューマー(Consumer)とのこと。
環境
前回の続きなので、環境はそのままです。
レプリケーションの構成はどちらのサーバで実行しているかに注意します。
ホスト名 | FQDN | IPアドレス | レプリカID |
ds-1 | ds-1.example.com | 172.16.11.51 | 1 |
ds-2 | ds-2.example.com | 172.16.11.52 | 2 |
事前準備
ここからコマンドを入力していくのですが、コマンドの度にLDAPの接続先やパスワードを入力するのは手間なので、既定の接続情報を設定ファイルに記述しておきます。
2台のサーバそれぞれで新規に"/root/.dsrc"ファイルを作成し、以下の内容を記述します。
[localhost]
uri = ldapi://%%2fvar%%2frun%%2fslapd-localhost.socket
binddn = cn=Directory Manager
basedn = dc=example,dc=com
これをしておくことで、"dsconf"や"dsidm"といったコマンドを使うときに接続先の詳細を省略することができます。
"ldapi://"で始まるURIはLDAPへIPC接続するときの指定方法です。"root"ユーザーでここへアクセスすると"cn=Directory Manager"の権限で操作できます。
レプリケーション有効化の確認
最初に各ノードでレプリケーションを有効にするのですが、今回はインスタンス作成時の設定ファイルの中で有効にしてしまっているので確認のみです。
まずは"ds-1"側で次のコマンド結果を確認します。
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
cn: replica
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaId: 1
nsDS5ReplicaName: b5f26ab5-f95a11ee-9079cb92-8ec9756e
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaType: 3
nsState:: AQAAAAAAAADtHhpmAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAA==
nsds5ReplicaChangeCount: 2
nsds5replicareapactive: 0
objectClass: top
objectClass: nsds5Replica
"dsconf"に続いて指定している"localhost"は、先程の".dsrc"ファイルで設定した内容です。
上記の例ではレプリケーションが有効化されており、レプリカIDやレプリケーション用アカウント等が読み取れます。
同様に"ds-2"側でもコマンドを実行し、レプリケーションが有効化されていることの他にレプリカID(nsDS5ReplicaId)が異なることを確認します。
2台のサーバでレプリカIDが同じだと双方向のレプリケーションは構成できません。
レプリケーションの実行(ds-1 → ds-2)
では、実際にレプリケーションを実行します。
今回はサーバ間の通信に暗号化されたLDAPSを使うことにします。
証明書はインスタンス作成時の設定ファイルで指定したように自己署名署名を使っているのですが、証明書のホスト名チェックでエラーになる場合があるので、次のコマンドでホスト名チェックを無効化しておきます(2台両方で実行)。
続いて、"agmt-ds1-to-ds2"というレプリケーション合意を作成し、レプリケーションの初期化を実行します。
この作業は"ds-1"側で実行します。
引数で与えているレプリケーション用アカウントやパスワードはインスタンス作成時の設定ファイルに記載した内容です。レプリケーション先(--host)には"ds-2"のFQDNを指定します。
コマンドが正常に実行できたら、正常に初期化できたか確認します。
Agreement successfully initialized.
上記のように表示されれば初期化は成功です。
レプリケーションのステータスも確認しておきます。
Status For Agreement: "agmt-ds1-to-ds2" (ds-2.example.com:636)
Replica Enabled: on
Update In Progress: FALSE
Last Update Start: 20240413061925Z
Last Update End: 20240413061925Z
Number Of Changes Sent: 0
Number Of Changes Skipped: None
Last Update Status: Error (0) Replica acquired successfully: Incremental update succeeded
Last Init Start: 20240413061922Z
Last Init End: 20240413061924Z
Last Init Status: Error (0) Total update succeeded
Reap Active: 0
Replication Status: Not in Synchronization: supplier (Unknown) consumer (Unknown) State (green) Reason (error (0) replica acquired successfully: incremental update succeeded)
Replication Lag Time: unavailable
"Last Update End"が直近の時間を示しており、"Last Update Status"が"Incremental update succeeded"となっていればレプリケーションが正常に実行されたものと思います。
レプリケーションの実行(ds-2 → ds-1)
今度は逆向きのレプリケーション合意"agmt-ds2-to-ds1"を作成します。
"ds-2"側で実行します。
コマンドの内容はほぼ同じなのですが、逆向きなのでレプリケーション先(--host)には"ds-1"を指定します。また、初期化はしないので"--init"オプションは指定しないでください。
コマンドが正常に実行できたら、"ds-1"の時と同様にステータスを確認します。
Status For Agreement: "agmt-ds2-to-ds1" (ds-1.example.com:636)
Replica Enabled: on
Update In Progress: FALSE
Last Update Start: 20240413062955Z
Last Update End: 20240413062955Z
Number Of Changes Sent: 0
Number Of Changes Skipped: None
Last Update Status: Error (0) Replica acquired successfully: Incremental update succeeded
Last Init Start: 19700101000000Z
Last Init End: 19700101000000Z
Last Init Status: unavailable
Reap Active: 0
Replication Status: Not in Synchronization: supplier (Unknown) consumer (Unknown) State (green) Reason (error (0) replica acquired successfully: incremental update succeeded)
Replication Lag Time: unavailable
ステータスが正常であれば双方向でレプリケーションが構成できました。
これでどちらか一方でユーザー作成等をすると、もう一方にも反映されるはずです。
今回はここまで。(次へ続く)