「認証サーバーが止まりました」＝「全社員が仕事できません」
こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、ACIによるアクセス制御について学びました。
これでセキュアなディレクトリができましたが、サーバーが「1台」しかない状態は、インフラエンジニアにとって悪夢でしかありません。
認証基盤はシステムの「心臓」です。
Webサーバーが落ちてもWebが見られないだけですが、LDAPサーバーが落ちると、PCへのログイン、メールの送受信、ファイルサーバーへのアクセス、VPN接続……すべてが停止します。
このSPOF（単一障害点）を解消するのが「レプリケーション」です。
先生、レプリケーションはOpenLDAPでもやってました！
でも、マスター（書き込み用）とスレーブ（読み取り用）を分けて構成してたら、マスターが死んだときに書き込みができなくなって、手動でスレーブを昇格させる作業で徹夜しました……。
「どっちに書き込んでもOK」みたいな夢のような構成はないんですか？
コウ君、それこそが389 Directory Serverの真骨頂よ。
389 DSは「マルチマスターレプリケーション (MMR)」を標準でサポートしているの。
4台以上のマスター構成も組めるし、どのサーバーで更新しても、瞬時に他のサーバーへ同期されるわ。
しかも、同時に同じデータを書き換えた時の「競合解決」ロジックが非常に優秀なの。
今回もウィンドウズ先生に、止まらないシステムの極意を教えてもらいましょう！
はい、ウィンドウズ先生です。
Active Directoryもマルチマスターですが、389 DSも同様のアーキテクチャを持っています。
OpenLDAPのMirrorMode設定で苦労した方なら、389 DSの「設定のシンプルさ」と「動作の安定性」に驚くはずです。
今回は、単なる設定手順だけでなく、裏側で動いているCSN（Change Sequence Number）の仕組みや、障害発生時の挙動まで、プロとして知っておくべき深層を解説します。
本記事では、レプリケーションの基礎理論、トポロジー設計、dsconf コマンドによる構築手順、そして障害復旧テストまでを徹底解説します。
🐧 389 Directory Server 完全攻略講座 カリキュラム
- 【第1回】OpenLDAP vs 389 DS。アーキテクチャの違いから学ぶ、次世代LDAPの選定基準
- 【第2回】爆速インストール。構成ファイルによるIaC化とCockpit Web GUIの構築
- 【第3回】CLI管理の革命。dsidmコマンドとJSON出力の活用
- 【第4回】アクセス制御 (ACI) の設計論。ACLとの決定的な違い
- 【第5回】マルチマスターレプリケーション構築。可用性99.999%への道
- 【第6回】セキュリティ強化。自己署名証明書の撤廃とTLS完全化
- 【第7回】パフォーマンスチューニング。インデックス設計とキャッシュ戦略
- 【第8回】クライアント連携。SSSDによるオフライン認証と統合管理
目次
第1章：レプリケーションの基礎理論と用語定義
構築に入る前に、389 DSにおけるレプリケーションの用語を整理しましょう。
OpenLDAPやデータベース用語とは微妙に異なる部分があります。
3つの役割（ロール）
| 役割名 | 機能概要 | 書き込み |
|---|---|---|
| Supplier (Master) | データの発生源。更新を受け付け、他のサーバーへ変更を通知する。 | 可能 |
| Consumer (Slave) | データの受信者。Supplierから更新を受け取る。読み取り専用。 | 不可（ReferralでSupplierへ転送） |
| Hub | Consumerでありながら、さらに下流のConsumerへデータを中継する。 | 不可 |
マルチマスターレプリケーション (MMR)
2台以上のサーバーが「Supplier」として互いにデータを同期し合う構成です。
389 DSでは、最大4台までの書き込み可能なSupplierを構成できます（理論上はもっと可能ですが、競合解決のオーバーヘッドのため4台が推奨上限です）。
レプリケーションアグリーメント (Agreement)
「サーバーAからサーバーBへ同期する」という契約のことです。
一方通行の設定なので、双方向（マルチマスター）にする場合は、A→B と B→A の2つのアグリーメントを作成する必要があります。
第2章：競合解決のロジック。CSNとRUVの役割
「2台のサーバーで、同時に同じユーザーの電話番号を変更したらどうなるのか？」
このデータの整合性を保つ仕組みが、389 DSの心臓部です。
CSN (Change Sequence Number)
すべての変更操作（Add, Modify, Delete）には、CSN という一意なIDが付与されます。
CSNは以下の要素で構成されています。
Timestamp + Sequence + ReplicaID + SubSequence
競合が発生した場合、389 DSは「CSNのタイムスタンプが新しい方を勝者とする（Last Write Wins）」というルールで自動解決します。
これにより、管理者が介入することなくデータの収束が行われます。
RUV (Replica Update Vector)
「どのサーバーの変更を、どこまで取り込んだか」を管理する情報です。
Gitのコミットハッシュのようなものです。
レプリケーションが遅延している場合、このRUVを比較することで「サーバーBはサーバーAの5分前の状態だ」といった診断が可能になります。
💡 プロの注意点：時刻同期の重要性
CSNはタイムスタンプベースです。
もしサーバー間の時刻が大幅にずれていると、古い変更が「最新」と誤認され、データが先祖返りする恐れがあります。
NTP (Chrony) の設定は、LDAP構築前に必ず完璧にしておいてください。
第3章：設計フェーズ。トポロジーと可用性レベル
現場でよく使われる構成パターンを紹介します。
パターンA：2ノード・マルチマスター（推奨）
- 構成： Supplier A ⇔ Supplier B
- 特徴： シンプルで強力。どちらが落ちても読み書き可能。
- 用途： 中小規模〜大規模（数万ユーザー程度）まで幅広く対応。
パターンB：マルチマスター + 読み取り専用スレーブ
- 構成： (Supplier A ⇔ Supplier B) → Consumer C, D, E…
- 特徴： 書き込み負荷と読み取り負荷を分離。
- 用途： 全国の拠点に読み取り専用サーバーを配置したい場合など。
今回は、基本かつ最強の「パターンA（2ノード・マルチマスター）」を構築します。
第4章：実践構築(1) 準備とレプリケーション有効化
それでは実際に構築しましょう。
サーバー2台（ldap01, ldap02）に、第2回の要領で389 DSがインストールされ、同じサフィックス（dc=linuxkoubou,dc=com）でインスタンスが作成されている状態からスタートします。
1. 名前解決とポート開放
お互いのFQDNを解決できる必要があります。
# /etc/hosts (両ノード) 192.168.1.11 ldap01.linuxkoubou.com 192.168.1.12 ldap02.linuxkoubou.com
FirewallでLDAPポートを開放します。
firewall-cmd --add-service={ldap,ldaps} --permanent
firewall-cmd --reload
2. レプリケーション管理者ユーザーの作成
レプリケーションの認証に使われる専用ユーザー（Bind DN）を作成します。cn=Directory Manager を使うこともできますが、セキュリティ上、専用ユーザーを作るのがベストプラクティスです。
# 両ノードで実行 dsconf localhost replication create-manager --name "cn=replication manager,cn=config" --password "ReplPass123!"
3. レプリケーションの有効化
各サーバーを「サプライヤー」として設定し、一意なID（Replica ID）を割り当てます。
Replica IDは重複してはいけません（1〜65535）。
ldap01 (ID: 1) で実行:
 |
本気で学ぶ Linux実践入門 サーバ運用のための業務レベル管理術 新品価格 |
dsconf localhost replication enable --role supplier --replica-id 1 --bind-dn "cn=replication manager,cn=config"
ldap02 (ID: 2) で実行:
dsconf localhost replication enable --role supplier --replica-id 2 --bind-dn "cn=replication manager,cn=config"
これで各サーバーは「レプリケーションする準備」が整いました。
第5章：実践構築(2) アグリーメント作成と初期化
準備ができたら、2台を接続（アグリーメント作成）し、データを同期させます。
1. アグリーメントの作成 (ldap01 -> ldap02)
ldap01に対し、「ldap02へデータを送れ」と指示します。
# ldap01で実行 dsconf localhost repl-agmt create --suffix "dc=linuxkoubou,dc=com" \ --host "ldap02.linuxkoubou.com" --port 389 \ --conn-transport TCP \ --bind-dn "cn=replication manager,cn=config" --bind-passwd "ReplPass123!" \ agmt-to-ldap02
2. アグリーメントの作成 (ldap02 -> ldap01)
逆方向も設定します。
# ldap02で実行 dsconf localhost repl-agmt create --suffix "dc=linuxkoubou,dc=com" \ --host "ldap01.linuxkoubou.com" --port 389 \ --conn-transport TCP \ --bind-dn "cn=replication manager,cn=config" --bind-passwd "ReplPass123!" \ agmt-to-ldap01
3. 初期化（Total Initialization）
アグリーメントを作っただけではデータは同期されません。
最初に一度だけ、片方のデータでもう片方を上書きする「初期化」が必要です。
ここでは ldap01 を正として、ldap02 を初期化します。
# ldap01で実行 dsconf localhost repl-agmt init --suffix "dc=linuxkoubou,dc=com" agmt-to-ldap02
コマンドを実行すると、ldap01の全データがldap02へ転送されます。
ステータスを確認してみましょう。
dsconf localhost repl-agmt status --suffix "dc=linuxkoubou,dc=com" agmt-to-ldap02
Status: 0 (Replica acquired successfully: Total update succeeded) と表示されれば完了です。
第6章：トラブルシューティングと監視
「レプリケーションが動かない！」という時、見るべきポイントは決まっています。
1. ステータスコードの確認
先ほどの repl-agmt status コマンドでエラーコードを確認します。
- Error -1 (Can’t contact LDAP server): 通信エラー。相手のFirewall、ポート番号、名前解決を確認。
- Error 49 (Invalid credentials): 認証エラー。
cn=replication managerのパスワードが間違っている。
2. ログの確認
389 DSのエラーログは非常に詳細です。/var/log/dirsrv/slapd-localhost/errors を tail -f しながら初期化を実行すると、原因が一目瞭然です。
3. コンフリクトエントリの確認
競合解決の結果、敗北したデータは消えるわけではなく、「コンフリクトエントリ（dnに特定のUUIDが付く）」として隠し保存される場合があります。
これが増えすぎるとパフォーマンスに影響するため、定期的にチェックします。
ldapsearch -D "cn=Directory Manager" -W -b "dc=linuxkoubou,dc=com" "nsds5ReplConflict=*"
第7章：障害試験。マスターを停止してみる
構築したら、必ず「壊すテスト」をしましょう。
試験シナリオ
- ldap01を停止する:
systemctl stop dirsrv@localhost - ldap02で更新する:
dsidm localhost user create...でユーザーを追加。 - ldap01を復旧する:
systemctl start dirsrv@localhost - 同期確認: 数秒後、ldap01にもユーザーが追加されているか確認。
これが成功すれば、あなたの構築したシステムは「片肺運転」に耐えうる堅牢なシステムであると証明されます。
💡 プロのノウハウ：ロードバランサー (LB)
マルチマスター構成では、クライアントがどのサーバーに接続するかを制御するために、ロードバランサー（HAProxyやF5など）またはDNSラウンドロビンを使用します。
ただし、アプリケーションによっては「書き込み直後に読み込むとデータがない（同期遅延）」問題が起きるため、LBの設定で「特定ユーザーは同じサーバーに維持する（スティッキーセッション）」等の工夫が必要になる場合があります。
まとめ：可用性は設計と訓練から生まれる
お疲れ様でした！
第5回は、389 DSのマルチマスターレプリケーション構築について解説しました。
今回の重要ポイント：
- 389 DSはマルチマスター構成（MMR）が標準であり、設定も容易。
- CSNによる競合解決ロジックにより、データの整合性が保たれる。
- アグリーメントは双方向に張る必要がある。
- 時刻同期（NTP）はレプリケーションの命綱である。
これで、ハードウェア障害が起きても止まらない認証基盤が完成しました。
しかし、可用性が高くても、通信が「平文」ではセキュリティ的に失格です。
次回は、LDAP通信を暗号化し、盗聴リスクから守るためのTLS/SSL化について学びましょう。
次回、第6回は「セキュリティ強化。自己署名証明書の撤廃とTLS完全化」です。
インストール時に作成された自己署名証明書を、Let’s Encryptなどの信頼できる証明書に入れ替え、平文通信（ポート389）を完全に無効化する手順を解説します。お楽しみに！
▼ HA構成を実験する ▼
複数台サーバーで検証
「おすすめVPS」
可用性設計のエキスパートへ
「ITエンジニア転職」
コメント