Awanio CEP sebagai sumber

Panduan ini membahas migrasi guest keluar dari satu site Awanio CEP menuju site Awanio CEP lain — dari cluster yang menjalankan platform Awanio ke cluster lain yang juga menjalankannya. Sisi target pada wizard sama dengan yang dijelaskan di VMware to CEP; semua yang berbeda ada di sisi sumber dan dijelaskan di sini.

Target Vapor dan Cockpit tidak tersedia untuk sumber CEP. Pilih target CEP.

Sebelum mulai

• Sign in to Condensa dari halaman overview.
• Siapkan service account di masing-masing site — satu di sumber, satu di target — beserta access key dan secret-nya.
• Site target harus menjalankan build platform yang menerima migration disk (lihat Apa yang dibutuhkan setiap site). Site sumber tidak memerlukan apa pun yang baru.
• Rencanakan downtime untuk setiap guest yang Anda migrasikan: jalur ini cold saja.

Hanya cold, dan alasannya

Sebuah site menyajikan disk milik guest lewat KubeVirt VirtualMachineExport, dan KubeVirt hanya menerbitkannya selagi guest dalam keadaan mati. Tidak ada changed-block tracking sebagai cadangan, sehingga tidak ada varian warm untuk jalur ini.

Condensa menyampaikannya sebelum Anda memutuskan: langkah 3 pada wizard memuat pemberitahuan tersebut, dan setiap guest menampilkan pill Cold.

Kondisi guest saat migrasi dimulai	Yang terjadi
Mati	Disk-nya di-export dan langsung disalin.
Berjalan	Condensa mematikannya lebih dulu, menunggu sampai benar-benar berhenti, lalu meng-export. Guest dibiarkan tetap mati setelahnya.

Salinan hasil migrasi itulah yang Anda jalankan di target. Guest sumber tetap di tempatnya, dalam keadaan mati — tidak ada yang dihapus, jadi rollback cukup dengan menyalakannya kembali.

Guest yang berjalan dimatikan tanpa konfirmasi kedua

Memilih guest yang sedang berjalan adalah keputusannya. Condensa memberi waktu hingga lima menit untuk berhenti dengan bersih dan melaporkan guest yang tidak mau berhenti; Condensa tidak pernah mematikannya secara paksa. Matikan sendiri apa pun yang punya service yang perlu di-flush, pada waktu yang Anda pilih.

Siapa yang membawa disk

Tidak ada perantara. Site sumber menerbitkan export-nya lewat HTTPS, dan importer milik cluster target sendiri yang mengambilnya langsung. Disk tidak pernah melewati Condensa, yang untuk jalur ini tidak memerlukan alamat publik dan sama sekali tidak berada di jalur data.

Apa harus menjangkau apa	Alasan
Condensa → API site sumber (443)	Inventory, permintaan export, perintah power
Condensa → API site target (443)	Permintaan migration-disk, pembuatan VM
Node cluster target → API site sumber (443)	Transfer disk yang sebenarnya

Baris ketiga inilah yang sering terlupakan. Condensa bisa saja berkomunikasi lancar dengan kedua site sementara node target tidak dapat menjangkau sumber, dan migrasi kemudian gagal saat import, bukan di awal.

Apa yang dibutuhkan setiap site

Inilah sifat yang membuat jalur ini bisa dipakai terhadap site yang tidak Anda kendalikan — sudah terbukti pada platform produksi milik pelanggan, yang sama sekali tidak perlu diubah:

• Sumber — tidak ada yang baru. Endpoint export, power, dan inventory yang sudah dimilikinya sudah cukup. Tanpa agent, tanpa konfigurasi, tanpa restart.
• Target — build platform yang menerima POST /sa/virtualization/migration-disks. Pada build lama, migrasi gagal di disk pertama dengan pesan yang menyebut endpoint tersebut; upgrade sisi target, bukan sisi sumber.

Target harus mempercayai sertifikat milik sumber

Importer di target mengambil export-nya sendiri dan memverifikasi sertifikat TLS sumber dari trust store miliknya — tidak ada setelan provider di sisi Condensa yang melonggarkannya. Condensa memeriksa hal ini sebelum mematikan apa pun, jadi penolakan di titik ini tidak merugikan Anda: guest masih berjalan dan belum ada export yang dibuat.

Bila situs sumber memakai sertifikat privat atau self-signed, serahkan CA-nya ke Condensa satu kali, pada provider CEP sumber (Condensa 1.6.3 ke atas): tekan Periksa sertifikat, pastikan fingerprint-nya milik situs ini, lalu Pakai sertifikat yang disajikan sebagai CA situs ini. Bila situs menyajikan rantai tanpa root-nya, tempel root-nya ke CA Sumber. CA itu kini ikut setiap migrasi dari situs ini, ke target mana pun, dan platform target membuat objek kepercayaannya sendiri — tidak ada yang perlu disiapkan di target.

Ini membutuhkan platform target yang menerima CA inline (awan-api-go dengan endpoint capabilities; rilis platform minimumnya disebut di catatan rilis). Condensa menanyakannya ke target sebelum mematikan guest mana pun, dan mengatakannya bila tidak bisa. Langkah Review di wizard menampilkan hasilnya untuk sumber dan target yang dipilih — termasuk start yang akan ditolak, beserta alasannya — sebelum Anda menekan Start.

Untuk target dengan platform lebih lama, fallback-nya adalah ConfigMap yang Anda buat sekali di cluster target, di namespace organisasi (UUID organisasi), memuat CA dengan kunci ca.pem — satu ConfigMap per target boleh memuat beberapa CA sumber:

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

Lalu buka provider CEP target di Condensa dan isikan nama itu pada ConfigMap CA Sumber Tepercaya. Condensa tidak bisa membaca ConfigMap itu dari tempatnya berjalan, jadi ConfigMap yang hilang atau salah akan menggagalkan transfer, bukan precheck. Sumber dengan sertifikat yang dipercaya publik tidak pernah diarahkan ke mekanisme mana pun.

Yang berbeda bagi guest di target

VM dibuat oleh situs target, jadi tiga hal berikut adalah perbuatan situs, bukan migrasinya:

• Network. Petakan setiap network Multus milik guest sumber ke network target di wizard; Condensa menempelkannya setelah VM dibuat dan situs memberi alamatnya. Interface pod selalu ada. Network sumber yang tidak dipetakan tidak ditempelkan, dan log mengatakannya.
• Alamat MAC. Situs memberi MAC baru — ia belum mengizinkan migrasi mempertahankan MAC sumber. Guest yang konfigurasi jaringannya mencocokkan MAC (bawaan netplan Ubuntu) akan boot tanpa alamat; perbaiki netplan-nya dari konsol VNC situs, atau cocokkan berdasarkan nama interface sebelum migrasi. Log migrasi mengutip MAC sumber karena alasan ini.
• cloud-init. Situs menjalankan cloud-init miliknya sendiri saat boot pertama. Condensa memintanya mempertahankan hostname dan SSH password apa adanya; sampai platform menghormati permintaan itu (sedang dilacak), anggap SSH password nonaktif di guest hasil migrasi dan pakai kunci atau konsol.

Menambahkan provider CEP

Anda memerlukan dua provider, satu untuk tiap site. Klik tab Provider, lalu Add Provider, dan ulangi:

1. Vendor — pilih Awanio CEP.
2. Name — nama tampilan yang menunjukkan site mana (mis. CEP Jakarta dan CEP Surabaya). Label membedakan beberapa provider CEP di dalam wizard, jadi isilah bila Anda punya lebih dari dua.
3. Pada Connection Details:
   • Host — base URL API site tersebut, termasuk segmen versinya: https://api.example.com/v2.
   • Access Key dan Access Secret — kredensial milik service account. Keduanya dienkripsi saat disimpan dengan CONDENSA_ENCRYPTION_KEY.
4. Klik Create Provider, lalu Test Connection pada card yang baru muncul.

Provider yang sama dapat berperan sebagai sumber maupun target; tidak ada yang menandainya sebagai salah satu sampai Anda membuat sebuah migrasi.

Membuat migrasi

Klik tab Migrations, lalu Create Migration.

Langkah 1 — Info dasar dan target

Isi Migration Name, pilih Target Provider (sebuah site CEP), lalu Target Organization dan, opsional, Target Project. Tidak ada storage pool atau target network yang perlu dipilih — target CEP menempatkan disk pada storage milik organization tersebut.

Gunakan Name Prefix bila Anda memigrasikan banyak guest sekaligus dan ingin mudah mengenalinya di target (migrated-). Kosongkan untuk mempertahankan nama persis seperti di sumber, dan ganti nama guest satu per satu di langkah review sebagai gantinya.

Langkah 2 — Provider sumber

Pilih site CEP yang satunya. Tidak ada datacenter yang perlu dipilih — Condensa menampilkan seluruh isi site, satu halaman setiap kali, terbatas pada organization yang dapat dilihat oleh service account.

Langkah 3 — Memilih guest

Pilih satu guest atau lebih. Setiap baris menampilkan power state, pill Cold, OS, alamat, dan total ukuran disk dari seluruh volume — bukan hanya boot disk, sehingga angkanya sesuai dengan yang benar-benar harus dipindahkan.

Langkah 4 — Review

Periksa targetnya dan, pada Per-VM Settings, Target Name yang akan dipakai setiap guest. Lalu klik Create Migration.

Export, dan berapa lama ia bertahan

Saat migrasi dimulai, Condensa meminta site sumber menerbitkan sebuah export dan memberinya masa hidup yang dihitung dari beban kerjanya: total ukuran disk pada asumsi laju minimum 4 MB/s, dikalikan tiga sebagai margin aman, tidak pernah kurang dari satu jam dan tidak pernah lebih dari 72 jam.

Guest yang terlalu besar untuk selesai dalam 72 jam akan ditolak sebelum ada yang dimatikan, disertai ukuran dan laju asumsinya di dalam pesan. Migrasikan disk-nya secara terpisah, atau pindahkan lewat jalur yang lajunya dapat Anda ukur.

Ketika migrasi berakhir — sukses maupun gagal — Condensa menutup export tersebut dan token download-nya dicabut seketika, tidak dibiarkan bertahan sampai TTL habis. Terhadap site lama yang tidak punya endpoint delete, export justru kedaluwarsa dengan sendirinya; log menyebutkan mana dari keduanya yang terjadi.

Tidak ada yang tertinggal di sumber

Setelah migrasi sukses, site sumber tidak menyimpan export, token download, maupun snapshot. Satu-satunya jejak adalah guest itu sendiri, dalam keadaan mati di tempatnya semula.

Menjalankan dan memantau migrasi

1. Buka menu aksi (titik tiga di sebelah kanan baris) lalu pilih Start Migration.
2. Status berubah menjadi Running dan progress bar naik sebagai persentase sungguhan — transfernya melaporkan ukuran total.
3. Setelah selesai, status menjadi Success. Klik nama migrasi untuk melihat detail per disk beserta log-nya.

Migrasi yang gagal dapat dijalankan ulang dari menu aksi yang sama dengan Retry.

Ketika progress bar menyebut "size unknown"

Sebagian site hanya menerbitkan stream disk terkompresi, yang tidak membawa informasi ukuran total. Progress bar lalu bergerak bolak-balik alih-alih menghitung, dan labelnya berbunyi size unknown — transfernya sehat, hanya saja tidak bisa menyatakan sudah sejauh mana. Ia tetap berakhir di 100% seperti transfer lainnya.

Apa yang tiba di target

Sebuah VM baru di organization target, dengan:

• CPU dan memory yang sama seperti guest sumber,
• seluruh disk ter-import dan terpasang dalam urutan aslinya, sehingga guest mem-boot apa yang sebelumnya ia boot,
• OS type sesuai yang dilaporkan sumber — dari OS variant bila site mencatatnya, dan dari entri catalogue bila tidak,
• sebuah catatan bahwa VM ini dimigrasikan oleh Condensa, dan dari jenis sumber apa.

Tidak ada network yang terpasang

VM hasil migrasi tiba tanpa network interface. Pasang satu di site target sebelum Anda menyalakannya, atau ia akan boot tanpa konektivitas. Lagi pula alamat tidak ikut berpindah bersama guest antar-site — alamat milik sumber adalah milik network sumber.

Verifikasi di target

Buka console site target, temukan VM tersebut di organization target, pasang network-nya, lalu nyalakan. Periksa di dalam guest bahwa filesystem-nya sudah ter-mount dan service-nya sudah berjalan sebelum Anda menghapus guest sumber.

Untuk lisensi berbasis kredit dan bagaimana migrasi mengonsumsi kredit, lihat Lisensi.