DAGはクラスターアプリ?

■DAGはクラスターアプリケーションではない
クラスター上のExchangeですが、Cluster ResコマンドでExchangeリソースが表示されなくなりました。これは、表示抑制ではなく、Exchange 2010以降では「無くなった」ということです。
下記①と②の記事を見つけました。


Exchange によって提供された ExRes.dll という名前のクラスター リソース DLL を使用する、以前のバージョンの Exchange クラスターとは異なり、Exchange 2010 はクラスター リソース DLL を必要としたり、使用したりすることはなくなりました。Exchange 2010 はクラスター化アプリケーションではありません。フェールオーバー クラスター コンポーネントの一部だけ、つまり、ハートビート機能とクラスター データベースを使用してデータベース モビリティを提供します。
http://technet.microsoft.com/ja-jp/library/dd335211(v=exchg.141).aspx


以前のバージョンの Exchange Server は、クラスター アプリケーションとして機能していました。このときには、メールボックス サーバーの高可用性を実装する場合、まず Windows フェールオーバー クラスターを作成し、次に Exchange セットアップをクラスター化されたモードで実行しました。セットアップ プロセスの一環として Exchange クラスター リソース DLL (exres.dll) が登録され、クラスター化メールボックス サーバーを作成できるようになりました。
これに対し、Exchange Server 2010 は、クラスター アプリケーションとして機能しないので、可用性を高めるためにクラスターのリソース管理機能は使用されなくなりました。Exchange クラスター リソース DLL と、この DLL で提供されるすべてのクラスター リソースは存在しなくなりました。Exchange Server 2010 では、内部に用意された独自の高可用性モデルが使用されます。このモデルでも Windows フェールオーバー クラスタリングの一部のコンポーネントは使用されていますが、Exchange Server 2010 で完全に管理されています。
http://technet.microsoft.com/ja-jp/magazine/ee835711.aspx

これをちょっとわかりやすく言うと・・・。
クラスターでは、クラスター上で動いているアプリのステータスを細かくチェックしていて、異常を検知するとそのアプリを設定された回数分ノード上で再起動させ、それでもダメならフェールオーバーさせる・・・ということをやっています。
クラスター内部の仕組みはこんな感じです。

リソースコントロールマネージャ・・・ノード上で再起動かフェールオーバーか判断
↓ ↑
リソースホストサブシステム・・・ステータスの監視役
↓ ↑
リソースDLL・・・そのアプリにとってふさわしいステータスチェックのコードを実装。
↓ ↑ リソースホストサブシステムからの問い合わせに応じて簡単チェック/
↓ ↑ 詳細チェックを実行してステータスを報告。
リソース(アプリ)・・・クラスタ対応アプリ

クラスターがリソースを制御する上で重要なのが、リソースDLL(Exchangeの場合、exres.dll)です。これがあるから、クラスターはそのアプリのステータスを的確に把握して、再起動やフェールオーバーの制御につなげることができるわけです。
でも、Exchange Server 2010以降では無くなった・・・つまり、Exchangeはクラスター上で動くクラスタ対応アプリではなくなったという意味です。そして、クラスターが提供していた、的確なステータスチェック、ステータス監視、アプリの再起動やフェールオーバーの判断などの機能はExchange Serverに内部実装されたということです。それが上記の「内部に用意された独自の高可用性モデルが使用されます」との記述です。
しかしそれでも、フェールオーバークラスターは活用しています。
どの部分を活用しているかというと
・ノード間のハートビート制御
・クォーラムの機能
ということです。
いままでクラスター側で担当していた、もろもろの機能がExchange側に移されたような感じです。

スポンサーリンク
レクタングル(大)広告
レクタングル(大)広告
  • このエントリーをはてなブックマークに追加

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です


*