(57)【特許請求の範囲】
【請求項１】
複数のサーバを備え、
前記複数のサーバのうちの少なくとも一は、
所定のサーバに設定変更の承認要求を送信すると共に、該所定のサーバを介して、前記承認要求に対する結果を受信する送受信手段と、
前記送受信手段が受信した前記結果が変更可能の場合、自サーバの設定変更を実行する変更手段と
を備え、
前記所定のサーバとして、前記複数のサーバのうち一が予め設定され、
前記所定のサーバは、前記承認要求を受信すると、管理端末に前記承認要求を送信すると共に、前記管理端末から受信した前記承認要求に対する結果を、前記承認要求の送信元のサーバに送信し、
前記設定変更の前記承認要求に対する結果を、前記承認要求の送信元以外のサーバにも適用するか否かを示す情報を前記設定変更ごとに保持し、前記承認要求に対する結果が、前記情報に基づき前記承認要求の送信元以外のサーバにも適用する結果である場合、該結果を前記承認要求の送信元以外のサーバにも送信する
サーバ管理システム。
【請求項２】
前記各サーバは、それぞれ、前記送受信手段と、前記変更手段とを備えたサービスプロセッサを備えた
請求項１記載のサーバ管理システム。
【請求項３】
当該所定のサーバは、承認要否に関する承認ポリシーを、前記複数のサーバに送信し、
前記送受信手段は、
前記所定のサーバから取得した前記承認ポリシーに基づいて、承認が必要と判断した場合に前記承認要求を前記所定のサーバに送信する
請求項１または請求項２記載のサーバ管理システム。
【請求項４】
前記所定のサーバは、前記承認要求を受信すると、承認要否に関する承認ポリシーに基づいて、承認が必要と判断した場合に前記承認要求を前記管理端末に送信する
請求項１乃至請求項３のいずれかに記載のサーバ管理システム。
【請求項５】
前記所定のサーバは、前記承認ポリシーの変更履歴を記憶装置に保存する
請求項３記載のサーバ管理システム。
【請求項６】
前記所定のサーバは、受信した前記承認要求および該承認要求に対する結果に関するログを記憶装置に保存する
請求項３乃至請求項５のいずれか１項記載のサーバ管理システム。
【請求項７】
前記複数のサーバのうち、前記所定のサーバの異常の際に当該所定のサーバに代わって前記承認要求を受信する予備サーバが予め設定され、
前記予備サーバは、前記所定のサーバの異常を検出すると、当該所定のサーバと自サーバ以外のサーバに前記異常を通知すると共に前記所定のサーバに代わって前記承認要求を受信する
請求項１乃至請求項６のいずれか１項記載のサーバ管理システム。
【請求項８】
複数のサーバのうちの予め設定された一のサーバであって、
設定変更の承認要求を受信すると、当該承認要求を管理端末に送信すると共に、当該管理端末から受信した前記承認要求に対する結果を、前記承認要求の送信元に送信し、
前記設定変更の前記承認要求に対する結果を、前記承認要求の送信元以外にも適用するか否かを示す情報を前記設定変更ごとに保持し、前記承認要求に対する結果が、前記情報に基づき前記承認要求の送信元以外にも適用する結果である場合、該結果を前記承認要求の送信元以外にも送信する
サーバ。
【請求項９】
前記管理端末から取得した承認要否に関する承認ポリシーを、前記複数のサーバに送信する
請求項８記載のサーバ。
【請求項１０】
複数のサーバのうちの予め設定された一は、
設定変更の承認要求を受信すると、当該承認要求を管理端末に送信すると共に、当該管理端末から受信した前記承認要求に対する結果を、前記承認要求の送信元に送信し、
前記設定変更の前記承認要求に対する結果を、前記承認要求の送信元以外にも適用するか否かを示す情報を前記設定変更ごとに保持し、
前記承認要求に対する結果が、前記情報に基づき前記承認要求の送信元以外にも適用する結果である場合、該結果を前記承認要求の送信元以外にも送信する
サーバ管理方法。
【請求項１１】
設定変更の承認要求を受信すると、当該承認要求を管理端末に送信すると共に、当該管理端末から受信した前記承認要求に対する結果を、前記承認要求の送信元に送信する送受信手段を備え、
前記設定変更の前記承認要求に対する結果を、前記承認要求の送信元以外にも適用するか否かを示す情報を設定変更ごとに保持し、
前記承認要求に対する結果が、前記情報に基づき前記承認要求の送信元以外にも適用する結果である場合、前記送受信手段は、該結果を前記承認要求の送信元以外にも送信する
サービスプロセッサ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバに対して各種設定を行う技術に関する。
【背景技術】
【０００２】
これまで手元のコンピュータで管理・利用していたアプリケーションやコンピューティングリソースを、ネットワーク経由でサービスの形で必要に応じて利用可能とするクラウドコンピューティングと呼ばれる方式が、近年、盛んに活用されている。
【０００３】
サービスの提供者は、大規模なデータセンターなどに多数のサーバを用意し、遠隔からネットワークを通じてソフトウェアやデータ保管領域を利用できるようなシステムを構築している。このようなシステムをユーザに適切に提供するため、サーバに対して、例えば、ユーザ毎の要求に応じた設定や、障害発生時の迅速な復旧処理等を適切に行うことが求められる。
【０００４】
ところで、サーバは、一般に、ＢＭＣ（Ｂａｓｅｂｏａｒｄ  Ｍａｎａｇｅｍｅｎｔ  Ｃｏｎｔｒｏｌｌｅｒ）やサーバ管理サービスプロセッサ等と呼ばれるサーバ管理チップを搭載しており、このサーバ管理チップにより、ハードウェア、例えばＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、メモリ、温度、電圧、電流等の監視を行っている。サーバ管理チップは、また、ハードウェア障害等のためにオペレティングシステムがダウンしている際においても機能する、障害通報機能やリモートコントロール機能等を提供する。このサーバ管理チップを、以降、「サービスプロセッサ」と称する。
【０００５】
サービスプロセッサには、また、ネットワーク情報、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレス、ユーザ権限等の各種設定がなされている。このような設定は、データセンターなどに多数設置された各サーバに対して、作業員が個別に行う場合がある。
【０００６】
この場合、作業員は、例えば、インターネットを介して各サーバと通信可能な保守端末からＷｅｂブラウザを経由して上記設定を行う。あるいは、サーバ本体側に組み込まれた設定ツールのインタフェースを介して作業員が設定・変更を行うものもある。
【０００７】
ここで、例えば、特許文献１には、未登録デバイスを接続した時点でユーザへの通知を行うと共に、管理者が承認した場合に、デバイス制御の設定を変更することができるシステムが開示されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１３−０７７１８２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上述のように、サービスプロセッサに対する各種設定は、作業員により、保守端末またはサーバに組み込まれた設定ツール等を用いて行われる場合がある。この場合、作業員本人のみによる作業となることが多く、そのため設定された値が正しいかどうかを複数の作業員がチェックしたり、承認者が承認した設定のみを反映させたりすることができない。よって、作業員の認識誤り等に起因する誤設定を防ぐことができないという課題がある。
【００１０】
特許文献１に開示されるシステムでは、クライアントに新規にデバイスを接続する際に、デバイス制御ポリシー一覧を格納したサーバにアクセスし、サーバから承認されたデバイスのみを変更可能とすることにより、不正なデバイスを検出している。しかしながら、不正有無の判断のための承認用サーバを特別に用意する必要があるという課題がある。
【００１１】
本願発明は、上記課題を鑑みてなされたものであり、設定変更を、誤りなくかつ承認用サーバを要することなく実行できるサーバ管理システム等を提供することを主要な目的とする。
【課題を解決するための手段】
【００１２】
本発明の第１のサーバ管理システムは、複数のサーバを備え、前記複数のサーバのうちの少なくとも一は、所定のサーバに設定変更の承認要求を送信すると共に、該所定のサーバを介して、前記承認要求に対する結果を受信する送受信手段と、前記送受信手段が受信した前記結果が変更可能の場合、自サーバの設定変更を実行する変更手段とを備える。
【００１３】
本発明の第１のサーバは、複数のサーバのうちの予め設定された一のサーバであって、設定変更の承認要求を受信すると、当該承認要求を管理端末に送信すると共に、当該管理端末から受信した前記承認要求に対する結果を、前記承認要求の送信元に送信する。
【００１４】
本発明の第１のサーバ管理方法は、複数のサーバのうちの少なくとも一が、所定のサーバに設定変更の承認要求を送信すると共に、該所定のサーバを介して前記承認要求に対する結果を受信し、前記受信した前記結果が変更可能の場合、自サーバの設定変更を実行する。
【００１５】
本発明の第１のサービスプロセッサは、所定のサーバに自サービスプロセッサの設定変更の承認要求を送信すると共に、該所定のサーバを介して前記承認要求に対する結果を受信する送受信手段と、前記送受信手段が受信した前記結果が変更可能の場合、自サービスプロセッサの設定変更を実行する変更手段とを備える。
【発明の効果】
【００１６】
本願発明によれば、設定変更を、誤りなくかつ承認用サーバを要することなく実行できるという効果が得られる。
【図面の簡単な説明】
【００１７】
【図１】本発明の第１の実施形態に係るサーバ管理システムの構成を示すブロック図である。
【図２】本発明の第１の実施形態に係るサーバ管理システムのサーバ装置が備えるサービスプロセッサの機能を示す機能ブロック図である。
【図３】本発明の第１の実施形態に係るサーバ管理システムのサーバ装置が備えるサービスプロセッサを実現するハードウエア構成の一例を示す図である。
【図４】本発明の第１の実施形態に係るサーバ管理システムのサーバ装置が備える承認ポリシーの一例を示す図である。
【図５】本発明の第１の実施形態に係るサーバ管理システムにおいてマスタＳＰが指定された際のサーバ管理システムの動作を示すフローチャートである。
【図６】本発明の第１の実施形態に係るサーバ管理システムの運用中の動作について説明するフローチャートである。
【図７】本発明の第１の実施形態に係るサーバ管理システムのプライマリマスタＳＰに障害が発生した際のサーバ管理システムの動作を示すフローチャートである。
【図８】本発明の第２の実施形態に係るサーバ管理システムの構成を示すブロック図である。
【発明を実施するための形態】
【００１８】
以下、本発明の実施形態について図面を参照して詳細に説明する。
【００１９】
第１の実施形態
図１は、本発明の第１の実施形態に係るサーバ管理システム１００の構成を示すブロック図である。サーバ管理システム１００は、複数のサーバ装置１１０−１乃至１１０−ｎ（ｎは整数）を備える。サーバ装置１１０−１乃至１１０−ｎは、インターネット網２００に通信可能に接続されている。インターネット網２００には、サーバ装置１１０−１乃至１１０−ｎを管理する管理端末３００が通信可能に接続されている。
【００２０】
サーバ装置１１０−１乃至１１０−ｎは、例えばデータセンターに配置されており、それぞれユーザに対するサービスを提供するシステムを構築しているとする。各サーバ装置間には図示しないルータ、スイッチングハブ等が配置されてもよく、互いにＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）を介して通信可能である。
【００２１】
各サーバ装置１１０−１乃至１１０−ｎは、自装置のハードウェアの監視等を行うサービスプロセッサをそれぞれ搭載する。サーバ装置１１０−１乃至１１０−ｎのうちのいずれか１つ（ここではサーバ装置１１０−１）に搭載されるサービスプロセッサは、マスタサービスプロセッサとして、他のサーバ装置１１０−２乃至１１０−ｎのサービスプロセッサの設定の管理を行う（詳細は後述する）。
【００２２】
ここで、サービスプロセッサの設定には、ＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）の設定、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ  Ａｒｒａｙｓ  ｏｆ  Ｉｎｅｘｐｅｎｓｉｖｅ  Ｄｉｓｋｓ）コントローラの設定、またはサービスプロセッサ自身の設定など、各サーバ装置のＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）起動前に行われる各種設定が含まれる。あるいは、サービスプロセッサの設定には、サービスプロセッサに対する電源断やリセット等のボタン操作が含まれてもよい。
【００２３】
本実施形態では、マスタのサーバ装置のサービスプロセッサ（以降、「マスタサービスプロセッサ」または「マスタＳＰ」とも称する）が、他のサーバ装置のサービスプロセッサ（以降、「スレーブサービスプロセッサ」または「スレーブＳＰ」と称する）の設定の管理を行うことで、各サーバ装置におけるサービスプロセッサの設定を誤りなく行うことについて説明する。
【００２４】
[運用前]
まず、サーバ管理システム１００の運用前の動作について説明する。管理者は、管理端末３００を用いて、インターネット網２００を介して、サーバ装置１１０−１乃至１１０−ｎを操作することができる。ここで、「管理者」は、管理端末３００を操作してインターネット網２００を介してサーバ装置１１０−１乃至１１０−ｎの管理や、保守員による設定変更の承認等をする者を意味する。「保守員」は、例えばデータセンターなどにおいて直接またはＷｅｂブラウザ等を経由して各サーバ装置１１０−１乃至１１０−ｎに設定変更を行う者を意味する。
【００２５】
管理者は、管理端末３００を操作して、まず、通信可能に接続されているサーバ装置のうち、同一グループとするサーバ装置を選択すると共に、その中からマスタとするサーバ装置を決定する。例えば、管理端末３００には、複数のサーバ装置を一元管理するソフトウエア等が搭載されており、管理者は、そのソフトウエアを用いて、一元管理するサーバ装置を選択すると共に、そのサーバ装置からマスタに設定するサーバ装置を指定してもよい。
【００２６】
図１に示すように、サーバ装置１１０−１のサービスプロセッサがマスタＳＰに指定されたとする。マスタに指定されない他のサーバ装置（図１では、サーバ装置１１０−２、１１０−３、・・・１１０−ｎ）のサービスプロセッサは、スレーブＳＰとなる。管理者は、また、冗長構成とするためにプライマリマスタの他、セカンダリマスタに設定するサーバ装置（予備サーバ）を指定する。例えば、セカンダリマスタとして、複数のスレーブＳＰのうち負荷の低いスレーブＳＰを設定してもよい。図１では、サーバ装置１１０−４のサービスプロセッサがスレーブＳＰであると共にセカンダリマスタＳＰを兼ねている。
【００２７】
各サーバ装置１１０−１乃至１１０−ｎは、いずれがプライマリマスタ、セカンダリマスタまたはスレーブに設定されたかの通知を、管理端末３００から受信する。なお、プライマリマスタとセカンダリマスタは、生存確認のために、定期的にパケット交換を行う。
【００２８】
図２は、サーバ装置１１０−１乃至１１０−ｎ（図２では、サーバ装置１１０−１乃至１１０−ｎを代表して「サーバ装置１１０」と称する）が備えるサービスプロセッサ１３０の機能を示す機能ブロック図である。図２に示すように、サーバ装置１１０のサービスプロセッサ１３０は、送受信部１３１、記憶装置１３２および変更部１３５を備える。変更部１３５は、判断部１３３および実行部１３４を備える。
【００２９】
各構成要素は、概略以下の機能を有する。すなわち、送受信部１３１は、マスタＳＰ以外の場合、保守端末１２０から設定変更を受けると、その設定変更の承認要求をマスタＳＰに送信すると共に、その承認要求に対する結果を受信する。マスタＳＰの送受信部１３１は、保守端末１２０から設定変更を受けると、その設定変更の承認要求を管理端末３００に送信する。なお、サービスプロセッサに対する設定変更は、保守端末１２０からその操作を受けることに限定されず、例えば、保守員が直接サーバ装置１１０−１乃至１１０−ｎを操作してもよい。
【００３０】
記憶装置１３２は、マスタＳＰまたは管理端末３００から受け取った承認ポリシー（詳細は後述する）を記憶する。変更部１３５の判断部１３３は、承認ポリシーに基づいて、設定変更の承認要否を判断したり、送受信部１３１が受信した承認要求に対する結果に基づいて、自サーバ装置の設定変更の可否を判断したりする。実行部１３４は、判断部１３３により設定変更の実行可と判断された場合、その設定変更を実行する。
【００３１】
図３は、図２に示すサービスプロセッサ１３０を実現するハードウエア構成の一例を示す図である。図２に示すサービスプロセッサ１３０の各部は、図３に例示するハードウエア資源により実現される。図３に示す構成は、プロセッサ１０、メモリ１１およびプログラムを格納する記憶装置１３を備える。
【００３２】
サービスプロセッサ１３０の送受信部１３１、判断部１３３および実行部１３４は、記憶装置１３に格納された、これら各部の機能を実現するプログラムを、プロセッサ１０が、メモリ１１に読み出して実行することによって実現される。
【００３３】
なお、サーバ装置１１０−１乃至１１０−ｎにおけるサービスプロセッサ１３０は、図２に示す他にも各種処理を行う回路を備えるが、本実施形態では、本発明に関する構成要素について主に説明する。また、記憶装置１３２は、サービスプロセッサ１３０が備えてもよいし、サービスプロセッサ１３０とは別のハードウエアとしてサーバ装置１１０に設けてもよい。
【００３４】
プライマリマスタに指定されたサーバ装置のサービスプロセッサ、すなわちマスタＳＰは、以下に説明するように、スレーブＳＰの管理を行う。すなわち、マスタＳＰは、スレーブＳＰへの承認ポリシーの送信、承認要求の中継、および承認に関するログ保存を行う。ここで、承認ポリシーとは、サービスプロセッサの設定に関し、その設定変更の実行に管理者の承認が必要か不要かを示したポリシーである。つまり、サービスプロセッサにおける所定の設定については管理者の承認が必要となり、それが承認ポリシーとして事前に定められている。
【００３５】
管理者は、サービスプロセッサに対するいずれの設定変更には承認が必要あるいは不要であり、またいずれの設定変更は許可するか許否するか等を示す承認ポリシーを記述したファイルを作成し、管理端末３００からマスタサービスプロセッサに通知しておく。
【００３６】
図４は、管理者により作成された承認ポリシー１４０の一例を示す図である。図４に示すように、承認ポリシー１４０は、「設定変更」、「承認要否」、「変更許否」、「全適用」の各項目を含む。「設定変更」は、サービスプロセッサに対する保守員の設定変更の内容を指す。例えば、ネットワーク設定変更、ＩＰアドレス変更、ＲＡＩＤコントローラ設定変更およびユーザ権限変更等がある。
【００３７】
「承認要否」は、設定変更の実行において、管理者の承認が必要か否かを示す。管理者の承認が「要」である場合、サービスプロセッサは、設定変更の実行の承認要求を送信し、その承認要求に対する結果が実行可である場合に設定変更を実行する。
【００３８】
「変更許否」は、管理者の承認が「不要」である場合に、設定変更の実施（実行）を行ってよいか否かを示す。「変更許否」が「可」である場合は、設定変更の実行可であり、「否」である場合は、設定変更の実行不可であることを示す。
【００３９】
「全適用」は、管理者の承認が必要な設定変更に関し、承認要求に対する結果をすべてのスレーブＳＰに適用するか否かを示す。例えば、あるスレーブＳＰからマスタＳＰにＩＰアドレスの変更に関する承認要求が送信され、それに対して管理者が「承認拒否」を送信してきた場合、マスタＳＰは、送信元のスレーブＳＰのみでなく他のスレーブＳＰにもＩＰアドレスの変更の「承認拒否」を送信する。
【００４０】
承認ポリシーは、図４に示す例に限定されない。また、同一グループに属する各サーバ装置に適用する承認ポリシーは同一でなくても、サーバ装置ごとに異なってもよい。
【００４１】
図５は、管理者によって複数のサーバ装置のサービスプロセッサのうちマスタＳＰが指定された際のサーバ管理システム１００の動作を示すフローチャートである。マスタＳＰは、自身がマスタＳＰに指定されたとき、記憶装置１３２に承認ポリシーを保持しているか否かを判断し、保持していない場合（Ｓ２１０においてＮｏ）、承認ポリシーを管理端末３００に要求する。
【００４２】
管理端末３００は、上記要求に応じて、管理者により作成された承認ポリシーをマスタＳＰに送信する（Ｓ２１１）。マスタＳＰは、管理端末３００から取得した承認ポリシーを保存すると共に（Ｓ２１２）、その承認ポリシーを同一グループに属するスレーブＳＰに通知する（Ｓ２１３）。
【００４３】
また、承認ポリシーを保持している場合（Ｓ２１０においてＹｅｓ）、マスタＳＰは、その承認ポリシーを同一グループに属するスレーブＳＰに通知する（Ｓ２１３）。
【００４４】
各スレーブＳＰは、マスタＳＰから受け取った承認ポリシーを、記憶装置１３２に保存しておく（Ｓ２１４）。
【００４５】
なお、管理者は、承認ポリシーを変更するごとにマスタサービスプロセッサに承認ポリシーを送信し、マスタサービスプロセッサは、受信した承認ポリシーをスレーブＳＰに通知すると共に、その変更履歴を保存しておく。
【００４６】
[運用中]
図６は、サーバ管理システム１００の運用中の動作について説明するフローチャートである。図６を参照して、サーバ管理システム１００の運用中の動作について説明する。なお、ここでは、予めマスタＳＰおよび各スレーブＳＰに例えば図４に示す承認ポリシー１４０が送られ、記憶装置１３２に記憶されているとする。
【００４７】
保守員が保守端末１２０を操作して、Ｗｅｂブラウザ経由で、例えばサーバ装置１１０−２のスレーブＳＰ（以降、「スレーブＳＰ１１０−２」とも称する）に設定変更の通知を行ったとする（Ｓ３１０）。スレーブＳＰ１１０−２は、送受信部１３１において、設定変更を検出すると（Ｓ３１１においてＹｅｓ）、判断部１３３において、記憶装置１３２に記憶されている承認ポリシーに基づいて、その設定変更の承認要否を判断する（Ｓ３１２）。
【００４８】
設定変更が、承認ポリシーにおいて「承認要」に指定されていた場合（Ｓ３１３においてＹｅｓ）、スレーブＳＰ１１０−２の判断部１３３は、設定変更の承認が必要と判断する。そして、送受信部１３１は、その設定変更の承認要求を、サーバ装置１１０−１のマスタＳＰ（以降、「マスタＳＰ１１０−１」とも称する）に送る。
【００４９】
マスタＳＰ１１０−１は、受け取った承認要求を管理端末３００に送信する（Ｓ３１４）。管理端末３００は、管理者に対して承認要求を提示すると共に、その承認要求に対する結果、すなわち、保守員による設定変更の承認を許可するか許否するかを管理者から受け付け、その結果をマスタＳＰ１１０−１に返信する（Ｓ３１５）。
【００５０】
マスタＳＰ１１０−１は、管理端末３００から承認結果を受信すると、承認結果を承認要求と共にログ保存する（Ｓ３１６）。なお、マスタＳＰ１１０−１は、障害に備えて、保存しているログをセカンダリマスタＳＰに、定期的、パケット交換時、あるいは任意のタイミングで通知しておく。
【００５１】
マスタＳＰ１１０−１は、受信した承認結果を、承認要求の送信元であるスレーブＳＰ１１０−２に返信する（Ｓ３１７）。ここで、マスタＳＰ１１０−１は、承認要求を行った設定変更が「全適用」に該当するか否かを承認ポリシーに基づいて判断し、「全適用」に該当する場合、承認要求の送信元であるスレーブＳＰだけでなく同一グループ内のすべてのスレーブＳＰに承認結果を送信する。
【００５２】
なお、設定変更が「全適用」に該当するか否かの情報が承認ポリシーに含まれず、管理者からの承認結果に「全適用」の情報が含まれてもよい。この場合、マスタＳＰは、「全適用」の情報が含まれる承認結果を、承認要求の送信元であるスレーブＳＰだけでなく同一グループ内のすべてのスレーブＳＰに送信してもよい。
【００５３】
上記のように、「全適用」の設定変更に関する承認結果を受け取ったスレーブＳＰは、記憶装置１３２に記憶される承認ポリシーを、その承認結果に基づいて更新してもよい。
【００５４】
スレーブＳＰ１１０−２は、送受信部１３１において承認結果を受信し、判断部１３３において、承認結果に基づいて設定変更の可否を判断する。設定変更が承認許可された場合、実行部１３４は、設定変更を実行し、承認拒否された場合は実行しない（Ｓ３１８）。なお、承認結果に変更可否の指示が含まれている場合、判断部１３３はその承認結果を実行部１３４に通知し、実行部１３４は承認結果が変更可能の場合に設定変更を実行する。
【００５５】
そして、スレーブＳＰ１１０−２は、実行または不実行の結果、すなわち実行した場合はその結果を、不実行の場合はエラーを、送受信部１３１から保守端末１２０に送信する（Ｓ３１９）。保守端末１２０は、取得した結果を、ディスプレイ等に表示する（Ｓ３２０）。
【００５６】
なお、処理Ｓ３１３において、承認が不要であると判断した設定変更について（Ｓ３１３においてＮｏ）、さらに、判断部１３３において、承認ポリシーに基づいて、変更許否を判断する。変更可である場合（Ｓ３２１においてＹｅｓ）、設定変更の実施を行い（Ｓ３１８）、結果を送信する（Ｓ３１９）。変更不可である場合（Ｓ３２１においてＮｏ）、設定変更の実施を行わず、エラーを保守端末１２０に送信する（Ｓ３１９）。
【００５７】
上記説明では、例として保守端末１２０からのスレーブＳＰ１１０−２に対する設定変更に関して説明したが、他のスレーブＳＰ１１０−３乃至スレーブＳＰ１１０−ｎに対する設定変更に関しても同様に、マスタＳＰ１１０−１が承認要求を受信すると共に管理端末３００に問い合わせ、結果をスレーブＳＰに返信する。つまり、スレーブＳＰから管理者への承認要求を、マスタＳＰが中継する。
【００５８】
以上の手順により、保守端末１２０からスレーブＳＰに対する設定変更の承認要求をマスタＳＰが中継して管理端末３００に送信し、その承認結果をマスタＳＰを介してスレーブＳＰに返信する。
【００５９】
[障害時]
図７は、プライマリマスタＳＰに障害（異常）が発生した際のサーバ管理システム１００の動作を示すフローチャートである。図７を参照して、プライマリマスタＳＰに障害が発生した際のサーバ管理システム１００の動作について説明する。
【００６０】
プライマリマスタＳＰに障害が発生し、プライマリマスタＳＰからのパケットが途絶えたこと、または障害のためにマスタの役割ができない旨の通知がセカンダリマスタＳＰで検出されたとする（Ｓ４１０においてＹｅｓ）。このとき、セカンダリマスタＳＰは、自身がプライマリマスタＳＰに昇格した旨の通知を、同一グループのサーバ装置のスレーブＳＰに通知する（Ｓ４１１）。
【００６１】
各スレーブＳＰは、プライマリマスタＳＰの情報を更新する（Ｓ４１２）。以降、スレーブＳＰは、保守端末１２０からの設定変更を検出し、その設定変更に承認が必要であると判断した場合、更新後のプライマリマスタＳＰに送信する。
【００６２】
なお、上記では、マスタＳＰがスレーブＳＰに承認ポリシーを通知し、保守端末１２０から設定変更の通知を受けると、スレーブＳＰが承認ポリシーに基づいて承認要否を判断する構成を説明したが、これに限定されない。すなわち、マスタＳＰはスレーブＳＰに承認ポリシーを通知せず、スレーブＳＰは保守端末１２０から設定変更の通知を受けると、そのたびにマスタＳＰに承認要求を行い、マスタＳＰにおいて承認要否の判断を行う構成としてもよい。あるいは、マスタＳＰとスレーブＳＰともに承認ポリシーに基づく承認要否を判断する構成としてもよい。すなわち、マスタＳＰはスレーブＳＰに承認ポリシーを通知する。そして、スレーブＳＰはその承認ポリシーに基づいて承認要否を判断して必要な場合に承認要求をマスタＳＰに送信し、マスタＳＰは自身が保持する承認ポリシーに基づいて承認要否を判断する構成としてもよい。
【００６３】
以上のように、本第１の実施形態によれば、サーバ管理システム１００では、複数のサーバ装置のサービスプロセッサのうち、いずれかを予めマスタに指定し、管理者の承認要否を示す承認ポリシーを管理端末３００から予めマスタＳＰに通知しておく。そして、マスタＳＰは、スレーブＳＰに対する設定変更の承認要求を中継する。この構成を採用することにより、第１の実施形態によれば、承認ポリシーに基づいて管理者の承認が得られた場合にサービスプロセッサの設定変更を実行するので、保守員の認識誤り等に起因する誤設定を防ぐことができるという効果が得られる。
【００６４】
また、同一グループに属する複数のサーバ装置のサービスプロセッサのうち、いずれかを予めマスタＳＰに指定すると共に、そのマスタＳＰが他のサービスプロセッサからの承認要求を中継するので、承認用のサーバを用意する必要がないという効果が得られる。
【００６５】
また、プライマリマスタのみでなくセカンダリマスタのサービスプロセッサを予め指定することで、プライマリマスタＳＰに障害が発生した際に上記承認要求の中継をセカンダリマスタＳＰが代わりに行うので、プライマリマスタＳＰの障害時にも自律的に承認処理を継続することができるという効果が得られる。
【００６６】
また、管理端末３００から、インターネット網２００を介して各サーバ装置のサービスプロセッサに承認結果や承認ポリシーをそれぞれ送信するのではなく、マスタＳＰが承認結果や承認ポリシーを中継するので、ネットワークトラフィックを削減できるという効果が得られる。
【００６７】
さらに、マスタＳＰが承認ポリシーの変更履歴や、承認要求および承認結果の履歴を一元的にログ保存するので、同一グループに属するサーバ装置のサービスプロセッサ全体で行われる設定変更に関する承認処理の履歴の管理が容易になるという効果が得られる。
【００６８】
第２の実施形態
図８は、本発明の第２の実施形態に係るサーバ管理システム５００の構成を示すブロック図である。サーバ管理システム５００は、複数のサーバ５１０、５２０を備え、複数のサーバのうちの少なくとも一は、送受信部５２１および変更部５２２を備える。
【００６９】
送受信部５２１は、所定のサーバに設定変更の承認要求を送信すると共に、その所定のサーバを介して、承認要求に対する結果を受信する。変更部５２２は、送受信部５２１が受信した結果が変更可能の場合、自サーバの設定変更を実行する。
【００７０】
本発明は、本第２の実施形態に示す少なくとも上記構成を備えることにより、以下の効果を奏する。すなわち、本第２の実施形態によれば、所定のサーバに設定変更の承認要求を送信し、その結果に基づいて設定変更の実行または不実行とするので、設定変更を、誤りなく、かつ承認用サーバを要することなく実行できるという効果が得られる。
【００７１】
以上、上述した実施形態を模範的な例として本発明を説明した。しかしながら、本発明は、上述した実施形態には限定されない。即ち、本発明は、本発明のスコープ内において、当業者が理解し得る様々な態様を適用することができる。
【符号の説明】
【００７２】
１０  プロセッサ
１１  メモリ
１３  記憶装置
１００、５００  サーバ管理システム
１１０−１乃至１１０−ｎサーバ装置
１２０  保守端末
１３０  サービスプロセッサ
１３１  送受信部
１３２  記憶装置
１３３  判断部
１３４  実行部
１３５  変更部
１４０  承認ポリシー
２００  インターネット網
３００  管理端末
【図１】
0006394620.tif 000002
【図２】
0006394620.tif 000003
【図３】
0006394620.tif 000004
【図４】
0006394620.tif 000005
【図５】
0006394620.tif 000006
【図６】
0006394620.tif 000007
【図７】
0006394620.tif 000008
【図８】
0006394620.tif 000009