そろそろLDAPにしてみないか?

第21回(最終回) OpenLDAPの冗長化対策【3】

この記事を読むのに必要な時間:およそ 6 分

諸事情により,前回から非常に時間が空いてしまってご迷惑をおかけしました。

前回は,OpenLDAPのsyncrepl機能を使って,LDAPサーバの二重化,つまり冗長化を実現することができました。ただしいくつかの制限がありましたので,改めてその内容をリストアップしておきます。

  • 通常はプロバイダのみが検索,更新処理を行い,コンシューマ側はスタンバイ状態となっている(クライアント側の設定次第では,コンシューマ側の検索機能を活用することも可能)
  • コンシューマは検索結果を提供することはできるが,更新要求を直接受け付けることはできない
  • プロバイダがダウンした場合,すべての要求はコンシューマに委任されるが,この際更新要求が発生するとクライアントにエラーが通知される
  • 負荷分散は実現されていなかった(クライアント側の設定切り替え,またはロードバランサの導入により対応可能)

このように,一見不完全に思われる部分もありますが,今まで何度も紹介してきたように,LDAPサーバのデータ更新頻度はそれほど高くない場合が多いため,障害が発生してプロバイダが数時間停止してしまったとしても,なるべく早く復旧作業を正しく行えば,それほど大きな影響を及ぼすものではありません。

しかし,「比較的データの更新頻度が高い場合」,または「社外の顧客などが更新処理を行う(数分のダウンタイムも許されない)」といった場合,このダウンタイムを極力ゼロに近づける必要があります。今回は,このようなシチュエーションを考慮した冗長設計を考えていくことにしましょう。

Active/ActiveとActive/Standby

LDAPに限らず,どのサービスについても言えることですが,冗長化対策を行う上で覚えておきたいのがこの2つの用語です。

前者では,2台以上のサーバがすべて稼働し,全ノードのCPUを効率的に活用することで 冗長化+負荷分散(並列処理)という効果を期待することができます。一方,後者の場合はサービスを提供するのは常時1台のノードであり,そのノードに障害が発生して初めて別のノードへの切り替わりが発生します。スタンバイ側のCPUは通常眠ったままですので,一見Active/Activeのほうがハードウェア資源を効率的に使用できるように思えますが,アプリケーション側での排他制御などが必要となるため,Active/Active方式はすべてのアプリケーションで利用できる機能ではありません。

また,仮にActive/Active構成の場合で両方のCPU資源をフルに活用した場合,片方の障害によって,全てのアクセスがもう一方に集中してしまうことになります。サーバがそのアクセスに耐えうるスペックを持っていれば問題ないのですが,もしそうでない場合,1サーバだけでは高負荷に耐えることができず,1台の障害が結局全体の障害になってしまう可能性も考慮しておかなければなりません。

前回の設定でも,「検索」のみに着目した場合はActive/Active方式を実現できていたわけですが,更新処理に関しては冗長化対策を行っていませんでした。

OpenLDAPのMirrorMode

OpenLDAP-2.4系で実装された「ミラーモード」という機能を用いると,いわゆるマルチマスターレプリケーションと呼ばれる,更新処理をもサポートしたActive/Active型の冗長構成を実現することができます(正確には,ミラーモード=マルチマスターというわけではないので,マルチマスターレプリケーションに似た機能です)。

OpenLDAP-2.4系のレプリケーションドキュメントの中には,次のように興味深い記述があります。

18.2.2.1. マルチマスターレプリケーションに関する正しい議論
  • もしいずれかのプロバイダがダウンすると,他のプロバイダは更新要求を処理し続けることができる
  • Single Point Of Failureを回避することができる
  • プロバイダはディザスタリカバリの観点から物理的に離れた箇所に設置することができる
  • 自動フェイルオーバー,冗長性に優れる
18.2.2.2. マルチマスターレプリケーションに関する誤った議論
  • ロードバランシングを行うわけではない
  • プロバイダは書き込みを他の全てのサーバに伝えなければならない,ネットワークトラフィックと書き込みはシングルマスタ時同様,ネットワーク上に広がっていく。
  • サーバのユーティライゼーションやパフォーマンスはシングルマスタ時とそれほど変わりない。最悪,インデックス処理,最適化を考えると,シングルマスタのほうが優れている場合もある。

さらに,ミラーモードに関しては,次のような記述があります。

18.2.3.1. ミラーモードのための議論
  • 書き込みのためのHAソリューションを提供する
  • プロバイダが生きている限り,書き込み要求は安全に処理される
  • プロバイダノードは互いにレプリケーションを実行する。それらは常にアクティブであり他へテイクオーバーする準備ができている(ホットスタンバイ)
  • Syncreplは障害後の再同期をサポートする
18.2.3.2. ミラーモードに対する議論
  • ミラーモードはマルチマスターソリューションを意味するものではない。書き込み要求は1台のサーバのみに発生させなければならないためである。
  • ミラーモードはActive/Activeホットスタンバイとして定義できる。したがって,ロードバランサなどにより,どのプロバイダが現在アクティブなのか,選択させなければならない。
  • バックアップとは別物として考える
  • Delta-Syncreplは未サポート

つまり,ミラーモード構成の2台のLDAPサーバが存在していた場合,どちらか一方で更新処理を行うと,もう一方にもその更新が反映されます。しかし,複数のサーバで同時に更新処理が発生してしまうと,タイミングによっては全ノード上でのデータの一貫性が失われてしまう可能性があります。よって,ミラーモードは次のような形を想定して使用するのが一般的です※1)。

図1 ミラーモードの使われ方
(Active/Standby的な考え方。サーバ1に障害が発生しても,サーバ2が引き続き更新処理を受け付けることができる)

図1 ミラーモードの使われ方(Active/Standby的な考え方。サーバ1に障害が発生しても,サーバ2が引き続き更新処理を受け付けることができる)

もしサーバ1に障害が発生した場合には,ハードやOSを正常に戻した後,正しいslapd.confを用意しプロセスを起動することで,サーバ2にある最新のデータを自動的に同期させることができます。

また,もし冗長化対策だけでなく,検索の負荷分散を行いたい場合は,ロードバランサ側で更新専用となる10389/tcpなどのポートを準備しておき,次のような形で検索と更新のトラフィックをコントロールすることもできるでしょう。

図2 更新時の冗長化,検索時の負荷分散を実現
(検索トラフィックに関してはロードバランサでバランシングし,更新処理については常に一方のサーバのみを使用する)

図2 更新時の冗長化,検索時の負荷分散を実現(検索トラフィックに関してはロードバランサでバランシングし,更新処理については常に一方のサーバのみを使用する)

ただし,検索アプリケーションでは389/tcpというポート番号を指定し,更新アプリケーションでは10389/tcpを指定しなければならないため,アプリケーションによってはこの方法が使用できない場合もあります※2)。

※1)
実際の環境ではロードバランサ自身や間にあるスイッチ自体の冗長化も検討してください。
※2)
ポートを分けるのではなく,ロードバランサ上のバーチャルIPを複数に分ければ,どのアプリケーションでも389/tcpを指定することもできます。

著者プロフィール

中満英生(なかみつひでお)

大学時代に出会ったSolarisがきっかけでUNIXの世界へ。その後ホスティングプロバイダ,データセンターで実務経験を積む傍ら,雑誌記事の執筆や技術セミナーの講師を務める。サーバ設定の他,セキュリティに関する著作や技術者エッセイも執筆経験あり。

コメント

コメントの記入