oracle cloud infrastructure上に高可用性アーキテクチャを ......3 | best practices for...

Oracle Cloud Infrastructure上に高可用性アーキテクチャをデプロイする際のベスト・プラクティス O R A C L E R E F E R E N C E A R C H I T E C T U R E | 2 0 1 9 年 2 月

2 | BEST PRACTICES FOR DEPLOYING HIGH AVAILABILITY ARCHITECTURE ON ORACLE CLOUD INFRASTRUCTURE

改訂履歴

このホワイト・ペーパーには、初版発行以来、次の改訂が加えられています。

更新日改訂内容

2018/10/5 フォルト・ドメインに関する情報を追加。

単一の可用性ドメインへのデプロイメントのシナリオを追

加。

Oracle Cloud Infrastructureホワイト・ペーパーの最新版はhttps://cloud.oracle.com/iaas/technical-

resourcesでご覧いただけます。

https://cloud.oracle.com/iaas/technical-resources

https://cloud.oracle.com/iaas/technical-resources


目次

改訂履歴 2

要約 4

はじめに 4

高可用性の構成要素 4

高可用性ソリューションのアーキテクチャ 6

コンピュートの高可用性設計 6

ネットワークの高可用性設計 9

ロード・バランシングの高可用性設計 9

FastConnectと VPNの高可用性設計 12

ストレージの高可用性設計 18

データベースの高可用性設計 20

結論 23


要約

このリファレンス・アーキテクチャ・ペーパーでは、オラクルのお客様とパートナ向けに、

Oracle Cloud Infrastructure上にデプロイされる高可用性(HA)ソリューションを設計する際のアー

キテクチャ関連のベスト・プラクティスを示します。Oracle Cloud Infrastructure固有の様々な機

能を活用する方法についても詳しく説明します。

はじめに

このリファレンス・アーキテクチャ・ペーパーでは、Oracle Cloud Infrastructure上で高可用性

(HA)アーキテクチャをプランニング、設計、デプロイする際に必要なベスト・プラクティスを示

します。

高可用性サービスまたはアプリケーションとは、最大限のアップタイムとアクセス可能性が得ら

れるように設計されたサービスまたはアプリケーションです。高可用性アーキテクチャを設計す

る場合、3つの重要な要素である冗長性、監視およびフェイルオーバーについて考える必要があ

ります。

冗長性とは、複数のコンポーネントが同じタスクを実行できることを意味します。冗長

コンポーネントは障害の発生したコンポーネントで実行されていたタスクを引き継ぐこ

とができるので、単一障害点の問題が解消されます。

監視とは、コンポーネントが正しく動作しているかどうかをチェックすることです。

フェイルオーバーとは、プライマリ・コンポーネントに障害が発生したときに、セカン

ダリ・コンポーネントがプライマリになるプロセスです。

本書では、この3つの重要な要素に焦点を当てたアーキテクチャ設計について説明します。高可

用性はアプリケーション・レベルやクラウド・インフラストラクチャ・レベルをはじめとする多

様なレベルで実現できますが、本書ではクラウド・インフラストラクチャ・レベルに注目します。

高可用性の構成要素

Oracle Cloud Infrastructureリージョンとは、1つ以上の可用性ドメインで構成されるローカルの地

理的エリアです。各可用性ドメインは、3つのフォルト・ドメインで構成されます。

可用性ドメインとは、リージョン内にある1つ以上のデータ・センターです。可用性ドメインは

相互に分離され、フォルト・トレラントで、複数の可用性ドメインが同時に障害を起こすことは

ほぼありません。可用性ドメインは電源や冷却装置、内部可用性ドメイン・ネットワークなどの

物理インフラストラクチャを共有しないため、ある可用性ドメインに影響を及ぼす障害が他の可

用性ドメインの可用性に影響を及ぼす可能性は低くなります。

フォルト・ドメインとは、可用性ドメイン内のハードウェアとインフラストラクチャをグループ

化したものです。各可用性ドメインに3つのフォルト・ドメインが含まれています。フォルト・


ドメインによってインスタンスを分散させ、単一の可用性ドメイン内の同じ物理ハードウェアに

インスタンスが集中するのを避けることができます。そのため、あるフォルト・ドメインに影響

を及ぼすハードウェア障害やComputeハードウェアのメンテナンスが他のフォルト・ドメイン内

のインスタンスに影響を及ぼすことはありません。新規インスタンスのフォルト・ドメインを運

用開始時に指定することも、フォルト・ドメインが自動的に選択されるようにすることも可能で

す。

リージョン内の可用性ドメインはすべて、低レイテンシ、広帯域幅のネットワークで相互に接続

されています。可用性ドメイン間のこの予測可能な暗号化された相互接続は、高可用性と災害復

旧の両方を実現するための構成要素となります。

図1.高可用性の構成要素

Oracle Cloud Infrastructureのリソースは、リージョン固有(仮想クラウド・ネットワークなど)また

は可用性ドメイン固有(Computeインスタンスなど)のいずれかです。クラウド・サービスを構成

する際、サービスが可用性ドメイン固有の場合は、複数の可用性ドメインまたはフォルト・ドメ

インを活用して、高可用性を確保すること、およびリソース障害から保護することが重要です。

他の可用性ドメインまたはフォルト・ドメインに冗長Computeインスタンスを作成することで、

プライマリComputeインスタンスまたはそのドメインに影響を及ぼす問題によってアプリケー

ションが影響を受けるのを防止できます。

保護の対象となる障害のクラスに応じて、複数のリージョン、複数の可用性ドメインまたは複数

のフォルト・ドメインを使用したソリューションを設計できます。


高可用性ソリューションのアーキテクチャ

この項では、Oracle Cloud Infrastructureの各レイヤーについて説明し、高可用性ソリューション

を設計する際のベスト・プラクティスと設計ガイドラインを詳しく示します。

図2.Oracle Cloud Infrastructureのアーキテクチャ概要

コンピュートの高可用性設計

Oracle Cloud Infrastructure Computeは、ベア・メタルと仮想マシン(VM)両方のインスタンスを提

供し、単一コアの小規模なVMから52のコアと768GBのRAMを備えたベア・メタル・サーバーま

で、必要なサイズのサーバーをデプロイできる柔軟性をもたらします。これらのオプションによ

り、最も要求の厳しいアプリケーションやワークロードをクラウドで実行するためのパフォーマ

ンス、柔軟性およびコントロールが得られます。

単一障害点の解消

高可用性ソリューションを設計する際の重要な原則の1つに、単一障害点を回避することがあり

ます。

単一の可用性ドメインへのデプロイメント

可用性ドメインにはそれぞれ3つのフォルト・ドメインがあります。フォルト・ドメインを正し

く活用すれば、Oracle Cloud Infrastructure上で実行するアプリケーションの可用性を高めること

ができます。

アプリケーションのアーキテクチャにより、フォルト・ドメインを使用してインスタンスを別々

に扱うか、グループ化するかが決まります。

シナリオ 1: 可用性が高いアプリケーションのアーキテクチャ

このシナリオでは、アプリケーションの高可用性が確保されます。たとえば、2つのWeb

サーバーとクラスタ・データベースのような構成です。このシナリオでは、1つのWeb


サーバーと1つのデータベース・ノードを1つのフォルト・ドメインに、各ペアの残りの

半分を別のフォルト・ドメインにグループ化します。このアーキテクチャの場合、いず

れかのフォルト・ドメインで障害が発生しても、アプリケーションが停止する結果にな

らないことが保証されます。

シナリオ 2: 単一のWebサーバーとデータベース・インスタンスのアーキテクチャ

このシナリオでは、アプリケーション・アーキテクチャの可用性は高くありません。た

とえば、1つのWebサーバーと1つのデータベース・インスタンスのような構成です。こ

のシナリオでは、Webサーバーとデータベース・インスタンスの両方を同じフォルト・

ドメインに配置する必要があります。このアーキテクチャの場合、アプリケーションは

その単一フォルト・ドメインの影響しか受けないことが保証されます。

複数の可用性ドメインへのデプロイメント

高可用性を得るもう1つの方法は、同じタスクを実行するComputeインスタンスを複数の可用性

ドメインにデプロイすることです。この設計は、冗長性を取り入れることで、単一障害点を排除

します。

次の図は、冗長性を実現するために2つの可用性ドメインにデプロイされたWebサーバーVMを示

しています。

図3. WebサーバーVMを2つの可用性ドメインにデプロイ

このアーキテクチャの冗長性は、システムやアプリケーションの要件に応じて、スタンバイ・

モードまたはアクティブ・モードのいずれかで実現できます。

スタンバイ・モードの場合、セカンダリ(スタンバイ)コンポーネントがプライマリ・コン

ポーネントと並列で実行されます。プライマリ・コンポーネントに障害が発生すると、


スタンバイ・コンポーネントが引き継ぎます。スタンバイ・モードは通常、稼働状態を

維持する必要のあるアプリケーションに使用されます。

アクティブ・モードの場合、プライマリまたはスタンバイに指定されるコンポーネント

はありません。すべてのコンポーネントが同じタスクの実行に能動的に参加します。い

ずれかのコンポーネントに障害が発生すると、関連するタスクは単に別のコンポーネン

トに割り振られます。アクティブ・モードは通常、ステートレス・アプリケーションに

使用されます。

フローティングIPアドレス

ComputeインスタンスのフローティングIPアドレスは、セカンダリ・プライベートIPアドレスで

あれ、予約済のパブリックIPアドレスであれ、Oracle Cloud Infrastructure上での高可用性アーキ

テクチャの設計において重要な役割を果たします。

Computeインスタンスにはセカンダリ・プライベートIPアドレスを割り当てることができます。

Computeインスタンスに問題が発生した場合、セカンダリ・プライベートIPアドレスを同じサブ

ネット内のスタンバイ・インスタンスに割り当てなおすことで、インスタンスのフェイルオー

バーを実現できます。

予約済のパブリックIPアドレスは、永続的なものとして、現在割り当てられているComputeイン

スタンスの存続期間を超えて存在することができます。高可用性およびフェイルオーバーのシナ

リオでは、予約済のパブリックIPアドレスをプライマリ・インスタンスから割当て解除して、ス

タンバイ・インスタンスに割り当てなおすことができます。

このフローティングIPアドレスのフェイルオーバーは、CorosyncやPacemakerなどのLinux高可

用性サービスを活用することで自動化できます。

データの可用性と完全性

高可用性アーキテクチャでは、Computeインスタンスにおけるデータの可用性と完全性の両方を

設計によって確実に保護することが重要です。Computeインスタンスのデータの可用性を保護す

るには、データを別の場所にレプリケートまたはバックアップします。

Computeインスタンスに障害が発生した場合、同期または非同期のレプリケーションを使用して

データを保護できます。

前の項で述べたように、Oracle Cloud Infrastructureの可用性ドメインは、相互の距離が十

分に近く、ネットワークのパフォーマンスも高いため、同期レプリケーションをサポー

トしています。アプリケーションが即時フェイルオーバーを必要としており、データ損

失を許容できない場合は、同期レプリケーションをお薦めします。ネットワークのパ

フォーマンス要件により、同期レプリケーションは通常、1つのリージョン内で使用され

ます。


すべてのリージョンにわたってデータの可用性を保護する必要のあるアプリケーション

には、非同期レプリケーションをお薦めします。

従来のバックアップもデータを保護する方法の1つです。データの耐久性を最大限に高めるため

に、バックアップは元のComputeインスタンスと同じ可用性ドメインに格納しないでください。

Oracle Cloud Infrastructure Object Storageを使用してComputeインスタンスのデータをバック

アップすることをお薦めします。

ローカルNVMeドライブを備えたComputeインスタンスの場合、NVMeデバイスの障害から保護

する方法として最も推奨されるのは保護されたRAIDアレイです。

ネットワークの高可用性設計

Oracle Cloud Infrastructureを使用する上での最初のステップの1つは、クラウド・リソース用に仮

想クラウド・ネットワーク(VCN)を設定することです。VCNとは、Oracle Cloudデータ・セン

ター内に設定するソフトウェア定義のネットワークです。サブネットとは、クラウド・ネット

ワークの下位区分です。ネットワークの高可用性を確保することは、アーキテクチャ設計におい

て最も重要な要素の1つです。

サブネットの適切なサイズの決定

VCNの各サブネットは単一の可用性ドメインに存在し、クラウド・ネットワーク内の他のサブ

ネットと重複しないIPアドレスの連続した範囲(172.16.1.0/24など)で構成されます。サブネット

のCIDRにある最初の2つのIPアドレスと最後のIPアドレスは、Oracle Cloud Infrastructure

Networkingサービスによって予約されています。サブネットは作成したらサイズを変更できない

ため、サブネットを作成する前に必要なサイズについて考えることが重要です。ワークロードの

将来的な成長を考慮し、高可用性要件(スタンバイComputeインスタンスを設定する必要性など)

を満たすために十分な容量を残してください。

ロード・バランシングの高可用性設計

Oracle Cloud Infrastructure Load Balancingは、1つのエントリ・ポイントから、仮想クラウド・

ネットワーク(VCN)からアクセス可能な複数のサーバーへの自動トラフィック分散を実現します。

このサービスは、お客様が選択したパブリックIPアドレスまたはプライベートIPアドレスとプロ

ビジョニングされた帯域幅によるロード・バランサを提供します。

Load Balancingサービスは、リソースの利用率を高め、スケーリングを促進するとともに、高可

用性を確保できるよう支援します。仮想ホスト名またはパス・ルート・ルール、あるいはその2

つの組合せに基づいて、受信リクエストを各種バックエンド・セットにルーティングする処理も

サポートしています。


パブリック・ロード・バランサ

インターネットからのトラフィックを受け入れるには、パブリック・ロード・バランサを作成し

ます。受信トラフィックのエントリ・ポイントとして機能するパブリックIPアドレスがサービス

によって割り当てられます。このパブリックIPアドレスは、任意のDNSベンダーを通じてわかり

やすいDNS名に関連付けることができます。

パブリック・ロード・バランサは対象範囲がリージョンで、別々の可用性ドメインに1つずつ、

合計2つのサブネットを必要とします。そのため、パブリック・ロード・バランサは本質的に、

複数の可用性ドメインにまたがる高可用性を有しています。お客様のシステムの高可用性を実現

するには、システムをパブリック・ロード・バランサの背後に配置してください。たとえば、次

の図に示すように、WebサーバーVMをバックエンド・サーバー・セットとしてパブリック・

ロード・バランサの背後に配置することができます。

図4. パブリック・ロード・バランサを使用した高可用性アーキテクチャ

プライベート・ロード・バランサ

ロード・バランサをインターネットから分離して、セキュリティ状況を簡素化するには、プライ

ベート・ロード・バランサを作成します。Load Balancingサービスにより、受信トラフィックの

エントリ・ポイントとして機能するプライベートIPアドレスが割り当てられます。

プライベート・ロード・バランサを作成する場合、プライマリ・ロード・バランサとスタンバ

イ・ロード・バランサの両方をホスティングするのに必要なサブネットは1つだけです。この場

合、プライベート・ロード・バランサ・サービスは可用性ドメイン内にバインドされます。


図5. プライベート・ロード・バランサを使用した高可用性アーキテクチャ

複数の可用性ドメインにまたがる高可用性を実現するために、お客様はOracle Cloud

Infrastructure上で複数のプライベート・ロード・バランサを構成し、オンプレミスまたはプライ

ベートのDNSサーバーを使用して、プライベート・ロード・バランサのIPアドレスによるラウン

ドロビンDNS構成を設定することができます。この構成は次のように設定します。

1. 各可用性ドメインに 1つずつ、合計 2つのプライベート・ロード・バランサをデプロイし

ます。

2. VCN内に 2つのカスタム DNS VMを構成します。

3. カスタムDNSリゾルバを使用するようにVCNのデフォルトDHCPオプションを変更し、

DNSサーバーを DNS VMの IPアドレスに設定します。

4. TTL を小さい値に設定し、プライベート・ロード・バランサの FQDN に対して、新しい

ラウンドロビン DNSゾーン・エントリを追加します。

5. 2つのプライベート・ロード・バランサの IPアドレスを持つ 2つの Aレコードを追加し

ます。

6. プライベート・ロード・バランサにアクセスする際には、プライベート・ロード・バラ

ンサの FQDNを使用します。

次の図は、複数の可用性ドメインにまたがる高可用性プライベート・ロード・バランサの設定方

法を示しています。


図6. 複数の可用性ドメインにまたがるプライベート・ロード・バランサを使用した高可用性アーキテクチャ

FastConnectとVPNの高可用性設計

可用性が高く、フォルト・トレラントなネットワーク接続は、適切に設計されたシステムの鍵と

なります。この項では、Oracle Cloud InfrastructureのIPSec VPNとFastConnectのサービス・レベ

ル契約(SLA)の要件を満たすようにネットワークの設計を冗長化する方法に関するガイドライン

を示します。また、冗長VPN接続、冗長FastConnect接続、およびバックアップ用のVPN接続を

持つFastConnect接続の高可用性オプションについて説明します。

リモート接続を設計する際には、組織のビジネス可用性とアプリケーション要件に基づいて最も

適切な構成を決定します。ただし、一般には自社の拠点とオラクルのデータ・センターの間で冗

長なハードウェアとネットワーク・サービス・プロバイダを使用することを検討してください。

最も堅牢な方法は、異なるネットワーク・サービス・プロバイダからの回線による複数の

FastConnect接続を使用することです。

ネットワークの高可用性を実現するために、次のベスト・プラクティスをお薦めします。

オラクル、プロバイダまたは自社組織による定期的なメンテナンスをスケジュールしま

す。

可用性のために複数のインタフェースを使用する予定であっても、単一障害点を回避し

ます。同じ物理位置から接続する場合でも、高可用性接続には冗長ハードウェアが必要

です。

FastConnectプロバイダを選ぶ際には、デュアル・プロバイダ方式でネットワークの多様


性を確保することを検討します。

1つのネットワーク接続の障害が冗長接続で対応できる範囲を超えて、冗長接続の性能を

低下させることのないように、十分なネットワーク容量をプロビジョニングします。

IPSec VPNを使用したネットワークの高可用性設計

IPSec VPN接続を実装して、データ・センターをOracle Cloud Infrastructureに接続することを選

択できます。IPSec VPN接続は設定が容易でコスト効果に優れています。

冗長性を実現するには、Oracle Cloud Infrastructure動的ルーティング・ゲートウェイ(DRG)のそ

れぞれに複数のVPNエンドポイントを設定し、各IPSec VPN接続が、静的ルートを使用してトラ

フィックをルーティングする複数の冗長IPSecトンネルで構成されるようにします。高可用性を

確保するには、次の図に示すように、内部ネットワーク内でVPN接続の可用性を設定し、必要に

応じていずれかのパスが使用されるようにする必要があります。

図7.IPSec VPNの高可用性設計

広範囲のCIDRを静的ルートとして使用

データ・センターが複数の地理的位置にまたがる場合、特定の地理的位置のCIDRに加えて、広範

囲のCIDR (0.0.0.0/0)を静的ルートとして使用することをお薦めします。この広範囲のCIDRは、

ネットワーク設計に高可用性と柔軟性をもたらします。

たとえば、次の図は、別々の地域にあり、それぞれOracle Cloud Infrastructureに接続する、2つの

ネットワークを示しています。各地域にオンプレミス・ルーターが1つあるため、2つのIPSec

VPN接続を作成できます。各IPSec VPN接続に2つの静的ルートがあることに注意してください。

特定の地域のCIDR用の静的ルートと広範囲の0.0.0.0/0静的ルートです。


図8. 複数の地理的位置を持つIPSec VPN

1つのシナリオとして、前の図のCPE 1ルーターが停止したとします。サブネット1とサブネット

2が相互に通信できれば、CPE 2への0.0.0.0/0静的ルートにより、VCNは引き続きサブネット1内

のシステムにアクセスすることができます。次の図は、このシナリオを示しています。

図9. IPSec VPNの可用性シナリオ1

もう1つのシナリオとして、サブネット3を持つ新しい地域を追加して、それをサブネット2に接

続します。サブネット3に対するVCNのルートテーブルにルート・ルールを追加することで、

CPE 2への0.0.0.0/0静的ルートにより、VCNが新しいVPN接続を作成せずにサブネット3内のシス

テムにアクセスできるようにします。次の図は、このシナリオを示しています。


図10.IPSec VPNの可用性シナリオ2

FastConnectを使用したネットワークの高可用性設計

Oracle Cloud Infrastructure FastConnectでは、データ・センターとOracle Cloud Infrastructureの

間に専用のプライベート接続を簡単に確立できます。FastConnectは広帯域幅のオプションを提

供するとともに、インターネットベースの接続と比較して、信頼性が高く一貫したネットワーキ

ング体験を提供します。

FastConnectを使用する場合、プライベート・ピアリングまたはパブリック・ピアリング、ある

いはその両方を使用することを選択できます。

プライベート・ピアリングは、既存のインフラストラクチャを Oracle Cloud

Infrastructure の仮想クラウド・ネットワーク(VCN)に拡張する場合に使用します(たとえ

ば、ハイブリッド・クラウドを実装する場合や、リフトアンドシフト・シナリオなど)。

接続上での通信は、IPv4プライベート・アドレス(通常は RFC 1918)を使用して行います。

パブリック・ピアリングは、インターネットを使用せずに Oracle Cloud Infrastructureの

パブリック・サービスにアクセスする場合に使用します(たとえば、Object Storage、

Oracle Cloud Infrastructureのコンソールと API、または VCN内のパブリック・ロード・

バランサにアクセスする場合)。接続上での通信は、IPv4パブリック IPアドレスを使用し

て行います。FastConnect を使用しない場合、パブリック IP アドレス宛てのトラフィッ

クはインターネット経由でルーティングされます。FastConnectを使用する場合、そのよ

うなトラフィックはプライベート物理接続を経由します。

プロバイダの接続拠点(POP)にあるOracle Cloud Infrastructureルーターに直接接続するか、多く

のOracleパートナのいずれかを利用して、世界中のPOPからOracle Cloud Infrastructure

Networkingリソースに接続することができます。オラクルは、1リージョン当たり複数のPOPや1

POP当たり複数のFastConnectルーターなど、フォルト・トレラントな接続を構築できる機能を

提供しています。


FastConnectの冗長性

単一障害点を冗長性によって回避するために、Oracle Cloud Infrastructureには次の機能が用意さ

れています。

各都市圏内の複数の FastConnect拠点

各 FastConnect拠点内の複数のルーター

各 FastConnect拠点内の複数の物理回線

オラクルは、FastConnect拠点でのルーターと物理回線の冗長性に対応しています。FastConnect

を使用したネットワーク設計では、高可用性要件に合せて次の冗長性構成を検討することをお薦

めします。

可用性ドメインの冗長性: いずれかの FastConnect拠点に接続して、リージョン内のいず

れかの可用性ドメインに位置するサービスにアクセスします。この構成では、1リージョ

ン当たり複数の POP により、可用性ドメインの柔軟性を得ることができます。ピアリン

グ接続は POP内のルーターで終端します。

データ・センター拠点の冗長性: リージョンごとに 2つの異なる FastConnect拠点で接続

します。

ルーターの冗長性: FastConnect拠点ごとに 2つの異なるルーターに接続します。

回線の冗長性: いずれかの FastConnect拠点に複数の物理接続を持ちます。この回線はそ

れぞれ、集約インタフェース/LAG に複数の物理リンクを持つことができるため、冗長性

がもう 1レベル追加されます。

パートナ/プロバイダの冗長性: 単一または複数のパートナを利用して、FastConnect拠点

に接続します。

オンプレミス・データ・センターの場所に基づいて、次のいずれかの方法でFastConnect接続を

確立できます。

コロケーション(ポート速度: 10Gbps): FastConnect拠点で Oracleとコロケート

Oracleプロバイダ(ポート速度: 1Gbpsおよび 10Gbpsの単位で増分): Oracleプロバイダ

に接続

コロケーションのシナリオでは、クロスコネクトが既存のネットワークをFastConnect拠点の

Oracleに接続する物理ケーブルになります。FastConnectサービスをプロビジョニングする際に

は、少なくとも2つのクロスコネクトを設定することをお薦めします。各クロスコネクトが異な

るルーターに接続し、1つのルーターで発生した障害がOracle Cloud Infrastructureリソースへの接

続に影響を及ぼさないようにする必要があります。最初のクロスコネクトを作成した後、2番目

のクロスコネクトが最初のクロスコネクトとは異なるOracle FastConnectルーターにプロビジョ

ニングされるようにリクエストすることができます。冗長リンクの両方に新しい仮想回線をプロ

ビジョニングする必要があります。これにより、いずれかのルーターに障害が発生した場合に、


オンプレミス・ネットワークとOracle Cloud Infrastructure VCNの間の接続を確保できます。

Oracleプロバイダのシナリオでは、同じプロバイダまたは異なるプロバイダにより、2つの異な

るFastConnect拠点を持つ冗長回線を設定することをお薦めします。この構成により、回線と

データ・センター・レベルの両方で冗長性を得ることができます。次の図は、2つの仮想回線と2

つの異なるFastConnect拠点を持つFastConnect接続を示しています。

図11. FastConnectの高可用性設計

オラクルのFastConnectパートナはOracleネットワークへの冗長リンクを有しています。お客様

はパートナの顧客として、パートナのネットワークへの冗長リンクを用意する必要があります。

この接続は、お客様のネットワークとパートナのネットワークの両方で、異なるルーターを通る

必要があります。仮想回線をプロビジョニングする際には、回線が複数のプロバイダ・リンクに

またがるようにプロビジョニングします。

計画メンテナンス中の影響を回避

いずれかのルーターでメンテナンスを実行する場合、仮想回線上で学習したルートに関するボー

ダー・ゲートウェイ・プロトコル(BGP)ローカル・プリファレンスを構成して、稼働したままの

ルーターのローカル・プリファレンスの方が大きくなるようにすることができます。BGPローカ

ル・プリファレンスは、オンプレミス・ネットワークでのアウトバウンド・トラフィックの優先

度を変更するために使用します。

BGP ASプリペンドを使用すると、Oracleからお客様のネットワークへのトラフィックを変更で

きます。メンテナンスが実行されるルーターで、ローカルBGP AS番号をプリペンドします。そ

うすることで、Oracle CloudネットワークではASパスが短いFastConnect仮想回線が優先される

ようになります。


BGPローカル・プリファレンスとASプリペンドを変更したら、ルーターの仮想回線インタフェー

ス・カウンタを監視して、入力パケットと出力パケットのカウンタ値が非常に小さいことを確認

します。リンク上に残っているトラフィックはBGPプロトコルのトラフィックだけのはずです。

冗長パスの継続的なテスト

通常の運用では、オンプレミス・ネットワークとOracle Cloudの間で使用可能なパスをすべて使

用することをお薦めします。そうすることで、障害が発生した場合に冗長パスが必ず機能してい

ることが保証されます。あるいは、アクティブ/バックアップ設計を使用することで、障害発生時

にバックアップ・パスが機能するという安心感が得られます。この理由から、同一のBGPローカ

ル・プリファレンスとBGP ASパス長を使用することを検討してください。

IPSec VPNとFastConnectの両方を使用

冗長性をもう1レベル追加するために、IPSec VPNとFastConnectの両方を設定して、オンプレミ

スのデータ・センターをOracle Cloud Infrastructureに接続することができます。同じDRGに対し

てIPSec VPN接続とFastConnect仮想回線の両方を設定する場合、IPSec VPNは静的ルートを使

用するが、FastConnectはBGPを使用することを忘れないでください。Oracle Cloud

Infrastructureは、FastConnect仮想回線のBGPセッションでVCNの各サブネットに対してルート

をアドバタイズし、オンプレミス・ネットワークによってアドバタイズされたルートと静的ルー

トが重複する場合には、静的ルートよりBGPルートを優先するようにデフォルトのルート選択動

作をオーバーライドします。次の図は、この構成を示しています。

図12.IPSec VPNとFastConnectの両方を使用

ストレージの高可用性設計

Oracle Cloud Infrastructureは次のストレージ・サービスを提供します。


Block Volume

Object Storage

File Storage

Oracle Cloud Infrastructure Block Volumeでは、ブロック・ストレージ・ボリュームを動的にプロ

ビジョニングし、管理することが可能です。ボリュームの作成、アタッチ、接続、移動を必要に

応じて行い、ストレージとアプリケーションの要件を満たすことができます。ボリュームをイン

スタンスにアタッチして接続すると、通常のハード・ドライブのように使用できます。ボリュー

ム上のデータのメンテナンス中にボリュームを切断して、別のComputeインスタンスにアタッチ

することもできます。

Oracle Cloud Infrastructure Object Storageは、インターネット規模の高パフォーマンスなスト

レージ・プラットフォームで、信頼性が高くコスト効率のよいデータ耐久性を提供します。

Object Storageサービスは、イメージやビデオなどのアナリティック・データやリッチ・コンテ

ンツも含め、あらゆるコンテンツ・タイプの非構造化データをサイズの制限なく格納できます。

Object Storageはリージョン単位のサービスであり、リージョン内のすべての可用性ドメインで

使用できます。データは、複数の可用性ドメインにまたがって複数のストレージ・サーバーに冗

長に格納されます。

Oracle Cloud Infrastructure File Storageは、耐久性とスケーラビリティに優れたエンタープライ

ズ・クラスの分散型ネットワーク・ファイル・システムを提供します。File Storageファイル・シ

ステムには、仮想クラウド・ネットワーク(VCN)内の任意のベア・メタル・インスタンス、仮想

マシン・インスタンスまたはコンテナ・インスタンスから接続できます。Oracle Cloud

Infrastructure FastConnectとIPSec VPNを使用して、VCNの外部からファイル・システムにアク

セスすることもできます。数千のインスタンスからなる大規模なComputeクラスタでは、File

Storageを高パフォーマンスの共有ストレージとして使用できます。その場合、File Storageは柔

軟なデータ保護のための冗長ストレージとなります。

高可用性と耐久性を実現するために、ストレージ・レイヤーには次のベスト・プラクティスをお

薦めします。

アプリケーション・データをバックアップするには、Object Storageを使用します。デー

タは、複数の可用性ドメインにまたがって複数のストレージ・サーバーに冗長に格納さ

れます。チェックサムを使用してデータの完全性が能動的に監視され、破損したデータ

が検出されて自動的に修復されます。データの冗長性が失われても自動的に検出されて

修正されるので、お客様が影響を受けることはありません。

スケジュールされた自動バックアップを実行し、バックアップ・ポリシーに基づいて

バックアップを保持するには、Block Volume のポリシーベースのバックアップを使用し

ます。絶えずデータをバックアップすることで、データのコンプライアンス要件や規制

要件に準拠できます。

ブロック・ボリュームについて、ポイントインタイムのディスクからディスクへの直接


コピーが即時に必要な場合は、Block Volume のクローニング機能を使用します。ボ

リュームのクローニングは、コピーオンライトもソース・ボリュームへの依存性もない

ため、スナップショットとは異なります。バックアップは伴いません。クローン操作は

即時に行われ、クローン操作が開始された直後にクローン・ボリュームが使用可能にな

ります。クローン・ボリュームの状態が使用可能に変わり次第、アタッチして使用する

ことができます。

未テストのアプリケーションや信頼できないアプリケーションによる予想外の変更や悪

意ある変更からデータを保護する必要がある場合は、読取り専用アタッチによるブロッ

ク・ボリュームを使用します。読取り専用アタッチの場合、ボリュームは読取り専用と

してマークされるため、ボリューム内のデータは変更されません。読取り専用アタッチ

は、同じボリュームに読取り専用でアクセスする Compute インスタンスが複数存在する

場合にも使用できます。たとえば、顧客に静的な製品カタログ情報を提供する Web フロ

ント・エンドがインスタンスで実行されている場合です。

ワークロードを処理するためにファイル・セマンティクスを備えた可用性の高い共有ス

トレージが求められており、データ保護のために組込みの暗号化とスナップショットが

必要な場合は、File Storage を使用します。File Storage は業界標準のネットワーク・

ファイル・システム(NFS)ファイル・アクセス・プロトコルを使用しており、数千の

Computeインスタンスから同時にアクセス可能です。File Storageはアプリケーションに

対して、高パフォーマンスで柔軟なデータ保護を提供します。File Storageサービスは、

1 つの可用性ドメイン内でローカルに実行されます。File Storage は可用性ドメイン内で、

同期レプリケーションと高可用性フェイルオーバーを使用して、データの安全性と可用

性を維持します。

複数の可用性ドメインにまたがる高可用性がアプリケーションで必要とされている場合

は、Block Volumeサービスに加えて GlusterFSを使用します。

将来の成長に伴うニーズを考慮してストレージ容量をプランニングし、サイズを決定し

ます。

データベースの高可用性設計

Oracle Cloud Infrastructure Databaseサービスを使用すると、Oracleデータベース・システム(DB

システム)の運用をすばやく開始して、DBシステム上に1つ以上のデータベースを作成することが

できます。Databaseサービスは、サイズ、価格、パフォーマンスが異なる数種類のDBシステム

をサポートしています。

Exadata DBシステムの使用

Exadata DBシステムを使用すると、Oracle Cloud Infrastructure内でExadataのパワーを活用でき

ます。Exadata DBシステムは、高速で低レイテンシのInfiniBandネットワークとインテリジェン

トなExadataソフトウェアによって接続された、クォータ・ラック、ハーフ・ラックまたはフ

ル・ラックのComputeノードとストレージ・サーバーで構成されています。自動バックアップを

構成したり、様々なワークロードを最適化したり、システムの規模を拡大して、要求を満たすこ


とができます。

Exadata DBシステムは、組込みの高可用性機能を備えています。オンプレミスのExadata DBシ

ステムに関する既存のベスト・プラクティスがすべて適用されます。

2ノードのRAC DBシステムの使用

Oracle Cloud Infrastructureは、仮想マシンComputeインスタンス上で2ノードのRAC DBシステム

を提供します。2ノードのRAC DBシステムは組込みの可用性機能を備えているため、高可用性が

必要なソリューションには2ノードのRAC DBシステムを使用することをお薦めします。

Oracle Cloud Infrastructure Object Storageに自動的にバックアップするようにDatabaseサービス

を構成できます。

次の図は、2層のWebアプリケーションの高可用性をサポートする2ノードのRAC DBシステムの

デプロイメントを示しています。

図13. 2層のWebアプリケーションの高可用性をサポートする2ノードのRAC DBシステム

Data Guardの使用

単一ノードのDBシステムによるソリューションの場合、Oracle Data Guardを使用して高可用性

を実現することをお薦めします。Data Guardは、エンタープライズ・データの高可用性、データ

保護および災害復旧を保証します。

Data GuardをOracle Cloud Infrastructure Databaseサービスに実装するには、プライマリ・ロール

とスタンバイ・ロールの2つのデータベースが必要です。この2つのデータベースがData Guardア


ソシエーションを構成します。ほとんどのアプリケーションはプライマリ・データベースにアク

セスします。スタンバイ・データベースは、トランザクション的に一貫したプライマリ・データ

ベースのコピーです。

可用性と災害復旧を強化するために、スタンバイ・データベースのDBシステムは、プライマリ・

データベースのDBシステムとは異なる可用性ドメインに配置することをお薦めします。Oracle

Cloud Infrastructure可用性ドメイン間の高パフォーマンス・ネットワークがこのデプロイメント

を可能にしています。

図14. 高可用性データベース設計のためのData Guardの使用

Data Guardは、プライマリ・データベースからREDOデータを送信して適用することにより、ス

タンバイ・データベースを維持します。プライマリ・データベースが使用できなくなった場合は、

Data Guardを使用してスタンバイ・データベースをプライマリ・ロールに切り替えることができ

ます。

高可用性をサポートするData Guard構成では、次のアクションを実行できます。

スイッチオーバー: データベースのプライマリ・データベースとスタンバイ・データベー

スのロールを逆転させます。各データベースは、引き続き新しいロールで Data Guardア

ソシエーションに参加します。スイッチオーバーにより、データ損失のないことが保証

されます。プライマリ・データベースの計画メンテナンスを実行する前に、スイッチ

オーバーを使用できます。

フェイルオーバー: 既存のプライマリ・データベースに障害が発生した場合、またはアク


セスできなくなった場合に、スタンバイ・データベースをプライマリ・ロールに移行さ

せます。最大パフォーマンス保護モードを使用している場合、フェイルオーバーによっ

てデータが失われる可能性があります。

回復: データベースを Data Guard アソシエーションのスタンバイ・ロールに戻します。

reinstate コマンドを使用すると、障害の原因を修正した後、障害の発生したデータベー

スをサービスに戻すことができます。

CPUとストレージの自動スケーリング

ソリューションの高可用性を実現するには、DBシステムに十分な容量を持たせる必要があります。

Oracle Cloud InfrastructureのDatabaseサービスでは、Databaseサービスの様々なシェイプに基づ

いて、CPUコアまたはデータベース・ストレージを動的にスケーリングすることができます。

ベア・メタルComputeインスタンスに基づいたDBシステムの場合、最小限のCPUコアから始め

て、必要に応じてCPUコアの数を動的に増やすことをお薦めします。

仮想マシンComputeインスタンスに基づくDBシステムの場合、ストレージ・サイズを動的に増や

すことができます。

結論

どのようなデプロイメントをプランニングする際にも、可用性のプランニングは重要な問題の1

つです。このリファレンス・アーキテクチャ・ペーパーでは、コンピュート、ネットワーク、ス

トレージ、データベースの各レイヤーを含むOracle Cloud Infrastructure上での高可用性(HA)ソ

リューションの設計に役立つアドバイスを提供するとともに、プランニングの指針となるいくつ

かのベスト・プラクティスを示しています。

冗長性により、単一障害点を解消します。

複数のリージョン、リージョン内の複数の可用性ドメイン、または可用性ドメイン内の

複数のフォルト・ドメインにまたがるように、アプリケーションまたはソリューション

のコンポーネントをデプロイします。

将来の成長を念頭に置いて設計し、十分なリソース容量を確保します。

Oracle Databaseの Data Guard機能と動的スケーリング機能を活用します。

複数の可用性ドメインにまたがってアプリケーション・データをレプリケートします。

問題解決とフェイルオーバーのプロセスを自動化します。

Oracle Cloud Infrastructureは、新しい機能により常に進化し続けています。最新の情報、ドキュ

メントおよびトレーニングはhttps://cloud.oracle.comでご覧いただけます。

https://cloud.oracle.com/

Oracle Corporation, World Headquarters Worldwide Inquiries

500 Oracle Parkway Phone: +1.650.506.7000

Redwood Shores, CA 94065, USA Fax: +1.650.506.7200

Copyright © 2019, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載さ

れている内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述に

よる明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる

他の保証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文書によっ

て直接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の書面による許可を前もって得ることな

く、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。

Oracle および Java はオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である

場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべての SPARCの商標はライセンスをもとに使用し、SPARC

International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の

商標または登録商標です。UNIXは、The Open Groupの登録商標です。0219

Best Practices for Deploying High Availability Architecture on Oracle Cloud Infrastructure

2019年 2月

著者: Changbin Gongおよび Adeel Amin

C O N N E C T W I T H U S

blogs.oracle.com/oracle

facebook.com/oracle

twitter.com/oracle

oracle.com

oracle cloud infrastructure上に 高可用性アーキテクチャを ......3 | best practices for...

Documents

oracle cloud infrastructure上に高可用性アーキテクチャを ......3 | best practices for...