特許ウォッチ

公開番号2024156644
公報種別公開特許公報(A)
公開日2024-11-06
出願番号2024070587
出願日2024-04-24
発明の名称ITリソース管理システムでサーバーを管理する方法
出願人ジニエイアイカンパニーリミテッド,GeniAI CO., LTD
代理人個人
主分類G06F 11/30 20060101AFI20241029BHJP(計算;計数)
要約【課題】サーバーで発生する可能性のある障害を予め防止し、サーバー障害による被害を低減する方法を提供する。
【解決手段】2以上の管理対象サーバーを含むITリソースを管理するためのITリソース管理システムにおける管理方法は、管理サーバー110において、管理対象サーバー10～40からハードウェア関連データおよびソフトウェア関連データを収集するステップと、管理サーバーから収集したデータに基づいて、各管理対象サーバーの現状を把握して管理し、これに関連する管理サービス統計データと管理サービスレポートを含む各種サーバー管理情報を、管理者端末120と、顧客端末130と、に提供するステップと、を含む。
【選択図】図1
特許請求の範囲【請求項１】
２以上の管理対象サーバーを含むＩＴリソースを管理するためのＩＴリソース管理システムにおけるサーバー管理方法において、
管理サーバーにおいて、管理対象サーバーからハードウェア関連データおよびソフトウェア関連データを収集するステップと、
前記管理サーバーから収集したデータに基づいて、各管理対象サーバーの現状を把握して管理し、これに関連する管理サービス統計データと管理サービスレポートを含む各種サーバー管理情報を管理者端末と顧客端末に提供するステップと、
を含むサーバー管理方法。
続きを表示（約 3,700 文字）【請求項２】
請求項１に記載のサーバー管理方法において、
前記管理サーバーが、各管理対象サーバーから収集されたＯＳ、ＢＩＯＳ、ファームウェアを含む情報を記憶するステップと、
前記管理サーバーが、緊急ファームウェアアップデートを含むファームウェアアップデートイベントが発生した場合、対応する管理対象サーバーにファームウェアを配布するステップと、
前記管理サーバーが、管理対象サーバーのファームウェア情報を点検し、ファームウェアのアップデートが完了したかどうかを確認するステップと、
をさらに含むサーバー管理方法。
【請求項３】
請求項２に記載のサーバー管理方法において、
前記管理サーバーは、Redfish APIを利用して、各管理対象サーバーのハードウェア詳細仕様、OS（Operating system）情報、ファームウェア情報及びドライバー情報を含む運営中のx86サーバーに関する情報を収集し、x86サーバーの標準化管理を行う、サーバー管理方法。
【請求項４】
請求項１に記載のサーバー管理方法において、
前記管理サーバーは、管理対象サーバーのＢＢＵ（Backup Battery Unit）周期を確認し、予め定められた周期になると、この内容を該当管理対象サーバーの顧客端末に転送し、
管理対象サーバーのＢＢＵ充電容量を点検し、バッテリの充電効率が予め定められた数値以下に減少すると、この内容を該当管理対象サーバーの顧客端末に通知し、
管理対象サーバーのＢＢＵ残容量を点検し、バッテリの残量が予め定められた数値以下である場合、この内容を該当管理対象サーバーの顧客端末に通知し、
管理対象サーバーのＢＢＵ書き込みポリシー（ＷｒｉｔｅＰｏｌｉｃｙ）を点検し、書き込みポリシーが変更されると、この内容を該当管理対象サーバーの顧客端末に通知し、
管理対象サーバーのログ（log）確認を通じて、バッテリーフル充電（Full Charging）効率（％）を確認し、完全充電効率が予め定められた数値未満の装備に対するバッテリ交替を通知するメッセージを該当管理対象サーバーの顧客端末に通知する、
サーバー管理方法。
【請求項５】
請求項１に記載のサーバー管理方法において、
管理サーバーは、管理対象サーバーのどの装備で障害が発生した場合にログとパターンを分析し、分析したデータを格納し、障害が解決されると、該当装備と同様の装備を分類し、分類された類似装置に対して障害を事前に対応処理を実行するサーバー管理方法。
【請求項６】
請求項１に記載のサーバー管理方法において、
管理サーバーは、管理対象サーバーでハードウェア関連の問題が発生した場合、分類表を参照して、障害発生の可能性が高い類似装備を危険装備に分類し、分類された危険装備に関する警告メッセージを発送し、障害事前に対応措置を実行するサーバー管理方法。
【請求項７】
請求項６に記載のサーバー管理方法において、
前記分類表は、システム装備の具体的な類似判断基準を含み、同じクラス装備の分類、同じCPU装備の分類、同じメモリー装備の分類、同じNIC装備の分類、同じディスク装備の分類、同じHBA装備の分類、同じBIOS装備の分類、同じドライバーバージョンの装備の分類、同じOS装備の分類、同じファームウェアバージョンの装備の分類を含む、サーバー管理方法。
【請求項８】
請求項７に記載のサーバー管理方法において、
前記管理サーバーは、管理対象サーバーでハードウェア関連の問題が発生すると、障害症状を把握し、障害症状別症状コードに対応する障害原因を含むリストを参照して、障害症状に応じた症状コードを確認し、症状コードに対応する原因を確認し、それに応じて対応策レポートを発送し、障害原因に対応する障害対応措置を実行し、障害症状に対応する症状コードがない場合は新たな症状コードを生成し、前記のリストに追加するサーバー管理方法。
【請求項９】
請求項８に記載のサーバー管理方法において、
前記リストは、
RAC1198は、iDracファームウェアの問題、
コネクタブルメモリー障害は、メモリーの問題とバイオスファームウェアの問題、
Link Failure発生は、NIC障害とファームウェアの問題、
Link Failure Count多数の発生は、NICドライバーおよびファームウェアの問題、
NIC Link is Down は、NIC ドライバーとファームウェアの問題、
Linkステータスおよびサーバー点検要請は、NIC ドライバーおよびファームウェアの問題、
HOST_DOWN発生は、NICドライバーおよびファームウェアの問題、
サーバー前面黄色点灯発生は、iDracファームウェアの問題、
SWC5008:criticalメッセージ出力は、iDracファームウェアの問題、
NO_PARTITIONアラーム発生は、ディスク障害、
Reset adapteは、BIOSのファームウェアの問題、
Correctable memory errorは、メモリーの問題とBIOSのファームウェアの問題、
CPUの性能低下は、BIOSのファームウェアの問題、
MemoryおよびSlotの表示にはならないメモリーの問題とBIOSファームウェアの問題は、Gbic障害、
System無限リブートは、BIOSファームウェアの問題、
LCD Panel特定メッセージ出力は、iDracファームウェアの問題、
iDRACで繰り返しエラーメッセージ発生は、iDracファームウェアの問題、
vCenterエージェントと同期エラーは、EXSiバージョン、OSバージョンの問題、
サーバーリブート現象は、バイオスファームウェアの問題、
HBA Write速度低下は、HBAファームウェアとドライバーの問題、
HBA Read速度低下は、HBAファームウェアとドライバーの問題、
HBAリンクダウンは、HBA Gbicとカードの問題、
HBA二重化切体障害は、HBA GbicとCardの問題、
Riser1認識不良は、Riser Cardの問題、
Riser2認識不良は、Riser Cardの問題、
ネットワーク二重化障害は、Network Cardの問題、
PSU Alert黄色LED点灯は、PSU障害、
低電圧による異常発生は、PSU障害、PXEブート不可バイオス設定、NICファームウェア／ドライバーの問題、POSTブート不可マザーボード障害、LifeCycle接続不可マザーボード障害、
iDRAC Hang症状は、iDracファームウェアの問題、
iDRAC Networkの切断は、マザーボード障害、iDracファームウェアの問題、
iDRAC SNMPサービス障害発生は、iDracファームウェアの問題、
サーバー使用中に突然サーバーオフの症状は、マザーボードの問題、
Medium Error発生は、ディスク障害、
ERROR Event確認要請は、Error Eventによる問題、CMC接続不可、CMCファームウェアの問題、
DSET分析要請は、分析による障害、
TSR Log分析要請は、分析による障害、
NFSサービスの起動失敗は、NFS設定とOS設定の確認、vCenterに接続できないEXSiバージョンとOSバージョンの問題、
NIC Resetはネットワークカードの問題、
GPU認識不可は、GPUカードの障害、
OS Crash発生は、OS Dump分析、
Network error/dropped packets発生は、Network Cardの問題、
CRCエラー発生は、Network Cardの問題、
サーバースイッチが切れる現象は、Networkカードの問題、
ネットワーク（Bonding）への通信がスムーズにならない問題は、ネットワークカードの問題、
メモリー交替後の同じスロットイベントの発生は、メモリー障害またはマザーボード障害、ディスク読み取り専用状態でアクセスできないディスク障害、またはRAID構成の問題、
スイッチが月に3～4回Hangする症状は、マザーボードまたはOSバージョンの問題、
LACP Network Speed問題が発生するのは、Network Cardの問題、
クラスタフェイルオーバー発生は、クラスタ設定の問題またはHW障害、

発明の詳細な説明【技術分野】
【０００１】
本発明は、サーバー、ストレージ、ネットワークなどのＩＴ（Information Technology）リソースをシステム化し標準化する管理技術に関する。
続きを表示（約 1,400 文字）【背景技術】
【０００２】
最近、サーバー、ストレージ、ネットワークなどのＩＴ（Information Technology）環境が複雑になり、作業時間が不足する現象が発生している。このようにコンピュータシステムが大容量化、高速化されるにつれて、システムのエラーやウイルスなどによるコンピュータ障害が頻繁に発生している。
【０００３】
特に大容量のサーバーでは、さまざまなアプリケーションプログラムの動作やデータの格納、読み取り、転送など、さまざまな要因による障害が頻繁に発生できる。したがって、各企業では、これらのサーバーを管理する別々のサーバー管理者を常駐させてサーバーを管理し、障害発生時にこれを処理するようにしている。
【０００４】
ところで、サーバー管理には専門的な技術が必要であり、そのような専門職員を採用するにはかなりの費用がかかる。したがって、特に小規模の企業などでは、該当するサーバー管理者として専門技術者を採用するのではなく、社内既存の人材の中から適切な人を選択し、サーバー管理者として置いている実情である。
【０００５】
そのような場合には、サーバー管理がスムーズに行われにくく、しかもサーバー障害発生時にスムーズに対処することはほとんど不可能である。また、サーバー管理のために専門技術を有するサーバー管理者を採用した場合でも、サーバー管理者が出張等の理由でサーバーから遠隔地にいる場合には、サーバーの障害発生時にこれらのサーバーの状況が管理者に迅速に通知されることが難しく、サーバーの障害発生時にスムーズに対処するのが難しかったし、サーバー管理者が当該サーバーの障害発生を通知された場合でも、遠隔地にいる関係でこれに対する即時の対処が難しく、結局サーバーがダウンするなど莫大な損失が生じることがある。
【０００６】
従来、複数のサーバーを統合して管理するサーバー統合管理システムにおいて、あるサーバーに障害が発生した場合、これを検知し、事後に障害を回復する方式である。しかし、このような従来の事後障害回復方式では、障害が発生したサーバーを復旧する期間中、当該サーバーの動作が中断され、サーバーの使用中断に伴う損失が発生し、復旧に要する人員やコストによる損害が大きいという問題がある。
【先行技術文献】
【特許文献】
【０００７】
韓国公開特許１０－２０１５－０１２４６４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明は、前記のような問題点を解決するために、案出されたものであり、ＩＴリソースをシステム化し、業務を標準化することにより、運営効率性を改善し、運営コストを低減し、セキュリティを強化できるＩＴリソースシステムにおけるサーバー管理方法を提供することにその目的がある。
【０００９】
本発明の目的は、前記目的に限定されず、言及されていない他の目的は、以下の説明から通常の技術者に明確に理解することができるであろう。
【課題を解決するための手段】
【００１０】
このような目的を達成するための本発明は、２以上の管理対象サーバーを含むＩＴリソースを管理するためのＩＴリソース管理システムにおけるサーバー管理方法に関する。
（【００１１】以降は省略されています）

関連特許