-
Notifications
You must be signed in to change notification settings - Fork 0
MS_NLBvsMSCSWSFC
- 戻る（冗長化アーキテクチャ）
IISと
- ファイル・サーバ（以下 FS）
- プリンタ・サーバ（以下 PS）
- SQL Server
- JP1
を筐体の数を抑えるため、
これらを 1 つの筐体に詰めてクラスタ化したい場合にこの要件が上がる。
できません（実現不可能）。
クラスタ サービスとネットワーク負荷分散の両方をインストールした
コンピュータをサポートする必要がある場合、
いずれか一方のコンポーネントを削除する必要があります。
- クラスタ サービスを実行する必要があるコンピュータ
→［ネットワークとダイヤルアップ接続］ツールから NLB を削除します。 - NLB を実行する必要があるコンピュータ
→ クラスタ サービスを削除します。
補足（なぜ同居できないのか）: 両者が同じレイヤで
ネットワーク スタックに介入するためである。
NLB WSFC 仕組み 全ノードが同一 MAC を名乗り、フィルタで振り分ける 1 ノードだけが仮想 IP を持つ（ARP で所有を主張） ハートビート 独自 クラスタ ネットワーク 「全員が同じ IP/MAC を持つ」（NLB） と
「1 人だけが IP を持つ」（WSFC） は、
ARP のレベルで矛盾する。
両方を有効にすると、どちらが応答すべきか決まらない。現在もこの制約は変わっていない
（Microsoft は同一ホストでの併用をサポートしない）。
筐体数を減らしたい場合は、仮想化（Hyper-V）で
ゲスト OS を分けるのが現実的な解になる。
NLB と MSCS/WSFC の同居のような、
高い可用性とスケーラビリティを実現するために、L7 負荷分散を実現する
Application Request Routing (ARR)という
モジュールが IIS 7.0 から導入されているようです。
補足（ARR と現在の選択肢）: ARR は IISを
リバース プロキシ / L7 ロードバランサとして使うためのモジュールで、
- URL パス・ホスト ヘッダーによる振り分け
- ヘルス チェック（NLBに無い機能）
- SSL 終端
ができる。NLBの弱点（L4 のみ・アプリ監視なし）を補える。
ただし現在は、同じ目的に対して次の選択肢の方が一般的である。
選択肢 位置づけ Nginx / HAProxy オンプレの定番。軽量・実績豊富 Azure Application Gateway マネージド L7 LB（WAF 付き） Azure Front Door グローバル分散 + CDN ARR 既存の IIS 資産を活かす場合
ステートレスな IISは、一般的には NLBクラスタを
選択するべきです。
Web アプリケーションがセッション・ステートフルである場合も、
Session 状態を
- State Service Mode
- SQL Server Mode
- Custom Session Provider
に退避するようにする事で、NLBクラスタに対応させることができます。
ただし、NLB と MSCS/WSFC の同居ができないので、
IISを負荷分散クラスタ化せず、フェイル・オーバー・クラスタ化する場合に
限って、KB970759 のスクリプトを使用して MSCS/WSFC クラスタ化します。
Windows Server 2008 R2 からはスクリプトが標準で付属しないようなので、
KB970759 にあるスクリプトの内容を理解して、
必要に応じて書き替えて構成・検証するしかなさそうです。
- スクリプトの内容を確認すると「既定の Web サイト」のみの対応なので、
Active-Active 構成に対応させようとした場合、スクリプトの手修正が必要になる。 - サポートはされるが、スクリプト側は自己責任になる。
以下の様な不具合が報告されています。
KB970759 の情報を元に、IIS をクラスタのリソースとして登録しました。
セットアップは問題なく完了し、動作も良好でした。しかし、後から IIS の
仮想ディレクトリを作成したところ、作成は問題なく行えるのですが、
クライアントからアクセスすると「サーバーエラー 404 ファイルまたは
ディレクトリが見つかりません」となってしまう場合があります。
補足（この節の結論）: 3 つの問題点が示すとおり、
IISの WSFC クラスタ化は避けるべきである。
- Microsoft も推奨していない（KB のスクリプトは参考実装）
- スクリプトの保守が自己責任になる
- トラブル時の切り分けが難しい
IISは本来ステートレスなので、
セッションを外部化して NLB（または L7 LB）で負荷分散するのが
素直な設計である。
現在なら、セッションは Redis に置き、
前段は Nginx / Application Gateway、
という構成が標準になる（NLBの補足も参照）。
- IIS の設定情報はクラスタ・ノード間で共有されるか？
- IIS6：メタベース（
MetaBase.xml） - IIS7：
applicationHost.config
- IIS6：メタベース（
- メタベースを共有ディスクに入れる必要があるか？
KB970759 の手順に共有構成をエクスポートして共有ディスクに入れる手順があるが、
JIT コンパイルで生成されるアセンブリなどが、
何処にどう格納されるのか？など動きが良く解らない所がある。
通常、JIT コンパイルされるものは以下に格納される。
%windir%\system32\inetsrv\ASP Compiled Templates
フェイル・オーバー後、
- 正しく JIT コンパイルしてくれるのか？
- 若しくはプリコンパイルする必要があるのか？
- 仮想ディレクトリを共有ディスクに入れる手順も書かれていない。
- なお、仮想ディレクトリに、FS の共有フォルダを指定することは可能である模様。
- UNC 指定でもマウントしたフォルダでも可能の模様ですが、
ユーザ・プロファイルの話が有るので UNC 指定が良いようです。 - アクセス許可設定だけは注意が必要、以下のいずれかを選択。
- フォルダのアクセス許可にコンピュータ・アカウントを足す。
- アプリケーション・プールのアカウントを AD アカウントに変更する。
- UNC 指定でもマウントしたフォルダでも可能の模様ですが、
- FS を、クラスタ・アプリケーションに設定。
- IISは、クラスタ・アプリケーションに設定しない。
- NIC を監視することで障害時に対応する仮想 IP を 2 号機へフェイル・オーバー。
- 後処理スクリプトで 2 号機の IIS を起動
（Standby 側の IIS は通常時は停止しているため） -
IIS や AP 障害時（フリーズも含む）は切り替えできない。
フロント NIC のみを監視しているため、フェイル・オーバーのトリガにならない。
移行メモ（誤字）: 元ページの「Stanby」は「Standby」の誤記である。
また「IISやUP障害時」は文脈上「AP 障害時」と解される。
-
同じクラスタ・グループのクラスタ・リソースに、
- NIC × 1 に仮想 IP × 2 を複数指定して追加できた。
- （NIC × 1 に仮想 IP × 1 を指定して、）× 2 を追加できた。
-
ただし、
- クラスタ・グループのクラスタ・リソースに追加した NIC は、
クラスタ ネットワーク通信を許可する必要がある。 - この場合、既定でクラスタ・アプリケーションでは
双方の NIC、仮想 IP が使用される。 - なお、IP アドレスは、DHCP でも、固定でも、可能だった。
- クラスタ・グループのクラスタ・リソースに追加した NIC は、
-
IISが、全ての IP を Listening する設定の場合は、
netstatで見る限り IIS はTCP 0.0.0.0:80で Listening しており、
起動・停止の制御は不要。 -
仮想ディレクトリに、FS の共有フォルダを指定することは可能だが、
IIS → FS の共有フォルダへのアクセスには、以下の両方の
アクセス権が必要。- ノード 2 台のコンピュータ・アカウント
（IIS と FS がクロスした時用） -
IIS AppPool\DefaultAppPool（自 IIS から自 FS へアクセスする時用）
- ノード 2 台のコンピュータ・アカウント
補足（最後の項目が実務的に重要）: この「両方が必要」という結論は、
サービス・タスク系のアカウント問題で
述べた内容の具体例になっている。
アクセス経路 使われる資格情報 同一ノード内（IIS → ローカル FS） IIS AppPool\<プール名>（仮想アカウント）ノードを跨ぐ（IIS → 別ノードの FS） コンピュータ アカウント（ DOMAIN\HOST$）フェイル オーバーの結果として
IIS と FS が別ノードに分かれる可能性があるため、
両方の権限を先に付けておく必要がある。
「普段は動くが、フェイル オーバー後だけアクセス拒否になる」という
分かりにくい障害はこれが原因になる。
Tags: 移行, Windows, 冗長化
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。