Garis besar migrasi zona ketersediaan Azure
Artikel ini menunjukkan kepada Anda cara menilai kesiapan zona ketersediaan aplikasi Anda untuk tujuan migrasi dari zona non-ketersediaan ke dukungan zona ketersediaan. Kami akan membawa Anda melalui langkah-langkah yang Anda perlukan untuk menentukan bagaimana Anda dapat memanfaatkan dukungan zona ketersediaan selaras dengan aplikasi dan persyaratan regional Anda. Untuk informasi selengkapnya tentang zona ketersediaan dan wilayah yang mendukungnya, lihat Apa itu wilayah Azure dan zona ketersediaan.
Saat membuat beban kerja yang andal, Anda dapat memilih setidaknya salah satu konfigurasi zona ketersediaan berikut:
Zonal. Konfigurasi zonal menyediakan zona ketersediaan tertentu yang dipilih sendiri.
Zona-redundan. Konfigurasi zona-redundan menyediakan sumber daya yang direplikasi atau didistribusikan di seluruh zona secara otomatis.
Selain dua opsi zona ketersediaan, zonal dan zona-redundan, Azure menawarkan layanan Global, yang berarti bahwa mereka tersedia secara global terlepas dari wilayah. Karena layanan ini selalu tersedia di seluruh wilayah, layanan ini tahan terhadap pemadaman regional dan zonal.
Untuk melihat layanan Azure mana yang mendukung zona ketersediaan, lihat Layanan zona ketersediaan dan dukungan regional.
Catatan
Saat Anda tidak memilih konfigurasi zona untuk sumber daya Anda, baik zonal atau zona-redundan, sumber daya dan sub-komponennya tidak akan tangguh zona dan dapat turun selama pemadaman zona di wilayah tersebut.
Pertimbangan untuk bermigrasi ke dukungan zona ketersediaan
Ada sejumlah cara yang mungkin untuk membuat aplikasi Azure yang andal dengan zona ketersediaan yang memenuhi SLA dan target keandalan. Ikuti langkah-langkah di bawah ini untuk memilih pendekatan yang tepat untuk kebutuhan Anda berdasarkan pertimbangan teknis dan peraturan, kemampuan layanan, residensi data, persyaratan kepatuhan, dan latensi.
Langkah 1: Periksa apakah wilayah Azure mendukung zona ketersediaan
Pada langkah pertama ini, Anda harus memvalidasi bahwa wilayah Azure yang Anda pilih mendukung zona ketersediaan serta layanan Azure yang diperlukan untuk aplikasi Anda.
Jika wilayah Anda mendukung zona ketersediaan, kami sangat menyarankan Anda mengonfigurasi beban kerja untuk zona ketersediaan. Jika wilayah Anda tidak mendukung zona ketersediaan, Anda harus menggunakan panduan Azure Resource Mover untuk bermigrasi ke wilayah yang menawarkan dukungan zona ketersediaan.
Catatan
Untuk beberapa layanan, zona ketersediaan hanya dapat dikonfigurasi selama penyebaran. Jika Anda ingin menyertakan zona ketersediaan untuk layanan yang ada, Anda mungkin perlu menyebarkan ulang. Lihat dokumentasi khusus layanan dalam Ringkasan panduan migrasi zona ketersediaan untuk produk dan layanan Microsoft Azure.
Langkah 2: Periksa ketersediaan produk dan SKU di wilayah Azure
Dalam langkah ini, Anda akan memvalidasi bahwa layanan dan SKU Azure yang diperlukan tersedia di zona ketersediaan wilayah Azure yang Anda pilih.
Untuk memeriksa dukungan regional layanan, lihat Produk yang tersedia menurut wilayah.
Untuk mencantumkan SKU VM yang tersedia menurut wilayah dan zona Azure, lihat Memeriksa ketersediaan SKU VM.
Jika wilayah Anda tidak mendukung layanan dan SKU yang diperlukan aplikasi, Anda harus kembali ke Langkah 1: Periksa ketersediaan produk di wilayah Azure untuk menemukan wilayah baru yang mendukung layanan dan SKU yang diperlukan aplikasi Anda. Kami sangat menyarankan Agar Anda mengonfigurasi beban kerja Anda dengan zona-redundansi.
Untuk ketersediaan tinggi zona Azure IaaS Virtual Machines, gunakan Virtual Machine Scale Sets (VMSS) Flex untuk menyebarkan VM di beberapa zona ketersediaan.
Langkah 3: Pertimbangkan persyaratan aplikasi Anda
Dalam langkah terakhir ini, Anda akan menentukan, berdasarkan persyaratan aplikasi, jenis dukungan zona ketersediaan mana yang paling cocok untuk aplikasi Anda.
Di bawah ini adalah tiga pertanyaan penting yang akan membantu Anda memilih penyebaran zona ketersediaan yang benar:
Apakah aplikasi Anda menyertakan komponen sensitif latensi?
Zona ketersediaan Azure dalam wilayah Azure yang sama dihubungkan oleh jaringan berkinerja tinggi dengan latensi pulang-pergi kurang dari 2 mdtk.
Pendekatan yang direkomendasikan untuk mencapai ketersediaan tinggi, jika latensi rendah bukan persyaratan yang ketat, adalah mengonfigurasi beban kerja Anda dengan penyebaran zona redundan.
Untuk komponen aplikasi penting yang memerlukan kedekatan fisik dan latensi rendah, seperti game, simulasi teknik, dan perdagangan frekuensi tinggi (HFT), kami sarankan Anda mengonfigurasi penyebaran zona. Virtual Machine Scale Sets Flex menyediakan komputasi selaras zona bersama dengan disk penyimpanan yang terpasang.
Apakah kode aplikasi Anda memiliki kesiapan untuk menangani model terdistribusi?
Untuk model layanan mikro terdistribusi dan tergantung pada aplikasi Anda, ada kemungkinan pertukaran data yang sedang berlangsung antara layanan mikro di seluruh zona. Pertukaran data berkelanjutan ini melalui API, dapat memengaruhi performa. Untuk meningkatkan performa dan mempertahankan arsitektur yang andal, Anda dapat memilih penyebaran zona.
Dengan penyebaran zona, Anda harus:
Identifikasi sumber daya atau layanan sensitif latensi dalam arsitektur Anda.
Konfirmasikan bahwa sumber daya atau layanan sensitif latensi mendukung penyebaran zona.
Temukan bersama sumber daya atau layanan sensitif latensi di zona yang sama. Layanan lain dalam arsitektur Anda mungkin terus tetap redundan zona.
Replikasi layanan zonal sensitif latensi di beberapa zona ketersediaan untuk memastikan ketahanan zona.
Keseimbangan beban antara beberapa penyebaran zona dengan load balancer standar atau global.
Jika layanan Azure mendukung zona ketersediaan, kami sangat menyarankan Anda menggunakan redundansi zona dengan menyebarkan simpul di seluruh zona untuk mendapatkan SLA waktu aktif yang lebih tinggi dan perlindungan terhadap pemadaman zona.
Untuk aplikasi 3 tingkat, penting untuk memahami tingkat aplikasi, bisnis, dan data; serta status mereka (stateful atau stateless) untuk merancang selaras dengan praktik dan panduan terbaik sesuai dengan jenis beban kerja.
Untuk beban kerja khusus di Azure seperti contoh di bawah ini, lihat panduan arsitektur zona pendaratan dan praktik terbaik masing-masing.
SAP
Azure Virtual Desktop
Azure Kubernetes Service
Oracle
Apakah Anda ingin mencapai Kelangsungan Bisnis dan Pemulihan Bencana di wilayah Azure yang sama karena persyaratan kepatuhan, residensi data, atau tata kelola?
Untuk mencapai kelangsungan bisnis dan pemulihan bencana dalam wilayah yang sama dan ketika tidak ada pasangan regional, kami sangat menyarankan Anda mengonfigurasi beban kerja Anda dengan zona-redundansi. Pendekatan satu wilayah juga berlaku untuk industri tertentu yang memiliki persyaratan residensi dan tata kelola data yang ketat dalam wilayah Azure yang sama. Untuk mempelajari cara mereplikasi, failover, dan failback komputer virtual Azure dari satu zona ketersediaan ke zona ketersediaan lainnya dalam wilayah Azure yang sama, lihat Mengaktifkan pemulihan bencana Azure VM antar zona ketersediaan.
Jika Anda memerlukan multi-wilayah, atau jika wilayah Azure Anda tidak mendukung zona ketersediaan, kami sarankan Anda menggunakan pasangan regional. Pasangan regional terletak pada jarak yang jauh di sekitar 100 mil terpisah, dan memberi Anda perlindungan radius ledakan dari kegagalan tingkat regional seperti kebakaran, banjir, gempa bumi dan bencana alam atau tak terduga lainnya. Untuk informasi selengkapnya, lihat Replikasi lintas wilayah di Azure: Kelangsungan bisnis dan pemulihan bencana.
Catatan
Mungkin ada skenario di mana kombinasi layanan zonal, zona-redundan, dan global berfungsi paling baik untuk memenuhi persyaratan bisnis dan teknis.
Poin lain yang perlu dipertimbangkan
Untuk mempelajari tentang menguji aplikasi Anda untuk ketersediaan dan ketahanan, lihat Menguji aplikasi untuk ketersediaan dan ketahanan.
Setiap pusat data di suatu wilayah ditetapkan ke zona fisik. Zona fisik dipetakan ke zona logis di langganan Azure Anda. Langganan Azure secara otomatis diberi pemetaan ini pada saat langganan dibuat. Anda dapat menggunakan ARM REST API khusus, listLocations, dan mengatur versi API ke 2022-12-01 untuk mencantumkan pemetaan zona logis ke zona fisik untuk langganan Anda. Informasi ini penting untuk komponen aplikasi penting yang memerlukan lokasi bersama dengan sumber daya Azure yang dikategorikan sebagai Layanan strategis yang mungkin tidak tersedia di semua zona fisik.