仮想化技術の個人的ニュース

仮想化技術の個人的に気になること

Control Upを利用した運用②

こんにちは。

 

今回は
「Control Upを利用した運用」
の件でお話をさせていただきます。

 


今回は前回「Control Upを利用した運用①」、

hatayu0421.hatenablog.com

の続きで、備忘録含め情報共有として書かせて頂きます。

 


今回は、ControlUpを実装してリソースのトレンド把握のために
使用する「ControlUp Insights」をもう少しご紹介していきます。

 

『過去の単位期間あたりの負荷状況であったり、
割り当たっているリソースがゲストに対して適切なのかどうかという情報も
ここで判断が可能です。

尚、Insightsではレポートを作成することが可能で、
一部にはなりますが自動化して定期的にレポーティングすることが可能です。』

まずは前回記載していた上記の事項から実際の画面を交えての説明となります。

 

  • 過去の単位時間あたりの負荷状況

左ペインより「Reports」>「System Health」>「Computer Trends」を選択することで負荷状況を見ることができます。

選択できる単位(期間)としては、右上にある通り「4H」、「24H」、「1Week」、「1Month」、「1Year」です。

 

左ペインより「Sizing Recomendations」を選択することで負荷状況を見ることができます。

コンテンツの左側がCPU、右側がRAMになっていますが、
この環境はVDI環境のために基本的にはユーザさんが使う(処理している)
タイミングだけリソースが使われるためかOver Sizeだといわれているものが多いですね。
(画面内の円グラフのオレンジ(赤)の表示)
ちなみに画面にはあまり表示されていませんが、グラフの下に各マシンに対する推奨値などなどが表示されています。
(メモリが〇GBが適正だからxGB減らす(remove)方がいいですよ、、、などなど)

 

  • レポート作成

レポートの作成は、画面の右上にある「Export」を選択することで行えます。
出力形式はCSVかPDFになります。
制限事項として、1000行までしか出力されませんので注意が必要です。


本日はここまで。

ご参考になれば、幸いです。

Horizon Universal Console の管理者ログインについて

今回は
「Horizon Universal Console の管理者ログインについて」
の件でお話をさせていただきます。

 

今回、既にHorizon Cloudを導入済みのお客様にて運用変更があり、
これまでグループアドレスで登録していたCustomer Connectの
ログイン情報ではなく、各個メールアドレスのCustomer Connectの
ログイン情報を使用した上で、二要素認証を有効にする必要があり
発覚した問題(制限事項)でした。

 

端的にいうと、Horizon CloudへのCustomer Connect ユーザの
紐づけはシングルテナントにしか行えません、、、。

 

実際にやってみた結果、、、

このように上部にエラーメッセージ
(My VMware アカウント設定を更新できません)
が表示されます。

 

この件、
メーカのサポートの方に問い合わせた結果、
一人のユーザ(メールアドレス)を複数のテナントに
紐づける(複数のドメインを管理する)ことは
想定していない、、、とのことでした。

 

同じVMware様のCloud Services Consoleでは、
(Workspace ONEであったり、VMware Cloudなどの管理をする、、)
普通に複数テナントを扱えるようになっているのに、
困りますね、、、。

 

結果。
無理を言っても仕方ない、、、ということで、
このアカウントをこのお客様のテナントで使うことは諦め、
別の方法で運用していくことを検討することになりました。

 

ちなみに、
Horizon Cloud 以外にも、Carbon Black についても同様に、
どこか別のお客さんに登録していると、
登録できない様です。(こちらは画面を撮れてませんが、、、。)

海外ではSIerというのはあまり一般的では無く、
ユーザ企業のエンジニアが自身でやってらっしゃるという話も
耳にしたことがありますが、日本の商文化?が少し世界と異なるから
なのですかね、、、。

 

本日はここまで。

ご参考になれば、幸いです。

Control Upを利用した運用①

今回は
「Control Upを利用した運用」
の件でお話をさせていただきます。

 

Control Upを導入している自社メンバーの話を聞いていて、
面白そうだと思ったという点と、
V4Hの後継を探さなければいけないという点から
自分自身でも、Control Upを案件に投入することにした、、、
という経緯があり、本記事を備忘録含め情報共有として
書かせて頂きます。

 

今回、取り上げるControl Upは基本として、
VMware社もV4Hの後継として、紹介(推奨?)販売していると思うのですが、
基本的には仮想デスクトップ環境のリソースなどのトレンド分析に
適した製品という位置づけだと考えています。

 

実際、
出来ること、、、としては、
①リアルタイムでの各デスクトップ(仮想マシン)の状況分析
②蓄積したログからの過去状況を含めた状況分析
③状況に応じたジョブをトリガーで自動実行環境の提供
これらが行える製品の様な気がします。

(③の「トリガーで自動実行が一番の売りだ!」とは
 自社のメンバーOの一押しポイントなんですが)

 

そんな製品ではあるのですが、
今回利用する目的としては、
運用監視+リソースのトレンド把握としての使い方
(①、②)なので、その辺をどう使っていけるか、
という点でご紹介させて頂きます。

 

実際の画面としては、
下の写真の「ControlUp Management Console」

こちらで、(ほぼ)リアルタイムでの状態確認を行います。

具体的には、(実環境なので黒塗りにしてしまってますが)
右ペインで対象のデスクトップを選択してそれぞれの
リソース負荷(CPU、RAM、Disk、Network)であったり、
リソースを消費しているプロセスの上位の物を確認することが出来ます。

また、このConnsoleでは、マシンの状態を視覚的かつ感覚的に
分かるように、問題のある物は赤く表示されます。
(この環境では全体の展開台数が多いので環境全体としての負荷が高いと
 上の方で赤くなっています)
尚、このConsoleでは重要視したい監視(?)項目を
カスタマイズできるので、環境によっては無視していい物は
Stress Levelとして検知させずに赤くなるレベルを調整することも可能です。

 

続いて、
「ControlUp Insights」。

こちらの方で、前述のリアルタイムに見ていたデータを
統計的に情報を見ていくことが可能です。
過去の単位期間あたりの負荷状況であったり、
割り当たっているリソースがゲストに対して適切なのかどうかという情報も
ここで判断が可能です。

尚、Insightsではレポートを作成することが可能で、
一部にはなりますが自動化して定期的にレポーティングすることが可能です。

※Insightsの詳細については次回深堀していきます。

 

本日はここまで。

ご参考になれば、幸いです。

ディスク統合が必要・・・と表示される警告

今回は
「ディスク統合が必要・・・と表示される警告」
の件でお話をさせていただきます。

 

今回主題にしたいのは、
VMwareのvSphere87とHorizon8の環境において、
インスタントクローン(Instant Clone)を展開する際の話で、
2023年2月にリリースするために準備していた環境で
監視を有効にした後に気が付いた点の情報を共有したいと思います。

 

今回、気が付いた話なのですが、
Horizon環境においてインスタントクローンのプールで
デスクトップを更新する(が更新される)と、、、
アラート(Critical Alarm)がよく発生するな。。。と
気が付いたところから調べてみた話です。

 

この問題の発生したエンドユーザ環境では、
メールにてアラートを通知しているのですが、、、。


デスクトップの更新が掛かるタイミングで通知がよく来る、
状況を確認するために環境を見てもアラートすら存在していない。。。
(メール通知があった該当のマシンをみても、アラートの存在すらない。。。)
という状況で、かなり不可思議な話でした。

 

その様な状況で、判明した事象として、

「スナップショットを保持した仮想マシンをvSphere上から削除しようとした場合、
 vSphereは『仮想マシンのディスクの統合が必要です』フラグを立てる」

ということが判明しました。

 

理屈が判れば、「なるほどね。」な話ですが、

このユーザ様のHorizonのInstant Cloneは

スナップショットを保持していて、ユーザがログオフするタイミングで

リフレッシュ(マシンの再作成)が行われるタイミングで、

仮想マシンが削除されるから、繰り返しゝゝゝゝ

掲題の「ディスク統合が必要」というアラームが出る。

そう言った仕組みでした。

 

ひとまず、

これらデスクトップのマシンに対しては、

アラート(Critical Alarm)をメールで通知しないようにする方法が

メーカサポートの推奨でもあり無視して運用してくださいと言われているので、

上記の方法で一旦は回避する方針とするつもりです。

 

本日はここまで。

ご参考になれば、幸いです。

Horizon Cloud on Azureを構築する際に起こる問題

こんにちは。


今回は、

Horizon Cloud on Azureを構築する際に起こる問題についてご紹介します。

 

とはいえ、Horizon Cloud 単体で起こる問題ではなく、On-PremiseのHorizon環境とHorizon Cloudを並行して構築する際に起こった話。。
と、かなり限定的になる話ではあるのですが、
同じ問題で困っている方の助けになれば幸いです。

 

だいぶ端折って書きますが、Horizon Cloudの環境を準備する際、
Horizon Universal ConsoleでAzureのSubscription関連の情報を登録した後に
Pod(Pod Manager)をデプロイし、
ドメインと連携するためにActive Directoryの登録、
マスター作成→デスクトップ(プール)の展開となります。

 

今回、問題になるのは「Active Directoryの登録」、ここです。

 

On-Premise側からコネクタでライセンスの確認など一度でも連携すると
クラウドOnlyで構築しているときは手動で入力できるドメイン名のところが
選択しかできない状態となります。

 

そのため、コネクタからInternetに接続できなかったりして
正常に通信できない状態だと、
On-Premiseの環境からドメインの情報を正常に取得できずに
選択しようにも空白(何も表示されない)しか選択できず、
さらに手動で入力もできないという問題が発生し、
Horizon Cloud の構築作業が進まなくなります。

本当に、、、納期間際でどれだけ焦ったか・・・。

 

解決方法は、、、コネクタを使えるようにして、
On-Premiseの情報が正常に連携できるようにすること。

On-Premiseのポッドを消せませんか?と聞かれたりもしましたが、
On-Premiseの方がオフラインになってしまっていると、
On-PremiseのポッドをHorizon Universal Consoleから削除もできないので
必然的にコネクタを直すしかないという訳です。

 

本日はここまで。

ご参考になれば、幸いです。

Horizon Cloud on Azureで変わっていたこと

こんにちは。


今回は、

Horizon Cloud on Azureで変わっていたことについてご紹介します。

 

これまでに複数の環境に
Horizon Cloud on Azureを導入してきましたが、
Horizon Universal Consoleから作成していく
Pod Managerとゲートウェイ(Unified Access Gateway)があります。

 

今回ご紹介するのは

Pod Managerとゲートウェイ冗長化構成でしか

構成できなくなっていた、、、ということです。

 

本番環境としてHorizon Cloud on Azure を利用するのであれば、
そもそも可用性を高めるために冗長化しておく(と思う)ので、
大した影響ではないですが、

DR環境としてであったり、検証(Proof of Concept)環境だったりすると、
可用性の要件がないことがしばしばあり、
「コストをあまり掛けたくない」と、そういった声をよく聞きます。

 

具体的には、

昔はPod ManagerもUAGもシングルで構成できたと認識しているので、
Pod Manager1台分とUAG1台分、さらにロードバランサのリソースが追加で必要となります。

 

2022年11月時点のAzureの価格では、
Pod Manager(D2v3):¥94,234-
UAG(A4v2):¥76,144-
ロードバランサ:¥3,395- × 2
合計:¥177,168-

くらいの差が出て、追加で必要となります。

(上記は、あくまで概算です。
 条件としては、管理システムであるため仮想マシンは停止せずに
 月730時間稼働し続ける想定での月額です。)

 

このことをきちんと踏まえて冗長構成での
提案をしていないと、DR環境だったりして5年間の累積では、、、
1,030万円ほど上振れする話になりますのでご注意ください。

 

ちなみに、、、
最新バージョンでは、

高可用性の項目はありますが、、、
触れない、カーソルを合わせても操作できない仕様となっています。。

 

本日はここまで。

ご参考になれば、幸いです。

VxRailおすすめポイント

こんにちは。


今回は、Dell社とVMware社が共同開発したDell VxRailをご紹介します。

 

 

VxRailの特徴としては、

① メーカー検証済の安定基盤を提供

  Dell社によるハードウェア/ファームウェア/ソフトウェア(vSphere/vSANなど)
  検証済の環境を提供

② 簡単アップグレード

  わずかな操作で無停止のアップグレードが可能(vCenterもアップグレード対象)

③ 無償アップグレードサービス 
  Dell社の専任エンジニアがエンドユーザに代わってリモートアップグレードを
     無償で実施

 

ここで一番のポイントとして、③の無償アップグレードサービスです。

アップグレード範囲は、ハードウェアのファームウェアやVxRailの管理サーバだけでなく、vCenter/ESXiも対象ということです。かつDell社が事前検証済で安全なアップグレードが可能です。

 

昨今、VMware Cloud on AWSの利用を検討する企業では、vCenterやESXiのソフトウェアの維持管理に関わる運用負荷を軽減されたいと思っている情シスの方は多いのではないのでしょうか。

 

何らかの理由により、マネージドサービス(VMware Cloud on AWSなど)を採用できず、オンプレミスによる利用が必要で、且つソフトウェア維持管理の負担を軽減したい場合は、VxRailをご検討してみてはいかがでしょうか。


簡単ではありましたが、VxRalがどのような点で優れているかお分かりいただけたのではないでしょうか。

 

本日はここまで。

ご参考になれば、幸いです。