レベル: 中級 Frank De Gilio (degilio@us.ibm.com), Senior complex solutions architect, IBM , IBM Design Center for On Demand Business
Hilon Potter (merlin@us.ibm.com), Senior architect and certified IT specialist, IBM Design Center for On Demand Business
2005年 2月 08日 オンデマンド・オペレーティング環境を構築できる新しいテクノロジーや製品がすべて揃っていても、個々のコンポーネントを整理して全体像に組み込むのは容易な作業ではありません。この記事では、IBM Enterprise Workload Manager for Multiplatforms、IBM Tivoli Provisioning Manager、IBM Tivoli Intelligent Orchestrator の 3 つの IBM 製品の働きと、それらがどのように連携し、一体化したインフラストラクチャーを形成していくのかについて、概要を説明します。
はじめに
この3製品は一見どれも同じ働きをするような印象を与えますが、実際は違います。機能面の重複はなく、相互に補完し合うものです。パッケージもそれぞれ異なります。実際、Tivoli® Provisioning Managerは様々にパッケージして提供されています。
各製品を1つずつ見ていきましょう。技術は常に進化していますが、この記事では 2005年2月時点での機能と相互関係について説明します。テクノロジーの成熟とともにこれらの製品も成長し、オンデマンド・インフラストラクチャーを最適にサポートするべく変わっていくでしょう。
IBM Enterprise Workload Manager for Multiplatforms
Enterprise Workload Manager for Multiplatforms は IBM Virtualization Engine Suite for Servers の一部ですが、スタンドアロン製品として入手することも可能です。Enterprise Workload Manager for Multiplatforms の将来の戦略的役割は、インフラストラクチャー全体で作業を動的にルーティングするためのデータを提供することです。現在は、コンポーネントをモニターしながら、インフラストラクチャーの状況をエンド・ツー・エンドで把握するためのパフォーマンス情報を収集しています。これには、以下の 2 つのキー・コンポーネントが含まれています。
-
エージェント：コンポーネントに関する情報を収集します。これらのエージェントが実行されているサーバーを管理対象サーバーと呼びます。
-
ドメイン・マネージャー：エージェントが収集した情報を集約します。エージェントの全データの収集ポイントであり、ドメイン・マネージャー独自のサーバー上で実行されます。
Enterprise Workload Manager for Multiplatforms エージェントは Application Response Measurement (ARM) V4.0 対応のサーバー上で実行可能ですが、これには殆どの分散サーバー・オペレーティング・システムが含まれます。ARM V4.0 は z/OS® 上でもサポートされています。また、Enterprise Workload Manager for Multiplatforms は ARM V4.0 対応のミドルウェアもモニターできます。ARM 標準には、エンタープライズ・アプリケーションを「管理可能なエンティティー」として統合するための共通の方法が記述されています (参考文献を参照)。
多層構造の Enterprise Workload Manager for Multiplatforms 環境において、トランザクションのエンド・ツー・エンドのパフォーマンス像を示す統計情報を漏れなく収集するためには、HTTP サーバー、アプリケーション・サーバー、データベース・サーバーがすべて ARM V4.0 に対応していなければなりません。この ARM データはドメイン・マネージャーに送られ、そこで Cloudscape データベース内に 1 時間格納されます。ARM に対応していないコンポーネントが 1 つ以上存在していても、パフォーマンス情報は取得できますが、それは完全なエンド・ツー・エンドの情報ではなくなります。Enterprise Workload Manager for Multiplatforms にデータを送るには、アプリケーション・サーバー上で実行されているアプリケーションも、ARM V4.0 対応である必要があります。
現在のところ、Enterprise Workload Manager for Multiplatforms はデータのルーティングに関するポリシー制御や決定は行っていません。Enterprise Workload Manager for Multiplatforms はエンド・ツー・エンドのパフォーマンス像を把握するための操作にデータを提供しています。当然ながら、データを表示させるためのブラウザー・ベースのインターフェースが用意されています。ルーターやロード・バランサーといったネットワーク・アプライアンスは、Server Application State Protocol (SASP) を使って情報を取得することができます。
図 1 は、典型的なデータベースに対するWeb ベース・トランザクションの、エンド・ツー・エンドでのトランザクションのフローをモニターしたものです。この例で使用されている IBM HTTP サーバー、WebSphere® Application Server、DB2® Universal Database は、いずれも ARM V4.0 に対応しています。
図1. Enterprise Workload Manager for Multiplatforms のフロー例
トランザクションは以下のようにモニターされます。
- Web (IBM HTTP) サーバーに Web 要求が到着します。ARM 開始イベントが生成され、ローカルの Enterprise Workload Manager for Multiplatforms エージェントによって処理されます。
- 固有の相関トークンが作成され、開始時刻が取得されます。相関 ID が要求に追加されます。
- 要求が、相関 ID および Web サーバーの 識別とともにアプリケーション・サーバーに送られます。
- 要求が到着すると、アプリケーション・サーバーは Web サーバーから受け取った相関 ID を使って ARM 開始イベントを実行します。Web サーバーの場合と同様に、アプリケーション・インスタンスの開始時刻が記録されます。アプリケーションがデータベースへの要求を行うと、アプリケーション・サーバーはその要求に相関 ID を付加し、自身のサーバー識別トークンを追加します。
- 相関 ID とホストの WebSphere Application Server の識別が要求に組み込まれ、DB2 Universal Database サーバーに送られます。
- 要求が到着すると、DB2 Universal Database サーバーがその相関 ID を使って ARM 開始イベントを実行し、このトランザクションへの関わりが始まったことを追跡できるようにします。
- このトランザクションの処理が完了すると、DB2 Universal Database は 相関 ID を使って ARM 停止イベントを実行します。このイベントはデータベース・サーバーのトランザクションへの関わりの停止時刻を記録します。
- 要求は、応答に加え、WebSphere が DB2 Universal Database に送った Enterprise Workload Manager for Multiplatforms 相関 ID を含めて、アプリケーション・サーバーに返されます。
- アプリケーション・サーバーが処理を終了し、データをユーザーに返す準備を整えます。データが WebSphere を離れる際に WebSphere サーバー内で ARM 停止イベントが実行され、このサーバーのトランザクションへの関わりの停止時刻が記録されます。
- 相関 ID が含まれた応答が Web サーバーに送られます。
- Web サーバーが ARM 停止イベントを実行し、Web サーバーのトランザクションへの関わりの停止時刻を記録します。
- 応答がエンド・ユーザーに送られます。
Enterprise Workload Manager for Multiplatforms ドメイン・マネージャーは、この情報を利用して、総トランザクション時間と、各サーバーがエンド・ツー・エンドのトランザクションに関わった時間を計算することができます。ARM サポート機能はいずれ、エンド・ツー・エンドのトランザクションに関わるスイッチ、ルーター、ファイアウォールなどのネットワーク・アプライアンスでも利用できるようになるでしょう。必要な詳細情報のすべてを Enterprise Workload Manager for Multiplatforms で取得するには、各層のオペレーティング・システムとミドルウェアが ARM 対応でなければなりません。ARM サポートは既にCisco サービス・モジュールに搭載済みです。
Enterprise Workload Manager for Multiplatforms のドメイン・マネージャー接続用に設計された SASP プロトコル対応ルーターであれば、トランザクションのパフォーマンス・データを取得し、それを用いてどのパスが最も効率的かを割り出して、最適なパフォーマンスを得られるパスを検出できます。このような機能を持つルーターが近い将来利用可能になることは疑う余地がありません。
遠い将来には、ルーターが、内蔵されたソフトウェアとEnterprise Workload Manager for Multiplatforms が収集した測定情報を用いて、各要求に添付されているポリシーからそれぞれの要求が取るべきパスを決定できるようになるかもしれません。そうなれば、Web ストアの VIP 顧客のような優先順位の高いユーザーには最善のパフォーマンスのパスが与えられ、優先順位のより低い顧客、例えばあまり頻繁に購入しない Web ストアの顧客には、パフォーマンス・レベルの低いパスが与えられることでしょう。こういった枠組みによって、顧客とサービス・プロバイダーの間のサービス・レベル契約 (SLA) をよりきめ細かく管理できます。
IBM Tivoli Provisioning Manager
Tivoli Provisioning Manager は、いわばスクリプト実行環境です。Tivoli Provisioning Manager は、ポリシーによる判断やプラットフォームの選択は行いません。Tivoli Provisioning Managerは、特定の機能を実現させるために、ワークフローと呼ばれるスクリプトを実行します。Tivoli Provisioning Manager で使用されるのは、Java™ 言語に似た構成を持つ独自のスクリプト言語です。ワークフローとは何かについては、メインフレーム・ユーザーにとっては「JCL のような構文のワークフロー」、分散巣システムのユーザーにとっては「シェルや Perl スクリプト」を思い浮かべていただければよいでしょう。
Tivoli Provisioning Manager V2.1 には、ワークフローのプログラマーがプロビジョニング・サーバー用の高度なアルゴリズムを作成できるように、try-catch ブロックや Jython サポートなどの強力で進化した構文が採用されています。これらのワークフローは、IBM Director Remote Deployment Manager (RDM) や Cluster Systems Management ソフトウェアといった、ハードウェア・レベルで提供されるプロビジョニング機能と連携させることが可能です。Tivoli Provisioning Manager は、これらの下位レベル・サービスにメッセージを渡してサーバー電源のオン/オフを切り替えたり、RDM や CSM で利用可能な各種機能を実行したりできます。
Tivoli Provisioning Manager のワークフローは他のワークフローを呼び出すことができますが、これによって、上位レベルの呼び出し元に対して詳細な情報を隠蔽する、機能に対するオブジェクトの抽象化を行うことができます。例えば、サーバーをクラスターに追加する Add_Server というワークフローを実行するとしましょう。Add_Server は、使用するサーバーとそのプロビジョニング方法を特定したり、そのサーバーとそのサーバーへのネットワークをサポートするにはどのようにネットワーク接続を変更すべきかを決定したりするために、下位レベルのワークフローを呼び出します。この詳細は、単にサーバーをクラスターに追加したいだけのユーザーからはすべて隠蔽されます。このようなテクノロジーにより、インフラストラクチャーの運用全体の詳細を知悉していないプログラマーでも、有益なワークフローを開発することができます。
Tivoli Provisioning Manager には現在、Tivoli Intelligent Orchestrator と組み合わせたパッケージと、IBM Virtualization Engine との単体パッケージがあります。基本ワークフローのほとんどは、製品自体に含まれているか、Orchestration and Provisioning Automation Library (OPAL) から入手できます。独自にワークフローを記述する前に OPAL カタログをチェックして、既成のバージョンがないか調べてください。OPAL のワークフローでは通常、個別のお客様のニーズに合わせてワークフローを調整する必要がありますが、インフラストラクチャー構築のための実証済みの基礎として活用できます。OPAL カタログの検索については、参考文献を参照してください。
IBM Tivoli Intelligent Orchestrator
Tivoli Intelligent Orchestrator はインフラストラクチャー全体の資源を管理します。インフラストラクチャーをモニターし、インフラストラクチャーの最適化に使用すべき資源がないか調べます。手動、半自動、自動の 3 つの動作モードがあります。
手動モードでは、ユーザーはダイヤルとカラー・コード表示 (緑から赤) でサーバー環境を把握できます。エンド・ユーザーは、この表示を見て「現在の負荷に対応するにはどのように資源を移動すべきか」を決定することができます。その決定に基づいて、ユーザーは資源管理用の Tivoli Provisioning Manager ワークフローを実行します。
半自動モードでも、ユーザーは資源表示からサーバー環境のアクティビティーを確認できます。それに加えて、Tivoli Intelligent Orchestrator が、特定のアプリケーション・クラスターがより多くの資源を必要としているのを検出すると、どのような変更が効率的かを判断し、ユーザーにその変更の承認を求めます。ユーザーの承認を受けると、Tivoli Intelligent Orchestrator は適切な Tivoli Provisioning Manager ワークフローを実行します。
自動モードでは、ユーザーは資源表示からサーバー環境のアクティビティーを確認することはできますが、資源管理のための入力は行いません。Tivoli Intelligent Orchestrator が、特定のアプリケーション・クラスターがより多くの資源を必要としているのを検出すると、どこかに利用可能な資源がないかを調べ、その資源を Tivoli Provisioning Manager ワークフローを使って適切なクラスターに配置します。
いずれかの動作モードを Tivoli Intelligent Orchestrator のデフォルト・モードとして設定した上で、特定のクラスターに対して別のモードを設定することも可能です。異なるクラスターを異なるモードで柔軟に管理できるので、すべての資産をコンピューター任せにすることなく、Tivoli Intelligent Orchestrator 環境に慣れていくことができるのです。これらのモードは稼働中に変更できるので、大きな柔軟性をもたらします。
また、Tivoli Intelligent Orchestrator は RDM や CSM とも通信可能なので、新たに利用可能となった資源を直ちに認識できます。例えば、新しいブレードがブレード・センターに追加されると、RDM がそれを認識し、Tivoli Provisioning Manager をディスパッチして、そのブレードのプロビジョニングを行わせることができます。
Tivoli Intelligent Orchestrator は、クラスター内の資源から受け取ったデータに基づいてクラスターのアクティビティーを判断します。クラスターの負荷は Objective Analyzer (OA) を使用して判断されます。Tivoli Intelligent Orchestrator には、Web ワークロード環境に基づいた、キャパシティー・オンデマンドと呼ばれるデフォルトの OA が付属しています。OA テクノロジーを利用すれば、特定のクラスターがどのような資源を必要としているのかを判断できるようにワークロードをモデル化できます。OA は Tivoli Intelligent Orchestrator に「クラスターは何台のサーバーを必要としているか」を知らせます。これを受けて、Tivoli Intelligent Orchestrator が「クラスターの要件に応じてその資源を提供することは可能か」を決定するためにクラスターの優先順位を判断します。未使用の資源はクラスターにプロビジョニングできます。使用可能な資源がなければ、Tivoli Intelligent Orchestrator は優先順位の低いクラスターから資源を引き上げ、優先順位の高いクラスターにそれをプロビジョニングするように決定する場合もあります。
全製品の連携
Tivoli Intelligent Orchestrator、Tivoli Provisioning Manager、Enterprise Workload Manager for Multiplatforms の 3 つのキー・コンポーネントは、オンデマンド環境の礎と言えるでしょう。
図 2 は、これら 3 つのコンポーネントがどのように連携できるかを示しています。
図2. シンプルな 3 層構造の Web インフラストラクチャー
これらは以下のように連携します。
- クライアントが要求を送信します。
- Web サーバーのフロントにあるロード・バランサー (Cisco 製品など) は、HTTP サーバーの稼働状況に関する統計情報を Enterprise Workload Manager for Multiplatforms から受け取り、最も稼働状況のよい Web サーバーに作業をルーティングします。
- HTTP サーバーのクラスターにおいては、要求を受け取ったクラスターがそれを分類し、ARM の開始を発行します。要求が完了してクライアントに返送されるときには、ARM の停止が発行されます。
- 中間層の WebSphere Application Server は、アプリケーションの開始と停止に従って開始/停止の ARM コマンドを発行します。
- DB2 Universal Database も、要求の処理に合わせて、開始/停止 ARM コマンドを発行します。
- Enterprise Workload Manager for Multiplatforms ドメイン・マネージャーは、トランザクション要求中に捕捉されたすべてのデータを収集し、格納します。履歴データは 1 時間保管されます。
- Tivoli Intelligent Orchestrator は、OA を使用して Enterprise Workload Manager for Multiplatforms をポーリングして測定情報を収集し、測定情報を用いてポリシー違反の発生確率を計算します。Tivoli Intelligent Orchestrator は違反の発生確率を OA に定期的に問い合わせ、その確率に基づいて判断を下します。
- ある層についてサーバーの追加や削除が必要だと判断した場合、Tivoli Intelligent Orchestrator は、Tivoli Provisioning Manager を呼び出し、プロビジョニングまたはプロビジョニング解除(de-provisioning)用の定義済みワークフロー (あるいはスクリプト) を使用してサーバーをプロビジョニングさせます。
図 3 は、Tivoli Intelligent Orchestrator と Tivoli Provisioning Manager を使ったグリッド統合を示しています。
図3. Tivoli Intelligent Orchestrator と Tivoli Provisioning Manager を使ったグリッド統合の例
ワークフローは以下のようになります。
- 要求がグリッド資源マネージャーに送信されます。
- グリッド資源マネージャーが、作業を受けるノードを決定します。
- 選択されたノードに要求が送られます。
- 応答が要求元へ返されます。
- グリッド要求が処理されている間、Tivoli Intelligent Orchestrator 内の OA は定期的にグリッド・マネージャーをポーリングしてパフォーマンス統計とキューの深さを取得し、違反の発生確率を計算します。この発生確率に基づいて、Tivoli Intelligent Orchestrator は、他のサーバーをプロビジョニングするか既存サーバーのプロビジョニングを解除するかを決定します。
- サーバーのプロビジョニングまたはプロビジョニング解除の決定が下されると、Tivoli Intelligent Orchestrator は Tivoli Provisioning Manager を呼び出します。
Tivoli Provisioning Manager は、1 つ以上のスクリプトで構成されたワークフローを実行し、サーバーをグリッド環境にプロビジョニングしたり、プロビジョニング解除を行ったりします。
注:市販のグリッド製品が ARM に完全対応するようになれば、Enterprise Workload Manager for Multiplatforms がその環境で何が起きているかを分析できるので、前述の Web インフラストラクチャーの例のような完全に統合されたグリッド環境を開発できます。
まとめ
これまで説明してきたコンポーネントはいずれも、システム全体にとって不可欠の要素です。
-
Enterprise Workload Manager for Multiplatformsは、エンド・ツー・エンドのインフラストラクチャー内でトランザクション・フローの測定情報を収集および提供します。この情報にはEnterprise Workload Manager for Multiplatforms のインターフェースからアクセスでき、他のデバイスやコンポーネントがこの情報を使用してエンド・ツー・エンドのトランザクション内のそれぞれの決定ポイントや経路指定ポイントで最速のパスを判断することも可能です。
-
Tivoli Intelligent Orchestratorは、エンタープライズ全体で資源を効率的に配置されるようにします。
-
Tivoli Provisioning Managerは、Tivoli Intelligent Orchestrator から指示された配置を実行します。また、Director RDM や CSM などのハードウェア・ベース・テクノロジーを使用して、資源のハードウェア・コンポーネントとソフトウェア・コンポーネントを管理します。
将来的には、これらのコンポーネントはより緊密に連携するようになるでしょう。例えば、Enterprise Workload Manager for Multiplatforms OA を Tivoli Intelligent Orchestrator 内で実行し、資源使用率を調べられるようになるかもしれません。Tivoli Intelligent Orchestrator と Tivoli Provisioning Manager を併用し、要求が送られる先のアプリケーションに、適切な資源をすべて確保しておけるようにもなるでしょう。また、Enterprise Workload Manager for Multiplatforms は、相関のあるエンド・ツー・エンドの測定情報を提供することにより、オンデマンド・インフラストラクチャー内のサーバーとネットワーク・アプライアンスを最適化するための助けとなるでしょう。これらのコンポーネントは、インフラストラクチャーが自らを管理する世界への、実用への第一歩なのです。
参考文献
著者について  | 
| | Frank De Gilio has been an IBM employee since 1985. He worked in MVS system development, tools and middleware development, and has worked on projects that tied MVS to workstations in client/server and Internet environments. In 1997, he joined the IBM S/390® new technology center, where his experience in UNIX®, MVS, and Microsoft® Windows® application/middleware development was key in showing customers how to use the latest OS/390® technology in Web-enabled environments. Currently in the new IBM Design Center for On Demand Business, he shows customers how the latest on demand technologies can be used to energize their infrastructures. |
| 
| | Hilon Potter is a senior architect and certified IT specialist in the IBM Design Center for On Demand Business. He has helped IBM clients design end-to-end solutions for more than 10 years and is a regular participant at SHARE, the zSeries® Business Leaders Council and other conferences. He is also a member of the IBM Poughkeepsie Technical Vitality Affiliate, and has several patents pending and issued in the area of Web-based services. |
記事の評価
| 
