Arsitektur migrasi tanpa agen

Artikel ini menjelaskan konsep replikasi saat memigrasikan VMware VM menggunakan metode migrasi tanpa agen alat migrasi dan modernisasi.

Proses replikasi

Opsi replikasi tanpa agen bekerja dengan menggunakan rekam jepret VMware dan teknologi VMware changed block tracking (CBT) untuk mereplikasi data dari disk komputer virtual. Diagram blok berikut menunjukkan berbagai langkah yang terlibat saat Anda memigrasikan komputer virtual menggunakan alat Migrasi dan modernisasi.

Saat replikasi dikonfigurasi untuk komputer virtual, replikasi tersebut terlebih dahulu melalui fase replikasi awal. Selama replikasi awal, rekam jepret VM diambil, dan salinan data lengkap dari disk rekam jepret direplikasi ke disk terkelola di langganan target Anda.

Setelah replikasi awal untuk VM selesai, proses replikasi beralih ke fase replikasi bertahap (replikasi delta). Dalam fase replikasi bertahap, perubahan data yang terjadi sejak siklus replikasi yang terakhir selesai direplikasi dan ditulis pada disk yang dikelola replika, sehingga menjaga replikasi tetap sinkron dengan perubahan yang terjadi pada VM.

Teknologi VMware changed block tracking (CBT) digunakan untuk melacak perubahan antara siklus replikasi. Di awal siklus replikasi, rekam jepret VM dan pelacakan blok yang diubah digunakan untuk mendapatkan perubahan antara rekam jepret saat ini dan rekam jepret terakhir yang berhasil direplikasi. Hanya data yang telah berubah sejak siklus replikasi sebelumnya yang selesai direplikasi untuk menjaga replikasi agar VM tetap sinkron. Pada akhir setiap siklus replikasi, rekam jepret dirilis, dan konsolidasi rekam jepret dilakukan untuk komputer virtual.

Ketika Anda melakukan operasi migrasi pada mesin virtual replikasi, ada siklus replikasi delta sesuai permintaan yang mereplikasi perubahan yang tersisa sejak siklus replikasi terakhir. Setelah siklus sesuai permintaan selesai, disk yang dikelola replikasi yang sesuai dengan komputer virtual digunakan untuk membuat komputer virtual di Azure. Tepat sebelum memicu migrasi/failover, Anda harus mematikan komputer virtual lokal. Mematikan komputer virtual memastikan tidak ada data yang hilang selama migrasi.

Setelah migrasi berhasil dan VM di-boot di Azure, pastikan Anda menghentikan replikasi VM. Menghentikan replikasi akan menghapus disk perantara (disk nilai awal) yang dibuat selama replikasi data, dan Anda juga akan menghindari timbulnya biaya tambahan yang terkait dengan transaksi penyimpanan pada disk ini.

Siklus replikasi

Catatan

Pastikan Anda memeriksa rekam jepret yang ada dari upaya replikasi sebelumnya atau dari aplikasi pihak ketiga lainnya. Pelacakan perubahan tidak dapat diaktifkan pada VM jika rekam jepret sudah ada untuk VM. Hapus rekam jepret yang ada atau aktifkan pelacakan blok perubahan pada VM.

Siklus replikasi mengacu pada proses mentransfer data secara berkala dari lingkungan lokal ke disk yang dikelola Azure. Siklus replikasi penuh terdiri dari langkah-langkah berikut:

1. Membuat rekam jepret VMware untuk setiap disk yang terkait dengan VM
2. Mengunggah data ke akun penyimpanan log di Azure
3. Merilis rekam jepret
4. Mengonsolidasikan disk VMware

Siklus dikatakan selesai setelah disk dikonsolidasikan.

Komponen yang terlibat dalam replikasi

Komponen lokal: appliance Azure Migrate memiliki komponen berikut yang bertanggung jawab untuk replikasi

• Agen DRA
• Agen gateway

Komponen Azure: Tabel berikut ini merangkum berbagai Artefak Azure yang dibuat saat menggunakan metode migrasi VMware VM tanpa agen.

Komponen	Wilayah	Langganan	Deskripsi
Vault layanan pemulihan	Wilayah proyek Azure Migrate	Langganan proyek Azure Migrate	Digunakan untuk mengatur replikasi data
Bus Layanan	Wilayah target	Langganan proyek Azure Migrate	Digunakan untuk komunikasi antara layanan cloud dan appliance Azure Migrate
Akun Penyimpanan Log	Wilayah target	Langganan proyek Azure Migrate	Digunakan untuk menyimpan data replikasi, yang dibaca oleh layanan dan diterapkan pada disk yang dikelola pelanggan
Akun penyimpanan gateway	Wilayah target	Langganan proyek Azure Migrate	Digunakan untuk menyimpan keadaan mesin selama replikasi
Brankas kunci	Wilayah target	Langganan proyek Azure Migrate	Mengelola string koneksi untuk bus layanan dan kunci akses untuk akun penyimpanan log
Azure Virtual Machine	Wilayah target	Target langganan	VM dibuat di Azure saat Anda melakukan migrasi
Disk Terkelola Azure	Wilayah target	Target langganan	Disk terkelola yang dilampirkan ke Azure VM
Kartu antarmuka jaringan	Wilayah target	Target langganan	NIC yang melekat pada VM yang dibuat di Azure

Izin yang diperlukan

Ketika Anda memulai replikasi untuk pertama kalinya, pengguna yang masuk harus diberi peran berikut:

• Pemilik atau Kontributor dan Administrator Akses Pengguna di Grup Sumber Daya proyek Azure Migrate dan Grup Sumber Daya target

Untuk replikasi berikutnya, pengguna yang masuk harus diberi peran berikut:

• Pemilik atau Kontributor di Grup Sumber Daya proyek Azure Migrate dan Grup Sumber Daya target

Selain peran yang dijelaskan di atas, pengguna yang masuk akan memerlukan izin berikut pada tingkat langganan - Microsoft.Resources/subscriptions/resourceGroups/read

Integritas data

Ada dua tahap dalam setiap siklus replikasi yang memastikan integritas data antara disk lokal (disk sumber) dan disk replika di Azure (disk target).

1. Pertama, kami memvalidasi apakah setiap sektor yang telah berubah di disk sumber direplikasi ke disk target. Validasi dilakukan menggunakan bitmap. Disk sumber dibagi menjadi sektor 512 byte. Setiap sektor di disk sumber dipetakan ke bit dalam bitmap. Ketika replikasi data dimulai, bitmap dibuat untuk semua blok yang diubah (dalam siklus delta) di disk sumber yang perlu direplikasi. Demikian pula, ketika data ditransfer ke disk Azure target, bitmap dibuat. Setelah transfer data berhasil diselesaikan, layanan cloud membandingkan dua bitmap untuk memastikan tidak ada blok yang berubah yang terlewatkan. Jika ada ketidakcocokan antara bitmap, siklus dianggap gagal. Karena setiap siklus adalah resinkronisasi, ketidakcocokan akan diperbaiki pada siklus berikutnya.

2. Selanjutnya kami memastikan bahwa data yang ditransfer ke disk Azure sama dengan data yang direplikasi dari disk sumber. Setiap blok yang diubah yang diunggah dikompresi dan dienkripsi sebelum ditulis sebagai blob di akun penyimpanan log. Kami menghitung checksum blok ini sebelum kompresi. Checksum ini disimpan sebagai metadata bersama dengan data terkompresi. Setelah dekompresi, checksum untuk data dihitung dan dibandingkan dengan checksum yang dihitung di lingkungan sumber. Jika ada ketidakcocokan, data tidak ditulis ke disk Azure, dan siklus dianggap gagal. Karena setiap siklus adalah resinkronisasi, ketidakcocokan akan diperbaiki pada siklus berikutnya.

Keamanan

Appliance Azure Migrate mengompresi data dan mengenkripsi sebelum mengunggah. Data dikirimkan melalui saluran komunikasi aman melalui https dan menggunakan TLS 1.2 atau yang lebih baru. Selain itu, Azure Storage secara otomatis mengenkripsi data Anda saat data disimpan ke cloud (enkripsi tidak aktif).

Status replikasi

Ketika VM menjalani replikasi (salinan data), ada beberapa kemungkinan status:

• Replikasi awal diantrekan: VM diantrekan untuk replikasi (atau migrasi) karena mungkin ada VM lain yang menggunakan sumber daya lokal (selama replikasi atau migrasi). Setelah sumber daya kosong, VM ini akan diproses.
• Replikasi awal sedang berlangsung: VM sedang dijadwalkan untuk replikasi awal.
• Replikasi awal: VM sedang menjalani replikasi awal. Saat VM menjalani replikasi awal, Anda tidak dapat melanjutkan migrasi dan migrasi pengujian. Anda hanya dapat menghentikan replikasi pada tahap ini.
• Replikasi awal (x%): Replikasi awal aktif dan telah berkembang oleh x%.
• Sinkronisasi delta: VM mungkin mengalami siklus replikasi delta yang mereplikasi churn data yang tersisa sejak siklus replikasi terakhir.
• Jeda sedang berlangsung: VM sedang menjalani siklus replikasi delta aktif dan akan dijeda dalam beberapa waktu.
• Dijeda: Siklus replikasi telah dijeda. Siklus replikasi dapat dilanjutkan dengan melakukan operasi replikasi resume.
• Lanjutkan antrean: VM diantrekan untuk melanjutkan replikasi karena ada VM lain yang saat ini menggunakan sumber daya lokal.
• Lanjutkan sedang berlangsung (x%): Siklus replikasi sedang dilanjutkan untuk VM dan telah berkembang oleh x%.
• Hentikan replikasi yang sedang berlangsung: Pembersihan replikasi sedang berlangsung. Ketika Anda menghentikan replikasi, disk perantara yang dikelola (disk nilai awal) yang dibuat selama replikasi akan dihapus. Pelajari selengkapnya.
• Menyelesaikan migrasi yang sedang berlangsung: Pembersihan migrasi sedang berlangsung. Ketika Anda menyelesaikan migrasi, disk terkelola menengah (disk benih) yang dibuat selama replikasi akan dihapus. Pelajari selengkapnya.
• – : Ketika VM telah berhasil dimigrasikan dan/atau ketika Anda telah menghentikan replikasi, status berubah menjadi "-". Setelah Anda menghentikan replikasi / menyelesaikan migrasi dan operasi berhasil diselesaikan, VM akan dihapus dari daftar mesin replikasi. Anda dapat menemukan VM di tab komputer virtual di wizard replikasi.

Status lain

• Replikasi awal gagal: Data awal tidak dapat disalin untuk VM. Ikuti panduan remediasi untuk mengatasinya.
• Perbaikan tertunda: Ada masalah dalam siklus replikasi. Anda dapat memilih tautan untuk memahami kemungkinan penyebab dan tindakan untuk memulihkan (sebagaimana berlaku). Jika Anda memilih Replikasi perbaikan otomatis dengan memilih Ya saat Anda memicu replikasi VM, alat ini akan mencoba memperbaikinya untuk Anda. Jika tidak, pilih VM, dan pilih Perbaiki Replikasi. Jika Anda tidak memilih Replikasi perbaikan otomatis atau jika langkah di atas tidak berfungsi untuk Anda, hentikan replikasi untuk komputer virtual, atur ulang pelacakan blok yang diubah pada komputer virtual, lalu konfigurasi ulang replikasi.
• Replikasi perbaikan diantrekan: VM diantrekan untuk perbaikan replikasi karena ada VM lain yang menggunakan sumber daya lokal. Setelah sumber daya gratis, VM akan diproses untuk replikasi perbaikan.
• Sinkronisasi ulang (x%): VM sedang mengalami sinkronisasi ulang data. Ini dapat terjadi jika ada beberapa masalah / ketidakcocokan selama replikasi data.
• Menghentikan replikasi/migrasi lengkap gagal: Pilih tautan untuk memahami kemungkinan penyebab kegagalan dan tindakan untuk memulihkan (sebagaimana berlaku).

Catatan

Beberapa VM dimasukkan ke dalam keadaan antri untuk memastikan dampak minimal pada lingkungan sumber karena konsumsi IOPS penyimpanan. VM ini diproses berdasarkan logika penjadwalan seperti yang dijelaskan di bagian berikutnya.

Status migrasi/pengujian migrasi

• Migrasi pengujian tertunda: VM berada dalam fase replikasi delta, dan Anda sekarang dapat melakukan migrasi pengujian (atau migrasi).
• Pembersihan migrasi pengujian tertunda: Setelah migrasi pengujian selesai, lakukan pembersihan migrasi pengujian untuk menghindari biaya di Azure.
• Siap untuk bermigrasi: VM siap untuk dimigrasikan ke Azure.
• Migrasi sedang dalam antrean: VM diantrekan untuk migrasi karena ada VM lain yang menggunakan sumber daya lokal selama replikasi (atau migrasi). Setelah sumber daya gratis, VM akan diproses.
• Uji migrasi/Migrasi sedang berlangsung: VM sedang menjalani migrasi/migrasi pengujian. Anda dapat memilih tautan untuk memeriksa pekerjaan migrasi yang sedang berlangsung.
• Tanggal, tanda waktu: Tanggal migrasi/pengujian tanggal dan tanda waktu migrasi.
• –: Replikasi awal sedang berlangsung. Anda dapat melakukan migrasi atau menguji migrasi setelah proses replikasi beralih ke fase sinkronisasi delta (replikasi inkremental).

Status lain

• Selesai dengan info: Pekerjaan migrasi/pengujian migrasi diselesaikan dengan informasi. Anda dapat memilih tautan untuk memeriksa pekerjaan migrasi terakhir untuk kemungkinan penyebab dan tindakan untuk memulihkan (sebagaimana berlaku).
• Gagal: Pekerjaan migrasi/pengujian migrasi gagal. Anda dapat memilih tautan untuk memeriksa pekerjaan migrasi terakhir untuk kemungkinan penyebab dan tindakan untuk memulihkan.

Logika penjadwalan

Replikasi awal dijadwalkan ketika replikasi dikonfigurasi untuk VM. Ini diikuti oleh replikasi inkremental (replikasi delta).

Siklus replikasi Delta dijadwalkan sebagai berikut:

• Siklus replikasi delta pertama dijadwalkan segera setelah siklus replikasi awal selesai
• Siklus replikasi delta berikutnya dijadwalkan sesuai dengan logika berikut: min[maks[1 jam, (Waktu siklus replikasi delta sebelumnya/2)], 12 jam]

Artinya, replikasi delta berikutnya akan dijadwalkan tidak lebih cepat dari satu jam dan tidak lebih dari 12 jam. Misalnya, jika VM membutuhkan waktu empat jam untuk siklus replikasi delta, siklus replikasi delta berikutnya dijadwalkan dalam dua jam, dan bukan dalam satu jam setelahnya.

Catatan

Logika penjadwalan berbeda setelah replikasi awal selesai. Siklus delta pertama dijadwalkan segera setelah replikasi awal selesai dan siklus berikutnya mengikuti logika penjadwalan yang dijelaskan di atas.

• Saat Anda memicu migrasi, siklus replikasi delta sesuai permintaan (siklus replikasi delta pra-failover) dilakukan untuk VM sebelum migrasi.

Prioritas VM untuk berbagai tahap replikasi

• Replikasi VM yang sedang berlangsung diprioritaskan daripada replikasi terjadwal (replikasi baru)
• Siklus pra-failover (replikasi delta sesuai permintaan) memiliki prioritas tertinggi diikuti oleh siklus replikasi awal. Siklus replikasi Delta memiliki prioritas terkecil.

Artinya, setiap kali operasi migrasi dipicu, siklus replikasi sesuai permintaan untuk VM dijadwalkan dan replikasi berkelanjutan lainnya mengambil kursi kembali jika mereka bersaing untuk sumber daya.

Batasan:

Kami menggunakan batasan berikut untuk memastikan bahwa kami tidak melebihi batas IOPS pada SAN.

• Setiap appliance Azure Migrate mendukung replikasi 52 disk secara paralel
• Setiap host ESXi mendukung 8 disk. Setiap host ESXi memiliki buffer NFC 32-MB. Jadi, kita dapat menjadwalkan 8 disk pada host (Setiap disk membutuhkan 4 MB buffer untuk IR, DR).
• Setiap datastore dapat memiliki maksimum 15 rekam jepret disk. Satu-satunya pengecualian adalah ketika VM memiliki lebih dari 15 disk yang melekat padanya.

Meluaskan skala replikasi

Azure Migrate mendukung replikasi bersamaan dari 500 komputer virtual. Saat Anda berencana untuk mereplikasi lebih dari 300 komputer virtual, Anda harus menyebarkan appliance peluasan skala. Appliance peluasan skala mirip dengan appliance utama Azure Migrate tetapi hanya terdiri dari agen gateway untuk memfasilitasi transfer data ke Azure. Diagram berikut menunjukkan cara yang disarankan untuk menggunakan appliance peluasan skala.

Anda dapat menerapkan alat penskalaan kapan saja setelah mengonfigurasi alat utama, tetapi tidak diperlukan hingga ada 300 VM yang mereplikasi secara bersamaan. Ketika ada 300 VM yang melakukan replikasi secara bersamaan, Anda harus menggunakan appliance peluasan skala untuk melanjutkan.

Menghentikan replikasi/Menyelesaikan migrasi

Ketika Anda menghentikan replikasi, disk perantara yang dikelola (disk nilai awal) yang dibuat selama replikasi akan dihapus. Anda hanya dapat menghentikan replikasi selama replikasi aktif. Anda dapat memilih Selesaikan migrasi untuk menghentikan replikasi setelah VM dimigrasikan.

VM tempat replikasi dihentikan, dapat direplikasi dengan mengaktifkan replikasi lagi. Jika VM dimigrasikan, Anda dapat melanjutkan replikasi dan migrasi lagi.

Sebagai praktik terbaik, Anda harus selalu menyelesaikan migrasi setelah VM berhasil dimigrasikan ke Azure untuk memastikan bahwa Anda tidak dikenakan biaya tambahan untuk transaksi penyimpanan pada disk terkelola menengah (disk benih). Dalam beberapa kasus, Anda akan melihat bahwa menghentikan replikasi membutuhkan waktu. Ini karena setiap kali Anda menghentikan replikasi, siklus replikasi yang sedang berlangsung selesai (hanya ketika VM berada dalam sinkronisasi delta) sebelum menghapus artefak.

Dampak churn

Kami mencoba meminimalkan jumlah transfer data di setiap siklus replikasi dengan memungkinkan data untuk melipat sebanyak mungkin sebelum kami menjadwalkan siklus berikutnya. Karena replikasi tanpa agen dilipat dalam data, pola churn lebih penting dari tingkat churn. Saat file ditulis berulang-ulang, tingkatnya tidak berdampak banyak. Akan tetapi, pola di mana setiap sektor lain ditulis akan menyebabkan churn tinggi pada siklus berikutnya. Jika siklus replikasi delta saat ini mengalami penundaan karena churn data yang tinggi, inisiasi siklus berikutnya mungkin tertunda. Volume data yang lebih tinggi untuk direplikasi untuk disk tertentu akan memperpanjang durasi yang diperlukan untuk membuat titik pemulihan. Akibatnya, siklus migrasi akhir akan memakan waktu lebih lama, yang mengarah ke jendela matikan yang diperluas untuk komputer virtual sumber (VM).

Dalam kasus di mana ukuran rekam jepret meningkat (karena pola churn) hingga batas yang melintasi kapasitas datastore yang tersedia, ada risiko datastore kehabisan ruang. Ini dapat berdampak buruk pada beban kerja produksi dan dapat membuat VM sumber tidak responsif. Untuk mengurangi risiko ini, disarankan untuk meningkatkan ukuran datastore secara proaktif. Selain itu, jika beberapa Virtual Machine sedang direplikasi secara bersamaan dan memiliki disk di datastore yang kapasitasnya tersedia rendah, disarankan untuk melakukan migrasi satu per satu untuk menghindari perebutan sumber daya.

Manajemen replikasi

Pembatasan

Anda dapat menambah atau mengurangi bandwidth replikasi menggunakan NetQosPolicy.AppNamePrefix yang akan digunakan di NetQosPolicy adalah "GatewayWindowsService.exe".

Anda dapat membuat kebijakan mengenai appliance Azure Migrate untuk membatasi lalu lintas replikasi dari appliance dengan membuat kebijakan seperti ini:

New-NetQosPolicy -Name "ThrottleReplication" -AppPathNameMatchCondition "GatewayWindowsService.exe" -ThrottleRateActionBitsPerSecond 1MB

Catatan

Hal ini berlaku untuk semua VM replikasi dari appliance Azure Migrate secara bersamaan.

Anda juga dapat meningkatkan dan mengurangi bandwidth replikasi berdasarkan jadwal menggunakan contoh skrip.

Jendela pemadaman

Azure Migrate menyediakan mekanisme berbasis konfigurasi di mana pelanggan dapat menentukan interval waktu kapan mereka tidak ingin replikasi dilanjutkan. Interval waktu ini disebut jendela pemadaman. Kebutuhan untuk jendela pemadaman dapat muncul dalam beberapa skenario seperti ketika lingkungan sumber dibatasi sumber daya atau ketika pelanggan ingin replikasi hanya dilakukan selama jam non-bisnis, dll.

Catatan

• Siklus replikasi yang ada pada awal jendela pemadaman akan selesai sebelum replikasi berhenti.
• Untuk setiap migrasi yang dimulai selama jendela pemadaman, replikasi akhir tidak akan berjalan, menyebabkan migrasi gagal.

Jendela pemadaman dapat ditentukan untuk alat dengan membuat/memperbarui file GatewayDataWorker.jsdi C:\ProgramData\Microsoft Azure\Config. File biasa adalah formulir:

{
    
    "BlackoutWindows": "List of blackout windows"
    
}

Daftar jendela pemadaman adalah string format "DayOfWeek;StartTime;Duration" yang dibatasi "|". Durasi dapat ditentukan dalam hari, jam, dan menit. Misalnya, jendela pemadaman dapat ditentukan sebagai:

{
    
    "BlackoutWindows": "Monday;7:00;7h | Tuesday;8:00;1d7h | Wednesday;16:00;1d | Thursday;18:00;5h | Friday;13:00;8m"
    
}

Nilai pertama dalam contoh di atas menunjukkan jendela pemadaman dimulai setiap Senin pukul 07.00 waktu setempat (waktu pada appliance) dan berlangsung selama 7 jam.

Setelah GatewayDataWorker.json dibuat/diperbarui dengan konten ini, layanan Gateway pada appliance perlu dimulai ulang agar perubahan ini diterapkan.

Dalam skenario peluasan skala, appliance utama dan appliance peluasan skala menghormati jendela pemadaman secara mandiri. Sebagai praktik terbaik, kami sarankan menjaga jendela tetap konsisten di seluruh appliance.

Langkah berikutnya

Melakukan migrasi VMware VM dengan migrasi tanpa agen.