HAクラスター環境におけるバックアップについて

共有ストレージ構成の場合
Pocket

今回は、HAクラスター環境におけるバックアップについて考えてみたいと思います。

以前Quest Software様にも語って頂きましたが、
「バックアップとHAクラスター」
はIT危機管理の基本であり、車の両輪のように、どちらもなくてはならないものです

また、
「バックアップとレプリケーション」
は競合するものではなく、目的に応じて使い分ける、または両方を活用する必要があります。たとえば、レプリケーションは常に最新の状態でデータを複製できますが、その一方で問題のあるデータ(ウィルスに感染したデータなど)も複製してしまいます。

このような場合に、データが正常だった最終時点に戻すには、バックアップが不可欠です。レプリケーションを行えば、システム障害のあった直前のイメージに即座にアクセスすることができる(=RTO/RTO面では優位)一方、データを世代別に蓄積したり、eDiscoveryのような世界に対応することはできません。

よって、サイオステクノロジーのLifeKeeperは、DataKeeperというレプリケーション機能と組み合わせて使うことのできるHAクラスター製品ですが、
– HAクラスターだからといって、バックアップが不要となるわけではありませんし
– レプリケーション機能があるからといってバックアップが不要になるわけではありません。

今回は、LifeKeeperを使ったHAクラスター環境におけるバックアップを行う際の注意点や留意事項について考えてみたいと思います。


考え方としては、バックアップの取得対象として以下の5つを想定しながら、それぞれのバックアップ手法と注意すべき点を挙げていきます。

  1. OS領域
  2. LifeKeeper/DataKeeperのプログラム(実行モジュール)
  3. LifeKeeper/DataKeeperの構成情報
  4. アプリケーションのプログラム(LifeKeeper/DataKeeper以外のプログラム。例:Oracle, PostgreSQLなど)
  5. アプリケーションのデータ

また、外部のバックアップサーバーからバックアップを行う際のHAクラスター環境ならではの留意事項についても触れてみます。

1.のOS領域のバックアップは、OSの標準ユーティリティやサードパーティーのバックアップソフトウェアで取得する方法が一般的ですが、こちらに関してはHA環境だからと言って特別の考慮点は無いと考えられるので、ここでは取り上げません。

2.のLifeKeeper/DataKeeperのプログラム(実行モジュール)もOS標準ユーティリティやサードパーティーのバックアップソフトウェアで取得可能ですが、敢えてバックアップはせずに、ディスク障害等でプログラムが消えてしまった場合には再インストールを行うという割り切りを考える方々もいらっしゃることでしょう。

3.のLifeKeeper/DataKeeperの構成情報のバックアップですが、こちらに関してはLifeKeeperにはlkbackupと呼ばれるコマンドが付属しています。

lkbackupは、LifeKeeperおよびリソースが起動した状態で実行でき、稼働中のサービスに影響を与えません。
lkbackupコマンドを実行するタイミングは、主に以下の3つの場合が考えられます。

  • LifeKeeperを新規インストールし、リソースの作成が完了した直後
  • LifeKeeperの構成を変更(依存関係の追加・変更、リソースの追加・削除)する前後
  • LifeKeeperのバージョンアップの前後

lkbackupで構成情報のバックアップを取得しておけば、ディスク障害で構成情報が消えてしまった場合や、オペレーションミスなどで構成情報が壊れてしまった場合にも、 特定時点(正常に動いていた時点)の状態に素早く戻すことができます。
lkbackpの詳細については、以下のユーザーサイトに解説がありますので参考にしてください。
[[Linux]クラスター構成のバックアップ/リストア方法を教えてください。]

4.の(LifeKeeper以外の)アプリケーションプログラムのバックアップですが、こちらも1.や2.と同様、OS標準のユーティリティやサードパーティーのバックアップソフトでのバックアップイメージ作成とリストアが可能ですが、この部分に関してもHAクラスター環境ならではの留意点は特に無いと考えられます。

5.のアプリケーションのデータのバックアップが本日の本題です。
HAクラスター環境では、稼働系と待機系サーバー双方から利用可能な「共有領域」が設けられ、平常時は稼働系から「共有領域」を使用し、稼働系のシステム障害発生後には待機系サーバーから同じ「共有領域」を利用することが可能です。

アプリケーションのデータ(例:データベースのデータ)は通常この共有領域に置かれますが、この共有領域のバックアップを行う際には、以下の点に留意する必要があります。

共有ストレージ構成の場合

稼働系と待機系の共有領域に配置されたデータのバックアップを取得する場合、共有領域にあるデータには稼働系からしかアクセスできない(待機系からはデータへのアクセスができない)ため、バックアップも稼働系から実行します。この場合、バックアップ中のシステムリソース(CPUなど)への負荷(オーバーヘッド)には充分注意する必要があります。

共有ストレージ構成の場合

データレプリケーション構成の場合

データレプリケーション構成の場合も、稼働系からのバックアップが基本となりますが、一時的にミラーリングを停止してロックを解除することにより、待機系側でもバックアップを実行できます。ただしこの場合、一時的にデータが同期されなくなります。

データレプリケーション構成の場合

外部のバックアップサーバーからクラスターノードのバックアップを実行する場合

外部のバックアップサーバーからクラスターノードのバックアップを実行するには、クラスターノードの仮想IPアドレスまたは実IPアドレスのいずれかを使用します。それぞれの場合の注意点は以下の通りです。

クラスターノードの仮想IPアドレスを使用してバックアップを実行する場合

 バックアップサーバーから見て、LifeKeeper Coreが持つ仮想IPアドレスが示すノードに対してバックアップを実行します。この場合、バックアップサーバーはどのノードが稼働系であるかを意識する必要はありません。

クラスターノードの仮想IPアドレスを使用してバックアップを実行する場合

クラスターノードの実IPアドレスを使用してバックアップを実行する場合

  •  バックアップサーバーから見て、LifeKeeper Coreが持つ仮想IPアドレスを使用せずに、実IPアドレスに対してバックアップを実行します。
  •  共有領域には待機系からはアクセスできないので、バックアップサーバーおよびクライアントは、どのノードが稼働系なのかを確認する必要があります。

クラスターノードの実IPアドレスを使用してバックアップを実行する場合
また、以下のサイトで公開しているホワイトペーパーでは、クエスト・ソフトウェアのNetVault Backup 11を使ってHAクラスター化されたOracleおよびMySQLのアプリケーションデータのバックアップ/リストアに関して解説しております。

http://sios.jp/products/lkdk/product/s_nv.html
NetVault Backup以外のバックアップソフトウェアを使用する場合は、利用者側で事前に十分な動作検証を実施してください。

冒頭でも述べた通り、障害発生時などにデータが正常だった最終時点に戻すには、バックアップが不可欠なのです。
今後はクラウド環境におけるHA環境のバックアップ/リストアについても考えてみたいと思います。

共有ストレージ不要!
"SANLess Clusters"についてもっと詳しく

sanless-clusters banner


"SANLess Clusters"ソリューションを見る

SNSでもご購読できます。