IIS 7.0 概要とアーキテクチャ
マイクロソフト株式会社
IT Pro エバンジェリスト
奥主 洋
http://blogs.technet.com/hirookun
IIS情報サイト（英語）
Vista / Longhorn Server Beta2とともに公開
http://www.iis.net
広告ベース運営のコミュニティサイト
IIS7製品開発チームの技術記事
バーチャルラボでIIS7を体験できる！
アジェンダ
Core
Configuration
Admin
Setup
Security
Diagnostics
WrapUp
＝ サーバーコア
＝ 構成システム
＝ 管理機能
＝ セットアップ
＝ セキュリティ
＝ 診断機能
＝ まとめ
Core ＝サーバーコア
IIS6とIIS7のアーキテクチャー
IIS6.0
IIS7.0
HTTP
Response
HTTP
Request
HTTP
Response
HTTP
Request
基本
basicauth.dll
認証
認証
基本
匿名
NTLM
・・・
CGI
決定
ハンドラー
authsspi.dll
匿名
キャッシュ解決
・・・
authanon.dll
・・・
CGI
cgi.dll
静的
コンテンツ
実行ハンドラー
静的ｺﾝﾃﾝﾂ
ISAPI
・・・
ISAPI
static.dll
isapi.dll
・・・
・・・
レスポンス送信
圧縮
許可
NTLM
ログ
キャッシュ更新
圧縮
compstat.dll
レスポンス送信
ログ
loghttp.dll
IIS6におけるASP.NET統合
HTTP
Request
認証
基本
匿名
NTLM
・・・
CGI
決定
ハンドラー
静的
コンテンツ
aspnet_isapi.dll
認証
ﾌｫｰﾑ
Windows
・・・
ISAPI
ﾏｯﾌﾟ
ﾊﾝﾄﾞﾗｰ
・・・
レスポンス送信
圧縮
HTTP
Response
ASPX
ログ
ISAPIエクステンション
による実装
ASP.NETリクエストの
みを処理
実行時の制限
ISAPI
実行される順番
類似機能の存在
Trace
・・・
認証
ハンドラーのマッピング
エラーハンドラー
IIS7におけるASP.NET統合
HTTP
Request
HTTP
Request
クラシックモード
認証
許可
統合モード
基本
基本
認証
許可
匿名
キャッシュ解決
キャッシュ解決
aspnet_isapi.dll
静的
コンテンツ
実行ハンドラー
Windows
実行ハンドラー
・・・
ﾌｫｰﾑ
Windows
認証
ﾌｫｰﾑ
匿名
静的
コンテンツ
ISAPI
ISAPI
ASPX
ﾏｯﾌﾟ
ﾊﾝﾄﾞﾗｰ
・・・
キャッシュ更新
ASPX
Trace
キャッシュ更新
Trace
レスポンス送信
圧縮
圧縮
レスポンス送信
ログ
HTTP
Response
ログ
HTTP
Response
Configuration ＝ 構成システム
構成ファイルのレイアウト
root 構成ファイルのツリー
web.configファイル
IIS +
ASP.NET +
.NET Framework
上位継承
IIS
ASP.NET
applicationHost.config
.NET
Framework
web.config
※ビルド 5384 は inetsrv 直下にある
root web.config
machine.config
スキーマ：%windir%\system32\inetsrv\config\schema\
IIS_schema.xml, ASPNET_schema.xml , FX_schema.xml
Config 設定の委任、ロッキング
IISマネージャ
システム管理者はグローバ
ルおよび特定設定が可能
サイト/アプリを委任された管
理者は自身のサイト/アプリ
の設定をすることが可能
applicationHost.config
セクションをアンロックするとセクション全体をサイト/アプリの管理者に開放
粒度の小さいロッキングも特定のエレメント/アトリビュートに対して可能
lockAttributes、lockAllAttributesExcept、lockElements
lockAllElementsExcept、lockItem
Admin ＝ 管理機能
複数ある管理方法、ツール
GUI
コマンドライン
スクリプト
マネージドコード
IIS マネージャ
appcmd
WMI (root\WebAdministration)
Microsoft.Web.Administration
IIS、ASP.NETを両方管理することが可能
拡張された実行状態データを見ることが可能
ワーカープロセス、アップドメイン、リクエスト
管理の委任が可能
使いやすく、状況・用途に最も適したものを利用し
てください．．．
管理機能のアーキテクチャー
IIS
マネージャー
マネージド
API
WMI
appcmd
コンフィグレーション リーダー
XML コンフィグ ファイル
アンマネージド
API
IIS マネージャ
HTTPでのリモート接続、ファイアウォール越えが可能
マネージドコードによるツール機能の拡張も可能
システム管理者ではない委任されたユーザーによるサ
イトやアプリケーションの管理を実行可能
Appcmd – 一覧とフィルタリング
C:\>
SITE
SITE
SITE
appcmd list sites
"Default Web Site" (id:1,bindings:HTTP/*:80:,state:Started)
"Site1" (id:2,bindings:http/*:81:,state:Started)
"Site2" (id:3,bindings:http/*:82:,state:Stopped)
C:\> appcmd list requests
REQUEST "fb0000008000000e" (url:GET
/wait.aspx?time=10000,time:4276 msec,client:localhost)
C:\> appcmd list requests /apppool.name:DefaultAppPool
C:\> appcmd list requests /wp.name:3567
C:\> appcmd list requests /site.id:1
アプリプール、ワーカー
プロセスあるいはサイト
によるフィルター結果
新IIS7構成情報に簡単に、すばやくアクセス
IIS6で用意された*.vbs ファイル群に変わるもの
ビルトインで“パイプ”をサポート
WMIを利用したスクリプティング
Set oService =
GetObject("winmgmts:root\WebAdministration")
' Create binding for site
Set oBinding =
oService.Get("BindingElement").SpawnInstance_
oBinding.BindingInformation = "*:80:www.site.com"
oBinding.Protocol = "http"
' Create site
oService.Get("Site").Create _
"NewSite", array(oBinding), "C:\inetpub\wwwroot"
' Create application
oService.Get("Application").Create _
"/foo", "NewSite", "C:\inetpub\wwwroot\foo"
全く新しい WMI プロバイダーにより新Configをフルサポート
WMIv2 と ADSI サポート
既存のスクリプトはそのまま動作、メタベースの互換性サポートをインストール
するのは簡単
Admin Base Object (ABO) コールを新Configにルーティング（Appendix）
Inetinfo.exe サービスがロードされていることに引き続き依存
マネージドコードでの管理
Microsoft.Web.Administration
ServerManager iisManager = new ServerManager();
foreach(WorkerProcess w3wp in iisManager.WorkerProcesses) {
Console.WriteLine("W3WP ({0})", w3wp.ProcessId);
}
foreach(Request request in w3wp.GetRequests(0)) {
Console.WriteLine("{0} - {1},{2},{3}",
request.Url,
request.ClientIPAddr,
request.TimeElapsed,
request.TimeInState);
}
IISを管理する初めてのマネージドAPI
WMI、appcmdと同じ機能、オブジェクトを利用
System.Configurationも引き続き利用可能
Setup ＝ セットアップ
IIS7のセットアップ
IIS7環境の入手方法
Windows Vista
Starter、Home Basic
Home Premium
Business、Enterprise、Ultimate
・・・IISなし
・・・FTPなし
・・・フルIIS
Windows コードネーム “Longhorn Server”
是非 Beta2（ビルド 5384、日本語版）をご利用ください
サーバーとクライアント
Longhorn ServerもVistaも同一バージョンのIIS7
同時実行制限（現時点で10）はある
VistaのIIS7も複数Webサイト可
既存OSへのIIS7
XP、Windows 2003への提供予定なし
セットアップのオプション
•多くのコンポーネント
•デフォルトでは静的コンテンツのみ
•Sysocmgrの置き換え
•ファイル書式は完全に違う
•クライアントではコンポーネ
ントは選択可能だが、構成
をセットできない
セットアップ、移行、アップグレード
インストールログ
\Windows\IIS7.log
アンインストール
リブートを抑制するためにサービスを停止させる
アンインストールを行う前にconfigファイルやバックアップを
削除する
移行ツールなど
Vista にはなし、Longhorn Server は検討中
アップグレード
Web と FTP のコンポーネントをすべてインストール
アップグレード後に不要なコンポーネントの削除が必要
アプリプールはクラシックモードにセット、マネージドコードが
実行できない状態になる
すべての ASP.NET リクエストが失敗する状態
Security ＝ セキュリティ
セキュリティ
スリム化、最適化可能
モジュール化構造
インストールしなければパッチ考慮不要！
管理委任が可能なインフラ
管理権限を詳細に定義可能
Windowsアカウントだけでなく、独自定義可能
統合された認証機能群
統合モードにおけるフォーム認証
旧ASP、HTML、画像、PHPにもフォーム認証可能
必要であれば独自の認証機能も実装可能
セキュリティ
セキュアなConfiguration
アプリケーションプールのプロセス分離
Config中のパスワード暗号化
継承の上書き制御
ApplicationHost.config中のAllowOverride
システム管理者とアプリ管理者は分離
リクエストフィルタリング
URLScan機能をモジュールとして実装
404.8を返すHidden Namespace
アクセス可能なURLを定義
Diagnostics ＝ 診断機能
Localhost ブラウザーに返るエラー
再構築されたカスタムエラー
言語に対応 (Accept-Encoding)
サーバー外のクライアントと “Localhost” で相違
詳細なエラー結果情報
時刻、URL、実行中のモジュール、ステータス etc
Runtime Status And Control API
「ルスカ」
実行時ステータスをAPIで取得、制御する
Appプール
ワーカープロセス
Ｗｅｂサイト
Appドメイン
ゴール
Ａｐｐプール、Ｗｅｂサイト、Ａｐｐドメイン、ワーカー
プロセスの最新状態を取得する方法を提供する
上記のオブジェクトを制御する直接的で矛盾のな
い方法を提供すること
詳細な実行時の状況を公開する
オートマチック フェールド リクエスト トレーシング
Automatic Failed Request Tracing あるいは FREB
失敗リクエストに関して再現作業なしの解析メカ
ニズムの提供
トレースはオンにするが、失敗のみイベントを処理できる
ＵＲＬ単位で失敗の定義をカスタムで行える
実行に要している/要した時間
ステータスやサブステータスコード
ＵＲＬ転移でトレースを構成できるようにする
ＵＲＬ単位で何をトレースするか決められるようにする
例） aspnetでも “*.aspx”だけに絞り込む
プロセスの生存期間以降でもログファイルを見れ
るようにする
オートマチック フェールド リクエスト トレーシング
どうやって使うか – config ベースでの説明
ApplicationHost.config
サポートされるトレースプロバイダーとフラグ記載
web.config
トラックする失敗の条件を指定
する
URL を指定
失敗の条件
ステータスコード etc
URL単位でエラー種別を指定
統一されたWebプラットフォーム トレーシング
IIS7とレーシングインフラストラクチャーを通
して以下を同一ログにルーティングする
ASP.NET ページ上の Trace.Write() および
Trace.Warn() コール
System.Diagnostics.TraceSource コール
リクエストのコンテキストで発生したWebEvent
既存のインフラを利用してサポート
– プロバイダーモデル
互換! 上記の機能はIIS7ではない環境でも
Visual Studio 2005上で引き続き動作する
ページトレーシング
どうやって使うか
まずページトレーシングを有効にする <%@ Page Trace=“True” %>
ASPNET プロバイダー、Page フラグを取得するようにFREBを構成す
る
<traceFailedRequests>
<add path=“login.aspx” >
<traceAreas>
<add provider=“ASPNET” area=“Page” verbosity=“verbose” />
</traceAreas>
<failureDefinitions>
<add statusCodes=“401” timeTaken=“” />
</failureDefinitions>
</add>
<traceFailedRequests>
イベントは以下を出力する
データ: Connection ID, Activity ID, Uri, Write() Warn() コールで指定
したメッセージ
Trace.Warn() と Trace.Write() は別のイベントタイプ
Write() イベント : verbosity=“verbose”
Warn() イベント : verbosity=“warning”
Wrap Up ＝ まとめ！
マイクロソフトIT部門からのお薦め
特徴的な機能 – 管理と問題解析
管理ツール
UI の改善
新 管理 API (C#) と appcmd
“appcmd list wp” ワーカープロセスの一覧
“appcmd create backup” システム構成の保管、復元
“appcmd enum config” 構成情報の列挙
Web 診断
Runtime Status and Control API (RSCA)
Failed Request Trace Logging
自動 ETW トレース レポート
リクエストエラー条件に基づいている
HTTP ステータスコード と リクエストの実行経過時間
マイクロソフトIT部門からのお薦め
特徴的な機能 – モジュール、構成、コンテンツ処理
モジュール化構造
サーバーコンポーネントのカスタマイズ
Webプラットフォームの運用に最適化されている
統合され、展開可能な構成モデル
XCopy による展開: ApplicationHost.config
config にマシン依存の情報なし、IUSRアカウントも同一
UNC コンテンツ保管
クライアント サイド キャッシング – パフォーマンスとフォルトトレランスを
向上
新 SMB2 プロトコル – UNCパスに対するスケーラビリティの向上
展開シナリオ
静的、巨大なファイルのコンテンツストア (Downloads, Media, etc)
動的なコンテンツ (Rich Client/Server Page Experiences)
IIS7.0、使ってみませんか？
Core – サーバーコア
マネージドコードで作成したコアモジュールを実装可能
Configuration – 構成システム
アプリケーションの配布も容易
Admin - 管理機能
管理権限の細分化による管理委任
拡張可能な管理ツール、リッチなAPIによる管理
Setup - セットアップ
多彩なセットアップ方法
Security - セキュリティ
モジュール構造により 軽装、攻撃対象を減らす
Diagnostics - 診断機能
実行時の状態と制御をオブジェクト管理（RSCA：ルスカ！）
拡張可能な トレーシング サブシステム
技術情報リソース
Windows Server “Longhorn” Beta 2 のインターネット インフォメーション サービス 7.0：
http://www.microsoft.com/japan/windowsserver/longhorn/iis/default.mspx
インターネット インフォメーション サービス 7.0 (IIS7) についてよく寄せられる質問：
http://www.microsoft.com/japan/windowsserver/longhorn/iis/iis7faq.mspx
IIS 7.0 Beta: Internet Information Services (IIS) 7.0 SDK
http://msdn.microsoft.com/library/default.asp?url=/library/enus/IIS_70_WebExtSDK/html/6c07a4d0-1bf0-45d3-8178-25df76e6740c.asp
IISコミュニティの新ポータル（英語情報）
http://www.iis.net
IIS7 Module Overview （※NativeとManagedモジュールの一覧を含む）
http://www.iis.net/default.aspx?tabid=2&subtabid=23&i=930
How to Install IIS7 in Longhorn Server
http://www.iis.net/default.aspx?tabid=2&subtabid=23&i=956
How to install IIS7 in Windows Vista Beta 2
http://www.iis.net/default.aspx?tabid=2&subtabid=23&i=957
Appendix ＝ 添付資料
モジュール開発Tips
IIS7検討時のTips
IISパイプラインの詳細比較
新トレースアーキテクチャー
モジュール開発時のTips
IIS7 のサーバーコアモジュール
ISAPIとの対比
もっと強力なコードが書ける
よりリッチなＡＰＩ
より詳細な通知
記述が容易でもっと強固に書ける
オブジェクト指向 C++
キーになるパターンが単純化されている
管理がしやすい
統一された機能の管理が可能
粒度の小さい機能の有効化
IIS7 サーバーコアモジュール
統合モードを利用する際のインパクト
実行時の変更
IISネイティブのスレッドプールを使用
移行時のパフォーマンス影響
選択された実行: プリコンディション
実行時の最適化: リシャッフル、マージ
IHttpModule イベント順序
インパーソネーション
認証されたユーザー
コンフィギュレーション
httpRuntime, httpModules, httpHandlers
IIS7 サーバーコアモジュール
ASP.NET開発の向かう方向
既存のASP.NET 2.0 API
IHttpModule タイプ
そのまま利用可能！
IHttpHandler タイプ
既存の API がサーバーオブジェクトに接続される
追加される API
レスポンスヘッダーの列挙
リクエストヘッダーの操作
サーバー変数の操作
etc…
IIS7 サーバーコアモジュール
.NET か C++ か?
.NET: 記述が容易で取り扱い易い
ようやくほとんど何でもできるレベルへ
.NET フレームワーク上の言語を問わない RAD
リッチな ASP.NET API
サンドボックス化されたアプリ展開 (CAS)
C++: がっちり、きっちり
システムをもっとコントロールできる
パフォーマンスではこちらが上
マネージド/ネイティブ間のスイッチに留意
パイプライン外の処理、プロセス間のやりとり
IIS7 サーバーコアモジュール
どんな時にC++が必要なんだろう？
ほとんど必要ない...
マネージドとネイティブ モジュールAPIはほぼ共通の
機能を持つ
ただし、例外はある でもニッチなシナリオ
ネイティブモジュールが必要になるケース
リクエストでは無いイベントの処理
例） ファイルやコンフィグの変更、キャッシュのクリーンアップ
アップドメインを跨ぐようなシナリオ
特定のパフォーマンスが絡むシナリオ
IIS7検討時のTips
アプリケーション互換性
既存のアプリは純粋に動作するが、、、
サーバー関連
統合モードは ASP.NET2.0 だけ
IIS7専用のビルトインアカウントがデフォルト
IIS6 ワーカープロセス分離モードと同じ構造
デフォルトでバッファリングはオン
ASP.NETは元々オン、IISは今まで常にオフ
ASP.NET アプリケーション
ASP.NET 1.1, ASP.NET 2.0
2つのモード: クラシックモード（互換モード）, 統合モード
CLR 事前ロード
ISAPI フィルターとエクステンション
Read-raw 通知は無くなっている
メタベースアクセスのWMI/ABO/ADSI 互換性
ABO マッパーによる互換性
互換性を提供する:
スクリプト
コマンドラインツール
ABOへの直接呼び出し
IIS6
ADSI Script
デフォルトではインストールされない
IIS6ができることが限界
新しいIISプロパティの読み書きはできない
アプリケーションプール: managedPipelineMode,
managedRuntimeVersion
リクエストフィルタリング
フェールドリクエストトレーシング
ASP.NETプロパティの読み書きはできない
web.config ファイルの読み書きはできない
新しい実行時データにはアクセスできない
例）ワーカープロセス、実行中のリクエストの状態情報
IISADMIN
ABOMapper
applicationHost.config
統合された ASP.NET への移行
早いタイミングでリクエストを処理するモジュー
ルに注意する
モジュールにおける “managedHandler” プリ
コンディションは 「 ASP.NETのリクエストのみ
で実行する 」という意味
デフォルトインストールでは互換性・パフォーマンス
のため、プリコンディションはオンになっている
ハンドラーとモジュールは移動する
system.web/httpHandlers
=> system.webServer\handlers
system.web/httpModules
=> system.webServer\modules
applicationHost.configを複製する
全アプリケーションプールのリサイクルが起こるケース
アプリケーションプール共通のデフォルトセッティングが変更される
<globalModules> リストへの変更
特定のアプリケーションプールのリサイクルが起こるケース
特定アプリケーションプール固有のセッティング変更
RSA マシン暗号化（デフォルト）のみ使用し、RSAマシンキー
を複製する
http://msdn2.microsoft.com/en-us/library/yxw286t2(VS.80).aspx
特に注意する注意点:
マシン特定のデータ、IPアドレスとかドライブレター
同じモジュールのセットがインストールされている必要がある
存在しないモジュールの<globalModules>内での参照は 503エラー
その他 Tips
Configuration:
Configのロックダウンポリシーは事前に決めよう．．．
まずは慎重に保守的にポリシーを設定しよう
必要に応じてロックを外すようにした方がいい
後にロックをかけようとするとアプリへの影響がその時点で出る
Configuration：
IISマネージャーを使う、アプリ発行するエンドユーザー
を教育しよう．．．
起こりうるシナリオ:
ユーザーがアプリケーションを発行する
IISマネージャーを使ってユーザーが web.config を変更する
ユーザーが更新された web.config をローカルのアプリケー
ションにコピー
数日後、ユーザーがアプリケーションを再発行する
** IIS マネージャーでの変更をユーザーは忘れがち**
その他 Tips
Setup：
できる限りルールを決めて同じセットのモ
ジュールをインストールする．．．
これによって下記を防げる:
503 “Service Unavailable”
[モジュールは有効化されようとしているが肝心
のモジュールがない]
アプリケーションが期待通り動作しない
[web.config がインストールされていないモ
ジュールを参照する]
[カスタムで作成したモジュールとの機能競合に
よる期待外の結果]
パフォーマンスに関して
IIS7はWebサーバー ＝ アプリプラットフォーム
アプリケーション構成の影響が大きい
カスタムモジュールの有無、実行順序
故に一概に何％とは言えない、でもIIS6以上目標
Vista と Longhorn Server という観点
Vista でも ストレス試験は実施
Longhorn Server は試験の合格点を高いレベルに
設定している
CPU高負荷 連続状況や同時実行の過負荷試験
全体パフォーマンス調整
Vista は開発環境、軽装な環境での利用という想定
LHSは企業の本番Webサーバーという想定
IISパイプラインの詳細比較
新トレースアーキテクチャー
IIS6のリクエストパイプライン
w3wp.exe
aspnet_isapi.dll
handlers
cgi
w3svc
static
file
Isapi
exts
IHttpModule Events
url map
determine handler
begin req
logging
auth’c req
custom errors
auth’z req
compression
resolve cache
end req
authentication
handler map
update req cache
handler exec
rel req state
ISAPI Filter Notifications
url map
auth’c req
log
IHttpHandlers
Pre-proc headers End net session
Trace.axd
http.sys
PageHandler
IIS7のリクエストパイプライン
Native Handler
static file
IHttpHandler
isapi ext
Native Module
*.aspx
end
trace.axd
IHttpModule
log
was
update cache
native modules
release state
managed modules
execute handler
pre-execute handler
basic auth
digest auth
windows auth
acquire state
map handler
resolve cache
authorize
authenticate
begin
http.sys
url auth’z
role mgr
forms auth
新トレース アーキテクチャー
柔軟性高い トレース インフラ
各々独立した格納: トレースイベントの
コンシューマは単にモジュール
ETW
Automatic Failure Req Tracing (FREB)
フレキシブル: 新しい格納フォーマットが
必要になる都度、新しいモジュールを追
加
トレース
イベント
ソース
w3core
どのように動作するか...
GL_TRACE_EVENTにモジュールが
登録する
コンシューマがトレースコンフィグレー
ションを渡す
パイプライン上のモジュールがコンフィ
グレーションを読み込む
パイプライン上のモジュールがトレース
イベントを発生させる
イベントがコンシューマに届けられる
コンシューマがイベントをハンドルする
この図式の中でインフラ系のイベントが
共通的に発生される
IIS7 出荷までに300以上を予定
いずれかの
module
パイプライ
ン上のモ
ジュール
トレース
コンフィグ
読み込み
トレース
イベント
プロバイダー/
コンシューマー
コンシューマ
モジュール
TRACE_EVENT
(etw, freb
etc.)
Trace
config
任意の
トレース
出力書式
© 2006 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
© Copyright 2024 ExpyDoc
