2020年7月31日金曜日

vRealize Operations の標準ダッシュボードを削除してしまった際の復元方法

vRealize Operations Manager のダッシュボードを編集する際、ボーっとして操作すると「ダッシュボードの削除」を間違って押してしまいダッシュボードが vROps 無いから削除されてしまう事があります...
何で「ダッシュボードの削除」ボタンが上から2番目という押しやすい場所にあるのかは謎です...

ダッシュボードそのものを"削除"してしまった場合

ダッシュボードを開いた状態で「アクション」 > 「ダッシュボードの削除」を選ぶと、ダッシュボードそのものが消し去られます。
ダッシュボードタブから非表示にしたい場合は「メニューからダッシュボードを削除」を選択する必要がありますが、似た操作名でインパクトのあるものが上にあるので操作する際は気を付ける必要があります。


例えば上の画面で「vSAN 運用概要」のダッシュボードを削除します。
するとインストールされている Management Pack ("ドキュメント上だと 事前定義されたダッシュボード" や "ネイティブ管理パック" と呼ばれる)から「vSAN 運用概要」のダッシュボードが削除されてしまい、
もう一度「vSAN 運用概要」ダッシュボードを表示したくともメニューから消えてしまいます。

試しに 3 つほど vSAN 関連のダッシュボードを削除してみます。
「管理」タブの「リポジトリ」から「vSAN」パッケージのコンテンツを表示すると

本来 5 つあるはずのダッシュボードが 2つしか存在していません。

これを元に戻すには若干手間が必要です。

※ vSphere の管理パックであれば「デフォルトの内容の再設定」という操作が可能なのですが、その他のネイティブ管理パックではこの操作が実施できません。

vSphere の管理パックの復元方法は KB が用意されていますので参照ください。

ネイティブ管理パックから削除した事前定義されたダッシュボードの復元方法

バックアップなどが取得されていない場合、間違って削除してしまったダッシュボードの復元は恐らく

  • vROps をバージョンアップする際に「デフォルトの内容の再設定」にチェックを入れる
  • リポジトリから対象の管理パックだけを最新インストールし「デフォルトの内容の再設定」する
の 2 パターンがあるかと思います。

ただ、https://marketplace.vmware.com/ などからダウンロードした管理パックと違い、vSAN や NSX など vROps に予め組み込まれたネイティブ管理パックは個別では提供されていないので、入手するためには「vROps のアップデート用パッケージ」から取り出すなどの手段が必要です。

また、バージョンアップに関してもすでに最新に更新済みであったり、更新済み環境に改めてダッシュボードの復元のためだけにパッケージ全部を当てなおすのもどうかと思います。
今回はネイティブ管理パックを個別に入手して適用、ダッシュボードを復元する方法を記します(たぶん非公式手法です)。

ネイティブ管理パックの個別パッケージの入手方法

まずは My VMware から vROps のアップデート用パッケージを入手します。


ダウンロードしたパッケージは拡張子が「.pak」となっていますが、実際は ZIP 形式の圧縮ファイルなので拡張子を「.zip」に変更し、中身を確認します。

.pak ファイルを(今回は vROps 8.1.1 のものなので vRealize_Operations_Manager-VA-8.x-to-8.1.1.16522872.pak

.zip に拡張子の変更

ZIP に変更したファイルを開き、中に含まれる vROps の拡張子「.iso」のパッケージファイルをさらに開く(今回は vRealize-Operations-Manager-Appliance-8.1.1.16522874-cloud-components.iso

開くと拡張子「.pak」のファイルが沢山あると思います。
これら名前から推測できますが、ネイティブ管理パックのパッケージになります。

今回は vSAN のネイティブ管理パックを復元したいので「vmware-MPforVSAN-8.1-16522881.pak」を取得します。

ネイティブ管理パックの復元方法

「管理」タブから「ソリューション」>「リポジトリ」を選択し、「追加/アップグレード」をクリック

 先ほど取得した vSAN 用のネイティブ管理パックを指定し、「デフォルトの内容の再設定」にチェックを入れます。

デフォルトの内容の再設定について、一応警告をしっかり読んでください。
もし NG の場合は予め変更箇所のバックアップを取っておき、再設定後に復元します。

パッケージを適用します。


適用完了後、ネイティブ管理パックのコンテンツを確認します。

※ 今回、vROps 8.1.0 の環境に、vROps 8.1.1 用のパッケージを抜き出して適用したので vSAN のネイティブ管理パックのバージョンだけ新しくなっています。
本来はまるっと全体をバージョンアップするのが正当な手法です。ご注意ください。


復元したコンテンツを確認します。無事に 5 つのダッシュボードが表示されています。

以上、間違って削除してしまったネイティブ管理パックのダッシュボードの復元方法でした。
ご参考まで。



vRealize Operations の標準ダッシュボードで「ダッシュボード時間」の切り替えを有効にする方法

検証環境の vRealize Operations Manager の 7.x から 8.x にバージョンアップした際に気になった事でした、各ダッシュボードの右上にある「ダッシュボード時間」の切り替えがグレーアウトしている事象があります。
デモ用環境なのでコロナ禍で出番無くずっと放置していましたが、今回はその修正方法を覚え書きしておきます

vROps 7.x と 8.x でのダッシュボード時間の表示について

vROps 7.x の環境が手元になくなってしまったので過去の詳細を確認しきれていませんが、vROps 7.5 の時はで標準ダッシュボードに含まれる一般的な「運用概要」や「トラブルシューティング」などで使えていた以下の赤矢印の部分です。

※ vROps 7.5 の時の「vSAN 運用概要」ダッシュボードでは 1H~7D-カスタムが選択可能でダッシュボード時間で表示設定されたウィジェットは時間軸の表示変更が可能


これが vROps 8.0 または 8.1 になると以下の様に、今まで標準ダッシュボードで出来ていた時間変更がグレーアウトしてしまい
  • 「ダッシュボードレベルの時間コントロールを有効にするには、このダッシュボードのウィジェットを1つ以上 [ダッシュボード時間] に設定する必要があります」
  • 「 one or more widgets on this dashboard should be set to "dashboard time" to enable dashboard level time controls 」

などとメッセージが表示されます。

どうやら今まで標準ダッシュボードのウィジェットに設定されていた「ダッシュボード時間」の設定が vROps 8.x では固定となってしまっている様で、
今まで通りダッシュボード時間で表示を変更するためには各ウィジェットの設定を変更する必要がありそうです。

ウィジェットのダッシュボード時間設定の方法

今回は vROps 8.1 (Build 15972145) の画面で変更手順を紹介します。

初期状態は先ほどのダッシュボード時間の変更がグレーアウトしている状態です。

ダッシュボード時間を利用できるようにしたいウィジェットの「目玉」マーク(ツールバーの表示)ボタンをクリック。

 カレンダーアイコンをクリック

既定値では範囲が「過去 6 時間」などとなっています。

これを「ダッシュボード時間」に変更します。
※ ウィジェットの種類やバージョンによってこの設定方法に若干の違いがあります(以下の様なプルダウンリストの他、ラジオボタンでの選択など)

変更を反映するとダッシュボード右上のダッシュボード時間バーのグレーアウトが解除されます。
 例えばデフォルトの「6 時間」の場合と、

ダッシュボード時間を「24 時間」に変更してグラフを見比べると

この様にグラフの時間軸が変更される事が確認できます。

後は各ダッシュボードのグラフの時間設定を必要なだけ変更してあげます、が、沢山ダッシュボードがあると大変ですねコレ...

簡単ではありますが、vROps のバージョンアップ後に今までとグラフの時間表示、操作が異なって困ってしまったときはこの辺りを確認してみてください。

※ この方法ですが、vROps のアップデートパッケージ適用時に「デフォルトの内容の再設定」を有効にすると設定が戻ってしまう可能性がありますのでご注意ください。





2020年6月20日土曜日

VMware 技術情報で便利な公式まとめサイト集

一昨年頃からいろいろと VMware 関連の情報ページが再編・新設されており、有益なものは都度記事にまとめてましたが、改めてベストプラクティス系の資料が集まったサイトを整理したいと思います。
※ 昨年から今年にかけてまとめた記事、ダブった内容もありますが結構書いてました。
これらサイトの中身、全部目を通す必要は全くありませんが、どこにどんなコンテンツがあるのか見出しだけでも眺めておくと今後業務で必要になった際に素早く情報にたどり着けますので参考にしていただけると幸いです。

Best Practice / White Paper / Technical Deep Dive 資料まとめサイト

以下、vSAN・Storage 系、vSphere 系、EUC 系、NSX 系、vRealize 系、VMC 系とそれらを横串にしたソリューションのまとめサイトが公開されています。
殆どの動画以外のコンテンツが PDF でエクスポート可能なので、気に入ったコンテンツは ピン止めしたり RSS 登録したりでローカルに落としておくとオフラインでも調べものが捗ります。

意外と Storage Hub は知られているけれども、VMware 内のプロダクト担当でも Tech Zone や vRealize の Product Walkthroughs の存在が知られていなかったりします...

Storage Hub (vSAN, Storage、Cloud Foundation、SRM などインフラ関連)

vSAN やコアストレージ機能、SRM などのストレージが関連するアーキテクチャの他、VMware Cloud Foundation の様な HCI フルスタックな製品の情報が集約されています。
vSAN やコアストレージ系のベストプラクティスは導入前に必読です。
https://storagehub.vmware.com/

vSphere Central (vSphere 全般の様々な技術情報)

vSphere の各主要機能なディープな情報が集まっています。
vSphere 基盤のベストプラクティスは StorageHub の情報と合わせて必読です。VCP などの試験対策にもなります。
https://vspherecentral.vmware.com/

Digital Workspace Tech Zone (Horizon や Workspace One など End User Computing 関連)

End User Computing 関連のベストプラクティス、プレゼン動画などが集約されています。
https://techzone.vmware.com/

VMware Cloud Tech Zone (VMC 関連)

TechZone の VMC サブドメインサイト。VMC on AWS をはじめとしたクラウドサービスのベストプラクティスが集まっています。
https://vmc.techzone.vmware.com/

Networking & Security Tech Zone (NSX など Network Virtualization  関連)

TechZone の NSX サブドメインサイト。こちらもネットワーク仮想化に関するベストプラクティスが集約されています。
https://nsx.techzone.vmware.com/

vRealize Product Walkthroughs (vRealize 関連の自動化・可視化ソリューション関連)

私自身も最近存在を知った vRealize 系のプロダクト情報が集まったサイトです。
https://vrealize.vmware.com/

VMware Product Walkthroughs (プロダクト間でソリューションとして関連付けたサイト)

プロダクト横断ソリューションなどのガイドへのリンクがまとめられています。
https://featurewalkthrough.vmware.com/

従来からある Technical Paper (各プロダクトのまとめサイトが出来る以前からあったページ)

最近はこちらにコンテンツが追加される事は少なくなりましたがまだ現役です。結構 Deep な昔の資料も見つけることが可能です。
https://www.vmware.com/jp/techpapers.html

公式ドキュメント

各バージョン毎の設計、導入、運用時に確認必須な公式ドキュメント。各製品のリリースノートもここから入手します。
資料の中にもパフォーマンスベストプラクティスガイドやトラブルシューティングガイドもあるので必読。
https://docs.vmware.com/jp/

トップページは主要製品カテゴリのリンクなので、個別製品のドキュメントを探すときは「すべての製品」からたどります。
https://docs.vmware.com/allproducts.html

資料を PDF 化したい場合は各ドキュメントの見出し右上の「PDF」マークをクリックします。
英語 UI に切り替えると RSS フィード購読が出来るので気になる記事や、製品リリースノートの RSS フィードを登録しておけば製品に更新があった場合にいち早く気付くことが可能。

日本語表示のままだと RSS フィードの登録ボタンは表示されないので注意。
英語表示は KB もそうですが、必ず日本語表示と合わせてチェックした方が良いです。
日本語表示が更新されていなかったり、日本語表示自体が提供されていない事も多々ありますのでご注意ください。

その他、設計・導入時にチェック必須なツール・サイト

ベストプラクティス情報とは異なりますが、導入・運用時にチェックするべき情報サイトも少しずつ変化しているので改めて紹介します。

VMware Configuration Maximum tool  (最大構成上限のチェック)

各製品の構成上限は現在は Config Max Tool で各バージョン毎チェックを行い、PDF などにも情報をエクスポート可能です。

VMware Ports and Protocols (製品毎のポート要件、ネットワーク要件のチェック)

各製品のネットワークポート要件も現在はツールで各製品、バージョン毎に絞り込み確認し、ダウンロードが可能です。
https://ports.vmware.com/

Lifecycle Product Matrix

各製品のサポート期間のチェックは従来通り以下のマトリクスでチェックします。

VMware Product Interoperability Matrice

上記サポート期間中の製品は新しいバージョンが出るたびに各製品間の互換性サポートが更新されるのでバージョンアップや新規導入時に必ずチェックします。ただしここのマトリクスの表示が全てではないので必ずリリースノートや関連 KB も確認してください。

VMware Compatibility Guide

VMware Compatibility Guide (VCG) や Hardware Compatibility List (HCL) と呼ばれる周知のツールですが、新規導入時もそうですが、バージョンアップの際には必ず互換性チェックが必要です。また、ハードウェア側での不具合が見つかった際などは導入時にサポートされていたファームウェアバージョンが途中で非サポートとなる場合もあります。

数が多くなると大変かもしれませんが導入したハードウェア、特にサーバー本体、RAIDカード・HBA、NIC など重要なコンポーネントは RSS フィードなどを登録(矢印のところ)して、更新をチェックできる様にする事をお勧めします。

https://www.vmware.com/resources/compatibility/search.php


vSAN VCG Notification Service

vSAN VCG 通知サービス、今年5月から開催されたサービスですが、上記 VCG・HCL のフィード確認と合わせて vSAN で利用する HBA、SSD などのファームウェア・ドライバの更新履歴を分かりやすくチェックする事が可能なツールです。
https://vsansizer.vmware.com/revision-control/audit-detail

利用中のデバイスは VCG・HCL のページから各デバイスで RSS フィードの登録、または メール通知の登録が出来ます。


まとめは特にありませんが、定期的に自分のブックマークを兼ねてこれら記事は更新していこうと思います。

2020年6月15日月曜日

ESXi 6.x 以降でシステムリソースの予約値を変更する方法

vSphere 5.5 (ESXi 5.5) までは vSphere Client で値の変更が出来たシステムリソース(ESXi Kernel のリソース)の予約値ですが、vSphere 6.0 以降では変更が出来なくなってしまいました。
あえて修正しなくてもベストな値が自動で反映されているので通常は修正する必要はありませんが、各 ESXi 毎に予めシステムリソースの予約値を多めに確保しておきたい場合や、ホームラボ用途で予約値を減らしたいという場合もあるので、本記事では PowerCLI を利用して変更する方法を記します。

※ 正式な手順ではないので本番環境に設定する場合は必ず事前検証、各メーカーサポートへの確認を行ってください。
※ あと、だいぶ前に見た KB で今見つからなかったのですが、vSphere のバージョンアップ時などに設定がリセットされる事象があったのでもしかしたら今のバージョンでも元に戻る仕様かもしれません。テスト環境をバージョンアップする機会があれば追って確認して追記します。

本記事は LucD さんの VMTN での助言をベースにしています。

システムリソースの予約値とは?

システムリソースの予約とは、ESXi が動作するために最低限確保している CPU とメモリのリソース予約値で vSphere Client からホストを選択し、設定 > システム > システムリソースの予約 を開く事で確認できます。


このシステムリソースの予約、vSphere 5.5 までは vSphere Client の画面上にて編集する事が可能でしたが、vSphere 6.0 以降では vSphere Client では編集が出来ません(上記画面上で編集ボタンがそもそもない)。
※ これは設定に応じて適切な値が自動で予約されており、意図的にリソースを減らされて ESXi Kernel が不安定になる事を防止するために変更されたものと思われます。

今回はこの値を PowerCLI を利用して変更する方法をご紹介します。

システムリソースの予約値の変更以外で対応可能な制御方法

現バージョンでは標準 UI から変更不可となってしまったシステムリソースの予約値を変更する以外に、予めシステムリソースをある程度確保しておく方法として vSphere HA のアドミッションコントロールで全体の余剰リソースを多めに確保する方法や、VM を格納するリソースプールの制限設定でシステムリソース分を確保しておく方法があり、むしろクラスタ全体で柔軟なリソース管理をする意味でこちらが現在の推奨設定です。

これらの方法はクラスタ単位での設定であり、リソースプールの設定は格納された VM にのみ適用される制御方法となるため、単一ホストに負荷が集中して ESXi のシステムリソースが不足しないようにするためには DRS で VM の自動負荷分散配置できるようにします。

アドミッションコントロールについての公式 Docs

リソース プールの管理の公式 Docs

PowerCLI を利用したシステムリソースの予約値変更

まず、手元の環境の vSAN クラスタのうち 1台のシステムリソースの予約値を確認します。

画面を見るとメモリが 25.16GB、CPU が 239 MHz システムリソースとして予約されています。
但し、GUI でみる場合と、CLI での設定では単位の違いや微妙な数値の違いがあるので 正確な設定値を CLI で事前確認する事が必須です。
これを PowerCLI で確認する際には一発で取得するコマンドは用意されていないので、Get-VMHost で取得した ESXi の情報の中から探し出します。
今回求める情報は ExtensionData > SystemResources > "host/system" Key > Config と求めていきます。

# CPU 予約値の確認
PS C:\> $esx1 = (Get-VMHost)[0]   # ホスト1号機を指定
PS C:\> ($esx1.ExtensionData.SystemResources.Child | where {$_.key -eq "host/system"}).Config.CpuAllocation
Reservation           : 239    ← 239MHz 予約されている事が分かる
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1

# メモリ予約値の確認
PS C:\> ($esx1.ExtensionData.SystemResources.Child | where {$_.key -eq "host/system"}).Config.MemoryAllocation
Reservation           : 24869  ← GUIの数値とは若干異なる事が分かる、ここでは 24869MB で予約されている
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1
 

念のため、全体の CPU のリソースも確認しておきます。
以下から 28,728 MHz という事が分かります。

PS C:\> Get-VMHost

Name                 ConnectionState PowerState NumCpu CpuUsageMhz CpuTotalMhz   MemoryUsageGB   MemoryTotalGB Version
----                 --------------- ---------- ------ ----------- -----------   -------------   ------------- -------
vxesx01.vx.local     Connected       PoweredOn      12       18523       28728         197.555         255.889   6.7.0
vxesx02.vx.local     Connected       PoweredOn      12        9587       28728         217.086         255.889   6.7.0
vxesx04.vx.local     Connected       PoweredOn      12       13355       28728         124.164         255.889   6.7.0
vxesx03.vx.local     Connected       PoweredOn      12       11707       28728         109.574         255.889   6.7.0
 

今回は例として、ミッションクリティカルなシステムなのでシステムリソースの予約値として CPU 全体の MHz 合計値の 10% = 2,872MHz を予約値として LucD さんの VMTN での回答を例に設定してみます。
※ 必ず設定変更する前に ESXi のコンフィグバックアップを取得したり(KB)、現在の設定値をエクスポート(VMTNのサンプル)しておいて元に戻せるようにしてください。

まずは1台目のホストを指定して設定反映させてみます。

PS C:\> $esx1 = (Get-VMHost)[0]                             # ← まずはホスト1号機に設定
PS C:\> $spec = New-Object VMware.Vim.HostSystemResourceInfo
PS C:\> $spec.key = "host/system"
PS C:\> $spec.Config = New-Object VMware.Vim.ResourceConfigSpec
PS C:\> $spec.Config.cpuAllocation = New-Object VMware.Vim.ResourceAllocationInfo
PS C:\> $spec.Config.cpuAllocation.reservation = 2872       # ← 合計 CPU の 10% を指定
PS C:\> $spec.Config.memoryAllocation = New-Object VMware.Vim.ResourceAllocationInfo
PS C:\> $spec.Config.memoryAllocation.reservation = 24869   # ← メモリの予約値は初期値をそのまま反映
PS C:\> $spec.Config.ChangeVersion = $esx1.ExtensionData.SystemResources.Config.ChangeVersion
PS C:\> $esx1.ExtensionData.UpdateSystemResources($spec)    # ← 変更値の反映
 
変更後の値を確認します
# CPU 予約値の変更確認

PS C:\> ($esx1.ExtensionData.SystemResources.Child | where {$_.key -eq "host/system"}).Config.CpuAllocation
Reservation           : 2872    # ← 2,872MHz に予約値が変更されている事が分かる
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1
 

vSphere Client 上での変更値を確認すると CPU のリソース予約が 2.87GHz (=2,872MHz) に変更された事が確認できます。 


問題なければ、クラスタ内の他のホストにも変更を掛けます。
※ 以下の例では Get-VMHost で取得したすべてのホストが同一構成で同じ CPU 予約値を設定する前提でパイプで渡して一括設定しています。

# 同一構成の4台でクラスタが組まれている前提で一括適用(1台目に設定した際の $spec が生きている状態で)
PS C:\> Get-VMHost | %{$spec.Config.ChangeVersion = $_.ExtensionData.SystemResources.Config.ChangeVersion; $_.ExtensionData.UpdateSystemResources($spec)}

# 4台とも変更されたことを確認
PS C:\> ((Get-VMHost).ExtensionData.SystemResources.Child | where {$_.key -eq "host/system"}).Config.CpuAllocation


Reservation           : 2872
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1

Reservation           : 2872
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1

Reservation           : 2872
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1

Reservation           : 2872
ExpandableReservation : True
Limit                 : -1
Shares                : VMware.Vim.SharesInfo
OverheadLimit         : -1
 

設定を一括で元に戻したい場合は以下で戻すことが可能です。

PS C:\> $spec = New-Object VMware.Vim.HostSystemResourceInfo
PS C:\> $spec.key = "host/system"
PS C:\> $spec.Config = New-Object VMware.Vim.ResourceConfigSpec
PS C:\> $spec.Config.cpuAllocation = New-Object VMware.Vim.ResourceAllocationInfo
PS C:\> $spec.Config.cpuAllocation.reservation = 239       # ← 初期値の CPU リソース予約値を入力
PS C:\> $spec.Config.memoryAllocation = New-Object VMware.Vim.ResourceAllocationInfo
PS C:\> $spec.Config.memoryAllocation.reservation = 24869   # ← メモリの予約値は初期値をそのまま反映
PS C:\> Get-VMHost | %{$spec.Config.ChangeVersion = $_.ExtensionData.SystemResources.Config.ChangeVersion; $_.ExtensionData.UpdateSystemResources($spec)}
 

以上が変更手順、確認手順となります。

本番環境でシステムリソースを多めに確保しておきたい場合や、逆にリソースの限られるホームラボ環境でシステムリソースの予約を減らしたい場合に活用できる手法ですが、システムリソースを減らすことは安定性を失うことになりかねないので十分にご注意ください。