クラウド時代のWebSphere自動化・標準化 1 日本アイ・ビー・エム システムズ・エンジニアリング株式会社 Webシステム基盤
by user
Comments
Transcript
クラウド時代のWebSphere自動化・標準化 1 日本アイ・ビー・エム システムズ・エンジニアリング株式会社 Webシステム基盤
WebSphere Cloud Solution ワークショップ クラウド時代のWebSphere自動化・標準化 日本アイ・ビー・エム システムズ・エンジニアリング株式会社 Webシステム基盤 山口 崇 [email protected] © 2010 IBM Corporation 1 WebSphere Cloud Solution ワークショップ Disclaimer 2 この資料は日本アイ・ビー・エム株式会社ならびに 日本アイ・ビー・エム システムズ・エンジニアリング株式会社の正式な レビューを受けておりません。 当資料は、資料内で説明されている製品の仕様を保証するもので はありません。 資料の内容には正確を期するよう注意しておりますが、この資料の 内容は2010年7月現在の情報であり、製品の新しいリリース、PTF などによって動作、仕様が変わる可能性があるのでご注意下さい。 今後国内で提供されるリリース情報は、対応する発表レターなどで ご確認ください。 © 2010 IBM Corporation 2 WebSphere Cloud Solution ワークショップ 目次 3 §1. 自動化・標準化が求められる背景 §2. WAS環境における標準化 §3. WAS環境における自動化 §4. WAS自動化・標準化の例 §5. まとめ © 2010 IBM Corporation クラウド･コンピューティングを採用する企業の主な目的は、省力化によるコスト削減、 およびITのスピード化によるビジネス環境の変化への柔軟な対応です。 WebSphere Application Server（WAS）のようなアプリケーション･サーバーを使用 するシステム構築の際もそれは変わりません。 クラウドとそれに伴う技術がこうした効果をもたらすことは確実です。とは言え、クラウ ド技術だけで必要な構成全てを完結することができないことも事実です。そこに ギャップが生じ、期待値ほどの効果が得られない可能性があります。 こうしたケースで必要となるのは、クラウド技術を補完する「自動化」と、自動化の指 針を提示する「標準化」です。これらのキーワードはクラウド･コンピューティングが広 まる以前から幾度も言われている、言わば使い古された用語なのですが、クラウド の普及に伴い再び重要度が増しています。 この章では、クラウド･コンピューティングの文脈において自動化および標準化が求 められるようになった背景から、WAS環境構築に際しての標準化、自動化の指針、 および関連技術に関して解説します。そして最後に標準化・自動化を行うために ISEで作成中のツール･アセットをご紹介します。 3 WebSphere Cloud Solution ワークショップ §1. 自動化・標準化が求められる背景 4 © 2010 IBM Corporation まず、この章でクラウド･コンピューティングがWASにもたらす影響を整理します。それら影響への 対処として自動化および標準化が求められるに至った背景を解説します。 4 WebSphere Cloud Solution ワークショップ クラウド･コンピューティングとWAS クラウド・コンピューティングの定義 インターネット技術を元に、コンピューター･リソースを「サービス」として提供する処理形態 いくつかの付随的な特徴 仮想化技術の活用／柔軟性(elasticity) ／従量課金／セルフサービス・ポー タル／所有から使用へ／提供スピードの迅速化・・・ クラウド選択のフロー Public SaaS 要件に合う 要件に合う サービスがない サービスがない 5 Private PaaS セキュリティー要 セキュリティー要 件を満たさない 件を満たさない IaaS ネットワーク要件 ネットワーク要件 を満たさない を満たさない (SaaS) PaaS IaaS 要件に合う 要件に合う サービスがない サービスがない © 2010 IBM Corporation 前のセッションにもありましたが、改めてクラウド･コンピューティングの定義について 解説します。クラウドの定義は諸説ありますが、非常に大きな概念であるため、共通 する部分を抽出すると上記のようないささか曖昧な定義となってしまい、この資料を 読む方の期待する方向性が絞り込めないからです。 絞込みのためには、十分条件ではないけれどもクラウドに付随する特徴が何か、と いうことを挙げていきます。仮想化技術を使用していることや、リクエストの増減に応 じてサーバーを随時追加できるような柔軟性の高さ、また使った分だけ払う従量課 金といった点が思いつく点です。クラウド・コンピューティング環境でWAS環境を構 築／運用する場合、こうした特徴に配慮し、従来と異なる設計や構築手順を考える 必要が出てきます。 また私見ながら、ある業務に対しクラウド・コンピューティングを適用しようとした場合 の選択のフローを下に挙げています。基本姿勢は「あるものをなるべく活用」する、 です。よって一番最初の候補はパブリック･クラウド上のSaaSになります。SaaSの サービスとしてシステム化したい業務に合致するものがあれば、積極的にそれを使 えばよいことになります。業務が特殊で対応するSaaSがない、または国内で要件 に合うサービスが提供されていないといった場合、PaaS、IaaSとレイヤーを下げて いきます。まだセキュリティーやネットワークなどの要件を満たさないようであれば、 プライベート･クラウドを構築することになります。プライベート･クラウドのバリエー ションは限定されると思いますが、PaaS、IaaSとなるべく出来合いのものを使えるよ うに選択を絞り込んでいきます。 WASはアプリケーション基盤を提供するミドルウェアなので、クラウド･コンピュー ティングではPaaSのレイヤーに相当するものになります。よってここでは、クラウド･ コンピューティング環境下でPaaSとしてWASを構築する際の考慮点を述べていき ます 5 WebSphere Cloud Solution ワークショップ クラウドがWASに与える影響：環境構築時 初期環境構築負荷の軽減 仮想イメージのコピーやプロビジョニング・ツールによってベースとなるWASの環境構築負荷が軽 減されるが、そのための設計および追加構成まで含めた簡易化を行わないと効果が限定される。 設計および追加構成負荷の軽減が必要 アプリケーション WAS構成定義 WAS PaaS IaaS OS ハイパーバイザー ハードウェア 簡易に設計をするための「システムの標準化」、追加設定が必要な作業の「自動化」 6 © 2010 IBM Corporation クラウド･コンピューティングがWASに与える影響は大きく分けて環境構築時と運用 時の二つに分けられます。それぞれにおいて、どういった良い方向の影響があり、 それに対して新たに考慮すべき点および対処法は何か、という観点でまとめて行き ます。 まず構築時ですが、クラウド･コンピューティング環境では環境構築の負荷は劇的 に改善されます。セルフ・サービス･ポータル画面から欲しいイメージを選択し、デ プロイするだけで数分後にはWASの入った環境が使えるようになります。 しかし、ここで提供される環境はWASの導入が済んでいるに過ぎないものです。そ の上で稼働するアプリケーションに必要な構成が済んでいるわけではありません。 例えばプロファイルを作ったり、サーバーを立てたりヒープサイズを調整したりといっ たWASの構成定義を追加で行わないことにはWAS環境として使用することが出来 ません。そして構成定義を行うためには、当然ながらその前段で正しく設計をする 作業が必要になります。 環境構築の途中までの負荷が軽減されることで得られるコスト削減効果も、本来は WASが使える環境まで設計され、設定されていないと限定的なものに留まります。 設計をスピーディーに行うためには「システムの標準化」を行う必要があり、構成定 義作業を「自動化」しておくことが重要になります。 6 WebSphere Cloud Solution ワークショップ クラウドがWASに与える影響：環境構築時 単体環境構築負荷の軽減 WASの単体環境の構築は実現できるが、クラスターなど複数台環境を意識したデプロイの仕組 みが必要となる。 複数台でのシステム構築負荷の軽減が必要 Cell Cluster Cluster WebSphere CloudBurst Appliance 複数台環境を一括で組み上げる「自動化」、複数担当者の作業をまとめる「手順の標準化」 7 © 2010 IBM Corporation もう一つの環境構築時の影響は、前項と同じく構築負荷の軽減ですが、ここでは何 台のマシンを構築するかと言う観点で見ていきます。通常WASのシステムは負荷 分散・高可用性を考慮し、複数台マシンでクラスター構成を組みます。 一方、クラウド・プロバイダーが提供するサービスでは、通常単体のマシンをデプロ イする形となるため、前項の構成定義と並行して、複数台のシステムでセルやクラス ターを組み上げる作業を行う必要があります。 他の章で紹介されている、WebSphere CloudBurst Appliance（WCA）という製品 を使えば、セル構成・クラスター構成を維持した形で一括デプロイすることが可能で す。しかしWCAがない環境や、パブリック･クラウドを使用するようなケースでは、複 数台環境の構築を行う「自動化」が必要になります。 またWAS環境を構築する場合、OS担当とミドルウェア基盤担当、アプリケーション 担当などの複数のチームを調整した上での設定作業が必要になります。そこでは 「システムの標準化」だけでなく、フィックスのバイナリーやログファイルを共有ディス クに配置するといった「手順の標準化」も重要になってきます。 7 WebSphere Cloud Solution ワークショップ クラウドがWASに与える影響：運用時 動的環境変更機会の増大 柔軟性が向上するため、クラスターに対するノード追加・削除などを行う機会が増えるが、その際 にサービスに対して与える影響を極小化しなくてはならない。 サービスへの影響の極小化が必要 Cell Cluster Cluster 変更時の設定作業をサービスへの影響を最小で行うための「自動化」 8 © 2010 IBM Corporation 続いてWAS運用時にクラウドが与える影響です。 クラウドの特徴としての柔軟性を考えると、これまであまり実運用でなされていな かったサービス途中でのクラスターメンバーの追加のような環境変更を行う機会が 増えてくると思われます。ただし、例えばクラスターに新しいサーバーを追加したい 場合、単に新しい仮想イメージを追加するだけでは不十分で、デプロイメント･マ ネージャー（DM）にノードを追加するaddNodeコマンドの実行、クラスター定義の 拡張（サーバーの追加）といった作業を行う必要があります。これらの変更はノード の追加だけでなく縮退の場合も考える必要があります。 そこで重要なのは、こうした作業が既に動いているサービスに対して与える影響を 極小化することです。極小化するためには作業時間短縮のための「自動化」が重要 になります。 8 WebSphere Cloud Solution ワークショップ クラウドがWASに与える影響：運用時 運用系新機能の活用 クラウド／仮想環境では、スナップショットやLPM ／vMotionなどの新機能を活用できるため、従 来のWAS環境でのバックアップやフェイルオーバーと設計の方法論が変わってくる。 高可用性設計の再考 Cell Cluster Cluster 新たな「システムの標準化」および「手順の標準化」 9 © 2010 IBM Corporation もう一点、クラウドがWAS運用に与える影響を考えると、クラウドの基盤となる仮想 化技術、特にバックアップやフェイルオーバーで使用できるようになる、新しい技術 の取り込みが挙げられます。 例えばPower VMでのLive Partition Mobility（LPM）機能やVMware環境での vMotion機能を使用したホット･フェイルオーバー、バックアップ代わりのVMwareス ナップショット機能などは、従来のWASシステムのバックアップやフェイルオーバー の設計とは異なる方法となるため、こうした新たな技術を盛り込んだ「システムの標 準化」と、運用等の「手順の標準化」が必要とされます。 9 WebSphere Cloud Solution ワークショップ クラウドがWASに与える影響への対処 構築時 初期環境構築負荷の軽減 設計および追加構成負荷の軽減が必要 単体環境構築負荷の軽減 複数台でのシステム構築負荷の軽減が必要 運用時 動的環境変更機会の増大 サービスへの影響の極小化が必要 運用系新機能の活用 高可用性設計の再考 「自動化」 10 「標準化」 © 2010 IBM Corporation ここまで見てきたように、クラウドによって得られる恩恵をより大きくし、導入効果を上 げるためには様々な局面での「自動化」、およびシステム・手順両面での「標準化」 が重要になることが分かりました。 次からの節ではその標準化・自動化をどのようにやっていくかを述べたいと思いま す。 10 WebSphere Cloud Solution ワークショップ §2. WAS環境における標準化 11 © 2010 IBM Corporation まずはWAS環境における標準化に関して解説します。 11 WebSphere Cloud Solution ワークショップ WASの標準化：①パラメーターの標準化 WASの構成において決めるべきパラメーター例 導入前 OS バージョン エディション 32/64bit 導入イメージ配置パス 導入 WAS導入パス 言語パック フィックス適用 Update Installer導入 パス FixPackレベル WAS導入パス 12 フィックス配置パス プロファイル作成 プロファイル･タイプ プロファイル名 プロファイル・ディレクト リー セル名 ノード名 サーバー名 ホスト名 管理セキュリティー On/Off ユーザー パスワード ポート サービス登録有無 addNode先DM名 サーバー構成 サーバー･タイプ ノード サーバー名 サーバー･テンプレート 固有ポートの使用有無 クラスター構成 クラスター名 セッション管理定義 クラスター･メンバー メンバー･ウェイト アプリケーション導入 Earロケーション アプリケーション名 デプロイ･ターゲット © 2010 IBM Corporation WAS環境の標準化というと、まずパラメーター設定を統一すると言うシステム的な 標準化を思い浮かべるかもしれません。しかし、前節で挙げてきたような課題に対 処するためには、システム構築のフローなどの手順の標準化というものも重要にな ります。この節ではそれら二つの側面から標準化について考察したいと思います。 まず、パラメーターの標準化です。WASのパラメーターと言うと、ざっと挙げても上 のように導入前から導入、フィックス適用、プロファイル作成・・・とたくさんのパラメー ターを設定する必要があります。言い換えると、これらのパラメーターを毎回決めて いると非常に時間とワークロードがかかり、クラウドの構築スピードに乗ることが出来 なくなります。 12 WebSphere Cloud Solution ワークショップ WASの標準化：①パラメーターの標準化 パラメーターは以下の三種類に分類される。 パラメーターは以下の三種類に分類される。 極力具体的な値にすることで、自動化が容易になる。 極力具体的な値にすることで、自動化が容易になる。 (A) 具体的な値が決まるもの (B) ルールに基づいて、システムごとに変数から値が決まるもの 例：ノード名は「<ホスト名>+Node+<2桁連番>」 例：データソースJNDI名は「jdbc/<データベース名>」 (C) 決定に際しての指針が提示されるもの 13 易 自動化 例：セッション･オーバーフローの許可はfalse 例：blockingReadConnectionTimeoutは60秒 例：大きなヒープサイズを使用する場合-Xgcpolicy:genconにし、スループットを優 先する場合-Xgcpolicy:optthruputとする 難 例：ヒープサイズは物理メモリー/トランザクション数/GCなどを勘案し決定する © 2010 IBM Corporation WAS構成パラメーターを標準化する際に、パラメーターを分類してみます。 まず、(A)の具体的な値が決まるものは、パラメーター項目に対し、絶対的な値が一 つ定まるようなケースです。例としていくつか挙げていますが、boolean型で true/falseが明白に決まるものや、どんな環境でも一律で適用するべきセキュリ ティー対策系のパラメーターなどが相当します。続いてあるのが、(B)のノード名や データソース名といった、システムごとに異なる値だが何らかのネーミングルールを もとに決まるものがあります。これは変数を与えてあげれば一律に決まると言う意味 で、設定が難しいものではありません。最後にあるのが(C) で、環境に応じての指 針が与えられているものです。2GB以上のヒープサイズの場合genconのGCポリ シーが望ましいと言った、変動要素が大きく人間の判断を必要とするものがこれに 相当します。 自動化を考えると、(A)・(B)が自動化のためには望ましいのですが、実際のところは (C)のパラメーターも多くあります。こうした各システムごとに判断が必要になるもの を極力少なくすることが標準化では重要になります。 13 WebSphere Cloud Solution ワークショップ WASの標準化：①パラメーターの標準化 パターン化 The Standard Standard A 追加 構成 追加 構成 追加 構成 追加構成 X System X System 14 Y System Standard B Standard C 追加構成 Y System Z System Z System © 2010 IBM Corporation とは言え、無理に一つのパラメーターに決め込んでしまうと、結局各サブシステムを 作成する際に個別対応・カスタマイズしなくてはならない点が多くなり、標準化のメ リットが薄れてしまいます。そこで、パラメーター標準のパターン化を行います。 例えば規模に応じてクラスター構成の有無やセッション共有構成の違いで分けたり、 インターネット／イントラネットの違いでセキュリティー要件を厳しくしたりといった、 パターン別の松竹梅オプションを作成しておきます。構築の際には業務要件およ びシステム要件からどのパターンに適合するかの判断をクイックに行うだけで、最 低限のカスタマイズ量に抑えることができます。 14 WebSphere Cloud Solution ワークショップ WASの標準化：②構成・運用手順の標準化 WASの構成において決めるべき手順の例 導入・構成・変更時 スケジュール・分担 メディア準備方法 作業形態 データセンター作業/ リモートログオン 作業ログフォーマット 作業結果検証方法 報告・承認フロー 定常運用 起動停止 ログ運用 生死確認 パフォーマンス監視 バックアップ/リストア アプリケーション更新 作業検証方法 報告・承認フロー 障害時運用 縮退 障害コンポーネントの 切り離し 情報収集 問題判別・対応 復旧 報告・承認フロー 構成の拡張・縮退 拡張・縮退条件設定 拡張・縮退作業 課金情報の収集 報告・承認フロー 新たなステークホルダー の登場 15 新しい技術の採用 © 2010 IBM Corporation 続いて手順の標準化について解説します。WAS関連の手順と言うと、上に挙げた ような導入・構成時や定常運用・障害時運用などが考えられます。こうした手順のフ ローは既にある程度決定済みと思いますが、クラウド化によって構成の拡張･縮退と いった、これまで無かった運用手順が追加されたり、変更されたりする可能性があり ます。 例えばこれまで基盤としてOS周りの担当チーム／WAS等のミドルウェア担当チー ム／アプリチームなどと分かれていた部分が、クラウド･プロバイダーという新しい チーム（または別会社）が登場することになります。さらに、新たな技術、例えば Amazon S3のような共用ストレージに仮想イメージごとのバックアップを取るような 仕組みを手順として組み込む必要が出ることもあります。 15 WebSphere Cloud Solution ワークショップ WASの標準化：②構成・運用手順の標準化 クラウド化の影響を加味し、従来からの手順の見直し・共通化を進める。 クラウド化の影響を加味し、従来からの手順の見直し・共通化を進める。 繰り返し手順は自動化を推進し、運用負荷を軽減する。 繰り返し手順は自動化を推進し、運用負荷を軽減する。 OSチーム 基盤構成検討 レビュー 基盤構成 テスト レビュー ミドルウェアチーム 要件入力 構成確認 構成確認 テスト クラウド･プロバイ ダー サービス･ポータル 基盤チーム 要件入力 16 構成確認 OS/ミドルパラメーター追加 テスト © 2010 IBM Corporation ざっくりの想定での業務フローの変化の例を書いてみました。WAS環境構築の手 順も登場する組織やロールが変わることで、ワークフローに対する変更を余儀なくさ れます。 こうした変更の機会に従来の手順を見直し、自動化できるパートを切り出してくこと で、全体の構成を簡略化し、ワークロードを減らしていきます。 16 WebSphere Cloud Solution ワークショップ 標準化の策定方法 標準化策定の際に参考にする情報 現行システムへのヒアリング クラウド・プロバイダー情報 バージョン・リリース 設計書 実パラメーター 運用手順 … 技術文書の調査 社内ポリシーの適用 InfoCenter 最新W/Sドキュメント developerWorks … ITポリシー セキュリティー・ポリシー 準拠標準（ISOxx等）… 成果物ゴールの例 WAS標準設計書 z 設計書 z パラメーターシート 17 Ts&Cs (規約) SLA ワークフロー 課金情報 … WAS導入・構成手順書 z 導入手順書 z 構成手順書 WAS運用手順書 z 運用手順書 © 2010 IBM Corporation このようなシステムの標準化、手順の標準化はどうやって策定していくべきでしょう か。 まずは現行システムおよび手順の実態調査が必要です。どういったパラメーター設 定をしているのか、どういった手順で決めているのかは、実際の設計書からのパラ メーター･リストの抽出、手順書からの業務フローの視覚化で現状把握を行います。 こうした現状把握に対し、パブリックもしくはプライベートのクラウド・サービス・プロバ イダーのワークフローや提供される環境の基本設定の範囲などを加味し、新たなシ ステムおよび手順の参考にします。 従来のシステムが古いバージョンのWASを使っているような場合であれば、さらに 最新のワークショップ資料やdeveloperWorks記事、InfoCenterなどを参考に、ある べき設定を模索します。さらに、各企業が持っているITポリシーやセキュリティー・ポ リシーなどをシステムに当てはめ、必要な構成を追加します。 結果は設計指針・パラメーターリストなどを含んだ「WAS標準設計書」のような形で まとめることになります。手順の方も同様に、構成手順書や運用手順書を作成しま す。 17 WebSphere Cloud Solution ワークショップ 標準化の適用方法 成果物の適用方法 省力化 省力化 提案 提案 ソリューション・ ソリューション・ アウトライン アウトライン マイクロ マイクロ 設計 設計 マクロ設計 マクロ設計 パターン判定 構築 構築 サイクル サイクル 差分抽出 WAS標準設計書 z 設計書 z パラメーターシート 展開 展開 自動化 WAS導入・構成手順書 z 導入手順書 z 構成手順書 WAS運用手順書 z 運用手順書 バージョンアップ時などのメンテナンス作業の必要性 バージョンアップ時などのメンテナンス作業の必要性 18 © 2010 IBM Corporation 作成した標準はドキュメントであるため、各プロジェクトではそのドキュメントを参照し て設計・システム構築・運用を行います。実際にはドキュメントの強制力（設計時参 考資料なのか、準拠すべき規範なのか）など、適用におけるルールも手順として策 定する必要があります。 ドキュメンテーションのレベルでは実際のプロジェクトでの適用でのワークロードも 大きいため、次のステップとして文書からのスクリプト生成といった自動化へと進め ていきます。 注意点として、標準は策定したら終わりではありません。新たなバージョンの登場や 環境の変化、クラウド･プロバイダーの変更などに伴い随時改定していく必要があり ます。こうした作成した後のメンテナンスも標準化のプロジェクト・スコープに入れる ようにしてください。 18 WebSphere Cloud Solution ワークショップ §3. WAS環境における自動化 19 © 2010 IBM Corporation 続いてWAS環境における自動化について解説します。 19 WebSphere Cloud Solution ワークショップ WAS構成の基本フロー 製品メディアよりインストーラーにて WAS/IHS/Plugin等の製品イメージを導入 Update Installerを導入し、最新のフィッ クスパック/必要なiFixを追加導入 複数台構成時の管理対象範囲とな るセルを構成するためDMへのノー ドを追加 アプリケーション実行単位となる サーバー、そのグループであるクラ スターを作成 WAS構成の単位となる、DMおよび サーバー用プロファイルを作成 設計 製品 導入 フィックス 導入 プロファイ ル作成 セル構成 サーバー/ クラスター 作成 パラメー ター設定 アプリケー ション導入 テスト 設計書 反映 ヒープ、データソース、セッション管 理、スレッドサイズなどを調整 稼働するアプリケーションをサー バー、クラスターに対して導入 アプリケーションおよびWAS基盤が 想定挙動となるかテスト実施、修正 20 © 2010 IBM Corporation WASの自動化を解説する前に、自動化の対象となるWAS構成の基本フローを解 説します。 最初に設計があり、設計が終わると、インストーラーを使用して製品を導入します。 WASだけでなく、必要とされるIHSやプラグインなどの追加コンポーネント導入もこ こに含まれます。続いて、WASと同じ環境にUpdate Installerと呼ばれるツールを 導入し、最新のフィックスパックや必要な個別フィックス（iFix）を適用します。 製品コンポーネントが導入されると、続いてプロファイルを作成します。これはWAS のプロセスを稼働させるために必要なバイナリー･モジュールのサブセットで、デプ ロイメント･マネージャー（DM）用のプロファイル、アプリケーション･サーバー（AS） 用のプロファイルといった種類があります。セル構成を組む場合、統合構成ポイント となるDMプロファイルに対し、カスタム・プロファイルのaddNodeコマンドで統合し ます。 管理構成トポロジーが完成すると、実際にアプリケーションが稼働するサーバーを 構成します。これはDMなどの管理コンポーネントに対して実施する作業で、ASの 作成、クラスターの作成などを行います。その後、作成したサーバーやクラスターに 対し、データソースを定義したり、ヒープサイズを変更したりと言ったパラメーター設 定を行います。アプリケーション稼働の準備が整ったらアプリケーションを導入し、 稼働する対象のサーバーもしくはクラスターに割り当てます。 導入したアプリケーションは稼働確認のためにテストを実施します。稼働確認が取 れたら設定したパラメーターと設計書との間で齟齬が生じていないかチェックし、結 果を設計書に反映します。 20 WebSphere Cloud Solution ワークショップ WAS構成の基本フロー：クラウドで出来ること 設計 製品 導入 フィックス 導入 プロファイ ル作成 セル構成 サーバー/ クラスター 作成 パラメー ター設定 アプリケー ション導入 テスト 設計書 反映 AMI WAS HV WCA 標準化による省力化 標準化による省力化 21 自動化による補完 自動化による補完 © 2010 IBM Corporation 前項の構成フローに対し、WASで提供される各種クラウド技術を使うと、どの部分 が簡略化されるかを見て行きます。 まず、WAS導入済みの仮想環境をパブリック･クラウド上で提供するAmazon Machine Image（AMI）ですが、これが提供するのは製品およびフィックスの導入部 分です。WAS7.0.0.9のようにフィックス適用済みのWAS環境が簡単なオペレー ションのみで入手できます。最新フィックスパックへの対応が若干遅くなる点に注意 する必要があります。 仮想環境用導入イメージとして提供されるWAS Hypervisor Edition （WAS HV）は、 製品および最新のフィックスパックが適用されて提供されるほか、Feature Packと いうWAS機能拡張も付随する点が特徴になります。また作成済みプロファイル・イ メージも付属しており、初回起動時にホスト名やrootパスワード等の環境依存パラ メーターを入力するだけで、プロファイル込みの環境が起動します。 プロビジョニング･ツールであるWCAは、簡便なGUI操作で複数台環境のWAS仮 想イメージ（WAS HVを使用）をデプロイし、セル構成、サーバー構成からパラメー ター設定、アプリケーション導入までワン・クリックで実行できます。とは言え、パラ メーター設定等は通常手順で作成するものと同様のスクリプトを開発し、デプロイ･ パッケージとしてバンドルさせる必要があります。 クラウド機能を使ったとしても残る作業の部分は、自動化機能を活用し補完してあ げる必要があります。そして自動化のためには設計を標準化しておくことが大前提 となります。 21 WebSphere Cloud Solution ワークショップ WAS構成：手動手順と自動化手順 製品 導入 製品導入 フィックス 導入 フィックス導入 手動手順 プロファイ ル作成 セル構成 プロファイル 作成 セル構成 サーバー/ クラスター 作成 パラメー ター設定 アプリケー ション導入 サーバー/ パラメーター アプリケーショ ン導入 クラスター作成 設定 GUIプロファイ ル管理ツール 管理コンソー ル 管理コンソー ル 管理コンソー ル Installコマンド UpdateInstalle manageprofile addNodeコマ rコマンド sコマンド ンド （レスポンス・ファ イル） （レスポンス・ファ (レスポンス・ファ イル） イル） wsadminコマ ンド wsadminコマ ンド wsadminコマ ンド スクリプト･ライ ブラリー PFBCT 自動化手順 GUIインストー ラー 集中インスト レーション･マ ネージャー GUI Update Installer GUIプロファイ ル管理ツール 集中インスト レーション･マ ネージャー 22 © 2010 IBM Corporation 前項までに紹介したWASの導入・構成手順は、基本的にGUIのインターフェース （インストーラーや管理コンソール）を使用出来ます。これは一度行う場合には便利 な反面、ユーザーがパラメーターを一つ一つ指定する必要があり、繰り返し作業の 自動化には向いていません。一方、こうした導入・構成手順ではコマンド･ラインの インターフェースも提供されており、スクリプトからの実行が可能です。自動化のた めにはこうしたスクリプト系のWAS提供機能を活用します。 ここで着目する赤枠で囲んだ5つのWAS機能に関しては、次ページ以降で詳しく 説明します。 •コマンド・ライン･ツールでパラメーターを一括指定するレスポンス･ファイル •複数台WASバイナリー･イメージの一括導入を行う集中インストレーション･マネー ジャー •管理用CUIツールwsadmin •管理用CUIサンプル･スクリプト集スクリプト･ライブラリー •プロパティ･ファイル･ベース構成ツール、PFBCT 22 WebSphere Cloud Solution ワークショップ レスポンス・ファイルによる導入 GUI導入 導入開始 レスポンスファイルによる導入 install.sh 導入開始 -OPT -OPT silentInstallLicenseAcceptance="true" silentInstallLicenseAcceptance="true" -OPT -OPT installLocation="/usr/IBM/WebSphere/AppServer" installLocation="/usr/IBM/WebSphere/AppServer" -OPT -OPT PROF_enableAdminSecurity="false" PROF_enableAdminSecurity="false" ## -OPT -OPT feature="noFeature" feature="noFeature" ## -OPT -OPT feature="samplesSelected" feature="samplesSelected" -OPT -OPT feature="languagepack.console.all" feature="languagepack.console.all" -OPT -OPT feature="languagepack.server.all" feature="languagepack.server.all" 23 © 2010 IBM Corporation レスポンス･ファイルはウィザードで指定する各種パラメーターを「パラメーター＝ 値」形式で一つのファイルにまとめたものです。インストーラーをサイレント･モードで 実行し、その際にレスポンス･ファイルを指定してあげることで、ユーザーに対するイ ンタラクションなしでインストールやFix導入、プロファイル作成が開始されます。 23 WebSphere Cloud Solution ワークショップ 集中インストレーション･マネージャーによる導入 通常の導入 Node01 Node02 Node03 Node04 Node05 集中インストレーション･マネージャーによる導入 DM Node01 24 Node02 Node03 Node04 Node05 © 2010 IBM Corporation 集中インストレーション･マネージャーは複数台環境への導入を一括で行う機能で す。 通常であれば上記例のように、五台なら五台の環境全てでインストーラーを実行す る必要があります。インストレーション･イメージを共有ディスクなどに配置し個々の マシンから参照できるようにするなどで省力化は出来るとしても、同じ手順を五回繰 り返す必要があります。 集中インストレーション･マネージャーを使用すると、まず一台の環境にWASを導入 し、その際に集中インストレーション･マネージャー･レポジトリーの作成を指定しま す。これにより、インストール・イメージがWASの管理ディレクトリー配下に配置され ます。その環境でDMプロファイルを作成し、管理コンソールの集中インストレーショ ン･マネージャー･メニューへ行き、レポジトリーと残り四台のノードを指定することで、 DM経由で四台のマシンに一括で導入を行います。 24 WebSphere Cloud Solution ワークショップ wsadminとスクリプト･ライブラリーによる構成 WASの構成情報 階層構造を持ったXMLファイルに保管 JMXインターフェースにより参照・変更される server.xml、resource.xmlなど 管理コンソール/wsadmin セル環境ではDMで集中管理、配布される dmgr WASCellManager01 Cluster1 nodeagent server1 clmem1 server2 clmem2 WASNode01 nodeagent WASCell01 25 WASNode02 © 2010 IBM Corporation wsadminの説明をする前に、基本的なWAS構成情報の管理構造について解説し ます。WASの構成情報は古いバージョンではRDBに保管されていましたが、現在 のバージョンではXMLファイルに保管されています。構成情報は多岐に渡るため、 サーバー情報はserver.xml、データソースなどリソース情報はresource.xmlなど数 十に上る複数のファイルに分散保管され、セル構造と同様の階層を持つディレクト リー配下に保管されています。 このXMLファイルは直接編集を許しておらず、管理コンソールからJMXというJava 標準の管理インターフェースを介して参照や変更がなされます。セル環境ではこの 管理インターフェースはDMに統合され、全ての管理操作をDMに対して行った後、 各ノードに必要な構成ファイルが配布されます。 25 WebSphere Cloud Solution ワークショップ wsadminとスクリプト･ライブラリーによる構成 wsadmin コマンド行を使用した管理ツール 基本SOAPインターフェースを介し、管理コンソールと接続、JMX経由で管理 オペレーションを実行 対話式、もしくはjython/jaclスクリプトでのプログラミングが可能 以下のコマンド･オブジェクトを持つ AdminControl AdminControl AdminConfig AdminConfig AdminApp AdminApp AdminTask AdminTask Help Help スクリプト･ライブラリー WAS管理操作用のjythonスクリプト･サンプルの提供 <WAS_ROOT>/scriptLibraries ディレクトリ以下にカテゴリ別に配置 26 操作コマンドの実行に使用 操作コマンドの実行に使用 WAS構成エレメントの作成または変更に使用 WAS構成エレメントの作成または変更に使用 アプリケーションの管理に使用 アプリケーションの管理に使用 管理コマンドの実行に使用 管理コマンドの実行に使用 ヘルプを得るために使用 ヘルプを得るために使用 application/perfTuning/resources/security/servers/system/utilities © 2010 IBM Corporation wsadminは一言で言えば管理コンソール機能のコマンド行インターフェース版で す。WASのbinディレクトリーからwsadmin.sh(.bat)を起動し、DMのホスト・ポート番 号、ユーザーIDおよびパスワードを指定しSOAP接続するアプリケーションになりま す。wsadminコマンドを実行することでインタラクティブ･モードでコマンド実行を行 うことも可能ですし、jythonというスクリプト言語でロジックを持ったコマンド･スクリプト を作成してバッチ的に管理プログラムを実行することも可能です。 コマンドはAdminConfigというシステム管理情報の参照・変更、アプリケーション管 理操作に特化したAdminAppの他、AdminControlという起動終了等のオペレー ションに特化したコマンド･オブジェクトもあります。 wsadmin構成スクリプトはWASのバージョン5から導入されましたが、AdminConfig での構成情報の取得・変更は非常にオブジェクト指向的で、対象タイプをリストし、 リソースIDを取得し、リソースIDを元にオブジェクトを取得、変更とかなり複雑な手順 が必要です。この複雑さを改善するために、バージョン６よりよく使用される管理手 順をAdminTaskコマンドとしてまとめて提供されるようになりました。 さらにバージョン7で、jythonのスクリプトライブラリーが提供され、より柔軟な管理が 出来るようになりました。WAS導入ディレクトリー以下のscriptLibraries下にアプリ ケーションやサーバーなど構成単位に応じたjythonスクリプトが提供されており、例 えば一つのAdminApplication.pyスクリプトによりアプリケーションのインストール／ アンインストール、情報取得、更新、エクスポート、構成、開始終了などの操作を行 うことが出来ます。 26 WebSphere Cloud Solution ワークショップ wsadminとスクリプト･ライブラリーによる構成 例：アプリケーションのクラスローダー･モードの変更 wsadmin AdminConfigオブジェクト使用の場合 1. 1. 変更するオブジェクトの構成IDを検索し、dep変数に設定 変更するオブジェクトの構成IDを検索し、dep変数に設定 dep dep == AdminConfig.getid('/Deployment:myApp/') AdminConfig.getid('/Deployment:myApp/') 2. 2. デプロイ済みオブジェクトを識別し、それを デプロイ済みオブジェクトを識別し、それを depObject depObject 変数に設定 変数に設定 depObject = AdminConfig.showAttribute(dep, 'deployedObject') depObject = AdminConfig.showAttribute(dep, 'deployedObject') 3. 3. クラス・ローダーを識別し、それを クラス・ローダーを識別し、それを classldr classldr 変数に設定 変数に設定 classldr classldr == AdminConfig.showAttribute(depObject, AdminConfig.showAttribute(depObject, 'classloader') 'classloader') 4. 4. modify modify コマンドを使用して、構成オブジェクトの属性を変更 コマンドを使用して、構成オブジェクトの属性を変更 AdminConfig.modify(classldr, AdminConfig.modify(classldr, [['mode', [['mode', 'PARENT_LAST']]) 'PARENT_LAST']]) 5. 5. 構成の保管 構成の保管 AdminConfig.save() AdminConfig.save() スクリプト･ライブラリー使用の場合 上記分の操作が提供ライブラリーの使用で一つの管理操作として実行 AdminApplication.configureClassLoaderLoadingModeForAnApplication AdminApplication.configureClassLoaderLoadingModeForAnApplication ("myApp", ("myApp", "PARENT_LAST") "PARENT_LAST") 27 © 2010 IBM Corporation 一つ例として、アプリケーションのクラス･ローダー･モードを変更する場合の wsadminとスクリプト･ライブラリーとの差異を見てみます。 wsadminの場合はオブジェクトを取得し変更保管するまで五ステップが必要です が、スクリプト･ライブラリーの場一コマンドで完了します。通常の管理オペレーショ ンであれば、wsadminを一から書くよりもスクリプト･ライブラリーを活用することをお 勧めします。 27 WebSphere Cloud Solution ワークショップ PFBCT プロパティ･ファイル･ベース構成ツール 構成値の一括参照、一括変更のためのコマンド･ライン･ツール 構成リポジトリーXML <jvmEntries <jvmEntries xmi:id="JavaVirtualMachine_1271933 xmi:id="JavaVirtualMachine_1271933 307284" 307284" verboseModeClass="false" verboseModeClass="false" verboseModeGarbageCollection="fals verboseModeGarbageCollection="fals e" e" verboseModeJNI="false" verboseModeJNI="false" initialHeapSize="128" initialHeapSize="128" maximumHeapSize="256" maximumHeapSize="256" runHProf="false" runHProf="false" hprofArguments="" hprofArguments="" debugMode="false" debugMode="false" debugArgs="debugArgs="agentlib:jdwp=transport=dt_socket, agentlib:jdwp=transport=dt_socket, server=y,suspend=n,address=7777" server=y,suspend=n,address=7777" genericJvmArguments=""> genericJvmArguments=""> 構成プロパティー･ファイル ResourceType=JavaVirtualMachine ResourceType=JavaVirtualMachine extract AttributeInfo=jvmEntries AttributeInfo=jvmEntries validate apply initialHeapSize=128 initialHeapSize=128 PFBCT genericJvmArguments= genericJvmArguments= delete maximumHeapSize=256 maximumHeapSize=256 debugMode=false debugMode=false … … extract オリジナル構成 PFBCT オリジナル構成 プロパティ PFBCT 変更後構成 プロパティ apply 変更後構成 28 © 2010 IBM Corporation 例えスクリプト･ライブラリーを使用したとしても、システム全体のパラメーター変更を 行うのは大変です。 導入・構成時など、複数のパラメーターを一括適用する場合に有効なのがWAS バージョン7から提供されたプロパティ･ファイル･ベース構成ツール、略称PFBCT です。PFBCTには展開用のextract、展開したファイルのチェックを行うvalidate、 構成反映用のapply、構成削除用のdeleteの四つの機能があります。 WASの構成情報は前述の通りXMLに書かれているため人間にとっての可読性が 悪く、手動変更を許していません。PFBCTを使用すると、この構成情報を人間が読 みやすい形の「パラメーター＝値」形式のテキストファイルに展開してくれます。また 展開したテキストを書き換えPFBCTで適用すると、構成情報の更新も行われます。 よって展開→変更→（チェック）→適用のフローを回すことで、構成の一括変更が 出来るので、大変便利な機能になります。 28 WebSphere Cloud Solution ワークショップ PFBCT 例：server1の構成をカスタマイズする server1の既存構成からプロパティー・ファイル(config.props)を作成 wsadmin> wsadmin> AdminTask.extractConfigProperties('-propertiesFileName AdminTask.extractConfigProperties('-propertiesFileName config.props config.props -configData -configData Server=server1') Server=server1') テキスト・エディターを使ってプロパティーを変更 変更したプロパティーをserver1の構成に適用 wsadmin> wsadmin> AdminTask.applyConfigProperties(‘[-propertiesFileName AdminTask.applyConfigProperties(‘[-propertiesFileName config.props]’) config.props]’) 構成の保管 wsadmin> wsadmin> AdminConfig.save() AdminConfig.save() 29 © 2010 IBM Corporation server1の構成情報変更のフローとなるPFBCTの例を挙げますPFBCTもwsadmin のAdminTaskコマンド･グループのコマンドです。展開は AdminTask.extractConfigPropertiesで展開対象のオブジェクトおよび、展開先の ファイル名を指定します。展開が完了したらテキスト･エディターを使用し、パラメー ターの値を変更します。変更したファイルを、今度はapplyConfigPropertiesコマン ドを使用してサーバーに適用します。最後に変更情報を補完して終了です。 変更の際には、展開したファイル内の「パラメーター」＝「値」の「値」を直接書き換 える方式のほか、「値」を一旦「変数」に書き換え、別途「変数」＝「値」をまとめ書き したファイル（変数マップ：VariableMapと呼びます）を準備して適用することも可能 です。 29 WebSphere Cloud Solution ワークショップ PFBCT 設定情報の確認 構成プロパティー･ファイル ResourceType=JavaVirtualMachine ResourceType=JavaVirtualMachine AttributeInfo=jvmEntries AttributeInfo=jvmEntries PFBCT extract verboseModeClass=false verboseModeClass=false verboseModeGarbageCollection=false verboseModeGarbageCollection=false verboseModeJNI=false verboseModeJNI=false initialHeapSize=512 initialHeapSize=512 maximumHeapSize=1024 maximumHeapSize=1024 … … Excelなどに読み込み、 Excelなどに読み込み、 設計と実際の設定値 設計と実際の設定値 があっているかを確認 があっているかを確認 設計書（パラメーター･シート） パラメーター 30 デフォルト値 設計値 実設定値 判定 正常設定 冗長クラス・ロード false false false 冗長ガーベッジ・コレクション false true false 異常設定 冗長JNI false false false 正常設定 初期ヒープ・サイズ 0 512 512 正常設定 最大ヒープ・サイズ 0 1024 1024 正常設定 © 2010 IBM Corporation PFBCTは一括更新の機能として紹介されることが多いですが、設定情報の確認の ために使用することも出来ます。 自動化の最初のページのWAS構成フローの中で、一番右側に設計書反映と言う ステップを入れました。これは、自動化を行うことでスクリプト等の設定内容が意図ど おりのものとなったかを確認するステップです。 PFBCTのextract機能によって抽出された構成プロパティー･ファイルを、シェルや マクロ等で設計書のパラメーターシートに読み込み、設計値と同一か否かのチェッ クを行うと、設定の漏れやミスを見つけ出すことが出来ます。こうした部分まで自動 化が出来れば、個々のプロジェクトの構成作業においてはかなりの省力化につな がります。 30 WebSphere Cloud Solution ワークショップ テスト負荷の軽減二案 テストの省略 仮想イメージのデプロイ、自動化機能による「検証済み」環境のデプロイ であるため、これまで行っていた確認テストなど の一部省略を検討する テストの自動化 基盤テストの自動化 アプリケーション機能テストの自動化 31 サーバーの開始終了やログ出力の確認などはプロジェクト間でのスクリプト 共有を進め、ワークフローを含めた標準化・自動化を行う jmeterやRational Function Testerのようなツールによる自動化・スクリプト 化を行い、結果査収プロセスも標準化する パフォーマンステストの自動化 同様にRational Performance Tester等を使用し自動化する チューニング部分の自動化は難しいが、対処手順の標準化を進めることは 可能 © 2010 IBM Corporation 最後にテストの自動化ですが、クラウド環境でのテストの負荷軽減には自動化だけ 考えればいい訳ではありません。プロビジョニング･ツールなどが提供する検証済 み環境のデプロイであることを考え、不要となるテスト･ステップやテスト･ケースを省 略することをまず検討ください。 その上で残ったテスト、基盤テストや機能テスト、パフォーマンステストの自動化を 検討します。自動化のためにはフリーのツールを始め、IBMからもRationalを中心 に各種製品が提供されていますので、是非活用ください。 31 WebSphere Cloud Solution ワークショップ 自動化方針 WASの構成基本フローの自動化方針 レスポンス･ファイル 製品メディアよりインストーラーにて WAS/IHS/Plugin等の製品イメージを導入 集中インストレーション・マネージャー レスポンス･ファイル Update Installerを導入し、最新のフィッ クスパック/必要なiFixを追加導入 複数台構成時の管理対象範囲とな addNodeコマンド るセルを構成するためDMへのノー ドを追加 集中インストレーション・マネージャー WAS構成の単位となる、DMおよび レスポンス･ファイル サーバー用プロファイルを作成 設計 製品 導入 フィックス 導入 プロファイ ル作成 セル構成 アプリケーション実行単位となる サーバー、そのグループであるクラ スクリプト･ライブラリー スターを作成 サーバー/ クラスター 作成 パラメー ター設定 アプリケー ション導入 テスト 設計書 反映 ヒープ、データソース、セッション管 PFBCT 理、スレッドサイズなどを調整 稼働するアプリケーションをサー wsadmin バー、クラスターに対して導入 アプリケーションおよびWAS基盤が ツールの使用 想定挙動となるかテスト実施、修正 32 © 2010 IBM Corporation この節ではWASの構成フローに対し、これまで紹介した各種機能を適用してどのよ うに自動化が実現できるかを紹介してきました。まとめると上の図のようになります。 標準化によりパターン化されたパラメーターおよび、プロジェクト依存の環境パラ メーターに基づき設計を行った結果を、レスポンス・ファイルやスクリプト･ライブラ リー、PFBCTの入力ファイルとして反映します。これらを使用して自動化ツールを 流し、環境構成を行います。 最終的に構成された内容はPFBCTやExcelマクロ等を使用し、設計書に反映し、 結果確認を行います。 採用するクラウド環境に応じ、上記のステップから必要な部分を切り出して適用す ることで、トータルの環境作成負荷を軽減する指針としてください。 32 WebSphere Cloud Solution ワークショップ 自動化における注意点 モジュールやスクリプトの配置方法 インストール・イメージや、自動化実行シェルの配布 実行結果の確認方法 各ステップで吐かれるログの集約と状況判断 ログの共有ディスクへの配置、スクリプトによるログの集約 複数ステップを自動化する際にはステップごとに完了フラグを立て、再実行 に対応する セキュリティー 自動化ツールが使用する／構成するユーザー情報などの管理 33 共有ディスク上に配置しネットワーク・マウント プロビジョニング･ツール、集中インストレーション・マネージャーの活用 暗号化保管、初期パスワードの変更による対処 セキュリティー設定の外部化 © 2010 IBM Corporation ここまで紹介してきたWAS機能を活用し自動化を進めるにあたって、いくつかの注意点を記載しま す。 まず、モジュールやスクリプトの配置方法です。導入・構成を自動化スクリプトなどで行う際には、イン ストール･イメージやスクリプト自体を、通常は複数のマシン上に配布する必要があります。自動化を 行う際にはこうしたイメージの配布部分も自動化しておかないと、ファイル・サイズが大きく長い時間 がかかってしまいます。便利なのはSAN/NAS等の共有ディスクに一括配置し、各マシンからはネッ トワーク･マウントすることです。WCAのようにプロビジョニングの際に配布およびキャッシュする機能 を持っているツールや、集中インストレーション・マネージャーなどを活用することも考えられます。 続いて、実行結果の確認方法です。スクリプトを流して終了してしまう自動化は、途中でエラーが起 きたのか、意図したとおりに構成されたのかを見ながら待っているわけではなく、処理完了後に実行 ログを調べることになります。導入ログ、フィックスの適用ログ、プロファイル作成ログ、構成ログなど はそれぞれ別のディレクトリーに保管されるため、これらを共有ディスク上に配置したり、スクリプト内 でサマリーしたりと言った処理が有効になります。また、複数手順を流す自動化スクリプトの途中で 処理が異常終了した場合、再実行でまた一からやり直すのは非効率なので、各処理ごとに完了フラ グを立てるなどで再実行に対応したスクリプト設計にする必要があります。 さらに、自動化ツールが使用したり設定したりするユーザーID／パスワードをどのように持たせるかと 言ったセキュリティー上の配慮も必要です。こうしたパスワードなどが平文でスクリプト内に書かれて いるようなケースでは不用意なセキュリティー漏洩になりかねないため、暗号化や初期パスワードの みを設定して後で管理者が変更すると言った対処も必要です。スクリプト内ではセキュリティー設定 を基本行わず、その部分は人手による作業に外部化するなども、各社セキュリティー規約に順じて 行ってください。 33 WebSphere Cloud Solution ワークショップ 参考：RAFW紹介 ※ Rational Automation Framework for WebSphere 34 © 2010 IBM Corporation 参考として、自動化で紹介してきた構成作業スクリプト類を、製品機能として提供す るRAFW、Rational Automation Framework for WebSphereをご紹介します。こ れはRational Build Forgeというビルド／リリース自動化製品の上で稼働するコン ポーネントで、WASの構成スクリプトを一括提供しています。これら提供スクリプトを 使用し、自動実行させることでWAS環境を簡易に作り上げることが出来ます。自動 化を進める際にはこうした製品を適用することも検討ください。 34 WebSphere Cloud Solution ワークショップ §4. WAS自動化・標準化の例 35 © 2010 IBM Corporation 最後にWAS構成の自動化・標準化の例として、ISE内のタスクとして行っているアセット開発の例を ご紹介します。 35 WebSphere Cloud Solution ワークショップ ISE WAS自動化・標準化タスク 目的 構成の自動化・標準化を推進するアセットを作成し、WAS構成の迅速化 と負荷軽減に貢献する アセット概要 標準パラメーター･パターン パラメーター･ファイル生成ツール パラメーター･ファイル生成ツールのアウトプットを利用して、WASの導入・構 成を行うシェルを作成 PFBCT設定自動化シェル 36 プロジェクト依存パラメーターの入力により、導入・構成に必要なレスポンス･ ファイルやPFBCT変数マップ･ファイルを生成するExcelツールを作成 WAS基本構成自動化シェル WAS V7.0パラメーター･シートを元に、標準として設定しておくべきパラメー ター･リストを単体構成パターン／クラスター構成パターンの二種で作成 パラメーター･ファイル生成ツールのアウトプットを利用して、PFBCTによる WAS自動構成、構成情報の取得を行うシェルを作成 © 2010 IBM Corporation ISEで行っているWAS自動化･標準化タスクとは、WAS構成をスピーディーに、低 負荷で行うためのアセットを提供するためのタスクです。2010年7月のワークショッ プ開催時点では作成中のアセットであり、2010年8月頃を目処に第一版を完成さ せる予定です。 アセットは標準化されたWAS構成を自動導入するものですが、上のようないくつか のコンポーネントに分かれています。個々のコンポーネントの説明を次のページか ら行います。 36 WebSphere Cloud Solution ワークショップ 標準パラメーター･パターン リソース 単体サーバー 37 © 2010 IBM Corporation 標準パラメーターはISE提供のWAS V7のパラメーターシート（Excelファイル）を ベースに、ISE WAS担当者の経験を生かし、変更すべきパラメーターを提示したも のです。標準構成で変更しているパラメーターは最低限変えるべきものですが、パ ターンとして単体構成とクラスター構成の2パターンを提示しています。標準化の節 で、①パラメーター標準化の項で説明した、(A)の推奨値とパターンごとに決め打ち にした(C)の値を提供するとともに、環境依存の(B)の値に関しては異なる色のセル で抽出しています。 37 WebSphere Cloud Solution ワークショップ パラメーター･ファイル生成ツール ②マクロで環境設定に必 ②マクロで環境設定に必 要なファイルを生成 要なファイルを生成 生成ツール Excel インストーラーのレス ポンス･ファイル Update Installerのレ スポンス･ファイル manageprofilesのレ スポンス･ファイル ①環境依存パラメーター ①環境依存パラメーター をユーザーが埋める をユーザーが埋める 初期構成のシェル用 パラメーターリスト httpd.conf PFBCT用のパラメー ターリスト 38 © 2010 IBM Corporation 標準化したパラメーターはそのままではドキュメントに過ぎません。パラメーター・ ファイルを実際の構成に反映させるための仕組みが必要になります。 パラメーターは導入したWASのサーバー構成だけでなく、導入時やプロファイル作 成時など、何段階かのステップで使われます。パラメーター･ファイル生成ツールは こうしたステップで使用できるレスポンス･ファイルやパラメーター･ファイルを生成す るものです。ここでWASやIHSの導入レスポンスファイルや、httpd.confファイル、 PFBCTの変数マップなどのテキストファイルを生成します。 ツールはExcelのマクロで作成され、ホスト名や構成するノードの数など、環境依存 のパラメーターを指定した後にテンプレートファイルを変更することで、環境ごとの レスポンス･ファイルを作成できます。 38 WebSphere Cloud Solution ワークショップ WAS基本構成自動化シェル 自動化シェル インストーラーのレス ポンス･ファイル install.sh Update Installerのレ スポンス･ファイル update.sh manageprofilesのレ スポンス･ファイル manageprofiles.sh 導入対象ノード AppServer Profile 初期構成のシェル用 パラメーターリスト フィックス パック IHS FP WAS7 IHS wsadmin.sh httpd.conf ①必要なファイルを読み込 ①必要なファイルを読み込 み、導入作業をシーケンシャ み、導入作業をシーケンシャ ルに実施 ルに実施 39 © 2010 IBM Corporation 次に提供されるのが、WASの構成を作成する自動化シェルです。パラメーター･ ファイル生成ツールにより作成されたレスポンス･ファイル等を読み込み、WASや IHSの導入、フィックスの適用、プロファイル作成、サーバーやクラスター作成まで 順次行うものです。シェルはAIX用のkshとして提供されています。 39 WebSphere Cloud Solution ワークショップ PFBCT設定自動化シェル PFBCTシェル ①extractによる初期構 ①extractによる初期構 成の抽出 成の抽出 導入対象ノード extract PFBCT用のパラメー ターリスト 初期構成 AppServer 編集 Profile ②構成ファイルを ②構成ファイルを VariableMap用に変更 VariableMap用に変更 変更構成 フィックス パック IHS FP WAS7 IHS apply ③VariableMapと変更し ③VariableMapと変更し た構成ファイルのapply た構成ファイルのapply extract ④extractによる変更後 ④extractによる変更後 構成の抽出 構成の抽出 変更後構成 ⑤Excelパラメーターシートへの反映と、 ⑤Excelパラメーターシートへの反映と、 変更が正しいか否かの比較 変更が正しいか否かの比較 40 © 2010 IBM Corporation 構成の仕上げとして、PFBCTの設定自動化シェルが提供されます。これもパラメー ター･ファイル生成ツールにより作成されたWASの設定パラメーター･ファイルを読 み込み、WASの構成変更を行うものです。 構成の変更のためにはまず構成の抽出が必要であるため、サーバー作成等の基 本構成の済んだ環境に対してPFBCTのextract、変更、applyによる変更適用を行 います。 さらに、変更後環境のextractを行い、パラメーター･シートへの反映、変更が意図ど おりであるかの比較まで行えるような実装を考えています。 40 WebSphere Cloud Solution ワークショップ 自動化・標準化ツール統合ワークフロー 生成ツール 自動化シェル Excel インストーラーのレスポ ンス･ファイル install.sh 導入対象ノード Update Installerのレス ポンス･ファイル update.sh AppServe r manageprofilesのレス ポンス･ファイル manageprofiles.sh フィックス パック IHS FP WAS7 IHS 初期構成のシェル用パ ラメーターリスト Profile wsadmin.sh httpd.conf extract PFBCT用のパラメー ターリスト 初期構成 編集 変更構成 apply extract 変更後構成 PFBCTシェル 41 © 2010 IBM Corporation ここまで紹介したコンポーネントをどのように連携させるかの全フローです。標準化 パラメーターを元に生成ツールでパラメーターファイル群を作成し、自動化シェル、 PFBCTシェルが消化しながらWAS構成を作成します。これまで数日かかっていた WAS構成をこのツールを使用することで大幅に短縮可能です。 41 WebSphere Cloud Solution ワークショップ §5. まとめ 42 © 2010 IBM Corporation 42 WebSphere Cloud Solution ワークショップ まとめ クラウドの効果を得るためには、クラウド･プロバイダーやプロビ ジョニング・ツールが提供する以上の自動化が必要。 処理の自動化のためには、パラメーターおよび構成・運用手順 の標準化が前提。 今後の展望 43 JavaScriptよりもシェルスクリプト 構成の簡素化 ランタイムの自動化・自律化 インターフェースの標準化→ハイブリッド･クラウド © 2010 IBM Corporation クラウド･コンピューティングや仮想化により、WASなどのシステム環境構築の負荷 は確実に下がっています。しかし、そこで得られる負荷軽減では、結局人手が介在 してタイムリーなシステム提供が出来ないなど、十分なものとは言えません。 こうした自動化を行うためには、パラメーターを事前設定しておくという観点での標 準化、さらに構築や検収のフローまで含めた標準化が前提になるため、今まで以 上に自動化・標準化が重要になっているといえます。 最後に私見ながら今後の展望をいくつか挙げていきます。まず、これまで主に運用 で使用される地味な存在だったスクリプトが、クラウド化とともに重要度が増して注 目度が上がることが考えられます。また、仮想化されたリソースを弾力的に活用でき るという観点から、あまり設計に負荷をかけず簡易な構成をたくさん並べてスケール させる構成がより一般化する可能性があります。さらに、今回紹介したのは主に構 成および運用の自動化ですが、Amazon Web Servicesのauto scalingや、 WebSphere Virtual Enterpriseのような実行環境をオンデマンドに拡張･縮小させ るランタイムの自動化・自律化技術の適用が進んでいく方向性も考えられます。最 後に、オンプレミス／オフプレミス双方にシステムが存在するようになり、その間をつ なぐためのサービス･インターフェースの標準化が進んで行く事で、ハイブリッド･ク ラウドが広がっていくと思われます。 43 WebSphere Cloud Solution ワークショップ 参考資料 WebSphere Application Server V7.0 管理ガイド http://www.ibm.com/developerworks/jp/websphere/library/was/was7_adminguide/ WebSphere Application Server V7.0によるWebシステム基盤設計ワークショップ資料 参考資料：設計書ガイド（設計書マッピング） http://www.ibm.com/developerworks/jp/websphere/library/was/was7_guide/index.html 44 © 2010 IBM Corporation 参考資料を二点ほど紹介します。 管理ガイドはここで紹介したWAS自動化機能を体系的に解説したものです。実際 に機能を使用する際に参考にして下さい。また、基盤構築ワークショップ資料は WASをインフラ構築の観点で解説した資料になるため、いずれも今回の話に関連 しますが、特に設計書ガイドがパラメーター標準化の参考になるかと思いますので、 ご参照下さい。 44