OpenLDAP の syncrepl レプリケーション OSC 2007 Hokkaido /NEC ソフトウェア北海道 稲地稔
について 2007 年 4 月 1 日に正式発足 目的 LDAP に関する情報交換 技術情報 イベント情報 人的交流 LDAP 利用の普及促進 活動内容 Web による情報発信 http://www.ldap,jp/ メーリングリストによる情報交換技術セミナー OSC LWC のようなイベントに参加 2
講師紹介 稲地稔 ( いなちみのる ) NEC ソフトウェア北海道社員スタッフ OpenLDAP ドキュメントの翻訳 http://www5f.biglobe.ne.jp/~inachi/openldap/ 著作 2001 年 10 月技術評論社 WEB+DB Press Vol.5 特集 2 社内システム増強計画第 1 章 OpenLDAP と PHP による高速検索社員情報管理システムの作り方 2003 年 8 月技術評論社 OpenLDAP 入門 2006 年 5 月技術評論社 LDAP Super Expert 特集 1 OpenLDAP 2.3 の強化ポイント 3
ディレクトリサービスのレプリケーション ディレクトリサーバのデータを他サーバに自動コピーする機構 高可用性 信頼性 負荷分散のために必要 構成方法 : シングルマスターとマルチマスター シングルマスターレプリケーション クライアント 参照 更新が可能 マスターサーバ コピーは一方向 スレーブサーバ 参照のみ可能 クライアント マルチマスターレプリケーション クライアント 参照 更新が可能 マスターサーバ コピーは双方向 マスターサーバ 参照 更新が可能 クライアント 4
OpenLDAP のレプリケーション 2 種類の異なるレプリケーション方式を提供 両者ともシングルマスターレプリケーション slurpd 方式ミシガン大学の LDAP 処理系から引き継いだ伝統的な方式長い実績 ( 多くの情報 枯れた実装 ) 開発は停滞状態 syncrepl 方式バージョン 2.2 よりサポートされた まだ若い方式少ない実績 ( 情報が不足 ) 活発な開発 5
slurpd 方式のレプリケーション 変更操作の履歴を元に複製 マスターからスレーブへの Push ステートレス ( 相手の状態を関知しない ) クライアント 1 変更要求 slapd 2 変更処理 3 変更要求内容の書出し replog 4 変更要求内容の読込み slurpd 5 変更要求 slapd 6 変更処理 スレーブサーバ マスターサーバ 6
slurpd 方式の問題 syncrepl 登場の背景には slurpd の運用上の問題 スレーブの追加時に マスター DB のコピーが必要 マスターサーバを停止しなければならない スレーブの状態に関知せず更新操作を再現 エラー発生時に不整合が発生する可能性 管理者が手作業で修正するか マスター DB のコピーをやり直し そして ついに バージョン 2.4 で消える運命 7
syncrepl 方式のレプリケーション 拡張した検索操作 (LDAP Sync) による複製 コンシューマ ( スレーブ ) からプロバイダ ( マスター ) を Pull ステートフル ( 相手の状態を反映 ) クライアント 1 変更要求 slapd 2 変更処理 プロバイダ ( マスターサーバ ) 3LDAP Sync 要求 4LDAP Sync 応答 更新のあったエントリ 無変更エントリの UUID and/or 削除エントリの UUID slapd 5syncrepl 応答の反映 コンシューマ ( スレーブサーバ ) 8
LDAP Sync 操作の基本 通常の検索条件 + cookie で複製するエントリを選別 プロバイダ dc=company,dc=com LDAP Sync 要求 検索ベース : dc=company,dc=com 検索範囲 : サブツリーフィルタ条件 : objetcclass=inetorgperson cookie: 20070630023900Z#000000#00#000000 コンシューマ dc=company,dc=com ou=sales ou=development LDAP Sync 応答 ou=sales ou=development uid=0001001 同期 cookie の返却 20070630024032Z#000000#00#000000 uid=0001002 CSN=20070630023912Z#000000#00#000000 uid=0001002 uid=0001001 CSN=20070630024032Z#000000#00#000000 uid=0001001 の CSN は cookie の値より大きい 複製未 uid=0001001 uid=0001002 の CSN は cookie の値より小さい 複製済 CSN: Change Sequence Number 9
CSN (Change Sequence Number) Y Y Y Y M M D D h h mm s s Z # x x x x x x # x x # x x x x x x 日時日時カウントサーバ ID 変更カウント 日時変更のあった日時 ( 標準時 年月日時分秒 ) 日時カウント同一日時での変更順 (16 進数 6 桁 ) サーバ ID 変更したサーバの ID(16 進数 2 桁 未使用 ) 変更カウント同一操作での変更順 (16 進数 6 桁 未使用 ) 10
syncrepl で利用する運用属性 entrycsn エントリの変更時に更新される CSN contextcsn データベースで管理する最大の CSN entryuuid エントリを一意に識別するための UUID (Universal Unique IDentifier) 無変更 削除エントリの通知に利用 (DN は変更できるので一意な ID として使えない ) 11
refreshonly モード プロバイダへの定期的な接続 LDAP Sync 操作の実行 エントリ返却 同期 cookie の返却 プロバイダ コンシューマ 初期データ要求 ( 空 cookie) リフレッシュ要求 変更のあったエントリ返却 無変更 and/or 削除メッセージ同期 cookieの返却 定期的に繰り返し 12
refreshandpersist モード コンシューマが停止するまで LDAP Sync 操作が継続 エントリ返却 リフレッシュ終了 プロバイダ コンシューマ 初期データ要求 or リフレッシュ要求 変更のあったエントリ返却 and/or 削除メッセージ プロバイダに変更がある度に繰り返し 13
glue エントリ syncrepl で複製されないエントリを補完 通常の LDAP 操作では不可視 プロバイダ dc=company,dc=com LDAP Sync 要求 検索ベース : dc=company,dc=com 検索範囲 : サブツリーフィルタ条件 : objetcclass=inetorgperson コンシューマ G dc=company,dc=com ou=sales ou=development 複製するエントリの返却 G ou=sales ou=development G inetorgperson エントリ inetorgperson 以外のエントリ G glue エントリ 14
設定 プロバイダ側 データベース設定に syncprov オーバレイを指定 必要に応じて syncprov 固有のディレクティブを指定 syncprov オーバレイ固有の設定ディレクティブ ディレクティブ syncprov-checkpoint syncprov-sessionlog syncprov-nopresent syncprov-reloadhint 説明 データベースに contextcsn を実際に書き込む間隔を指定デフォルトではサーバ終了までデータベースに書き込まない セッションログに保持できる操作の数を指定デフォルトでは記録しない 無変更エントリの通知が不要かを TRUE/FALSE で指定デフォルトは FALSE cookie が空 あるいは古いときにすべてのエントリを再送するかのフラグを見るかを TRUE/FALSE で指定デフォルトは FALSE 15
設定例 プロバイダ側 # オーバレイをモジュール化している場合はロードが必要 modulepath /usr/local/libexec/openldap moduleload syncprov.la... # データベース設定の開始 database bdb suffix dc=company,dc=com... # syncrepl で利用する運用属性にインデックスをつける index entrycsn,entryuuid eq # syncprov オーバレイの利用を指定 overlay syncprov # セッションログの利用を指定 (100 操作分 ) syncprov-sessionlog 100 16
設定 コンシューマ側 データベース設定に syncrepl ディレクティブを指定 接続情報 + 認証情報 + モード + 検索条件 +α syncrepl ディレクティブのパラメータ rid provider type interval retry パラメータ searchbase filter scope attrs 説明プロバイダから見て一意なIDを3 桁の10 進数で指定プロバイダをLDAP URIで指定 refreshonlyかrefreshandpersistかを指定 refreshonlyの場合の実行間隔を指定 (DD:hh:mm:ss) プロバイダに接続できない場合の再トライ間隔を指定検索ベース検索フィルタ検索スコープ取得する属性 17
設定 コンシューマ側 (2) syncrepl ディレクティブのパラメータ ( 続き ) パラメータ 説明 attrsonly 属性型だけの取得 sizelimit 取得するエントリ数の制限 ( デフォルト無制限 ) timelimit 検索の時間制限 ( デフォルト無制限 ) schemachecking スキーマのチェックをするかをon/offで指定 starttls starttls 拡張操作により通信路を保護する (yesまたはcritical) bindmethod バインド方式をsimpleかsaslのどちらかで指定 binddn simpleバインドの場合のdnを指定 saslmech SASL 認証の認証機構を指定 authcid SASL 認証の認証 IDを指定 authzid SASL 認証の認可 IDを指定 credentials 認証パスワードを指定 realm SASL 認証のレルムを指定 secprops SASL 認証のセキュリティプロパティを指定 18
設定例 コンシューマ側 # データベース設定の開始 database bdb... # syncrepl で利用する運用属性にインデックスをつける index entrycsn,entryuuid eq # コンシューマの設定 (3 分間隔でレプリケーションを実行 ) syncrepl rid=1 provider=ldap://main.company.com type=refreshonly interval=00:00:03:00 searchbase= dc=company,dc=com filter= (objectclass=inetorgperson) scope=sub attrs= * schemachecking=off bindmethod=simple binddn= cn=syncuser,dc=company,dc=com credentials=secret 19
syncrepl に問題はないのか syncrepl にも問題が無いわけではない 多くの問題には回避策または将来的に解決する目処あり 更新差分レプリケーションができない小さな更新でもエントリの全内容が対象 大量の更新では帯域に負荷 Push 型のレプリケーションができないスレーブ側からのアクセスを禁止している FireWall がある場合には syncrepl の適用が困難 他 LDAP サーバ製品にレプリケーションできない LDAP Sync 操作のサポートは ( 現在のところ )OpenLDAP のみ 相変わらずマルチマスター構成にできない 厳密な意味での同期レプリケーションモードが無い 20
syncrepl の応用 delta-syncrepl とPush 型 syncrepl
delta-syncrepl 変更履歴を元にした syncrepl を実現 変更履歴の記録にアクセスログを利用 初期ロード cookie が古い場合は通常の syncrepl を実行 3 変更要求内容の書出し 4LDAP Sync 要求 クライアント 1 変更要求 slapd 2 変更処理 アクセスログ用 DB 5LDAP Sync 応答 変更操作の内容 slapd 7syncrepl 応答の反映 本体 DB プロバイダ 6 通常の syncrepl (4 で cookie が空か古い場合 ) コンシューマ 22
設定 プロバイダ側 ( アクセスログ用 DB) アクセスログ用 DB にも syncprov オーバレイを適用 syncprov-nopresent と syncprov-reloadhint の指定が必須 # アクセスログ用データベース設定の開始 database bdb suffix cn=accesslog... index objectclass,reqstart,reqresult eq # syncrepl で利用する運用属性にインデックスをつける index entrycsn,entryuuid eq # syncprov オーバレイの利用を指定 overlay syncprov # 無変更エントリを返さない syncprov-nopresent TRUE # LDAP Sync 要求の reloadhint フラグを無視しない syncprov-reloadhint TRUE 変更操作の内容を通知できればいいので 無変更エントリの通知は不要 cookie が空や古くても全ロードが起きないように 23
設定 プロバイダ側 ( 本体 DB) 通常の syncrepl と同様に syncprov オーバレイを適用 アクセスログの記録のために accesslog オーバレイを適用 成功した変更操作だけをアクセスログに記録するよう設定 accesslog オーバレイ固有の設定ディレクティブ ディレクティブ logdb logops logold logsucess logpurge 説明 記録するデータベースを suffix で指定 記録する操作の種別を指定変更操作だけを記録するには write を指定 変更前の情報を記録するエントリを検索フィルタで指定 delta-syncrepl では指定の必要なし 成功した操作だけを記録するかを TRUE/FALSE で指定 delta-syncrepl では TRUE を指定 記録の保持期間と 保持期間を超えたエントリを調査する間隔を指定 24
設定例 プロバイダ側 ( 本体 DB) # データベース設定の開始 database bdb suffix dc=company,dc=com... # syncrepl で利用する運用属性にインデックスをつける index entrycsn,entryuuid eq # syncprov オーバレイの利用を指定 overlay syncprov # アクセスログオーバレイの指定 overlay accesslog # アクセスログ用のデータベースを指定 logdb cn=accesslog # 変更操作だけをアクセスログに記録 logops write # 成功した操作だけをアクセスログに記録 logsuccess TRUE # アクセスログ DB を毎日スキャンし 3 日経ったエントリを除去 logpurge 03+00:00 01+00:00 25
設定 コンシューマ側 通常の syncrepl の設定に加え logbase, logfilter, syncdata を指定 # データベース設定の開始 database bdb... # syncrepl で利用する運用属性にインデックスをつける index entrycsn,entryuuid eq # コンシューマの設定 (3 分間隔でレプリケーションを実行 ) syncrepl rid=1 provider=ldap://main.company.com type=refreshonly interval=00:00:03:00 searchbase= dc=company,dc=com filter= (objectclass=inetorgperson) scope=sub attrs= * schemachecking=off bindmethod=simple binddn= cn=syncuser,dc=company,dc=com credentials=secret logbase= cn=accesslog アクセスログに LDAP Sync 要求する際の検索ベース logfilter= (&(objectclass=auditwriteobject)(reqresult=0)) syncdata=accesslog アクセスログに LDAP Sync 要求する際の検索フィルタ Delta-synceplのアクセス情報がアクセスログであることを示す 26
Push 型 syncrepl syncrepl で push 型のレプリケーションを実現 ldap バックエンドと syncrepl を組み合わせた代理サーバを用意 slurpd からの置き換えに有効 他 LDAP 製品へレプリケーションできる可能性も 3contextCSN 問合せ 1 変更要求 4LDAP Sync 操作 slapd slapd slapd クライアント 2 変更処理 6 変更反映 ldapバックエンド プロバイダ マスターサーバ 代理サーバ 5 変更反映の代理操作 スレーブサーバ 27
設定例 プロバイダ側 通常のプロバイダ設定と同様 # データベース設定の開始 database bdb suffix dc=company,dc=com... # syncrepl で利用する運用属性にインデックスをつける index entrycsn,entryuuid eq # syncprov オーバレイの利用を指定 overlay syncprov # セッションログの利用を指定 (100 操作分 ) syncprov-sessionlog 100 28
設定例 スレーブ側 slurpd 方式の場合のスレーブと同様の定義 加えて 更新を許可する DN のためのデータベース定義 # データベース設定の開始 database bdb suffix dc=company,dc=com... # syncreplで利用する運用属性にインデックスをつける index entrycsn,entryuuid eq # 更新を許す DN を指定 updatedn cn=monitor... # 更新を許す DN のための便宜的なデータベース定義 database monitor rootdn cn=monitor rootpw monitor データベースが空でもレプリケーション可能とするために 他 DB の管理者用 DN を利用 29
設定 代理 LDAP サーバ ldap バックエンドデータベースに syncrepl を指定 代理アクセス先にスレーブサーバを指定 # ldap バックエンドデータベース設定の開始 database ldap suffix dc=company,dc=com... # 代理アクセス先にスレーブサーバを設定 uri ldap://slave.company.com # スレーブサーバへのレプリケーションのための認証情報 acl-bind bindmethod=simple binddn= cn=monitor credentials=monitor # コンシューマの設定 (3 分間隔でレプリケーションを実行 ) syncrepl rid=1 provider=ldap://main.company.com type=refreshonly interval=00:00:03:00 searchbase= dc=company,dc=com filter= (objectclass=inetorgperson) scope=sub attrs= * schemachecking=off bindmethod=simple binddn= cn=syncuser,dc=company,dc=com credentials=secret 30
バージョン 2.4 での syncrepl 強化項目 注意 CVS 上の最新開発版ソースを元にした調査であるため実際のリリース版とは異なる場合があります
設定データベースのレプリケーション syncprov オーバレイ syncrepl ディレクティブの指定が可能に より管理が容易になる可能性プロバイダの設定をオンラインで更新 コンシューマへの自動反映スキーマの変更もレプリケーション可能検索条件によりプロバイダ固有の設定をレプリケーションされないようにすることも可能 設定をオンライン変更 設定の変更を自動反映 cn=config cn=config cn=config クライアント プロバイダ cn=config コンシューマ 32
マルチマスターレプリケーション 構成サーバのすべてがプロバイダ & コンシューマ 構成するサーバ間で一意な ID を各サーバに設定 mirrormode ディレクティブによりすべてのサーバが更新可能 1 データベースに複数の syncrepl 指定が可能 N-Way マルチマスター構成が可能 エントリレベルの衝突解決属性レベルの衝突の判定は不可 CSN のフォーマットが変更日時がマイクロ秒単位に 衝突判定の精度向上サーバ ID が 16 進数 3 桁に 更新したサーバの ID を記録 delta-syncrepl のマルチマスター化は不可 2.4 系列の後のほうで可能となる予定 33
エントリ更新の衝突の解決 refreshonly モードの実行間に異サーバで同一エントリを更新 CSN の大きい方を優先して解決 サーバ A refreshonly サーバ B refreshonly サーバ A 14:29 に更新 結果 14:30 に更新 サーバ B サーバ B のエントリの内容で上書き サーバ A のエントリの内容は無視 34
エントリ追加の衝突の解決 refreshonly モード実行間に異サーバで同一 DN のエントリを追加 CSN の大きい方を優先しようとしているが うまくいっていない サーバ A refreshonly サーバ B refreshonly 14:29に追加両方とも削除サーバA サーバB 結果 14:30に追加両方とも残るサーバA サーバB CSN の小さいエントリを無視した結果 大きいほうが削除対象となったもよう UUID の違いをうまく扱えないよう 35
親子関係の衝突の解決 refreshonly モードの実行間に異サーバで同一エントリを更新 CSN の大きい方を優先して解決 サーバ A refreshonly サーバ B refreshonly 追加 サーバ A 結果 削除 サーバ B G G サーバ B での削除により glue 化 glue エントリを補完してエントリを追加 36
まとめ バージョン 2.4 からはレプリケーションに syncrepl が必須 slurpd は消滅 syncrepl は検索操作を拡張した Pull ベースのレプリケーション検索対象とならないエントリは glue エントリで補完 従来の slurpd の利点もほぼ包括可能に delta-syncrepl Push 型 syncrepl バージョン 2.4 からは設定データベースと N-Way マルチマスタ構成のレプリケーションも可能 37
ご静聴ありがとうございました