vMotion の歴史 (4) – vCenter Server 5.0
前回のエントリでは vCenter Server 4.0 ~ 4.1 までの vMotion の歴史を機能を元に振り返りました。今回は vCenter Server 5.0 の 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
Metro vMotion (<= 10ms) - 5.0 - 2011
vSphere 4.1 でも RTT 5ms 以下のレイテンシならばサポートされていた vMotion ですが、vSphere 5.0 では RTT 10ms までサポートされるようになりました。※ ただし Enterprise Plus に限る つまり、データセンター跨ぎの vMotion も RTT 10ms 以下ならば可能になりました。
Enterprise Plus に限ると書いていますが、実際に Metro vMotion 可能な環境となると非常にブルジョアな環境となります。
- 完全同期レプリケーションのストレージ
- L2 延伸
この 2 つが必要となります。
完全同期レプリケーションのストレージが無ければ、vMotion 先のデータセンターでデータストアを読み書きできません。完全同期が可能なストレージやストレージ オプション、そして付随する機器はそれなりのお値段となり、この完全同期レプリケーションを可能にする回線費用も馬鹿になりません。また、Metro vMotion が可能な vSphere Metro Storage Cluster (vMSC) には認証制度があり、VMware Compatibility Guide (VCG) の Array Test Configuration で確認することができます。現在では以下の 7 種類から選択できます。
- iSCSI Cluster Metro Storage
- FC Cluster Metro Storage
- FCoE Cluster Metro Storage
- NFS Cluster Metro Storage
- FC-SVD Cluster Metro Storage
- iSCSI-SVD Cluster Metro Storage
- NFS-SVD Cluster Metro Storage
SVD は Storage Virtualization Device の略で、ストレージのヘッドと機能し、そのボリュームはヘッドの配下にぶら下げたストレージアレイからボリュームの領域を切り出します。有名処だと
- IBM SVC
- EMC VPLEX
といった SVD があります。
そして、vMotion する仮想マシンは IP アドレスが変わらないので、vMotion 先のデータセンターで仮想マシンが通信するために、移行元のデータセンターと移行先のデータセンターで L2 延伸する必要があります。L2 延伸に対応したスイッチはそれなりのお値段になります。最近リリースされた VMware NSX が 6.2 では複数 vCenter に対応し、ソフトウェアによる L2 延伸も可能になりましたが、それでもコスト増の要因になります。
詳細は以下の技術文書を参照してください。
Stretched Clusters and VMware vCenter Site Recovery Manager - Understanding the Options and Goals
この技術文書では、Cross-Site Fault Tolerant (RTT <1ms!!) という斜め上のネタにも触れられています。
Storage vMotion (Snapshot support) - 5.0 - 2011
vSphere 5.0 から スナップショットを持つ仮想マシンでも Storage vMotion を実行できるようになりました。
vSphere 4.0 から UI 上で Storage vMotion を使えるようになり、Storage vMotion を気軽に実行できるようになりました。しかし、計画的にストレージ移行を行うために業務調整を行って いざ作業当日に実は仮想マシンがスナップショットを持っていて Storage vMotion できませんでした、という悲劇が結構あったのではないかと思います。つーか、実際にありました…Orz。 VIVA vSphere 5.0 !!
Storage vMotion (mirrored I/O) - 5.0 - 2011
地味な改善ですが、vSphere 5.0 では Storage vMotion 中の Write I/O の扱い方が全く変わりました。
これまでは、ヘルパースナップショットが出来たり、Change Block Tracking (CBT) を使った実装でした。しかし、この実装では Storage vMotion で VMDK をコピーする速度よりも多くの Write I/O が来てしまうと、永遠にコピーが終わらないという問題がありました。
まぁ、そんな I/O が多いときに Storage vMotion すんな、というツッコミはあるのですが…。
Write I/O を、移行元の VMDK、および 移行先の VMDK の両方に行うことで、更新分の I/O についてはコピーし直すことが不要となります。
Multi NIC vMotion - 5.0 - 2011
今までは vMotion のバースト転送を 1 セッションで行っていたのを、vMotion で利用できる IP アドレスを複数にすることで、複数セッションで行えるようになりました。このとき vMotion に利用する vmkernel 用の vmk? は、全て同じサブネットの IP である必要があります。
vMotion migrations fail when using multiple VMkernel ports for vMotion in different IP subnets (2052092)
別々の IP サブネットで vMotion に複数の VMkernel ポートを使用しているときに vMotion 移行が失敗する
Multiple-NIC vMotion in vSphere (2007467)
vSphere 5 での Multiple-NIC vMotion
これを説明するときに、バッファローマン戦のウォーズマンによく例えていたのですが、あまりウケは取れませんでした…Orz
Stun During Page Send (SDPS) - 5.0 - 2011
仮想マシンの性能を意図的に落とすことで、vMotion の成功確率を上げる機能になります。
vMotion では、稼働している仮想マシンのメモリを、変更分のビットマップを取りながら、移行先のホストに送信します。これを Pre-Copy といいます。そして、仮想マシンをフリーズし仮想マシンのメモリが変更されない状態にしてから、ビットマップを参照しPre-Copy 中に変更したメモリ領域を移行先のホストに送信し、移行元のホストと移行先のホストで仮想マシンのメモリイメージが等しくなるようにします。この Pre-Copy 中に変更したメモリ領域があまりにも大きい場合、そのまま仮想マシンをフリーズして転送してしまうと、仮想マシンのフリーズ時間が長くなってしまいます。つまり、仮想マシンの停止時間が長くなってしまいます。これを避けるために、Pre-Copy 中に変更されるメモリ領域がが多い場合は、直前の Pre-Copy 中の変更分に対してさらにビットマップを取りながら、変更分の Pre-copy を行います。こうして Pre-Copy 後のメモリ変更分が十分小さくなり、仮想マシンの Switchover が短い時間で済む目処が立つまで Pre-Copy を繰り返します。
しかしながら、非常にメモリの書換が多い仮想マシンの場合、vMotion の Pre-Copy の転送速度を仮想マシンのメモリ書換速度を上回ってしまうことがあります。この場合、残念ながらいつまで経っても Pre-Copy 後の変更分のメモリ領域が小さくならず、最後には vMotion が失敗してしまいます。
ではどうしたらよいのか ? 諦めるのか ? vSphere 5.0 では Stun During Page Send (SDPS) という仕組みが入り、このようなメモリの書換が多い仮想マシンを vMotion させる場合、その仮想マシンのスケジューリング回数を減らし仮想マシンの性能を意図的に落とすことで、変更分のメモリ領域が少なくなるようにしています。
…まぁ、そこまで無理して普段は vMotion させなくてもよいんでは？とも思います。SPDS が発動するような仮想マシンは、メモリサイズが大きい、CPU 負荷が非常に高い、となりますので、得てして非常にミッションクリティカルな仮想マシンであることが多いと思います。ですので、こういった仮想マシンは DRS で気軽に動かすことはせず、漬け物石のようにホストに縛り付けるのがよいでしょう。ホストの部品交換やファームウェア/ESXi のアップグレードなどやむを得ない場合は、仮想マシンが落ち着いているときに vMotion させるのが吉です。あえてフルスロットルで稼働しているところで vMotion させることもないでしょう。
サービス プロバイダーは、そうもいかないのですよね…ツラいっすよね、イヤ ホントに。
Storage DRS - 5.0 - 2011
仮想ディスクに対する DRS が実装されました。負荷のメトリックとなるのは、データストアの容量、帯域、レイテンシになり、移動の対象は仮想ディスクでデータストア クラスタ内のデータストアを自動的に Storage vMotion で移動します。
仮想マシン (CPU、メモリ) に対する DRS は文句なく有用でしたが、この Storage DRS に関しては慎重に適用する必要があります。というのも、昨今のストレージは非常に多くのインテリジェンスを持つようになり、SSD キャッシュや重複排除など多様な高機能を持つようになりました。この高機能と Storage DRS を不用意に組み合わせると、ストレージの性能を落としてしまったり、負荷や安定動作にトドメを刺しかねません。
Storage DRS と SSD キャッシュ
仮想ディスクが自動的にデータストアを移動する、つまり、仮想ディスクが自動的に移動してしまうとせっかく暖めた SSD のキャッシュが無駄になってしまいます。大抵のストレージは LUN のブロックに対して SSD キャッシュを行います。つまり、Storage vMotion で仮想ディスクのブロックを LUN 跨ぎで移動してしまうと、移動先はキャッシュされていないブロックとなりますので、ストレージの負荷を下げるつもりで移動させたつもりが性能を下げた挙げ句負荷も上げてしまうことになってしまいます。
Storage DRS と重複排除
ストレージによっては、後処理の重複排除を LUN 単位で行っている場合があります。その場合、Storage vMotion を行うと、重複排除した分を新たな領域にコピーすることになるので、重複排除のメリットを台無しにしてしまいます。最悪ストレージの容量不足になりかねません。では前処理の重複排除ならば大丈夫かというとそうでもなく、前処理の重複排除は性能のために重複排除のテーブルを小さくし、後処理で残りの重複排除を行うストレージがほとんどです。つまり、前処理の重複排除で捌ききれなかった分はストレージの容量を使ってしまうのです。
ダメな子？
では無駄な機能なのかというと、そうでもなくて、上記の注意事項を踏まえていればそう悪くもありません。
- データストアを提供するストレージ筐体が 2 つ以上ある場合
- データストアを構成する物理ディスクが、他のデータストアで使われないシンプルなストレージ
- 重複排除、SSD キャッシュなどがないストレージ
といった場合には、非常に有用になります。
vSphere 6.0 では VASA から重複排除などの情報を取得できるようになり、その場合は Storage vMotion させないなど気が利く機能に進化しています。
