運用管理手順ガイド 運用管理手順ガイド 検証環境のシステム構成と考慮点 メンテナンス手法 バッチ適用手順 システム構成概要 システム構成の概要 – – WEBシステムを前提とし、イントラネット、およびエクストラネット経由によるユーザからのアクセス を想定 システム全体の可用性を高めるために、単一障害点（SPOF：Single Point of Failure）を可能な 限り排除する 信頼性・高可用性 – 単一障害点を排除するため、ネットワーク層、ハードウェア層、ソフトウェア層は可能な限り冗長構 成をとる 負荷分散方式 – Web Farmレイヤ (Webサーバ/APサーバー/リバースプロキシサーバ)は、NLB構成により負荷 分散を行う ネットワーク構成 – ネットワークのセグメント分割は行わない（DMZは構成しない） • DB層では、パケットフィルターを設定して、不必要なパケットは受け付けないように設定する セキュリティ – 認証方式 • イントラネットからのユーザーのアクセスはドメインによるシングルサイン方式とし、エクストラ ネットからのユーザーアクセスはプロキシサーバー（ISA）を経由したフォーム認証方式とする アプリケーション – 階層モデルは、物理 2階層（WEB/AP, DB）、論理 3階層（Web, Biz Logic(DAC), DB） 3 検証環境 システム構成図 インターネット経由 アクセスを想定 リバースプロキ シサーバ ( ISA ) Client 1 イントラ経由 アクセスを想定 ディレクトリサーバ Web Server + AP Server ( AD ) ( IIS + .NET ) Client 2 （SSL） Switching Hub 1G bps 1G bps （ウィットネス） （ミラー）（プリンシパル） FC 2G FC Switch FC 2G FC Switch システム監視サーバ ( MOM ) ステートサーバ/ MOM DB （SQL Server） FC 2G FC Switch DB Server ( SQL Server ) MSCS or DBM サーバの冗長化について サーバ種別 製品/機能 冗長化手法 ディレクトリサーバ AD レプリケーションによる多重化 リバースプロキシサーバ ISA NLBによる多重化 Web + AP サーバ IIS / .NET NLBによる多重化 監視サーバ MOM 管理サーバを2台構成にする多重化 ステートサーバ (*1) SQL Server MSCSによる多重化 DB サーバ (*2) SQL Server MSCSによる多重化 DBM による多重化 (*3) (*1) ステートサーバは下記の用途として使用した －IISのセッション情報の保持 －MOM (監視ツール) の情報保持 このサーバ障害発生時にはWEBサーバー（IIS）が動作不能となるため、クリティカル度が高くなる そのためMSCSによる多重化を行った (*2) DBサーバの冗長化に関しては、MSCS / DBM の2つの手法が考えられるが、両者構築を行い検証を行った (*3) DBMに関しては、「高可用性モード」 (同期で、Witnessサーバによる自動フェールオーバをする構成) を 使用した ネットワークの冗長化について ネットワークの冗長化 – ケーブルやポートの障害に備えて経路の冗長化を行い、ハブ、NIC等の機器故障に備えて機器自体 を冗長構成とする • • スパニング・ツリー機能を備えたLANスイッチ 2つのNICを用いたチーミング機能（同一IP） 注意事項 ループを回避するためにスパニング・ツリー機能を備えたLANスイッチが必要 NICチーミングの利用可否については、機器及び提供されているドライバに依存する NLBやMSCS等でネットワークの冗長化を図る場合には、制限事項や制約に注意 • 次ページ参照 ケーブルやNICなど経路 における障害発生 サーバーA NIC NICチーミング （同一IP） LANスイッチ NIC LANスイッチ – – – NICチーミング （同一IP） サーバーB NIC NIC スイッチの故障など、ネッ トワークのダウン 6 ネットワークの冗長化について ネットワークの冗長化手法としては基本的にはTeamingを使用した – 制限事項が製品によってあるので、下記にまとめる ネットワーク NICの多重化 AD NIC 2枚による Teaming IIS + NLB NIC 2枚によるTeaming MOM NIC 2枚によるTeaming IIS + ISA SQL:MSCS SQL:DBM 各種設定 マルチキャストモード External NICの多重化なし ユニキャストモード Internal NICの多重化なし ユニキャストモード Public NIC 2枚による Teaming 全ての通信(混合ネットワーク) Private NIC 2枚 個別動作（別IP） 内部通信のみ 内部通信のみ(ハートビートのみ)の場合、 NICはTeaming不可) NIC 2枚による Teaming DBMのネットワーク構成は次ページ DBMのネットワーク構成に関して DBM 「高可用性モード」(同期でWitnessサーバを使用し自動フェールオーバをする構成) の場合、下記2つのネットワーク構成が可能。 ・ Principal / Mirror / WitnessをPublic ネットワーク上に構成 Public Principal サーバのPublicネットワーク障害 を検知し、Mirror サーバにフェールオーバする Principal Mirror Witness ・ Principal/Mirror/Witness間でPING専用のPrivate ネットワークを構成 Public Principal Mirror Principal サーバのPublicネットワーク障害時も、 Principal/Mirror/Witness間でPING通信ができる ため、障害を検知できずフェールオーバしない Witness 今回の検証環境では、「 Principal / Mirror / WitnessをPublic ネットワーク上に構成」 を使用。NICに関しては3サーバ共にTeamingを使用した。 認証方式について イントラネットアクセス認証は、クライアントによるドメインへのログイン（シングルサインオン） エクストラネットアクセス認証は、フォームによる認証（ドメインへの認証）とする IISへのアクセスには、ADによる事前認証方式とし、IISにて偽装を行いDBへ特定のログインにてアクセスす る SQL Serverの認証はSQL Server認証 (ユーザ名/パスワードを使用) 本方式採用の根拠（有用点、留意事項） – – アプリケーション層からデータベースへのアクセスに、セッションプルーリングが利用可能なため、データベース接続の時 間短縮が図れる • セッションプールは、同一の接続（接続文字列）単位に、プーリングが行われるため、データベースへのアクセスは グルーピング化する必要がある 厳密な監査証跡が困難である • アプリケーション層にて偽装を行うため、データベースにおけるユーザー毎の監査証跡を取得することが出来ない フォーム認証 ドメインへのログイン Client ISA AD IIS ドメイン認証方式 ドメインへのログイン シングルサインオン SQL SQL認証 各種設定 ( 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\iis setspn –a HTTP/192.168.0.100 plopt\iis • 今回は下記を設定 (NLB Serverのサーバ名とIP Addressを設定) – 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 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\iis setspn –a HTTP/192.168.0.100 plopt\iis 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 各種設定 (ISA + NLB ) ISAのNLB統合モード – ユニキャストモード – アフィニティ単一 – Teamingなし • ISA Server の NLB 統合モードでは、ユニキャスト モードが利用されることも関 係し、Teaming を動作させた状態で、ISA Server 上から NLB を構成すること はできなかった • ISA 2台構成でNLB統合モードを利用しているため、負荷クライアント1台からの 負荷はいずれか1台に固定される 構成保管サーバの場所 – 各ノード上のローカルADAM ログファイルの保管場所 – ローカルのMSDEデータベース Web公開ルール – 「ISA Serverコンピュータからの要求にする」 サーバファームとして内部の3台のIISを指定 各種設定 (MSCS) Public Network – 全ての通信 (混合ネットワーク) ⇒ Public Networkでもハートビートを行う様な設定を使用 – ネットワークカードのTeamingを利用 Private Network – 内部クラスタ通信のみ – Private NetworkのTeamingはサポートしていない – Private Network用にネットワークカードを2枚用意し、別IPを振ることにより ネットワークカードの多重化を行った ハードウェアスペック 用途 ハードウェアスペック AD Pentium D 3.0GHz, 2GB RAM Windows Server 2003 R2 Enterprise Edition ISA+NLB Pentium D 3.0GHz, 2GB RAM Windows Server 2003 Enterprise Edition 、ISA Server 2006 IIS+NLB Pentium D 3.0GHz, 2GB RAM Windows Server 2003 R2 Enterprise Edition MOM Xeon 3.4GHz x2, 4GB RAM SQL-DBM-Witness (*1) Xeon 3.4GHz x2, 4GB RAM SQL-DBM (*2) Opteron 270 2.0GHz x2, 8GB RAM SQL-MSCS (*3) Opteron 875 2.2GHz x4, 16GB RAM STATEサーバ Opteron 270 2.0GHz x2, 8GB RAM 負荷用サーバ (*4) Opteron 280 2.4GHz x2, 8GB RAM DB用ストレージ(SAN) ソフトウェア Windows Server 2003 R2 Enterprise Edition , SQL Server 2005 SP1, Operation Manager 2005 Windows Server 2003 R2 Enterprise Edition , SQL Server 2005 SP1 Windows Server 2003 R2 Enterprise Edition x64 , SQL Server 2005 SP1 Windows Server 2003 R2 Enterprise Edition x64, SQL Server 2005 SP1 Windows Server 2003 R2 Enterprise Edition x64, SQL Server 2005 SP1 Windows Server 2003 R2 Enterprise Edition, Visual Studio 2005 Team Suite HOST Interface 2Gb/s Fiber Channel // コントローラキャッシュ256MB // RAID0+1 (*1,*2) SQLでのDBM構成は、PrincipalとMirrorサーバは同一スペック。Witnessサーバは異なるスペックで構成した (*2,*3) SQL DBMとSQL MSCSのサーバのスペックは同一の物を使用したかったが、テスト環境の都合上、 異なるスペック(MSCSの方が若干良いスペック)となっている (*4) トランザクションの負荷はクライアントマシンを多数使用するのではなく、スペックの良いサーバマシンで セッションを多数挙げる事で負荷をかけた 検証アプリケーションの方式 アプリケーション – .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 Data Access Components Database 考慮点（アプリケーション構成・方式） 階層モデル（物理・論理の階層モデル） – 本検証では、マイクロソフトの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へアクセスが可能だが、レスポンス的にコストペナルティ が高い） – 性能拡張方式はスケールアップ方式のみ 検証アプリケーション Webアプリケーション 画面遷移 TOP画面（Default.aspx） （自身のプロファイルを表示） ログイン イントラネット経由） シングル サインオン ログインしたユーザの プロファイルを表示 休暇申請画面（Vacation.aspx） エクストラネット経由） フォーム認証 部下を持つユーザが ログインした場合には、 [Enabled]となる 取得可能な休暇時間を表示 休暇申請処理の実行 （プロシージャの実行） 配下のスタッフ一覧 （SELECTクエリの実行） 部下一覧表示画面 （MemberList.aspx） 18 検証アプリケーション シーケンス図 検索テストパターン TOP画面 表示 （ログイン認証） スタッフ情報の取得（SELECT） MemberList.aspx 休暇申請ボタンの押下 繰り返し DAC（AP SV） 部下一覧表示画面 出力 DB HumanResources Web Default.aspx Test Client 検証期間 更新テストパターン TOP画面 表示 （ログイン認証） 取得可能な休暇時間の表示 繰り返し DAC（DB） 休暇取得可能時間の取得 （SELECT） Vacation.aspx 休暇申請ボタンの押下 DAC（AP SV） 休暇申請（休暇取得時間の入力） 申請結果の表示 （申請受付時間の表示） DB HumanResources Web Default.aspx Test Client 休暇申請処理 （UPDATE） 検証期間 検証アプリケーション テーブルスキーマ SQL Server 2005 サンプルデータベース 「 AdventureWorks 」 の一部を利用 20 アプリケーションの実行 VSTS (Visual Studio Team Suite)のWebテスト /負荷テスト 機能を使用 – Webテスト等のテストシナリオに対し、同時実行ユーザー数 や実行環境を詳細に設定することが可能 – テストの実施状況をリアルタイムに確認可能 耐障害テスト結果 製品コンポーネント テストパターン（大項目） テスト項目 システム停止時間 Active Directory H/W障害 OS障害 ネットワーク障害 H/W障害 OS障害 ネットワーク障害 (External) ネットワーク障害 (Internal) H/W障害 OS障害 ネットワーク障害 H/W障害 OS障害 ネットワーク障害 H/W障害 OS障害 ネットワーク障害 H/W障害 OS障害 ネットワーク障害(プライベート) ネットワーク障害(パブリック) H/W障害 OS障害 ネットワーク障害(プライベート) ネットワーク障害(パブリック) H/W障害 OS障害 ネットワーク障害 H/W障害 OS障害 ネットワーク障害 H/W障害 OS障害 ネットワーク障害 サーバーシャットダウン（強制電源断） ブルースクリーン NIC障害 (Teamingあり) サーバーシャットダウン（強制電源断） ブルースクリーン NIC障害(Teamingなし) NIC障害（Teamingなし） サーバーシャットダウン（強制電源断） ブルースクリーン NIC障害(Teaming あり) サーバーシャットダウン（強制電源断） ブルースクリーン NIC障害(Teamingあり) サーバーシャットダウン（強制電源断） ブルースクリーン NIC障害(Teamingあり) サーバーシャットダウン（強制電源断） ブルースクリーン NIC障害(Teamingなし) NIC障害(Teamingあり) サーバーシャットダウン（強制電源断） ブルースクリーン NIC障害(Teamingなし) NIC障害(Teamingあり) サーバーシャットダウン（強制電源断） ブルースクリーン NIC障害（Teamingあり） サーバーシャットダウン（強制電源断） ブルースクリーン NIC障害（Teamingあり） サーバーシャットダウン（強制電源断） ブルースクリーン NIC障害（Teamingあり） なし なし なし 5～10秒の間 5～10秒の間 5秒以内 5秒以内 5～10秒の間 5～10秒の間 なし 5～10秒の間 5～10秒の間 なし なし なし なし 48秒 47秒 なし なし 47秒 48秒 なし なし 8秒 9秒 なし なし なし なし なし なし なし ISA IIS IIS(ISA 経由) MOM State Server SQL Server (MSCS) SQL Server (DBM-P) SQL Server (DBM-M) SQL Server (DBM-W)
© Copyright 2024 ExpyDoc
