The Design and Implementation of Zap: A System for Migrating Computing Environments(2)

昨日の続き。
昨日のエントリの最後で挙げたような点を解決したプロセスマイグレーションのシステムをこの論文では提案している。
そういったプロセスマイグレーションのシステムを作る上で、以下のようなことを考えないといけない。

  • プロセス情報の一貫性
    • プロセス情報とは、PID、ソケット番号など
    • 一度割り当てられたら、変更してはいけない
  • リソースの衝突の回避
    • ホスト内ではプロセスはユニーク(PIDがかぶってはいけない)
  • プロセスの独立性

三つ目の独立性について、もうちょっと説明する。例えば、あるプロセスを移行しようとしていたときに、そのプロセスが移行前のホストで他のプロセスとメモリを共有していたとする。そういったときに、何も考えずにプロセスを移行してしまうと、共有していたメモリの一貫性が失われてしまうため、どうにかしないといけない。例えばそのときに、移行前のホストにプロキシのようなプロセスを立ち上げて、移行後はそのプロキシを介して共有していたメモリを操作する、という解決策が考えられる。しかし、こういった解決策を取ると、移行前のホストがダウンしただけでそのプロセスは処理を続けることが出来なくなってしまう。こういった状況をホスト間の依存関係と読んでいるわけで、この依存関係が生じないように、システムを設計しないとまずいよね、というお話でした。
そこで、上で挙げたような用件を満たすプロセスマイグレーションシステムを本論文では、提案しているわけだが、これはプロセスを仮想化して実現している。
このシステムでは一つのホスト内は、以下のような構成になっている。(これは、私が勝手に書いた図)

この図の中で、podというのがキモで、いくつかのプロセスをグループにまとめて管理・仮想化するレイヤーである。このpodの基本的なアイデアは、依存関係のある(例えばメモリを共有しているとか)プロセスはまとめてしまい、外のリソースとのやり取りを管理しましょう、というもの。そして、マイグレーションは、このpod単位で行うことで、移行先の環境で名前空間が衝突したり、移行前の環境に依存することがなくなる。
それでは、podを使ってどういった仮想化を行っているかを説明しよう。
podでは、以下の四つを仮想化している。

これらについてここから一つずつ説明していく。

プロセスの状態

このpodは、プライベートな仮想名前空間を持っている。そうすることで

  • pod内では、プロセスの情報(PIDなど)がユニーク
  • podの外部のリソースを隠す

といったことが可能になる。
つまり、ホストとは独立なPIDをpod内で割り当ててあげて、podのレイヤーで実際のホストから割り当てられたPIDとの対応表を覚えておくのである。すると、マイグレーションをしたときに、その対応表を書き換えてあげるだけで、プロセスとしては常に一貫したPIDを使うことが可能となる。
そして、マイグレーションを行う際には、

  • プロセスとグループのID
  • CPUレジスタの内容
  • シグナルハンドラ
  • IPC(プロセス間通信)用のキーと状態
  • パイプ

を、保存する。

メモリ

メモリの仮想化は、OSの仮想メモリで実現されているので、それをそのまま利用するだけ。
そして、マイグレーション時には、

を保存する。

ファイルシステム

ファイルシステムは、/tmpや/localといったホストによって異なるディレクトリは、各pod用に個別のファイルシステムを用意するという方法で対処している。
より具体的には、どこかにストレージサーバを立てて、NFSで各pod用のファイルシステムをそのサーバに用意する。そうすることで、プロセスが移行してもそのサーバを見ればいいだけなので、解決される。

バイス

/devもファイルシステムと同様にpodごとにマウント。
(ここよく読んでない。。)

ネットワーク

以下の三つの機能を提供している。

  • pod内のプロセスにリモートから通信可能
  • マイグレーションしても、アプリケーション層のインターフェースは変わらない
  • マイグレーションしても、オープンコネクションを保存できる

[ここは後で書く]

以下、所感。
全体的にうまくやっていると思った。ただ、いくつか気に入らないところもあった。
まず、一つ目として、ファイルシステムの仮想化、というかネットワーク越しに管理しているだけ、はどうかと思う。この論文の初めの方に、ホスト間の依存関係は良くない、とか言ってるけど、ファイルシステムの所ではストレージサーバに物凄く依存しているわけで。まあだからといって、他のいいアイデアが私にあるわけでもないのですが。。。
もう一つは、ネットワークの扱いのところ。最初、論文の概要を読んでいたときに、コネクション保持したままマイグレーションできるとか書いてあるから、すげーーと思ったけど、クライアント側でもアドレスを仮想化しないといけないのね。。
気になるのは、この二つかなぁ。
あと、どうでもいいけど、この論文すごく読みやすかった。まとめ方と例の使い方がうまい。いい。

追記
こちらのサイトに同じ論文のまとめがあった。元の論文に忠実な感じでいいです。