サイト内の現在位置を表示しています。

AzureでAzure VM Backupを利用したミラーディスク型HAクラスターのバックアップ・リストアを試してみました(Linux)

CLUSTERPRO オフィシャルブログ ~クラブロ~

はじめに

Microsoft Azure(以降、Azure)に構築したミラーディスク型のHAクラスターについて、Azure VM Backupを利用してバックアップ・リストアを試してみました。

Azure Backupでは様々なデータをバックアップすることが可能です。その一つであるAzure VM BackupはAzure Virtual Machines(以降、VM)全体をバックアップ対象にすることができます。
今回はAzure上に構築したミラーディスク型のHAクラスターについて、Azure VM Backupを利用したシステムディスクとミラーディスクのバックアップとリストアを行う手順をご紹介します。

この記事の内容

1. Azure Backupとは

Azure Backupは、Azureに関連する様々なデータをバックアップ、復元(リストア)することが出来るサービスです。
Azure VMやAzure Managed Disks、Azure VM内のSQL ServerのようなAzure環境上のデータだけでなく、オンプレミス環境上のVMやファイルなどの様々なデータをバックアップしてリストアすることが可能です。

今回はAzure上に構築したミラーディスク型HAクラスターのバックアップおよび復元(リストア)を、Azure VMをバックアップ対象にするAzure VM Backupを利用して行ってみました。

2. バックアップ・リストア対象のHAクラスター構成

東日本リージョンの環境に「内部ロードバランサーを使用したミラーディスク型のHAクラスター」を構築します。構築したミラーディスク型クラスターに対して、バックアップ・リストアを実行します。

Composition

HAクラスターの構築手順は、HAクラスタ構築ガイドを参照ください。
今回は構築手順の構成に加え、ミラーディスクリソースをもう1つ追加しました。

【参考】
  • クラウド > Microsoft Azure > HAクラスタ 構築ガイド
     → 構築手順(内部ロードバランサーを使用したHAクラスタの場合)

また、CLUSTERPROの構成は以下の通りです。
適宜ご利用の環境に合わせて読み替えてください。

  • CLUSTERPRO

  • ホスト名
  • ■ サーバー1(通常時は現用系)    :server1
  • ■ サーバー2(通常時は待機系)    :server2
  •  
  • フェールオーバーグループ        :failover
  • ■ Azureプローブポートリソース  :azurepp
  • ■ ミラーディスクリソース       :md
  • ■ ミラーディスクリソース2      :md2
  •  
  • モニタリソース
  • ■ Azureロードバランスモニタリソース    :azurelbw1
  • ■ Azureプローブポートモニタリソース    :azureppw1
  • ■ ミラーディスクコネクトモニタリソース :mdnw1
  • ■ ミラーディスクモニタリソース         :mdw1
  • ■ ミラーディスクコネクトモニタリソース2:mdnw2
  • ■ ミラーディスクモニタリソース2        :mdw2
  •  

Linuxでミラーディスク型クラスターを構築する際に、デバイスファイル名を指定する必要がありますが、AzureではVM起動などのタイミングでデバイスファイル名が変更されることがあります。
そのため、論理ボリュームを設定する、もしくはシンボリックリンクをデバイス名に指定することを推奨いたします。

論理ボリュームを設定する場合は以下のリンクから「論理ボリュームを利用したミラーディスク型クラスター構築」を参照し、作成した論理ボリュームをミラーディスクリソースに指定してください。

シンボリックリンクをデバイス名に指定する場合は以下を参照し、クラスターパーティション、データパーティションのシンボリックリンクをミラーディスクリソースに指定してください。

3. Azure VM Backupの設定

Azure VM Backupでは、バックアップしたデータ、および復元ポイントがRecovery Services コンテナーに格納されます。この復元ポイントを使用して、データを特定の時点に復元できます。
バックアップの整合性はアプリケーション整合性/ファイルシステム整合性、またはクラッシュ整合性を選択可能です。アプリケーション整合性/ファイルシステム整合性のバックアップではスナップショットと連携するため、VMにエージェントが必要です。

第4章で詳細を解説しますが、今回のバックアップはCLUSTERPROのメンテナンスガイドに従い、VMをシャットダウンした状態でバックアップを取得するため、クラッシュ整合性のバックアップとなります。

  • リンク先のMicrosoft公式ドキュメントの日本語表記は「復元ポイント」と「復旧ポイント」とで表記の揺れがある場合があります。
    本記事では、「復元ポイント」に統一して記述します。

この章では、Azure VM Backupを実行するための事前設定として、Recovery Services コンテナーとバックアップポリシー、およびバックアップの設定について解説します。

3.1 Recovery Services コンテナーの作成

まずはRecovery Services コンテナーを作成します。
手順は以下を参考にしました。

【参考】
  • Recovery Services コンテナーを作成する
  • バックアップ センターのメニューの概要ペインで[+ コンテナー]をクリックし、コンテナーの作成画面に遷移します。

  • [Recovery Services vault]を選択し、続行をクリックします。

  • 基本・冗長・暗号化・コンテナーのプロパティ・ネットワーク・タグの項目にそれぞれ値を入力して、Recovery Services コンテナーを作成します。
    今回は東日本リージョンのVMが存在するリソースグループにコンテナーを作成します。
    基本以外の項目はデフォルトのままとしました。

なお、既定では、Recovery Services コンテナーの冗長オプションはgeo冗長ストレージ(GRS)が使用されますが、ローカル冗長ストレージ(LRS)、ゾーン冗長ストレージ(ZRS)を選択することも可能です。Azure Storageの冗長性は運用ポリシーに応じて適宜選択ください。
冗長オプションは、ストレージレプリケーションの設定から変更可能です。
ただし、バックアップの取得後は変更できず、変更するにはRecovery Services コンテナーの再作成が必要となるためご注意ください。

【参考】
  • ストレージ レプリケーションを変更する

3.2 バックアップポリシーの作成

次にバックアップポリシーを作成します。
バックアップポリシーではバックアップの頻度と保持期間の設定を行います。バックアップポリシーはデフォルトで用意されていますが、今回は新規にバックアップポリシーを作成します。
手順は以下を参考にしました。

【参考】
  • カスタム ポリシーの作成
  • バックアップセンターのメニューの[管理]を展開して[バックアップポリシー]ペインを表示し、[+ 追加]をクリックします。

  • [データソースの種類]で「Azure 仮想マシン」を選択し、[コンテナー]で「3.1 Recovery Services コンテナーの作成」で作成したRecovery Services コンテナーを選択して、続行をクリックします。

  • [ポリシーの作成]の設定項目が表示されますので、それぞれ値を入力します。
    今回はテストのため、[ポリシーのサブタイプ]を「Standard」、[バックアップスケジュール]を「毎日」、[バックアップポイントの保有期間]を最短の「7日」に設定しました。

  • Enhanced(拡張)ポリシーを利用すると、1日あたり複数のバックアップ、最大30日間の運用レベルのデータ保持などが可能となりますが、追加のコストが発生する場合があります。

  • Azure VM Backupはスケジュールによる定期実行の設定が必須となります。
    本記事では上述の通り、VMをシャットダウンした状態にするため、実際の運用ではAzure VM Backupの定期実行の前に第4章で解説するバックアップの事前作業をジョブで行う、またはAzure VM Backupをコマンドで実行して一連のジョブに組み込むなどの運用設計が必要になりますのでご注意ください。

3.3 バックアップの設定

最後にバックアップの設定を行います。
手順は以下を参考にしました。

【参考】
  • バックアップ ポリシーを適用する
  • バックアップ センターのメニューの概要ペインで[+ バックアップ]をクリックすると[バックアップの構成]の設定項目が表示されます。
    [データソースの種類]に「Azure 仮想マシン」を選択し、[コンテナー]で「3.1 Recovery Services コンテナーの作成」で作成したRecovery Servicesコンテナーを選択して続行をクリックします。

  • 続いて、[ポリシーのサブタイプ]に「Standard」、[バックアップ ポリシー]に「3.2 バックアップポリシーの作成」で作成したバックアップ ポリシー、[仮想マシン]にHAクラスターを構成するサーバーを選択します。
    その際、[ディスク]にはミラーディスクリソースで設定したクラスタパーティション、データパーティションのディスクを全て含むように設定してください。
    最後に[バックアップの有効化]をクリックして、バックアップを有効化します。

  • Azure VM Backupではシステムディスク、追加ディスクを含めたVM全体のバックアップを取得することができます。
    追加ディスクを除外することはできますが、システムディスクを除外することはできないため、追加ディスクのみをバックアップ対象とすることはできません。

4. Azure VMのバックアップ手順

現用系/待機系のそれぞれについてAzure VM全体のバックアップを行います。
HAクラスターの実行状態によるバックアップデータへの影響を防止する観点から、システムディスクのバックアップはOSを停止した状態で行うことを推奨します。

待機系サーバーのバックアップ手順の流れは以下の通りです。
現用系サーバーをバックアップする際は、フェールオーバーグループを待機系サーバーへフェールオーバーした後に、同様の手順で行います。

  • フェールオーバーグループの停止とミラーディスクの同期の停止
  • 待機系サーバーでバックアップの事前処理コマンドを実行
    clpbackup --pre
  • 待機系サーバーのAzure VM バックアップ
  • 待機系サーバーでバックアップの事後処理コマンドを実行
    clpbackup --post
  • 現用系サーバーでミラーディスク監視を再開

バックアップの手順については以下を参照してください。

【参考】
  • CLUSTERPRO X 5.2 > Linux > メンテナンスガイド

  • 2.19 ミラー/ハイブリッドディスクをディスクイメージでバックアップするには
  • 2.19.2 現用系/待機系のミラーディスクを片サーバずつバックアップする場合

4.1 フェールオーバーグループの停止とミラーディスクの同期の停止

まず、ミラーディスクが正常に同期できていることを確認します。
同期状態の確認後、静止点を確保するために、フェールオーバーグループを停止します。

  • ミラーディスクが正常に同期できていることを確認します。
  •   現用系サーバーで以下のコマンドを実行します。
  •  出力された結果のMirror Statusが"Normal"であり、現用系/待機系両方のサーバーのMirror Colorが"Green"であることを確認します。
    なお、コマンドの戻り値によりミラーディスクの状態を判定することも可能です。現用系/待機系の両サーバーが正常(GREEN)の場合、17が返却されます。
  •   ※ミラーディスクリソースが複数ある場合は全てのミラーディスクリソースで確認します。

  •  実行例
# clpmdstat --mirror md
Mirror Status: Normal


  md                               server1               server2
  ------------------------------------------------------------------
  Mirror Color                GREEN                GREEN

# echo $?
17

# clpmdstat --mirror md2
Mirror Status: Normal


  md2                             server1               server2
  ------------------------------------------------------------------
  Mirror Color                GREEN                GREEN

# echo $?
17


  • フェールオーバーグループを停止します。
  •   現用系サーバーで以下のコマンドを実行します。

  •   実行例
# clpgrp -t failover
Command succeeded.

  • 自動ミラー復帰が動作しないようにするために、現用系/待機系両方のサーバーのミラーディスクモニタリソースを一時停止します。
  •   現用系サーバーで以下のコマンドを実行します。
  •   ※ミラーディスクモニタリソースが複数ある場合は全てのミラーディスクモニタリソースを一時停止します。

  •  実行例
# clpmonctrl -s -h server1 -m mdw1
Command succeeded.
# clpmonctrl -s -h server2 -m mdw1
Command succeeded.
# clpmonctrl -s -h server1 -m mdw2
Command succeeded.
# clpmonctrl -s -h server2 -m mdw2
Command succeeded.

  • ミラーディスクの同期を停止します。
  •  待機系サーバーで以下のコマンドを実行します。
  •   ※ミラーディスクリソースが複数ある場合は全てのミラーディスクリソースの同期を停止します。

  •  実行例
# clpmdctrl --break md
md: Isolated completed successfully
# clpmdctrl --break md2
md2: Isolated completed successfully

  • 現用系サーバーのフェールオーバーグループを起動します。
    フェールオーバーグループを起動した時点から業務を再開できます。 これにより、業務停止時間を最小限に抑えて、待機系サーバーのバックアップを取得できます。
  •  現用系サーバーで以下のコマンドを実行します。

  •  実行例
# clpgrp -s failover
Command succeeded.

4.2 待機系サーバーでバックアップの事前処理コマンドを実行

バックアップの事前処理コマンドを実行することで、ミラーディスクをバックアップモードに変更、CLUSTERPROの各種サービスの自動起動をオフに設定し、サーバーをシャットダウンします。

  • 待機系サーバーで以下のコマンドを実行します。

  •  実行例
# clpbackup.sh --pre
clpbackup.sh : Beginning backup-mode.
All backup flags have set to <ON>.
clpbackup.sh : Changing the setting of cluster services to Manual Startup.
clpbackup.sh : Shutting down...
Command succeeded.
clpbackup.sh : Command succeeded.

4.3 待機系サーバーのAzure VMのバックアップ

基本的にバックアップポリシーの設定のとおりにバックアップされますが、今回はテストのため、手動でバックアップします。手順は以下を参考にしました。

【参考】
  • 初回バックアップをトリガーする
なお、Azure Portalからの操作以外に、Azure CLIを利用することも可能です。

  • バックアップセンターのメニューの[管理]を展開して[インスタンスのバックアップ]ペインを表示します。

  • バックアップするVM行を右クリック、または右端の[…]アイコンをクリックし、[今すぐバックアップ]をクリックします。
    今回はテストのため、バックアップ保持期限は最短の2日間にします。

  • バックアップの状況を確認するには、バックアップセンターの[監視とレポート]を展開して[バックアップ ジョブ]ペインを表示し、該当のジョブをクリックします。

4.4 待機系サーバーでバックアップの事後処理コマンドを実行

バックアップの事後処理コマンドを実行することで、ミラーディスクを通常モードに変更、CLUSTERPROの各種サービスの自動起動をオンに設定し、サーバーを再起動します。

待機系サーバーのバックアップが完了したら、次の操作を行います。

  • Microsoft Azure ポータルから、待機系サーバーを起動します。

  • 待機系サーバーで以下のコマンドを実行します。

  •  実行例
# clpbackup.sh --post
clpbackup.sh : Starting Mirror Agent.
Command succeeded.
clpbackup.sh : Ending backup-mode.
All backup flags have set to <OFF>.
clpbackup.sh : Changing the setting of cluster services to Auto Startup.
clpbackup.sh : Stopping Mirror Agent.
Command succeeded.
clpbackup.sh : Rebooting...

4.5 現用系サーバーでミラーディスク監視を再開

現用系サーバーのミラーディスク監視を再開します。

  • 現用系サーバーで以下のコマンドを実行します。
  •   ※ミラーディスクモニタリソースが複数ある場合は全てのミラーディスクモニタリソースを再開します。
  •   ※待機系サーバーは再起動後に、自動的にクラスターへ復帰し、ミラーディスク監視も自動的に再開します。

  •  実行例
# clpmonctrl -r -h server1 -m mdw1
Command succeeded.
# clpmonctrl -r -h server1 -m mdw2
Command succeeded.

4.6 バックアップ対象を切り替えてバックアップ

フェールオーバーグループをフェールオーバーし、バックアップ対象を切り替えた後に、もう片方のサーバーもバックアップします。

  • フェールオーバーグループを待機系にフェールオーバーします。
  •  現用系サーバーで以下のコマンドを実行します。

  •  実行例
# clpgrp -m failover
Command succeeded.

  • フェールオーバーが完了したら、4.1~4.5を実施しもう片方のサーバーもバックアップします。

5. Azure VMのリストア手順

Recovery Services コンテナーに格納されている復元ポイントからAzure VMデータを復元します。
今回は、現用系/待機系両方のサーバーのシステムディスクと2つのミラーディスクに異常が発生し、交換する想定で、システムディスク、2つのミラーディスクをまとめてリストアします。

リストア手順の流れは以下の通りです。

  • Azure VMのリストア
  • ミラーディスクの設定確認
  • リストアの事後処理コマンドを実行
    clprestore --post
  • ミラーディスクのミラー復帰

リストアの手順の詳細については以下を参照してください。

【参考】
  • 既存のディスクの置き換え

  • CLUSTERPRO X 5.2 > Linux > メンテナンスガイド

  • 2.18 仮想マシンをリストアするには -ミラーディスクの場合-
  • 2.20 ミラー/ハイブリッドディスクにディスクイメージをリストアするには
  • 2.20.2 現用系/待機系の両サーバにミラーディスクイメージをそれぞれ同時にリストアする場合

なお、今回ご紹介する手順では既存のVMを置き換える方式を採用しているため追加ライセンスは必要ありませんが、バックアップから新たにVMを作成する方式でリストア(複製)する場合は、複製先の環境用のライセンスを追加で用意する必要があります。

5.1 Azure VMのリストア

現用系/待機系両方のサーバーをリストアします。
まずはサーバーをシャットダウンし、その後、リストアを開始します。
サーバーをシャットダウンした後の手順は、現用系/待機系両方のサーバーそれぞれで実行してください。

  • クラスターをシャットダウンします。
  •  現用系サーバーで以下のコマンドを実行します。

  •  実行例
# clpstdn
Command succeeded.

  • バックアップセンターのメニューの[管理]を展開して[インスタンスのバックアップ]ペインを表示します。
    バックアップするVM行を右クリック、または右端の[…]アイコンをクリックし、[復元]をクリックします。
    次に、復元ポイントの選択を行うため、選択をクリックします。

  • 表示された一覧の中から復元ポイントを選択します。

  • [復元の構成]は「既存を置換」を選択します。
    ステージングの場所を選択してリストアを開始します。
    バックアップの時と同様、リストアの状況を確認するには、バックアップセンターの[監視とレポート]を展開して[バックアップ ジョブ]ペインを表示し、該当のジョブをクリックします。

  • [復元の構成]で「新規作成」を選択すると、新規にVMを作成することができます。
    ただし新規にVMを作成する場合、上述した通り新規作成したVM用のCLUSTERPROライセンスを追加で購入する必要がありますのでご注意ください。

5.2 ミラーディスクの設定確認

リストア完了後、ディスクの設定確認を実施します。
なお、第2章で解説した通り、ミラーディスクリソースのデバイスファイル名に論理ボリュームのデバイス名を指定、またはシンボリックリンクを指定している場合は、本手順は不要です。
次の手順5.3に進んでください。

  • Microsoft Azure ポータルから、現用系/待機系両方のサーバーを起動します。

  • リストアしたクラスタパーティションやデータパーティションのパスを確認します。
    パスが変わっている場合は、Cluster WebUIを起動し、「設定モード」から、ミラーディスクリソースのプロパティで、リソースのプロパティの[詳細]タブのデータパーティションデバイス名とクラスタパーティションデバイス名に正しいパスを入力します。

    確認後、設定の反映を実行します。
  •   ※ミラーディスクリソースが複数ある場合はディスクデバイス名の入れ替わりが発生していないか、特に注意が必要です。
    ディスクデバイス名の入れ替わりが発生しないよう、「2.バックアップ・リストア対象のHAクラスター構成」で記述したように論理ボリュームを設定する、もしくはシンボリックリンクをデバイス名に指定することを推奨します。

5.3 リストアの事後処理コマンドを実行(現用系/待機系)

リストア完了後、事後処理コマンドを実行することで、自動的にCLUSTERPROの各種サービスの自動起動をオンにして、サーバーを再起動します。

  • Microsoft Azure ポータルから、現用系/待機系両方のサーバーを起動します。
    (手順5.2で起動している場合は次の手順に進んでください)

  • OSごとリストアしたため、実際の運用では、バックアップのタイミングの違いにより、現用系サーバーと待機系サーバーでCLUSTERPROの設定が異なる可能性があります。その場合は正しい設定に修正し、設定を反映してください。

  • 現用系/待機系両方のサーバーで、以下のコマンドを実行します。

  •  実行例
# clprestore.sh --post
clprestore.sh : Changing the setting of cluster services to Auto Startup.
clprestore.sh : Rebooting...

5.4 ミラーディスクのミラー復帰

サーバーの再起動後、ミラーディスクリソースのステータスが異常となりますので、ミラーディスクリソースを正常な状態にしてミラー復帰を開始します。

  • フェールオーバーグループが起動しているサーバーを確認します。
  •  server1、server2いずれかのサーバーで以下のコマンドを実行します。
  •  出力された結果のcurrentと表示されたサーバーがフェールオーバーグループが起動しているサーバーとなります。
  • 以下の実行例では、server1と表示されているため、server1でフェールオーバーグループが起動していることが分かります。

  •  server1で実行した例
# clpstat
======================== CLUSTER STATUS ===========================
Cluster : cluster
<server>
*server1 ...: Online
  lankhb1 : Normal Kernel Mode LAN Heartbeat
 server2 ...: Online
  lankhb1 : Normal Kernel Mode LAN Heartbeat
<group>
 failover ........: Error
  current : server1
  azurepp : Online
  md : Online Failure
  md2 : Online Failure
<monitor>
 azurelbw1 : Normal
 azureppw1 : Normal
 mdnw1 : Normal
 mdnw2 : Normal
 mdw1 : Error
 mdw2 : Error
 userw : Normal
=====================================================================

  • 一旦フェールオーバーグループを停止します。
  •  フェールオーバーグループが起動しているサーバーで以下のコマンドを実行します。

  •  実行例
# clpgrp -t failover
Command succeeded.

  • その後、データを最新としたいサーバー側のミラーディスクの状態を正常にします。今回はserver1をデータを最新としたいサーバーとし、現用系サーバーとして業務を再開します。
  •  現用系サーバーで以下のコマンドを実行します。
  •   ※ミラーディスクリソースが複数ある場合は全てのミラーディスクリソースを正常にします。

  •  実行例
# clpmdctrl --force md
md: Forced recovery has completed successfully.
# clpmdctrl --force md2
md2: Forced recovery has completed successfully.

  • 現用系サーバーでフェールオーバーグループを起動します。
  •  現用系サーバーで以下のコマンドを実行します。

  •  実行例
# clpgrp -s failover
Command succeeded.

  • バックアップした時点のデータとなり、リストアが完了していることを確認します。
    この時点から業務を再開できます。

  • 最後に、ミラーディスクのデータを待機系サーバーにフルコピーします。
  •  現用系サーバーで以下のコマンドを実行します。
  •   ※ミラーディスクリソースが複数ある場合は全てのミラーディスクリソースでフルコピーします。

  •  実行例
# clpmdctrl --recovery md
<md>: recovery started
# clpmdctrl --recovery md2
<md2>: recovery started

  • フルコピーが完了したら、フルコピー先にフェールオーバーグループを移動させ、正常にデータにアクセスできることを確認します。

さいごに

今回は、Azure VM バックアップを利用して、Azure VMのシステムディスクと追加ディスク(ミラーディスク)をバックアップ・リストアする方法を試してみました。
Azure Backupの機能で、データのバックアップ・リストアが容易に行える点は魅力的です。

本記事の構成をご検討の際は、CLUSTERPROのpopup試用版を用いて検証した後、ご提案・構築ください。

お問い合わせ

当ブログに関するお問い合わせは、popupお問い合わせ窓口 までお問い合わせください。