1. パイロット・ライトのディザスタ・リカバリ(DR)トポロジの設計
  2. パイロット・ライトのディザスタ・リカバリ(DR)トポロジの設計

パイロット・ライトのディザスタ・リカバリ(DR)トポロジの設計

大規模な停止が本番アプリケーションに影響する場合は、ワークロードを迅速にリストアする機能が必要です。ビジネス継続性計画には、リカバリ・ポイント、リカバリ時間および予算目標を満たすDR計画を含める必要があります。パイロット・ライト・トポロジーは、コスト要件とリカバリ要件のバランスを取ります。

パイロットライトという用語は、ガス駆動ヒーターなどのデバイスで常に点灯し、必要に応じて素早くデバイスを起動できる小さな炎を指します。DRのコンテキストでは、パイロット・ライト環境には、プライマリ・サイトから離れた場所で実行される、最新の構成およびクリティカル・データを含む特定のワークロードのコア・コンポーネントが含まれます。プライマリ・サイトで障害が発生した場合、リモートの場所にあるパイロット・ライト・コンポーネントを使用して、本番規模の環境を迅速にリストアできます。

Oracle Cloud Infrastructureは、パイロット・ライトDRトポロジの設計を可能にする、可用性と拡張性に優れたインフラストラクチャとサービスを提供します。

アーキテクチャ

このアーキテクチャは、冗長なリソースが複数のOracle Cloud Infrastructureリージョンに分散された複数層トポロジを示しています。

次の図は、この参照アーキテクチャを示しています。

x-region-pilot-light-topology.pngの説明が続きます
図x-region-pilot-light-topology.pngの説明

アーキテクチャには、次のコンポーネントがあります。

  • リージョン

    Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的領域です。リージョンは他のリージョンから独立しており、広大な距離を(複数の国または複数の大陸にまたがる)分離できます。

  • 可用性ドメイン

    可用性ドメインは、リージョン内のスタンドアロンの独立したデータ・センターです。各可用性ドメインの物理リソースは、フォルト・トレランスを提供する他の可用性ドメインのリソースから分離されます。可用性ドメインは、電源や冷却、内部の可用性ドメイン・ネットワークなどのインフラストラクチャを共有しません。したがって、あるアベイラビリティ・ドメインでの障害が、リージョン内の他のアベイラビリティ・ドメインに影響を及ぼすことはほとんどありません。

    アーキテクチャ・ダイアグラムには、可用性ドメインは表示されません。ただし、複数の可用性ドメインがあるリージョンでは、可用性を高めるために、各リージョンのリソースを可用性ドメイン全体に分散できます。

  • フォルト・ドメイン

    フォルト・ドメインは、アベイラビリティ・ドメイン内のハードウェアおよびインフラストラクチャのグループです。各可用性ドメインには、独立した電源とハードウェアを持つ3つのフォルト・ドメインがあります。複数のフォルト・ドメインにリソースを分散する場合、アプリケーションでは、フォルト・ドメイン内の物理サーバー障害、システム・メンテナンスおよび電源障害を許容できます。

    アーキテクチャ・ダイアグラムにフォルト・ドメインが表示されません。ただし、フォルト・ドメイン内の障害から保護するために、各可用性のリソースをフォルト・ドメイン全体に分散できます。

  • 仮想クラウド・ネットワーク(VCN)およびサブネット

    VCNは、Oracle Cloud Infrastructureリージョンで設定するカスタマイズ可能なソフトウェア定義のネットワークです。従来のデータ・センター・ネットワークと同様に、VCNではネットワーク環境を完全に制御できます。VCNには、VCNの作成後に変更できる複数の重複しないCIDRブロックを含めることができます。VCNは、リージョンまたは可用性ドメインにスコープ指定できるサブネットにセグメント化できます。各サブネットは、VCN内の他のサブネットと重複しない連続したアドレスの範囲で構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックまたはプライベートにできます。

    この参照アーキテクチャでは、各リージョンのすべてのリソースが単一のVCNにアタッチされます。

  • 要塞ホスト

    要塞ホストは、クラウド外部からトポロジへのセキュアで制御されたエントリ・ポイントとして機能するコンピュート・インスタンスです。要塞ホストは通常、非武装地帯(DMZ)でプロビジョニングされます。これにより、クラウドの外部から直接アクセスできないプライベート・ネットワークに機密リソースを配置することで、機密リソースを保護できます。トポロジには、定期的に監視および監査できる単一の既知のエントリ・ポイントがあります。したがって、トポロジのより機密性の高いコンポーネントへのアクセスを損なうことなく、公開を回避できます。

  • ロード・バランサ

    Oracle Cloud Infrastructure Load Balancingサービスは、バックエンドの複数のサーバーに対して、単一のエントリ・ポイントから自動トラフィック分散を提供します。

  • インターネット・ゲートウェイ

    インターネット・ゲートウェイでは、VCNのパブリック・サブネットとパブリック・インターネット間のトラフィックが許可されます。

  • コンピュート・インスタンス

    プライマリ・リージョンには、アプリケーション層の2つのコンピュート・インスタンスが含まれます。

    スタンバイ・リージョンには、レプリケートされたファイル・ストレージをマウントするためのコンピュート・インスタンスがあります。スタンバイ・リージョンの他の2つのコンピュート・インスタンスは、プライマリ・リージョンで障害が発生した場合に、レプリケートされたブート・ボリュームおよびブロック・ボリュームを使用して作成できるサーバーを表します。

  • ブロック・ボリューム

    ブロック・ストレージ・ボリュームでは、ストレージ・ボリュームを作成、アタッチ、接続および移動したり、ボリューム・パフォーマンスを変更して、ストレージ、パフォーマンスおよびアプリケーションの要件を満たすことができます。ボリュームをインスタンスにアタッチおよび接続した後は、そのボリュームを通常のハード・ドライブのように使用できます。また、データを失うことなく、ボリュームを切断して別のインスタンスにアタッチすることもできます。

    アーキテクチャでは、プライマリ・リージョンのブート・ボリュームとブロック・ボリュームがスタンバイ・リージョンにレプリケートされています。この設計では、プライマリ・リージョンで障害が発生した場合に、レプリケートされたブート・ボリュームおよびブロック・ボリュームを使用してコンピュート・インスタンスをプロビジョニングすることで、スタンバイ・リージョンでアプリケーション層を迅速にリストアできます。

  • ファイル・ストレージ

    Oracle Cloud Infrastructure File Storage Serviceでは、永続的でスケーラブルな、エンタープライズ規模のネットワーク・ファイル・システムを提供します。VCNのベア・メタル、仮想マシンまたはコンテナ・インスタンスからファイル・ストレージ・サービスのファイル・システムに接続できます。また、Oracle Cloud Infrastructure FastConnectおよびIPSec VPNを使用してVCNの外部からファイル・システムにアクセスすることもできます。

    このアーキテクチャでは、スクリプトを使用してスタンバイ・リージョンにレプリケートされるプライマリ・リージョンのファイル・ストレージが表示されます。

  • オブジェクト・ストレージ

    オブジェクト・ストレージを使用すると、データベースのバックアップ、分析データ、イメージやビデオなどのリッチ・コンテンツなど、あらゆるコンテンツ・タイプの構造化データと非構造化データにすばやくアクセスできます。インターネットまたはクラウド・プラットフォーム内部から、安全かつセキュアにデータを直接格納し、取得できます。パフォーマンスやサービスの信頼性を低下させることなく、ストレージをシームレスにスケーリングできます。標準ストレージは、迅速、即時、頻繁にアクセスするために必要な「ホット」ストレージに使用します。長期間保持し、ほとんどアクセスしない「コールド」ストレージにはアーカイブストレージを使用します。

    アーキテクチャでは、リージョン間レプリケーション・ポリシーを使用して、プライマリ・リージョンのオブジェクト・ストレージがスタンバイ・リージョンに自動的にレプリケートされています。

  • アプリケーション・サーバー

    アプリケーション・サーバーでは、データベースなどのセカンダリ・ピアを使用して、障害の発生時に処理に引き継がれます。アプリケーション・サーバーは、データベースとファイル・システムの両方に格納されている構成およびメタデータを使用します。アプリケーション・サーバーのクラスタリングは、単一のリージョンの範囲で保護を提供しますが、進行中の変更や新しいデプロイメントを、一貫したディザスタ・リカバリのために継続的にセカンダリ場所にレプリケートする必要があります。

  • データベース

    アーキテクチャには、各リージョンのデータベースが含まれます。Oracle Data Guardはデータ・レプリケーションに使用され、スタンバイ・データベースがトランザクション上一貫性のあるプライマリ・データベースのコピーであることを保証します。

    Data Guardは、プライマリ・データベースからスタンバイにREDOデータを転送および適用することによって、データベース間の同期を自動的に維持します。プライマリ・リージョンで障害が発生した場合、Data Guardはスタンバイ・データベースに自動的にフェイルオーバーします。

  • 動的ルーティング・ゲートウェイ(DRG)

    DRGは、VCNとリージョン外のネットワーク(別のOracle Cloud InfrastructureリージョンのVCN、オンプレミス・ネットワーク、別のクラウド・プロバイダのネットワークなど)との間のプライベート・ネットワーク・トラフィックのパスを提供する仮想ルーターです。

  • NATゲートウェイ

    NATゲートウェイを使用すると、VCN内のプライベート・リソースは、着信インターネット接続にそれらのリソースを公開せずにインターネット上のホストにアクセスできます。

  • サービス・ゲートウェイ

    サービス・ゲートウェイは、VCNからOracle Cloud Infrastructure Object Storageなどの他のサービスへのアクセスを提供します。VCNからOracleサービスへのトラフィックは、Oracleネットワーク・ファブリック上を移動し、インターネットを通過することはありません。

お薦め

パイロット軽量DRトポロジを設計するための開始点として、次の推奨事項を使用してください。実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。

  • VCN

    各VCNを作成するときに、各サブネットのクラウド・リソースに必要なIPアドレスの数を決定します。クラスレス・ドメイン間ルーティング(CIDR)表記を使用して、必要なIPアドレスに十分な大きさのサブネット・マスクおよびネットワーク・アドレス範囲を指定します。標準のプライベートIPアドレス空間内のアドレス範囲を使用します。

    プライベート接続を設定する予定の他のネットワーク(Oracle Cloud Infrastructure、オンプレミス・データ・センターまたは別のクラウド・プロバイダ内)と重複しないCIDRブロックを選択します。

    VCNを作成した後、CIDRブロックを変更、追加および削除できます。

    サブネットを設計する際には、トラフィック・フローとセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを、セキュリティ境界として機能する同じサブネットにアタッチします。

    リージョナル・サブネットを使用します。

  • セキュリティ・リスト

    データベースとファイル・ストレージのリージョン間レプリケーションを可能にするには、必要なセキュリティ・リストを構成します。ブート・ボリュームとブロック・ボリュームのレプリケーションでは、ボリュームがアタッチされているホスト間の通信は必要ありません。

  • Block Volumesバックアップ・ポリシー

    RPOを満たすために必要な頻度でブロック・ボリュームのバックアップを作成するようにポリシーを構成します。

  • Oracle Platform as a Service (PaaS)で実行されるアプリケーション・サーバーとカスタム・アプリケーション

    Oracle SOA Cloud ServiceやOracle WebLogic Server for Oracle Cloud InfrastructureなどのPaaSサービスでは、前述のほとんどのリソース(コンピュート、ブロック・ボリューム、ファイル・ストレージ、ネットワーキング、データベース)を使用します。これには、一貫した方法ですべての異なるレイヤーを保護する特定のディザスタ・リカバリ戦略が必要です。Oracleには、最大可用性アーキテクチャ(MAA)を作成し、このタイプのシステムを障害から保護するための詳細なベスト・プラクティスが用意されています。PaaSのディザスタ・リカバリ(DR)に関する具体的なドキュメントは、こちらをご覧ください。

注意事項

パイロット・ライトDR設定を実装する場合は、次の要因を考慮してください。

  • パフォーマンス

    RPOおよびRTOを計画する場合は、ボリューム・バックアップをリージョン間でコピーするために必要な時間を考慮してください。

  • 可用性

    DNSステアリング管理を使用して、フェイルオーバー後にクライアント・トラフィックを現在の本番リージョンにリダイレクトできます。

    ローカルにアタッチされたNVMeデバイスを提供するコンピュート・シェイプを使用する場合、オブジェクト・ストレージを使用する従来のバックアップ・ソリューションを使用して、これらのデバイスのデータをバックアップできます。

  • コスト

    プライマリからスタンバイ・リージョンへのフェイルオーバーが発生した場合、Terraformスクリプトを使用して必要なインフラストラクチャを迅速にプロビジョニングできます。プロビジョニング後にデータベース・システムのサイズを変更できるため、最初に必要な最小シェイプを指定し、フェイルオーバー後により大きなシェイプに変更します。

詳細の検討

Oracle Cloud Infrastructureの障害時リカバリおよびリジリエンスの詳細を参照してください。

次のOracle PaaSサービスについては、MAAディザスタ・リカバリの技術概要を参照してください。

Oracle Cloud Infrastructure MarketplaceのSOA Suite障害時リカバリ

Oracle WebLogic Server for Oracle Cloud Infrastructureのディザスタ・リカバリ