6 Oracle Unified Directory高可用性デプロイメントの理解

ほとんどのエンタープライズ・アプリケーションがディレクトリ・サーバーに依存しているため、信頼性の高いサービスが不可欠となっています。Oracle Unified Directoryをデプロイして、ディレクトリ・サーバー・インスタンス間またはディレクトリ・サーバー・インスタンスのグループ間の高可用性を確保できます。

次の各トピックでは、高可用性と、システム障害が発生した場合にサービスを継続するためにOracle Unified Directory機能がどのように役立つかについて説明します。

6.1 高可用性の概要

集中管理されているアイデンティティを使用して接続する企業および基幹アプリケーションが増えるにつれて、常時LDAPサービスを使用できるようにすることが欠かせなくなっています。高可用性とパフォーマンスは、すべてのエクストラネットとエンタープライズのデプロイメントの際立った特長になっています。

高可用性は、ディレクトリ・サービスに関して、特定の測定期間中の合意した動作パフォーマンス・レベルを保証するためのシステム設計方法と関連する実装です。

合意するサービス・レベルは、組織ごとに異なります。サービス・レベルは、システムがアクセスされる時刻、メンテナンスのためにシステムを停止する可能性があるかどうか、および組織が負担するダウンタイムのコストなど、様々な要因にも依存します。この場合、障害またはダウンタイムは、システムが使用不可状態であり、合意したサービス・レベルを提供できない期間として定義されます。

Oracle Unified Directoryには、精巧で使いやすく、コスト効率に優れた高可用性機能が用意されており、ダウンタイムを解消し、システムの使用可能時間を最大化します。

6.2 可用性とシングル・ポイント障害の理解

Oracle Unified Directoryの高可用性サービスを提供するデプロイメントでは、障害からリカバリしたり、合意したサービス・レベルを維持したりできます。高可用性デプロイメントでは、コンポーネントの障害は、個々のディレクトリ問合せには影響する可能性がありますが、その結果としてシステム全体に障害が発生することはありません。

シングル・ポイント障害(SPOF)とは、そこに障害が発生したときにシステム全体が使用不可または信頼できない状態になるシステム・コンポーネントを指します。高可用性デプロイメントを設計する際、潜在的なSPOFを特定し、それらを抑制する方法を調べます。

次の各トピックでは、可用性とシングル・ポイント障害について説明します。

6.2.1 SPOFのタイプの理解

シングル・ポイント障害(SPOF)とは、そこに障害が発生したときにシステム全体が使用不可または信頼できない状態になるシステム・コンポーネントを指します。高可用性デプロイメントを設計する際、潜在的なSPOFを特定し、それらを抑制する方法を調べます。

SPOFは、次のカテゴリに分けることができます。

6.2.1.1 ハードウェア障害について

ハードウェアSPOFは、大きく次のカテゴリに分けることができます:

  • ネットワークの障害

  • ディレクトリ・サーバーまたはディレクトリ・プロキシ・サーバーが動作している物理サーバーの障害

  • ハードウェア・ロード・バランサの障害

  • ストレージ・サブシステムの障害

  • 電源障害

6.2.1.2 ソフトウェア障害について

ディレクトリ・サーバーまたはプロキシ・サーバーの障害は、次のように大別できます。

  • レスポンス時間の低下

  • 書込みのオーバーロード

    • ファイル・ディスクリプタが最大数に達した

    • ファイル・システムが満杯になった

    • 構成されているストレージが不足している

    • 索引が多すぎる

  • 読取りのオーバーロード

  • キャッシュの問題

  • CPUの制約

  • レプリケーションの問題

    • 同期外れ

    • レプリケーションの伝播の遅延

    • レプリケーション・フロー

    • レプリケーションのオーバーロード

  • 大量のデータに対するワイルドカード検索

6.2.2 SPOFを抑制する手法の理解

SPOFは、コンポーネントに障害が発生した場合にシステム全体が実行不可または使用不可になる原因となるハードウェアまたはソフトウェア・コンポーネントです。冗長性はSPOFに対応する戦略的手法です。

冗長性を実装することで、単一コンポーネントの障害がディレクトリ・サービス全体の障害を引き起こさないことを保証できます。冗長性には、冗長なソフトウェア・コンポーネントまたはハードウェア・コンポーネント、あるいはその両方を提供することが含まれます。この戦略の例では、レプリケートされる複数のディレクトリ・サーバー・インスタンスを別々のホストにデプロイし、ディレクトリ・サーバー・データのストレージとしてRedundant Array of Independent Disks (RAID)を使用します。レプリケートされるディレクトリ・サーバーを使用する冗長性は、高可用性を実現する最も効率的な方法です。

6.3 高可用性のための冗長性の概要

ディレクトリ・サービスの信頼性と継続サービスを保証するには、システム障害発生時にシームレスに冗長なシステムに移行できる、高レベルのシステム可用性を維持する必要があります。

冗長性はディレクトリ・サーバーとプロキシ・サーバーの両方に適用され、次の影響を抑制します:

  • ハードウェア障害。トラフィックを別のハードウェア・コンポーネントにリダイレクトできるため。

  • ソフトウェア障害。体系的に障害が再発する可能性はありません。

冗長性によって、障害は次のように処理されます:

6.3.1 ハードウェア・レベルでの冗長性の理解

ハードウェアは最も重要なSPOFです。ハードウェアは、ネットワークにおいて、ネットワーク・トラフィックの処理、システムの制御または認証の管理を行うどのような部分にもある可能性がありいます。

この項では、ハードウェア冗長性の概要について説明します。

ノート:

このトピックに関する包括的な情報を提供することは、この本で扱う範囲を超えています。ただし、John Wiley & Sons, Incから出版されている『Blueprints for High Availability』など、ハードウェア冗長性を使用した高可用性の実現に関する出版物が数多くあります。

ネットワーク・レベルの障害は、冗長なネットワーク・コンポーネントを用意することで抑制できます。デプロイメントを設計する際、次のものに対して冗長なコンポーネントを用意することを検討します:

  • インターネット接続

  • ネットワーク・インタフェース・カード

  • ネットワーク配線

  • ネットワーク・スイッチ

  • ゲートウェイとルーター

SPOFとしてのハードウェア・ロード・バランサの影響は、アーキテクチャ内に冗長なハードウェア・ロード・バランサを追加することで抑制できます。

冗長なサーバー・コントローラを使用することによって、ストレージ・サブシステムのSPOFの影響を抑制できます。また、コントローラとストレージ・サブシステムの間の冗長なケーブル、冗長なストレージ・サブシステム・コントローラまたはRedundant Array of Independent Disksを使用することもできます。

電源が1つしかない場合、この電源を失うことでサービス全体が使用不可になる可能性があります。この状況を回避するには、可能であればハードウェアに冗長な電源を用意して、電源を分散することを検討します。電源のSPOFの影響を抑制する他の方法として、サージ・プロテクタ、複数の電力事業者、ローカル・バッテリ・バックアップおよび緊急ローカル発電機を使用することなどがあります。

たとえば、自然災害が特定の地理的地域を襲った場合、データ・センター全体で障害が発生する可能性があります。この場合、綿密に設計された複数のデータ・センターを使用するレプリケーション・トポロジを使用して、分散ディレクトリ・サービスが使用不可になることを防ぐことができます。「高可用性のために冗長性を使用するサンプル・トポロジ」を参照してください。

6.3.2 レプリケーションを使用するディレクトリ・サーバー・レベルでの冗長性の理解

レプリケーションは、Oracle Unified Directoryサーバーでの冗長性の実装に使用される一般的な方法です。レプリケーションによって、フェイルオーバー・システムに冗長性が実装されます。

冗長ソリューションは通常、クラスタリング・ソリューションより低コストで実装しやすく、管理が容易です。クラスタリング・モデルでは、同じアプリケーション処理負荷を処理するために少なくとも2つのサーバーを構成し、一方のノードをアクティブで、もう一方のノードをパッシブでスタンバイさせて使用する必要があります。

冗長ソリューションの一部としてのレプリケーションには、可用性以外に多くの機能があることに注意してください。レプリケーションの主な利点は、複数サーバー間で読取りを分割できることですが、この利点と追加したサーバーを管理するタスクとのバランスを取る必要があります。レプリケーションは、読取り操作のスケーラビリティ、および正しく設計された場合には、一定の制限はありますが、書込み操作のスケーラビリティも提供します。「Oracle Unified Directoryレプリケーション・モデルの理解」を参照してください。

「ソフトウェア障害について」で説明されているSPOFは、ディレクトリ・サーバーの冗長なインスタンスを用意することで抑制できます。この場合もレプリケーションが使用されます。レプリケーションは、冗長なサーバーが同期されること、およびダウンタイムなしでリクエストをルーティングできることを保証します。

レプリケーションは、1つのサーバーを失うことでディレクトリ・サービスが使用不可になることを防ぐために使用します。信頼性のあるレプリケーション・トポロジを適用することにより、サーバーで障害が発生しても、複数のデータ・センターにわたるクライアントで、最新のデータを確実に使用できます。少なくとも、ローカル・ディレクトリ・ツリーを1つ以上のバックアップ・サーバーにレプリケートする必要があります。ディレクトリ・アーキテクトは、データの信頼性を最大化するために、物理的な場所ごとに3回レプリケートすることをお薦めします。データが少なくとも3回レプリケートされている場合、ディレクトリ・サーバーに障害が発生しても、構成は可用性が高く、障害から保護されている状態で維持されます。フォルト・トレランスのためにレプリケーションの回数を決定する際、ディレクトリで使用するハードウェアとネットワークの品質を検討します。ハードウェアの信頼性が低い場合、必要なバックアップ・サーバーの数は増えます。

Oracle Unified Directoryレプリケーション・モデルは、ゆるやかな一貫性を持つマルチマスター・モデルです。言い換えると、レプリケートされるトポロジのすべてのディレクトリ・サーバーが、読取り操作と書込み操作の両方を処理できます。「Oracle Unified Directoryレプリケーション・モデルの理解」を参照してください。

レプリケーションを通常のデータ・バックアップ・ポリシーのかわりとして使用しないでください。レプリケーションは、所定のサービス・レベル合意の範囲内にサービスを維持する目的で設計されています。アプリケーションまたはユーザーによってディレクトリに格納された不正なデータから保護することが目的ではありません。「データのバックアップおよびリストア」を参照してください。

想定されているサービス・レベル合意の範囲でディレクトリのデータを読み取る能力を維持するには、適切なロード・バランシング戦略を導入する必要があります。複数のレプリカ間で読取り負荷を分散するために、ソフトウェアとハードウェアの両方のロード・バランシング・ソリューションが存在します。これらのソリューションはそれぞれ、レプリカごとの状態を決定し、ロード・バランシング・トポロジに参加するかどうかを管理できます。これらのソリューションは、完全性と精度という点に違いが存在する可能性があります。

地理的に分散したサイト全体の書込みフェイルオーバーを維持するために、WAN経由の複数データ・センターのレプリケーションを使用できます。それには、各データ・センターに少なくとも2つのマスター・サーバーを設定し、それらのサーバーがWAN経由でフルメッシュされるように構成します。この戦略により、トポロジ内のどのマスターで障害が発生しても、サービスが失われることはありません。書込み可能サーバーが使用不可になった場合、書込み操作は代替サーバーにルーティングされる必要があります。

6.3.3 冗長ソリューションの一部としてのDirectory Proxy Serverの使用の理解

プロキシ・サーバーを使用して、プロキシの複数のインスタンスを介して冗長性を実装できます。これは、高可用性ディレクトリ・サービスを実現するもう1つの手法です。

ディレクトリ・プロキシ・サーバーは、高可用性ディレクトリ・デプロイメントをサポートする目的で設計されています。プロキシは、レプリケートされる一連のディレクトリ・サーバー間で、自動ロード・バランシングおよび自動のフェイルオーバーとフェイルバックを提供します。トポロジ内で1つ以上のディレクトリ・サーバーが使用不可になった場合、負荷は残りのサーバー間で均等に分散されます。

ディレクトリ・プロキシ・サーバーはディレクトリ・サーバーを積極的にモニターして、サーバーが引き続きオンラインであることを確認します。また、実行される各操作のステータスも調査します。すべてのサーバーのスループットとパフォーマンスが同等であるとはかぎりません。プライマリ・サーバーが使用不可になった場合、一時的にセカンダリ・サーバーにリダイレクトされたトラフィックは、プライマリ・サーバーが使用可能になるとすぐに、プライマリ・サーバーに戻されます。

ノート:

データを分散した場合は、複数の切断されたレプリケーション・トポロジを管理する必要がありますが、これにより、管理が複雑になります。さらに、ディレクトリ・プロキシ・サーバーは、ユーザー認可の管理をプロキシ認可制御に大きく依存しています。分散に関与するディレクトリ・サーバーごとに、固有の管理ユーザーを作成し、これらの管理ユーザーにプロキシ・アクセス制御権を付与する必要があります。

6.3.4 高可用性のためのアプリケーション分離の使用の理解

ディレクトリ・プロキシ・サーバーを使用して、欠陥のあるクライアント・アプリケーションによる障害から、レプリケートされるディレクトリ・サービスを保護することもできます。可用性を高めるために、限られた数のマスターまたはレプリカが各アプリケーションに割り当てられます。

欠陥のあるアプリケーションが特定のアクションを実行すると、サーバーがシャットダウンされるシナリオについて考えてみます。アプリケーションがその後に続く各レプリカにフェイルオーバーした場合、1つのアプリケーションの1つの問題が、レプリケートされるトポロジ全体に障害を引き起こす可能性があります。このようなシナリオを回避するために、各アプリケーションのフェイルオーバーとロード・バランシングの対象を限られた数のレプリカに制限できます。これにより、障害が発生する可能性があるのは限られた数のレプリカのみとなり、障害が他のアプリケーションに及ぼす影響も少なくなります。

6.3.5 レプリケーション・ゲートウェイを使用して高可用性を実現する方法の理解

レプリケーション・ゲートウェイは、冗長なレプリケーション・ゲートウェイ・サーバーを使用して異種サーバーで行われた変更をレプリケーション・トポロジ全体に伝播できるようにすることで、高可用性デプロイメント・ソリューションを提供できるように設計されています。

レプリケーション・ゲートウェイは、Oracle Directory Server Enterprise EditionトポロジとOracle Unified Directoryトポロジの間で変更を伝播します。「レプリケーション・ゲートウェイの役割の理解」を参照してください。

6.4 高可用性のために冗長性を使用するサンプル・トポロジ

サンプルのトポロジは障害が発生した場合に冗長性およびレプリケーションを示し、継続したサービスを提供します。

冗長性およびレプリケーションによって障害が発生した場合にサービスが継続されることを示したサンプルのトポロジについては、次を参照してください。