レアケースだとは思いますが、pyvmomiを利用する際のclientとサーバーの間にproxyがいる場合意外と接続が面倒だったので備忘録
参考は以下
要点は以下
pyvmomi-community-samples などで使われている、pyvmomiのSmartConnect や、SmartConnectNoSLL を利用せず、 SmartStubAdapterにproxyの設定を渡し, そのAdapterをVimSessionOrientedStubに渡し、VimSessionOrientedStubをServiceIntence生成に使うという方法になっている。
vSphereのAPI経由でオブジェクトの情報を参照したいとき、かつ、moidはわかっているので
改めてAPI経由で検索する必要がない時のショートカット方法のメモです。
from pyVim.connect import SmartConnect from pyVmomi import vim if __name__ == "__main__": si = SmartConnect( host="ip or fqdn", user="username", pwd="password", port="443", disableSslCertValidation=True ) vm = vim.VirtualMachine("moid", si._stub) print(vm.name)
この記事は2021年の vExperts Advent Calendar の23日目の記事です。
前日は MT9276さんの VMware HOLで、Apache Log4j のワークアラウンド手順確認(PythonスクリプトをHOLへ持ち込み) でした。 スクリプトを持ち込めるのは自分も初めて知りました！ HOLでWAを試せるとなると、複数回試すことができて、実際のWA適用の際に安心できるな、と思いました。
ものすごいいまさらですが、2021年からvExpertになりました、@yaaamaaaguuu です。
ブログやTwitterではあまり言及しませんが、普段はNSXの運用や検証, NSXを利用するソフトウェアの開発などに取り組んでいます。
せっかくなのでNSX-Tに関する記事でvExpertアドベントカレンダーの1記事を担当させていただきます。よろしくお願いいたします。
年末も近いので、大掃除をしないといけない気持ちになってきますね？
この記事では、NSX-TのAPIを利用して、検証等などで作ってしまった不要なリソースを消していく方法を紹介し、年末の大掃除でUIをひたすらポチポチし続ける苦行を回避する方法を共有しようと思います。
NSX-T上のオブジェクトを削除するAPIを取り扱います。削除APIをコールすると当然対象のリソースは削除されますので、対象を誤らないように気を付けてください。誤ったAPIコールで、誤ったオブジェクトを削除してしまっても私は責任をとれません。
また本記事は NSX-T 3.1系とLinux上で動作するコマンド (zsh, curl, jq 等)を利用した記事となります。
さらにVMC上のNSX-Tについての差異は扱いません。
2021/12/22 時点での最新のNSX-Tのバージョンは3.2.0となり、APIドキュメントは こちら となります。(基本的にはAPIドキュメントに記載されている内容の抜粋となります。)
何はともあれ、NSX-TのAPIをコールできないことには話が始まりません。とりあえずAPIをコールするにしても、認証情報を付与する必要がありますが、NSX-T上のユーザー名/パスワードをBasic認証の情報として付与してあげるとよいだけです。以下のようなコマンドになると思います。
# 試しにNSXのClusterの情報を参照してみる
curl -k -u "${username}:${password}" https://${NSXMANAGER}/api/v1/cluster/status
JSON形式でNSXのClusterの情報が出力されたら成功です。以降のAPIコールが上手くいかない場合は、利用してるユーザーの権限を確認してみるとよいと思います。(clusterのステータスの表示が上手くいかなくても、消したいと考えているオブジェクトを消す権限などがある可能性もあると思いますし、その逆もあると思います。)
APIコールが上手くいったならば、次に削除対象のオブジェクトを指定する方法を探します。
NSX-T の各個別API (例えば、セグメントを参照する GET /policy/api/v1/infra/segments など) には、細かい条件 (例えば表示名が HOGE で始まるなど) を指定する方法がありません。その代わりに Full text search API が備わっていて、こちらのAPIを利用すると、参照するオブジェクトをある程度細かく指定することができます。
このFull text search APIを利用するパスは2個あります。これは、Policy Planeのオブジェクトか、Management Planeでのオブジェクトか、を意識して使い分ける必要があります。APIドキュメント内の Searchable types には両方が記載されていますが、パスによって参照可能なオブジェクトが異なったりします。(Management PlaneのオブジェクトとPolicy Planeオブジェクトに関する詳細は別途NSX-Tのリソースを参照してください。)
GET /policy/api/v1/search/query
GET /api/v1/search/query
APIパスについてをなんとなく把握したら、次はFull text search APIで利用するQuery Syntaxについてです。とはいっても、こちらのSyntaxについてもあるドキュメント程度詳細に記載されているので要点だけ記載します。
ということで、簡単な例を記載しておきます。
# NSX-T上のグループ かつ 表示名の先頭がYAMAGUCHI_ となっているモノ
curl -k -u "${username}:${password}" -k -G --data-urlencode 'query=resource_type:Group AND display_name:YAMAGUCHI_*' 'https://${NSXMANAGER}/policy/api/v1/search'
あとは、上記の要領で、必要となるオブジェクトを検索するクエリを作り上げます。
ここまで来たらあとは、大した手間ではありません。 resource_typeで削除対象としたいオブジェクトを指定しつつ、各個別のオブジェクトの削除APIをたたいていくとよいです。 APIレスポンスからうまく削除対象のidを引き出すためにjqなどと合わせながら以下のようなスクリプトを組みます。(jqがよくわからなければ、 https://stedolan.github.io/jq/manual/ あたりのマニュアルを眺めるとよいです。)
# 例えばYAMAGUCHI_とPrefixのついたグループを片っ端から削除する
for groupId in `curl -k -u "${username}:${password}" -G --data-urlencode 'query=resource_type:Group AND display_name:YAMAGUCHI_*' 'https://${NSXMANAGER}/policy/api/v1/search' | jq '.results[].id' -r`;
do
echo curl -k -X DELETE 'https://${NSXMANAGER}/policy/api/v1/infra/domains/default/groups/'$id;
curl -u "${username}:${password}" -k -X DELETE 'https://${NSXMANAGER}/policy/api/v1/infra/domains/default/groups/'$id;
sleep 1;
done
NSX-T のAPI + jq + shell script で NSX-T上のオブジェクトを一括で削除する方法を記載しました。
NSX-T上のお掃除はAPIをうまく利用してサッとやって年末を迎えましょう。
この記事は2021年の vExperts Advent Calendar の23日目の記事でした。
明日は、Yuki Kawamitsuさんがストレージ関連で何かの記事を投稿するとのことです。お楽しみに！
https://kinesis-ergo.com/wp-content/uploads/kb500-user_manual.pdf を見るとよいのだけども = + w を押すと元のF1~F12に戻る。
( = + m を押すと、マルチメディアグループ機能というやつが有効になって、F10とかF11あたりを押すとボリュームのアップダウンになる。)
マルチメディアグループが有効になっていると、IDEを使っているときのF1 ~ F12 を交えたショートカットが軒並みダメになってめちゃくちゃ不便。
この記事は富士通クラウドテクノロジーズ Advent Calendar 2020の24日目の記事です。
23日目は id:foobaron さんの EVPN L2VPN All-Active MultihomingにおけるRoute Typeと経路迂回 でした。 データセンターのネットワーク運用者は要チェックです。
25日目は inasato さんの 「ESXi Arm Edition v1.1 で物理 NIC の追加してみた」 です。
アドベントカレンダー24日目の記事です。12/24といえばクリスマスイブです。どんなプレゼントがもらえるか？がワクワクする日ですね。インフラエンジニアならば誰しもがクリスマスにロードバランサーをプレゼントされるのを夢見たことがあるのではないかと思っています。
クリスマスとは関係ないですが、ロードバランサーを触る機会をいただくことが年々増えているため、一度ロードバランサーの入門前に知っておきたかった話 (もしくは一度知ってしまえばなるほどね。と思えるような話) をまとめておこうと思います。いろいろなことを書こうとは思いますが、LBに精通しているわけではないので抜け漏れはあると思います。
以下の文章でロードバランサーはLBと省略し、以下のようなことを記載します。
以下のようなことは本記事では記載しません。
基本的にはある1つの宛先に対する通信を受け取った際に、設定した複数の宛先に振り分けることがLBには期待されます。例えば1度目の192.0.2.1に対する通信を192.0.2.11に、2度目の192.0.2.1に対する通信を192.0.2.12に振り分ける、といった振る舞いを期待します。ユースケースとしては複数台用意した同一のwebアプリケーションサーバーに通信を振り分けること実現します。
1つの宛先を複数の宛先に振り分ける都合上、複数の宛先が宛先として機能するか？を確認し、宛先として機能しない場合は宛先としては見なさない様にすることもLBには期待されます。具体的な例を挙げると、LBから一定の間隔で振り分け先のIPに対してICMPでの通信を試みて、複数回の返信がなければ振り分け先のサーバーから除外する様な振る舞いを期待します。ICMPは具体例の一つで、試みる通信のプロトコルや試みる頻度が選択可能であることも期待されます。通信の振り分け先が全て不能の状態だと判定した際にはLBがエラーのページをレスポンスすることも期待されます。
また、LBはクライアントとコンテンツをレスポンスするサーバーの中間に位置する都合、複数の振り分け先で処理するよりも中間のLBで処理してしまった方が良いことを処理することも求められます。よく挙げられる例としては、SSL/TLSの通信の終端や、特定の通信を許可/拒否するフィルタリングですが、解釈するプロトコルがより高レベルなものだと、認証認可のための処理を挟むことができたりします。
最後に、LBは、ある宛先に対する通信を1度集約し、分散させる装置である都合上、LB自身に可用性が期待されます。具体的には, 2台以上の同様なLBでActive/Stanbyの構成や、Active/Activeの構成が取れることを期待されます。また1台のLBに障害が発生した際にも、既存の通信に与える影響を最小に通信の処理を継続できることが求められます。
ここではLBのネットワーク構成などについて言及しようと思います。 物理的な話や論理的な話での分類というよりは、対比しやすい話を記載していきます。
以降いくつかアイコンを用いた図を使いますが、以下のようなイメージで使い分けています。また黒い線はネットワーク的な繋がりを、オレンジ色の線は通信の経路を示すつもりで利用しています。
イメージをつかむ足がかりになることを目的としているので、正確な構成図は示しません。
また特にロードバランサーのアイコンは後述するLB装置/バーチャルサーバー/LBインスタンスとしてのアイコンを特に使い分けていません。話の文脈的にLB装置であるか、バーチャルサーバーであるか、LBインスタンスであるか？を識別するのが重要なときだけどのような役割でLBアイコンを使っているか記載します。
LBと一口に言っても、物理的なハードウェアを利用して実現する方法や、仮想サーバー上のOSにソフトウェアをインストールして実現する方法などあります。
物理ハードウェアや仮想サーバーなど複数のLBのための装置を1セットのLBとみなした時、更にそのLBの中で複数のロードバランスの設定を持つことができるケースが多いです。LB装置内部に仮想的なサーバーを持つようなイメージでバーチャルサーバーと読んでいるようです。ここではバーチャルサーバーと書きましたが、この呼称はLB製品によってまちまちだと思います。
下記の図でLBのアイコンは、実際にパケットを処理しているプロセス的な何かだとイメージしてください。良い言葉が無いのでこの文章ではLBインスタンスと呼びます。
LB装置とバーチャルサーバーの設定と、LBインスタンスなどの組み合わせにより無限に考え方があると思うのでコレはあくまで一例です。
例えば、Active/Stanby構成のうち、片方のバーチャルサーバーの通信を処理するLBインスタンスのActive/Stanbyを入れ替えるとLB装置としてはActive/Active に見えたりすると思います。 (実際に通信を賄うのはどちらかになるので、バーチャルサーバーから見たらActive/Stanbyは変わらないですが。)
またLB装置が複数のケースでもそうで、バーチャルサーバーの設定の適用範囲や、その適用範囲のうちどのように通信を処理するLBインスタンスが稼働して通信をさばいたりは様々な組み合わせがあります。モノによって組める構成は異なると思うので要確認です。
バーチャルサーバーは通信を受け付けるIPを設定する必要があります。その通信を待ち受けるIPをVIP (ビップもしくはブイアイピイ)と呼びます。バーチャルサーバーのIP で Virtual IPとのことです。
前述したようにLBには可用性が求められます。2台のLB装置でActive/Stanbyの構成を作り、Activeが障害を起こすとStanbyに切り替える構成をよく聞きます。またソフトウェアで実現するロードバランサーでは3台以上のLB装置を連携させる方式も聞きます。
特にソフトウェアベースのLBで3台以上を連携させるときに見かける方式としては、代表のノードが一度通信を受取、L2の宛先を書き換えて他のLB装置に転送する方式と、上位のルーターとBGPで連携し上位ルータの段階で複数のLB装置に通信を分散させる多段なロードバランサーを構成する方式を見かけます。
以下の図では振り分け先サーバーを省略していますが、オレンジ色の先が届いているActiveと記載されているLBから振り分け先に通信を転送することになります。
続いてイメージしやすい話を記載すると、1arm, 2armインラインがあると思います。 1armは通信を受け付けたNICから振り分け先サーバーに通信を転送する構成で、2arm/インラインは通信を受け付けたNICとは異なるNICから振り分け先に通信を転送する構成になります。
クライアントとクライアントからのリクエストを処理する間にロードバランサーが存在することになります。クライアントからロードバランサーがVIPで通信を受け付けた際に、送信元IPアドレスをロードバランサーが書き換えずに振り分け先にパケットを転送するのが透過IP(P透過, 透過モード)、 送信元IPアドレスをロードバランサーが設定されたIPに書き換えるのがSNAT (透過IPと対比して、非透過と呼ばれることもあるらしい) です。
また送信元IPを書き換えてしまうと、振り分け先サーバーでは本来の送信元が不明になります。そのための対策としてHTTPの通信をロードバランスする際にX-Forwarded-Forヘッダーにもともとの送信元IPを記載する機能や、HTTPも含めその他のプロトコルの際にも送信元がわかるようにProxy Protocolに対応する機能があったりします。
Active機が故障し、Stanby機がActive機に昇格するような際に、Active側で待ち受けていたIPをStanby側に引き継ぐ必要があります。所有者が変わる必要があるさまを指してFloating IP と読んでいるみたいです。
個人的にはStackoverflowのこの解答 を読んでわかった気分になりました。
複数のロードバランサー製品を見て共通で備わっている機能には以下のような項目があります。 この項目と、前述のネットワーク構成の設定を組み合わせてロードバランサーを実現することになります。
具体的な要件が決まっている設定値は、要件が満たされているか？を確認すると良いと思いますが、そうでない値はどのような機能があるかを眺めながら動作確認することになると思います。
検証をする際に利用すると便利なツールを雑多にいくつか紹介しておきます。これらのツールを用いて、前述の設定項目/機能が意図通り動作しているか？を確認していくことになると思います。
ここで上げるツールは基本的にLinuxで使えるものを挙げます。
自分がLBを学ぶにあたっては、以下の資料が大変参考になりました。
ロードバランサーの初歩的な話をまとめて記載しました。将来的に誰かの役に立てば幸いです。
この記事の図は https://app.diagrams.net/ と ニフクラ アイコン＆シンボル を利用して記載しました。
この記事は富士通クラウドテクノロジーズ Advent Calendar 2020の24日目の記事です。
23日目は id:foobaron さんの EVPN L2VPN All-Active MultihomingにおけるRoute Typeと経路迂回 でした。
25日目は inasato さんの 「ESXi Arm Edition v1.1 で物理 NIC の追加してみた」 です。 Raspberry Piで実現できるESXi Armの欠点を克服しそうなネタなので楽しみですね。
Emacsで手動でhexを入力してバイナリを編集するための備忘録
例えば30日OS自作本などだと最初にhexを入力しましょう。みたいなのが出てくるのだけども、そういうのこそ使い慣れたEmacsでさっとやってしまいたい。
Emacsの標準のhexlモードだと人間がhex値を入力することでバイナリを編集するのは可能(C-M-x
nhexl-mode をインストールする
M-x package install
M-x nhexl-mode M-x nhexl-nibble-edit-mode
この記事は富士通クラウドテクノロジーズ Advent Calendar 2020の3日目の記事です。 id:yaaamaaaguuu が記事を書き、職場の先輩である id:hidemium さんからフィードバックを受けて加筆修正したものになります。(hidemiumさんありがとうございました。)
2日目はdaprでつくるマイクロサービスでした。daprが便利そうなことが伝わってくる記事でした。自分も後日試してみたいと思っています。
皆様にとって、2020年はどのような年だったでしょうか？
個人的には VCP-NV と呼ばれるVMwareの資格を取得するために色々と取り組んだことが心に残っています。
資格試験のためだけではないですが、自宅にVMware製品を導入した検証環境を構築してVMware製品を検証することが多かったため、そのまとめとして、VMwareのデータセンター向け製品を個人で検証するためのTipsを紹介することで、個人で検証するためのハードルを下げることができたら良いと思っています。
あくまで検証用途です。本番環境で今回紹介するTipsを適用すると、本番環境でサポートされなくなる可能性のある手法も含みます。筆者宅の検証環境などで試していることが大半ではありますが、試す際はご自身の責任でお願いいたします。
VMwareが用意しているHands on Labを利用しましょう。
利用したい製品がデプロイされるHoLを起動し、用意してあるトレーニングのメニューを無視して、 自分の確認したいことをさっと確認してみる、というのは新しい製品で検証環境が十分でないときに有効な手段です。
ESXiはMyVMwareに登録したらisoをダウンロードできたと思うので、そちらを利用すると良いです。
ネットワークの構成や性能にかかわらず、物理のESXiを用意したい場合は、IntelのNUCを購入しESXiをインストールするのが良いと思います。なぜIntelのNUCを推すかというと、William Lam 氏のブログ https://www.virtuallyghetto.com で頻繁に推されていて、 動作確認がされていることが多いからです。もし将来的にvSANなどを検証したい場合は2.5インチベイがあるほうを選ぶと良いです。
NUCなどを利用していてPCIeなどで物理NICを拡張することができない場合や、適当なコンピュータのマザーボードのNICがESXiに対応していない場合はこちらのDriveを導入してUSB NICをつかうことになります。USB NICは製品によってサポートされるMTUの上限が異なるポイントに注意してください。(自分が複数購入したものは4500程度でした。)
個人的には試せていないのですが、 (1台あたりの価格が通常のNUCよりだいぶ高価ですが) Intel NUC9 extreme を利用するとNICの構成の問題を解消できると思います。
またx86にこだわらない場合、Raspberry piなどで試せるESXi Arm Editionなどが選択肢に入ってくると思います。
物理ノードのリソースは、システム要件 (+お財布事情) に沿って用意していただくのが良いですが、vCenter,NSXの検証でCPUのリソースの実消費は比較的少ないのに対し、メモリの実消費は比較的多いことに注意する必要があります。
具体的な話をすると、筆者の検証環境は、core i3-6100U, 32GBのメモリのNUCが3台構成のところにvCenter/NSX-T Managerをデプロイ、HAとvSANを有効にしている状態で以下のようなリソース状況です。
本番環境では互換性のある物理サーバーを用意してください。
物理のマシンにESXiをインストールする以外に、ESXiを仮想マシンとして用意する方法があります。ネステッド もしくは ネスト と呼ばれています。物理のESXiの上にNested ESXiをデプロイして、Nested ESXiの上に仮想マシンをデプロイして色々試すことが可能です。試したことはないですが、VMware のWorkstationやFusionで動作させる方法もあるようです。
Nested ESXi を用意するには２つ手法があります。
上記の2つの方法のうち、前者に取り組むことは勉強にはなりますが、用意するのに割と手間がかかります。Lam氏の公開しているNested ESXiのイメージが非常に実用的なため、そちらを利用するとよいでしょう。ただし、公開されているovaのハードウェアバージョンが比較的新しいため、 場合によっては自分でisoから用意する必要があります。
Nested ESXi を稼働させるにはいくつか気をつけたほうが良いことがあります。
あくまで個人向けの検証用途の話です。
VMUGのAdvantage のライセンスを利用するのが良いと思います。値段は$200/year (2年継続だと $180/yer, 3年継続だと $170/year)だそうです。
2020/12/02 だと、vCenter, NSX-v, NSX-T, vSAN, Tanzu などに加えて、
VMware FusionやWrokstationのProなどがダウンロードできるライセンスとなっています。
前述のNUCなどにESXiをインストールするか、Fusion/Workstationで各アプライアンスを起動して検証する形になると思います。
各種vSphereやNSXの機能の利便性を実感するには、複数のESXiがある方が良いケースが多くあります。そして複数のESXiを用意して検証をするには最低限スイッチとNASではないかと考えています。
宅内検証環境の物理構成の詳細に言及し始めるとキリが無いので、この記事ではこの程度にとどめます。
vCenterをESXiにさっとデプロイするには、isoからGUIのインストーラーを起動するのが一般的ではあると思います。
ただ、vCenterをインストールする際のパラメーターは決まり切っているので、
検証の際に何度もいちいちGUIでパラメーターを埋めて...というのは面倒な気がします。
そんな時は、govc をつかって、vcsaのアプライアンスをデプロイすると良いです。
# iso をmountする, ディレクトリは適当 mount -t iso9660 VMware-VCSA-all.iso /mount_dir # iso 内のvcsaのovaからインポート用の情報を生成する govc import.spec /mount_dir/VMware-vCenter-Server-Appliance-xxxx_OVF10.ova | jq . > vcsa_import_spec.json # vcsa_import_spec.json を適切に編集する # guestinfo.cis.deployment.autoconfig = "True" にすると、 # vcsaを起動後にパラメーターに沿って自動的に設定してくれます。 # https://www.virtuallyghetto.com/2016/10/how-to-deploy-the-vcenter-server-appliance-vcsa-6-5-running-on-vmware-fusion-workstation.html が参考です。 # import.ova には適当にデータストアやデプロイ先を指定するオプションが必要です。 govc import.ova -options=vcsa_import_spec.json /mount_dir/VMware-vCenter-Server-Appliance-xxxx_OVF10.ova
こちらの方法はVMwareのドキュメントに記載があるものではないので、あくまでデプロイを簡易にする非公式手順であることに留意してほしいです。
NSX-T Managerもovaをデプロイ直後はメモリのリソースの予約 (手元の環境で見ると16GBのメモリ) が入っています。検証環境のリソース状況によっては、NSX Managerが起動できないケースや、NSX Managerが起動できても他のVMが起動できなくなるなどが考えられます。
リソース不足起因のトラブルを踏まないようにするためには、検証環境のリソースを増強するのが良いのですが、暫定的にはNSX Managerのメモリの予約を外してしまうことでNSX Managerや他のVMが起動できなくなることを回避できます。
商用の環境でNSX-T Managerのリソースは予約は外さないでください。
NSX-T Managerはスナップショットをサポートしていません。そのためにアプライアンスでスナップショットを無効にする方法 がドキュメントに記載されています。またNSX-T 3.0.1 以降ではスナップショットが取れなくなるための設定が予め入っています。
しかし、個人の検証レベルではサポートを受けられるか否かよりも、例えばテキトウにスナップショットを取ってアップデートを実施してみるなどの気軽さのほうが大事な気がします。ということで、ドキュメントに書いてあることに逆らうことにはなりますが、仮想マシン オプションから snapshot.MaxSnapshots を必要に応じて編集すると良いと思います。
VMwareのデータセンター向け製品を個人で検証するためのTipsを記載しました。何かの参考になれば嬉しいです。
今回のTipsは個人向けということで、ドキュメントの互換性や手順などを、思いっきり無視しているモノとなります。
間違っても商用の環境で試すなどはしないでください。
この記事は富士通クラウドテクノロジーズ Advent Calendar 2020の3日目の記事でした。
明日の4日目はGit Hooksでうっかりミスを防ぎたいだそうです。gitのhookは非常に便利なのでどのような記事が投稿されるのか楽しみですね。