| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド 11g リリース1 (11.1.1.7.0) B72436-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド 11g リリース1 (11.1.1.7.0) B72436-01 |
|
前 |
次 |
高可用性とは、ディレクトリ・サービスに関して合意された、最小の稼働時間およびパフォーマンス・レベルを意味します。合意されたサービス・レベルは、組織ごとに異なります。サービス・レベルは、システムがアクセスされる時刻、システムをメンテナンスのために停止できるかどうか、組織にとっての停止時間のコストなどの要素によって異なる場合があります。このコンテキストでは、障害とは、ディレクトリ・サービスがこの最低レベルのサービスを提供することを妨げるものとして定義されます。
この章の内容は、次のとおりです。
高可用性を実現するDirectory Server Enterprise Editionデプロイメントは、障害から迅速にリカバリできます。高可用性デプロイメントでは、コンポーネント障害が個々のディレクトリ問合せに影響することがありますが、完全なシステム障害は発生しません。シングル・ポイント障害(SPOF)とは、障害が発生すると、システム全体が使用できなくなるか、またはシステム全体の信頼性が低下する原因となる、1つのシステム・コンポーネントのことです。高可用性デプロイメントを設計する場合は、潜在的なSPOFを識別し、これらのSPOFをどのように軽減できるかを調べます。
SPOFは、次の3つのカテゴリに分けることができます。
ハードウェア障害(サーバー・クラッシュ、ネットワーク障害、停電、ディスク・ドライブ・クラッシュなど)
ソフトウェア障害(Directory ServerのクラッシュやDirectory Proxy Serverのクラッシュなど)
データベースの破損
冗長性を使用することによって、1つのコンポーネントの障害が原因でディレクトリ・サービス全体が失敗しないようにすることができます。冗長性により、冗長なソフトウェア・コンポーネント、ハードウェア・コンポーネントまたは両方が提供されます。この方針の例として、Directory Serverの複数のレプリケートされたインスタンスを別々のホストにデプロイしたり、Directory ServerデータベースのストレージにRedundant Array of Independent Disks (RAID)を使用することをあげることができます。レプリケートされたDirectory Serverによる冗長性は、高可用性を実現する最も効率的な方法です。
高可用性ディレクトリ・サービスを提供するためのより一般的なアプローチは、冗長なサーバー・コンポーネントとレプリケーションの使用です。冗長ソリューションは、通常はコストが低く、実装と管理が容易です。冗長ソリューションの一部としてのレプリケーションには、可用性以外に多くの機能があります。レプリケーションの主な長所は、読取り負荷を複数のサーバーに分散できることですが、これにより、サーバー管理の面でオーバーヘッドが増加します。また、レプリケーションにより、特定の制限内で読取り操作のスケーラビリティ、および設計が適切である場合には書込み操作のスケーラビリティが提供されます。レプリケーション概念の概要は、Oracle Directory Server Enterprise Editionリファレンスの第7章「Directory Serverのレプリケーション」を参照してください。
障害が発生している間、冗長システムの可用性が低下することがあります。たとえば、負荷が2つの冗長サーバー・コンポーネントで共有されている環境を考えます。1つのサーバー・コンポーネントで障害が発生すると、もう一方のサーバーの負荷が過剰になり、このサーバーでクライアント・リクエストへの応答が遅くなる可能性があります。レスポンスが遅いと、迅速なレスポンス時間に依存するクライアントでは障害とみなされることがあります。つまり、サービスが動作可能であっても、サービスの可用性がクライアントの可用性要件を満たさない場合があります。
この章の最初に説明したSPOFに関しては、冗長性により、次の方法で障害が処理されます。
単一のハードウェア障害。ハードウェア障害は、単一であっても、マシンにとって致命的です。したがって、冗長ハードウェアがある場合でも、障害を修復するために手動操作が必要になります。
Directory ServerまたはDirectory Proxy Serverの障害。サーバーは自動的に再起動されます。
データベースの破損。アーキテクチャに応じて、冗長ソリューションでデータベースの破損に対応できる必要があります。
ここでは、ハードウェアの冗長性に関する基本情報を示します。ハードウェアの冗長性を使用して高可用性を確保するための包括的な情報は、数多くの出版物に記載されています。特に、John Wiley & Sons, Inc.が発行している『Blueprints for High Availability』(http://www.amazon.com/exec/obidos/tg/detail/-/0471430269/qid=1105613280/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/002-6680176-0680863?v=glances=booksn=507846)を参照してください。
ハードウェアSPOFは、大きく次のように分類できます。
ネットワークの障害
Directory ServerやDirectory Proxy Serverが実行されている物理サーバーの障害
ロード・バランサの障害
ストレージ・サブシステムの障害
電源障害
ネットワーク・レベルの障害は、冗長なネットワーク・コンポーネントを配置することで軽減できます。デプロイメントを設計するときに、次の冗長コンポーネントの配置を検討してください。
インターネット接続
ネットワーク・インタフェース・カード
ネットワーク配線
ネットワーク・スイッチ
ゲートウェイとルーター
アーキテクチャに冗長ロード・バランサを含めることによって、ロード・バランサがSPOFになる可能性を軽減できます。
データベースの破損が発生した場合は、可用性を確保するためのデータベース・フェイルオーバー方針が必要になります。冗長サーバー・コントローラを使用して、ストレージ・サブシステムのSPOFを軽減できます。コントローラとストレージ・サブシステム、冗長ストレージ・サブシステム・コントローラまたはRedundant Array of Independent Disks間で冗長配線を使用することもできます。
電源が1つのみの場合は、その電源が失われると、サービス全体が使用できなくなる可能性があります。この状況を回避するために、可能な場合はハードウェアに対する冗長電源を用意したり、電源を多様化することを検討してください。電源におけるSPOFを軽減する他の方法として、サージ保護装置、複数の電力会社およびローカル・バッテリ・バックアップの使用、ローカルでの発電などをあげることができます。
たとえば、特定の地理的領域での自然災害によって、データ・センター全体の障害が発生する可能性があります。この場合、適切に設計された、複数のデータ・センターのレプリケーション・トポロジにより、分散したディレクトリ・サービス全体が使用できなくなることを回避できます。詳細は、「高可用性のためのレプリケーションおよび冗長性の使用」を参照してください。
Directory ServerまたはDirectory Proxy Serverの障害には、次のようなものがあります。
極端に長いレスポンス時間
書込みの過負荷
最大化されたファイル記述子
最大化されたファイル・システム
適切でないストレージ構成
過剰な索引
読取りの過負荷
キャッシュの問題
CPUの制約
レプリケーションの問題
同時発生
レプリケーション伝播の遅延
レプリケーションのフロー
レプリケーションの過負荷
大規模なワイルドカード検索
これらのSPOFは、Directory ServerおよびDirectory Proxy Serverの冗長インスタンスを配置することによって軽減できます。ソフトウェア・レベルの冗長性では、レプリケーションが使用されます。レプリケーションにより、冗長サーバーが同期された状態に保たれ、停止時間なしでリクエストを再ルーティングできることが確実になります。詳細は、「高可用性のためのレプリケーションおよび冗長性の使用」を参照してください。
レプリケーションを使用すると、単一のサーバーが失われたことでディレクトリ・サービスが使用できなくなることを回避できます。信頼性のあるレプリケーション・トポロジを適用することにより、サーバーで障害が発生しても、複数のデータ・センターにわたるクライアントで、最新のデータを確実に使用できます。少なくとも、ローカル・ディレクトリ・ツリーを1つ以上のバックアップ・サーバーにレプリケートする必要があります。データの信頼性を最大化するには、物理的な場所ごとに3回レプリケートする必要があると考えるディレクトリ・アーキテクトもいます。フォルト・トレランスのためにレプリケーションをどの程度使用するかを決定するときは、ディレクトリで使用されるハードウェアとネットワークの品質を考慮します。信頼性の低いハードウェアに対しては、より多くのバックアップ・サーバーが必要になります。
レプリケーションを定期的なデータ・バックアップ・ポリシーのかわりに使用しないでください。ディレクトリ・データのバックアップの詳細は、「バックアップおよびリストア・ポリシーの設計」および『Oracle Directory Server Enterprise Edition管理者ガイド』の第8章「Directory Serverのバックアップおよびリストア」を参照してください。
LDAPクライアント・アプリケーションは、通常、1つのLDAPサーバーのみを検索するように構成します。異なるDNSホスト名に配置されたLDAPサーバーをローテーションするように、カスタム・クライアント・アプリケーションを作成できます。それ以外の場合、LDAPクライアント・アプリケーションは1つのDNSホスト名でのみDirectory Serverを検索するように構成できます。Directory Proxy Server、DNSラウンド・ロビンまたはネットワーク・ソートを使用して、バックアップDirectory Serverへのフェイルオーバーを提供できます。DNSラウンド・ロビンまたはネットワーク・ソートの設定および使用の詳細は、DNSのドキュメントを参照してください。このコンテキストでDirectory Proxy Serverを使用する方法の詳細は、「冗長ソリューションの一部としてのDirectory Proxy Serverの使用」を参照してください。
ディレクトリのデータを読み取る機能を維持するには、適切なロード・バランシング方針を適用する必要があります。読取り負荷を複数のレプリカに分散するために、ソフトウェアとハードウェアの両方のロード・バランシング・ソリューションが存在します。これらの各ソリューションでは、各レプリカの状態を確認したり、そのローカル・バランシング・トポロジへの参加を管理することもできます。ソリューションは、完全性と正確さに関して異なることがあります。
地理的に離れたサイトへの書込みフェイルオーバーを維持するために、WAN上で複数のデータ・センター・レプリケーションを使用できます。このためには、データ・センターごとに少なくとも2つのマスター・サーバーを設定し、サーバーをWAN上で完全にメッシュ化するように構成します。この方針により、トポロジ内のいずれかのマスターで障害が発生した場合に、サービスの損害が回避されます。書込み可能サーバーが使用できなくなった場合は、書込み操作を代替サーバーにルーティングする必要があります。Directory Proxy Serverなど、様々な方法を使用して書込み操作を再ルーティングできます。
次の各項では、高可用性を確保するためにレプリケーションおよび冗長性を使用する方法について説明します。
冗長レプリケーション承諾を使用すると、障害の発生時に迅速なリカバリが可能になります。レプリケーション承諾を有効および無効にできることは、元のレプリケーション・トポロジで障害が発生した場合にのみ使用されるレプリケーション承諾を設定できることを意味します。この操作は手動ですが、この方針を使用すると、必要に応じてレプリケーション承諾の設定を待機するよりも大幅に時間を短縮できます。冗長レプリケーション承諾の使用方法の説明は、「高可用性のために冗長性を使用するサンプル・トポロジ」を参照してください。
レプリカの昇格または降格により、レプリケーション・トポロジにおけるレプリカのロールが変化します。専用コンシューマとハブが含まれた非常に大規模なトポロジでは、高可用性の方針の一部として、レプリカのオンラインでの昇格および降格を含めることができます。たとえば、追加のロード・バランシングおよびフェイルオーバー用に2つのハブが構成されたマルチマスター・レプリケーション・シナリオを考えます。1つのマスターがオフラインになった場合は、最適な読取り/書込みの可用性を維持するために、いずれかのハブをマスターに昇格できます。マスター・レプリカがオンラインに戻ったときは、単にハブ・レプリカに降格することで、元のトポロジに戻ります。
詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリカの昇格と降格に関する説明を参照してください。
Directory Proxy Serverは、高可用性ディレクトリ・デプロイメントをサポートするように設計されています。このプロキシは、自動ロード・バランシングおよび一連のレプリケートされたDirectory Server間の自動フェイルオーバーや自動フェイルバックを提供します。トポロジ内の1つ以上のDirectory Serverが使用できなくなると、負荷は残りのサーバーに均等に再分散されます。
Directory Proxy ServerはアクティブにDirectory Serverを監視して、サーバーがまだオンラインであることを確認します。プロキシは、実行された各操作のステータスも調べます。すべてのサーバーでスループットとパフォーマンスが同じであるとはかぎりません。プライマリ・サーバーが使用できなくなった場合、セカンダリ・サーバーに一時的にリダイレクトされたトラフィックは、プライマリ・サーバーが使用できるようになると、すぐにプライマリ・サーバーに戻されます。
データを分散する場合は、複数の切断されたレプリケーション・トポロジを管理する必要がありますが、これにより、管理が複雑になります。さらに、Directory Proxy Serverでは、ユーザー認可の管理をプロキシ認可制御に大きく依存しています。分散に関与する各Directory Serverに特定の管理ユーザーを作成する必要があります。これらの管理ユーザーには、プロキシ・アクセス制御権限を付与する必要があります。
Directory Proxy Serverを使用して、レプリケートされたディレクトリ・サービスを問題のあるクライアント・アプリケーションが原因の障害から保護することもできます。可用性を改善するには、一連の制限されたマスターまたはレプリカを各アプリケーションに割り当てます。
問題のあるアプリケーションが特定のアクションを実行したときに、サーバーがシャットダウンされるとします。アプリケーションが連続する各レプリカにフェイルオーバーすると、あるアプリケーションに関する1つの問題が原因で、レプリケートされたトポロジ全体の障害が発生する可能性があります。このようなシナリオを回避するには、各アプリケーションのフェイルオーバーとロード・バランシングをかぎられた数のレプリカに制限できます。これにより、潜在的な障害はこの一連のレプリカに制限され、他のアプリケーションに対する障害の影響が減少します。
次のサンプル・トポロジでは、冗長性を使用して障害が発生しても継続的なサービスを提供する方法を示します。
次の図に示すデータ・センターには、3つのマスターを使用する、マルチマスター・トポロジがあります。このシナリオでは、3つ目のマスターは障害発生時の可用性を確保するためにのみ使用されます。問題が発生しない場合、読取り操作と書込み操作はDirectory Proxy Serverによってマスター1とマスター2にルーティングされます。リカバリを高速化し、レプリケーション承諾の数を最小限に抑えるために、リカバリ・レプリケーション承諾が作成されます。これらの承諾は、デフォルトでは無効ですが、障害の発生時に迅速に有効にできます。
図12-1に示すシナリオでは、様々なコンポーネントが使用できなくなる可能性があります。これらの潜在的な障害ポイントおよび関連するリカバリ・アクションを次の表に示します。
表12-1 単一のデータ・センターの障害マトリックス
| 障害が発生したコンポーネント | アクション |
|---|---|
|
マスター1 |
マスター1の修復中、読取り操作と書込み操作は、Directory Proxy Serverによってマスター2とマスター3に再ルーティングされます。マスター2とマスター3の間のリカバリ・レプリケーション承諾が有効になっているため、マスター3に対する更新はマスター2にレプリケートされます。 |
|
マスター2 |
マスター2の修復中、読取り操作と書込み操作は、マスター1とマスター3に再ルーティングされます。マスター1とマスター3の間のリカバリ・レプリケーション承諾が有効になっているため、マスター3に対する更新はマスター1にレプリケートされます。 |
|
マスター3 |
マスター3はバックアップ・サーバー専用であるため、このマスターで障害が発生しても、ディレクトリ・サービスは影響を受けません。マスター3は、サービスを中断することなくオフラインにして修復できます。 |
|
Directory Proxy Server |
Directory Proxy Serverで障害が発生すると、サービスは中断されます。このトポロジでは、Directory Proxy Serverの冗長インスタンスを使用することをお薦めします、このようなトポロジの例は、「複数のDirectory Proxy Serverの使用」を参照してください。 |
3つのマスターのある単一のデータ・センターでは、1つのマスターで障害が発生しても、読取りおよび書込み機能は維持されます。この項では、障害が発生したコンポーネントを回復するために適用できるサンプル・リカバリ計画について説明します。
次のフローチャートおよび手順では、1つのコンポーネント、マスター1で障害が発生したとします。2つのマスターで同時に障害が発生した場合は、問題の修復中に読取りおよび書込み操作を残りのマスターにルーティングする必要があります。
マスター1がまだ停止されていない場合は停止します。
障害の原因を特定します。
深刻な障害のトラブルシューティングを行うには、次の手順に従います。
マスター1にアクセスするアプリケーションがマスター2またはマスター3を指すようにDirectory Proxy Serverによってリダイレクトされることを確認します。
最新のバックアップを使用できるかどうかを確認します。
最新のバックアップを使用できる場合は、マスター1をバックアップから再初期化し、手順3に進みます。
最新のバックアップを使用できない場合は、次のいずれかを実行します。
マスター1を再起動し、マスター2またはマスター3からマスター1への全体的な初期化を実行します。
この手順の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリカの初期化に関する説明を参照してください。
全体的な初期化の実行時間が長すぎる場合は、マスター2またはマスター3からオンライン・エクスポートを実行し、マスター1にインポートします。
マスター1が起動していない場合は、起動します。
マスター1が読取り専用モードの場合は、読取り/書込みモードに設定します。
レプリケーションが正しく機能していることを確認します。
DSCCのdsccmon view-suffixesまたはinsyncコマンドを使用してレプリケーションを確認できます。
詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリケーション・ステータスの取得に関する説明、dsccmonおよびinsyncを参照してください。
一般的に、2つのデータ・センターのあるデプロイメントでは、単一のデータ・センターについて説明したものと同じリカバリ計画を適用できます。1つ以上のマスターが使用できなくなると、Directory Proxy Serverによって、ローカルの読取りおよび書込みが残りのマスターに自動的に再ルーティングされます。
前に説明した単一のデータ・センター・シナリオと同様に、リカバリ・レプリケーション承諾を有効にすることができます。これらの承諾により、両方のデータ・センターでは、障害が発生しても、引き続き、レプリケートされた更新を確実に受け取ることができます。このリカバリ計画を図12-3に示します。
リカバリ・レプリケーション承諾を使用するかわりに、すべてのマスターが変更を他のすべてのマスターにレプリケートする完全にメッシュ化されたトポロジを使用することもできます。レプリケーション承諾が少ないほど管理が容易になる可能性がありますが、完全にメッシュ化されたトポロジを使用しない技術的な理由は存在しません。
このシナリオにおける唯一のSPOFは、各データ・センターのDirectory Proxy Serverです。図12-4に示すように、冗長なDirectory Proxy Serverをデプロイすることで、この問題を解決できます。
リカバリ計画は、障害が発生するコンポーネントの組合せに依存します。ただし、複数の障害に対処するための基本的な計画を適用した後、他のコンポーネントで障害が発生した場合にその計画を適用できます。
図12-3に示すサンプル・トポロジでは、ニューヨークのデータ・センターのマスター1とマスター3で障害が発生したと想定しています。
このシナリオでは、Directory Proxy Serverによって、ニューヨークのデータ・センターの読取りと書込みがマスター2とマスター4に自動的に再ルーティングされます。これにより、ニューヨークのサイトで、ローカルの読取りおよび書込み機能が確実に維持されます。
次の図に示すデプロイメントには、内部LDAPサービスへの外部アクセスを拒否するエンタープライズ・ファイアウォールがあります。内部で開始されたクライアントのLDAPリクエストは、ネットワーク・ロード・バランサによってDirectory Proxy Serverに送信され、IPレベルの高可用性が確保されます。Directory Proxy Serverを実行しているホストを除き、Directory Serverへの直接アクセスは防止されます。プロキシがSPOFになることを防止するために、2つのDirectory Proxy Serverがデプロイされています。
完全にメッシュ化されたマルチマスター・トポロジを適用すると、他のマスターで障害が発生しても、確実に、いつでもすべてのマスターを使用できます。わかりやすくするために、この図には、一部のレプリケーション承諾のみ示されています。
次の図に示すシナリオでは、アプリケーション1のバグによってDirectory Serverで障害が発生します。プロキシ構成により、アプリケーション1からのLDAPリクエストは、確実にマスター1とマスター3に送信されます。バグが発生すると、マスター1とマスター3で障害が発生します。ただし、アプリケーション2、3および4はまだ動作中のDirectory Serverにアクセスできるため、無効になりません。
