| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-04 |
|
 前 |
 次 |
集中管理されているアイデンティティを使用して接続する企業および基幹アプリケーションが増えるにつれて、常時LDAPサービスを使用できるようにすることが欠かせなくなっています。高可用性とパフォーマンスは、すべてのエクストラネットとエンタープライズのデプロイメントの際立った特長になっています。
この章には次のトピックが含まれます:
高可用性は、ディレクトリ・サービスに関して、特定の測定期間中の合意した動作パフォーマンス・レベルを保証するためのシステム設計方法と関連する実装です。
合意するサービス・レベルは、組織ごとに異なります。サービス・レベルは、システムがアクセスされる時刻、メンテナンスのためにシステムを停止する可能性があるかどうか、および組織が負担するダウンタイムのコストなど、様々な要因にも依存します。この場合、障害またはダウンタイムは、システムが使用不可状態であり、合意したサービス・レベルを提供できない期間として定義されます。
Oracle Unified Directoryには、精巧で使いやすく、コスト効率に優れた高可用性機能が用意されており、ダウンタイムを解消し、システムの使用可能時間を最大化します。
Oracle Unified Directoryの高可用性サービスを提供するデプロイメントでは、障害からリカバリしたり、合意したサービス・レベルを維持したりできます。高可用性デプロイメントでは、コンポーネントの障害は、個々のディレクトリ問合せには影響する可能性がありますが、その結果としてシステム全体に障害が発生することはありません。
シングル・ポイント障害(SPOF)とは、そこに障害が発生したときにシステム全体が使用不可または信頼できない状態になるシステム・コンポーネントを指します。高可用性デプロイメントを設計する際、潜在的なSPOFを特定し、それらを抑制する方法を調べます。
この項には次のトピックが含まれます:
SPOFは、次の3つのカテゴリに分けることができます:
ハードウェアSPOFは、大きく次のカテゴリに分けることができます:
ネットワークの障害
ディレクトリ・サーバーまたはディレクトリ・プロキシ・サーバーが動作している物理サーバーの障害
ハードウェア・ロード・バランサの障害
ストレージ・サブシステムの障害
電源の障害
ディレクトリ・サーバーまたはプロキシ・サーバーの障害は、次のカテゴリに分けることができます:
レスポンス時間の低下
書込みのオーバーロード
ファイル・ディスクリプタが最大数に達した
ファイル・システムが満杯になった
構成されているストレージが不足している
索引が多すぎる
読取りのオーバーロード
キャッシュの問題
CPUの制約
レプリケーションの問題
同期外れ
レプリケーションの伝播の遅延
レプリケーション・フロー
レプリケーションのオーバーロード
大量のデータに対するワイルドカード検索
冗長性を実装することで、単一コンポーネントの障害がディレクトリ・サービス全体の障害を引き起こさないことを保証できます。冗長性には、冗長なソフトウェア・コンポーネントまたはハードウェア・コンポーネント、あるいはその両方を提供することが含まれます。この戦略の例では、レプリケートされる複数のディレクトリ・サーバー・インスタンスを別々のホストにデプロイするか、またはディレクトリ・サーバー・データのストレージとしてRedundant Array of Independent Disks (RAID)を使用するか、あるいはその両方を実行します。レプリケートされるディレクトリ・サーバーを使用する冗長性は、高可用性を実現する最も効率的な方法です。
ディレクトリ・サービスの信頼性と継続サービスを保証するには、システム障害発生時にシームレスに冗長なシステムに移行できる、高レベルのシステム可用性を維持する必要があります。
冗長性はディレクトリ・サーバーとプロキシ・サーバーの両方に適用され、次の影響を抑制します:
ハードウェア障害。トラフィックを別のハードウェア・コンポーネントにリダイレクトできるため。
ソフトウェア障害。体系的に障害が再発する可能性はありません。
冗長性によって、障害は次のように処理されます:
この項では、ハードウェア冗長性の概要について説明します。ハードウェア冗長性を使用した高可用性の実現については、多くの出版物で包括的に説明されています。特に、John Wiley & Sons, Incから出版されている『Blueprints for High Availability』を参照する必要があります。
ネットワーク・レベルの障害は、冗長なネットワーク・コンポーネントを用意することで抑制できます。デプロイメントを設計する際、次のものに対して冗長なコンポーネントを用意することを検討します:
インターネット接続
ネットワーク・インタフェース・カード
ネットワーク・ケーブル
ネットワーク・スイッチ
ゲートウェイとルーター
SPOFとしてのハードウェア・ロード・バランサの影響は、アーキテクチャ内に冗長なハードウェア・ロード・バランサを追加することで抑制できます。
冗長なサーバー・コントローラを使用することによって、ストレージ・サブシステムのSPOFの影響を抑制できます。また、コントローラとストレージ・サブシステムの間の冗長なケーブル、冗長なストレージ・サブシステム・コントローラまたはRedundant Array of Independent Disksを使用することもできます。
電源が1つしかない場合、この電源を失うことでサービス全体が使用不可になる可能性があります。この状況を回避するには、可能であればハードウェアに冗長な電源を用意して、電源を分散することを検討します。電源のSPOFの影響を抑制する他の方法として、サージ・プロテクタ、複数の電力事業者、ローカル・バッテリ・バックアップおよび緊急ローカル発電機を使用することなどがあります。
たとえば、自然災害が特定の地理的地域を襲った場合、データ・センター全体で障害が発生する可能性があります。この場合、綿密に設計された複数のデータ・センターを使用するレプリケーション・トポロジを使用して、分散ディレクトリ・サービスが使用不可になることを防ぐことができます。詳細は、第6.4項「冗長性を使用して高可用性を実現するサンプル・トポロジ」を参照してください。
Oracle Unified Directoryサーバーに冗長性を実装する一般的な方法は、レプリケーションを使用することです。冗長ソリューションは通常、クラスタリング・ソリューションより低コストで実装しやすく、管理が容易です。これは、クラスタリング・モデルでは同じアプリケーション処理負荷を処理するために少なくとも2つのサーバーを構成し、一方のノードをアクティブで、もう一方のノードをパッシブでスタンバイさせて使用する必要があるからです。冗長ソリューションの一部としてのレプリケーションには、可用性以外に多数の機能があります。レプリケーションの主な利点は、複数サーバー間で読取りを分割できることですが、この利点は追加したサーバーを管理するタスクとのバランスを取る必要があります。レプリケーションは、読取り操作のスケーラビリティ、および正しく設計された場合には、一定の制限はありますが、書込み操作のスケーラビリティも提供します。レプリケーションの概念の概要は、第7章「Oracle Unified Directoryレプリケーション・モデルの理解」を参照してください。
第6.2.1.2項「ソフトウェア障害」で説明されているSPOFは、ディレクトリ・サーバーの冗長なインスタンスを用意することで抑制できます。この場合もレプリケーションが使用されます。レプリケーションは、冗長なサーバーが同期されること、およびダウンタイムなしでリクエストをルーティングできることを保証します。
レプリケーションは、1つのサーバーを失うことでディレクトリ・サービスが使用不可になることを防ぐために使用します。信頼できるレプリケーション・トポロジは、たとえサーバーに障害が発生した場合でも、データ・センター全体でクライアントが最新データを使用できることを保証します。最低でも、ローカル・ディレクトリ・ツリーを少なくとも1つのバックアップ・サーバーにレプリケートする必要があります。ディレクトリ・アーキテクトは、データの信頼性を最大化するために、物理的な場所ごとに3回レプリケートすることをお薦めします。データが少なくとも3回レプリケートされている場合、ディレクトリ・サーバーに障害が発生しても、構成は可用性が高く、障害から保護されている状態で維持されます。フォルト・トレランスのためにレプリケーションの回数を決定する際、ディレクトリで使用するハードウェアとネットワークの品質を検討します。ハードウェアの信頼性が低い場合、必要なバックアップ・サーバーの数は増えます。
Oracle Unified Directoryレプリケーション・モデルは、ゆるやかな一貫性を持つマルチマスター・モデルです。言い換えると、レプリケートされるトポロジのすべてのディレクトリ・サーバーが、読取り操作と書込み操作の両方を処理できます。レプリケーションの詳細は、第7章「Oracle Unified Directoryレプリケーション・モデルの理解」を参照してください。
レプリケーションを通常のデータ・バックアップ・ポリシーのかわりとして使用しないでください。レプリケーションは、所定のサービス・レベル合意の範囲内にサービスを維持する目的で設計されています。アプリケーションまたはユーザーによってディレクトリに格納された不正なデータから保護することが目的ではありません。ディレクトリ・データのバックアップの詳細は、第20.3項「データのバックアップおよびリストア」を参照してください。
想定されているサービス・レベル合意の範囲でディレクトリのデータを読み取る能力を維持するには、適切なロード・バランシング戦略を導入する必要があります。複数のレプリカ間で読取り負荷を分散するために、ソフトウェアとハードウェアの両方のロード・バランシング・ソリューションが存在します。これらのソリューションはそれぞれ、レプリカごとの状態を決定し、ロード・バランシング・トポロジに参加するかどうかを管理できます。これらのソリューションは、完全性と精度という点に違いが存在する可能性があります。
地理的に分散したサイト全体の書込みフェイルオーバーを維持するために、WAN経由の複数データ・センターのレプリケーションを使用できます。それには、各データ・センターに少なくとも2つのマスター・サーバーを設定し、それらのサーバーがWAN経由でフルメッシュされるように構成します。この戦略により、トポロジ内のどのマスターで障害が発生しても、サービスが失われることはありません。書込み可能サーバーが使用不可になった場合、書込み操作は代替サーバーにルーティングされる必要があります。
ディレクトリ・プロキシ・サーバーは、高可用性ディレクトリ・デプロイメントをサポートする目的で設計されています。プロキシは、レプリケートされる一連のディレクトリ・サーバー間で、自動ロード・バランシングおよび自動のフェイルオーバーとフェイルバックを提供します。トポロジ内で1つ以上のディレクトリ・サーバーが使用不可になった場合、負荷は残りのサーバー間で均等に分散されます。
プロキシ・サーバーは、複数のプロキシ・インスタンスを使用して冗長化することもできます。高可用性ディレクトリ・サービスを実現するもう1つの手法です。
ディレクトリ・プロキシ・サーバーはディレクトリ・サーバーを積極的に監視して、サーバーが引き続きオンラインであることを確認します。また、実行される各操作のステータスも調査します。すべてのサーバーのスループットとパフォーマンスが同等であるとはかぎりません。プライマリ・サーバーが使用不可になった場合、一時的にセカンダリ・サーバーにリダイレクトされたトラフィックは、プライマリ・サーバーが使用可能になるとすぐに、プライマリ・サーバーに戻されます。
データが分散されている場合、接続されていない複数のレプリケーション・トポロジを管理する必要があるので、管理が非常に複雑になります。さらに、ディレクトリ・プロキシ・サーバーは、ユーザー認可の管理をプロキシ認可制御に大きく依存しています。分散に関連するディレクトリ・サーバーごとに、固有の管理ユーザーを作成する必要があります。これらの管理ユーザーには、プロキシ・アクセス制御権限を付与する必要があります。
ディレクトリ・プロキシ・サーバーを使用して、欠陥のあるクライアント・アプリケーションによる障害から、レプリケートされるディレクトリ・サービスを保護することもできます。可用性を高めるために、限られた数のマスターまたはレプリカが各アプリケーションに割り当てられます。
欠陥のあるアプリケーションが特定のアクションを実行すると、サーバーがシャットダウンされるとします。アプリケーションがその後に続く各レプリカにフェイルオーバーした場合、1つのアプリケーションの1つの問題が、レプリケートされるトポロジ全体に障害を引き起こす可能性があります。このようなシナリオを回避するために、各アプリケーションのフェイルオーバーとロード・バランシングの対象を限られた数のレプリカに制限できます。これにより、障害が発生する可能性があるのは限られた数のレプリカのみとなり、障害が他のアプリケーションに及ぼす影響も少なくなります。
レプリケーション・ゲートウェイは、Oracle Directory Server Enterprise EditionトポロジとOracle Unified Directoryトポロジの間で変更を伝播します。レプリケーション・ゲートウェイは、冗長なレプリケーション・ゲートウェイ・サーバーを使用して異種サーバーで行われた変更をレプリケーション・トポロジ全体に伝播できるようにすることで、高可用性デプロイメント・ソリューションを提供できるように設計されています。レプリケーション・ゲートウェイの詳細は、第1.4.2項「レプリケーション・ゲートウェイの役割」を参照してください。
次のサンプル・トポロジは、冗長性とレプリケーションを使用して、障害発生時に継続サービスを提供する方法を示します:
