NLB 環境における IIS7.x の共有構成について

IIS7.x の共有設定について先日のブログの記事で、ネットワーク負荷分散の方法として Windows Server 2008 の ネットワーク負荷分散 ( NLB ) 機能のリンクを紹介したのですが、肝心の IIS の共有設定について紹介しておりませんでしたので、取り急ぎリンクを掲載させていただきます。

TechNet - 『共有構成』
https://technet.microsoft.com/ja-jp/library/ff454006.aspx

さて、上に紹介した IIS の共有設定の内容についてなのですが、これらについて検証、作業する場合は、必ず C:\windows\system32\inetsrv\config 以下の全ての *.config ファイルのバックアップコピーを取得しておいてください。

実は私、このドキュメントの翻訳監修作業中に設定を誤り、IIS が二度と起動しくなるという事態に陥ったことがあるのです。

しかも通常であれば、IIS のみを入れなおせば、正常に戻るはずですが、このときは、IIS を役割から削除し、残った設定ファイル類を手動で削除しても元にもどすことはできず、結局 OS を入れなおす ( というか、バックアップしてあった vhd に戻す ) という手順が必要になりました。

 

おまけ : 共有構成における ASP.NET アプリケーション配置の注意点

NLB を使用して、リクエストを複数の Web サーバーに負荷を分散させた場合、コンテンツのメンテナンスの工数を削減するためにコンテンツをネットワーク共有上に配置するという方法がとられることも多いと思います。

この方法、HTML や jpeg といった静的なファイルに関してはさほど問題にはなりませんが、ASP.NET アプリケーションについてはその仕組み上、あまりお薦めできません。

なぜなら .NET アプリケーションでは、マネージド コードのほとんどがアプリケーションシナリオで十分な安全性が保たれるように設計されており、インターネットやローカル、イントラネットなど、信頼性の低い、または信頼性のない環境からのコードがローカルマシン上で実行されたときの権限は厳しく制限されており、制限そのものはもちろんのこと、チェック処理にかかる負荷など、様々な懸念点が考えられるためです。

 

.NET Framework 1.1 ～ 3.5 SP1

.NET Framework 1.1 時代には、セキュリティが大幅に強化され、Code Access Security（CAS） の概念が追加されました。これにより、ローカル以外に存在するアセンブリは既定で「セキュリティが信用できないもの」としてロード、実行に大きな制限がかけられています。

このような制限により、global.asax から作成されるクラスがロードできないというエラーなどのアセンブリ/クラスのロードに関するエラー （ 該当のファイルパスが読み込めないといった明示的な I/O エラーを除く ） や、SecurityException、PermissionDenied などのエラーが発生する可能性があります。

また、ASP.NET の構造上、アプリケーションの実行の際に実際に使用される DLLは、該当環境システムフォルダ下層にシャドーコピーされて実行される必要があるため、セキュリティ制限下では様々な問題をはらむ可能性があります。

その他、ASP.NET アプリケーションを共有フォルダに配置した環境では、物理ファイルは別サーバ上に存在するため、常にセキュリティチェックの対象となります。セキュリティチェックは大変コストのかかる処理であるため、アプリケーションのパフォーマンスを低下させます。

上記のような機構的な問題、また実際に同様の環境で運用し、問題が発生した過去事例が複数あるため、共有フォルダに ASP.NET アプリケーションを配置して運用、開発することはあまりお勧めできないしだいです。

 

.NET Framewok 4.0 の場合

.NET Framewok 4.0 からは CAS は既定では無効になっており、セキュリティ ポリシーが簡略化され CLR 内部でセキュリティ監査されるコード量を減らして処理の実行を効率化しています。

また CAS に代わる 「レベル 2 のセキュリティ透過性モデル（Level 2 Security Transparency model）」と呼ばれる新しいセキュリティモデルも採用されていますが、これら ポリシーの変更によって、グローバルキャッシュの信頼済みコードの動作が変わる場合もあるので共有フォルダに配置する云々とは関係なく、セキュリティに関する部分は注意する必要があります。

詳しくは以下のリンクをご参照ください。

ASP.NET 4 の互換性に影響する変更点
https://download.microsoft.com/download/3/4/C/34C3BDA5-84FA-4FBD-9BBC-00AA52C05813/ASP.NET_Breaking_Changes.pdf

.NET Framework 4 におけるセキュリティの変更点
https://msdn.microsoft.com/ja-jp/library/dd233103.aspx#simplification

コード アクセス セキュリティ
https://msdn.microsoft.com/ja-jp/library/c5tk9z76.aspx

 

こういった .NET Framework の機構のほか、共有フォルダのあるネットワークのパフォーマンス(※)、帯域、共有されているフォルダのディスクの負荷なども関係してくるので、トラブルシュートの際には切り分けに手間がかかる場合があります。
(※) ネットワークの速度と、HD のバススピードの速度の差を考えれば、ご理解いただけるでしょう。

さて、なにやら 「おまけ」 の部分の方が長くなってしいましたが、ASP.NET アプリケーションの共有フォルダに配置しての運用については、

やめといたほうがいいんじゃないすかねぇ…。

ということで。