スキップしてメイン コンテンツに移動

エクストリームHoloDeckデプロイ

 

この投稿は、vExperts Advent Calendar 2025の12日目です。


引き続きVCFをなんとか自宅で動かせないかとアレコレ考えています。

ということで、前回のポストまででHoloDeckをデプロイする事前準備までが終わったので、いざHoloDeckのデプロイを実施してみます。


ちなみに、タイトルのエクストリーム○○とは、過激な状況や極限状況などで特定のスポーツやアクティビティなどをすることでして、代表的なもの(?)としてエクストリーム出社があります。


ここでは、「エクストリームHoloDeckデプロイ」を"極限まで少ないリソースのホストにHoloDeckをデプロイする"と定義して、その限界に挑戦した(リソースの都合上せざるを得なかった)記録となります。



大まかな流れは以下の通りです。
    0.今回使用するホストのリソース詳細
    1.HoloDeckデプロイスクリプトの実行
    2.Scriptsの作成と配信設定
    3.動作確認(デバイス側操作でScriptsを実行)


0.今回使用するホストのリソース詳細

私自身HoloDeckを使ってみるにあたり、インターネット上の情報を色々探してみました。

ミニPCなどにデプロイしたと思われるブログポストなども見かけ、これはうちにあるヤツでもなんとかすれば行けるのでは...?と思い至りやってみた次第でして。

ネット上に数多存在する情報の1つとして、手元のミニPCのリソース情報を残しておきたいと思います。
項目備考
筐体Shuttle SH570R8https://shuttle-japan.jp/sh570r8/
CPUIntel Core i9-119008コア 16スレッド
メモリRAM :64GB
NVMe:256GB
RAM 64GB+Memory Tiering機能でNVMeのSSD 256GB(RAMの4倍)
ストレージ
1TBのNVMe SSDMemory Tiering機能でメモリとして使用
1TBのNVMe SSDHoloDeckコンポーネントのデプロイ専用
1TBのSATA SSDHoloConsoleとHoloRouterデプロイ用(前回ポストで実施済み)
ESXi ver.8.0 U3b-


ちなみに、HoloDeckの要件としては、以下になるので全然足りてません。。。笑



1.HoloDeckデプロイスクリプトの実行

HoloDeckデプロイスクリプトを実行する直前までの準備は前のポストまでで完了しているので、さっそくデプロイスクリプトを実行していきます。

まずはHoloConsoleにリモートデスクトップで接続します。



HoloConsole内のエクスプローラで「C:\VLC\VLC-Holo-Site-1」フォルダ配下にある「VLCGui.ps1」を右クリックして「Run with Powershell 7」で実行します。


すると、こんなPowershellのウインドウとHoloDeckデプロイツールのウインドウが表示されるので、「Automated」をクリックします。


まずは「VCF EMS JSON」の入力欄をクリックします。するとファイル選択画面が表示されるので「Holo-Site-1-vcf-ems-public.json」というファイルを選択します。


「CB OVA Location」の入力欄をクリック後、Cloud BuilderのOVAファイルを選択します。


「Prefix for VMs」欄にHoloDeck関連でデプロイされる仮想マシン名の接頭辞を指定します。


「Addtl Hosts JSON」の入力欄をクリック後、「add_3_hosts_ESXi10-12.json」ファイルを開きます。


これでウインドウ左側の設定はあらかた完了したので次はウインドウ右側を埋めていきます。簡単に言うとHoloDeckをデプロイする親となるESXiに接続するための情報を入力し、デプロイ先のデータストアやNWなどを指定する箇所です。

入力が完了したら「Connect」をクリックします。
すると、接続先のESXi上に存在するNetworkやDatastoreが表示されるので、それぞれ適切なものを選択します。


最後に残りの以下を設定し、「Validate」をクリックします。
 -Ext GW:親ESXiの外のNWのGW
 -Ext DNS:外部NWのDNS
 -First 3 Addtl hosts as:None


設定内容に問題が無ければ、ボタンが「Construct!」に変わるので、これをクリックします。


Cloud Builderのインポートが始まるとすごい勢いでデータ転送をしていきます。なんせ30GBほどもあるので。


まずはCloud Builder仮想アプライアンスがデプロイされました。特に何をするわけでもありませんが一旦仮想マシンコンソールを開いてみます。


スクリプトのロギングウインドウに戻ると、Cloud Builderが起動してきて何やら処理が進んでいる模様。


しばらくするとCloud Builderの再起動がかかり、仮想マシンコンソールの画面が変わりました。IPアドレスなどがバナー表示されるようになりました。


何やら処理をするらしく、再びしばらくCloud Builderの疎通待ちです。


子ESXiたちの作成が始まりました。


子ESXiたちのインストールが開始しました。子ESXiは7台います。試しにその中の1つを適当に選んで仮想マシンコンソールを開いて様子を見てみます。


インストールが完了したので再起動すると言ってます。


子ESXiのインストールが完了しました。
事前定義されたJSONファイルに設定情報が含まれているようで、ホスト名やIPアドレスなどの設定も完了した状態になっています。


しばらく待っていると、HoloDeckスクリプトの方でも、すべての子ESXiがオンラインになったのでさらなる設定を始めるよ、というログが出た。


まもなくCloud BuilderのWeb管理コンソールでBring UpのResultが見れるらしい。


HoloConsoleにインストールされているChromeで以下のURLにアクセスするとCloud Builderのログイン画面が表示され、ログインするとDeployの経過が見れるようになりました。
https://10.0.0.221/bringup-result
見始めた時はvCenterのデプロイをしているところでした。


試しに子ESXiの1号機にログインしてみると、vCenterのインポートがモリモリ進んでいます。
見たところvCenterなんていないけどちゃんと進んでるのかなー、なんて思っていましたが、ネスト環境であることを忘れて最初は親ESXiを見てました…


リソースの制約のためか30分ほど時間が掛かりましたが、vCenterにログインできるようになりました。ホストの追加やクラスタの作成とか諸々進んでいるみたいです。


ようやく、分散仮想スイッチの設定まで来ました。まだまだ先は長いです。


続けてvSAN関連の設定が進んでいるようです。


NSX Managerのデプロイが始まりました。


結構時間がかかりましたが、ようやくNSX Managerのデプロイも終わりました。1時間もかかっているのはエクストリーム環境故か。。。


NSX Managerのデプロイあたりで親ESXiのCPUの利用率がエライことになってます。。。画像は100%ちょいですが、見ていた中でのMAXでは150%ほどまで言ったタイミングがありました。


親ESXiのメモリスタッツを見てみるとTier1 Memory(つまりRAMではなくSSDの方)もそれなりに消費されているようです。


NSX Managerのデプロイも完了し、管理コンソールにもログインできました。


SDDC Managerのデプロイが始まった。すでに3時間ほど経過しているがこれ本当に終わるのか。。。


おそらくリソース不足で一時的にハングしたりしたのでしょう。何度かこういうエラーも出ました。


CPUが。。。?


Bring-UPは完了したっぽい!


ただ、HoloDeckデプロイのスクリプトの処理は引き続き何かしている模様。


しばらくするとWorkload Domain用のESXiのコミッショニングが完了して、HoloDeckのデプロイ全体も完了しました。


やっとSDDC Managerの管理コンソールにお目にかかることができました。。。
実はデフォルトのスクリプトや設定ではリソースが貧弱すぎて何度か失敗したので、一部スクリプトのリトライ化数の上限設定やJSONファイルをいじって何度目かのトライでようやっとたどり着けました。本来は不要な内容なのでいじった箇所などは別途紹介できればと思います。(いじった後は何度かやっても失敗しなくなりました。)


以上、エクストリームHoloDeckデプロイ手順でした。
以降はデプロイ後の停止や再起動の手順メモです。

2.HoloDeck環境の停止手順

使わないときは停止しておきたいので、停止と起動の手順もメモっておきます。

まずはNSX Managerをシャットダウン。


続いてSDDC Managerをシャットダウン。


vSANクラスタをシャットダウン。


vCenterがvSANクラスタの中のESXi上にいるけどいいの?と心配されますが、次へ。


次へ。


「SHUTDOWN」をクリック。


この後、vCenter仮想マシンや子ESXiたちは自動的にシャットダウンされます。
あとは必要に応じてHoloRouterやHoloConsoleの仮想マシンをシャットダウンします。


3.HoloDeck環境の起動手順

一度停止したHoloDeck環境の起動手順のメモです。

HoloConsoleとHoloRouterとCloud Builderを起動します。
HoloDeckにおいては、Cloud Builderが実はDNSサーバの役割を兼ねてたりするので起動をしないと正常に動作しません。


MGMT Domainの子ESXiたちを起動します。


勝手にvCenterが起動してくる。(子ESXiの中で)


vCenterの管理コンソールにログインして、クラスタを右クリック後「Restart cluster」をクリック


その後NSX ManagerとSDDC Managerも起動します。


以上、エクストリームHoloDeckデプロイの実施記録でしたが、デプロイしたHoloDeck環境を使ってみるというまでにはまだ至らなかったので、いつかHoloDeckを色々使ってみるということもやってみたいと思います。




コメント

このブログの人気の投稿

Workspace ONE Accessに証明書認証でログイン

Workspace ONE AccessではSaaSなどのサービスへのアクセス管理ができますが、クライアント証明書認証の機能も備わっています。 ここでは、Workspace ONE UEMから配信した証明書を使用して、Workspace ONE Accessに証明書認証でログインする、ということをやってみます。 まずは、Workspace ONE UEMコンソールでの作業です。 すべての設定>システム>エンタープライズ統合>Workspace ONE Access>構成 へ移動し、「 エクスポート 」をクリックしてAirWatch認証局のルート証明書をエクスポートします。 次に、Windows向けにWorkspace ONE Access認証用証明書プロファイルを作成してデバイスに対して配信します。 SCEPペイロードを選択し、「 資格情報ソース 」は「 AirWatch認証局 」を選択します。証明書テンプレートは「 証明書(クラウド展開) 」です。 【補足】 上記のプロファイルで配信した証明書は 秘密キーのエクスポートができない ようになっているため、使い回しを防ぐことができます。つまり、私用のデバイスにインポートし直してログインしてしまおう...ということはできない仕組みになっているワケですね。 次はWorkspace ONE Accessの管理コンソールでの作業です。 IDとアクセス管理>管理>認証方法をクリックし、「 証明書(クラウドデプロイ) 」の設定を変更します。(UEMのプロファイルで選択した証明書テンプレートと同じ名前ですね。若干の誤差はありますが...) 始めに、「 証明書アダプタを有効にする 」にチェックを入れ、「 ルートおよび中間CA証明書 」のところには先ほどWorkspace ONE UEMからエクスポートした証明書をアップロードし、「 証明書の失効を有効にする 」にもチェックを入れておきます。 【補足】 公的認証局であっても、ここでルート証明書をアップロードしない限り証明書認証はできないので、今回の例では Workspace ONE UEM内部の認証局から発行されている証明書以外では認証できない 構成にすることができます。 少し下にスクロールして「 OCSPの失効を有効にする 」にチェックを入れ、「 OCSPレスポンダの署名証明書 」には...

Workspace ONE AccessからServiceNowにシングルサインオン(SAML)

以前、Workspace ONEと他システム間で、 OpenID Connect で連携する内容をポストしましたが、今回は SAML を利用したシングルサインオンの構成を検証してみました。 ServiceNow と SAML連携 して、WS1のポータルからシングルサインオンする構成を試してみます。 大枠の流れとしては以下の通りです。      1.ServiceNow(SP)のSAML認証設定          1.1. WS1 AccessからSAML連携に必要な情報を取得           1.2.SAML認証設定      2.WS1 Access(IDP)でSAML認証設定      3.動作確認 1.ServiceNow側(SP)でSAML認証設定 まずは、今回の構成ではSP(Service Provider)となるServiceNow側でSAMLによるシングルサインオンを可能とするように構成します。 1.1.WS1 Accessから S AML連携に必要な情報を取得 まずは、WS1 AccessのIDPメタデータのURLを取得します。 [カタログ]>[Webアプリケーション]をクリック後、[設定]をクリックします。 左ペインから[SAMLメタデータ]をクリック後、IDPメタデータの[URLをコピー]をクリックします。 クリップボードにコピーされるので、テキストエディタにでも貼り付けておきます。 次に、WS1 AccessのIDP署名証明書を取得します。 左ペインから、[SAMLメタデータ]をクリック後、署名証明書の[ダウンロード]をクリックします。 こんなファイルがダウンロードされます。 1.2.SAML認証設定 続いて、ServiceNow側のSAML認証設定を行います。 ServiceNowの管理コンソールにログインし、検索バーに[saml]と入力後、[SAML2 Single Sign-On]配下の[Certificate]をクリックします。 後で、使用するため先ほどダウンロードした、[signingCertificate.cer]をテキストエデ...

自分のデバイスは自分で管理

Workspace ONE UENにはセルフサービスポータル(SSP)という機能があります。 名前の通りセルフサービスで自身に紐付いているデバイスに対して色々できるポータルで、デバイスのステータスを確認したり、位置情報を確認してみたり、コマンドを実行したりと様々なことができます。 色々できるとなると、逆に誤操作などでデバイスワイプを実行してしまい意図せず初期化してしまったりするのではないか...という懸念が出てきますが、WS1 UEMのセルフサービスポータルではユーザーが実施可能な操作をカスタマイズできます。 例えば、あくまで情報参照用とするためにデバイス情報の表示の権限だけ与えておいたり、紛失したときの対策のために加入解除操作はできるようにしておく、など運用要件によりカスタマイズして利用できるというワケです。 ここでは、加入解除のみを実行できるようにカスタマイズしたSSPにログインし、ユーザー目線で実際に自分のデバイスを加入解除する、ということをやってみます。 実際にありそうなシーンと言えば、あまり考えたくありませんが、夜中に会社支給のデバイスの紛失に気付いてしまったときとかですかね... まずは、Workspace ONE UEMのSSPにログインします。 WebブラウザでWorkspace ONE UEMコンソールのURLの末尾にmydeviceを付けてEnterキーを押します。「https://cnXXX.awmdm.com/mydevice」みたいな感じです。 アクセス後は、ログイン方法などを選択後次ヘ進み、ユーザー名パスワードを入力してログインします。 今回は事前に権限を極限まで絞っているため「 企業情報ワイプ 」のみ表示されていますので、これをクリックします。 【補足】 画像に映っている通り、自分に紐付くデバイスが複数存在する場合もすべてSSPから管理できます。 すると、対象のデバイスで加入解除が実行され、企業データが削除されます。 ちなみに、上記の動作確認ではSSPの権限をかなり限定して企業情報ワイプしかできないようにしてますが、特に権限を限定しなければ「 企業情報ワイプ 」以外にも「 デバイスの位置情報を確認 」など様々なオプションが実行できますし、「 詳細に進む 」をクリックすると... デバイスの順守状態や適切にプロファイルが適用されているか、...