Pilih wilayah Azure untuk migrasi

Artikel
04/11/2024

Saat memigrasikan lingkungan yang sudah ada ke Azure, Anda perlu memilih wilayah Azure atau sekumpulan wilayah untuk menghosting komponen yang dimigrasikan. Pemilihan wilayah melibatkan langkah-langkah tingkat tinggi berikut:

Tinjau panduan pemilihan wilayah Azure inti untuk memahami cara memilih wilayah Azure yang memenuhi kebutuhan Anda.
Inventori dan dokumentasikan status lingkungan Anda saat ini.
Terapkan pendekatan umum untuk migrasi Anda, termasuk apakah akan berjalan di satu wilayah, menggunakan beberapa zona ketersediaan, atau menggunakan beberapa wilayah.
Menilai perubahan proses yang mungkin diperlukan.
Merencanakan proses migrasi.
Optimalkan dan promosikan perubahan proses.

Artikel ini menyediakan panduan tentang cara memilih wilayah Azure yang memenuhi kebutuhan migrasi Anda. Jika belum melakukannya, Anda mungkin perlu memperluas wilayah zona pendaratan untuk mendukung pendekatan multi-wilayah.

Catatan

Artikel ini membahas pertimbangan yang khusus untuk migrasi beban kerja. Anda juga harus memahami prinsip umum untuk memilih wilayah Azure untuk organisasi atau beban kerja apa pun. Untuk informasi selengkapnya, lihat Memilih wilayah Azure.

Dokumentasikan kompleksitas skenario Anda

Tentukan apakah skenario Anda memerlukan dokumentasi dan penyelarasan proses. Pendekatan berikut dapat membantu Anda menilai potensi tantangan dan menetapkan tindakan umum:

Pertimbangkan kesiapan dan implementasi tata kelola yang lebih kuat.
Inventarifikasi geografi yang terpengaruh. Mengkompilasi daftar negara atau wilayah yang terpengaruh.
Dokumentasikan basis pengguna. Apakah migrasi cloud akan memengaruhi karyawan, mitra, atau pelanggan di negara atau wilayah yang diidentifikasi?
Pusat data dan aset dokumen. Apakah upaya migrasi mencakup aset apa pun di negara atau wilayah yang diidentifikasi?
Dokumentasikan ketersediaan versi produk regional dan persyaratan failover.
Dokumentasikan persyaratan ketahanan Anda untuk menentukan apakah zona ketersediaan diperlukan. Biasanya, Anda mempertimbangkan persyaratan ketahanan untuk seluruh skenario, bukan untuk wilayah individual.
Dokumentasikan persyaratan kedaulatan dan persyaratan residensi data Anda. Beban kerja yang memiliki persyaratan kedaulatan atau residensi data tertentu dapat memengaruhi pilihan wilayah Azure Anda.

Sepanjang proses migrasi, pertimbangkan cara menyelaraskan perubahan di berbagai skenario dan inventaris Anda. Tabel berikut ini memperlihatkan contoh cara mendokumentasikan berbagai skenario.

Wilayah	Negara/wilayah	Karyawan lokal	Pengguna eksternal lokal	Pusat data atau aset lokal	Persyaratan kedaulatan data
Amerika Utara	Amerika Serikat	Ya	Mitra dan pelanggan	Ya	Tidak
Amerika Utara	Kanada	No	Pelanggan	Ya	Ya
Eropa	Jerman	Ya	Mitra dan pelanggan	Tidak - hanya jaringan	Ya
Asia Pasifik	Korea Selatan	Ya	Mitra	Ya	Tidak

Mengapa lokasi pengguna relevan?

Organisasi yang mendukung pengguna di beberapa negara atau wilayah mengembangkan solusi teknis yang menangani lalu lintas pengguna. Dalam beberapa kasus, solusi melibatkan pelokalan aset. Dalam skenario lain, organisasi mungkin memilih untuk menerapkan solusi global wide area network (WAN) untuk mengatasi pangkalan pengguna yang berbeda melalui solusi yang berfokus pada jaringan. Dalam kedua kasus, profil penggunaan pengguna yang berbeda dapat memengaruhi strategi migrasi.

Misalnya, jika organisasi mendukung karyawan, mitra, dan pelanggan di Jerman tetapi saat ini tidak memiliki pusat data di Jerman, organisasi mungkin menerapkan solusi lini sewaan. Jenis solusi ini merutekan lalu lintas ke pusat data di negara atau wilayah lain. Perutean yang ada ini menghadirkan risiko yang signifikan terhadap performa aplikasi yang telah dimigrasikan. Menyuntikkan lebih banyak hop dalam WAN global yang mapan dan disetel dapat menciptakan persepsi aplikasi yang kurang baik setelah migrasi. Menemukan dan memperbaiki masalah tersebut dapat menambah penundaan yang signifikan pada suatu proyek.

Masing-masing bagian berikut mencakup panduan untuk mengatasi kompleksitas ini di seluruh prasyarat dan proses penilaian, migrasi, dan pengoptimalan. Memahami profil pengguna di setiap negara atau wilayah sangat penting untuk mengelola kompleksitas ini dengan benar.

Mengapa lokasi pusat data relevan?

Lokasi pusat data yang ada dapat memengaruhi strategi migrasi. Pertimbangkan faktor berikut:

Keputusan arsitektur: Salah satu langkah pertama dalam desain strategi migrasi adalah menentukan wilayah target. Lokasi aset yang ada sering memengaruhi penentuan ini. Selain itu, ketersediaan layanan cloud dan biaya unit layanan tersebut dapat bervariasi antar wilayah. Persyaratan residensi data, termasuk persyaratan kedaulatan, juga dapat memengaruhi keputusan arsitektur. Memahami tempat aset saat ini dan tempat aset di masa depan mempengaruhi keputusan arsitektur dan dapat mempengaruhi perkiraan anggaran.

Dependensi pusat data: Dalam tabel di bagian Dokumen kompleksitas skenario Anda, contoh skenario menunjukkan bahwa Anda mungkin perlu merencanakan dependensi antara berbagai pusat data global. Organisasi yang beroperasi pada skala ini mungkin tidak mendokumen atau memahami dependensi ini dengan jelas. Pendekatan organisasi Anda untuk mengevaluasi profil pengguna membantu Anda mengidentifikasi beberapa dependensi ini di organisasi Anda. Tim Anda juga harus mengeksplorasi lebih banyak langkah penilaian yang dapat membantu mengurangi risiko dan kompleksitas yang muncul dari dependensi.

Menerapkan pendekatan umum

Pendekatan berikut menggunakan model berbasis data untuk mengatasi kompleksitas migrasi global. Jika cakupan migrasi mencakup beberapa wilayah, tim adopsi cloud harus mengevaluasi pertimbangan kesiapan berikut:

Tentukan apakah Anda dapat memenuhi persyaratan bisnis Anda: Gunakan beberapa zona ketersediaan untuk menentukan persyaratan ketersediaan, ketahanan, performa, dan biaya yang tinggi. Jika persyaratan ini tidak terpenuhi, pertimbangkan apakah Anda memerlukan pendekatan multi-wilayah.
Mengevaluasi kedaulatan data: Kedaulatan data dapat memerlukan pelokalan beberapa aset, tetapi banyak aset tidak diatur oleh batasan kepatuhan tersebut. Layanan seperti pengelogan, pelaporan, perutean jaringan, identitas, dan layanan TI pusat lainnya mungkin memenuhi syarat untuk dihosting sebagai layanan bersama di beberapa langganan atau wilayah. Mengevaluasi kedaulatan data dengan menggunakan model layanan bersama untuk layanan tersebut. Untuk kerangka pendekatan ini, lihat arsitektur referensi untuk topologi hub-spoke dengan layanan bersama.
Pastikan lingkungan Anda diskalakan: Jika Anda menyebarkan beberapa instans lingkungan serupa, Anda dapat membentuk tim khusus untuk migrasi lingkungan untuk membantu menciptakan konsistensi, meningkatkan tata kelola, dan mempercepat penyebaran. Panduan tata kelola untuk perusahaan yang kompleks menetapkan pendekatan yang menciptakan lingkungan yang berskala di beberapa wilayah.

Prasyarat berbasis data

Ketika tim Anda nyaman dengan pendekatan dasar dan kesiapan selaras, pertimbangkan prasyarat berbasis data ini:

Selesaikan penemuan umum: Selesaikan tabel dalam Kompleksitas dokumen untuk mengevaluasi kompleksitas strategi adopsi cloud Anda.
Menganalisis profil pengguna untuk setiap negara atau wilayah yang terpengaruh: Penting untuk memahami perutean pengguna umum di awal proses migrasi. Mengubah garis sewa global dan menambahkan koneksi seperti Azure ExpressRoute ke pusat data cloud dapat mengakibatkan penundaan jaringan berbulan-bulan. Atasi perutean pengguna sedini mungkin dalam proses.
Selesaikan rasionalisasi real estat digital awal: Jika Anda memperkenalkan kompleksitas ke dalam strategi migrasi, selesaikan rasionalisasi real estat digital awal. Untuk informasi selengkapnya, lihat Apa itu estat digital?.
Gunakan penandaan untuk persyaratan estat digital: Menetapkan kebijakan pemberian tag untuk mengidentifikasi beban kerja apa pun yang terpengaruh oleh persyaratan kedaulatan data. Pastikan tag yang diperlukan dimulai dalam rasionalisasi real estat digital dan dibawa ke aset yang dimigrasikan.
Mengevaluasi model hub-spoke: Sistem terdistribusi sering berbagi dependensi umum. Anda sering dapat mengatasi dependensi bersama dengan menerapkan model hub-spoke. Meskipun menerapkan model hub-spoke berada di luar cakupan untuk proses migrasi, benderai model untuk dipertimbangkan selama perulangan masa depan dari proses siap.
Prioritaskan backlog migrasi: Jika Anda memerlukan perubahan jaringan untuk mendukung penyebaran produksi beban kerja yang mendukung beberapa wilayah, tim strategi cloud harus melacak dan mengelola eskalasi yang dihasilkan dari perubahan jaringan. Tingkat dukungan eksekutif yang lebih tinggi ini membantu mempercepat perubahan dengan membebaskan tim strategi untuk mereprioritaskan backlog dan memastikan bahwa perubahan jaringan tidak memblokir beban kerja global. Prioritaskan beban kerja global hanya ketika perubahan jaringan selesai.

Prasyarat ini membantu menetapkan proses yang dapat mengatasi kompleksitas selama eksekusi strategi migrasi.

Menilai perubahan proses

Jika skenario migrasi Anda melibatkan kompleksitas aset global dan basis pengguna, tambahkan aktivitas utama untuk menilai kandidat migrasi Anda. Aktivitas ini menghasilkan data untuk membantu Anda mengklarifikasi hambatan dan hasil bagi pengguna dan aset global.

Tindakan yang disarankan selama proses penilaian

Mengevaluasi dependensi pusat data silang: Alat analisis dependensi di Azure Migrate dapat membantu Anda menentukan dependensi. Gunakan alat-alat ini sebelum Anda memulai migrasi. Jika skenario Anda melibatkan kompleksitas global, mengevaluasi dependensi adalah langkah yang diperlukan dalam proses penilaian. Anda dapat menggunakan pengelompokan dependensi untuk memvisualisasikan dependensi dan mengidentifikasi alamat IP dan port aset apa pun yang diperlukan untuk mendukung beban kerja.

Penting

Anda memerlukan pakar subjek (UKM) yang memahami penempatan aset dan skema alamat IP untuk mengidentifikasi aset yang terletak di pusat data sekunder.
Evaluasi dependensi hilir dan klien dalam visualisasi untuk memahami dependensi dua arah.

Identifikasi dampak pengguna global: Output dari analisis profil pengguna prasyarat harus mengidentifikasi beban kerja apa pun yang terpengaruh oleh profil pengguna global. Jika kandidat migrasi berada dalam daftar beban kerja yang terpengaruh, arsitek migrasi harus berkonsultasi dengan jaringan dan operasi UKM. Para ahli ini membantu memvalidasi perutean jaringan dan ekspektasi performa. Minimal, arsitektur harus menyertakan koneksi ExpressRoute di antara pusat operasi jaringan terdekat dan Azure. Arsitektur referensi untuk koneksi ExpressRoute dapat membantu Anda mengonfigurasi koneksi jaringan yang diperlukan.

Desain untuk kepatuhan: Output dari analisis profil pengguna prasyarat juga harus mengidentifikasi beban kerja apa pun yang terpengaruh oleh persyaratan kedaulatan data. Selama aktivitas arsitektur proses penilaian, arsitek yang ditetapkan harus berkonsultasi dengan UKM kepatuhan. Para ahli ini dapat membantu arsitek memahami persyaratan apa pun untuk migrasi dan penyebaran di beberapa wilayah. Persyaratan tersebut secara signifikan mempengaruhi strategi desain. Arsitektur referensi berikut dapat membantu desain:

Peringatan

Jika Anda menggunakan arsitektur referensi untuk ExpressRoute atau arsitektur referensi untuk aplikasi, Anda mungkin perlu mengecualikan elemen data tertentu dari proses replikasi untuk memenuhi persyaratan kedaulatan data. Tugas mengecualikan elemen data tertentu menambahkan langkah ke proses promosi.

Perubahan proses migrasi

Jika Anda memigrasikan aplikasi yang harus disebarkan ke beberapa wilayah, tim adopsi cloud harus memperhitungkan beberapa pertimbangan lagi. Desain vault Azure Site Recovery dan konfigurasi dan server proses adalah dua dari pertimbangan tersebut. Dua pertimbangan lainnya adalah desain bandwidth jaringan dan sinkronisasi data.

Tindakan yang disarankan selama proses migrasi

Desain vault Site Recovery: Site Recovery adalah alat yang disarankan untuk replikasi cloud-native dan sinkronisasi aset digital ke Azure. Site Recovery mereplikasi data tentang setiap aset ke vault Site Recovery. Vault ini terikat ke langganan tertentu di wilayah tertentu dan pusat data Azure. Jika Anda mereplikasi aset ke wilayah kedua, Anda mungkin juga memerlukan vault Site Recovery kedua.

Desain server konfigurasi dan proses: Site Recovery berfungsi dengan instans lokal konfigurasi dan server proses yang terikat ke satu vault Site Recovery. Saat Anda menggunakan konfigurasi ini, Anda mungkin perlu menginstal instans kedua server ini di pusat data sumber untuk memfasilitasi replikasi.

Desain bandwidth jaringan: Selama replikasi dan sinkronisasi yang sedang berlangsung, Anda memindahkan data biner melalui jaringan dari pusat data sumber ke vault Site Recovery di pusat data Azure target. Proses replikasi dan sinkronisasi mengonsumsi bandwidth. Menduplikasi beban kerja ke wilayah kedua menggandakan jumlah bandwidth yang digunakan.

Dalam beberapa skenario, bandwidth terbatas. Di tempat lain, beban kerja melibatkan konfigurasi besar atau penyimpangan data. Dalam kasus ini, mereplikasi data ke wilayah kedua dapat mengganggu waktu yang diperlukan untuk menyelesaikan migrasi. Lebih penting lagi, batasan ini dapat memengaruhi pengalaman pengguna atau aplikasi yang masih bergantung pada bandwidth yang tersedia di pusat data sumber.

Sinkronisasi data: Pengosongan bandwidth terbesar sering kali berasal dari sinkronisasi platform data. Jika Anda menyebarkan di beberapa zona ketersediaan, Anda mungkin dapat menggunakan layanan data zona-redundan yang secara otomatis menyinkronkan data Anda di beberapa zona ketersediaan. Penyebaran di beberapa wilayah sering memerlukan sinkronisasi data untuk menjaga aplikasi tetap selaras. Pendekatan ini didefinisikan dalam arsitektur referensi untuk aplikasi web multi-wilayah dan aplikasi n-tingkat multi-wilayah.

Jika menjaga aplikasi tetap sinkron adalah status operasional yang Anda inginkan untuk aplikasi, Anda mungkin ingin menyinkronkan platform data sumber dengan setiap platform cloud. Lakukan sinkronisasi ini sebelum Anda memigrasikan aplikasi dan aset tingkat menengah.

Pemulihan bencana Azure-ke-Azure: Opsi alternatif dapat mengurangi kompleksitas lebih lanjut. Jika Anda menggunakan penyebaran dua langkah untuk memenuhi kebutuhan garis waktu dan sinkronisasi data, pemulihan bencana Azure-ke-Azure mungkin merupakan solusi yang dapat diterima. Dalam skenario ini, Anda memigrasikan beban kerja ke pusat data Azure pertama dengan menggunakan satu vault Site Recovery dan konfigurasi dan desain server proses. Setelah menguji beban kerja, Anda dapat memulihkan beban kerja ke pusat data Azure kedua dari aset yang dimigrasikan.

Pendekatan ini mengurangi efek pada sumber daya di pusat data sumber. Pemulihan bencana Azure-ke-Azure juga memanfaatkan kecepatan transfer cepat dan batas bandwidth tinggi antara pusat data Azure.

Catatan

Pendekatan pemulihan bencana Azure-ke-Azure dapat meningkatkan biaya migrasi jangka pendek melalui biaya bandwidth keluar yang lebih tinggi.

Perubahan proses rilis

Saat Anda mengatasi kompleksitas global selama pengoptimalan dan promosi, Anda mungkin memerlukan upaya yang identik di setiap wilayah yang Anda sebarkan. Jika Anda menggunakan satu wilayah, Anda mungkin masih perlu mereplikasi pengujian bisnis dan rencana perubahan bisnis.

Tindakan yang disarankan selama proses rilis

Optimalisasi pengujian awal: Pengujian automasi awal dapat mengidentifikasi peluang pengoptimalan potensial, seperti halnya upaya migrasi apa pun. Untuk beban kerja global, uji beban kerja secara independen di setiap wilayah. Perubahan konfigurasi kecil di jaringan Anda atau di pusat data Azure yang dipilih dapat memengaruhi performa.

Rencana perubahan bisnis: Buat rencana perubahan bisnis untuk skenario migrasi yang kompleks. Rencana perubahan bisnis membantu memastikan komunikasi yang jelas tentang perubahan pada proses bisnis dan pengalaman pengguna. Rencana ini juga membantu memastikan komunikasi yang jelas tentang waktu upaya yang diperlukan untuk mengintegrasikan perubahan. Dalam upaya migrasi global, rencana tersebut harus mencakup pertimbangan untuk pengguna di setiap geografi yang terpengaruh.

Pengujian bisnis: Setiap wilayah mungkin juga memerlukan pengujian bisnis. Pengujian bisnis membantu memastikan performa dan kepatuhan yang memadai terhadap pola perutean jaringan yang dimodifikasi.

Penerbangan promosi: Promosi sering terjadi sebagai satu aktivitas, dan lalu lintas produksi segera dialihkan ke beban kerja yang dimigrasikan. Dalam upaya rilis global, Anda harus memberikan promosi dalam koleksi pengguna yang telah ditentukan sebelumnya yang disebut penerbangan. Penerbangan promosi memberi tim strategi cloud dan tim adopsi cloud kesempatan untuk mengamati performa dan meningkatkan dukungan bagi pengguna di setiap wilayah. Anda dapat mengontrol penerbangan promosi di tingkat jaringan. Secara khusus, Anda dapat mengubah perutean rentang IP tertentu dari aset beban kerja sumber ke aset yang baru dimigrasikan. Setelah memigrasikan kumpulan pengguna tertentu, Anda dapat mengalihkan rute grup berikutnya.

Pengoptimalan penerbangan: Salah satu manfaat dari penerbangan promosi adalah bahwa mereka memberi Anda pengamatan yang lebih mendalam dan kesempatan untuk mengoptimalkan aset yang disebarkan. Setelah penerbangan pertama berhasil menggunakan produksi untuk waktu yang singkat, Anda dapat memperbaiki aset yang dimigrasikan ketika prosedur operasi TI mendukungnya.