IT or War

概要 仮想マシンのストレージポリシーを Thick プロビジョニングから Thin プロビジョニングへ変更したとき、vSAN データストアの使用容量は本当に減るのか。vSphere Cluster 8.x の実機で、Snapshot が絡んだ場合の挙動まで含めて検証しました。 VMware vSAN では、仮想マシンのディスクを「Thick(領域を確保する)」で作るか「Thin(使った分だけ消費する)」で作るかを、ストレージポリシーの Object space reservation で切り替えられます。すでに Thick で運用している仮想マシンをあとから Thin に変えたい、というのは容量が逼迫してきた環境ではよくある要望です。 ただ「ポリシーを変えれば本当に空き容量が戻るのか」「Snapshot を取っているとどうなるのか」「変更後すぐに数字へ反映されるのか」といった点は、実際にやってみないと分かりにくい部分です。そこで vSANクラスタ上の VM を対象に、一連の操作と容量の変化を追いかけてみました。 先に結論 Thick → Thin へポリシー変更した結果、 vSAN データストアの使用容量は 4.86TB → 4.41TB へ約 0.45TB 減少 しました。仮想マシン単体の VM Used Space で見ると 620GB → 124GB(差分 約 496GB) 。FTT1(ミラー)構成のため、物理消費ベースでは約 500GiB 相当の削減に相当します。ただし数値が反映されるまでには VM の PowerCycle と 1〜2 時間の待機が必要でした。 検証環境 今回はVxRail に標準で存在する VxRail Manager VM を検証対象にしています。特別な仕込みは行わず、既存の仮想マシンのストレージポリシーを切り替える、という運用でありがちなシナリオをそのまま再現しました。 プラットフォーム:  vSphere/vSAN 8.x ハードウェア:  Intel Skyelake CPU サーバ 3 ノード構成 耐障害性: FTT=1 / RAID-1(ミラーリング) 対象 VM:  仮想マシンディスクサイズ 288GiB、GuestOS 実使用 約 39GiB 検証の流れ 「作業前の状態確...

概要 vCenter Server Appliance (VCSA) に標準搭載されている簡易ファイアウォール機能を使い、特定 IP からのアクセスを拒否する設定を実際に投入してみる。GUI での操作から、裏側で生成される iptables ルール、そして通信方向ごとの挙動を確認した。 1. VAMI ファイアウォールとは vCenter は簡易的なアクセス制御機能を搭載しており、特定の IP アドレスやサブネットからのアクセスを許可・拒否できます。設定は vCenter Server Management Interface（VAMI、 https://<appliance>:5480 ）の Firewall メニューから行います。 [1] これは環境内にファイアウォールを持たないフラットなネットワークでも、vCenterへのアクセスを制御できるという、セキュリティ観点では意外と有用な機能です。踏み台（ジャンプホスト）や管理セグメントからのみアクセスを許し、それ以外を遮断する、といった用途に使えます。 [2] ポート単位の制御はできない この機能はあくまでネットワーク層（送信元 IP／サブネット）でのフィルタです。「443 だけ許可」「22 だけ拒否」といったポート単位の制御はできず、ルールはその NIC に届く すべてのトラフィックに一律で適用 されます。SSH だけ絞りたい、GUI は全体公開したい、といった要件は VAMI 単体では実現できないため、外部 L4 ファイアウォールや NSX 側で行う必要があります。 [3] 2. VAMI GUI での設定手順 VAMI の Firewall 画面では、ルールを上から順に評価します。今回は例として、送信元 192.168.80.253/32 からのアクセスを拒否（Reject）するルールを 1 件投入しました。 ①ブラウザで https://<appliance-IP-or-FQDN>:5480 にアクセスし、 root でログイン（vCenter SSO の SystemConfiguration.Administrators グループのメンバーである必要があります）。 ②左メニューの Firewall を開き、 ADD をクリック。 ③ルールを指定する。 Network...

概要 vSAN 8.0 Update 2 から、読み取り性能に効いてきた DOM クライアント読み取りキャッシュ（DomClientReadCache）がデフォルトで無効化されている。CPU 負荷の軽減が狙いのようだが、小規模データセットでは IO 性能が低下しうる。実機（ESXi 8.0 U3）で実際に変更になっているかを確認し、有効化を検討すべきケースを整理する。 要点 vSAN 8.0 U2 以降、 /VSAN/DomClientReadCache はデフォルトで 無効（0） になった。 目的は CPU 使用率の削減 。大規模データセットではキャッシュヒット率が低く、キャッシュの恩恵よりも CPU コストの方が大きいと判断されたため。 副作用として、ワーキングセットが小さい環境（目安 5GB 未満 ）では読み取り性能が低下する場合がある。 CPU に余裕があり、かつデータセットが小さい環境では、再度有効化することで性能を取り戻せる可能性がある。 実機の ESXi 8.0 U3 で確認したところ、設定値は確かに 0 だった。 DomClientReadCache とは何か vSAN の I/O パスは、各仮想マシンの側で動く DOM（Distributed Object Manager）クライアント と、オブジェクトごとに存在する DOM オーナー という役割に分かれている。読み取り要求が来ると、まず DOM クライアントが自身のキャッシュ（DOM client read cache）に最近読んだブロックがあるかを確認し、ヒットすればそこで即座に応答する。ヒットしなければ DOM オーナーに問い合わせ、下位レイヤーからデータを取得し、チェックサム検証・展開を経て VM に返す、という流れになる。 つまり DomClientReadCache は、この「DOM クライアント層で完結できる読み取り」を増やすためのメモリ内キャッシュである。ヒットすればストレージ下位層への往復や CPU 処理（チェックサム・伸張など）を省ける。 8.0 U2 で何が変わったのか vSAN 8.0 Update 2 から、この DomClientReadCache が デフォルトで無効（値 0） に変更された。Broadcom（旧 VMware）のナレッジ記事 KB 31337...

  記事の概要 ESXi のアップデートを CLI で行う手順です。 vCenter がない Standalone の環境や、 vLCM に頼らず手動で実施したい場合などを想定しています。       参考 Patching ESXi host using Command Line ESXCLI コマンドを使用したホストのアップグレード方法     現在のバージョンの確認   まずは現在のバージョンを確認する vmware -vl       パッチのダウンロード   今回は 8.0U3 の最新パッチを当てる。 Broadcom サポートサイトからのダウンロードをする   まずは vSphere の項目を探す     最新のパッチのイメージは Solutions から談ロードできる     最新のパッチを選択する     そして Zip のイメージファイルをダウンロードする     パッチの転送   次のダウンロードしたイメージファイルを ESXi に転送する。 保存先は永続のストレージであればどこでもよい。 以下の例ではデータストアに作成したディレクトリは以下に保存している       仮想マシンの停止とメンテナンスモードの有効化   次に、該当の ESXi 上で仮想マシンが稼働していないことを確認し、 メンテナンスモードに入れていく。 きちんとメンテナンスモードに入ったかどうかを確認する。   vm-support -V vim-cmd /hostsvc/maintenance_mode_enter vim-cmd /hostsvc/hostsummary | grep inMaintenanceMode ...