390.1 OpenLDAPのレプリケーション
主題390：OpenLDAP の設定
390.1 OpenLDAPのレプリケーション
LinuC300の試験範囲である主題390～397まであるうちの「主題390：OpenLDAP の設定」から「390.1 OpenLDAPのレプリケーション」についてのまとめ
重要度：3
説明：
OpenLDAPで利用可能なサーバのレプリケーションに習熟していること。主要な知識範囲：
- レプリケーションの概念
- Open LDAPのレプリケーションの設定
- レプリケーション ログファイルの分析
- レプリカ ハブの理解
- LDAPの参照
- LDAP同期のレプリケーション重要なファイル、用語、ユーティリティ：
- マスターサーバとスレーブサーバ
- マルチマスターレプリケーション
- コンシューマー
- レプリカハブ
- ワンショットモード
- referral
- syncrepl
- PULL型レプリケーションとPUSH型レプリケーション
- refreshOnlyとrefreshAndPersist
- replog
～レプリケーション関連の用語～
ディレクトリサービス
ユーザーID、パスワード、設定情報など様々な情報を格納し検索できる仕組みのこと。
OpenLDAPのほか、389 Direcotry Server、Apache Directory Server、ActiveDirectory などが挙げられる。DIT
Directory Information Treeの略で、LDAPで管理するツリー構造のデータのこと。DN
Distinguished Nameの略で識別名とも呼ばれる。
大文字/小文字の区別はされない。プロバイダ(サプライヤ)
OpenLDAPの冗長構成でマスターとなるLDAPサーバーのことコンシューマ
OpenLDAPの冗長構成でスレーブとなるLDAPサーバーのことプッシュ/push型、リスニング型
プロバイダからコンシューマにデータを送信するタイプ。
slurpdがこのタイプに相当する。プル/pull型、ポーリング型
コンシューマがプロバイダからデータを取ってくるタイプ。
syncreplがこのタイプに相当する。オーバーレイ
OpenLDAPの機能を拡張するもの
レプリケーションを実現するsyncprov、syncreplなどがあるバックエンド
OpenLDAPのデータベース
bdb、hdb：OpenLDAP2.4まで
mdb：OpenLDAP2.4から実装され、OpenLDAP2.5からmdbのみ
mdbはチューニングが不要＝DB_CONFIGが不要slurpd(～OpenLDAP2.3)
ディレクトリを複製するPULL型のレプリケーション機能。
OpenLDAP2.4で削除されている。ワンショットモード
slurpdによるレプリケーションで使われるモード。
同期処理を1回だけ行う。replog
slurpdによるレプリケーションで使われるログファイル。syncrepl(OpenLDAP2.2～)
LDAP Sync(LDAP Content Synchronization Protocol)を使った同期レプリケーションを実現するPULL型のレプリケーション機能。syncprov(OpenLDAP2.3～)
オーバーレイの一種で、同期レプリケーションでプロバイダ側で設定する。refreshOnly
syncreplでコンシューマがプロバイダに対して定期的に更新情報の有無を確認し、更新があればコンシューマがプロバイダから更新情報を取得する。refreshAndPersist
syncreplでプロバイダとコンシューマ間で常時接続され、プロバイダへの更新がリアルタイムにコンシューマに反映される。レプリカハブ
プロバイダから受け取った更新処理を他のコンシューマに伝達する。referral
LDAPのツリー構造を分割し管理を分散させる機能。
レプリケーションの概念
OpenLDAPはユーザー情報を扱うディレクトリサービスを実現するオープンソースソフトウェアで、ディレクトリサービスのプロトコルとしてはLDAP(Lightweight Directory Access Protocol)を実装している。
OpenLDAPは多種多様なシステムへのログイン情報を一元管理することができることから、システムトラブルでログインできなくなるようなことがないようレプリケーションなどの冗長構成とするのが望ましい。
～OpenLDAPの冗長構成～
OpenLDAPの冗長構成はレプリケーション機能で実現できる。
レプリケーションにはいくつか種類がある。
slurpd(～OpenLDAP2.3)
ディレクトリを複製するPUSH型のレプリケーション機能。
OpenLDAP2.4で削除されている。同期レプリケーション(OpenLDAP2.2～)
syncreplによるレプリケーション。
プロバイダ→コンシューマという関係性で、更新処理ができるのはプロバイダのみ。
シングルマスターレプリケーションとも呼ばれている。デルタ同期レプリケーション(OpenLDAP2.3～)
syncreplによるレプリケーション。
変更履歴を利用して差分同期ができるレプリケーション。ミラーモードレプリケーション(OpenLDAP2.4～)
syncreplによるレプリケーション。
それぞれのOpenLDAPサーバーがプロバイダかつコンシューマとなっている構成で、どちらが更新されてもデータの同期が取られる。
しかし、複数のサーバーに同時に更新処理が発生した場合は正しく同期される保証はないため更新処理は一貫していずれか一つのプロバイダにする必要がある。
このことから完全なマルチマスターではなく、アクティブ/アクティブやホットスタンバイと呼ばれる。
検索はDNSラウンドロビンやロードバランサーなどで通信を分散させることができるが、更新処理は分散させてはいけない。マルチマスターレプリケーション(OpenLDAP2.4～)
syncreplによるレプリケーション。
公式ドキュメントには「N-Wayマルチプロバイダレプリケーション」と表現されている。
それぞれのOpenLDAPサーバーがプロバイダかつコンシューマとなっている構成。
更新処理はどのサーバーでも対応可能なので、検索も更新処理もDNSラウンドロビンやロードバランサーなどで通信を分散させることができる。プロキシレプリケーション(OpenLDAP2.4～)
syncreplによるレプリケーション。
OpenLDAPのレプリケーションはコンシューマから要求をきっかけに実現するPULL型であるため、コンシューマからの通信がファイアウォールなどによって制限がされている場合はレプリケーションできない。
そのような時にプロキシ(代理)で更新処理を中継することでレプリケーションを可能にする。
プロバイダ --- プロキシ --- コンシューマ という構成となり、プロキシはプロバイダに対してPULL型で動作し、コンシューマに対してPUSH型で動作する。
OpenLDAPのレプリケーションの設定
～同期レプリケーション～
設定のポイント
プロバイダ側でsyncprovを有効化する。
コンシューマ側で同期に関連する設定をする。
設定方法
別記事『Appendix OpenLDAP 同期レプリケーション』参照
～ミラーモードレプリケーション～
設定のポイント
プロバイダもコンシューマもほぼ同じ設定。
serverIDを重複しないように割り当てる。
ridには相手のserverIDを指定する。
providerには相手のサーバーアドレスを指定する。
olcMirrorMode(olcMultiProvider)を有効化する。
設定方法
別記事『Appendix OpenLDAP ミラーモードレプリケーション』参照
レプリケーション ログファイルの分析
replog：
更新処理の履歴が記録されており、slurpdでの同期処理に使われていた。
slurpdはOpenLDAP2.4で廃止され、syncreplに置き換わっている。
(参考資料)
・OpenLDAP 2.2 Administrator's Guide: Replication with slurpd
(補足)
slurpdは廃止された機能でありLinuC300では試験範囲ではないので解説は割愛する。
レプリカハブの理解
・・・調査中・・・
カスケードレプリケーションのシナリオでは、ハブとなる 1 台のサーバーがコンシューマーとサプライヤーの両方のロールを果たします。ハブは、変更ログを維持する読み取り専用のレプリカです。サプライヤーから更新を受け取り、これらの更新をコンシューマーに提供します。カスケードレプリケーションは、負荷の高いトラフィックのバランスをとる場合や、地理的に分散した環境でサプライヤーをローカルに配置する場合に使用します。
Replica - a server participating in replication. A replica may be a supplier, a hub, or a consumer. Only suppliers are writable by regular LDAP clients. The current version of the server supports 4 suppliers. Hubs and consumers may only be updated by another replica. The only difference between a hub and a consumer is that a hub is both a consumer (from suppliers or other hubs) and a supplier (to other hubs or consumers). Hubs are typically used for load balancing and fail-over.
--- ↓ Google翻訳 ↓ --
レプリカ - レプリケーションに参加するサーバー。レプリカは、サプライヤー、ハブ、またはコンシューマーである可能性があります。通常のLDAPクライアントが書き込みできるのはサプライヤーのみです。サーバーの現在のバージョンは 4 つのサプライヤーをサポートしています。ハブとコンシューマは、別のレプリカによってのみ更新できます。ハブとコンシューマの唯一の違いは、ハブが (サプライヤまたは他のハブからの) コンシューマでもあり、(他のハブまたはコンシューマへの) サプライヤでもあることです。ハブは通常、負荷分散とフェイルオーバーに使用されます。
レプリカハブというキーワードはOpenLDAPでは出てこないがプロキシレプリケーション(OpenLDAP2.4～)がこれに該当するのかもしれない。
LDAPの参照
referral機能を使うことで分散管理が可能になる。
Q. 分散ディレクトリの動きについて説明して欲しい。
LDAPの分散ディレクトリは、「紹介(Referral)」機構により実現されています。 Referralとは、 クライアントの要求を受け取ったサーバが「その要求は他のサーバで行ってほしい」と別のサーバを紹介する仕組みです。
設定のポイント
上位ドメインを管理するLDAPサーバーでは、下位ドメインを定義しreferral設定で下位ドメインを管理しているLDAPサーバーを定義する
下位ドメインを管理するLDAPサーバーでは、グローバル設定(cn=config)に上位ドメインを管理しているLDAPサーバーを定義する。
設定方法
別記事『Appendix OpenLDAP referral』参照
LDAP同期のレプリケーション
syncreplによる同期レプリケーションは、変更操作はプロバイダ側で実施し、コンシューマ側はプロバイダ側に変更があるかを問い合わせて、変更があればデータをプロバイダから取得するPULL型の仕組み。
また、同期レプリケーションにはrefreshOnlyとrefreshAndPersistsyncreplのモードがある。
refreshOnly
syncreplでコンシューマがプロバイダに対して定期的に更新情報の有無を確認し、更新があればコンシューマがプロバイダから更新情報を取得する。refreshAndPersist
syncreplでプロバイダとコンシューマ間で常時接続され、プロバイダへの更新がリアルタイムにコンシューマに反映される。