HPE InfoSight実機検証レポート

クラウド上の機械学習で高可用性を実現するHPE InfoSight
HPE 3PAR StoreServでの利用に関して実機で検証

一般的な3-Tierのシステムを構成し障害発生時の対応を検証

　この検証が行われたのは2018年12月～2019年1月。HPE 3PAR StoreServを使用した3-Tierのシステムを構成し、そこで物理的な障害を発生させ、HPE レスポンスセンターの対応が確認された。ハイパーバイザーを動かすノードは3機用意し、そのうち1台は管理ノードとして使用。これらとストレージをつなぐネットワークとしては、ファイバーチャネルSANスイッチが用意された。

　　「物理的な障害を発生させる方法としては、HPE 3PAR StoreServの電源モジュールの抜去を行いました。」と説明するのは、横河レンタ・リース システム事業部 エンジニアリング システムエンジニアの平野 誉士。予想外の電源停止を起こすことで、HPE レスポンスセンターへと通知がいくようにしたという。これを、従来のHPE 3PARリモートサポートに接続したHPE 3PAR StoreServと、HPE InfoSightに接続したHPE 3PAR StoreServの両方で実施し、HPEレスポンスセンターからの連絡時間と連絡内容を確認したのである。

　「ここで注意していただきたいのは、手動による意図的な障害であるため、HPE InfoSightの機能である『障害の予兆検知』の対象外となるということです。そのためHPE InfoSightに障害情報が通知されても、AI活用による対応の迅速化は期待できません。ここで検証しているのはあくまでも、HPE InfoSightがリモートサポートのプロセスに加わることでサービスレベルが落ちないのか、ということです。」
　このような検証は、従来のHPE 3PAR リモートサポートへHPE InfoSightのプロセスが加わる際の不安を解消する上で、重要なものだといえるだろう。ここで同様のサービスレベルが担保されるのであれば、不安なくHPE InfoSightへと接続できる。その後、機器稼働に関するデータが蓄積されれば、AI活用の効果も期待できるようになる。

連絡時間と連絡内容はHPE InfoSightの有無で変化なし

検証結果は以下の通りである。

• HPEレスポンスセンターからの連絡時間
  　イベント発生から数時間内で連絡が届いた。これは従来のHPE 3PARリモートサポートとHPE InfoSightで同様だった。つまりHPE InfoSightへの接続は、HPE レスポンスセンターのサービスレベルには影響を与えていない。
  　「最初のうちは短時間で連絡をいただけたのですが、検証を繰り返すうちに連絡時間が長くなりました。これはイベント内容をレスポンスセンターで検討し、連絡すべきか否かを判断しているからだということです。」（平野談）

• HPEレスポンスセンターからの連絡内容
  　連絡を受け取った時の内容は「xx時yy分に電源モジュール#zzがダウンしたアラートを受信しました。何か計画作業等実施されておりますでしょうか。」という内容だった。これもHPE InfoSightへの接続の有無で変化はなかった。また、連絡内容からHPE レスポンスセンターがこちらの状況を的確に把握していることが推測される。

　なお、HPE InfoSight接続後のHPE レスポンスセンターの流れは、以下のようになっていると平野は説明する。

　エラーが検出されると、まずHPEレスポンスセンターへとアラートを送信。これと並行してHPE InfoSightへもデータが送信される。
　HPEレスポンスセンターでアラートを受信すると、保守契約内容に合わせて修理受付番号が発行され、アラート情報から1次診断が実施される。HPE InfoSightに接続された場合には、これら一連の処理がAIによって実行されるようになる。
　その後は、前述のようにHPE レスポンスセンターからの連絡により、1次診断結果の報告と、オンサイト訪問日の調整が行われる。ここから先は、HPE InfoSightの有無による差異はない。また、必要に応じてリモートアクセスによる追加診断も実施される。
　つまり、実際に障害が発生した場合の対応プロセスは、HPE InfoSightへの接続によって大きく変化しないことが理解できる。HPE InfoSightで大きく変化するのは、障害発生前の予兆検知や、それにもとづく予防保守が可能になることなのだ。従って、HPE InfoSightへ移行しても、HPE レスポンスセンターのサービスレベルが低下する不安はないといえる。