ディザスタ・リカバリ

ディザスタ・リカバリ(DR)の目的は、インストール・サイトのレベルで高可用性を実現し、Oracle Private Cloud Applianceでホストされているクリティカルなワークロードを停止やデータ損失から保護することです。

アプライアンス・ソフトウェア・バージョン3.0.2-b1261765以降では、新しいDRサービスが提供され、DR操作のオーケストレーションが「サービス・エンクレーブ」に直接組み込まれます。

ノート:

Oracle Site Guardを使用してOracle Enterprise Managerインストールを実行する3番目のシステムに依存する第1世代のディザスタ・リカバリは、DRが構成された既存のアプライアンスに対して引き続き動作します。既存の構成を新しいDRサービスに移行するためのパスが提供されます。

ディザスタ・リカバリの設定は、アプライアンス管理者またはOracleエンジニアの責任です。これには、すべての参加システムを相互接続し、両方のPrivate Cloud Applianceシステムでレプリケーション設定を構成します。 2つのアプライアンスは、どちらも単独で完全に動作する環境ですが、同時に互いのスタンバイまたはレプリカになるように構成されています。

管理者は、「DR構成」を作成および管理することで、ディザスタ・リカバリ制御の対象となるワークロードおよびリソースを決定します。 DR構成では、サイトレベルのインシデントから保護されるコンピュート・インスタンスおよび関連するブロック・ボリュームを定義し、ピアリングされたシステム間で関連するソース・コンパートメントとターゲットのコンパートメントおよびネットワーキング・リソースをマップします。 DR構成をリフレッシュして、含まれるインスタンスに対して発生した可能性のある変更を取得できます。

インシデントが発生すると、フェイルオーバー操作が起動され、スタンバイ・システムまたはレプリカ・システムのディザスタ・リカバリ制御下にインスタンスが起動されます。フェイルオーバーは粒度ではなくサイト全体のプロセスであるため、コンピュート・インスタンスは突然失敗します。プライマリおよびレプリカZFS Storage Applianceのロールを戻すと、DRサービスは、レプリケーション設定およびサイト・マッピングに従って、スタンバイ・システム上のプライマリ・システムの影響を受けるコンピュート・インスタンスを起動します。

フェイルオーバーは、中断を伴うインシデントがインストール・サイトの1つで検出される結果です。ただし、DRサービスではスイッチオーバーもサポートされます。スイッチオーバーは、同様のプロセスですが、管理者が手動でトリガーします。制御されたスイッチオーバー・シナリオでは、実行中のインスタンスがプライマリ・システムで安全に停止され、データの損失や破損が回避されます。スイッチオーバーは通常、計画メンテナンスまたはテストに使用されます。両方のサイトが再び完全に動作している場合、ピアリングされたPrivate Cloud Applianceシステムは、レプリカからプライマリへの(2番目の)スイッチオーバーを実行することで、元の構成に戻すことができます。これは、一般的なDR用語ではフェイルバックとも呼ばれます。

ネイティブDR

ディザスタ・リカバリの現在の実装は、「ネイティブDR」とも呼ばれます。これは、サービスがPrivate Cloud Applianceインフラストラクチャ・サービス・レイヤーに組み込まれているためです。アプライアンス間で相互ピア接続が確立されると、プライマリ・ラックとスタンバイ・ラックのDRサービスはREST APIコールを使用して通信します。ローカル・コマンドは、プラットフォーム・レイヤーの内部メッセージングおよび管理サービスを介して、適切なクラウド・インフラストラクチャ・サービスに送信されます。

DRサービスは、リソースと操作を明確に区別します。 DR保護下のリソースは、DR構成で識別されます。 DR操作は、スイッチオーバー、フェイルオーバーまたはフェイルオーバー後の操作中に実行するステップの概要を示すDR計画で定義されます。 DR構成とDR計画はピアリングされたシステム間で共有され、プライマリ・アプライアンスまたはスタンバイ・アプライアンスから作成および保守できます。 DR操作は、スタンバイから常にトリガーされるフェイルオーバーを除いて、どちらのアプライアンスからも実行できます。

詳細およびステップ・バイ・ステップの構成手順は、「Oracle Private Cloud Appliance管理者ガイド」の「ネイティブのディザスタ・リカバリ」を参照してください。

第1世代DR

異なるサイトにインストールされた2つのPrivate Cloud Applianceシステムの他に、この実装には、Oracle Site Guardを使用してOracle Enterprise Managerインストールを実行する3番目のシステムが必要です。このプラグインでは、管理者は両方のPrivate Cloud Applianceシステムを「サイト」として設定し、フェイルオーバー・ワークフロー(操作計画)を構成する必要があります。これは、DR操作のオーケストレーションがアプライアンス・ソフトウェアの外部にあることを意味します。いずれかの環境でインシデントが検出された場合、Oracle Site Guardのロールはフェイルオーバー・ワークフローを実行することであるため、影響を受けるコンピュート・インスタンスは、レプリカ・システムで再起動することでリカバリできます。

このDRアプローチでのピアリングは、アプライアンス・レベルではなく、ZFS Storage Applianceの間に構成されます。 DR構成を作成すると、ピア・システムへのレプリケーション用に専用のZFSプロジェクトが設定され、関連するコンピュート・インスタンス・リソースがデフォルトのストレージ・ロケーションからこの新しいZFSプロジェクトに移動されます。 2つのピアZFS Storage Appliance間の専用ネットワーク接続 - 各ラックに1つ - 5分間隔で信頼性の高いデータ・レプリケーションを実現します。

詳細およびステップ・バイ・ステップの構成手順は、「Oracle Private Cloud Appliance管理者ガイド」の「ディザスタ・リカバリ」を参照してください。