ヘッダーをスキップ
Oracle® Database高可用性概要
11gリリース2 (11.2)
B56308-04
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

5 投資利益率(ROI)の最適化

Oracleグリッド・コンピューティング、障害時リカバリ・ソリューションとスタンバイ・データベースの高度な使用、および仮想化は、すべて投資利益率(ROI)の最適化に役立ちます。

高可用性および防災の両方を実現しながら、既存のシステム・インフラストラクチャをスケールアウトできます。Oracle Data Guardスタンバイ・データベースはグリッドに不可欠な部分であり、停止の原因や範囲に関係なく、データ保護および可用性を提供します。停止の原因は、個々のデータベースに影響するデータ破損から広い地域に影響を及ぼす自然災害まで様々です。

Data Guardの高度な機能は、スタンバイ・ロールでもスタンバイ・データベースを(読取り専用問合せやレポート作成などの)本番用に使用することを可能にし、最大のROIをもたらします。スタンバイ・データベースをアイドル状態にしておくかわりに、これらを利用してアクティビティをサポートできるため、他のシステム用に追加の容量を購入する必要がありません。また、プライマリ・データベース用の容量を追加購入する必要がなくなるか、購入を見合せることができます。これにより、ミッション・クリティカルなOracle Databaseに対する世界レベルの防災のコストを効果的に削減できます。

この章の内容は次のとおりです。

5.1 グリッド・コンピューティング

グリッド・コンピューティングとは、あらゆる企業のコンピューティング・ニーズに応えるため、多数のサーバーおよびストレージを柔軟性のあるオンデマンド・コンピューティング・リソース内に効果的にプールするコンピューティング・アーキテクチャです。

Oracle Databaseには、パフォーマンス、スケーラビリティ、セキュリティ、管理性、機能性またはシステム可用性を犠牲にせずに、コスト面におけるグリッド・エンタープライズ・コンピューティングの利点が取り込まれています。

  • データベース・サーバー・グリッドは、1つ以上のデータベースを実行するために接続された汎用サーバーの集合です。

  • データベース・ストレージ・グリッドは、相互に組み合され、データベース・サーバー・グリッド内のコンピュータからアクセスされる低コストのモジュラ・ストレージ・アレイの集合です。

同じグリッド・コンピューティングの概念を使用して、データ保護、計画停止時間の最小化、品質保証テストに適したテスト・システムなどを複数のプライマリ・データベースに対して提供する、スタンバイ・データベースのハブを作成できます。グリッドの機能により、現在の優先順位に応じて、システム・リソースの動的プロビジョニングおよびプロビジョニング解除が可能です。たとえば、プライマリ・データベースがData Guardハブのいずれかのスタンバイ・データベースにフェイルオーバーした場合、テスト・アクティビティに割り当てられているリソースが減少している間、そのスタンバイ・データベースにより多くのシステム・リソースとストレージ・リソースを割り当てることができます。グリッドでは、ビジネス要件を損うことなく、高レベルの使用率と低TCOが可能になります。

図5-1に、グリッド・エンタープライズ・コンピューティング環境内のデータベース・サーバー・グリッドおよびデータベース・ストレージ・グリッドを示します。

図5-1 グリッド・コンピューティング環境

図5-1の説明が続きます
「図5-1 グリッド・コンピューティング環境」の説明

5.2 データベース・サーバー・グリッド

低コストのおよび信頼性のあるブレード・サーバーの可用性、小規模のマルチ・プロセッサ・サーバーおよびLinuxなどの安価なオープンソース・オペレーティング・システムによって、可用性、スケーラビリティ、柔軟性および管理性が非常に高いデータベース・サーバー・グリッドの構築が可能になりました。

Oracle RACはデータベース・サーバー・グリッドを有効にするテクノロジです。それぞれがOracleデータベースのアクティブなインスタンスを実行する複数の低コスト・サーバーにわたって、単一のOracle RACデータベースをデプロイすることで、コストを下げることができます。もしくは、単一クラスタを使用して、Oracle RACの複数のデータベースにわたるシステム使用率増加の管理を統合できます。

Oracle RACによって、グリッド内の動的プロビジョニング・リソースおよびサービスに柔軟性が与えられ、コンピューティング・ニーズの変化に対応し、容量への需要増加に合せてグリッドにシステムを追加したり、システムを削除できます。また、Oracle RACでは、クライアントの自動遷移、および障害が発生したノードから同じOracle RACデータベース内の残りのノードに処理を再分散することで、システム障害からの保護が提供されます。グリッド・コンピューティングのスケーラビリティおよび可用性の利点は、低コストのサーバーに限定されるものではありません。グリッド・コンピューティングは、すべてのシステム・アーキテクチャに効果があります。

5.3 データベース・ストレージ・グリッド

低コストのAdvanced Technology Attachment(ATA)ディスクベース・ストレージ・アレイおよびストレージ・ネットワークの可用性により、Oracle Databaseでデータベース・ストレージ・グリッドを非常に低コストで使用できるようになりました。ソリューションの一例は、パフォーマンスおよび可用性に関して優れた特性を提供するOracle Exadata Storage Serverです。各Exadataセルを、I/Oのパフォーマンスとキャパシティの単位で表示できます。

Oracle Storage Gridは、Oracle Automatic Storage Management(ASM)とOracle Exadata Storage Server Software、またはASMとサード・パーティのストレージを使用して実装されます。Exadataを使用したOracle Storage Gridを使用すると、MAA関連のテクノロジをシームレスにサポートでき、パフォーマンスが向上し、無制限のI/Oスケーラビリティが得られます。また、使用および管理が容易で、企業はミッション・クリティカルな可用性および信頼性を得られます。Oracle Storage Gridの推奨事項およびExadataの使用方法は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。

データベース管理者は、Oracle ASMインタフェースを使用して、Oracle ASMがすべてのサーバーおよびストレージ・プラットフォームにわたり管理するデータベース・ストレージ・グリッド内のディスクを指定できます。Oracle ASMは、ディスク領域をパーティション化し、ストレージ・アレイ全体でデータ記憶域を均一に分散します。さらに、ストレージ・アレイがデータベース・ストレージ・グリッドに追加または削除される際、Oracle ASMは自動的にデータ記憶域を再分散します。

また、I/Oリソース管理を使用して管理し、サービス・レベルの要件を満たすことができます。リソース・マネージャは、データベース内またはデータベース間でのグリッドおよび優先アプリケーションの管理を可能にします。

5.4 アクティブ・スタンバイ・データベースを使用した障害時リカバリ

スタンバイ・データベースは、障害時リカバリの提供に加えて、ITおよびアプリケーションの動的な要件を満たすために利用できます。Oracle Data GuardのOracle Active Data Guardオプションを使用すると、障害時リカバリ・ソリューションを提供する以外に、通常操作時に他の有用な作業にフィジカル・スタンバイ・データベースを使用できます。

次の項では、他のビジネス目的でフィジカル・スタンバイ・データベースを利用できるOracle Data Guardの機能について説明します。

5.4.1 フィジカル・スタンバイ・データベースのOracle Active Data Guardオプション

Data GuardのREDO Apply(フィジカル・スタンバイ・データベース)は、相対的に簡単なことと、高パフォーマンスおよび高度なデータ保護のために、障害時リカバリの一般的なソリューションになっています。Oracle Active Data Guardオプション脚注1(Oracle Database 11gリリース1(11.1)以降のリリースで使用可能)を使用すると、REDO Applyがアクティブである間、読取り専用アクセスのためにフィジカル・スタンバイ・データベースをオープンできます。そのため、データ保護を犠牲にしたり、フェイルオーバーが必要な場合のリカバリ時間を延長したりせずに、最新のフィジカル・スタンバイ・データベースに対して問合せやレポート作成を実行できます。読取り専用のワークロードをプライマリ・データベースからアクティブ・スタンバイ・データベースにオフロードすると、パフォーマンスが向上し、追加の容量の購入を見送ることができます。

Oracle Active Data Guardオプションを有効にするには、読取り専用モードでデータベースを開き、ALTER DATABASE RECOVER MANAGED STANDBY文を発行します。プライマリ・データベースとフィジカル・スタンバイ・データベースの両方で、COMPATIBLEパラメータを11.0.0以上に設定する必要があります。この機能の使用は、Oracle Databaseへの読取り専用アクセスを必要とするすべてのアプリケーションに対して完全に透過的です。

Oracle Active Data Guardオプションは、次の機能により、究極の高可用性ソリューションを提供します。

  • プライマリ・データベースとスタンバイ・データベースでOracle RACをサポートします。

    Oracle Active Data Guardオプションは、単一インスタンスおよびOracle RACのフィジカル・スタンバイ・データベースの両方で機能します。REDO Applyは1つのOracle RACインスタンスでのみ実行できますが、適用インスタンスを含むすべてのインスタンスを読取り専用モードで実行できます。

  • プライマリ・データベースの最新状態にきわめて近い一貫した結果を、トランザクションにより返します。

    遅延設定や適用頻度により、スタンバイ・データベースはプライマリ・データベースと同時か何秒か遅れます。問合せは、常にトランザクションでは一貫しており、そのときの最後にコミットしたトランザクションの一貫したビューを示します。

  • スタンバイ・データベースが読取り専用で開いているときに、プライマリ・データベースで生成されたREDOがスタンバイ・データベースにすでに適用され、スタンバイ・データベースがプライマリ・データベース・ロールをすぐに引き継ぐことができるため、高速なスイッチオーバーまたはフェイルオーバーが可能です。

  • プライマリ・データベースに障害が発生した場合、ファスト・スタート・フェイルオーバーを自動フェイルオーバーのために使用できます。


注意:

Oracle Active Data Guardが有効な実行中のフィジカル・スタンバイ・データベースをトランザクションが変更しようとすると、そのトランザクションはエラーで失敗します。

Oracle Active Data Guardの使用の詳細は、『Oracle Data Guard概要および管理』を参照してください。

5.4.2 スタンバイ・リーダー・ファームを使用したWebスケール

複数のフィジカル・スタンバイ・データベース(Oracle Active Data Guardオプションを使用)とロジカル・スタンバイ・データベースを使用して、リーダー・ファームをデプロイできます。このような構成の例を図5-2に示します。この図は、プライマリ・データベースに障害が発生した場合、Oracle Data Guardのファスト・スタート・フェイルオーバーを使用してフェイルオーバーが自動的に行われることを示しています。フェイルオーバーが行われると、リーダー・ファームのすべてのスタンバイ・データベースは、新しいプライマリ・データベースを自動的に認識することに注意してください。

リーダー・ファームを使用すると、基本的なシステムおよびストレージ・アーキテクチャのサポート可能範囲を超えて、最も要求の厳しいWebアプリケーションの読取りパフォーマンスを向上できます。これにより、I/Oが駆動要因となるグリッド・アーキテクチャを使用して拡張を行う比較的低コストの方法が可能になります。

この概念は単純です。つまり、1つのプライマリ・データベースが読取り/書込みのトランザクションをサポートし、複数のスタンバイ・データベースがWebユーザーに読取り専用アクセスを提供します。このようなアプローチでは、スタンバイ・データベースが追加されるにつれて、読取りパフォーマンスが直線的に高まります。また、1つのスタンバイ・データベースに影響を及ぼす問題が構成内の他のスタンバイ・データベースから分離されるため、フォルトを分離する効果的な方法でもあります。

フィジカル・スタンバイ・データベースのリーダー・ファームを作成する利点には次のようなものがあります。

  • フォルトの分離

  • フィジカル・スタンバイ・データベースとREDO Applyによる高パフォーマンス

  • REDO Applyを使用した、すべてのDDLとデータ型のシームレス・サポート

  • プライマリ・データベースの変更を含めて、すべてのリーダー・データベースを最新の状態に維持

  • データ損失をゼロまたは最小限に抑えた、自動フェイルオーバー機能

  • グリッド・コントロールによる一元的な構成としての管理

  • 1つのライター・データベースとn個のリーダー・データベースを使用した拡張

  • ローリング・アップグレード機能

図5-2は、Oracle Data Guard、フィジカル・スタンバイ・データベースおよびOracle Active Data Guardオプションを使用して、ビジネスの迅速な成長に必要な柔軟性を提供し、その一方で障害時リカバリも提供する適切な使用例を示しています。この構成では、プライマリ・データベースはREDOデータを複数のスタンバイ・データベースに転送し、そのうちの1つが、データ損失をゼロまたは最小限に抑えた自動フェイルオーバーを行うファスト・スタート・フェイルオーバー用に有効になっています。

図5-2 スタンバイ・データベースのリーダー・ファーム

図5-2の説明が続きます
「図5-2 スタンバイ・データベースのリーダー・ファーム」の説明

図5-2のOracle Data Guard構成で、ファスト・スタート・フェイルオーバーがトリガーされるとします。

  • 自動フェイルオーバーは目的のスタンバイ・データベースに対して行われます。

  • すべてのスタンバイ・データベースは新しいプライマリ・データベースからデータを受け入れます。

  • スイッチオーバーを適宜実行して、すべてのデータベースを元のロールに戻すことができます。

5.5 Oracle VMとドメイン・ライブ・マイグレーション

グリッド・コンピューティング、スタンバイ・データベースを高度に使用した障害時リカバリ・ソリューション、および仮想化は、すべてROIの改善に役立ちます。仮想化の主な利点には、統合や、すべてのリソースを効率的に使用することが含まれます。

Oracle VMを使用すると、サポートされている仮想化環境内にオペレーティング・システムとアプリケーション・ソフトウェアをデプロイできます。各仮想マシンには独自の仮想CPU、ネットワーク・インタフェース、記憶域およびオペレーティング・システムがあるため、Oracle VMでは基礎となるハードウェアの物理制約からワークロードが分離されます。Oracle VMは、計画サーバー停止またはワークロードの不均衡と関連したサービス停止を大幅に減らす機会を提供します。Oracle VMのドメイン・ライブ・マイグレーション機能を使用して、ドメインを1つの物理サーバーから、仮想マシンが稼働しているもう1つの同質のコンピュータに移行すると、可用性を高めることができます。たとえば、次のことができます。

  • 障害が発生したサーバーから、修復中に操作を続けられる存続能力のあるサーバーにドメインを移行

  • 1つのサーバーが過負荷にならないようにワークロードをリバランス

移行中もドメインではサービスの提供は続けられ、エンド・ユーザーは何の変化にも気付きません。


関連項目:




脚注の凡例

脚注1: Oracle Active Data GuardはOracle Data Guardドキュメントではリアルタイム問合せと呼ばれます。