Azure における VM バックアップ インフラストラクチャの計画を立てる

この記事では、パフォーマンスとリソースに関する提案を行い、VM のバックアップ インフラストラクチャを計画するお手伝いをします。 さらに、Backup サービスの主要な側面を定義します。これらの側面は、アーキテクチャの決定、容量計画、スケジューリングの際の重要な要素になることがあります。 必要な環境の準備が済んだら、VM のバックアップを開始する前に行う次の手順は計画の作成です。 Azure 仮想マシンについて詳しい情報が必要な場合は、「Virtual Machines のドキュメント」を参照してください。

Azure における仮想マシン バックアップの動作

Azure Backup サービスは、スケジュールされた時刻にバックアップ ジョブを開始し、バックアップ拡張機能をトリガーして特定時点のスナップショットを作成します。 Azure Backup サービスは、Windows の_VMSnapshot_ 拡張機能、および Linux の VMSnapshotLinux 拡張機能を使用します。 拡張機能は、最初の VM バックアップ中にインストールされます。 拡張機能をインストールするには、VM が実行されている必要があります。 VM が実行されていない場合、Backup サービスは基盤となるストレージのスナップショットを取ります (VM が停止している間はアプリケーション書き込みが行われないため)。

Windows VM のスナップショットを取るとき、Backup サービスは Volume Shadow Copy Service (VSS) と連携して仮想マシンのディスクの一貫したスナップショットを取得します。 Linux VM をバックアップしている場合、VM スナップショットを取るときの整合性を確保できるよう自分のカスタム スクリプトを記述することができます。 これらのスクリプトを呼び出すための詳細については、この記事の後半で説明します。

Azure Backup サービスがスナップショットを取ると、データはバックアップコンテナーに転送されます。 効率を最大に高めるために、前回のバックアップ以降に変更されたデータ ブロックが特定され、そのデータのみが転送されます。

Azure 仮想マシンのバックアップ アーキテクチャ

データ転送が完了すると、スナップショットが削除され、回復ポイントが作成されます。

注意

  1. バックアップ プロセス中、Azure Backup には仮想マシンに接続された一時ディスクは含まれません。 詳細については、ブログの一時記憶域をご覧ください。
  2. Azure Backup はストレージ レベルのスナップショットを取得してそのスナップショットをバックアップコンテナーに転送するため、バックアップ ジョブが終了するまでストレージ アカウント キーを変更しないでください。
  3. プレミアム VM の場合、ストレージ アカウントにスナップショットをコピーします。 これは、Azure Backup サービスにデータをコンテナーに転送するために必要十分な IOPS を与えるための措置です。 ストレージをこの方法で付加的にコピーするとき、VM の割り当てサイズに基づいて課金されます。

データの一貫性

業務に不可欠なデータのバックアップと復元は、その生成元となるアプリケーションの実行中にバックアップを行う必要があるため簡単ではありません。 これに対処するために、Azure Backup では、Windows VM と Linux VM のアプリケーション整合性バックアップをサポートしています。

Windows VM

Azure Backup は、Windows VM 上で VSS 完全バックアップを行います ( VSS 完全バックアップの詳細をご覧ください)。 VSS コピー バックアップを有効にするには、VM に以下のレジストリ キーを設定する必要があります。

[HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\BCDRAGENT]
"USEVSSCOPYBACKUP"="TRUE"

Linux VM

Azure Backup はスクリプトのフレームワークを提供します。 Linux VM をバックアップしているときのアプリケーション整合性を確保するには、バックアップのワークフローと環境を制御する、カスタムの事前スクリプトと事後スクリプトを作成します。 Azure Backup は、VM スナップショットを取る前に事前スクリプトを呼び出し、VM スナップショット ジョブが完了したら事後スクリプトを呼び出します。 詳細については、事前スクリプトと事後スクリプトを使用した VM のアプリケーション整合性バックアップをご覧ください。

注意

Azure Backup は、ユーザーが書き込んだ事前スクリプトと事後スクリプトだけを呼び出します。 事前スクリプトと事後スクリプトが正常に実行されると、Azure Backup は復旧ポイントをアプリケーション整合性としてマークします。 ただし、カスタム スクリプトを使用したときのアプリケーション整合性の最終的な責任はユーザーが担います。

この表は、整合性の種類を一覧にしたものです。Azure VM のバックアップと復元で確保される状態をそれぞれ説明しています。

整合性 VSS ベース 説明と詳細
アプリケーション整合性 あり - Windows の場合 アプリケーション整合性は、以下を保証するのでワークロードに最適です。
  1. "VM が起動します"。
  2. "破損がない"。
  3. "データの損失がない"。
  4. バックアップの時点で VSS または事前/事後スクリプトを使用してアプリケーションを関連付けるので、データとそのデータを使用するアプリケーションとの間で整合性が保たれる。
  • Windows VM - ほとんどの Microsoft ワークロードには、データ整合性に関連するワークロード固有のアクションを実行する VSS ライターがあります。 たとえば、Microsoft SQL Server には、トランザクション ログ ファイルとデータベースへの書き込みが正常に行われることを保証する VSS ライターがあります。 Azure Windows VM のバックアップの場合、アプリケーション整合性復旧ポイントを作成するには、VM スナップショットを作成する前に、バックアップ拡張機能が VSS ワークフローを呼び出し、ワークフローを完了する必要があります。 Azure VM のスナップショットが正確であるためには、すべての Azure VM アプリケーションの VSS ライターも完了する必要があります。 (VSS の基本と詳しいしくみを確認してください)。
  • Linux VM - ユーザーがカスタムの事前スクリプトと事後スクリプトを実行してアプリケーション整合性を確保できます。
  • ファイル システム整合性 あり - Windows ベースのコンピューターの場合 復旧ポイントでファイルシステム整合性が保たれるシナリオとしては、次の 2 つがあります。
    • Azure の Linux VM のバックアップ (事前スクリプト/事後スクリプトがない場合または事前スクリプト/事後スクリプトが失敗した場合)。
    • Azure 内の Windows VM のバックアップ中の VSS の障害。
    どちらの場合でも、次のことを確保することが重要です。
    1. "VM が起動します"。
    2. "破損がない"。
    3. "データの損失がない"。
    アプリケーションでは、復元されたデータに対する独自の "修正" メカニズムを実装する必要があります。
    クラッシュ整合性 いいえ この状況は、(ソフト リセットまたはハード リセットにより) 仮想マシンが "クラッシュ" した状況に相当します。 クラッシュ整合性は通常、バックアップ時に Azure 仮想マシンがシャットダウンされるときに発生します。 クラッシュ整合性の復旧ポイントは、オペレーティング システムの観点からもアプリケーションの観点からも、ストレージ メディア上のデータの整合性に関して何も保証しません。 バックアップ時にディスクに既に存在していたデータのみが、キャプチャされバックアップされます。

    保証はありませんが、通常、OS は起動します。その後、chkdsk などのディスク検査手順が実行されて、破損エラーがあれば修正されます。 メモリ内にあったデータや、ディスクに転送されていなかった書き込みは、すべて失われます。 通常、アプリケーションは、データのロールバックを実行する必要がある場合に独自の検証メカニズムに従います。

    たとえば、データベースに存在しないエントリがトランザクション ログにある場合、データベース ソフトウェアは、データの整合性が得られる時点までロールバックします。 (スパン ボリュームのように) データが複数の仮想ディスクにまたがる場合、クラッシュ整合性の復旧ポイントは、データの正確性に関して何も保証しません。

    パフォーマンスおよびリソース使用率

    Azure で VM をバックアップする場合、オンプレミスにデプロイされるバックアップ ソフトウェアと同様に、必要な容量とリソースの使用率を考慮する必要があります。 Azure Storage の制限 には、実行中のワークロードに対する影響を最小に抑え、パフォーマンスを最大にする VM のデプロイメントの構成が定義されています。

    バックアップのパフォーマンスを計画する際は、Azure Storage の次の制限に注意してください。

    • ストレージ アカウントあたりの最大送信速度
    • ストレージ アカウントあたりの合計要求レート

    ストレージ アカウントの制限

    バックアップ データがストレージ アカウントからコピーされ、ストレージ アカウントの 1 秒あたりの入力/出力操作数 (IOPS) および送信速度 (またはスループット) メトリックに追加されます。 このとき同時に、仮想マシンも IOPS とスループットを消費しています。 この目的は、バックアップおよび仮想マシンのトラフィックが、ストレージ アカウントの制限を超過しないようにすることです。

    ディスクの数

    バックアップ プロセスは、バックアップのジョブを可能な限り早く完了しようとします。 そのため、バックアップ プロセスは可能な限り多くのリソースを使用します。 ただし、すべての I/O 操作には 1 秒あたり 60 MB の 「単一 BLOB のターゲット スループット」の制限があります。 速度を最大にするため、バックアップ プロセスは各 VM のディスクを 「並列」でバックアップしようとします。 VM にディスクが 4 つある場合、サービスは 4 つすべてのディスクを並列でバックアップしようとします。 バックアップしているディスクの数は、ストレージ アカウント バックアップ トラフィックを決定する際に最も重要な要因です。

    バックアップ スケジュール

    パフォーマンスに影響を与えるもう 1 つの要因は、 バックアップ スケジュールです。 すべての VM が同時にバックアップされるようなポリシーを構成すると、トラフィックが輻輳します。 バックアップ プロセスはすべてのディスクを並列でバックアップしようとします。 ストレージ アカウントからのバックアップ トラフィックを減らすには、それぞれの VM を 1 日の異なる時間帯に、重複せずにバックアップされるようにします。

    容量計画

    以上の要素を総合して、ストレージ アカウントの使用ニーズを計画する必要があります。 ディスクに対する影響およびバックアップ スケジュールの選択肢を確認するには、 VM のバックアップ容量計画に関する Excel スプレッドシート をダウンロードしてください。

    バックアップのスループット

    バックアップ対象の各ディスクは、Azure Backup がディスク上のブロックを読み込み、変更されたデータのみを格納します (増分バックアップ)。 次の表では、Backup サービスのスループットの平均値を示します。 次のデータを使うと、特定のサイズのディスクをバックアップするために必要な時間を見積もることができます。

    バックアップ操作 最適なスループット
    初回バックアップ 160 Mbps
    増分バックアップ (DR) 640 Mbps

    変更された (バックアップする必要がある) データがディスク全体に分散している場合、スループットが大幅に低下します。

    VM のバックアップの合計時間

    バックアップ時間のほとんどはデータの読み取りとコピーに費やされますが、VM のバックアップには、他にも必要な合計時間に影響を与える操作があります。

    • バックアップ拡張機能のインストールまたは更新の所要時間。
    • スナップショットの時間。スナップショットをトリガーするのにかかった時間です。 スナップショットは、スケジュールされたバックアップ時刻の近くでトリガーされます。
    • キューの待機時間。 Backup サービスは複数の顧客のバックアップを処理するので、スナップショットから Backup コンテナーまたは Recovery Services コンテナーへのバックアップ データのコピーは直ちには開始されない場合があります。 負荷のピーク時には、処理するバックアップ数に応じて、待機時間が最大 8 時間まで延長される可能性があります。 ただし、毎日のバックアップ ポリシーでは、VM バックアップの合計時間は 24 時間未満になります。
    • データ転送時間。バックアップ サービスが前回のバックアップからの増分変更を計算し、これらの変更をコンテナー ストレージに転送するために必要な時間です。

    バックアップ時間が長い (12 時間超) 理由

    バックアップは、スナップショットの作成と、コンテナーへのスナップショットの転送という、2 つのフェーズで構成されています。 Backup サービスはストレージ用に最適化されます。 スナップショット データをコンテナーに転送するとき、サービスは前のスナップショットからの増分変更のみを転送します。 増分変更を特定するため、サービスはブロックのチェックサムを計算します。 変更されたブロックは、コンテナーに送信されるブロックとして識別されます。 その後、サービスは識別された各ブロックをさらに詳しく調べて、転送するデータを最小化する可能性を探ります。 変更されたブロックをすべて評価した後、サービスは変更箇所を結合して、コンテナーに送ります。 一部のレガシ アプリケーションでは、小さい断片化した書き込みはストレージにとって最適ではありません。 スナップショットに小さい断片化した書き込みが多く含まれる場合、サービスはアプリケーションによって書き込まれたデータの処理に余分な時間を費やします。 VM 内部で実行するアプリケーションについて、Azure が推奨するアプリケーション書き込みブロックの大きさは、8 KB 以上です。 アプリケーションが 8 KB 未満のブロックを使っている場合、バックアップのパフォーマンスに影響があります。 バックアップのパフォーマンスが向上するアプリケーションの調整については、Azure Storage でのパフォーマンスが最適になるようなアプリケーションのチューニングをご覧ください。 バックアップのパフォーマンスに関する記事では Premium Storage の例が使われていますが、ガイダンスは Standard Storage のディスクにも当てはまります。

    合計復元時間

    復元操作は、2 つの主要なサブ タスクで構成されています。コンテナーから選択したユーザーのストレージ アカウントへのデータのコピーと、仮想マシンの作成です。 コンテナーからのデータのコピーは、バックアップが Azure 内部で保存される場所や、ユーザーのストレージ アカウントが保存される場所によって異なります。 データのコピーに使用される時間は、次に依存します。

    • キュー待機時間: サービスは複数のユーザーからの復元ジョブを同時に処理するため、復元要求はキューに入れられます。
    • データ コピー時間: データがコンテナーからユーザーのストレージ アカウントにコピーされます。 復元時間は、選択したユーザーのストレージ アカウントで Azure Backup サービスが取得する IOPS とスループットに依存します。 復元処理中のコピー時間を短縮するには、他のアプリケーションの書き込みと読み取りが読み込まれないストレージ アカウントを選びます。

    ベスト プラクティス

    仮想マシンのバックアップを構成するときには、次のプラクティスに従うことをお勧めします。

    • 同じクラウド サービスから同時にバックアップを行うクラシック VM の数が 10 を超えないようにスケジュールしてください。 同じクラウド サービスから複数の VM をバックアップしたい場合は、バックアップの開始時刻を 1 時間ずつずらしてください。
    • VM を同時にバックアップする場合は、数が 40 を超えないようにスケジュールしてください。
    • VM バックアップを非ピーク時にスケジュールします。 こうすれば、バックアップ サービスは IOPS を、ユーザーのストレージ アカウントからコンテナーへデータを転送するために使用します。
    • ポリシーが、異なるストレージ アカウントに分散されている VM にも適用されることを確認します。 1 つのストレージ アカウント内で同じバックアップ スケジュールによって保護されるディスクは、20 個以下がお勧めです。 1 つのストレージ アカウント内に 20 を超えるディスクがある場合は、それらの VM を複数のポリシーに分散させることで、必要な IOPS をバックアップ プロセスの転送フェーズ中に実現できます。
    • Premium ストレージで実行されている VM を同じストレージ アカウントに復元しないでください。 復元操作のプロセスがバックアップ操作と重なった場合は、バックアップ用の IOPS が減ります。
    • Premium VM バックアップでは、バックアップが成功するために、Premium ディスクをホストするストレージ アカウントにスナップショットをステージングするための空き領域が 50% 以上あることを確認してください。
    • バックアップ用に有効になっている Linux VM の該当の Python のバージョンが 2.7 であることを確認してください。

    データの暗号化

    Azure Backup では、データはバックアップ プロセスの一部として暗号化されません。 ただし、VM 内でデータを暗号化し、保護されたデータをシームレスにバックアップできます ( 暗号化データのバックアップの詳細をご覧ください)。

    保護するインスタンスのコストの計算

    Azure Backup を使用してバックアップされている Azure 仮想マシンは、 Azure Backup の価格の対象になります。 保護するインスタンスの計算は、仮想マシンの "実際" のサイズ ("リソース ディスク" を除く、仮想マシン上の全データの合計) に基づきます。

    VM をバックアップする価格は、仮想マシンに接続されている各データ ディスクの最大サポート サイズに基づき "ません"。 価格は、データ ディスクに格納された実際のデータに基づきます。 同様に、バックアップ ストレージの課金は、Azure Backup に格納されているデータ量 (各回復ポイントの実際のデータの合計) に基づきます。

    たとえば、最大サイズが各 1 TB のデータ ディスクが 2 台追加で搭載されている A2 標準サイズの仮想マシンがあります。 次の表は、これらの各ディスクに格納されている実際のデータです。

    ディスクの種類 最大サイズ 実際のデータ量
    オペレーティング システム ディスク 1023 GB 17 GB
    ローカル ディスク / リソース ディスク 135 GB 5 GB (バックアップに含まれない)
    データ ディスク 1 1023 GB 30 GB
    データ ディスク 2 1023 GB 0 GB

    この場合の仮想マシンの 実際 のサイズは、17 GB + 30 GB + 0 GB = 47 GB です。 この保護するインスタンスのサイズ (47 GB) が、毎月の課金の基礎になります。 仮想マシンのデータ量が大きくなると、課金に使用される保護インスタンスのサイズもそれに応じて変化します。

    課金は、最初のバックアップが正常に完了するまでは開始されません。 この時点では、ストレージと保護するインスタンスの両方に対する課金が開始されます。 仮想マシンのコンテナーに格納されているバックアップ データがある限り、課金は継続します。 仮想マシンの保護を停止しても、仮想マシンのバックアップ データがコンテナーに存在していると、課金は継続します。

    保護が停止されてさらにすべてのバックアップ データが削除されている場合のみ、指定した仮想マシンの課金が停止します。 保護が停止してアクティブなバックアップ ジョブがないとき、最後に成功した VM バックアップのサイズは、毎月の課金に使用する保護インスタンスのサイズになります。

    疑問がある場合は、

    ご不明な点がある場合や今後搭載を希望する機能がある場合は、 フィードバックをお送りください

    次のステップ