NLB？MSCS/WSFC？ のバックアップ(No.4)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• NLB？MSCS/WSFC？ へ行く。
  • 1 (2014-09-11 (木) 17:35:39)
  • 2 (2014-09-11 (木) 17:39:21)
  • 3 (2015-10-27 (火) 09:52:45)
  • 4 (2015-11-25 (水) 10:46:33)
  • 5 (2015-11-27 (金) 16:09:24)
  • 6 (2016-01-26 (火) 13:35:24)
  • 7 (2017-03-03 (金) 21:39:44)
  • 8 (2017-03-27 (月) 11:45:27)

---

Open棟梁Project - マイクロソフト系技術情報 Wiki

• 戻る?

目次 †

前提知識 †

• NLB
• MSCS/WSFC

NLBとMSCS/WSFCの同居 †

要件 †

IISと

• ファイル・サーバ（以下FS）
• プリンタ・サーバ（以下PS）
• SQL Server
• JP1

を筐体の数を抑えるため、

これらを１つの筐体に詰めてクラスタ化したい場合にこの要件が上がる。

実現可能性 †

できません（実現不可能）。

• MSCS と NLB の相互運用性
  http://support.microsoft.com/kb/235305/ja
  

クラスタ サービスとネットワーク負荷分散の両方をインストールしたコンピュータを
サポートする必要がある場合、いずれか一方のコンポーネントを削除する必要があります。

これらのコンポーネントのいずれかをアンインストールするには、以下のうち適切な方法を実行します。

• クラスタ サービスを実行する必要があるコンピュータ
  コンピュータがサーバー クラスタでクラスタ サービスを実行する必要がある場合、
  [ネットワークとダイヤルアップ接続] ツールから NLB を削除します。

• NLB を実行する必要があるコンピュータ
  コンピュータで NLB を実行する必要がある場合、クラスタ サービスを削除します。

L7負荷分散 †

この問題をクリアするために、L7負荷分散を実現する

Application Request Routing (ARR)という

モジュールがIIS7.0から導入されているようです。

高い可用性とスケーラビリティの実現 - ARR および NLB
http://technet.microsoft.com/ja-jp/library/ee886284.aspx

• 

ARR では、コンテンツ サーバーに対して
高い可用性とスケーラビリティを提供していますが、
展開全体の可用性とスケーラビリティは高くありません。

これには、次の理由があります。

• ARR は単一障害点である。
• コンテンツ サーバーのスケーラビリティが、
  単一の ARR サーバーの最大容量によって制限されている。

上記の課題を克服するために、管理者はNLBと組み合わせた
複数の ARR サーバーの使用を検討することができます。

• 

ARR は、

• アクティブ/パッシブ モードで展開して、高可用性のみ実現できます。
• または、アクティブ/アクティブ モードで展開して、
  高い可用性とスケーラビリティの両方を実現できます。

このホワイトペーパーでは、ARR と NLB を一緒に展開して、

• ARR のコア シナリオを有効にし、
• かつ、全体的に高い可用性とスケーラビリティを実現する

方法について説明しています。

NLB は、Windows Server 2008 のすべてのSKU（製品ラインアップ）で使用できます。

IISをMSCS/WSFC環境上でクラスタ化 †

概要 †

ステートレスなIISは、一般的にはNLBクラスタを選択するべきです。

Webアプリケーションが

• セッション・ステートレスでない場合も、
• （セッション・ステートフルである場合）

Session状態を

• State Service Mode
• SQL Server Mode
• Custom Session Provider
  • Oracle Providers for ASP.NET
    • セッション状態プロバイダ
  • .etc

に退避するようにする事で、NLBクラスタに対応させることができます。

ただし、NLBとMSCS/WSFCの同居ができないので、

IISを負荷分散クラスタ化せず、
フェイル・オーバー・クラスタ化する場合に限って、
KB970759のスクリプトを使用してMSCS/WSFCクラスタ化します。

問題点 †

KB970759のスクリプトが標準で付属していない †

Windows Server 2008 R2 からはスクリプトが標準で付属しないようなので、
以下のURL（KB970759）にあるスクリプトの内容を理解して、

Microsoft Windows Server 2008 フェールオーバー クラスターで
IIS 7.0 World Wide Web 発行サービスを構成する
http://support.microsoft.com/kb/970759/ja

必要に応じて書き替えて構成・検証するしかなさそうです。

Windows Server 2008 以降でクラスター化された IIS を作成 « SE の雑記
http://engineermemo.wordpress.com/2011/05/15/windows-server-2008-%e4%bb%a5%e9%99%8d%e3%81%a7%e3%82%af%e3%83%a9%e3%82%b9%e3%82%bf%e3%83%bc%e5%8c%96%e3%81%95%e3%82%8c%e3%81%9f-iis-%e3%82%92%e4%bd%9c%e6%88%90/

• MSCS / WSFCクラスタとNLBクラスタは共存ができないため、
  MSCS / WSFCクラスタ環境で IIS を冗長化した構成で使う場合には、
  [汎用スクリプト] を登録してMSCS / WSFCクラスタ化された IIS を作成していました。

• 2008 では 2003 で使用していたスクリプトが含まれてしまっているのですが、
  使用せずに以下の技術情報 (KB970759) のスクリプトを使用します。
  

  2008 R2 では含まれなくなっています。

KB970759のスクリプトの手修正が必要になる。 †

• KB970759のスクリプトの内容を確認すると「既定のWebサイト」のみの対応なので、
  Active-Acitve構成に対応させようとした場合、スクリプトの手修正が必要になる。

• サポートはされるが、スクリプト側は自己責任になる。
  サポート問合せの時、＋使用しているスクリプトの提供が必要になる。

理解が不十分で運用中に問題となる可能性がある。 †

以下の様な不具合が報告されています。

Windows Server TechCenter? > Windows Server フォーラム > Windows Server 2008 全般
　> Windows2008 IIS7.0のクラスタ（WSFC）環境で、新しく作成した仮想ディレクトリにアクセスするとHTTP 404エラーが表示される。
http://social.technet.microsoft.com/Forums/ja/windowsserver2008ja/thread/2b8aa4b0-e8ac-49c0-a267-1a01d1f248f6

http://support.microsoft.com/kb/970759

の情報を元に、IISをクラスタのリソースとして登録しました。セットアップは問題なく完了し、動作も良好でした。しかし、後からIISの仮想ディレクトリを作成したところ、作成は問題なく行えるのですが、クライアントからアクセスすると「サーバーエラー 404 ファイルまたはディレクトリが見つかりません」となってしまう場合があります。「場合」について切り分けができていません。ある日は問題なくアクセスできたのに、数日後は404エラーが表示される、といった具体で、一旦ダメになると、サーバを再起動するまでアクセスできないままになります。原因が分かりましたらご教示頂けますでしょうか。

IISのMSCS/WSFCクラスタを検証 †

懸念 †

（１）IISの設定情報は共有されるか？ †

• IISの設定情報はクラスタ・ノード間で共有されるか？
  • IIS6：メタベース（MetaBase?.xml）
  • IIS7：applicationHost.config

• メタベースを共有ディスクに入れる必要があるか？

（２）JITコンパイルは問題ないか？ †

KB970759の手順に共有構成をエクスポートして共有ディスクに入れる手順があるが、
JITコンパイルで生成されるアセンブリなどが、何処にどう格納されるのか？
など動き（のディティール）が良く解らない所がある。

通常、JITコンパイルされるものは以下に格納される。
%windir%\system32\inetsrv\ASP Compiled Templates

フェールオーバー後、

• 正しくJITコンパイルしてくれるのか？
• 若しくはプリコンパイルする必要があるのか？

（３）仮想ディレクトリを共有ディスクに入れることができるか？ †

• 仮想ディレクトリを共有ディスクに入れる手順も書かれていない。

• 仮想ディレクトリを共有ディスクに入れ
  仮想ディレクトリにプリコンパイルしたものを入れておけば良い？

• なお、仮想ディレクトリに、FSの共有フォルダを指定することは可能である模様。
  （実際は、クラスタ化されたFSの共有フォルダを指定する）

• UNC指定でもマウントしたフォルダでも可能の模様ですが、
  ユーザ・プロファイルの話が有るのでUNC指定が良いようです。

• アクセス許可設定だけは注意が必要、以下のいずれかを選択。
  • フォルダのアクセス許可にコンピュータ・アカウントを足す。
  • アプリケーション・プールのアカウントをADアカウントに変更する。

（４）その他、スクリプトを使用しない方法 †

• FSを、クラスタ・アプリケーションに設定。
• IISは、クラスタ・アプリケーションに設定しない。

• この状態で、１つのクラスタ・グループのクラスタ・リソースに
  

1. フロントNIC×１と仮想IP×２（FS用とIIS用）のセットを
   追加して、フェイル・オーバー、フェイル・バックできるか？
2. 以下を追加して、フェイル・オーバー、フェイル・バックできるか？
   • フロントNIC×１に仮想IP×１（IIS用）のセットを追加
   • バックNIC×１に仮想IP×１（FS用）のセットを追加

• NICを監視することで障害時に対応する仮想IPを2号機へフェイル・オーバー。
  （なお、仮想IPは１つのNICに対して複数指定することもできる筈）

• 後処理スクリプトで2号機のIISを起動
  (Stanby側のIISは通常時は停止しているため)

  これは、特定のIPをListeningする場合は、
  Listeningする仮想IPがフェイル・オーバーしないとIISが起動しないため。
  全てのIPをListeningする場合は、起動・停止の制御は不要であるものと思われる。

• IISやUP障害時(フリーズも含む)は切り替えできない。

  フロントNICのみを監視しているため。
  上記ではフェイル・オーバーのトリガにならない。

結果 †

（１）の検証結果 †

（２）の検証結果 †

（３）の検証結果 †

（４）の検証結果 †

• 同じクラスタ・グループのクラスタ・リソースに、
  1. NIC×１に仮想IP×２を複数指定して追加できた。
  2. （NIC×１に仮想IP×１を指定して、）×２を追加できた。

• ただし、

• クラスタ・グループのクラスタ・リソースに追加したNICは、
  クラスタネット・ワーク通信を許可する必要がある。

• この場合、既定でクラスタ・アプリケーションでは双方のNIC、仮想IPが使用される。

• なお、IPアドレスは、DHCPでも、固定でも、可能だった。

• IISが、全てのIPをListeningする設定の場合は、netstatで見る限り
  IISは、TCP 0.0.0.0:80（0.0.0.0）でListeningしており、起動・停止の制御は不要。

• 仮想ディレクトリに、FSの共有フォルダを指定することは可能だが、
  IIS→FSの共有フォルダへのアクセスには、以下の両方のアクセス権が必要。
  • ノード２台のコンピュータ・アカウント(IISとFSがクロスした時用)
  • IIS AppPool?\DefaultAppPool?(自IISから自FSへアクセスする時用)

     

Site admin: dotNetDevelopmentInfrastructure

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.032 sec.