運用管理手順ガイド

1. 運用管理手順ガイド

2. 運用管理手順ガイド • 検証環境のシステム構成と考慮点 • メンテナンス手法 • バッチ適用手順

3. システム構成概要 • システム構成の概要 • WEBシステムを前提とし、イントラネット、およびエクストラネット経由によるユーザからのアクセスを想定 • システム全体の可用性を高めるために、単一障害点（SPOF：Single Point of Failure）を可能な限り排除する • 信頼性・高可用性 • 単一障害点を排除するため、ネットワーク層、ハードウェア層、ソフトウェア層は可能な限り冗長構成をとる • 負荷分散方式 • WebFarmレイヤ　(Webサーバ/APサーバー/リバースプロキシサーバ)は、NLB構成により負荷分散を行う • ネットワーク構成 • ネットワークのセグメント分割は行わない（DMZは構成しない） • DB層では、パケットフィルターを設定して、不必要なパケットは受け付けないように設定する • セキュリティ • 認証方式 • イントラネットからのユーザーのアクセスはドメインによるシングルサイン方式とし、エクストラネットからのユーザーアクセスはプロキシサーバー（ISA）を経由したフォーム認証方式とする • アプリケーション • 階層モデルは、物理 2階層（WEB/AP, DB）、論理 3階層（Web, Biz Logic(DAC), DB）

4. 検証環境 システム構成図 ディレクトリサーバ ( AD ) Web Server + AP Server ( IIS + .NET ) インターネット経由アクセスを想定 リバースプロキシサーバ( ISA ) イントラ経由アクセスを想定 Client 1 Client 2 （SSL） Switching Hub 1G bps 1G bps （ウィットネス） （ミラー） （プリンシパル） FC 2G FC 2G FC 2G FC Switch FC Switch FC Switch システム監視サーバ ( MOM ) ステートサーバ/ MOM DB（SQL Server） DB Server ( SQL Server ) MSCS or DBM

5. サーバの冗長化について (*1) ステートサーバは下記の用途として使用した －IISのセッション情報の保持 －MOM (監視ツール) の情報保持 このサーバ障害発生時にはWEBサーバー（IIS）が動作不能となるため、クリティカル度が高くなる 　　　 そのためMSCSによる多重化を行った (*2) DBサーバの冗長化に関しては、MSCS / DBM の2つの手法が考えられるが、両者構築を行い検証を行った (*3) DBMに関しては、「高可用性モード」 (同期で、Witnessサーバによる自動フェールオーバをする構成) を 　　　 使用した

6. ネットワークの冗長化について • ネットワークの冗長化 • ケーブルやポートの障害に備えて経路の冗長化を行い、ハブ、NIC等の機器故障に備えて機器自体を冗長構成とする • スパニング・ツリー機能を備えたLANスイッチ • 2つのNICを用いたチーミング機能（同一IP） • 注意事項 • ループを回避するためにスパニング・ツリー機能を備えたLANスイッチが必要 • NICチーミングの利用可否については、機器及び提供されているドライバに依存する • NLBやMSCS等でネットワークの冗長化を図る場合には、制限事項や制約に注意 • 次ページ参照 ケーブルやNICなど経路における障害発生 サーバーA LANスイッチ LANスイッチ NIC NICチーミング（同一IP） NIC サーバーB NICチーミング（同一IP） NIC NIC スイッチの故障など、ネットワークのダウン

7. ネットワークの冗長化について • ネットワークの冗長化手法としては基本的にはTeamingを使用した • 制限事項が製品によってあるので、下記にまとめる

8. DBMのネットワーク構成に関して DBM　「高可用性モード」(同期でWitnessサーバを使用し自動フェールオーバをする構成) の場合、下記2つのネットワーク構成が可能。 ・　Principal / Mirror / WitnessをPublic ネットワーク上に構成 Public Principal サーバのPublicネットワーク障害 を検知し、Mirror サーバにフェールオーバする Principal Mirror Witness ・　Principal/Mirror/Witness間でPING専用のPrivate ネットワークを構成 Public Principal サーバのPublicネットワーク障害時も、 Principal/Mirror/Witness間でPING通信ができる ため、障害を検知できずフェールオーバしない Principal Mirror Witness 今回の検証環境では、「 Principal / Mirror / WitnessをPublic ネットワーク上に構成」 を使用。NICに関しては3サーバ共にTeamingを使用した。

9. 認証方式について • イントラネットアクセス認証は、クライアントによるドメインへのログイン（シングルサインオン） • エクストラネットアクセス認証は、フォームによる認証（ドメインへの認証）とする • IISへのアクセスには、ADによる事前認証方式とし、IISにて偽装を行いDBへ特定のログインにてアクセスする • SQL Serverの認証はSQL Server認証 (ユーザ名/パスワードを使用) • 本方式採用の根拠（有用点、留意事項） • アプリケーション層からデータベースへのアクセスに、セッションプルーリングが利用可能なため、データベース接続の時間短縮が図れる • セッションプールは、同一の接続（接続文字列）単位に、プーリングが行われるため、データベースへのアクセスはグルーピング化する必要がある • 厳密な監査証跡が困難である • アプリケーション層にて偽装を行うため、データベースにおけるユーザー毎の監査証跡を取得することが出来ない フォーム認証ドメインへのログイン ISA AD Client IIS SQL ドメイン認証方式 SQL認証 ドメインへのログインシングルサインオン

10. 各種設定　　 ( IIS + NLB ) • マルチキャストモード　& NIC Teaming • アフィニティなし • HTTP Keep-Alive 無効　(デフォルトは有効) • 今回は同一サーバでVSTSが同一セッションを使いまわす設定をしていたので、Keep-Aliveが有効だと、NLB上負荷分散できなかった • 後の調査により、VSTSでも複数のセッションを一連のテスト毎に使う設定ができる事が判明。この設定を使えば、Keep-Aliveを有効でもNLBで負荷分散が可能。 • NTLM認証 (Keep-AliveがONでないと通らない) 　が通らなかったので、Kerberos 認証を使用 • Support Tools に含まれる SetSPN を実行して、利用するドメイン アカウントに Service Principal Name を登録するsetspn -a HTTP/仮想サーバー名　ドメイン名\実行アカウント名例setspn –a HTTP/web.platform.com plopt\iissetspn –a HTTP/192.168.0.100 plopt\iis • 今回は下記を設定 (NLB Serverのサーバ名とIPAddressを設定) • HTTP/iis01.platform.com • HTTP/iis02.platform.com • HTTP/iis03.platform.com • HTTP/192.168.100.5 • HTTP/192.168.100.6 • HTTP/192.168.100.7 • HTTP/192.168.100.50

11. IIS NLB 環境下での認証方式の注意点 • 認証方式の注意 • Keep-Alive の設定 • 統合 Windows 認証のうち NTLM 認証では IIS の Keep-Alive が必須　http://support.microsoft.com/kb/286128/ja • 統合 Windows 認証のうち Kerberos 認証では IIS の Keep-Alive が必須ではない • Kerberos 認証を無効にする • Kerberos 認証を無効にして、統合 Windows 認証では NTLM しか使わないようにするには、下記コマンドを実行 • cscript adsutil.vbs set w3svc/NTAuthenticationProviders "NTLM“http://support.microsoft.com/kb/215383 • Kerberos 認証をサーバー名以外で利用する • 仮想 IP アドレス、占有 IP アドレス、仮想 サーバー名などでも Kerberos 認証を利用したい場合には、下記の手順が必要 • IIS ワーカ プロセスの実行アカウントにドメイン アカウントを利用する（ワーカ プロセスにドメイン カウントを利用するためには、各サーバーのローカル グループ IIS_WPG に当該アカウントを追加しておく必要もある） • Support Tools に含まれる SetSPN を実行して、利用するドメイン アカウントに Service Principal Name を登録するsetspn -a HTTP/仮想サーバー名　ドメイン名\実行アカウント名例setspn –a HTTP/web.platform.com plopt\iissetspn –a HTTP/192.168.0.100 plopt\iis

12. NLBを構成した場合のasp.netの構成ファイルの設定NLBを構成した場合のasp.netの構成ファイルの設定 • ASP.NETが生成するViewStateは暗号鍵付きのハッシュ値でサーバー側で暗号化されている • 第三者による改竄を防止するため • NLBを構成した場合、デフォルトでは暗号鍵がそれぞれ異なるため負荷分散すると(あるセッションが別のサーバーにアクセスすると)エラーが発生する • これを防止するため、各サーバーの暗号化鍵をそろえる必要がある • machine.congif (サーバー全体)、web.config(単一サイトのみ）に記述する • 暗号鍵は厳密に管理する必要があるため、macine.configへの記述を推奨 • 記述例 <configuration>  <system.web>    <machineKey validationKey="08CE6B478DCE73……(中略) ……E566D8AC5D1C045BA60“                decryptionKey=”4252D6B2268……(中略) ……67F451CE65D0F2ABE9BCD3A"                validation="SHA1"/>  </system.web></configuration> 参考 .NETエンタープライズ Webアプリケーション開発技術大全 Webアプリケーションの状態管理 http://www.atmarkit.co.jp/fdotnet/entwebapp/entwebapp03/entwebapp03_03.html

13. 各種設定　 (ISA + NLB ) • ISAのNLB統合モード　 • ユニキャストモード • アフィニティ単一 • Teamingなし • ISA Server の NLB 統合モードでは、ユニキャスト モードが利用されることも関係し、Teaming を動作させた状態で、ISA Server 上から NLB を構成することはできなかった • ISA 2台構成でNLB統合モードを利用しているため、負荷クライアント1台からの負荷はいずれか1台に固定される • 構成保管サーバの場所 • 各ノード上のローカルADAM • ログファイルの保管場所　　 • ローカルのMSDEデータベース　 • Web公開ルール　 • 「ISA Serverコンピュータからの要求にする」　 • サーバファームとして内部の3台のIISを指定

14. 各種設定　(MSCS) • Public Network • 全ての通信 (混合ネットワーク) ⇒ Public Networkでもハートビートを行う様な設定を使用 • ネットワークカードのTeamingを利用 • Private Network • 内部クラスタ通信のみ • Private NetworkのTeamingはサポートしていない • Private Network用にネットワークカードを2枚用意し、別IPを振ることによりネットワークカードの多重化を行った

15. ハードウェアスペック (*1,*2) SQLでのDBM構成は、PrincipalとMirrorサーバは同一スペック。Witnessサーバは異なるスペックで構成した (*2,*3) SQL DBMとSQL MSCSのサーバのスペックは同一の物を使用したかったが、テスト環境の都合上、 　　　 　　異なるスペック(MSCSの方が若干良いスペック)となっている (*4) トランザクションの負荷はクライアントマシンを多数使用するのではなく、スペックの良いサーバマシンで セッションを多数挙げる事で負荷をかけた

16. 検証アプリケーションの方式 • アプリケーション • .NET Framework 2.0 を利用した、シンプルなWebアプリケーションを作成 • プレゼンテーション層、データアクセス層は、コンポーネントを分離 • データアクセス層の実装は、アプリケーションサーバ層、DB層（ストアド）の2通りに配置 AP層、およびストアドプロシージャにて、データアクセスロジックを実装する方式 Web / AP Server（IIS） Presentation Layer ASP.NET Web Form Dataset Data Access Layer Data Access Components Database Data Access Components

17. 考慮点（アプリケーション構成・方式） • 階層モデル（物理・論理の階層モデル） • 本検証では、マイクロソフトのWebシステムの定石的アプローチである以下のモデルを採用 • 物理2階層（WEB/AP、DB）：論理3階層（WEB、Biz Logic、DB） • ティアによる分割：物理階層を2階層（WEB/AP, DB）とするメリット • スケーラビリティ、可用性、保守性、セキュリティ、管理容易性、パフォーマンス • レイアによる分割：論理階層を3階層（WEB(VIEW), Bizlogic, DB）とするメリット • 保守性、再利用性、チーム開発（アプリケーション開発の分業化） • DAC(データアクセスロジック・コンポーネント）の配置、実装 • DAC層をどのレイアに展開・配置を行うかは、双方のパターンについてメリット・デメリットのトレードオフを検討する必要がある • DACをアプリケーション層に実装する場合 • メリット： • 複数のデータベースへのアクセスを行い、結果セットの加工が可能 • 処理負荷の高いデータアクセスロジックを複数サーバーに分散配置が可能 • デメリット： • 管理の複雑さ（バージョン管理、コンポーネントの展開・配置） • DACをデータベースに内包する • メリット： • セキュリティやアプリケーション開発の側面から、アプリケーション開発者にスキーマなどDBオブジェクトを隠ぺい化できる • デメリット • 基本的には自身のDBのみのアクセスが可能（リンクサーバー等を利用してたDBへアクセスが可能だが、レスポンス的にコストペナルティが高い） • 性能拡張方式はスケールアップ方式のみ

18. 検証アプリケーション　Webアプリケーション 画面遷移 TOP画面（Default.aspx） （自身のプロファイルを表示） ログイン ログインしたユーザのプロファイルを表示 イントラネット経由）シングル サインオン 休暇申請画面（Vacation.aspx） エクストラネット経由） フォーム認証 部下を持つユーザがログインした場合には、[Enabled]となる 取得可能な休暇時間を表示 休暇申請処理の実行（プロシージャの実行） 配下のスタッフ一覧（SELECTクエリの実行） 部下一覧表示画面（MemberList.aspx）

19. 検証アプリケーション 　シーケンス図 検索テストパターン Test Client Web DAC（APSV） DB Default.aspx TOP画面 表示（ログイン認証） 休暇申請ボタンの押下 スタッフ情報の取得（SELECT） 検証期間 HumanResources MemberList.aspx 部下一覧表示画面 出力 繰り返し 更新テストパターン Test Client Web DAC（APSV） DAC（DB） DB Default.aspx TOP画面 表示（ログイン認証） 休暇取得可能時間の取得（SELECT） 休暇申請ボタンの押下 検証期間 取得可能な休暇時間の表示 HumanResources Vacation.aspx 休暇申請（休暇取得時間の入力） 繰り返し 申請結果の表示（申請受付時間の表示） 休暇申請処理（UPDATE）

20. 検証アプリケーション　　テーブルスキーマ　検証アプリケーション　　テーブルスキーマ　 • SQL Server 2005 サンプルデータベース「 AdventureWorks 」の一部を利用

21. アプリケーションの実行 • VSTS (Visual Studio Team Suite)のWebテスト /負荷テスト機能を使用 • Webテスト等のテストシナリオに対し、同時実行ユーザー数や実行環境を詳細に設定することが可能 • テストの実施状況をリアルタイムに確認可能

22. 耐障害テスト結果