仮想化基盤のあれこれ

とあるIT企業でプリセールス所属だけどポストセールス(いわゆるデリバリー)を担当してます。VMware社製品が中心でしたがそれ以外にも手を広げ始めました。まぁクラウド時代なのでAWSとかAzureとかですね。

HCXの可用性向上って何が向上?

こんにちは、Yos235です。

 

もうすぐゴールデンウィークですが、休み期間中のトラブルによる呼び出し、
嫌ですよねぇ。サービス停止によって緊急呼び出しを喰らわないように、
システムの可用性向上策をいろいろと練り上げたくなるんですが、
いまやろうとしていたのが、東西サイト間での可用性向上。

 

HCXはオンプレからクラウドの移行に最適なツールですが、L2延伸の機能が在るがゆえにL2延伸したまま動かせばええやん!みたいな発想をされる方々が続出(個人の感想です)してるのを受けて、HCXはL2延伸用のコンポーネント冗長化することができるようになりました。

docs.vmware.com

 

でも、実はそれって各サイトにあるコンポーネントが2つになって、2つのトンネルが作られる、経路の可用性向上策ですね。2つのトンネルはアクティブスタンバイなので、コンポーネントが落ちたら切り替わるというもの。

 

2つ別々のキャリアで冗長網を持てる大規模案件なら良いですが、トンネルが2つとも落ちるってパターンが割と多いと思うのですよね。トンネルを終端しているコンポーネントが落ちたら、の対策よりもやって欲しいのはサイトが落ちたと検知と自動切り替えだったんで、ちょっと残念です。

 

今HCXでできるのは、(回線が2系統なければ)前述のコンポーネント単体障害、APR(HCXコンポーネント間の回線網を監視する)です。あとは、延伸先のゲートウェイからアップリンクに出すこと(トロンボーン現象の対応)は可用性というよりも移行途中の支援機能なのであんまり万能ではないです。このあたりをもう少し頑張ってくれると、ぼくら少しは安眠出来るんですけどね…

 

特に後者の機能はこれ素敵!って思ったんだけど、よく考えると延伸したセグメントが延伸先(ここ最近だとVMware Cloud on AWSかな)にいるってことを、外部にどうやって知らせるの?とか全体的な設計が必要だった

りするのでムズいのよね、実は。

 

まぁ、HCXは延伸がメインじゃなくて、移行を支援するツールなので(以下略

 

今日はこの辺で。