仮想マシンの障害回復のためのRackwareの構成
Rackware Migration Manager (RMM)は、OCIおよびCompute Cloud@Customerとの間で仮想マシンをレプリケートするために本番サイトにデプロイされます。
次のラックウェア・アーキテクチャは、OCIとCompute Cloud@Customerの間のディザスタ・リカバリを示しています。
このアーキテクチャでは、RMMが本番サイトにデプロイされ、OCIおよびCompute Cloud@Customerとの間で仮想マシンをレプリケートします。RMMサーバーはOCIにデプロイされます。ラックウェアDR計画は、WebおよびアプリケーションVMをアタッチされたブロック・ストレージとともに保護するためにRMMサーバー上に構成されます。WebおよびアプリケーションVMとそのブロック・ストレージは、RackwareによってOCIからCompute Cloud@Customerにレプリケートされます。
OCIのバックアップおよびリストア・アーキテクチャの構成について
OCIのバックアップおよびリストア・アーキテクチャを構成するための構成の推奨事項を次に示します。
- OCIを本番サイトまたはプライマリ・サイトとして、Compute Cloud@Customerをセカンダリ・サイトまたはスタンバイ・サイトとして構成します。
- ラックウェアの障害回復ポリシーを動的にプロビジョニングされたターゲットとして構成します。Rackwareは、RMM上でオリジン・サーバーのイメージのコピーを維持することでワークロードを保護します。このイメージを使用して、イベントが発生した場合にオンデマンドでターゲット・インフラストラクチャにインスタンスをデプロイすることで、コストを大幅に削減し、RTOが高いという犠牲を払ってRPOを削減できます。
- ラックウェアは仮想マシンを停止し、OCIからCompute Cloud@Customerにレプリケートします。
- OCIを実行している本番データベースを構成して、Compute Cloud@Customer上のスタンバイ・データベースにレプリケートします。フェイルオーバーが必要な場合は、Data Guardを使用してスタンバイOracle Databaseをプロモートしたり、障害時リカバリ作業の完了後にOCIのOracle Databaseをプライマリに戻すためにフェイルバックしたりできます。
- Cloud Syncレプリケーションが正しく構成され、OCIからCompute Cloud@CustomerにOCI Object Storageをレプリケートするようにスケジュールされた状態で、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が最小になりますが、常にアクティブな障害回復サイトを維持する必要があるため、コストが高くなります。
- ラックウェアは、仮想マシンをOCIからCompute Cloud@Customerの最小スケールで実行されているCompute Cloud@Customerにレプリケートします。
- OCIを実行している本番データベースを構成して、Compute Cloud@Customer上のスタンバイ・データベースにレプリケートします。フェイルオーバーが必要な場合は、Data Guardを使用してスタンバイOracle Databaseをプロモートしたり、障害時リカバリ作業の完了後にOCIのOracle Databaseをプライマリに戻すためにフェイルバックしたりできます。
- アクティブなCloud Syncレプリケーションを使用してOCIにOCI Storage Gatewayをデプロイし、OCIからCompute Cloud@CustomerにOCI Object Storageをレプリケートするように適切に構成します。
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本番環境を実行しています。
- OCIを実行している本番データベースを構成して、Compute Cloud@Customer上のスタンバイ・データベースにレプリケートします。フェイルオーバーが必要な場合は、Data Guardを使用してスタンバイOracle Databaseをプロモートしたり、障害時リカバリ作業の完了後にOCIのOracle Databaseをプライマリに戻すためにフェイルバックしたりできます。
- OCI Storage GatewayをOCIにデプロイし、アクティブで連続したCloud Syncレプリケーションを適切に構成して、OCI Object StorageをOCIからCompute Cloud@Customerにレプリケートします。
OCIからOracle Compute Cloud@Customerへのディザスタ・リカバリのためのRackwareの構成
OCIからOracle Compute Cloud@Customer for Linuxへのディザスタ・リカバリを実行するようにRackWareを構成するステップは次のとおりです:
Linuxプラットフォームでは、次の構成が推奨されます
- アクセス資格証明:
rootユーザーまたはsudo権限を持つユーザー - 記憶域
- オリジン・ボリューム・グループには、空きエクステントとして使用可能な使用済領域の15%以上が必要です。
/var/tmpには、20MB以上の空き領域が必要です。
- no-exec:
fstabのno-execプロパティーを使用して/tmpおよび/var/tmpファイルシステムを構成しないでください。 - Grub: オリジン・サーバーには
/etc/default/grubファイルが必要です - ウイルス対策: ウイルス対策プログラムがオリジンで実行されている場合は、
/mnt/rackware/ディレクトリを許可リストに追加する必要があります。
Windowsプラットフォームの場合は、次の構成をお勧めします。
- アクセス資格証明: 管理権限を持つ
SYSTEMユーザーまたはローカル・ユーザー。 - ストレージ: 各ボリュームには、VSSスナップショット用の十分な空き領域(少なくとも20%)が必要です。
- アンチウイルス: オリジンでは、ウイルス対策プログラムまたは Windows Defenderの許可リストに
rsync.exe、rwattr.exe、rwchangesvc.exe、およびrw_tngsync_util.exeを追加する必要があります。 - 言語:
SYSTEMロケールで英語以外の言語の場合は、Rackwareサポートに連絡してください。
次のステップに従います。
- すでにRackware RMMがOCIに正しくインストールされている場合は、Rackware RMM管理コンソールに移動して、インストール時に構成された資格証明を使用してログインします。ウェーブ・オプションには次のものがあります。
- ウェーブの作成: ウェーブを作成するには、「レプリケーション」、「ウェーブ」にナビゲートし、プラス(+)アイコンをクリックしてウェーブ作成ウィザードを開きます。名前を入力し、「Create」をクリックします。
- パラレル数: ウェーブ内のパラレル転送の数を設定できます。
- 自動プロビジョニング: ユーザーは、ターゲット・クラウドへのAPIコールを介してターゲットをプロビジョニングするようにRMMを構成できます。
- DRポリシー:ユーザーは、ウェーブ内のすべてのホストを定期的に同期するようにポリシーを構成できます。
- パススルー:有効にすると、データはRMMを経由します。(オリジン、RMM、宛先)
- ディザスタ・リカバリ・ポリシーの構成: ディザスタ・リカバリ・ポリシーを使用すると、ソースから、ユーザー指定の間隔でRackWare RMMおよびターゲット・インスタンス(事前にプロビジョニングされたスキームの場合)で取得されたイメージにデルタを同期できます。ユーザーは、異なる周期で必要な数の障害時リカバリ・ポリシーを作成できます。これにより、ユーザーのDR戦略に基づいてさまざまな間隔でさまざまな波を同期する柔軟性が向上します。新しい障害回復ポリシーを作成するには、DR、ポリシーに移動し、プラス (+)アイコンをクリックして、DR作成ウィザードを開きます。DR名、周期性、開始時間、および通知電子メールを指定します。
- 障害時リカバリ・ポリシーの適用: 障害時リカバリ・ポリシーを適用するには、「レプリケーション」タブに移動し、「ウェーブ」をクリックし、「OCI」をクリックして波の詳細C3を表示し、「ポリシーなし」をクリックします。「構成」ダイアログ・ボックスが開きます。正しい障害回復ポリシーを選択し、「Assign policy」をクリックします。次に示すスクリーンショットは、以前にOCIに構成されたDRPolicy_01ポリシーのOracle Compute Cloud@Customer Waveへの割当てを示しています。ウェーブにポリシーを割り当てると、当該ウェーブがレプリケーション、ウェーブ、DR、ウェーブに移行し、ディザスタ・リカバリ用に構成されるようになります。
- WindowsまたはLinux仮想マシンのレプリケーションおよびディザスタ・リカバリを「Wave Detail」画面で初期化するには、「Start Replication」をクリックします。
Rackwareには、ディザスタ・リカバリ・アーキテクチャを微調整するために使用できる次の機能も用意されています。
- 自動プロビジョニングによる適切なサイズ設定:ユーザーは、ターゲット・インスタンスのコンピュートおよびストレージ仕様を削減または増やすことを選択できます。この機能により、ユーザーはファイルシステムのサイズ変更の粒度を追加できます。
- ディザスタ・リカバリ中の動的プロビジョニング: ユーザーは、Rackwareの機能を活用してソース・インスタンスのレプリカ・イメージをローカルに保守し、このイメージを使用して障害時リカバリ・イベントにフェイルオーバー・インスタンスをデプロイできます。
- バックアップ、単一ファイルのリストアおよび保護スナップショット: Rackwareのバックアップ製品には、最大3年間のスナップショット保持、選択的なファイル・リストア、ポイントインタイム・リカバリのための無制限の保護スナップショットなどの豊富な機能セットが付属しています。
- BIOSからUEFI: ユーザーは、元インスタンスに追加の構成を変更することなく、UEFI対応インスタンスにシームレスに移行できます。
- スロットル移行: ユーザーは、帯域幅を個別に抑制できるため、すべての移行をより詳細に制御できます。
- 完全に自動化されたフェイルオーバーおよびフォールバック: フェイルオーバーは、オリジン環境にフォールバックしているため完全に自動化されます。
- Rackware Migration Manager: 選択的なファイルシステムの同期、ファイルおよびフォルダの除外、
cloud-initの有効化、カスタムの後処理スクリプトなどの多くの機能を提供します。