JP7436737B1 - マルチベンダーを支援するサーバ管理システム - Google Patents

Abstract

【課題】本発明は、マルチベンダーを支援するサーバ管理システムに関する。【解決手段】サーバ管理システムは、前記サーバ管理システムを管理する管理者が使用する管理者端末と、管理対象サーバを依頼した各顧客が使用する顧客端末と、前記管理対象サーバからデータを収集し、各管理対象サーバの現況を把握して管理し、これに関連した管理サービス統計データと管理サービスレポートを含む各種サーバ管理情報を前記の管理者端末と前記顧客端末に提供する管理サーバと、を含む。本発明によれば、マルチベンダーを支援するサーバ管理システムを提案することで、より便利で効率的に多数のサーバを管理できるという効果がある。【選択図】図１

Description

本発明は、サーバを管理するためのサーバ管理システムに関するものであり、より詳しくは、マルチベンダー（ｍｕｌｔｉ－ｖｅｎｄｏｒ）を支援するサーバ管理システムに関するものである。

近年、コンピュータが大容量化、高速化するにつれて、システムのエラーやウイルスなどによるコンピュータの障害が頻繁に発生している。特に、大容量のサーバの場合、多様な応用プログラムの動作と、データ保存、読み出し、および伝送など、色々な要因による障害が頻繁に発生しうる。したがって、各企業では、このようなサーバを管理する別途のサーバ管理者を常駐させてサーバを管理して、障害発生時に、これを処理するようにしている。

ところで、サーバ管理には、専門的な技術が要求され、そのような専門人材を採用するには、かなりの費用が要求される。したがって、特に、小規模な企業等では、当該サーバ管理者として専門技術者を採用するのではなく、社内の既存の人材の中から適切な者を選び、サーバ管理者として置いているのが実情である。その場合には、サーバ管理が円滑に行われにくく、しかもサーバ障害の発生時に円滑に対処することがほとんど不可能である。

また、サーバ管理のために専門技術を有するサーバ管理者を採用した場合でも、サーバ管理者が出張等の理由でサーバから遠隔地にいる場合には、サーバ障害の発生の時に、このようなサーバの状況を管理者に迅速に通知することが困難となり、サーバ障害の発生時に円滑に対処することが困難となった。さらに、サーバ管理者が当該サーバ障害の発生の通知を受けた場合でも、遠隔地にある関係で、直ちに対処することが難しく、最終的にサーバがダウンするなど莫大な損失を招かれることができる。

従来は、多数のサーバを統合して管理するサーバ統合管理システムで、あるサーバに障害が発生すれば、これを感知し、事後に障害を復旧する方式である。しかし、このような従来の事後の障害復旧方式は、障害が発生したサーバを復旧する期間中に、該当サーバの動作が中断され、サーバ使用の中断による損失が発生し、復旧するのにかかる人材と費用による損害が大きいという問題点がある。

韓国公開特許第２０１５－０１２４６４２号

本発明は、前記のような問題点を解決するために案出されたものであり、マルチベンダーを支援し、より迅速に自動化できるサーバ管理システムを提供することをその目的としている。

本発明の目的は以上で言及した目的に限定されず、言及されていない他の目的は、下記の記載から、通常の技術者であれば、明確に理解することができるものである。

このような目的を達成するために、本発明は、マルチベンダーを支援するサーバ管理システムに関するものであり、前記サーバ管理システムを管理する管理者が使用する管理者端末と、管理対象のサーバを依頼した各お客様が使用する顧客端末と、及び前記管理対象のサーバからデータを収集し、各管理対象のサーバの現状を把握して管理し、これに関連した管理サービス統計データと管理サービスレポートとを含む各種サーバ管理情報を前記管理者端末及び前記顧客端末に提供する管理サーバを含む。

前記管理サーバは、複数の管理対象サーバからマルチベンダーハードウェア情報を収集して保存し、保存した情報を照会して利用できるように、前記管理者端末及び前記顧客端末に提供することができる。

前記管理サーバは、登録された複数の管理対象サーバからマルチベンダーハードウェアインベントリ情報を収集して保存することができる。

前記管理サーバは、緊急ファームウェア（ｆｉｒｍｗａｒｅ）アップデートを含むファームウェアアップデートイベントがあれば、すべての管理対象サーバに対してファームウェアアップデートを進行することができる。

前記管理サーバは、管理対象サーバのある装備で障害が発生すると、ログおよびパターンを分析し、分析したデータを保存し、障害が解決されれば、該当装備と類似した装備を分類し、分類された類似装備に対して障害事前対応処理を行うことができる。

前記管理サーバは、Ｒｅｄｆｉｓｈ ＡＰＩを利用して各管理対象サーバのハードウェア詳細仕様、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）情報、ファームウェア情報、およびドライバー情報を含む運営中のｘ８６サーバに対する情報を収集でき、ｘ８６サーバの標準化管理を行うことができる。

本発明によれば、マルチベンダーを支援するサーバ管理システムを提案することで、より便利で効率的に多数のサーバを管理できる効果がある。

また、本発明によれば、サーバを所有している顧客に障害パターンを分析して先制的に障害をあらかじめ対応するようにし、サーバ管理機能を提供することで、顧客のニーズ（ｎｅｅｄｓ）に合うデータを加工して伝達できる効果がある。

図１は、本発明の一実施例によるサーバ管理システムの全般的な構成を概念的に図示したものである。 図２は、本発明の一実施例によるサーバ管理システムでマルチベンダーを支援してサーバを管理する方法を例示するフローチャートである。 図３は、本発明の一実施例によるサーバ管理システムで障害ログおよびパターンを分析して障害を事前に予防する方法を例示するフローチャートである。 図４は、本発明の一実施例によるサーバ管理システムで「Ｒｅｄｆｉｓｈ ＡＰＩ」を活用してマルチベンダーを支援する動作モデルを例示するものである。 図５は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図６は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図７は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図８は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図９は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図１０は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図１１は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図１２は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図１３は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図１４は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図１５は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図１６は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図１７は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図１８は、本発明の一実施例によるサーバ管理システムの画面例を図示するものである。 図１９は、本発明の一実施例によるシステム装備を分類した図表である。 図２０は、本発明の一実施例によるハードウェアの症状と、その原因を記載した図表である。 図２１は、本発明の一実施例によるハードウェアの症状と、その原因を記載した図表である。 図２２は、本発明の一実施例によるサーバ管理システムで障害事前対応方法を示すフローチャートである。 図２３は、本発明の一実施例によるサーバ管理システムで障害事前対応方法を示すフローチャートである。

本発明は、多様な変更を加えることができ、様々な実施例を持つことができる。特定の実施例を図面に例示して詳細に説明する。しかし、これは、本発明を特定の実施形態に対して限定しようとするものではなく、本発明の思想および技術範囲に含まれるすべての変更、均等物、ないし代替物を含むと理解されなければならない。

本出願で使用した用語は、単に特定の実施例を説明するために使用されたものであり、本発明を限定しようとする意図ではない。単数の表現は、文脈上明らかに異なる意味を持たない限り、複数の表現を含む。本出願において、「含む」又は「持つ」等の用語は、明細書上に記載された特徴、数字、段階、動作、構成要素、部品、又はこれらを組み合わせたものが存在することを指定しようとするものであり、一つまたはその以上の他の特徴、若しくは数字、段階、動作、構成要素、部品、又はこれらを組み合わせたものの存在又は付加の可能性をあらかじめ排除しないと理解しなければならない。

他に定義されない限り、技術的または科学的な用語を含み、本明細書で使用されるすべての用語は、本発明が属する技術分野で通常の知識を有する者によって一般に理解されるのと同じ意味を有する。一般的に使用される辞書で定義されているものなどの用語は、関連技術の文脈上の意味と一致する意味を有すると解釈されるべきであり、本出願で明確に定義されていない限り、理想的または過度に形式的な意味として解釈されるべきではない。

なお、添付図面を参照して説明するにあたり、図面符号にかかわらず同一の構成要素には同一の参照符号を付し、これに対する重複する説明は省略する。

本発明の説明において、関連する公知技術の具体的な説明が本発明の要旨を不必要に曇らせることができると判断される場合、その詳細な説明を省略する。

図１は、本発明の一実施例によるサーバ管理システムの全般的な構成を概念的に図示するものである。

図１を参照すれば、本発明のサーバ管理システムは、管理サーバ１１０、管理者端末１２０、及び顧客端末１３０を含む。

管理者端末１２０は、サーバ管理システムを管理する管理者が使用する端末である。

顧客端末１３０は、管理対象サーバ１０、２０、３０、４０の管理を依頼した各顧客が使用する端末である。

本発明の一実施例において、管理者端末１２０と顧客端末１３０は、デスクトップコンピュータ、ラップトップコンピュータ、タブレットＰＣ、携帯電話、スマートフォンなど有無線の通信が可能な多様な端末の形態として実現できる。

管理サーバ１１０は、管理対象サーバ１０，２０，３０，４０からデータを収集し、各管理対象サーバの現状を把握して管理し、これに関連する管理サービス統計データと管理サービスレポートを含む各種サーバ管理情報を管理者端末１２０と顧客端末１３０に提供する。

管理サーバ１１０は、複数の管理対象サーバからマルチベンダーのハードウェア情報を収集して保存し、保存した情報を照会して利用できるように管理者端末１２０及び顧客端末１３０に提供することができる。

管理サーバ１１０は、登録された複数の管理対象サーバからマルチベンダハードウェアインベントリ（ｍｕｌｔｉ－ｖｅｎｄｏｒ ｈａｒｄｗａｒｅ ｉｎｖｅｎｔｏｒｙ）情報を収集して保存することができる。

管理サーバ１１０は、緊急ファームウェアアップデートを含むファームウェアアップデートのイベントがある場合、全ての管理対象サーバに対してファームウェアアップデートを進めることができる。

管理サーバ１１０は、管理対象サーバのどの機器から障害が発生した場合、ログ及びパターンを分析し、分析したデータを保存し、障害が解決されれば、当該装備と類似の装備を分類し、分類された類似の装置に対して障害事前対応処理を実施することができる。

管理サーバ１１０は、Ｒｅｄｆｉｓｈ ＡＰＩを利用して各管理対象サーバのハードウェア詳細仕様、ＯＳ情報、ファームウェア情報、及びドライバー情報を含む運用中のｘ８６サーバに対する情報を収集することができ、ｘ８６サーバの標準化管理を行うことができる。

管理サーバ１１０は、管理対象サーバ１０、２０、３０、４０の障害パターンを分析して、類似の障害が発生することを予防する予防分析機能を提供し、予防分析機能を介して管理対象サーバ１０、２０、３０、４０で予め定められたイベントの発生時に、発生したイベントによる障害が発生する可能性があることを警告する予想障害発生メッセージを、該当管理対象サーバの管理を依頼した顧客端末に先制的に送信することができる。

管理サーバ１１０は、管理対象サーバ１０、２０、３０、４０の設置、障害、技術支援の履歴を管理する履歴管理機能を提供することができる。

管理サーバ１１０は、管理対象サーバ１０、２０、３０、４０の納品履歴を管理する納品管理機能を提供することができる。

管理サーバ１１０は、管理対象サーバで装備関連イベントが発生すると、あらかじめ定められた分類基準に従って危険装備を分類し、当該危険装備に対する警告メッセージを管理者端末１２０及び該当顧客端末に発送し、該当危険装備に対する事前障害対応措置を行うことができる。

管理サーバ１１０は、管理対象サーバで装備関連イベントが発生すると、当該装備の障害症状を把握し、当該障害症状に対応する障害コードに従って原因を分析し、障害対応方案を含むレポートを管理者端末１２０及び該当顧客端末に発送し、当該装備に対する障害対応措置を行うことができる。

本発明において、管理サーバ１１０は、顧客端末１３０の要求に応じて管理対象サーバの管理に関連するデータを加工して配信するデータ配信サービス（ｄａｔａ ｄｅｌｉｖｅｒｙ ｓｅｒｖｉｃｅ）機能を提供することができる。

また、管理サーバ１１０は、管理対象サーバのクリティカル障害を分析し、同一事例を伝播してサーバ障害を事前に予防することができ、四半期ごとに各サーバの障害統計を管理者端末１２０及び顧客端末１３０に提供することができる。

本発明において、管理サーバは、納品したサーバ関連装備に対する履歴を管理することができ、設置／障害／技術支援の履歴管理サービスを提供し、パーツ別の問題（ｉｓｓｕｅ）を管理することができる。

本発明は、顧客から依頼された複数の管理対象サーバ１０、２０、３０、４０を管理するサーバ管理システムに関するものである。

本発明の一実施例において管理対象となるサーバである管理対象サーバは、多様なサーバであってもよく、例えば、Ｄｅｌｌ（登録商標）サーバ１０、ＨＰ（登録商標）サーバ２０、Ｌｅｎｏｖｏ（登録商標）サーバ３０、Ｘ８６サーバ４０とできる。

管理対象サーバ１０、２０、３０、４０と管理サーバ１１０は、様々な有無線通信方式を介して通信し、例えばＨＴＴＰ通信やＪＳＯＮ形式のＰＯＳＴ伝送方式で通信することができる。

また、管理対象サーバ１０、２０、３０、４０は、大規模な電算環境の様々なｘ８６サーバで定められたスケジューリングに従ってスクリプトを自動実行することができる。

管理者は、管理者端末１２０を介して管理サーバ１１０に接続し、管理サーバ１１０に定められたスケジューリングに従ってバッチ（ＢＡＴＣＨ）プログラムを実行し、既存のデータと比較して変更履歴を管理する。

管理サーバ１１０は、自動的に管理対象サーバ１０、２０、３０、４０のハードウェア情報及びソフトウェア情報を収集し、これに基づいて各サーバの現況を把握し、各サーバの要求状況に応じた管理サービスを提供する。

管理サーバ１１０は、管理対象サーバのＢＢＵ（Ｂａｃｋｕｐ Ｂａｔｔｅｒｙ Ｕｎｉｔ）周期を点検し、あらかじめ決められた周期になると、この内容を該当管理対象サーバの顧客端末に伝送することができる。

また、管理サーバ１１０は、管理対象サーバのＢＢＵ充電容量を点検し、バッテリーの充電効率があらかじめ定められた数値の以下に減少すると、この内容を該当管理対象サーバの顧客端末に知らせることができる。例えば、管理サーバ１１０は、管理対象サーバのＢＢＵ充電容量を点検し、バッテリーの充電効率が４０％以下に減少すれば、その内容を該当管理対象サーバの顧客端末に知らせることができる。

管理サーバ１１０は、管理対象サーバのＢＢＵ残り容量を点検し、バッテリーの残り容量が予め定められた数値以下である場合、この内容を該当管理対象サーバの顧客端末に知らせることができる。例えば、管理サーバ１１０は、管理対象サーバのＢＢＵ残余容量を点検し、バッテリーの残量が１０％以下である場合、この内容を該当管理対象サーバの顧客端末に知らせることができる。

また、管理サーバ１１０は、管理対象サーバのＢＢＵ書き込みポリシー（Ｗｒｉｔｅ Ｐｏｌｉｃｙ）を点検し、書き込みポリシーが変更されると、この内容を該当管理対象サーバの顧客端末に知らせることができる。

本発明は、多数のサーバを統合して管理するサーバ統合管理システムに対するものであり、サーバの多様な機能を診断し、障害を予め予測して警告し、解決方法を一緒に提示する。本発明では、サーバの多様な機能のうち、ＢＢＵを例示して説明することにする。

Ｄｅｌｌ（登録商標）サーバを例にとると、ＲＡＩＤコントローラのバッテリー失敗（ｆａｉｌｕｒｅ）によるキャッシュ（ｃａｃｈｅ）データの損失を防止するために、ＢＢＵのバッテリーの状態点検および、先制的交換の進行が必要である。このために、Ｄｅｌｌ（登録商標）サーバのログ（ｌｏｇ）確認を通じて、バッテリー完全充電（Ｆｕｌｌ Ｃｈａｒｇｉｎｇ）率（％）を確認し、完全充電率が５０％未満の装備を確認し、バッテリー交換を進行する。３６ヶ月以降のバッテリー充電率は、約７０％前後で自然に減少し、これを考慮して約２０％程度の追加的な減少があるバッテリーに対して、充電率の不良と判定することができる。

本発明のサーバ統合管理システムは、ＢＢＵ周期点検、充電容量の点検、残余容量の点検、書き込みポリシー（Ｗｒｉｔｅ Ｐｏｌｉｃｙ）の点検を行い、これによりキャッシュデータの損失を防止し、バッテリー状態に対する危険因子を事前に防止することができる。

本発明のサーバ管理システムでは、あるイベントが発生した場合、当該イベントを通じてサーバに障害が発生する可能性があることを診断し、予め当該サーバのシステムに警告し、解決方法に関する情報を一緒に伝達する。これと関連して、サーバで発生するイベントは、非常に多様であり、以前になかったイベントが新たに発生する可能性もある。本発明では、このようなサーバで発生することができるイベントのうちいくつかのイベントを例示することにする。

１．ｉＤＲＡＣ７、バージョン１．５１．５１に適用された製品「Ｄｅｌｌ（登録商標） Ｒ７２０サーバ」でファン（ＦＡＮ）騒音（Ｒｅａｄｉｎｇ １２，０００ＲＰＭ以上）

これに対する解決方法としては、ｉＤＲＡＣ７１．４６．４５バージョンへのダウングレードすることを推奨する。

２．ラックＰＤＵ＃１及びＰＤＵ＃２で電力使用率がＰＤＵ＃１に傾く現象が発生

図２１を参照すれば、Ｄｅｌｌ（登録商標）サーバだけでなく、ＨＰ（登録商標）サーバも同様に、パワーサプライのデフォルトとして、アクティブスタンバイ（Ａｃｔｉｖｅ Ｓｔａｎｄｂｙ）で動作するように設定されており、これにより電力がラックＰＤＵの一方に集中する状況が発生し、バランスを合わせるためには、「Ｐｒｉｍａｒｙ－ＰＳＵ」の比率を合わせる必要がある。

３．Ｄｅｌｌ（登録商標）サーバ製品の第１２世代～第１４世代カーネルアップデート（ｋｅｒｎｅｌ ｕｐｄａｔｅ）後のＯＳの異常動作

このとき、管理サーバ１１０は、デル（Ｄｅｌｌ）（登録商標）サーバでカーネルアップデート後、ＯＳ上で異常動作が発見された場合、これにより発生し得る予想障害発生メッセージを該当管理対象サーバに送信し、これと共に予測障害の解決方法を該当管理対象サーバに伝達する。

４．ＴＣＰ／ＩＰポートの不足によるサービス不可

これは、Ｗｉｎｄｏｗｓ（登録商標）２００８でアップタイム（Ｕｐｔｉｍｅ）が４９７日以上の場合、ネットワークＴＩＭＥ＿ＷＡＩＴセッション（ｓｅｓｓｉｏｎ）がクローズできず残っている現象である。これにより、ポートを占有するようになり、それ以上のポートがない時に問題となる。Ｗｉｎｄｏｗｓ（登録商標）２００８サーバとＷｉｎｄｏｗｓ（登録商標）２０１２サーバが対象となり、アップデートされたパッチを除去することで障害を解決できる。

５．Ｗｉｎｄｏｗｓ（登録商標）２００３～２０２２のイベントログの発生

６．メモリの生産周期診断

これは、特定メモリの特定生産周期が不良であることを確認するものであり、障害対象は、第１３世代装備（Ｒ７３０、Ｒ９３０、Ｒ６３０）であり、障害ＯＳは「Ｗｉｎｄｏｗｓ（登録商標）２０１２Ｒ２サーバ」で「ＫＢ３０６４２０９ｈｏｔｆｉｘ」が含まれたサーバであり、解決方法は、該当ホットフィックスを除去することである。

本発明において、管理サーバ１１０は、管理対象サーバのメモリ生産周期を診断し、あらかじめ定められたメモリ生産周期を不良と判定し、この内容を該当管理対象サーバに知らせる。

７．「ＰＣＩｅ Ｔｙｐｅ」のＳＳＤを使用している場合、デバイス設定で応答が停止する現象

これに対する解決方法は、ＢＩＯＳ１．１．４を１．２．１０にアップデートすることである。

８．「１２Ｇサーバ」のＢＩＯＳアップデート後、温度センサーが正常に作動せず、警告音（Ａｌｅｒｔ＿）が発生し続ける問題

これに対する解決方法は、ＢＩＯＳ２．５．２バージョンを診断し、最新のファームウェアにアップデートすることである。

９．パッチのアップデート後、ＢＳＯＤ発生後にブート不可の現象

このイベントは、２０１４年８月の「Ｐａｔｃｈ Ｔｕｅｓｄａｙ Ｕｐｄａｔｅ」の「Ｗｉｎｄｏｗｓ（登録商標）エラー、ＫＢ２９８２７９１」による現象である。

障害対象は、「Ｗｉｎｄｏｗｓ（登録商標）２００８サーバ」であり、パッチアップデートを通じて障害を解決することができる。

１０．「Ｗｉｎｄｏｗｓ（登録商標）２０１２ Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒ」を使用したクライアントでＤＮＳ接続エラーが発生

サーバからドメインアカウントにログインする際、アカウントとパスワードが正常であるにもかかわらず、「ユーザー名、またはパスワードが正しくありません」というエラーが発生する。

「Ｗｉｎｄｏｗｓ（登録商標）Ｓｅｒｖｅｒ２００８Ｒ２／Ｗｉｎｄｏｗｓ（登録商標）７」から「ＤＥＳ－ＣＢＣ－ＭＤ５およびＤＥＳ－ＣＢＣ－ＣＲＣ暗号化」を使用せず、「ＡＥＳ２５６－ＣＴＳ－ＨＭＡＣ－ＳＨＡ１－９６、ＡＥＳ１２８－ＣＴＳ－ＨＭＡＣ－ＳＨＡ１－９６、ＲＣ４－ＨＭＡＣ暗号化」のみを使用するが、ＡＤサーバが「Ｗｉｎｄｏｗｓ（登録商標）Ｓｅｒｖｅｒ２０１２Ｒ２」であり、ドメインメンバー（Ｄｏｍａｉｎ Ｍｅｍｂｅｒ）が「Ｗｉｎｄｏｗｓ（登録商標）Ｓｅｒｖｅｒ２００８Ｒ２」または「Ｗｉｎｄｏｗｓ（登録商標）７」の場合、コンピュータのアカウントに対するパスワードの更新時に、ＡＥＳキーの生成が失敗するという製品上の問題により発生する現象である。

１１．「ＧＮＵ Ｂａｓｈ ４．３ Ｓｈｅｌｌ」に存在する脆弱性

「Ｂａｓｈ」の脆弱性を利用して、攻撃者は、ウェブサーバのコンテンツおよびコードの変更、ウェブサイトの変調、ユーザーデータの流出およびＤＤｏＳ攻撃の実行が可能であることが知られている。この他にも、ＳＳＨ、ＤＨＣＰプロトコル、などの多様な環境下での「Ｂａｓｈコードインジェクション」脆弱性攻撃のシナリオも提起されている状況である。

障害対象は、「ＲｅｄＨａｔ（登録商標） Ｅｎｔｅｒｐｒｉｓｅ Ｌｉｎｕｘ（登録商標） ５，６，７サーバ」であり、障害解決方法は、「Ｂａｓｈ」アップデートである。

１２．「ＧＮＵ Ｃ ライブラリ（ｇｌｉｂｃ）」のバッファオーバーフロー脆弱性

ネットワーク接続時によく使われる、「ｇｅｔｈｏｓｔｂｙｎａｍｅ（）」、「ｇｅｔｈｏｓｔｂｙｎａｍｅ２（）」関数の呼び出し時、脆弱な関数が呼び出される現象であり、外部の攻撃者は、脆弱なサーバで遠隔に任意のコードを実行することができる。

障害の対象は、「ＲｅｄＨａｔ（登録商標） Ｅｎｔｅｒｐｒｉｓｅ Ｌｉｎｕｘ（登録商標） ５，６，７サーバ」であり、障害解決方法は、ＧＬＩＢＣアップデートである。
１３．「ＲｅｄＨａｔ（登録商標） Ｖ５およびＶ６」系ＯＳのバグ。

「Ｉｎｔｅｌ（登録商標） ＣＰＵ」を使用する「ＲｅｄＨａｔ（登録商標） Ｅｎｔｅｒｐｒｉｓｅ Ｌｉｎｕｘ（登録商標） ６ｏｒ５」のすべてのバージョンで、２０８．５日以降に「Ｒｅｂｏｏｔ現象」が発生するバグである。

障害の対象は、「ＲｅｄＨａｔ（登録商標） Ｅｎｔｅｒｐｒｉｓｅ Ｌｉｎｕｘ（登録商標） ５，６サーバ」であり、障害解決方法は、カーネルアップデートである。

１４．レイドコントローラのバッテリーペール（Ｒａｉｄ Ｃｏｎｔｒｏｌｌｅｒ Ｂａｔｔｅｒｙ Ｆａｉｌ）

レイドコントローラキャッシュ（Ｒａｉｄ Ｃｏｎｔｒｏｌｌｅｒ Ｃａｃｈｅ）の使用不可によりＩ／Ｏ性能が低下する。障害の対象は、「Ｄｅｌｌ（登録商標） Ｐｅｒｃ ５ｉ、６ｉ」用の「Ｒａｉｄ Ｃｏｎｔｒｏｌｌｅｒ Ｂａｔｔｅｒｙ」であり、障害解決方法は、「Ｄｅｌｌ（登録商標） Ｐｅｒｃ ５ｉ、６ｉ」用の「Ｒａｉｄ Ｃｏｎｔｒｏｌｌｅｒ Ｂａｔｔｅｒｙ」の使用周期である４～５年ごとに事前交換することである。

１５．ＣＰＵ ＩＥＲＲ エラー発生によるシステムダウン（ＳＹＳＴＥＭ ＤＯＷＮ）。

障害の対象は、「Ｉｎｔｅｌ（登録商標） ｉＢｒｉｄｇｅ Ｖ２」使用ＣＰＵの使用サーバ（ＰＥ Ｒ７２０、ＰＥ Ｒ９２０）であり、障害解決方法は、ＢＩＯＳ設定（Ｓｅｔｔｉｎｇ）を変更することである。

例えば、システムプロファイル設定（Ｓｙｓｔｅｍ Ｐｒｏｆｉｌｅ Ｓｅｔｔｉｎｇｓ）を、システムプロファイルを「Ｃｕｓｔｏｍ」に設定し、ＣＰＵパワーマネジメント（Ｐｏｗｅｒ Ｍａｎａｇｅｍｅｎｔ）を「Ｍａｘｉｍｕｍ Ｐｅｒｆｏｒｍａｎｃｅ」とし、Ｃ１Ｅを「Ｄｉｓａｂｌｅｄ Ｃ Ｓｔａｔｅｓ Ｄｉｓａｂｌｅｄ」とし、「Ｍｏｎｉｔｏｒ／Ｍｗａｉｔ」を「Ｄｉｓａｂｌｅｄ」に設定する。

１６．ｉＤｒａｃ １．５０．５０ Ｆ／Ｗ（Ｆｉｒｍｗａｒｅ）（該当バージョン検索）使用時の管理ウェブ接続不可。

ｉＤｒａｃ Ｆ／Ｗ ＯＳ上でのＦ／Ｗアップグレードするか、日常生活でのメディアによるアップグレードを通じて、「１．５１．５１」にアップグレードする。

本発明は、マルチベンダーを支援するサーバ管理システムを提案する。例えば、本発明では、Ｄｅｌｌ（登録商標）、ＨＰ（登録商標）、Ｌｅｎｏｖｏ（登録商標）、などの３社のハードウェアシステムに関する情報を１つのインベントリ（Ｉｎｖｅｎｔｏｒｙ）に格納し、インベントリに格納された情報を用いてハードウェアに関する全ての情報を照会することができ、機能を活用できるように具現する。

本発明で説明の便宜のために、Ｄｅｌｌ（登録商標）、ＨＰ（登録商標）、Ｌｅｎｏｖｏ（登録商標）、などのメーカーを例示してマルチベンダーを支援するサーバ管理システムについて説明する。

図２は、本発明の一実施例によるサーバ管理システムにおいて、マルチベンダーを支援してサーバを管理する方法を例示するフローチャートである。図２において、各段階の実行主体は、管理サーバ１１０である。

図２を参照すれば、管理対象サーバを登録する（Ｓ２０１）。このとき、各サーバの管理ＩＰ情報を用いて対象サーバを登録することができる。たとえば、「Ｄｅｌｌ（登録商標）」の場合は「ｉＤＲＡＣ」、「ＨＰ（登録商標）」の場合は「ｉＬＯ」、「Ｌｅｎｏｖｏ（登録商標）」の場合は「ｉＭＭ」を使用して対象サーバを登録することができる。

次に、各サーバ別の接続の有無を把握し（Ｓ２０３）、マルチベンダハードウェアインベントリ情報を収集する（Ｓ２０５）。本発明の一実施例において、ハードウェア共通標準である「Ｒｅｄｆｉｓｈ ＡＰＩ」を使用して、メーカー区分なしに、ｘ８６サーバのハードウェアシステムに対するインベントリ情報を収集することができる。

そして、収集したインベントリ情報を保存する（Ｓ２０７）。

「緊急ファームウェアアップデート」を含むファームウェアアップデートイベントがある場合、全ての管理対象サーバに対してファームウェアアップデートを行う（Ｓ２０９）。そして、変更されたアップデート情報を確認する（Ｓ２１１）。本発明の一実施例では、「Ｒｅｄｆｉｓｈ ＡＰＩ」を通じてファームウェアアップデート情報を確認することができる。

そして、各サーバの安全度、点検対象かどうか、重要度、等に応じてグループを設定し（Ｓ２１５）、リアルタイムでサーバ情報を確認する（Ｓ２１７）。

このように、本発明の一実施例では、「Ｒｅｄｆｉｓｈ ＡＰＩ」を利用して各サーバのハードウェア詳細仕様、ＯＳ情報、ファームウェア情報、ドライバ情報、などの運営中のｘ８６サーバに関する様々な情報を収集することができ、ｘ８６サーバの標準化管理を行うことができる。

図３は、本発明の一実施例によるサーバ管理システムにおいて、障害ログおよびパターンを分析して障害を事前予防する方法を例示するフローチャートである。図３において、各ステップを行う主体は、管理サーバ１１０である。

図３を参照すれば、管理対象サーバのある装備で障害が発生すると（Ｓ４０１）、ログおよびパターンを分析する（Ｓ４０３）。そして、分析したデータを保存する（Ｓ４０５）。

障害が解決されると（Ｓ４０７）、該当装備と類似した装備を分類し（Ｓ４０９）、分類された類似装備に対して障害事前対応処理を実施する（Ｓ４１１）。

このように、本発明において障害発生時、ログおよびパターンを分析して自動的に類似装備を分類することにより、類似装備で発生する障害を事前に予防することができる。

図４は、本発明の一実施例によるサーバ管理システムで「Ｒｅｄｆｉｓｈ ＡＰＩ」を活用してマルチベンダーを支援する動作モデルを例示する図である。

図４に示すように、本発明では、「Ｒｅｄｆｉｓｈ ＡＰＩ」を利用して、Ｄｅｌｌ（登録商標）、ＨＰ（登録商標）、Ｌｅｎｏｖｏ（登録商標）、などのメーカーの区別なしに、ｘ８６サーバのハードウェアシステムに対するインベントリ情報を収集し、収集した情報を照会して活用することができる。例えば、「Ｄｅｌｌ（登録商標）」の場合は「ｉＤＲＡＣ」を使用してデータを収集し、「ＨＰ（登録商標）」の場合は「ｉＬＯ」を使用してデータを収集し、「Ｌｅｎｏｖｏ（登録商標）」の場合は「ｉＭＭ」を使用してデータを収集する。そして、「Ｒｅｄｆｉｓｈ ＡＰＩ」を利用して多数のサーバにＯＳやファームウェアを配布して設置することができる。

そして、本発明では、「Ｒｅｄｆｉｓｈ ＡＰＩ」を利用して各サーバのハードウェア仕様、ＯＳ情報、ファームウェア情報、などを迅速に確認することができる。

そして、本発明でパターンを分析して障害を予測することができ、ハードウェアログを利用してパターン分析を行うことができる。

「Ｒｅｄｆｉｓｈ ＡＰＩ」は、２０１５年に初めてリリースされて以来、継続的なアップデートが行われており、複数のサーバ製造ベンダー社を支援し、「ＩＰＭＩ」と同じ機能を提供している。また、「Ｒｅｄｆｉｓｈ ＡＰＩ」は、「ＢＩＯＳ」と「Ｓｅｃｕｒｅ Ｂｏｏｔ」設定機能を、ファームウェアアップデート機能、ストレージとサーバのネットワーキング設定機能を支援する。そして、「Ｏｐｅｎ Ｃｏｍｐｕｔｅ Ｐｌａｔｆｏｒｍ」、「Ｏｐｅｎ ｓｔａｃｋ」、「ＳＮＩＡ（Ｓｔｏｒａｇｅ Ｎｅｔｗｏｒｋｉｎｇ Ｉｎｄｕｓｔｒｙ Ａｓｓｏｃｉａｔｉｏｎ）」、などを支援し、ネットワークスイッチマネジメント、外付けストレージマネジメント、などを支援する。

パワーエッジ（Ｐｏｗｅｒ Ｅｄｇｅ）サーバの管理ツールである「ｉＤＲＡＣ」は、「Ｒｅｄｆｉｓｈ」を活用して「Ｒｅｄｆｉｓｈ ＲＥＳＴｆｕｌ ＡＰＩ」を支援する。例えば、「ｉＤＲＡＣ」は、サーバ電源（「Ｒｅｓｅｔ」、「Ｒｅｂｏｏｔ」、「Ｐｏｗｅｒ Ｃｏｎｔｒｏｌ」）、サーバハードウェアインベントリ、サーバモニタリング、および状態チェック、システムログ収集、サーバの状態変化チェック、およびアラームを行うことができる。
パワーエッジサーバは、「Ｒｅｄｆｉｓｈ」を通じてサーバの初期設定を自動化することができる。そして、「ｉＤＲＡＣ」初期設定、ＢＩＯＳ、ＲＡＩＤコントローラ、ネットワークカード、などの様々な構成情報をテンプレート化してサーバの自動化配布を行うことができる。

パワーエッジサーバの「ｉＤＲＡＣ」における「Ｒｅｄｆｉｓｈ」活用例の中で、サーバ構成自動化（Ａｕｔｏ ｄｅｐｌｏｙｍｅｎｔ）を例示すると、次のようになる。サーバが持つ固有の設定値は、「ＳＣＰ（Ｓｅｒｖｅｒ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｐｒｏｆｉｌｅ）」のメタデータとして保存され、これは「Ｒｅｄｆｉｓｈ ＡＰＩ」で構成できる。また、「Ｒｅｄｆｉｓｈ ＡＰＩ」を通じて「ＢＩＯＳ」、「ｉＤＲＡＣ／ＬＣ」、「ＰＥＲＣ ＲＡＩＤ Ｃｏｎｔｒｏｌｌｅｒ」、「ＮＩＣ」、「ＨＢＡ」、などの各種設定情報を設定することができる。「ＳＣＰ」は、「Ｅｘｐｏｒｔ、Ｐｒｅｖｉｅｗ、Ｉｍｐｏｒｔ」が可能で、新しく構築されるサーバに構成情報を自由に適用することができる。「ＳＣＰ」は、「ＨＴＴＳ」、「ＮＦＳ」、「ＣＩＦＳ」、などの方式で共有でき、「ＸＭＬ」や「ＪＳＯＮ」のファイル形式などで具現できる。

図５～図１８は、本発明の一実施例によるサーバ管理システムの画面例を示す。

図５は、初期画面例であり、管理対象サーバに対して自動的に収集したインベントリ及びログに関する情報を一目で見ることができるようにダッシュボードを介して支援する画面例である。

図６は、管理対象サーバのインベントリ情報をリアルタイムで確認できる画面例であり、この画面例で変更された情報に対しても自動的にインベントリ情報が変更される。

図７の画面例では、管理対象サーバの問題が確認される時に、分かりやすく各パート別に赤色
で表示され、正常なパートは緑色
で表示される。

図８は、ファームウェア情報を含む全体管理対象サーバのリアルタイムマネジメント情報を確認できる画面例である。

図９は、全体管理対象サーバのリアルタイムＣＰＵ詳細情報及び現在の状態を確認できる画面例である。

図１０は、全体管理対象サーバのリアルタイムメモリ詳細情報および現在の状態を確認できる画面例である。

図１１は、全体管理対象サーバのリアルタイム「Ｒａｉｄ Ｃｏｎｔｒｏｌｌｅｒ」の詳細情報及び現在の状態を確認できる画面例である。

図１２は、全体管理対象サーバのリアルタイムディスク詳細情報及び現在の状態を確認できる画面例である。

図１３は、全体管理対象サーバのＰＳＵのリアルタイム詳細情報および現在の状態を確認できる画面例である。

図１４及び図１５は、全体管理対象サーバの収集ログに関するリアルタイム詳細情報を確認できる画面例であり、リアルタイム「Ｖｅｎｄｏｒ ＨＷ」エラーコードを収集して自動的に分類し、エラーコード別問題装備の確認が可能である。

図１６は、障害分析画面例であり、障害原因、結論、交換時期を含む障害分析情報が表示されている。

図１７は、顧客社と比較した各サーバ別障害分析分布図を例示する画面例である。

図１８は、サービスレポート機能を例示した画面例であり、発生時期、 問題の事項、問題解決、及び再発防止措置事項を含むレポート内容が例示されている。

図１９は、本発明の一実施例によるシステム装備を分類した図表であり、図２０及び図２１は、本発明の一実施例によるハードウェアの症状及びその原因を記載した図表である。

図２２～図２３は、本発明の一実施例によるサーバ管理システムにおける障害事前対応方法を示すフローチャートである。

図２２を参照すれば、管理サーバ１１０は、管理対象サーバでハードウェア関連の問題が発生すると（Ｓ１０１）、図１９の分類表を参照して、障害発生の可能性が高い類似装備を危険装備に分類する（Ｓ１０３）。

そして、分類された危険装備に対する警告メッセージを発送し（Ｓ１０５）、障害事前対応措置を行う（Ｓ１０７）。

図１９の分類表を参照すれば、本発明の一実施例におけるシステム装備の具体的な類似判断基準が例示されており、 同じクラスの装備の分類、同一ＣＰＵ装備の分類、同一メモリ装備の分類、同一ＮＩＣ装備の分類、同一ディスク装備の分類、同一ＨＢＡ装備の分類、同一ＢＩＯＳ装備の分類、同一ドライバーバージョン装備の分類、同一ＯＳ装備の分類、同一ファームウェアバージョン装備の分類、などが例示されている。

図２３を参照すれば、管理サーバ１１０は、管理対象サーバでハードウェア関連の問題が発生すると（Ｓ３０１）、障害の症状を把握する（Ｓ３０３）。

そして、図２０及び図２１の図表を参照して障害症状に応じた症状コードを確認する（Ｓ３０５）。また、症状コードに対応する原因を確認し（Ｓ３０７）、それに応じて対応策レポートを発送する（Ｓ３０９）。また、障害原因に対応する障害対応措置を行う（Ｓ３１１）。

Ｓ３０５段階で障害症状に対応する症状コードがない場合、新たな症状コードを生成し、図２０及び図２１のリストに追加する（Ｓ３１３）。

図２０及び図２１を参照すれば、本発明の一実施例による障害症状別症状コードに対応する障害原因が例示されている。すなわち、「ＲＡＣ１１９８」はｉＤｒａｃファームウェアの問題、「コネクタブルメモリ障害」はメモリの問題及びバイオスファームウェアの問題、「ＬｉｎｋＦａｉｌｕｒｅの発生」はＮＩＣ障害及びファームウェアの問題、「ＬｉｎｋＦａｉｌｕｒｅＣｏｕｎｔの多数発生」はＮＩＣドライバー及びファームウェアの問題、「ＮＩＣ Ｌｉｎｋ ｉｓ Ｄｏｗｎ」はＮＩＣドライバー及びファームウェアの問題、Ｌｉｎｋの状態及びサーバの点検要請はＮＩＣドライバー及びファームウェアの問題、 「ＨＯＳＴ＿ＤＯＷＮ」の発生はＮＩＣドライバー及びファームウェアの問題、「サーバ前面の黄色点灯」の発生はｉＤｒａｃファームウェアの問題、「ＳＷＣ５００８：ｃｒｉｔｉｃａｌメッセージ」の出力はｉＤｒａｃファームウェアの問題、「ＮＯ＿ＰＡＲＴＩＴＩＯＮ」アラームの発生はディスクの障害、「Ｒｅｓｅｔ ａｄａｐｔｅ」はＢＩＯＳファームウェアの問題、「Ｃｏｒｒｅｃｔａｂｌｅ ｍｅｍｏｒｙ ｅｒｒｏｒ」はメモリの問題およびＢＩＯＳファームウェアの問題、「ＣＰＵの性能低下」はＢＩＯＳファームウェアの問題、「ＭｅｍｏｒｙおよびＳｌｏｔが表示されない」はメモリの問題およびＢＩＯＳファームウェアの問題、「Ｄｉｓｋ ｆａｕｌｔ ｅｒｒｏｒ」はディスクの障害、「ｄｉｓｋ ｐｒｅｄｉｃｔｅｄ ｆａｉｌ」は「ディスクのＢａｄＢｌｏｃｋ」による障害、「周期的なＦＡＮ６の認識問題」はＦａｎ６の障害、「光量４００以下によるＦａｕｌｔ」はＧｂｉｃの障害、「ＮＩＣ ＧＢＩＣ 通信不可」はＧｂｉｃの障害、「システムの無限リブート」はＢＩＯＳファームウェアの問題、「ＬＣＤパネルでの特定のメッセージ出力」はｉＤｒａｃファームウェアの問題、「ｉＤＲＡＣで繰り返しエラーメッセージの発生」はｉＤｒａｃファームウェアの問題、「ｖＣｅｎｔｅｒエージェントと同期化エラー」はＥＸＳｉバージョンとＯＳバージョンの問題、「サーバＲｅｂｏｏｔ現象」はＢＩＯＳファームウェアの問題、「ＨＢＡ Ｗｒｉｔｅの速度低下」はＨＢＡファームウェアとドライバーの問題、「ＨＢＡ Ｒｅａｄの速度低下」はＨＢＡファームウェアとドライバーの問題、「ＨＢＡ Ｌｉｎｋ Ｄｏｗｎ」はＨＢＡ Ｇｂｉｃ及びカードの問題、「ＨＢＡ二重化の節体障害」は「ＨＢＡ Ｇｂｉｃ」及びカードの問題、「Ｒｉｓｅｒ１の認識不良」は「Ｒｉｓｅｒ Ｃａｒｄ」の問題、「Ｒｉｓｅｒ２の認識不良」は「Ｒｉｓｅｒ Ｃａｒｄ」の問題、「ネットワーク二重化の障害」はネットワークカードの問題、「ＰＳＵ Ａｌｅｒｔの黄色ＬＥＤの点灯」はＰＳＵの障害、「低電圧による異常発生」はＰＳＵの障害、「ＰＸＥブート不可」はＢＩＯＳ設定およびＮＩＣファームウェア／ドライバーの問題、「ＰＯＳＴブート不可」はマザーボードの障害、「ＬｉｆｅＣｙｃｌｅ接続不可」はマザーボードの障害、「ｉＤＲＡＣ Ｈａｎｇの症状」はｉＤｒａｃファームウェアの問題、「ｉＤＲＡＣネットワークの切断」はマザーボードの障害とｉＤｒａｃのファームウェアの問題、「ｉＤＲＡＣ ＳＮＭＰサービスの障害の発生」はｉＤｒａｃのファームウェアの問題、「サーバの使用中に突然サーバが切れる症状」はマザーボードの問題、「Ｍｅｄｉｕｍ Ｅｒｏｒの発生」はディスクの障害、「ＥＲＲＯＲ Ｅｖｅｎｔ」の確認要請はエラーイベントによる問題、「ＣＭＣ接続不可」はＣＭＣファームウェアの問題、が原因で対応される。

そして、「ＤＳＥＴ分析要求」は分析による障害、「ＴＳＲ Ｌｏｇ」分析要求は分析による障害、「ＮＦＳサービスの起動失敗」はＮＦＳ設定とＯＳ設定の点検、「ｖＣｅｎｔｅｒ接続不可」はＥＸＳｉのバージョンとＯＳバージョンの問題、「ＮＩＣ Ｒｅｓｅｔ」は「Ｎｅｔｗｏｒｋ Ｃａｒｄ」の問題、「ＧＰＵ認識不可」は「ＧＰＵ Ｃａｒｄ」の障害、「ＯＳ Ｃｒａｓｈ」の発生は「ＯＳ Ｄｕｍｐ」の分析、「Ｎｅｔｗｏｒｋ ｅｒｒｏｒ／ｄｒｏｐｐｅｄ ｐａｃｋｅｔｓ」の発生はネットワークカードの問題、「ＣＲＣエラーの発生」はネットワークカードの問題、「サーバ―スイッチの切れた現象」はネットワークカードの問題、「Ｎｅｔｗｏｒｋ（Ｂｏｎｄｉｎｇ）に通信が円滑でない」はネットワークカードの問題、「メモリ交換後の同一スロットイベントの発生」はメモリの障害またはマザーボードの障害、「「Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ」状態でアクセス不可」はディスクの障害またはＲＡＩＤ構成の問題、「スイッチの１ヶ月に３～４回の「Ｈａｎｇ」症状」はマザーボードまたはＯＳバージョンの問題、「「ＬＡＣＰ Ｎｅｔｗｏｒｋ Ｓｐｅｅｄ」の問題が発生する」のはネットワークカードの問題、「クラスタフェイルオーバーの発生」はクラスタ設定の問題、またはＨＷの障害、「ＲＴＳＰ同期化の失敗」はＯＳ設定またはネットワークの障害、「セッション低下現象の発生」はネットワークカードまたはＧｂｉｃの問題、「不明な電源遮断」はＰＳＵ障害、サーバが遅い及び「Ｈａｎｇ」現象はアプリケーションまたはＨＷの障害、「Ｎｅｔｗｏｒｋ Ｐｉｎｇ Ｌｏｓｓ」はネットワークカードまたはＧｂｉｃの問題、「Ｌｏａｄ Ａｖｇ」の上昇はＣＰＵ点検の必要、「Ｆａｔａｌ Ｅｒｒｏｒ」の発生は「ＰＣＩ Ｃａｒｄ」または「Ｒｉｓｅｒ Ｃａｒｄ」の問題、「ＰＸＥインストール中の停止またはパフォーマンスの低下」はネットワークカードまたはＧｂｉｃの問題、「Ｂｌｕｅ Ｓｃｒｅｅｎの発生（０ｘ００００４ｆ）」はマザーボード／バイオス／ディスク／メモリの障害、「Ｂｌｕｅ Ｓｃｒｅｅｎ」はマザーボード／バイオス／ディスクの障害、「ＯＳ Ｂｏｏｔｉｎｇ」の失敗はマザーボード／バイオス／ディスクの障害、「プロセスＤｏｗｎおよびＯＳのインストール中のパニック」はマザーボード／バイオス／ディスクの障害、「サーバからの臭い」はファン／マザーボード／ＰＳＵの問題、「ＮＡＳ接続不可措置」はネットワーク／ＯＳ設定の問題、「ＫＶＭ接続不可」はマザーボード／ＫＶＭケーブル／ＫＶＭの問題、「ＤｉｓｋＡｍｂｅｒＬＥＤ」はディスクの障害、「Ｐｏｓｔブーテイング時のＤｅｌａｙ」はマザーボード／ファン／ＰＣＩ／メモリの問題、「電源供給不良措置」はＰＳＵの障害、「Ｔｅａｍｉｎｇ性能低下」はネットワーク／ＯＳ設定の問題、「ＶＤ Ｂａｄ Ｂｌｏｃｋ」はディスクの障害、「ＨＢＡＬｏｏｐ」はＨＢＡの障害、「Ｒａｉｄ構成情報が見えない」のはファームウェア／ディスクドライバーの問題、「Ｖｏｌｕｍｅ認識不可」はファームウェア／ディスクドライバーの問題、「Ｋｅｒｎｅｌ Ｐａｎｉｃ」はＯＳ／Ａｐｐの問題、「最大性能使用時のサーバリブート（ｒｅｂｏｏｔ）」はＣＰＵ／ＰＳＵ／マザーボード／メモリの問題、「サーバ処理速度が著しく遅くなる」のはＣＰＵ／ＰＳＵ／マザーボード／メモリ／ディスクの問題、「サーバ電源が入らない」はＰＳＵの障害、が原因で対応する。

以上、本発明をいくつかの望ましい実施例を用いて説明したが、これらの実施例は例示的なものであり、限定的なものではない。本発明が属する技術分野で通常の知識を持つ者なら、本発明の思想と添付された特許請求範囲に提示された権利範囲から抜け出せずに多様な変化と修正を加えることができることを理解することができる。

１１０ 管理サーバ
１２０ 管理者端末
１３０ 顧客端末
１０、２０、３０、４０ 管理対象サーバ

Claims (1)

1. マルチベンダーを支援するサーバ管理システムにおいて、
   前記サーバ管理システムを管理する管理者が使用する管理者端末と、
   管理対象サーバを依頼した各顧客が使用する顧客端末と、
   前記管理対象サーバからデータを収集し、各管理対象サーバの現況を把握して管理し、これに関連した管理サービス統計データと管理サービスレポートを含む各種サーバ管理情報を前記管理者端末と前記顧客端末に提供する管理サーバと、を含み、
   前記管理サーバは、複数の管理対象サーバからマルチベンダハードウェア情報を収集して保存し、保存した情報を照会して利用できるように、前記管理者端末および前記顧客端末に提供し、
   前記管理サーバは、管理対象サーバのＢＢＵ（Ｂａｃｋｕｐ Ｂａｔｔｅｒｙ Ｕｎｉｔ）周期を点検し、あらかじめ決められた周期になると、この内容を該当管理対象サーバの顧客端末に伝送し、
   前記管理サーバは、管理対象サーバのＢＢＵ充電容量を点検し、バッテリーの充電効率があらかじめ定められた数値の以下に減少すると、この内容を該当管理対象サーバの顧客端末に知らせ、
   前記管理サーバは、管理対象サーバのＢＢＵ残り容量を点検し、バッテリーの残り容量が予め定められた数値以下である場合、この内容を該当管理対象サーバの顧客端末に知らせ、
   前記管理サーバは、管理対象サーバのＢＢＵ書き込みポリシー（Ｗｒｉｔｅ Ｐｏｌｉｃｙ）を点検し、書き込みポリシーが変更されると、この内容を該当管理対象サーバの顧客端末に知らせ、
   前記管理サーバは、管理対象サーバのログ（ｌｏｇ）確認を通じて、バッテリー完全充電（Ｆｕｌｌ Ｃｈａｒｇｉｎｇ）効率（％）を確認し、完全充電効率が予め定められた数値未満の装備に対するバッテリーの交換を知らせるメッセージを該当管理対象サーバの顧客端末に知らせ、
   前記管理サーバは、各管理対象サーバからマルチベンダハードウェアインベントリ情報を収集して保存し、緊急ファームウェアのアップデートを含むファームウェアのアップデートイベントがあると、すべての管理対象サーバに対してファームウェアアップデートを行い、ファームウェアアップデート後に変更されたアップデート情報を確認し、各管理対象サーバの安全度、点検対象有無、重要度に応じてグループを設定し、リアルタイムでサーバ情報を確認し、
   前記管理サーバは、管理対象サーバのある装備で障害が発生すると、ログおよびパターンを分析し、分析したデータを保存し、障害が解決されると、該当装備と類似した装備を分類し、分類された類似装備に対して障害事前対応処理を実施し、
   前記管理サーバは、ハードウェア共通標準であるＲＥＳＴｆｕｌ ＡＰＩを利用して各管理対象サーバのハードウェア詳細仕様、ＯＳ（Ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）の情報、ファームウェアの情報及びドライバーの情報を含む運用中のｘ８６サーバに対する情報を収集することができ、ｘ８６サーバの標準化管理を行い、
   前記管理サーバは、管理対象サーバでハードウェア関連の問題が発生すると、分類表を参照して障害発生可能性が高い類似装備を危険装備に分類し、分類された危険装備に対する警告メッセージを発送し、事前障害対応措置を行い、
   この時、前記分類表は、システム装備の具体的な類似判断基準を含み、同じクラスの装備の分類、同一ＣＰＵ装備の分類、同一メモリ装備の分類、同一ＮＩＣ装備の分類、同一ディスク装備の分類、同一ＨＢＡ装備の分類、同一ＢＩＯＳ装備の分類、同一ドライバーバージョン装備の分類、同一ＯＳ装備の分類、同一ファームウェアバージョン装備の分類を含み、
   前記管理サーバは、管理対象サーバで ハードウェア関連の問題が発生すると、 障害症状を把握し、 障害症状ごとの症状コードに対応する障害原因を含むリストを参照し、障害症状に応じた症状コードを確認し、症状コードに対応する原因を確認し、それに応じて対応策レポートを送信し、障害原因に対応する障害対応措置を行い、障害症状に対応する症状コードがない場合は、新たな症状コードを生成して前記リストに追加し、
   このとき、前記リストにおいて、「ＲＡＣ１１９８」はｉＤｒａｃファームウェアの問題、「コネクタブルメモリ障害」はメモリの問題及びバイオスファームウェアの問題、「ＬｉｎｋＦａｉｌｕｒｅの発生」はＮＩＣ障害及びファームウェアの問題、「ＬｉｎｋＦａｉｌｕｒｅＣｏｕｎｔの多数発生」はＮＩＣドライバー及びファームウェアの問題、「ＮＩＣ Ｌｉｎｋ ｉｓ Ｄｏｗｎ」はＮＩＣドライバー及びファームウェアの問題、「Ｌｉｎｋの状態及びサーバの点検要請」はＮＩＣドライバー及びファームウェアの問題、「ＨＯＳＴ＿ＤＯＷＮの発生」はＮＩＣドライバー及びファームウェアの問題、「サーバ前面の黄色点灯の発生」はｉＤｒａｃファームウェアの問題、「ＳＷＣ５００８：ｃｒｉｔｉｃａｌメッセージの出力」はｉＤｒａｃファームウェアの問題、「ＮＯ＿ＰＡＲＴＩＴＩＯＮアラームの発生」はディスクの障害、「Ｒｅｓｅｔ ａｄａｐｔｅ」はＢＩＯＳファームウェアの問題、「Ｃｏｒｒｅｃｔａｂｌｅ ｍｅｍｏｒｙ ｅｒｒｏｒ」はメモリの問題およびＢＩＯＳファームウェアの問題、「ＣＰＵの性能低下」はＢＩＯＳファームウェアの問題、「ＭｅｍｏｒｙおよびＳｌｏｔが表示されない」はメモリの問題およびＢＩＯＳファームウェアの問題、「Ｄｉｓｋ ｆａｕｌｔ ｅｒｒｏｒ」はディスクの障害、「ｄｉｓｋ ｐｒｅｄｉｃｔｅｄ ｆａｉｌ」は「ディスクのＢａｄＢｌｏｃｋ」による障害、「周期的なＦＡＮ６の認識問題」はＦａｎ６の障害、「光量４００以下によるＦａｕｌｔ」はＧｂｉｃの障害、「ＮＩＣ ＧＢＩＣ 通信不可」はＧｂｉｃの障害、「システムの無限リブート」はＢＩＯＳファームウェアの問題、「ＬＣＤパネルでの特定のメッセージ出力」はｉＤｒａｃファームウェアの問題、「ｉＤＲＡＣで繰り返しエラーメッセージの発生」はｉＤｒａｃファームウェアの問題、「サーバＲｅｂｏｏｔ現象」はＢＩＯＳファームウェアの問題、「ＨＢＡ Ｗｒｉｔｅの速度低下」はＨＢＡファームウェアとドライバーの問題、「ＨＢＡ Ｒｅａｄの速度低下」はＨＢＡファームウェアとドライバーの問題、「ＨＢＡ Ｌｉｎｋ Ｄｏｗｎ」はＨＢＡ Ｇｂｉｃ及びカードの問題、「ＨＢＡ二重化の節体障害」は「ＨＢＡ Ｇｂｉｃ」及びカードの問題、「Ｒｉｓｅｒ１の認識不良」は「Ｒｉｓｅｒ Ｃａｒｄ」の問題、「Ｒｉｓｅｒ２の認識不良」は「Ｒｉｓｅｒ Ｃａｒｄ」の問題、「ネットワーク二重化の障害」はネットワークカードの問題、「ＰＳＵ Ａｌｅｒｔの黄色ＬＥＤの点灯」はＰＳＵの障害、「低電圧による異常発生」はＰＳＵの障害、「ＰＸＥブート不可」はＢＩＯＳ設定およびＮＩＣファームウェア／ドライバーの問題、「ＰＯＳＴブート不可」はマザーボードの障害、「ＬｉｆｅＣｙｃｌｅ接続不可」はマザーボードの障害、「ｉＤＲＡＣ Ｈａｎｇの症状」はｉＤｒａｃファームウェアの問題、「ｉＤＲＡＣネットワークの切断」はマザーボードの障害とｉＤｒａｃのファームウェアの問題、「ｉＤＲＡＣ ＳＮＭＰサービスの障害の発生」はｉＤｒａｃのファームウェアの問題、「サーバの使用中に突然サーバが切れる症状」はマザーボードの問題、「Ｍｅｄｉｕｍ Ｅｒｏｒの発生」はディスクの障害、「ＥＲＲＯＲ Ｅｖｅｎｔ」の確認要請はエラーイベントによる問題、「ＣＭＣ接続不可」はＣＭＣファームウェアの問題、「ＤＳＥＴ分析要求」は分析による障害、「ＴＳＲ Ｌｏｇ」分析要求は分析による障害、「ＮＦＳサービスの起動失敗」はＮＦＳ設定とＯＳ設定の点検、「ＮＩＣ Ｒｅｓｅｔ」は「Ｎｅｔｗｏｒｋ Ｃａｒｄ」の問題、「ＧＰＵ認識不可」は「ＧＰＵ Ｃａｒｄ」の障害、「ＯＳ Ｃｒａｓｈ」の発生は「ＯＳ Ｄｕｍｐ」の分析、「Ｎｅｔｗｏｒｋ ｅｒｒｏｒ／ｄｒｏｐｐｅｄ ｐａｃｋｅｔｓ」の発生はネットワークカードの問題、「ＣＲＣエラーの発生」はネットワークカードの問題、「サーバ―スイッチの切れた現象」はネットワークカードの問題、「Ｎｅｔｗｏｒｋ（Ｂｏｎｄｉｎｇ）に通信が円滑でない問題」はネットワークカードの問題、「メモリ交換後の同一スロットイベントの発生」はメモリの障害またはマザーボードの障害、「「Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ」状態でアクセス不可」はディスクの障害またはＲＡＩＤ構成の問題、「スイッチの１ヶ月に３～４回の「Ｈａｎｇ」症状」はマザーボードまたはＯＳバージョンの問題、「「ＬＡＣＰ Ｎｅｔｗｏｒｋ Ｓｐｅｅｄ」の問題が発生する」のはネットワークカードの問題、「クラスタフェイルオーバーの発生」はクラスタ設定の問題、またはＨＷの障害、「ＲＴＳＰ同期化の失敗」はＯＳ設定またはネットワークの障害、「セッション低下現象の発生」はネットワークカードまたはＧｂｉｃの問題、「不明な電源遮断」はＰＳＵ障害、サーバが遅い及び「Ｈａｎｇ」現象はアプリケーションまたはＨＷの障害、「Ｎｅｔｗｏｒｋ Ｐｉｎｇ Ｌｏｓｓ」はネットワークカードまたはＧｂｉｃの問題、「Ｌｏａｄ Ａｖｇ」の上昇はＣＰＵ点検の必要、「Ｆａｔａｌ Ｅｒｒｏｒ」の発生は「ＰＣＩ Ｃａｒｄ」または「Ｒｉｓｅｒ Ｃａｒｄ」の問題、「ＰＸＥインストール中の停止またはパフォーマンスの低下」はネットワークカードまたはＧｂｉｃの問題、「Ｂｌｕｅ Ｓｃｒｅｅｎの発生（０ｘ００００４ｆ）」はマザーボード／バイオス／ディスク／メモリの障害、「Ｂｌｕｅ Ｓｃｒｅｅｎ」はマザーボード／バイオス／ディスクの障害、「ＯＳ Ｂｏｏｔｉｎｇ」の失敗はマザーボード／バイオス／ディスクの障害、「プロセスＤｏｗｎおよびＯＳのインストール中のパニック」はマザーボード／バイオス／ディスクの障害、「サーバからの臭い」はファン／マザーボード／ＰＳＵの問題、「ＮＡＳ接続不可措置」はネットワーク／ＯＳ設定の問題、「ＫＶＭ接続不可」はマザーボード／ＫＶＭケーブル／ＫＶＭの問題、「ＤｉｓｋＡｍｂｅｒＬＥＤ」はディスクの障害、「Ｐｏｓｔブーテイング時のＤｅｌａｙ」はマザーボード／ファン／ＰＣＩ／メモリの問題、「電源供給不良措置」はＰＳＵの障害、「Ｔｅａｍｉｎｇ性能低下」はネットワーク／ＯＳ設定の問題、「ＶＤ Ｂａｄ Ｂｌｏｃｋ」はディスクの障害、「ＨＢＡＬｏｏｐ」はＨＢＡの障害、「Ｒａｉｄ構成情報が見えない」のはファームウェア／ディスクドライバーの問題、「Ｖｏｌｕｍｅ認識不可」はファームウェア／ディスクドライバーの問題、「Ｋｅｒｎｅｌ Ｐａｎｉｃ」はＯＳ／Ａｐｐの問題、「最大性能使用時のサーバリブート（ｒｅｂｏｏｔ）」はＣＰＵ／ＰＳＵ／マザーボード／メモリの問題、「サーバ処理速度が著しく遅くなる」のはＣＰＵ／ＰＳＵ／マザーボード／メモリ／ディスクの問題、「サーバ電源が入らない」はＰＳＵの障害、が原因で対応する、ことを特徴とするサーバ管理システム。