以下、一実施形態を説明する。なお、以下に説明する実施形態は請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。
また、以下の説明では、「kkkテーブル」の表現にて情報を説明することがあるが、情報は、テーブル以外のデータ構成で表現されていてもよい。データ構成に依存しないことを示すために「kkkテーブル」のうちの少なくとも1つを「kkk情報」と呼ぶことができる。また、テーブルの構成は一例であり、2以上のテーブルが1つのテーブルにまとめられたり、1つのテーブルが複数のテーブルに分割されたりしてもよい。
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ(例えばCPU(Central Processing Unit)によって実行されることで、定められた処理を、適宜に記憶資源(例えばメモリ)及び/又は通信インターフェイスデバイス(例えば通信ポート)等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。また、プロセッサは、処理の一部または全部を行うハードウエア回路を含んでもよい。プログラムは、プログラムソースから各コントローラにインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機または計算機が読み取り可能な記憶メディアであってもよい。
また、以下の実施形態では、計算機システムを管理する第1の管理システム(以下、計算機管理システム)と、システム運用の自動化を支援する第2の管理システム(以下、運用自動化システム)とがある。しかし、計算機管理システムと運用自動化システムは1つの管理システムであってもよい。また、計算機管理システムは運用対象装置に含まれていてもよい。
また、以下の説明において、管理システムは、一以上の計算機で構成されてよい。具体的には、例えば、管理計算機が情報を表示する場合(具体的には、管理計算機が自分の表示デバイスに情報を表示する、或いは、管理計算機が表示用情報を遠隔の表示用計算機に送信する場合)、管理計算機が管理システムである。また、例えば、複数の計算機で管理計算機と同等の機能が実現されている場合は、当該複数の計算機(表示を表示用計算機が行う場合は表示用計算機を含んでよい)が、管理システムである。本実施形態では、運用自動化システムの管理サーバが管理計算機であり、運用自動化システムの管理クライアントが表示用計算機である。
また、管理計算機は、表示システムを含むI/Oシステムに接続されたインターフェースデバイスと、情報を記憶する記憶資源(例えばメモリ)と、インターフェースデバイス及び記憶資源に接続されたプロセッサとを有する。表示システムは、管理計算機が有する表示デバイスでもよいし、管理計算機に接続された表示用計算機でもよい。I/Oシステムは、管理計算機が有するI/Oデバイス(例えばキーボード及びポインティングデバイス、タッチパネル)でもよいし、管理計算機に接続された表示用計算機又は別の計算機でもよい。管理計算機が「表示用情報を表示する」ことは、表示システムに表示用情報を表示することであり、これは、管理計算機が有する表示デバイスに表示用情報を表示することであってもよいし、管理計算機が表示用計算機に表示用情報を送信することであってもよい(後者の場合は表示用計算機によって表示用情報が表示される)。また、管理計算機が情報を入出力するとは、管理計算機が有するI/Oデバイスとの間で情報の入出力を行うことであってもよいし、管理計算機に接続された遠隔の計算機(例えば表示用計算機)との間で情報の入出力を行うことであってもよい。情報の出力は、情報の表示であってもよい。
また、以下の説明において、要素の識別情報として、「uk(ユニークキー)」、「キー名」という表現を用いるが、これらのうちの少なくとも1つに代えて又は加えて他種の識別情報(例えば番号)が使用されてもよい。
図1は、実施形態の第1の概要を示す。図2は、実施形態の第2の概要を示す。
運用自動化システムは、システム運用の多数の部品を管理する。ここで、「システム運用」とは、計算機システムの運用のことである。「部品」とは、システム運用の一部分であり、1つの独立した処理(業務)である。部品は、例えば、スクリプトを実行する処理モジュールであり、実行ファイルでよい。部品は、運用自動化システムに予め設けられるが、これに限らず、後から運用自動化システムに追加することもできる。部品は、例えば、ストレージ装置の構成変更(例えば論理ボリュームの作成)を実行させる部品でよいが、これに限らず、部品同士を組み合わせるために使用する部品、汎用的に使用可能な部品などがあってもよい。例えば、部品としては、繰り返し実行するためのソフトウェア部品、ファイル転送部品、ファイル実行部品などがあってもよい。
なお、運用自動化システムの外部より部品(パッケージ)がダウンロードされインポートされる場合、運用自動化システムのユーザが部品を作成又は改善する場合、又はサービステンプレートが部品とされる場合、といったことが考えられるが、これ以外で運用自動化システムにて部品がインポートされてもよい。ちなみに部品の改善例として、(1)部品内部の不具合の修正、(2)内部処理効率の改善、(3)部品が運用対象とする装置が変更された(例えば、ある装置の管理をするコマンドの仕様が変わったので、そのコマンドを実行する部品も変える必要が出た)、(4)部品が運用対象とする装置が増えた(例えば、第1のベンダーの装置に加えて新たに第2ベンダーの装置も運用できるようになった)、(5)部品の入出力プロパティ数が増減した、(6)部品の入出力プロパティに与える値のフォーマットが変更された、(7)部品に関連付けられているデフォルト値が変更又は追加された、(8)部品として処理できることが増加又は処理効率の改善、のうちの少なくとも1つが考えられる。
運用自動化システムは、多数の部品(部品群)を管理する。本実施形態では、多数の部品のうちの2以上の部品を基にサービステンプレート(ST)が作成され、作成されたSTを基にサービスが作成され、作成されたサービスが実行される。以下、部品管理、ST作成、ST確定、サービス作成及びサービス実行の概要を説明する。
<部品管理>
運用自動化システムは、多数の部品(部品群)を管理する。部品は、部品提供ユーザにより追加又は編集されてよい。運用自動化システムは、部品毎に、部品に関連付けられる1以上の部品プロパティを管理する。また、運用自動化システムは、部品毎に、部品のバージョンを管理する。図1では、部品BBBを例に取って、部品プロパティ及びバージョンを示しているが、別の部品にも、その別の部品の部品プロパティ及びバージョンが関連付けられている。
「部品プロパティ」とは、部品のプロパティである。部品プロパティとして、部品入力プロパティと部品出力プロパティの2種類がある。部品入力プロパティは、定義された項目(表示名)についての値の入力に関するプロパティであり、部品出力プロパティは、定義された項目(表示名)についての値の出力に関するプロパティである。1つの部品に、1以上の部品入力プロパティと0以上の部品出力プロパティのうちの少なくとも1つが関連付けられる。すなわち、部品によっては、出力プロパティが0個の場合もあるが、入力プロパティは、各部品につき1個以上関連付けられている。入力値は、例えば、過去に作成されたサービスのプロパティとして入力された値のコピーであってもよいし、実行済みの他の部品について出力された値のコピーであってもよい。出力値は、部品実行後の構成情報等でよい。
バージョン001の部品BBBと、バージョン002の部品BBBがそれぞれ管理されている。すなわち、同一部品でも「バージョン」が異なれば、異なる部品のように扱われる。別の言い方をすれば、部品が更新(例えば改善)されても、更新後の部品が更新前の部品に上書きされることなく、更新前の部品とは別に更新後の部品が管理される。部品が更新された場合にいわゆるソフトウェアの更新のように更新前の部品が自動で更新後の部品に置き換わると、運用自動化においてトラブルの原因となり得る。特に、更新前の部品が既に作成されたサービスの要素の場合には、トラブルの原因となる可能性が高い。そこで、本実施形態では、運用自動化システムは、部品が更新された場合、更新後の部品の第1種の識別情報(例えば部品名)を更新前の部品の第1種の識別情報と同じとするが、更新後の部品のバージョン及び第2の識別情報(例えば部品uk(部品ユニークキー))のうちの少なくとも1つを、更新前の部品のバージョン及び第2の識別情報と違う値とする。これにより、運用自動化システムは、更新後の部品を更新前の部品と別部品のように管理できる。
「部品提供ユーザ」とは、部品の作成、追加又は更新等を行う運用自動化システムのユーザである。部品提供ユーザは、例えばGUI(Graphical User Interface)、CLI(Common Language Infrastructure)、API(Application Programming Interface)などを介して、部品を作成、追加、又は更新等行うことができる。
<ST作成>
運用自動化システムが、ST作成画面を表示する。ST作成画面に、情報の入力UIが表示される。ST作成ユーザが、ユーザ操作により、ST作成画面に情報を入力する。例えば、運用自動化システムは、ST作成画面を介して、多数の部品のうちの2以上の部品の選択と、2以上の部品の実行順序の指定とを受け付ける。運用自動化システムが、選択された2以上の部品と指定された実行順序とに基づきサービスフローのサービステンプレートを作成する。
「ST作成ユーザ」とは、サービステンプレートを作成するユーザである。ST作成ユーザは、上述のように、ST作成画面を用いてサービステンプレートを作成する。ST作成ユーザは、部品提供ユーザと同一であってもよいし異なっていてもよい。
「ユーザ操作」とは、画面に対してユーザが入力デバイスを使用して行う操作である。ユーザ操作に使用される入力デバイスは、一般に、ポインティングデバイス(例えばマウス)とキーボードの組合せ、又は、タッチスクリーンである。画面を介した入力は、ユーザ操作により行われる。
「サービステンプレート」とは、サービスのテンプレートである。本実施形態では、サービステンプレートが「ST」と略記されることもある。
「サービスフロー」とは、典型的には、選択された2以上の部品の並びである。部品の並びは、指定された実行順序に従う。選択された部品の数が1つだけの場合、サービスフローを構成する部品の数も1つである。
上述のように、運用自動化システムは、ST作成画面を介して選択された2以上の部品及び指定された実行順序を基にサービステンプレートを作成する。具体的には、例えば、運用自動化システムは、選択された2以上の部品に関連付けられている複数の部品プロパティ(例えば部品プロパティ001及び002)にそれぞれ対応した複数のSTプロパティ(例えばSTプロパティ00A及び00B)を作成し、作成した複数のSTプロパティをサービステンプレート(例えばST001)に関連付ける。部品プロパティに対応したSTプロパティは、その部品プロパティを基に運用自動化システムにより自動作成される。STプロパティの作成中又は作成後にユーザ操作により入力された値がSTプロパティに含まれてもよいが、ユーザ操作による入力(つまり手動入力)無しにSTプロパティが作成されてよい。「STプロパティ」とは、STのプロパティである。STプロパティとして、ST入力プロパティとST出力プロパティの2種類がある。ST入力プロパティは、定義された項目(表示名)についての値の入力に関するプロパティであり、ST出力プロパティは、定義された項目(表示名)についての値の出力に関するプロパティである。1つのサービステンプレートに、1以上のST入力プロパティと0以上のST出力プロパティのうちの少なくとも1つが関連付けられる。すなわち、ST出力プロパティが必ず1個あるとは限らない。
図1の例では、サービスフローは、部品BBB「Provisioning volume」(ストレージ装置に論理ボリュームを作成する)と、部品DDD「Create pair volume」(論理ボリューム(プライマリボリューム)とペアになる論理ボリューム(セカンダリボリューム)を作成する)の組合せであり、そのサービスフローのサービステンプレート(ST001)が作成されたとする。
<ST確定>
運用自動化システムは、作成されたサービステンプレートについて、ユーザ操作により確定を受けた場合、その作成されたサービステンプレートのST種別を「Release」として管理する(図2参照)。ST種別「Release」は、サービステンプレートが確定しており、そのサービステンプレートを基にサービスを作成することが可能であることを意味する。一方、確定していないサービステンプレートは、ST種別「Debug」である。ST種別「Debug」は、サービステンプレートが編集中であることを意味する。なお、運用自動化システムは、サービス実行において、ST種別「Debug」のサービステンプレートの選択を受け付けないようにしてもよい(例えば、ST種別「Debug」のサービステンプレートを、選択可能に表示しない(ディスエーブル))。その一例としては、後述するサービス作成ユーザは、ST種別が「Release」であるサービステンプレートだけサービスの作成を可能とし、サービステンプレート作成ユーザは、テスト目的もあるため、ST種別が「Release」と「Debug」両方でサービス作成を可能としてもよい。なお、こうした処理を実現するため、運用自動化システムはユーザ認識を行っていることは言うまでも無い。
<サービス作成>
運用自動化システムは、作成済のサービステンプレートを管理する。運用自動化システムは、ST種別「Release」のサービステンプレートのうちのいずれかのサービステンプレートの選択をサービス作成ユーザから受け、選択されたサービステンプレートを基にサービス作成画面を表示する。サービス作成ユーザが、ユーザ操作により、サービス作成画面に情報を入力する。運用自動化システムは、サービス作成画面を介して入力された情報を基にサービスを作成する。
「サービス作成ユーザ」とは、サービスを作成(実行)するユーザである。サービス作成ユーザとST作成ユーザは異なるユーザであってもよいし同一ユーザであってもよい。
「サービス」とは、インスタンス化されたサービステンプレートである。具体的には、サービステンプレートは、サービスの実行に必要な値がブランクとなっており、その必要な値がサービステンプレートに入力されたものが、サービスである。なお、前述のサービスの実行に必要な値については、デフォルト値がSTのプロパティの情報として設定できる場合もある。
なお、サービスは運用に関係するものであることを表すために「運用サービス」と記載する場合がある。なお、特定の状況に於いては「サービス」は、ユーザが指定した運用対象装置に対して行うべき運用処理を示しているとも言える。例えば、図13の例でST入力プロパティ1304Cを指定した場合はこの表現に該当する。また、部品自体に指定する運用対象装置を埋め込んだり、部品の入力プロパティのデフォルト値として与えたりしない場合は、「サービス」と「サービステンプレート」間の別な見方として、「サービス」が示す処理内容では入力値の定めにより構成変更や情報取得先として指定する運用対象装置が明確になっている一方で、「サービステンプレート」では指定する運用対象装置が不明であるとも言える。
なお、運用自動化システムは、作成されたサービスに、サービスプロパティを関連付けらよい。「サービスプロパティ」とは、サービスの入力・出力プロパティ(入力及び出力のうちの少なくとも一方のプロパティ)である。サービスの入力・出力プロパティには、サービス作成においてサービステンプレートに入力された値と、サービス実行において部品から出力された値とのうちの少なくとも1つが設定される。具体的には、例えば、サービスの実行では、サービス作成において入力プロパティに入力された値が、そのサービスのサービステンプレートに関連付けられている部品に入力されて、処理が実行されてよい。また、部品から出力された値が、サービスの出力プロパティに設定されることで、サービスの実行結果画面において、その設定された値(例えば、部品が実行された後の構成情報等)が表示されてよい。
<サービス実行>
運用自動化システムが、作成したサービスの実行の命令を、計算機管理システムに送信する。計算機管理システムが、その命令に従い、サービスを実行する。
以上が、部品管理、ST作成、サービス作成及びサービス実行の各々の概要である。
複数のSTプロパティのうちの少なくとも1つのST入力プロパティの各々に、カスタムUIを定義した情報であるカスタムUI生成情報が関連付けられている。但し、デフォルトUIに関しては、カスタムUI生成情報は「Null」(デフォルトUI用の情報)である。カスタムUI及びデフォルトUIについては後述する。また、図面では、「カスタムUI生成情報」を、「カスタムInfo.」のように略記することもある。STプロパティのカスタムUI生成情報は、そのSTプロパティに対応した部品プロパティに関連付けられているUI生成情報(例えば、UIの生成に必要な情報を含んだ情報)である。複数の部品プロパティのうちの少なくとも1つの部品入力プロパティの各々に、カスタムUI生成情報が関連付けられている場合がある。
運用自動化システムは、ST作成画面及びサービス作成画面等の画面を、一連の流れにおいて表示することができる。少なくとも1つの画面には、UIが表示される。本実施形態において、UIは、画面に表示される1つの要素である。1以上のUIを含んだ画面をGUIと呼ぶこともできる。なお、以後の説明ではUIを「UI要素」と呼ぶことがある。
<UIの生成及び表示>
本実施形態では、運用自動化システムは、少なくともサービス作成画面に表示されるUIを、例えば次のように生成する。
すなわち、運用自動化システムは、選択されたサービステンプレートの複数のSTプロパティにそれぞれ対応した複数のカスタムUI生成情報を基に、複数のUIをそれぞれ生成する。運用自動化システムは、生成した複数のUIを1つのサービス作成画面に表示する。本実施形態では、1つのカスタムUI生成情報を基に1つのUIが生成される。つまり、カスタムUI生成情報とUIの関係は、1:1である。しかし、カスタムUI生成情報とUIの関係は、n:1でもよいし、1:nでもよいし、m:nでもよい(mとnは2以上の整数)。
このようなUI生成によれば、例えば、部品BBBと部品DDDで構成されたサービスフローのうち部品DDDが部品EEEと入れ替えられても、部品入れ替え後のサービス作成画面に表示されるUIとして、部品DDDに代えて部品EEEのUIが生成され表示される。このように、UIの生成が効率的である。
<カスタムUI>
また、本実施形態では、UIとして、デフォルトUIに代えて又は加えて、カスタムUIが用意されている。
「デフォルトUI」は、テキストフィールドのkey-value形式でのUIであり、具体的には、STプロパティ(部品プロパティ)の表示名と、テキストフィールドとの組である。なお、デフォルトUIにてテキストフィールドが採用される理由は、幅広い入力形式に対応できることが理由である。STプロパティ(部品プロパティ)の表示名(入力項目)に関わらず、テキストフィールドが表示される。従って、ユーザは、表示名を見て、入力する値又は名称等の情報を考えなければならず、そして、その情報をキータイプによりテキストフィールドに入力する必要がある。このため、タイプミス等の誤入力が生じ得る。また、STプロパティ(部品プロパティ)に無効な値や名称等があってもそのような無効な値や名称等が入力されるおそれもある。また、ユーザに高い知識が必要とされ得る。
それに対し、「カスタムUI」は、テキストフィールドのkey-value形式でのUIではなく、ユーザビリティが考慮されたUIである。例えば、カスタムUIは、STプロパティ(部品プロパティ)の表示名と、プルダウンメニュー、チェックボックス及びラジオボタン等のうちの少なくとも1つのような、1以上のGUI要素(ウィジェット)とを含んだUIである。このため、デフォルトUIに比べて、誤入力は生じないし、ユーザに高い知識が必要とされない。なお、カスタムUIも、テキストフィールドを含んでよいが、デフォルトUIのようなUI(テキストフィールドのkey-value形式でのUI)よりもユーザビリティの高いUI(例えば、テキストフィールドの近傍に表示される無効な値や名称等のリストを含んだUI)である。
図1の例によれば、1つのサービス作成画面において、デフォルトUI(表示名:LUNと、テキストフィールドとの組)と、カスタムUI(表示名:Volume Capacityと、ボリューム容量のプルダウンメニューと、ボリューム容量の単位(例えばMB(メガバイト))のプルダウンメニューとの組)が混在している。
このように、本実施形態では、全てのUIが、カスタムUIである必要は無い。カスタムUIが関連付いていない部品とカスタムUIが関連付いた部品とが1つのサービスフローに混在しても、サービス作成画面では、デフォルトUIの他にカスタムUIも定義通り表示される。システム運用の部品は多数存在するので、全てのUIをカスタムUIにしてから部品提供するとなると、運用自動化システムのベンダーが自社製品を提供するまでに時間がかかる。本実施形態によれば、カスタムUIのカスタムUI生成情報が関連付いていない部品が早期に提供されたり、ST作成ユーザが部品を独自に作成してサービステンプレートに組み込んだりしても、サービス作成ユーザが、サービス作成においてカスタムUIの恩恵を受けることができる。
なお、部品プロパティ(STプロパティ)にカスタムUIが追加された場合、及び、古いカスタムUIから新しいカスタムUIに変わった場合でも、画面に表示されるUIは、変更前のUI(すなわち、デフォルトUI又は古いカスタムUI)とされる。具体的には、例えば、運用自動化システムは、既存のSTに関連付いている部品のUIの変更要求を受け付けた場合、UIの変更要求を受けた部品のコピーを作成(既存の部品を基にバージョンの異なる新たな部品を作成)し、UIを変更した部品を作成する。次に、既存のSTのコピーを作成し(既存のSTを基にバージョンの異なる新たなSTを作成)、その作成した新しいSTに、既存の部品とバージョンが異なる新しい部品を入れ替える。既存のSTで使用されている部品に関連付いているUIを自動的に変更してしまうと、元々はうまく使えていたSTが使えなくなる可能性がある(例えば、元々は入力できていた値が入力できなくなった等)。本実施形態によれば、使用可能なSTに悪影響を及ぼさずに部品のUIの入れ替えが可能となる。
また、作成済のサービステンプレートに関連付いている部品の部品プロパティに関連付いたUIが変更されて新規部品が追加されても、運用自動化システムは、そのサービステンプレートに基づくサービス作成画面において、既存の部品を使用して変更前のUIを表示する。これにより、サービステンプレートの作成後に関連するUIが変更されることで元々入力可能だった値の入力が不可能になるといったおそれを回避できる。変更前のUIの生成及び表示を維持する具体例は、図26を参照して説明する。
<部品バージョンと関連STの表示>
運用自動化システムは、図1を参照して説明したように、部品のバージョンと、そのバージョンの部品が関連付いたサービステンプレート(関連ST)との関係を管理する。サービス作成又はサービス作成開始前等において、運用自動化システムは、図2に示すように、部品(例えば部品BBB)の選択をユーザから受けた場合に、選択された部品のバージョン毎に、関連STリストを表示する。関連STリストは、関連ST毎に、関連STの情報(例えば、ST名、STバージョン及びST種別)を有する。これにより、下記の(A)乃至(B)のうちの少なくとも1つを実現し得る。
(A)更新後の部品がインポートされた場合、更新前の部品を選択することで、ユーザは、更新前の部品についてのバージョン毎の関連STリストから、更新前の部品について関連STの有無がわかる。また、更新前の部品に関連STがあれば、その関連STのST種別もわかる。ユーザは、関連STの有無及びST種別を基に、既存のサービステンプレートに関連付いている部品を、更新後の部品に入れ替えるか否かを判断できる。例えば、更新前の部品について関連STが存在しなければ、ユーザは、STに関連付いている部品を更新後の部品に置換することは不要であると判断できる。また、例えば、更新前の部品(例えばバージョン001の部品BBB)についてST種別「Release」の関連STが存在していれば、ユーザは、その関連STに関連付いている更新前の部品を更新後の部品に入れ替えると不具合が生じ得ること、及び、それ故に更新前の部品を更新後の部品に入れ替えた新たなSTを作成することとを、判断できる。また、例えば、更新前の部品について関連STが存在するもののST種別「Release」の関連STが存在していなければ(例えばバージョン002の部品BBB)、ユーザは、関連STに関連付いている更新前の部品を更新後の部品に入れ替えても良いことを判断できる。
(B)ユーザは、選択した部品(例えば部品BBB)についてのバージョン毎の関連STリストから、選択した部品について関連STの有無と、関連STのST種別がわかる。ユーザは、関連STの有無及びST種別を基に、選択した部品を更新することによる影響(例えば、新たなバージョンの部品とすることの必要性、関連STに関連付いている部品の交換の必要性、新たにSTを作成することの必要性等)を判断できる。例えば、選択した部品についてST種別「Release」の関連STが存在していなければ、ユーザは、選択した部品のバージョンを変更すること無しに部品を更新して良い(つまりバージョンの異なる部品を追加するのではなく部品それ自体を入れ替えてよい)と判断できる。また、例えば、選択した部品についてST種別「Release」の関連STが存在していれば、ユーザは、選択した部品について新たなバージョンの部品を更新後の部品とする必要があると判断できる。
通常、部品が更新されても(バージョンアップされても)、確定したサービステンプレートに関連付いている部品を更新後の部品に入れ替えることは避けることが望ましい。本実施形態によれば、上述の通り、各バージョンの部品がどのサービステンプレートに関連づいているのかのリストが表示される。このため、更新後の部品に入れ替えられるべき又は入れ替えられてはならない部品が関連付いているサービステンプレートがどれであるかの判断が容易である。
以上が、実施形態の概要である。以下、実施形態を詳細に説明する。
図3は、実施形態に係るシステム全体の構成を示す。
計算機システム310に、計算機管理システム302が接続されており、計算機管理システム302に運用自動化システム301が接続されている。運用自動化システム301は計算機管理システム302と一体でもよい。
計算機システム310は、1以上のホスト計算機(以下、ホスト)303と、1以上のストレージ装置304とを含む。ホスト303とストレージ装置304は通信ネットワーク306を介して接続されている。ホスト303は、ストレージ装置304に接続されたI/F(通信インターフェースデバイス)と、メモリのような記憶資源と、それらに接続されたプロセッサとを有する。ストレージ装置304は、1以上のPDEV(物理記憶デバイス)と、1以上のPDEVに接続されたコントローラとを有する。コントローラは、ホスト303に論理ボリュームを提供する。ホスト303は、提供された論理ボリュームを指定したI/O(Input/Output)要求をストレージ装置304に送信する。ストレージ装置304のコントローラが、そのI/O要求に従い、論理ボリュームに対するデータI/Oを行う。I/O対象のデータが、論理ボリュームのI/O先領域に基になっている1以上のPDEVに対して入出力される。なお、ホスト303とストレージ装置304とは運用対象装置の一例である。
計算機管理システム302は、計算機システム310を管理する管理システムである。計算機管理システム302は、運用自動化システム301からの命令に従いサービスを実行する。サービス実行では、例えば、ストレージ装置304に論理ボリュームを作成すること、及び、ストレージ装置304にセカンダリボリュームを作成することが行われる。
運用自動化システム301は、システム運用の自動化を支援する管理システムである。運用自動化システム301は、管理サーバ311と、管理サーバ311に接続された管理クライアントとを有する。管理サーバ311が管理クライアント312に送信した表示用情報を基に、管理クライアント312により情報が表示される。つまり、管理サーバ311が管理クライアント312を介して情報を表示する。
具体的には、例えば、管理サーバ311は、部品と関連STとの関係を特定し(P11)、部品のバージョン毎の関連STリストを表示する(P12)。
また、例えば、管理サーバ311は、ST作成画面を表示し(P21)、ST作成ユーザからST作成画面を介してSTの作成(編集を含む)を受け付ける(P22)。管理サーバ311は、確定したSTに基づきサービス作成画面を表示する(P23)。管理サーバ311は、サービス作成ユーザからサービス作成画面を介して情報を受け、入力された情報を基にサービスを作成し保持する(P24)。管理サーバ311は、サービスの編集のための画面を表示し(P25)、サービスの編集を受け付けることもできる。管理サーバ311は、作成(編集を含む)されたサービスの実行画面を表示する(P26)。管理サーバ311は、サービス実行画面を介してサービスの実行をサービス作成ユーザから受け付け、受け付けたサービスの実行の命令を、計算機管理システム302に送信する(P27)。
図3に示した処理P11、P12及びP21〜P27の各処理群(1以上の処理)が、プログラム群(1以上のコンピュータプログラム)がプロセッサにより実行されることにより行われる。
図4は、管理サーバ311の構成を示す。
管理サーバ311は、通信ポート414(I/Fの一例)、メモリ412(記憶資源の一例)、及び、それらに接続されたプロセッサ(典型的にはCPUのようなマイクロプロセッサ)411を有する。管理サーバ311は、通信ポート414を介して、少なくとも計算機管理システム302及び管理クライアント312と通信する。
メモリ412は、半導体メモリに限らずハードディスクドライブでもよい。メモリ412は、コンピュータプログラムと管理テーブルを記憶する。具体的には、例えば、メモリ412は、部品管理テーブル421、部品プロパティ管理テーブル422、ST管理テーブル423、フロー管理テーブル424、STプロパティ管理テーブル425、サービス管理テーブル426、サービスプロパティ設定テーブル427、及び、管理プログラム431を記憶する。管理プログラム431が、プロセッサ411により実行され、それにより、例えば図3に示した処理P11、P12、P24及びP27を行う。
図5は、管理クライアント312の構成を示す。
管理クライアント312は、通信ポート514(I/Fの一例)、入出力デバイス513、メモリ512(記憶資源の一例)、及び、それらに接続されたプロセッサ(典型的にはCPUのようなマイクロプロセッサ)511を有する。
メモリ512は、半導体メモリに限らずハードディスクドライブでもよい。メモリ512は、表示プログラム531を記憶する。表示プログラム531が、プロセッサ511により実行され、それにより、例えば図3に示した処理P12、P21、P23、P25及びP26を行う。
以下、管理サーバ311が有する管理情報(テーブル421〜427)の構成を説明する。
図6は、部品管理テーブル421の構成を示す。
部品管理テーブル421は、部品に関する情報を有する。部品管理テーブル421は、部品毎にレコードを有し、各レコードに、管理番号601、部品名602、バージョン603、実行ファイルパス604、及び部品uk605が格納される。管理番号601は、レコードの通し番号である。部品名602は、部品の名称である。バージョン603は、部品のバージョンを表す。実行ファイルパス604は、部品の実行ファイルへのパス(パス名)を表す。部品uk605は、部品のユニークキー(番号)である。ukは、識別情報の一例である。
図6から分かるように、バージョンが異なる同一部品は、部品名602が同じであり(例えば、「Provisioning Volume」)、バージョン603が異なる(例えば「01.00.00」、「01.10.00」)。つまり、バージョンが異なる同一部品は、別々の部品として管理される。しかし、複数の部品の部品名602が同一であれば、それら複数の部品のオリジナルは同一であることがわかる。
図7は、部品プロパティ管理テーブル422の構成を示す。
部品プロパティ管理テーブル422は、部品プロパティに関する情報を有する。部品プロパティ管理テーブル422は、部品プロパティ毎にレコードを有し、各レコードに、管理番号701、部品uk702、表示名703、キー名704、初期値705、入出力タイプ706、プロパティグループ707及びカスタムUI生成情報708が格納される。
管理番号701は、レコードの通し番号である。部品uk702は、部品のユニークキーである。表示名703は、画面に表示される部品プロパティ名であり、例えば入力項目又は出力項目に相当する。
キー名704は、部品プロパティを一意に特定するための名称であり、部品プロパティの識別情報の一例である。初期値705は、生成されたUIに予め設定される値である。初期値705「Null」は、初期値が存在しないことを意味する。つまり、UIが表示されたとき、入力欄又は出力欄がブランクである。
入出力タイプ706は、部品プロパティが部品入力プロパティであるか部品出力プロパティであるか(言い換えれば、UI上の値が入力値であるか出力値であるか)区別するための情報である。入出力タイプ706の値は、対応する部品プロパティが部品入力プロパティの場合に「In」であり、対応する部品プロパティが部品出力プロパティの場合に「Out」である。
プロパティグループ707は、部品プロパティが属するプロパティグループの名称を示す。すなわち、本実施形態では、少なくとも1つのプロパティグループが存在し、プロパティグループに、1以上の部品プロパティと、1以上のSTプロパティ(例えば、その1以上の部品プロパティにそれぞれ対応する1以上のSTプロパティ)とのうちの少なくとも一方が関連付けられる。プロパティグループ707の値「Null」は、対応する部品プロパティがいずれのプロパティグループにも属さないことを意味する。
カスタムUI生成情報708は、生成されるカスタムUIの種別を表す。カスタムUI生成情報708の値「Null」は、カスタムUI生成情報がデフォルトUI用の情報であることを意味する。
図8は、ST管理テーブル423の構成を示す。
ST管理テーブル422は、サービステンプレートに関する情報を有する。ST管理テーブル423は、ST毎にレコードを有し、各レコードに、管理番号801、ST名802、STバージョン803、ST uk804、フローuk805及びST種別806が格納される。
管理番号801は、レコードの通し番号である。ST名802は、サービステンプレートの名称である。STバージョン803は、サービステンプレートのバージョンである。ST uk804は、サービステンプレートのユニークキーである。フローuk805は、サービステンプレートに対応するサービスフローのukである。ST種別806は、サービステンプレートの種別を表す。ST種別806の値「Debug」は、サービステンプレートが編集可能であることを意味し、ST種別806の値「Release」は、サービステンプレートが確定していること(編集不可)であることを意味する。
図8から分かるように、バージョンが異なる同一STは、ST名802が同じであり(例えば、「Provisioning & Pair」)、STバージョン803が異なる(例えば「01.00.00」、「01.10.00」)。つまり、STバージョンが異なる同一STは、別々のSTとして管理される。しかし、複数のSTのST名802が同一であれば、それら複数のSTのオリジナルは同一であることがわかる。
上述したように、STに関連付いている部品のバージョンの入れ替え(つまり部品の更新)が可能なのは、その部品が関連付いているSTが未確定(Debug)である場合である。なお、既にサービスとして存在してしまっているSTが編集されることで生じる混乱(例えば、そのSTに関連付いている部品への影響)を回避するために、本実施形態では、管理プログラム431が、確定したST(ST種別「Release」のST)を編集状態(Debug)に戻すことを禁止する。管理プログラム431は、確定したSTの編集要求をユーザから受け付けた場合、確定したSTのコピーを生成し、そのSTコピーを、編集対象のSTとして表示する。変形例として、管理プログラム431は、確定したSTであっても実行中又は実行待ちのサービスが無ければ(例えば、STを基にサービスを作成中及び作成済で無ければ)、確定したSTを編集状態に戻すことを許可し、STが確定しており且つ実行中又は実行待ちのサービスが1つでもあれば、そのSTを編集状態に戻すことを禁止してよい。
図9は、フロー管理テーブル424の構成を示す。
フロー管理テーブル424は、サービスフローに関する情報を有する。フロー管理テーブル424は、サービスフロー毎にレコードを有し、各レコードに、管理番号901、フローuk902、構成部品ukリスト903及びプロパティマッピングリスト904が格納される。
管理番号901は、レコードの通し番号である。フローuk902は、フローのユニークキー(番号)である。
構成部品ukリスト903は、サービスフローを構成する部品のukのリストである。構成部品ukリスト903では、サービスフローにおける部品の並び順に(部品の実行順序通りに)、部品のukが並ぶ。
プロパティマッピングリスト904は、サービスフローに対応するサービスのサービスプロパティのukのリストである。リスト904において、サービスプロパティのukは、例えば、部品ukと、部品のキー名との組合せである。なお、「{部品uk(1). storage.pathinfo = 部品uk(2). storage.pathinfo}」のような、部品ukの部品プロパティの組合せは、一方の部品からの出力値が他方の部品への入力値となることを意味する。
図10は、STプロパティ管理テーブル425の構成を示す。
STプロパティ管理テーブル425は、STプロパティに関する情報を有する。STプロパティ管理テーブル425は、STプロパティ毎にレコードを有し、各レコードに、管理番号1001、ST uk1002、STプロパティuk1003、表示名1004、キー名1005、入出力タイプ1006、プロパティグループ1007及びカスタムUI生成情報1008が格納される。
管理番号1001は、レコードの通し番号である。ST uk1002は、STプロパティが関連付いているSTのST ukである。
STプロパティuk1003は、STプロパティのユニークキー(例えば番号)である。
表示名1004は、画面に表示されるSTプロパティ名である。キー名1005は、STプロパティを一意に特定するための名称であり、STプロパティの識別情報の一例である。
入出力タイプ1006は、STプロパティがST入力プロパティであるかST出力プロパティであるか(言い換えれば、UI上の値が入力値であるか出力値であるか)区別するための情報である。入出力タイプ1006の値は、対応するSTプロパティがST入力プロパティの場合に「In」であり、対応するSTプロパティがST出力プロパティの場合に「Out」である。
プロパティグループ1007は、STプロパティが属するプロパティグループの名称を示す。すなわち、上述したように、本実施形態では、後述するNullも含めて少なくとも1つのプロパティグループが存在し、プロパティグループに、1以上の部品プロパティと、1以上のSTプロパティとのうちの少なくとも一方が関連付けられる。プロパティグループ1007の値「Null」は、対応するSTプロパティがいずれのプロパティグループにも属さないことを意味する。
カスタムUI生成情報1008は、生成されるカスタムUIの種別を表す。カスタムUI生成情報1008の値「Null」は、対応するSTプロパティにデフォルトUIが関連付けられていることを意味する。なお、カスタムUI生成情報は、カスタムUI生成詳細情報(例えば、ウィジェットの数、各々のウィジェットの種別、表示対象のテキスト、表示されるリスト等)を含んでよい。カスタムUI生成詳細情報(図示せず)は、STプロパティに関連付けられてよい。STプロパティに関連付いているカスタムUI生成詳細情報を基に、カスタムUIが生成されてよい。
図11は、サービス管理テーブル426の構成を示す。
サービス管理テーブル426は、サービスに関する情報を有する。サービス管理テーブル426は、サービス毎にレコードを有し、各レコードに、管理番号1101、サービス名1102、サービス説明1103、ST uk1104及びサービスuk1105が格納される。
管理番号901は、レコードの通し番号である。サービス名1102は、サービスの名称である。サービス説明1103は、サービスに関する説明の記述であり、例えば、サービスにおける処理とその順序を含んでよい。ST uk1104は、サービスに対応するSTのST ukである。サービスuk1105は、サービスのユニークキー(番号)である。
図12は、サービスプロパティ設定テーブル427の構成を示す。
サービスプロパティ設定テーブル427は、サービスプロパティに関する情報を有する。サービスプロパティ設定テーブル427は、サービスプロパティ毎にレコードを有し、各レコードに、管理番号1201、プロパティ設定値1202、STプロパティuk1203及びサービスuk1204が格納される。
管理番号1201は、レコードの通し番号である。プロパティ設定値1202は、対応するSTプロパティの入力値(又は出力値)である。「Null」は、入力値(又は出力値)が存在しないことを意味する。STプロパティuk1203は、対応するSTプロパティのSTプロパティukである。サービスuk1204は、対応するサービスのサービスukである。
図12によれば、サービスuk「1」のサービスに、5つのSTプロパティが関付けられていて、5つのSTプロパティにそれぞれ対応した5つのUI(デフォルトUI及びカスタムUIのうちの少なくとも1つ)に、「STORAGEHOST」、「1」等の値が入力(又は出力)されたことがわかる。
以上が、テーブル421〜427の構成の説明である。なお、上述の説明において、表示名、キー名及びukのような識別情報は、ユーザにより入力された情報でもよいし、管理プログラム431により決められた情報でもよい。
以下、ST入力プロパティとST出力プロパティの関係の詳細と、UI生成/表示の詳細のそれぞれの例を説明する。
図13は、ST入力プロパティとST出力プロパティの関係の一例を示す。
サービステンプレート1301に対応するサービスフローが、部品1302A(「Provisioning Volume」)と、部品1302B(「Create pair volume」)とにより構成されている。そのサービスフローでは、部品1302Aの次に部品1302Bが実行されるような実行順序となっている。
部品1302Aには、4つの部品入力プロパティ1303A〜1303Dが関連付けられている。4つの部品入力プロパティ1303A〜1303Dのそれぞれの表示名は、「Number of Volume」、「Volume Capacity」、「Host Name」及び「Number of path」である。また、部品1302Aには、2つの部品出力プロパティ1303E及び1303Fが関連付けられている。2つの部品出力プロパティ1303E及び1303Fのそれぞれの表示名は、「Volume uk」及び「Path info」である。
部品1302Bには、4つの部品入力プロパティ1303G〜1303Jが関連付けられている。4つの部品入力プロパティ1303G〜1303Jのそれぞれの表示名は、「Volume uk」、「Host Name」、「Path info」及び「Path世代数」である。また、部品1302Bには、1つの部品出力プロパティ1303Kが関連付けられている。その部品出力プロパティ1303Kの表示名は、「Path info」である。
これらの部品プロパティにおいて、表示名「Volume uk」の部品出力プロパティ1303Eと、同じ表示名「Volume uk」の部品入力プロパティ1303Gは、同一のキー名を有する。同様に、表示名「Path info」の部品出力プロパティ1303Fと、同じ表示名「Path info」の部品入力プロパティ1303Iも、同一のキー名を有する。これにより、部品出力プロパティ1303Eからの出力値が、部品入力プロパティ1303Gの入力値とされ、また、部品出力プロパティ1303Fからの出力値が、部品入力プロパティ1303Iの入力値とされる。このように、「Volume uk」及び「Path info」については、出力値がそのまま入力値と使用されるので、ST作成ユーザがわざわざ「Volume uk」及び「Path info」について値を入力する必要が無い。従って、誤入力を防止できる。
このような部品を有するサービスフローのサービステンプレート1301には、ST入力プロパティ1304A〜1304Eと、ST出力プロパティ1304F及び1304Gが、管理プログラム431により関連付けられる。ST入力プロパティ1304Aは、部品入力プロパティ1303Aを基に生成されたST入力プロパティであり、故に、表示名は「Number of Volume」である。ST入力プロパティ1304Bは、部品入力プロパティ1303Bを基に生成されたST入力プロパティであり、故に、表示名は「Volume Capacity」である。ST入力プロパティ1304Cは、部品入力プロパティ1303C及びHを基に生成されたST入力プロパティであり、故に、表示名は「Host Name」である。ST入力プロパティ1304Dは、部品入力プロパティ1303Dを基に生成されたST入力プロパティであり、故に、表示名は「Number of path」である。ST入力プロパティ1304Eは、部品入力プロパティ1303Jを基に生成されたST入力プロパティであり、故に、表示名は「Path世代数」である。ST出力プロパティ1304Fは、部品出力プロパティ1303Eを基に生成されたST入力プロパティであり、故に、表示名は「Volume uk」である。ST出力プロパティ1304Gは、部品出力プロパティ1303Kを基に生成されたST入力プロパティであり、故に、表示名は「Path info」である。これらのST入力プロパティ及びST出力プロパティは、部品入力プロパティ及び部品出力プロパティを基にそれぞれ管理プログラム431により生成される。
図14は、図13のSTに対応したサービス作成画面の一例である。
サービス作成画面1401には、ST入力プロパティ1304A〜1304Eにそれぞれ対応したUI1411〜1415が表示される。UI1411〜1415は、それぞれ管理プログラム431により生成されたUIである。UI1411〜1415のうち、UI1411及び1415がそれぞれデフォルトUIであり、UI1412〜1414がそれぞれカスタムUIである。UI1411〜1415の各々は、ST入力プロパティに関連付いているカスタムUI生成情報を基に生成される。
サービス作成画面1401には、実行ボタン1417と取消ボタン1418が設けられている。ST作成ユーザは、UI1411〜1415に入力した値でよければ、実行ボタン1417を押し、それにより、入力された値を基にサービスが作成され、そのサービスの実行命令が計算機管理システム302に送信される。ST作成ユーザは、UI1411〜1415に入力した値を取り消すのであれば、取消ボタン1418を押し、それにより、全てのUI1411〜1415がブランクとされる。
なお、サービス作成画面1401に表示されるUIが、デフォルトUIであるかカスタムUIであるかは、STのSTプロパティに関連付いているカスタムUI生成情報次第なので、画面1401に表示される全てのUIがカスタムUIであることもある。
また、管理プログラム431は、ST入力プロパティ1304A〜1304Eがそれぞれいずれのプロパティグループに属しているかを基に、プロパティグループ別に、UIを表示してもよい。例えば、同一のプロパティグループに属する2以上のUIが1つの枠で囲まれてもよい。分野が同一のSTプロパティが同一のプロパティグループに属していれば、UIの配置がプロパティグループに応じた配置となる。これにより、視認性の向上が期待される。
以下、本実施形態での表示の具体例を説明する。
図15は、ST作成画面の一例を示す。
ST作成画面は、部品リストプレーン1511と、部品詳細プレーン1512と、フロー作成プレーン1513と、ST種別選択ツール1514とを有する。
部品リストプレーン1511には、管理されている部品の部品名のリスト(部品管理テーブルに記録されている部品名のリスト)1531が、管理プログラム431により表示される。
部品詳細プレーン1512には、部品リスト1531から選択された部品に対応する詳細(例えば部品名及びバージョン)が、管理プログラム431により表示される。
フロー作成プレーン1513には、部品リスト1531から選択された部品のアイコン1541A及び1541Bがユーザ操作に従い表示され、部品アイコン1541A及び1541B同士の接続により、サービスフローが定義される。例えば、管理プログラム431は、部品リスト1531から選択された部品をフロー作成プレーン1513にドラッグ&ドロップするユーザ操作に従い、その部品のアイコン1541A及び1541Bをフロー作成プレーン1513に表示する。部品リスト1531から部品がドラッグ&ドロップされる都度に、管理プログラム431は、部品アイコンをフロー作成プレーン1513に追加する。また、管理プログラム431は、ユーザ操作に従い、第1の部品アイコンから第2の部品アイコンへの矢印リンクを張ることで、第1の部品の次に第2の部品を実行することを定義する。
ST種別選択ツール1514は、Debugボタン1521とReleaseボタン1522とを含む。管理プログラム431は、Releaseボタン1522が押された場合、フロー作成プレーン1513に表示されているサービスフローのSTを、ST種別「Release」として保存する。一方、管理プログラム431は、Debugボタン1521が押された場合、フロー作成プレーン1513に表示されているサービスフローのSTを、ST種別「Debug」として保存する。
以上が、ST作成画面1501の構成の説明である。
新たにインポートされた部品があれば、ST作成画面1501の部品リスト1531には、その新たにインポートされた部品の部品名も含まれる。ST作成ユーザが、その新たな部品の部品名を選択し、関連ST表示のためのユーザ操作を行うと(選択された部品名を関連ST表示の対象として指定すると)、管理プログラム431が、例えばポップアップで、バージョン毎の関連STリストを表示する。
図16は、バージョン毎の関連STリストの一例を示す。
管理プログラム431は、部品リスト1531から選択された部品名と同一の部品名のバージョン及び部品ukを部品管理テーブル421から特定する。管理プログラム431は、特定した部品ukに対応するフローukをフロー管理テーブル424から特定し、特定したフローukに対応するST名及びST種別をST管理テーブル423から特定する。これにより、管理プログラム431は、部品リスト1531から選択された部品のバージョン毎の関連STリスト(関連STのST名、バージョン及びST種別のリスト)1611A及び1611Bを生成し表示する。それらのリスト1611A及び1611Bは、例えばST作成画面1501上のポップアップ画面1601に表示される。
例えば、ST作成ユーザは、通常、新たに部品がインポートされた場合、その新たな部品を、古いバージョンの部品を使用する既存のSTに適応する必要があるかを検討することになる。この時、部品とSTの関係が把握できないと、どのSTをエンハンスすればよいのか不明である。
本実施形態によれば、部品リスト1531から選択された部品について、関連ST(選択された部品と部品名が同じ部品が関連付いているST)がバージョン毎に表示される。これにより、ST作成ユーザは、選択した部品と同一部品名の部品を使用しているSTを把握できる。このため、新しい部品がインポートされた場合に、どのサービステンプレートを新しい部品に入れ替える必要があるか容易に判別できる。
なお、関連STリストの表示のためのユーザ操作は、部品更新前に行われてよい。例えば、ST作成ユーザが、部品を更新するか否かの判断のために、その部品についての関連STを管理プログラム431に表示させる。ST作成ユーザは、その部品についてST種別「Release」が存在しないことがわかった場合に、選択した部品を、バージョンを更新すること無しに更新することを決めてよい。一方、ST作成ユーザは、その部品についてST種別「Release」が存在することがわかった場合に、選択した部品をバージョンと共に更新することを決めてよい。
ところで、上述したように、ST作成画面1501を用いて作成されたSTを基に、サービス作成画面を用いてサービスを作成することができる。
図17は、サービス作成画面の具体例を示す。
サービス作成画面1701は、フロー概要プレーン1721と、UIプレーン1722とを有する。管理プログラム431が、確定したSTのサービスフローの概要図を例えばフロー管理テーブル424を基に生成し、生成した概要図をフロー概要プレーン1721に表示する。
また、管理プログラム431が、確定したSTのST入力プロパティに関連付いているカスタムUI生成情報を基に、UIを生成し、生成したUIをUIプレーン1722に表示する。UIプレーン1722には、例えば図示のように、デフォルトUI1711とカスタムUI1712が混在する。
カスタムUIは、デフォルトUIよりユーザビリティが高く、値の入力がサービス作成ユーザにとって容易である。そのため、例えば図16に示したST作成画面1501の部品リスト1531に、部品名に加えて、有効なカスタムUI生成情報(「Null」ではないカスタムUI生成情報)が関連付けられているか否かも表示されてよい。ST作成ユーザは、部品名が同一の複数の部品にカスタムUIが関連付けられた部品とカスタムUIが関連付けられていない部品とあれば、カスタムUIが関連付けられている部品をSTに関連付ける部品として選択する。これにより、サービス作成において値を入力し易いSTを作成することができる。
なお、サービス作成画面1701には、例えば図示のように、STのサービスフローの概要図が表示されてもよい。
図18は、カスタムUIのバリエーションを示す。
図18によれば、表示名「Volume Capacity」を含むカスタムUI1812が、プルダウンメニュー以外のウィジェット、例えば、ラジオボタン及びチェックボックスを含む。このように、カスタムUIは、1種類以上のウィジェットを含んでよい。
図19は、カスタムUIの別のバリエーションを示す。
図19によれば、表示名「Volume Capacity」を含むカスタムUI1912が、よりユーザビリティの高いカスタムUIとなっている。例えば、表示名「Volume Capacity」に対応した値の入力は、スライダー1901の位置の調整でよい。値の上限(図19の例によれば「100GB」)は、例えば、管理プログラム431が、ストレージ装置304の構成に関する情報を基に算出した容量上限でよい。また、カスタムUI1912は、使用可能なボリューム容量を示すオブジェクト1902を表示してよい。管理プログラム431は、そのオブジェクト1902が示す使用可能ボリューム容量を、「Volume Capacity」のスライダー1901の位置の調整に応答して変更してよい。
以下、本実施形態で行われる処理を説明する。
図20は、部品インポート処理のフローチャートである。
管理プログラム431は、部品の情報パッケージ(例えば、実行ファイル及び部品プロパティを含む)を受け、部品の実行ファイルを、メモリ412(又は、外部のストレージ装置等の補助ストレージ装置)に格納する(S2001)。部品の情報パッケージは、カスタムUI生成情報の一部又は全部を含んでよい。
管理プログラム431は、実行ファイルのパス名等の情報を、部品管理テーブル421に格納する(S2002)。
また、管理プログラム431は、部品プロパティに関する情報を部品プロパティ管理テーブル422に格納する(S2003)。なお、部品プロパティ管理テーブル422の属性の一部は、インポート後に部品提供ユーザ又はST作成ユーザが追加又は変更してもよい。例えば、表示名703は他の部品の表示名と混乱することが好ましくない場合である。そして、プロパティグループについてはUIの配置をグループ化できることから、ST作成ユーザが追加又は変更してもよい。
本実施形態では、カスタムUI生成情報は、予め運用自動化システム301に存在するものではなく(運用自動化システム301にビルトインされているものではなく)、インポートされる部品に付随して入力される。これにより、インポートされる部品に適したUIを、部品のインポートという適切なタイミングで、自動的に運用自動化システム301の運用対象として追加することができる。
なお、部品インポート処理では例え同じ部品名であったとしても異なるバージョンの部品である場合は、インポートした部品に対して新しい部品ukを部品管理テーブルにて割り当てる。そのため、作成済みのサービステンプレートやサービスで用いる部品が自動で変更されることはない。そのメリットはこれまで説明してきた通りである。しかし、同じ部品名であった場合は異なるバージョンであっても従来のバージョンと同じ部品ukを割り当てる等によって、部品インポート処理によって自動的に作成済みのサービステンプレートやサービスで用いる部品を変更してもよい。
図21は、ST編集処理のフローチャートである。
ST編集処理とは、ST作成処理における処理である。ST作成ユーザがST作成画面1501のフロー作成プレーン1513上に必要な部品を置いて部品の順番を決めるが、図21に示すST編集処理は、フロー作成プレーン1513上のサービスフローのSTを一時保存する処理である。
管理プログラム431は、STの情報(ST名、STバージョン、ST uk等)を、ST管理テーブル423に格納する(S2101)。また、管理プログラム431は、そのSTのサービスフローの情報(フローuk、構成部品ukリスト等)を、フロー管理テーブル424に格納する。
管理プログラム431は、そのSTのサービスフローの構成部品ukリストが表す全ての部品の各々について(例えば、構成部品ukリストが表す部品順序通りに)、S2104〜S2106を行う(S2103)。すなわち、管理プログラム431は、構成部品ukリストから選択された部品の部品プロパティに対応したSTプロパティに関する情報を、STプロパティ管理テーブル425に格納する(S2104)。この処理には、部品プロパティ管理テーブルのカスタムUI生成情報708及びプロパティグループ707の値をSTプロパティ管理テーブル425のカスタムUI生成情報1008及びプロパティグループ1007に格納することも含む。S2104では、例えば、管理プログラム431は、前の部品の出力プロパティと、次の部品の入力プロパティの関連付けが可能か否か(キー名が同一か否か)を判断し、その判断の結果が肯定であれば、その出力プロパティ及び入力プロパティを関連付けてよい。管理プログラム431は、対応するプロパティマッピングリスト904に、S2104で格納したSTプロパティに基づく情報を追加する(S2105)。そして、管理プログラム2104は、構成部品ukリストが表す部品のうちの次の部品を選択する(S2106)。なお、ある部品の入力プロパティが、他の部品の出力プロパティと関連付いている場合は、STプロパティ管理テーブル425への登録を省略してもよい。
図22は、ST確定処理のフローチャートである。
管理プログラム431は、作成済(登録済)のSTから選択されたSTについて、ST種別「Release」が指定を受け付け、そのSTのST種別を、「Debug」から「Release」に変更する(S2201)。ST種別が「Release」となったSTについて、管理プログラム431は、編集を禁止する。なお、この編集禁止の例としては編集に関するユーザ操作を拒否したり、またそもそも編集の際に編集禁止としたSTを選択したりできないようにする、といったことが考えられる。
図23は、関連ST表示処理のフローチャートである。
管理プログラム431は、選択された部品(例えば図15の部品リスト1531から選択された部品)の部品名と同一の部品名のバージョン及び部品ukを部品管理テーブル421から特定する(S2301)。管理プログラム431は、特定した部品ukに対応するフローukをフロー管理テーブル424から特定する(S2302)。管理プログラム431は、特定したフローukに対応するST名及びST種別をST管理テーブル423から特定する(S2303)。管理プログラム431は、S2302及びS2302を、S2301で特定された全ての部品ukについて行う(S2304)。その後、管理プログラム431は、選択された部品のバージョン毎の関連STリスト(関連STのST名、バージョン及びST種別のリスト)を生成し表示する(S2305)。
図24は、サービス作成画面1701表示処理のフローチャートである。
管理プログラム431は、確定したSTの選択をサービス作成ユーザから受け、選択されたSTに対応したサービス情報(例えばST uk)を、サービス管理テーブル426に格納する(S2401)。管理プログラム431は、選択されたSTのST ukに対応する全てのSTプロパティに関する情報をSTプロパティ管理テーブル425から特定する(S2402)。管理プログラム431は、特定したSTプロパティに関連付いているカスタムUI生成情報1008を基に、各ST入力プロパティについてUI(デフォルトUI又はカスタムUI)を生成し(S2403)、生成したUIを含んだサービス作成画面1701(プロパティ入力画面)を表示する(S2404)。
なお、S2403が参照するカスタムUI生成情報1008の代わりとして、フロー管理テーブル424のプロパティマッピングリスト904の値を参考にした上で対応する部品の部品プロパティを特定し、部品プロパティ管理テーブル422のカスタムUI生成情報708を参照してもよい。サービス生成画面のUIを決定するにあたって、直接的又は間接的かに関わらず部品のカスタムUI生成情報を参照することで、サービステンプレート作成ユーザが各サービステンプレート毎にサービス作成画面をデザインしなくても利便性の高い画面を生成できるからである。
図25は、サービス実行処理のフローチャートである。
図24の処理により表示された画面のUIに値が入力され、サービス作成ユーザにより実行が指定された場合に、サービス実行処理が開始される。なお、作成されたサービスが登録されて実行待ちの状態となり、実行待ちの状態のサービスについて実行が指示されることで、サービス実行処理が乖離されてもよい。
管理プログラム431は、サービス作成画面1701(プロパティ入力画面)に入力された値を、サービスプロパティ設定テーブル427に格納する(S2501)。その後、管理プログラム431は、入力された設定値を基に、サービスを実行する(S2502)。具体的には、管理プログラム431は、例えば下記を行う。
(A)管理プログラム431は、サービスの元となったサービステンプレートを選択する。
(B)管理プログラム431は、(A)で選択したサービステンプレートのフローの構成部品ukリスト903を参照し、実行すべき部品を実行順序と共に特定する。
(C)管理プログラム431は、(B)で特定した通りに部品を実行する。(C)において、管理プログラム431は、プロパティマッピングリスト904を参照することで、適切なサービスプロパティの入力プロパティ又は他の部品の出力プロパティを選び、その値を入力する。その入力された値が、実行対象の部品の入力プロパティに設定される入力値である。なお、「部品の実行」とは、実行ファイルパス604に記載の実行ファイルを実行することである。
(D)実行順序通りに部品を実行した後、管理プログラム431は、プロパティマッピングリスト904を参照の上で、サービステンプレートの出力プロパティに関連する部品の出力プロパティを選び、その値をサービステンプレートの出力プロパティとしてサービスの実行結果として表示する。なお、サービスの実行結果についてもカスタムUI及びプロパティグループの処理を適用してもよいことは言うまでもない。
なお、実行ファイルに記載された処理内容は、典型的には、運用対象装置への構成変更、又は、運用対象装置からの構成情報、メトリック情報、状態の取得、といった要求を運用対象装置に直接又は間接に送信することである。なお、運用対象装置に要求を直接に送信する例としては、運用自動化システムから運用対象装置に要求を直接に送信する場合であり、要求を間接に送信する例としては、計算機管理システム302に対して要求を送信する場合と運用対象装置の保守員に保守メッセージを送信し、保守員が運用対象装置の運用として保守業務を行う場合とが考えられる。
図26は、UI変更処理のフローチャートである。
管理プログラム431は、UIの変更要求を受け付け(S2601)、S2602を実行する。S2602では、管理プログラム431は、UIの変更要求に従いUIの変更を実行する。UIが変更された場合、変更前のUIに関連付いている部品のコピーを作成し、その部品コピーに、新たなバージョン(変更前のUIに関連付いている部品のバージョンと異なるバージョン)を割り当てる。そして、管理プログラム431は、その部品コピーに、変更後のUI(変更後のUIを表すカスタムUI生成情報)を関連付ける。管理プログラム431は、その部品コピー(新たなバージョンの部品)に関する情報を部品管理テーブル421に格納し(追加)し、その部品コピーに関連付いている部品プロパティに関する情報を部品プロパティ管理テーブル422に格納(追加)する。なお、管理プログラム431は、変更対象のUIが関連付いている部品がいずれの既存ST(又は、いずれの既存確定ST(ST種別「Release」のST))にも関連付いていなければ、部品コピーを作成すること無しに、UIの変更を受け付けてよい。
管理プログラム431は、変更要求で指定されているUIが既存のSTに関連付いているか否かを判断する(S2603)。
S2603の判断結果が肯定の場合(S2603:YES)、管理プログラム431が、既存部品と関連がある既存STの一覧画面を表示する(S2604)。このとき、ユーザが選択した既存STについて、管理プログラム43がその既存のSTのコピーを作成し(例えば、既存のSTを基にバージョンの異なる新たなSTを作成し)(S2605)、その作成したSTコピーで使用されている既存部品を新たなバージョンの部品に入れ替える。これにより、変更後のUIが、既存のSTに関連付けられることが回避される。ここで言う「既存のST」は、ST種別が「Release」のSTであって、ST種別が「Debug」のSTは対象外でもよい。
なお、部品のUI変更処理は上記以外で実現しても良い。例えば、部品提供ユーザが、UIが更新されることで新しいバージョンとなった部品をインポートしたり、サービステンプレートを部品としてインポートしたりしている場合は、サービステンプレートに関係するカスタムUI生成情報が変更されることでバージョンアップされた場合である。
以上、一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。