クラスタのバックアップは基本的にWindows標準のバックアップ機能(NTBackup)で取得可能だ。MSCS環境でバックアップを取得するデータは、大きく分けると4種類存在し、それぞれバックアップの取得方法が異なっている。
対象データ | NTBackupのオプション | |||
ASR | Systemstate (システム状態のみのバックアップを作成する) |
なし (このコンピュータにある情報すべて) |
||
クラスタのディスク署名とパーティション | ○ | |||
クラスタ・クォーラム上のデータ | ○ | |||
共有ディスク上のデータ | ○ | |||
クラスタ・ノードのローカル・データ | ○ | |||
MSCS環境におけるバックアップの対象データ |
●クラスタのディスク署名とパーティション
クラスタのディスク署名とパーティションのレイアウトはMSCSで非常に重要な情報となる。MSCSではディスク署名を管理している。ディスク署名は各ディスクの最初のセクタに書き込まれている。MSCSでは、このディスク署名情報を管理し、認識するディスクの識別を行っている。そのため、ディスクを交換してドライブ・レターを同じものに変更してもMSCS上では認識できない仕組みとなっている。
また、クラスタ構成情報ではディスクのドライブ・レターやパーティション情報が異なると機能しなくなるため重要な情報となる。これらは、Windows標準のASR(自動システム回復)でバックアップが可能だ。詳細な手順は次の情報を参照するとよいだろう。
●クラスタ・クォーラム上のデータ
クォーラムの情報には、第2回で説明したようにクォーラム・ログ、チェックポイント・ファイル、クラスタ・データベースなどが保持されているため、最も重要といえる。これらの情報はアプリケーション・データほどではないが、比較的頻繁に変更されることがあるため、定期的にバックアップを取得する必要がある。バックアップはNTBackupにてSystemstateオプションを使用して取得する必要がある。取得の手順は次の情報を参照してほしい。
●共有ディスク上のデータ
共有ディスク上に保存しているアプリケーション・データについては、各アプリケーションに適したバックアップ手法を用いる必要がある。ファイル共有などではファイルのコピーやNTBackupなどで取得すればよいと思われるが、SQL Serverのように、単純なファイル・コピーでは適切なバックアップが取得できないアプリケーションにおいては、固有のバックアップ手法を用いる必要がある。しかしながら、MSCSだからといって特別意識する必要はなく、そのアプリケーションでのバックアップのノウハウをそのまま適用できるので難しくはないはずだ。
●クラスタ・ノードのローカル・データ
クラスタの各ノードのローカル・データについてもバックアップが必要となる。ノードのバックアップも通常のWindowsをバックアップする手法を用いることができる。
●ASRバックアップの注意点
ASRでのバックアップで注意する点として、可能な限り停止できるアプリケーションは停止しておくことが望ましい。特にSQL Serverを構成している場合は、SQL Serverが稼働していないノードでASRによるバックアップを実行することが推奨されている。一方、クラスタ・サービスは起動状態である必要がある。
●NTBackupの挙動
NTBackupでは、MSCSのバックアップを行う際に、内部的にはMSCSで準備されているAPIを利用してバックアップが行われる。これによりサードベンダ製のバックアップ・ソフトウェアでもMSCSのバックアップを行えるように作成できる。
API名 | 説明 |
---|---|
Backup Cluster Database | クラスタ構成データベースをバックアップするAPI。クラスタの内部コンポーネントであるフェイルオーバー・マネージャに接続してバックアップの取得を行う |
Restore Cluster Database | バックアップからクラスタ構成データベースを復元するAPI。クラスタ・サービスを自動的に停止/開始の制御も行ってくれる |
クラスタのバックアップで用いられるAPI |
クラスタの障害パターンはさまざまであり、ハードウェア/ソフトウェアが親密な関係にある。以下のマイクロソフトのサイトでは、それぞれのバックアップ・リストアのシナリオ・パターンを複数用いて説明しているので参考にしてほしい。
これまでの説明で、何度かクラスタ・サービス・コンポーネントの名称を挙げたが、ここで簡単ではあるが概要を紹介する。クラスタ・サービスは複数のクラスタ・サービス・コンポーネントで形成されている。それぞれのコンポーネントは独自の役割を持っており、それぞれが協調しあってサービスが成り立っている。通常の運用ではこれらのコンポーネントを意識する必要はないが、トラブルシューティングなどにおいてクラスタ・ログを解析する際、各コンポーネントの概要を把握していると解析作業が楽になるだろう。なお、クラスタ・ログではこれらのコンポーネントの略称が利用されている。
コンポーネント | 略称 | 概要 |
---|---|---|
Event Log Replication Manager | ELM | クラスタを構成しているすべてのノード間のイベント・ログの複製を行う |
Node Manager | NM | クォーラム、ノードのJOINプロセス、障害通知、ノードとネットワークの管理をコントロールする |
Membership Manager | MM | クラスタを構成するノードの特定や、ノードの参加/削除/障害によるクラスタ構成の変更の際に、動的なクラスタ・メンバのハンドリングを行う |
Global Update Manager | GUM | クラスタのステータスの整合性を保つために、変更が行われたときに何らかの障害が発生したとしても、すべての処理が完了、または実行前のいずれかの状態で終わるようにコントロールする |
Backup Restore Manager | BRM | Failover ManagerやDatabase Managerと連動し、クォーラム・ログやすべてのチェックポイント・ファイルをバックアップまたは復元する |
Database Manager | DM | クラスタ構成データベースを構成、管理する |
Checkpoint Manager | CM | クォーラム・リソース上のクラスタ情報を現在参加しているノードへ書き込むタイミングを制御する |
Log Manager | LM | クォーラム・リソース上のクォーラム・ログに変更を書き込む |
Failover Manager | FM | リソースのスタートアップ/リスタート/フェイルオーバーをコントロールする |
クラスタ・サービス・コンポーネント クラスタ・サービスは、さまざまなコンポーネントが連携して形成されている。なお、上記は主要なコンポーネントのみであり、実際は多数のコンポーネントが協調して動作している。 |
Copyright© Digital Advantage Corp. All Rights Reserved.