(57)【要約】  複数の機能ボードを具備するサーバを保守する方法、管理ノード及びサーバは、複数の機能ボードのうち少なくとも１つの機能ボードのシャットダウンを実行する前に、少なくとも１つの機能ボードの識別子を含むシャットダウン要求をサーバにおいて受信するステップ及び機能と、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスを識別するステップ及び機能と、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスの識別子を含むサービス通知を送信するステップ及び機能とを含む。送信されたサービス通知を考慮して行なわれるシャットダウン決定及びキャンセルシャットダウン決定のうちいずれか一方を含む決定通知を受信するステップ及び機能と、決定通知がシャットダウンする決定を含む場合に少なくとも１つの機能ボードをシャットダウンするステップ及び機能とが更に含まれる。
2007536672.tif 000002
【特許請求の範囲】
【請求項１】
複数の機能ボードを備えるサーバを保守する方法であって、
‐前記複数の機能ボードのうちの１つに対応する識別子を有するシャットダウン要求を前記サーバにおいて受信するステップと、
‐前記識別子が受信された前記少なくとも１つの機能ボードのシャットダウンを実行する前に、
前記少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスを識別し、
前記少なくとも１つの機能ボードと関連付けられる前記少なくとも１つのサービスの識別子を有するサービス通知を送信するステップと、
‐前記送信されたサービス通知を考慮して行なわれるシャットダウン決定及びキャンセルシャットダウン決定のうちいずれか一方を有する決定通知を受信するステップと、
‐前記決定通知がシャットダウンする前記決定を有する場合に前記少なくとも１つの機能ボードをシャットダウンするステップとを備える方法。
【請求項２】
‐前記シャットダウン要求の受信後、前記少なくとも１つの機能ボードを、前記少なくとも１つの機能ボードの現在のタスクが正常に処理され、新しいタスクが前記少なくとも１つの機能ボードにより受け付けられない、シャットダウンモードにするステップと、
‐前記決定通知の受信後、前記決定通知が前記キャンセルシャットダウン決定を有する場合、前記少なくとも１つの機能ボードの前記シャットダウンモードをキャンセルするステップとを更に備える請求項１記載の方法。
【請求項３】
‐シャットダウン要求を受信する前記ステップは、前記シャットダウン要求内のタイマ値を前記サーバにおいて受信するステップを備え、
‐前記少なくとも１つの機能ボードをシャットダウンする前記ステップは、前記少なくとも１つの機能ボードをシャットダウンする前に、前記タイマ値の時間が経過するのを待つステップを備える請求項１記載の方法。
【請求項４】
‐前記サービス通知の送信後、前記少なくとも１つの機能ボードと関連付けられる前記少なくとも１つのサービスに関する情報に対する要求を受信するステップと、
‐前記少なくとも１つの機能ボードと関連付けられる前記少なくとも１つのサービスに関して前記サーバに保持される情報を有する情報回答を送信するステップとを更に備える請求項１記載の方法。
【請求項５】
‐前記サービス通知の送信後、タイマ値を有する待ち要求を受信するステップと、
‐前記タイマ値の時間が経過するのを待つステップと、
‐前記少なくとも１つの機能ボードと関連付けられる前記少なくとも１つのサービスを再度識別するステップと、
‐前記少なくとも１つの機能ボードと関連付けられる前記少なくとも１つのサービスの識別子を有する更なるサービス通知を送信するステップとを更に備える請求項１記載の方法。
【請求項６】
前記少なくとも１つの機能ボードをシャットダウンする前記ステップは、前記少なくとも１つの機能ボードの前記識別子及び前記少なくとも１つのサービスの前記識別子を有するロック通知を送信することを更に備える請求項１記載の方法。
【請求項７】
‐前記サーバに接続される管理ノードにおいて前記サービス通知を受信するステップと、
‐前記少なくとも１つの機能ボードと関連付けられる前記少なくとも１つのサービスの重要度を評価するステップであって、前記重要度は、前記少なくとも１つのサービスに関連付けられる種々の基準を考慮して評価される、ステップと、
‐前記シャットダウン決定及び前記キャンセルシャットダウン決定のうちいずれか一方を使用して前記決定通知を作成するステップと、
‐前記決定通知を前記管理ノードから前記サーバに送信するステップとを更に備える請求項１記載の方法。
【請求項８】
各々が少なくとも１つのサービスを提供する複数の機能ボードを具備する通信ネットワーク内のサーバであって、
入力通信モジュールであって、
‐前記複数の機能ボードのうち少なくとも１つの機能ボードに対応する識別子を有するシャットダウン要求を受信し、
‐シャットダウン決定及びキャンセルシャットダウン決定のうちいずれか一方を有する決定通知を受信することが可能な、入力通信モジュールと、
診断モジュールであって、
‐前記シャットダウン要求において識別された前記少なくとも１つの機能ボードと関連付けられる前記少なくとも１つのサービスを識別し、
‐前記シャットダウン要求の受信時、前記少なくとも１つの機能ボードと関連付けられる前記少なくとも１つのサービスの識別子を有する前記せービス通知を作成及び送信することが可能であり、前記決定通知の前記シャットダウン決定及び前記キャンセルシャットダウン決定は送信されるサービス通知を考慮して行なわれる、診断モジュールと、
ハードウェア管理モジュールであって、
‐前記決定通知が前記シャットダウン決定を有する場合、前記シャットダウン要求において識別された前記少なくとも１つの機能ボードをシャットダウンすることが可能な、ハードウェア管理モジュールと、を具備するサーバ。
【請求項９】
前記ハードウェア管理モジュールは、
‐前記シャットダウン要求の受信時、前記少なくとも１つの機能ボードを、前記少なくとも１つの機能ボードの現在のタスクが正常に処理され、新しいタスクが前記少なくとも１つの機能ボードにより受け付けられない、シャットダウンモードにし、
‐前記決定通知が前記キャンセルシャットダウン決定を有する場合、前記少なくとも１つの機能ボードの前記シャットダウンモードをキャンセルすることが更に可能である請求項８記載のサーバ。
【請求項１０】
‐前記入力通知モジュールは、前記シャットダウン要求内のタイマ値を受信することが更に可能であり、
‐前記ハードウェア管理モジュールは、前記少なくとも１つの機能ボードをシャットダウンする前に、前記タイマ値の時間が経過するのを待つことが更に可能である請求項８記載のサーバ。
【請求項１１】
前記入力通知モジュールは、前記少なくとも１つの機能ボードと関連付けられる前記少なくとも１つのサービスに関する情報に対する要求を受信することが更に可能であり、前記診断モジュールは、前記少なくとも１つの機能ボードと関連付けられる前記少なくとも１つのサービスに関して前記サーバに保持される情報を有する情報回答を送信することが更に可能である請求項８記載のサーバ。
【請求項１２】
‐前記入力通知モジュールは、前記サービス通知の送信後、タイマ値を有する待ち要求を受信することが更に可能であり、
‐前記診断モジュールは、
‐前記タイマ値の時間が経過するのを待ち、
‐前記少なくとも１つの機能ボードと関連付けられる前記少なくとも１つのサービスを再度識別し、
‐前記少なくとも１つの機能ボードと関連付けられる前記少なくとも１つのサービスの識別子を有する更なるサービス通知を送信することが更に可能である請求項８記載のサーバ。
【請求項１３】
前記ハードウェア管理モジュールは、
‐前記シャットダウン決定を有する前記決定通知の受信後、前記少なくとも１つの機能ボードの前記識別子及び前記少なくとも１つのサービスの前記識別子を有するロック通知を送信することが更に可能である請求項８記載のサーバ。
【請求項１４】
複数の機能ボードを備えるリモートサーバの保守を管理する管理ノードであって、
‐前記管理ノードのユーザとの対話を管理することが可能であり、前記対話の特性はリモート及びローカルのうちいずれか一方であるグラフィカル・ユーザインタフェース（ＧＵＩ）と、
‐前記リモートサーバの少なくとも１つの機能ボードを保守するために前記ＧＵＩを介して前記ユーザから要求を受信し、
‐前記複数の機能ボードのうち前記少なくとも１つの機能ボードの識別子を有するシャットダウン要求を前記リモートサーバに送信し、
‐前記少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスの識別子を有するサーバ通知を前記リモートサーバから受信し、
‐前記少なくとも１つのサービスの重要度に基づいて前記少なくとも１つの機能ボードのシャットダウンに対する決定を行ない、
‐前記決定が前記少なくとも１つの機能ボードをシャットダウンする決定である場合、シャットダウン決定を有する決定通知を前記リモートサーバに送信することが可能な保守モジュールとを具備する管理ノード。
【請求項１５】
前記保守モジュールは、
‐前記少なくとも１つの機能ボードと関連付けられる前記少なくとも１つのサービスに関して前記リモートサーバに情報要求を送信し、
‐前記決定を行なう前に、前記少なくとも１つのサービスに関して、前記リモートサーバにおいて見つけられる更なる情報を有する前記リモートサーバからの情報回答を待つことが更に可能である請求項１４記載の管理ノード。
【請求項１６】
前記保守モジュールは、
‐タイマ値と共に待ち要求を前記リモートサーバに送信し、
‐前記決定を行なう前に更なるサービス通知を待つことが更に可能である請求項１４記載の管理ノード。
【請求項１７】
前記保守モジュールは、
‐前記決定を行なう前にエキスパートシステムと対話することが更に可能であり、前記エキスパートシステムは、前記管理ノードと共に配置されるか又はリモートに配置される請求項１４記載の管理ノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リモートサーバシステムに配置される機能ボードの保守に関する。
【背景技術】
【０００２】
現在の殆どのコンピュータは、各々が特定の機能性を有する複数のカード又はボードを備えている。例えば、それらのボードは、コンピュータのネットワーク接続性を提供してもよく、あるいはディスプレイ・インタフェースを提供してもよい。コンピュータのアーキテクチャに応じて、各ボードは固定的に搭載されてもよく、あるいは着脱交換可能であってもよい。一般に、コンピュータにおけるボード内の通信は、周知の特性を有するデータバスを介して実行される。それら特性は、標準化され、また、全ての産業（ＰＣＩ、ＡＧＰ等）に適用されてもよく、あるいは特定のコンピュータメーカに特有（自社開発のインタフェース）であってもよい。特性は、ボードにより提供される機能性や、ボードが固定か取外し可能かの種類によって異なる。
【０００３】
サーバ機能を有するコンピュータにおいては、サーバの機能性がボードの適切な動作に関連するため、ボードの保守は非常に重要である。サーバにより提供されるサービスに対する保守の影響を最小限にするために、多くの努力がされてきた。その目標は、サーバにより提供される全てのサービスに対して最大の可用性を常に取得することである。時間を節約するために、例えば、サーバコンピュータの１つのボードのみをシャットダウンし、サーバをリセットする必要なくそのボードを修理するか、又は別のボードと置換することができる。そのような方法が望ましい状況としては、例えば、周期的に警告を生成するボードの一貫性のない障害を解決する場合や、ボードのハードウェア又はソフトウェアをアップグレードする場合、並びに、ボードに対してテストを実行する場合がある。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、サーバにより現在提供されているサービスに対するボードのシャットダウンの影響又は他の重要な保守作業の影響を識別する周知の方法は存在しない。このため、特定の保守タスクの結果を事前に評価することは不可能である。サービスプロバイダの観点から保守作業の影響を予測できるように、サーバにより提供されるサービスに関連するボードの作業状態を取得するのが便利である。本発明は、そのような要求に応じる。
【課題を解決するための手段】
【０００５】
本発明の第１の面は、複数の機能ボードを備えるサーバを保守する方法に関する。方法は、複数の機能ボードのうち少なくとも１つの機能ボードの識別子を有するシャットダウン要求をサーバにおいて受信するステップと、少なくとも１つの機能ボードのシャットダウンを実行する前に、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスを識別し、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスの識別子を有するサービス通知を送信するステップとを備える。この方法は、送信されたサービス通知を考慮して行なわれるシャットダウン決定及びキャンセルシャットダウン決定のうちいずれか一方を有する決定通知を受信するステップと、決定通知がシャットダウンする決定を有する場合に少なくとも１つの機能ボードをシャットダウンするステップとを更に備える。
【０００６】
本発明の第２の面は、各々が少なくとも１つのサービスを提供する複数の機能ボードを具備する通信ネットワーク内のサーバに関する。このサーバは、入力通信モジュール、診断モジュール及びハードウェア管理モジュールを備える。サーバの入力通信モジュールは、複数の機能ボードのうち少なくとも１つの機能ボードの識別子を有するシャットダウン要求を受信し、シャットダウン決定及びキャンセルシャットダウン決定のうちいずれか一方を有する決定通知を受信することが可能である。サーバの診断モジュールは、シャットダウン要求において識別された少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスを識別し、シャットダウン要求の受信時にサービス通知を作成及び送信することが可能である。サービス通知は、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスの識別子を有する。ここで、決定通知のシャットダウン決定及びキャンセルシャットダウン決定は、送信されたサービス通知を考慮して行なわれる。サーバのハードウェア管理モジュールは、決定通知がシャットダウン決定を有する場合、シャットダウン要求において識別された少なくとも１つの機能ボードをシャットダウンすることが可能である。
【０００７】
本発明の第３の面は、複数の機能ボードを備えるリモートサーバの保守を管理するための通信ネットワーク内の管理ノードに関する。管理ノードは、グラフィカル・ユーザインタフェース（ＧＵＩ）及び保守モジュールを具備する。管理ノードのＧＵＩは、管理ノードのユーザとの対話を管理することが可能である。ここで、対話の特性は、リモート及びローカルのうちいずれか一方である。管理ノードの保守モジュールは、リモートサーバの少なくとも１つの機能ボードを保守するためにＧＵＩを介してユーザから要求を受信し、複数の機能ボードのうち少なくとも１つの機能ボードの識別子を有するシャットダウン要求をリモートサーバに送信することが可能である。更に、保守モジュールは、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスの識別子を有するサービス通知をリモートサーバから受信し、少なくとも１つのサービスの重要度に基づいて少なくとも１つの機能ボードのシャットダウンに対する決定を行ない、決定が少なくとも１つの機能ボードをシャットダウンする決定である場合にシャットダウン決定を有する決定通知をリモートサーバに送信することが可能である。
【発明を実施するための最良の形態】
【０００８】
本発明は、添付の図面と関連付けて以下の詳細な説明を参照することにより更によく理解されるだろう。
【０００９】
本発明は、サーバにより提供されるサービスに対する保守作業の悪影響を低減することを目的とする。機能ボードを介して提供されるサーバのサービスの場合、一般に保守作業は、保守作業を進めるために機能ボードをシャットダウンすること（又は同様の効果を有するオフラインにすること）を必要とする。そのような場合、保守作業の影響を予測できるように、影響を受ける機能ボードの作業状態を事前に取得することが望ましい。本発明は、サーバと管理ノードとの間の対話を可能性として含む機構を提供する。ここで、シャットダウンされる機能ボードにより提供されるサービスに関する情報は、管理ノードから適切な要求を受信した後に管理ノードに送信される。管理ノードにおける人間オペレータ又はエキスパートシステムは、可能性として管理ノードにおいて入手可能な他の情報を考慮して、保守作業を継続するか又は保守作業をすぐにキャンセルするかを適切に決定できる。
【００１０】
図面を参照すると、図１は、通信ネットワーク１００のサーバ１２０の保守に対する信号フロー及びノードの動作の一例を示す。図１は、サーバ１２０及び管理ノード１１０を示す。管理ノード１１０は、リモートに配置され、種々のネットワーク機器を介してサーバ１２０とネットワーク接続されるか、あるいはローカルに配置され、サーバ１２０と直接接続されるか又はサーバ１２０と共に配置される。サーバ１２０及び管理ノード１１０がネットワーク１００を介して通信する必要がある場合、通信の種々のプロトコル（イーサネットを介するＩＰ、ＡＴＭのＳＳ７等）は本発明に影響を与えることなく使用されてもよい。同様に、サーバ１２０と管理ノード１１０との間で交換されるメッセージの構造は標準化されてもよく（例えば、簡易ネットワーク管理プロトコル（ＳＮＭＰ：Simple Network Management Protocol））、あるいはサーバ１２０及び管理ノード１１０の製造業者が少なくとも部分的に自社開発したものでもよい。
【００１１】
サーバ１２０は、各々が少なくとも１つのサービスを提供できる複数の機能ボード（図１には示さない）を含む。一例として、本発明は基地局制御器（ＢＳＣ：Base Station Controller）の特定のアプリケーションに適用される。本発明において、例えば、ネットワーク接続性サービスを提供するインタフェースボード、同期サービスを提供するタイミングボード、トラフィックスイッチングサービスを提供するスイッチボード、汎用サーバ関連サービスを提供する汎用プロセッサボード、専用サーバ関連サービスを提供する専用プロセッサボード及びメディアストリーミングサービスを提供するメディアストリーミングボード等の種々の機能ボード、或いは、フィールド交換可能ユニット（ＦＲＵ：Field Replaceable Units）が使用される。当然、ＢＳＣは機能ボードアーキテクチャを有するサーバ１２０の一例であり、サーバ１２０において使用されるサービスの例は本発明の機能をより適切に説明するために示されることを理解すべきである。
【００１２】
図１に示される本発明の第１の実施形態において、サーバ１２０の複数の機能ボードのうち少なくとも１つの機能ボードを保守する方法が提供される。方法は、少なくとも１つの機能ボードの識別子を含むシャットダウン要求をサーバ１２０において受信するステップ１３０を含む。通常、シャットダウンするための要求が管理ノード１１０から送信され、そこでは保守する機能ボードが選択されている。例えば、機能ボードの選択は、サーバ１２０のアーキテクチャを示す管理ノード１１０のグラフィカル・ユーザインタフェース（ＧＵＩ）（図１には示さない）を介して行なわれる。
【００１３】
少なくとも１つの機能ボードの識別子に加え、要求はタイマ値ｔ１を含んでもよい。タイマ値は、少なくとも１つの機能ボードがシャットダウンされるまでの最小限の時間を表す。しかし、以下に提示される他の条件が満足される場合のみ、シャットダウンが行なわれる。タイマ値は、ステップ１３０のシャットダウンするための要求で送信される前に、管理ノード１１０のＧＵＩにおいて調整できる。
【００１４】
ステップ１３０においてシャットダウン要求を受信すると、オプションとして、サーバ１２０は少なくとも１つの機能ボードをシャットダウンモードにしてもよい（ステップ１３２）。シャットダウンモードでは、現在の全てのタスクは正常に処理されるが、少なくとも１つの機能ボードが新しいタスクを受け付けることを禁止する。タスクのライフサイクルが予測される特別な例の場合、タイマ値と組み合わせることでシャットダウンモードは有用である。そのような場合、シャットダウンモードは、機能ボードがシームレスに自身を解放することを可能にし、別の機能ボードは、シャットダウンされる機能ボードにより受け付けられなかった新しい要求を処理すると考えられる。図１において、ステップ１３２はステップ１３０の直後に示されるが、機能ボードの種類及び関連サービスに依存して、ステップ１３０の要求の受信後いつでも実行できる。図１において、ステップ１３２のボックスは破線で示され、本発明の本実施形態の方法におけるオプション特性及びオプションの位置付けを示す。
【００１５】
方法は、少なくとも１つの機能ボードのシャットダウンを実行する前に、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスを識別するステップ１３３を含む。少なくとも１つのサービスの識別は、例えば、少なくとも１つの機能ボードのリソースを使用する少なくとも１つのアプリケーションを識別し、その後少なくとも１つのサービスに少なくとも１つのアプリケーションを関連付けることにより行なわれる。識別後、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスの識別子を含むサービス通知は、ステップ１３６で管理ノード１１０に送信される前に、ステップ１３４において作成される。
【００１６】
この時点で、管理ノード１１０は、ステップ１３６においてサービス通知を受信し、例えばＳＮＭＰ（又はＭＩＢ）データベースのサーバ１２０に関する他の情報に対してアクセス権を有してもよい。サーバ１２０にある情報により、管理ノード１１０の人間オペレータ又はエキスパートシステム（不図示）は、シャットダウン決定がされるべきか又はキャンセルシャットダウン決定がされるべきかに関して適切な決定を行なえる（ステップ１４２）。ステップ１４２の決定は、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスの重要度の評価を含むことができる。そのような場合、重要度は、少なくとも１つのサービスと関連付けられる種々の基準を考慮して評価される。当然、本発明の範囲は、決定を行なうために使用される基準ではなく、そのような基準に基づく決定が機能ボードをシャットダウンする前に行なわれる可能性を含むことを理解すべきである。しかし、基準のリストの例は、少なくとも１つのサービスと関連付けられるユーザ数、少なくとも１つのサービスとサーバ１２０、又は、通信ネットワーク１００の他のサービスとの対話、サーバ１２０の所有者に対する予想される収益の損失等を含む。ある状況において、オプションとして、管理ノード１１０の人間オペレータ又はエキスパートシステムは、ステップ１４２の決定を行なうのに十分な情報を有していない場合がある。その場合、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスに関する情報に対する要求（ステップ１３８）は、管理ノード１１０からサーバ１２０に送信される。サーバ１２０は、少なくとも１つの機能ボード上の少なくとも１つのサービスに対して開かれるネットワークポート数等の少なくとも１つのサービスに関するサーバに含まれる関連情報を検索する（ステップ１３９）。ステップ１４０において、サーバ１２０は、検索した情報から作成される情報回答を返信する。図１において、ステップ１３８〜１４０は破線のボックス１４１中に示され、本発明におけるオプション特性を示す。
【００１７】
ステップ１３６のサービス通知の受信後、管理ノード１１０における人間オペレータ又はエキスパートシステムが何らかの理由により更なる時間を要求するか又は最終決定を行なうのを待つことを要求する場合、決定１４２は、オプションとして延期決定で構成されてもよい。そのような場合、少なくとも１つの機能ボードの識別子及び待ちタイマ値ｔ２を含む待ち要求は、管理ノード１１０により作成され、サーバ１２０に送信される（ステップ１４４）。サーバ１２０は、待ちタイマ値の時間が経過するのを待ち（ステップ１４６）、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスを再度識別し（ステップ１４８）、さらに、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスの識別子を含む更なるサービス通知を送信する（ステップ１５０）。ステップ１４４の待ち要求は、更なるシャットダウン要求でもよく、ステップ１３０のシャットダウン要求を置換又は更新する。この例におけるステップ１４４の更なるシャットダウン要求は、タイマ値ｔ２を含む。ステップ１５０の後、人間オペレータ又はエキスパートシステムは、決定１４２を先に行なった方法と同様の方法で更なる決定１４２’を行なう。同様に、決定１４２’は、決定を延期してもよく、或いは、更なる情報を要求してもよい（ステップ１４１）。図１において、ステップ１４４〜１５０及び１４２’は破線のボックス１５１中に示され、本発明におけるオプション特性を示し、また、決定１４２’が最終決定を延期する間、必要な回数だけステップ１５１を繰り返し可能なことを例示する。
【００１８】
ステップ１５１及びステップ１４１を繰り返す回数に関係なく、又はそれらステップが全く実行されない場合でも、シャットダウンする決定又はシャットダウンをキャンセルする決定は、人間オペレータ又はエキスパートシステムにより必ず行なわれる必要がある（ステップ１４２又は１４２’）。決定されると、シャットダウンする決定又はシャットダウンをキャンセルする決定は、決定通知でサーバ１２０に送信される（ステップ１５２）。同様に、サーバ１２０は、ステップ１５２の決定通知を受信し、決定通知がシャットダウンする決定を含む場合、ステップ１３０のシャットダウンするための要求において識別子により既に識別されている少なくとも１つの機能ボードをシャットダウンする（ステップ１５６）。しかし、オプションのタイマ値がステップ１３０のシャットダウン要求に含まれ、かつ決定通知がシャットダウン決定を含む場合、少なくとも１つの機能ボードをシャットダウンするステップ１５６は、ステップ１３０のシャットダウン要求のタイマ値の時間が経過してから実行できる。ステップ１５２の決定通知は、ステップ１４２又は１４２’で行なわれた決定に依存にして異なる特質を有する。例えば、機能ボードをシャットダウンする決定を含むステップ１５２の決定通知は、シャットダウンされる機能ボードの識別子を含むロック通知であってもよく、この場合、少なくとも１つの機能ボード上で実行する全てのタスクは終了され、ボードはシャットダウンされる。同様に、機能ボードのシャットダウンをキャンセルする決定を含むステップ１５２の決定通知は、シャットダウンされない機能ボードの識別子を含むアンロック通知であってもよい。
【００１９】
ステップ１３０のシャットダウン要求がタイマ値ｔ１を含む更なるオプションの動作において、タイマ値ｔ１の時間が経過する前にキャンセルシャットダウン決定がステップ１４２又は１４２’の決定において受信されない限り、少なくとも１つの機能ボードのシャットダウンは、タイマ値ｔ１の時間が経過した時に行なわれてもよい。同様に、ステップ１４４の待ち要求がタイマ値ｔ２を含む場合、タイマ値ｔ２の時間が経過する前にキャンセルシャットダウン決定がステップ１４２又は１４２’の決定において受信されない限り、少なくとも１つの機能ボードのシャットダウンは、タイマ値ｔ２の時間が経過した時に行なわれてもよい。
【００２０】
上述のように、機能ボードをシャットダウンモードにするステップ１３２は、ステップ１３０のシャットダウン要求の受信からステップ１５２の決定通知の受信までの間にいつでも実行できる。ボードがステップ１３２においてシャットダウンモードにされ、かつ、キャンセルシャットダウン決定がステップ１５２の決定通知において受信される場合、機能ボードのシャットダウンモードをキャンセルするステップ１５７が実行される必要がある。図１において、機能ボードのシャットダウンモードをキャンセルするステップ１５７は破線のボックスで示され、オプションのステップ１３２に関連することによるオプション特性を強調する。しかし、ボードがステップ１３２においてシャットダウンモードにされ、かつシャットダウン決定がステップ１５２の決定通知において受信される場合、機能ボードのシャットダウンモードをキャンセルする必要はない。
【００２１】
シャットダウン決定がステップ１５２の決定通知において受信される全ての場合において、ロック通知をサーバ１２０から管理ノード１１０に送信すること（ステップ１５８）はオプションの動作である。ステップ１５８のロック通知は、機能ボードがそれ以降オフラインになることを示す。ステップ１５８のロック通知は、少なくとも１つの機能ボードの識別子、及び少なくとも１つのサービスの識別子を含む。
【００２２】
新しい機能ボード（或いは、シャットダウンされた機能ボードの変更バージョン）がサーバ１２０に配置され、起動される（ステップ１６０）場合の他のオプションのステップが、図１に示される。ステップ１６０の起動後、アンロック通知は、サーバ１２０において管理ノード１１０から受信される必要がある（ステップ１６２）。ステップ１６４のアンロック通知は、少なくとも新しい機能ボードの識別子を含み、また、新しい機能ボードにより提供される少なくとも１つのサービスの識別子を更に含むことができる。アンロック通知の受信後、新しい機能ボードは、アンロックモードにされるか（ステップ１６４）又は動作モードを完了する。図１において、ステップ１５８〜１６４は破線のボックス１６１中に示され、本発明におけるオプション特性を示す。
【００２３】
次に図２を参照すると、リモートサーバ（図２には示さない）の保守を管理するための通信ネットワーク（図２には示さない）内の管理ノード２００のモジュール表現の一例が示される。リモートサーバは、本発明による複数の機能ボードを含む。管理ノード２００は、グラフィカル・ユーザインタフェース（ＧＵＩ）２１０及び保守モジュール２２０を含む。
【００２４】
ＧＵＩ２１０は、管理ノード２００のユーザとの対話を管理できる。管理ノード２００がローカル又はリモートでアクセスされるため、管理ノード２００のユーザとの対話はリモート特性、又はローカル特性を有する。
【００２５】
管理ノード２００の保守モジュール２２０は、リモートサーバの少なくとも１つの機能ボードの保守と関連する複数のタスクを処理できる。保守モジュール２２０は、ＧＵＩを介してユーザから要求を受信し、リモートサーバの少なくとも１つの機能ボードを保守できる。その要求により、保守モジュール２２０は、複数の機能ボードのうち少なくとも１つの機能ボードの識別子が含まれるシャットダウン要求をリモートサーバに送信できる。シャットダウン要求の後、保守モジュール２２０は、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスの識別子を含むサービス通知をリモートサーバから受信する。サービス通知が利用可能である時、保守モジュール２２０は、特に少なくとも１つのサービスの重要度に基づいて、少なくとも１つの機能ボードがシャットダウンされるか否かを決定できる。決定するために、保守モジュール２２０は、管理ノード２００と共に配置されるか、又は管理ノード２００に対してリモートに配置されるエキスパートシステムと更に対話してもよい。少なくとも１つの機能ボードをシャットダウンする決定である場合、保守モジュール２２０は、シャットダウン決定を含む決定通知をリモートサーバに更に送信できる。上述のように、本発明の範囲は、決定を行なうために使用される基準ではなく、そのような基準に基づく決定が機能ボードをシャットダウンする前に行なわれる可能性を含む。
【００２６】
本発明のオプションの実施形態において、更に保守モジュール２２０は、サービス通知の受信後、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスに関して情報要求をリモートサーバに送信できる。そのような場合、管理モジュール２２０は、決定を行なう前に、リモートサーバにおいて見つけられる少なくとも１つのサービスに関する更なる情報を含むリモートサーバからの情報回答を待つ必要がある。これは、サービス通知が適切な決定を行なうのに十分な情報を含んでいない場合に特に有用である。
【００２７】
管理ノード２００の保守モジュール２２０に対する別のオプションの動作として、サービス通知の受信後、タイマ値と共に待ち要求をリモートサーバに送信し、決定を行なう前に更なるサービス通知を待つ。
【００２８】
次に図３を参照すると、サーバ３００のモジュール表現の一例が示される。サーバ３００は複数の機能ボード３４０Ａ〜３４０Ｅを含み、各機能ボード３４０Ａ〜３４０Ｅは少なくとも１つのサービスを提供する。サーバ３００は、種々の要求を受信できる入力通信モジュール３１０と、サーバ３００の現在の作業を解析できる診断モジュール３２０と、機能ボード３４０Ａ〜３４０Ｅを含むサーバ３００のハードウェア部分を管理できるハードウェア管理モジュール３３０とを更に含む。
【００２９】
更に詳細には、入力通信モジュール３１０は、複数の機能ボード３４０Ａ〜３４０Ｅのうち、例えば少なくとも１つの機能ボード３４０Ｃの識別子を含むシャットダウン要求を受信し、シャットダウン決定及びキャンセルシャットダウン決定のうちいずれか一方を含む決定通知を受信できる。
【００３０】
診断モジュール３２０は、シャットダウン要求において識別された少なくとも１つの機能ボード３４０Ｃと関連付けられる少なくとも１つのサービスを識別し、シャットダウン要求の受信時にサービス通知を作成して送信できる。サービス通知は、少なくとも１つの機能ボード３４０Ｃと関連付けられる少なくとも１つのサービスの識別子を含み、決定通知のシャットダウン決定及びキャンセルシャットダウン決定は、送信されたサービス通知を考慮して行なわれる。
【００３１】
ハードウェア管理モジュール３３０は、決定通知がシャットダウン決定を含む場合、シャットダウン要求において識別された少なくとも１つの機能ボード３４０Ｃをシャットダウンできる。
【００３２】
オプションとして、更にハードウェア管理モジュール３３０は、シャットダウン要求の受信時、少なくとも１つの機能ボード３４０Ｃをシャットダウンモードにできる。シャットダウンモードにおいて、少なくとも１つの機能ボード３４０Ｃの現在のタスクは正常に処理され、新しいタスクは少なくとも１つの機能ボード３４０Ｃにより受け付けられない。同様に、ハードウェア管理モジュール３３０は、決定通知がキャンセルシャットダウン決定を含む場合、少なくとも１つの機能ボードをアンロックモードにできてもよい。
【００３３】
更に、入力通信モジュール３１０は、シャットダウン要求内のタイマ値を受信できてもよい。そのような場合、ハードウェア管理モジュール３３０は、少なくとも１つの機能ボードをシャットダウンする前に、タイマ値の時間が経過するのを待つことができる必要がある。
【００３４】
入力通信モジュールは、少なくとも１つの機能ボード３４０Ｃと関連付けられる少なくとも１つのサービスに関する情報に対する要求を受信できてもよい。診断モジュール３２０は、少なくとも１つの機能ボード３４０Ｃと関連付けられる少なくとも１つのサービスに関してサーバに含まれる情報を含む情報回答を送信する機能を更に有する必要がある。
【００３５】
サーバ３００の別のオプションの実施形態において、更に入力通信モジュール３１０は、サービス通知の送信後、タイマ値を含む待ち要求を受信できる。この場合、診断モジュールは、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスを再度識別する前に、タイマ値の時間が経過するのを待ち、少なくとも１つの機能ボードと関連付けられる少なくとも１つのサービスの識別子を含む更なるサービス通知を送信できる。
【００３６】
ハードウェア管理モジュール３３０は、シャットダウン決定を含む決定通知の受信後、少なくとも１つの機能ボードの識別子及び少なくとも１つのサービスの識別子を含むロック通知を送信できてもよい。
【００３７】
本発明のいくつかの好適な実施形態が添付の図面に示され、先の詳細な説明において説明されたが、本発明は、開示される実施形態に限定されず、本発明の趣旨から逸脱せずに多くの再構成、変更、置換が可能であることは理解されるだろう。例えば、管理ノード２００は、サーバ３００に対してローカルなノード及びリモートのノードを複数含んでもよく、それらノードは、互いに対話し、詳細な説明において説明された機能性を管理ノード２００下で提供する。
【図面の簡単な説明】
【００３８】
【図１】本発明による複数の機能ボードを含むサーバの保守に対する信号フロー及びノードの動作の一例を示す図である。
【図２】本発明による複数の機能ボードを含むリモートサーバの保守を管理する管理ノードのモジュール表現の一例を示す図である。
【図３】本発明による各々が少なくとも１つのサービスを提供する複数の機能ボードを含むサーバのモジュール表現の一例を示す図である。
【図１】
2007536672.tif 000003
【図２】
2007536672.tif 000004
【図３】
2007536672.tif 000005
【国際調査報告】
2007536672.tif 000006
2007536672.tif 000007
2007536672.tif 000008