Internet Infrastructure Review（IIR）Vol.26
2015年2月25日

3.4 UKAIの実装

UKAIの設計を検証するためにプロトタイプ実装を公開しています（※3）。実装は以下の点に配慮してあります。

1. 既存のハイパーバイザーとの親和性
2. 分散システムによる一点障害の排除
3. クラウドコントローラとの連携

仮想マシンに仮想ディスクを提供する方式は2つ考えられます。直接的な方法は、ハイパーバイザー本体に新しい仮想ディスク形式を拡張実装することです。直接組み込むことによる性能向上が見込めますが、ハイパーバイザーごとに個別対応する必要があります。もう1つの方法は、仮想ディスクのイメージをファイルとして提供することです。多くのハイパーバイザーは最もシンプルな方式として、1つのファイルを1つの仮想ディスクイメージとみなして仮想マシンに提供する仕組みを持っています。UKAIでは後者の方式を採用し、ハイパーバイザーと独立した仕組みで仮想ディスクストレージを構築します。

分散システムを設計する場合に最も気になるのは、障害発生時の冗長性をどこまで持たせるかです。前節で述べたとおり、UKAIはストレージノードを複数運用することができるため、ストレージノードの障害にはある程度対応可能です。もう1つの問題は仮想ディスクを構成する情報（仮想ディスクのメタデータ）をどのように分散システムとして保存するかということになります。プロトタイプ実装では分散協調支援システムであるApache ZooKeeperを利用しています。

拡大する

図-2 UKAIプロトタイプシステムのモジュール構成

図-2にプロトタイプシステムのモジュール構成図を示します。ハイパーバイザーはローカルシステムにマウントされたファイルシステム上に作られたファイルを仮想ディスクとして利用します。ハイパーバイザーから見ると、仮想ディスクイメージは単なるファイルに見えるため、ローカルファイルを仮想ディスクとして利用する場合と同様に運用できます。実際には、マウントポイントの先にはUKAIが存在しており、ファイル入出力はすべてUKAIのサブシステムを経由する形になります。プロトタイプでは、UKAIサブシステムの実装のためにFUSE（※4）とそのPythonバインディングの一種であるfusepy（※5）を使っています。UKAI自体もPythonで実装されています。

仮想ディスクはその名のとおり実態を持たず、実データへのポインターの集合になります。図-3に仮想ディスクと実データ及びストレージノードの関係を示します。図に示したとおり、仮想ディスクは複数のデータブロックに分割され、それぞれのデータブロックが実データへのポインターを持ちます。1つのデータブロックは複数の実データポインターを持つことができ、ストレージノードの障害に対応します。

仮想ディスクの再配置は図-4に示したように実行されます。仮想マシンが異なるハイパーバイザーへマイグレート、もしくは異なるハイパーバイザーで再起動する場合に、実データを格納していたストレージノードとの間に大きな通信遅延が予測されたとします。この場合、まず移動先のハイパーバイザーに近いストレージノードに実データのコピーを作成し、仮想マシンを移動した後、遅延の大きいストレージノードの実データを削除します。仮想ディスクは単なるポインターの集合なので、稼働中の仮想マシンは実データのコピーが作成されたことや、遠方の実データが削除されたことを意識する必要はありません。再配置が完了するまでの間はディスクアクセス性能が劣化しますが、仮想マシンを停止することなく仮想ディスクの実データの位置を最適化できます。

拡大する

図-3 UKAI仮想ディスクと実データ格納の概念図

拡大する

図-4 仮想ディスクの再配置

1. （※3）UKAI：A Location-Aware Distributed Storage Software for Virtual Machine Disk Images（https://github.com/keiichishima/ukai）。
2. （※4）FUSE（http://fuse.sourceforge.net）。
3. （※5）fusepy（https://github.com/terencehonles/fusepy/）。

3.ストレージテクノロジー

• 3.1 仮想化前提基盤
• 3.2 仮想マシン用ディスクストレージの必要性
• 3.3 位置配慮型仮想ディスクストレージUKAI
• 3.4 UKAIの実装
• 3.5 まとめ