「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- ステートレス・システム（複数インスタンス）の負荷分散が可能。
- ステートフル・システムのフェイル・オーバーも可能になっている。
- インスタンス間の状態共有はできないので、
- １インスタンスのActive-Passive構成（フェイル・オーバー）。
- ｎインスタンスのActive-Active構成（負荷分散）。
が可能。
クラスタとは、 †
- ネットワーク的には単一のサーバとして見える複数のサーバであり、
- SAN上の「共有ディスク（クォーラム・ボリューム）」に接続されていて、
- ステータス情報をネットワーク経由で常時共有している。
- クラスタ・サービスのポイントには、
- 複数のシステムでディスクを共有する。
- 複数のシステムに仮想的な単一の名前とアドレス（IPアドレス）を付ける。
- クライアントからこの仮想的な名前またはアドレス（IPアドレス）でアクセスする。
などの点が上げられる。
クラスタ アプリケーション †
アクティブ - パッシブ †
- アプリケーションの観点からすると、各アプリケーションはクラスタ内の2つ以上のサーバにインストールされている。
- しかし、アプリケーションの1つのインスタンスだけが「アクティブ」サーバで稼働しており、これが「共有ディスク（データ・ボリューム）」に独占的にアクセスしてすべてのクライアント・リクエストにサービスを提供する。
- 他のサーバはアプリケーションのそのインスタンスに関して「パッシブ」であり、従ってクラスタは本質的には「負荷分散・拡張性」を提供しない。
アクティブ - アクティブ †
- しかし、クラスタ内の他のサーバは、同じアプリケーションの他のインスタンスや、別のアプリケーションに関しては「アクティブ」で、各「アクティブ・ノード」は別のディスクに独占的にアクセスできる構成もある。
- この構成はしばしば「アクティブ－アクティブ」と呼ばれるが、「共有ディスク（データ・ボリューム）」に接続する2台以上のサーバが「負荷分散・拡張性」を提供することはない。
構成 †
- 共有ディスクが必要になる。
- ｎ物理ノード＋１，ｎインスタンスの複雑な構成も取れる。
共有ディスク †
- 3つの「物理サーバ」はいずれも、総合的なクラスタ構成と状態情報を格納する「共有ディスク（クォーラム・ボリューム）」にアクセスできる。
- フェイル・オーバー（フェイル・バック）発生時に、MSCSは「共有ディスク（クォーラム・ボリューム）」を用いて、どの「物理サーバ」をアクティブにして「共有ディスク（データ・ボリューム）」に独占的にアクセスさせるかを決定する。
- 「アクティブ・ノード」に障害が発生した場合、「パッシブ・ノード」が自動的に引き継いで新しい「アクティブ・ノード」となり、「共有ディスク（データ・ボリューム）」にアクセス可能になる。
- 例
- 「仮想サーバA」＝（「物理サーバ1」 ＋ 「物理サーバ2」）
で、フェイル・オーバーが発生しない限り、
「共有ディスク（データ・ボリューム）」にアクセスできるのは「物理サーバ1」だけである。
- 「仮想サーバB」＝（「物理サーバ2」 ＋ 「物理サーバ3」）
でも、フェイル・オーバーが発生しない限り、
「共有ディスク（データ・ボリューム）」にアクセスできるのは「物理サーバ3」だけである。
フェイル・オーバー時の動作 †
- 「物理サーバ１」「物理サーバ２」は「仮想サーバA」をホストし、「物理サーバ２」「物理サーバ３」は「仮想サーバB」をホストする。各「仮想サーバ」は1つ以上のサービスをクライアントに提供する。
- 「物理サーバ1、2、3」はそれぞれネットワークで接続されており、これによってほかのサーバの状態を監視できる。この例では「物理サーバ２」は「パッシブ」な役割に徹しており、「アクティブ」な「物理サーバ１」「物理サーバ３」を引き継ぐことができる。
- 3つの「物理サーバ」はすべてSANアダプタを備えており、SANストレージ・アレイに接続されている。各「物理サーバ」は、ローカル・ディスクを装備せず、代わりにSAN上の自身の専用ボリュームからブートすることもできる（Windows Server 2003のこの機能はSANベンダ側のサポートが必要）。
MSCSフェイル・オーバー処理の弱点 †
MSCS方式には、次の弱点がある。
- 「アクティブ・ノード」のCPUレジスタとメモリの内容は「パッシブ・ノード」に連続的にミラーリングされないため、アプリケーションやサービスは「パッシブ・ノード」上で起動する必要があり、ディスクに書き込まれた最後のトランザクションについてのみ最新の状態となる。
- クライアントから見るとフェイル・オーバーは、一時的なネットワーク切断に見え、アプリケーションに再度接続し直す必要がある。
- 「アクティブ・ノード」と「パッシブ・ノード」が「共有ディスク（データ・ボリューム、クォーラム・ボリューム）」を共有するので、完全に冗長ではない。しかしこの弱点は、RAIDアレイに格納し、冗長なストレージ・コントローラとネットワーク接続を使用することで解決できる。
クラスタ対応アプリケーション †
- MSCSでは、新しい「ジェネリック・スクリプト（generic script）」クラスタ・リソース・タイプにより、開発者はスクリプティング（Microsoft VBScriptやJScript）を用いて、いくつかの既存アプリケーションをクラスタ対応にすることができる。その際、CやC++で特殊なアプリケーション・リソースDLLを書く必要はない。
- 「アクティブ・ノード」のOSやハードウェアの障害が「パッシブ・ノード」へのフェイル・オーバーを引き起こすのと同様に、「クラスタ対応アプリケーション」の障害もフェイル・オーバーを引き起こすことができる。
- クラスタ方式は、複製上の記録が同期しなくなることが許されないトランザクショナル・データベースに理想的である。Microsoft SQL ServerとExchangeの各Enterpriseバージョンは「クラスタ対応アプリケーション」として設計されている。
その他 †
- MSCSはサーバ・ファームよりも高価でSANを必要とするが、業界標準のサーバを使用するため、ハードウェアにかかる費用が安価である。
- MicrosoftはMicrosoftハードウェア互換性リスト（HCL）に掲載された完全なクラスタ・ソリューションだけをサポートする。このため、顧客はクラスタをデバイス・レベルのコンポーネントから自由に構築してサポート対象の構成に組み立てることはできない。
- MSCSでは、クラスタを構成する各ノードに対し、順次OSのアップグレードができる。これを「ローリング・アップグレード」という。１つのノードがアップグレード中であっても、別のアップグレード中でないノードを使用してサービスを使用できるため、「可用性」が向上している。
参考情報 †
変更点 †
なんとなく、
フェイル・オーバー性能最優勢ではなく、クラウド環境でも動作するように、
仕組みが分散システムのような感じになってきている様に見える。
2003→2008 †
MSCSという名称が、WSFCに変更された以外は大きな変更点は見当たらない。
ただし、以下の変更点がある。
ハートビート用NIC †
- ハートビート用NICが必須で無くなっている。
＃ハートビート用NICであることを明示することは出来なくなっているが、
＃ハートビート用NIC別に準備することが推奨であることは変わらない模様。
- サービス用（外部）
クライアントにこのネットワーク経由の接続を許可する
- クラスタ内用（内部）
クライアントにこのネットワーク経由の接続を許可しない。
これによりハートビートで使用され易くなる。
ただし、何を優先するか等の情報は公開されていない
- 「既定のクラスタ・グループ」がなくなって、記憶域、ネットワークなどに分散されている。
管理ツール類 †
- サーバーマネージャ、クラスタアドミニストレータ
2000, 2003 の頃は、NIC の所に手動でクラスタ用のIPを設定できたが、
2008から、サーバーマネージャ、クラスタアドミニストレータ使う方法へ変わっている。
（直接設定変更できなくなったのか、非推奨なのかは未確認）
→2008R2 †
大きな変更点に、Cluster Shared Volumes (CSV)の導入がある。
Cluster Shared Volumes (CSV) †
CSVはHyper-Vの
をサポートする機能として実装された。
- 今までのクラスタの共有ディスクは、どちらか片方のノードからしかアクセスできなかった。
- Hyper-Vのホスト・クラスタ、ライブ・マイグレーションで柔軟な運用を実現するには、
クラスタ・リソースであるLUN（Logical Unit Number：論理ユニット番号）を
VM毎に作成する必要があった。しかし、まだ以下の課題があった。
- 1LUNに1つ以上のVHD（仮想マシン）を格納する方式では、
2インスタンスActive-Activeの負荷を均等化できない。
- 1LUNに1つのVHD（仮想マシン）を格納する方式では、
ドライブ文字が足りなくなってしまう。
- この課題をクリアするために、CSVで両ノードからVMへのアクセスを可能とした。
- これにより、ホスト・クラスタ、ライブ・マイグレーションで、
VM置き場を複数のホストから共有でき、LUNを大量に作成する必要が無くなった。
- NTFSファイル・システムはLUN所有者側が持つ。
- ファイル作成や削除などのNTFSファイル・システム操作はLUN所有者側から行う。
VM所有者側から、これらの操作をする場合は、LUN所有者に処理を依頼する。
- VM所有者がVMにアクセスする場合、LUN所有者にファイルの場所を教えてもらい、
以降、直接ストレージにアクセスする。これにより両ノードからのアクセスが実現される。
- また、VM所有者がCSVにアクセスできなくなった場合、
ネットワーク → LUN所有者経由でCSVにアクセスする冗長化機能も持っている。
- Windows Server 2008 R2 で導入されたクラスタの共有ボリューム (CSV) は、
クラスタ内の複数のノードが同じ NTFS ファイル システムに同時にアクセスできる
分散ファイル アクセス ソリューションです。
- 例えば、複数のクラスタ・ノードに分散された仮想マシンが、
記憶域内の同じディスク上の仮想ハード ディスク（VHD）に同時にアクセスできます。
- また、クラスタ化された仮想マシンは、それぞれ独立してフェイル・オーバできます。
補足 †
上記、クラスタの共有ボリューム（technet）
の記述は、技術的に正確な表現では無いようです。
以下、正確性を増した表現です。
- CSV にあるファイルは、同時「ファイル・アクセス」可能な訳ではなく、
ファイル毎に物理ノードから、直接「ブロック・アクセス」できる。
- CSVのボリュームを管理する物理ノード
(従来の共有リソースの所有者ノードと同じ役目)
は、依然として存在してまいす。
- 所有者ノードが、NTFSのファイル・システムとしての整合性を保つ。
(所有者ノードがダウンすると、別の物理ノードが所有者ノードの役目を引き継ぐ)
- 非所有者ノードは、
- 所有者ノードに「ファイル・アクセス」(作成やサイズ拡張)を代行してもらい、
- 以降、ボリューム上のブロック位置を特定して、直接「ブロック・アクセス」します。
- CSV上にある同じファイルへのアクセスはできない。
- CSV上にある一般ファイルやVHDファイルを、
非所有者ノードのエクスプローラから参照可能であるが、
- 操作できない、
- あるいは遅い。
- バックアップ、リストアできない。
cluster.exe †
- cluster.exe コマンドそのものは、2008R2 まで存在する。
- ただし、/maklogsize オプションが確認できない。
移行ツール †
→2012 †
強化・追加された機能 †
AD-less Cluter Bootstrapping †
自ホストのVM上のDCを使用できる（起動時にDCが必須でないオプション）。
cluster.exe †
既定でインストールされない、Powershellへの移行が推奨
→2012R2 †
Workgroup Cluster †
読んでみると、Workgroup Clusterは、Always Onでも利用されている模様。
参考 †
Tags: :Windows, :冗長化
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
BlockDiagramOfMSCS.png