vSphere 7検証レポート：vSphere Lifecycle Managerを触ってみた！

情報ガイドステーションメニュー

｜ vSphere 7検証レポート：vSphere Lifecycle Managerを触ってみた！

■目次

・～そもそも「なぜライフサイクル管理」が話題に上るのか？～
・～vLCMで実現できることとその仕様～
・～vLCMの使い方（準備編）～
・～vLCMの使い方（クラスタのイメージ管理）～
・～VxRailとvLCMの違い～

■～そもそも「なぜライフサイクル管理」が話題に上るのか？～

今回はvSphereの新機能としてのライフサイクル管理のお話しになりますが、今やオンプレの主流デザインの１つでもあるハイパーコンバージド（HCI）でもその特徴として「ライフサイクル管理のシンプルさ」が必ず上がります。なぜライフサイクル管理を特徴の１つとして掲げるのでしょうか。

背景にあるのはシステムの複雑化とセキュリティ課題が挙げられます。以下のグラフはシステム管理における時間工数やシステム障害、自動化に関するレポートです。

新しい価値を創出するために労力を注ぎたい、と言う経営層の思いとは裏腹に、現場は現状維持に追われているようです。また、発生して欲しくないシステム障害はシステムそのものの複雑化が影響してメンテナンスそのものの難易度が原因のようです。これらを「自動化」でスムーズに行いたい、と言うモチベーションはあるものの「ブラックボックス」は避けたいと言うのもうかがえます。このあたりは日本人だけでヒアリングすると比率は上がりそうですね。

そもそもですが、なぜシステムのバージョン管理をしなければならないのか、と言うことも認識しておく必要があります。いくつも理由がありますが、大きくは「信頼性の向上」が筆頭にあげられるかと思います。ハードウェアを管理する基礎となるファームウェアのバグがSSDの故障を引き起こした件は記憶に新しいですし、CPUの脆弱性を悪用した攻撃の話しも度々耳にするようになりました。これらを「事前に回避」するためには「適切と判断されている最新のソフトウェア」で運用することが重要です。以前は正常稼働を確認したバージョンで運用を続けた方が安全と言われて、いわゆる「塩漬け」にすることが珍しくありませんでした。しかし、現在は上記のような「事前回避」はもちろん、セキュリティ監査の観点でも適切にバージョンを更新続けることが必要になっていると聞くことも増えました。

この「バージョンを更新する作業」がシンプルでハードルが低く、確実に実行できれば誰もが幸せになれるのは当然ですよね？

■～vLCMで実現できることとその仕様～

当然ですが、上記であげた「ライフサイクル管理のシンプル化」です。これまでもvSphere環境ではVMware Update Managerと言うもので管理はできました。これはあくまでも「VMwareのソフトウェアソリューション」部分が対象でした。今回のvLCMでは対象範囲が広がり、ハードウェア部分（BIOSやFirmware）なども管理できるようになった、と言うのが最大のポイントかと思います。

今回、我々が検証を行ったときに少々やっかいだと感じたのは管理手法が２つある点と、新しい用語の壁です。まず２つの手法についてですが、以下の表の通り「ベースライン」と「イメージ」が存在しています。前者はVUMと同等機能なので今回の紹介からは割愛して、後者の新しい管理手法である「イメージ」に絞りたいと思います。

イメージでのライフサイクル管理のポイントとしては上記の他に以下のようなものが挙げられます。

　● 追加インストール不要（vCenterのサービスとして組み込み済み）
　● クラスタのノード（ESXi）はすべてvSphere7
　● クラスタ内のすべてのノードのハードウェア構成は同一ベンダー, 同一モデル
　● VIB個別の操作は不可
　● 現時点ではvSphere HAやvSANなどvSphereに統合されたソリューションのみが連携対象（アドオンコンポーネントになるvSphere with KubernetesやNSXとの連携はできません）

後程ご紹介しますが、手法として「クラスタに対するポリシー」管理になっているため、同一のベンダー、モデルが求められます。動作内容からすると、もっと言えばハードウェアコンポーネントが同一であることが望ましいと言えるでしょう。

ここでチェックポイントなのですが、うえの方で『ハードウェア部分（BIOSやFirmware）なども管理できるようになった』とお伝えしましたが、すべての環境で実現できるわけではありません。vLCMはソフトウェア部分の管理とハードウェア部分の管理に分かれていることがその理由です。ソフトウェア部分＝vSphereの部分と置き換えてもらえれば良いかと思いますが、当然ですがこれはすべてvCenterの範囲で管理できます。でもハードウェアの部分はvCenterでは管理できませんよね？これはvSphere7でも変わっていません。ハードウェア部分を管理するためのコンポーネントとして「ハードウェアサポートマネージャ（HSM）」が必要になります。このハードウェアサポートマネージャはサーバベンダがハードウェアに合わせて準備するものなので、ハードウェアサポートマネージャが無いベンダーはvLCMでハードウェア部分を管理することが出来ません。我々Dell TechnologiesのPowerEdgeシリーズには元々vCenter Plug-inとしてOpenManage Integration for VMware vCenter（OMIVV）と言うものがあり、これがハードウェアサポートマネージャを担ってくれます。

この記事ではOMIVVのことは割愛しますが、ほんのわずかなコスト追加でハードウェアの物理位置やBIOSのイベントなどをWeb Client上で確認することができるので便利です。詳しくはこの記事を参照してください。

■～vLCMの使い方（準備編）～

準備はソフトウェアとハードウェアの２面それぞれで行います。今回は大まかな流れとポイントに絞ってご紹介します。ステップバイステップでの細かいHow Toについては別の記事で紹介していますので、そちらを参考に作業頂けたらと思います。

ソフトウェアの管理はvCenterのメニューにある「Lifecycle Manager」から行い、「デポのイメージ」と言うものを作成することになります。「デポのイメージ」は基本となるvSphereのインストールISOイメージと、サーバベンダなどが提供するカスタムコンポーネントの塊である「ベンダーアドオン」の組み合わせで構成されます。ハードウェアの管理はPowerEdgeの場合はOMIVVプラグインページから行い、「クラスタプロファイル」と言うものを作成します。クラスタプロファイルにはデプロイ自動化のためのISOプロファイル、BIOS設定を管理するためのシステムプロファイル、そしてドライバやFirmwareなどを管理するリポジトリプロファイルの３つがあります。これらのうち、管理対象としたいプロファイルをセットすればOKです。全ノードで同じBIOS設定、同じFirmwareバージョンで構成することが目的であればシステムプロファイル＋リポジトリプロファイルで構成すればOKです。これがおススメ構成です。

まずはソフトウェア管理として「デポのイメージ」を準備します。

1. vCenterの「メニュー」から「Lifecycle Manager」を選択します。
2. 「インポートされたISO」タブへ移動し、「ISOのインポート」を実行して基本インストールのISOイメージ（カスタムISO含む）をインポートします。
3. 次に「アップデート」タブへ移動し、「アクション」から「更新のインポート」を実行してベンダーアドオンを指定します。

以上のステップで「デポのイメージ」にISOイメージとベンダーアドオンが追加されたことを確認します。

次にハードウェア管理として「クラスタプロファイル」を準備します。

1. vCenterの「メニュー」から「OpenManage Integration for VMware vCenter」を選択します。
2. 「対応性及び導入」タブへ移動します。
3. 任意のプロファイル（システムプロファイルやリポジトリプロファイル）を構成します。
4. 「対応性及び導入」タブ中にある「クラスタプロファイル」へ移動し、準備したプロファイルをどのクラスタへ適用するのか指定します。

以上でソフトウェア、ハードウェアそれぞれの管理情報が整いました。

■～vLCMの使い方（クラスタのイメージ管理）～

ここまで準備できていればあとは任意のクラスタの「アップデート」タブで「デポのイメージ」と「クラスタプロファイル」を組み合わせるだけです。

1. 任意のクラスタを選択します。
2. 「アップデート」タブへ移動します
3. 「イメージ」へ移動し、「イメージのセットアップ」を実行します（最初の１回だけ, ベースライン管理へは戻れません）

4. 「ESXiのバージョン」は「デポのイメージ」へ追加しておいたISOイメージが選択できます。
5. 「ベンダーアドオン」も同様に「デポのイメージ」へ追加しておいたアドオンコンポーネントが選択できます。
6. 「ファームウェアとドライバのアドオン」はOMIVVを選択し、OMIVVで作成したクラスタプロファイルができます。

あとは「イメージのコンプライアンス」で設定した「デポのイメージ」の状態や「クラスタプロファイル」との「差異」をチェックしてくれます。是正したい場合は「すべての修正」を行うことでローリングアップデートが実行されます。

この一連の手順はYouTubeでVMware社が公開している動画があります。英語ではありますが操作の流れは把握しやすいので、一度ご覧頂くと良いかと思います。もちろんハードウェアサポートマネージャとしてOpenManage Integration for VMware vCenterの操作も含まれています。

vSphere Lifecycle Manager (vLCM)
https://www.youtube.com/watch?v=R4NGT12hvSM

■～VxRailとvLCMの違い～

冒頭でお話しした通り、ライフサイクル管理を「一押しポイント」にしている製品と言えばHCIを忘れてはいけません。特に弊社にはvSphereアーキテクチャだけで実装しているVxRailがあります。このVxRailと今回リリースされたvLCMはどのように違うのか？もうVxRailではなく、vLCMが実装されたvSAN Ready Nodesが主力なのか？と言うことも聞かれるので、誤解が無いようにご紹介したいと思います。

確かにvLCMにより、ライフサイクル管理がこれまでよりシンプルになり、ハードウェア層を含めて管理できるようにはなりました。従来手法と比べれば間違いなく「シンプル」ですし便利だと思います。

しかし、VxRailはそのさらに先をゴールとしています。vLCMとは異なり、ソフトウェア/ハードウェアの管理のための準備は一切不要です。必要なのはバージョンアップイメージ１つ（１ファイル）だけです。このバージョンアップイメージはあらかじめ仮想レイヤ以下のBIOSやファームウェア、ドライバなどの互換性チェックが完了しており、お客様での確認は「ゲストOSやそのほかの取り巻くソリューションとの互換性」だけになります。また、サポート契約がProSupport Plus（PSP）で且つリモートサポートツール（ZoomやWebExなど）が利用できる場合においては、バージョンアップ前のチェック作業やバージョンアップ作業そのものをサポート範囲として承ることが可能です。このようなバージョンアップ作業をサポート対応するのは非常に珍しいかと思いますし、「慣れていない」ユーザ様、運用者様にとっては非常に「安心できる」サービスかと思います。

上記は実際には背中合わせのお話しです。VxRailのソフトウェアバージョンは「メーカでセット済み」の組み合わせになるので、細かいリビジョンまでユーザ様で管理したいと言うニーズの場合はvLCMの方が柔軟性があるとも言えます。達成したい目的は何なのか、これが「どちらが望ましい管理手法なのか」を判断するポイントになります。簡単・確実なのであればVxRail、詳細管理まで管理者が判断して処理だけ自動にしたいのであればvLCMと言うわけです。それ以外にも様々な「目的」に合わせて考える必要があるかと思います。

vLCMはリリースされたばかりの機能ではありますが、マルチベンダー環境で「同一手順」で管理できる点や、まちがいなくVMwareソリューションとの連携もあるでしょうから、今後の熟成に期待大だと言えるのではないでしょうか

Dell Technologies ISG DCC パートナーSE
石塚　智規＆片山　倫也
2020/8/13

■目次

■～そもそも「なぜライフサイクル管理」が話題に上るのか？～

■～vLCMで実現できることとその仕様～

■～vLCMの使い方（準備編）～

■～vLCMの使い方（クラスタのイメージ管理）～

■～VxRailとvLCMの違い～

関連記事はこちら

おすすめ記事