以下に、本発明に係る運用管理プログラム、運用管理方法および運用管理装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。
まず、本実施例に係るサーバ運用管理の概念について説明する。図1は、サーバやストレージなどのリソースの運用管理の概念を示す図であり、図2は、本実施例に係るリパーパシング処理の概念を説明する図である。ここで、リパーパシング処理とは、サーバの用途を自動的に切り替える処理である。
図1には、各業務1,2においてWebサーバ41〜49やAP(Application)サーバ51〜56、DB(Database)サーバ61〜63、ストレージ71〜79などの情報処理装置が利用される場合が示されている。
ここで、Webサーバ41〜49は、Webブラウザで閲覧されるコンテンツをインターネットを介してクライアント装置に提供するサーバ装置である。APサーバ51〜56は、ユーザによる情報処理要求を受け付けたWebサーバ41〜49から要求された情報処理の実行を引き継ぐサーバ装置である。
DBサーバ61〜63は、APサーバ51〜56からデータベースへのアクセス要求を受け付けた場合に、データベースへのアクセスを管理するサーバ装置である。ストレージ71〜79は、ネットワークを介してWebサーバ41〜49やAPサーバ51〜56、データベースサーバ61〜63に接続され、SAN(Storage Area Network)を構成する記憶装置である。
本発明に係るリソース運用管理処理では、LAN(Local Area Network)やSANなどにおいて、他の装置との間の物理的な結線状態が互いに均一であるサーバやストレージなどのリソース群をドメインとして管理する。
たとえば、図1の場合には、業務1,2で利用されるサーバ群が、Webドメイン4、APドメイン5およびDBドメイン6として管理され、業務1,2で利用されるストレージ群が、ストレージドメイン7として管理されている。
この場合、Webドメイン4に属するWebサーバ41〜49の他の装置に対する結線状態は互いに均一であり、APドメイン5に属するAPサーバ51〜56の他の装置に対する結線状態は互いに均一であり、DBドメイン6に属するDBサーバ61〜63の他の装置に対する結線状態は互いに均一であり、ストレージドメイン7に属するストレージ71〜79の他の装置に対する結線状態は互いに均一となっている。
そして、このリソース運用管理処理では、未使用のWebサーバ41〜49、APサーバ51〜56、DBサーバ61〜63およびストレージ71〜79をドメインごとにプール3に登録しておき、必要に応じて各業務1,2にWebサーバ41〜49、APサーバ51〜56、DBサーバ61〜63およびストレージ71〜79を割り当てる。
たとえば、図1では、業務1には、Webサーバ42,43、APサーバ51、DBサーバ61、ストレージ77が割り当てられ、業務2には、Webサーバ49、APサーバ52,53、DBサーバ62、ストレージ78,79が割り当てられている。
そして、業務1,2に割り当てられたWebサーバ42,43,49、APサーバ51,52,53、DBサーバ61,62の負荷が増大したり、ストレージ77〜79の記憶容量が不足したような場合に、プール3に登録されているWebサーバ41,44〜48、APサーバ54〜56、DBサーバ63,ストレージ71〜76を業務で利用可能なサーバとして追加する。
具体的には、プール3に登録されているWebサーバ41,44〜48、APサーバ54〜56,DBサーバ63に必要なソフトウェアを導入し、ネットワークの設定などを自動的におこなうことにより、Webサーバ41,44〜48、APサーバ54〜56,DBサーバ63を業務で利用可能なサーバとして追加する。
また、ストレージ71〜76を追加する場合は、ストレージ71〜76に対して論理ボリュームの設定やネットワークの設定などを自動的におこなうことにより、当該ストレージ71〜76を業務で利用可能なストレージ71〜76として追加する。
たとえば、図1には、業務2のWebドメイン4において、プール3に登録されていたWebサーバ44が新たに追加される場合が示されている。
さらに、このリソース運用管理処理では、業務1,2で利用されているWebサーバ42,43,49、APサーバ51〜53,DBサーバ61,62またはストレージ77〜79が長期間使用されていないような場合に、Webサーバ42,43,49、APサーバ51〜53、DBサーバ61,62、または、ストレージ77〜79を業務で利用可能なサーバから除外し、プール3に登録する処理がおこなわれる。
ここでプール3に登録されたWebサーバ42,43,49、APサーバ51〜53,DBサーバ61,62,ストレージ77〜79は、別の業務1,2で利用されているWebサーバ42,43,49、APサーバ51〜53、DBサーバ61,62の負荷が増大したり、ストレージ77〜79の記憶容量が不足したような場合に再利用される。
具体的には、Webサーバ42,43,49、APサーバ51〜53、DBサーバ61,62に導入されているソフトウェアを削除し、ネットワークの設定の変更などを自動的におこなうことにより、Webサーバ42,43,49、APサーバ51〜53,DBサーバ61,62が業務1,2で利用可能なサーバから除外され、プール3に登録される。
また、ストレージ77〜79を業務1,2で利用可能なストレージから除外してプール3に登録する場合には、ストレージ77〜79に対するネットワークの設定などを自動的におこなうことにより、当該ストレージ77〜79を業務で利用可能なストレージから除外し、プール3に登録する。
たとえば、図1には、業務2のAPドメイン5において、プール3に登録されていたAPサーバ52が業務で利用可能なサーバから除外され、プール3に登録される場合が示されている。また、プール3に登録されたサーバ54は、業務1で利用されているサーバ51の負荷が増大したような場合に再利用され、業務1に新たに追加される。
そして、図2に示すように、リパーパシング処理においては、サーバの用途が時間帯によって自動的に切り替えられる。図2には、プールグループ8cに属するサーバ8c1,8c2が、平日昼間にはDBドメインに属するDBサーバグループ8aに追加される。ここで、DBサーバグループ8aとは、DBドメインにおいて、データをデータベースに記憶する処理をおこなうサーバのグループである。
DBサーバグループ8aに追加されたサーバ8a1,8a2は、DBサーバ用のソフトウェアが記憶されたDBサーバブートディスク9a1,9a2からネットワークブートにより起動され、業務に提供される。
そして、DBサーバグループ8aに追加されたサーバ8a1,8a2は、夜間や休日になると、プールグループ8cに返却され、さらにバッチサーバグループ8bに追加される。ここで、バッチサーバグループ8bとは、DBドメインにおいて、バッチ処理をおこなうサーバのグループである。
その際、バッチサーバグループ8bに追加されたサーバ8b1,8b2は、バッチサーバ用のソフトウェアが記憶されたバッチサーバブートディスク9b1,9b2からネットワークブートにより起動され、業務に提供される。
このように、リパーパシング処理においては、均一のソフトウェアを利用するサーバの集まりとしてサーバグループを登録し、登録したサーバグループに属するサーバが利用するソフトウェアの切り替えを制御することとしたので、サーバの数が多い大規模な情報処理システムにおいても、サーバをサーバグループ単位で管理することにより、サーバの用途の変更を管理者が容易にかつ効率的に実行することができる。
つぎに、本実施例に係るリソース運用管理システムの機能構成について説明する。図3は、本実施例に係るリソース運用管理システムの機能構成を示す図である。
図3に示すように、このリソース運用管理システムでは、運用管理クライアント10と、サイト管理サーバ20とが、FW(Firewall)30経由でネットワークを介して接続されている。また、サイト管理サーバ20とドメイン管理サーバ50,60とが、FW40経由でネットワークを介して接続されている。
また、サイト管理サーバ20と、エッジドメイン180に属するルータ80とが、FW40経由でネットワークを介して接続されている。さらに、サイト管理サーバ20と、ストレージドメイン220に属するストレージ160a〜160c、および、プールされているストレージ160dとが、FW40経由でネットワークを介して接続されている。
ドメイン管理サーバ50は、FW90、SLB(Server Load Balancer)100およびWebドメイン190に属するサーバ110a〜110cに、ネットワークを介して接続されている。
また、ドメイン管理サーバ60は、FW120、SLB130、APドメイン200に属するサーバ140a〜140c、および、DBドメイン210に属するサーバ150a〜150cに、ネットワークを介して接続されている。
さらに、ストレージドメイン220に属するストレージ160a〜160c、および、プールされているストレージ160dは、Webドメイン190に属するサーバ110a〜110c、APドメイン200に属するサーバ140a〜140c、および、DBドメイン210に属するサーバ150a〜150cにSAN170を介して接続されている。
ここで、運用管理クライアント10は、リソース運用管理処理に係るさまざまな設定をユーザから受け付けて、その設定情報をサイト管理サーバ20に送信するとともに、サイト管理サーバ20からさまざまな出力結果を受け付けて、モニタ等に表示するクライアント装置である。
サイト管理サーバ20は、図1および図2で説明したようなリソース運用管理処理およびリパーパシング処理を、ドメイン管理サーバ50,60と連携して実行するサーバ装置である。このサイト管理サーバ20は、システムリソースマネージャ21、サーバRM(Resource Manager)22、ソフトウェアRM(Resource Manager)23、ネットワークRM(Resource Manager)24、ストレージRM(Resource Manager)25、システムリソースDB(Database)26およびAP(Application)管理統括部27の各機能部を
有する。
システムリソースマネージャ21は、運用管理クライアント10からリソース運用管理処理に係るさまざまな設定情報を受け付けるとともに、サーバRM22、ソフトウェアRM23、ネットワークRM24、ストレージRM25と連携してリソースの設定処理およびリパーパシング処理を実行する管理部である。また、このシステムリソースマネージャ21は、ドメイン管理サーバ50,60との間のデータの授受を司る。
サーバRM22は、各サーバ110a〜110c,140a〜140cおよび150a〜150cの起動、停止、ハードウェアに係る情報の収集、設定などをおこなう管理部である。このサーバRM22は、ドメイン管理サーバ50のサーバサブRM(Resource Manager)52およびサーバ110aのサーバRMエージェント112aと連携して上記処理を実行する。
ソフトウェアRM23は、各サーバ110a〜110c,140a〜140cおよび150a〜150cに対するソフトウェアのインストール、設定、ソフトウェアに係る情報の収集などをおこなう管理部である。このソフトウェアRM23は、ドメイン管理サーバ50のソフトウェアサブRM(Resource Manager)53およびサーバ110aのソフトウェアRMエージェント113aと連携して上記処理を実行する。
ネットワークRM24は、ネットワークに係る情報の収集や設定などをおこなう管理部である。このネットワークRM24は、ドメイン管理サーバ50のネットワークサブRM(Resource Manager)54およびサーバ110aのネットワークRMエージェント114aと連携して上記処理を実行する。
ストレージRM25は、ストレージドメイン220に属するストレージ160a〜160c、および、プールされているストレージ160dに係る情報の収集や設定などをおこなう管理部である。ここでは、ストレージRM25は、ドメイン管理サーバ50,60を介することなく、ストレージ160a〜160c、および、プールされているストレージ160dを管理する。
システムリソースDB(Database)26は、システムリソースマネージャ21、サーバRM22、ソフトウェアRM23、ネットワークRM24およびストレージRM25が管理するさまざまなリソースの情報を記憶するデータベースである。ここに記憶される具体的なデータについては、後に詳細に説明する。
AP管理統括部27は、AP(Application)管理部116aを統括管理する処理部である。具体的には、AP管理部116aにアプリケーションの組み込み処理や設定処理の実行要求をおこなう。このAP管理統括部27の機能は、サイト管理サーバ20に導入されたミドルウェアが実行されることにより実現されるものである。
ドメイン管理サーバ50,60は、1つまたは複数のドメイン内のリソースを管理するサーバ装置である。ドメイン管理サーバ50は、システムリソースドメインマネージャ51、サーバサブRM52、ソフトウェアサブRM53、ネットワークサブRM54およびドメインリソースDB(Database)55の各機能部を有する。
なお、ドメイン管理サーバ60は、ドメイン管理サーバ50の各機能部と同様の機能部を有しているため、図3ではドメイン管理サーバ60の各機能部の図示および説明を省略する。
システムリソースドメインマネージャ51は、サーバサブRM52、ソフトウェアサブRM53、ネットワークサブRM54と連携して各ドメインに属するリソースの情報収集や設定処理などを実行する管理部である。
また、このシステムリソースドメインマネージャ51は、サイト管理サーバ20、FW90やSLB100などのネットワーク機器、また、管理対象であるサーバ110a〜110cとの間のデータの授受を司る。
サーバサブRM52は、サーバRM22およびサーバRMエージェント112aと連携して、各サーバ110a〜110cの起動、停止、ハードウェアに係る情報の収集、設定などをおこなう管理部である。
ソフトウェアサブRM53は、ソフトウェアRM23およびソフトウェアRMエージェント113aと連携して、各サーバ110a〜110cに対するソフトウェアのインストール、設定、ソフトウェアに係る情報の収集などをおこなう管理部である。
ネットワークサブRM54は、ネットワークRM24およびネットワークRMエージェント114aと連携して、ネットワークに係る情報の収集や設定などをおこなう管理部である。
ドメインリソースDB55は、サーバサブRM52、ソフトウェアサブRM53、ネットワークサブRM54が管理対象であるサーバ110a〜110cの各種情報の収集や設定をおこなう場合に、サーバ110a〜110cから取得した情報や、システムリソースDB26から取得したデータを記憶するデータベースである。また、ドメインリソースDB55は、サーバ110a〜110cのネットワークブートをおこなう場合に用いる仮のOS(Operating System)を記憶する。
ルータ80は、インターネット70を介したデータ通信においてデータパケットのルーティングをおこなうネットワーク機器である。FW30,40,90,120は、各種サーバ110a〜110c,140a〜140c,150a〜150cへの不正アクセスを防止するためのネットワーク機器である。
SLB100,130は、サーバ110a〜110c,140a〜140cに対する情報処理要求を複数のサーバ110a〜110c,140a〜140cに分散して転送する負荷分散装置である。なお、SLB100,130の前後には、さらにスイッチが接続されているが、図3ではスイッチの図示を省略している。
サーバ110a〜110c,140a〜140c,150a〜150cは、さまざまな情報処理を実行するサーバ装置である。サーバ装置110aは、リソースマネージャエージェント111a、サーバRMエージェント112a、ソフトウェアRMエージェント113a、ネットワークRMエージェント114a、ストレージRMエージェント115aおよびAP管理部116aの各機能部を有する。
なお、サーバ110b,140a,140b,150a,150bは、サーバ110aの各機能部と同様の機能部を有しているため、図3ではサーバ110b,140a,140b,150a,150bの各機能部の図示および説明を省略する。
また、サーバ110c,140c,150cは、プールされているサーバであり、これらのサーバには、リソースマネージャエージェント111a、サーバRMエージェント112a、ソフトウェアRMエージェント113a、ネットワークRMエージェント114a、ストレージRMエージェント115aおよびAP管理部116aの各機能部は存在しない。
これらのサーバ110c,140c,150cにおいては、業務に利用可能なサーバとして設定される場合に、各機能部を実現するコンピュータプログラムがサーバ110c,140c,150cに導入され実行されることにより各機能部が実現される。
リソースマネージャエージェント111aは、ドメイン管理サーバ50のシステムリソースドメインマネージャ51からサーバ110aの情報収集処理や設定処理などの実行要求を受け付け、それらの処理をサーバRMエージェント112a、ソフトウェアRMエージェント113a、ネットワークRMエージェント114a、ストレージRMエージェント115aと連携して実行するエージェントである。
サーバRMエージェント112aは、サーバ110aの起動、停止、ハードウェアに係る情報の収集、設定などを実行するエージェントである。ソフトウェアRMエージェント113aは、サーバ110aに対するソフトウェアの導入、設定およびソフトウェアに係る情報収集などをおこなうエージェントである。
ネットワークRMエージェント114aは、サーバ110aが接続されているネットワークの情報収集および設定などを実行するエージェントである。ストレージRMエージェント115aは、サーバ110aに接続されたストレージの情報収集や設定などをおこなうエージェントである。
ストレージ160a〜160cは、Webドメイン190に属するサーバ110a〜110c、APドメイン200に属するサーバ140a〜140c、DBドメイン210に属するサーバ150a〜150cにより利用されるストレージである。また、ストレージ160dは、プールされているストレージである。これらのストレージ160a〜160dは、RAID装置により構成される。
なお、Webドメイン190に属するサーバ110a〜110c、APドメイン200に属するサーバ140a〜140c、および、DBドメイン210に属するサーバ150a〜150c間を接続するネットワークにはVLAN(Virtual Local Area Network)を設定する。
つぎに、図1で説明したような、業務へのサーバの割当処理の処理手順について説明する。図4は、業務へのサーバの割当処理の処理手順を示すフローチャートである。
ここで、サイト管理サーバ20には、システムリソースマネージャ21、サーバRM22、ソフトウェアRM23、ネットワークRM24、ストレージRM25、AP管理統括部27の各機能をサイト管理サーバ20に実行させるプログラムをあらかじめ導入しておくこととする。
また、ドメイン管理サーバ50,60には、システムリソースドメインマネージャ51、サーバサブRM52、ソフトウェアサブRM53、ネットワークサブRM54の各機能をドメイン管理サーバ50,60に実行させるプログラムをあらかじめ導入しておくこととする。
さらに、各サーバ110a,110b,140a,140b,150a,150bには、リソースマネージャエージェント111a,サーバRMエージェント112a、ソフトウェアRMエージェント113a、ネットワークRMエージェント114a、ストレージRMエージェント115a、AP管理部116aの各機能をサーバ110a,110b,140a,140b,150a,150bに実行させるプログラムをあらかじめ導入しておくこととする。
図4に示すように、まず、サイト管理サーバ20のシステムリソースマネージャ21は、運用管理サーバおよび管理LANの登録処理をおこなう(ステップS101)。ここで、運用管理サーバおよび管理LANとは、サーバ110a〜110c,140a〜140c,150a〜150cやSAN170などの管理対象となるリソースを管理するために用いられるサイト管理サーバ20やドメイン管理サーバ50およびLANのことである。
以下に、ステップS101でおこなわれる処理をさらに詳細に説明する。図5は、運用管理サーバの情報を登録するサイトデータ300の一例を示す図である。このサイトデータ300は、サイト名、サイト管理サーバ名およびドメイン管理サーバ名の情報を記憶している。
サイト名は、管理対象となるリソースがあるサイトの識別情報である。サイト管理サーバ名は、そのサイトを管理するよう設定されたサイト管理サーバ20の識別情報である。ドメイン管理サーバ名は、そのサイトに設定されたドメインを管理するよう設定されたドメイン管理サーバ50,60の識別情報である。
また、図6は、ドメイン管理サーバ50,60の情報を登録するドメイン管理サーバデータ310の一例を示す図である。このドメイン管理サーバデータ310は、ドメイン管理サーバ名および管理サブネット名の情報を記憶している。
ドメイン管理サーバ名は、図5で説明したドメイン管理サーバ名と同様の情報である。管理サブネット名は、ドメイン管理サーバによりリソースが管理されるサブネット(管理サブネット)の識別情報である。
また、図7は、管理対象となるサブネットの情報を登録する管理サブネットデータ320の一例を示す図である。この管理サブネットデータ320は、管理サブネット名、ネットワークアドレス、ネットマスクおよびデフォルトゲートウェイの情報を記憶している。
管理サブネット名は、図6で説明した管理サブネット名と同様の情報である。ネットワークアドレスは、管理サブネットを識別するためのネットワークアドレスである。ネットマスクは、IPアドレスの何ビット目をネットワークアドレスとして使用するかを定義するために用いられるネットマスクである。デフォルトゲートウェイは、管理サブネット外にデータを送信する場合に用いられるデフォルトゲートウェイを特定するIPアドレスの情報である。
ステップS101において、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して設定したサイト、サイト管理サーバおよびドメイン管理サーバの情報を受け付け、その情報を図5に示したサイトデータ300に登録する。
また、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して設定したドメイン管理サーバおよび管理サブネットの情報を受け付け、その情報を図6に示したドメイン管理サーバデータ310に登録する。
続いて、システムリソースマネージャ21は、図6で説明した管理サブネットに対応するネットワークアドレス、ネットマスクおよびデフォルトゲートウェイの情報を、図7の管理サブネットデータ320に登録する。
さらに、システムリソースマネージャ21は、ミドルウェアによりその機能が実現されるAP管理統括部27に、サーバ110a〜110c,140a〜140c,150a〜150cの追加や削除などのイベントの発生を通知し、AP管理統括部27と連携して各種処理を実行するためのコマンドを設定する。
図8は、ミドルウェアと連携して各種処理を実行するためのコマンドを記憶したミドルウェア連携IFデータ330の一例を示す図である。このミドルウェア連携IFデータ330は、ミドルウェア名、対象イベント、タイミング、場所、実行コマンドの情報を記憶している。
ミドルウェア名は、システムリソースマネージャ21が連携して処理をおこなうミドルウェアの情報である。対象イベントは、システムリソースマネージャ21がミドルウェアに実行要求をおこなうイベントの情報である。タイミングは、システムリソースマネージャ21がミドルウェアに処理の実行要求を送信するタイミング(対象イベントの処理の前後)の情報である。
場所は、ミドルウェアのコマンドを実行する場所(ManagerあるいはAgent)の情報である。「Manager」は、管理サイトサーバ20上でコマンドを実行する場合を示し、「Agent」は、管理対象となるサーバ110a〜110c,140a〜140c,150a〜150c上でコマンドを実行する場合を示している。実行コマンドは、ミドルウェアに対して各種イベントの発生を通知するコマンドの情報である。
図4の説明に戻ると、システムリソースマネージャ21は、ドメインの作成処理および作成したドメイン間のリンク処理をおこなう(ステップS102)。以下に、ステップS102でおこなわれる処理をさらに詳細に説明する。
図9は、サーバ110a〜110c,140a〜140c,150a〜150cが属するドメインであるサーバドメインに係る情報を記憶したサーバドメインデータ340の一例を示す図である。
このサーバドメインデータ340は、サーバドメイン名、サーバアーキテクチャ名および管理サブネット名の情報を記憶している。サーバドメイン名は、管理対象となるサーバ110a〜110c,140a〜140c,150a〜150cが属するドメインの識別情報である。
サーバアーキテクチャ名は、各サーバドメインに属するサーバ110a〜110c,140a〜140c,150a〜150cのCPU(Central Processing Unit)アーキテクチャの識別情報である。管理サブネット名は、図6に示した管理サブネット名と同様の情報である。
ステップS102においては、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作しておこなったサーバドメインおよびサーバアーキテクチャの設定に係る情報を受け付け、サーバドメインデータ340に登録する。このサーバドメインは、ステップS101において設定された管理サブネット単位で設定される。
また、ステップS102においては、システムリソースマネージャ21は、各サーバドメインに属するサーバグループを設定し、サーバグループ間で共有されるプールグループおよび特定のサーバグループに専用のプールグループを設定する。
ここで、サーバグループとは、同一のサーバドメインに含まれるサーバを1つまたは複数のグループに分けたものである。また、プールグループとは、各サーバグループに割り当てられたサーバのプールである。
図10は、プールグループに係る情報を記憶したプールグループデータ350の一例を示す図である。このプールグループデータ350には、プールグループ名、種別、サーバドメイン名の情報が記憶されている。
プールグループ名は、上述したサーバのプールの識別情報である。種別は、プールグループが複数のサーバグループに共用させるものか、特定のサーバグループにのみ利用を許可するものかを示す情報である。サーバドメイン名は、図9で説明したサーバドメイン名と同様の情報である。
ここで、システムリソースマネージャ21は、各サーバドメインに対してプールグループを割り当てる。また、サーバドメインが、複数のサーバグループを有する場合に、システムリソースマネージャ21は、それらのサーバグループ専用のプールグループを割り当てる。
その後、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して設定したストレージドメインの情報を受け付け、システムリソースDB26にその情報を、以下に説明するストレージドメインデータ360として登録する。
図11は、ストレージドメインに係る情報を記憶したストレージドメインデータ360の一例を示す図である。このストレージドメインデータ360は、ストレージドメイン名およびパスの多重度の情報を記憶している。ストレージドメイン名は、設定されたストレージドメインを識別する識別情報である。パスの多重度は、SANにおけるデータ通信パスの多重度の情報である。
さらに、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して設定したネットワークサブドメインの情報を受け付け、システムリソースDB26にその情報を、以下に説明するネットワークサブドメインデータ470として登録する。
ここで、ネットワークサブドメインとは、異なるサーバドメインに属するサーバを接続する複数のネットワーク機器が属するネットワークドメインをさらに分割したサブドメインである。
図12は、ネットワークドメインおよびネットワークサブドメインを説明する説明図である。図12には、Webドメイン370に属するサーバ380a〜380eと、APドメイン390に属するサーバ400a〜400eとを接続するスイッチ430a,430b,450a,450b、および、SLB460a,460bが示されている。
ここで、スイッチ430aおよびスイッチ430bは、「Web-Back」ネットワークサブドメイン420を構成し、スイッチ450aおよびスイッチ450bは、「AP-Front」ネットワークサブドメイン440を構成している。
また、「Web-Back」ネットワークサブドメイン420、「AP-Front」ネットワークサブドメイン440、SLB460a、および、SLB460bが「Web-AP」ネットワークドメイン410を構成している。
図13は、ネットワークサブドメインに係る情報を記憶したネットワークサブドメインデータ470の一例を示す図である。このネットワークサブドメインデータ470は、ネットワークサブドメイン名、スイッチ機種およびスイッチ管理IPの情報を記憶している。
ネットワークサブドメイン名は、図12で説明したネットワークサブドメインを識別する情報である。スイッチ機種は、ネットワークサブドメインに属するスイッチの機種の情報である。スイッチ管理IPは、管理用に各スイッチに割り当てられたIPアドレスの情報である。
また、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して設定したネットワークドメインに係る情報を受け付け、システムリソースDB26にその情報を、以下に説明するネットワークドメインデータ480として登録する。
図14は、ネットワークドメインに係る情報を記憶したネットワークドメインデータ480の一例を示す図である。このネットワークドメインデータ480は、ネットワークドメイン名、フロントネットワークサブドメイン名、接続方式、機器名、バックネットワークサブドメイン名および冗長化方式の情報を記憶している。
ネットワークドメイン名は、図12で説明したネットワークドメインを識別する識別情報である。フロントネットワークサブドメイン名は、図12に示したように、ネットワークドメインがSLB460a,460bを境として2つのネットワークサブドメインに分割された場合に、インターネット70に近い方のネットワークサブドメインを識別する識別情報である。
接続方式は、フロントネットワークサブドメインに属するスイッチ430a,430bなどのネットワーク機器と、後に説明するバックネットワークサブドメインに属するスイッチ450a,450bなどのネットワーク機器との間を接続する方式に係る情報である。たとえば、この方式には、ロードバランサにより接続する方式や、ファイアウォールにより接続する方式などがある。機器名は、ネットワーク機器を識別する識別情報である。
バックネットワークサブドメイン名は、図12に示したように、ネットワークドメインがSLB460a,460bを境として2つのネットワークサブドメインに分割された場合に、インターネット70に遠い方のネットワークサブドメインを識別する識別情報である。冗長化方式は、ネットワークドメインにおいてデータ通信経路が冗長化されている場合の冗長化の方式を示す情報である。
さらに、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して設定したネットワークサブドメインの接続機器に係る情報を受け付け、システムリソースDB26にその情報を、以下に説明する負荷分散装置データ490として登録する。ここで、ネットワークサブドメインの接続機器とは、図12で説明したSLB460a,460bなどの機器のことである。
図15は、負荷分散装置に係る情報を記憶した負荷分散装置データ490の一例を示す図である。この負荷分散装置データ490は、負荷分散装置名、管理IP、機種名、SNMPコミュニティ名およびID/パスワードの情報を記憶している。
負荷分散装置名は、ネットワークサブドメインの接続機器を識別する名称である。管理IPは、接続機器の管理用に各接続機器に割り当てられたIPアドレスの情報である。機種名は、接続機器の機種の識別情報である。
SNMP(Simple Network Management Protocol)コミュニティ名は、接続機器を管理するドメイン管理サーバ50,60およびサイト管理サーバ20と接続機器とが属するSNMPコミュニティを特定する情報である。ID/パスワードは、接続機器にアクセスするために必要なIDおよびパスワードの情報である。
また、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して設定したネットワークサブグループの情報を受け付け、システムリソースDB26にその情報を、以下に説明するネットワークサブグループデータ660として登録する。
ここで、ネットワークサブグループとは、サーバドメインに属するサーバにサーバグループが設定されている場合に、異なるサーバドメインに属するサーバグループ間を接続するネットワークを複数のネットワークに分割したものである。
図16は、ネットワークサブグループの構成例を説明する説明図である。図16には、Webドメイン510に属するサーバ520a〜520eと、APドメイン550に属するサーバ560a〜560eとを接続するスイッチ590,610、および、SLB600a,600bが示されている。
ここで、サーバ520aとサーバ520bとは、「A_Web」サーバグループ530を構成し、サーバ520cとサーバ520dとは、「B_Web」サーバグループ540を構成し、サーバ560aとサーバ560bとは、「A_AP」サーバグループ570を構成し、サーバ560cとサーバ560dとは、「B_AP」サーバグループ580を構成している。
そして、「A_Web」サーバグループ530とSLB600aとを接続するネットワークが「A_Web_Back」ネットワークサブグループ620を構成し、「B_Web」サーバグループ540とSLB600bとを接続するネットワークが「B_Web_Back」ネットワークサブグループ630を構成し、SLB600aと「A_AP」サーバグループ570とを接続するネットワークが「A_AP_Front」ネットワークサブグループ640を構成し、SLB600bと「B_AP」サーバグループ580とを接続するネットワークが「B_AP_Front」ネットワー
クサブグループ650を構成している。
また、図17は、ネットワークサブグループに係る情報を記憶したネットワークサブグループデータ660の一例を示す図である。このネットワークサブグループデータ660は、ネットワークサブグループ名、ネットワークサブドメイン名、サブネットおよび冗長化用サブネットの情報を記憶している。
ネットワークサブグループ名は、図16で例を挙げて説明したようなネットワークサブグループを識別する識別情報である。ネットワークサブドメイン名は、ネットワークサブグループが属するネットワークサブドメインを識別する識別情報である。
サブネットは、ネットワークサブグループに割り当てられるネットワークアドレスおよびサブネットマスクの情報である。冗長化用サブネットは、ネットワークサブグループに属するネットワークが複数のデータ通信回線を用いて冗長化される場合に、余分に追加されたデータ通信回線からなるネットワークに割り当てられるネットワークアドレスおよびサブネットマスクの情報である。
その後、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して設定したサーバドメイン間の対応関係に係る情報を受け付け、システムリソースDB26にその情報を、以下に説明するサーバドメイン間リンクデータ670として登録する。
図18は、サーバドメイン間の対応関係に係る情報を記憶したサーバドメイン間リンクデータ670の一例を示す図である。このサーバドメイン間リンクデータ670は、フロントサーバドメイン名、ネットワークドメイン名およびバックサーバドメイン名の情報を記憶している。
フロントサーバドメイン名は、図12に示したようなネットワークドメインを挟むサーバドメインのうち、よりインターネット70側にあるサーバドメインを識別する識別情報である。ネットワークドメイン名は、図12で説明したネットワークドメインの識別情報である。バックサーバドメイン名は、図12に示したようなネットワークドメインを挟むサーバドメインのうち、よりインターネット70から遠い側にあるサーバドメインを示す情報である。
さらに、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して設定したサーバドメインとストレージドメインとの間の対応関係に係る情報を受け付け、システムリソースDB26にその情報を、以下に説明するサーバ/ストレージドメイン間リンクデータ680として登録する。
図19は、サーバドメインとストレージドメインとの間の対応関係に係る情報を記憶したサーバ/ストレージドメイン間リンクデータ680の一例を示す図である。このサーバ/ストレージドメイン間リンクデータ680は、サーバドメイン名およびストレージドメイン名の情報を記憶している。ここで、サーバドメイン名は、図9に示したサーバドメイン名と同様の情報である。ストレージドメイン名は、図11に示したストレージドメイン名と同様の情報である。
図4の説明に戻ると、システムリソースマネージャ21は、管理対象となるサーバリソースおよびストレージリソースの登録をおこなう(ステップS103)。以下に、ステップS103でおこなわれる処理をさらに詳細に説明する。
まず、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して、サーバを登録する管理サブネットの選択をおこなった際、ユーザにより選択された管理サブネットの情報を受け付ける。
さらに、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して入力した管理対象とするサーバの情報を運用管理クライアント10から受け付け、その情報をドメイン管理サーバ50のドメインリソースDB55に、以下に説明するネットワークブートサーバデータ690として記憶する。ここで登録されたサーバは、後にネットワークブートがおこなわれ、サーバの各種情報が取得された後、サーバリソースとして登録される。
図20は、ネットワークブートがなされるサーバの情報を記憶したネットワークブートサーバデータ690の一例を示す図である。このネットワークブートサーバデータ690は、MACアドレス、IPアドレスおよびホスト名の情報を記憶している。
MACアドレスは、サーバのMACアドレスの情報である。IPアドレスは、サーバに割り当てられたIPアドレスの情報である。ホスト名は、サーバに割り当てられたホスト名の情報である。
ここで、システムリソースマネージャ21は、ネットワークブートをおこなうサーバのユーザにより入力されたMACアドレスの情報を受け付けた場合に、そのMACアドレスに対応するサーバに、IPアドレスとホスト名とを自動的に割り当てる。
そして、システムリソースマネージャ21は、ドメイン管理サーバ50のシステムリソースドメインマネージャ51と連携し、ドメイン管理サーバ50のドメインリソースDB55に記憶された仮のOSを用いて、IPアドレスとホスト名とが割り当てられたサーバのネットワークブートをおこなう。
そして、サーバサブRM52、リソースマネージャエージェント111a、および、サーバRMエージェント112aが連携することにより、サーバのハードウェアに係る情報を収集し、収集した情報をシステムリソースドメインマネージャ51に送信する。
その後、システムリソースマネージャ21は、システムリソースドメインマネージャ51からサーバのハードウェアに係る情報を取得して、システムリソースDB26にその情報を、以下に説明する管理対象サーバデータ700として記憶する。
また、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して、SAN170を介して接続されるストレージ160a〜160dからサーバを起動するSANブートをおこなうか否かの設定情報を入力した場合に、その設定情報を受け付け、その設定情報を管理対象サーバデータ700に登録する。
図21は、管理対象となるサーバのデータを記憶した管理対象サーバデータ700の一例を示す図である。この管理対象サーバデータ700は、サーバ名、IPアドレス、MACアドレス、サーバアーキテクチャ名、モデル名、SANブートおよび状態の情報を記憶している。
サーバ名は、管理対象となるサーバを識別する名称である。IPアドレスは、サーバに割り当てられたIPアドレスである。MACアドレスは、サーバのMACアドレスである。サーバアーキテクチャ名は、サーバのCPUアーキテクチャの識別情報である。モデル名は、サーバの型式を示す情報である。SANブートは、SAN170を介して接続されるストレージ160a〜160dからサーバを起動するSANブートをおこなうか否かの設定情報である。状態は、サーバに異常が発生しているか否かを示す情報である。
なお、ここでは、ユーザがMACアドレスを指定してネットワークブートをおこなうサーバを選択することとしているが、サーバの選択を自動的におこなうようにしてもよい。具体的には、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して、自動的に選択をおこなうサーバの台数に係る情報を設定した場合に、その設定情報を運用管理クライアント10から受け付ける。
そして、システムリソースマネージャ21は、設定された台数分のサーバを選択し、選択したサーバのIPアドレスおよびホスト名の情報を、図20に示したネットワークブートサーバデータ690に登録する。
そして、システムリソースマネージャ21は、ドメイン管理サーバ50のシステムリソースドメインマネージャ51と連携し、ドメイン管理サーバ50のドメインリソースDB55に記憶された仮のOSを用いて、IPアドレスとホスト名とが割り当てられたサーバのネットワークブートをおこなう。
そして、サーバサブRM52、リソースマネージャエージェント111a、および、サーバRMエージェント112aが連携することにより、各サーバのMACアドレス、サーバアーキテクチャ、モデル、状態の情報を収集し、収集した情報をシステムリソースドメインマネージャ51に送信する。
その後、システムリソースマネージャ21は、システムリソースドメインマネージャ51から各サーバのMACアドレス、サーバアーキテクチャ、モデル、状態の情報を取得して、その情報をシステムリソースDB26に管理対象サーバデータ700として記憶する。
続いて、システムリソースマネージャ21は、管理対象となるストレージ機器の登録をおこなう。ここで、ストレージ機器とは、FC(Fiber Channel)スイッチやRAID装置などの機器である。
具体的には、システムリソースマネージャ21は、管理対象として登録するストレージのIPアドレスの情報が、図7に示した管理サブネットごとにユーザにより入力された場合に、その情報を運用管理クライアント10から受け付ける。そして、システムリソースマネージャ21は、IPアドレスに対応するストレージ機器の情報をシステムリソースDB26に記憶することによりストレージ機器を登録する。
その後、システムリソースマネージャ21は、図21の管理対象サーバデータ700に登録されたサーバをサーバドメインに追加する処理をおこなう。具体的には、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作してサーバとそのサーバを追加するサーバドメインを指定した場合に、そのサーバおよびサーバドメインの情報を運用管理クライアント10から受け付ける。
そして、システムリソースマネージャ21は、図21に示した管理対象サーバデータ700を参照し、サーバのサーバアーキテクチャが、図9に示したサーバドメインデータ340に登録されているサーバアーキテクチャと一致することをチェックする。
また、システムリソースマネージャ21は、図21に示した管理対象サーバデータ700を読み込み、サーバがSANブートをおこなうように設定されていることをチェックする。
さらに、システムリソースマネージャ21は、サーバドメインに追加するサーバのネットワークの結線状態をチェックする。具体的には、システムリソースマネージャ21は、図18に示したサーバドメイン間リンクデータ670を読み込み、サーバドメインに対するフロントサーバドメインおよびバックサーバドメインの情報を取得する。
そして、システムリソースマネージャ21は、図14に示したネットワークドメインデータ480を読み込み、ネットワークドメインに対応するフロントサブドメインおよびバックサブドメインの情報を取得する。
その後、システムリソースマネージャ21は、図13に示したネットワークサブドメインデータ470を読み込み、フロントサブドメインおよびバックサブドメインに対応するスイッチを特定する。
そして、システムリソースマネージャ21は、ネットワークRM24およびネットワークサブRM54に対して、サーバとスイッチ間の結線をチェックするよう要求する。さらに、ネットワークRM24およびネットワークサブRM54は、ネットワークRMエージェント114aにサーバとスイッチとの間の結線をチェックするよう要求し、チェック結果を取得する。
そして、システムリソースマネージャ21は、サーバとスイッチとの間の結線に問題がない場合、そのサーバに係る情報を図10で説明したプールグループに対応付けて、以下に説明するプロビジョニング構成データ710としてシステムリソースDB26に記憶する。
図22は、サーバが属するグループの情報を記憶したプロビジョニング構成データ710の一例を示す図である。このプロビジョニング構成データ710は、サーバ名、プールグループ名、サーバグループ名、ストレージサブグループ名、アクセス可否の情報を記憶する。
サーバ名は、図21で説明したサーバ名と同様の情報である。プールグループ名は、図10で説明したプールグループ名と同様の情報である。サーバグループ名は、同一のサーバドメインに含まれるサーバを1つまたは複数のグループに分けた場合のグループの識別情報である。この段階では、サーバグループ名の情報はまだ登録されない。
ストレージサブグループ名は、ストレージドメインに属するストレージを1つまたは複数のグループに分け、サーバグループに属する各サーバに割り当てた場合に、各サーバに割り当てたグループの識別情報である。この段階では、ストレージサブグループ名の情報はまだ登録されない。アクセス可否は、サーバによるストレージへのアクセスを許可するか否かを示す情報である。この段階では、アクセス可否の情報はまだ登録されない。
プロビジョニング構成データ710にサーバ名およびプールグループを登録した後、システムリソースマネージャ21は、先に登録したストレージ機器をストレージドメインに登録する。
具体的には、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して、ストレージドメインとストレージドメインに登録するストレージ機器とを指定した場合に、それらの情報を運用管理クライアント10から受け付ける。
そして、システムリソースマネージャ21は、図19に示したサーバ/ストレージドメイン間リンクデータ680を読み込んで、ストレージドメインに対応するサーバドメインを特定する。
さらに、システムリソースマネージャ21は、ストレージRM25およびストレージRMエージェント115aと連携して、特定されたサーバドメインに属するサーバと、ストレージドメインに属するストレージ機器との間の結線の均一性をチェックする。
図23は、結線状態が均一であるサーバとストレージ機器との結線の一例を示す図である。図23に示すように、この例では、ストレージドメイン740に属するFCスイッチ750a、および、サーバドメイン720に属するサーバ730a,730b間の結線状態と、ストレージドメイン740に属するFCスイッチ750b、および、サーバ730a,730b間の結線状態とが均一になっている。
また、FCスイッチ750a,750b、および、ストレージドメイン740に属するRAID装置760a間の結線状態と、FCスイッチ750a,750b、および、ストレージドメイン740に属するRAID装置760b間の結線状態が均一になっている。
システムリソースマネージャ21は、上記結線の均一性のチェックをWWPN(World Wide Port Name)の情報を基にしておこなう。その際、システムリソースマネージャ21は、図11に示したストレージドメインデータ360からストレージドメインのパスの多重度の情報を読み込み、冗長度のチェックも併せておこなう。図24は、WWPNに基づく結線の均一性チェック処理を説明する図である。
図24には、図23に示したRAID装置760a,760bが記憶しているRAID装置WWPNデータ770a,770bと、FCスイッチ750a,750bが記憶しているFCスイッチWWPNデータ780a,780bと、サーバ730a,730bが記憶しているサーバWWPNデータ790a,790bとが示されている。
RAID装置WWPNデータ770a,770bは、CA(Channel Adapter)およびWWPNの情報を記憶している。CAは、RAID装置760a,760bが有するチャネルアダプタの識別情報である。WWPNは、RAID装置760a,760bが有するチャネルアダプタに割り当てられているWWPNの情報である。
FCスイッチWWPNデータ780a,780bは、portおよび相手先WWPNの情報を記憶している。portは、FCスイッチ750a,750bのポートの識別情報である。相手先WWPNは、FCスイッチ750a,750bのポートに接続されているRAID装置760a,760bのチャネルアダプタに割り当てられているWWPNの情報、または、FCスイッチ750a,750bのポートに接続されているサーバ730a,730bのHBA(Host Bus Adapter)に割り当てられたWWPNの情報である。
サーバWWPNデータ790a,790bは、HBAおよびWWPNの情報を記憶している。HBAは、サーバ730a,730bが有するHBAの識別情報である。WWPNは、サーバ730a,730bが有するHBAに割り当てられているWWPNの情報である。
システムリソースマネージャ21は、RAID装置WWPNデータ770a,770b、FCスイッチWWPNデータ780a,780b、および、サーバWWPNデータ790a,790bをRAID装置760a,760b、FCスイッチ750a,750b、および、サーバ730a,730bから収集し、WWPNの対応関係を調べることにより、各装置間の結線状態の均一性をチェックすることができる。
その後、システムリソースマネージャ21は、あらかじめ設定されているLUN(Logical Unit)の記憶領域と、LUNが未設定の記憶領域とをプール用のストレージとして登録する。
続いて、システムリソースマネージャ21は、サーバグループの作成処理をおこなう(ステップS104)。以下に、ステップS104でおこなわれる処理をさらに詳細に説明する。
まず、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して設定したストレージテンプレートに係る情報を受け付け、システムリソースDB26にその情報を、以下に説明するストレージテンプレートデータ800として登録する。ここで、ストレージテンプレートとは、後に作成されるサーバグループ用のストレージの構成に係る設定情報である。
図25は、ストレージテンプレートに係るデータを記憶したストレージテンプレートデータ800の一例を示す図である。このストレージテンプレートデータ800は、ストレージテンプレート名、ディスク種別、ディスク名、信頼性の必要度、負荷の度合い、ディスク容量およびブートディスクの情報を記憶している。
ストレージテンプレート名は、設定されたストレージテンプレートを識別する識別情報である。ディスク種別は、ストレージテンプレートに属するディスクの用途の種別を示す情報である。
たとえば、「root」は、そのディスクがシステムデータを記憶するために利用されることを示し、「local」は、そのディスクがサーバ個別のデータを記憶するために利用されることを示し、「shared」は、そのディスクがサーバ間で共有されるデータを記憶するために利用されることを示す。
ディスク名は、各ディスクに割り当てられたディスクを識別する名称である。信頼性の必要度は、ディスクに必要とされる信頼性の情報である。負荷の度合いは、ディスクにかかる負荷の度合いの情報である。ディスク容量は、ディスクの記憶容量である。ブートディスクは、そのディスクがシステムのブート用に利用されるものか否かを示す情報である。
続いて、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して設定したサーバグループの情報を受け付け、システムリソースDB26にその情報を、以下に説明するサーバグループデータ810として記憶する。
図26は、サーバグループに係る情報を記憶したサーバグループデータ810の一例を示す図である。このサーバグループデータ810は、サーバグループ名、サーバドメイン名、ソフトウェア配布イメージ名、版数、ストレージテンプレート名、SANブートおよび自動リカバリの情報を記憶している。
サーバグループ名は、同一のサーバドメインに含まれるサーバを1つまたは複数のグループに分けた場合のグループの識別情報である。サーバドメイン名は、サーバグループが属するサーバドメインの識別情報である。ソフトウェア配布イメージ名は、サーバグループに属するサーバに配布するソフトウェアのイメージファイルを識別する情報である。
版数は、ソフトウェア配布イメージの版数の情報である。ストレージテンプレート名は、図25で説明したストレージテンプレート名と同様の情報である。SANブートは、サーバグループに属するサーバのSANブートをおこなうか否かを示す情報である。自動リカバリは、複数のサーバが連携して動作するスケールアウト構成のサーバが故障した場合に、自動的にサーバを追加する処理を実行するか否かを示す情報である。
その後、システムリソースマネージャ21は、システムリソースDB26に、サーバグループに対応するストレージグループの情報を、以下に説明するサーバ/ストレージグループリンクデータ820として登録する。ここで、ストレージグループとは、同一のストレージドメインに含まれるストレージを1つまたは複数のグループに分けたものである。
図27は、サーバグループに対応するストレージグループの情報を記憶したサーバ/ストレージグループリンクデータ820の一例を示す図である。このサーバ/ストレージグループリンクデータ820は、サーバグループ名、ストレージグループ名およびストレージドメイン名の情報を記憶している。
サーバグループ名は、図26に示したサーバグループ名と同様の情報である。ストレージグループ名は、各サーバグループに対応して生成されたストレージグループの識別情報である。ストレージドメイン名は、ストレージグループが属するストレージドメインの識別情報である。
ストレージグループを生成する際には、システムリソースマネージャ21は、図26に示したサーバグループデータ810から、サーバグループに対応付けられたストレージテンプレートの情報を読み込み、図25に示したストレージテンプレートデータ800からストレージテンプレートに対応するディスク種別の情報を読み込む。
そして、システムリソースマネージャ21は、「root」や「local」、「shared」などのディスク種別ごとに、ストレージグループを各サーバグループに対して生成し、その情報をサーバ/ストレージグループリンクデータ820に登録する。
さらに、システムリソースマネージャ21は、図19に示したサーバ/ストレージドメイン間リンクデータから、サーバグループが属するサーバドメインに対応するストレージドメインの情報を読み込み、その情報をサーバ/ストレージグループリンクデータ820に登録する。
その後、システムリソースマネージャ21は、サーバグループを追加したことをAP管理部116aに認識させるコマンドをAP管理部116aに送信する。具体的には、システムリソースマネージャ21は、図8に示した「issvgrp add」をAP管理部116aに送信する。
続いて、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して設定したサーバグループ間の対応関係の情報を受け付け、システムリソースDB26にその情報を、以下に説明するサーバグループ間リンクデータ830として登録する。
図28は、サーバグループ間の対応関係に係る情報を記憶したサーバグループ間リンクデータ830の一例を示す図である。このサーバグループ間リンクデータ830は、フロントサーバグループ名、ネットワークグループ名およびバックサーバグループ名の情報を記憶している。
フロントサーバグループ名は、ネットワークグループにより連結されるサーバグループのうち、よりインターネット70側にあるサーバグループを識別する識別情報である。ここで、ネットワークグループとは、サーバグループ間を連結するよう図16で説明したネットワークサブグループを結合したネットワークのグループである。
ネットワークグループ名は、上記ネットワークグループを識別する識別情報である。バックサーバグループ名は、ネットワークグループにより連結されるサーバグループのうち、インターネット70から遠い側にあるサーバグループを識別する識別情報である。
その後、システムリソースマネージャ21は、システムリソースDB26に、ネットワークグループに係る情報を、以下に説明するネットワークグループデータ850として記憶する。
具体的には、システムリソースマネージャ21は、まず、図18に示したサーバドメイン間リンクデータ670を読み込み、2つのサーバドメインに挟まれて設定されているネットワークドメインの情報を取得する。
そして、システムリソースマネージャ21は、図14に示したネットワークドメインデータ480を読み込み、ネットワークドメインに対応するフロントサブドメイン、バックサブドメインおよび機器の情報を取得する。
さらに、システムリソースマネージャ21は、図17に示したネットワークサブグループデータ660を読み込み、フロントサブドメイン、および、バックサブドメインに対応するネットワークサブドメインをネットワークサブグループデータ660から検索し、検索したネットワークサブドメインに対応するネットワークサブグループのうち、未使用のネットワークサブグループを抽出する。
続いて、システムリソースマネージャ21は、図14に示したネットワークドメインデータ480から読み込んだ機器の情報に該当するネットワーク機器を1つまたは複数のグループに分けて、システムリソースDB26にその情報を、以下に説明する負荷分散グループデータ840として記憶する。
図29は、負荷分散装置のグループ情報を記憶した負荷分散グループデータ840の一例を示す図である。この負荷分散グループデータ840は、負荷分散グループ名、ロードバランサ名および代表IPの情報を記憶している。
負荷分散グループ名は、ロードバランサを1つまたは複数のグループに分けた場合のグループを識別する情報である。ロードバランサ名は、ロードバランサを識別する名称である。代表IPは、各負荷分散グループに割り当てられたIPアドレスの情報である。
その後、システムリソースマネージャ21は、上記各ネットワークグループに属するネットワークドメインやネットワークサブグループ、負荷分散グループなどの対応関係の情報に基づいて、システムリソースDB26にその情報を、以下に説明するネットワークグループデータ850として記憶する。
図30は、ネットワークグループに係る情報を記憶したネットワークグループデータ850の一例を示す図である。このネットワークグループデータ850は、ネットワークグループ名、ネットワークドメイン名、フロントネットワークサブグループ名、負荷分散グループ名およびバックネットワークサブグループ名の情報を記憶している。
ネットワークグループ名は、図28で説明したネットワークグループと同様の情報である。ネットワークドメイン名は、図18で説明したネットワークドメインと同様の情報である。
フロントネットワークサブグループ名は、図17で説明したネットワークサブグループ名に対応するものであり、負荷分散グループを挟むネットワークサブグループのうち、よりインターネット70側にあるネットワークサブグループを識別する識別情報である。
負荷分散グループ名は、図29で説明した負荷分散グループ名と同様の情報である。バックネットワークサブグループ名は、図17で説明したネットワークサブグループ名に対応するものであり、負荷分散グループを挟むネットワークサブグループのうち、よりインターネット70から遠い側にあるネットワークサブグループを識別する識別情報である。
さらに、システムリソースマネージャ21は、ネットワークRM24およびネットワークサブRM54と連携し、図13のネットワークサブドメインデータ470に登録されたスイッチに対して、ネットワークサブグループのVLANの設定をおこなう。
続いて、システムリソースマネージャ21は、サーバグループに一台目のサーバを追加して、そのサーバに導入されたソフトウェアのソフトウェアイメージを作成する処理をおこなう(ステップS105)。以下に、ステップS105でおこなわれる処理をさらに詳細に説明する。
まず、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して、サーバとそのサーバを登録するサーバグループを指定した場合に、サーバおよびサーバグループの情報を受け付け、サーバグループにサーバを登録する。
そして、システムリソースマネージャ21は、図26のサーバグループデータ810を読み込んでサーバグループに対応するストレージテンプレートを検索し、そのストレージテンプレートの設定条件を図25のストレージテンプレートデータ800から取得する。
さらに、ストレージRM25は、システムリソースマネージャ21により取得されたストレージテンプレートの設定条件を満足するようプールされたストレージに論理ボリュームを設定し、論理ボリュームが設定されたストレージを上記サーバグループに割り当てる処理をおこなう。
図31は、論理ボリュームをRAID装置に設定する設定処理の処理手順を示すフローチャートである。図31に示すように、まず、システムリソースマネージャ21は、論理ボリュームの必要条件の情報を取得する(ステップS201)。ここで、論理ボリュームの必要条件とは、図25のストレージテンプレートデータ800に記憶された信頼性の必要度、負荷の度合い、および、ディスク容量の情報である。
図32は、論理ボリュームの設定画面の一例を示す図である。図32には、システムリソースマネージャ21が、運用管理クライアント10に対して出力する論理ボリュームの必要条件を表示した必要条件出力画面860と、論理ボリューム設定後の論理ボリューム構成出力画面880とが示されている。
図32の例では、3つの必要条件を満足する3つの論理ボリュームを作成するよう要求された場合が示されている。そして、必要条件出力画面860には、3つの必要条件870a〜870cが出力される。
図31の説明に戻ると、システムリソースマネージャ21は、信頼性の必要度および負荷の度合いに応じて、RAID装置のRAIDレベルを決定する(ステップS202)。図33は、RAIDレベルの設定情報を記憶したRAIDレベル設定データ940の一例を示す図である。
このRAIDレベル設定データ940は、信頼性の必要度、負荷の度合いおよびRAIDレベルの情報を記憶している。信頼性の必要度は、図25で説明した信頼性の必要度と同様の情報である。負荷の度合いは、図25で説明した負荷の度合いと同様の情報である。RAIDレベルは、信頼性の必要度および負荷の度合いにより決定されるRAIDレベルの情報である。
図31の説明に戻ると、システムリソースマネージャ21は、必要とされるディスク容量の合計値から、RAID装置種を決定する(ステップS203)。図34は、RAID装置に係る情報を記憶したRAID装置データ950の一例を示す図である。
このRAID装置データ950は、必要な記憶容量合計値、RAID装置の型名、データアクセススピード、RAIDグループを構成するディスクドライブ数(RAID0+1の場合)、RAIDグループを構成するディスクドライブ数(RAID5の場合)およびRAIDグループの最大数の情報を記憶している。
必要な記憶容量合計値は、論理ボリュームに必要とされるディスク容量の合計値の情報である。RAID装置の型名は、必要な記憶容量合計値を確保するのに適したRAID装置の型名の情報である。
データアクセススピードは、RAID装置の型名により特定されるディスクドライブのデータのアクセススピードの情報である。このデータアクセススピードには、アクセススピードが速い順に、「一番目」、「二番目」、「三番目」の3つのディスクドライブ種の情報が記憶されている。
RAIDグループを構成するディスクドライブ数(RAID0+1の場合)は、RAIDレベルがRAID0+1の場合において、RAIDグループを構成するディスクドライブの数の情報である。RAIDグループを構成するディスクドライブ数(RAID5の場合)は、RAIDレベルがRAID5の場合において、RAIDグループを構成するディスクドライブの数の情報である。RAIDグループの最大数は、作成するRAIDグループの最大数の情報である。
図31の説明に戻ると、システムリソースマネージャ21は、図34で説明したRAID装置データ950から、RAID装置種ごとの特有情報を取得する(ステップS204)。
ここで、特有情報とは、データアクセススピードのうち、「一番目」に該当するディスクドライブ種、RAIDグループを構成するディスクドライブ数(RAID0+1の場合)、RAIDグループを構成するディスクドライブ数(RAID5の場合)およびRAIDグループの最大数の情報である。
そして、ストレージRM25は、論理ボリュームを作成する(ステップS205)。具体的には、ストレージRM25は、論理ボリュームの各必要条件を満足する論理ボリュームを作成し、RAID装置に論理ボリュームを設定する。
図32に示した論理ボリューム構成出力画面880には、各必要条件900a〜900cを満足する論理ボリューム910a〜910d,920a〜920eが、RAID装置890に設定された状況が示されている。
図31の説明に戻ると、ストレージRM25は、RAIDレベルが同一である論理ボリュームをグループ化したRAIDグループを作成する(ステップS206)。そして、ストレージRM25は、作成したRAIDグループに論理ボリュームを割り当てる(ステップS207)。
図32の例では、必要条件900aおよび必要条件900bを満足する論理ボリューム910a〜910dは、RAIDレベルがRAID0+1で同じであるので、RAIDグループ930aにグループ化されている。また、必要条件900cを満足する論理ボリューム920a〜920eは、RAIDレベルがRAID5であるので、RAIDグループ930bとしてグループ化されている。
RAIDグループを作成する際には、ストレージRM25は、各RAIDグループに属するディスクドライブを、図34のRAID装置データ950のデータアクセススピードにより決定されるディスクドライブ種に設定する。
また、ストレージRM25は、RAIDグループを構成するディスクドライブ数を、図34のRAID装置データ950のRAIDグループを構成するディスクドライブ数(RAID0+1の場合)、または、RAIDグループを構成するディスクドライブ数(RAID5の場合)により決定されるディスクドライブ数に設定する。
さらに、ストレージRM25は、RAIDグループの数が図34のRAID装置データ950のRAIDグループの最大数以下になるようRAIDグループを作成する。
図32の論理ボリューム構成出力画面880では、必要条件900a〜900cを満足し、各RAIDグループ930a,930bに割り当てられた論理ボリューム910a〜910d,920a〜920eが、対応する必要条件900a〜900cと線で結合されて表示されている。
図31の説明に戻ると、ストレージRM25は、図32に示した論理ボリュームの構成をRAID装置に反映させるコマンドファイルを作成する(ステップS208)。そして、ストレージRM25は、そのコマンドファイルに基づいて、作成した論理ボリュームを実装置に反映させる(ステップS209)。
その後、システムリソースマネージャ21は、各サーバが属するサーバグループに対応付けて、RAID装置に設定された論理ボリュームをストレージサブグループとして登録し、サーバのストレージグループに対するアクセス権を設定する。具体的には、システムリソースマネージャ21は、図22に示したプロビジョニング構成データ710にサーバグループ名、ストレージサブグループ名およびアクセス可否の情報を記憶する。
図35は、ストレージサブグループが設定されたプロビジョニング構成データ960の一例を示す図である。このプロビジョニング構成データ960には、図22に示したプロビジョニング構成データ710にサーバグループ名、ストレージサブグループ名およびアクセス可否の情報が追加されている。
RAID装置に構築された論理ボリュームをサーバに認識させ、ストレージサブグループとして登録する場合には、ストレージRM25は、以下のような手順で論理ボリュームの設定をおこなう。
図36は、サーバに論理ボリュームを認識させる論理ボリュームの設定処理の処理手順を示すフローチャートである。図36に示すように、まず、ストレージRM25は、RAID装置の論理ボリュームをグループ化し、アフィニティグループを設定する(ステップ
S301)。
ここで、アフィニティグループとは、サーバが認識する論理ユニット番号(LUN, Logical Unit Number)とRAID装置における論理ボリューム(LV, Logical Volume)番号との間の対応関係を示す情報である。
図37は、RAID装置に構築された論理ボリュームの設定処理を説明する説明図である。図37には、サーバ「A」およびサーバ「B」から構成されるサーバグループ970と、論理ボリューム「LV0」、「LV1」、「LV2」、「LV3」が構築されたRAID装置「α」、および、論理ボリューム「LV10」、「LV11」、「LV12」、「LV13」が構築されたRAID装置「β」から構成されるストレージプール980とが示されている。
さらに、図37には、ストレージプール980からRAID装置「α」の論理ボリューム「LV0」および「LV1」と、RAID装置「β」の論理ボリューム「LV12」および「LV13」とが追加されたストレージグループ990が示されている。
ストレージグループ990に追加されたRAID装置「α」の論理ボリューム「LV0」および「LV1」は、アフィニティグループ「AG0」およびアフィニティグループ「AG1」に属するように設定されている。また、RAID装置「β」の論理ボリューム「LV12」および「LV13」は、アフィニティグループ「AG10」およびアフィニティグループ「AG11」に属するように設定されている。
図38は、アフィニティグループに係る情報を記憶したアフィニティグループデータ1010である。このアフィニティグループデータ1010は、RAID装置名、アフィニティグループ名、LUNおよびLVの情報を記憶している。
RAID装置名は、各RAID装置を識別する識別情報である。アフィニティグループ名は、各RAID装置において設定されたアフィニティグループの識別情報である。LUNは、サーバAまたはサーバBからアクセスする際に論理ボリュームを識別する識別情報である。LVは、論理ボリュームを識別する識別情報である。
図36の説明に戻ると、ストレージRM25は、サーバ「A」およびサーバ「B」と、論理ボリューム「LV0」,「LV1」,「LV12」,「LV13」との間の冗長パスをチェックし、パスを選択することによりアクセスパスを設定する(ステップS302)。
そして、ストレージRM25は、論理ユニットに対するマルチパスの設定をおこなう(ステップS303)。図39は、マルチパスの構成に係る情報を記憶したマルチパス構成データ1020の一例を示す図である。
このマルチパス構成データ1020は、マルチパスインスタンス名およびLUNの情報を記憶している。マルチパスインスタンス名は、設定されたマルチパスのインスタンスを識別する情報である。LUNは、設定されたマルチパスインスタンスに対応し、サーバ「A」またはサーバ「B」により認識される論理ユニットを識別する情報である。
そして、ストレージRM25は、設定したマルチパスインスタンスをミラーボリュームの構成要素としてクラスタリングをおこなうサーバのクラスタリソースに登録する(ステップS304)。その後、ストレージRM25は、クラスタリソースに登録されたマルチパスインスタンスを用いて異なるRAID装置のボリュームどうしをペアとするミラーボリュームグループを設定する(ステップS305)。
図37には、サーバ「A」またはサーバ「B」において内部設定されるサーバ内ストレージ構成1000が示されている。このストレージ構成1000においては、マルチパスインスタンス「mplb0」およびマルチパスインスタンス「mplb2」とから構成されるミラーボリューム「M0」と、マルチパスインスタンス「mplb1」およびマルチパスインスタンス「mplb3」とから構成されるミラーボリューム「M1」とが設定されている。
図40は、ミラーボリュームの構成に係る情報を記憶したミラーボリューム構成データ1030である。このミラーボリューム構成データ1030は、ミラーボリュームおよび構成ディスクの情報を記憶している。
ミラーボリュームは、設定されたミラーボリュームを識別する識別情報である。構成ディスクは、ミラーボリュームを構成する論理ユニットを識別する識別情報である。ここで、構成ディスクには、図39に示したマルチパス構成データ1020におけるマルチパスインスタンスの情報が記憶されているが、マルチパス構成データ1020を参照することにより、ミラーボリュームに対応するLUNを特定することができる。
図38に示したアフィニティグループデータ1010は、ストレージRM25によりシステムリソースDB26およびRAID装置内に記憶される。また、図39に示したマルチパス構成データ1020、および、図40に示したミラーボリューム構成データ1030は、ストレージRM25によりシステムリソースDB26に記憶されるとともに、ストレージRMエージェント115aにより管理対象であるサーバ内に記憶される。
図4に示すステップS105におけるソフトウェアイメージの作成処理の説明に戻ると、ネットワークRM24は、サーバグループに登録したサーバのネットワークの設定をつぎにおこなう。
具体的には、ネットワークRM24は、図28に示したサーバグループ間リンクデータ830から、サーバを追加したサーバグループをフロントサーバグループおよびバックサーバグループとして有するネットワークグループの情報を読み込む。
さらに、ネットワークRM24は、図30に示したネットワークグループデータ850を読み込み、ネットワークグループに対応するフロントネットワークサブグループおよびバックネットワークサブグループを抽出する。
その後、ネットワークRM24は、図17に示したネットワークサブグループデータ660を読み込み、フロントネットワークサブグループおよびバックネットワークサブグループに対応するネットワークサブグループを検索し、ネットワークサブグループに割り当てられたサブネットの情報を基にして、サーバにIPアドレスを割り当てる。
図41は、サーバに割り当てられたIPアドレスに係る情報を記憶したIPアドレス管理データ1040の一例を示す図である。このIPアドレス管理データ1040は、システムリソースマネージャ21により、システムリソースDB26に記憶される。
このIPアドレス管理データ1040は、IPアドレスおよび割当先の情報を記憶している。IPアドレスは、サーバに割り当てられたIPアドレスの情報である。割当先は、IPアドレスの割当先であるサーバを識別する情報である。
続いて、ネットワークRM24は、図29に示した負荷分散グループデータ840および図30に示したネットワークグループデータ850を基にして、サーバが追加されたサーバグループに対応するネットワークグループに代表IPアドレスを有する負荷分散グループを割り当てる。なお、この時点では、ロードバランサの負荷分散機能は停止状態にある。
その後、ユーザは、サーバに導入するOSなどのソフトウェアを、サーバグループに追加するサーバに対応付けられたストレージサブグループにインストールする。このストレージサブグループは、SANの技術を用いて構成されたものである。
そして、インストールの終了後、ソフトウェアサブRM53は、ソフトウェアRM23およびソフトウェアRMエージェント113aと連携して、OS、デバイスドライバ、アプリケーションソフトウェアなどのソフトウェアの集合体から構成されるソフトウェアイメージを作成し、作成したソフトウェアイメージをドメインリソースDB55に記憶する。
具体的には、ソフトウェアRM23は、図8に示したミドルウェア連携IFデータ330を読み込み、ソフトウェアRMエージェント113aは、ミドルウェアにより実現される機能部であるAP管理部116aに対して、ソフトウェアイメージ採取前に実行が必要なコマンドを送信する。
すなわち、ソフトウェアRMエージェント113aは、AP管理部116aの機能を停止させるコマンドを送信し、AP管理部116aの機能を停止させる。そして、ソフトウェアサブRM53は、サーバのシステムをシャットダウンする。さらに、ソフトウェアサブRM53は、サーバのドメイン管理サーバ50のドメインリソースDB55に記憶された仮のOSを用いてサーバのネットワークブートをおこなう。
その後、ソフトウェアサブRM53は、起動したサーバに導入されているソフトウェアのソフトウェアイメージを作成する。そして、ソフトウェアRM23は、システムリソースDB26にソフトウェアイメージに係る情報を、以下に説明するソフトウェアイメージ管理データ1050として登録する。
図42は、ソフトウェアイメージに係る情報を記憶したソフトウェアイメージ管理データ1050の一例を示す図である。このソフトウェアイメージ管理データ1050は、ソフトウェアイメージ名、形式、OS属性およびソフトウェア名の情報を記憶している。
ソフトウェアイメージ名は、ソフトウェアイメージの名称である。形式は、ソフトウェアイメージがアーカイブ形式で作成されたものであるのか、パッチ形式で作成されたものであるのかを示す情報である。OS属性は、ソフトウェアイメージが、OSのソフトウェアイメージであるか否かを示す情報である。ソフトウェア名は、ソフトウェアイメージが作成されたソフトウェアの名称である。
さらに、ソフトウェアサブRM53は、作成したソフトウェアイメージを基にして、他のサーバ用に配布するソフトウェア配布イメージを作成する。具体的には、ソフトウェアサブRM53は、一台目のサーバ用にストレージに導入された複数のソフトウェアのソフトウェアイメージを組にしたソフトウェア配布イメージを作成する。
そして、システムリソースマネージャ21は、システムリソースDB26にソフトウェア配布イメージに係る情報を、以下に説明するソフトウェア配布イメージ管理データ1060として記憶する。
図43は、ソフトウェア配布イメージに係る情報を記憶したソフトウェア配布イメージ管理データ1060の一例を示す図である。このソフトウェア配布イメージ管理データ1060は、ソフトウェア配布イメージ名、版数、サーバアーキテクチャ名およびソフトウェアイメージ/スナップショット名の情報を記憶している。
ソフトウェア配布イメージ名は、ソフトウェア配布イメージの名称である。版数は、ソフトウェア配布イメージの版数である。サーバアーキテクチャ名は、ソフトウェア配布イメージの配布対象となるサーバのCPUアーキテクチャを識別する識別情報である。ソフトウェアイメージ/スナップショット名は、ソフトウェア配布イメージに含まれるソフトウェアイメージまたはスナップショットを識別する識別情報である。
ここでスナップショットとは、ある特定の時点でサーバに導入されているソフトウェアのソフトウェアイメージである。システムリソースマネージャ21は、システムリソースDB26にスナップショットに係る情報を、以下に説明するスナップショット管理データ1070として登録する。
図44は、スナップショットに係る情報を記憶したスナップショット管理データ1070の一例を示す図である。このスナップショット管理データ1070は、スナップショット名およびソフトウェアイメージ名の情報を記憶している。スナップショット名は、スナップショットの名称である。ソフトウェアイメージ名は、スナップショットに含まれるソフトウェアイメージを識別する識別情報である。
その後、ソフトウェアRM23は、図8に示したミドルウェア連携IFデータ330を読み込み、ソフトウェアRMエージェント113aは、ミドルウェアにより実現される機能部であるAP管理部116aに対して、ソフトウェアイメージ採取後に実行が必要なコマンドを送信する。
具体的には、ソフトウェアRMエージェント113aは、停止していたAP管理部116aを始動させるコマンドを送信し、AP管理部116aを始動させる。そして、ネットワークRM24は、スイッチにVLANの設定をおこなってサーバをVLANに接続するとともに、ロードバランサの負荷分散機能を始動させ、負荷を分散させる対象サーバとして当該サーバを割り当てる。
その後、システムリソースマネージャ21は、図8に示したミドルウェア連携IFデータ330を読み込み、ミドルウェアにより実現される機能部であるAP管理統括部27に対して、サーバグループ作成後に実行が必要なコマンドを送信する。
具体的には、システムリソースマネージャ21はAP管理統括部27に対して、サーバグループの追加を認識させるコマンドを送信する。そして、AP管理統括部27は、AP管理部116aと連携して、サーバに対してアプリケーションプログラムの導入および設定などをおこない、サーバを業務で利用可能な状態に設定する。
図4の説明に戻ると、システムリソースマネージャ21は、二台目以降のサーバをサーバグループに追加する処理をおこなう(ステップS106)。以下に、ステップS106でおこなわれる処理をさらに詳細に説明する。
図45は、サーバをサーバグループに追加する処理の処理手順を示すフローチャートである。図45に示すように、まず、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して、サーバとそのサーバを登録するサーバグループを指定した場合に、サーバおよびサーバグループの情報を受け付ける(ステップS401)。
そして、システムリソースマネージャ21は、サーバグループにサーバを登録する(ステップS402)。続いて、システムリソースマネージャ21は、図21に示した管理対象サーバデータ700および図43に示したソフトウェア配布イメージ管理データ1060を読み込んで、サーバのサーバアーキテクチャがソフトウェアイメージを導入可能なものか否かを調べる(ステップS403)。サーバのサーバアーキテクチャがソフトウェアイメージを導入可能なものでない場合には(ステップS403,No)、当該サーバのサーバグループへの追加処理を終了する。
サーバのサーバアーキテクチャがソフトウェアイメージを導入可能なものである場合には(ステップS403,Yes)、ストレージRM25は、一台目のサーバにストレージを設定した場合と同様の方法で、サーバに対してストレージを設定する処理をおこなう(ステップS404)。具体的には、ストレージRM25は、図31および図36で説明した論理ボリュームの設定処理を当該サーバに対して実行する。
続いて、ネットワークRM24は、一台目のサーバにネットワークを設定した場合と同様の方法で、サーバグループに登録したサーバのネットワークブートを仮のOSを用いておこない、サーバのネットワークの設定をおこなう(ステップS405)。
その後、ソフトウェアサブRM53は、一台目のサーバに導入されたソフトウェアから作成されたソフトウェア配布イメージを二台目のサーバに対応付けられたストレージサブグループに展開し、展開されたソフトウェアを用いてサーバを再起動させる(ステップS406)。
ソフトウェア配布イメージをサーバに対応付けられたストレージサブグループに展開した場合には、ソフトウェアRM23は、システムリソースDB26に、配布したソフトウェア配布イメージに係る情報を記憶する。
図46は、ソフトウェア配布イメージの配布状況に係る情報を記憶した配布管理データ1080の一例を示す図である。この配布管理データ1080は、サーバ名、ストレージサブグループ名、ソフトウェア配布イメージ名、版数および状態の情報を記憶している。
サーバ名は、ストレージサブグループが割り当てられているサーバを識別する情報である。ストレージサブグループ名は、ソフトウェア配布イメージが展開されるストレージサブグループを識別する情報である。ソフトウェア配布イメージ名は、ストレージサブグループに展開されたソフトウェア配布イメージを識別する情報である。版数は、配布されたソフトウェア配布イメージの版数の情報である。状態は、ソフトウェア配布イメージの配布状況を示す情報である。
図45の説明に戻ると、システムリソースマネージャ21は、ネットワークRM24およびAP管理統括部27と連携して、二台目のサーバを業務モードに移行させる処理をおこなう(ステップS407)。
具体的には、ネットワークRM24は、サーバの再起動時に、一台目のサーバが属するサブネットの情報に基づいて、二台目のサーバにIPアドレスを割り当てる。二台目のサーバに割り当てられたIPアドレスの情報は、システムリソースマネージャ21により、図41に示したIPアドレス管理データ1040に記憶される。
続いて、ネットワークRM24は、スイッチにVLANの設定をおこなってサーバをVLANに接続するとともに、ロードバランサに対して、負荷を分散させる対象サーバとして当該サーバを登録させる。
その後、システムリソースマネージャ21は、AP管理統括部27に対して、サーバのサーバグループの追加をAP管理統括部27に認識させるコマンドを送信する。そして、AP管理統括部27は、AP管理部116aと連携して、サーバに対してアプリケーションプログラムの導入および設定などをおこない、サーバを業務で利用可能な状態に設定する。
三台目以降のサーバをサーバグループに追加する場合には、図45で説明したサーバの追加処理を繰り返す。
つぎに、図2で説明したリパーパシング処理の処理手順を図47および図48を用いて説明する。図47は、リパーパシング処理に係る事前設定処理の処理手順を説明するフローチャートであり、図48は、リパーパシング処理の処理手順を示すフローチャートである。
図47に示すように、まず、システムリソースマネージャ21は、ユーザが運用管理クライアント10を操作して設定したリパーパシングの設定に係る情報を受け付け、システムリソースDB26にその情報を、以下に説明するリパーパシング設定データ1090およびスケジュール設定データ1110として登録する(ステップS501)。
図49は、リパーパシングの設定に係る情報を記憶したリパーパシング設定データ1090の一例を示す図である。このリパーパシング設定データ1090は、リパーパシング定義名、使用サーバ数、状態1、状態2および状態3の情報を記憶している。
リパーパシング定義名は、リパーパシングの各設定に対して付与されたリパーパシングの定義名の情報である。使用サーバ名は、リパーパシング処理に使用するサーバの台数の情報である。状態1、状態2および状態3は、リパーパシング処理において、用途が異なるサーバグループにサーバが属する状態が3つある場合に、それぞれの状態においてサーバがどのサーバグループに帰属するのかを識別する情報である。この状態1、状態2および状態3には、それぞれ状態において、サーバが帰属するサーバグループの識別情報が記憶される。
ここで、サーバが現在どのサーバグループに属しているかの状態に係る情報は、システムリソースマネージャ21により、以下に説明するリパーパシング運用データ1100としてシステムリソースDB26に登録されている。図50は、サーバの状態に係る情報を記憶したリパーパシング運用データ1100の一例を示す図である。
このリパーパシング運用データ1100は、リパーパシング定義名および現在の状態の情報を記憶している。リパーパシング定義名は、図49で説明したリパーパシング定義名と同様の情報である。現在の状態は、サーバが現在どのサーバグループに属しているかの状態を識別する情報である。この現在の状態には、図49のリパーパシング設定データ1090の状態1、状態2または状態3のいずれかの状態に係る情報が記憶される。
図51は、リパーパシング処理を実行するスケジュールに係る情報を記憶したスケジュール設定データ1110の一例を示す図である。このスケジュール設定データ1110は、リパーパシング定義名、日時および動作の情報を記憶している。
リパーパシング定義名は、図49で説明したリパーパシング定義名と同様の情報である。日時は、リパーパシング処理を実行する日時の情報である。動作は、リパーパシング処理において、図49で説明した状態を切り替える場合の切り替え元の状態および切り替え先の状態を識別する情報である。
なお、図49に示したリパーパシング設定データ1090、図50に示したリパーパシング運用データ1100および図51に示したスケジュール設定データ1110には、状態1、状態2または状態3の3つの状態に係る情報が記憶されるが、その数は3つに限定されるものではなく、任意の数の状態に係る情報を記憶することができる。以下では、簡略化のため、状態1および状態2の2つの状態を切り替えるリパーパシング処理をおこなう場合について説明することとする。
図47の説明に戻ると、システムリソースマネージャ21は、状態の切り替えをおこなうサーバグループが同一のサーバドメインに属するサーバグループに属すること、また、プールグループに管理対象となるサーバが図49の使用サーバ数に設定された台数存在することをチェックする(ステップS502)。
具体的には、システムリソースマネージャ21は、サーバグループのチェックを図26に示したサーバグループデータ810を参照して実行する。また、システムリソースマネージャ21は、プールグループのチェックを図22に示したプロビジョニング構成データ710を参照して実行する。
そして、システムリソースマネージャ21は、図49に示した状態1に対応する切り替え用のサーバグループにサーバを登録する(ステップS503)。そして、システムリソースマネージャ21は、ストレージRM25と連携して、サーバを登録したサーバグループに対するストレージサブグループを作成する(ステップS504)。
具体的には、システムリソースマネージャ21は、ストレージRM25と連携することにより、RAID装置に論理ボリュームを設定し、図25に示したストレージテンプレートデータ800および図26に示したサーバグループデータ810を参照して、図35に示したように、サーバグループに対応するストレージサブグループを作成する。さらに、システムリソースマネージャ21は、作成したストレージサブグループに対するサーバからのアクセスを許可する。
続いて、システムリソースマネージャ21は、図26に示したサーバグループデータ810を参照することにより、サーバを登録したサーバグループに配信すべきソフトウェア配布イメージを選択する。そして、ソフトウェアサブRM53は、サーバグループに対応するストレージサブグループにそのソフトウェア配布イメージを配信して展開する(ステップS505)。
その後、システムリソースマネージャ21は、ネットワークサブRM54と連携して、ソフトウェア配布イメージを配信したストレージサブグループに対応するサーバからのストレージサブグループに対するアクセスを不許可に設定することにより、当該サーバをサーバグループから切り離す(ステップS506)。その際、システムリソースマネージャ21は、ストレージサブグループの削除はおこなわず、保存しておく。
続いて、システムリソースマネージャ21は、サーバグループから切り離されたサーバを、状態2に対応する切り替え用の別のサーバグループに登録する(ステップS507)。そして、システムリソースマネージャ21は、ストレージRM25と連携して、サーバを登録したサーバグループに対するストレージサブグループを作成する(ステップS508)。
具体的には、システムリソースマネージャ21は、ストレージRM25と連携することにより、RAID装置に論理ボリュームを設定し、図25に示したストレージテンプレートデータ800および図26に示したサーバグループデータ810を参照して、図35に示したように、サーバグループに対応するストレージサブグループを作成する。さらに、システムリソースマネージャ21は、作成したストレージサブグループに対するサーバからのアクセスを許可する。
その後、システムリソースマネージャ21は、図26に示したサーバグループデータ810を参照することにより、サーバを登録したサーバグループに配信すべきソフトウェア配布イメージを選択する。そして、ソフトウェアサブRM53は、サーバグループに対応するストレージサブグループにそのソフトウェア配布イメージを配信して展開し(ステップS509)、この事前設定処理を終了する。
なお、状態数が3以上である場合には、ステップS509の後、サーバをサーバグループから切り離し、状態の数だけステップS507からステップS509の処理およびサーバをサーバグループから切り離す処理を繰り返し実行すればよい。
つぎに、図48に示すように、リパーパシング処理においては、システムリソースマネージャ21は、切り替え先のサーバグループの情報を、図49に示したリパーパシング設定データ1090から取得する(ステップS601)。
そして、システムリソースマネージャ21は、図26に示したサーバグループデータ810を参照して、サーバグループに対応するソフトウェア配布イメージの情報を取得し、さらに、図46を参照して、そのソフトウェア配布イメージが配信済であることをチェックする(ステップS602)。
その後、システムリソースマネージャ21は、ネットワークサブRM54と連携して、サーバからのストレージサブグループに対するアクセスを不許可に設定することにより、サーバが現在属するサーバグループから当該サーバを切り離し、プールグループに追加する(ステップS603)。その際、システムリソースマネージャ21は、ストレージサブグループの削除はおこなわず、保存しておく。
続いて、システムリソースマネージャ21は、プールグループに追加されたサーバを、切り替え先のサーバグループに登録し(ステップS604)、登録したサーバグループに対応するストレージサブグループに作成された論理ボリュームに対するサーバからのアクセスを許可する(ステップS605)。
そして、サーバRM22は、サーバサブRM52と連携して、アクセスが許可された論理ボリュームを起動ディスクとしてサーバを起動し(ステップS606)、このリパーパシング処理を終了する。
なお、上記リパーパシング処理では、図49に示したように、各状態に対して1つのサーバグループを設定しているが、各状態に対して1つ以上のサーバグループを設定することとしてもよい。
図52は、各状態に1つ以上のサーバグループを設定したリパーパシング設定データ1120の一例を示す図である。このリパーパシング設定データ1120は、リパーパシング定義名、使用サーバ名、状態1および状態2の情報を記憶している。
リパーパシング定義名は、図49で説明したリパーパシング定義名と同様の情報である。使用サーバ数は、図49で説明した使用サーバ数と同様の情報である。状態1および状態2は、リパーパシング処理において、用途の異なるサーバグループにサーバが属する状態が2つある場合に、それぞれの状態においてサーバがどのサーバグループに帰属するのか識別する情報である。この状態1および状態2には、それぞれ状態において、サーバが帰属するサーバグループの識別情報が記憶される。
ここで、図49で説明したリパーパシング設定データ1090の状態1、状態2および状態3と異なる点は、1つのリパーパシング定義名に対して、各状態に1つ以上のサーバグループを設定して、サーバグループに属するサーバが利用するソフトウェアを別のソフトウェアに切り替え、サーバグループに属するサーバの用途を別の用途に変更する点である。
図52の例では、状態1に対して、サーバグループ「A_DB」とサーバグループ「B_DB」とが登録され、状態2に対して、サーバグループ「A_Batch」が登録されている。そして、状態1から状態2へと状態が変更される場合には、サーバグループ「A_DB」とサーバグループ「B_DB」とに属するサーバの2つの用途から、サーバグループ「A_Batch」に属するサーバの1つの用途にサーバの用途が変更される。
また、状態2から状態1へと状態が変更される場合には、サーバグループ「A_Batch」に属するサーバの1つの用途から、サーバグループ「A_DB」とサーバグループ「B_DB」とに属するサーバの2つの用途にサーバの用途が変更される。また、状態1および状態2のそれぞれに複数のサーバグループが登録された場合には、各サーバグループに属するサーバの複数の用途から別の複数の用途にサーバの用途が変更される。
また、各サーバグループには、各サーバグループに割り当てるサーバ数を設定することとしてもよい。図52の例では、状態1に対して、サーバグループ「A_DB」とサーバグループ「B_DB」とが登録され、使用サーバ数により指定される4台のサーバのうち、サーバグループ「A_DB」に対しては1台のサーバを、サーバグループ「B_DB」に対しては3台のサーバを割り当てるよう設定されている。状態2においては、サーバグループ「A_Batch」に対して、4台のサーバを割り当てるよう設定されている。
上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図53から図55を用いて、上記各種処理を実現するプログラムを実行するコンピュータの一例について説明する。
図53は、図3に示したサイト管理サーバ20となるコンピュータ1200のハードウェア構成を示す図である。このコンピュータ1200は、ユーザからのデータの入力を受け付ける入力装置1210、モニタ1220、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置1230、ROM(Read Only Memory)1240、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース1250、HDD(Hard Disk Drive)1260、RAM(Random Access Memory)1270およびCPU(Central Processing Unit)1280をバス1290で接続して構成される。
そして、HDD1260には、サイト管理サーバ20の機能と同様の機能を発揮するプログラム、つまり、図53に示すシステムリソース管理プログラム1260bおよびAP管理統括プログラム1260cが記憶されている。
なお、システムリソース管理プログラム1260bおよびAP管理統括プログラム1260cについては、適宜統合または分散して記憶することとしてもよい。
そして、CPU1280が、システムリソース管理プログラム1260bおよびAP管理統括プログラム1260cをHDD1260から読み出して実行することにより、システムリソース管理プロセス1280aおよびAP管理統括プロセス1280bとして機能するようになる。
このシステムリソース管理プロセス1280aは、図3に示したシステムリソースマネージャ21、サーバRM22、ソフトウェアRM23、ネットワークRM24、ストレージRM25に対応する。また、AP管理統括プロセス1280bは、図3に示したAP管理統括部27に対応する。
また、HDD1260には、システムリソースデータ1260aが記憶される。なお、このシステムリソースデータ1260aは、図3に示したシステムリソースDB26に記憶される各種データに対応する。
そして、CPU1280は、リソースの管理に係る各種データをシステムリソースデータ1260aとして記憶するとともに、システムリソースデータ1260aをHDD1260から読み出してRAM1270に格納し、RAM1270に格納されたシステムリソースデータ1270aに基づいて各種データ処理を実行する。
図54は、図3に示したドメイン管理サーバ20となるコンピュータ1300のハードウェア構成を示す図である。このコンピュータ1300は、ユーザからのデータの入力を受け付ける入力装置1310、モニタ1320、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置1330、ROM1340、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース1350、HDD1360、RAM1370およびCPU1380をバス1390で接続して構成される。
そして、HDD1360には、ドメイン管理サーバ50,60の機能と同様の機能を発揮するプログラム、つまり、図54に示すドメインリソース管理プログラム1360bが記憶されている。なお、ドメインリソース管理プログラム1360bについては、適宜統合または分散して記憶することとしてもよい。
そして、CPU1380が、ドメインリソース管理プログラム1360bをHDD1360から読み出して実行することにより、ドメインリソース管理プロセス1380aとして機能するようになる。
このドメインリソース管理プロセス1380aは、図3に示したシステムリソースドメインマネージャ51、サーバサブRM52、ソフトウェアサブRM53、ネットワークサブRM54に対応する。
また、HDD1360には、ドメインリソースデータ1360aが記憶される。なお、このドメインリソースデータ1360aは、図3に示したドメインリソースDB55に記憶される各種データに対応する。
そして、CPU1380は、ドメインにおけるリソースの管理に係る各種データをドメインリソースデータ1360aとして記憶するとともに、ドメインリソースデータ1360aをHDD1360から読み出してRAM1370に格納し、RAM1370に格納されたドメインリソースデータ1370aに基づいて各種データ処理を実行する。
また、図55は、図3に示したサーバ110aとなるコンピュータ1400のハードウェア構成を示す図である。このコンピュータ1400は、ユーザからのデータの入力を受け付ける入力装置1410、モニタ1420、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置1430、RAM1440、ROM1450、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース1460、HDD1470およびCPU1480をバス1490で接続して構成される。
そして、HDD1470には、サーバ110aの機能と同様の機能を発揮するプログラム、つまり、図55に示すエージェントリソース管理プログラム1470aおよびAP管理プログラム1470bが記憶されている。なお、エージェントリソース管理プログラム1470aおよびAP管理プログラム1470bについては、適宜統合または分散して記憶することとしてもよい。
そして、CPU1480が、エージェントリソース管理プログラム1470aおよびAP管理プログラム1470bをHDD1470から読み出して実行することにより、エージェントリソース管理プロセス1480aおよびAP管理プロセス1480bとして機能するようになる。
このエージェントリソース管理プロセス1480aは、図3に示したリソースマネージャエージェント111a、サーバRMエージェント112a、ソフトウェアRMエージェント113a、ネットワークRMエージェント114aおよびストレージRMエージェント115aに対応する。また、AP管理プロセス1480bは、図3に示したAP管理部116aに対応する。
ところで、システムリソース管理プログラム1260b、AP管理統括プログラム1260c、ドメインリソース管理プログラム1360b、エージェントリソース管理プログラム1470aおよびAP管理プログラム1470bについては、必ずしも最初からHDD1260、HDD1360またはHDD1470に記憶させておく必要はない。
たとえば、コンピュータ1200、1300または1400に挿入されるフレキシブルディスク(FD)、CD−ROM、MOディスク、DVDディスク、光磁気ディスク、ICカードなどの「可搬用の物理媒体」、または、コンピュータの内外に備えられるハードディスクドライブ(HDD)などの「固定用の物理媒体」、さらには、公衆回線、インターネット、LAN、WANなどを介してコンピュータ1200、1300または1400に接続される「他のコンピュータ(またはサーバ)」などに各プログラムを記憶しておき、コンピュータ1200、1300または1400がこれらから各プログラムを読み出して実行するようにしてもよい。
上述してきたように、本実施例では、システムリソースマネージャ21が、均一のソフトウェアを利用するサーバの集まりとしてサーバグループを登録し、登録したサーバグループに属するサーバが利用するソフトウェアの切り替えを制御することとしたので、サーバの数が多い大規模な情報処理システムにおいても、サーバをサーバグループ単位で管理することにより、サーバの用途の変更を管理者が容易にかつ効率的に実行することができる。
また、本実施例では、システムリソースマネージャ21が、物理結線が均一なサーバの集まりとしてサーバドメインを登録し、登録したサーバドメインにおいて均一のソフトウェアを利用するサーバの集まりとしてサーバグループを登録することとしたので、物理結線の均一性が保証された各サーバドメインにおいて、用途を切り替えるサーバが属するサーバグループを登録することにより、用途を変更して利用するサーバのサーバグループを管理者が容易に構築し、構築したサーバグループに属するサーバの用途の変更を容易にかつ効率的におこなうことができる。
また、本実施例では、システムリソースマネージャ21が、サーバグループに属するサーバにSANを介して接続されたRAID装置に記憶されているソフトウェアに対するサーバからのアクセスを制御することによりサーバが利用するソフトウェアの切り替えを制御することとしたので、ソフトウェアの切り替えを容易に実行し、サーバ群の用途変更処理を効率的におこなうことができる。
また、本実施例では、システムリソースマネージャ21が、スケジュール設定データ1110に基づいて、サーバグループに属するサーバが利用するソフトウェアの切り替えを制御することとしたので、サーバの用途の切り替えを計画的におこなうことができる。
また、本実施例では、システムリソースマネージャ21が、リパーパシング設定データ1120に基づいて、複数のサーバグループに属する複数のサーバがそれぞれ利用する各ソフトウェアを別のソフトウェアに切り替える制御、または、1つのサーバグループに属する複数のサーバが利用するソフトウェアを別の複数のソフトウェアに切り替える制御をおこなうことにより、複数のサーバの1つまたは複数の用途を別の用途に変更することとしたので、サーバの用途の変更を柔軟かつ効率的におこなうことができる。
また、本実施例では、システムリソースマネージャ21が、リパーパシング設定データ1120に基づいて、複数のリソースグループに属する指定された数のリソースがそれぞれ利用する各ソフトウェアを別のソフトウェアに切り替える制御、または、1つのリソースグループに属するリソースが利用するソフトウェアを指定された数のリソースごとに別の複数のソフトウェアに切り替える制御をおこなうことにより、複数のリソースの1つまたは複数の用途を別の用途に変更することとしたので、各用途に対して必要な数のサーバを分配することができる。
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、請求の範囲に記載した技術的思想の範囲内において種々の異なる実施例にて実施されてもよいものである。
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。
この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。