投稿

vSAN 環境のローリングアップグレードの部分的な実行について(vLCM利用)

イメージ
 調査目的 vSphere LCM (vLCM) の機能を利用して、クラスタ内の一部のみをアップグレードすることができるのか。 調査背景 VMware vSAN環境においては、ESXi あたり2時間程度のUpgrade時間が見積もられることが多い。 管理VMのUpgradeや事前事後の作業も含めると、10ノードくらいのクラスタであっても、Upgrade完了まで24時間程度見積もっておく必要がある。 しかしながら、環境によってはそんなに長いメンテナンスウインドウをとることができないケースもある。 補足:vSphere/vSANとしてはUpgrade中であっても仮想マシンの可用性は維持できるため、メンテナンスウインドウは必須ではないのだが、ユーザのポリシーによっては稼働中のメンテナンス自体が禁止されていたり、vMotionによって発生するわずかな VM Stun や遅延を嫌う場合もある。 調査結果 vLCMのImage適用はESXi単体で実施できるため、操作としてクラスタの一部のESXiのみをアップグレードすることは可能である。 ソース: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere-lifecycle-manager.doc/GUID-26EB282E-AD1E-425A-B4CF-1D70C0DE3C8F.html 引用 You can remediate a single  ESXi  host or multiple hosts in a container object. You can initiate remediation at a folder, a cluster, a data center, and even  vCenter Server  level. https://juku-jp.vmware.com/resource/form_307/   ただし、VMwareとしては推奨をしていない(上記、VMware社主催セミナーのQAに基づく) vSANを利用したHCIアプライアンスとしてVxRailがある。VxRailは独自のLCM機能を実装しておりVxRail LCMの範囲ではクラスタの部分的なアップグ...

vSAN ベース HCI VxRail のEVCモードのデフォルトはHaswel

事象 VxRailを構築した直後にEVCが自動で有効化されている or されていない件についての問い合わせ。 仕様について 過去のドキュメントでは明確に記載されていたが最近のドキュメントではEVCに関する仕様が省略されてしまっている模様。 VxRail は旧CPU世代および旧サーバ世代との混在を想定した設計となっており、旧世代のCPU機能がデフォルトのEVCとなっている。 そのため、VxRail構築直後にHaswelでEVCが有効化されているのは仕様である。 もしEVCが構築直後に有効化されていなかった場合は、何らかの失敗が発生していた可能性があるのでサポートに問い合わせた方が良い 補足 鋭い人なら疑問に思うかもしれない。 VxRailは、最初の状態ではESXiも設定されておらず、vCenterも存在しない。 初期構築の過程でESXiにIPが振られ、vCenterがデプロイされ、その後vSAN クラスタを形成していく。 ここで一つ問題がある。EVCを設定するのは当然vSAN(vSphere)クラスタ構築後になるのだが、その時すでにvCenterが稼働しているため、EVCで古い世代を指定することはできないのではないか?ということである。 これに対する回避方法として、以下が考えられる。 1.vCenter起動時に Per VM EVCを設定する 2.vCenterが稼働しているESXi以外で先にクラスタを組み、EVCを設定した後でvCenterを移動させる VxRailは1の方式は使っていない。なぜならばPer VM EVCがサポートされるよりも前から存在している製品だからである。 実は2の方式でもない。VxRailのクラスタセットアップのフローとして、まずはvCenterが稼働するESXiでvSphere クラスタを組み、あとから 順次Add Host していくという手順でクラスタを構築しているためである。 では、正解は何かというと、実は1の方式に近い。 VxRail は Per VM EVC という機能が追加されるよりも数年前から、仮想マシンの設定値をいじることで疑似的なPer VM EVCを実現し、それを用いてVxRail クラスタを構築していたのだ。

Nutanix AHV から VMware vSAN 環境への移行に関するメモ

調査目的 vSphere 環境からNutanix AHV への移行は Nutanix Move を使うことで簡易化ができる(ダウンタイムは必要) 逆に、AHVからvSphere/vSAN 環境に移行したい場合はどうなるのか? 調査結果 調査といってもググっただけだが以下のことが分かった。 実際にラボで試したわけではないので確認が不足しているかもしれない点はご容赦ください。(そもそもメモなので) ・少なくとも無償のツールやサービスの範囲では、Nutanix Move 相当の機能を持つものは存在しない。 ・CLIを使った手動の方法によって、仮想ディスク単位で変換をすることは可能 ・変換後の仮想ディスクはVMDKファイルであり、そのままvSANにコピーすることはできないため、いったんVMFS環境に保存したのちにvSAN DataStoreに移動する必要がある。 ・ベンダーやSIerが提供する有償サービスで可能な場合も考えられる。 以上のことから、vSphere/vSANからNutanix AHVに移行するのは簡単だが、出すのは非常に面倒でハードルが高いことが分かる。 入れるのがいいが出すのが難しい、という特徴は一部のクラウドサービスでも同様であり、オンプレ回帰と呼ばれるモーメンタムを生む一因にもなっている。 Nutanix の場合はクラウドサービスのように思ったよりコスト高になったり、障害時の対応に不満が残る、といった追加のデメリットはない(妄想)とおもうが、出し入れが容易に越したことはない。 ベンダやSIerが提供するData Migrationの有償サービスにおいても、私が調べたベンダに関しては、Hyper-VとvSphere間での移行は提供していたが、AHVは含まれていなかった。

vCLS VMの操作権限を取得する方法

以下の VMware doc 記事にあるように、ServiceProviderUsers グループに参加させることで、vSphere with Tanzu のインフラ管理権限が取得できる。これにより、通常の権限では操作できない Control Plane VMの操作ができるようになる。 https://docs.vmware.com/jp/VMware-vSphere/7.0/com.vmware.vsphere.authentication.doc/GUID-87DA2F34-DCC9-4DAB-8900-1BA35837D07E.html 実はServiceProviderUsers グループは vSphere with Tanzu のインフラ管理ができるだけではなく、vCLS VM の操作権限も持っている。 そのため、下記手順のように新規ユーザ  (例:podAdmin@vsphere.local) を作成し、 ServiceProviderUsers  グループに参加させることで、通常は操作できない vCLS VM の操作ができるようになる。 1) vSphere clientにadministrator@vsphere.localにログイン 2) ホーム > 管理 > Single Sign-On > ユーザおよびグループ にて 3) vsphere.local ドメインで  追加ボタンで podAdmin ユーザ 追加します。 4) グループで 検索にて service を検索し、  ServiceProviderUsers グループ をクリックし、メンバーに podAdminを追加します。 5) 左側の アクセスコントロール > グローバル権限 > ユーザとグループで VSPHERE.LOCAL/podAdmin を選択し、    上の鉛筆アイコン(ロールの変更)で 「システム管理者」 を選択、 子への伝達にチェックをいれて、OKボタンを保存します。 SupervisorControlPlane VMと vCLSは操作可能であることを確認してください。 以上。

vSphere仮想化基盤にTPMって必要なの?

イメージ
※このBlogは、 vExpert Advent Calendar 2022 の12/4 の記事として投稿しています。 (体調不良にて投稿が遅れてしまい申し訳ございません。) はじめに TPMという部品をご存じでしょうか? 正式名称は Trusted Platform Moduleです。  おそらくですが多くの vSphere ユーザの方はこれまでその存在を深く考えたことがないのではないかとおもいます。  確かにこれまでは、vSphere 6.7 以前は TPM という存在をvSphere 側で意識することはありませんでしたし、6.7以降であってもvSphereとしてのコアの機能とは 縁の薄い部品だったと思います。 しかしながら、今後はユーザ側もある程度の TPM に関しての知識が要求されるかと思われます。主な理由は以下の2つです。 Windows11で TPM が必須  vSphere 8 で TPM 1.2 が非サポート 本投稿は、Windows11を実行する仮想マシンのデプロイや、vSphere 8 へのアップグレードというイベントに備えて、TPMがどういった機能を提供するものなのかを簡単にご説明することを目的としています。 Trusted Platform Module とは Trusted Platform Moduleとは、端末認証を安全に行うために必要な機能が搭載されているICチップです。マザーボード上に搭載されています。 具体的には以下の機能を持ちます。 - RSA暗号の演算・鍵生成・格納 - 乱数生成 - ハッシュ演算・ハッシュ値保管など 端末認証での利用を想定しているため、基本的にマザーボードに一度取り付けたら外すことは二度とありません。(例外もあります) そのため、マザーボードを交換する場合はTPMもセットで交換します。 Windows 11 ではTPMが必須とされたことで、TPMという言葉を聞いたことがある、という方は多いかと思います。 逆にいえばそれまでのWindowsにおいては必須とされていませんでしたし、物理サーバ側としてもオプションパーツとしての位置づけですので、上位のOSやアプリから要求されなければ必ずしも必要ではありません。 vSphere環境においても、お客様が明示的にTPMを利用したいと...

VxRail クラスタ起動時のタイムアウト値について詳細調査

 イントロ VxRail は、VxRail クラスタShutdown機能を利用してクラスタをシャットダウンすると次回起動時に自動的にメンバーノードのメンテナンスモードが解除され、vSANが再度有効化されたのちにSystemVMが自動で起動するようになっている。 起動時に上記の動作を提供するスクリプトが仕込まれており、それは以下のスクリプトファイルである。 /etc/rc.local.d/998.start_vm.py このスクリプトには上記の動作を安定化させるためにいくつかの待機フェーズが仕込まれている。この記事では、スクリプト内で利用される各待機フェーズにおけるタイムアウト値を調査した 免責 本記事内容は、7.0.320 で稼働するノードの該当スクリプトを解析しています。 調査結果についてはベストエフォートであり、必ずしもその正確性や網羅性を保証するものではありません。 スクリプトの動作を確認 スクリプト内で以下の部分がメイン関数であるとわかる      546 def main():     547     parser = argparse.ArgumentParser()     548     parser.add_argument('-d', dest='debug', help='Debug mode (no run in background)', action='store_true')     549     550     args = parser.parse_args()     551     if not args.debug:     552         daemonize()     553     do_start_vms() do_start_vms という関数が呼び出されている     422 def do_start_vms():...

VMwareに先行したVxRailの優秀な機能

 VxRail LCM VxRailを代表する優秀な機能です。VxRail ManagerがvCenter(内部型に限る)とESXi とハードウェア関連(Driver/Firmware)のコンポーネントを一元管理のもとUpgradeします。Upgrade前後の互換性やUpgrade手順はすべてDellによって動作検証済みであり、ユーザによる事前の動作検証や手順確認を必要としません。 一方でvSphere/vSAN観点では、VxRail LCM から遅れること約4年後の2020年にvSphere LCMという機能をリリーしました。vSphereで管理できないハードウェア関連コンポーネントは、各サーバベンダが提供するHSM(Hardware Support Manager)と連携することで一元バージョン管理を実現しています。 しかしながら、vLCMはvCenterやHSM自体のUpgradeが含まれません。手順の最適化やUpgradeファイルのパッケージ化など様々な面でVxRail LCMのほうが機能面・品質面でも先行し続けています。 vSAN Cluster Shutdown こちらもVxRailが当初から提供している機能です。VxRail 上の管理VM(VxRail Manager や vCenter)を含め、vSAN Clusterを安全に正しい手順でシャットダウンします。 VxRailのリリース初期のころは、またVMwareのvSAN自体がそれほど世間から認知・浸透しておらず、通常の3Tierと同じ手順でShutdownしてしまった結果、Shtudownできなくなったり、アクセス不可となるような事例もしばしば目にしました。しかしながらVxRailであればそういった心配なく誰でも簡単に正しい手順でShutdownができます。 あまり知られていませんが、VxRail Shutdown機能はShutdownだけでなく、PowerUp時にも活躍します。Shutdown時と同様にPowerUp時もvSAN特有の手順や考慮事項が必要になりますが、VxRailであれば、サーバの電源ボタンを押すだけで自動的に、① ESXi の起動の待ち合わせ~②メンテナンスモード解除~③vSANの有効化~④管理VMの起動、が実行されます。 一方で、vSphere/vSAN観点でこの機能...