1. OCIからOracle Compute Cloud@Customerへのディザスタ・リカバリの設定
  2. 仮想マシンの障害時リカバリのためのラックウェアの構成

仮想マシンの障害時リカバリのためのラックウェアの構成

Rackware Migration Manager (RMM)は、OCIおよびCompute Cloud@Customerとの間で仮想マシンをレプリケートするために本番サイトにデプロイされます。

次のラックウェア・アーキテクチャは、OCIとCompute Cloud@Customer間のディザスタ・リカバリを示しています:

rackware-dr-oracle-compute-cloud-customer-oci.pngの説明が続きます
図rackware-dr-oracle-compute-cloud-customer-oci.pngの説明

ラックウェア-dr-oracle-compute-cloud-customer-oci-oracle.zip

このアーキテクチャでは、RMMが本番サイトにデプロイされ、OCIおよびCompute Cloud@Customerとの間で仮想マシンをレプリケートします。RMMサーバーはOCIにデプロイされます。Rackware DR計画は、WebおよびApp VMと接続されたブロック・ストレージを保護するようにRMMサーバー上に構成されます。Webおよびアプリケーション・仮想マシンとそのブロック・ストレージは、RackwareによってOCIからCompute Cloud@Customerにレプリケートされます。

OCIのバックアップおよびリストア・アーキテクチャの構成について

OCIのバックアップおよびリストア・アーキテクチャを構成するための構成の推奨事項を次に示します。

  • OCIを本番サイトまたはプライマリ・サイトとして、Compute Cloud@Customerをセカンダリ・サイトまたはスタンバイ・サイトとして構成します。
  • ラックウェアのディザスタ・リカバリ・ポリシーを動的にプロビジョニングされるターゲットとして構成します。Rackwareは、RMMでオリジン・サーバーのイメージのコピーを保持してワークロードを保護します。イベントが発生した場合、イメージを使用してオンデマンドでターゲット・インフラストラクチャにインスタンスをデプロイし、コストを大幅に削減し、RTOを上回るコストでRPOを削減できます。
  • Rackwareは仮想マシンを停止し、OCIからCompute Cloud@Customerにレプリケートします。
  • Compute Cloud@Customer上のスタンバイ・データベースにレプリケートするようにOCIを実行している本番データベースを構成します。フェイルオーバーが必要な場合は、Data Guardを使用してスタンバイOracle Databaseをプロモートし、障害時リカバリ作業の完了後にOCIのOracle Databaseをプライマリに戻すためにフェイルバックできます。
  • OCI Object StorageをOCIからCompute Cloud@Customerにレプリケートするように、Cloud Syncレプリケーションを適切に構成およびスケジュールされたOCIにOCI Storage Gatewayをデプロイします。
  • Rackwareを使用して、ディザスタ・リカバリ操作中にCompute Cloud@CustomerとOCIの間で仮想マシンのディザスタ・リカバリを調整します。

OCI用のパイロット・ライト・アーキテクチャの構成について

パイロット・ライト・アーキテクチャは、OCIを使用したCompute Cloud@Customerのディザスタ・リカバリと同じです。

構成の推奨事項は次のとおりです。

  • バックアップおよびリストアのユースケースと同様に、本番サイトにRMMをデプロイして、OCIおよびCompute Cloud@Customerとの間で仮想マシンをレプリケートします。この場合、本番サイトまたはプライマリ・サイトとしてOCIを構成し、セカンダリ・サイトまたはスタンバイ・サイトとしてCompute Cloud@Customerを構成します。
  • ラックウェアのディザスタ・リカバリ・ポリシーを「事前プロビジョニングされたターゲット」として構成します。この構成では、RMM上のオリジン・サーバーのイメージに加えて、ターゲット・インフラストラクチャ上のアクティブ・サーバー・インスタンスを維持することで、ワークロードを保護することを選択できます。ユーザーが指定した間隔でイメージおよびターゲット・サーバーを更新するように同期ジョブを構成します。このアプローチではRTOが最も低くなりますが、アクティブなディザスタ・リカバリ・サイトを常に維持する必要があるため、コストが高くなります。
  • Rackwareは、Compute Cloud@Customerの最小規模で実行されているCompute Cloud@Customerに仮想マシンをOCIからレプリケートします。
  • Compute Cloud@Customer上のスタンバイ・データベースにレプリケートするようにOCIを実行している本番データベースを構成します。フェイルオーバーが必要な場合は、Data Guardを使用してスタンバイOracle Databaseをプロモートし、障害時リカバリ作業の完了後にOCIのOracle Databaseをプライマリに戻すためにフェイルバックできます。
  • OCI Storage GatewayをOCIからCompute Cloud@CustomerにOCI Object Storageをレプリケートするように適切に構成されたアクティブなCloud SyncレプリケーションとともにOCIにデプロイします。

OCIのウォーム・スタンバイ・アーキテクチャの構成について

ウォーム・スタンバイ・アーキテクチャは、OCIを使用したCompute Cloud@Customerのディザスタ・リカバリと同じです。

構成の推奨事項は次のとおりです。

  • 本番サイトにRMMをデプロイして、OCIおよびCompute Cloud@Customerとの間で仮想マシンをレプリケートします。この場合、本番サイトまたはプライマリ・サイトとしてOCIを構成し、セカンダリ・サイトまたはスタンバイ・サイトとしてCompute Cloud@Customerを構成します。
  • ラックウェアのディザスタ・リカバリ・ポリシーを「事前プロビジョニングされたターゲット」として構成します。この構成では、RMM上のオリジン・サーバーのイメージに加えて、ターゲット・インフラストラクチャ上のアクティブ・サーバー・インスタンスを維持することで、ワークロードを保護することを選択できます。ユーザーが指定した間隔で(異なる周期性で)イメージおよびターゲット・サーバーを更新するように同期ジョブを構成します。このアプローチではRTOが最も低くなりますが、アクティブなディザスタ・リカバリ・サイトを常に維持する必要があるため、コストが高くなります。
  • Rackwareは常に仮想マシンをOCIからCompute Cloud@Customerにレプリケートし、Compute Cloud@Customerで動作する同じバージョンのOCI本番環境を実行します。
  • Compute Cloud@Customer上のスタンバイ・データベースにレプリケートするようにOCIを実行している本番データベースを構成します。フェイルオーバーが必要な場合は、Data Guardを使用してスタンバイOracle Databaseをプロモートし、障害時リカバリ作業の完了後にOCIのOracle Databaseをプライマリに戻すためにフェイルバックできます。
  • OCI Storage GatewayをOCIからCompute Cloud@CustomerにOCI Object Storageをレプリケートするように適切に構成されたアクティブおよび連続したCloud SyncレプリケーションでOCIにデプロイします。

OCIからOracle Compute Cloud@Customerへのディザスタ・リカバリのためのラックウェアの構成

OCIからOracle Compute Cloud@Customer for Linuxへのディザスタ・リカバリを実行するようにRackWareを構成するステップは次のとおりです。

Linuxプラットフォームでは、次の構成をお薦めします

  • アクセス資格証明: sudo権限を持つrootユーザーまたはユーザー
  • 記憶域
    • オリジン・ボリューム・グループには、空きエクステントとして使用可能な使用済領域の少なくとも15%が必要です。
    • /var/tmpには、20MB以上の空き領域が必要です。
  • no-exec: /tmpおよび/var/tmpファイルシステムは、fstabのno-execプロパティを使用して構成しないでください。
  • Grub: オリジン・サーバーには/etc/default/grubファイルが必要です
  • ウイルス対策: ウイルス対策プログラムがオリジンで実行されている場合は、許可リストに/mnt/rackware/ディレクトリを追加する必要があります。

Windowsプラットフォームでは、次の構成をお薦めします:

  • アクセス資格証明: SYSTEMユーザーまたは管理権限を持つローカル・ユーザー。
  • ストレージ: 各ボリュームには、VSSスナップショット用の十分な空き領域(少なくとも/約20%)が必要です。
  • ウイルス対策: オリジンは、ウイルス対策プログラムまたはWindows Defenderの許可リストにrsync.exe、rwattr.exe、 rwchangesvc.exeおよびrw_tngsync_util.exeを追加する必要があります。
  • 言語: SYSTEMロケールの英語以外の言語については、Rackwareサポートに連絡してください。

次のステップに従います:

  1. すでにOCIにRackware RMMが正しくインストールされていると仮定して、Rackware RMM管理コンソールに移動し、インストール時に構成された資格証明を使用してログインします。ウェーブ・オプションには次のものがあります。
  2. ウェーブの作成: ウェーブを作成するには、「レプリケーション」、「ウェーブ」にナビゲートし、プラス(+)アイコンをクリックしてウェーブ作成ウィザードを開きます。名前を入力し、「作成」をクリックします。
    • パラレル数: ウェーブ内のパラレル転送の数を設定できます。
    • 自動プロビジョニング: ユーザーは、ターゲット・クラウドへのAPIコールを介してターゲットをプロビジョニングするようにRMMを構成できます。
    • DRポリシー:ユーザーは、ウェーブ内のすべてのホストを定期的に同期するようにポリシーを構成できます。
    • パススルー:有効にすると、データはRMMを介して流れます。(オリジナル、RMM、宛先)
  3. ディザスタ・リカバリ・ポリシーの構成: ディザスタ・リカバリ・ポリシーを使用すると、ユーザー指定の間隔で、ソースからのデルタを、RackWare RMMおよびターゲット・インスタンスで取得されたイメージ(事前にプロビジョニングされたスキームの場合)に同期できます。ユーザーは、必要な数のディザスタ・リカバリ・ポリシーを異なる周期で作成できます。これにより、ユーザーのDR戦略に基づいて、様々な間隔で異なるウェーブを柔軟に同期できます。新しいディザスタ・リカバリ・ポリシーを作成するには、DR、ポリシーに移動し、プラス(+)アイコンをクリックしてDR作成ウィザードを開きます。DR名、周期性、開始時間および通知電子メールを指定します。
  4. ディザスタ・リカバリ・ポリシーの適用: ディザスタ・リカバリ・ポリシーを適用するには、「レプリケーション」タブに移動し、「ウェーブ」をクリックし、「OCI」をクリックしてC3ウェーブの詳細を表示し、「ポリシーなし」をクリックします。「構成」ダイアログ・ボックスが開きます。正しいディザスタ・リカバリ・ポリシーを選択し、「ポリシーの割当て」をクリックします。次のスクリーンショットは、以前にOCIに構成されていたDRPolicy_01ポリシーのOracle Compute Cloud@Customer Waveへの割当てを示しています。ポリシーをウェーブに割り当てると、そのウェーブがディザスタ・リカバリ用に構成されるようになったため、そのウェーブがレプリケーション、ウェーブがDR、ウェーブに移動します。
  5. WindowsまたはLinux仮想マシンのレプリケーションおよびディザスタ・リカバリを「ウェーブ詳細」画面で初期化するには、「レプリケーションの開始」をクリックします。

Rackwareには、ディザスタ・リカバリ・アーキテクチャの微調整に使用できる次の機能も用意されています。

  • 自動プロビジョニングを使用した適切なサイズ設定:ユーザーは、ターゲット・インスタンスのコンピュートおよびストレージ仕様を減らすか増やすかを選択できます。この機能により、ユーザーはファイルシステムのサイズ変更の粒度を追加できます。
  • ディザスタ・リカバリ中の動的プロビジョニング: ユーザーは、ソース・インスタンスのレプリカ・イメージをローカルに維持するRackwareの機能を活用し、このイメージを使用して障害時リカバリ・イベントにフェイルオーバー・インスタンスをデプロイできます。
  • バックアップ、単一ファイル・リストアおよび保護されたスナップショット: Rackwareのバックアップ製品には、最大3年間のスナップショットの保持、選択的なファイル・リストア、ポイントインタイム・リカバリのための無制限の保護されたスナップショットなどの豊富な機能セットが付属しています。
  • BIOSからUEFI: ユーザーは、元のインスタンスに追加の構成を変更することなく、UEFI対応インスタンスにシームレスに移行できます。
  • スロットル移行: ユーザーは、帯域幅を個別に抑制できるため、すべての単一移行をより詳細に制御できます。
  • 完全自動フェイルオーバーおよびフォールバック: オリジン環境にフォールバックするため、フェイルオーバーは完全に自動化されます。
  • Rackware Migration Manager: 選択的なファイルシステムの同期、ファイルおよびフォルダの除外、cloud-initの有効化、カスタムのポストスクリプトなど、多くの機能を提供します。