JP2016018493A - 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム - Google Patents
情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム Download PDFInfo
- Publication number
- JP2016018493A JP2016018493A JP2014142478A JP2014142478A JP2016018493A JP 2016018493 A JP2016018493 A JP 2016018493A JP 2014142478 A JP2014142478 A JP 2014142478A JP 2014142478 A JP2014142478 A JP 2014142478A JP 2016018493 A JP2016018493 A JP 2016018493A
- Authority
- JP
- Japan
- Prior art keywords
- license
- server
- information
- unit
- cpu
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Hardware Redundancy (AREA)
Abstract
【課題】クラスタ構成の情報処理システムにおいてＣＰＵライセンス数を最小化する。
【解決手段】情報処理装置２，３は、複数の処理部２２，３２と、複数の処理部２２，３２のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、複数の処理部２２，３２のいずれを動作させるかを規定するライセンス情報５４を記憶するライセンス情報記憶部５２と、情報処理装置２，３に対する電源投入が指示されると、ライセンス情報５４に基づいて、複数の処理部２２，３２のそれぞれに対し、当該処理部２２，３２を動作させるかどうかを設定する設定部４６と、設定部４６による設定の完了後に、処理部２２，３３を動作させる制御部４９と、をそなえる。
【選択図】図１
【解決手段】情報処理装置２，３は、複数の処理部２２，３２と、複数の処理部２２，３２のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、複数の処理部２２，３２のいずれを動作させるかを規定するライセンス情報５４を記憶するライセンス情報記憶部５２と、情報処理装置２，３に対する電源投入が指示されると、ライセンス情報５４に基づいて、複数の処理部２２，３２のそれぞれに対し、当該処理部２２，３２を動作させるかどうかを設定する設定部４６と、設定部４６による設定の完了後に、処理部２２，３３を動作させる制御部４９と、をそなえる。
【選択図】図１
Description
本発明は、情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラムに関する。
情報処理システムにおいては、サーバにそなえられた複数のCentral Processing Unit（ＣＰＵ）に対して、システム管理者（以下、管理者と称する）が、システムで動作させるＣＰＵの個数分のＣＰＵライセンス（以降、ライセンスとも称する）を購入するという方式が広く採用されている。
上記方式を採用している情報処理システムでは、管理者は、購入した各ライセンスを、サーバの監視及び制御を行なうファームウェア（サービスプロセッサ）であるExtended System Control Facility（ＸＳＣＦ）を用いて、１つのＣＰＵに適用（登録）する。
上記方式を採用している情報処理システムでは、管理者は、購入した各ライセンスを、サーバの監視及び制御を行なうファームウェア（サービスプロセッサ）であるExtended System Control Facility（ＸＳＣＦ）を用いて、１つのＣＰＵに適用（登録）する。
一方、システムの冗長性を向上させるために、業務に使用される運用系サーバと、バックアップ用の待機系サーバとをそなえたクラスタ構成の情報処理システムが広く用いられている。中でも、ホットスタンバイと呼ばれるクラスタ構成の情報処理システムにおいては、待機系サーバは業務には使用されず、運用系サーバの故障時にサーバ切り替えが実施されると、新たに運用系サーバとなる。このように、元は待機系であったサーバを運用系に切り替える処理を、「運用系サーバに昇格させる」と呼ぶ。逆に、元は運用系であったサーバを待機系に切り替える処理を、「待機系サーバに降格させる」と呼ぶ。
このようなクラスタ情報処理システムでＣＰＵライセンスが採用される場合、管理者は、運用系サーバと待機系サーバとの両方で使用するＣＰＵの個数分のＣＰＵライセンスを購入していた。
しかしながら、待機系サーバにおいては、運用系サーバで故障が発生し、サーバ切り替えが行なわれるまで、ＣＰＵが完全に停止されているか、或いは最小限の個数のＣＰＵのみしか使用されない。
このように、クラスタ情報処理システムにおいては、待機系サーバのＣＰＵ（以降、待機系ＣＰＵとも称する）はほとんど使用されないにも関わらず、運用系、待機系の両サーバのＣＰＵライセンスを購入し、登録する必要がある。このため、実際に使用されるＣＰＵの個数のおよそ２倍のＣＰＵライセンス費用がかかる。
このように、クラスタ情報処理システムにおいては、待機系サーバのＣＰＵ（以降、待機系ＣＰＵとも称する）はほとんど使用されないにも関わらず、運用系、待機系の両サーバのＣＰＵライセンスを購入し、登録する必要がある。このため、実際に使用されるＣＰＵの個数のおよそ２倍のＣＰＵライセンス費用がかかる。
又、運用系、待機系の両サーバのそれぞれのＣＰＵライセンスを購入及び登録する作業は非常に煩雑であり、管理者の作業負荷が高い。
１つの側面では、本件は、クラスタ構成の情報処理システムにおいてＣＰＵライセンス数を最小化することを目的とする。
１つの側面では、本件は、クラスタ構成の情報処理システムにおいてＣＰＵライセンス数を最小化することを目的とする。
このため、情報処理装置は、複数の処理部と、前記複数の処理部のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、前記複数の処理部のいずれを動作させるかを規定するライセンス情報を記憶するライセンス情報記憶部と、前記情報処理装置に対する電源投入が指示されると、前記ライセンス情報に基づいて、前記複数の処理部のそれぞれに対し、当該処理部を動作させるかどうかを設定する設定部と、前記設定部による前記設定の完了後に、前記処理部を動作させる制御部と、をそなえる。
又、複数の処理部と、前記複数の処理部のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、前記複数の処理部のいずれを動作させるかを規定するライセンス情報を記憶するライセンス情報記憶部と、をそなえる情報処理装置の制御方法は、前記情報処理装置に対する電源投入が指示されると、前記ライセンス情報に基づいて、前記複数の処理部のそれぞれに対し、当該処理部を動作させるかどうかを設定し、前記設定の完了後に、前記処理部を動作させる。
さらに、複数の処理部と、前記複数の処理部のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、前記複数の処理部のいずれを動作させるかを規定するライセンス情報を記憶するライセンス情報記憶部と、をそなえる情報処理装置の制御プログラムは、前記情報処理装置に対する電源投入が指示されると、前記ライセンス情報に基づいて、前記複数の処理部のそれぞれに対し、当該処理部を動作させるかどうかを設定し、前記設定の完了後に、前記処理部を動作させる処理をコンピュータに実行させる。
開示の技術によれば、クラスタ構成の情報処理システムにおいてＣＰＵライセンス数を最小化することができる。
以下、図面を参照して情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラムに係る実施の形態を説明する。ただし、以下に示す実施形態はあくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。又、各図は、図中に示す構成要素のみをそなえるという趣旨ではなく、他の機能等を含むことができる。
（Ａ）構成
まず、図１〜図９を参照して、実施形態の一例としての情報処理システム１の構成を説明する。
（Ａ）構成
まず、図１〜図９を参照して、実施形態の一例としての情報処理システム１の構成を説明する。
図１は、実施形態の一例としての情報処理システム１のシステム構成を示す図であり、図２は、実施形態の一例としてのサーバ２，３のハードウェア構成を示す図である。
情報処理システム１は、ホットスタンバイ型のクラスタシステムである。
ここで、ホットスタンバイ型のクラスタシステムとは、ユーザに対してサービスを提供する運用系サーバ２と、当該運用系サーバ２の故障にそなえて待機（ホットスタンバイ）している待機系サーバ３とが存在するシステムである。
情報処理システム１は、ホットスタンバイ型のクラスタシステムである。
ここで、ホットスタンバイ型のクラスタシステムとは、ユーザに対してサービスを提供する運用系サーバ２と、当該運用系サーバ２の故障にそなえて待機（ホットスタンバイ）している待機系サーバ３とが存在するシステムである。
本情報処理システム１は、運用系サーバ２と、待機系サーバ３と、Personal Computer（ＰＣ）４とをそなえる。運用系サーバ２、待機系サーバ３及びＰＣ４は、Local Area Network（ＬＡＮ）等のネットワーク５により相互に接続されている。
情報処理システム１のユーザは、ＰＣ４を介して、運用系サーバ２が提供するサービスを利用する。
情報処理システム１のユーザは、ＰＣ４を介して、運用系サーバ２が提供するサービスを利用する。
以降、簡潔を期するために、運用系サーバ２を単にサーバ２、待機系サーバ３を単にサーバ３とも呼ぶ。
サーバ２は、サーバ機能をそなえた情報処理装置であり、システムボード（System Board：ＳＢ）２１とＸＳＣＦ２５とをそなえる。
ＳＢ２１は、複数のＣＰＵ（処理部）２２−１〜２２−ｋ（ｋは２以上の整数）、メモリ２３、及び入出力（Input/Output；Ｉ／Ｏ）コントローラ（単にＩ／Ｏとも呼ぶ）２４をそなえる。
サーバ２は、サーバ機能をそなえた情報処理装置であり、システムボード（System Board：ＳＢ）２１とＸＳＣＦ２５とをそなえる。
ＳＢ２１は、複数のＣＰＵ（処理部）２２−１〜２２−ｋ（ｋは２以上の整数）、メモリ２３、及び入出力（Input/Output；Ｉ／Ｏ）コントローラ（単にＩ／Ｏとも呼ぶ）２４をそなえる。
ＣＰＵ２２−１〜２２−ｋは、サーバ２のOperating System（ＯＳ）を実行すると共に、サーバ２で実行される種々の制御や演算を行なう処理装置であり、不図示のＲＯＭやHard Disk Drive（ＨＤＤ）等に格納されているプログラム等を読み出し、各種処理を実行する。ＣＰＵ２２−１〜２２−ｋは、例えば、公知のＣＰＵを使用して実装することができる。
なお、以下、サーバ２のＣＰＵを示す符号としては、複数のＣＰＵのうち１つを特定する必要があるときには符号２２−１〜２２−ｋを用いるが、任意のＣＰＵを指すときには符号２２を用いる。
メモリ２３は、ＣＰＵ２２が実行するプログラムや種々のデータや、ＣＰＵ２２の動作により得られたデータ等を格納する。メモリ２３としては、例えば、Random Access Memory（ＲＡＭ）など、既存の種々のメモリを使用することができる。
メモリ２３は、ＣＰＵ２２が実行するプログラムや種々のデータや、ＣＰＵ２２の動作により得られたデータ等を格納する。メモリ２３としては、例えば、Random Access Memory（ＲＡＭ）など、既存の種々のメモリを使用することができる。
Ｉ／Ｏコントローラ２４は、サーバ２と外部との入出力を制御するコントローラである。
ＸＳＣＦ２５は、ＳＢ２１のＣＰＵ２２、メモリ２３、及びＩ／Ｏコントローラ２４等の監視及び制御を行なうファームウェア（サービスプロセッサ）であり、不図示のＣＰＵと不揮発性メモリとをそなえる。
ＸＳＣＦ２５は、ＳＢ２１のＣＰＵ２２、メモリ２３、及びＩ／Ｏコントローラ２４等の監視及び制御を行なうファームウェア（サービスプロセッサ）であり、不図示のＣＰＵと不揮発性メモリとをそなえる。
ＸＳＣＦ２５の不図示のＣＰＵは、プログラムを実行することにより、ユーザＩ／Ｆ部４１、ライセンス登録部４２、ＳＢ電源制御部４３、ライセンス制御部（設定部）４６、サーバ判定部４７、ライセンス設定部（管理部）４８、ＣＰＵ制御部（制御部）４９、サーバ監視部５０、及びサーバ間通信部（通信部）５１として機能する。
又、ＸＳＣＦ２５の不図示の不揮発性メモリは、後述するライセンスデータベース（ＤＢ）（ライセンス情報記憶部）５２を記憶する記憶部として機能する。
又、ＸＳＣＦ２５の不図示の不揮発性メモリは、後述するライセンスデータベース（ＤＢ）（ライセンス情報記憶部）５２を記憶する記憶部として機能する。
サーバ３は、サーバ機能をそなえた情報処理装置であり、ＳＢ３１とＸＳＣＦ３５とをそなえる。
ＳＢ３１は、複数のＣＰＵ（処理部）３２−１〜３２−ｋ（ｋは２以上の整数）、メモリ３３、及びＩ／Ｏ）コントローラ（単にＩ／Ｏとも呼ぶ）３４をそなえる。
ＣＰＵ３２−１〜３２−ｋは、サーバ３のＯＳを実行すると共に、サーバ３で実行される種々の制御や演算を行なう処理装置であり、不図示のＲＯＭやＨＤＤ等に格納されているプログラム等を読み出し、各種処理を実行する。ＣＰＵ３２−１〜３２−ｋは、例えば、公知のＣＰＵを使用して実装することができる。
ＳＢ３１は、複数のＣＰＵ（処理部）３２−１〜３２−ｋ（ｋは２以上の整数）、メモリ３３、及びＩ／Ｏ）コントローラ（単にＩ／Ｏとも呼ぶ）３４をそなえる。
ＣＰＵ３２−１〜３２−ｋは、サーバ３のＯＳを実行すると共に、サーバ３で実行される種々の制御や演算を行なう処理装置であり、不図示のＲＯＭやＨＤＤ等に格納されているプログラム等を読み出し、各種処理を実行する。ＣＰＵ３２−１〜３２−ｋは、例えば、公知のＣＰＵを使用して実装することができる。
なお、以下、サーバ３のＣＰＵを示す符号としては、複数のＣＰＵのうち１つを特定する必要があるときには符号３２−１〜３２−ｋを用いるが、任意のＣＰＵを指すときには符号３２を用いる。
メモリ３３は、ＣＰＵ３２が実行するプログラムや種々のデータや、ＣＰＵ３２の動作により得られたデータ等を格納する。メモリ３３としては、例えば、ＲＡＭなど、既存の種々のメモリを使用することができる。
メモリ３３は、ＣＰＵ３２が実行するプログラムや種々のデータや、ＣＰＵ３２の動作により得られたデータ等を格納する。メモリ３３としては、例えば、ＲＡＭなど、既存の種々のメモリを使用することができる。
Ｉ／Ｏコントローラ３４は、サーバ３と外部との入出力を制御するコントローラである。
ＸＳＣＦ３５は、ＳＢ３１のＣＰＵ３２、メモリ３３、及びＩ／Ｏコントローラ３４等の監視及び制御を行なうファームウェア（サービスプロセッサ）であり、不図示のＣＰＵと不揮発性メモリとをそなえる。
ＸＳＣＦ３５は、ＳＢ３１のＣＰＵ３２、メモリ３３、及びＩ／Ｏコントローラ３４等の監視及び制御を行なうファームウェア（サービスプロセッサ）であり、不図示のＣＰＵと不揮発性メモリとをそなえる。
ＸＳＣＦ３５の不図示のＣＰＵは、ＸＳＣＦ２５の不図示のＣＰＵと同様に、プログラムを実行することにより、ユーザＩ／Ｆ部４１、ライセンス登録部４２、ＳＢ電源制御部４３、ライセンス制御部４６、サーバ判定部４７、ライセンス設定部４８、ＣＰＵ制御部４９、サーバ監視部５０、及びサーバ間通信部５１として機能する。
又、ＸＳＣＦ３５の不図示の不揮発性メモリは、後述するライセンス記憶域５３及びライセンス属性テーブル（ライセンス情報）５４を格納するライセンスＤＢ５２を記憶する記憶部として機能する。
又、ＸＳＣＦ３５の不図示の不揮発性メモリは、後述するライセンス記憶域５３及びライセンス属性テーブル（ライセンス情報）５４を格納するライセンスＤＢ５２を記憶する記憶部として機能する。
本情報処理システム１はクラスタ構成のシステムであり、待機系サーバ３は、後述するように運用系サーバ２が稼働しているかどうかを常時監視する。詳細には、待機系サーバ３は、運用系サーバ２上で実行されているＯＳの稼動状況を監視する。運用系サーバ２のＯＳが動作を停止（ハングアップ）したことを検出すると、待機系サーバ３は、自らを運用系サーバに昇格させて、ユーザへのサービスの提供を継続しようとする。
このために、待機系サーバ３は、ＸＳＣＦ３５を介して運用系サーバ２を強制的に停止させる強制停止を指示する。この指示を受けると、運用系サーバ２のＸＳＣＦ２５は、当該サーバ２の動作しているＣＰＵ２２を停止させて、サーバ２のＯＳを停止させる。待機系サーバ３は、運用系サーバ２が完全に停止されると、自身が新たな運用系サーバ３に昇格する。
ユーザＩ／Ｆ部４１は、ＰＣ４とＸＳＣＦ２５とを接続する。管理者は、ＰＣ４を用いてＸＳＣＦ２５に接続し、サーバ２の各種設定を行なったり、サーバ２の状態を閲覧する。
ライセンス登録部４２は、管理者が購入したＣＰＵライセンスのＣＰＵライセンスデータ（図７（ａ），（ｂ）参照）を後述するライセンスＤＢ５２のライセンスファイル５３に登録すると共に、当該ＣＰＵライセンスデータに基づいてライセンス属性テーブル５４を更新する。
ライセンス登録部４２は、管理者が購入したＣＰＵライセンスのＣＰＵライセンスデータ（図７（ａ），（ｂ）参照）を後述するライセンスＤＢ５２のライセンスファイル５３に登録すると共に、当該ＣＰＵライセンスデータに基づいてライセンス属性テーブル５４を更新する。
ここで、ＣＰＵライセンスについて説明する。ＣＰＵライセンス（単にライセンスとも呼ぶ）とは、ＣＰＵ２２，３２の使用権であり、１つのＣＰＵライセンスに対して、システム内のＣＰＵ２２，３２のいずれか１つの使用が許可される。例えば、ＣＰＵライセンスは、例えば図７（ａ），（ｂ）に示すようなＣＰＵライセンスファイル（ライセンスファイルとも称する）の形でサーバ２，３に配布される。
ＳＢ電源制御部４３は、ＳＢ２１の不図示の電源を制御して、ＳＢ２１の電源を投入又は切断する。
ライセンス制御部４６は、ＣＰＵライセンスの管理を行なう。ライセンス制御部４６は、サーバ判定部４７とライセンス設定部４８とをそなえる。
サーバ判定部４７は、ＸＳＣＦ２５の不図示の内部情報を参照して、自サーバ２がクラスタシステム用サーバか、非クラスタシステム用サーバかを判定する。又、サーバ判定部４７は、自サーバ２がクラスタシステム用サーバである場合には、運用系サーバか待機系サーバかも判定する。
ライセンス制御部４６は、ＣＰＵライセンスの管理を行なう。ライセンス制御部４６は、サーバ判定部４７とライセンス設定部４８とをそなえる。
サーバ判定部４７は、ＸＳＣＦ２５の不図示の内部情報を参照して、自サーバ２がクラスタシステム用サーバか、非クラスタシステム用サーバかを判定する。又、サーバ判定部４７は、自サーバ２がクラスタシステム用サーバである場合には、運用系サーバか待機系サーバかも判定する。
ライセンス設定部４８は、自サーバ２の電源投入時に、ライセンスＤＢ５２の値に基づいて、ＣＰＵ２２を有効又は無効にする。
ライセンス制御部４６、サーバ判定部４７及びライセンス設定部４８の詳細な処理については図３〜５を用いて後述する。
ＣＰＵ制御部４９は、ＣＰＵ２２の制御を行なう。詳細には、ＣＰＵ制御部４９は、ＳＢ２１の電源投入後に、ＣＰＵ２２のライセンス設定が完了するまでＣＰＵ２２をスタート（起動）させない状態に維持する。
ライセンス制御部４６、サーバ判定部４７及びライセンス設定部４８の詳細な処理については図３〜５を用いて後述する。
ＣＰＵ制御部４９は、ＣＰＵ２２の制御を行なう。詳細には、ＣＰＵ制御部４９は、ＳＢ２１の電源投入後に、ＣＰＵ２２のライセンス設定が完了するまでＣＰＵ２２をスタート（起動）させない状態に維持する。
サーバ監視部５０は、クラスタシステムを構成している相手サーバ（自サーバ２の場合はサーバ３）の動作を監視する。サーバ監視部５０は、例えばウオッチドッグの機能を用いることで相手サーバ３が正常に動作しているかどうかを確認する。
サーバ間通信部５１は、相手サーバ３との間の通信を行なう。
ライセンスＤＢ５２は、ＣＰＵライセンスを管理するためのデータベースである。ライセンスＤＢ５２は、ライセンス記憶域５３及びライセンス属性テーブル５４をそなえる。
サーバ間通信部５１は、相手サーバ３との間の通信を行なう。
ライセンスＤＢ５２は、ＣＰＵライセンスを管理するためのデータベースである。ライセンスＤＢ５２は、ライセンス記憶域５３及びライセンス属性テーブル５４をそなえる。
ライセンス記憶域５３は、管理者がＣＰＵライセンス発行サーバ６から購入したＣＰＵライセンスに関する情報を格納しているライセンスファイル（図７（ａ），（ｂ）参照）を格納する記憶域である。
ライセンス属性テーブル５４は、情報処理システム１で購入済みのＣＰＵライセンスの状態を管理するための情報を格納しているテーブルである。ライセンス属性テーブル５４については、図８を用いて後述する。
ライセンス属性テーブル５４は、情報処理システム１で購入済みのＣＰＵライセンスの状態を管理するための情報を格納しているテーブルである。ライセンス属性テーブル５４については、図８を用いて後述する。
なお、図１に示すサーバ３のユーザＩ／Ｆ部４１、ライセンス登録部４２、ＳＢ電源制御部４３、ライセンス制御部４６、サーバ判定部４７、ライセンス設定部４８、ＣＰＵ制御部４９、サーバ監視部５０、サーバ間通信部５１、ライセンスＤＢ５２、ライセンス記憶域５３、及びライセンス属性テーブル５４は、サーバ２の対応する構成要素と同様の構成及び機能を有するため、その詳細な説明は省略する。すなわち、これらは、サーバ２のＳＢ２１やＣＰＵ２２に代えて、サーバ３のＳＢ３１やＣＰＵ３２に対して各種処理を実行する。
次に、本実施形態の一例としてのライセンス制御部４６の処理について説明する。
図３は、実施形態の一例としてのサーバ２におけるＣＰＵライセンスの登録手順を示す図である。
図３にはサーバ２のＣＰＵライセンスの登録手順のみを示すが、サーバ３においても同様の手順が実行される。
図３は、実施形態の一例としてのサーバ２におけるＣＰＵライセンスの登録手順を示す図である。
図３にはサーバ２のＣＰＵライセンスの登録手順のみを示すが、サーバ３においても同様の手順が実行される。
ステップＳＡ１において、情報処理システム１の管理者が、情報処理システム１において同時に動作させるＣＰＵの最大個数分のＣＰＵライセンスを、ＣＰＵライセンス発行サーバ６から購入する。このとき、例えば、ＣＰＵライセンス発行サーバ６からＣＰＵライセンスを定義する情報を記録しているライセンスファイルが、購入したＣＰＵライセンスの数分、サーバ２に送信される。
次にステップＳＡ２において、管理者は、購入したＣＰＵライセンスをサーバ２のライセンスＤＢ５２に登録する。その際、管理者は、例えば図２や、図３のステップＳＡ２に示すようなライセンス登録コマンドを、ＸＳＣＦ２５のユーザインタフェース上で実行する。そして、ＸＳＣＦ２５の後述するライセンス登録部４２が、管理者によって実行されたコマンドに基づいて、ＣＰＵライセンスをライセンスＤＢ５２に格納する。
ＣＰＵライセンスが登録されると、ステップＳＡ３において、ＣＰＵ２２が使用可能となる。その際、ＸＳＣＦ２５の後述するライセンス制御部４６は、後述するライセンス記憶域５３内のＣＰＵライセンスファイル及びライセンス属性テーブル５４（図１参照）に応じて、動作可能なＣＰＵ２２の個数を決定し、これを不図示のＯＳに通知する。そして、ＯＳが、サーバ２の電源投入時に、ライセンス制御部４６から通知された個数のＣＰＵ２２を起動させる。
ライセンス制御部４６は、後述するライセンス属性テーブル５４の情報に基づいて、ＣＰＵ２２のうちの少なくとも一部のＣＰＵ２２を動作させる。新たなＣＰＵライセンスが情報処理システム１に登録された後、サーバ２の電源が投入されると、ライセンス制御部４６は、サーバ２の状態（非クラスタシステム用サーバか、或いは、クラスタシステム用サーバの場合は運用系サーバか待機系サーバか）に応じて、ＣＰＵ２にライセンス状態を割り当てる。このライセンス状態の割り当てについては、図１１を用いて後述する。
又、ライセンス制御部４６は、クラスタシステムにおいてサーバの運用系・待機系が切り替えられたとき、すなわち、サーバ２が運用系又は待機系から逆に切り替えられたときに、ライセンス属性テーブル５４の情報に基づいて、ＣＰＵ２２のライセンス状態を変更する。このように、運用系サーバ２のＯＳがハングアップした場合に、運用系サーバ２に適用されていたＣＰＵライセンスを、待機系サーバ３に移す処理をライセンス移管処理と呼ぶ。
図４は、実施形態の一例としての情報処理システム１における運用系サーバ２のＯＳハングアップ時のＣＰＵライセンス移管処理を模式的に示す図である。
ステップＳＢ１において、運用系サーバ２のＯＳがハングアップする。
ステップＳＢ２において、待機系サーバ３のＯＳが運用系サーバ２のＯＳのハングアップを検出する。
ステップＳＢ１において、運用系サーバ２のＯＳがハングアップする。
ステップＳＢ２において、待機系サーバ３のＯＳが運用系サーバ２のＯＳのハングアップを検出する。
ステップＳＢ３において、待機系サーバ３のＯＳが、サーバ３のサーバ間通信部５１を介して、運用系サーバ２のＸＳＣＦ２５に対して、ＯＳを強制停止させるよう指示する。
ステップＳＢ４において、運用系サーバ２のＣＰＵ制御部４９は、ＯＳを強制停止させる。
ステップＳＢ５において、運用系サーバ２のサーバ間通信部５１は、ＯＳの強制停止完了を待機系サーバ３のＯＳに報告する。
ステップＳＢ４において、運用系サーバ２のＣＰＵ制御部４９は、ＯＳを強制停止させる。
ステップＳＢ５において、運用系サーバ２のサーバ間通信部５１は、ＯＳの強制停止完了を待機系サーバ３のＯＳに報告する。
運用系サーバ２のＯＳ停止を確認後、ステップＳＢ６において、待機系サーバ３のライセンス制御部４６は、自サーバ３を運用系サーバに昇格させる。
又、ライセンス制御部４６は、自サーバ２が待機系サーバのときに、運用系サーバが完全に停止した場合、自サーバ２を新たな運用系サーバに昇格させる。その際も、ライセンス制御部４６は、ライセンス属性テーブル５４の情報に基づいて、サーバの状態に応じて、ＣＰＵ２２のライセンス状態を変更する。
又、ライセンス制御部４６は、自サーバ２が待機系サーバのときに、運用系サーバが完全に停止した場合、自サーバ２を新たな運用系サーバに昇格させる。その際も、ライセンス制御部４６は、ライセンス属性テーブル５４の情報に基づいて、サーバの状態に応じて、ＣＰＵ２２のライセンス状態を変更する。
図５〜図６は、実施形態の一例としての情報処理システム１におけるＣＰＵライセンス管理の概念を示す図である。
本実施形態の一例としての情報処理システム１においては、従来のＣＰＵライセンスを拡張した、拡張ＣＰＵライセンスという概念を採用している。
ここで、従来のライセンス（以降、通常ＣＰＵライセンスとも称する）と、拡張ＣＰＵライセンスとの違いについて説明する。
本実施形態の一例としての情報処理システム１においては、従来のＣＰＵライセンスを拡張した、拡張ＣＰＵライセンスという概念を採用している。
ここで、従来のライセンス（以降、通常ＣＰＵライセンスとも称する）と、拡張ＣＰＵライセンスとの違いについて説明する。
通常ＣＰＵライセンスは、ＣＰＵの使用を許可するＣＰＵライセンスがサーバ単位で管理される。このため、システムがクラスタシステムの場合には、運用系サーバ、待機系サーバのそれぞれについてＣＰＵライセンスを購入及び登録する。
一方、拡張ＣＰＵライセンスは、クラスタシステムで用いられ、図５に示すように、ＣＰＵライセンスをクラスタ単位でグルーピングする。
一方、拡張ＣＰＵライセンスは、クラスタシステムで用いられ、図５に示すように、ＣＰＵライセンスをクラスタ単位でグルーピングする。
詳細には、図５に示すように、クラスタシステムの運用系サーバ２で動作させるＣＰＵ個数分のＣＰＵライセンスがグルーピングされ、そのライセンスデータがライセンスＤＢ５２のライセンス記憶域５３にそれぞれに登録される。図６の例では、４１番ライセンス〜ｍ番ライセンスのｎ個のライセンスデータ（ライセンスファイル）が、運用系サーバ２と待機系サーバ３との両方のライセンスＤＢ５２に登録される。
しかし、実際に有効化されるのは、運用系サーバ２の一部のＣＰＵ２２のみであり、運用系サーバ２の残りのＣＰＵ２２や待機系サーバ３のＣＰＵ３２は無効のままとなる。
例えば、４１番のライセンスデータは、両サーバ２，３のライセンスＤＢ５２に登録されるが、当該ＣＰＵライセンスが有効化されるのは、運用系サーバ２のみである。このように、拡張ＣＰＵライセンスを使用する場合であっても、有効化されるＣＰＵの個数が、管理者が購入したＣＰＵライセンスの個数に制限され、ＣＰＵライセンス違反が生じることはない。
例えば、４１番のライセンスデータは、両サーバ２，３のライセンスＤＢ５２に登録されるが、当該ＣＰＵライセンスが有効化されるのは、運用系サーバ２のみである。このように、拡張ＣＰＵライセンスを使用する場合であっても、有効化されるＣＰＵの個数が、管理者が購入したＣＰＵライセンスの個数に制限され、ＣＰＵライセンス違反が生じることはない。
なお、図５〜図６には、拡張ライセンスのみを用いる例を示したが、クラスタ型の情報処理システム１で通常ライセンスも併用してもよい。この場合、通常ライセンスは、サーバ単位で管理され、ライセンスＤＢ５２に登録される。
図７に、本情報処理システムにおける通常ＣＰＵライセンスファイルと拡張ＣＰＵライセンスファイルとを例示する。図７（ａ）は通常ＣＰＵライセンスを、図７（ｂ）は拡張ＣＰＵライセンスをそれぞれ示す。
図７に、本情報処理システムにおける通常ＣＰＵライセンスファイルと拡張ＣＰＵライセンスファイルとを例示する。図７（ａ）は通常ＣＰＵライセンスを、図７（ｂ）は拡張ＣＰＵライセンスをそれぞれ示す。
図７（ａ）の例の通常ＣＰＵライセンスでは、テキストデータのヘッダの２行目の「ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ：」の後の値が、ＣＰＵライセンスを一意に識別するシーケンス番号を示す。
図７（ｂ）に示す拡張ＣＰＵライセンスは、図７（ａ）の通常ＣＰＵライセンスと同様の情報に加えて、「ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ」の行の末尾に、拡張ＣＰＵライセンスであることを示す“Ｅｘｔｅｎｄｅｄ”との文字列を有する。
図７（ｂ）に示す拡張ＣＰＵライセンスは、図７（ａ）の通常ＣＰＵライセンスと同様の情報に加えて、「ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ」の行の末尾に、拡張ＣＰＵライセンスであることを示す“Ｅｘｔｅｎｄｅｄ”との文字列を有する。
以降、簡潔を期するために、通常ＣＰＵライセンスを通常ライセンス、拡張ＣＰＵライセンスを拡張ライセンスともそれぞれ呼ぶ。
図８は、実施形態の一例としてのライセンス属性テーブル５４を示す図である。
ライセンス属性テーブル５４には、登録済みのＣＰＵライセンス毎に、ライセンス登録部４２によって１つのエントリ（行）が登録される。
図８は、実施形態の一例としてのライセンス属性テーブル５４を示す図である。
ライセンス属性テーブル５４には、登録済みのＣＰＵライセンス毎に、ライセンス登録部４２によって１つのエントリ（行）が登録される。
ライセンス属性テーブル５４は、種類（Ｃａｔｅｇｏｒｙ）５４１、ＩＤ５４２、サーバシステム型（Ｆｏｒｍ）５４３、サーバ状態（Ｓｅｒｖｅｒ）５４４、及び使用許可状態（Ｐｅｒｍｉｔ）５４５を、相互に関連付けて有する。
種類５４１は、ＣＰＵライセンスが、通常ライセンスであるか拡張ライセンスであるかどうかを示す値を記憶する。例えば、ＣＰＵライセンスが通常ライセンスの場合は値“Ｎｏｒｍａｌ”（＝‘ｘ００’）が、拡張ライセンスの場合は値“Ｅｘｔｅｎｄｅｄ”（＝‘ｘ０１’）が、それぞれ種類５４１に記憶される。
種類５４１は、ＣＰＵライセンスが、通常ライセンスであるか拡張ライセンスであるかどうかを示す値を記憶する。例えば、ＣＰＵライセンスが通常ライセンスの場合は値“Ｎｏｒｍａｌ”（＝‘ｘ００’）が、拡張ライセンスの場合は値“Ｅｘｔｅｎｄｅｄ”（＝‘ｘ０１’）が、それぞれ種類５４１に記憶される。
ＩＤフィールド５４２は、ＣＰＵライセンスを一意に特定する識別子を記憶する。例えば、ＩＤフィールド５４２には、ＣＰＵライセンスファイルのシーケンス番号が設定される。例えば、図７（ａ）のＣＰＵライセンスファイル例の場合はシーケンス番号１１６、図７の（ｂ）の例の場合はシーケンス番号４０にそれぞれ相当する値が、ＩＤフィールド５４２に記憶される。
サーバシステム型５４３は、情報処理システム１がクラスタシステムであるか非クラスタシステムであるかを示す値を記憶する。例えば、情報処理システム１がクラスタシステムの場合は値“Ｃｌｕｓｔｅｒ”（＝‘ｘ０１’）が、非クラスタシステムの場合は値“Ｎｏｎ−Ｃｌｕｓｔｅｒ”（＝‘ｘ００’）が、それぞれサーバシステム型５４３に記憶される。
サーバ状態５４４は、ＣＰＵライセンスが適用されているサーバ２，３が運用系であるか待機系であるかを示す値を記憶する。例えば、ＣＰＵライセンスが適用されているサーバが運用系の場合は値“Ｍａｓｔｅｒ”（＝‘ｘ０１’）が、待機系の場合は値“Ｓｌａｖｅ”（＝‘ｘ０２’）が、それぞれサーバ状態５４４に記憶される。又、図８の３行目のエントリのように、ＣＰＵライセンスが拡張ライセンスであるが、サーバ２，３が非クラスタ用サーバの場合は、サーバ状態５４４の値がゼロクリアされる（‘ｘ００’が設定される）。
使用許可状態５４５は、ＣＰＵライセンスが適用されているＣＰＵ２２，３２の使用許可状態を示す値を記憶しており、この値はライセンス設定部４８によって設定される。例えば、ＣＰＵライセンスが適用されているＣＰＵ２２，３２の使用が許可されている場合は値“Ａｃｔｉｖｅ”（＝‘ｘ０１’）が、使用が許可されていない場合は値“Ｎｏｎ−Ａｃｔｉｖｅ”（＝‘ｘ００’）がそれぞれ設定される。或いは、後述する強制ライセンス移管処理により強制的に使用を許可した場合は値“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”（＝‘ｘ０２’）が、それぞれ使用許可状態５４５に設定される。なお、ライセンス制御部４６は、使用許可状態５４５の値を、情報処理システム１の種類及びサーバ２，３の種類に応じて設定する。例えば、サーバ２又は３が運用系サーバである場合、使用許可状態５４５に値“Ａｃｔｉｖｅ”が設定される。一方、情報処理システム１が非クラスタ型であるか又はサーバ２，３が待機系の場合、使用許可状態５４５に値“Ｎｏｎ−Ａｃｔｉｖｅ”が設定される。
なお、通常ライセンスの状態もライセンス属性テーブル５４によって管理される。通常ライセンスの場合、種類５４１に値“Ｎｏｒｍａｌ”が設定され、電源投入時には使用許可状態５４５に値“Ａｃｔｉｖｅ”が設定される。
なお、ライセンス属性テーブル５４は、実際には図８に示すようなテーブル形式で文字列が格納されるのではなく、種類５４１、ＩＤ５４２、サーバシステム型５４３、サーバ状態５４４、及び使用許可状態５４５を表す、‘ｘ００’、‘ｘ０１’、‘ｘ０２’などの１６進値を、左から順に連結したビット列が使用される。例えば、図８の例では、種類５４１には、値“Ｅｘｔｅｎｄｅｄ”ではなく、１６進値‘ｘ０１’が格納される。なお、図面においては、文字列値の後に、対応する１６進値を、丸括弧で囲んで併記している。
なお、ライセンス属性テーブル５４は、実際には図８に示すようなテーブル形式で文字列が格納されるのではなく、種類５４１、ＩＤ５４２、サーバシステム型５４３、サーバ状態５４４、及び使用許可状態５４５を表す、‘ｘ００’、‘ｘ０１’、‘ｘ０２’などの１６進値を、左から順に連結したビット列が使用される。例えば、図８の例では、種類５４１には、値“Ｅｘｔｅｎｄｅｄ”ではなく、１６進値‘ｘ０１’が格納される。なお、図面においては、文字列値の後に、対応する１６進値を、丸括弧で囲んで併記している。
図９に、システム型及びＣＰＵライセンスの種類毎に、電源投入時及び電源切断時に設定される使用許可状態５４５の値を示す。又、図９の最終行には、電源投入時に、ライセンス属性テーブル５４に設定される値の例を示す。
例えば、図９の左端のケースでは、電源投入時にライセンス属性テーブル５４に、
ライセンス種類：“Ｎｏｒｍａｌ”（‘ｘ００’）＋ＩＤ値＋サーバシステム型：“Ｎｏｎ−Ｃｌｕｓｔｅｒ”（‘ｘ００’）＋サーバ状態：“Ｎｏｎ−Ｃｌｕｓｔｅｒ”（‘ｘ００’）＋使用許可状態：“Ａｃｔｉｖｅ”（‘ｘ０１’）＝
“００ＩＤ０００００１”（ＩＤには、ＩＤ値が１６進数表記で入る）
の値が設定される。
（Ｂ）動作
以下、図１０〜図２３を参照して、本情報処理システム１の動作について説明する。
例えば、図９の左端のケースでは、電源投入時にライセンス属性テーブル５４に、
ライセンス種類：“Ｎｏｒｍａｌ”（‘ｘ００’）＋ＩＤ値＋サーバシステム型：“Ｎｏｎ−Ｃｌｕｓｔｅｒ”（‘ｘ００’）＋サーバ状態：“Ｎｏｎ−Ｃｌｕｓｔｅｒ”（‘ｘ００’）＋使用許可状態：“Ａｃｔｉｖｅ”（‘ｘ０１’）＝
“００ＩＤ０００００１”（ＩＤには、ＩＤ値が１６進数表記で入る）
の値が設定される。
（Ｂ）動作
以下、図１０〜図２３を参照して、本情報処理システム１の動作について説明する。
最初に、図１０〜図１３を用いて各サーバ２，３で実行される処理を説明し、その後、図１４〜図２３を用いて、情報処理システム１全体としての処理を説明する。
図１０は、実施形態の一例としてのサーバ２，３におけるライセンス登録処理を示すフローチャートである。
この処理は、サーバ２，３が運用系、待機系いずれの場合も実行される。
図１０は、実施形態の一例としてのサーバ２，３におけるライセンス登録処理を示すフローチャートである。
この処理は、サーバ２，３が運用系、待機系いずれの場合も実行される。
ステップＳ１において、情報処理システム１の管理者が、情報処理システム１において同時に動作させるＣＰＵの最大個数分のＣＰＵライセンスを、ＣＰＵライセンス発行サーバ６から購入する。そして、図３に示したようなコマンドを実行して、購入したＣＰＵライセンスをサーバ２，３のライセンスＤＢ５２に登録する。
ステップＳ２において、ライセンス登録部４２が、管理者がステップＳ１で登録したＣＰＵライセンスが正当なＣＰＵライセンスであるかと、ライセンスの種類（通常ライセンス又は拡張ライセンス）とを確認する。その際、ライセンスファイルのヘッダデータに文字列“Ｅｘｔｅｎｄｅｄ”が存在する場合（図７（ｂ）参照）、ライセンス登録部４２は、ＣＰＵライセンスが拡張ライセンスであると判断する。一方、ライセンスファイルのヘッダデータに文字列“Ｅｘｔｅｎｄｅｄ”がない場合（図７（ａ）参照）、ライセンス登録部４２は、ＣＰＵライセンスが通常ライセンスであると判断する。
ステップＳ２において、ライセンス登録部４２が、管理者がステップＳ１で登録したＣＰＵライセンスが正当なＣＰＵライセンスであるかと、ライセンスの種類（通常ライセンス又は拡張ライセンス）とを確認する。その際、ライセンスファイルのヘッダデータに文字列“Ｅｘｔｅｎｄｅｄ”が存在する場合（図７（ｂ）参照）、ライセンス登録部４２は、ＣＰＵライセンスが拡張ライセンスであると判断する。一方、ライセンスファイルのヘッダデータに文字列“Ｅｘｔｅｎｄｅｄ”がない場合（図７（ａ）参照）、ライセンス登録部４２は、ＣＰＵライセンスが通常ライセンスであると判断する。
ステップＳ２でＣＰＵライセンスが正当ではない場合（既に登録済みの場合など）、ステップＳ６において、ライセンス登録部４２は管理者に登録エラーを通知し、本処理を終了する。
一方、ＣＰＵライセンスが正当である場合、ステップＳ３において、ライセンス登録部４２は、ＣＰＵライセンスを適用するサーバ２又は３がクラスタシステム用サーバであるかどうかを確認する。その際、ライセンス登録部４２は、ＸＳＣＦ２５，３５の内部情報に基づいて、サーバ２又は３がクラスタシステム用サーバか、非クラスタシステム用サーバかを判定する。
一方、ＣＰＵライセンスが正当である場合、ステップＳ３において、ライセンス登録部４２は、ＣＰＵライセンスを適用するサーバ２又は３がクラスタシステム用サーバであるかどうかを確認する。その際、ライセンス登録部４２は、ＸＳＣＦ２５，３５の内部情報に基づいて、サーバ２又は３がクラスタシステム用サーバか、非クラスタシステム用サーバかを判定する。
ステップＳ４において、ライセンス登録部４２は、ライセンスファイルをライセンスＤＢ５２のライセンス記憶域５３に格納する。
次にステップＳ５において、ライセンス登録部４２は、ライセンスファイルからライセンスＩＤを取得して、登録したＣＰＵライセンスに対する新規エントリをライセンス属性テーブル５４に作成する。その際、ライセンス登録部４２は、ステップＳ２で確認したライセンスの種類、ライセンスＩＤ、及びステップＳ３で確認したサーバシステム型に対応する値を、新規エントリの種類５４１、ＩＤフィールド５４２及びサーバシステム型５４３にそれぞれ記憶する。
次にステップＳ５において、ライセンス登録部４２は、ライセンスファイルからライセンスＩＤを取得して、登録したＣＰＵライセンスに対する新規エントリをライセンス属性テーブル５４に作成する。その際、ライセンス登録部４２は、ステップＳ２で確認したライセンスの種類、ライセンスＩＤ、及びステップＳ３で確認したサーバシステム型に対応する値を、新規エントリの種類５４１、ＩＤフィールド５４２及びサーバシステム型５４３にそれぞれ記憶する。
なお、複数のＣＰＵライセンスを登録する場合、図１０の処理が、登録するＣＰＵライセンス数分繰り返される。
次に、図１０のライセンス登録処理が終了した後にサーバ２，３で実行される電源投入処理について説明する。
図１１は、実施形態の一例としてのサーバ２，３における電源投入処理を示すフローチャートである。
次に、図１０のライセンス登録処理が終了した後にサーバ２，３で実行される電源投入処理について説明する。
図１１は、実施形態の一例としてのサーバ２，３における電源投入処理を示すフローチャートである。
この処理も、サーバ２，３が運用系、待機系いずれの場合も実行される。
ステップＳ１１において、サーバ２又は３のＳＢ２１，３１に対する電源投入要求が行なわれる。電源投入要求は、管理者が、サーバ２又は３のＸＳＣＦ２５，３５に対してコマンド（例えば、ｐｏｗｅｒｏｎ ＰＰＡＲ ０）を実行することにより行なわれる。
ステップＳ１２において、ＳＢ電源制御部４３が、ＳＢ２１又は３１に電源を投入し、ハードウェアの初期化を実施させる。ステップＳ１３において、ＣＰＵ制御部４９は、ＣＰＵ２２又は３２をスタートさせずに、停止させた状態に維持する。
ステップＳ１１において、サーバ２又は３のＳＢ２１，３１に対する電源投入要求が行なわれる。電源投入要求は、管理者が、サーバ２又は３のＸＳＣＦ２５，３５に対してコマンド（例えば、ｐｏｗｅｒｏｎ ＰＰＡＲ ０）を実行することにより行なわれる。
ステップＳ１２において、ＳＢ電源制御部４３が、ＳＢ２１又は３１に電源を投入し、ハードウェアの初期化を実施させる。ステップＳ１３において、ＣＰＵ制御部４９は、ＣＰＵ２２又は３２をスタートさせずに、停止させた状態に維持する。
ステップＳ１４において、サーバ判定部４７が、ライセンス属性テーブル５４を参照して、サーバ２又は３が非クラスタシステム用サーバであるか、クラスタシステム用サーバである場合は運用系か待機系かを判定する。なお、ＸＳＣＦ２５，３５の内部情報に基づいてこの判定が行なわれてもよい。
サーバ２又は３がクラスタシステム用の運用系サーバであるか、又は非クラスタ用サーバの場合（ステップＳ１４の「運用系」及び「非クラスタ」ルート参照）、ステップＳ１５において、サーバ判定部４７は、ライセンス属性テーブル５４を参照して、登録済みのライセンスが通常ライセンスか拡張ライセンスかを判定する。
サーバ２又は３がクラスタシステム用の運用系サーバであるか、又は非クラスタ用サーバの場合（ステップＳ１４の「運用系」及び「非クラスタ」ルート参照）、ステップＳ１５において、サーバ判定部４７は、ライセンス属性テーブル５４を参照して、登録済みのライセンスが通常ライセンスか拡張ライセンスかを判定する。
通常ライセンスの場合（ステップＳ１５の「通常」ルート参照）、ステップＳ１６において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリの使用許可状態５４５の値を“Ａｃｔｉｖｅ”に設定する。
一方、拡張ライセンスの場合（ステップＳ１５の「拡張」ルート参照）、ステップＳ１７において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリのサーバ状態５４４の値を“Ｍａｓｔｅｒ”に、使用許可状態５４５の値を“Ａｃｔｉｖｅ”にそれぞれ設定する。
一方、拡張ライセンスの場合（ステップＳ１５の「拡張」ルート参照）、ステップＳ１７において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリのサーバ状態５４４の値を“Ｍａｓｔｅｒ”に、使用許可状態５４５の値を“Ａｃｔｉｖｅ”にそれぞれ設定する。
ステップＳ１４でサーバ２又は３が待機系サーバである場合（ステップＳ１４の「待機系」ルート参照）、ステップＳ１８において、サーバ判定部４７は、ライセンス属性テーブル５４を参照して、登録済みのライセンスが通常ライセンスか拡張ライセンスかを判定する。
通常ライセンスの場合（ステップＳ１８の「通常」ルート参照）、ステップＳ１９において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリの使用許可状態５４５の値を“Ａｃｔｉｖｅ”に設定する。
通常ライセンスの場合（ステップＳ１８の「通常」ルート参照）、ステップＳ１９において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリの使用許可状態５４５の値を“Ａｃｔｉｖｅ”に設定する。
一方、拡張ライセンスの場合（ステップＳ１８の「拡張」ルート参照）、ステップＳ２０において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリのサーバ状態５４４の値を“Ｓｌａｖｅ”に、使用許可状態５４５の値を“Ｎｏｎ−Ａｃｔｉｖｅ”にそれぞれ設定する。
ライセンス設定部４８は、上記のサーバ状態５４４の値の設定を、登録済みの全ライセンスについて行なう。
ライセンス設定部４８は、上記のサーバ状態５４４の値の設定を、登録済みの全ライセンスについて行なう。
次にステップＳ２１において、電源切断要求が発行されたかどうかが判定される。
電源切断要求が発行された場合（ステップＳ２１のＹＥＳルート参照）、本処理を終了する。
一方、電源切断要求が発行されていない場合（ステップＳ２１のＮＯルート参照）、ステップＳ２２において、ライセンス設定部４８が、ライセンス属性テーブル５４の当該ライセンスのエントリの使用許可状態５４５の値が“Ａｃｔｉｖｅ”又は“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”であるかどうかを判定する。
電源切断要求が発行された場合（ステップＳ２１のＹＥＳルート参照）、本処理を終了する。
一方、電源切断要求が発行されていない場合（ステップＳ２１のＮＯルート参照）、ステップＳ２２において、ライセンス設定部４８が、ライセンス属性テーブル５４の当該ライセンスのエントリの使用許可状態５４５の値が“Ａｃｔｉｖｅ”又は“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”であるかどうかを判定する。
使用許可状態５４５の値が“Ｎｏｎ−Ａｃｔｉｖｅ”の場合（ステップＳ２２のＮＯルート参照）、所定時間待機した後に、処理がステップＳ２１に戻る。
一方、使用許可状態５４５の値が“Ａｃｔｉｖｅ”又は“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”である場合（ステップＳ２２のＹＥＳルート参照）、ステップＳ２３において、ＣＰＵ制御部４９がＣＰＵ２２又は３２をスタートさせる。その際、ＣＰＵ制御部４９は、ライセンス属性テーブル５４の使用許可状態５４５に“Ａｃｔｉｖｅ”又は“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”が設定されているエントリ数分の個数のＣＰＵ２２，３２をスタートさせる。スタートさせる候補のＣＰＵ２２，３２が複数存在する場合、ＣＰＵ制御部４９は、任意の選択方式を使用してスタートさせるＣＰＵ２２，３２を決定する。
一方、使用許可状態５４５の値が“Ａｃｔｉｖｅ”又は“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”である場合（ステップＳ２２のＹＥＳルート参照）、ステップＳ２３において、ＣＰＵ制御部４９がＣＰＵ２２又は３２をスタートさせる。その際、ＣＰＵ制御部４９は、ライセンス属性テーブル５４の使用許可状態５４５に“Ａｃｔｉｖｅ”又は“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”が設定されているエントリ数分の個数のＣＰＵ２２，３２をスタートさせる。スタートさせる候補のＣＰＵ２２，３２が複数存在する場合、ＣＰＵ制御部４９は、任意の選択方式を使用してスタートさせるＣＰＵ２２，３２を決定する。
その後、ステップＳ２４において、サーバ２又は３のＯＳが起動され、本処理を終了する。
図１２は、実施形態の一例としてのサーバ２，３における電源切断処理を示すフローチャートである。
この処理も、サーバ２，３が運用系、待機系いずれの場合も実行される。
図１２は、実施形態の一例としてのサーバ２，３における電源切断処理を示すフローチャートである。
この処理も、サーバ２，３が運用系、待機系いずれの場合も実行される。
ステップＳ３１において、サーバ２又は３のＳＢ２１，３１に対する電源切断要求が発行される。電源切断要求は、管理者、又は図１８で後述するように待機系サーバ３により発行される。
ステップＳ３２において、ＳＢ電源制御部４３がＣＰＵ制御部４９を呼び出す。
ステップＳ３３において、サーバ判定部４７は、ライセンス属性テーブル５４を参照して、サーバ２又は３が非クラスタシステム用サーバであるか、クラスタシステム用サーバである場合は運用系か待機系かを判定する。なお、ＸＳＣＦ２５，３５の内部情報に基づいてこの判定が行なわれてもよい。
ステップＳ３２において、ＳＢ電源制御部４３がＣＰＵ制御部４９を呼び出す。
ステップＳ３３において、サーバ判定部４７は、ライセンス属性テーブル５４を参照して、サーバ２又は３が非クラスタシステム用サーバであるか、クラスタシステム用サーバである場合は運用系か待機系かを判定する。なお、ＸＳＣＦ２５，３５の内部情報に基づいてこの判定が行なわれてもよい。
サーバ２又は３がクラスタシステム用の運用系サーバであるか、又は非クラスタ用サーバの場合（ステップＳ３３の「運用系」及び「非クラスタ」ルート参照）、ステップＳ３４において、サーバ判定部４７は、ライセンス属性テーブル５４を参照して、登録済みのライセンスが通常ライセンスか拡張ライセンスかを判定する。
通常ライセンスの場合（ステップＳ３４の「通常」ルート参照）、ステップＳ３５において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリの使用許可状態５４５の値を“Ｎｏｎ−Ａｃｔｉｖｅ”に設定する。
通常ライセンスの場合（ステップＳ３４の「通常」ルート参照）、ステップＳ３５において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリの使用許可状態５４５の値を“Ｎｏｎ−Ａｃｔｉｖｅ”に設定する。
一方、拡張ライセンスの場合（ステップＳ３４の「拡張」ルート参照）、ステップＳ３６において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリのサーバ状態５４４の値をゼロクリアすると共に、使用許可状態５４５の値を“Ｎｏｎ−Ａｃｔｉｖｅ”に設定する。
ステップＳ３３でサーバ２又は３が待機系サーバである場合（ステップＳ３３の「待機系」ルート参照）、ステップＳ３７において、サーバ判定部４７は、ライセンス属性テーブル５４を参照して、登録済みのライセンスが通常ライセンスか拡張ライセンスかを判定する。
ステップＳ３３でサーバ２又は３が待機系サーバである場合（ステップＳ３３の「待機系」ルート参照）、ステップＳ３７において、サーバ判定部４７は、ライセンス属性テーブル５４を参照して、登録済みのライセンスが通常ライセンスか拡張ライセンスかを判定する。
通常ライセンスの場合（ステップＳ３７の「通常」ルート参照）、ステップＳ３８において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリの使用許可状態５４５の値を“Ｎｏｎ−Ａｃｔｉｖｅ”に設定する。
一方、拡張ライセンスの場合（ステップＳ３７の「拡張」ルート参照）、ステップＳ３９において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリのサーバ状態５４４の値をゼロクリアすると共に、使用許可状態５４５の値を“Ｎｏｎ−Ａｃｔｉｖｅ”に設定する。
一方、拡張ライセンスの場合（ステップＳ３７の「拡張」ルート参照）、ステップＳ３９において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリのサーバ状態５４４の値をゼロクリアすると共に、使用許可状態５４５の値を“Ｎｏｎ−Ａｃｔｉｖｅ”に設定する。
ライセンス設定部４８は、上記のサーバ状態５４４の値の設定を、登録済みの全ライセンスについて行なう。
次にステップＳ４０において、ＣＰＵ制御部４９がＣＰＵ２２又は３２をストップさせる。
その後、ステップＳ４１において、サーバ２又は３のＯＳが停止されて、ＳＢ２１又は３１の電源が切断され、本処理を終了する。
次にステップＳ４０において、ＣＰＵ制御部４９がＣＰＵ２２又は３２をストップさせる。
その後、ステップＳ４１において、サーバ２又は３のＯＳが停止されて、ＳＢ２１又は３１の電源が切断され、本処理を終了する。
図１３は、実施形態の一例としてのサーバ３における電源強制切断処理を示すフローチャートである。
電源強制切断処理は、運用系サーバ２で何らかの異常が発生したことによりサーバ２のＯＳがハングアップし、運用系サーバ２が完全に動作を停止して応答しなくなった場合に、待機系サーバ３のＸＳＣＦ３５により実行される。
電源強制切断処理は、運用系サーバ２で何らかの異常が発生したことによりサーバ２のＯＳがハングアップし、運用系サーバ２が完全に動作を停止して応答しなくなった場合に、待機系サーバ３のＸＳＣＦ３５により実行される。
ステップＳ５１において、待機系サーバ３のＯＳが、運用系サーバ２のＯＳが完全に動作を停止したことを検出し、運用系サーバ２の完全強制停止を実施するよう、サーバ間通信部５１に指示する。
ステップＳ５２において、運用系サーバ２のサーバ間通信部５１は、ネットワーク５経由で運用系サーバ２の不図示の入力電源（ＡＣ電源）を強制的に切断する。
ステップＳ５２において、運用系サーバ２のサーバ間通信部５１は、ネットワーク５経由で運用系サーバ２の不図示の入力電源（ＡＣ電源）を強制的に切断する。
ステップＳ５３において、待機系サーバ３のサーバ監視部５０が、運用系サーバ２が完全に停止したかどうかを判定する。
運用系サーバ２が完全には停止していない場合（ステップＳ５３のＮＯルート参照）、所定時間待機した後に、処理がステップＳ５３に戻る。
運用系サーバ２が完全に停止した場合（ステップＳ５３のＹＥＳルート参照）、ステップＳ５４において、待機系サーバ３のライセンス設定部４８が、自サーバ３を運用系に昇格させるように設定する。詳細には、ライセンス設定部４８は、待機系であり、かつ、該当ＩＤのライセンス属性テーブル５４の種類５４１が“Ｅｘｔｅｎｄｅｄ”であるサーバ３２の、ライセンス属性テーブル５４の使用許可状態５４５の値を“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”に切り替え、本処理を終了する。
運用系サーバ２が完全には停止していない場合（ステップＳ５３のＮＯルート参照）、所定時間待機した後に、処理がステップＳ５３に戻る。
運用系サーバ２が完全に停止した場合（ステップＳ５３のＹＥＳルート参照）、ステップＳ５４において、待機系サーバ３のライセンス設定部４８が、自サーバ３を運用系に昇格させるように設定する。詳細には、ライセンス設定部４８は、待機系であり、かつ、該当ＩＤのライセンス属性テーブル５４の種類５４１が“Ｅｘｔｅｎｄｅｄ”であるサーバ３２の、ライセンス属性テーブル５４の使用許可状態５４５の値を“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”に切り替え、本処理を終了する。
これまで、サーバ２，３で個別に実行される処理を説明してきたが、以降、様々な場面を取り上げて、本情報処理システム１全体の動作を説明する。
（Ｃ）ケース１
最初に、情報処理システム１において拡張ライセンスを登録する際の情報処理システム１全体の処理について説明する。
（Ｃ）ケース１
最初に、情報処理システム１において拡張ライセンスを登録する際の情報処理システム１全体の処理について説明する。
このとき、両サーバ２，３のライセンス登録部４２により、運用系サーバ２のＣＰＵライセンスを有効化すると共に、待機系サーバ３のＣＰＵライセンスを無効化するよう、ライセンス属性テーブル５４に値が設定される。
ライセンス属性テーブル５４に値が設定されたのち、電源投入指示が行なわれた際に、ＣＰＵ制御部４９は、ライセンス属性テーブル５４を参照して、ＣＰＵライセンスが有効に設定されているＣＰＵ２２，３２のみを動作させる。
ライセンス属性テーブル５４に値が設定されたのち、電源投入指示が行なわれた際に、ＣＰＵ制御部４９は、ライセンス属性テーブル５４を参照して、ＣＰＵライセンスが有効に設定されているＣＰＵ２２，３２のみを動作させる。
拡張ライセンスを登録する際の処理を、図１４〜図１８を用いて説明する。
ライセンス属性テーブル５４に図１４に例示する値が設定されている場合の拡張ライセンスを登録する際の処理を、図１５のフローチャートに示す。
なお、図１５には、運用系サーバ２でのみステップＳ１０１〜Ｓ１０８が実行されているように図示されているが、実際には、待機系サーバ３においてもステップＳ１０１〜Ｓ１０８と同様の処理が実行される。
ライセンス属性テーブル５４に図１４に例示する値が設定されている場合の拡張ライセンスを登録する際の処理を、図１５のフローチャートに示す。
なお、図１５には、運用系サーバ２でのみステップＳ１０１〜Ｓ１０８が実行されているように図示されているが、実際には、待機系サーバ３においてもステップＳ１０１〜Ｓ１０８と同様の処理が実行される。
ステップＳ１０１において、情報処理システム１の管理者が、情報処理システム１において同時に動作させるＣＰＵの最大個数分のＣＰＵライセンスを、ＣＰＵライセンス発行サーバ６から購入する。
ステップＳ１０２において、管理者は、購入した拡張ライセンスをクラスタシステム専用のライセンスとして登録するためのＸＳＣＦコマンドを、運用系サーバ２，３のＸＳＣＦ２５，３５で実行する。例えば、管理者は、ａｄｄｃｏｄａｃｔｉｖａｔｉｏｎ Ｃｌｕｓｔｅｒ “ライセンステキスト”を実行する。
ステップＳ１０２において、管理者は、購入した拡張ライセンスをクラスタシステム専用のライセンスとして登録するためのＸＳＣＦコマンドを、運用系サーバ２，３のＸＳＣＦ２５，３５で実行する。例えば、管理者は、ａｄｄｃｏｄａｃｔｉｖａｔｉｏｎ Ｃｌｕｓｔｅｒ “ライセンステキスト”を実行する。
ステップＳ１０３において、ライセンス登録部４２が、管理者がステップＳ１０２で登録したＣＰＵライセンスの種類（通常ライセンス又は拡張ライセンス）を確認する。その際、ライセンスファイルのヘッダデータに文字列“Ｅｘｔｅｎｄｅｄ”が存在する場合（図７（ｂ）参照）、ライセンス登録部４２は、ＣＰＵライセンスが拡張ライセンスであると判断する。一方、ライセンスファイルのヘッダデータに文字列“Ｅｘｔｅｎｄｅｄ”がない場合（図７（ａ）参照）、ライセンス登録部４２は、ＣＰＵライセンスが通常ライセンスであると判断する。
ステップＳ１０４において、ライセンス登録部４２は、ＣＰＵライセンスを適用するサーバ２，３がクラスタシステム用サーバであるかどうかを確認する。その際、ライセンス登録部４２は、ＸＳＣＦ２５の内部情報に基づいて、サーバ２，３がクラスタシステム用サーバか、非クラスタシステム用サーバかを判定する。
ステップＳ１０５において、ライセンス登録部４２は、ライセンスファイルをライセンスＤＢ５２のライセンス記憶域５３に格納する。
ステップＳ１０５において、ライセンス登録部４２は、ライセンスファイルをライセンスＤＢ５２のライセンス記憶域５３に格納する。
次にステップＳ１０６において、ライセンス登録部４２は、ライセンスファイルからライセンスＩＤを取得して、登録したＣＰＵライセンスに対する新規エントリをライセンス属性テーブル５４に作成する。その際、ライセンス登録部４２は、ステップＳ１０３で確認したライセンスの種類、ライセンスＩＤ、及びステップＳ１０４で確認したサーバシステム型に対応する値を、新規エントリの種類５４１、ＩＤフィールド５４２及びサーバシステム型５４３にそれぞれ記憶する。
ステップＳ１０７において、サーバ２，３のＳＢ２１，３１に対する電源投入要求が行なわれる。電源投入要求は、管理者が、サーバ２，３のＸＳＣＦ２５，３５に対してコマンド（例えば、ｐｏｗｅｒｏｎ ＰＰＡＲ ０）を実行することにより行なわれる。
ステップＳ１０８において、ＳＢ電源制御部４３が、ＳＢ２１又は３１に電源を投入し、ハードウェアの初期化を実施させる。このとき、ＣＰＵ制御部４９は、ＣＰＵ２２又は３２をスタートさせずに、停止させた状態に維持する。
ステップＳ１０８において、ＳＢ電源制御部４３が、ＳＢ２１又は３１に電源を投入し、ハードウェアの初期化を実施させる。このとき、ＣＰＵ制御部４９は、ＣＰＵ２２又は３２をスタートさせずに、停止させた状態に維持する。
ステップＳ１０９において、サーバ判定部４７が、ライセンス属性テーブル５４を参照して、サーバ２又は３が非クラスタシステムのサーバ或いはクラスタシステム用の運用系サーバかどうかを判定する。
サーバ２又は３が非クラスタシステムのサーバ或いはクラスタシステム用の運用系サーバである場合（ステップＳ１０９のＹＥＳルート参照）、ステップＳ１１０において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリのサーバ状態５４４の値を“Ｍａｓｔｅｒ”に、使用許可状態５４５の値を“Ａｃｔｉｖｅ”にそれぞれ設定する。このように変更されたライセンス属性テーブル５４のエントリの例を、図１６に示す。
サーバ２又は３が非クラスタシステムのサーバ或いはクラスタシステム用の運用系サーバである場合（ステップＳ１０９のＹＥＳルート参照）、ステップＳ１１０において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリのサーバ状態５４４の値を“Ｍａｓｔｅｒ”に、使用許可状態５４５の値を“Ａｃｔｉｖｅ”にそれぞれ設定する。このように変更されたライセンス属性テーブル５４のエントリの例を、図１６に示す。
一方、サーバ２又は３がクラスタシステム用の待機系サーバである場合（ステップＳ１０９のＮＯルート参照）、ステップＳ１１１において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリのサーバ状態５４４の値を“Ｓｌａｖｅ”に、使用許可状態５４５の値を“Ｎｏｎ−Ａｃｔｉｖｅ”にそれぞれ設定する。このように変更されたライセンス属性テーブル５４のエントリの例を、図１７に示す。
ライセンス設定部４８は、上記のサーバ状態５４４の値の設定を、登録済みの全ライセンスについて行なう。
次にステップＳ１１２において、電源切断要求が発行されたかどうかが判定される。
電源切断要求が発行された場合（ステップＳ１１２のＹＥＳルート参照）、本処理を終了する。
次にステップＳ１１２において、電源切断要求が発行されたかどうかが判定される。
電源切断要求が発行された場合（ステップＳ１１２のＹＥＳルート参照）、本処理を終了する。
一方、電源切断要求が発行されていない場合（ステップＳ１１２のＮＯルート参照）、ステップＳ１１３において、ライセンス設定部４８が、ライセンス属性テーブル５４の当該ライセンスのエントリの使用許可状態５４５の値が“Ａｃｔｉｖｅ”又は“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”であるかどうかを判定する。
使用許可状態５４５の値が“Ｎｏｎ−Ａｃｔｉｖｅ”の場合（ステップＳ１１３のＮＯルート参照）、ステップＳ１１４において待機系サーバ３のＣＰＵ３２を停止させた状態に維持したまま、一定期間待機した後に、処理がステップＳ１１２に戻る。
使用許可状態５４５の値が“Ｎｏｎ−Ａｃｔｉｖｅ”の場合（ステップＳ１１３のＮＯルート参照）、ステップＳ１１４において待機系サーバ３のＣＰＵ３２を停止させた状態に維持したまま、一定期間待機した後に、処理がステップＳ１１２に戻る。
一方、使用許可状態５４５の値が“Ａｃｔｉｖｅ”又は“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”である場合（ステップＳ１１３のＹＥＳルート参照）、ステップＳ１１５において、ＣＰＵ制御部４９がＣＰＵ２２をスタートさせる。その際、ＣＰＵ制御部４９は、ライセンス属性テーブル５４の使用許可状態５４５に“Ａｃｔｉｖｅ”又は“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”が設定されているエントリ数分の個数のＣＰＵ２２，３２をスタートさせる。スタートさせる候補のＣＰＵ２２，３２が複数存在する場合、ＣＰＵ制御部４９は、任意の選択方式を使用してスタートさせるＣＰＵ２２，３２を決定する。
その後、ステップＳ１１６において、サーバ２のＳＢ２１でＯＳが起動され、本処理を終了する。
（Ｄ）ケース２
次に、運用系サーバ２で何らかの異常が発生したことによりサーバ２のＯＳがハングアップしたが、運用系サーバ２が応答可能な場合に実行されるライセンス移管処理について、図１８〜図２０を用いて説明する。
（Ｄ）ケース２
次に、運用系サーバ２で何らかの異常が発生したことによりサーバ２のＯＳがハングアップしたが、運用系サーバ２が応答可能な場合に実行されるライセンス移管処理について、図１８〜図２０を用いて説明する。
図１８は、運用系サーバ２の停止時のライセンス移管処理を示すフローチャートであり、図１９は、図１８のライセンス移管処理を模式的に示す図である。
この例では、図１９のステップＳＣ１において、両サーバ２，３に、クラスタ専用のライセンスの登録及びグルーピングが既に行なわれている。
このとき、ステップＳ１２１において、運用系サーバ２で何らかの異常が発生したことによりサーバ２のＯＳがハングアップする（図１９のステップＳＣ２参照）。このとき、待機系サーバ３のＣＰＵ３２はライセンス違反とならないようストップされた状態に留まっている。
この例では、図１９のステップＳＣ１において、両サーバ２，３に、クラスタ専用のライセンスの登録及びグルーピングが既に行なわれている。
このとき、ステップＳ１２１において、運用系サーバ２で何らかの異常が発生したことによりサーバ２のＯＳがハングアップする（図１９のステップＳＣ２参照）。このとき、待機系サーバ３のＣＰＵ３２はライセンス違反とならないようストップされた状態に留まっている。
ステップＳ１２２において、待機系サーバ３のＯＳが、運用系サーバ２のＯＳがハングアップしたことを検出する（図１９のステップＳＣ３参照）。
ステップＳ１２３において、待機系サーバ３のＯＳが、サーバ間通信部５１に対して、運用系サーバ２に対して強制停止を指示するように要求する。
ステップＳ１２４において、待機系サーバ３のサーバ間通信部５１が、ネットワーク５経由で運用系サーバ２に対して強制停止を指示する（図１９のステップＳＣ４参照）。
ステップＳ１２３において、待機系サーバ３のＯＳが、サーバ間通信部５１に対して、運用系サーバ２に対して強制停止を指示するように要求する。
ステップＳ１２４において、待機系サーバ３のサーバ間通信部５１が、ネットワーク５経由で運用系サーバ２に対して強制停止を指示する（図１９のステップＳＣ４参照）。
ステップＳ１２５において、運用系サーバ２のサーバ間通信部５１が、待機系サーバ３から停止指示を受け取る。
ステップＳ１２６において、運用系サーバ２のＳＢ電源制御部４３が、ＳＢ２１で実行されていたＯＳを強制停止させるために、ＳＢ２１の電源を強制的に切断するよう指示を出す（図１９のステップＳＣ５参照）。
ステップＳ１２６において、運用系サーバ２のＳＢ電源制御部４３が、ＳＢ２１で実行されていたＯＳを強制停止させるために、ＳＢ２１の電源を強制的に切断するよう指示を出す（図１９のステップＳＣ５参照）。
ステップＳ１２７において、ＳＢ電源切断指示ののちに、ＳＢ電源制御部４３はＣＰＵ制御部４９を呼び出し、全ＣＰＵ２２を起動ループから抜けさせる。
以降、ライセンス状態の移管処理が実行される。ステップＳ１２８において、サーバ判定部４７は、ライセンス属性テーブル５４を参照して、サーバ２が非クラスタシステムのサーバ或いはクラスタシステム用の運用系サーバかどうかを判定する（図１９のステップＳＣ６参照）。
以降、ライセンス状態の移管処理が実行される。ステップＳ１２８において、サーバ判定部４７は、ライセンス属性テーブル５４を参照して、サーバ２が非クラスタシステムのサーバ或いはクラスタシステム用の運用系サーバかどうかを判定する（図１９のステップＳＣ６参照）。
サーバ２が非クラスタシステムのサーバ或いはクラスタシステム用の運用系サーバである場合（ステップＳ１２８のＹＥＳルート参照）、ステップＳ１２９において、ライセンス設定部４８は、ライセンス属性テーブル５４の当該ライセンスのエントリの使用許可状態５４５の値を“Ｎｏｎ−Ａｃｔｉｖｅ”に設定する（図１９のステップＳＣ６参照）。このように変更されたライセンス属性テーブル５４のエントリの例を、図２０に示す。
一方、サーバ２又は３がクラスタシステム用の待機系サーバである場合（ステップＳ１０９のＮＯルート参照）、ＣＰＵ制御部４９は、使用許可状態５４５の値を“Ｎｏｎ−Ａｃｔｉｖｅ”のまま変更しない。
ライセンス設定部４８は、上記のサーバ状態５４４の値の設定を、登録済みの全ライセンスについて行なう。
ライセンス設定部４８は、上記のサーバ状態５４４の値の設定を、登録済みの全ライセンスについて行なう。
ステップＳ１３０において、運用系サーバ２のＳＢ電源制御部４３が、拡張ライセンス分のＣＰＵ２２をストップさせる。
ステップＳ１３１において、運用系サーバ２のＳＢ電源制御部４３は、ＯＳを強制停止し、ＳＢ２１の電源切断を実施する。
ステップＳ１３２において、運用系サーバ２のＯＳは、サーバ間通信部５１経由で強制停止完了を待機系サーバ３のＯＳに報告する（図１９のステップＳＣ７参照）。
ステップＳ１３１において、運用系サーバ２のＳＢ電源制御部４３は、ＯＳを強制停止し、ＳＢ２１の電源切断を実施する。
ステップＳ１３２において、運用系サーバ２のＯＳは、サーバ間通信部５１経由で強制停止完了を待機系サーバ３のＯＳに報告する（図１９のステップＳＣ７参照）。
次にステップＳ１３３において、待機系サーバ３のサーバ間通信部５１が運用系サーバ２から停止報告を受け取る。そして、ステップＳ１３４において、待機系サーバ３のＯＳは、サーバ間通信部５１から運用系サーバ２の停止報告を受け取り、ステップＳ１３５で自サーバ３を新たな運用系サーバに昇格させる（図１９のステップＳＣ８参照）。
一方、ステップＳ１３６において、運用系サーバ２のＸＳＣＦ２５は、自サーバ２を待機系サーバに降格させる（図１９のステップＳＣ９参照）。
一方、ステップＳ１３６において、運用系サーバ２のＸＳＣＦ２５は、自サーバ２を待機系サーバに降格させる（図１９のステップＳＣ９参照）。
ステップＳ１３７において、両サーバ２，３に対し電源投入が指示される。これ以降、図１５のステップＳ１０７以降の処理が実行される。
ステップＳ１３８において、両サーバ２，３に電源が投入され、新運用系サーバ３及び新待機系サーバ２のライセンス属性テーブル５４の値が参照／変更されてＣＰＵ２２，３２の使用許可状態が更新される。その後、新運用系サーバ３のＣＰＵ制御部４９が、ＣＰＵ３２をスタートする（図１９のステップＳＣ１０参照）。
（Ｅ）ケース３
最後に、運用系サーバ２で何らかの異常が発生したことによりサーバ２のＯＳがハングアップし、運用系サーバ２が完全に動作を停止した場合に実行される強制ライセンス移管処理について、図２１〜図２３を用いて説明する。
ステップＳ１３８において、両サーバ２，３に電源が投入され、新運用系サーバ３及び新待機系サーバ２のライセンス属性テーブル５４の値が参照／変更されてＣＰＵ２２，３２の使用許可状態が更新される。その後、新運用系サーバ３のＣＰＵ制御部４９が、ＣＰＵ３２をスタートする（図１９のステップＳＣ１０参照）。
（Ｅ）ケース３
最後に、運用系サーバ２で何らかの異常が発生したことによりサーバ２のＯＳがハングアップし、運用系サーバ２が完全に動作を停止した場合に実行される強制ライセンス移管処理について、図２１〜図２３を用いて説明する。
図２１は、運用系サーバ２の停止時の強制ライセンス移管処理を示すフローチャートであり、図２２は、図２１の強制ライセンス移管処理を模式的に示す図である。
この例では、図２２のステップＳＤ１において、両サーバ２，３に、クラスタ専用のライセンスの登録及びグルーピングが既に行なわれている。
このとき、ステップＳ１４１において、運用系サーバ２で何らかの異常が発生したことによりサーバ２のＯＳがハングアップする（図２２のステップＳＤ２参照）。このとき、待機系サーバ３のＣＰＵ３２はライセンス違反とならないようストップされた状態に留まっている。
この例では、図２２のステップＳＤ１において、両サーバ２，３に、クラスタ専用のライセンスの登録及びグルーピングが既に行なわれている。
このとき、ステップＳ１４１において、運用系サーバ２で何らかの異常が発生したことによりサーバ２のＯＳがハングアップする（図２２のステップＳＤ２参照）。このとき、待機系サーバ３のＣＰＵ３２はライセンス違反とならないようストップされた状態に留まっている。
ステップＳ１４２において、待機系サーバ３のＯＳが、運用系サーバ２のＯＳがハングアップしたことを検出する（図２２のステップＳＤ３参照）。
ステップＳ１４３において、待機系サーバ３のＯＳが、サーバ間通信部５１に対して、運用系サーバ２に対して強制停止を指示するように要求する。
ステップＳ１４４において、待機系サーバ３のサーバ間通信部５１が、ネットワーク５経由で運用系サーバ２に対して強制停止を指示する（図２２のステップＳＤ４参照）。
ステップＳ１４３において、待機系サーバ３のＯＳが、サーバ間通信部５１に対して、運用系サーバ２に対して強制停止を指示するように要求する。
ステップＳ１４４において、待機系サーバ３のサーバ間通信部５１が、ネットワーク５経由で運用系サーバ２に対して強制停止を指示する（図２２のステップＳＤ４参照）。
しかし、運用系サーバ２は完全に動作を停止しているため、ステップＳ１４４で発行された、待機系サーバ３からの指示に応答することができない。このため、ステップＳ１４５において、運用系サーバ２からの応答がタイムアウトする（図２２のステップＳＤ４参照）。
ステップＳ１４６において、待機系サーバ３のＯＳは、運用系サーバ２が完全な動作停止に陥っていると判断し、運用系サーバ２の完全強制停止を実施するよう、サーバ間通信部５１に指示する（図２２のステップＳＤ４参照）。
ステップＳ１４６において、待機系サーバ３のＯＳは、運用系サーバ２が完全な動作停止に陥っていると判断し、運用系サーバ２の完全強制停止を実施するよう、サーバ間通信部５１に指示する（図２２のステップＳＤ４参照）。
ステップＳ１４７において、サーバ間通信部５１は、ネットワーク５経由で運用系サーバ２の不図示の入力電源（ＡＣ電源）を強制的に切断する。
この結果、ステップＳ１４８において、運用系サーバ２のハードウェアが完全に停止する（図２２のステップＳＤ４参照）。
これ以降、ライセンス強制移管処理が実行される。ステップＳ１４９において、待機系サーバ３のサーバ判定部４７が、運用系サーバ２がクラスタシステム用の運用系サーバであり、かつ運用系サーバ２が完全に停止したかどうかを判定する。
この結果、ステップＳ１４８において、運用系サーバ２のハードウェアが完全に停止する（図２２のステップＳＤ４参照）。
これ以降、ライセンス強制移管処理が実行される。ステップＳ１４９において、待機系サーバ３のサーバ判定部４７が、運用系サーバ２がクラスタシステム用の運用系サーバであり、かつ運用系サーバ２が完全に停止したかどうかを判定する。
運用系サーバ２が完全には停止していない場合（ステップＳ１４９のＮＯルート参照）、所定時間待機した後に、処理がステップＳ１４９に戻る。
運用系サーバ２がクラスタシステム用の運用系サーバであり、かつ運用系サーバ２が完全に停止した場合（ステップＳ１４９のＹＥＳルート参照）、ステップＳ１５０において、待機系サーバ３のライセンス設定部４８が、自サーバ３を運用系に昇格させるように設定する。詳細には、ライセンス設定部４８は、待機系であり、かつ、該当ＩＤのライセンス属性テーブル５４の種類５４１が“Ｅｘｔｅｎｄｅｄ”であるサーバ３２のライセンス属性テーブル５４のサーバ状態５４４の値をクリアする。又、使用許可状態５４５の値を“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”に設定する。このように設定することで、ライセンスが強制的に待機系サーバ３に移管される（これを「自立有効化」と呼ぶ；図２２のステップＳＤ５参照）。このように変更されたライセンス属性テーブル５４のエントリの例を、図２３に示す。
運用系サーバ２がクラスタシステム用の運用系サーバであり、かつ運用系サーバ２が完全に停止した場合（ステップＳ１４９のＹＥＳルート参照）、ステップＳ１５０において、待機系サーバ３のライセンス設定部４８が、自サーバ３を運用系に昇格させるように設定する。詳細には、ライセンス設定部４８は、待機系であり、かつ、該当ＩＤのライセンス属性テーブル５４の種類５４１が“Ｅｘｔｅｎｄｅｄ”であるサーバ３２のライセンス属性テーブル５４のサーバ状態５４４の値をクリアする。又、使用許可状態５４５の値を“Ｆｏｒｃｅ−Ａｃｔｉｖｅ”に設定する。このように設定することで、ライセンスが強制的に待機系サーバ３に移管される（これを「自立有効化」と呼ぶ；図２２のステップＳＤ５参照）。このように変更されたライセンス属性テーブル５４のエントリの例を、図２３に示す。
ライセンス設定部４８は、上記のサーバ状態５４４の値の設定を、登録済みの全ライセンスについて行なう。
ステップＳ１５１において、待機系サーバ３のＯＳは、サーバ間通信部５１から運用系サーバ２の停止報告を受け取り、自サーバ３を運用系サーバに昇格させる（図２２のステップＳＤ６参照）。
ステップＳ１５１において、待機系サーバ３のＯＳは、サーバ間通信部５１から運用系サーバ２の停止報告を受け取り、自サーバ３を運用系サーバに昇格させる（図２２のステップＳＤ６参照）。
これらの処理により、
ステップＳ１５２において、サーバ３に対し電源投入が指示される。これ以降、サーバ３において図１５のステップＳ１０７以降の処理が実行される。
ステップＳ１５３において、サーバ３に電源が投入され、新運用系サーバ３が起動し（強制ライセンス移管後の新運用系サーバ３の起動を「自立起動」とも呼ぶ）、新運用系サーバ３のライセンス属性テーブル５４の値が参照／変更されてＣＰＵ３２の使用許可状態が参照／更新される。その後、新運用系サーバ３のＣＰＵ制御部４９が、ＣＰＵ３２をスタートする。
ステップＳ１５２において、サーバ３に対し電源投入が指示される。これ以降、サーバ３において図１５のステップＳ１０７以降の処理が実行される。
ステップＳ１５３において、サーバ３に電源が投入され、新運用系サーバ３が起動し（強制ライセンス移管後の新運用系サーバ３の起動を「自立起動」とも呼ぶ）、新運用系サーバ３のライセンス属性テーブル５４の値が参照／変更されてＣＰＵ３２の使用許可状態が参照／更新される。その後、新運用系サーバ３のＣＰＵ制御部４９が、ＣＰＵ３２をスタートする。
その後、ステップＳ１５４において旧運用系サーバ２のハードウェアが復活した場合、ステップＳ１５５において、旧運用系サーバ２のＸＳＣＦ２５が、自サーバ２を待機系サーバに降格させる（図２２のステップＳＤ８参照）。
これ以降、サーバ２において図１５のステップＳ１０７以降の処理が実行される。ステップＳ１５６において、新待機系サーバ２に電源が投入される。
これ以降、サーバ２において図１５のステップＳ１０７以降の処理が実行される。ステップＳ１５６において、新待機系サーバ２に電源が投入される。
そして、新待機系サーバ２のライセンス属性テーブル５４の値が変更されてＣＰＵ２２の使用許可状態が更新される。詳細には、ライセンスの使用許可状態５４５の値が、“Ａｃｔｉｖｅ”から“Ｎｏｎ−Ａｃｔｉｖｅ”に更新される（図２２のステップＳＤ９参照）。
（Ｆ）作用・効果
上記の実施形態の一例によれば、ライセンス制御部４６が、サーバ２，３のＣＰＵ２２，３２を停止させた状態で、ライセンス属性テーブル５４に基づいてどのＣＰＵ２２，３２を動作させるのかを判断する。そして、ライセンス制御部４６が動作させると判定したＣＰＵ２２，３２を、ＣＰＵ制御部４７がスタートさせる。つまり、運用系サーバ２のＣＰＵ２２は動作させ、待機系サーバ３のＣＰＵ３２は動作させないよう制御される。
（Ｆ）作用・効果
上記の実施形態の一例によれば、ライセンス制御部４６が、サーバ２，３のＣＰＵ２２，３２を停止させた状態で、ライセンス属性テーブル５４に基づいてどのＣＰＵ２２，３２を動作させるのかを判断する。そして、ライセンス制御部４６が動作させると判定したＣＰＵ２２，３２を、ＣＰＵ制御部４７がスタートさせる。つまり、運用系サーバ２のＣＰＵ２２は動作させ、待機系サーバ３のＣＰＵ３２は動作させないよう制御される。
このように、ライセンス制御部４６とＣＰＵ制御部４７とは、ＣＰＵ２２，３２の動作制御を、運用系サーバ２及び待機系サーバ３のＳＢ２１，３１の電源投入又は電源切断時に行なう。
待機系サーバ３のＣＰＵ３２は動作させないので、運用系サーバ２で動作させるＣＰＵ２２の個数分のＣＰＵライセンスのみがあればよく、待機系サーバ３のＣＰＵ３２のライセンスは必要ない。このため、ＣＰＵライセンスの購入コストをほぼ半分に削減することができる。
待機系サーバ３のＣＰＵ３２は動作させないので、運用系サーバ２で動作させるＣＰＵ２２の個数分のＣＰＵライセンスのみがあればよく、待機系サーバ３のＣＰＵ３２のライセンスは必要ない。このため、ＣＰＵライセンスの購入コストをほぼ半分に削減することができる。
又、ＣＰＵ２２，３２を実際に動作させる前に、各ＣＰＵ２２，３２を動作させるかどうかが設定されるので、ライセンスの違反を防止することができる。
さらに、運用系サーバ２の故障時には、運用系サーバ２のＣＰＵライセンスが自動的に待機系サーバ３に引き継がれる。
このため、煩雑なライセンスの移管作業が不要となり、サーバ切り替えが効率よく実行される。
（Ｇ）その他
なお、上述した実施形態に関わらず、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。
さらに、運用系サーバ２の故障時には、運用系サーバ２のＣＰＵライセンスが自動的に待機系サーバ３に引き継がれる。
このため、煩雑なライセンスの移管作業が不要となり、サーバ切り替えが効率よく実行される。
（Ｇ）その他
なお、上述した実施形態に関わらず、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。
例えば、上記の実施形態の一例においては、サーバ２が運用系サーバ、サーバ３が待機系サーバである例を採り上げたが、サーバ２，３のいずれが運用系、待機系であってもよい。
又、サーバ２にｋ個のＣＰＵ２２が、サーバ３にｋ個のＣＰＵ３２がそれぞれそなえられている例を採り上げたが、サーバ２，３のＣＰＵ２２，３２の個数が異なっていてもよい。
又、サーバ２にｋ個のＣＰＵ２２が、サーバ３にｋ個のＣＰＵ３２がそれぞれそなえられている例を採り上げたが、サーバ２，３のＣＰＵ２２，３２の個数が異なっていてもよい。
上記の実施形態の一例においては、運用系サーバ２の故障時に運用系サーバをサーバ２からサーバ３に切り替える例を採り上げてライセンス移管処理について説明したが、このライセンス移管処理は、運用系サーバ２の保守時にも実施される。
さらに、ライセンス属性テーブル５４に、上記の実施形態の一例で使用した値とは異なる値を設定してもよい。又、ライセンス属性テーブル５４に上記の実施形態の一例とは異なるフォーマットを使用してもよい。
さらに、ライセンス属性テーブル５４に、上記の実施形態の一例で使用した値とは異なる値を設定してもよい。又、ライセンス属性テーブル５４に上記の実施形態の一例とは異なるフォーマットを使用してもよい。
なお、クラスタシステムにおいてＣＰＵ２２，３２の故障や縮退により動作しているＣＰＵ２２，３２が減った場合であっても、上記実施形態の一例の動作は変わらず、使用可能なＣＰＵライセンスを、残っているＣＰＵ２２，３２に対して設定する。
なお、サーバ３のユーザＩ／Ｆ部４１、ライセンス登録部４２、ＳＢ電源制御部４３、ライセンス制御部４６、サーバ判定部４７、ライセンス設定部４８、ＣＰＵ制御部４９、サーバ監視部５０、及びサーバ間通信部５１としての機能を実現するための情報処理装置の制御プログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷ等），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ＋Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋ＲＷ，ＨＤ ＤＶＤ等），ブルーレイディスク，磁気ディスク，光ディスク，光磁気ディスク等の、コンピュータ読取可能な記録媒体に記録された形態で提供される。そして、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置又は外部記憶装置に転送し格納して用いる。又、そのプログラムを、例えば磁気ディスク，光ディスク，光磁気ディスク等の記憶装置（記録媒体）に記録しておき、その記憶装置から通信経路を介してコンピュータに提供するようにしてもよい。
なお、サーバ３のユーザＩ／Ｆ部４１、ライセンス登録部４２、ＳＢ電源制御部４３、ライセンス制御部４６、サーバ判定部４７、ライセンス設定部４８、ＣＰＵ制御部４９、サーバ監視部５０、及びサーバ間通信部５１としての機能を実現するための情報処理装置の制御プログラムは、例えばフレキシブルディスク，ＣＤ（ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＣＤ−ＲＷ等），ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−Ｒ，ＤＶＤ＋Ｒ，ＤＶＤ−ＲＷ，ＤＶＤ＋ＲＷ，ＨＤ ＤＶＤ等），ブルーレイディスク，磁気ディスク，光ディスク，光磁気ディスク等の、コンピュータ読取可能な記録媒体に記録された形態で提供される。そして、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置又は外部記憶装置に転送し格納して用いる。又、そのプログラムを、例えば磁気ディスク，光ディスク，光磁気ディスク等の記憶装置（記録媒体）に記録しておき、その記憶装置から通信経路を介してコンピュータに提供するようにしてもよい。
サーバ３のユーザＩ／Ｆ部４１、ライセンス登録部４２、ＳＢ電源制御部４３、ライセンス制御部４６、サーバ判定部４７、ライセンス設定部４８、ＣＰＵ制御部４９、サーバ監視部５０、及びサーバ間通信部５１としての機能を実現する際には、内部記憶装置（本実施形態ではＸＳＣＦ２５，３５の不図示のメモリやＨＤＤ）に格納された情報処理装置の制御プログラムがコンピュータのマイクロプロセッサ（本実施形態ではＸＳＣＦ２５，３５の不図示のＣＰＵ）によって実行される。このとき、記録媒体に記録されたプログラムをコンピュータが読み取って実行するようにしてもよい。
（Ｈ）付記
以上の実施形態に関し、更に以下の付記を開示する。
（Ｈ）付記
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
情報処理装置であって、
複数の処理部と、
前記複数の処理部のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、前記複数の処理部のいずれを動作させるかを規定するライセンス情報を記憶するライセンス情報記憶部と、
前記情報処理装置に対する電源投入が指示されると、前記ライセンス情報に基づいて、前記複数の処理部のそれぞれに対し、当該処理部を動作させるかどうかを設定する設定部と、
前記設定部による前記設定の完了後に、前記処理部を動作させる制御部と、
をそなえることを特徴とする情報処理装置。
情報処理装置であって、
複数の処理部と、
前記複数の処理部のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、前記複数の処理部のいずれを動作させるかを規定するライセンス情報を記憶するライセンス情報記憶部と、
前記情報処理装置に対する電源投入が指示されると、前記ライセンス情報に基づいて、前記複数の処理部のそれぞれに対し、当該処理部を動作させるかどうかを設定する設定部と、
前記設定部による前記設定の完了後に、前記処理部を動作させる制御部と、
をそなえることを特徴とする情報処理装置。
（付記２）
前記情報処理装置は、
該情報処理装置が冗長構成である場合に、該情報処理装置と冗長構成を構成している他の情報処理装置との間で通信を行なう通信部と、
該情報処理装置が冗長構成かどうか、及び該情報処理装置が冗長構成である場合には該情報処理装置が運用系か待機系かに基づいて、前記処理部のうちのいずれを動作させるかを判定し、当該判定結果を前記ライセンス情報として前記ライセンス情報記憶部に書き込む管理部をさらにそなえる
ことを特徴とする付記１記載の情報処理装置。
前記情報処理装置は、
該情報処理装置が冗長構成である場合に、該情報処理装置と冗長構成を構成している他の情報処理装置との間で通信を行なう通信部と、
該情報処理装置が冗長構成かどうか、及び該情報処理装置が冗長構成である場合には該情報処理装置が運用系か待機系かに基づいて、前記処理部のうちのいずれを動作させるかを判定し、当該判定結果を前記ライセンス情報として前記ライセンス情報記憶部に書き込む管理部をさらにそなえる
ことを特徴とする付記１記載の情報処理装置。
（付記３）
前記管理部は、該情報処理装置が冗長構成の待機系である場合に、前記処理部に対し、当該処理部の動作を不許可にするよう前記ライセンス情報を設定する
ことを特徴とする付記２記載の情報処理装置。
（付記４）
前記管理部は、前記情報処理装置が冗長構成の運用系である場合に、前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
ことを特徴とする付記２又は３記載の情報処理装置。
前記管理部は、該情報処理装置が冗長構成の待機系である場合に、前記処理部に対し、当該処理部の動作を不許可にするよう前記ライセンス情報を設定する
ことを特徴とする付記２記載の情報処理装置。
（付記４）
前記管理部は、前記情報処理装置が冗長構成の運用系である場合に、前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
ことを特徴とする付記２又は３記載の情報処理装置。
（付記５）
前記通信部が前記他の情報処理装置からの応答がないことを検出すると、
該通信部は前記他の情報処理装置の前記制御部に対して、電源の強制切断を指示すると共に、
前記管理部が、前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
ことを特徴とする付記２〜４のいずれか１項に記載の情報処理装置。
前記通信部が前記他の情報処理装置からの応答がないことを検出すると、
該通信部は前記他の情報処理装置の前記制御部に対して、電源の強制切断を指示すると共に、
前記管理部が、前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
ことを特徴とする付記２〜４のいずれか１項に記載の情報処理装置。
（付記６）
複数の処理部と、
前記複数の処理部のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、前記複数の処理部のいずれを動作させるかを規定するライセンス情報を記憶するライセンス情報記憶部と、をそなえる情報処理装置の制御方法であって、
前記情報処理装置に対する電源投入が指示されると、前記ライセンス情報に基づいて、前記複数の処理部のそれぞれに対し、当該処理部を動作させるかどうかを設定し、
前記設定の完了後に、前記処理部を動作させる
ことを特徴とする情報処理装置の制御方法。
複数の処理部と、
前記複数の処理部のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、前記複数の処理部のいずれを動作させるかを規定するライセンス情報を記憶するライセンス情報記憶部と、をそなえる情報処理装置の制御方法であって、
前記情報処理装置に対する電源投入が指示されると、前記ライセンス情報に基づいて、前記複数の処理部のそれぞれに対し、当該処理部を動作させるかどうかを設定し、
前記設定の完了後に、前記処理部を動作させる
ことを特徴とする情報処理装置の制御方法。
（付記７）
該情報処理装置が冗長構成である場合に、該情報処理装置と冗長構成を構成している他の情報処理装置との間で通信を行ない、
該情報処理装置が冗長構成かどうか、及び該情報処理装置が冗長構成である場合には該情報処理装置が運用系か待機系かに基づいて、前記処理部のうちのいずれを動作させるかを判定し、当該判定結果を前記ライセンス情報として前記ライセンス情報記憶部に書き込む
ことを特徴とする付記６記載の情報処理装置の制御方法。
該情報処理装置が冗長構成である場合に、該情報処理装置と冗長構成を構成している他の情報処理装置との間で通信を行ない、
該情報処理装置が冗長構成かどうか、及び該情報処理装置が冗長構成である場合には該情報処理装置が運用系か待機系かに基づいて、前記処理部のうちのいずれを動作させるかを判定し、当該判定結果を前記ライセンス情報として前記ライセンス情報記憶部に書き込む
ことを特徴とする付記６記載の情報処理装置の制御方法。
（付記８）
該情報処理装置が冗長構成の待機系である場合に、前記処理部に対し、当該処理部の動作を不許可にするよう前記ライセンス情報を設定する
ことを特徴とする付記７記載の情報処理装置の制御方法。
（付記９）
前記情報処理装置が冗長構成の運用系である場合に、前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
ことを特徴とする付記７又は８記載の情報処理装置の制御方法。
該情報処理装置が冗長構成の待機系である場合に、前記処理部に対し、当該処理部の動作を不許可にするよう前記ライセンス情報を設定する
ことを特徴とする付記７記載の情報処理装置の制御方法。
（付記９）
前記情報処理装置が冗長構成の運用系である場合に、前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
ことを特徴とする付記７又は８記載の情報処理装置の制御方法。
（付記１０）
前記通信部が前記他の情報処理装置からの応答がないことを検出すると、
前記他の情報処理装置の前記制御部に対して、電源の強制切断を指示すると共に、
前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
ことを特徴とする付記７〜９のいずれか１項に記載の情報処理装置の制御方法。
前記通信部が前記他の情報処理装置からの応答がないことを検出すると、
前記他の情報処理装置の前記制御部に対して、電源の強制切断を指示すると共に、
前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
ことを特徴とする付記７〜９のいずれか１項に記載の情報処理装置の制御方法。
（付記１１）
複数の処理部と、
前記複数の処理部のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、前記複数の処理部のいずれを動作させるかを規定するライセンス情報を記憶するライセンス情報記憶部と、をそなえる情報処理装置の制御プログラムであって、
前記情報処理装置に対する電源投入が指示されると、前記ライセンス情報に基づいて、前記複数の処理部のそれぞれに対し、当該処理部を動作させるかどうかを設定し、
前記設定の完了後に、前記処理部を動作させる
処理をコンピュータに実行させることを特徴とする情報処理装置の制御プログラム。
複数の処理部と、
前記複数の処理部のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、前記複数の処理部のいずれを動作させるかを規定するライセンス情報を記憶するライセンス情報記憶部と、をそなえる情報処理装置の制御プログラムであって、
前記情報処理装置に対する電源投入が指示されると、前記ライセンス情報に基づいて、前記複数の処理部のそれぞれに対し、当該処理部を動作させるかどうかを設定し、
前記設定の完了後に、前記処理部を動作させる
処理をコンピュータに実行させることを特徴とする情報処理装置の制御プログラム。
（付記１２）
該情報処理装置が冗長構成である場合に、該情報処理装置と冗長構成を構成している他の情報処理装置との間で通信を行ない、
該情報処理装置が冗長構成かどうか、及び該情報処理装置が冗長構成である場合には該情報処理装置が運用系か待機系かに基づいて、前記処理部のうちのいずれを動作させるかを判定し、当該判定結果を前記ライセンス情報として前記ライセンス情報記憶部に書き込む
処理を前記コンピュータに実行させることを特徴とする付記１１記載の情報処理装置の制御プログラム。
該情報処理装置が冗長構成である場合に、該情報処理装置と冗長構成を構成している他の情報処理装置との間で通信を行ない、
該情報処理装置が冗長構成かどうか、及び該情報処理装置が冗長構成である場合には該情報処理装置が運用系か待機系かに基づいて、前記処理部のうちのいずれを動作させるかを判定し、当該判定結果を前記ライセンス情報として前記ライセンス情報記憶部に書き込む
処理を前記コンピュータに実行させることを特徴とする付記１１記載の情報処理装置の制御プログラム。
（付記１３）
該情報処理装置が冗長構成の待機系である場合に、前記処理部に対し、当該処理部の動作を不許可にするよう前記ライセンス情報を設定する
処理を前記コンピュータに実行させることを特徴とする付記１２記載の情報処理装置の制御プログラム。
該情報処理装置が冗長構成の待機系である場合に、前記処理部に対し、当該処理部の動作を不許可にするよう前記ライセンス情報を設定する
処理を前記コンピュータに実行させることを特徴とする付記１２記載の情報処理装置の制御プログラム。
（付記１４）
前記情報処理装置が冗長構成の運用系である場合に、前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
処理を前記コンピュータに実行させることを特徴とする付記１２又は１３記載の情報処理装置の制御プログラム。
前記情報処理装置が冗長構成の運用系である場合に、前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
処理を前記コンピュータに実行させることを特徴とする付記１２又は１３記載の情報処理装置の制御プログラム。
（付記１５）
前記通信部が前記他の情報処理装置からの応答がないことを検出すると、
前記他の情報処理装置の前記制御部に対して、電源の強制切断を指示すると共に、
前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
処理を前記コンピュータに実行させることを特徴とする付記１２〜１４のいずれか１項に記載の情報処理装置の制御プログラム。
前記通信部が前記他の情報処理装置からの応答がないことを検出すると、
前記他の情報処理装置の前記制御部に対して、電源の強制切断を指示すると共に、
前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
処理を前記コンピュータに実行させることを特徴とする付記１２〜１４のいずれか１項に記載の情報処理装置の制御プログラム。
１ 情報処理システム
２ 運用系サーバ
３ 待機系サーバ
２１，３１ ＳＢ
２２−１〜２２−ｋ（２２） ＣＰＵ（処理部）
３２−１〜３２−ｋ（３２） ＣＰＵ（処理部）
２５，３５ ＸＳＣＦ
４１ ユーザＩ／Ｆ部
４２ ライセンス登録部
４３ ＳＢ電源制御部
４６ ライセンス制御部（設定部）
４７ サーバ判定部
４８ ライセンス設定部（管理部）
４９ ＣＰＵ制御部（制御部）
５０ サーバ監視部
５１ サーバ間通信部（通信部）
５２ ライセンスＤＢ（ライセンス情報記憶部）
５３ ライセンス記憶域
５４ ライセンス属性テーブル（ライセンス情報）
２ 運用系サーバ
３ 待機系サーバ
２１，３１ ＳＢ
２２−１〜２２−ｋ（２２） ＣＰＵ（処理部）
３２−１〜３２−ｋ（３２） ＣＰＵ（処理部）
２５，３５ ＸＳＣＦ
４１ ユーザＩ／Ｆ部
４２ ライセンス登録部
４３ ＳＢ電源制御部
４６ ライセンス制御部（設定部）
４７ サーバ判定部
４８ ライセンス設定部（管理部）
４９ ＣＰＵ制御部（制御部）
５０ サーバ監視部
５１ サーバ間通信部（通信部）
５２ ライセンスＤＢ（ライセンス情報記憶部）
５３ ライセンス記憶域
５４ ライセンス属性テーブル（ライセンス情報）
Claims (7)
- 情報処理装置であって、
複数の処理部と、
前記複数の処理部のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、前記複数の処理部のいずれを動作させるかを規定するライセンス情報を記憶するライセンス情報記憶部と、
前記情報処理装置に対する電源投入が指示されると、前記ライセンス情報に基づいて、前記複数の処理部のそれぞれに対し、当該処理部を動作させるかどうかを設定する設定部と、
前記設定部による前記設定の完了後に、前記処理部を動作させる制御部と、
をそなえることを特徴とする情報処理装置。 - 前記情報処理装置は、
該情報処理装置が冗長構成である場合に、該情報処理装置と冗長構成を構成している他の情報処理装置との間で通信を行なう通信部と、
該情報処理装置が冗長構成かどうか、及び該情報処理装置が冗長構成である場合には該情報処理装置が運用系か待機系かに基づいて、前記処理部のうちのいずれを動作させるかを判定し、当該判定結果を前記ライセンス情報として前記ライセンス情報記憶部に書き込む管理部をさらにそなえる
ことを特徴とする請求項１記載の情報処理装置。 - 前記管理部は、該情報処理装置が冗長構成の待機系である場合に、前記処理部に対し、当該処理部の動作を不許可にするよう前記ライセンス情報を設定する
ことを特徴とする請求項２記載の情報処理装置。 - 前記管理部は、前記情報処理装置が冗長構成の運用系である場合に、前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
ことを特徴とする請求項２又は３記載の情報処理装置。 - 前記通信部が前記他の情報処理装置からの応答がないことを検出すると、
該通信部は前記他の情報処理装置の前記制御部に対して、電源の強制切断を指示すると共に、
前記管理部が、前記ライセンスの数を上限とする数の前記処理部に対し、当該処理部の動作を許可するよう前記ライセンス情報を設定する
ことを特徴とする請求項２〜４のいずれか１項に記載の情報処理装置。 - 複数の処理部と、
前記複数の処理部のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、前記複数の処理部のいずれを動作させるかを規定するライセンス情報を記憶するライセンス情報記憶部と、をそなえる情報処理装置の制御方法であって、
前記情報処理装置に対する電源投入が指示されると、前記ライセンス情報に基づいて、前記複数の処理部のそれぞれに対し、当該処理部を動作させるかどうかを設定し、
前記設定の完了後に、前記処理部を動作させる
ことを特徴とする情報処理装置の制御方法。 - 複数の処理部と、
前記複数の処理部のうちの１つの動作を許可する少なくとも１つのライセンスに基づいて、前記複数の処理部のいずれを動作させるかを規定するライセンス情報を記憶するライセンス情報記憶部と、をそなえる情報処理装置の制御プログラムであって、
前記情報処理装置に対する電源投入が指示されると、前記ライセンス情報に基づいて、前記複数の処理部のそれぞれに対し、当該処理部を動作させるかどうかを設定し、
前記設定の完了後に、前記処理部を動作させる
処理をコンピュータに実行させることを特徴とする情報処理装置の制御プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014142478A JP6417759B2 (ja) | 2014-07-10 | 2014-07-10 | 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014142478A JP6417759B2 (ja) | 2014-07-10 | 2014-07-10 | 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2016018493A true JP2016018493A (ja) | 2016-02-01 |
| JP6417759B2 JP6417759B2 (ja) | 2018-11-07 |
Family
ID=55233643
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2014142478A Active JP6417759B2 (ja) | 2014-07-10 | 2014-07-10 | 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6417759B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2020135571A (ja) * | 2019-02-22 | 2020-08-31 | 横河電機株式会社 | コンピュータシステム、コンピュータ装置およびライセンス管理方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008158639A (ja) * | 2006-12-21 | 2008-07-10 | Hitachi Ltd | プロセッサライセンスを管理するサーバ装置 |
| WO2009118886A1 (ja) * | 2008-03-28 | 2009-10-01 | 富士通株式会社 | ハードウェアリソースの管理装置 |
-
2014
- 2014-07-10 JP JP2014142478A patent/JP6417759B2/ja active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008158639A (ja) * | 2006-12-21 | 2008-07-10 | Hitachi Ltd | プロセッサライセンスを管理するサーバ装置 |
| WO2009118886A1 (ja) * | 2008-03-28 | 2009-10-01 | 富士通株式会社 | ハードウェアリソースの管理装置 |
Non-Patent Citations (1)
| Title |
|---|
| 菅井 光浩: "プロダクト 知る・選ぶ・使う", 日経ＳＹＳＴＥＭＳ 第１５８号, JPN6018003809, 26 May 2006 (2006-05-26), JP, pages 106 - 113, ISSN: 0003733832 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2020135571A (ja) * | 2019-02-22 | 2020-08-31 | 横河電機株式会社 | コンピュータシステム、コンピュータ装置およびライセンス管理方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP6417759B2 (ja) | 2018-11-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5637873B2 (ja) | 計算機システムおよびｐｃｉカードのｈｂａ識別子引き継ぎ方式 | |
| JP4939102B2 (ja) | ネットワークブート計算機システムの高信頼化方法 | |
| JP6034990B2 (ja) | サーバ制御方法及びサーバ制御装置 | |
| JP2010510592A (ja) | システムプロセッサーのトランスペアレントな交換 | |
| JP6237406B2 (ja) | 情報処理装置、ストレージシステム、およびプログラム | |
| JP2006163963A (ja) | ディスク引き継ぎによるフェイルオーバ方法 | |
| JP5413514B2 (ja) | 管理装置、情報処理装置、制御方法及びプログラム | |
| JP6555096B2 (ja) | 情報処理装置およびプログラム更新制御方法 | |
| JP6813010B2 (ja) | 可用性のシステム、方法、およびプログラム | |
| JP2004295270A (ja) | 共用記憶システム | |
| JP2016042249A (ja) | 設定検証方法、設定検証プログラムおよび設定検証装置 | |
| JP2005242574A (ja) | 情報処理システム、および情報処理方法 | |
| US8312211B2 (en) | Disk array apparatus, method for application of control firmware, and controlling unit for controlling application of control firmware | |
| JP2013161130A (ja) | 制御装置、制御システムおよび制御方法 | |
| JP5509176B2 (ja) | 計算機システムおよび計算機システムにおけるモジュール引き継ぎ方法 | |
| JP2015148861A (ja) | 情報処理システム及びプログラム管理方法 | |
| JP6417759B2 (ja) | 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム | |
| JP6749072B2 (ja) | ストレージ管理装置及びストレージ管理プログラム | |
| US20210034376A1 (en) | Boot personality for network device | |
| JP5484434B2 (ja) | ネットワークブート計算機システム、管理計算機、及び計算機システムの制御方法 | |
| JP6089835B2 (ja) | 情報処理装置及び制御方法 | |
| JP2009042932A (ja) | 記憶制御装置の制御プログラムの更新方法 | |
| JP2007018049A (ja) | 記憶制御システム | |
| JP6435842B2 (ja) | ストレージ制御装置及びストレージ制御プログラム | |
| JP6012479B2 (ja) | 情報処理システム、制御方法および制御プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20170406 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20180119 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20180206 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180409 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20180911 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20180924 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6417759 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |