Simple 1500シリーズ The 虎舞竜 ～真冬のHCX怪奇現象編～
皆様ごきげんよう、私です。
つい先日、vExpert 2021を受賞することができました。
VMware製品を触り始めて7年ほど経ちますが、vExpertの応募に申し込んだのは
今回が初めてです。
巧拙はともかくとして、思いのほか、ブログを書くという行為は、
私の性分に合っているようで、
自分自身の技術ナレッジの整理にもなっているので、これからも積極的に
発信していきたいと考えています。
私も、ググって助けられたことがたくさんありますので、
私のブログが、誰かの一助になれば、とてもうれしく思います。
さて、今回は、『The 虎舞竜』シリーズ(?)として、
HCXデプロイ時にぶち当たった謎の虎舞竜について、記載していこうと思います。
※ HCXが何たるかは、別のタイミング説明します！ごめんちゃい！
あ、ありのまま今起こったことを話すぜ…！
とある案件でVMware Cloud on AWS(以降VMC)へ、オンプレミス環境のマシンを移行する案件で、『HCX』と呼ばれるコンポーネントを使うことになりました。
このHCXですが、準備だけ怠らなければ、作成自体は結構簡単なコンポーネントです。
私も検証のため、自宅で構築してみましたが、vCenter Serverの構築を含め、3時間もかかりませんでした。
と、ところが・・・いざお客様環境に構築すると、
構築に5日もかかったではありませんか・・・
催眠術だとか超スピードだとか
そんなチャチなもんじゃあ 断じてねえ
もっと恐ろしいものの片鱗を 味わったぜ…
どうしてこんなことに・・・
HCXのデプロイはざっくりと、
① ESXiの構築
② vCenterの構築
③ HCX Managerのデプロイ
④ サイトペアリング
⑤ Network Profileの作成
⑥ Compute Porfileの作成
⑦ Service Meshの作成
⑧ ＼(^o^)／
という感じです。
今回問題となったのは、このうち⑦ Service Meshの作成です。
本題。事象発生・迷走。
まず、HCXのもつ『Bulk Migration』と『L2延伸機能』を使い、VMware Cloud on AWSとオンプレミスを接続・仮想マシンを移行することがHCXを導入する目的でした。
Service Meshを作成すると、VMware Cloud on AWSとオンプレミス側で同一のHCXコンポーネントがデプロイされ、コンポーネントを経由してVPNやL2延伸が行えるようになります。
Service Meshを作成する段階で、
・Interconnect
・WAN Optimaization
・Bulk Migration
・L2 Extension
の4つのコンポーネントを有効にしました。
これらを有効にすると、VMCとオンプレミス側の両方のvSphere基盤上に、仮想アプライアンスがデプロイされます。
↑こんな感じ。諸事情により画面が黒っぽいです。
そして、Service Mesh作成段階で、これらのコンポーネント同士で通信を行うのですが…
はい！ここで問題発生！
Hybrid Interconnect(IX)のステータスが、なんとDownに…なるではありませんか…
( ﾟДﾟ)ﾊｧ?
( ^)o(^ )「いやいや。きっと、もっかいデプロイすれば治るやろ！」
( ^)o(^ )「ﾌｧｰｰｰｗｗｗ」
なんと今度は、NE(L2延伸してくれるコンポーネント)がダウンに…
お、おかしい…
空飛ぶスパゲッティモンスター教の熱心な信者である、
信心深いこの私が、構築の神に見放されるなど…
その後、
・Network Profileの再作成
・Compute Profileの再作成
はては、HCX Manager自体の再デプロイまで試したのですが、
いずれも効果はでず…
ただ、少しだけ原因となっているであろう箇所は特定ができていました。
それが、オンプレミスからインターネットへ抜けるために用意された「ルーター」の設定です。
だってよー、私の家の検証環境はうまくいってるし、インストーラーのハッシュ値も完璧、再デプロイでもダメなんだもの…環境の違いって、もうそこしかないぢゃん(´・ω・`)
その時、ルーターでは、何が起きていたのか。
私は、ネットワーク関連の知識がとにかく乏しく、
「ルーターが原因」ということが何となくわかっていても、「何が悪いのか」までは
判断ができませんでした。
お客様先のルーターはCisco製で、Config情報をいただいて眺めてみたのですが、6割ぐらいは何を書いているのか紐解けませんでした。
ただ、1点。NATテーブルを確認するためのコマンドである、
show ip nat transrations
の実行結果が非常に怪しいことになっていました。
んん？ちょっと待って。
4500番で出て行っている通信と1543番で出て行ってる通信あるんだけど、「1543番」って何？？
VMwareが公表しているHCXのポート要件で、
・Interconnect
・L2 Extension
のコンポーネントが使用するポートは、共にUDPの4500番です。
オンプレミス側ローカルIP
オンプレミス側グローバルIP
VMC側ローカルIP
VMC側グローバルIP
この4つの要素のつながりは、
オンプレミス側ローカルIP
→ (Source NAT)オンプレミス側グローバルIP
→ VMC側ローカルIP
→ VMC側グローバルIP
という感じです。
まず、オンプレミス側で4500番で出ていく通信は、
Source NATされてグローバルIPへ変換されます。
ネットワーク詳しい人に聞いてみたのですが仕様的に、オンプレミスIP：4500は、グローバルIP：4500へ変換されるそうです。(真偽不明)
つまり、ポート(ここだと4500)が一緒のものを使用するようなのです。
少し、整理しましょう。
この原理に当てはめるなら、
つまり、
192.19.72.202:4500で出ていく通信は、19.155.80.72:4500にSNATされます。
同じように、
192.19.72.203:4500で出ていく通信も、19.155.80.72:4500にSNATされるはずです。
つまり、同一グローバルIPの同一ポートを使用しようとしているということです。
4500番ポートのバッティングにより、後からデプロイされたNEは、4500番ポートが使用できず、1543番という自動採番されたポート番号を使用しようとしていたようです。
そらあかんやろ…(´・ω・`)
ポートバッティングが原因そうだったので、
Static NATを使うことで、この事象は無事解消しました。
とはいえ、謎は残る。
ネットワーク詳しい人でも、そうじゃない人からでも、んなもんあたりまえやん((￣δ・￣)ﾎｼﾞﾎｼﾞ な今回の事象を「怪奇現象」といったかというと、その理由が2つあります。
① なぜに私の家の環境では問題なく動作していたのか？
② 自動採番されたとはいえ、ポートがかぶってなければ動作してんじゃないの？
この2点の疑問が未だ解消されていないためです。
私の家にCiscoルーターなどという逸般の誤家庭にあるような機器はありません。
あるのは、バッ〇ァローのごく普通の無線LANルーターのみです。
この無線LANルーターがNATした際は、一体どんな動きをしていたのでしょうか？
ポートのバッティングをすることもなかったのでしょうか？
バッティングしていたとしても、Ciscoのように自動採番のポート番号を使っていたのでしょうか？
この辺りが未だに疑問です。
そして、今回この事象の解決に5日間もかかった最大の理由が、①です。
この先入観故に、NATは問題ないんじゃない？(^_-)-☆ という考えに囚われてしまったことが、事象解消の遅延を生んだ最大の要因です。
先入観にとらわれてはいけませんね…猛省です。
ちなみに・・・
以下の仕様があることをVMwareさんから確認ができました。
・HCXにおいて、VMCを起点とする通信はない。基本的に、オンプレミス発信の通信のみ。
・VMC側のコンポーネントが4500番ポートで受けられていることが最も重要。オンプレミス側グローバルIPが、4500番ポートを使用していなくても、VMC側のコンポーネントは特に問題がない。
ということでした。
なので、Static NATを使用して明示的にポート番号を指定してあげることは、
VMwareとして問題のない設定ということです。
いかがでしたでしょうか？
HCXが何たるかを説明する前に、HCXについてのトラブル事例を先に書いてしまいましたが、似たような事象にぶち当たった人の参考になれば幸いです。
でわでわ。
