第20回 OpenLDAPの冗長化対策【2】 | gihyo.jp
最初に 前回「基本形」としてお伝えしていたOpenLDAPのsyncrepl機能ですが、まずは記事の内容で少し補足です。 これまで「マスターとなるサーバはサプライヤ、スレーブとなるサーバはコンシューマ」と記述していましたが、OpenLDAPの場合はそれぞれ、プロバイダ、コンシューマと呼ぶのが一般的でした。サプライヤという用語も間違いでは無いのですが、こちらは主にSun Java Directory ServerやRed Hat Directory Serverなどで使用されている用語ですので、OpenLDAPに合わせるためここからは「プロバイダ」に統一するようにします。 syncreplが提供するレプリケーション 一般的なデータベースの冗長構成ではデータの完全同期が期待さることが多いかもしれません。たとえば、2台のDBサーバが存在したとして、完全同期のレプリケーションでは、クライアントが一
第21回（最終回） OpenLDAPの冗長化対策【3】 | gihyo.jp
諸事情により、前回から非常に時間が空いてしまってご迷惑をおかけしました。 前回は、OpenLDAPのsyncrepl機能を使って、LDAPサーバの二重化、つまり冗長化を実現することができました。ただしいくつかの制限がありましたので、改めてその内容をリストアップしておきます。 通常はプロバイダのみが検索、更新処理を行い、コンシューマ側はスタンバイ状態となっている（クライアント側の設定次第では、コンシューマ側の検索機能を活用することも可能） コンシューマは検索結果を提供することはできるが、更新要求を直接受け付けることはできない プロバイダがダウンした場合、すべての要求はコンシューマに委任されるが、この際更新要求が発生するとクライアントにエラーが通知される 負荷分散は実現されていなかった（クライアント側の設定切り替え、またはロードバランサの導入により対応可能） このように、一見不完全に思われる部
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
