今回は、
「VMware製品の脆弱性（VMSA-2021-0028）について」 と
いうタイトルでお送りします。
脆弱性情報が公開されました
Apache Log4jを使う多くの製品に影響があり、
さらに脆弱性の深刻度としてCVSSv3（Common Vulnerability Scoring System v3.0）
スコアは最大値の10です。
皆さんご注意ください。
https://www.vmware.com/security/advisories/VMSA-2021-0028.html
取り急ぎの情報のみですが、
ご参考まで。
今回は、
「『クラウド』サービスとのL2延伸（結論）」
というタイトルでお送りします。
前回、
「クラウドサービスとのL2延伸（備忘録的要素90%） - 器用貧乏、仮想化をあつかう
https://masaod94.hatenablog.com/entry/2021/08/29/212912」
で書いた話が決着つきました。
簡単に問題点だけ改めて書くと
VMware Cloud にL2延伸している環境で
一部のサーバだけをVMC側に移行した際に
オンプレに残している一部のサーバと
通信を行うとエラーが発生する（ことがある）。
全部がダメではなく、ICMPだったりは大丈夫、、、で
アプリが通信すると駄目になる。
結論、
問題の原因としては、L2延伸によって
Maximum Transmission Unit（MTU）が実質上小さくなることでした。
L2延伸と言ってますが結局VPNですから、
カプセル化する際の余計なヘッダが乗ってくる分
パケットサイズが制限されてしまうことによって、
パケットの断片化が起こりますからね。
（↑断片化されるような環境でも、仕組み上は、自動的に断片化して再結合して通信してくれるんですが、、、）
サーバの設定であったり、アプリケーションの設定で問題が発生することがありますからそこにハマっていたんでしょう。
今回は、ユーザの方で担当していたアプリケーション（DBだからミドルウェア？）の設定で、、、という話だったようです。（細かい設定までは教えてもらえませんでした・・）
そんなわけで、ユーザのDBチームの方で設定を変えて、
リトライした結果、通信の問題は起こらなくなったというわけでした。
まとめ？得られたノウハウ？としては、
アプリ含めてMTU小さくなって問題が出るアプリや
その設定が無いか事前に確認しておかないといけないですねー。
そういえば、余談ですが、
類似の話、、（なのか？）で、
昔もパケット断片化の問題あり、、、
この話はUNIXサーバ（OS）で断片化する際の断片化のやり方がまずくて、
構築していたベンダーさんに「なんでそんな非推奨な設定にしてるの？」と、
話をしましたが、、、。
その際の技術情報はIPAで公開されているこちらですね。
この中の「5) Protocol Stackのセキュア化」の話で、
これによって、うちが構築していた経路上のVPN装置で通信を
ドロップしていたという話だったような、、、。
ご参考まで。
今回は、
「NSX-Tを実装しました（いつもどおりの紆余曲折あり・・・）（２／２）」
というタイトルでお送りします。
前回の続きで、今回は前回お話したオーバレイを何故組まなければいけないという結論に至ったのか、、、という部分と、よく解説されているNSX-Tの基本的な動作の仕組みとの隙間を埋められれば、な感じでの話です。
（繰り返しですが、あくまでも自分が理解したイメージの様な話で、メーカ公表の正確な表示とは異なるかもしれませんが、理解する助けになるかもしれない、、、と書いてます。）
NSX-Vであれば、
Edge Service Gatewayをデプロイして、これを仮想のネットワークアプライアンス（Citrix ADC（旧NetScaler）などなど、、、）の様に単独のサービス提供者として使えばよかったわけですが、
NSX-Tは、、、
同じ名称？のEDGEは、、、立ち位置が違うんです。
何というか、そもそもNSX-TのEDGEは『Tier-0』、『Tier-1』Gateway（論理ルータ）というサービスを実行するための基盤（ハイパーバイザー的・・・）として動くんです。
上記を前提としておいて、
更に追加の条件として、NSX-Tでのロードバランサのサービスは、
Tier-1Gatewayにホストしなければいけない。
その為、NSX-Tのロードバランサを動かすためには、
Tier-1Gateway を正常に動かす＝EDGE（T1、T0の動作基盤）を正常に動かす。
そのEDGEを正常に動作させるためには、
オーバレイ用セグメントと、VLAN用セグメント（サービス用）をそれぞれ用意しておかないといけない。。。
と、逆順に書いていった結果、
そんなに難しい話ではなく、当たり前な話になってますね（笑
うーん、とはいえ、、、
参考にしてくれる（参考になる）方はきっといると信じましょう。
ちなみに、もう一つ余談ですが、
上記の様にEDGEとTier0、Tier1で組んだネットワークは論理ネットワーク内に構成されるんですが、バランス対象のサーバは論理ネットワーク内に組み込み必要はありません。
これも、、、論理ネットワークの中にバランス対象のサーバたちも組み込んで作らないといけないんじゃないか？と、途中で悩んでいたりもしたので、そこら辺を悩んでる方のために書いておきます。
Tier-1（およびサービス）をTier-0からルーティングなりNATなりで通信できるようにしておけば、これは問題ありません！
ご参考まで。
今回は、
「NSX-Tを実装しました（いつもどおりの紆余曲折あり・・・）（１／２）」
というタイトルでお送りします。
（※多分に私見（偏見？）を含んだ話で、某サイトであれば『要○○』が付く感じです（笑）
とあるユーザさんでNSX-Vで作られていたVDI環境を
新たに作り直すという案件で、
やることとしては、分散ファイアウォールを使ったマイクロセグメンテーションと、
管理系サーバの負荷分散をするための負荷分散装置を利用したい。
と、いう話だったんですが、、、タイトルおよび冒頭のとおり紆余曲折ありました。
そもそも、
なんというか、NSX-Vは正直いうとサーバを少し触れるネットワークエンジニアなら簡単に触れます（暴言？）、、、が、それは何をやらなければいけないというのが目に見えている（物理の考え方に近い・・・）のが大きいと思います。
それに対して、
NSX-TはSDN（Software Defined Network）を前提にした概念が必要な感じで構築しなければならず、、、オーバレイを考慮しておかないとうまく動かない、、、様に思えました。
NSX-Tの組み立て方的な話を公開されている方々は沢山いらっしゃるんですが、
この辺のどういうことを考えながらやらなければいけないかというのを書いてくださっているサイトは見つけられなかったんですよね。
（誤解が無いように、、、↑ディスっているわけではなく、
『手順として』こういう風にやればいいというのは大変役に立ちました（汗）
そんなわけで、他の方々が直接的に書いていない部分を埋める的な話で、書いていきます。
（ノウハウだから書かないのかもしれませんが・・・(笑）
端的に、
一番困ったのが、冒頭の要件を満たすために何をしたらいいのか。
自分が至った結論としては、、、
「NSX-Tを動かすために最低限の環境を準備しなければいけない。」
この最低限、、、が、どこまでやればいいのかを見つけられなくて困ったんですよねー。
勿体ぶってもしかたないので、
『NSX-TでOver-Layネットワークを組んでおいて、その上で様々なネットワークサービスを提供する。』んです。
これ、、、結構重要だと思うんですよね。
自分の様にNW畑出身で、NSX-V使っていた人間としては、
仮想のネットワークアプライアンスくらい普通にデプロイしてくれればいいのに、って思ってしまうと思うので、『なんで、コレ（このサービス）が動かないんだ？？』ってなることが多いんじゃないかと、、、。
長くなってしまいそうなので、２回に分けますが、、、
次回も宜しければご覧ください。
ご参考まで。
今回は、
「vSANデータストアに関する障害の話」
というタイトルでお送りします。
結構前にエンドユーザ様環境で発生した障害の話なのですが、
vSANのデータストアが溢れました...。
（溢れた…という表現が妥当なのかというのはあるのですが、、、。）
その当日、大分容量の大きな仮想マシンを
他のデータストアから移行してきていた様で
vSANデータストアとしての全体使用量は
溢れるところまでは行ってなかったのですが75%を超えていて、、、
それよりも問題はvSANクラスタの中の特定ホスト数台のDiskに
データが集中してしまい、該当のDiskの使用率が
100%になっていたという状態でした。
実害としては、
該当のディスクにデータ（オブジェクト）がある仮想マシンは
データストア内（ディスクに対して）で空き容量が無いために、
Suspendに近い状態となって動作しない状態となり、、、
vSANクラスタ内の仮想マシンに対して、かなり影響の大きい話となっていました。
動作的にはリバランスが必要になったホスト（ディスク）から
データを退避させるのにまず空きが必要なのに、
使える領域が少なくなってしまって
リバランスの処理が全く進まず、、、
という悪循環を繰り返していたような感じでした、、、。
このような状況から、、、
出来ること（メーカサポートからも言われたこと、、）というのは
『空き容量を確保してください』なわけで、
そして、
焼け石に水かもしれないとは思いながらも、
不要なデータ（各種OSなどのインストール用ISOや停止されている旧システムのVMDKなど、、、）を削除して、
少しでも容量を確保しつつ、リバランスが終わるのを
ひたすら、、、ディスクの状況を見守りながら待つ。
そんなわけで非常に幸運なことに
無事、、、データロストは無く復旧できたことから
リバランスの処理は遅々としてではあったものの
きっちりと動いていたんだなーと、再認識されられたとともに、、、
75%は超えないように運用するのが必須です、と、
改めてユーザ様には認識して頂かなければ、、、と、
ココロに決めさせられた事案でした。
いやー
本当に二度と遭遇したくないような障害でしたね。。
ご参考まで。
今回は、
「DCに居たら、停電してサーバルームが・・・」
というタイトルでお送りします。
ちょうど本日某所のデータセンタに居りまして、
12時52分ごろ、、、サーバルームが真っ暗になりました・・・。
↑
東日本旅客鉄道株式会社（JR東日本）さんの変電所で12時50分に火事があったらしく、その影響で周辺の送電網でも電圧低下が発生し、給電に影響したようですね。
（DC側で受電系統を切り替える際に、、、断したんですかね・・？）
今回は、
サーバ等の機器が接続されている電源はCVCF等で保護されていたのでしょう、、、ということで影響は無く、
作業しようとしていた我々が、え？え？？と、、、「窓のない部屋で真の暗闇・・・（サーバのLEDだけは見えましたが・・・）」に陥り、慌てていた？だけでした。。。
因みに、エアコンも止まってましたね。。
まぁ、、、
照明やエアコンは、、最悪自家発電設備（自家発）起動までの間、落ちても問題ない、、、ということなんでしょうね。
データセンタのファシリティ関連も含めてサービス化するために、入社当時の1年目に色々見てましたが、、、普通？10分以内には自家発が立ち上がるらしいですから、エアコンも止まっていても冷却性能に問題が無い（システムが止まる温度まではマシン内の温度が上がらない）ということなのでしょうね。。。
うーん、
クラウドなどなどの話を商材にはしてますが、
やはり物理的に問題が起きれば障害起きてシステムダウンするんだろうなーというものを目の当たりにしてきた日でした。。
因みに、古い？技術者（として？）の発言に取られてしまうんでしょうけど、、、
昨今クラウド化は進んではいますが、、、
インフラをやられる方は電機？電器？の基本的な話は知っておくと
障害原因の分析やらクラウド業者やDC事業者の説明のおかしなところにも気づけたりすると思うので、、、、、、
「非常～～」にFundamentalな部分だとは思いますが、知っておくべきだと思います。
（因みに、、、学生時代に研究室で分電盤の大元の方落としたり、、、色々やらかしたことあるからこそ、、、の発言です。。笑）
因みに、DC事業者さんが電力の使用量で、分電盤や回路ごとのブレーカ容量よりも少ないのにご指摘をされるのは、、、『何か』があったときに自家発に切り替えるまでのCVCFやUPSの容量が問題なんでしょうねー。。想定より使われてると、、、10分持たずに、、、。
・・・・・・
・・・。
多くは語りますまい。。。
これは当たり前の話ではありますが、、、
アプリよりな方がたは意識してないですし、、、
我々インフラ屋も改めて気にしてないといけないですね・・・。
ご参考まで。
今回は、
「VMware製品の基本中の基本、、、vSphereの機能について」
というタイトルでお送りします。
ポイントとしては、移行と、vMotionと、HAの話です。
自分が所属するグループの新人には、私が昔よく説明をしていた話でもあります。
うーん、社内の技術者？？？（敢えて3個ほど付けました笑）・・・
への愚痴も含んでの話になりますが、、、
エンジニアがちゃんと整理できてなくて話をされたがために混同させられてしまったエンドユーザ様もいるかと思い、そんなユーザさまのために敢えて書いておきます。
（↑この発言は夜道に気を付けないといけないパターンです(笑 ）
よくあるパターン
・vMotionとHAを混同している
・vMotionと「VMの移行」を混同している
上記は本当に「よくあるパターン」だと思います。
そもそも、vMotionとは、、、、、、
『仮想マシンのライブ マイグレーション
vSphere vMotion
vSphere vMotion を使用すると、サーバ間でのワークロードのライブ マイグレーションをダウンタイムなしで実行できます。ユーザーはシステムを継続して使用できるため、生産性を維持できます。』
そう、あくまでも『ライブ』マイグレーションなんですよ・・・。
と上記を踏まえて頂き、、、
これもよくある
『ホスト障害が発生した際に何故「vMotion」でマシンを保護できなかったのか？』
という質問に対しては、
vMotionはメモリ状態も移すからダウンタイムほぼゼロでホスト間を移行出来るものなので、
突発的に発生するホスト障害などでメモリ状態を移行できない状況では、vMotionはそもそも使えません。
『vSphere HA』は、突発的な障害などで仮想マシンを『再起動して』保護するものです。（大意）
ものすごく雑な感はありますが、、、
vMotionと、HAの違いは上記がポイントです。
あと一点、付け加えてですが、
VMwareだけではなく、仮想化そもそものポイントである可搬性の特徴でもありますが、物理ホスト間を移行しやすい、、、わけで、
「vMotionを使わなくても」普通に「移行」できます。
もちろんこれは、VMwareではvCenterがいれば、vSphere Client（GUI）でお手軽にできますし、いない場合やvCenter自身をオフラインで移行したいなどのときは、vmdkやvmxなどの必要なファイル（フォルダ）をマルっと移動して、インベントリに登録し直すとかでもいいわけです。
そんなわけで、言葉の定義の解説でした。
ご参考まで。
