IT or War

背景   諸々の都合で Windows OS の後ろにラボを配置しなくてはいけなくなったのでメモ DNAT 的なことをしたかっただけ。   環境 Windows Server バージョンはたぶん何でもよい。 Windows Server （仮想マシン）から足（ NIC ）を二つ出して、それぞれ External と Internal としている。 External の IP ： Port を変換して Internal ： Port にして転送をする     実施方法 コマンドプロンプトから設定をする場合のシンタックス netsh interface portproxy add v4tov4 listenport= listenaddress= connectport= connectaddress=   実施例： netsh interface portproxy add v4tov4 listenport=443 listenaddress=aaa.bbb.ccc.ddd connectport=443 connectaddress=xxx.yyy.zzz.www 設定の削除方法 netsh interface portproxy delete v4tov4 listenport= listenaddress=   参考（というかそのまま） https://redfishiaven.medium.com/port-forwarding-in-windows-and-ways-to-set-it-up-c337e171086f  

  記事の概要 以下の VMware KB のスクリプトを使ってみて感じた留意事項を記録しておく。 Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN   スクリプトについての簡易説明 既存環境にライセンスを適用する場合、必要となる VVF or VCF コアライセンスと、 vSAN TiB ライセンスの必要数を算出する必要がある。 KB には、そのためのスクリプトと、使い方がが示されている。   以下の点に事前に確認しておく必要がある。 ① PowerCLI 13.3 以降が必要 ② Broadcom はスクリプトの表示結果が適切でなかったとしても責任はもたない。 ③確認対象の環境は既に vCenter で管理されたクラスタである必要がある（未構成 or 購入前のハードウェアに対するチェックスクリプトではない）   ①については PowerCLI に依存するスクリプトであるため当然だが、②については重要である。 仮にこのスクリプトで算出したライセンス数が実際に必要なライセンス数と異なっていた場合、それに伴う損失について Broadcom は一切責任を取らない、と考えるべきである。 そのため、このスクリプトだけで算出するのではなく、ある種の検算も必要になるため、その方法も本記事で示す。   スクリプトの実行方法 詳細な実行方法については KB に記載があるので割愛する。 概要としては PowerCLI をインストールした環境に、 KB 添付のスクリプトをインポートして、既存の vCenter サーバを対象として実行するのみである。 実行時に引数として、利用予定のライセンスタイプ（ VVF or VCF ）を指定する。 VVF と VCF では付属の vSAN ライセンス容量が異なるため、正しく指定しないと正しい結果が得られない。   VVF を指定して実行してみた 以下が実行時の出力である。 最終的な結果として、 VVF が 96 、 vSAN Add-on が 3 となっているが、この解釈...

はじめに vSAN クラスタに異なる IO Rate の負荷をかけてその際の vSAN CPU 使用率について確認しました。     検証方法 vSAN OSA クラスタ（ハードウェア構成についての詳細は規約に抵触する可能性があるため非公開） HCI Bench を利用して、 1 VM あたり 5000~25000 IOPS までの範囲で 5000 IOPS 間隔で負荷を上げていき、その際の CPU 使用率について確認をした   vSAN CPU 使用率の確認方法 Aria Operations で確認します。 詳細については別の記事で紹介しています。     検証結果 検証の順序的にちょっと見にくいですが、 IO Rate 5000~25000 までで比例的に vSAN CPU 使用量が増加していることがわかります。     最大 IO Rate において vSAN CPU 使用率が 24 ％ほどとなっていますが、 この数値を他の環境に当てはめることはできません のでご注意ください。 （ vSAN は 20~30 ％の CPU を利用する、という解釈は間違い） 別の記事でも説明していますが、 CPU 使用率（％）は物理 CPU リソース（コア＊ベース周波数）や、 vSAN クラスタのハードウェア構成にも依存します。 同じハードウェア構成（メモリ、ドライブ、ネットワーク、ノード数など）でも CPU が違えば vSAN CPU 使用率は異なりますし、逆に物理 CPU が同じでも、 vSAN のハードウェア構成が異なれば、最大負荷時の vSAN CPU 使用率（％）は異なります。 本番環境と同じ構成を準備するのは困難と思いますので、もし提案・サイジングフェーズにおいて、 vSAN CPU 使用率の参考値を見積もりたい場合は、本番と同様の IO 負荷の時の CPU 使用量（ MHz ）を、できるだけ類似のハードウェア構成で確認するのが良いと思います。  

概要 Beacon Probing についての相談があったので、調べた内容をメモ。 基本的には利用は避けるべきと判断しています。   Beacon Probing ってなんだっけ？ Beacon Probing は仮想スイッチの Uplink のリンク障害検知手法の一つです。 https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-networking-8-0/networking-policies/teaming-and-failover-policy.html   デフォルトは Link Status Only となっており、いわゆる物理ポートの Up/Down でのみ判断をする方法です。 ただしこの方法だと直接接続のスイッチ（ TOR ）との Link 状態しかわからないため、 TOR スイッチと上位スイッチとのリンク障害時にはなにもできないため、 そのための対策として Beacon Probing という機能があります。 What is beacon probing?   Beacom Probing はその仕様上、ドキュメントにもある通り、 3 ポート以上でないと想定通りの動作となりません。 かつ、 TOR スイッチがそもそも冗長化されていない場合や、複数の TOR スイッチが論理スイッチ構成（ Stack や vPC 、 VLT など）をとっている場合は不要です。     Beacon Probing を検討する際の注意事項   ビーコン検知は 3 ポート /3 switch 以上の構成を想定してデザインされていますので、 2 ポート /2 スイッチでは普通は利用されません。（下記 KB 参照） What is beacon probing?   一応 2 ポート以下でも設定することは可能ではありますが、以下のドキュメントにもある通り、 2 ポート以下での利用は不安定な動作を誘発する可能性があり、単純な Link Down にとどまらず Flapping などのさらなる悪質な障害につながる恐れがあるため、 L...

  背景 想定外停電時など、 UPS と連携して API 経由で自動的に vSAN Cluster をシャットダウンするスクリプトを作成したい。     参考サイト PerformClusterPowerAction vSAN Management SDK for Python     スクリプトの解説 vSAN Management API にある PerformClusterPowerAction を利用することで、 vSAN の機能を利用したクラスタシャットダウンを API で実行できる。 実際のコードは vSAN Management SDK for Python パッケージ内にある vsanclustershutdownsamples.py をほぼ丸々利用する。   ただし、このスクリプトはそのままでは Self Managed vCenter 環境（ vSAN クラスタ上に vCenter がいる構成）のシャットダウンをすることができない。 なぜならば、スクリプト内の ClusterPowerOffPrecheck にて、 Self Managed vCenter 環境ではエラーになってしまうためである。 そこで、ヘルスチェック結果でその項目だけ正常（ green ）以外のステータスを許容するように少しだけスクリプトを書き換える必要がある。   スクリプト実行環境 Ubuntu 24.04.2 Python 3.12.3   シャットダウン対象クラスタ情報 vSphere   8.0.3, 24585383 vSAN ESA ４ノード環境 vCenter Server のみが起動している状態（それ以外の VM は事前に停止しておく） DNS/NTP などの必須の環境サービスは vSAN クラスタ外で健全に動作しているとする     スクリプトの準備と実行手順   まずは必要な Python SDK for the VMware vSphere API （ PyVmomi ）をインストールする   # pip...

  概要 vCenter 8.x を Reduced downtime Upgrade で 9.0 にする     参考 vCenter Server upgrades with the reduced downtime [TAM Blog] Reduced Downtime Upgrade （ RDU ）機能のご紹介（ Part1 ） - VMware Japan Blog [TAM Blog] Reduced Downtime Upgrade （ RDU ） 機能のご紹介（ Part2 ） - VMware Japan Blog       Reduced Downtime Upgrade （ RDU ）とは あたらしい VCSA のアップグレード方式です。 従来の手法と比べて vCenter の再起動やデータ移行に伴うダウンタイムが短縮されており、 より簡単に負担なくアップグレードができるようになっている。   従来の方法は UI での操作手順も異なる。   今後はこの方法が主流となり、従来の方法は廃止される予定となっている。   まずはダウンロード   Broadcom Support Site から vCenter の ISO をダウンロードする Installer と同じ ISO を利用する     vCenter 8.x までは、 My Download から vCenter で検索すると簡単に見つかるが、 vCenter 9.0 は Vmware Cloud foundation で検索して、 Vmware Cloud Foundation の中で vCenter を探して掘り進んでいくと見つかります。         ISO ファイルをデータストアに配置する   何とかダウンロードした ISO ファイルは VCSA にマウントする必要があるので、その前段階としてデータストアに転送します。 VCSA をホストする ESX からアクセスできる...