目次
LDAP システムを運用する上でディレクトリの複製を作成しておくことは高負荷時の負荷分散を行うにも信頼性の高い LDAP 環境を構築する上でも必要不可欠な条件です。しかしディレクトリの更新が日常的に行われるシステムでは、サービスを継続したまま更新内容を複製先に反映させる必要があるため、LDAPサーバと複製サーバ間の整合性をとることが非常に難しくなります。syncbackup は、このような環境でも高い信頼性をもった LDAP 環境を構築できるように LDAPクライアントから送られた更新要求を LDAP サーバと複製 LDAP サーバの両方に同時に書き込みを行う仕組みです。
この方式は、データベースの冗長化を行うためのLDAPに限らない基本的な仕組みです。LDAP以外の他のデータベースシステムではこの方式を同期レプリケーションと呼ぶことが多いのですが、LDAPでは「LDAP SYNC レプリケーション」という用語が既に別の意味で存在するため、混乱を避けるために syncbackup と呼んでいます。
図 1. 「更新要求の同時書き込み」を見てください。syncbackup では LDAP クライアントから送られた更新要求に対して、それを受け取ったサーバが別の複製サーバへ同じ更新要求をそのまま伝搬します。伝搬を受け取った複製サーバはその更新要求を処理し結果をサーバに返します(この時、サーバ自身もその要求を処理します)。伝搬結果を受け取ったサーバはその内容をうけて最終的な結果をクライアントに返します。
syncbackupを用いると、LDAPクライアントに更新要求の成功が返った場合にその更新が複数のLDAPサーバに対して行われた事が確実に保証されます。したがって、更新を行ったLDAPサーバが突然停止した場合でもその更新内容を別の複製サーバから引き続き利用することができます。そして、複製サーバがLDAPサーバのサービスを引き継けば更新サービスも継続して提供することができます。
複製サーバへの更新をサーバへの書き込みと非同期に行う方法もありますが、この方法では、もしそのサーバが停止した時点でその更新の複製が完了していない場合、サーバが復旧するまで更新内容を参照することができません。これは、あるエントリに対して行われた更新に依存した別の新たな更新をしようとする場合に非常に大きな問題になります。例えば、パスワードの更新を行って次にその新しいパスワードを利用してLDAPサーバに接続しようとする場合、パスワードの更新は成功したはずなのに、実際には変わっていないという現象が発生します。また、削除したはずのエントリが削除されないといった問題や、作成したはずのエントリが作成されていないといった問題も発生するようになります。
syncbackupでは、更新を同時に行うために、自分自身への更新を行うと同時に、同じ内容を複製LDAPサーバにLDAPプロトコルを使って伝搬します。そして、サーバは、自分自身と伝搬を行ったサーバの両方から更新の成功が得られた場合のみ、クライアントに成功を返します。これによって、クライアントに成功が返った場合は、自分自身と複製サーバの複数のサーバへの更新が完了している事になります。
また、syncbackup では、複製LDAPサーバ全ての成功を待つことはせずに、 図 2. 「syncbackupの仕組み」に見られるように、少なくとも 1 つの複製LDAPサーバ(この数は変更可能です)から成功が返った時点で、クライアントに成功を返します。この理由は、複製LDAPサーバに遅延が起きたり、そのサーバが停止したりした場合に、それにひきづられてサーバサービス全体に遅延が発生するのを防止するためです。言い替えると、どれか一台の複製サーバが遅延なく正常に成功を返すことができれば、サーバサービス全体の遅延を防ぐことができます。
さて、実際にLDAPサーバが停止した場合に、どのようにサービスを継続するか見ていきます。今までクライアントからの要求を受け付けていたLDAPサーバ(これをマスタサーバと呼びます)は既に停止していますので、そのサービスを別の複製LDAPサーバ(通常の複製サーバと区別するために、このサーバをバックアップサーバと呼びます)が引き取る 必要があります [1]。
syncbackupでは、バックアップサーバを、「データの複製が完了しているもの」と「遅延が発生しているもの」の二種類のサーバに分類することができます。マスタサーバは全てのサーバの中で常に最新の状態になっている必要がありますので、マスタサーバに昇格するサーバはデータの複製が完了しているものでなければいけません。
syncbackupは、この作業を行うのにバックアップサーバの中から複製が完了しているサーバを探すのではなく、あらかじめマスタサーバへ昇格するサーバを決定し、そのサーバを最新の状態に追従してから、マスタサーバサービスを開始します。これは以下のように行います。
syncbackupでは、最新状態を保持するバックアップサーバがバックアップサーバ群のどこかに存在するはずです。そこで、マスタサーバ昇格の際に、他のバックアップサーバに問い合わせを行って、自分より新しい更新を保持している場合は、その更新を取り寄せます。全てのバックアップサーバから更新を取り寄せれば、そのサーバは最新の更新状態になることができます。
ただし、複数のサーバに確実に更新が行われても、その全てのサーバが同時に 停止した場合、その更新内容を参照することはできないことに注意してください。もし、この現象が発生した場合、更新内容は停止したサーバが復旧するまで取り出す事はできません。
syncbackupがこのような引き継ぎ方式をとる理由は主に三つあります。一つは、マスタサーバの決定方式を不確定要素に依存しないようにすること、二つ目は、どのバックアップサーバもシステム管理者の判断で任意の時点でマスタサーバに昇格できるようにすること、そして三つ目は、サーバ二台間の引き取りしかサポートしていない引き取り自動プログラムでも syncbackup を利用可能にするためです。
この内、一つ目の不確定要素とは以下のような要素です。syncbackupではマスタサーバはバックアップサーバの中から最も早く返事のあったサーバのみを同時更新のサーバとして管理します。この最も早くという現象は、ネットワークの負荷や、ストレージに遅延が発生するというような不確定要素に基づいて決まります。したがって、最新のバックアップサーバを新しいマスタサーバとしてしまうと、不確定要素が原因で、毎回そのサービスを引き継ぐバックアップサーバが変わってしまいます。このような状況は、システム管理的な立場から見ると障害時の挙動を推測しずらくなるという欠点があり好ましくありません。また、それぞれのバックアップサーバで、それぞれ性能面、信頼面に差がある場合、サービスを引き継ぐ順序をあらかじめ決定しておきたいことがあります。不確定要素に依存すると、本来は総合面で信頼性が高いはずのバックアップサーバが、停止時にたまたまおきた確率の低い遅延によってマスタサーバにならず、たまたまうまく動いた信頼性の低いバックアップサーバ側にマスタサーバのサービスが引き継がれてしまうということも起こりえますので、最新の更新状態にあるサーバのみをマスタサーバの候補とするのは問題があります。
ただし、この方式の場合、新マスタサーバの候補となるサーバのディレクトリを最新の状態に追従するまで、マスタサービスを開始できないという欠点があります。したがって、最新状態に追従する時間をどれだけ短くできるかが引き継ぎ時間を短くできる最大のポイントになります。現在の syncbackup はディレクトリを最新状態に追従するために、LDAP SYNC レプリケーションという複製プロトコルを利用していますので、この LDAP SYNC レプリケー ションの速度が非常に重要になります。
最新の更新状態になったバックアップサーバが新しいマスタサーバになった場合、信頼性の高いディレクトリ更新機能を引き続き提供するには、クライアントから送られた更新要求をバックアップサーバに伝搬する同時更新の機能も継続しなければいけません。しかし、起動したばかりの新しいマスタサーバはバックアップサーバがどういう状態であるかを知りません。またバックアップサーバは元々のマスタサーバに接続していましたので、元々のサーバが停止すると TCP コネクションも切断されてしまいます。したがって、バックアップサーバが再度伝搬を受け付けるようになんらかの対処を行なう必要があります。
syncbackupでは、バックアップサーバがマスタサーバの停止を感知した場合、自分自身にクライアントの更新要求を伝搬してもらうようにマスタサーバに再接続/再要求を行ないます。マスタサーバはバックアップサーバの再接続を受け付けるまで更新をBUSY状態にし、クライアントからの更新要求を受理しません。再接続が完了すれば、BUSY状態を解除し、更新要求を受け付けるようになります。
syncbackupに見られるような、更新が複数のサーバで同時に行われる形式の複製は、LDAPタスクフォースで定義される「トランザクション整合性 (Transactional consistency)」を満足するための必要条件です。syncbackup を使えばすぐにトランザクション整合性が 実現されるわけではありませんが、トランザクション整合性を確保するための基本的な枠組を提供することはできます。
現在実装されているLDAPサーバの多くは、トランザクション整合性は満足しないが「最終的整合性(Eventual consistency)」は満足するというものがほとんどです。最終的整合性とは、複製が完了するまでに、多少のタイムラグが存在するが、最終的には整合性が保証されるものをいいます。最終的整合性は、タイムラグを許容する代わりに、LDAPシステムの複雑性を緩和したり、ディレクトリのキャッシュを効率的に管理したり、広域的なディレクトリの複製を、更新の速度を犠牲にすることなく効率的に構築できるなどの利点がありますが、一方で、LDAPサーバが突然停止した場合に、どのサーバにもその更新の複製が行われていないという可能性があるため、ディレクトリの更新という点に着目すると、信頼性の高いLDAP環境を構築するには完全ではありません。一方、syncbackupは、自分自身の更新とその複製が同時に行われるため、この問題は発生しません。
ただし、syncbackupは、バックアップサーバからの結果を最低1つ待ちますが、その 時点で結果が返っていないサーバに対しては、結果の取得を後で行います。したがって、結果の取得に時間がかかった場合、そのバックアップサーバには更新要求のタイムラグが発生することになります。タイムラグのある複製プロトコルは最高でも最終的整合性しか満足できません。にも関わらず最終的整合性のモデルと同時更新を行うモデルの二つのモデルを組み合わせてある理由は、最終的整合性モデルにはバックアップサーバに遅延が発生した場合でも、その影響をあまり受けないという利点があるからです。また、たとえシステムの一部でタイムラグが発生してもそのシステム全体という枠組ではタイムラグは発生しませんので、それほど大きな問題ではありません。むしろ、バックアップサーバのトラブルにシステム全体が影響を受けない利点のほうが重要です。
最終的整合性を満足する他の複製方式には、例えば「LDAP SYNC レプリケーション」があります。LDAP SYNC レプリケーションは LDAP の検索プロトコルに対する拡張である LDAP 内容同期操作 ( Content Synchronization Operation ) を利用したレプリケーション方式で、サーバに更新が行われた場合、その更新が検索の結果として複製サーバに返却されます。LDAP SYNC レプリケーションは、検索フィルタやベースDN等を使った多彩な設定が指定可能なため、必要な情報だけを保持する複製サーバが容易に作成できます（syncbackupは内部的にLDAP SYNC レプリケーションも利用しています）。LDAP SYNC レプリケーションは OpenLDAP 2.2 以降で利用可能な方式です。
OpenLDAP 2.1 以前にもディレクトリを複製する方式が存在しますが、これは最終 的整合性モデルではありませんし、整合性をとるための枠組もありません。このモデルは「アドホック整合性(ad-hoc consistency)」と呼ばれます。アドホック整合性とは整合性についてどのような考慮もされていないモデルです。アドホック整合性モデルでは、整合性を確保するために運用面で回避する必要があります。例えば複製失敗時に生成されるリジェクトファイルをたよりに、整合性が正しいかどうかをシステム管理者が確認します。
syncbackupは、LDAPv3に準拠した標準プロトコル、およびLDAPv3に準拠した拡張操作、拡張コントロールを用いて実現されており、LDAPv3に準拠したLDAPサーバであれば、プロトコルエラーが発生することはありません。ただし、syncbackup用に新たに定義された拡張操作、拡張コントロールを、そのLDAPサーバがサポートしている必要があります。現在、syncbackup拡張命令をサポートしているLDAPサーバはOpenLDAP 2.2.1beta に syncbackup パ ッチを適用したものしかありませんが、OpenLDAP, syncbackup パッチともオープンソース ライセンスで使用が許諾されていますので、自由に利用することができます。
syncbackupは、現在 OpenLDAP バージョン 2.2.1beta へのパッチ形式で配布されていますが、コンパイル済みのパッケージが Debian GNU/Linux 用に用意されていますので、該当する方は、バイナリ構築作業を省略して syncbackup を使うことが可能です。
syncbackup Debianパッケージは、syncbackup 機能の無い元々のDebianパッケージ全体を置き換えるタイプと、必要なファイルだけに差分を適用する(パッケージに対する差分という意味から)パッケージパッチの二種類あります。置き換えるタイプのパッケージをインストールすると、Debianの元々のパッケージが上書きされます。一方、パッケージパッチ形式のパッケージは、元々のパッケージと変更のあるファイルのみが含まれていて、インストールするとその変更したファイルを利用するようになります。置き換えタイプとパッケージパッチタイプの違いについては付録の置き換えタイプとパッケージパッチを参照してください。
syncbackupを利用するには /etc/apt/sources.list にパッケージ情報が存在する URI を追加します。Debian GNU/Linux 3.0 の場合は
置き換えタイプのパッケージの場合
deb http://未定/ woody/未定/パッケージパッチタイプの場合
deb http://未定/binary-patch/ woody/未定/
を、開発版(sid)の場合は
置き換えタイプのパッケージの場合
deb http://未定/ unstable/未定/パッケージパッチタイプの場合
deb http://未定/binary-patch/ unstable/未定/
を追加してください。
これらの Debianパッケージは、syncbackupパッチに加えて OpenLDAP Issue Tracking System で報告されているバグの修正パッチも含まれています。
woody版では、SASLを利用することができません。woodyでSASLを利用したい場合は、新しいバージョンのSASLライブラリを入手して(開発版にあります)、それを使ってパッケージを再構築する必要があります。
置き換えタイプ用のパッケージと、パッケージパッチタイプのパッケージの対応表を示します。置き換えタイプでは表 1. 「置き換えパッケージ対応表」を、パッケージパッチタイプでは、元々のDebianパッケージ(表 2. 「OpenLDAP 2.2.1beta パッケージ対応表」)とパッケージパッチパッケージ(表 3. 「パッケージパッチパッケージ対応表」)を利用します。
表 1. 置き換えパッケージ対応表
| パッケージ名 | 用途 |
|---|---|
| slapd | syncbackupをサポートしたLDAPサーバ |
| libldap2 | クライアントライブラリ(変更点はありません) |
| libldap2-dev | クライアント開発キット(変更点はありません) |
| ldap-utils | LDAPクライアントツール(変更点はありません) |
| libslapd2-dev | サーババックエンドDB開発キット(変更点はありません)[a] |
[a] 動きません。元々のDebianパッケージでも同様です。 | |
置き換えパッケージの場合は
apt-get install slapd
と実行することで syncbackup に対応した LDAP サーバがインストールされます。ただし、APT のピン止め機能を使っている場合、意図したバージョンがインストールされないことがありますので注意してください。
パッケージパッチパッケージを利用する場合は以下のようにします。
apt-get install slapd-sb
パッケージパッチの依存関係によって、slapd自体も自動的にインストールされます。
表 2. OpenLDAP 2.2.1beta パッケージ対応表
| パッケージ名 | 用途 |
|---|---|
| slapd | LDAPサーバ |
| libldap2 | クライアントライブラリ |
| libldap2-dev | クライアント開発キット |
| ldap-utils | LDAPクライアントツール |
| libslapd2-dev | サーババックエンドDB開発キット[a] |
[a] 動きません。元々のDebianパッケージでも同様です。 | |
パッケージパッチパッケージの場合、パッケージパッチパッケージを削除すると、自動的にDebianの slapd に戻ります。
apt-get remove slapd-sb
Debianのslapdも削除したい場合は明示的に指定してください。
apt-get remove slapd
パッケージを利用しない場合は、OpenLDAP のソースアーカイブ、および syncbackup パッチを入手して、お使いの環境で直接バイナリを構築します。ソースから直接 syncbackup を構築する方法については、未定を参照してください。
これから実際に syncbackup 環境を構築していきますが、その前に syncbackup 環境を構築するのに必要な最小の構成とはどのような構成であるかを考えます。
syncbackup 環境は、一台の LDAP サーバと一台の複製サーバがあれば動作させることはできます。しかし、複製サーバが一台だけしかない場合、LDAPサーバはたった一台の複製サーバが停止するだけでクライアントから受け取った更新要求をどこにも複製することができなくなってしまいます。また、LDAP サーバ自体が停止すれば当然更新要求を受理することができませんから、結果として二台のサーバで構成する syncbackup 環境は LDAP サーバと複製サーバのどちらかが停止するだけで LDAP 更新環境全体を停止させることになります。これでは信頼性があがるどころかかえって低くなってしまい、syncbackupを導入する利点がなくなってしまいます。その点を考慮すると、信頼のある syncbackup 環境を構築するには三台以上のサーバを用意することが必須になります。[2]
ただし、三台以上の冗長構成をとるとシステムが複雑になったり運用コストが割高になってしまったりする問題があります。そこで syncbackup は weaksync というモードを用意して二台構成でもある程度信頼のあるディレクトリ更新環境を構築できるようにしています。 weaksync とは、複製サーバが複製の準備ができていない場合に、マスタサーバが必要とする複製保証の条件を一時的に緩和するものです。例えば、複製サーバが一台しかない環境で、その複製サーバが起動していない時に LDAP サーバにクライアントから更新要求がきた場合、マスタサーバが要求する複製保証の数をその時点で準備が整っている複製サーバの数、この場合は 0 台ですので、複製保証の数を 0 個まで緩和します。複製が 0 個で良いわけですからマスタサーバは複製サーバに複製を行わずに自分自身への書き込みが成功した段階で LDAP クライアントに成功を返します。
これにより、複製サーバが停止しても LDAP サーバが更新要求を受理することができるようにはなるのですが、一方で、更新要求が成功しても複製サーバに複製が行われていない状態が発生するようになります。したがって、もしこの間に LDAP サーバが停止すると、停止直前までに複製できなかった更新要求は LDAP サーバが復旧するまで参照することができなくなりますので注意が必要です。
この場合 LDAP サーバは、処理した要求の複製が行われていないという内容の追加情報を成功レスポンスと一緒にクライアントへ返します。したがって、クライアント側でなんらかの対処をとることは可能ですが、この情報は内容が明確に規定されていない自然言語(英語)であるため、将来の拡張性が高くないという問題があります。
weaksyncモードを利用するか否かは運用の問題です。複製サーバが停止した場合でも、クライアントの要求を受理したい場合は weaksync モードにし、複製を確実に保証したい場合は weaksync モードにはしないようにします。weaksyncモードでない場合で LDAP サーバへ更新要求が来た時に複製サーバの準備ができていない場合は、クライアントに LDAP_BUSY エラーを返し時間をおいて再度行ってもらうよう即すようになります。
まずは、weaksyncモードを利用して、マスタサーバが一台とバックアップサーバが一台のLDAPディレクトリ更新環境を構築してみます。マスタサービスを引き継ぐ設定は他のツールと組み合わせる必要がありますのでここでは行いません。マスタサーバがバックアップサーバへ更新要求を伝搬する環境のみを実現します。なお、syncbackup環境を構築する前に、通常の環境で LDAP サーバが動作するようにしておいてください。
マスタサーバの設定を行うには、slapdの設定ファイル slapd.conf にマスタサーバ用の設定を記述します。
図 4. 「weaksync用のマスタサーバ設定例」は、マスタサーバ用のslapd.confファイルの中から syncbackup に関連する項目を抽出したものです。
現在、syncbackupをサポートするバックエンドデータベースは bdb データベースのみです。他のバックエンドデータベースでは設定を行っても更新要求の伝搬が発生しません。
図 4. weaksync用のマスタサーバ設定例
database bdb
...
syncdn "cn=Manager,<サフィックス>"
weaksync on
replica syncid=backup
host=backup
bindmethod=simple
binddn="cn=Backup,<サフィックス>"
credentials=secret
...
この設定は、指定したデータベースに対して weaksync モードで syncbackup を有効にし、バックアップサーバ backup に対して伝搬を行うようにします。悪意のあるコンピュータに更新要求の伝搬をしないように、伝搬を許可するためのバインドDNを syncdn に記述します。このDNはそのデータベースの内容全てに読み込み権限があるDNにしてください。通常は rootdn にします。
replica設定には、syncidの記述を含めてください。syncidがない場合、このreplica設定は従来の slurpd による複製サーバと解釈されます。syncid はバックアップサーバを識別する一意の ID です。通常はバックアップサーバのホスト名と同じにしておけば問題ありません。ひとつのホストで複数のバックアップサーバを起動する場合は、それぞれ違う ID にします。
将来のsyncbackupではreplica設定ではなく、syncreplicaのような replica 項目とは別の新たな設定項目を作成する予定です。原因は、ディストリビューションの slapd 起動スクリプトの中で slurpd を立ち上げる条件を replica 項目がある場合としていることがあるため、syncbackup用のreplica項目しかない場合にトラブルが発生するからです。
loglevel 256 を指定すると、伝搬の状況が syslog に出力されます。うまく動作しない場合のデバッグや統計情報の生成などに利用できます。
バックアップサーバの設定もマスタサーバと同様にslapd.confに記述します。
図 5. バックアップサーバ設定例
database bdb
...
updatedn "cn=Backup,<サフィックス>"
updateref "ldap://<マスタサーバのアドレス>:389/"
syncbackup syncid=backup
provider=ldap://<マスタサーバのアドレス>:389/
binddn="cn=Manager,<サフィックス>"
bindmethod=simple
credentials=secret
checkinterval=10
...
syncbackupの項目にマスタサーバの内容を記述します。syncid はマスタサーバで管理しているものと同じにする必要があります。先ほど、マスタサーバ側の設定で syncid を backup としましたので、バックアップ側でも同様に backup にします。binddn はマスタサーバの syncdn と同じにします。checkinterval はバックアップサーバがマスタサーバに対して動作チェックを行う時間間隔を秒単位で指定します。この場合は 10 秒単位でマスタサーバの動作チェックを行い、そこでマスタサーバが停止していると判断した場合は、マスタサーバに再接続を試みます。
設定が整ったら、マスタサーバを再起動します。パッケージからインストールしてある場合は
/etc/init.d/slapd restart
を、ソースから直接構築した場合は、いったんバックアップサーバを停止してから
/usr/local/libexec/slapd
を実行してください。
設定が完了したので、syncbackupが動作するか確認してみましょう。weaksyncモードではバックアップサーバを起動しなくても、マスタサーバに更新要求を送ることができます。ldapaddを使って新しいエントリを追加してみましょう。
~$ ldapadd -x -D "cn=Manager,<サフィックス> <<EOF dn: ou=Test,<サフィックス> objectClass: organizationalUnit ou: Test EOF adding new entry "ou=Test,<サフィックス>"
書き込みが成功した場合、マスタサーバのログに以下のような出力があるはずです。
conn=2 op=1 BACKUP DELAYED dn="ou=Test,<サフィックス>"
この出力はdn="ou=Test,<サフィックス>"に対するバックアップが遅延したことを表しています。これは、バックアップサーバが立ち上がっていない状態ですので、マスタサーバが伝搬成功の保証数を緩和した結果です。仮に weaksync でない場合に、同じ作業をした場合は
adding new entry "ou=Test,<サフィックス>" ldapadd: update failed: ou=Test,<サフィックス> ldap_add: Server is busy (51) additional info: not enough backup servers registered
のように、クライアントに LDAP_BUSY が返ってきます。
マスタサーバの動作が確認できましたら、続いてバックアップサーバの動作を確認してみましょう。正常にバックアップサーバが動作すると
conn=1 op=2 STARTSYNC id="backup" \
cookie="(null)" dn="cn=Manager,<サフィックス>"
conn=1 op=2 STARTSYNC ATTACH id="backup"
conn=1 op=2 BACKUP BIND backup="backup"
のようなメッセージがマスタサーバログに出力されます。
ここでエントリを追加すると
conn=6 op=1 ADD dn="ou=Test,<サフィックス>" conn=6 op=1 BACKUP latency=0 backup="backup" conn=6 op=1 RESULT tag=105 err=0 text="
のようなメッセージがマスタログに出力されます。このメッセージは追加要求が backup に遅延なしで伝搬され、クライアントに成功を返した事を表します。バックアップサーバが一台のみの場合は遅延は発生しませんので、latencyの値は常に 0 です。
うまく動作しない場合は設定に問題がある可能性があります。問題が発生した場合は、エラーの内容がマスタサーバのログに出力されます。例えば、マスタサーバの設定でバックアップサーバへのバインドDNのパスワードが間違っていた場合は、
conn=1 op=2 STARTSYNC ATTACH id="backup" ldap_simple_bind: Invalid credentials conn=1 op=2 STARTSYNC SYNCERROR id="backup" err= conn=1 op=2 DETACH id=backup
のように Invalid credentials と SYNCERROR のメッセージがマスタサーバのログに出力されます。
伝搬に関する内容は、conn と op で判別することができます。これらの値は conn=1 op=2 STARTSYNC ATTACH id="backup" のメッセージを見ることでわかります。この場合は ID backup に対する conn は 1 で、op は 2 です。ID backup の伝搬に関する内容には必ず conn=1 op=2 が付加されていますので、ログ解析時に参考にしてください。他の番号を持った出力は違う内容に関するメッセージです。
weaksync 環境が構築できましたので、サーバマシンをもう一台用意して 3 台のサーバによる、より信頼性のある syncbackup 環境を構築します。
まず初めに新しいサーバの同期識別子を決めます。先程の例ではバックアップサーバの同期識別子を backup としていましたが、今度の場合はバックアップサーバが 2 台になりますので同期識別子を backup1 と backup2 にします。
図 6. マスタサーバ設定例
database bdb
...
syncdn "cn=Manager,<サフィックス>"
replica syncid=backup1
host=backup
bindmethod=simple
binddn="cn=Backup,<サフィックス>"
credentials=secret
replica syncid=backup2
host=backup
bindmethod=simple
binddn="cn=Backup,<サフィックス>"
credentials=secret
...
バックアップサーバが増えた場合には単に replica 記述をもう一つ加えるだけです。同じ項目をコピーして syncid を適切な値に編集すれば良いでしょう。今回は weaksync モードではありませんので weaksync on の設定は削除しました。バックアップサーバ側も syncid の値を変更するだけであとの項目は同じものが再利用できます。
A. 付録
ここで紹介しているOpenLDAP Debianパッケージは、元々のDebianパッケージを置き換えるタイプと、パッケージパッチタイプの二種類あります。置き換えるパッケージの場合、syncbackupパッケージのバージョン番号の方が元々のDebianパッケージよりも大きいため、元々のDebianパッケージが更新されても、そのパッケージは更新対象とはなりません。一方、パッケージパッチ形式のパッケージでは、元々のパッケージが更新された場合、そのパッチをどうするかについてシステム管理者のポリシーによって二通りの方法をとることができます。ひとつは、パッケージパッチを削除して、通常のDebianのパッケージに戻す方法、もうひとつは、パッケージパッチが新しいパッケージに対応するまで、パッケージを保留状態とする方法のふたつです。パッケージパッチが新しくなると、旧パッケージパッチの削除、Debianパッケージの更新、新パッケージパッチの適用をシステムが自動的に行います。
パッケージパッチタイプのパッケージでは、元々のパッケージのファイルが全て保存されており、かつパッチ削除の方法についても認識しているため、パッケージパッチパッケージを削除するだけで、そのパッケージをインストールする前の状態に簡単に戻すことができます。一方、通常の置き換えタイプでは、元々のDebianパッケージのファイルが上書きされてしまっていますので、元に戻すにはそのパッケージを入手して、ダウングレードするしかありません。ダウングレードについては、通常きちんとしたフレームワークが存在しないため、意図しない状態に陥ることがありえます[3]。ただし、パッケージパッチタイプのパッケージではパッチパッケージ自身に加えて、そのパッチの対象となる元々のパッケージの二つのパッケージが必要になります。また、元々のパッケージに含まれるファイルを保存しておくため、ストレージの使用量がわずかに多くなります。したがって、用途にあわせて使いわけていくことをお薦めします。
概要
本付録は syncbackup を実現する LDAPv3 拡張プロトコルの仕様を記述した上で、概念の明確化、汎用性の抽出を行い、拡張プロトコル仕様の問題点を整理することを目的とする。
はじめに syncbackup 拡張プロトコル仕様の定義に必要ないくつかの概念、用語を挙げ、同期レプリケーション機能の動きを手短にまとめる。続いて各プロトコルの完全な構文を ASN.1 で記述する。その後、これらのプロトコルに関する考察を行い、現状把握している問題点、改良点を挙げ今後の課題を述べる。
この文書における次の各キーワード「しなければならない（ MUST ）」、 「してはならない（ MUST NOT ）」、「要求されている（ REQUIRED ）」、 「することになる（ SHALL ）」、「することはない（ SHALL NOT ）」、 「する必要がある（ SHOULD ）」、「しないほうがよい（ SHOULD NOT ）」、 「推奨される（ RECOMMENDED ）」、「してもよい（ MAY ）」、 「選択できる（ OPTIONAL ）」は、RFC 2119 (の日本語訳) で述べられているように 解釈されるべきものである。
Light Weight Directory Access Protocol (LDAP) バージョン 3 (RFC3377) システムの高可用性と性能を向上させるにはディレクトリの複製を作成することが重要であり、現在 IETF にて標準化作業が行われている。しかし現在の標準化作業は非同期に複製を作成するプロトコルが主な活動内容になっており、同期式にディレクトリの複製を行うプロトコルの標準化作業はあまり行われていない。syncbackup は LDAPv3 の拡張操作(Extended Operation)(RFC2251) を利用して LDAP プロトコル上でディレクトリを同期的に複製(同期レプリケーション)する。
このプロトコルの要約は以下の通りである:
| - 複製を確実に保証するために同期式のレプリケーションを用いる。ただし、全ての複製サーバに対して同期を保証することはせずに最低同期保証数という概念を導入する。 |
| - 複製クラスタ間に伝搬した更新の同一性を保証するために、伝搬イベントに一意の番号を割り振る。 |
| - 複製操作自体は拡張操作にせずに、LDAP コントロールを用いて複製操作であることを示す。 |
syncbackup は 2 つの拡張操作と 1 つのコントロールを新たに定義する。このうち 1 つの拡張操作と 1 つのコントロールは同期レプリケーションを実現するための拡張命令、残りの拡張操作は高可用性を実現するための拡張命令である。同期レプリケーション機能用の拡張命令は、ひとつは複製の伝搬を要求するための startSYNC 拡張操作、もうひとつはサーバ間で更新イベントの同一性を保証するための contextCSN コントロールである。高可用性を実現するために新たに作成した拡張命令はサーバが動作しているかを監視する NO-OP 拡張操作である。startSYNC 拡張操作では要求と応答の二つの拡張要素を定義する。
認証はマスタサーバが複製サーバを認証するフェーズと複製サーバがマスタサーバを認証するフェーズの二つがある。マスタサーバが複製サーバを認証するには、複製サーバがマスタサーバに同期要求を送信する前に適切な識別名でバインドしておく。複製サーバがマスタサーバを認証するには、複製を開始する直前にマスタサーバが複製サーバへバインドする。
同期レプリケーションを開始するには、はじめに複製サーバがマスタサーバに startSYNC 拡張操作を要求する。要求には伝搬開始点を指定するクッキーと、どの複製サーバの伝搬を開始したいのかを示す同期識別子 (syncid) を含める。マスタサーバはクッキー情報を解釈して複製サーバの伝搬開始点を認識し複製サーバ候補として内部記憶に割り当てる。続いて、複製サーバ候補にマスタサーバがバインドを試みる。バインドが成功すれば、その複製サーバ候補は実際に複製サーバとなる。この時点でその複製サーバの伝搬開始点がマスタサーバの最新の更新イベントである場合はこの複製サーバは「同期済み」となる。そうでない場合はこの複製サーバは「遅延状態」にある。割り当てが成功した場合、startSYNC 操作に対して割り当て成功の中間応答を返却する。
クライアントから更新が要求された場合、はじめにマスタサーバはその更新の成功によって保持される contextCSN 値を決定する。contextCSN はそのサーバの最新の更新状態を保持する値である。マスタサーバは複製サーバに操作の伝搬を行う時にクライアントから要求された実際の操作とコントロールに加えて、その操作の成功によって新たに保持される contextCSN の値を contextCSN コントロールとして加える。syncbackup の階層化を可能にするため、クライアントが既に contextCSN コントロールを保持していればサーバ側で contextCSN 値を生成するのではなく、クライアントのその値を再利用する。
複製サーバから見ると、通常の更新要求と伝搬の更新要求はほとんど同一に見える。違いは伝搬の更新要求には contextCSN コントロールが付加されている点である。したがって、複製サーバは伝搬の更新を通常の更新とほとんど同じように処理することが可能である。複製サーバは contextCSN コントロールを受理した場合は、新たに contextCSN 値を生成するのではなく、受け取った contextCSN 値を利用しなければならない( MUST )。
複製サーバは受け取った contextCSN を利用して更新を行った後、その結果に応じてエラーまたは成功の応答をマスタサーバに返却する。エラーの応答が返却された場合、マスタサーバはエラーの発生した複製サーバの割り当てを解除し、その複製の startSYNC 操作に対してエラー応答を返却する。マスタサーバが正常に終了する場合、startSYNC に対して操作完了の正常応答を返却する。
startSYNC セッションは任意の時点で操作の破棄を要求することができる。破棄要求を受け取ったマスタサーバはその複製サーバの割り当てを解除する。複製用の接続セッションに注目すると、破棄が起こった場合は、単にその接続がアンバインドされるだけであり、正常に終了する場合との見分けはつかない。
startSYNC を要求するには伝搬開始点と同期識別子が既知であれば実際に複製が行われる複製サーバでない場所から要求してもよい ( MAY )。したがって例えば同期管理を行う別のサーバを用意してそのサーバで複数の複製サーバの同期の開始、中断を管理することができる。
同期要求は requestName が IANA-割り当て空間.1、requestValue に requestSynchronizationValue を BER でエンコードした OCTET-STRING の LDAP 拡張要求で、マスタサーバに対して複製サーバへの複製を開始するように要求する。
requestSynchronizationValue ::= SEQUENCE {
syncid OCTET STRING,
cookie OCTET STRING
}
syncid はマスタサーバが管理する複製サーバ群の中からある複製サーバを特定するための同期識別子、cookie はその複製サーバの伝搬開始点を指定するためのクッキーである。クライアントは LDAP Content Synchronization 操作で取得したクッキーを requestSynchronizationValue の cookie として使用しても良い ( MAY )。もしそのサーバが LDAP Content Synchronization と startSYNC の両方をサポートするならば、そのサーバは LDAP Content Synchronization で返却したクッキー情報から伝搬開始点を特定できなければならない ( MUST )。
クッキーが空であるのはサーバ上のエントリが空であった時点を伝搬開始点とすることを表す。
同期要求応答は responseName が IANA-割り当て空間.2、response が synchronizationResponseValue を BER でエンコードした OCTET-STRING の LDAP 拡張応答である。
synchrozizationResponseValue ::= SEQUENCE {
status ENUMERATED {
noSuchCookie (1)
syncError (2)
serverFailure (3)
}
}
status は同期エラーが発生した場合の startSYNC に特有なエラーを指定する。同期要求応答が LDAP_SUCCESS である場合はこの値は意味を持たない。サーバはクライアントから指定されたクッキーを解釈できない場合に noSuchCookie エラーを返す。サーバはクッキーの保持期間を制限してもよい ( MAY )。保持期間をすぎたクッキーがクライアントから送られた場合も noSuchCookie を返す。クライアントはクッキーの保持期間の影響で noSuchCookie が返る事を仮定する必要がある ( SHOULD )。サーバは複製中にその複製サーバのエラーが発生した場合は syncError を、サーバ自身のエラーで startSYNC を継続できない場合は serverFailure を返す。
(TODO) Internet Draft に出ているディレクトリ複製プロトコルとの比較。
| LDUP Replication Update Protocol |
| LDAP Contetnt Synchronization Operation |
[1] これは、システム管理者が手動で行う事も、引き取り自動プログラムを使って自動化することも可能です。
[2] syncbackup を用いないで信頼性のある LDAP 環境構築する場合でもやはり三台以上のサーバを用意することが必要になります。ただし、この場合は 2 台の LDAP サーバともう一台の共有ディスクの合計で 3 台といった構成になります。なお、このようにした場合共有ディスクの冗長化も必要になりますので、実際にはそれ以上に複雑な構成になります。
[3] ダウングレードとは、そのパッケージ作成時には存在しない未来のパッケージから更新を行うことです。したがって、未来のパッケージがそのパッケージが考慮していること以上の行為を行ってしまっている場合、未来パッケージ側でダウングレード前になんらかの対処をしなければ、意図しない状況に陥ることが考えられます。ダウングレードの対処は過去の遺物に対する対処ですので、パッケージの本質とはあまり関係のない冗長なコードです。このコードを未来永劫パッケージ管理システムに存在させることは好ましいことではありません。パッケージパッチパッケージはこの問題を解決させるためのひとつの方法でもあります。