IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ジニエイアイ カンパニー リミテッドの特許一覧

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