(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024156645
(43)【公開日】2024-11-06
(54)【発明の名称】サーバー構成自動化機能を提供するITリソース管理システム
(51)【国際特許分類】
G06F 11/30 20060101AFI20241029BHJP
【FI】
G06F11/30 140A
G06F11/30 162
【審査請求】有
【請求項の数】11
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2024070592
(22)【出願日】2024-04-24
(31)【優先権主張番号】10-2023-0053118
(32)【優先日】2023-04-24
(33)【優先権主張国・地域又は機関】KR
(71)【出願人】
【識別番号】523374161
【氏名又は名称】ジニエイアイ カンパニー リミテッド
【氏名又は名称原語表記】GeniAI CO., LTD
【住所又は居所原語表記】5th fl, 316, Yeongdong-daero, Gangnam-gu, Seoul, Republic of Korea
(74)【代理人】
【識別番号】100121382
【弁理士】
【氏名又は名称】山下 託嗣
(72)【発明者】
【氏名】ユ,セ クウォン
【テーマコード(参考)】
5B042
【Fターム(参考)】
5B042JJ02
5B042JJ15
5B042KK07
5B042KK13
5B042KK14
5B042KK15
5B042KK17
5B042KK20
5B042MA05
5B042MA08
5B042MA14
(57)【要約】
【課題】本発明は、2以上の管理対象サーバーを含むITリソースを管理するためのITリソース管理システムに関する。
【解決手段】管理対象サーバーからハードウェア関連データ及びソフトウェア関連データを収集し、各管理対象サーバーの現状をモニタリングして管理し、これに関連する管理サービス統計データと管理サービスレポートを含む各種サーバーモニタリング情報を管理者が使用する管理者端末と管理対象サーバーを依頼した顧客端末に提供する。管理サーバーは、各管理対象サーバーが有する固有の設定値をSCP(Server Configuration Profile)のメタデータとして格納するようにサーバー構成自動化機能を提供する。本発明によれば、サーバーで発生する可能性のある障害を予め防止し、サーバー障害による被害を低減することができる効果がある。
【選択図】
図3
【特許請求の範囲】
【請求項1】
2以上の管理対象サーバーを含むITリソースを管理するためのITリソース管理システムであって、
管理対象サーバー関連データを格納するためのデータベースと、
前記管理対象サーバーからハードウェア関連データ及びソフトウェア関連データを収集し、各管理対象サーバーの状況をモニタリング・管理し、これに関連する管理サービス統計データ及び管理サービスレポートを含む各種サーバーモニタリング情報を管理者が使用する管理端末と管理対象サーバーを依頼した顧客端末に提供する管理サーバーを含み、
前記管理サーバーは、各管理対象サーバーが有する固有の設定値をSCP(Server Configuration Profile)のメタデータとして格納するようにサーバー構成自動化機能を提供する、
ITリソース管理システム。
【請求項2】
請求項1に記載のITリソース管理システムにおいて、
前記管理サーバーは、Redfish APIを用いて前記サーバー構成自動化機能を提供する、ITリソース管理システム。
【請求項3】
請求項2に記載のITリソース管理システムにおいて、
前記管理サーバーは、新たに構築される管理対象サーバーにSCPを配布し、構成情報を適用させる、ITリソース管理システム。
【請求項4】
請求項1に記載のITリソース管理システムにおいて、
前記管理サーバーは、
管理対象サーバーのBBU(Backup Battery Unit)周期を点検し、予め定められた周期になると、この内容を該当管理対象サーバーの顧客端末に送信し、
管理対象サーバーのBBU充電容量を点検し、バッテリーの充電効率が予め定められた数値以下に減少すると、この内容を該当管理対象サーバーの顧客端末に通知し、
管理対象サーバーのBBU残容量を点検し、バッテリーの残量が予め定められた数値以下である場合、この内容を該当管理対象サーバーの顧客端末に通知し、
管理対象サーバーのBBU書き込みポリシー(Write Policy)を点検し、書き込みポリシーが変更されると、この内容を該当管理対象サーバーの顧客端末に通知し、
管理対象サーバーのログ(log)確認を通じて、バッテリーフル充電(Full Charging)効率(%)を確認し、完全充電効率が予め定められた数値未満の装備に対するバッテリー交替を通知するメッセージを該当管理対象サーバーの顧客端末に通知する、
ITリソース管理システム。
【請求項5】
請求項1に記載のITリソース管理システムにおいて、
前記管理サーバーは、登録された複数の管理対象サーバーからマルチベンダハードウェアインベントリ情報を収集して格納する、ITリソース管理システム。
【請求項6】
請求項5に記載のITリソース管理システムにおいて、
前記管理サーバーは、緊急ファームウェアアップデートを含むファームウェアアップデートイベントがある場合、全ての管理対象サーバーに対してファームウェアアップデートを進める、ITリソース管理システム。
【請求項7】
請求項1に記載のITリソース管理システムにおいて、
前記管理サーバーは、管理対象サーバーのいずれかの装備で障害が発生した場合、ログとパターンを分析し、分析したデータを格納し、障害が解決されると、該当装備と同様の装備を分類し、分類された類似装備に対して障害事前に対応処理を実行する、ITリソース管理システム。
【請求項8】
請求項1に記載のITリソース管理システムにおいて、
前記管理サーバーは、管理対象サーバーでハードウェア関連の問題が発生した場合、分類表を参照して、障害の発生可能性が高い類似装備を危険装備に分類し、分類された危険装備に対する警告メッセージを発送し、障害事前に対応措置を実行する、ITリソース管理システム。
【請求項9】
請求項8に記載のITリソース管理システムにおいて、
前記分類表は、システム装備の具体的な類似判断基準を含み、同じクラス装備の分類、同じCPU装備の分類、同じメモリ装備の分類、同じNIC装備の分類、同じディスク装備の分類、同じHBA装備の分類、同じBIOS装備の分類、同じドライバーバージョンの装備の分類、同じOS装備の分類、同じファームウェアバージョンの装備の分類を含む、ITリソース管理システム。
【請求項10】
請求項9に記載のITリソース管理システムにおいて、
前記管理サーバーは、管理対象サーバーでハードウェア関連の問題が発生した場合、障害症状を把握し、障害症状別症状コードに対応する障害原因を含むリストを参照し、障害症状に応じた症状コードを確認し、症状コードに対応する原因を確認し、それに応じて対応策レポートを発送し、障害原因に対応する障害対応措置を実行し、障害症状に対応する症状コードがない場合は新たな症状コードを生成し、前記リストに追加するITリソース管理システム。
【請求項11】
請求項10に記載のITリソース管理システムにおいて、
前記リストは、
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は、バイオスファームウェアの問題、
Correctable memory errorは、メモリの問題およびバイオスファームウェアの問題、
CPU性能低下は、バイオスファームウェアの問題、
Memoryおよびスロット表示にならないのは、メモリーの問題とバイオスファームウェアの問題、
Disk fault errorは、ディスク障害、
disk predicted failは、ディスクBadBlockによる障害、
周期的なFAN 6認識問題は、Fan 6障害、
光量400以下によるFaultは、Gbic障害、NIC GBIC通信不可のGbic障害、
System無限リブートは、BIOSファームウェアの問題、
LCD Panel特定メッセージ出力は、iDracファームウェアの問題、
iDRACで繰り返しエラーメッセージが発生するのは、iDracファームウェアの問題、
vCenterエージェントと同期エラーは、EXSiバージョンとOSバージョンの問題、
サーバーのReboot現象は、BIOSファームウェアの問題、
HBA Write速度低下は、HBAファームウェアとドライバーの問題、
HBA Read速度低下は、HBAファームウェアとドライバーの問題、
HBA Link Downは、HBA GbicとCardの問題、
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 Service起動失敗は、NFS設定およびOS設定点検、vCenter接続不可のEXSiバージョン、OSバージョンの問題、
NIC Resetは、Network Cardの問題、GPU認識不可能なGPU Card障害、
OS Crashの発生は、OS Dump分析、
Network error/dropped packetsの発生は、Network Cardの問題、
CRCエラーの発生は、Network Cardの問題、
サーバーのスイッチが切れる現象は、Network Cardの問題、
Network(Bonding)への通信がスムーズにならない問題は、Network Cardの問題、
メモリー交替後に同じスロットイベントの発生は、メモリー障害またはマザーボード障害、Disk Read Only状態でアクセスできないディスク障害またはRAID構成の問題、
スイッチが月に3~4回Hangする症状は、マザーボードまたはOSバージョンの問題、
LACP Network Speed問題が発生するのは、Network Cardの問題、
クラスタフェイルオーバーの発生は、クラスタ設定の問題またはHW障害、
RTSP同期障害は、OS設定またはNetwork障害、
セッション低下現象の発生は、Network CardまたはGbicの問題、
不明な電源遮断は、PSU障害、
サーバーの遅れ、ハング現象は、アプリケーションまたはHW障害、
Network Ping Lossは、Network CardまたはGbicの問題、
LoadAvgの上昇は、CPU点検が必要、
Fatal Errorの発生は、PCI CardまたはRiser Cardの問題、
PXEインストール中の停止またはパフォーマンス低下は、Network CardまたはGbicの問題、
Blue Screenの発生(0x00004f)は、マザーボード/BIOS/ディスク/メモリー障害、
Blue Screenは、マザーボード/BIOS/ディスク障害、
OS Booting失敗は、マザーボード/BIOS/ディスク障害、
プロセスDownおよびOSインストール中のパニックは、マザーボード/BIOS/ディスク障害、
サーバーからの臭いは、ファン/マザーボード/PSUの問題、
NAS接続不可対策は、ネットワーク/OS設定の問題、KVM接続不可マザーボード/KVMケーブル/KVMの問題、
Disk Amber LEDは、ディスク障害、
Postブート時にDelayは、マザーボード/ファン/PCI/メモリーの問題、
電源不良対策は、PSU障害、
Teaming性能低下は、ネットワーク/OS設定の問題、
VD Bad Blockは、ディスク障害、
HBA Loopは、HBA障害、Raid構成情報が見えないというファームウェア/ディスクドライバーの問題、Volume認識不可能なファームウェア/ディスクドライバーの問題、
Kernel Panicは、OS/Appの問題、
最大性能使用時にサーバーリブートは、CPU/PSU/メインボード/メモリーの問題、
サーバーの処理が著しく遅くなるのは、CPU/PSU/マザーボード/メモリー/ディスクの問題、
サーバーの電源が入らないのは、PSU障害が原因で対応することを含む、
ITリソース管理システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、サーバー、ストレージ、ネットワークなどのIT(Information Technology)リソースをシステム化し標準化する管理技術に関し、より詳細には、サーバー構成を自動化する機能を提供するサーバー管理技術に関する。
【背景技術】
【0002】
最近、サーバー、ストレージ、ネットワークなどのIT(Information Technology)環境が複雑になり、作業時間が不足する現象が発生している。このようにコンピュータシステムが大容量化、高速化されるにつれて、システムのエラーやウイルスなどによるコンピュータ障害が頻繁に発生している。
【0003】
特に大容量のサーバーの場合、多様なアプリケーションプログラムの動作やデータ格納、読み出し、転送など、様々な要因による障害が頻繁に発生する可能性がある。したがって、各企業では、このようなサーバーを管理する別々のサーバー管理者を常駐させてサーバーを管理し、障害の発生時にこれを処理するようにしている。
【0004】
ところで、サーバー管理には専門的な技術が必要であり、そのような専門職員を採用するにはかなりの費用がかかる。したがって、特に小規模の企業などでは、該当するサーバー管理者として専門技術者を採用するのではなく、社内既存の人材の中から適切な人を選択し、サーバー管理者として置いている実情である。
【0005】
そのような場合、サーバー管理はスムーズに行われにくく、さらにサーバー障害の発生時にスムーズに対処することはほとんど不可能である。
【0006】
また、サーバー管理のために専門技術を持つサーバー管理者を採用した場合でも、サーバー管理者が出張などの理由でサーバーから遠隔地にいる場合には、サーバーの障害の発生時にこれらのサーバーの状況が管理者に迅速に通知されることが難しく、サーバー障害の発生時にスムーズに対処するのが難しかったし、サーバー管理者がそのサーバーの障害の発生を通知された場合でも、遠隔地にいる関係でこれに対する即時の対処が難しく、結局サーバーがダウンするなど莫大な損失が生じることがある。
【0007】
従来、複数のサーバーを統合して管理するサーバー統合管理システムにおいて、あるサーバーに障害が発生した場合、これを検知し、事後に障害を回復する方式である。しかし、このような従来の事後障害復旧方式は、障害の発生したサーバーを復旧する期間中に当該サーバーの動作が中断され、サーバーの使用中断に伴う損失が発生し、復旧に要する人員とコストに応じた損害が大きいという問題がある。
【先行技術文献】
【特許文献】
【0008】
【特許文献1】韓国公開特許10-2015-0124642号公報
【発明の概要】
【発明が解決しようとする課題】
【0009】
本発明は、前記のような問題点を解決するために案出されたものであり、ITリソースをシステム化し、業務を標準化することにより、運営効率性を改善し、運営コストを削減し、セキュリティを強化できるITリソースシステムを提供することにその目的がある。
【0010】
本発明の目的は、前記目的に限定されず、言及されていない他の目的は、以下の説明から通常の技術者に明確に理解することができるであろう。
【課題を解決するための手段】
【0011】
このような目的を達成するための本発明は、2以上の管理対象サーバーを含むITリソースを管理するためのITリソース管理システムに関する。ITリソース管理システムは、関連データおよびソフトウェア関連データを収集し、各管理対象サーバーの状況をモニタリング・管理し、これに関連する管理サービス統計データおよび管理サービスレポートを含む各種サーバーモニタリング情報を管理者が使用する管理者端末および管理対象サーバーを要請した顧客端末に提供する管理サーバーを含み、前記管理サーバーは、各管理対象サーバーが有する固有の設定値をSCP(Server Configuration Profile)のメタデータとして記憶する方式でサーバー構成自動化機能を提供する。
【0012】
管理サーバーはRedfish APIを使用してサーバー構成自動化機能を提供できる。
【0013】
管理サーバーは、新たに構築された管理対象サーバーにSCPを配布して構成情報を適用することができる。
【発明の効果】
【0014】
本発明によれば、多数の管理対象サーバーのモニタリングを通じて、先制的にサーバーで発生する障害を予測し、警告し解決策を提供することにより、サーバーで発生し得る障害を予め防止し、サーバー障害によるダメージを軽減する効果がある。また、本発明によれば、ITリソースをシステム化し、業務を標準化することにより、運営効率性を改善し、運営コストを削減し、セキュリティを強化することができる効果がある。
【0015】
また、本発明によれば、より便利で効率的に多数のサーバーを管理することができる効果がある。
【0016】
また、本発明によれば、サーバー管理を依頼した顧客に障害パターンを分析し、先制的に障害を予め対応付けておき、サーバー管理機能を提供することにより、顧客のニーズに合ったデータを加工し、伝達できる効果がある。
【図面の簡単な説明】
【0017】
【
図1】本発明の一実施形態によるITリソース管理システムの全体構成を概念的に示す図である。
【
図2】本発明の一実施形態によるITリソース管理システムにおける動作過程を概念的に示す図である。
【
図3】本発明の一実施形態によるITリソース管理システムにおけるサーバー構成自動化方法を示すフローチャートである。
【
図4】本発明の一実施形態によるITリソース管理システムが提供する機能を示す画面例である。
【
図5】本発明の一実施形態によるITリソース管理システムが提供する機能を示す画面例である。
【
図6】本発明の一実施形態によるITリソース管理システムが提供する機能を示す画面例である。
【
図7】本発明の一実施形態によるITリソース管理システムが提供する機能を示す画面例である。
【
図8】本発明の一実施形態によるITリソース管理システムが提供する機能を示す画面例である。
【
図9】本発明の一実施形態によるITリソース管理システムの構成例を示す図である。
【
図10】本発明の一実施形態によるITリソース管理システムにおけるRedfishイベントによるサーバーモニタリング機能を説明するための例示図である。
【
図11】本発明の一実施形態によるITリソース管理システムにおけるRedfishによるサーバー構成作業自動化機能を説明するための例示図である。
【
図12】本発明の一実施形態によるITリソース管理システムにおけるRedfishによるサーバー構成自動化機能を説明するための例示図である。
【
図13】本発明の一実施形態によるITリソース管理システムにおいてマルチベンダーを支援してサーバーを管理する方法を例示するフローチャートである。
【
図14】本発明の一実施形態によるITリソース管理システムにおける障害のログおよびパターンを分析して障害を予防する方法を示すフローチャートである。
【
図15】本発明の一実施形態によるITリソース管理システムにおいてRedfish APIを利用してマルチベンダーを支援する動作モデルを例示図である。
【
図16】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図17】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図18】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図19】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図20】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図21】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図22】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図23】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図24】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図25】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図26】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図27】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図28】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図29】本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
【
図30】本発明の一実施形態によるシステム装備を分類した図である。
【
図31】本発明の一実施形態によるハードウェア症状とその原因を記載した図である。
【
図32】本発明の一実施形態によるハードウェア症状とその原因を記載した図である。
【
図33】本発明の一実施形態によるITリソース管理システムにおける障害を事前に対応する方法を表示するフローチャートである。
【
図34】本発明の一実施形態によるITリソース管理システムにおける障害を事前に対応する方法を表示するフローチャートである。
【発明を実施するための形態】
【0018】
本発明は、様々な変更を加えることができ、様々な実施に例を有することができるが、特定の実施に例を図面に例示し、詳細に説明する。しかしながら、これは、本発明を特定の実施形態に限定することを意図するものではなく、本発明の精神および技術的範囲に含まれるすべての変更、均等物から代替物を含むことを理解されたい。
【0019】
本出願で使用される用語は、単に特定の実施において例を説明するために使用されたものであり、本発明を限定することを意図していない。単数の表現は、文脈上明らかに他に意味がない限り、複数の表現を含む。
【0020】
本出願において、「含む」または「有する」などの用語は、本明細書に記載の特徴、数字、ステップ、動作、構成要素、部品、またはそれらの組み合わせが存在することを指定することを意図しており、1つまたは複数の他の特徴 それらは、数字、ステップ、動作、構成要素、部品、またはそれらを組み合わせたものの存在または追加の可能性を予め排除しないことを理解されたい。
【0021】
他に定義されない限り、技術的または科学的用語を含む本明細書で使用されるすべての用語は、本発明が属する技術分野で通常の知識を有する者によって一般に理解されるのと同じ意味を有する。
【0022】
一般的に使用される事前に定義されているものなどの用語は、関連技術の文脈上の意味と一致する意味を有すると解釈されるべきであり、本出願で明確に定義されていない限り、理想的または過度に形式的な意味として解釈されるべきではない。
【0023】
なお、添付図面を参照して、説明するにあたって、符号にかかわらず同じ構成要素には同じ符号を付し、これに対する重複する説明は省略する。
【0024】
本発明を説明する際に、関連する公知技術の具体的な説明が本発明の要旨を不必要に曇らせることができると判断される場合、その詳細な説明を省略する。
【0025】
本発明は、2以上の管理対象サーバーを含むITリソースを管理するためのITリソース管理システムに関する。ITリソース管理システムは、管理対象サーバーからハードウェア関連データ及びソフトウェア関連データを収集し、各管理対象サーバーの現状をモニタリングして管理し、これに関連する管理サービス統計データと管理サービスレポートを含む各種サーバーモニタリング情報を管理者が使用する管理者端末と管理対象サーバーを依頼した顧客端末に提供する。管理サーバーは、各管理対象サーバーが有する固有の設定値をSCP(Server Configuration Profile)のメタデータとして格納するようにサーバー構成自動化機能を提供する。
【0026】
管理サーバーはRedfish APIを使用してサーバー構成自動化機能を提供できる。
【0027】
管理サーバーは、新たに構築される管理対象サーバーにSCPを配布し、構成情報を適用させることができる。
【0028】
図1は、本発明の一実施形態によるITリソース管理システムの全体構成を概念的に示す図であり、
図2は、本発明の一実施形態によるITリソース管理システムにおける動作過程を概念的に示す図である。
図1及び
図2を参照すると、本発明のITリソース管理システムは、管理サーバー110、データベース112、管理者端末120、顧客端末130を含む。
【0029】
管理者端末120は、ITリソース管理システムを管理する管理者が使用する端末である。顧客端末130は、管理対象サーバー10、20、30、40を依頼した各顧客が使用する端末である。
【0030】
本発明の一実施形態では、管理者端末120と顧客端末130とは、デスクトップコンピュータ、ラップトップコンピュータ、タブレットPC、携帯電話、携帯電話、スマートフォンなどの有無線通信が可能な様々な端末形態で実現することができる。
【0031】
本発明の一実施形態では、ユーザー端末は、管理者端末120と顧客端末130とを含む概念である。
【0032】
データベース112は、管理対象サーバー10、20、30、40関連データを格納する。
【0033】
管理サーバー110は、管理対象サーバー10、20、30、40からデータを収集し、各管理対象サーバーの現状を把握して管理し、これに関連する管理サービス統計データと管理サービスレポートとを含む。管理サーバー110は、各種サーバー管理情報を管理者端末120と顧客端末130に提供する。
【0034】
管理サーバー110は、複数の管理対象サーバーからマルチベンダハードウェア情報を収集し、格納し、格納した情報を照会して利用できるように管理者端末120および顧客端末130に提供することができる。
【0035】
管理サーバー110は、登録された複数の管理対象サーバーからマルチベンダハードウェアインベントリ情報を収集して格納することができる。
【0036】
管理サーバー110は、緊急ファームウェアアップデートを含むファームウェアアップデートイベントがあれば、全ての管理対象サーバーに対してファームウェアアップデートを進めることができる。
【0037】
管理サーバー110は、管理対象サーバーのどの装備で障害の問題が発生した場合、ログ及びパターンを分析し、分析したデータを格納し、障害の問題が解決されると、当該装備と同様の装備を分類し、分類された類似装備に対して障害を事前に対応処理を実行することができる。
【0038】
管理サーバー110は、Redfish APIを利用して、各管理対象サーバーのハードウェア詳細仕様、OS(Operating system)情報、ファームウェア情報及びドライバー情報を含む運営中のx86サーバーに関する情報を収集することができ、x86サーバーの標準化管理を実行できる。管理サーバー110は、管理対象サーバー10、20、30、40の障害パターンを解析し、同様の障害が発生するのを防止する予防分析機能を提供し、予防分析機能を介して管理対象サーバー (10,20,30,40)で予め定められたイベントの発生時の発生したイベントによる障害が発生する可能性があることを警告する予想障害の発生メッセージを、該当管理対象サーバーを依頼した顧客端末に先制的に送信できる。
【0039】
管理サーバー110は、管理対象サーバー10、20、30、40の設置、障害、技術支援履歴を管理する履歴管理機能を提供することができる。
【0040】
管理サーバー110は、管理対象サーバー10、20、30、40の配達履歴を管理する配送管理機能を提供することができる。
【0041】
管理サーバー110は、管理対象サーバーで装備関連イベントが発生すると、予め定められた分類基準に従って危険装備を分類し、当該危険装備に関する警告メッセージを管理者端末120及び該当顧客端末に発送する。そして、当該危険装備に対する事前に障害対応措置を実行できる。
【0042】
管理サーバー110は、管理対象サーバーで装備関連イベントが発生した場合、当該装備の障害症状を把握し、当該障害症状に対応する障害コードに従って原因を分析し、障害対応方案を含むレポート 管理者端末120および当該顧客端末に発送し、当該装備に対する障害対応措置を実行できる。
【0043】
本発明において、管理サーバー110は、顧客端末130からの要請に応じて管理対象サーバーの管理に関連するデータを処理し、伝達するデータデリバリーサービス(data delivery service)機能を提供することができる。
【0044】
また、管理サーバー110は、管理対象サーバーのクリティカル障害を分析し、同じ事例を伝播して、サーバー障害を事前に予防することができ、四半期ごとに各サーバーの障害統計を管理者端末120、顧客端末130に提供することができる。
【0045】
本発明において、管理サーバーは、配達したサーバー関連装備に対する履歴を管理することができ、設置/障害/技術支援履歴管理サービスを提供し、パーツ別の問題を管理することができる。
【0046】
本発明は、顧客から依頼された複数の管理対象サーバー10、20、30、40を管理するITリソース管理システムに関する。
【0047】
本発明の一実施形態において管理対象となるサーバーである管理対象サーバーは、様々なサーバーであってもよく、例えば、Dell(登録商標)サーバー10、HP(登録商標)サーバー20、Lenovo(登録商標)サーバー30、X86サーバー40であってもよい。
【0048】
管理対象サーバー10、20、30、40と管理サーバー110は、様々な有無線通信方式を介して通信し、例えば、HTTP通信やJSON形式のPOST転送方式で通信することができる。
【0049】
また、管理対象サーバー10、20、30、40は、大規模なコンピュータ環境の様々なx86サーバーで定められたスケジューリングに従ってスクリプトを自動実行できる。
【0050】
管理者は、管理者端末120を介して管理サーバー110に接続し、管理サーバー110に定められたスケジューリングに従ってバッチ(BATCH)プログラムを実行し、既存のデータと比較して変更履歴を管理する。
【0051】
管理サーバー110は、自動的に管理対象サーバー10、20、30、40のハードウェア情報及びソフトウェア情報を収集し、これに基づいて各サーバーの現状を把握し、各サーバーの要請状況に合わせて管理サービスを提供する。
図2は、本発明の一実施形態によるITリソース管理システムにおける動作過程を概念的に示したものであり、
図2において管理対象サーバーはiDRAC9バージョンが適用されたDell(登録商標)サーバー10であり、Redfish API(Application Programming Interface)が使用されたプラットフォームを例示した。
【0052】
図2を参照すると、ユーザー端末においてフラスコ(Flask)を用いてゲットモジュール(Get Module)を実行し、Redfish APIを用いて、Dell(登録商標)サーバー10からiDRAC9整形データ及び非整形データを収集する。
【0053】
その後、収集したデータを分類し、データ前処理を実行する。前処理したデータをデータベース112に格納し、データベースにスタックされたデータについてAI学習データモデルを介して学習を実行し、データを再分類し、データロー(row)を生成する。
【0054】
そして、ユーザー端末でフラスコ(Flask)を用いてページを呼び出し、データ解析モジュールでデータベース112を検索し、解析を進め、データ視覚化を実行し、これをフラスコレスパンスユーザーウェブ(Flask Response User Web)ページに伝達する。
図3は、本発明の一実施形態によるITリソース管理システムにおけるサーバー構成自動化方法を示すフローチャートである。
【0055】
図3の実施形態はRedfish APIを用いた実施形態である。
図3を参照すると、管理サーバー110は、各管理対象サーバーから収集されたOS、BIOS、ファームウェアなどの情報を格納する(S2010)。管理サーバー110は、緊急ファームウェアアップデートなどのファームウェアアップデートイベントが発生すると、該当する管理対象サーバーにファームウェアを配布する(S2020、S2030)。次に、管理サーバー110は、管理対象サーバーのファームウェア情報を点検し(S2040)、ファームウェアのアップデートが完了したか否かを確認する(S2050)。
図4ないし
図8は、本発明の一実施形態によるITリソース管理システムが提供する機能を示す画面例である。
【0056】
図4はメインダッシュボードの画面例である。
図4を参照すると、管理サーバー110は、管理対象サーバー10、20、30、40から収集されたリソース情報と、登録された業績件数などに基づいて重要な情報を一つの画面にまとめて表示するメインのダッシュボード画面を提供する。本発明では、特定情報を深く分析し、継続的にモニタリングできるように支援し、ユーザーが頻繁に使用する装備が何であり、ある業務に多くの時間を要しており、管理対象サーバーのコンポーネント別安定化ファームウェア(Firmware)が適用されているかどうかなどの様々な情報をダッシュボード画面を介して提供し、ダッシュボード画面を介して、ユーザーが重要管理対象サーバー情報を一目で確認できるように提供することができる。
【0057】
図4の画面例では、サーバー、ストレージ、ネットワーク運営状況情報を表示しているが、稼働中の総数量と、サーバーメーカー別数量に対するパイチャートを提供する。
【0058】
そして、毎月の業績件数状況情報を提供し、作業、変更、障害成果件数に関する棒グラフを提供する。
【0059】
安定化ファームウェア適用状況情報を表示する際に、BIOS、R/C、NIC、iDRAC、HBAなどの安定化ファームウェア適用装置と未適用装置の割合である安定化適用率に関するチャートを提供する。
【0060】
図5は、リソース管理機能を表示した画面例である。本発明において、管理サーバー110は、サーバー等の装備の新規設置、変更リストを自動的に収集し、整理し、信頼性の高いデータをリアルタイムで提供するリソース管理機能を提供する。
【0061】
管理サーバー110は、リソース管理機能においてユーザー端末から登録された情報を収集し、標準化されたRedfish RESTful APIを介して、あらかじめ定義された周期に従ってデータセンター内のサーバーのリソース情報を自動的に収集することができる。
【0062】
図5の画面例では、装備情報が表示されており、サーバー、ストレージ、ネットワーク、SAN、バックアップ装備、廃棄装備などの装備情報を登録または照会することができる。
【0063】
関連統計情報を提供するために、運営、アイドル、サービス前、廃棄などの装備状態に対するパイチャートを提供し、年度別、ベンダー別動作装備の現状と、最近登録された装備リスト、追加カスタマイズ方式などの さまざまな統計グラフを提供する。
図6は、パフォーマンス管理機能を表示した画面例である。
【0064】
本発明において、管理サーバー110は、予定されたタスク、タスクによって変更された事項などに対する管理と障害の発生後の履歴、改善結果を管理するためのパフォーマンス管理機能を提供する。
【0065】
これにより、本発明において障害の原因が明確である場合、同じ障害が発生しないように記録管理し、改善が必要な事項に対して担当者を割り当て、改善結果を確認することができる。
【0066】
また、年度、月別、データセンター位置、運営サービス前、アイドルなどの状況に応じて様々な成果状況統計情報を提供することができる。
【0067】
図6の画面例では、オンラインまたはオフラインのジョブ履歴管理を含むジョブ履歴、障害処理履歴管理人の障害履歴、システム変更履歴管理人の変更履歴などが表示されており、バックアップスケジュール管理、業績状況に関する各種統計グラフが表示される。
【0068】
図7は、自動化管理機能を表示した画面例である。本発明において、管理サーバー110は、標準化されたRedfish RESTful APIを介して、同期周期(Daily/Weekly/Monthly)設定、自動化収集値(全て/Chassis/MGMT/CPU/NIC/HBA/DISK/GPUなど)設定、スケジュール情報登録などの自動化収集のためのグループ別実行周期管理と、毎日自動点検を通じて、点検必要対象装備に関する通知情報を提供する自動化管理機能を提供する。
【0069】
図7の画面例では、収集同期周期の設定、自動化収集値のカスタマイズ設定、収集スケジュール情報を登録する自動化設定と、日常点検が必要な装備の自動分類、MGMT(Management Repository)接続エラー装備を確認することができる ある日常点検のメニューが表示されている。
図7に示すように、管理サーバー110は、日常点検のメニューで装備の状態によって色を変えて表示することができる。
【0070】
すなわち、装備に異常がなければ記号1(緑丸)で、管理者の点検が必要な場合である「点検必要」であれば記号2(赤丸)で、肉眼で点検が必要な場合である「目視点検必要」であれば記号3(黄丸)で、MGMTに接続できない場合の「MGMTアクセス不可」の場合、記号4(灰色丸)で表示することができる。
【0071】
図8は、構成図管理を表示した画面例である。本発明において、管理サーバー110は、ITインフラ構成要素であるサーバー、ストレージ、ネットワーク、SAN等のITインフラ環境を効率的に運営及び管理するために必要な構成図のビュー機能である構成図管理機能を提供する。
【0072】
すなわち、管理サーバー110は、ユーザー端末から選択されたリソースであるサーバー、ストレージ、ネットワーク、SAN等の構成に対するビュー(View)を自動的に表示する構成も管理機能を提供し、これにより、性能の問題そして、障害が発生したときにより速い意思決定をすることができる。
図8を参照すると、構成図管理機能においてユーザー端末から選択された装備(サーバー、ストレージ、ネットワーク、SAN等)の構成図のビュー機能を提供し、ホスト名(Hostname)、装備モデル基準検索及び選択機能を提供し、パフォーマンスの問題や障害の発生時にインフラ構成をリアルタイムで確認できるようにする。
【0073】
図9は、本発明の一実施形態によるITリソース管理システムの構成例を示す図である。
図9の構成例では、Redfish APIが使用され、管理対象サーバーがMGMTネットワークを介して接続され、管理者端末120ウェブ接続方式で管理対象サーバーに接続することができる。
【0074】
本発明の一実施形態では、ITリソース管理システムは、Redfish APIベースのプラットフォームでマルチベンダーx86サーバーのハードウェアシステムのインベントリ情報をリアルタイムで収集し、BIOS設定、ファームウェアなどを配布する。これにより、メンテナンス効率の向上と運営コストの削減の効果をもたらすことができる。また、収集されたログ(Log)に基づいて類似装備を把握し、同じ障害を事前に予防できるようにする。
【0075】
図10は、本発明の一実施形態によるITリソース管理システムにおけるRedfishイベントによるサーバーモニタリング機能を説明するための例示図である。
図10を参照すると、本発明における管理サーバー110は、Redfishイベントを介したサーバーモニタリング機能を提供することができる。
【0076】
Redfishイベントは、HTTPSに基づいてサーバーのイベント情報をRedfishクライアントに転送し、管理でアラームが発生するとHTTP POSTに転送され、HTTP GETを介して受信できる。この時、重要通知メールプッシュ(Push)、状態モニタリング、日常点検の対象サーバーを選別し、必要なデータをロードすることができる。
【0077】
図11は、本発明の一実施形態によるITリソース管理システムにおけるRedfishによるサーバー構成作業自動化機能を説明するための例示図である。
図11を参照すると、本発明における管理サーバー110は、Redfishを介したサーバー構成作業自動化機能を提供することができる。
【0078】
この機能では、BIOS設定の変更、セキュアブート(Secure Boot)、iDRAC Configurationなどをローカルに配布することができ、アップデートすることができる。また、管理対象サーバーファームウェアインベントリの管理およびアップデートを提供し、サーバー展開時にBIOS標準設定、マネジメント標準設定値を一括適用することで、展開時間を短縮でき、自動化管理機能により、誤設定値が入力されるのを防止できる。また、管理対象サーバーにインストールされているファームウェア情報をあらかじめ設定しておいた周期に応じてアップデートし、緊急ファームウェア配布時、対象装備を自動的に選別し、管理者にメールをプッシュする機能を提供する。
【0079】
図12は、本発明の一実施形態によるITリソース管理システムにおけるRedfishによるサーバー構成自動化機能を説明するための例示図である。本発明では、管理サーバー110は、Redfishを介したサーバー構成自動化機能を提供することができる。
【0080】
サーバーが持つ固有の設定値は、SCP(Server Configuration Profile)のメタデータとして格納されるが、このメタデータは、本発明においてRedfish APIを用いて構成することができる。
【0081】
SCPは、エクスポート(Export)、プレビュー(Preview)、およびインポート(Import)を可能にし、それを使用して、本発明のサーバー構成自動化機能を介して、新しく構築されるサーバーに構成情報を適用することができる。
【0082】
SCPは、HTTPS、NFS、CIFSなどの方法で共有でき、XMLとJSON形式で実現される。サーバー構成時にSSHプロトコルを使用すると、多数のアプリケーションを安定して一貫して配布できる。
【0083】
本発明では、物理サーバー配布のための固有の設定値をメタデータとしてファイル共有サーバーにXML、JSON形式で格納し、マネジメントネットワークに接続された新しく構築されるサーバーに構成情報を自動的に適用することができる。
【0084】
このように、本発明の構成自動化機能により、オペレータは、新しいサーバー構成のために各サーバーに別々の接続を行わなくても迅速に新しいサーバーを構成することができる。
【0085】
本発明の一実施形態では、Redfishを利用したAI(Artificial Intelligence)分析機能を提供する。すなわち、SRC(Server remote control)(iDRAC、iLO、IPMI)により、サーバー、ストレージ装置の整形、非定型ログデータを収集し、データ分類及び前処理進行過程を実行できる。
【0086】
その後、学習データモデルを活用して装備の状態や障害を予測し、重要な問題の発生時に文字や電子メールなどでユーザー端末にアラームメッセージを伝達する。
【0087】
本発明のAI分析機能により、正常なトラックピックが何であるかを学習し、異常トラフィックを発見し、ユーザーに必要な危険度の優先順位を設定し、問題を分析して支援することができる。
【0088】
AIを通じて、サーバー運営時に収集されたログを分析して学習し、アルゴリズムを開発し、学習されたアルゴリズムを通じて、既存の障害の発生と同様のログ情報の確認時に顧客端末130に警報メッセージを伝達する障害解決策を提供する。すなわち、AI分析機能により、事前に障害防止の問題の発生迅速共有、リアルタイム分析などを実行できる。
【0089】
管理サーバー110は、管理対象サーバーのBBU(Backup Battery Unit)周期を点検し、予め定められた周期になると、この内容を該当管理対象サーバーの顧客端末に転送することができる。
【0090】
また、管理サーバー110は、管理対象サーバーのBBU充電容量を点検し、バッテリーの充電効率が予め定められた数値以下に減少すると、この内容を該当管理対象サーバーの顧客端末に通知することができる。
【0091】
例えば、管理サーバー110は、管理対象サーバーのBBU充電容量を点検し、バッテリーの充電効率が40%以下に低下した場合、この内容を該当管理対象サーバーの顧客端末に通知することができる。
【0092】
管理サーバー110は、管理対象サーバーのBBU 残容量を点検し、バッテリーの残量が10%以下となった場合、この内容を該当管理対象サーバーの顧客端末に通知することができる。例えば、管理サーバー110は、管理対象サーバーのBBU残容量を点検し、バッテリーの残量が10%以下である場合、この内容を該当管理対象サーバーの顧客端末に通知することができる。
【0093】
また、管理サーバー110は、管理対象サーバーのBBU書き込みポリシー(Write Policy)を点検し、書き込みポリシーが変更されると、この内容を該当管理対象サーバーの顧客端末に通知することができる。
【0094】
本発明の多数のサーバーを統合し、管理するサーバー統合管理システムのためのものであり、サーバーの様々な機能を診断し、障害を予め予測し、警告し、解決策を一緒に提示する。
【0095】
本発明では、サーバーの様々な機能のうち、BBU(Backup Battery Unit)を例示して説明する。
【0096】
Dell(登録商標)サーバーを例にとると、RAIDコントローラのバッテリー障害によるキャッシュデータの損失を防ぐために、BBUのバッテリーの状態の点検及び先制的な交換の進行が必要である。このために、Dell(登録商標)サーバーのログ確認により、バッテリーフル充電(Full Charging)効率(%)を確認し、フル充電効率が50%未満の装備を点検し、バッテリー交替を進める。
【0097】
36ヶ月以降のバッテリー充電効率は約70%前後で自然に減少し、これを考慮して、約20%程度の追加的な減少があるバッテリーに対して充電効率不良と判定することができる。
【0098】
本発明のサーバー統合管理システムは、BBU周期点検、充電容量点検、残容量確認、書き込みポリシー(Write Policy)点検を実行し、これによりキャッシュデータの損失を防止し、バッテリー状態の危険因子を事前に防止できる。本発明のITリソース管理システムでは、あるイベントが発生した場合、該当イベントを介してサーバーに障害が発生する可能性があることを診断し、予め該当サーバーのシステムに警告し、解決策に関する情報をまとめて伝達する。
【0099】
これに関して、サーバーで発生するイベントは非常に多様であり、以前になかったイベントが新たに発生する可能性もある。本発明では、このようなサーバーで発生し得るイベントのうちいくつかのイベントを例示する。
【0100】
1.iDRAC7 バージョン 1.51.51 に適用された製品のDell(登録商標) R720 サーバーでファン (FAN) ノイズ (Reading 12,000 RPM 以上)
これに対する解決策は、iDRAC7バージョン1.46.45にダウングレードすることを推奨する。
【0101】
2.ラック PDU#1およびPDU#2で電力使用率がPDU#1にシュート現象の発生
図32を参照すると、Dell(登録商標)サーバーだけでなく、HPサーバーも同様に電源(Power Supply)のデフォルト(Default)としてアクティブスタンバイ(Active Standby)として動作するように設定されており、これにより電力がラック(Rack)PDUの一方に追い込まれる状況が発生するのにバランス(Balance)を合わせるためにはPrimary- PSUの比率を合わせる必要がある。
【0102】
3.Dell(登録商標)サーバー製品の第12世代~第14世代カーネルアップデート(kernel update)後のOSの異常動作
このとき、管理サーバー110は、デル(登録商標)サーバーでカーネルアップデート後、OS(Operating system)上で異常動作が発見された場合、これにより発生し得る予想障害の発生メッセージを管理対象サーバーに送信し、それに伴って予想される障害の解決策を対応する管理対象サーバーに伝達する。
【0103】
4.TCP/IPポート(Port) 不足によるサービス不可
これは、ウィンドウズ(登録商標)(Windows)2008でアップタイム(Uptime)が497日以降の場合、ネットワーク(Network)TIME_WAITセッション(session)が閉じられずに残っている現象である。これにより、ポートを占有し、それ以上のポートがない場合に問題になる。ウィンドウズ(登録商標)2008サーバーとウィンドウズ(登録商標)2012サーバーが対象となり、アップデートされたパッチを削除することで障害を解決できる。
【0104】
5.ウィンドウズ(登録商標)2003~2022 イベントログの発生
【0105】
6.メモリーの生産サイクルの診断
これは特定メモリーの特定生産サイクルが不良であることを確認するもので、障害対象は、第13世代装備(R730、R930、R630)であり、障害OSはウィンドウズ(登録商標)2012 R2サーバー(Server)でKB3064209 hotfixを含むサーバー そして、解決策は対応するhotfixを削除することである。本発明において、管理サーバー110は、管理対象サーバーのメモリー生産周期を診断し、予め定められたメモリー生産周期を不良と判定し、この内容を該当管理対象サーバーに通知する。
【0106】
7.PCIe TypeのSSDを使用している場合、デバイス設定で応答が停止する現象
これに対する解決策は、BIOS 1.1.4を1.2.10にアップデートすることである。
【0107】
8.12G サーバーのBIOS アップデート後の温度 センサーが正常に動作しないため、ビープ音 (Alert_) が継続の発生する問題。
これに対する解決策は、BIOS 2.5.2バージョンを診断し、最新のファームウェアでアップデートすることである。
【0108】
9.パッチアップデート後にBSODの発生後ブート(Booting)不可現象
このイベントは2014年8月のPatch Tuesday update WindowsエラーKB2982791による現象である。障害の対象は、windows(登録商標)2008サーバーであり、パッチアップデートを介して障害を解決できる。
【0109】
10.ウィンドウズ(登録商標)2012 Active Directorを用いたクライアント(Client)でDNS接続エラーの発生
サーバーからドメインアカウントにログインすると、アカウントとパスワードが正常であっても「ユーザー名またはパスワードが正しくありません」というエラーが発生する。ウィンドウズ(登録商標)サーバー2008 R2/ウィンドウズ(登録商標)7以降、DES-CBC-MD5およびDES-CBC-CRC暗号化を使用せず、AES256-CTS-HMAC-SHA1-96、AES128-CTS-HMAC-SHA1-96、RC4 -HMAC暗号化のみを使用するが、ADサーバーがウィンドウズ(登録商標)サーバー2012 R2で、ドメインメンバー(Domain Member)がウィンドウズ(登録商標)サーバー2008 R2またはウィンドウズ(登録商標)7の場合、コンピューターアカウントのパスワード アップデート時にAESキー生成が失敗する製品上の問題により発生した現象である。
【0110】
11.GNU Bash 4.3 Shellに存在する脆弱性
Bashの脆弱性により、攻撃者は、Webサーバーのコンテンツとコードの変更、Webサイトの改ざん、ユーザーデータの漏洩、およびDDoS攻撃の実行が可能であることが知られている。この他にも、SSH、DHCPプロトコルなど様々な環境下でのBashコードインジェクション脆弱性の攻撃シナリオも提起されている状況である。障害の対象は、Red Hat Enterprise Linux(登録商標) 5,6,7サーバーであり、障害解決策は、Bashアップデートである。
【0111】
12.GNU Cライブラリ(glibc)のバッファオーバーフローの脆弱性
ネットワーク接続時によく使われる gethostbyname(), gethostbyname2()の関数呼び出し時に、脆弱な関数が呼び出される現象として、外部の攻撃者は脆弱なサーバーにてリモートで任意のコードを実行させることができる。障害の対象は、Red Hat Enterprise Linux(登録商標) 5,6,7サーバーであり、障害解決策は、GLIBCアップデートである。
【0112】
13.Radhat V5およびV6シリーズOSのバグ
Intel(登録商標) CPUを用いたRed Hat Enterprise Linux(登録商標) 6 or 5は、すべてのバージョンで208.5日以降にReboot現象が発生するバグである。障害の対象は、Red Hat Enterprise Linux(登録商標) 5,6サーバーであり、障害解決策は、カーネルアップデートである。
【0113】
14.レイドコントローラのバッテリーフェイル(Raid Controller Battery Fail)
レイドコントローラキャッシュ(Raid Controller Cache)の使用不可によるI/O性能が低下する。障害の対象は、Dell Perc(登録商標) 5i、6i用のRaid Controller Batteryであり、障害解決策は、Dell(登録商標) Perc 5i、6i用のRaid Controller Batteryの使用サイクル4~5年ごとに事前に交替することである。
【0114】
15.CPU IERRエラー(Error)の発生によるシステムダウン(SYSTEM DOWN)
障害の対象となるのは、Intel(登録商標) iBridge V2対応CPU使用サーバー(PE R720、PE R920)であり、障害解決策は、BIOS設定(Setting)を変更することである。たとえば、システムプロファイル設定(System Profile Settings)をシステムプロファイル(System Profile)をCustomに設定し、CPUパワーマネジメント(Power Management)をMaximum Performance、C1EをDisabled C States Disabled、Monitor/MwaitをDisabledに設定する。
【0115】
16.iDrac 1.50.50 F/W(Firmware)(該当バージョン検索)使用時に管理Web接続不可
iDrac F/W(Firmware) OS上でのF/Wアップグレード(Upgrade)するか、日常生活でのメディアによるアップグレードを通じて、1.51.51にアップグレードする。
【0116】
本発明は、マルチベンダーを支援するITリソース管理システムを提案する。例えば、本発明では、Dell(登録商標)、HP(登録商標)、Lenovo(登録商標)など3社のハードウェアシステムに関する情報を1つのインベントリ(Inventory)に格納し、インベントリに格納された情報を用いて、ハードウェアに関する全ての情報を照会することができ、機能を活用できるように実現する。本発明の説明の便宜のために、Dell(登録商標)、HP(登録商標)、Lenovo(登録商標)などの製造業者を例示して、マルチベンダーを支援するITリソース管理システムについて説明する。
【0117】
図13は、本発明の一実施形態によるITリソース管理システムにおいてマルチベンダーを支援してサーバーを管理する方法を例示するフローチャートである。
図13において、各ステップの実行主体は管理サーバー110である。
【0118】
図13を参照すると、管理対象サーバーを登録する(S201)。このとき、各サーバーの管理IP情報を用いて対象サーバーを登録することができる。たとえば、Dell(登録商標)の場合はiDRAC、HP(登録商標)の場合はiLO、Lenovo(登録商標)の場合はiMMを使用してターゲットサーバーを登録できる。
【0119】
次に、各サーバーに接続するか否かを把握し(S203)、マルチベンダハードウェアインベントリ情報を収集する(S205)。本発明の一実施形態では、ハードウェア共通標準であるRedfish API(Application Programming Interface)を使用して、メーカーを区別することなくx86サーバーのハードウェアシステムのインベントリ情報を収集することができる。
【0120】
その後、収集したインベントリ情報を格納する(S207)。緊急ファームウェアアップデートを含むファームウェアアップデートイベントがある場合、全ての管理対象サーバーに対してファームウェアアップデートを進める(S209)。そして、変更されたアップデート情報を確認する(S211)。本発明の一実施形態では、Redfish APIを介してファームウェアアップデート情報を確認することができる。
【0121】
次に、各サーバーの安全度、点検対象の有無、重要度等に応じてグループを設定し(S215)、リアルタイムでサーバー情報を確認する(S217)。このように、本発明の一実施形態ではRedfish APIを利用して、各サーバーのハードウェア詳細仕様、OS(Operating system)情報、ファームウェア情報、ドライバー情報など運営中のx86サーバーに関する様々な情報を収集することができ、x86サーバーの標準化管理を実行できる。
【0122】
図14は、本発明の一実施形態によるITリソース管理システムにおける障害のログおよびパターンを分析して障害を予防する方法を示すフローチャートである。
図14の各ステップを実行する主体は管理サーバー110である。
【0123】
図14を参照すると、管理対象サーバーのいずれかの装備で障害の問題が発生した場合(S401)、ログおよびパターンを分析する(S403)。その後、分析したデータを格納する(S405)。障害の問題が解決されると(S407)、該当装備と同様の装備を分類し(S409)、分類された類似装備に対して障害を事前に対応処理を実行する(S411)。このように、本発明において障害の問題の発生時にログ及びパターンを分析し、自動的に類似装置を分類することにより、類似装置で発生する障害を予防することができる。
【0124】
図15は、本発明の一実施形態によるITリソース管理システムにおいてRedfish APIを利用してマルチベンダーを支援する動作モデルを例示する。
図15に示すように、本発明では、Redfish APIを利用して、Dell(登録商標)、HP(登録商標)、Lenovo(登録商標)などメーカーの区別なしにx86サーバーハードウェアシステムに関するインベントリ情報を収集し、収集した情報を照会して活用することができる。
【0125】
たとえば、Dell(登録商標)の場合はiDRACを使用してデータを収集し、HP(登録商標)の場合はiLOを使用してデータを収集し、Lenovo(登録商標)の場合はiMMを使用してデータを収集する。
【0126】
また、Redfish APIを使用して、複数のサーバーにOSとファームウェアを配布してインストールできる。本発明ではRedfish APIを用いて、各サーバーのハードウェア仕様、OS情報、ファームウェア情報などを迅速に確認することができる。
【0127】
本発明では、パターンを分析して障害を予測することができ、ハードウェアログを用いてパターン分析を進めることができる。
【0128】
Redfish APIは、2015年に最初にリリースされて以来、継続的なアップデートが行われており、複数のサーバー製造ベンダー社を支援し、IPMIと同じ機能を提供している。
【0129】
さらに、Redfish APIはBIOSとSecure Boot設定機能、ファームウェアアップデート機能、ストレージとサーバーのネットワーク設定機能を支援する。また、Open Compute Platform、Open stack、SNIA(Storage Networking Industry Association)などを支援し、ネットワークスイッチマネジメント、外付けストレージマネジメントなどを支援する。
【0130】
Power Edgeサーバーの管理ツール(tool)であるiDRACは、Redfishを利用してRedfish RESTful APIを支援する。たとえば、iDRACは、サーバーの電源(Reset、Reboot、Power Control)、サーバーのハードウェアインベントリ、サーバーのモニタリングとステータス点検、システムログの収集、サーバーの状態変化の点検、およびアラームを実行できる。
【0131】
パワーエッジサーバーはRedfishを介してサーバーの初期設定を自動化できる。そして、iDRAC初期設定、BIOS、RAIDコントローラ、ネットワークカードなど様々な構成情報をテンプレート化し、サーバーの自動化展開ができる。
【0132】
パワーエッジサーバーのiDRACでRedfishの活用例の中でサーバー構成の自動化(Auto deployment)を例示すると、次の通りである。
【0133】
サーバーが持つ固有の設定値は、SCP(Server configuration profile)のメタデータとして格納され、Redfish APIで構成できる。また、Redfish APIを介して、BIOS、iDRAC/LC、PERC RAID Controller、NIC、HBAなどの各種設定情報を設定できる。
【0134】
SCPは、エクスポート、プレビュー、インポートが可能で、新しく構築されたサーバーに設定情報を自由に適用できる。SCPは、HTTS、NFS、CIFSなどの方法で共有でき、XMLやJSONファイル形式などで実現することができる。
【0135】
図16ないし
図29は、本発明の一実施形態によるITリソース管理システムの画面例を示す図である。
図16は初期画面例であり、管理対象サーバーに対して自動的に収集したインベントリ及びログに関する情報を一目で見ることができるようにダッシュボードを介して支援する画面例である。
【0136】
図17は、管理対象サーバーのインベントリ情報をリアルタイムで確認できる画面例であり、この画面例で変更された情報に対しても自動的にインベントリ情報が変更される。
【0137】
図18の画面例では、管理対象サーバーの問題が確認されたときに容易に認識できるように、パーツごとに記号5(赤丸)で表され、正常なパーツは記号6(緑丸)で示されている。
【0138】
図19は、ファームウェア(F/W)情報を含む全体管理対象サーバーのリアルタイムマネジメント情報を確認できる画面例である。
【0139】
図20は、全体管理対象サーバーのリアルタイムCPU詳細情報及び現在の状態を確認できる画面例である。
【0140】
図21は、全体管理対象サーバーのリアルタイムメモリー詳細情報および現在の状態を確認できる画面例である。
【0141】
図22は、全体管理対象サーバーのリアルタイムRaid Controller詳細情報及び現在の状態を確認できる画面例である。
【0142】
図23は、全体管理対象サーバーのリアルタイムDisk詳細情報及び現在の状態を確認できる画面例である。
【0143】
図24は、全体管理対象サーバーのPSU(Power Supply)リアルタイム詳細情報及び現在の状態を確認できる画面例である。
【0144】
図25及び
図26は、全体管理対象サーバーの収集ロゴに対するリアルタイム詳細情報を確認できる画面例であり、リアルタイムVendor HWエラーコードを収集して自動的に分類し、エラーコード別の問題装備確認が可能である。
【0145】
図27は、障害分析画面例として、障害の原因、結論、交替時期を含む障害分析情報が表示されている。
【0146】
図28は、顧客会社と比較した各サーバー別障害分析分布図を例示した画面例である。
【0147】
図29は、サービスレポート機能を例示した画面例としての発生時期の問題事項、問題解決及び再発防止措置事項を含むレポート内容を例示している。
【0148】
図30は、本発明の一実施形態によるシステム装備を分類した図表であり、
図31及び
図32は、本発明の一実施形態によるハードウェア症状及びその原因を記載した図表である。
【0149】
図33ないし
図34は、本発明の一実施形態によるITリソース管理システムにおける障害を事前に対応する方法を示すフローチャートである。
【0150】
図33を参照すると、管理サーバー110は、管理対象サーバーでハードウェア関連の問題が発生した場合(S101)、
図30の分類表を参照して、障害の発生可能性が高い類似装備を危険装備に分類する(S103)。次に、分類された危険装備に対する警告メッセージを発送し(S105)、障害事前に対応措置を実行する(S107)。
図30の分類表を参照すると、本発明の一実施形態におけるシステム装備の具体的な類似判断基準が例示されており、同じクラス装備の分類、同じCPU装備の分類、同じメモリー装備の分類、同じNIC装備の分類、同じディスク装備の分類、同じHBA装備の分類、同じBIOS装備の分類、同じDriverバージョン装備の分類、同じOS装備の分類、同じFirmwareバージョン装備の分類などが例示されている。
【0151】
図34を参照すると、管理サーバー110は、管理対象サーバーでハードウェア関連の問題が発生した場合(S301)、障害症状を把握する(S303)。次に、
図31及び
図32の図を参照して、障害症状に応じた症状コードを確認する(S305)。その後、症状コードに対応する原因を確認し(S307)、それに応じて対応策レポートを発送する(S309)。次に、障害原因に対応する障害対応措置を実行する(S311)。S305段階で障害症状に対応する症状コードがない場合、新たな症状コードを生成し、
図31及び
図32のリストに追加する(S313)。
図31および
図32を参照すると、本発明の一実施形態による障害症状別症状コードに対応する障害原因が例示されている。
【0152】
つまり、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はバイオスファームウェアの問題、Correctable memory errorはメモリーの問題およびバイオスファームウェアの問題、CPU性能低下はバイオスファームウェアの問題、MemoryおよびSlotを表示できないのはメモリーの問題およびバイオスファームウェアの問題、Disk fault errorはディスク障害、disk predicted failはディスクBadBlockによる障害、周期的なFAN 6認識問題はFan 6障害、光量400以下によるFaultはGbic障害、NIC GBIC通信不可はGbic障害、System無限リブートはBIOSファームウェアの問題、LCD Panel特定メッセージ出力はiDracファームウェアの問題、iDRACで繰り返しエラーメッセージの発生はiDracファームウェアの問題、vCenterエージェントと同期エラーはEXSiバージョン、OSバージョンの問題、サーバーのReboot現象はBIOSファームウェアの問題、HBA Writeの速度低下はHBAファームウェアとドライバーの問題、HBA Readの速度低下はHBAファームウェアとドライバーの問題、HBA Link DownはHBA GbicとCardの問題、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ファームウェアの問題が原因で対応する。
【0153】
また、DSET分析要請は分析による障害、TSR Log分析要請は分析による障害、NFS Service起動失敗はNFS設定とOS設定点検、vCenter接続不可のEXSiバージョンとOSバージョンの問題、NIC ResetはNetwork Cardの問題、GPU認識不可能なGPUカードの障害、OS Crashの発生はOS Dump分析、Network error/dropped packetsの発生はNetwork Cardの問題、CRCエラーの発生はNetwork Cardの問題、サーバースイッチが切れる現象はNetwork カードの問題、ネットワークへの通信がスムーズにならない問題はネットワークカードの問題、メモリー交替後の同じスロットイベントの発生はメモリー障害またはマザーボード障害、ディスク読み取り専用状態でアクセスできないディスク障害、またはRAID構成の問題、スイッチが月に3~4回Hangする症状はマザーボードまたはOSバージョンの問題、LACP Network Speed問題が発生するのはNetwork Cardの問題、クラスタフェイルオーバーの発生はクラスタ設定の問題またはHW障害、RTSP同期障害はOS設定またはNetwork障害、セッション低下現象の発生はNetwork CardまたはGbicの問題、不明な電源遮断はPSU障害、サーバーの遅れおよびハング現象はアプリケーションまたはHW障害、Network Ping LossはNetwork Card、またはGbicの問題、LoadAvgの上昇はCPU点検が必要、Fatal Errorの発生はPCI CardまたはRiser Cardの問題、PXEインストール中の停止またはパフォーマンス低下はNetwork CardまたはGbicの問題、Blue Screenの発生(0x00004f)はマザーボード/BIOS/ディスク/メモリー障害、Blue Screenはマザーボード/BIOS/ディスク障害、OS Booting障害はマザーボード/BIOS/ディスク障害、プロセスDown、OSのインストール中のパニックはマザーボード/BIOS/ディスク障害、サーバーからの臭いはファン/マザーボード/PSUの問題、NAS接続不可対策はネットワーク/OS設定の問題、KVM接続不可マザーボード/KVMケーブル/KVMの問題、Disk Amber LEDはディスク障害、Postブート時にDelayは マザーボード/ファン/PCI/メモリーの問題、電源不良対策はPSU障害、Teming性能の低下はネットワーク/OS設定の問題、VD Bad Blockはディスク障害、HBA LoopはHBA障害、Raid構成情報が見えないファームウェア/ディスクドライバーの問題、Volume認識不可能なファームウェア/ディスクドライバーの問題、Kernel PanicはOS/Appの問題、最大性能使用時にサーバーリブートはCPU/PSU/マザーボード/メモリーの問題、サーバー処理速度が顕著に遅くなるのはCPU/PSU/マザーボード/メモリー/ディスクの問題、サーバーの電源が入らないのはPSU障害が原因で対応する。
【0154】
以上、本発明をいくつかの好ましい実施例を用いて説明したが、これらの実施例は例示的なものであり、限定的なものではない。
【0155】
本発明が属する技術分野において通常の知識を有する者であれば、本発明の精神と添付の特許請求の範囲に提示された権利範囲から逸脱することなく様々な変更と修正を加えることができることが理解されるであろう。
【符号の説明】
【0156】
110:管理サーバー
112:データベース
120:管理者端末
130:顧客端末
10、20、30、40:管理対象サーバー
【外国語明細書】