第2回 仮想化ソフトウェアを使ってMSCSを構築するWindowsクラスタリング入門(2/7 ページ)

» 2009年01月29日 00時00分 公開
[高橋郷]

MSCSの機能詳細

 サーバ・クラスタの機能については第1回のサーバ・クラスタの用語説明において触れたが、ここではもう少し詳しく解説する。

クラスタ・サービス
 クラスタ・サービスはMSCSの中核となるサービスである。実体はClussvc.exeという実行ファイルだ。クラスタ・サービスはさまざまな役割を持っているが、主な役割として下記のようなものがある。

  • クラスタ構成(クラスタ・データベース)の管理
  • ほかのクラスタ構成ノードとの協調
  • イベント通知処理
  • フェイルオーバー制御

 クラスタ・サービスは内部的には複数のコンポーネントで構成されている。例えば、フェイルオーバー処理を制御するFailover Managerや、イベント・ログの記録を行うEvent Log Replication Managerなどだ。これらのコンポーネントの理解は障害時などのログ解析などに役立つ。詳細は次回説明する。

クラスタ・データベース
 クラスタの各種構成はクラスタ・データベースと呼ばれるデータベースで構成される。クラスタ・データベースでは、クラスタのノード構成情報をはじめ、すべての構成が管理されている。

 クラスタ・データベースはレジストリとして管理され、実体は「CLUSDB」というファイルだ。なお、クラスタ・データベースの構成はMSCSの管理ツールであるクラスタ・アドミニストレータのツリーに近い構造となっているため、比較的読みやすい。

レジストリ HKLM\Cluster
ファイル %Systemroot%\Cluster\CLUSDB

クォーラム・リソース
 クォーラム・リソースは、チェックポイント・ファイル、クォーラム・ログの保持などを行う場所である。また、クラスタ構成時の調停処理に利用される。なお、クォーラム・リソースを持つ共有ディスクをクォーラム・ディスクと呼ぶ。

 チェックポイント・ファイルは、世代管理された(履歴管理された)クラスタ・データベースだ。クラスタはフェイルオーバーすることで、クラスタ全体を管理するノードが切り替わる。ノードが切り替わった際のクラスタ再構成時に、このチェックポイント・ファイルを使用してクラスタ・データベースを最新の構成情報に復元する。チェックポイント・ファイルの物理ファイルは、「%QuorumDisk%\MSCS\chk*****.tmp」だ。ファイル名の * には世代番号が入り、レジストリにて最新の世代番号が管理されている。チェックポイント・ファイルのCLUSDBファイルと同じものだ。チェックポイント・ファイルは次のタイミングでローカルからクォーラムへコピーされて最新化される。

  • クラスタを形成したとき
  • ノードがダウンしたとき
  • クォーラム・ログのサイズが制限まで達したとき(デフォルトは64Kbytes)
  • 定期的なチェックポイント(デフォルトは4時間)

 クォーラム・ログは、最新のチェックポイント・ファイル以降の更新履歴を保持するログ・ファイルだ。SQL Serverなどのデータベースで利用されるトランザクション・ログと同様の位置付けと思ってもらえればイメージしやすいだろう。クォーラム・ログの物理ファイルは「%QuorumDisk%\MSCS\quolog.log」ファイルで、標準で64Kbytesが最大サイズとなっている。この設定はクラスタの管理ツールであるクラスタ・アドミニストレータで変更可能だ。

 クォーラム・リソースは、チェックポイント・ファイルやクォーラム・ログのような物理情報のほかに、クラスタ構成の調停作業に用いられ、「スプリット・ブレイン・シンドローム」の回避を行っている。スプリット・ブレイン・シンドロームとは、例えばクラスタ起動時や障害発生時にノード間での通信が切断されている場合、それぞれのノード自身が稼働系のノードとして認識してしまい、それぞれのノードでクラスタを構成し始め分裂状態に陥ることだ。MSCSではこの分裂状態を避けるために、クォーラム・リソースを所有できるかどうかで稼働系ノードを制御する。つまりクォーラム・リソースを保持しているノードだけがクラスタ・サービスを形成できる。

クォーラム・リソースの種類
 クォーラム・リソースには次の3つの種類がある。

種類 内容
スタンダード・クォーラム スタンダード・クォーラムは通常のクォーラム構成で、各ノードからアクセス可能な共有ディスクにクォーラムを配置する。クォーラム・リソースは共有ディスク上で1つだけ管理される
ローカル・クォーラム ローカル・クォーラムはノードのローカル・ディスクにクォーラムを保持する構成で、ほかのノードとはクォーラム・リソースを共有しないシングル・ノードのクラスタだ。障害時にフェイルオーバーすることもない。基本的には開発環境やクラスタ上で動作するアプリケーションなどの検証環境を目的として構成する
マジョリティ・ノード・セット・クォーラム マジョリティ・ノード・セット・クォーラムは、Windows Server 2003から追加されたクォーラム・リソースの構成だ。通常のクォーラム・リソースは共有ディスクに配置し、各クラスタ・ノードは単一のデータを参照するのに対し、マジョリティ・ノード・セット・クォーラムは共有ディスクを持たず、各ノードでクォーラム・リソースを管理し、ノード間で同期を取りながらクラスタを構成する。主に、遠隔地における物理的に離れたノード間でクラスタを構成するMirrored Disksクラスタ・モデルで利用される。構成するには、ノード間の通信が500msec以内で行える必要がある。さらに、「(クラスタの構成メンバー数/2)+1」以上の稼働ノードが必要となる。例えば、2台構成の場合は(2/2)+1で2台稼働、同様に3台構成の場合2台稼働、5台構成の場合3台稼働が必要となる

リソース
 リソースとはクラスタ・サービスによって管理される物理的あるいは論理的な要素だ。物理的要素の例としてはディスク、論理的要素の例としては、IPアドレス、仮想サーバ、アプリケーション(サービス)などが挙げられる。リソースはそれぞれが何らかの機能(役割)を持っていて、リソース・モニタとリソースDLLによって管理/形成される。

  • リソース・モニタ
     リソース・モニタは、リソースDLLを介してリソースの状態を監視するプロセスだ。リソース・モニタは、複数のリソース共通で1つ用意することも、リソースごとに用意することも可能だ。MSCSの標準ではリソース・モニタは1つのみである。ただし、サードパーティ製のアプリケーションなどは個別のリソース・モニタを推奨する場合が多い。リソース・モニタを分離すると、ほかのリソース・モニタに対するパフォーマンスや挙動の影響が少ないものの、プロセスが増えるため、あまり分離するとサーバ全体のパフォーマンスに影響する。
  • リソースDLL
     リソースDLLは、リソース・モニタとリソースの間で、リソースの種類ごとに適切なリソースの管理や操作などを行う。特に重要な役割として、障害の検知を行うこと、リソースの依存関係を定義することがある。クラスタ・サービスでは「Looks Alive」と「IsAlive」の2つの監視手法を用いる。具体的な監視内容はリソースごとに異なっており、その定義をしているのがリソースDLLだ。例えば、SQL ServerのLooks Aliveではサービスが起動しているかどうかのみを確認し、IsAliveでは「select @@servername」クエリを実行して応答するかを確認するように定義されている。そのほか、共有ディスクの接続制御などのデバイス接続に関する定義や、フェイルオーバー時の再開ポリシーや処理方法の定義を行っている。
リソースの種類
[クラスタ アドミニストレーター]の[クラスタの構成]−[リソースの種類]を見ると、定義されているリソースDLLを見ることができる。

グループ
 グループはファイル・システムでいうところのフォルダのようなもので、リソースの入れ物のようなものだ。グループはフェイルオーバーの単位でもあり、提供するサービスや、アプリケーションの単位ともいえる。依存関係の有効範囲などの境界線でもある。

依存関係
 依存関係は、必要とするリソースと必要とされるリソースの関係であり、ほかのリソースを開始するにはどのリソースを開始して利用しなければならないかを示す。Windowsのサービスの依存関係と同様だ。例えば、ネットワーク名リソースは、IPアドレス・リソースに依存しているため、IPアドレス・リソースがオンラインにならない限り、ネットワーク名リソースもオンラインになれない。つまりIPアドレスが存在しないのに、名前だけが存在することはできないわけだ。

 Windows 2000 ServerのMSCSではリソース依存関係をある程度自分で定義する必要があったが、Windows Server 2003のMSCSからは適切なリソース依存関係が形成されていない場合は、何が足らないかを警告するようになっている。

 そのほか、依存関係は以下のルールが成り立つ。

  • リソースはリソースに依存する
  • 依存しているリソースがオンラインにならないと、オンラインになれない
  • 依存しているリソースがオフラインになると、依存されているリソースもオフラインになる
  • ほかのグループにまたがって依存関係は結べず、グループ内で設定される
  • 単一方向の依存関係しか結べない

 なお、依存関係をツリー構造で示したものを「Dependency Tree」という。

Dependency Tree
ファイル共有リソースにはネットワーク名リソースとディスク・リソースが必要。ネットワーク名リソースにはIPアドレス・リソースが必要といった依存関係を記述する。

フェイルオーバー
 フェイルオーバーについては、第1回で障害発生時などに別のノードにサービスを切り替えることとして説明してきた。実際には一言で語れる単純な動作ではなく、フェイルオーバー時に行われる挙動にはいくつか理解するべきことがある。

 まず、フェイルオーバーにはプッシュ型とプル型がある。プッシュ型は計画停止による手動フェイルオーバー、プル型は障害時による突発的なフェイルオーバーだ。プッシュ型でもプル型でもフェイルオーバーのアルゴリズムは変わらないが、突発的なフェイルオーバーは予定されていた処理が行えない可能性があるため、メモリ情報が破棄されデータを損なう可能性が、手動による計画停止に比べて高い。

 次にMSCSではフェイルオーバーを実行する前に、リソースの再起動処理が設定可能だ。リソースが障害を起こした際には、いきなりフェイルオーバーを行うのではなく、定義された時間内に指定回数、同じノードでリソースを再起動して復旧できるか試みる。それでも復旧しない場合にのみ、フェイルオーバーが行われる。

 そのほか、当然だが以下のような挙動をすることを理解する必要がある。

  • メモリ情報は基本的にクリアされて引き継がれない
  • リソースDLLで定義されていないレジストリ情報は失われる
  • コミットされていないディスク情報は失われる
  • クライアントとの接続は切断される

フェイルバック
 フェイルバックとは、障害を起こしてフェイルオーバーしたリソースが、ノード復旧後に、元のノードにリソースを戻す処理のことだ。基本的には、決められたノードでサービスを提供したい場合にフェイルバックの設定を行う。

 フェイルバックを行うということは、再度フェイルオーバーを行うことと同じだ。そのため、ノードが復旧したからといって即時にフェイルオーバーされると、利用者にサービスを提供できない状態が数分間発生することになる。フェイルバックは時間帯の指定ができるので、夜間に実施するようスケジュールするか、24時間稼働のシステムの場合、フェイルバックの機能を用いずに計画的なフェイルオーバーを実施するのが好ましい。

Copyright© Digital Advantage Corp. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

AI for エンジニアリング
「サプライチェーン攻撃」対策
1P情シスのための脆弱性管理/対策の現実解
OSSのサプライチェーン管理、取るべきアクションとは
Microsoft & Windows最前線2024
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。