ライブマイグレーション
サーバーは交換が必要になります。ハードウェアの老朽化、プロバイダーの変更、リージョンの移動。rdc repo migrate は実行中のリポジトリを1つのコマンドで別のマシンへ移行します。--checkpoint を使えばプロセスメモリも一緒に運べます。デモアプリの pulse はカウンターをメモリに保持しており、移行後もリセットせずにカウントを続けます。
チュートリアル動画
移行の仕組み
フェーズ1はアプリが動き続ける間にバルクデータをコピーします。フェーズ2は稼働中のプロセスをチェックポイント（rediacc.checkpoint=true ラベルが付いたコンテナは CRIU を使用）し、最終デルタとプロセスの状態を新しいマシンへ転送して、そのまま再開します。ダウンタイムはデータサイズではなく、デルタの転送時間だけです。
ステップ1: 証拠、メモリ上のカウンター
rdc term connect --machine <machine-name> --repository pulse --command 'docker logs heartbeat_app --tail 5'アプリはメモリ内カウンターを保持し、5秒ごとにビートをログに記録します。カウンターはRAMにのみ存在します。プロセスを再起動すると1にリセットされます。
memory counter=6 と表示され、5秒ごとに増えています。カウンターはプロセスメモリにのみ存在します。プロセスが再起動すれば1から始まります。
ステップ2: ライブで移行する
rdc repo migrate --name pulse --from <machine-name> --to <target-machine> --checkpoint --skip-dnsチェックポイントによる移行: フェーズ1でソースをオンラインに保ちながら2GBの大部分を転送し、短いカットオーバーで実行中のプロセスをチェックポイントして最終デルタを転送します。出力には各フェーズと実際のダウンタイムが表示されます。
出力が移行の経過を説明します。フェーズ1はソースをオンラインのまま2GBのバルクを転送し、その後カットオーバーの行が実際の DOWNTIME を表示します。2ギガバイトのリポジトリで数十メガバイト、約20秒です。
ステップ3: 新しいホストを確認する
rdc repo list --machine <target-machine>ターゲットマシンのrepositoryを一覧表示します。pulseはマウント済み、Dockerは稼働中、containerも起動しています。
ターゲット上で pulse がマウントされ、Docker が起動し、コンテナが動いています。
ステップ4: ソースは停止している
rdc repo list --machine <machine-name>ソース上のrepositoryは停止してアンマウントされています。Dockerなし、containerもゼロです。イメージは将来のデルタ転送のベースとして保持されます。
ソースにはリポジトリの記録が残っていますが、実態は：マウントなし、Docker なし、コンテナゼロ。もはや何も動いていません。次のデルタ転送のベースとして意図的にイメージを残しているため、将来の差分プッシュが安くなります。
ステップ5: カウンターはカウントし続けた
rdc term connect --machine <target-machine> --repository pulse --command 'docker logs heartbeat_app --tail 5'新しいマシンのログには、カウンターが1にリセットされることなく、チェックポイントで凍結した場所から継続していることが示されています。プロセスメモリが一緒に移動しました。
memory counter=17、18、19、20…。チェックポイントで止まったところからそのまま再開し、1にリセットされていません。プロセスメモリが旅をしたのです。アプリはマシンが変わったことに気づきませんでした。
--checkpointなしでも、migrate はディスクとコンテナを移動します。その場合、ターゲット上でコンテナは途中から再開せず、新たに起動します。
次: デルタ転送