HiRoLabブログ

HiRoのゆるふわIT備忘録

VCF OperationsのvCenter linkingが失敗した際のログを覗いてみた

■はじめに

免責事項:本投稿は私個人の知見に基づいております。
所属する会社・組織とは一切関係がございません。

この投稿は、vExperts Advent Calendar 2025 の 22日目です。

普段 VCF Operations を触る機会が少ないため、本投稿では vCenter Linking のログを探索します。
トラブルシューティングも兼ねて、vCenter Linking の設定が失敗した際に、サポートバンドルからエラー原因を特定する方法を自分なりに模索した内容となっています。

■目次

■対象者

本ブログの対象者は以下です。
・VCF Operationsのログ解析に興味がある方

■環境

今回利用する環境は以下です。

HOL(HOL-2610-01-VCF-L)

vCenter Linking の検証であるため、操作対象は以下のコンポーネントとなります。

・vCenter : vc-mgmt-a.site-a.vcf.lab, vc-wld01-a.site-a.vcf.lab
・VCF Operations : ops-a.site-a.vcf.lab

■今回の検証

トラブルシューティングをするため、事前にvCenterに細工をしました。
そのため、vCenter Linkingを設定した際にステータスがErrorとなります。

それでは、vCenter Linking の設定からトラブルシューティングを進めていきます。

■vCenter Linking設定

まずはvCenter Linkingを設定します。

  1. 以下手順に従って設定画面に移動
    Infrastructure Operations > Configurations

  2. Create GroupでGroup名を入力してNEXT

  3. vCenter Instanceを選択してNEXT

  4. 作成内容を確認してFINISH

  5. ステータスがエラーとなることを確認

■サポートバンドルダウンロード手順

次はサポートバンドルを作成しダウンロードします。

  1. 以下手順に従ってサポートバンドルの画面に移動
    Administration > Control Panel > Support Bundles

  2. ADDを押下

  3. Full Support bundleを選択

  4. サポートバンドルが作成できたらダウンロード

■エラー原因の解析

これより、ダウンロードしたログバンドルよりログ解析を行います。
先ず、ダウンロードしたログバンドルがzipファイルとなっている為、unzipコマンドで展開します。

展開すると2つのzipファイルが確認できます。
ops-a.site-a.vcf.lab.zip
・cluster_info.zip

vCenter Linkingのエラーを特定

ops-a.site-a.vcf.lab.zipを展開することでvCenter Linkingのログファイルが確認できます。   vCenter Linkingのログはlogs/vrops-vcenter-linking.log で確認できます。

とりあえず、errorというワードでgrepしたところ、vCenter Linkingのエラー理由がログに出力されております。
一部のvCenterでサービスがunavailableになっているため、もう片方のvCenterでpeerの利用ができない状態になっているようです。

今回は2つのvCenterがある。
どっちのvCenterでサービスがunavailableになっているか特定する必要があります。

余談全てのvCenterにログインしてサービスの状態を見に行けば・・・?というコメントはおやめください。
折角なので、vCenter IDから対象のvCenterを特定してみましょう。

それでは気を取り直して・・・

vCenter IDとvCenter Instance UUIDの関連付け

エラー出力にあるvCenter IDからvCenterのinstance UUIDを特定します。

UUIDを確認するためのログは複数ありますが、本ブログではvar/log/httpd/access_logで確認します。

赤枠が対象のInstance UUIDとなります。
このUUIDと関連があるvCenterのサービスがunavailableになっていると予想できます。

vCenter Instance UUIDとvCenter FQDNの関連付け

次に UUID から vCenter の FQDN を特定します。 logs/analytics.audit-*.logを確認することでuuidとvCenterのFQDNの両方が出力されております。

赤枠よりvCenter(vc-wld01-a.site-a.vcf.lab)でサービスがunavailableになっていると予想できます。

■ vCenterの状態確認

では実際にvCenter(vc-wld01-a.site-a.vcf.lab)を覗いてみます。

  1. vCenterにSSH接続
  2. 以下コマンドでUUIDを確認


vc-mgmt-a.site-a.vcf.lab

access_logで確認したUUIDと一致したため、間違いないようです。

次にサービス状態を確認します。
どうやら vpxd が stop 状態となっているようです。

■サービス起動とvCenter linkingをリセット
  1. vpxdのサービスを起動します。

  2. vCenter Linkingをリセットします。

Active状態となりました。

■さいごに

さいごに所感となります。
複数の製品が関係してくるとログの調査が難しいことが分かりました。
今回だとvCenter Linkingのログで対象のvCenterを見つけることが出来ず、ほかのログを探索するということが良い学びとなりました。
今後もログ解析に役立つ情報を投稿していければと思います。

Terraform CloudでAvi Load BalancerのAlert設定を自動化してみた

■はじめに

この投稿は、vExperts Advent Calendar 2024 の 13日目です。

今回はAvi Load BalancerのAlert設定周りのTerraformのテンプレートファイルを作成して
Terraform Cloudにてワークスペースを実行しAlert設定を自動化したブログになります

Terraform Cloudのより詳細な使い方は過去の検証ブログを参考に

hiro1325.hatenablog.com

■目次

■対象者

・Terraform Cloudで自動化を初めようと思っている人

VMware Avi Load Balancerの自動化に興味がある人

■前提知識

・gitの操作が出来る

■構成図

Terraform Cloud実行における構成図は以下

■Avi Load BalancerのAlert設定

本セクションではEvent発生から通知までの仕組みに加え
実際の設定画面を使って新規でAlert設定する手順を説明

Event発生から通知

Event発生し通知されるまでのフローは以下

Alert設定概要

新規でAlert設定する場合は
手戻りを無くすためNotifications→Alert Action→Alert Configの順で設定するのが良い

今回は設定を自動化する為
Web UIの画面においては必要箇所のみ簡単に説明

Notifications(Syslog)

Syslogの設定は名前とIPアドレスのみの設定で完了
ポート番号はデフォルトで指定されている

Alert Action

Alert Actionの設定はNotificationsで作成したSyslog設定を指定

Alert Config

Alert Configの名前を指定

次にAlert Configが動作する為のトリガーになるEventを指定

最後に作成したAlert Actionを指定

参考
VMware by BroadcomのAvi Load Balancer Alert設定のドキュメント

■テンプレートファイルの準備

TerraformのAviのプロバイダーは以下を参考にしてください

registry.terraform.io

作成したテンプレートファイルは以下

provider.tf
main.tf

プロバイダー情報やAviコントローラーのユーザ情報などが記載されている
テンプレートファイル(provider.tf)は以下

terraform {
  required_providers {
    avi = {
      source = "vmware/avi"
      version = "30.2.1"
    }
  }
}
provider "avi" {
avi_username = "admin"
avi_tenant = "admin"
avi_password = "<パスワード>"
avi_controller = "< AviコントローラーのIPアドレス >"
avi_version = "30.2.1"
}

resourceブロックのリソースタイプとAviの設定項目の紐づけは以下

リソースタイプ Avi Load Balancerの設定
avi_alertsyslogconfig Notification Syslog
avi_actiongroupconfig Alert Action
avi_alertconfig Alert Config

よって作成したmain.tfは以下

data "avi_tenant" "default_tenant" {
  name= "admin"
 }

resource "avi_alertsyslogconfig" "syslog" {
  name      = "avi-syslog"
  syslog_servers {
    syslog_server = "< SyslogサーバのIP >"
    syslog_server_port = "514"
    udp = "True"
  }
  tenant_ref = data.avi_tenant.default_tenant.id
}

resource "avi_actiongroupconfig" "action" {
  name = "avi-syslog-action"
  external_only = "True"
  level = "ALERT_LOW"
  syslog_config_ref = avi_alertsyslogconfig.syslog.id
  tenant_ref = data.avi_tenant.default_tenant.id
}

resource "avi_alertconfig" "alert" {
  action_group_ref = avi_actiongroupconfig.action.id
  name = "avi-Syslog-Config-Events"
  alert_rule {
    sys_event_rule {
      event_id = "USER_LOGIN"
      not_cond = "False"
    }
  }
  category = "REALTIME"
  source = "EVENT_LOGS"
  summary = "Syslog for Config Events occured"
  throttle = "0"
}

最後にgithubにpushすればファイル作成は終了

■terrform cloudの設定

ワークスペースの作成

前回と同じリポジトリを使用するが
Avi Load Balancer用のディレクトリを作成

特定のディレクトリを指定する方法は以下の
Terraform Working Directoryにてパスを入力

その他の設定は冒頭で説明した過去の検証ブログを参考に

ワークスペースの実行

ワークスペースを実行し
terraform planが正常終了

作成されるリソースを確認
問題なければconfirm & apply

terraform applyが成功

■syslog通知の確認

Avi Load Balancerでsyslog設定が出来ているかテストメッセージを送信して確認

まずはじめにValidate settingをクリック

送信するメッセージを入力してSubmitをクリック

syslogサーバにて以下のメッセージ確認が出来る

■お片付け

最後に作成した環境のお片付けを行う terraform destoroyをTerraform Cloudで実行する手順にあたる

ワークスペースの Settings->Destruction and Deletionにて Queue destroy planをクリック

確認の為のワークスペース名が求められるので入力しQueue destroy planをクリック

terraform planが正常終了

confirm & applyをクリック

成功してsyslog設定が削除されたことが分かる

■おわりに

はじめてのアドベントカレンダーに挑戦し無事ブログを公開できたことを嬉しく思います

本ブログの内容を少しアレンジしたデモを次のJapan VMUG vExpert が語る #42で行いたいと思います

LTの動画はこちら

youtu.be

はじめてのTerraform Cloudで仮想マシンを作ってみた

■はじめに

Terraform Cloudを使い自宅ESXi環境にVM 2台をデプロイしたブログ

本ブログは過去に実施したTerraformでVMwareの自動化にチャレンジした内容を
使い方を含めTerraform Cloudでやってみた内容となっている

hiro1325.hatenablog.com

■目次

■対象者

・Terraform Cloudで自動化を初めようと思っている人

VMware周りの自動化に興味がある人

■前提知識

・gitの操作が出来る

・vSphereの基礎的な知識がある

・dockerの基礎的な知識がある

■構成図

Terraform Cloud実行における構成図は以下

■terrform cloudの設定

ワークスペースの作成

プロジェクトの選択としてDefault Projectを選択

ワークスペースの作成

githubと連携したいので
Version Control Workflowを選択

github.comを選択

次にリポジトリを選択

ワークスペース名を入力して作成

作成されていることをワークスペースの画面より確認

terrform cloud agentの設定

terraform cloud agentを使用には terraform cloudでtokenを発行

作成済みのOrganization nameを選択 setting->Agentsにてagent poolを作成

pool名を入力して次へ

Descriptionを入力してtoken作成

次の工程の環境変数とdockerコンテナ起動で使用するので 出力された以下コマンドや変数をメモして終了 -dオプションが無いことに注意

■ terraform cloud agent用VMの設定

・agent用のVM(Ubuntu)を準備 事前のインストールパッケージ

apt install docker

環境変数にtokenやagent名を設定しておく

export TFC_AGENT_TOKEN=<生成されたtoken>
export TFC_AGENT_NAME=<エージェント名>

次にterraform cloud agentのコンテナを起動
terraform cloudでtoken発行した際に出力されたdockerコマンドを入力

docker run -d -e TFC_AGENT_TOKEN -e TFC_AGENT_NAME hashicorp/tfc-agent:latest

私の場合はバックグラウンドで実行させてたいので-dオプションを付けて実行

以前のブログで検証したterraformのファイルをgithubにpush

ワークスペースの実行

ワークスペースの実行には「New Run」をクリック

次に実行するRun nameを入力

terraform planが正常に終了
confirm&applyをクリック

必要に応じてコメントを入力
confirm planを実行
※コメントは必須ではありません

成功したこと確認

vCenterのタスクの開始時刻からもApplyの時刻と同じことから
正常に作成されたことを確認

■お片付け

最後に作成した環境のお片付けを行う terraform destoroyをTerraform Cloudで実行する手順にあたる

ワークスペースの Settings->Destruction and Deletionにて Queue destroy planをクリック

確認の為のワークスペース名が求められるので入力しQueue destroy planをクリック

作成時と同様に destoroyのterraform plan正常終了したので
confirm & applyをクリック

同様にコメントを入力して confirm planをクリック

成功してVMが削除されたことが分かる

同様にvCenterからも確認

■まとめ

今回は前回terraformのコマンドのみで実施した検証をTerraform Cloudで同じことをやってみた
次はAvi Load Balancerに対して実施予定

初めてのAvi Load BalancerでBGP Peeringをやって見た-③

■はじめに

第2部の続きでBGP Peeringの設定編になります
Avi Load BalancerのSEまで構築済み
下記ブログを参考にしてください

hiro1325.hatenablog.com

hiro1325.hatenablog.com

■目次

本ブログは初心者向けに作られており且つ設定で躓いた点も含まれているため、AviのBGP設定においてはCLIだけで設定を進める内容にはなっていません
その為GUIにて設定した続きをCLIで実施するような形をとっているので、Avi ControllerについてはGUIの設定から読み進めることを推奨

■対象者

VMware Avi Load Balancerを初めて挑戦しようと思っている人

VMware製品に興味があるひと

■BGP形成手順

第1部の検証構成の概要図からの抜粋になるが
仮想ルーターとAvi SE間でBGP Peeringを形成

※改めて仮想ルーターCisco CSR1000vを使用

CSR1000vのConfig

CSR100vのBGPの設定は次の通り

 
(config)#router bgp Local-ASN 
(config-router)#neighbor Peer-IP remote-as remote-ASN
 

Avi ControllerにてBGPの設定(GUI)

Avi ControllerにてBGPを設定するには
VRF Context画面にてCloudを選択します

デフォルトではGlobalが設定されてます こちらを使っていくのでチェックを付けて編集ボタンを押下

VRF Contextの編集画面に切り替わったことを確認
この画面にてBGP Peeringを有効化にします
そしてLocal ASNを入力
iBGPまたはeBGPを選択します

※timerの設定はデフォルトでkeepalive intervalとhold timeが設定されている為そのままにします

次にpeerの設定をします Addを押下

BGP Peerを形成するネットワークを選択
PrefixとPeer IPを指定

今回はpeerにVIPの広告のみを行う為
次の図のようにチェック入れて保存

Avi controller のGUIからの設定だと以上になります ここでお気づきだろうと思うが・・・ リモートASの設定は・・・?

GUIを手探りで色々と探ってみたがリモートASの設定が見当たらない

そこでここから先はCLIに切り替えて設定を見ていく

※改めてCLIで全て設定可能と思われるが、初心者向け且つ私が躓いた点としてブログにしたかった為
今回はGUICLIの両方を使い分けて設定していく

Avi ControllerにてBGPの設定(CLI)

ここではGUIの画面で確認がとれなかったリモートASについてのみになります

VRF Contextの設定確認

設定変更の前に現環境のVRF Context情報を確認します 複数のCloudで同じVRF Contextの名前を使っている場合はどのオブジェクトか選択が求められます

$ Avi Controllerにssh
$ shell
$ ユーザIDとパスワード入力
> show vrfcontext VRF-Context-name
> cloudを選択

検証環境で確認すると次のようになります
peers indexで指定されている番号は次のremote-asの変更する際に必要になります

remote-asの変更
> configure vrfcontext VRF Context name
> bgp_profile
> peers index index番号
> remote_as ASN
> save

※peers indexのみだと新規Peer情報作成になってしまうので既存Peer

BGP形成の確認

Avi Controllerにて確認は稼働中のPrimary SEにてBGP Peeringの画面に状態を確認します アイコンが緑になっていればEstablishedで正常にBGP Peerになっている

仮想ルーターにてBGP Peerの状態確認コマンドはこちら

#show ip bgp summary

検証環境で確認するとこちら

BGPにてVIPが広告されているか確認するコマンドはこちら

#show ip route bgp

検証環境で確認するとこちら

ここまでで仮想ルータにてBGP Peerが形成されており
VIPのアドレスを学習できていることが言えます

デモ

実際のロードバランスするの様子はJapan VMUGの活動として
2024/08/21に開催されたvExpertが語る会でデモを含めたLTにて実演してます
よそしければ参考にお願いします

※デモのみ確認したい人は09:22から見て頂ければよいかと

www.youtube.com

参考にした記事

参考にした記事はこちら

docs.vmware.com

avinetworks.com

■まとめ

Avi Load BalancerのコンポーネントからBGPを形成するまで
3部構成に渡ってブログにしてきました

恐らく、CLIで設定していくのが良いのかなと思い
更に自動化していくのがよいのかなと思った為今後は
terraformで自動化に挑戦する予定

  

初めてのAvi Load BalancerでBGP Peeringをやってみた-②

■はじめに

第1部の続きでAvi ControllerにてSEのデプロイの記事になります

下記記事でそれぞれのコンポーネントについて説明している為
そちらも併せて参考にしてください

hiro1325.hatenablog.com

※実際の画面を使った説明では構築済みになっている状態で説明させていただきます

■目次

■対象者

VMware Avi Load Balancerを初めて挑戦しようと思っている人

VMware製品に興味があるひと

■サービスエンジン構築概要

Avi Load Balancerにおいてサービスエンジン(SE)構築の流れは次の通りである

  1. Infrastructureにてcloudの設定
  2. InfrastructureのCloud ResourceにてNetworksとService Engine Groupの設定
  3. Applicationsにてpoolsの設定
  4. VS VIPの設定
  5. Virtual Serviceの設定

Virtual Serviceまで実施できると自動的にサービスエンジン(SE)のVMがデプロイされる

次から実際の操作に従って設定を行っていく

■サービスエンジン構築手順

Cloud設定

Infrastructureのcloudにてcreateボタンを押下しプルダウンメニューから
VMware vCenter/vSphere ESXを選択する

cloudの名前は任意に設定してvCenter/vSphereの設定箇所に
SEをデプロイする対象のvCenter情報を入力する

Pools設定

Poolsの設定で必要な項目は以下になる

・Pools名
・Poolsに紐づけるCloud
・ロードバランスのアルゴリズム
・ロードバランスさせるサーバの登録

まずはじめにApplications PoolsにてCreate Poolを押下

Poolsの設定画面が開くので任意のPools名を付けていただきCloudの情報を紐づけます

Cloudを紐づけると次のようになる

次にロードバランスのアルゴリズムを選択します
今回はラウンドロビンにします

次にロードバランスさせるサーバを登録します
IPアドレスDNS名にて登録が可能

Poolsの設定はここまでとする

VIP設定

次にApplications VS VIPにてVIPを作成

VIPの作成画面が開くので他と同様に任意の名前を設定
そしてCloudを紐づけます

次にVIPを設定するためにAddを押下

今回の検証ではIPv4で行っていくためVIPとして設定するアドレスを入力してAdd

このVIPで使うアドレスはどのネットワークかを選択

ここまで設定できたらSAVEしてVIPの設定終わりです

VS設定

次に仮想サービス(VS)の作成を行います

ApplicationsのVirtual Servicesにてcreate Virtual ServiceにてAdvanced setupを押下します

Cloudの選択画面にて今回作成したCloudを選択します

VSの名前と作成したVIPを選択

作成したpoolsを選択

サービスエンジンの確認

VSまで作成ができたらサービスエンジンが自動的にデプロイされる

デプロイされたVMは次の画面にて確認が出来る

まとめ

第2部のブログではAvi Controllerの設定にてサービスエンジン(SE)がデプロイできるとこまで実施
コンポーネントが何をやっているか設定しながら抑えていく必要がある
次はBGP設定に取り掛かる

初めてのAvi Load BalancerでBGP Peeringをやってみた-①

■はじめに

自宅Lab環境にAvi Load Balancer構築した
色々触りながらBGP PeeringにてVIPを広告するとこまで出来たので 3部構成に分けたブログとする

今ブログでは検証構成からAvi Load Balancerのコンポーネントについて纏めていく

■目次

■対象者

VMware Avi Load Balancerを初めて挑戦しようと思っている人

VMware製品に興味があるひと

■構成図

今検証のネットワーク構成の概要図はこちら

仮想ルーターとALB SEはBGP Peerを形成 仮想ルーターCisco CSR1000v使用

仮想ルーターはALB SEからVIPのアドレスを学習している
よってクライアントPCからVIPにアクセスできPoolsで管理しているサーバに対して負荷分散することが可能

■ALBとは

Avi Networksが提供するマルチクラウド環境で展開可能な仮想化のロードバランサー製品

■主なコンポーネント

Avi LoadBalancerの主なコンポーネントは次の通りである

  1. Pool:Avi Load balancerで管理してる負荷分散対象のサーバ

  2. バーチャルIP(VIP): クライアントからのリクエストを受け取るIP

  3. 仮想サービス(VS):poolとVIPを紐づけるサービス

  4. サービスエンジン(SE):分散処理を行うエンジン

1-3まで作成することでサービスエンジンが自動的にデプロイされる

■負荷分散までの流れ

実際にサービスエンジン(SE)が構築され
クライアントがVIPにアクセスして負荷分散されるながれを次で説明

①クライアントがVIPへリクエストを送信

②VSによってVIPとPoolが紐づいているサーバに対して負荷分散

■まとめ

今回のブログではALBにおける各コンポーネントについての纏めまでとします
次は実際にAvi Controllerを使ってサービスエンジン(SE)のデプロイまで進める

Interop Tokyo 2024 VMUGブース体験

目次

はじめに

まずはじめにVMwareさんご協力により
今年もVMUGの活動の場としてブースを設けさせていただきありがとうございます

おかげで昨年と同様にInterop TokyoにてVMUGブースのスタッフができ無事終えることが
出来たのでかる~く体験談をブログにします

昨年のブーススタッフ体験ブログはこちら

hiro1325.hatenablog.com

対象者

本ブログを読み進めるにあたり対象者はこちら

・VMUG活動に興味がある方

・vExpertを目指そうと思っている方

昨年との違い

昨年大きく違った点はブース出展が最終日の午後のみになったこと
また今年は分離したEUC部門の一部を借りてのブース出展になったこと

ブーススタッフの内容

今年のブースはこんな感じです

ブーススタッフの主なお仕事は来場者へのVMUGでの活動の説明
そしてコミュニティサイトにてメンバー登録を行っていただきました

www.vmug.com

vmug-jp.connpass.com

euc-jp.connpass.com

最後にVMUGメンバーになった方にノベルティをお渡しします
スタッフのお仕事はこんな感じです

今年のノベルティはモバイルバッテリー、Tシャツ、ボトルを配りました

さいごに

Interop Tokyo 2024にVMUGブーススタッフを行ってきましたが
今年は色々とあり昨年ほど大規模なブース運営とはいきませんでした

来年こそは2023年の時と同様にブース展開をしていければと思っています

改めてご協力頂いたVMwareさん
そして来場者の方々ありがとうございます