JP2006127001A - 業務システムの運用方法、運用管理システムおよび運用プログラム - Google Patents

業務システムの運用方法、運用管理システムおよび運用プログラム Download PDF

Info

Publication number
JP2006127001A
JP2006127001A JP2004311959A JP2004311959A JP2006127001A JP 2006127001 A JP2006127001 A JP 2006127001A JP 2004311959 A JP2004311959 A JP 2004311959A JP 2004311959 A JP2004311959 A JP 2004311959A JP 2006127001 A JP2006127001 A JP 2006127001A
Authority
JP
Japan
Prior art keywords
unit
business system
business
service
executing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2004311959A
Other languages
English (en)
Other versions
JP4167643B2 (ja
Inventor
Yuji Mizote
裕二 溝手
Tetsuya Hashimoto
哲也 橋本
Kenta Takahashi
健太 高橋
Hisanori Igawa
尚紀 井川
Kiichi Ishida
貴一 石田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2004311959A priority Critical patent/JP4167643B2/ja
Priority to US11/070,886 priority patent/US20060101059A1/en
Publication of JP2006127001A publication Critical patent/JP2006127001A/ja
Application granted granted Critical
Publication of JP4167643B2 publication Critical patent/JP4167643B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Stored Programmes (AREA)

Abstract

【課題】 複数のシステム装置、ソフトウエアからなるＷｅｂベースの業務システムにおいて、業務システムの構築作業および運用作業の負担を軽減することを課題とする。
【解決手段】 複数のシステム装置を有する業務システムに対する運用管理システムにおいて、記憶手段が、ユニット構成情報、共通インターフェースを構成する複数のメソッド、および、各メソッドに対応するプログラムとを記憶する。また、共通インターフェースは、少なくとも、前記ユニットに対して前記業務システムとしての動作を停止させる部分停止メソッドと、前記ユニットに対して前記業務システムとしての動作を再開させる部分再開メソッドとを有している。そして、演算処理手段が、所定システム装置に対して前記業務システムとしての動作を停止させて運用操作を行う場合に、所定システム装置を含むユニットに対して、部分停止させ、運用操作を行い、その後、部分再開させること。
【選択図】 図１

Description

本発明は、複数の装置やソフトウェアを組み合わせたスケーラブルで２４時間無停止の業務システムに対する運用方法、運用管理システムおよび運用プログラムに関する。
近年のＷｅｂベースの業務システムは、高度化・複雑化が進み、そのシステム設計、キャパシティプランニング、構築、運用の負担が多大なものとなっている。一方、オンラインサービスなどに対する２４時間サービス提供の要求がますます高まっており、２４時間無停止でのメンテナンスのニーズが大きい。
Ｗｅｂベースの業務システムは、多数のシステム装置、ネットワークおよびソフトウエアからなり、そのトポロジあるいは構成は多種多様である。そのため、システム構成設計、システム運用設計、システム構築およびシステム自動運用プログラムの開発を、案件毎に特注で実施する必要がある。
たとえば、特許文献１では、プロセッサ装置、ストレージ装置およびネットワーク装置からなる業務システム（特許文献１では仮想サーバファームと記載）の構築運用作業のうち、初期構築作業および装置構成変更（プロセッサ装置の追加削除など）の自動化を実現する技術が開示されている。これらの自動化には、ＶＬＡＮ（Virtual Local Area Network）、ＳＡＮ（Strage Area Network）の設定、プロセッサ装置とオペレーティングシステム（ＯＳ、含むミドルウエア）ブートイメージとの関連付け、プロセッサ装置と負荷分散装置との関連付けが含まれるが、プロセッサ装置上で動作するミドルウエアの設定〔装置のトポロジに応じたＪ２ＥＥ（Java（登録商標） 2 Enterprise Edition：Ｒ）サーバおよびＨＴＴＰ（Hypre Text Transfer Protcol）サーバの設定、アプリケーションの配備〕は含まれていない。さらに、２４時間無停止での業務サービスの運用に関しては、仮想サーバファーム上で従来と同じように個別に運用設計し、運用プログラムを特注で開発する必要がある。
また、ティア横断的な運用管理の自動化という観点では、特許文献２において、マルチティアで構成される業務システムの、無停止でのソフトウエアバージョンアップの方法が開示されている。なお、ティアとは、物理層あるいは論理層という意味であり、以下、単に層と記載する場合も同義である。しかし、特許文献２では、Ｗｅｂベースの業務システムにおける、システム構成上の多様性という課題に対する解決法は示されておらず、ソフトウエアバージョンアップ以外の運用操作に対する２４時間無停止対応に関しても記載がない。
以上のように、特許文献１および特許文献２の課題は、多様なシステム構成のバリエーションを持つＷｅｂベースの業務システムに対して、多様な運用シナリオでの運用プログラムの設計・開発のフレームワーク化ができていない点である。
また、このフレームワークに関する課題に関して、非特許文献１では、システム構成のバリエーション毎に異なる運用操作ロジックと、汎用的に処理できるフレームワーク部分とを分離し、構成毎に異なる運用操作ロジック部分は、Configuration Provider Interfaceと呼ばれる共通インターフェースをサポートするプラグインプログラムとしてシステム構成のバリエーション毎に実装する技術が開示されている。そして、このフレームワークにより、運用操作のＧＵＩ（Graphical User Interface）部分の共通化がなされているが、ＧＵＩを除く大部分の処理は構成のバリエーション毎に特別に開発する必要があり、フレームワークにおける処理の共通化が不十分なままである。
特表２００３−５０７８１７号公報（段落００１７〜００１９、図２） 米国特許出願公開第２００３／０００５４２６号明細書 オファーバイラン外（Ofer Biran et al），「マルチティア・クラスタ・システムにおけるアプリケーション集合の管理（Management of Application Complexes in Multi-tier Clustered Systems）」，ＩＢＭシステムジャーナル（IBM System Journal），（米国），２００３，第４２巻（Vol.42），第１号（No.1）
したがって、本発明は、複数のシステム装置、ソフトウエアからなるＷｅｂベースの業務システムにおいて、業務システムの構築作業および運用作業の負担を軽減すること、特に、２４時間無停止での業務システム運用に関する運用設計や運用プログラムの開発を軽減することを課題とする。
前記課題を解決するために、本発明は、複数のシステム装置を有する業務システムに対する運用管理システムにおいて、記憶手段が、ユニット構成情報、共通インターフェースを構成する複数のメソッド、および、各メソッドに対応するプログラムとを記憶する。また、共通インターフェースは、メソッドとして、少なくとも、前記ユニットに対して前記業務システムとしての動作を停止させる部分停止メソッドと、前記ユニットに対して前記業務システムとしての動作を再開させる部分再開メソッドとを有している。そして、演算処理手段が、所定システム装置に対して前記業務システムとしての動作を停止させて運用操作を行う場合に、所定システム装置を含むユニットに対して、部分停止させ、運用操作を行い、その後、部分再開させる。
本発明によれば、多数のシステム装置、ソフトウエアからなるＷｅｂベースの業務システムにおいて、業務システムの構築作業および運用作業の負担を軽減すること、特に、２４時間無停止での業務システム運用に関する運用設計や運用プログラムの開発を軽減することができる。
本発明に係る業務システムに対する運用管理システムの実施形態について、まず、図１〜図３を参照しながら全体の構成や業務システムの構成について説明し、次に、図４〜図２６を参照しながら業務システムの構築と運用について説明する。なお、業務システムにおいて、構築とは、エンドユーザなどへのサービス提供の開始までに行われる作業や処理のことを指す。また、運用とは、狭義にはそのサービス提供開始以降の作業や処理のことを指すが、広義には構築も含めた概念を表わすものとする。
〔全体構成〕
図１に、業務システムと該業務システムを管理する運用管理システムを含む全体の構成を示す。運用管理者は、管理用端末システム装置１０１を利用して、運用管理システム１０２に接続し、業務システム１００を管理する。運用管理システム１０２は、プロセッサ、記憶部、通信部などから構成され、モジュールであるユーザインターフェース部１１１、プラグインファイルロード処理部１１６、システム構築運用制御処理部１１７などを用いることで、様々な処理や定義付けなどを行う。
管理用端末システム装置１０１、運用管理システム１０２および業務システム１００は、運用管理ネットワーク１０４で接続されている。業務システム１００は、業務トランザクション実行ネットワーク１０５にも接続され、業務トランザクションのデータは業務トランザクション実行ネットワーク１０５上で送受信される。業務トランザクション実行ネットワーク１０５はインターネット１０８とも接続され、エンドユーザの業務トランザクションをインターネット経由で受け付ける。
業務システム１００は、負荷分散装置１０７および複数の管理対象システム装置１０６（以下、単に「システム装置１０６」と記載）から構成される。なお、本実施形態ではネットワーク装置として負荷分散装置１０７を例にとって説明するが、他ネットワーク装置であるキャッシュサーバ、ファイアウォールなども本発明に適用可能である。負荷分散装置１０７は、インターネット１０８から送信されてくるデータを複数のシステム装置１０６に振り分ける機能を有しており、プロセッサ、記憶部、通信部などから構成される。なお、負荷分散装置１０７の負荷分散機能は、各システム装置１０６にソフトウェアとして組み込まれるようにしてもよい。
また、業務システム１００の多くはＤＢサーバを利用するが、本実施形態においては、運用管理システム１０２は業務システム１００のＤＢサーバを管理対象として含んでいない。しかし、業務システム１００におけるＤＢサーバの構成は、パラレルサーバ構成により複数システム装置から構成することができ、そして、その構築運用の簡略化には本発明の運用管理手法を適用することができる。さらに、本実施形態では、業務システム１００を、Ｊ２ＥＥベースのシステムであることを想定するが、本発明はＪ２ＥＥに限定されるものではない。
プラグインファイル１０３は、業務システム１００のシステム装置１０６の構成パターンの定義情報および運用プログラム（運用手順をプログラム化したもの）を保持するファイルであり、運用管理システム１０２を経由して管理対象システム装置１０６と接続された記憶手段１３１に格納されているものとする。なお、記憶手段１３１としては、磁気ディスク、光ディスクなどがあるが、記憶できる手段であれば他のものであってもよい。また、記憶手段１３１は、運用管理システム１０２の一部として一体に構成されていてもよい。
そして、プラグインファイルロード処理部１１６が、適切なタイミング（たとえば、運用管理システム１０２の起動時）に、プラグインファイル１０３を読み込み、読み込んだ内容を構成パターン定義テーブル１１３およびプラグインプログラムコード１１５として展開する。また、運用管理システム１０２の機能をＪａｖａ（登録商標）を用いて実現した場合、プラグインプログラムコード１１５は、Ｊａｖａ（登録商標）仮想マシン上のバイトコードとして実現され、Ｊａｖａ（登録商標）仮想マシン内のヒープ（メモリ）に格納される。プラグインファイル１０３は構成パターン毎に存在し、プラグインファイル１０３毎にプラグインプログラムコード１１５が存在する。
なお、業務システム１００を構成するシステム装置１０６のトポロジは多種多様であるが、その多様性は典型的な構成パターンに類型化することができる。そして、ユニット内のシステム装置１０６のトポロジおよびシステム装置１０６で稼働させるソフトウェアの配置構成は、構成パターンに応じた規則性を持つのである。そこで、ユニットに対してその構成パターンによらない基本的な運用操作の共通インターフェースを事前に定めておき、ユニット内の構成パターンに応じて作成された共通インターフェースの実装プログラムをユニットの定義情報と関連付けて管理することにより、業務システム１００の効率のよい構築や運用を行うことができるのである。
全体構成の説明に戻り、システム装置１０６は、プロセッサ、メモリ、ディスクストレージ、ネットワークインターフェースなどからなる装置であり、オペレーティングシステム（ＯＳ）およびＯＳ上の各種サービス（プロセス）である管理サービス対象群１１０が稼動する。なお、本実施形態において、「システム装置」とは、いわゆるサーバとほぼ同義であり、また同じ意味で「ホスト」、「サーバマシン」という表現も使用する。
本実施形態では、サービスとして、ＨＴＴＰプロトコルを処理するＨＴＴＰサービス、Ｊ２ＥＥの機能を実現するＪ２ＥＥサービス、サービス実行中のエラー情報や性能情報を収集するロギングサービスなどを想定する。システム装置１０６においては、業務用の管理対象サービス群１１０に加えて、管理エージェントサービス１１９も稼動している。管理エージェントサービス１１９は、運用管理システム１０２が業務システム１００を管理するときに機能するソフトウェアである。
業務システム１００に対する運用管理作業には多種多様な作業が存在するが、大きく、初期構築作業（初期構築後のシステム装置の追加と削除も含む）と日常運用作業の２つに分類できる。
初期構築作業はさらに、業務システム１００のインフラストラクチャレベルの構築作業と業務レベルの構築作業の２つに分類することができる。前者のインフラストラクチャレベルの構築作業には、ネットワーク環境の設定（ＩＰアドレス、ＶＬＡＮ、ＳＡＮの設定など）や、オペレーティングシステムやミドルウエアなどのソフトウエアのインストールなどがあり、インフラストラクチャレベルの構築作業の終了後に、業務レベルの構築作業を実施する。業務レベルの構築作業には、管理対象サービス（以下、単に「サービス」と記載）のセットアップ、設定情報の配布、業務アプリケーション（以下、単に「アプリケーション」と記載）のデプロイなどがある。日常運用作業には、サービスの設定変更、アプリケーションのバージョンアップ、システムの計画停止/起動などがある。
本実施形態は、初期構築作業の業務レベルの構築部分と日常運用作業の簡略化/セミ自動化を実現する。インフラストラクチャレベルの構築作業に関しては、特許文献１などに開示された従来技術あるいはマニュアル作業で事前に実施されていることを想定している。
管理者による、運用管理システム１０２を利用した、業務システム１００の構築運用の大きな流れは、次のようになる。
まず、管理者はユーザインターフェース部１１１を介して、業務システム１００に対するシステム構成定義を行い、定義情報をシステム構成定義テーブル群１１４に格納する。次に、管理者は、業務システム１００の環境構築および運用の実行を、ユーザインターフェース部１１１に命令する。ユーザインターフェース部１１１は該命令をシステム構築運用制御処理部１１７に伝え、システム構築運用制御処理部１１７は、システム構成定義テーブル群１１４の情報に基づいてプラグインプログラムコード１１５を制御し、環境構築および運用に必要な命令列および設定ファイルを、負荷分散装置１０７あるいはシステム装置１０６に送信する。
システム装置１０６において、管理エージェントサービス１１９が該命令列および設定ファイルを受信し、システム装置１０６上の各種管理対象サービス群１１０に対する環境構築および運用操作命令を実行する。たとえば、サービスがＨＴＴＰサービスの場合、設定ファイルとしてｈｔｔｐｄ．ｃｏｎｆがあり、運用操作命令としてＨＴＴＰサービスの起動停止用のコマンドがある。
管理エージェントサービス１１９の好適な実現方法としては、設定ファイルの送受信にはＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を、運用操作の命令列の発行には、Ｔｅｌｎｅｔなどを利用する方法がある。
負荷分散装置１０７の好適な例としては、Ｔｅｌｎｅｔなどによる命令列の送受信や、ＦＴＰあるいはＴＦＴＰ（Ｔｒｉｖｉａｌ Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などにより設定ファイルの送受信を行うものがある。
システム構成定義テーブル群１１４は、基本情報テーブル１３００（図１３）、負荷分散装置定義テーブル１４００（図１４）、ティア共通サービス環境定義テーブル１５００（図１５）、ユニット構成定義テーブル１６００（図１６）、サーバマシン定義テーブル１７００（図１７）およびサービスインスタンス定義テーブル１８００（図１８）からなる。
〔構成パターンとユニットの概念〕
本実施形態で想定する、業務システム１００の構成パターンのバリエーションと、閉塞可能な単位であるユニットの概念を、図２および図３を参照しながら説明する。
図２は、業務システム１００の基本的な構成パターンであり、２層構造になっている。第１の層２０１は、ＨＴＴＰサービス、Ｊ２ＥＥサービスおよびロギングサービスを稼動させたシステム装置２０５をクラスタ構成としたものである。
第２の層２０２はデータ層でありＤＢＭＳ用のシステム装置２０６からなる。ＤＢＭＳも複数システム装置を用いてクラスタ構成としてもよい。負荷分散装置１０７は第１の層２０１に対して負荷分散を行う。なお、システム装置２０５、２０６は、図１のシステム装置１０６に対応する。
層（ティア）の定義はすでに前記したが、さらに加えて説明すると、層とは、同種の機能を有するシステム装置の集合であり、特定の層に属するシステム装置上には、同一種類のサービスを同じコンフィグレーション（設定）で稼動させる。
この層の概念に対して、システム装置２０５およびその上で稼動する管理対象サービス群２１０、２１１、２１２のまとまりをユニットと呼ぶ。ユニットの特徴は、特定のユニットを停止しても、業務システム１００全体としては停止せずに縮退モードで動作することができることである。２４時間無停止で、図２の構成の業務システム１００をメンテナンスする場合、ユニット単位で、停止、メンテナンス、再開を繰り返し実行すればよい。したがって、ユニットを、業務システム１００を構成する部分であり、業務システム１００全体を停止することなく停止・再開できる単位と定義する。
図３は、図２の第１の層２０１を２つに分離することにより３層構造とし、第１層３０１と第２層３０２の装置間の接続関係を１：１とした構成である。第１層３０１はＨＴＴＰサービスおよびロギングサービスを稼動させたシステム装置３１１、３１３の集合（ＨＴＴＰティアと呼ぶ）である。第２層３０２はＪ２ＥＥサービスおよびロギングサービスを稼動させたシステム装置３１２、３１４の集合（Ｊ２ＥＥティアと呼ぶ）である。なお、システム装置３１１〜３１４は、図１のシステム装置１０６に対応する。
第３層２０２は、図２の場合と同様にＤＢＭＳ用のシステム装置２０６からなる。システム装置３１１、システム装置３１２およびそれら上で稼動する管理対象サービス群３２１〜３２４が、部分縮退可能な単位であるユニット３０４を形成する。図２の構成と比べ、図３の構成の特徴的な点は、ユニットがティア横断的である、つまり、ユニットが第１層３０１および第２層３０２のシステム装置の両方を含んでいる点である。図３の業務システム１００は、ユニット３０４とユニット３０５の２ユニットから構成される。
なお、第１層３０１と第２層３０２の装置間の接続関係には１：１（図３の場合）以外に、Ｎ：１、１：Ｎ、Ｍ：Ｎの３つのバリエーションがある。
Ｎ：１の場合、第２層３０２のシステム装置１つに対して、第１層３０１のシステム装置が複数接続され、接続関係にある第１層３０１の複数のシステム装置と第２層３０２のシステム装置１つがユニットを形成し、さらにユニットが複数集まって業務システム１００を構成する。
１：Ｎの場合、第１層３０１のシステム装置１つに対して、第２層３０２のシステム装置が複数接続され、接続関係にある第１層３０１の単一システム装置と第２層３０２の複数システム装置がユニットを形成する。第１層３０１のシステム装置１つが第２層３０２の複数のシステム装置に対して負荷分散を行う必要があり、Ｎ：１の場合と異なる設定・運用が必要となる。
Ｍ：Ｎの場合は、第１層３０１の任意のシステム装置は第２層３０２のシステム装置すべてと接続関係にあり、第１層３０１の任意のシステム装置は第２層３０２のシステム装置すべてに対して負荷分散を行う。第１層３０１と第２層３０２がメッシュで接続されるため、第１層３０１および第２層３０２に含まれるシステム装置は各々独立に停止し、業務システム１００全体として部分縮退可能である。したがって、第１層および第２層のシステム装置の各々をユニットとする。
第１層３０１と第２層３０２のシステム装置に対するサービスの配置にもバリエーションがある。Ｊ２ＥＥサービスは、一般にＷｅｂコンテナ機能とＥＪＢ（Enterprise Java(登録商標) Beans）コンテナ機能という２つの機能からなることから、第１層３０１のシステム装置にＨＴＴＰサービスおよびＷｅｂコンテナとしてのＪ２ＥＥサービスを稼動させ、第２層３０２のシステム装置にＨＴＴＰサービスおよびＥＪＢコンテナとしてのＪ２ＥＥサービスを稼動させるバリエーションがある。
また、より可用性を高めた構成として、たとえば、図２の符号２０５のシステム装置を単一の装置で実現するのではなく、現用系と待機系の２系統のシステム装置から実現する構成（フェイルオーバー構成）がある。図２の拡張であるフェイルオーバー構成のバリエーションでは、各ユニット２０３、２０４は各々現用系と待機系の２つのシステム装置からなる。
以上のように、ユニットという管理単位を規定することで、業務システム１００の多様な構成のいずれにおいても、複数のユニットからなる集合として正規化することができる。ユニットとは部分閉塞再開可能な業務システムの一部分を抽象化したものであるので、特定のユニットを停止した場合、業務システム１００は停止したユニットを除く残りのユニットで縮退動作を行い、業務システム１００全体としては停止しない。また、ユニット内の構成は業務システム１００の取りうる構成パターンにより異なる。
本実施形態の説明では、業務システム１００の構成パターンのバリエーションとして、システム装置の多層構成、多層構成における層間の接続トポロジ、システム装置上のサービスの配置および装置のフェイルオーバー構成に関するバリエーションを取り上げ説明した。その他考えられるバリエーションとして、負荷分散装置１０７のフェイルオーバー構成、ＤＢのパーティションニング構成、ＤＢのパーティションニング構成に即したＪ２ＥＥサーバ用装置の構成などがあり、ユニットの考え方はこれらのバリエーションにも適用可能である。
本発明の特徴は、ユニットと呼ぶティア横断的な管理単位を設け、また各メソッドから構成される共通インターフェース５０１を利用することにより、業務システム１００の多様な構成パターンにおいて、２４時間無停止運用の運用プログラムをシステム構築運用制御処理部１１７として共通化し、ユニット内の構成パターンに依存する部分はプラグインファイル１０３として局所化することが可能となっている点である。このシステムレベル（ユニット以上の単位）の運用ロジックの共通化とユニット内の動作の局所化により、新規構成パターンへの対応は局所化された運用ロジックの部分的な追加で対応することが可能となる。
以降において、図３の業務システム１００の構成を例にとって、プラグインファイル１０３の構造（図４）、システム構成定義の構造と定義手順（図５〜図１８）、システムレベルの運用ロジックの構成パターンによらない共通処理フロー（図１９〜図２１）、構成パターンに依存する運用ロジックの処理フロー（図２２〜図２６：プラグインプログラムの実装部分）の順で説明する。
〔プラグインファイルの構造とそのロード処理〕
図４は、プラグインファイル１０３のファイル構成と構成パターン定義例を示したものである。
プラグインファイル１０３は、構成パターンのメタ情報を保持する構成パターン定義部４０１と、構成パターンに即したユニットの運用動作を実装したプログラム部４０２からなる。構成パターン定義部４０１はＸＭＬ（Extensible Markup Language）に基づくテキストファイルで、その具体的な例が構成パターン定義４１０であり、構成パターン定義４１０の左側の数字は定義ファイル内の行番号を示す。プログラム部４０２の好適な実現例は、図５に示すＪａｖａ（登録商標）インターフェースを実装したＪａｖａ（登録商標）ソースプログラムをＪａｖａ（登録商標）コンパラによりコンパイルした結果出力されるＪａｖａ（登録商標）クラスファイルである。プラグインファイル１０３は、構成パターン定義部４０１のテキストファイルとプログラム部４０２のクラスファイルをＪａｖａ（登録商標） Ａｒｃｈｉｖｅ形式でアーカイブ化したファイル（Ｊａｒファイル）である。
次に、構成パターン定義４１０について説明する。１行目（４１２）で本構成パターンの構成パターン名を指定し、２行目から５行目（４１３）にかけて構成パターンの特徴を自然言語で説明している。６行目（４１４）には、ＧＵＩツールと連動する際、ＧＵＩツール上で構成パターンの特徴を画像表示する際に利用する画像ファイルのパス情報が指定されている。なお、画像ファイルはプラグインファイル１０３に同梱されており、パス情報により画像ファイルが存在するアーカイブファイル内の位置を指定する。
７行目から１７行目（４１５）にかけて、層（ティア）の構造が定義され、図３の構成パターンは“ＨＴＴＰティア”と呼ばれる第１層３０１と“Ｊ２ＥＥティア”と呼ばれる第２の層３０２からなり、ＨＴＴＰティア３０１に属するシステム装置上にはＨＴＴＰサービスとロギングサービスを稼動させることを定義し（４１６）、Ｊ２ＥＥティア３０２に属するシステム装置上にはＪ２ＥＥサービスとロギングサービスを稼動させることを定義している（４１７）。
図５は、前記したようにプログラム部４０２の実現例であり、ユニット運用操作のＪａｖａ（登録商標）インターフェースである共通インターフェース５０１を示す図である。共通インターフェース５０１の左側の数字は、インターフェース定義の行番号を示す。共通インターフェース５０１は、図２および図３で説明した業務システム１００の多様な構成パターンに対して、共通に定義される運用操作インターフェースである。ただし、共通インターフェース５０１の実装は構成パターン毎に異なる。また、基本的にすべてのオペレーションは操作対象のシステム名とユニット名を引数として指定する。システム名は第１引数のsystem-idで、ユニット名は第２引数のunit-idで指定する。
共通インターフェース５０１の各メソッドの機能について簡単に説明する。２行目のcreateServiceDefintionsは、業務システム１００の構成パターンに即してユニット内のサービスの定義情報を自動生成するメソッドである。３行目のsetupServicesは、構成パターンのサービス構成に即してサービス群をセットアップするメソッドである。４行目のunsetupServicesは、３行目のsetupServicesでセットアップされたサービスを削除するメソッドである。５行目のstartServicesは、ユニット内のサービス群を開始するメソッドである。６行目のstopServicesは、ユニット内のサービス群を停止するメソッドである。７行目のdistributeConfigurationは、設定ファイルをシステム装置１０６に配布するメソッドである。８行目のdeployApplicationsは、ユニット内のサービスにアプリケーションを配備するメソッドである。９行目のredeployApplicationsは、ユニット内のサービスにアプリケーションを再配備するメソッドである。
１０行目のundeployApplicationsは、ユニット内のサービスからアプリケーションを削除するメソッドである。１１行目のstartApplicationsは、ユニットに配備したアプリケーションを開始するメソッドである。１２行目のstopApplicationsは、ユニットに配備したアプリケーションを停止するメソッドである。１３行目のjoinVirtualServerは、ユニットを負荷分散装置１０７の振り分け対象に追加するメソッドである。１４行目のleaveVirtualServerは、ユニットを負荷分散装置１０７の振り分け対象から削除するメソッドである。また、１５行目のacceptRequestは、負荷分散装置１０７がインターネット１０８経由で受信するユーザトランザクションをユニット内のシステム装置１０６にルーティングするメソッドである。１６行目のblockRequestは、負荷分散装置１０７がインターネット１０８経由で受信するユーザトランザクションに対するユニット内のシステム装置１０６へのルーティングを停止するメソッドである。
このように、各メソッドにより共通インターフェース５０１が構成され、それが記憶手段１３１に記憶されている。
図６に、構成パターン定義テーブル１１３の詳細を示す。構成パターン定義テーブル１１３は、構成パターン名フィールド６０１、クラスアドレスフィールド６０２、説明用テキストフィールド６０３、画像用ＵＲＬフィールド６０４、ティア名フィールド６０５およびサービス種別名フィールド６０６の６つフィールド（カラム）からなるテーブルである。
構成パターン名フィールド６０１は、図４の符号４１２に対応する。クラスアドレスフィールド６０２は、プラグインプログラムコード１１５のＪａｖａ（登録商標）仮想マシン（ＶＭ）ヒープ上のアドレス情報を保持する。説明用テキストフィールド６０３は、図４の符号４１３に対応する。画像用ＵＲＬフィールド６０４は、図４の符号４１４に対応する。ティア名フィールド６０５は、図４の符号４１５に対応する。定義フラグメントである４１５の部分は２つのティアから構成されることを示しており、それぞれレコード６１１とレコード６１２のように展開される。サービス種別フィールド６０６は、図４の符号４１６および符号４１７に対応し、それぞれ、レコード６２１、６２２およびレコード６２３、６２４のように展開される。
プラグインファイルロード処理部１１６によるプラグインファイル１０３のロード手順は、次のとおりである。まず、記憶手段１３１上の特定のディレクトリ下にあるファイル一覧を取得する。次に、取得したファイル一覧の各ファイルに対して、プラグインファイル１０３を読み込み、構成パターン定義４１０を構成パターン定義テーブル１１３に展開し、プログラム部４０２のクラスファイルをＪａｖａ（登録商標）ＶＭのヒープ上にバイトコード（クラス）として展開し、そのアドレス情報を構成パターン定義テーブル１１３のクラスアドレスフィールド６０２に設定する。
〔管理者によるシステム構成定義の画面と手順〕
図７から図１２は、管理者によるシステム構成定義の手順を示したものである。管理者が定義した情報は、図１３から図１７に示すテーブル群に格納される。これらの画面は、ユーザインターフェース部１１１が制御し、表示する。
図７に、システム構成パターン選択画面７００を示す。運用管理システム１０２が構成パターン定義テーブル１１３に格納されているパターン名（フィールド６０１）の一覧をプルダウンメニュー７０１として表示する。管理者は、プルダウンメニュー７０１から適切な構成パターン名を選択し、テキストフィールド７０５にシステム名を入力し、ボタン７０２をクリックし、次画面である負荷分散装置定義画面８００（図８）に遷移する。図３の業務システム１００の場合、プルダウンメニュー７０１から選択すべき適切な構成パターンは“ＨＴＴＰ分離２ティア構成”である。符号７０３の画像および符号７０４の説明文は、それぞれ構成パターン定義テーブル１１３の画像用ＵＲＬフィールド６０４および説明用テキストフィールド６０３に対応する。
システム構成パターン選択画面７００でのユーザ入力情報は、図１３に示す基本情報テーブル１３００に格納される。テキストフィールド７０５の値はテーブル１３００のシステム名フィールド１３０１に格納され、プルダウンメニュー７０１で選択された構成パターン名はパターン名フィールド１３０２に格納される。
レコード１３１１は、図３に示す業務システム１００のシステム名が“システム１”であり、それが構成パターン“ＨＴＴＰ分離２ティア構成”に属していることを示している。構成パターン名１３０２の値をキーに、構成パターン定義テーブル１１３を検索することにより、構成パターンのメタ情報を参照することができる。
図８に、負荷分散装置１０７の負荷分散装置定義画面８００を示す。管理者は、負荷分散装置１０７の論理名称８０１、運用管理ＩＰアドレス８０２、仮想サーバのＩＰアドレス８０３、ポート番号８０４を入力し、ボタン８０５をクリックすることにより次画面であるサービス環境定義画面９００（図９）に遷移する。運用管理ＩＰアドレス８０２は、運用管理システム１０２が負荷分散装置１０７に運用管理命令列を発行する際、負荷分散装置１０７に接続するのに利用するＩＰアドレスである。仮想サーバのＩＰアドレス８０３は、いわゆるＶＩＰ（Ｖｉｒｔｕａｌ ＩＰ）と呼ばれるアドレスであり、エンドユーザがインターネット１０８を介して業務システム１００に接続する際に利用するＩＰアドレスである。
負荷分散装置定義画面８００でのユーザ入力情報は、図１４に示す負荷分散装置定義テーブル１４００に格納される。論理名称８０１、運用管理ＩＰアドレス８０２、仮想サーバのＩＰアドレス８０３、ポート番号８０４はそれぞれ、テーブル１４００の負荷分散装置名フィールド１４０１、運用管理ＩＰアドレスフィールド１４０３、仮想ＩＰアドレスフィールド１４０４、ポート番号フィールド１４０５に格納される。システム名フィールド１４０２には、そのとき定義中のシステムの名称（７０５の値）が格納される。図８の負荷分散装置定義画面８００での入力例が、レコード１４１１として格納されている。
図９に、ティア共通のサービス環境定義（パラメータ定義）画面９００を示す。図３に示すように、異なるユニットのサービスにおいても、それぞれのユニットに属するサービスが同一層（ティア）に属する場合、これらサービスのパラメータ定義は基本的に同じとなる。たとえば、図３の第２層３０２に属するＪ２ＥＥサービス３２３の場合、ユニット３０４とユニット３０５のそれぞれに対してＪ２ＥＥサービスを定義する必要があるが、これら２つのサービスは共通の環境定義（パラメータ定義）を持つため、サービス種別単位で一括して定義する。ただし、すべてのパラメータがサービス種別単位で一括して定義できるわけではなく、トポロジや構成により定まり個別サービスインスタンス毎に値が異なるパラメータもある。トポロジや構成により定まるパラメータの解決方法は、図２２のcreateServiceDefinitionsで説明する。
図９のサービス環境定義画面９００で、メニュー９０１、９０２から定義対象の層（ティア）とサービス種別を選択し、サービス種別毎の環境定義を一括して行う。図９は、Ｊ２ＥＥティア上のＪ２ＥＥサービスに共通な環境定義を行う（フィールド９０３部分に対応）場面を示している。環境定義は、各種パラメータに対して適切な値を入力あるいは選択することにより行う。環境定義対象のサービス種別がＪ２ＥＥサービスの場合、さらに、Ｊ２ＥＥアプリケーションの指定も必要であり、フィールド９１１にて、Ｊ２ＥＥアプリケーションのファイルパスを指定する。すべての層（ティア）のサービスの環境定義が終了した場合、ボタン９０５をクリックして、次画面であるユニット構成定義画面１０００（図１０）に遷移する。
サービス環境定義画面９００でのユーザ入力情報は、図１５に示すティア共通サービス環境定義テーブル１５００に格納される。そのとき定義中のシステムのシステム名７０５がティア共通サービス環境定義テーブル１５００のシステム名フィールド１５０１に格納される。メニュー９０１および９０２で選択した環境定義対象のティアとサービス種別の情報を、それぞれ、ティア名フィールド１５０２およびサービス種別名フィールド１５０３に格納する。フィールド９０３で定義したパラメータ定義情報は、パラメータ名と入力値からなる名前値ペアのリストとして環境定義フィールド１５０４に格納される。フィールド９１１で定義したアプリケーション情報はアプリケーション情報フィールド１５０５に格納される。
図９のサービス環境定義画面９００での入力例が、上から３つめのレコード１５１１として格納されている。なお、レコード１５１１の定義は、Ｊ２ＥＥティア３０２上の任意のユニット内のＪ２ＥＥサービスに対する共通の定義に関してのみであり、個別サービスインスタンスに関する環境定義（たとえばＪ２ＥＥサービス３２３に対する個別の環境定義）は、レコード１５１１の内容に基づいて、図２２で説明するcreateServiceDefintionsで生成する。
図１０、図１１は、ユニットの構成とシステム装置の配置を定義する画面である。図１０のユニット構成定義画面１０００において、ユニットの追加の場合、ボタン１０１１をクリックすることにより新規ユニットが追加され、ユニットの削除の場合、ボタン１０１２をクリックすることにより削除を行う。
ユニット追加時には、符号１０２０の行が新たに追加される。図１０は、ユニットがまったく定義されていない状態からボタン１０１１をクリックした直後の画面イメージである。
１０２０の行が追加されたのち、新規ユニットのユニット名フィールド１００１にユニット名を入力し、システム装置選択プルダウンメニュー１００２および１００３から、システム装置を１つずつ選択し、それぞれをＨＴＴＰティアおよびＪ２ＥＥティアのシステム装置とする。以上の操作により、図３のユニット３０４がユニット名“ユニット１”として定義され、ユニット３０５も同様にして定義する。
ユニット構成定義画面１０００でのユーザ入力情報は、図１６に示すユニット構成定義テーブル１６００に格納される。
ユニット名の指定（１００１）と新規ユニット内に配置するサーバマシンを２つ選択（１００２、１００３）したことにより、ユニット構成定義テーブル１６００に対して新規レコードが２つ追加される。追加された２つのレコードの各々に対して、そのとき定義対象となっているシステムのシステム名７０５の値がシステム名フィールド１６０１に、ユニット構成定義画面１０００のユニット名１００１で指定した値がユニット名フィールド１６０２に、選択したサーバマシン名（１００２の値あるいは１００３の値）がサーバマシン名フィールド１６０３に、サーバマシンが属するティア名（１００２の場合は“ＨＴＴＰティア”、１００３の場合“Ｊ２ＥＥティア”となる）がティア名フィールド１６０４に格納される。図１０のユニット構成定義画面１０００での入力例で生成された新規レコードは、レコード１６１１、レコード１６１２に対応している。
プルダウンメニュー１００２あるいは１００３に所望のシステム装置が事前に定義されていない場合は、プルダウンメニューから新規１００４を選択し、サーバマシン定義画面１１００（図１１）に遷移し、システム装置を定義する。システム装置の定義は、システム装置の論理名であるサーバマシン名１１０１、業務トランザクション実行ネットワーク１０５上のＩＰアドレスである業務実行ＩＰアドレス１１０２、運用管理ネットワーク１０４上のＩＰアドレスである運用管理ＩＰアドレス１１０３および管理エージェントサービス１１９のポート番号である運用サービスポート番号１１０４からなる。
サーバマシン定義画面１１００でのユーザ入力情報は、図１７に示すサーバマシン定義テーブル１７００に格納される。図１１のサーバマシン定義画面１１００のサーバマシン名１１０１、業務実行ＩＰアドレス１１０２、運用管理ＩＰアドレス１１０３、運用サービスポート番号１１０４を、それぞれ、サーバマシン定義テーブル１７００のサーバマシン名フィールド１７０１、実行ＩＰフィールド１７０２、管理ＩＰフィールド１７０３、管理ポートフィールド１７０４に格納する。図１１のサーバマシン定義画面１１００での入力例が、レコード１７１１として格納されている。以上の操作により、業務システム１００を、図３に示す構成の業務システム１００として定義できた。次に、これらの定義を元に、業務システム１００の構築、運用の処理について説明する。
〔システムレベルの構築運用ロジック：システム構築運用制御処理部１１７の処理フロー〕
共通インターフェース５０１を利用した、業務システム１００の構成に依存しない汎用的な、業務システム１００の構築、運用の手順（システム構築運用制御処理部１１７による処理）を、図１９〜図２１に示す。図１９および図２０は業務システム１００の構築に関しての処理であり、図２１は業務システム１００の運用に関しての処理である。そして、図１９〜図２１の手順中の各メソッド（図５）の処理については、図２２〜図２６を参照しながら説明する。
図１９から図２１において、システム構築運用制御処理部１１７が共通インターフェース５０１のメソッドを起動する。その起動手順は、操作対象の業務システム１００が属するパターン名を基本情報テーブル１３００のパターン名フィールド１３０２から取得し、パターン名に対応する共通インターフェース５０１の実装クラスのクラスアドレスを構成パターン定義テーブル６００のクラスアドレスフィールド６０２から取得する。そして、Ｊａｖａ（登録商標）言語のＲｅｆｌｅｃｔｉｏｎ機能を利用することにより、実装クラスのメソッドを呼び出す。
図１９は、システム構築運用制御処理部１１７による業務システム１００の構築手順を示したフローチャートである。本手順は図１０のボタン１００５のクリックを契機に実行される。本手順の実行により、システム装置内の各種サービスのセットアップと環境設定が終了し、業務システム１００が起動可能な状態となる。
まず、構築対象のシステム装置（３１１〜３１４）の名称をキーに負荷分散装置定義テーブル１４００から定義情報を取得し、負荷分散装置定義に基いて、負荷分散装置１０７に接続し、仮想サーバとポートの定義を実行する、つまり、仮想サーバと仮想サーバ上のポートの定義を指示する命令列を、運用管理ＩＰアドレス（１４０３）を介して接続した負荷分散装置１０７に対して送信する（ステップ１９０１）。負荷分散装置１０７の好適な例は、仮想サーバ定義として、仮想ＩＰアドレス（１４０４）とポート番号（１４０５）を引数として仮想サーバを定義する手段を有する。次に、構築対象のシステム名をキーにユニット構成定義テーブル１６００からユニットを検索し（ステップ１９０２）、検索結果の各ユニットに対して（ステップ１９０３で「はい」の場合、図１６の場合“ユニット１”と“ユニット２”の各々に対して）、ステップ１９０４、１９０５、１９０６、１９０７を実行する。
前記各ユニットに対して、共通インターフェース５０１のcreateServiceDefinitionsを実行し（ステップ１９０４）、サービスインスタンス定義テーブルを生成する。次に、共通インターフェース５０１のsetupServicesを実行し（ステップ１９０５）、ステップ１９０４で生成した定義に基づいてシステム装置１０６上にサービスをセットアップする。次に、共通インターフェース５０１のjoinVirtualServerを実行し（ステップ１９０６）、ステップ１９０５で生成したサービスのうち、負荷分散装置１０７の振り分け対象となるサービスに対して、負荷分散装置１０７の振り分け対象として追加する。最後に、共通インターフェース５０１のdistributeConfigurationを実行し（ステップ１９０７）、ステップ１９０４で生成した環境定義情報からコンフィグレーションファイルを生成し、ステップ１９０５でセットアップしたサービスに対して前記ファイルを送付する。
図２０は、システム構築運用制御処理部１１７が実行する業務システム１００の起動手順を示すフローチャートである。本手順は、図１２のボタン１２０５のクリックを契機に実行される。本手順の実行により、システム装置内の各種サービスの起動とアプリケーションのデプロイが実行され、業務システム１００がエンドユーザからの要求を受け付ける。
まず、起動対象のシステム名をキーにユニット構成定義テーブル１６００からユニットを検索し（ステップ２００１）、検索結果の各ユニットに対して（ステップ２００２で「はい」の場合、図１６の場合“ユニット１”と“ユニット２”の各々に対して）、ステップ２００３、２００４、２００５、２００６を実行する。
前記各ユニットに対して、共通インターフェース５０１のstartServicesを実行し（ステップ２００３）、ユニット内のサービスを起動する。次に、共通インターフェース５０１のdeployApplicationsを実行し（ステップ２００４）、ユニット内のサービスに対して、アプリケーションをデプロイする。次に、共通インターフェース５０１のstartApplicationsを実行し（ステップ２００５）、ユニット内のサービスに対してアプリケーションを開始する。最後に、共通インターフェース５０１のacceptRequestを実行し（ステップ２００６）、エンドユーザのリクエストの受付を開始する。
図２０では業務システム１００の起動手順を示したが、業務システム１００の停止手順は図２０の場合とほぼ同様である。業務システム１００を停止する場合、図１２のボタン１２０６をクリックすることでシステム構築運用制御処理部１１７が処理を開始し、図２０におけるステップ２００３、２００４、２００５、２００６の代わりに、起動と逆の順番で各ステップの逆オペレーション、つまり、blockRequest、 stopApplications、 stopServicesを実行すればよい。ただし、deployApplicationsの逆オペレーションであるundeployApplicationsは実行しない。
以上で業務システム１００の構築処理が終了し、その後、画面がシステム運用画面１２００（図１２、説明は後記）に遷移して、システム構築運用制御処理部１１７による運用処理が開始されることになる。運用操作としては、ユニット単位の部分停止（ボタン１２０２あるいは１２０４）、部分再開（ボタン１２０１あるいは１２０３）、システム全起動（ボタン１２０５）、システム全停止（ボタン１２０６）がある。それぞれのボタンをクリックすることにより、システム構築運用制御処理部１１７がそれぞれの処理を開始する。
前記の基本運用操作に加えて、パラメータの変更、業務アプリケーションの変更（バージョンアップを含む入れ替え）およびユニット構成変更（ユニットの追加と削除）などがあり、それぞれボタン１２０７、１２０８、１２０９をクリックして、図９あるいは図１０に示す画面に遷移して変更定義を行い、システム構築運用制御処理部１１７が変更処理を実行する。
次に、業務システム１００の運用に関する処理について、業務アプリケーションを変更する場合を例にとって、その手順について説明する。図２１は、システム構築運用制御処理部１１７が実行する業務アプリケーションのバージョンアップ（入れ替え）手順を示すフローチャートである。本手順は、業務システム１００の運用中に、図１２のＡＰ変更用のボタン１２０８のクリックから遷移する環境定義画面９００（図９）のフィールド９１１の変更後開始され、業務システム１００を全停止することなく、業務アプリケーションの入れ替えを実行する。
まず、構築対象のシステム名をキーにユニット構成定義テーブル１６００からユニットを検索し（ステップ２１０１）、検索結果の各ユニットに対して（ステップ２１０２で「はい」の場合、図１６の場合“ユニット１”と“ユニット２”の各々に対して）、ステップ２１０３、２１０４、２１０５、２１０６、２１０７を実行する。
前記各ユニットに対して、共通インターフェース５０１のblockRequestを実行し（ステップ２１０３）、業務アプリケーションを変更するユニットへの負荷分散装置１０７によるエンドユーザからのリクエストの振り分けを停止する。次に、共通インターフェース５０１のstopApplicationsを実行し（ステップ２１０４）、当該ユニット内のサービスに対して業務アプリケーションの実行を停止する。次に、共通インターフェース５０１のredeployApplicationsを実行し（ステップ２１０５）、当該ユニット内のサービスに対してアプリケーションを入れ替える。次に、共通インターフェース５０１のstartApplicationsを実行し(ステップ２１０６)、業務アプリケーションを開始する。最後に、共通インターフェース５０１のacceptRequestを実行し（ステップ２１０７）、負荷分散装置１０７による当該ユニットへのエンドユーザからのリクエストの振り分けを再開する。
このように、前記手順のステップ２１０３〜２１０７において、特定のユニットのみを停止して業務アプリケーションを入れ替えることで、業務システム１００全体としてはサービスを停止させず、エンドユーザからの要求を残りのユニットで処理することができる。
次に、運用操作の他の例として、２４時間無停止でのパラメータ定義更新手順について述べる。パラメータ定義の変更方法は、図９のフィールド９０３にパラメータの変更値を入力し、ティア共通サービス環境定義テーブル１５００の更新後、システム構築運用制御処理部１１７がパラメータ定義更新手順を開始する。処理フローは図２１とほぼ同様であり、順次ユニットを閉塞して業務システム１００を部分縮退させながら、停止中のユニットに対して環境定義の再配布処理を実行していく。具体的には、ステップ２１０４、２１０５、２１０６の代わりに、 stopServicesを実行してユニットのサービスを停止するステップ、setupServicesのステップ１９０５およびステップ１９０７と同じ手順を実行し、環境定義の再設定と設定ファイルの再配布を行うステップ、および、startServicesによりサービスを開始するステップ、に差し替えればよい。
なお、図２１の処理フローおよび前記した２４時間無停止でのパラメータ定義更新手順は、２４時間無停止運用時の典型的な処理パターンを示している。特定のユニットを停止し（blockRequest、stopServices、stopApplicationsのいずれかあるいは組み合わせの実行）、ユニット停止中に運用の目的に応じたメンテナンス操作を実行し、ユニットを再開させる(acceptRequest、startServices、startApplicationsのいずれかあるいは組み合わせの実行)処理を、業務システム１００を構成するユニットに対して繰り返し実行する。
また、図２１の処理フローで示されるメンテナンス操作は、アプリケーションの再配備（redeployApplications）であり、前記した２４時間無停止でのパラメータ定義更新手順では設定ファイルの再配布である。その他想定される運用操作として、ＯＳのパッチを適用する処理、記憶手段のバックアップなどがあり、それぞれの２４時間無停止運用時には、それぞれの目的に応じたユニット単位での運用操作を実装したプログラムを事前に準備し、図２１の処理フローと同様の手順で呼び出せばよい。
さらに、図１９、図２０は業務システム１００を最初に構築する際の手順である。これらの手順は、業務システム１００構築後にユニットの構成を変更（追加および削除）する場合にも適用できる。その場合、図１９、図２０が示すように業務システム１００を構成する全てのユニットに対して実行する必要はなく、特定ユニットに対してのみ処理するようにすればよい。また、業務システム１００の負荷が、それが想定する処理能力を超える場合、新規ユニットを追加することにより、処理能力を超えた部分の負荷に対応することができる。逆に、想定より負荷が大幅に低い場合は、稼動中のユニットの停止後にそのユニットを削除すればよい。ユニットの追加削除は、図１２のユニット構成変更ボタン１２０９により遷移する図１０の画面１０００で行う。
〔構成パターンに依存する運用ロジックの処理フロー〕
続いて、図３の業務システム１００が属する構成パターンに対する共通インターフェース５０１の実装例の処理フローについて、図２２〜図２６のフローチャートを参照しながら説明する。これらは、前記したように、業務システム１００の構成に依存しない構築や運用の手順（図１９〜図２１）における、各メソッドの処理である。各メソッドの処理内容は、システム装置１０６の構成パターンにより、変化することもある。
各メソッドの概要は、createServiceDefinitions（図５）が、図７から図１２で行った構成定義情報からサービスインスタンス定義情報テーブル１８００を生成するものであり、その他のメソッドは、テーブル１８００を利用して負荷分散装置１０７あるいはシステム装置１０６に各種構築運用命令や設定ファイルなどを送信するものである。
図２２は、createServiceDefinitionsメソッド実装の処理手順を示すフローチャートである。本手順が生成するサービスインスタンス定義情報は、図１８に示すサービスインスタンス定義テーブル１８００に格納される。図７から図１２で行った構成定義では、装置のトポロジとシステム装置情報、ティア共通に設定するサービス種別毎のパラメータを定義しているが、各装置上に稼動させる個別サービスのインスタンス定義はまだ実施していない。本処理フローは、ユニット構成定義テーブル１６００、サービス構成を保持する構成パターン定義テーブル１１３、ティア共通サービス環境定義テーブル１５００およびサーバマシン定義テーブル１７００を利用して、これら個別サービスのインスタンス定義を生成するものである。
まず、メソッドの引数であるシステム名とユニット名をキーにユニット構成定義テーブル１６００を検索し（ステップ２２０１）、検索結果の各レコードに対して（ステップ２２０２、“ユニット１”の場合、レコード１６１１とレコード１６１２の２つ）、ステップ２２０３からステップ２２０７を実行する。
ステップ２２０３において、基本情報テーブル１３００から引数のシステム名に対応する構成パターン名フィールド１３０２の値を取得し、取得した該パターン名（“システム１”の場合“ＨＴＴＰ分離２ティア構成”）と現在処理中のレコードのティア名（ティア名フィールド１６０４の値）をキーにティアがホスティングするサービス種別（サービス種別名フィールド６０６の値）の一覧を構成パターン定義テーブル１１３から取得する。
取得した各サービス種別に対して（ステップ２２０４）、サービスインスタンス定義を行う（ステップ２２０５〜２２０７）。たとえば、図６では、ＨＴＴＰティア(６１１)の場合、サービス種別としてＨＴＴＰサービス（６２１）とロギングサービス（６２２）の２種類があることから、ＨＴＴＰティアに属する各サーバマシンに対して、ＨＴＴＰサービスとロギングサービスの２つのサービスインスタンス定義を行う。Ｊ２ＥＥティア(６１２)も同様であり、図３の業務システム１００の場合、全体としてシステム装置が４つ（３１１〜３１４）あり、それぞれにサービスを２つ稼動させることから、計８つのサービスインスタンス定義を生成する(図１８)。
サービスインスタンス定義は、ステップ２２０５、ステップ２２０６、ステップ２２０７からなる。まず、サービスインスタンス定義テーブル１８００に新規サービスインスタンス定義レコードを生成する。該新規サービスインスタンス定義レコードのサービス名フィールド１８０１には、サービスインスタンス定義テーブル１８００で一意性が保証できる名前を自動生成し、格納する。該新規サービスインスタンス定義レコードのシステム名フィールド１８０２、ユニット名フィールド１８０３、サーバマシン名フィールド１８０４およびティア名フィールド１８０５には、それぞれ引数で指定されたシステム名、引数で指定されたユニット名、現在処理中のサーバマシンの名前（サーバマシン名フィールド１６０３の値に対応）およびティアの名前（ティア名フィールド１６０４の値に対応）を設定する。サービス種別１８０８には現在処理中のサービス種別の名前（サービス種別名フィールド６０６の値に対応）を格納する（ステップ２２０５）。
次に、引数で指定されたシステム名、現在処理中のサービス種別名および現在処理中のティアの名前（ティア名フィールド１６０４の値に対応）をキーに、ティア共通サービス環境定義テーブル１５００を検索し、環境定義（１５０４）とアプリケーション情報（１５０５）を取得し、前記新規サービスインスタンス定義レコードの環境定義フィールド１８０６とアプリケーション情報フィールド１８０７に格納する（ステップ２２０６）。なお、前記ステップ２２０６では、ティア共通に定義したパラメータ定義およびアプリケーション情報を同一ティアに属する個別サービスインスタンス定義に展開（コピー）している。
最後に、システム装置の情報（サーバマシン定義テーブル１７００）と構成パターンのトポロジから定まるパラメータを、前記新規サービスインスタンス定義レコードの環境定義フィールド１８０６のリストに追加する（ステップ２２０７）。たとえば、図３の例では、ホスト１（３１１）上のＨＴＴＰサービス３２１が接続するＪ２ＥＥサービスは、同一ユニット３０４内のホスト２（３１２）上のＪ２ＥＥサービス３２３である。したがって、ＨＴＴＰサービス３２１の設定パラメータである“接続するＪ２ＥＥサービスのアドレス情報”パラメータの値は、サーバマシン定義テーブル１７００からそのネットワークアドレスは“１９２．１．１．２”であることが定まる。このような構成に応じたパラメータ解決手順は、Ｊａｖａ（登録商標）言語と各種テーブル（１１３、１１４）を参照する処理を構成毎のプラグインファイル１０３にハードコードすることにより実現できる。
図２３は、setupServicesメソッド実装の処理手順を示したフローチャートである。まず、引数であるシステム名とユニット名をキーにサービスインスタンス定義テーブル１８００を検索し（ステップ２３０１）、検索結果の各サービスインスタンス定義に対して（ステップ２３０２）サービスセットアップを実行する。サービスセットアップは、以降のステップからなり、まず、サービスインスタンス定義のサーバマシン名（１８０４）に対するネットワーク情報（管理ＩＰアドレス（１７０３）とポート番号（１７０４））を、サーバマシン定義テーブル１７００から取得する（ステップ２３０３）。次に、前記管理ＩＰアドレスと前記ポート番号を用いて、サーバマシン上の管理エージェントサービス１１９に接続し、サービス種別に応じたサービスのセットアップの命令列を送付し、管理エージェントサービス１１９がその命令列を実行する（ステップ２３０４）。
なお、unsetupServicesの手順は図２３とほぼ同様であり、ステップ２３０４の代わりに、システム装置１０６上のサービスにかかわる各種ファイルおよび設定を削除することを指示する命令列を管理エージェントサービス１１９に送信し、負荷分散装置１０７に対しても図１９のステップ１９０１で行った仮想サーバに関する定義とjoinVirtualServerで行ったリアルサーバに関する定義を削除する命令列を送信する。
また、distributeConfigurationの手順は図２３とほぼ同様であり、ステップ２３０４の代わりに、各種設定パラメータの名前値ペアのリストである環境定義（１８０６）からサービス種別に応じた設定ファイルを生成し、管理エージェントサービス１１９に対して生成した前記設定ファイルを配布すればよい。生成されるファイルの例として、サービス種別がＨＴＴＰサービスの場合、ｈｔｔｐｄ.ｃｏｎｆと呼ばれるファイルなどがある。
さらに、startServicesの手順は図２３とほぼ同様であり、ステップ２３０４の代わりに、管理エージェントサービス１１９に対してサービス種別に応じたサービス起動処理の命令列を送信すればよい。
また、stopServicesの手順は図２３とほぼ同様であり、ステップ２３０４の代わりに、管理エージェントサービス１１９に対してサービス種別に応じたサービス停止処理の命令列を送信すればよい。
続いて、図２４は、deployApplicationsメソッド実装の処理手順を示すフローチャートである。まず、引数であるシステム名とユニット名をキーにサービスインスタンス定義テーブル１８００を検索し（ステップ２４０１）、検索結果の各サービスインスタンス定義に対して（ステップ２４０２）、アプリケーション情報フィールド１８０７がｎｕｌｌでない場合（ステップ２４０３）、アプリケーションのデプロイ処理を実行する。アプリケーションのデプロイ処理は、以降のステップからなり、まず、サービスインスタンス定義のサーバマシン（１８０４）に関するネットワーク情報（管理ＩＰアドレス（１７０３）とポート番号（１７０４））をサーバマシン定義テーブル１７００から取得する（ステップ２４０４）。次に、ステップ２４０４で取得した情報に基づいて、管理エージェントサービス１１９に接続し、サービスインスタンス定義テーブル１８００のアプリケーション情報フィールド１８０７で指定されるアプリケーションのファイルの送信後、サービス種別に応じたアプリケーションのデプロイ処理の命令列を送信する（ステップ２４０５）。
なお、undeployApplicationsの手順は図２４とほぼ同様であり、ステップ２４０５において、アプリケーションのアンデプロイ命令を、管理エージェントサービス１１９に送信する。
また、startApplicationsの手順は図２４とほぼ同様であり、ステップ２４０５において、アプリケーションの開始命令を、管理エージェントサービス１１９に送信する。
さらに、stopApplicationsの手順は図２４とほぼ同様であり、ステップ２４０５において、アプリケーションの停止命令を、管理エージェントサービス１１９に送信する。
次に、図２５は、redeployApplicationsメソッド実装の処理手順に示すフローチャートである。まず、undeployApplicationメソッドを実行し、ユニット内のアプリケーションをアンデプロイする（ステップ２５０１）。そして、引数であるシステム名とユニット名をキーにサービスインスタンス定義テーブル１８００を検索し（ステップ２５０２）、検索結果の各サービスインスタンス定義に対して（ステップ２５０３）、サービスインスタンス定義のティア名（１８０４）およびサービス種別（１８０８）をキーにティア共通サービス環境定義テーブル１５００からアプリケーション情報（１５０５）を取得し（ステップ２５０４）、取得したアプリケーション情報を、サービスインスタンス定義テーブルのアプリケーション情報フィールド１８０４に上書きする（ステップ２５０５）。最後に、deployApplicationsを起動する（ステップ２５０６）。
図２６は、joinVirtualServerメソッド実装の手順を示すフローチャートである。図３の業務システム１００の場合は、ユニット中のＨＴＴＰサービスが負荷分散の対象（振り分け対象のことをリアルサーバと呼ぶ）であることを負荷分散装置１０７に指示し（リアルサーバ定義）、仮想サーバとリアルサーバの振り分け定義を行う。たとえば、図３のユニット３０４を仮想サーバに追記する場合、ホスト１のＨＴＴＰサービス３２１に対してリアルサーバ定義を行い、“１９２．１．１００”をＶＩＰに持つ仮想サーバに対して前記リアルサーバを振り分けるよう定義する。
図２６の処理フローは、次のとおりである。まず、引数のシステム名をキーに負荷分散装置定義情報テーブル１４００から負荷分散装置１０７の運用管理ＩＰアドレス（１４０３）と仮想サーバ情報（仮想ＩＰアドレス（１４０４）とポート番号（１４０５））を取得する（ステップ２６０１）。次に、引数であるシステム名、ユニット名および負荷分散の対象となるティア名（図３の構成の場合、ＨＴＴＰティアが負荷分散の対象となる）をキーにサービスインスタンス定義テーブル１８００を検索する（ステップ２６０２）。検索結果の各サービスインスタンス定義に対して（ステップ２６０３）、仮想サーバの振り分け対象への参加処理を実行する。振り分け対象への参加処理は、以降のステップからなる。まず、サービスが稼動するサーバマシン（１８０４）の実行ＩＰアドレス（１７０２）をサーバマシン定義テーブル１７００から取得する（ステップ２６０４）。つまり、この実行ＩＰアドレスがリアルサーバのＩＰアドレスとなる。なお、本実施形態では、リアルサーバのポート番号は仮想サーバのポート番号と同じ値を利用することを想定する。
図２６の処理フローに戻ると、次に、先に取得した負荷分散装置定義情報のポート情報（１４０５）とサーバマシンの実行ＩＰアドレス（１７０２）から、負荷分散装置１０７への振り分け対象定義（リアルサーバ定義）の命令列を生成し、負荷分散装置１０７に送信する（ステップ２６０５）。なお、負荷分散装置１０７の好適な例としては、振り分け対象のＩＰアドレスおよびポート番号を引数にリアルサーバを定義する手段を有している。最後に、仮想サーバがリアルサーバの振り分けを行うことを指示する命令列を生成し、負荷分散装置１０７に送信する（ステップ２６０６）。前記手順において、負荷分散装置１０７との通信には、負荷分散装置定義情報テーブル１４００の運用管理ＩＰアドレス（１４０３）を用いる。
なお、leaveVirtualServerの処理手順は図２６の手順とほぼ同様であり、ステップ２６０５とステップ２６０６に代わりに、負荷分散装置１０７への振り分け対象定義を削除する命令列を、負荷分散装置１０７に送信する。
また、acceptRequestの処理手順は図２６の手順とほぼ同様であり、ステップ２６０５とステップ２６０６に代わりに、リアルサーバへの振り分けを有効化する命令列を、負荷分散装置１０７に送信する。
さらに、blockRequestの処理手順は図２６の手順とほぼ同様であり、ステップ２６０５とステップ２６０６の代わりに、リアルサーバへの振り分けを無効化する命令列を、負荷分散装置１０７に送信する。
このように、本実施形態に係る業務システムに対する運用管理システムよれば、業務システム１００において、ユニットという部分閉塞再開可能な管理単位を規定することで、業務システム１００全体としては停止することなく、システム装置１０６における運用操作（アプリケーションの入れ替えなど）を行うことができる。
また、共通インターフェース５０１を利用することで、システムレベルにおいては、業務システム１００の構成パターンに依存しない汎用的な構築および運用を行うことができる。そして、それぞれの構成パターンに対しては、ユニット内の構成パターンに応じて作成された共通インターフェース５０１の実装プログラムをユニットの定義情報と関連付けることで対応でき、業務システム１００の構築や運用の際の作業が局所化され、開発者や運用者の負担を低減することができる。
以上で実施形態の説明を終えるが、本発明の態様はこれらに限定されるものではない。たとえば、エンドユーザとの接続は、インターネットでなくても、ＬＡＮ（Local Area Network）や専用線などの他の通信回線であってもよい。その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。
本発明の実施形態の全体構成を示したブロック図である。 図１のシステム装置構成が２層からなる場合の構成図である。 図２のシステム装置の第1の層を２つに分離した３層構造の場合の構成図である。 プラグインプログラムファイルの構造を示した図である。 プラグインプログラムが持つ共通インターフェースを示した図である。 構成パターン定義テーブルの構成図である。 システム構成パターン選択画面を示す画面図である。 負荷分散装置定義画面を示す画面図である。 サービス環境定義画面を示す画面図である。 ユニット構成定義画面を示す画面図である。 サーバマシン定義画面を示す画面図である。 日常運用の操作を行うシステム運用画面を示す画面図である。 基本情報テーブルを示した図である。 負荷分散装置定義テーブルを示した図である。 ティア共通サービス環境定義テーブルを示した図である。 ユニット構成定義テーブルを示した図である。 サーバマシン定義テーブルを示した図である。 サービスインスタンス定義テーブルを示した図である。 システム構築運用制御処理部１１７によるシステム構築の流れを示すフローチャートである。 システム構築運用制御処理部１１７によるシステム起動の流れを示すフローチャートである。 システム構築運用制御処理部１１７による業務入れ替えの流れを示すフローチャートである。 図３の構成パターンに対するプラグインプログラム共通インターフェースのメソッドcreateServiceDefinitions実装の処理フローを示すフローチャートである。 図３の構成パターンに対するプラグインプログラム共通インターフェースのメソッドsetupServices実装の処理フローを示すフローチャートである。 図３の構成パターンに対するプラグインプログラム共通インターフェースのメソッドdeployApplications実装の処理フローを示すフローチャートである。 図３の構成パターンに対するプラグインプログラム共通インターフェースのメソッドredeployApplications実装の処理フローを示すフローチャートである。 図３の構成パターンに対するプラグインプログラム共通インターフェースのメソッドjoinVirtualServer実装の処理フローを示すフローチャートである。
符号の説明
１００ 業務システム
１０１ 管理用端末システム装置
１０２ 運用管理システム
１０６ 管理対象システム装置
１０７ 負荷分散装置
１３１ 記憶手段
２０１ 第１の層
２０２ 第２の層
３０１ 第１層
３０２ 第２層
５０１ 共通インターフェース
１３００ 基本情報テーブル
１４００ 負荷分散装置定義テーブル
１５００ ティア共通サービス環境定義テーブル
１６００ ユニット構成定義テーブル
１７００ サーバマシン定義テーブル
１８００ サービスインスタンス定義テーブル

Claims (11)

  1. 複数のシステム装置を有する業務システムを運用管理システムにより運用する業務システムの運用方法であって、
    前記運用管理システムは、演算処理手段と記憶手段を有し、
    前記記憶手段は、前記複数のシステム装置を所定数毎にそれぞれユニットとして関連付けて定義したユニット構成情報と、前記ユニットの構成パターンに関係なく不変な構築運用操作の共通インターフェースを構成する複数のメソッドと、その各メソッドに対応して実行され前記ユニットの構成パターンに依存して決定するプログラムとを記憶し、
    前記共通インターフェースは、前記メソッドとして、少なくとも、前記ユニットに対して前記業務システムとしての動作を停止させる部分停止メソッドと、前記ユニットに対して前記業務システムとしての動作を再開させる部分再開メソッドとを有しており、
    前記演算処理手段は、所定システム装置に対して前記業務システムとしての動作を停止させて運用操作を行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記部分停止メソッドを実行することにより前記業務システムとしての動作を停止させる第１のステップと、前記運用操作を行う第２のステップと、前記運用操作終了後に前記部分再開メソッドを実行することにより前記業務システムとしての動作を再開させる第３のステップとを実行することを特徴とする業務システムの運用方法。
  2. 前記業務システムは、外部通信装置からのアクセスを複数の前記ユニットに対して振り分ける負荷分散装置を含んで構成され、
    前記共通インターフェースは、前記メソッドとして、さらに、前記負荷分散装置に対して所定ユニットへのアクセスの振り分けを停止させる振分停止メソッドと、前記負荷分散装置に対して所定ユニットへのアクセスの振り分けを再開させる振分再開メソッドとを有し、
    前記演算処理手段は、所定システム装置に対して前記業務システムとしての動作を停止させて運用操作を行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記第１のステップの前に、前記振分停止メソッドを実行することにより前記負荷分散装置に当該ユニットへのアクセスの振り分けを停止させる第４のステップを実行し、前記第３のステップの後に、前記振分再開メソッドを実行することにより前記負荷分散装置に当該ユニットへのアクセスの振り分けを再開させる第５のステップを実行することを特徴とする請求項１に記載の業務システムの運用方法。
  3. 前記共通インターフェースは、前記メソッドとして、さらに、前記ユニット内のシステム装置が前記業務システムの一部としてサービスを提供するために必要なサービス定義情報を前記ユニット構成情報に基づいて作成するサービス定義メソッドと、前記サービス定義情報に基づいて各システム装置においてサービスをセットアップするセットアップメソッドと、前記サービス定義情報から各システム装置に関するコンフィグレーションファイルを作成および配布する設定メソッドとを有し、
    前記演算処理手段は、前記業務システムの構築時に、前記ユニット構成情報を参照することで各ユニットに対してそれぞれ順番に、前記サービス定義メソッドを実行することにより前記サービス定義情報を作成する第６のステップと、前記セットアップメソッドを実行することにより各システム装置のセットアップを行う第７のステップと、前記設定メソッドを実行することにより各システム装置のコンフィグレーションファイルの作成および配布を行う第８のステップを実行することを特徴とする請求項１または請求項２に記載の業務システムの運用方法。
  4. 前記共通インターフェースは、前記メソッドとして、さらに、前記ユニット内のシステム装置のアプリケーションを入れ替えるアプリケーション入替メソッドを有し、
    前記演算処理手段は、所定システム装置に対する運用操作としてアプリケーションの入れ替えを行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記第２のステップとして、前記アプリケーション入替メソッドを実行することにより所定システム装置に対してアプリケーションの入れ替えを行うことを特徴とする請求項１または請求項２に記載の業務システムの運用方法。
  5. 前記演算処理手段は、所定システム装置に対する運用操作として環境データであるパラメータの更新を行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記第２のステップとして、予め変更されたパラメータを前記セットアップメソッドを実行することにより所定システム装置に反映させるステップと、前記設定メソッドを実行することにより所定システム装置のコンフィグレーションファイルの作成および配布を行うステップとを実行することを特徴とする請求項１または請求項２に記載の業務システムの運用方法。
  6. 複数のシステム装置を有する業務システムに対する運用管理システムであって、
    前記運用管理システムは、演算処理手段と記憶手段を有し、
    前記記憶手段は、前記複数のシステム装置を所定数毎にそれぞれユニットとして関連付けて定義したユニット構成情報と、前記ユニットの構成パターンに関係なく不変な構築運用操作の共通インターフェースを構成する複数のメソッドと、その各メソッドに対応して実行され前記ユニットの構成パターンに依存して決定するプログラムとを記憶し、
    前記共通インターフェースは、前記メソッドとして、少なくとも、前記ユニットに対して前記業務システムとしての動作を停止させる部分停止メソッドと、前記ユニットに対して前記業務システムとしての動作を再開させる部分再開メソッドとを有しており、
    前記演算処理手段は、所定システム装置に対して前記業務システムとしての動作を停止させて運用操作を行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記部分停止メソッドを実行することにより前記業務システムとしての動作を停止させ、前記運用操作を行い、前記運用操作終了後に前記部分再開メソッドを実行することにより前記業務システムとしての動作を再開させることを特徴とする運用管理システム。
  7. 前記業務システムは、外部通信装置からのアクセスを複数の前記ユニットに対して振り分ける負荷分散装置を含んで構成され、
    前記共通インターフェースは、前記メソッドとして、さらに、前記負荷分散装置に対して所定ユニットへのアクセスの振り分けを停止させる振分停止メソッドと、前記負荷分散装置に対して所定ユニットへのアクセスの振り分けを再開させる振分再開メソッドとを有し、
    前記演算処理手段は、所定システム装置に対して前記業務システムとしての動作を停止させて運用操作を行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記部分停止メソッドを実行することにより前記業務システムとしての動作を停止させる前に、前記振分停止メソッドを実行することにより前記負荷分散装置に当該ユニットへのアクセスの振り分けを停止させ、前記部分再開メソッドを実行することにより前記業務システムとしての動作を再開させた後に、前記振分再開メソッドを実行することにより前記負荷分散装置に当該ユニットへのアクセスの振り分けを再開させることを特徴とする請求項６に記載の運用管理システム。
  8. 前記共通インターフェースは、前記メソッドとして、さらに、前記ユニット内のシステム装置が前記業務システムの一部としてサービスを提供するために必要なサービス定義情報を前記ユニット構成情報に基づいて作成するサービス定義メソッドと、前記サービス定義情報に基づいて各システム装置においてサービスをセットアップするセットアップメソッドと、前記サービス定義情報から各システム装置に関するコンフィグレーションファイルを作成および配布する設定メソッドとを有し、
    前記演算処理手段は、前記業務システムの構築時に、前記ユニット構成情報を参照することで各ユニットに対してそれぞれ順番に、前記サービス定義メソッドを実行することにより前記サービス定義情報を作成し、前記セットアップメソッドを実行することにより各システム装置のセットアップを行い、前記設定メソッドを実行することにより各システム装置のコンフィグレーションファイルの作成および配布を行うことを特徴とする請求項６または請求項７に記載の運用管理システム。
  9. 前記共通インターフェースは、前記メソッドとして、さらに、前記ユニット内のシステム装置のアプリケーションを入れ替えるアプリケーション入替メソッドを有し、
    前記演算処理手段は、所定システム装置に対する運用操作としてアプリケーションの入れ替えを行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記運用操作として、前記アプリケーション入替メソッドを実行することにより所定システム装置に対してアプリケーションの入れ替えを行うことを特徴とする請求項６または請求項７に記載の運用管理システム。
  10. 前記演算処理手段は、所定システム装置に対する運用操作として環境データであるパラメータの更新を行う場合に、前記ユニット構成情報を参照して特定した所定システム装置を含む前記ユニットに対して、前記運用操作として、予め変更されたパラメータを前記セットアップメソッドを実行することにより所定システム装置に反映させ、前記設定メソッドを実行することにより所定システム装置のコンフィグレーションファイルの作成および配布を行うことを特徴とする請求項６または請求項７に記載の運用管理システム。
  11. 請求項１から請求項５までのいずれか１項に記載の業務システムの運用方法をコンピュータに実行させることを特徴とする運用プログラム。
JP2004311959A 2004-10-27 2004-10-27 業務システムの運用方法、運用管理システムおよび運用プログラム Expired - Fee Related JP4167643B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2004311959A JP4167643B2 (ja) 2004-10-27 2004-10-27 業務システムの運用方法、運用管理システムおよび運用プログラム
US11/070,886 US20060101059A1 (en) 2004-10-27 2005-03-03 Employment method, an employment management system and an employment program for business system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004311959A JP4167643B2 (ja) 2004-10-27 2004-10-27 業務システムの運用方法、運用管理システムおよび運用プログラム

Publications (2)

Publication Number Publication Date
JP2006127001A true JP2006127001A (ja) 2006-05-18
JP4167643B2 JP4167643B2 (ja) 2008-10-15

Family

ID=36317589

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004311959A Expired - Fee Related JP4167643B2 (ja) 2004-10-27 2004-10-27 業務システムの運用方法、運用管理システムおよび運用プログラム

Country Status (2)

Country Link
US (1) US20060101059A1 (ja)
JP (1) JP4167643B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008176759A (ja) * 2006-12-22 2008-07-31 Hitachi Ltd 運用整合性維持方法、システム及びプログラム
JP2015162061A (ja) * 2014-02-27 2015-09-07 日本電信電話株式会社 分散処理システム
CN105653359A (zh) * 2014-11-28 2016-06-08 金蝶软件（中国）有限公司 生成操作说明书的方法和应用系统

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8239505B2 (en) * 2007-06-29 2012-08-07 Microsoft Corporation Progressively implementing declarative models in distributed systems
US8230386B2 (en) 2007-08-23 2012-07-24 Microsoft Corporation Monitoring distributed applications
US8191084B1 (en) * 2007-09-28 2012-05-29 Emc Corporation Techniques for supporting application operation
US20090112932A1 (en) * 2007-10-26 2009-04-30 Microsoft Corporation Visualizing key performance indicators for model-based applications
US20090113292A1 (en) * 2007-10-26 2009-04-30 Microsoft Corporation Flexibly editing heterogeneous documents
US8099720B2 (en) 2007-10-26 2012-01-17 Microsoft Corporation Translating declarative models
US7974939B2 (en) * 2007-10-26 2011-07-05 Microsoft Corporation Processing model-based commands for distributed applications
US8654659B2 (en) * 2009-12-23 2014-02-18 Citrix Systems, Inc. Systems and methods for listening policies for virtual servers of appliance

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7093005B2 (en) * 2000-02-11 2006-08-15 Terraspring, Inc. Graphical editor for defining and creating a computer system
US7296268B2 (en) * 2000-12-18 2007-11-13 Microsoft Corporation Dynamic monitor and controller of availability of a load-balancing cluster
US20030005426A1 (en) * 2001-06-08 2003-01-02 Scholtens Dale A. Methods and apparatus for upgrading software without affecting system service
US6823382B2 (en) * 2001-08-20 2004-11-23 Altaworks Corporation Monitoring and control engine for multi-tiered service-level management of distributed web-application servers
US7350186B2 (en) * 2003-03-10 2008-03-25 International Business Machines Corporation Methods and apparatus for managing computing deployment in presence of variable workload
US8180864B2 (en) * 2004-05-21 2012-05-15 Oracle International Corporation System and method for scripting tool for server configuration
US7702779B1 (en) * 2004-06-30 2010-04-20 Symantec Operating Corporation System and method for metering of application services in utility computing environments

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008176759A (ja) * 2006-12-22 2008-07-31 Hitachi Ltd 運用整合性維持方法、システム及びプログラム
JP2015162061A (ja) * 2014-02-27 2015-09-07 日本電信電話株式会社 分散処理システム
CN105653359A (zh) * 2014-11-28 2016-06-08 金蝶软件（中国）有限公司 生成操作说明书的方法和应用系统

Also Published As

Publication number Publication date
JP4167643B2 (ja) 2008-10-15
US20060101059A1 (en) 2006-05-11

Similar Documents

Publication Publication Date Title
KR102628362B1 (ko) 컨테이너화된 환경에서 클러스터의 라이브 마이그레이션
JP7391862B2 (ja) 自動的に配備される情報技術（ｉｔ）システム及び方法
US10042628B2 (en) Automated upgrade system for a service-based distributed computer system
US6772178B2 (en) Method and apparatus for managing remote data replication in a distributed computer system
US9442813B2 (en) Replaying jobs at a secondary location of a service
US8898620B2 (en) System and method for application process automation over a computer network
US8296267B2 (en) Upgrade of highly available farm server groups
JP5513997B2 (ja) 通信システムおよび通信システム更新方法
US7000235B2 (en) Method and apparatus for managing data services in a distributed computer system
US20060101059A1 (en) Employment method, an employment management system and an employment program for business system
EP2944070B1 (en) Service migration across cluster boundaries
US20070258388A1 (en) Virtual server cloning
WO2016183556A1 (en) Dynamic code loading
US20060259594A1 (en) Progressive deployment and maintenance of applications on a set of peer nodes
CN104040525B (zh) 通过网络连接访问覆盖介质
US20100058319A1 (en) Agile deployment of server
US7043738B2 (en) Method and apparatus for managing a data imaging system using CIM providers in a distributed computer system
US7054890B2 (en) Method and apparatus for managing data imaging in a distributed computer system
SG189899A1 (en) Machine manager service fabric
US20020191014A1 (en) Graphical user interfaces for software management in an automated provisioning environment
JP2022013831A (ja) データベースに基づく管理方法、プラットフォーム、電子デバイス及び記憶媒体
JP6993577B2 (ja) インタフェース変換プログラム、インタフェース変換方法および情報処理装置
US11630697B2 (en) System and method of dynamic context workflow automation
AU2021240195A1 (en) Data processing method, apparatus, system and device and computer-readable storage medium
KR102622170B1 (ko) Ai 모델 서빙 시스템 및 방법

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060728

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080313

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080325

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080526

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20080729

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080801

R150 Certificate of patent or registration of utility model

Ref document number: 4167643

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110808

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120808

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120808

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130808

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees