LXD でのライブマイグレーション

概要

マイグレーションには 2 つの要素があります。1 つは「ソース」、つまり既にインスタンスを保持しているホストです。もう 1 つは「シンク」、インスタンスを受け取るホストです。現在、 pull モードでは、ソースが操作をセットアップし、シンクがソースに接続してインスタンスを pull します。

マイグレーションでは以下の 3 つの websocket (チャンネル) を使用します。

コントロール・ストリーム
criu イメージ・ストリーム
ファイルシステム・ストリーム

マイグレーションが開始されると、インスタンスに関する情報、インスタンスの設定などがコントロール・チャンネル上を流れます (このプロセスの完全な説明は後述します)。 criu イメージとインスタンスのファイルシステムはそれぞれ個別のチャンネルを使って同期され、リストア操作の結果はシンクからソースにコントロール・チャンネル上で送られます。

特に、 criu チャンネルとファイルシステム・チャンネルの上で話されるプロトコルはコントロール・ソケット上で交渉されたものによって異なる場合があります。例えば、ソースとシンクの両方の LXD ディレクトリが btrfs 上にある場合、ファイルシステム・ソケットは btrfs の send/receive を話せます。さらに、現時点では我々は「ストップ・ザ・ワールド」タイプのマイグレーションを実行しますが、 criu の p.haul プロトコルはいつか criu ソケット上で実現されるでしょう。

コントロール・ソケット

2 つのエンドポイント間で 3 つの websocket が全て接続されたら、ソースは MigrationHeader (protobuf の記述が /lxd/migration/migrate.proto にあります) を送ります。このヘッダはインスタンスの設定を含んでおり、それは新しいインスタンスに追加されます。

話す予定のファイルシステムと criu のプロトコルを示す 2 つのフィールドもあります。例えば、サーバが btrfs ファイルシステム上にホストされている場合、単純な rsync の代わりに btrfs send を使いたいと示すことができます (同様に単にイメージを rsync で低速に転送する代わりに p.haul プロトコルを話したいと示すこともできるかもしれません)。

次にシンクはこのメッセージを調べてシンクがサポートするもので応答します。上の例を続けると、シンクが btrfs ファイルシステム上にない場合、最小公倍数 (この場合は rsync) で応答し、ソースはルート・ファイルシステムを rsync で送ることになります。同様に criu コネクションの例でシンクが p.haul プロトコル (や他の何か) をサポートしない場合は、 rsync にフォールバックします。