前回のエントリでは vCenter Server 5.5 までの vMotion の歴史を機能を元に振り返りました。今回は vCenter Server 6.0 ~ Technology Preview の vMotion の歴史を振り返ります。

vMotion の歴史 (1) – 概要
vMotion の歴史 (2) – VirtualCenter 1.0 ~ 2.5
vMotion の歴史 (3) – vCenter Server 4.0 ~ 4.1
vMotion の歴史 (4) – vCenter Server 5.0
vMotion の歴史 (5) – vCenter Server 5.1 ~ 5.5
vMotion の歴史 (6) – vCenter Server 6.0 ~ Technology Preview/Research <= このエントリ

vMotion across vCenter Servers - 6.0 - 2015

バージョン 6.0 からは、遂に vCenter Server を跨いだ vMotion が可能となりました。まだ制約は多いモノの、この vCenter Server 越えの vMotion は、多くのサービス プロバイダーの悲願だったのではないかと思います。

この機能の追加に付随して、後述の以下の機能も追加となっています。

  • vMotion across virtual switches
  • vMotion across L3
  • Long Distance vMotion <150ms
  • Replication-assisted vMotion

詳細は こちらの VMware Japan のブログ を参照して頂いた方がよいかもしれません。

なお、NSX 6.2 の Universal Distributed Firewall (UDFW) の情報は、Cross vCenter vMotion で移行先の vCenter Server/NSX でも引き継ぐことが出来ます。このため、vMotion したら Firewall の設定がなくなっていた、などというセキュリティ的にトホホなことは無くなります。しかしながら、 Cross vCenter vMotion で持って行ける NSX の情報は UDFW の設定のみで、以下の情報を持っていくことは出来ません。

  • Service Composer
  • NetEx
  • Edge DFW Integration
  • SpoofGuard
  • Security Tags

Cross vCenter vMotion できない、というよりも 以下の情報に関しては、まだ NSX 自体が Cross vCenter に対応していないため。

なお、以下の KB に

VMware vSphere 6.0 におけるクロス vCenter Server vMotion の要件 (2111284)

  • vSphere Web Client を使用する場合は 、vCenter Server の両方のインスタンスが拡張リンク モードで、ソース vCenter Server がターゲット vCenter Server で認証できるようにするために、同じ vCenter Single Sign-On ドメイン内に存在する必要があります。

という素敵な一言があります。つまり、Web Service SDK を使えば同一 SSO のドメインに属していなくても Cross vCenter vMotion できる、ということです。RelocateVM_Task のパラメーター spec:VirtualMachineRelocateSpec のプロパティ service:ServiceLocator がポイントになります。この ServiceLocator に 移行先の vCenter Server の URL と Credential を指定して Cross vCenter vMotion させることができます。

RelocateVM_Task

お手数ですが検索で RelocateVM_Task へジャンプして下さい。
　
なお、vSphere 6 Documentation と KB2111284 の記述が異なっているので、現在修正依頼中 (2015/12/31)。

vMotion across virtual switches - 6.0 - 2015

いままで地味に分散仮想スイッチ跨ぎの vMotion ができなかったのですが、vSphere 6.0 でサポートされるようになりました。

vMotion across L3 - 6.0 - 2015

vMotion に関するパケットのみゲートウェイを変更することが出来るようになりました。これによって L3 を跨がる ESXi への vMotion 時のトラフィックであっても、vCenter-ESXi 間で使われている管理ポートから送受信されることがなくなりました。

vSphere 6.0 から正式に複数の TCP/IP スタックを vmkernel が持つことが出来るようになりました。複数の TCP/IP スタックを持つことで得られる最大のメリットは、vSphere の各機能毎に利用するゲートウェイを指定することが出来、各機能毎にトラフィックを制御できるようになったことです。

管理ネットワーク (HA など) と分離したいトラフィックとして よく vSphere Replication が上げられます。ストレージのリモートミラーリングの代替なので、当然と言えば当然なのですが、これが今まではスタティック ルートを使うなどして結構力業で実現していました。

vSphere 6.0 から複数の TCP/IP スタックを用意できるようになったので、vSphere Replication 用のゲートウェイを設定した TCP/IP スタックを vSphere Replication が利用するように設定すれば良いことになりました。

一方、vMotion。L3 を vMotion のバーストトラフィックが流れるとコア スイッチに負荷がかかり、さらには DRS を有効にしたときには目も当てられなくなるのが自明であり、vCenter との通信も押しつぶされかねないこともあり、これまで L3 跨ぎの vMotion はサポートされていませんでした。しかしながら、この TCP/IP スタックを複数用意できる機能と、ネットワークの構成も Leef-Spine 型といったルーティング負荷を分散させるアーキテクチャの導入も増えて来たこともあり、今回のバージョンから L3 越えの vMotion が可能となりました。

6.0 へのバージョンアップの痛みは伴いますが、vMotion にネットワークセグメントの縛りがなくなったことで、ハードウェア リプレース時の方法の選択肢が増えたのではないかと思います。

L3 越えの vMotion を許可しないと、長距離 vMotion や vCenter 越えの vMotion を可能とする構成が酷く狭い物になってしまいますからね…

Long Distance vMotion <150ms - 6.0 - 2015

長距離 vMotion を現実可能な条件で実行するために、vMotion が許容するネットワーク レイテンシを 150ms としています。これまでは、Enterprise Plus での 10 ms (それ以外は 5ms) だったので大きな進歩になります。

What is new for vMotion in vSphere 6.0?

TCP の Socket Buffer Size をリサイズするなどとありますが、詳細は公開していないのでお察し下さい。

Replication-assisted vMotion - 6.0 - 2015

これは、Active-Active の完全同期型のレプリケーションをしているデータストアであれば仮想ディスク ファイルの転送を省略することができ、極めて短時間で Long Distance vMotion を実現する機能になります。この「Active-Active の完全同期型」というのが非常にハードルが高いものになっております。この完全同期は、ローカルの LUN 上の VMFS が読み書き可能、且つ、リモート側の LUN 上の VMFS も読み書き可能というものです。

さすがにこれは条件が厳しく対応出来るストレージが限られてしまうので、vMotion のスイッチオーバー時のみ完全同期に切り替えるといった非同期型の対応や、将来の Virtual Volumes での解決を期待したいところであります。

vMotion across clouds - Technology Preview - ????

vmworld 2015 の基調講演で紹介された機能で、オンプレ上にある仮想マシンを vCloud Air 上に vMotion させる機能になります。vSphere 6.0 で可能になった Cross {vCenter, vSwitch, L3} vMotion を組み合わせれば実現できるのかというと、そうではなく 更なる積み重ねが必要になります。

  • vMotion のトラフィックは暗号化されていない
  • vCloud Air 側の vCenter とは通信できない

といった問題があります。しかし、同様の問題を抱える vSphere Replication が vCloud Air 向けに実現できているので、Technology Preview となっていることも感がみれは、そう夢物語ではないことも予想できるかと…Stay Tuned !!

「そこまでして持っていくか !? 作り直せばいいやん」という声もありますが、構築したエンジニアが退職してしまった、予算がなく担当 SIer に頼めないなどのロストテクノロジー化/オーパーツ化してしまったサーバーをクラウドに持って行くには良い手段ではあります。それだけなら vSphere Replication ベースの vCloud Air DR でいいんじゃないか？というツッコミもあります。ま、再起動はトラブルが起きやすいということで…ま、いずれも Chef、Puppet、Ansible などで Infrastructure as a Code としていればよいのですが、皆が皆、そうできるものでもないので現実的によいソリューションであるのは間違いないでしょう。

vMotion with RDMA - Research - ????

注) これは R&D の製品開発の現場で試験的に実装して性能評価を行ったことを対外的に発表されたものになります。将来的に RDMA を使った vMotion が追加されることが確約されているわけではないのでご注意ください。

High Performance Computing (HPC) に携わった事がある人などから、vSphere は Remote Direct Memory Access (RDMA) に対応しないのか？という質問を受けることがあります。Ethernet が 10GbE が主流になりかけている現時点において、Infiniband は FDR で 56Gbps をすでに達成し完全にこれが主流となっています。この超広帯域かつ低レイテンシーの Infiniband を仮想環境でも使いたい !!! という声は日本でも局部的に出てきています。

Hyper-V は対応しているしね…

残念ながら、現状 VMware としては対応していない、が答えとなります。しかし、Partner Verified Support Program (PVSP) という枠組みの中であれば Mellanox 製品/ドライバを使って対応することが出来ます。この Mellanox の 特製ドライバ は、vmkernel に OFED スタックを埋め込んでくれます。これは Infiniband のプロトコルを直接利用したい人向けになるかと思われます。Mellanox のシリコンは IB と Ether で共通化されており、40Gbps の Ethernet も製品としてリリースされています。この NIC のドライバは vSphere の Inbox ドライバーですので帯域が欲しい場合にはこちらをご利用頂くのがよいでしょう。

正直 40GbE は逝ったかなと…。10GbE の次は 25GbE や 50GbE の方が主流になるんじゃないかと思うところです。

昔、R&D の EVP に「HPC も市場が育っていて、5 万円 (当時は超円高) ちょっとで Infiniband HCA が買える時代なのだから、vSphere でも Infiniband サポートしようぜ！」と確認してみたことがあります。残念ながら、その答えは 10GbE の単価が安くなるし Ethernet が主流なのでそちらに注力する、とつれないものでした (ならなかったじゃろ？という思いはありますが…)。が、そうはいっても完全に無視しているわけではありませんでした。

社外で参照できる情報は Google で検索するだけでも、これだけの情報があります。ちゃんと実際に実装しテストも行われています (その上での未サポートなので無邪気に Reject しているわけではない)。

vMotion の Pre-Copy 時間の短縮と、送信側/受信側の CPU 負荷の低減、と良い所が数多く見受けられます。しかしながら、現在 vmkernel に存在しないプロトコルスタックを追加することになるので、開発工数、品質管理工数、保守業務工数などビジネス的にも簡単には追加できないのかも知れません。

そちらの筋の出身ではあるので個人的に待望の機能ではありますが、対応するストレージや対応ミドルウェアが増えてくるとまた状況は変わってくるのではないかと思います。

おわりに

なんとかギリギリ年内に書き上げられてほっとしています。改めて思うのは「VMware、vMotion に力入れすぎだろう」ということです。1TB の仮想マシンの vMotion とか頭が下がる思いで一杯… (実際にはこれは非常に重要。TB クラスになると OS やアプリケーションの起動が遅くなるため、ミッションクリティカルであればあるほど再起動出来るタイミングがすくなってしまう。)。NSX や vSphere APIs for IO Filtering (VAIO) などの新しい機能も vMotion と絡んでおり求められているのもが バージョンを重ねる度に増えている感がありますが、なんだかんだ言っても vSphere の Virtual Machine Monitor と vMotion が VMware の Originality ではあるので、ここは絶えず投資していって欲しいところです。