HCXのL2延伸ってすごい安定するなぁ
HCXのL2延伸ってすごい安定するなぁの件です。
昔々あるところに、NSX Autonomous Edge(NAE)でL2延伸を構成した案件がありましたとさ。
アプリサーバはVMC on AWSへ行き、DBサーバはオンプレミスに残りました。
はてさて、DBへのセッションが安定しないではありませんか。
これは厄介、厄介。どうしたものか。
にしても、こういうクラウドとのネットワーク関連のトラブルというのはホントに根深いですねぇ。。。
オンプレ側の基盤？ネットワーク機器？回線？Direct Connect？どこが原因？全部が原因？とか、これを解明するのは至難のワザでございました。
昔のWindowsは、レジストリでもコマンドでもTCP関連のタイムアウト値がイジれない、という壁もあったんですねえ。
そこでNAEをHCXに替えてみました。
すると、なんということでしょう。めっきりエラーがなくなったではありませんか。
ということで、すっかりみんなご機嫌になりましたとさ。
めでたしめでたし。
と、まぁNAEが悪いわけではない、と信じたい（結局根本原因は不明でした。技術者としてどうなのよソレ）ですが、HCXは偉大でした。
で、HCXの何が良かったか、って多分ですがコイツじゃないかと僕は踏んでます。
↓のTraffic Engineering ってヤツ！！
ちなみに、この機能は2020年11月以降、VMCのライセンスにバンドルされるHCXでも使えるようになった機能のひとつです。
Traffic Engineering には、TCP Flow Conditioning とApplication Path Resiliencyっていう機能があります。
詳しい説明は↑に任せます（よくわからない）が、それぞれ要約すると
・パケットのフラグメントを最適化する
・トラフィックパスを最適化する
というような機能です。
HCXのL2延伸設定時に、チェックボックスをひとつポチっとするだけで有効にできちゃう。
ありがとうHCX！ありがとう無償化！
教訓：クラウド移行する際は、アプリケーションの種類やトラフィックフローをちゃんと精査してから移行しよう！物理的なレイテンシは避けられないので！
