vMotion時にキャッシュはどのように移行されるのか？
Datrium DVXという製品はホスト（サーバー）内にすべてのデータをフラッシュにキャッシュするというアーキテクチャーを持っています。CPUに近い場所でデータの処理するのが最も高速になるという発想です。
ただ、企業のITシステムですべてのデータをキャッシュするとなると、相当な容量のフラッシュが必要になってしまい、コストが現実的ではないため、これまで実現できなかったということも事実です。
そこでDatrium DVXはデータをフラッシュに保存する前に圧縮と重複排除を行って、データの容量を1/2から最大1/6に縮小するという解決策を取りました。これで、すべてのデータをフラッシュにキャッシュしてもコストはあまり掛かりませんね。現在サポートされているフラッシュのサイズは１ノードあたり最大で16TBですので、論理的には最大で100TBくらいのキャッシュを持つことができます。もし使っているうちに容量が足りなくなったら、民生のSATA SSDでも十分に速度が出ますので、簡単に拡張することができます。
そして、ホストのメンテナンスやアップデートのために、一時的に仮想マシンを他のノードにvMotionする場面があると思います。またvSphere DRS（Distributed Resource Scheduler）によってトリガーされる設定もあるかと思います。そのようなときにDatrium DVXはどのようにキャッシュを別のノードに移行するのでしょうか？
ここではvMotionの宛先ホストキャッシュウォームアップのDVX最適化について説明します。
- デスティネーションホストのデータ共通性 キャッシュはインラインで重複排除されるため、デスティネーションホストで似た仮想マシンがすでに使用しているデータはコピーしません。Datirum DVXではサーバー間でメタデータを共有して、すべてのノードを跨いて重複排除するような設計にしているからです。なので、ホスト数が増えても重複排除率が下がることがありませんね。
- ソースホストからのキャッシュ読み取り これは、ホストのデータローカリティのポリシーに対する一時的な例外になります。vMotionで移行したデスティネーションホストにまだないデータは、すべてのキャッシュがウォームアップされるまでの間、一時的にソースホストに存在するキャッシュから読み取りをおこないます。
そして、キャッシュデータはすべて予め圧縮と重複排除で縮小していますので、このような状況が発生しても、ネットワークに転送されるデータ量は一般的なHCIや３層構造インフラと比較して1/2-1/6になっています。ネットワークのボトルネックが発生しにくい設計と言えるわけですね。
Datrium DVXを使用することで、ストレージアレイ上にキャッシュ容量を確保したり、高価なキャッシュ/ストレージコントローラのアップグレードをしなくても、仮想環境のパフォーマンスを簡単かつ低コストで拡張できますね。