ソースとしての Awanio CEP

本ガイドでは、ある Awanio CEP サイトから別の Awanio CEP サイトへゲストを移行する方法を説明します — Awanio プラットフォームを実行しているクラスターから、同じく Awanio プラットフォームを実行している別のクラスターへの移行です。ウィザードのターゲット側は VMware to CEP で説明されているものと同じです。異なるのはソース側のみで、本ページではその点を説明します。

Vapor および Cockpit のターゲットは、CEP ソースでは利用できません。CEP ターゲットを選択してください。

開始する前に

• 概要ページから Condensa にサインインします。
• 各サイトにサービスアカウント（ソース側に 1 つ、ターゲット側に 1 つ）と、そのアクセスキーおよびシークレットを用意します。
• ターゲットサイトは、移行ディスクを受け入れるプラットフォームビルドで動作している必要があります（サイトごとに必要なものを参照）。ソースサイトに新たに必要なものはありません。
• 移行するすべてのゲストでダウンタイムを見込んでください。この経路はコールドのみです。

コールドのみである理由

サイトはゲストのディスクを KubeVirt の VirtualMachineExport を通じて提供しますが、KubeVirt がこれを公開するのはゲストが停止している間だけです。代替手段となる changed block tracking も存在しないため、この経路にウォーム版はありません。

Condensa は実行を確定する前にその旨を提示します。ウィザードのステップ 3 に注意書きが表示され、すべてのゲストに Cold のピルが表示されます。

移行開始時のゲストの状態	動作
停止中	ディスクがただちにエクスポートされ、コピーされます。
実行中	Condensa がまずシャットダウンし、停止を待ってからエクスポートします。その後もシャットダウンされたままになります。

ターゲットで起動するのは移行されたコピーです。ソースのゲストは停止した状態でそのまま残ります — 何も削除されないため、ロールバックは元のゲストを再度起動するだけです。

実行中のゲストは再確認なしにシャットダウンされます

実行中のゲストを選択した時点が意思決定です。Condensa は正常に停止するまで最大 5 分間待ち、停止しないゲストは報告します。強制終了は決して行いません。フラッシュが必要なサービスを持つものは、任意のタイミングでご自身でシャットダウンしてください。

ディスクを運ぶのは誰か

中間に立つものはありません。ソースサイトが HTTPS でエクスポートを公開し、ターゲットクラスター自身のインポーターがそれを直接取得します。ディスクが Condensa を経由することはありません。この経路で Condensa に公開アドレスは不要であり、そもそもデータパス上に存在しません。

到達が必要な経路	理由
Condensa → ソースサイト API (443)	インベントリ、エクスポート要求、電源操作
Condensa → ターゲットサイト API (443)	移行ディスクの要求、VM の作成
ターゲットクラスターのノード → ソースサイト API (443)	実際のディスク転送

見落とされやすいのは 3 行目です。Condensa から両サイトへ問題なく通信できていても、ターゲットのノードからソースへ到達できないことがあり、その場合は移行の開始時ではなくインポート中に失敗します。

サイトごとに必要なもの

これは、自分が管理していないサイトに対してもこの経路を利用できるようにする特性です。実際に、顧客の本番プラットフォームに対して一切の変更なしで実証されています。

• ソース — 新たに必要なものはありません。既存のエクスポート、電源、インベントリの各エンドポイントだけで十分です。エージェントも設定も再起動も不要です。
• ターゲット — POST /sa/virtualization/migration-disks を受け付けるプラットフォームビルドが必要です。古いビルドでは、最初のディスクでエンドポイント名を含むメッセージとともに移行が失敗します。ソースではなくターゲットをアップグレードしてください。

ターゲットはソースの証明書を信頼している必要があります

ターゲットのインポーターはエクスポートを自ら取得し、ソースの TLS 証明書を自身のトラストストアで検証します。Condensa 側のプロバイダー設定でこれを緩和することはできません。Condensa は何かを停止する前にこれを確認するため、ここで拒否されても損失はありません。ゲストは実行中のままで、エクスポートも作成されていません。

ソースサイトがプライベート証明書または自己署名証明書を使用している場合は、ソース側の CEP プロバイダーで CA を一度だけ Condensa に渡します（Condensa 1.6.3 以降）。証明書を確認を押し、フィンガープリントがこのサイトのものであることを確かめ、配信された証明書をこのサイトの CA として使用を押します。サイトがルートを含まないチェーンを配信する場合は、代わりにルートを Source CA に貼り付けます。その CA はこのサイトからのすべての移行に、どのターゲットへも同行し、ターゲットのプラットフォームが信頼用オブジェクトを自ら作成します。ターゲット側での準備は不要です。

これには、ターゲットのプラットフォームがインライン CA を受け付けること（capabilities エンドポイントを持つ awan-api-go。最小プラットフォームリリースはリリースノートに記載）が必要です。Condensa はゲストを停止する前にターゲットへ問い合わせ、できない場合はその旨を伝えます。ウィザードの Review ステップは、選択したソースとターゲットに対する結果 — 拒否される開始とその理由を含む — を、Start を押す前に表示します。

古いプラットフォームのターゲットでは、代替としてターゲットクラスターの組織ネームスペース（組織 UUID）に、キー ca.pem で CA を保持する ConfigMap を一度作成します。ターゲットごとに 1 つの ConfigMap で複数のソース CA を保持できます:

kubectl -n <organization-uuid> create configmap trusted-source-ca --from-file=ca.pem=source-ca.crt

次に Condensa でターゲット側の CEP プロバイダーを開き、Trusted source CA ConfigMap にその名前を入力します。Condensa は自身の実行場所から ConfigMap を読めないため、存在しない、または内容が誤っている場合は、事前チェックではなく転送が失敗します。公的に信頼された証明書を持つソースは、どちらの仕組みにも向けられません。

ターゲットでゲストが出会う違い

VM を作成するのはターゲットサイトなので、次の 3 点は移行ではなくサイトの挙動です:

• ネットワーク。 ソースゲストの各 Multus ネットワークを、ウィザードでターゲットのネットワークに対応付けてください。Condensa は VM 作成後にそれらを接続し、サイトがアドレスを割り当てます。pod インターフェースは常に存在します。対応付けのないソースネットワークは接続されず、ログにその旨が記録されます。
• MAC アドレス。 サイトは新しい MAC を割り当てます。移行でソースの MAC を保持することはまだできません。ネットワーク設定を MAC で照合するゲスト（Ubuntu の netplan は既定でそうします）はアドレスなしで起動します。サイトの VNC コンソールから netplan を修正するか、移行前にインターフェース名で照合するよう変更してください。このためにログはソースの MAC を記載します。
• cloud-init。 サイトは初回起動時に自身の cloud-init を実行します。Condensa はホスト名とパスワード SSH をそのまま保つよう要求しますが、プラットフォームがこれを尊重するまで（対応中）、移行後のゲストではパスワード SSH が無効になっていると考え、鍵またはコンソールを使用してください。

CEP プロバイダーの追加

サイトごとに 1 つ、計 2 つのプロバイダーが必要です。Provider タブをクリックし、Add Provider をクリックして、次の手順を繰り返します。

1. Vendor — Awanio CEP を選択します。
2. Name — どのサイトかがわかる表示名（例: CEP Jakarta、CEP Surabaya）。Label はウィザード上で複数の CEP プロバイダーを区別するためのものなので、3 つ以上ある場合は入力してください。
3. Connection Details の下:
   • Host — サイトの API ベース URL。バージョンのセグメントを含めます: https://api.example.com/v2。
   • Access Key と Access Secret — サービスアカウントの認証情報。CONDENSA_ENCRYPTION_KEY で暗号化して保存されます。
4. Create Provider をクリックし、新しく作成されたカードで Test Connection をクリックします。

同じプロバイダーをソースにもターゲットにも使用できます。移行を作成するまで、どちらであるかを示すものはありません。

移行の作成

Migrations タブをクリックし、Create Migration をクリックします。

ステップ 1 — 基本情報とターゲット

Migration Name を入力し、Target Provider（CEP サイト）を選択して、その Target Organization と、必要に応じて Target Project を指定します。ストレージプールやターゲットネットワークの選択はありません。CEP ターゲットでは、組織のストレージにディスクが配置されます。

まとめて移行し、ターゲット上で識別できるようにしたい場合は Name Prefix を使用します (migrated-)。空欄のままにするとソースとまったく同じ名前が維持され、個々のゲストの名前はレビューステップで変更できます。

ステップ 2 — ソースプロバイダー

もう一方の CEP サイトを選択します。データセンターの選択はありません。Condensa はサイト全体を、サービスアカウントが参照できる組織に絞り込んで、1 ページずつ一覧表示します。

ステップ 3 — ゲストの選択

1 台以上のゲストを選択します。各行には電源状態、Cold のピル、OS、アドレス、そしてすべてのボリュームを合計したディスクサイズが表示されます。ブートディスクだけではないため、実際に転送が必要な量と一致します。

ステップ 4 — レビュー

ターゲットと、Per-VM Settings の下にある各ゲストの Target Name を確認します。その後、Create Migration をクリックします。

エクスポートとその有効期間

移行が開始されると、Condensa はソースサイトにエクスポートの公開を要求し、作業量に応じた有効期間を設定します。総ディスクサイズを 4 MB/s という想定下限で見積もり、安全のために 3 倍した値で、最短 1 時間、最長 72 時間です。

72 時間以内に完了できないほど大きなゲストは、何も停止される前に拒否され、メッセージにサイズと想定転送レートが示されます。ディスクを分けて移行するか、実測できる回線で移動してください。

移行が終了すると — 成功・失敗を問わず — Condensa はエクスポートを閉じ、そのダウンロードトークンは TTL まで残らずただちに失効します。削除エンドポイントを持たない古いサイトに対しては、代わりにエクスポートが自然に期限切れになります。どちらが起きたかはログに記録されます。

ソースには何も残りません

移行が成功した後、ソースサイトにはエクスポートもダウンロードトークンもスナップショットも残りません。残るのはゲスト自体だけで、元の場所に停止した状態で残ります。

移行の開始と監視

1. アクションメニュー（行の右側にある3つのドット）を開き、Start Migration を選択します。
2. ステータスが Running に変わり、進行状況バーが実際の割合として増加します。転送が総サイズを報告するためです。
3. 完了するとステータスが Success に変わります。移行名をクリックすると、ディスクごとの詳細とログを確認できます。

失敗した移行は、同じアクションメニューの Retry から再実行できます。

バーに "size unknown" と表示される場合

一部のサイトは圧縮されたディスクストリームのみを公開しており、これには総サイズの情報が含まれません。その場合、バーはカウントせずに往復表示となり、ラベルには size unknown と表示されます。転送は正常で、進捗を示せないだけです。他と同様に 100% で終了します。

ターゲットに作成されるもの

ターゲット組織に新しい VM が作成されます。内容は次のとおりです。

• ソースのゲストと同じ CPU とメモリー
• すべてのディスクが元の順序でインポートされ、接続されます。これによりゲストは以前と同じディスクから起動します
• ソースが報告した OS タイプ。サイトが OS バリアントを記録している場合はそこから、記録していない場合はカタログのエントリーから取得します
• Condensa が移行したこと、およびどの種類のソースからの移行かを記録したメモ

ネットワークは接続されません

移行された VM にはネットワークインターフェースがありません。起動する前にターゲットサイトでネットワークを接続してください。接続しないまま起動すると、ネットワークに接続できない状態で起動します。いずれにせよ、アドレスはサイトをまたいでゲストに追従しません。ソースのアドレスはソース側のネットワークに属するものです。

ターゲットでの確認

ターゲットサイトのコンソールを開き、ターゲット組織で VM を見つけ、ネットワークを接続して起動します。ソースのゲストを削除する前に、ゲスト内でファイルシステムがマウントされ、サービスが起動していることを確認してください。

クレジット方式のライセンスと、移行によるクレジットの消費については ライセンス を参照してください。