投稿

Aria Operations を利用してvSANのCPU使用率を確認する

イメージ
  はじめに この記事では、 Aria Operations に vSAN クラスタを登録して vSAN 環境特有のメトリックである、 vSAN CPU 使用率の確認方法をご紹介します。 なお、 Aria Operations のデプロイと初期設定については別の記事をご参照ください。     vSAN クラスタの登録 Aria Operations にログインして vSAN クラスタを管理する vCenter をインベントリに登録します。 登録画面はバージョンにより異なります。以下は 8.18 の画面です。     今回は vSAN のメトリックを取得しますので、 vSAN のタブから vSAN Configuration を Activate しておきます。 ここまで完了したら画面下の ADD から登録を完了します。   vSAN CPU 使用率を表示する   登録した vCenter 配下の vSAN クラスタが自動的にインベントリに出現し、各種メトリックをやプロパティを確認できるようになります。 なお、登録直後はメトリックなどの項目が表示されませんので、 10~15 分程度待ってから確認してみてください。 vSAN CPU 使用率についての留意事項 Aria Operations のメトリックは vCenter Performance Monitor と異なり、 5 分ごとの情報収集となっておりますので、数分程度の変動はすべて平均化されてしまう点にご留意ください。 vSAN CPU は IO 負荷の大きさに比例して大きくなります。 検証環境など、 IO 負荷の低いクラスタにおいては(おそらく)数値を丸めている都合上0%になっていることも多いですが、 HCI ベンチなどで負荷を与えるときちんとCPU使用率の数値上昇していきます IO 負荷に応じて CPU 使用量が増加していく動作検証については別の記事でご紹介します。 なお、本記事では vSAN CPU 使用率の確認方法を紹介していますが、 vSAN CPU 使用率は IO 負荷状況だけでなく、クラスタの CPU リソース量(コア数 * ベース周波数)にも依...

Aria Operationsのデプロイ

イメージ
  はじめに アセスメントツールとして非常に優秀な Aria Operations の構築について紹介します。 Aria Operations は VVF/VCF ライセンスにデフォルトで付属していますので、これまで Aria Operations を利用していなかったユーザもぜひ利用してみてほしい製品です。     Aria Operations OVA ファイルのダウンロード Broadcom Support Portal から OVA ファイルをダウンロードします。 ダウンロード手順の詳細については割愛します。       vSphere 環境へのインストール ダウンロードした OVA ファイルを vSphere 環境に展開します。 これも特別なことは特にありませんので詳細手順は割愛します。 途中でデプロイサイズを選ぶ画面がありますが、環境に応じて適切に選択してください。 今回はラボ環境での評価になりますので、 Small を選択しています。   その後のネットワーク設定画面では、 IPv4 タイプで忘れずに Static を選択してください。     その他の項目についても、仮想アプライアンスの都合上、あとから変更しようとするとちょっと面倒だったりもしますので間違いのないように入力しましょう。   デプロイ後、 Aria Operations VM を起動すると自動的に firstboot の処理が走りますのでしばらく待ちます。 数分で以下の画面になりますので、この画面が表示されたらブラウザで接続して初期設定を開始します。   初期設定 今回の検証では簡易的な機能確認が目的ですのでクラスタ構成は組まずに 1 ノードの簡易構成で構築します。 ブラウザで接続をしたら EXPRESS INSTALLATION を選択して、特に分岐もなく、認証情報だけ設定して進めます。       初期設定が始まりますので、また少し待ちます。       その後自動的にログイン画面となります...

NSX ManagerをSmallで構成するとSDDC Managerからのアップグレードが失敗する

イメージ
概要 NSX Manager は Medium 以上で構成すべし   背景 VCF 5.2 環境を vSAN AF 4 ノード( MGMT ドメインのみ)で構築し、アップグレードを検証した。 NSX 側で何かを作成する予定はなかったため、 NSX Manager は Small を選択した。   事象 VCF 5.2.0.0 → 5.2.1.0 へのアップグレード時に NSX Manager の Update が失敗する問題に遭遇した。 SDDC Manager の LCM ログからは原因がはっきりとはしなかったが、 NSX Manager のメモリ使用率のアラーム(エラー)が出ており、 断続的に NSX Manager のメモリ使用率が 90 %を超過するような状況だった( Small なのでメモリ使用率は 16GB )   ※ NSX は構築直後の状態で何も変更や作成をしていないにもかかわらずこの状態だった   対処 以下の公式ドキュメント内のオプション 1 の手順にて、 NSX Manager のメモリを 16GB->24GB に増設した。 https://techdocs.broadcom.com/jp/ja/vmware-cis/nsx/vmware-nsx/4-2/administration-guide/operations-and-management/managing-the-nsx-manager-cluster/resize-an-nsx-manager-node.html     結果 結果として、 NSX Manager の Update を無事に完了することができた。 VCF 環境で NSX Manager を Small で構築するとアップグレードが安定しなくなるのでやめた方が良い      

SDDC Managerでvimを使う場合の小ネタ

概要 SDDC Manager で VI を使ってファイルを編集する際に、右クリックでコピペができない場合( insert VISUAL となる)の対処     背景 VCF on VxRail で 8.0.300 → 8.0.310 へのアップグレードをする際に以下の KB の事象に遭遇をした。 https://knowledge.broadcom.com/external/article/323978/troubleshooting-resolve-vxrail-upgrade-f.html   KB の対処の中で Checksum ファイルを作成する必要があるが、 vi で作成しようとした際に SHA-265 のコピペができなかった。 原因 SDDC Manager ではデフォルトで vim でマウス操作が有効になっており、結果として右クリックに反応してペーストではなく、ビジュアルモードが起動していたためのようだ。   参考: https://knowledge.sakura.ad.jp/22465/ https://qiita.com/manabuishiirb/items/6fb8ff796d8e016f40c6   対処 上記参考ページでは .vimrc を作成 / 編集する方法が示されているが、実は vim 起動中にコマンドモードにて、 set mouse-=a として、マウスを無効化するだけでも良い。 ただし、 vim を開きなおすとその設定は消えるため、恒久設定としたい場合は .vimrc のほうが良いと思われるが、 SDDC Manager はアプライアンス製品のため、極力デフォルトからいじりたくないのと、 SDDC Manager で vim を触るシチュエーションはそこまで多くないのでコマンドモードでの One Time の変更が便利と思う。   まとめ SDDC Manager の vim はデフォルトではコピペができないのでコマンドモードで set mouse-=a とすれば OK 。 なお、そもそものきっかけとなった KB手順は正確ではなく、 実際には checksum ファイルは自動作成であったため、そ...

Cloud Builder 5.2を再利用する(失敗)

イメージ
  概要 VCF ライセンスで SDDC 構成を組むためには Cloud Builder VM をデプロイして、管理ドメインを構築する必要がある。 この Cloud Builder は一度管理ドメインの構築に成功すると、基本的に別の管理ドメインを構成できない。 ただし、 Broadcom KB に Cloud Builder をリセットする方法について記載があるので、 Broadcom KB の手順で Cloud Builder 5.2 を再利用できるかどうか試す     参照 KB https://knowledge.broadcom.com/external/article?legacyId=75172     5.2 で実施する場合の注意 まず、第一に KB にも記載のある通り psql コマンドを Full Path で入力する必要がある。 第二に、 KB では sudo で実施しているが、デフォルトの admin ユーザでは sudo で実行できなかったため、 su で root ユーザにスイッチしてから実行した。 第三に、 Resources というテーブルがなくなっていた(下記の出力例参照)   root@cb [ /home/admin ]# /usr/pgsql/13/bin/psql -U postgres -d bringup -h localhost psql (13.14) Type "help" for help.   bringup=# delete from execution; DELETE 9 bringup=# delete from "Resource"; ERROR:   relation "Resource" does not exist LINE 1: delete from "Resource";                 ...