Memigrasikan beban kerja cloud ke wilayah lain
Langkah Migrasi relokasi adalah tempat Anda memindahkan beban kerja ke wilayah baru. Bergantung pada beban kerja Anda, Anda mungkin memiliki beberapa persyaratan teknis untuk disiapkan, tetapi strategi relokasi untuk beban kerja harus jelas. Anda harus siap untuk menjalankan relokasi.
Siapkan
Sebelum memulai relokasi beban kerja, Anda perlu menyiapkan wilayah target. Sesuai kebutuhan, ikuti langkah-langkah ini untuk menyiapkan lingkungan beban kerja Anda sebelum relokasi. Melakukannya memastikan Anda memiliki jaringan regional inti seperti hub regional dan, jika perlu, konektivitas lintas lokasi.
Menetapkan zona pendaratan. Saat merencanakan pemindahan Anda, nilai apakah itu memperluas cakupan zona pendaratan Azure Anda. Jika perluasan diperlukan, lihat panduan zona pendaratan Azure sebagai langkah dasar. Langkah ini memastikan pendekatan Anda selaras dengan praktik terbaik yang ditetapkan. Untuk informasi selengkapnya, lihat Menambahkan wilayah baru ke zona pendaratan Azure yang sudah ada. Pertimbangan penting untuk menyiapkan zona pendaratan baru Anda meliputi:
- Jaringan: Mengevaluasi struktur jaringan, jalur perutean, dan persyaratan konektivitas untuk zona pendaratan di wilayah baru.
- Integrasi: Tentukan apakah ada kebutuhan untuk mengintegrasikan zona pendaratan baru dengan yang ada di wilayah sumber Anda.
- Relokasi sumber daya selektif: Tentukan apakah semua sumber daya berpindah ke wilayah baru. Jika beberapa sumber daya tetap berada di lokasi asli, rencanakan topologi jaringan lintas wilayah yang berkelanjutan untuk mengelola sumber daya terdistribusi ini secara efektif.
Buat langganan baru hanya jika diperlukan. Hanya buat langganan baru jika Anda perlu merestrukturisasi layanan dan sumber daya yang terlibat. Cobalah untuk menyimpan beban kerja dalam langganan yang sudah ada jika memungkinkan karena membuat langganan baru menambah kompleksitas. Langganan berfungsi sebagai batasan untuk anggaran, kebijakan, dan kontrol akses berbasis peran (RBAC). Untuk langganan baru apa pun, Anda perlu memvalidasi anggaran, kebijakan, dan RBAC. Jika Anda tidak memindahkan semua sumber daya dalam langganan, maka Anda perlu mencakup kebijakan identitas dan keamanan agar sesuai dengan pengelompokan sumber daya yang lebih kecil. Untuk membuat langganan baru, Anda perlu membuat, mencakup, dan menerapkan kebijakan Azure dan peran RBAC yang diperlukan dalam langganan target. Tujuannya adalah untuk menjaga tata kelola dan postur keamanan.
Konfigurasikan nama domain baru jika diperlukan. Saat ada perubahan pada domain kustom beban kerja, Anda perlu mengonfigurasi nama domain baru. Buat nama host baru, tetapkan ke aplikasi atau layanan Anda, lalu validasi resolusi nama. Anda mungkin juga berencana untuk menurunkan dan mengonfigurasi time-to-live (TTL) dan mengaturnya dalam tahap cutover untuk kedaluwarsa otomatis. Untuk informasi selengkapnya, lihat Menambahkan domain kustom Anda dan Memetakan nama DNS ke paket App Service.
Buat sertifikat SSL/TLS baru jika diperlukan. Anda perlu membuat sertifikat SSL/TLS baru (X.509) untuk nama domain baru apa pun. Sertifikat ini memungkinkan enkripsi kunci publik-privat dan komunikasi jaringan aman (HTTPS). Gunakan Azure Key Vault untuk membuat atau mengimpor sertifikat X.509. Untuk informasi selengkapnya, lihat Sertifikat Azure Key Vault dan Metode pembuatan sertifikat
Merelokasi Azure Key Vault. Anda harus merelokasi Azure Key Vault sebelum memindahkan beban kerja Anda. Anda harus memiliki satu brankas kunci per lingkungan aplikasi, dan brankas kunci Anda tidak boleh berbagi rahasia di seluruh wilayah untuk memastikan kerahasiaan. Anda mungkin perlu membuat brankas kunci baru di wilayah target baru untuk menyelaraskan dengan panduan ini.
Buat ruang kerja Analitik Log baru. Anda harus memiliki ruang kerja Analitik Log terpisah untuk setiap wilayah. Buat ruang kerja baru di wilayah target. Karena tidak dapat memindahkan Ruang Kerja Analitik Log ke wilayah lain, Anda perlu membuat ruang kerja Analitik Log baru di wilayah target. Ada dua opsi untuk mempertahankan data di ruang kerja asli. Anda dapat menyimpan ruang kerja saat ini hingga Anda tidak memerlukan data, memperlakukan data sebagai baca-saja. Anda juga dapat mengekspor data ruang kerja ke akun penyimpanan di wilayah Azure target baru.
Memigrasikan layanan
Anda dapat mulai memigrasikan layanan dalam beban kerja Anda. Untuk eksekusi, ikuti panduan yang tersedia untuk otomatisasi relokasi yang Anda pilih. Azure Resource Mover dan Azure Site Recovery memiliki tutorial langkah demi langkah yang harus diikuti untuk relokasi layanan. Untuk informasi selengkapnya, lihat:
Anda dapat membuat templat infrastruktur sebagai kode atau skrip untuk sumber daya yang tidak dapat Anda pindahkan. Anda juga dapat menjalankan penyebaran secara manual di portal Azure. Langkah-langkah spesifik yang Anda ikuti bergantung pada layanan Azure yang Anda gunakan dan konfigurasinya. Untuk informasi selengkapnya, lihat Gambaran umum infrastruktur sebagai kode.
Migrasikan data
Tahap ini hanya relevan ketika beban kerja memerlukan migrasi data. Lakukan migrasi data dengan otomatisasi yang dipilih. Sebelum cutover ke beban kerja di wilayah target, Anda harus memastikan bahwa data terkait sinkron dengan wilayah sumber. Konsistensi data adalah aspek penting yang membutuhkan perawatan. Berikut panduan untuk memigrasikan data beban kerja.
Memigrasikan data wilayah sumber. Pendekatan untuk memigrasikan data wilayah sumber harus mengikuti metode relokasi untuk layanan beban kerja. Metode panas, dingin, dan hangat memiliki proses yang berbeda untuk mengelola data di wilayah sumber.
Menyinkronkan data. Teknik sinkronisasi tergantung pada arsitektur beban kerja dan permintaan aplikasi. Misalnya, dalam sinkronisasi sesuai permintaan, perubahan ditarik saat data diakses untuk pertama kalinya. Penarikan dan penggabungan perubahan hanya terjadi dalam kasus di mana ada perbedaan antara akses aplikasi terakhir dan saat ini.
Mengatasi konflik sinkronisasi. Pastikan data di lokasi sumber dan target sinkron dan atasi konflik data apa pun. Anda hanya ingin pengguna mencoba mengakses data yang tersedia. Misalnya, Azure Cosmos DB dapat membuat serialisasi tulisan bersamaan untuk memastikan konsistensi data.
Perbarui string koneksi
Konfigurasi string koneksi tergantung pada layanan yang disambungkan aplikasi. Anda dapat mencari "string koneksi" di halaman dokumentasi kami untuk menemukan panduan khusus layanan dan menggunakan panduan tersebut untuk memperbarui string koneksi. Untuk informasi selengkapnya, lihat Dokumentasi teknis.
Identitas Terkelola
Identitas terkelola yang ditetapkan sistem memiliki siklus hidup yang terikat ke sumber daya Azure. Jadi strategi relokasi sumber daya Azure menentukan bagaimana identitas terkelola yang ditetapkan sistem ditangani. Jika instans baru sumber daya dibuat di target, maka Anda harus memberikan izin yang sama dengan identitas terkelola yang ditetapkan sistem baru sebagai identitas terkelola yang ditetapkan sistem di wilayah sumber.
Di sisi lain, identitas terkelola yang ditetapkan pengguna memiliki siklus hidup independen, dan Anda dapat memetakan identitas terkelola yang ditetapkan pengguna ke sumber daya baru di wilayah target. Untuk informasi selengkapnya, lihat Gambaran umum identitas terkelola.
Langkah berikutnya
Anda memigrasikan layanan dan data beban kerja Anda. Sekarang Anda perlu menyelesaikan relokasi dengan cutover.