【OpenLDAP基本講座 第7回】レプリケーション。Syncreplによる冗長化構成と障害に強いインフラ構築

「サーバーが燃えました」で、業務を止めないために。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、通信の暗号化（TLS/SSL）を行い、セキュリティを強化しました。
これで「盗聴」には強くなりましたが、まだ解決していない大きなリスクがあります。

それは「可用性（Availability）」です。
もし、今動いているLDAPサーバーのハードディスクがクラッシュしたら？ 電源ユニットが爆発したら？
その瞬間、全社員がPCにログインできなくなり、メールも見れず、VPNも繋がらなくなります。
いわゆる SPOF（Single Point of Failure：単一障害点） です。

本記事では、OpenLDAPにおけるレプリケーションの仕組み、Provider（マスター）とConsumer（スレーブ）の構築手順、そして同期が壊れた際のリカバリ方法までを徹底解説します。

---

第1章：Syncreplの基礎理論。ProviderとConsumer

構築を始める前に、OpenLDAPのレプリケーション方式である Syncrepl の仕組みを理解しましょう。
昔のOpenLDAP（slurpd 時代）とは全く別物になっています。

役割の定義

• Provider (Master): データの「原本」を持つサーバー。書き込み（更新）はここに行います。
• Consumer (Slave): データの「複製」を持つサーバー。Providerからデータをもらいます。基本的には読み取り専用です。

同期モード：refreshAndPersist

Syncreplには主に2つのモードがあります。

1. refreshOnly: 定期的にポーリングして変更を確認する（cronのような動き）。リアルタイム性に欠ける。
2. refreshAndPersist: 接続を張りっぱなしにし、変更があった瞬間にProviderが通知する（プッシュ通知のような動き）。

認証基盤としては、パスワード変更などが即座に反映されてほしいので、通常は refreshAndPersist を使用します。

---

第2章：環境準備と初期同期の重要性

今回は2台のサーバーを用意します。

• LDAP01 (Provider): 192.168.1.10 (構築済み)
• LDAP02 (Consumer): 192.168.1.11 (新規構築、OSインストール直後)

前提条件

1. 両サーバーで名前解決ができること（/etc/hosts または DNS）。
2. FirewallでLDAPポート (389, 636) が相互に疎通できること。
3. 重要： LDAP02にもOpenLDAPパッケージをインストールし、cn=config の初期設定（第2回〜第3回参照）までは完了させておくこと。
   ただし、ユーザーデータ（ou=Peopleなど）は空のままでOKです。

初期データのコピー (slapcat / slapadd)

Syncreplは空の状態からでも全データを同期できますが、データ量が多い場合や、スキーマ整合性を確実にするために、最初はバックアップファイルで同期を取るのが鉄則です。

1. LDAP01でダンプ取得

slapcat -n 2 -l initial_data.ldif

※ -n 2 はメインDBの番号（環境による）。cn=config を確認してください。

2. ファイルをLDAP02へ転送

scp initial_data.ldif root@192.168.1.11:/root/

3. LDAP02でリストア

systemctl stop slapd
rm -rf /var/lib/ldap/* # 既存DBをクリア
slapadd -n 2 -l /root/initial_data.ldif
chown -R ldap:ldap /var/lib/ldap
systemctl start slapd

これで、スタートラインが揃いました。

---

第3章：Provider（マスター）側の設定

Provider側には、「同期リクエストを受け付ける機能（Overlay）」を追加します。
syncprov (Sync Provider) モジュールを使用します。

1. syncprovモジュールのロード

まず、モジュールがロードされているか確認し、なければロードします。

# mod_syncprov.ldif
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

ldapmodify -Y EXTERNAL -H ldapi:/// -f mod_syncprov.ldif

2. Overlayの設定

メインのデータベース（olcDatabase={2}mdb）に対して、syncprovオーバーレイを被せます。
これにより、このDBへの変更操作が監視され、Consumerに通知されるようになります。

# overlay_syncprov.ldif
dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
# チェックポイント: 100操作または10分ごとに同期状態を保存
olcSpCheckpoint: 100 10
# セッションログ: 短時間の切断時に差分同期するためのログサイズ
olcSpSessionlog: 100

ldapadd -Y EXTERNAL -H ldapi:/// -f overlay_syncprov.ldif

---

第4章：Consumer（スレーブ）側の設定

Consumer側には、「どのサーバーから」「どのユーザーで」「どうやって」データを取得するかを設定します。
olcSyncrepl 属性を使います。

Syncrepl設定LDIFの作成

LDAP02（Consumer）で以下のLDIFを作成します。
※記述が長くなるため、改行やスペースに注意してください。

# consumer_syncrepl.ldif
dn: olcDatabase={2}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: {0}rid=001
  provider=ldap://192.168.1.10:389
  bindmethod=simple
  binddn="cn=Manager,dc=linuxkoubou,dc=com"
  credentials="PASSWORD"
  searchbase="dc=linuxkoubou,dc=com"
  type=refreshAndPersist
  interval=00:00:00:10
  retry="5 5 300 +"
  timeout=1

パラメータ解説：

• rid=001: レプリカID。Consumer内で一意の数字（最大3桁）。
• provider: MasterのURI。TLSを使う場合は ldaps:// にするか、starttls=yes を追加。
• binddn / credentials: 接続に使うユーザーとパスワード。
• type=refreshAndPersist: リアルタイム同期モード。
• retry="5 5 300 +": 切断時の再接続設定。「5秒おきに5回試行、だめなら300秒おきに無限(+)に試行」。

設定の適用

ldapmodify -Y EXTERNAL -H ldapi:/// -f consumer_syncrepl.ldif

エラーが出なければ、即座に同期プロセスが開始されます。

---

第5章：動作確認とフェイルオーバー

本当に同期されているか確認しましょう。

1. データの追加テスト

LDAP01 (Provider) で実行:

# test_user.ldif を作成して追加
ldapadd -x -D "cn=Manager,..." -W -f test_user.ldif

LDAP02 (Consumer) で確認:

ldapsearch -x -b "dc=linuxkoubou,dc=com" "(uid=test_user)"

追加したユーザーがLDAP02でも検索できれば成功です！
ほぼタイムラグなし（1秒以内）で反映されるはずです。

2. フェイルオーバーの考え方

LDAP01がダウンした場合、クライアント（Webサーバーなど）はLDAP02を見に行く必要があります。
これにはクライアント側の設定で対応します。

/etc/openldap/ldap.conf (クライアント側)

URI ldap://192.168.1.10 ldap://192.168.1.11

このようにスペース区切りで複数のURIを書いておけば、OpenLDAPライブラリ（SSSD含む）は自動的に「生きているサーバー」を選んで接続してくれます。

---

第6章：トラブルシューティング。同期が止まったら？

「ユーザーを追加したのにスレーブに反映されない」。
レプリケーションのトラブルはインフラエンジニアの宿命です。

1. ログの確認

Consumer側のログ（/var/log/slapd.log または journal）を確認します。
syncrepl 関連のエラーが出ていないかチェックします。

• CSN too old: Consumerのデータが古すぎて、Providerの差分ログ（Sessionlog）では追いつけない状態。
• connect failed: ネットワークやFirewallの問題。
• bind failed: パスワード変更などで認証に失敗している。

2. 「CSN too old」からの復旧（再初期化）

長期間停止していたConsumerを復旧させる場合、差分同期ができないことがあります。
その場合は、潔くデータを捨てて全同期し直すのが最短ルートです。

手順:

1. Consumerのslapdを停止。
2. /var/lib/ldap/ の中身を削除（DB初期化）。
3. Providerから最新の slapcat ダンプを取得してコピー。
4. Consumerで slapadd を実行。
5. Consumerのslapdを起動。

Syncrepl設定自体は cn=config に残っているため、DBを入れ替えて起動すれば、最新のデータ＋最新の同期状態で再開されます。

---

まとめ：可用性はインフラの命綱

お疲れ様でした！
第7回は、OpenLDAPのレプリケーション（Syncrepl）について解説しました。

今回の重要ポイント：

• Syncreplの refreshAndPersist モードを使えば、リアルタイム同期が可能。
• Providerには syncprov Overlay、Consumerには olcSyncrepl 設定を入れる。
• 最初の同期は slapcat / slapadd で行うのが確実。
• トラブル時は、無理に直そうとせず「スレーブの再構築（DB入れ替え）」をする方が早い場合が多い。

さて、サーバー側の構築はこれで完成です！
堅牢でセキュアなLDAPクラスターが出来上がりました。
最後は、このサーバーを利用する「クライアント」の設定です。

次回、最終回（第8回）は「クライアント連携と運用。SSSD設定とバックアップ」です。
LinuxサーバーからこのLDAPを使ってログインできるようにし、さらにオフラインでもログインできるキャッシュ機能（SSSD）について解説します。お楽しみに！