Oracle Cloud Infrastructureドキュメント

高可用性

高可用性(HA)システムは、稼働時間とアクセシビリティを最大限実現できるように設計されています。

エンタープライズ・アプリケーションは日常業務に不可欠であり、使用可能である必要があります。これらのシステムは常に稼働していること、またダウンタイムが発生しないことが期待されています。ダウンタイムを完全になくすことは不可能ですが、アプリケーションにHAを持たせることで、ダウンタイムの影響を最小限に抑えることができます。HAを確保するには、コンポーネントに障害が発生してもアプリケーションが実行を続け使用可能になるように、単一障害点を排除します。Oracle Cloud Infrastructure(OCI)は、HAを備えたエンタープライズ・アプリケーションを作成できるHA機能および信頼性とレジリエンスのあるクラウド・トポロジのベスト・プラクティスを提供します。

従来のオンプレミス・エンタープライズ・アプリケーションでは複数層または3層アーキテクチャが一般的であるため、3層エンタープライズ・アプリケーションを例にとり、OCI HA機能および信頼性とレジリエンスのあるクラウド・トポロジのベスト・プラクティスを使用してアプリケーションのHAを実現する方法を示します。次の図は、単一リージョンのHA構成のエンタープライズ・アプリケーションの例を示しています。

単一リージョンの高可用性構成のエンタープライズ・アプリケーションの例。

この情報は、オンプレミスからOCIへの接続や、インフラストラクチャのディザスタ・リカバリ(DR)の側面については説明していません。

HAの概念

インフラストラクチャがほぼフルタイムの可用性を提供するように構成されている場合、それはHAシステムです。

高可用性アーキテクチャを設計するには、次の主要な要素について考慮してください:

  • 冗長性: 各リソースに、ステップ・インして引き継ぐ準備ができている類似のリソースが少なくとも1つありますか。図に示された各層では、リソースには常にプライマリとスタンバイがあり、また単一障害点(SPOF)を回避するためにリソースが異なる可用性ドメインおよびフォルト・ドメインにあることに注意してください。
  • モニタリング: プライマリ・リソースは期待どおりに機能していますか。そうでない場合、バックアップ・リソースはどの時点でプライマリを引き継ぎますか。
  • フェイルオーバー: プライマリからスタンバイへの切替えをトリガーする基準を満たした場合、スタンバイは準備できていますか。

HAを達成するには、システムでこれらのすべての要素が考慮されている必要があります。高可用性は多くの異なるレベル(アプリケーション・レベルやクラウド・インフラストラクチャ・レベルなど)で実現できますが、この項ではクラウド・インフラストラクチャ・レベルに重点を置いて説明します。詳細は、高可用性クラウド・トポロジの設計について学習を参照してください。

HAアプローチの選択

アプリケーションによってクリティカルの度合が異なります。次のディシジョン・ツリーを使用して、複数層エンタープライズ・アプリケーションをOCIにデプロイする際に使用するOCI HA機能を決定します。

複数層エンタープライズ・アプリケーションをデプロイする際に使用するOCI高可用性機能を決定するためのディシジョン・ツリー。

このエンタープライズ・アプリケーションの例では、HAが必要であり、可用性ドメインの停止に耐えられるようにする必要があります。リージョンの停止に耐えられるが、リージョンが影響を受けてもある程度のダウンタイムには対処できるようにする必要があります。これらの理由から、ここでは複数のリージョンへのアクティブ/パッシブ・デプロイメントを選択しました。パッシブ・デプロイメントの側面については、ディザスタ・リカバリで説明しています。

HAの測定

高可用性とは、システムが所定の期間、継続的な運用パフォーマンス・レベル(稼働時間)を満たせることです。

可用性は通常、1年間の稼働時間の割合で表され、多くの場合、「ナイン(9)の数」で表現されます。次の表に、可用性レベルと、各レベルの関連するダウンタイムを示します。

可用性% 可用性(ナイン) ダウンタイム/年 ダウンタイム/月 ダウンタイム/週 ダウンタイム/日
90% 1ナイン 36.53日 73.05時間 16.80時間 2.40時間
99% 2ナイン 3.65日 7.31時間 1.68時間 14.40分
99.9% 3ナイン 8.77時間 43.83分 10.08分 1.44分
99.99% 4ナイン 52.60分 4.38分 1.01分 8.64秒
99.999% 5ナイン 5.26分 26.30秒 6.05秒 864.00ミリ秒
99.9999% 6ナイン 31.56秒 2.63秒 604.80ミリ秒 86.40ミリ秒
99.99999% 7ナイン 3.16秒 262.98ミリ秒 60.48ミリ秒 8.64ミリ秒
99.999999% 8ナイン 315.58ミリ秒 26.30ミリ秒 6.05ミリ秒 864.00マイクロ秒
99.9999999% 9ナイン 31.56ミリ秒 2.63ミリ秒 604.80マイクロ秒 86.40マイクロ秒

各Oracle Cloud Infrastructureサービスには通常、そのサービスの期待される可用性を定義したサービス・レベル契約(SLA)があります。ほとんどのクラウド・ソリューションでは、クラウド・デプロイメントに必要なアーキテクチャを実現するために、サービスを組み合せて使用する必要があります。サービスを組み合せて使用する場合、全体的なシステムの可用性は各サブシステムの可用性に依存します。複数のコンポーネントを持つシステムの全体的なSLAは、複合SLAと呼ばれます。

システムまたはアプリケーションの複合SLAを計算するには、すべてのサブシステムおよびそれらのシステムの構成方法を考慮します。たとえば、アプリケーションが2つのシステム(システムAとシステムB)に依存しているシナリオについて考えてみます。各システムの可用性は99.9%です。次の図に示すように、システムどうしは連続的に依存しています。

連続的に依存するサブシステムを持つシステムの例を示す図。

システムAまたはシステムBが使用できない場合、全体のシステムが使用できなくなります。このタイプのシステム構成では、複合SLAは2つのシステムの可用性を乗算して計算できます(99.9%×99.9% = 99.8%)。2つのシステム間に連続的な依存関係があるため、結果の複合SLA (99.8%)は各システムの個別のSLAより低くなります。

HAの設計に関する考慮事項

Oracle Cloud Infrastructureには、インフラストラクチャのHAを有効にできるビルディング・ブロックが用意されています。

エンタープライズ・アプリケーションの例では、リージョン、可用性ドメインおよびフォルト・ドメインのOCI概念内のサービスを使用しています。複数の可用性ドメインを使用し、それらの各可用性ドメイン内で複数のフォルト・ドメインを使用すると、冗長性が向上し、SPOFが排除されます。リージョンに関するバックグラウンド情報、およびリージョン全体、単一リージョン内、または単一の可用性ドメイン内で使用可能なリソースのリストについては、リージョンおよび可用性ドメインを参照してください。

関連するOCI製品のレジリエンスの情報を確認してから、選択したOCIプラットフォーム製品に基づいて、製品の機能とそのHA要件の間のギャップに対応するようにアーキテクチャを調整することをお薦めします。

ホーム・リージョンは、Oracleによってテナンシが作成される場所です。また、組織のアイデンティティおよびアクセス管理(IAM)リソースはここで定義されます。ビジネス要件に応じて、他のリージョンにサブスクライブできます。IAMによって更新がテナンシ内のすべてのリージョンに自動的に伝播されます。詳細は、リージョンの管理を参照してください。

ネットワーキング

仮想クラウド・ネットワーク(VCN)およびサブネットのネットワーク基盤を作成した後、高可用性を提供するために、ロード・バランシング・サービスを使用してトラフィックを分散する必要があります。ロード・バランサがデプロイされると、アーキテクチャの例の図に示すようにHA構成が使用されます。詳細は、ネットワーク・リソースの高可用性の計画を参照してください。

コンピュート

SPOFを排除するために、各可用性ドメインのフォルト・ドメイン全体に分散された複数のコンピュート・インスタンスを作成します。アーキテクチャの例に示すように、コンピュート・インスタンスをロード・バランサの背後に配置してトラフィックを分散し、HAを実現します。詳細は、コンピュート・サービスの概要、コンピュート・インスタンスのベスト・プラクティスおよびコンピュート・インスタンスの高可用性の計画を参照してください。

ストレージ

OCIには、高可用性アーキテクチャの要件を満たすように構成できる一連のストレージ・サービス(ブロック・ボリューム、ファイル・ストレージおよびオブジェクト・ストレージ),が用意されています。

オブジェクト・ストレージは、信頼性とコスト効率の高いデータ耐久性を実現する、インターネット規模の高パフォーマンス・ストレージ・プラットフォームです。オブジェクト・ストレージはリージョナル・サービスであり、リージョン内のすべての可用性ドメインで使用できます。データは、高可用性を確保するために、複数のストレージ・サーバーおよび複数の可用性ドメインにわたって冗長的に格納されます。Object Storageには、自己修復とデータ整合性の自動監視も含まれており、耐久性と可用性をさらに強化します。

File Storageは、耐久性のあるスケーラブルで安全なエンタープライズ・グレードのネットワーク・ファイル・システムを提供します。異なるフォルト・ドメイン間で5回データをレプリケートする自己回復性アーキテクチャを使用して、高可用性と耐久性を確保します。File Storageは、最大8エクサバイトのデータの増加に対応するように自動的にスケーリングできます。ファイル・システムのスナップショットおよびクローンを使用して、偶発的な削除からデータを保護し、データのコピーを即時に作成できます。スナップショットのライフサイクルは、ポリシー・ベースのスナップショット機能を使用して自動的に管理できます。

ブロック・ボリュームには耐久性と可用性があり、修復メカニズムが組み込まれたストレージ・サーバーに複数のデータ・コピーを冗長的に格納します。ブロック・ボリュームは、1つまたは複数の仮想マシン(VM)にアタッチでき、仮想マシンの存続期間を超えて保持されます。ブロック・ボリュームは、オブジェクト・ストレージへの自動バックアップおよびボリューム・クローニング機能により、高可用性をさらに強化します。

ストレージ・リソースを作成するステップについては、ボリュームの作成、ファイル・システムの作成およびバケットの管理を参照してください。ベスト・プラクティスについては、ストレージの高可用性の計画に関する項を参照してください。

データベース

OCI Oracleデータベースは、複数のデプロイメント・モデルまたはフレーバーを備えています。各モデルでは、HA機能のセットが増加しています。

使用されるデータベース・システムに関係なく、Maximum Availability Architecture (MAA)を参照することをお薦めします。これは、Oracle高可用性テクノロジ、データ保護テクノロジおよびディザスタ・リカバリ・テクノロジを統合して使用するために、Oracleエンジニアによって何年にもわたって開発された一連のベスト・プラクティスであるためです。

OCI Base Databaseサービス

OCI Base Database Serviceでは、Oracle DatabaseとOCIの機能を活用しながら、データを完全に制御できます。サポートされているデータベース・エディションおよびそれらをデプロイできる基礎となるコンピュート・シェイプのリストは、OCIベース・データベース・サービスのドキュメントを参照してください。前述のHA機能は、すべてのデータベース・バージョンまたは基礎となるコンピュート・シェイプに適用されます。

Enterprise Edition Extreme Performance Editionでは、2ノードのReal Application Cluster (RAC)データベース・システムを、同じ可用性ドメイン内の異なるフォルト・ドメインにまたがるノードで使用できます。これにより、次のシナリオで高可用性が提供されます。

  • ノード障害保護
  • ダウンタイムなしのソフトウェア・メンテナンス
  • ダウンタイムのない柔軟な変更(CPU、メモリー、ストレージ)
  • (ほぼ)透明な計画外メンテナンス

可用性ドメイン間でHAが必要な場合は、Oracle Data Guardを介してレプリケートされたデータを使用して、プライマリRACデータベース・システムをミラー化するパッシブ・スタンバイRAC対応データベースを検討できます。パッシブ・スタンバイへのフェイルオーバーは、わずかな停止時間で手動で実行できます。

ノート: OCIベース・データベースでは、最大2つのRACノードがサポートされています。Oracle Databaseのバージョンまたは2より大きいRACノードの場合は、OCI Exadata Database on Dedicated Infrastructure (ExaDB-D)を検討してください。

専用インフラストラクチャ上のExadata Database(ExaDB-D)

Exadataは、組込みの高可用性機能を提供します。

オンプレミスのExadataに関する既存のベスト・プラクティスはすべて適用可能です。RACやData Guard (スタンバイ・データベース用)など、OCIベース・データベースについて記述されている概念は、Exadata Database on Dedicated Infrastructure (ExaDB-D)に適用でき、次の追加属性があります。

  • Exadata Database on Dedicated Infrastructure (ExaDB-D)では、2つ以上のRACノードを使用できます。これは、ベース・データベース・システムとの制限です。
  • Exadataのスケーラビリティ、パフォーマンスおよび可用性
  • Exadataの俊敏性: さまざまなVM、ストレージ、コンピューティング・リソースに対応
  • データベース操作用のデータ保護およびExadata QoS

Exadataには、データベース・ノード、ストレージ・サーバーおよびネットワークの障害を2秒未満で検出し、アプリケーションおよびデータベース・サービスの稼働時間およびパフォーマンスを再開できる即時障害検出があります。

アプリケーションの継続的な可用性を確保するために、次の構成をお薦めします。

Autonomous Database

デフォルトでは、Oracle Autonomous Database (ADB)の可用性は高く、局所的なハードウェア障害から保護するマルチノード構成が組み込まれています。

それぞれのADBアプリケーション・サービスは、少なくとも1つのOracle Real Application Clusters (Oracle RAC)インスタンスに配置され、計画外停止または計画メンテナンス・アクティビティの際に別の使用可能なOracle RACインスタンスにフェイルオーバーするオプションを備えており、ゼロまたはゼロに近い停止時間を実現します。

データベースのメジャー・アップグレードは自動化されています。また、Oracle Autonomous Database Serverless (ADB-S)のダウンタイムは最小限です。

1か月の稼働時間に関するサービス・レベル合意(SLA)は99.95% (1か月に最大22分の停止時間)です。

ADB-Sでは、1つのローカル(AD全体または1つのADリージョンのAD内)と、追加のリモート・スタンバイを使用できます。

Autonomous Data Guardは、Oracle Data Guardを含む1つの対称スタンバイ・データベースをローカル(AD間または単一のADリージョンのAD内)のExadataラックに追加し、別のリージョンに追加データベースを追加します。プライマリ・データベース・システムとスタンバイ・データベース・システムは、Data Guardロールの推移後にパフォーマンス・サービス・レベルが維持されるように対称的に構成されます。

アプリケーションの稼働時間を維持するためのベスト・プラクティスは、ここで説明されています。

モニタリング

モニタリングを使用すると、クラウド・リソースをアクティブおよびパッシブにモニターして、可用性の向上と一貫したサービス・レベルを実現できます。例については、Oracle Cloud Infrastructureで実行されているアプリケーションのエンドツーエンド・モニタリングを参照してください。

詳細の参照

ソリューション・プレイブック:

リファレンス・アーキテクチャ:

ブログおよびその他のリソース: