vHoge

VMwareのアレコレ備忘録。CLIでがんばるネタ多め。

VEBA をデプロイする with ovftool

vExperts Advent Calendarslack 通知ネタの延長戦にしようかと思ったが、
思っていたより時間がかかりそうなので、鮮度が良い内に小出しに。

VEBA とは

vCenter Event Broker Appliance の略。
VMworld EU のセッションで発表され、VMware Flings にて11月初旬に公開されたもので、vCenter のイベント駆動でファンクションを実行してくれる faas アプライアンス

flings.vmware.com

内部アーキテクチャとしては Photon OSKubernetes を乗せ、 その上に OpenFaaS を立て、vcenter-connector 経由で vCenter のイベントを pull?している。
Ingress には Contour を使っているようだが、意識することはあるのだろうか…

これらがひとつの OVA アプライアンスとして固められて配布されている。

Download

Flings から入手可能ではあるが、Flings から入手できるのは 0.1.0 で、
実は既に 0.2.0 が存在している。

先日まで Flings の VEBA の Comments タブがあってその中に URL が載っていたのだが、今見ても Comments が見当たらず…
夢を見ていた…?

とりあえず手元にある 0.2.0 でデプロイをすすめる。
VMware {Code} とか slack 見ればあるのかな…

Deploy with ovftool

ovftool を使って CLI デプロイを行う。
プロパティ等々は以下。 NW 設定がほとんどで、パスワード系が何個か。
細かい解説は割愛しますので、ご自分の環境に合わせて置き換えてください。

ovftool -n='VEBA' \
        -ds=datastore-hdd \
        -dm=thin \
        --net:'VM Network=VM Network' \
        --prop:guestinfo.hostname=veba01 \
        --prop:guestinfo.ipaddress=192.168.0.61 \
        --prop:guestinfo.netmask=24 \
        --prop:guestinfo.gateway=192.168.0.1 \
        --prop:guestinfo.dns=192.168.0.52 \
        --prop:guestinfo.domain=home.lab \
        --prop:guestinfo.root_password=hogehoge \
        --prop:guestinfo.openfaas_password=fugafuga \
        --prop:guestinfo.vcenter_server=192.168.0.50 \
        --prop:guestinfo.vcenter_username=administrator@vspehre.local \
        --prop:guestinfo.vcenter_password=hogefuga \
        --prop:guestinfo.vcenter_disable_tls_verification=True \
        --prop:guestinfo.debug=True \
        --noSSLVerify \
        --allowExtraConfig \
        --acceptAllEulas \
        --powerOn \
        ./vCenter_Event_Broker_Appliance_0.2.0.ova \
        'vi://vcsa01.home.lab/home01/host/cls01/192.168.0.51'

余談

        --prop:guestinfo.netmask=24

最初ココを "255.255.255.0" で指定しててネットワーク疎通しなかったという失敗談。
どこかの Doc 読めばわかる話ではあるが、この項目名だと prefix とは思わないよねぇ…

OVA のプロパティ詳細

ovftool vCenter_Event_Broker_Appliance_0.1.0.ova
OVF version:   1.0
VirtualApp:    false
Name:          vCenter Event Broker Appliance
Version:       0.1.0
Vendor:        VMware
Product URL:   https://flings.vmware.com/vcenter-event-broker-appliance
Vendor URL:    https://www.vmware.com/

Annotation:  Version: 0.1.0

Download Size:  541.50 MB

Deployment Sizes:
  Flat disks:   12.00 GB
  Sparse disks: 1.58 GB

Networks:
  Name:        VM Network
  Description: The VM Network network

Virtual Machines:
  Name:               vCenter_Event_Broker_Appliance
  Operating System:   otherguest
  Virtual Hardware:
    Families:         vmx-13
    Number of CPUs:   2
    Cores per socket: 1
    Memory:           8.00 GB

    Disks:
      Index:          0
      Instance ID:    9
      Capacity:       12.00 GB
      Disk Types:     SCSI-lsilogic

    NICs:
      Adapter Type:   VmxNet3
      Connection:     VM Network

Properties:
  Key:         guestinfo.hostname
  Category:    Networking
  Label:       Hostname
  Type:        string
  Description: Hostname of system

  Key:         guestinfo.ipaddress
  Category:    Networking
  Label:       IP Address
  Type:        string
  Description: IP Address of the system

  Key:         guestinfo.netmask
  Category:    Networking
  Label:       Netmask Prefix
  Type:        string
  Description: CIDR notation (e.g. 24 for 255.255.255.0, 28 for
               255.255.255.240)

  Key:         guestinfo.gateway
  Category:    Networking
  Label:       Gateway
  Type:        string
  Description: Gateway of the system

  Key:         guestinfo.dns
  Category:    Networking
  Label:       DNS
  Type:        string
  Description: DNS Server

  Key:         guestinfo.domain
  Category:    Networking
  Label:       DNS Domain
  Type:        string
  Description: DNS Domain

  Key:         guestinfo.root_password
  Category:    Credentials
  Label:       Root Password
  Type:        password
  Description: Password to login in as root. Please use a secure password

  Key:         guestinfo.openfaas_password
  Category:    Credentials
  Label:       OpenFaaS Password
  Type:        password
  Description: Password to login into OpenFaaS. Please use a secure password

  Key:         guestinfo.vcenter_server
  Category:    vSphere
  Label:       vCenter Server
  Type:        string
  Description: IP Address or Hostname of vCenter Server

  Key:         guestinfo.vcenter_username
  Category:    vSphere
  Label:       vCenter Username
  Type:        string
  Description: Username to login to vCenter Server

  Key:         guestinfo.vcenter_password
  Category:    vSphere
  Label:       vCenter Password
  Type:        password
  Description: Password to login to vCenter Server

  Key:         guestinfo.vcenter_disable_tls_verification
  Category:    vSphere
  Label:       Disable vCenter Server TLS Verification
  Type:        boolean
  Description: Disable TLS Verification for vCenter Server (required for
               self-sign certificate)
  Value:       False

  Key:         guestinfo.debug
  Category:    zDebug
  Label:       Debugging
  Type:        boolean
  Description: Enable Debugging
  Value:       False

デプロイすると

VEBA に HTTPS でアクセスすると ID/Pass が求められる。
User:admin / Pass:デプロイ時の openfaas_password で OpenFaaS の GUI が見える。

このとき、URL は IP でなくホスト名でないとアクセスできないので、DNS 登録するか hosts に IP とホスト名を書いておく(VirtualHost 的なあれ) OpenFaaS

https://【VEBAホスト】/status でステータスページ、
status

https://【VEBAホスト】/bootstrap で起動ログ(/var/log/bootstap.log を確認することができる。

起動ログはデプロイ時のパス3種 (root/openfaas/vCenter) がガッツリ出力されているので取り扱いにはご注意を…(debut=true のせい?)

今日はここまで

サンプルでも動かしてみようと思ったが、ローカルにコンテナレジストリを立てる必要があるらしく、とりあえず一旦ここまで。
続きはそのうち書きます…

謝辞

丁度 VEBA のデプロイをしていると VEBA の開発者である William Lam 氏 (@lamw) から熱い reply が。

丁度デプロイしたぜーと返信つけるともう一人開発者である Michael Gasch 氏 (@embano1) からも reply が。

Thank you for your kindness!!

vCenter アラートを今風に通知する

こちらの投稿は vExperts Advent Calendar 2019 の 10 日目になります。
初挑戦です(`・ω・´)よろしくお願いします。

adventar.org

vSphere Client も Full HTML 5 になったり Project Pacific が発表されてどんどん modern な環境を追及していく vSpehre ですが、vCenter のアラート通知は未だに SNMP or メール通知と中々レガシー…
ここも 今風な感じで Webhook 呼び出して Slack に通知を飛ばしてみる。

1. コマンドの実行

vCenter のアラートアクションに「通知トラップ」の「通知 E メールの送信」に並んで「コマンドの実行」がある。その名の通り、アラートの条件にひっかかった際に任意のコマンドを実行できる。

docs.vmware.com

公式 Doc を読む限りだと Windows 版 vCenter の例になっているが、vCSA でも使える。 なので、例えば vCSA に SSH でログインして以下を仕込む。

root@vcsa01 [ ~ ]# cat /usr/local/bin/alert.sh
#!/bin/sh
/usr/bin/curl -X POST --data-urlencode "payload={\"text\": \"${VMWARE_ALARM_NAME}\n${VMWARE_ALARM_TARGET_NAME}\n${VMWARE_ALARM_EVENTDESCRIPTION}\n${VMWARE_ALARM_ALARMVALUE} \"}" https://hooks.slack.com/services/【Token 的な何か】

これでアラーム定義から対象アラームのアラームルールでスクリプト実行を指定し、設置したパスを指定する。 スクリプト仕込み この状態でアラートを発生させる。
(試験的にアラート発生させるのはデータストア容量監視の閾値が個人的には楽) slack
メッセージに埋め込めるパラメータは環境変数に格納されており、↑ の公式 Doc の子ページに使える環境変数が載っているので欲しいメッセージの環境変数を組み合わせて埋め込んでやればOK。

正直 curl 叩いているだけなので個別にスクリプトにせず、スクリプト実行に直接 curl とオプション指定すればいけるかと思ったが、その場合だと何故か環境変数が空でメッセージが組み立てられなかった…なぜ…

2. snmptrapd

vCenter からは SNMP Trap 飛ばして、snmptrapd 側で slack へ POST する方法。
vCenter の設定的には全般設定で適当な SNMP レシーバを指定してアラートアクションに通知トラップを指定してやる。 SNMPレシーバ あとは SNMP レシーバ側で snmptrapd と curlスクリプトを仕込む。

# snmptrapd インストールは apt-get なり yum なりで
$ cat /etc/snmp/snmptrapd.conf
authCommunity log,execute,net public
traphandle default /usr/local/bin/alert2.sh

snmptrapd から呼び出すスクリプトが結構クセがあり、snmp メッセージを引数でなく標準入力で渡してくるので読み込みに一手間。さらに snmp メッセージがダブルクォートを含んでいるのでシェル → json 用に多重でエスケープが必要だったりでかなり面倒…

$ cat /usr/local/bin/alert2.sh
#!/bin/sh
while read line;
do
    text="$text$line\n"
done
text=`echo $text | sed s/\"/\\\\\\\\\"/g`

/usr/bin/curl -X POST \
        --data-urlencode "payload={\"text\": \"$text\"}" \
        https://hooks.slack.com/services/【Token 的な何か】

これでアラートを起こすと SNMPアラート と、アラートが投稿される。
このままだと何がなにやらなので公式 MIB を入れましょう。

kb.vmware.com

SNMPアラート with MIB (なんかまだ MIB が足りてないような…)

要望として

大体どこのチャットも Webhook があるので、そろそろ監視通知方法として HTTP 呼び出し辺りを実装してくれませんかねぇ… > VMware さん

一方ロシアは

Slack にメール送信で投稿した。

メールApp は有料プランでないと使えないので試せてないけど、多分コレが一番楽。
(組織によっては App 追加も色々ありそうだけど)

株式会社インターネットイニシアティブに入社しました

本日、株式会社インターネットイニシアティブに入社しました。

自身の IT エンジニアの看板は下ろし、今後は IT コンサルタントとして IT インフラやプラットフォーム、クラウド系のコンサルティングや PoC を行っていく担務になります。

コンサルと言っても ERP や業種/業務系のコンサルではないので、技術寄りな方…?

会社としては大規模に VMware なサービス展開を行っている会社ではありますが、部門として別のところで、自分が VMware に関われるかは担当プロジェクト次第なところもあり明言できませんが、VMUG や Meetup は何とか継続していければと考えていますので、関係各所の皆様には引き続き何卒よろしくお願いいたします。

OpenStack で感じる vSphere リソース抽象化のすばらしさ

タイトル長いな…
OpenStack 触ってたときに感じた vSphere リソース抽象化 の話。

OpenStack とは

今となっては言わずもがな、オープンソースで開発されているクラウド基盤。
ja.wikipedia.org コンピュートリソースやネットワーク、ストレージなどのハードウェアを抽象化して管理し、リソース操作 API を提供する。またユーザやテナント管理を提供し、サービス利用者は API を通じて On-Demand でのリソース利用を可能としている。

リソースの実体はバックエンドに存在している KVM や vSphere などの仮想化機構や物理ハードウェアから払い出される。 仮想化機構や物理ハードは OpenStack のコンポーネントからコミュニティや各ベンダで開発されている Driver や Plugin を通して操作され、リソース提供が行われており、OpenStack 自体が仮想化や Networking の機能を持ち、リソース提供しているわけではない。

OpenStack 自体が仮想化機能を持っているわけではない。(ここ重要)

vSphere vs OpenStack ?

上記の通り、OpenStack は仮想化機能を持っておらず、機能として競合するわけではないので、vSphere (ESXi) と競合するものではない。
というか、 VMware 社が VMware Integrated OpenStack (VIO)として提供、サポートするディストリビューションがあるぐらいの共存するべき存在のもの。
www.vmware.com

強いて言えば vCloud Director が競合しているんですかね?
vCloud Director は実物見たことないのでほとんど分からないんですけど…

VM リソースの払い出し

OpenStack での VM リソース払い出しは nova というコンポーネントが担当している。
ネットワークやストレージは他のコンポーネントになっているので今回は割愛。

KVM

バックエンドが KVM の場合、構成としては以下。
KVM nova-api, nova-conductor, nova-scheduler というプロセスが全体の Controller として管理を行い、nova-compute プロセスが各 HV 上に存在し libvertd 経由で各 VM を操作している。

大事なのは各 HV 毎に nova-compute プロセスが必要。

vSphere

一方で vSphere の場合の構成。
vSphere nova-api, nova-conductor, nova-scheduler は特に変わらないが、nova-compute は各 HV 上に存在するわけではなく、Controller の一部として存在し、ここから VMware 用の Driver 経由で vSphere API を叩く。
(ESXi 上にホイホイデプロイできないしね…)

KVM の場合だと HV 毎に必要だった nova-compute プロセスですが、
この構成の場合、nova-compute は vSphere のクラスタ毎に必要となる。

nova-compute配置
曲線オブジェクト難しい…

vSphere クラスタ = 巨大 HV

OpenStack での VM 起動は nova-scheduler が管理下の HV の残リソースや構成などから決定し、該当 HV 上の nova-compute に対し VM プロセスの作成を指示する。
vSphere の場合、nova-scheduler はどの vSphere クラスタ上に作成するかまでを決定し、どの HV 上に立てるかは vCenter の DRS 側でスケジューリングを行なっている。
※ なので OpenStack - vSphere 構成の場合、DRS (完全自動化) が要件になっている。
参考:OpenStack Docs: VMware vSphere

また、OpenStack 側で各 HV の残リソース情報を確認した際、nova-compute 経由で情報を取ってきているので、vSphere 構成だと表示される情報はクラスタリソースの合計値になっている。

つまり、OpenStack から見た場合、vSphere クラスタ = 巨大 HV とみなし、それにより KVM 構成と同じ nova プロセス構成で実現できている。

その根底にあるものは

OpenStack から話を展開してきましたが、別に vSphere クラスタ = 巨大 HV は OpenStack に限らず、vSphere が元々持っている抽象化の思想だと思います。
各 HV リソースを抽象化してリソースプールとし、必要に応じてリソースを払い出すというまさに仮想化、抽象化の神髄だが、このレベルでそれを実現できている製品は知っている限り他だと見当たらないような…
vSphere はそこに多くの実績があり、個人的にはアドバンテージの 1 つになっています。

そして、これを実現できているのは vMotion と DRS がかなり大きい。
vMotion は Live Migration として KVM もできたりするが、各 HV のリソース状況を取得して評価し、偏りが発生した場合は自動的に vMotion で均一化する DRS 相当の機能を実現しているものはあまり聞いたことなく…あるのかな? まぁ、vMotion 自体も信頼と実績が違いすぎる気も。

実際 KVM 構成の OpenStack だと結局 HV 単位のプロビジョニングベースでのリソース管理となっており、ノイジー問題を引くことも多々あった。
vSphere 構成の OpenStack だとクラスタ単位でのリソース管理となり DRS が効いているおかげでノイジー問題を引くことも少なかった印象。
(諸事情によりオーバーコミットはあまり攻めなかったが、おそらく KVM より攻めても全然大丈夫そう)

結局のところ

何か発散しそうなので無理矢理締めると

  • vSphere のリソース抽象化はすばらしい
  • vSphere クラスタ = 巨大 HV
  • その根底には vMotion と DRS

クラウド的に On-Demand で VM が作られる環境での vSphere は積極的に DRS を入れておくのがおすすめ。
これにリソースプールとかアフィニティルールがあったりでかなり緻密に管理できたりするのですが、On-Demand だとオーバースペックかも…
(リソースプールはともかく、アフィニティは都度 VM に適用なので)

ヤフー株式会社を退職します(しました)

個別にお知らせした方もいらっしゃいますが、
2019/10/31 付でヤフー株式会社を退職いたします。
実際のところは本日 2019/10/18 が最終出社日で、PC もスマホ社員証も全て返却済なので本日が退職みたいなものです。

関係各所の皆様には大変お世話になりました。ありがとうございました。

花
別にネガティブな理由やセンセーショナルな出来事があって辞めるわけではなく、面白可笑しく書けるような文才があるわけでもないのですが、一応ご報告までとして書いておきます。

退職エントリではないつもりですが、退職エントリになっちゃうのかなぁ。

退職理由

ネガティブな理由が何も無かったかと言われるとそうではなく、細かいものならありますが、それでも退職モチベーションになるようなものはありません。
他に興味があること、やりたいことができたというのが大きいです。

35歳プログラマ限界説

巷でよく言われるアレ。
ウチの会社に限ぎらず界隈を見てみるとナニソレな感じで、何歳になっても現役でコード読み書きしている人はたくさんいらっしゃいますが、やっぱりこの説は存在しているのかなというのが個人的実感。
別にコード読み書きするのがキツいとか限界とかではなく。
経験を積んで色々な視野が広がってきたことで現場エンジニアリングの背景の世界、それこそ IT 戦略や企画、ユースケースとかそんな話に興味が向いてきて、相対的に現場エンジニアリングやプログラミングへの興味が薄れてきたという感じ。
いわゆるコンサル的な上流への興味が大きくなり、そういうことができるところに行こうというのが大きい理由。

と言っても自分、今35歳でないですけど。

ヤフーに入社してどうだったか

もし違う会社に行っていたらみたいなタラレバはしてもしょうがないので知りませんが、
ヤフーに入社したことで VMware をガッツリさわり色々習得し、VMUG や vExpert、コミュニティ活動に参加でき、次の仕事へと繋がったと考えると間違ったものではなかったと思っています。

今後の予定

これから2週間ほどは遅い夏休みということで、実家帰ったり旅行したり、(車検から帰ってきたら)バイクで遠出とかしたいなぁと。
で、11 月より新天地での勤務となります。
そのため 11 月の動きが見えないので vForum は行けるかどうかは分かりません…

新天地についてはまだ入社前ということもあるので、 11月以降に Open にすると思います。