10. slurpd を利用した複製

構成によっては、単一の slapd(8) で LDAP でのディレクトリサービスを要求するクライアントの数を処理しきれないこともあります。そのような状況では複数の slapd が必要になります。たとえば、多くのサイトには複数の slapd サーバがあります。その一つはマスタで、その他のものはスレーブです。 DNS で ldap.example.com を検索すると、これらのサーバ (あるいはスレーブだけ)の IP アドレスを返すように DNS を設定して負荷を分散するようにできます。このマスタ/スレーブの配置は、性能、可用性、信頼性を向上する単純で効果的な方法を提供します。

slurpd(8)は、先に述べたマスタ/スレーブ複製機構を実現して、マスタの slapd からスレーブの slapd に変更を伝播する機能を提供します。slurpd はマスタの slapd と同じホストで動作します。

10.1. 概要

slurpd(8) は「帯域内(in band)」で複製サービスを提供します。すなわち、マスタのデータベースからスレーブのデータベースを更新するのに LDAP プロトコルを使います。おそらく、これを示す一番簡単な方法は例題です。この例で、LDAP クライアントによる最初の LDAP 更新操作からの伝播がスレーブの slapd に広がる様子を追っていきます。

サンプルの複製のシナリオ：

LDAP クライアントは LDAP 更新操作をスレーブの slapd に送る。
スレーブの slapd は、マスタの slapd を参照するよう LDAP クライアントに紹介(referral)を返す。
LDAP クライアントはマスターの slapd に LDAP 更新操作を送る。
マスターの slapd は更新操作を行い、複製ログファイルに変更内容を書き出して、クライアントに成功を示すコードを返す。
slurpd プロセスは、複製ログファイルに新しいエントリが追加されていることを検出して、複製ログのエントリを読み、LDAP でスレーブの slapd に変更内容を送る。
スレーブの slapd は更新操作を行い、slurpd プロセスに成功を示すコードを返す。

10.2. 複製ログ

複製ログファイルを作成するように slapd を設定すると、 LDIF 変更レコードを含んだファイルが出力されます。この複製ログは、複製サイト、時刻印、更新されたエントリの DN、実際の変更を指定する行の並びを与えます。次の例で、 Barbara (uid=bjensen)は description の値を置換されます。この変更は slave.example.net で動作している slapd に伝えられます。modifiersName や modifyTimestamp のような運用属性(operational attribute)の変更も変更レコードに記録され、スレーブの slapd に伝えられます。

        replica: slave.example.com:389
        time: 809618633
        dn: uid=bjensen,dc=example,dc=com
        changetype: modify
        replace: multiLineDescription
        description: A dreamer...
        -
        replace: modifiersName
        modifiersName: uid=bjensen,dc=example,dc=com
        -
        replace: modifyTimestamp
        modifyTimestamp: 20000805073308Z
        -

運用属性 modifiersName と modifyTimestamp の更新は、マスタの slapd によって追加されたものです。

10.3. コマンドラインオプション

この節では、slurpd(8) のよく使われるコマンドラインオプションについて詳説します。

        -d <level> | ?

このオプションは slurpd のデバッグレベルを <level> に設定します。レベルが `?' 文字の場合、さまざまなデバッグレベルを表示し、他のオプション指定を無視して slurpd は終了します。現在サポートされているデバッグレベルには次のものがあります(slapd のデバッグレベルのサブセットになっています)。

表10.1: デバッグレベル
レベル	説明
4	詳細なデバッグトレース
64	設定ファイルの処理
65535	すべてのデバッグレベルを有効にする

デバッグレベルは加算して指定できます。すなわち、詳細なデバッグトレースと設定ファイルの処理の観察を行いたければ、レベルをその二つのレベルの合計に設定すればよいのです(この場合は 68)。

        -f <filename>

このオプションは、slapd の設定ファイルを明示します。 slurpd は自分の設定ファイルを持っていません。代わりに、すべて設定情報は slapd の設定ファイルから読み込みます。

        -r <filename>

このオプションは slapd 複製ログファイルを明示します。通常の環境において、slurpd は slapd 設定ファイルから slapd 複製ログファイルの名前を読み取ります。しかし、これを -r フラグで上書きして、slurpd が違う複製ログファイルを処理するようにできます。このオプションの利用方法については高度な slurpd の操作を参照してください。

-o

「ワンショット(one-shot)」モードの操作を行います。通常の環境において slurpd は、複製ログファイルの処理を終得た後も活動を続け、複製ログに新しいエントリが追加されたかを定期的に監視します。ワンショットモードになっていると、対象的に slurpd は複製ログを処理するとすぐに終了します。オプション -o を与える場合には、オプション -r で複製ログファイルも明示しなければなりません。このモードについては高度な slurpd の操作を参照してください。

        -t <directory>

複製ログの一時的なコピーを置くディレクトリを明示します。デフォルトでは /usr/tmp に置かれます。

10.4. slurpd とスレーブ slapd の設定

複製の slapd を立ち上げるには、データベースのコピーが行われるように複製のためのマスタとスレーブの slapd の実体を設定しなければなりません。設定が終ったらマスタの slapd をシャットダウンします。最後に、マスタの slapd の実体、スレーブの slapd の実体、slurpd の実体を立ち上げます。この手順について詳しくは以降の節で説明します。望むなら多くのスレーブ slapd を設定することもできます。

10.4.1. マスタ slapd の設定

以降の節では、既に適切に動作している slapd(8) があるものとします。この動作している slapd(8) を複製のマスタにするためには、slapd.conf(5) に対して次の変更が必要です。

個々の複製について replica ディレクティブを追加します。パラメータ binddn= は、該当するスレーブ slapd の設定ファイルにある updatedn ディレクティブと一致させるようにしてください。また、この DN はスレーブのデータベースに対して書き込み権のあるものにしてください(スレーブ slapd の設定ファイルにある rootdn ディレクティブに指定されているエントリや access ディレクティブでアクセスが許可されているエントリなど)。
replogfile ディレクティブを追加します。これは変更を記録するところを slapd に知らせます。このファイルに記録された変更は slurpd が読み取ります。

10.4.2. スレーブ slapd の設定

スレーブ slapd サーバにするホストに slapd ソフトウェアをインストールしてください。スレーブサーバの設定は次にあげる点を除いてマスタの設定と同じにしてください。

replica ディレクティブは入れないでください。複製の「連鎖」は可能ですが、ほとんどの場合においてこれは不適当です。
replogfile ディレクティブは入れないでください。
updatedn ディレクティブを入れてください。このディレクティブで与える DN は、マスタ slapd の設定ファイルにある replica ディレクティブの binddn= パラメータに与えられている DN と一致させるようにしてください。
updatedn ディレクティブに指定した DN がデータベースに対する書き込み権を持つようにしてください(rootdn ディレクティブに指定されているものや access ディレクティブのどれかでアクセスが許可されているものなど)。
スレーブが更新要求を受け付けたときに返す URL を定義するために updateref ディレクティブを使ってください。

10.4.3. マスタ slapd のシャットダウン

スレーブを最初に立ち上げるときにマスタと全く同じデータを持っているようにするために、まずはマスタ slapd をシャットダウンしなければなりません。シャットダウンするには、マスタ slapd のプロセスに kill -INT <pid> で割込みシグナルを送ります。ここで <pid> はマスタ slapd プロセスのプロセスIDです。

データベースのコピーを用意する間に、マスタ slapd を読取り専用モードで運用しておくこともできます。このモードで運用している間にクライアントがデータを更新しようとすると、マスタ slapd は "unwilling to perform" エラーを返します。

10.4.4. マスタ slapd のデータベースのスレーブへのコピー

マスタのデータベースをスレーブにコピーします。 LDBM ベースのデータベースを使っている場合、 slapd.conf(5) の directory ディレクティブで指定されているディレクトリにあるすべてのデータベースファイルをコピーしなければなりません。データベースファイルは利用する基盤のデータベースパッケージによって接尾辞が違います。現時点でありえるものは次のとおりです。

表10.2: データベースファイルの接尾辞
接尾辞	データベース
`dbb`	Berkeley DB B-tree バックエンド
`dbh`	Berkeley DB hash バックエンド
`gdbm`	GNU DBM バックエンド

一般には slapd(8) で使わないファイルなど知らないでしょうから、 directory ディレクティブに指定したデータベースにあるファイルをすべてコピーするとよいでしょう。

注記：ここで言うコピー処理は、同様に構築/インストールされた OpenLDAP サーバを利用することを前提にしています。

10.4.5. 複製のためのマスタ slapd の設定

slapd が複製ログファイルを生成するように設定するには、マスタ slapd の設定ファイルに " replica" ディレクティブを追加します。たとえばホスト slave.example.com で動作する slapd に変更を伝播したいのであれば次のように設定します。

        replica host=slave.example.com:389
                binddn="cn=Replicator,dc=example,dc=com"
                bindmethod=simple credentials=secret

この例ではポート 389 (標準の LDAP ポート)に変更が送られます。 slurpd プロセスは "cn=Replicator,dc=example,dc=com" としてスレーブ slapd にバインドします。このバインドは簡易認証で行われ、パスワードに "secret" を使います。このバインド操作が成功するように、binddn= に与える DN は、スレーブのデータベースに存在していなければなりません(またはスレーブ slapd の設定ファイルに指定されている rootdn にしなければなりません)。また、この DN はスレーブの slapd.conf(5) に定義されているデータベースの updatedn ディレクティブに指定されていなければなりません。

注記：強固な認証と転送セキュリティの利用を強く勧めます。

10.4.6. マスタ slapd の再起動とスレーブ slapd の起動

マスタ slapd プロセスを再起動します。複製ログの生成を確認するために、データベース中のエントリを更新して、データがログファイルに書き出されていることを確認してください。

10.4.7. slurpd の起動

slurpd プロセスを起動します。slurpd はテストで行った更新を直ちにスレーブの slapd に送るでしょう。更新が送られたかを確認するためにスレーブ slapd のログファイルを調べてください。

        slurpd -f <masterslapdconfigfile>

10.5. 高度な slurpd 操作

10.5.1. 複製エラー

slurpd がスレーブ slapd に変更を伝播してエラーの返却コードを受け取ると、エラーの理由と複製レコードを拒絶ファイルに書き出します。拒絶ファイルは、それぞれの複製ログファイルと同じディレクトリにあります。拒絶ファイルの名前は複製ログファイルの名前に接尾辞 ".rej" がついたものです。たとえばホスト slave.example.com のポート 389 で動作する複製サーバについて拒絶ファイルができたとすると、その名前は次のようになります。

        /usr/local/var/openldap/replog.slave.example.com:389.rej

拒絶ログに書き出されたエントリの例を次に示します。

        ERROR: No such attribute
        replica: slave.example.com:389
        time: 809618633
        dn: uid=bjensen,dc=example,dc=com
        changetype: modify
        replace: description
        description: A dreamer...
        -
        replace: modifiersName
        modifiersName: uid=bjensen,dc=example,dc=com
        -
        replace: modifyTimestamp
        modifyTimestamp: 20000805073308Z
        -

これは、元の複製ログのエントリそのものですが、エントリの前に ERROR 行がつくことに注意してください。

10.5.2. ワンショットモードと拒絶ファイル

拒絶ログは slurpd を「ワンショット(one-shot)」モードで使うことによって処理できます。slurpd は通常のモードにおいて更新ログファイルに追加される複製レコードを監視します。対照的にワンショットモードで slurpd は単一のログファイルを処理して終了します。slurpd は複製ログのエントリの始めにある ERROR 行を無視するので、拒絶ファイルを処理する前に ERROR 行を取り除いておく必要はありません。

/usr/local/var/openldap/replog.slave.example.com:389 and exit, use the command ワンショットモードを使うには、コマンドライン引数として -r フラグに拒絶ログファイルの名前を指定し、-o フラグでワンショットモードを指定します。たとえば拒絶ファイル /usr/local/var/openldap/replog.slave.example.com:389 を処理して終了するには、次のようにコマンドを使います。

        slurpd -r /usr/tmp/replog.slave.example.com:389 -o