災害復旧レプリケーションの実行：完全ガイド
昨今、顧客は理由の如何を問わず、サービスの提供に少しでも遅れが生じると、すぐに我慢できなくなってしまいます。例えば、特定のサービスを探してA社のウェブサイトを訪れた際、そのサービスが利用できない場合、顧客は代わりに必要なサービスを提供できるA社の競合他社のウェブサイトに移動してしまう可能性が高いでしょう。 この慌ただしい現代において、長時間の業務停止は顧客ロイヤルティを損なう可能性が極めて高いです。
つまり、業務停止は次のような結果を招く恐れがあります:
- 逸失利益
- ブランドへのダメージ
- 顧客やパートナーとの関係における課題
- サプライチェーンに関する課題
- 法的問題など
こうした結果は、業務に不可欠なサービスやデータが利用できないことに起因している可能性があります。レプリケーションの目的は、ダウンタイムを完全に回避するか、少なくともその影響を最小限に抑えることにあります。ディザスタリカバリ(DR)は、単に災害復旧のためのレプリケーションだけにとどまるものではありません。同様に、レプリケーションも災害復旧のためだけでなく、データの同期、統合、集約、移行のためにも行われます。
災害発生後にITインフラ、あるいは少なくともその最も重要な部分を復旧させるためには、組織には、レプリケートされたデータを保存し、フェイルオーバーサイトとして利用できる代替拠点が必要です。メインサイトの稼働状態、あるいは物理的な存続さえも脅かすような災害からの復旧には、代替拠点が不可欠です。ディザスタリカバリレプリケーションとは、単一の拠点内、あるいはメイン拠点と代替拠点との間で、データの完全なコピーを作成することを指します。 災害復旧レプリケーションは、常に継続的に行われるべきです。なぜなら、災害が発生した場合、許容可能な期間内に、最新の業務に不可欠なITプロセスをDR(災害復旧)用のソフトウェアおよびハードウェアへフェイルオーバーする必要があるからです。
現在、クラウドレプリケーションの人気が高まっていますが、代替となる物理サイトの利用は依然として広く普及しています。物理サイトには主に"ホットサイト"と"コールドサイト"の2種類があります。 ホットサイトはプライマリデータセンターの複製であり、同じ機器、ソフトウェア、ハードウェアを備えているため、プライマリ拠点が稼働不能になった場合、ホットサイトは即座にフェイルオーバー先となることができます。ご想像の通り、そのコストは相応に高くなります。一方、コールドサイトは、ハードウェアやソフトウェアがインストールされていない単なるスペースですが、必要な電源および通信回線は備えています。
事業継続を脅かし、災害復旧を必要とする要因
組織のITインフラとその事業継続性を脅かす要因は数え切れないほど存在します。その中には、影響が軽微で比較的頻繁に発生するもの(インフラの一部における予期せぬダウンタイムなど)もあれば、壊滅的なものもありますが、これらすべてを、深刻度の異なる災害と捉えるのが妥当でしょう。これらを大まかに分類してみましょう:
- 自然災害。 これらは、誰にも制御できない天災です。 予測可能か否かにかかわらず、それらは圧倒的な勢いで、その進路にあるすべてに甚大な被害と破壊をもたらします。その進路には、たまたま貴組織の所在地が含まれている可能性もあります。洪水、ハリケーン、火山噴火、竜巻、地震は、貴組織の地域ではリスク要因ではないかもしれませんが、異常気象はあらゆる場所で脅威となります。文明に起因する脅威は現れては消えていきますが、私たちは常に予防策を講じ、自然災害による最悪の事態を回避しなければなりません。
- 人為的災害 これには、破壊工作、テロ、産業スパイ、器物破損などが含まれる。過失や善意の過失も、こうした脅威要因の一つである。
- 国内および国際的なイベント 戦争やストライキ、その他不安定な政治情勢による事態などが発生すれば、組織の物理的な拠点は一瞬にして消滅してしまう可能性があります。
- 技術およびソフトウェアに関連する障害や脅威 これには、停電、ハードウェアの故障、データの損失に加え、ウイルス、ランサムウェア、サイバー攻撃といった悪意のある要因も含まれます。
今日の世界では、ITインフラストラクチャの仮想化がますます普遍化しており、これがDR(災害復旧)の全体的な有効性向上に寄与しています。そのため、最新の災害復旧レプリケーションソフトウェアは、かつてないほど効果的かつ手頃な価格となっており、完全に自動化されたDRワークフローを構築・運用し、許容可能なRTO(復旧目標時間)とRPO(復旧時点目標)を達成することが可能になっています。
DRの評価指標のうち、レプリケーションを設定する際には以下の点を考慮する必要があります:
- 目標復旧時間(RTO) これは、復旧プロセスに要する許容可能な時間を測定するためのものであり、言い換えれば、組織がサービスの提供を再開するまでに、どれだけの時間を費やす余裕があるかを示すものです。
- 復旧時点目標 (RPO) これは、復旧が必要なファイルがどの程度最新の状態であるべきかを指します。ミッションクリティカルなアプリケーションが非常に動的であり、その内部で多くのトランザクションが発生している場合、これらのアプリケーションを即座に復旧させる必要があります。そうしなければ、多くのトランザクションが失われるリスクがあり、その結果、それらがもたらすはずだった収益も失うことになります。
- 作業回復時間(WRT) これは、企業が復元されたデータの完全性を確認するのに要する目安の時間を示しています。
- 最大許容ダウンタイム(MTD) 企業が深刻な損失や悪影響を被ることなく、災害復旧にどれだけの時間を割くことができるかを測定する。
以下に、組織向けの災害復旧レプリケーションソリューションを選択する際に考慮すべき、レプリケーションの特性の一覧を示します。
同期レプリケーションと非同期レプリケーション
その間、非同期レプリケーション、 データは、対応するソースへの書き込みと同時にターゲットデータオブジェクトにも書き込まれるため、RTOおよびRPOの目標値を可能な限り低く抑えることができます。この種のディザスタリカバリレプリケーションは、即時のフェイルオーバーを必要とするハイエンドのトランザクションアプリケーションや高可用性クラスタに最適です。データを書き込むソフトウェアクライアントは、プライマリおよびセカンダリストレージの両方にデータがコミットされて初めて、書き込みの確認を受け取ります。
オブジェクトとそのレプリカは常に同期された状態が維持されますが、これにより同期対象のアプリケーションに遅延が生じ、処理速度が低下します。また、帯域幅を消費し、全体的なオーバーヘッドも発生します。代替の保存場所を使用する場合、その接続が切断される可能性もあります。しかし、同期レプリケーションでは、データ損失なく、ほぼ瞬時にセカンダリサイトへフェイルオーバーすることが可能です。
処理中 非同期レプリケーション、データは、対応するソースに書き込まれた後、しばらくしてからターゲットデータオブジェクトに書き込まれます。データの災害復旧レプリケーションは、設定されたスケジュールに従い、一定の間隔(1分ごと、10分ごと、1時間ごとなど)で行われます。これは、ネットワーク帯域幅が同期レプリケーションの負荷に耐えられない場合、つまり、ミッションクリティカルなデータの変更頻度がフェイルオーバーサイトへの転送速度を常に上回っている場合に適した選択肢です。
ファイルベースおよびブロックベースのレプリケーション
ファイルシステムは、特定のディスクブロック上にファイルを保存します。1つのファイルが、ディスク上のあちこちに散らばったブロックに保存されていることもあります。そのため、ファイルベースのレプリケーション処理がファイルを読み込む際には、読み込むファイルの断片を探すためにディスク上を"駆け回ら"なければなりません。この"駆け回り"にはかなりの時間がかかります。 この時間のロスは、ブロックベースのレプリケーションによって回避できます。ブロックベースのレプリケーションでは、変更されたファイルそのものではなく、変更されたブロックをターゲットの場所に転送し、ディスク上の配置順に従ってブロックを読み取ります。したがって、他の条件が同じであれば、ブロックベースのレプリケーションを行うDRソリューションを選択することが望ましいと言えます。
フルレプリケーションと増分レプリケーション
データ全体を継続的にレプリケートすることは、非合理的かつ非現実的です。ただし、最初に1回、フルレプリケーションを行う必要があります。このフルレプリケーションの結果、ソースオブジェクトの完全な複製が作成されます。その後、増分レプリケーションを開始できます。これは、変更されたデータのみがフェイルオーバーサイトへコピーされることを意味します(ブロックベースのレプリケーションを使用している場合は、ブロックレベルでの変更)。現時点では、すべての高度な DRソリューション、例えば NAKIVO Backup & Replication…により、増分型の災害復旧レプリケーションを実行できるようになります。
アプリケーション認識型レプリケーション
災害復旧レプリケーションがアプリケーション対応型の場合、メモリ内のアプリケーションデータやI/O操作の状態をキャプチャします。これにより、アプリケーション上のデータ損失を防ぐことができます。レプリケートされたアプリケーションはトランザクションの一貫性を維持するため、DRサイトで実行してもクラッシュすることはありません。
災害復旧レプリケーション NAKIVO Backup & Replication
もしあなたが 最適なVMwareバックアップソリューション お使いの環境に合わせて、以下を試してみてください NAKIVO Backup & Replication. 当社のエージェントレス型データ保護ソリューションは、イメージベースのアプリケーション認識型増分バックアップと VMware仮想マシンのレプリケーション、およびHyper-V VMやAWS EC2インスタンスも対象となります。前述の通り、ここではVMware VMを例に、VMのレプリケーションを実行する方法について解説します。VMware仮想環境におけるレプリケーションは、 NAKIVO Backup & Replication 以下の機能を備えています(その多くはMicrosoft Hyper-VやAWS EC2でも利用可能です):
- アプリケーション認識モード このモードでは、Microsoft Exchange、Microsoft Active Directory、Microsoft SQL、およびその他のいくつかのアプリケーションが、災害復旧レプリケーションが開始される前に、メモリ内のデータとI/Oトランザクションをディスクに書き出すことが保証されます。このモードでレプリケートされるアプリケーションはクラッシュ不整合状態にあるため、災害が発生してレプリカの電源を入れ直さなければならない場合でも、エラーなく実行することができます。
- 便利 ポリシーによるレプリケーションの自動化. ポリシーを使用することで、VMのレプリケーションを完全に自動化できます。ポリシーは、VMのサイズ、タグ、名前、配置場所などに基づくルールで構成されます。ポリシーベースのジョブは、設定されたルールに該当するすべてのVMを対象とし、インフラストラクチャ内にVMが出現すると自動的にそれらを検出し、レプリケーションジョブに追加します。
- リカバリポイントの保持期間は柔軟に設定可能ですこれにより、VMスナップショットと呼ばれる30個の復旧ポイントを作成できます。"祖父・父・息子"方式のローテーションスキームを利用することで、日次、週次、月次、年次の復旧ポイントを作成できます。
- その スクリーンショットの確認 この機能を使用すると、レプリカが正常に動作しているかどうかを確認できます。この機能のおかげで、万一災害が発生した場合でも、破損したりエラーだらけになったVMレプリカといった"不愉快な"事態に直面することはありません。
- RTOの要件が厳しくないデータ、つまり非同期でレプリケートされるデータについては、本番用VMそのものではなく、その バックアップこれにより、主要なITリソースの負荷を軽減できます。
- VMのレプリカについては、作成するかどうかを選択できます シンプロビジョニングされたディスク…本番環境のVMでどのディスクが使用されているかに関わらず。ディスクがシンディスクの場合、その容量分はデータとアプリケーションのみで占められ、未使用領域は一切含まれません。
- 当社の製品のレプリケーション機能は、以下の状況で利用できます。 サイト復旧 この機能により、複雑なDRワークフローを統合・自動化できます。Site Recovery機能を利用すれば、レプリケーション、計画的または緊急時のフェイルオーバー、フェイルバック、その他の操作を単一のプロセスに統合し、ワンクリックで実行することが可能です！
- スワップデータ(Windows OS ではスワップファイル、Linux OS ではスワップパーティション)を VM レプリカから除外することで、レプリケーション速度が向上し、ストレージ容量を節約できます。
LAN-Free Data Transferこのモードでは、以下を通じてレプリケーションが大幅に高速化されますHot AddそしてDirect SAN Accessもし NAKIVO Backup & Replication VMデータストアにアクセスできるサーバー上で実行される場合、Hot Addこの機能は、ストレージI/Oスタックを介してこれらのデータストアからVMデータを読み取り、その過程でホストのTCP/IPスタックをバイパスします。Direct SAN Accessこの機能により、Fibre Channel または iSCSI 経由で SAN ストレージから直接データを読み取ることが可能となり、レプリケーション速度が向上するほか、本番ネットワークの負荷を軽減することができます。- Microsoft Exchange または Microsoft SQL Server をご利用の場合、 NAKIVO Backup & Replication できる サーバーのトランザクション・ログを切り詰める、サーバー上の容量をあまり占有しないようにするためです。
- 経由で ネットワーク高速化 この機能を利用すれば、レプリケーションの速度を最大2倍まで向上させることができます。この機能を利用するには、オンサイトまたはオフサイトに追加のTransporterをインストールするだけで済みます。
- 追加のTransporterをインストールすることで、以下のことも可能になります 暗号化 転送時およびターゲットリポジトリに到達した時点でのレプリケートされたデータ。
- 経由で マルチテナント この機能により、Replication-as-a-Serviceを提供することが可能になります。最大100個の分離されたテナントを作成でき、顧客はそれらを利用して、自らの判断でレプリケーションやその他のタスクを実行できます。
- 高度な帯域幅制御 この機能を使用すると、レプリケーションプロセスの帯域幅を制限し、ネットワークに過度な負荷がかからないようにすることができます。
- 時間を節約し、ネットワークの負荷を軽減する必要が生じた場合は、まず(種) VMのレプリカを取り外し可能なメディアに保存し、新しい場所に移動します。その後は、増分レプリケーションのみが必要となります。 NAKIVO Backup & Replication 組み込みの独自変更ブロック追跡機能およびVMwareの変更ブロック追跡機能を利用して、VMの増分レプリケーション(バックアップ)を実行できます。
- インストールできます NAKIVO Backup & Replication NASデバイス上で、デバイス間でデータをレプリケートし、パフォーマンスと速度の向上を実現します。
VMwareレプリケーションジョブの作成方法 NAKIVO Backup & Replication
以下では、VMware 環境向けの VM レプリケーション ジョブを作成する方法について説明します。 NAKIVO Backup & Replication. その手順はシンプルで直感的です。実際にご自身で確かめてみてください。
のメインUIでは NAKIVO Backup & Replication、クリック Create、次に選択して VMware vSphere replication job (環境によっては、以下の選択肢も可能です) Amazon EC2 replication job または Microsoft Hyper-V レプリケーション ジョブ).
その後、以下の手順に従ってください。
1. Source ～のステップ New Replication Job Wizard for VMware vSphere、レプリケートする仮想マシンまたは仮想マシンのコンテナ全体を選択し、[クリック] をクリックします Next.
2. の Destination 次に、レプリカについて、ターゲットコンテナ、ターゲットデータストア、およびVMフォルダを選択します。その後、[クリック] Next.
3. で Networks ターゲット(DR)サイトにいる場合は、VMがメインサイトとは異なるネットワークを使用するため、ネットワークマッピングを有効にして設定してください。設定が完了したら、[クリック] Nextあるいは、この手順をスキップして、[クリック] することもできます。 Next すぐに。
4. 画面の Re-IP この手順では、VMがメインサイトとは異なるIPアドレスをターゲット(DR)サイトで使用する場合に、IP変更ルーチンを設定できます。"Re-IP"ルールを作成するか、既存のルールを使用できます。その後、[クリック] Next. また、ここをクリックしてこの手順をスキップすることもできます Next すぐに。
5. 画面の Schedule この手順を実行すれば、レプリケーションジョブのスケジュール設定に非常に便利な方法が見つかるはずです。確認するには Do not schedule, run on demand これが1回限りのレプリケーションジョブである場合、またはスケジュールの具体的な詳細がまだ決まっていない場合。以下に Schedule #1、以下から選択できます Run daily/weekly (つまり、週に特定の曜日)、 Run monthly/yearly (つまり、1年のうち特定の月)、 Run periodically または Run after another job. もし～を選ぶなら Run after another job、例えば"ジョブ"を選択してください Z また、例えば、現在のジョブを次の後に実行するかどうかを設定したり、 Z 直ちに実施するか否か、また、それを開始すべきかどうか After successful runs, After failed runs、または After stopped runs. また、 別のスケジュールを追加する (#2、#3など)および カレンダーを表示 ご参考までに。設定の別の方法としては、 Effective fromこれは、レプリケーションジョブのスケジュールが有効になる日を決定します。
レプリケーション間隔が、レプリケーション対象のVMの最大RPOと一致していることを確認してください。
6. 画面の Retention この手順では、最大30個の復元ポイントを設定できます(レプリケーションジョブの完了後、 NAKIVO Backup & Replication (レプリカVMの復旧ポイントを作成する必要があります)。 NAKIVO Backup & Replication…という場合、従来の"祖父・父・子"方式を採用することができます。これは、レプリカやバックアップの保存において、DR(災害復旧)の観点から理想的な方式です。
7. 画面の Options このステップでは、残りのすべてのオプションを設定することで、レプリケーションジョブを最大限に自動化し、きめ細かな設定を行うことができます。レプリケーションジョブに名前を付け、アプリ対応モードの設定、変更追跡、ネットワーク高速化、暗号化、VMの検証、レプリカに使用するディスクの種類(シンディスクまたはレプリケートされたVMが使用するディスク)、ログの切り捨て、スクリプトの使用、転送モード、帯域幅の調整などを設定できます。
8. すべてのオプションの設定が完了したら、[クリック] Finish または Finish & Run (ジョブをすぐに実行したい場合)。レプリカの作成が完了すると、DRプロセスの準備が整います。
Site Recoveryジョブを作成する方法 NAKIVO Backup & Replication
先ほど作成したレプリケーションジョブは、以下の機能によって実現される、複雑な自動化されたDRワークフローの一部として活用できます。 Site Recovery 機能。この機能を活用することで、アクションや条件を整理し、特定の状況や目的(停電や災害回避など)に合わせた包括的なDRアルゴリズムを構築できます。
これにより、レプリケーションジョブをDRワークフローに次のように統合できます。 Site Recovery 記事:
1. で NAKIVO Backup & Replication メインUI、クリック Create、次に選択して Site recovery job.
2. New Site Recovery Job Wizard が開きます。ウィザードの Actions ステップを選択 Run jobs.
3. 以下の内容を確認できます Run Jobs ウィンドウが表示され、ここで、先ほど作成したジョブを含むレプリケーション・ジョブを選択できます。ジョブを選択して設定したら、[ Save.
4. その Actions このステップが再度開きます。このステップでは、複雑な災害復旧ワークフローに追加するアクションを選択するか、[ Next. その後は、単に以下の手順に従ってください。 New Site Recovery Job Wizardサイト復旧ジョブを作成するまで、の指示に従ってください。
結び
当社の製品は、ブロックベースおよびアプリケーション認識型のディザスタリカバリレプリケーションとバックアップ機能により、予期せぬダウンタイムや大規模な障害からお客様の仮想環境を保護します。ルールベースのポリシーを通じて、ディザスタリカバリレプリケーションプロセスを自動化・オーケストレーションし、複雑で包括的なワークフローに統合することが可能です。また、ネットワークアクセラレーションや変更追跡機能によりレプリケーションジョブを高速化できるほか、VM検証機能を通じてレプリカが正常に動作していることを確認できます。機能と価格については NAKIVO Backup & Replication 市場でも最高峰の製品の一つです。
実際にご自身の目で確かめ、試してみてください NAKIVO Backup & Replication 物理環境、仮想環境、またはクラウド環境において、ダウンロード 今すぐ、すべての機能が使える無料トライアルをお試しください！
