まず、本発明に係るリソース交換処理の概念について説明する。図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は、SAN(Storage Area Network)によりWebサーバ41〜49やAPサーバ51〜56,DBサーバ61〜63に接続される記憶装置である。
本発明に係るリソース交換処理では、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,63の負荷が増大した場合や、ストレージ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〜79を追加する場合は、ストレージ71〜79に対して論理ボリュームの設定やネットワークの設定などを自動的におこなうことにより、当該ストレージ71〜79を業務で利用可能なストレージ71〜79として追加する。
たとえば、図1には、業務2のWebドメイン4において、プール3に登録されていたWebサーバ44が新たに追加される場合が示されている。
また、本実施例では、図2に示すように、各サーバを業務で利用可能なサーバとして追加する場合に、予め、プールに登録されているサーバを、一旦、対応するサーバ群に組み込み、必要なソフトウェアやネットワーク設定等を行った後、プールに戻す。そして、サーバの負荷が増加した場合や、サーバが故障した場合に、プールに登録されたサーバを組み込むことで、高速にサーバ故障や高負荷などに対応することができる。
さらに、このリソース交換処理では、業務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に新たに追加される。
つぎに、本実施例に係るリソース交換処理システムの機能構成について説明する。図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エージェント14aと連携して上記処理を実行する。
ストレージ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は、プールされているサーバであり、これ
らのサーバには、上記各機能部は存在しない。これらのサーバ110c,140c,150cにおいては、業務に利用可能なサーバとして設定される場合に、各機能部を実現するコンピュータプログラムがサーバ110c,140c,150cに導入され実行されることにより各機能部が実現される。
リソースマネージャエージェント111aは、ドメイン管理サーバ50のシステムリソースドメインマネージャ51からサーバ110aの情報収集処理や設定処理などの実行要求を受け付け、それらの処理をサーバRMエージェント112a、ソフトウェアRMエージェント113a、ネットワークRMエージェント114a、ストレージRMエージェント115aと連携して実行するエージェントである。
サーバRMエージェント112aは、サーバ110aの起動、停止、ハードウェアに係る情報の収集、設定などを実行するエージェントである。ソフトウェアRMエージェント114bは、サーバ110aに対するソフトウェアの導入、設定およびソフトウェアに係る情報収集などをおこなうエージェントである。
ネットワークRMエージェント114aは、サーバ110aが接続されているネットワークの情報収集および設定などを実行するエージェントである。ストレージRMエージェント115aは、サーバ110aに接続されたストレージの情報収集や設定などをおこなうエージェントである。
ストレージ160a〜160cは、Webドメイン190に属するサーバ110a〜110c、APドメイン200に属するサーバ140a〜140c、DBドメイン210に属するサーバ150a〜150cにより利用されるストレージであり、RAID装置により構成される。ストレージ160dは、プールされているストレージである。
なお、Webドメイン190に属するサーバ110a〜110c、APドメイン200に属するサーバ140a〜140c、および、DBドメイン210に属するサーバ150a〜150c間を接続するネットワークにはVLAN(Virtual Local Area Network)を設定することもできる。
つぎに、本実施例に係るリソース交換処理の処理手順について説明する。図4は、本実施例に係るリソース交換処理の処理手順を示すフローチャートである。
ここで、サイト管理サーバ20には、システムリソースマネージャ21、サーバRM22、ソフトウェアRM23、ネットワークRM24、ストレージRM25、AP管理統括部27の各機能をコンピュータに実行させるプログラムを、ドメイン管理サーバ50,60には、システムリソースドメインマネージャ51、サーバサブRM52、ソフトウェアサブRM53、ネットワークサブRM54の各機能をコンピュータに実行させるプログラムを、各サーバ110a,110b,140a,140b,150a,150bには、リソースマネージャエージェント111a,サーバRMエージェント112a、ソフトウェアRMエージェント113a、ネットワークRMエージェント114a、ストレージRMエージェント115a、AP管理部116aの各機能をコンピュータに実行させるプログラムを、あらかじめ導入しておくこととする。
図4に示すように、まず、サイト管理サーバ20のシステムリソースマネージャ21は、運用管理サーバおよび管理LANの登録処理をおこなう(ステップS101)。ここで、運用管理サーバおよび管理LANとは、サーバ110a〜110c,140a〜140c,150a〜150cやSAN170などの管理対象となるリソースを管理するために用いられるサーバおよび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は、各サーバドメインに対してプールグループを1つずつ割り当てる。また、サーバドメインが、複数のサーバグループを有する場合に、システムリソースマネージャ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_Web530を構成し、サーバ520cとサーバ520dとは、サーバグループB_Web540を構成し、サーバ560aとサーバ560bとは、サーバグループA_AP570を構成し、サーバ560cとサーバ560dとは、サーバグループB_AP580を構成している。
そして、サーバグループA_Web530とSLB600aとを接続するネットワークがネットワークサブグループA_Web_Back620を構成し、サーバグループB_Web540とSLB600bとを接続するネットワークがネットワークサブグループB_Web_Back630を構成し、SLB600aとサーバグループA_AP570とを接続するネットワークがネットワークサブグループA_AP_Front640を構成し、SLB600bとサーバグループB_AP580とを接続するネットワークがネットワークサブグループB_AP_Front650を構成している。
また、図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のドメインリソースDB26に、以下に説明するネットワークブートサーバデータ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スイッチや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(Fiber
Channel)スイッチ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グループ930,940に割り当てられた論理ボリューム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は、アフィニティグループ0およびアフィニティグループ1に属するように設定されている。また、RAID装置βの論理ボリュームLV12およびLV13は、アフィニティグループ10およびアフィニティグループ11に属するように設定されている。
図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に示したネットワークサブグループデータ6
60を読み込み、フロントネットワークサブグループおよびバックネットワークサブグループに対応するネットワークサブグループを検索し、ネットワークサブグループに割り当てられたサブネットの情報を基にして、サーバに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で説明したサーバの追加処理を繰り返す。
つぎに、サーバグループに追加されたサーバをサーバグループから削除する処理について説明する。図47は、サーバグループからサーバを削除するサーバ削除処理の処理手順を説明するフローチャートである。
図47に示すように、まず、ネットワークRM24は、ネットワークサブRM54と連携して、サーバに設定されたVLANを切断する(ステップS501)。そして、ネットワークRM24は、ネットワークサブRM54と連携して、ロードバランサの設定を変更し、負荷を分散させる対象サーバから当該サーバを除外する(ステップS502)。
続いて、ネットワークRM24は、サーバに割り当てられたIPアドレスを返却する(ステップS503)。さらに、ソフトウェアサブRM53は、ドメイン管理サーバ50のドメインリソースDB55に記憶された仮のOSを用いて、ネットワークブートによりサーバの再起動をおこなう(ステップS504)。
そして、ストレージRM25は、サーバグループから削除するサーバに割り当てられたディスクを削除する(ステップS505)。その後、ストレージRM25は、サーバに対して設定されたサーバとストレージとの間の論理的な接続関係であるSANゾーニングを変更し、当該サーバを除外したサーバとストレージとの間のSANゾーニングを設定する(ステップS506)。
つぎに、サーバ異常時や高負荷時に、サーバ資源の追加を高速で行うため、プール内のサーバにソフトウェアおよびネットワークなどの情報を事前に設定する処理について説明する。
図48は、プール内のサーバにソフトウェアおよびネットワークなどの情報を事前に設定する処理手順を示すフローチャートである。図48に示すように、システムリソースマネージャ21は、追加するサーバおよび追加対象となるサーバグループの情報を運用管理クライアント10から受付け、サーバを対応するサーバグループに移行する(登録する)(ステップS601)。
そして、システムリソースマネージャ21は、図27に示したサーバ/ストレージグループリンクデータ820を読み込んで、サーバグループのストレージグループの情報を取得し(ステップS602)、取得したストレージグループの情報を基にストレージサブグループ名を作成し、作成したストレージサブグループ名を図35に示したプロビジョニング構成データ960に登録する(ステップS603)。
続いて、システムリソースマネージャ21は、図46に示した配布管理データ1080を読み込んで、追加するサーバに配信されているソフトウェアの情報を取得する(ステップS604)。そして、システムリソースマネージャ21は、図26に示したサーバグループデータ810を読み込んで、追加するサーバに配信すべきソフトウェアを判別し(ステップS605)、判別したソフトウェアを、ソフトウェアRM23が、追加するサーバにインストールし(ステップS606)、図46に示した配布管理データ1080を更新する(ステップS607)。
そして、ネットワークRM24が、サーバのネットワーク設定を行い(ステップS608)、サーバRM22が、サーバを起動させ(ステップS609)、システムリソースマネージャ21はサーバをプールに移行する(ステップS610)。
そして、サーバRM22が、サーバを停止させ(ステップS611)、ネットワークRMがサーバをネットワークらから切り離し(ステップS612)、サーバを次のサーバグループに移行させる場合には(ステップS613,YES)、システムリソースマネージャ21はサーバを次のサーバグループに移行させ(ステップS614)、ステップS602に移行する。一方、サーバを次のサーバグループに移行させない場合には(ステップS613,No)、処理を終了する。
つぎに、図48で示したフローチャートを具体的に説明する。図49は、プール内のサーバにソフトウェアおよびネットワークなどの情報を事前に設定する処理手順を具体的に示すフローチャートである。なお、図49では一例として、追加するサーバのサーバ名を「host5」、追加対象となるサーバグループを「A_Web」および「B_Web」とする。
図49に示すように、システムリソースマネージャ21は、追加するサーバ(以下、図49の説明において、追加するサーバをhost5と表記する)および追加対象となるサーバグループA_Webの情報を運用管理クライアント10から受付け、host5をサーバグループA_Webに移行する(登録する)(ステップS701)。
そして、システムリソースマネージャ21は、図27に示したサーバ/ストレージグループリンクデータ820を読み込んで、サーバグループA_Webのストレージグループの情報を取得(サーバグループA_Webの起動用のストレージグループがA_Web_rootdiskである旨の情報を取得)し(ステップS702)、取得したストレージグループの情報を基に、ストレージサブグループ名「A_Web_rootdisk_host5」を作成し、作成したストレージサブグループ名を図35に示したプロビジョニング構成データ960に登録する(ステップS703)。
続いて、システムリソースマネージャ21は、図46に示した配布管理データ1080を読み込んで、host5に配信されているソフトウェアの情報を取得する(図46に示した配布管理データ1080は、配信後のものであり、この時点では、host5には何も配信されていない)(ステップS704)。
そして、システムリソースマネージャ21は、図26に示したサーバグループデータ810を読み込んで、host5に配信すべきソフトウェア「A_OS_Web_image 版数1.0」を判別し(ステップS705)、図43に示したソフトウェア配布イメージ管理データ1060を基に、判別したソフトウェア「A_OS_Web_image 版数1.0」に対応するソフトイメージ「apimg_snap_1」を、ソフトウェアRM23が、host5にインストールし(ステップS706)、図46に示した配布管理データ1080を更新する(ステップS707)。
そして、ネットワークRM24が、host5のネットワーク設定を行い(ステップS708)、サーバRM22が、host5を起動させ(ステップS709)、システムリソースマネージャ21はhost5をプールに移行する(ステップS710)。
そして、サーバRM22が、host5を停止させ(ステップS711)、ネットワークRM24がhost5をネットワークらから切り離し(ステップS712)、システムリソースマネージャ21が、host5をサーバグループB_Webに移行する(ステップS713)。
そして、システムリソースマネージャ21は、図27に示したサーバ/ストレージグループリンクデータ820を読み込んで、サーバグループB_Webのストレージグループの情報を取得(サーバグループB_Webの起動用のストレージグループがB_Web_rootdiskである旨の情報を取得)し(ステップS714)、取得したストレージグループの情報を基に、ストレージサブグループ名「B_Web_rootdisk host5」を作成し、作成したストレージサブグループ名を図35に示したプロビジョニング構成データ960に登録する(ステップS715)。
続いて、システムリソースマネージャ21は、図46に示した配布管理データ1080を読み込んで、host5に配信されているソフトウェアの情報を取得する(ステップS716)。
そして、システムリソースマネージャ21は、図26に示したサーバグループデータ810を読み込んで、host5に配信すべきソフトウェア「B_OS_Web_image 版数1.1」を判別し(ステップS717)、図43に示したソフトウェア配布イメージ管理データ1060を基に、判別したソフトウェア「B_OS_Web_image 版数1.1」に対応するソフトイメージ「B_OSServer,A_Software_W」を、ソフトウェアRM23が、host5にインストールし(ステップS718)、図46に示した配布管理データ1080を更新する(ステップS719)。
そして、ネットワークRM24が、host5のネットワーク設定を行い(ステップS720)、サーバRM22が、host5を起動させ(ステップS721)、システムリソースマネージャ21はhost5をプールに移行し(ステップS722)、サーバRM22が、host5を停止させ(ステップS723)、ネットワークRM24がhost5をネットワークらから切り離す(ステップS724)。
つぎに、サーバ異常時や高負荷時に、サーバ資源を追加する処理について説明する。図50は、サーバ異常時や高負荷時に、サーバ資源を追加する処理手順を示すフローチャートである。システムリソースマネージャ21が、サーバグループの負荷が所定値を上回った旨の情報を受付け(ステップS801)、追加するサーバを対応するサーバグループに移行する(ステップS802)。
そして、システムリソースマネージャ21は、図27に示したサーバ/ストレージグループリンクデータ820を読み込み、サーバグループのストレージグループの情報を取得
し(ステップS803)、図46に示した配布管理データ1080を読み込んで、追加するサーバに配信されているソフトウェアの情報を取得する(ステップS804)。
そして、図26に示したサーバグループデータ810を読み込んで、対応するサーバグループのソフトウェアが更新されている場合には(ステップS805)、ネットワークRM24は、ロードバランサのサーバへの振り分けを停止させ(ステップS806)、ソフトウェアRM23が、パッチを適応し(ステップS807)、ネットワークRM24がサーバをネットワークに接続する(ステップS808)。一方、ソフトウェアが更新されていない場合には(ステップS805,No)、そのままステップS808に移行する。
そして、ネットワークRM24は、ロードバランサのサーバへの振り分けを再開させ(ステップS809)、サーバRM22は、サーバを起動させる(ステップS810)。なお、図50では、一例としてシステムリソースマネージャ21が、サーバグループの負荷が所定値を上回った旨の情報を受付けた場合に、サーバ資源をサーバグループに追加する処理を示したが、サーバが故障した場合や、運用管理クライアント10からサーバを移行する旨の命令を受付けた場合にも同様の処理を行う。
つぎに、図50に示したサーバ異常時や高負荷時に、サーバ資源を追加する処理を具体的に説明する。図51は、サーバ異常時や高負荷時に、サーバ資源を追加する処理手順を具体的に示すフローチャートである。なお、図51では一例として、サーバグループA_Webに高負荷がかかり、サーバ(サーバ名をhost5とする)を追加する場合を示す。
図51に示すように、システムリソースマネージャ21が、サーバグループA_Webの負荷が所定値を上回った旨の情報を受付け(ステップS901)、host5をサーバグループA_Webに移行する(ステップS902)。
そして、システムリソースマネージャ21は、図27に示したサーバ/ストレージグループリンクデータ820を読み込み、サーバグループのストレージグループの情報を取得(サーバグループA_Webの起動用のストレージグループがA_Web_rootdiskである旨の情報を取得)し(ステップS903)、図46に示した配布管理データ1080を読み込んで、host5に配信されているソフトウェアの情報を取得(host5にA_OS_Web_imaga 版数1.0が配信されている旨の情報を取得)する(ステップS904)。
そして、サーバグループデータ810を読み込んで、サーバグループA_Webのソフトウェアの情報を取得する(このフローチャートでは、サーバグループA_WebのソフトウェアがA_OS_Web_image 版数1.1である旨を取得した場合を示す)(ステップS905)。
サーバグループA_Webのソフトウェアが版数1.0から版数1.1に更新されているため、ネットワークRM24は、ロードバランサのhost5への振り分けを停止させ(ステップS906)、システムリソースマネージャ21が、図43に示したソフトウェア配布イメージ管理データ1060を読み込み、ソフトウェアRM23が、「patch_a」をhost5に適応する(ステップS907)。
そして、ネットワークRM24がhost5をネットワークに接続し(ステップS908)、ロードバランサのサーバへの振り分けを再開させ(ステップS909)、サーバRM22は、サーバを起動させる(ステップS910)。
このように、プール内のサーバに対して予め、追加対象となるサーバグループに対応するソフトウェアやネットワーク設定などを行っているため、サーバ異常時や高負荷時に、プール内のサーバを迅速に追加することができ、サーバクループの運用を即座に復旧させることができる。
つぎに、システムリソースマネージャ21が、リソース割当管理処理において、運用管理クライアント10に出力する各種出力画面について説明する。図52は、管理対象となるリソースの配置を示すリソース配置出力画面1090の一例を示す図である。
図52に示すように、このリソース配置出力画面1090は、Webドメイン1100、APドメイン1110、DBドメイン1120に属する各種サーバと、ストレージドメイン1130に属するストレージとがどのように接続されているかをユーザが一目で把握できるように構成されている。
図53は、リソースの配置に係る設定をユーザから受け付けるリソース配置設定画面1140の一例を示す図である。このリソース配置設定画面1140では、部品パレット1140aが出力され、この部品パレットにあるドメインやサーバ、ストレージなどの各種アイコンをユーザがマウス等を操作して配置していくことにより、各種リソースの配置を決定することができる。
図54は、サーバドメインに属するサーバグループの一覧を出力するサーバグループ一覧画面1150の一例を示す図である。このサーバグループ一覧画面1150では、ユーザによるマウス等の操作により、サーバドメインが指定されると、そのサーバドメインに属するサーバグループおよびサーバグループに追加可能な、プールされたサーバの一覧が出力される。
図55は、サーバグループに属するサーバの一覧を出力するサーバ一覧画面1160の一例を示す図である。このサーバ一覧画面1160では、ユーザによるマウス等の操作により、サーバグループが指定されると、そのサーバグループに属するサーバおよびサーバグループに追加可能な、プールされたサーバの一覧が出力される。
さらに、このサーバ一覧画面1160では、ユーザによるマウス等の操作により、プールされたサーバが指定され、追加ボタンがクリックされると、指定されたサーバをサーバグループに追加する処理の実行要求がシステムリソースマネージャ21に送信され、当該サーバの追加処理が実行される。
また、このサーバ一覧画面1160では、ユーザによるマウス等の操作により、サーバグループに属するサーバが指定され、削除ボタンがクリックされると、指定されたサーバをサーバグループから削除する処理の実行要求がシステムリソースマネージャ21に送信され、当該サーバの削除処理が実行される。
図56は、ストレージグループに属するストレージの一覧を出力するストレージ一覧画面1170の一例を示す図である。このストレージ一覧画面1170においても、図55に示したサーバ一覧画面1160と同様、ユーザによるマウス等の操作により、ストレージグループが指定されると、そのストレージグループに属するストレージおよびストレージグループに追加可能な、プールされたストレージの一覧が出力される。
そして、ストレージ一覧画面1170では、ユーザによるマウス等の操作により、プールされたストレージが指定され、追加ボタンがクリックされると、指定されたストレージをストレージグループに追加する処理の実行要求がシステムリソースマネージャ21に送信され、当該ストレージの追加処理が実行される。
また、このストレージ一覧画面1170では、ユーザによるマウス等の操作により、ス
トレージグループに属するストレージが指定され、削除ボタンがクリックされると、指定されたストレージをストレージグループから削除する処理の実行要求がシステムリソースマネージャ21に送信され、当該ストレージの削除処理が実行される。
上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図57から図59を用いて、リソース交換処理プログラムを実行するコンピュータの一例を説明する。
図57は、図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の機能と同様の機能を発揮するプログラム、つまり、図57に示すシステムリソース交換処理プログラム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に基づいて各種データ処理を実行する。
図58は、図3に示したドメイン管理サーバ20となるコンピュータ1300のハードウェア構成を示す図である。このコンピュータ1300は、ユーザからのデータの入力を受け付ける入力装置1310、モニタ1320、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置1330、ROM1340、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース1350、HDD1360、RAM1370およびCPU1380をバス1390で接続して構成される。
そして、HDD1360には、ドメイン管理サーバ50,60の機能と同様の機能を発揮するプログラム、つまり、図57に示すドメインリソース交換処理プログラム1360bが記憶されている。なお、ドメインリソース交換処理プログラム1260bについては、適宜統合または分散して記憶することとしてもよい。
そして、CPU1380が、ドメインリソース交換処理プログラム1360bをHDD1360から読み出して実行することにより、ドメインリソース交換処理プロセス1380aとして機能するようになる。
このドメインリソース交換処理プロセス1380aは、図3に示したシステムリソースドメインマネージャ51、サーバサブRM52、ソフトウェアサブRM53、ネットワークサブRM54に対応する。
また、HDD1360には、ドメインリソースデータ1360aが記憶される。なお、このドメインリソースデータ1360aは、図3に示したドメインリソースDB55に記憶される各種データに対応する。
そして、CPU1380は、ドメインにおけるリソースの管理に係る各種データをドメインリソースデータ1360aとして記憶するとともに、ドメインリソースデータ1360aをHDD1360から読み出してRAM1370に格納し、RAM1370に格納されたドメインリソースデータ1370aに基づいて各種データ処理を実行する。
また、図59は、図3に示したサーバ110aとなるコンピュータ1400のハードウェア構成を示す図である。このコンピュータ1400は、ユーザからのデータの入力を受け付ける入力装置1410、モニタ1420、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読取り装置1430、RAM1440、ROM1450、ネットワークを介して他のコンピュータとの間でデータの授受をおこなうネットワークインターフェース1460、HDD1470およびCPU1480をバス1490で接続して構成される。
そして、HDD1470には、サーバ110aの機能と同様の機能を発揮するプログラム、つまり、図59に示すエージェントリソース交換処理プログラム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がこれらから各プログラムを読み出して実行するようにしてもよい。
上述してきたように、本実施例では、ソフトウェアRM23やネットワークRM24が、プール内のサーバに、予め、追加対象となるサーバグループに対応するソフトウェアのインストールや、ネットワーク設定をシステムリソースDB26の情報を利用して行う。そして、サーバグループに含まれるサーバが故障した場合や、サーバグループの負荷が大きくなった場合に、ソフトウェアやネットワークの設定を予め行ったサーバを、サーバグループに追加することによって、低コストかつ迅速にサーバグループを復旧させることができる。