VMware Cloud on AWSのホスト数がどう数えても１多い
こんにちは、Yos235です。
2022年は、ホントに忙しかったです。
営業から技術部隊の支援に入り、ブログ更新どころじゃなかったからです。
ブログのアップデートがその場でできていたのは、配転前３月末まで。
営業部だと最新情報が入手しやすいけど、実践的な情報を得られるのは技術。
どっちも良いところ悪いところがあるので、どっちがいいとも言えないです。
ま、それはともかく。
今回は、VMware Cloud on AWSで、ElasticDRSで増えたホストをどうやって検知するか
というお題。
コマンドでホスト数を検知することが出来るのですが、なぜか１台多くカウントされてしまうのです（逆・番長皿屋敷状態）
vSphere Client上で、”Model: VMware Mobility Platform" と表示されている謎のホストは、Clusterには居ないけども、ホストとして見えている。。。
それの原因はなんとHCX。HCXのMobility Agentであり、IXのステータスがMAステータスにも反映されるとのこと。ちなみにIXが電源Offになれば、MAのステータスは”NotResponding”になって、カウントされなくなります。
ということで、今回はホストが増えて請求が増える（≒クレジットが減るのがはやい）というのを回避したいのが目的なので、ホスト＋１までを閾値にする、という設計となりましたとさ。めでたしめでたし。
SDDCの奇数番号とアップデート情報の入手
こんにちは、Yos235です。
寒くなってくると指の動きが重いですよね、、、エアコンをケチっているのでなかなかキーボードを打つのが億劫です。
VMware Cloud on AWSの奇数番号はオプションであって、正式リリースではないです。
しかしながら、今後の開発方向性であったり、コンパチビリティ確認には使えるので
以下を確認していると（基盤管理者的には）有用な情報だったりします。
例えば、今回だと、HCXのバージョンは、4.5.2が対象になるようなので、もしかするとオンプレ側も4.5からアップデートしないといけないかな、とかとか。
クラウドサービスを利用していると困るのは、クラウド側はどんどんアップデートしてくれるのは良いんだけども、オンプレ側がねぇ、、、みたいなことなので、この情報を早めにつかんでおくってことも大事かなと思う次第。
がんばれ、基盤管理者！（他人ごとｗ）
今日はこの辺で。
DRSがいい感じにバランスしない
こんにちは、Yos235です。
昔むかし、あるところでDRSを有効にしたvSphere（VDI）基盤がありました。
VDIで不届きものがいたので、同居しているマシンを良い感じに退避してくれて
負荷を分散するってことができる、はずでした。
が、vCenterから見たときに、平準化されてないよね？って気づいた方々も
いらっしゃったようで、それがなんでだろ、と調べたことがあります。
その時の情報がみつかったので、備忘録的に置いておきます。
ーーーーここからーーーー
vCenterで表示されるホストのメモリ使用率にはConsu
DRSのホスト間での偏り計算にはActiveMemoryが使
その違いが（管理者から見た際の）
DRSのAdvancedオプションに PercentIdleMBInMemDemand という値があり
デフォルトの25(%)より大きくすることで、
また、
物理メモリが充分余裕のある状況では100（％）
DRS performs unwanted memory load balancing moves or DPM excessively consolidates memory. (2059868)
> In environments where the memory size of all virtual machines is fully backed by physical memory,
> setting the value to 100 percent is appropriate.
なお、この設定値変更には以下のKBを参考にご確認ください。
Changing the default behavior of Distributed Power Management in vSphere (2059354)
ーーーーここまでーーーー
AcitveMemoryとConsumedMemoryの違いは以下の25ページ目をご覧ください。
vExpert 2022 ★★
こんにちは、Yos235です。
おかげ様で、今年も継続させて頂きました。
星★★ です。
こんな緩いBlogで、すみません。
わからない人にもわかってもらえるように説明する、がモットーなので、
わからない人でもサラっと読めて、もっと知りたい人には
リンクを辿って頂くスタイルで、今後も続けたいと思っています。
今日は、この辺で。
セッションホストでのIP仮想化
こんにちは、Yos235です。
RDSとかRDSHとかWin10マルチセッションとかいろいろな名前で呼ばれる
１つのマシンを複数人で利用するという仕組みがあります。
共有しないといけないことがあって、生成するファイルの保存先を
セッションごとに分ける、であるとか行儀のよいWindowsアプリであれば
いい感じに回避してくれるようにはなりました。（2000年頃は、ねぇ…）
そんな中で一つ知らなかった機能がありました。
IPアドレスの仮想化です。１つのマシンなのでIPアドレスは一つですけど
アプリケーション側でIPアドレスをもとに何らかの判別をするような
システムがあったりすると、ハマる内容でした。
（これでVDI（RDSH）が不採用になった案件があったな・・・遠い目）
とはいえ、注意すべきは、以下２点。
・現時点でWindows Server 2022では未対応
・オンプレミス環境のみ
今日はこの辺で。
VIDMコネクタのサポート期限
こんにちは、Yos235です。
WorkspaceONE（SaaS）とオンプレADの連携をするために
VIDM（VMware IDentity Manager)コネクタが必要です。
によれば、GAが2019-04-16、End of Supportが2021-07-01と記載がありますが
https://kb.vmware.com/s/article/83996
サポートは2022年6月末まで延長されています。（Last Updated: 2021/12/13）
となるとアップグレード先となるWS1Aコネクタのリリースが気になりますが、
Compatibility with Horizon Cloud Service
Workspace ONE Access cloud tenants and on-premises Workspace ONE Access 21.08 appliances are compatible with the new connector.
21.08がコンパチあるらしいですが、
There are some scenarios that are excluded from the new service, however. If you are using Horizon Cloud on IBM or Horizon Cloud on Microsoft Azure with Single Pod Broker the upgrade is not supported, as described in the document Migrating to VMware Workspace ONE Access Connector 21.08.
SinglePodBrokerを使用している場合は除くようです。
つまり Universal Connector にしてからの、 WS1Aコネクタへの移行ですね。
You cannot directly upgrade connector version 19.03 or 19.03.0.1 to version 21.08.
直接アップグレードはできません。
To migrate to the 21.08 connector, you migrate all your directories and supported virtual apps collections.
マイグレーション（移行）をします。
Migration is a one-time process, and you must migrate directories and virtual apps collections together.
アプリケーションコレクションとディレクトリを一緒に移行しなければならない。
If you are using Horizon Cloud Service on Microsoft Azure with Universal Broker, and you have a Workspace ONE Access cloud tenant, you can set up the integration between the Horizon Cloud and Workspace ONE Access tenants from the Horizon Cloud administration console.
HorizonAzureとUniversalBrokerを使っている場合は、クラウドのコンソールから
インテグレーションが可能。
This integration method does not require you to set up a virtual apps collection in the Workspace ONE Access console.
アプリケーションコレクションセットアップは必要ない。（ディレクトリは？）
click Clean Up to perform the clean-up tasks that are required to finish converting the legacy integration to an integration in a Universal Broker environment.
クリーンアップタスクを実行するだけで、統合が完了するらしい。
（ディレクトリは…）
またも中途半端ですが、今日はこの辺で。
WorkspaceONE Access と AD連携
こんにちは、Yos235です。
WorkspaceONE Access を使用してHorizon Azureに接続したい。
オンプレＡＤとの認証って誰がやるんだろう？という疑問がでてきたので
確認してみた。
基本的な構成はこんな感じなのですが、
Table 2: Workspace ONE Access Components
Workspace ONE Access Connector
Responsible for directory synchronization and handles some of the authentication methods between on-premises resources such as Active Directory, VMware Horizon, Citrix, and the Workspace ONE Access service.
You deploy the connector by running the Windows-based installer.
VIDMコネクタは、ディレクトリSyncだけを担当していると思ってたら、
handles some of the authentication "一部の" 認証も実行しているようです。
一方、こちらがHorizonAzureのNetoworkDiagram。
PodManager からKerberos(88)にも行っているし、
WorkspaceONE ComponentからADに行っているし。
個々の認証ってどこがやってるのかな？ってなるのですよね。
さらに読み進めていくと、
Manager VM (PodManager)からKerberosには確実に行ってる。
Kerberos services. Target is the server that contains a domain controller role in an Active Directory configuration. Registering the pod with an Active Directory is a requirement.
シングルポッド構成の場合はPodManagerとWS1ComponentのRelationshipが必要。
In a single-pod-broker configured environment, this connection is used to create a trust relationship between the pod and the Workspace ONE Access service, where the Workspace ONE Access Connector is synched with the pod.
ーーー
Workspace ONE Access Architecture | VMware
こちらのドキュメントに戻ると、、
Deploying a Workspace ONE Access Connector provides the following capabilities:
・Workspace ONE Access Connector–based authentication methods such as username and password, certificate, RSA Adaptive Authentication, RSA SecurID, RADIUS, and Active Directory Kerberos authentication for internal users
最後のfor internal usersの意味合いが難しいのだけど、
「接続端末がEnterprise Network 内にいる」場合の話に見えるんですよね。
ま、いずれにしてもVIDMコネクタが認証しているように見えますね。
となると根拠はないが、WS1との統合がない場合とUniversalConnectorの時は
PodManagerからＡＤへの通信を行っているが、SPB構成はコネクタ経由になる
、、、ってことだろうか。うーん、自信がないな…
中途半端ですが、今日はこの辺で。
