VxRail Vxveryにおける iSM is not running事象について

iSMはESXiとiDRACの仲介となるコンポーネントであり、VxRailにおいてはハードウェア監視の仕組みと関係しております。

iSM not running自体は仮想マシンの稼働やvSANの可用性に直接的に影響があるものではありませんので、あくまでも管理系の問題といえます。

iSM自体はVIBとしてESXiにインストールされているサービスですが、iSMの不具合は必ずしもiSM自体のソフトウェア的な問題とは限らず、iDRAC側の問題とも関係していたりもします。

iDRACはPowerEdgeサーバハードウェア上に搭載される小規模な管理コンポーネントですが、サーバ本体に搭載されるCPUや、サーバOSのような可用性設計がされているわけではなく、小規模かつ低電力で稼働するチップとなりますので、どうしても一時的な動作不良などが起こりやすく、iSMの挙動に影響する場合もあります。そのような状況においてはiDRACリセットや簡易放電作業が必要な場合もありますし、iDRACのFirware Updateで改善される場合もあります。

要するに何が言いたいのかといいますと、安定的な稼働を優先されたい場合は、ソフトウェア的にもハードウェア的にも定期的な再起動や、バージョンアップが推奨されます。

VxRailは容易にバージョンアップが可能な製品仕様とサービス設計がされておりますが、VxRail 7.0.480以降では運用支援機能として、ノードのローリングリブートを指定した時間に自動的に実行する機能が追加されています。

過去のシステム設計を踏襲されている場合は、簡単にvMotionが許容されなかったり、業務中の片系運用が許容されない運用ポリシーになっている場合もあるかと思いますが、（HCIに限らず）ノード障害やノードの保守作業に耐えうる設計となっていることがMission Criticalなシステムでは必須かと思います。アプリケーションをマイクロサービス化してモンスターVMを減らしたり、どうしてもそういった対応が難しいサービスレベルの要求が高いVMはシステムを分離したり、といったアプリケーション面での対応も考えられます。

仮想化基盤では様々なアプリケーションを集約できることがメリットの一つですが、集約させすぎて運用ポリシーのANDがとれず、メンテナンスができなくなってしまうと仮想化基盤のメリットも薄れてしまいますので、運用ポリシーに合わせたクラスタ設計も重要です。

ありがとうございます。やはりそうなりますよね。

一点確認したいことがございます。

「iSM自体はVIBとしてESXiにインストールされているサービス」とありますが、これは、Dell が提供しているモジュールと異なるのでしょうか？

iSMがESXiにバンドルされてるものだとすると、他ベンダーのHCI（ReadyNode含め）同じものがESXiに存在しており、各社ServerのBMCの通信モジュールとして担っているとの認識でいいのでしょうか？

@isot196​ 

いえ、iSM自体はDellが提供しているモジュールです。

ESXi 7.0 U3用Dell iDRAC Service Module (VIB)、v5.3.0.0 | ドライバの詳細 | Dell 日本