IIS 6.0の徹底的な分析

4番目に、アプリケーションプールの詳細
IIS 6.0アーキテクチャの重要なコンポーネントについて学びました。アプリケーションプールに関連するいくつかの問題を見てみましょう。図6に示すように、アプリケーションプールの[プロパティ]ダイアログには、リサイクル、パフォーマンス、正常性、およびIDの4つのページがあります。おそらく、これらのオプションページの中で最も魅力的なのは、[リサイクル]ページです。このページでは、ワーカープロセスのリサイクルを管理できます。ワーカープロセス分離モードでは、エラーが発生したワーカープロセスをより適切に管理するために、アプリケーションプール内のワーカープロセスを定期的に再起動するようにIISを構成できます。これにより、プール内のアプリケーションが正しく機能し、失われたシステムリソースを回復できるようになります。ワーカープロセスを再利用するために、失敗したワーカープロセスが要求を受信する機能は、要求キューに格納されている残りのすべての要求を処理するまで制限されます。現在の要求を排出するために、プロセス構成制限を与えることができます。同じネームスペースグループの代替ワーカープロセスは、古いワーカープロセスが停止する前に開始され、サービスの中断を防ぎます。古いプロセスは保留中の要求を完了してから正常にシャットダウンするか、または設定された制限時間、要求数、設定された時間スケジュールに達するか、または指定されたメモリ使用制限に達した後に閉じない場合、プロセスを明示的に終了します。 。デフォルトでは、アプリケーションプールは1740分（29時間）ごとに回収されます。

W3SVCは、[Health]ページのオプションに従って、アプリケーションプールが正常に動作しているかどうかを判断します。指定した時間ごとにワークプロセスをpingし、時間は秒単位で、デフォルト値は30秒​​です。プロセスは指定された時間内に開始する必要があります;制限時間は閉じられます（ワーカープロセスは指定された時間内にシャットダウンされる必要があります）;速い障害保護が開始されるかどうか（一定時間内に一定数のワーカープロセスが失敗すると、アプリケーションは無効になります）プール）。さらに、ISAPIアプリケーション（ASP.NETやasp.dllを含む）は、サービスを提供するのにはもはや適していないと宣言することができ、リサイクルが必要です。

既定では、IIS 6.0はプールを回収するときに、重複リサイクルと呼ばれるリサイクル技術を使用します。このリサイクルモードでは、失敗したワーカープロセスは実行されたままになり、新しいワーカープロセスが作成されます。 IIS 6.0は新しい着信要求を新しいワーカープロセスに渡しますが、古いワーカープロセスがキュー内の要求を処理するかタイムアウトエラーが発生するまで、古いワーカープロセスを破棄しません。この間、接続を有効にしているhttp.sysがあるため、TCP /IP接続は失われません。失敗したワーカープロセスタイムアウトエラーが発生した場合、次の要求によってワーカープロセスに渡される要求は新しい要求であるため、元々プロセスに保存されていたセッション情報は失われます。このようなリサイクル操作はすべて管理者の介入なしに自動化されており、ほとんどの場合、重大なサービスの中断を引き起こすことはありません。必要に応じて、構成データプロパティLogEventOnRecycleの値を1に設定できます。これは、W3SVCが再生操作を実行したときにイベントログレコードを生成することを示します。

複数のインスタンスで実行できないアプリケーションでは、重複したリサイクルリサイクル技術が問題を引き起こす可能性があります。このような問題が発生した場合は、構成データプロパティDissallowOverlappingRotationの値をTrue（1）に設定して、アプリケーションプールのリサイクル操作が閉じられたときにプロセスの "オーバーラップ"現象を閉じることができます。さらに、失敗したワーカープロセスについては、削除したくない場合があります。問題の根本的な原因を検出して見つけるためにプロセスを保持します。その後、構成データプロパティOrphanActionExeを実行ファイルの名前に設定します。オーファン実行ファイルは実行されたままです。

アプリケーションプールに関連するもう1つの機能は、IIS 6.0ではアプリケーションプールをWebガーデンとして構成できることです。 Webガーデンの概念を理解するために、IIS 5.0が自動的に循環ループモードで要求できる場合に、それぞれ同じアプリケーションを実行しているIIS 5.0サーバーと3つのWebサイトがあるシナリオを想像してください。これらの機能的に同等の、実質的に別々のWebサイトに順次送信して、負荷を3つの異なるプロセスに分割すると、小さなWebファームを形成できます。これがWebガーデンです。

IIS 6.0 Webガーデンでは、追加のWebサイトを作成する必要はありません。アプリケーションプールのワーカープロセスの数を指定するだけです。具体的な設定手順は次のとおりです。図8に示すように、アプリケーションプールの[プロパティ]ダイアログボックスを開き、[パフォーマンス]ページに移動し、[Webガーデン]の[最大作業プロセス数]入力ボックスにプロセス数を入力します。サーバーの負荷が小さく、追加のワークプロセスが不要な場合、IIS 6.0は一定時間経過後に実際のワーカープロセス数を自動的に減らし（デフォルトは20分、構成可能）、負荷が大きくなると追加のワークプロセスが必要になります。 6.0では、再びワークプロセス数が増加します。これはすべて自動的に行われ、管理者の介入は不要です。図VIII

ログイン

二つの新しいコンフィギュレーションデータと--SMPAffinitze SMPAffinitzeCPUMask--は、特にプロセッサを割り当てるように構成されたワーカープロセス可能属性：trueに設定SMPAffinitizedプロパティを表すために割り当てられますアプリケーションプールの特定のワーカープロセスは特定のCPUに割り当てられ、SMPProcessorAffinityMask属性を使用して、アプリケーションプール内のどのワーカープロセスにバインドするかを示す16進数のプロセッサマスクを構成します。 CPU

ここに書いて、記事の長さが長すぎたようです。この記事では、アーキテクチャの観点からIIS 6.0の新機能を紹介し、少なくとも一般的に見られる導入よりも包括的になるようにします。この記事の後半部分では、IIS 6.0の新機能について詳しく説明します。また、長い間期待していた多くの新機能についても説明します。
前回の記事では、IIS 6.0のインストールとWebサーバーの新しいアーキテクチャについて説明しました。 IIS 6.0の新機能の数は驚くべきものであり、それらの一部は非常に説得力があるため、ほとんどの人の注意がそれらに向けられています。 IIS 6.0に関するこの2回目の記事では、「スター」になったこれらの機能を理解するだけでなく、IIS 6.0があまり注意を払わないが同様に重要なさまざまな改善点にも焦点を当てます。

最初に、セキュリティ

マイクロソフトは何度も何度も同じことをしました - ソフトウェア製品が間違っていて、人々が批判されているので、問題を解決するために新しいバージョンを素早くリリース。たとえば、Windows NT 4.0のリリース後は安定性の問題で批判され、MicrosoftはWindows 2000をリリースし、新しいオペレーティングシステムの安定性は好評でしたが、Win 2Kサーバー上のIIS 5.0のデフォルトインストールは大きなセキュリティリスクとなりました。問題を解決するには多大な努力が必要です。 IIS 6.0は既定ではインストールされません既定でインストールされている場合、Webサーバーは静的コンテンツサービスのみを提供できます。したがって、この観点から、IIS 6.0アプリケーションエンジンおよびコンポーネントに突然問題が発生したとしても、IIS 6.0はセキュリティ上のリスクを大幅に軽減します。さらに、Windows Server 2003には新しいグループポリシー "IISのインストールを禁止する"があり、このグループポリシーを使用すると、Active Directory（AD）フォレスト内のWebサーバーに対応していないコンピュータにWindows 2003をインストールすることを禁止できます。ネットワーク上で無用で安全でないIIS 6.0サーバーの使用を防ぐため。ただし、このグループポリシーは現在Windows 2003サーバーにのみ有効であり、Windows XP ProおよびWin 2KマシンにIIS 5.0がインストールされるのを防ぐことはできません。

もちろん、新しくインストールしたIIS 6.0は動的コンテンツをサポートしていないため、「なぜサーバーでASPを実行できないのですか？」という質問がよくあります。よく寄せられる質問は、「IIS 6.0はWin 2Kサーバー上で実行できるかどうか」です。その答えは「いいえ」です。 IIS 6.0でプログラムを実行するには、IIS 6.0の新機能、Webサービス拡張機能、またはWebサービス拡張機能を使用する必要があります（この名前は、XML Webサービスと何らかの関係があることを示唆しているようです）。

プログラムに対してWebサービス拡張を有効にする場合は、まず[コントロールパネル]→[管理ツール]の[インターネットサービスマネージャ（ISM）]でIISマネージャを開き、図1のようにクリックします。 「新しいWebサービス拡張を追加する」をクリックし、ウィザードを起動して新しいルールを作成します。ルールに名前を付けて、有効にする実行可能ファイルを見つけます。さらに、\\ system32 \\ inetsrvの下にiisext.vbsスクリプトがあります。このスクリプトは、Webサービス拡張機能、アプリケーション、およびIIS 6.0でWindows Server 2003を実行している個々のファイルも構成および管理します。管理者はアプリケーションを有効にして、リストにこのスクリプトを使用することができます。図1では

を追加し、アプリケーションを削除し、注意して、「すべての不明なISAPI拡張」および「すべての不明なCGI拡張」両方のWebサービス拡張。既定では、これら2つの拡張機能は無効になっています。つまり、アプリケーションがIIS 6.0で明示的に実行を許可されていない限り、そのアプリケーションは実行されません。ユーザーが有効になっていないファイルを要求すると、IIS 6.0はユーザーに404エラーを返します - ファイルまたはディレクトリが見つからず、「404.2ファイルまたはディレクトリがW3SVCログに見つかりませんでした：ロックポリシーにより要求が禁止されます」。 IIS 6.0では、404.2およびその他のサブステータスコードは、トラブルシューティングおよびトラブルシューティングに役立つW3SVCログファイルのオプション機能です（IIS 5.0およびIIS 4.0にはサブステータスコードがありますが、ログファイルには記録されません）。しかし、サブステータスコードに基づいて特別な処理を実行するためにそれらをカスタムエラーページに変えることができます。 IIS 6.0のサブステータスコードは有用です。たとえば、403.20、アクセス不可：Passportのログインに失敗、403.18、アクセスなし：現在のアプリケーションプールで要求されたURLを実行できない、404.3、ファイル、またはディレクトリが見つかりませんでした：MIMEマッピングポリシーで要求が禁止されています; 500.19、サーバーエラー：このファイルのデータは構成データベースで正しく構成されていません。これらおよび他のすべてのエラーは、サブステータスコードをユーザーに送信しないカスタムエラーページにマッピングされ、攻撃者は特定のエラーメッセージを知ることができません。もう1つのセキュリティの向上は、IIS 6.0では、ハードウェアベースのSSL（Secure Sockets Layer）アクセラレータをIIS 6.0に統合する暗号化サービスプロバイダ（CSP）を割り当てることができることです。暗号化タスクは、サーバーの汎用CPUから暗号化操作用に最適化された専用装置に移ります。これにより、パフォーマンスと信頼性が向上します。

2番目に、構成データ

IIS 5.0およびIIS 4.0では、構成データベースはバイナリファイル構造を使用しますが、IIS 6.0はこの方法を断念しました。 IIS 6.0の構成データは、IIS 6.0サーバーの構成情報を含むMetabase.xmlと、構成データのスキーマ定義を含むmbschema.xmlの2つのXMLファイルで構成されています。 IISマネージャには、Webサイトを右クリックして[すべてのタスク]→[設定をファイルに保存]の順に選択し、設定データコピーのファイル名とパスを指定して設定データのコピーを保存する新機能があります。ただ大丈夫です。この方法で構成データを保存する場合、IIS 6.0はシステムのMachine Keyを使用して構成データの一部を暗号化するため、構成データのコピーはそのコピーを作成したコンピュータにのみ役立ちます。

ただし、[設定をファイルに保存する]ダイアログボックスで[設定をパスワードで暗号化する]オプションを選択してからパスワードを指定し、エクスポートした設定ファイルを保護するためにパスワードを使用することができます。パスワードが提供されている場合、IIS 6.0はマシンコードをパスワードに置き換えます。将来同じパスワードを提供することで、構成データを別のサーバーにインポートできます。あるいは、コマンドラインスクリプトiisback.vbs（systemroot \\ System32にあります）を使用して、リモートコンピューターまたはローカルコンピューター用のIIS構成のバックアップコピーを作成および管理することもできます。 IIS構成を復元し、バックアップコピーを一覧表示して削除します。

場合によっては、すべての設定情報を保存するのではなく、アプリケーションプール、Webサイト、または仮想ディレクトリの設定のみを保存する必要があります。この場合は、オブジェクトを右クリックして設定情報を保持します。図2に示すように、[すべてのタスク]→[設定をファイルに保存]の順に選択して、設定データを別のサーバーにインポートする準備ができたら、暗号化ファイルのパスワードを入力する必要があります。