Memigrasikan beban kerja Azure Kubernetes Service (AKS) dan MySQL Flexible Server ke dukungan zona ketersediaan
Panduan ini menjelaskan cara memigrasikan beban kerja Azure Kubernetes Service dan MySQL Flexible Server untuk menyelesaikan dukungan zona ketersediaan di semua layanan dependen. Untuk daftar lengkap semua dependensi beban kerja, lihat Dependensi layanan Beban Kerja.
Dukungan zona ketersediaan untuk beban kerja ini harus diaktifkan selama pembuatan kluster AKS atau Server Fleksibel MySQL Anda. Jika Anda menginginkan dukungan zona ketersediaan untuk kluster AKS yang ada dan Server Fleksibel MySQL, Anda harus menyebarkan ulang sumber daya tersebut.
Panduan migrasi ini berfokus terutama pada infrastruktur dan pertimbangan ketersediaan menjalankan arsitektur berikut di Azure:
Dependensi layanan beban kerja
Untuk memberikan dukungan beban kerja penuh untuk zona ketersediaan, setiap dependensi layanan dalam beban kerja harus mendukung zona ketersediaan.
Ada dua pendekatan jenis layanan yang didukung zona ketersediaan: zonal atau zona-redundan. Sebagian besar layanan mendukung satu atau yang lain. Namun, dalam beberapa kasus, ada opsi untuk memilih sumber daya zonal atau zona-redundan untuk layanan tersebut. Kami menunjukkan layanan mana yang mendukung sumber daya zona dan zona-redundan dalam rekomendasi berikut. Kami juga menunjukkan layanan mana yang bersifat global dan regional.
Arsitektur beban kerja AKS dan MySQL terdiri dari dependensi komponen berikut:
Azure Kubernetes Service (AKS)
Zona : Kumpulan simpul sistem dan kumpulan simpul pengguna bersifat zonal ketika Anda telah memilih zona tempat kumpulan simpul disebarkan selama waktu pembuatan. Sebaiknya Anda memilih ketiga zona terlebih dahulu untuk ketahanan yang lebih baik. Lebih banyak kumpulan simpul pengguna yang mendukung zona ketersediaan dapat ditambahkan ke kluster AKS yang ada dan dengan menyediakan nilai untuk
zonesparameter .Zona-redundan: Komponen sarana kontrol Kube seperti etcd, API server, Scheduler, dan Controller Manager secara otomatis direplikasi atau didistribusikan di seluruh zona.
Catatan
Untuk mengaktifkan redundansi zona komponen sarana kontrol kluster AKS, Anda harus menentukan kumpulan simpul sistem default Anda dengan zona saat membuat kluster AKS. Menambahkan lebih banyak kumpulan simpul zona ke kluster AKS non-zonal yang ada tidak akan membuat zona kluster AKS menjadi redundan, karena tindakan tersebut tidak mendistribusikan komponen sarana kontrol di seluruh zona setelah fakta.
Server Flexible Azure Database for MySQL
Zonal: Mode ketersediaan zona berarti bahwa server siaga selalu tersedia dalam zona yang sama dengan server utama. Meskipun opsi ini mengurangi waktu failover dan latensi jaringan, opsi ini kurang tangguh karena pemadaman zona tunggal yang berdampak pada server utama dan siaga.
Zona-redundan: Mode ketersediaan zona-redundan berarti bahwa server siaga selalu tersedia dalam zona lain di wilayah yang sama dengan server utama. Dua zona akan diaktifkan untuk redundansi zona untuk server utama dan siaga. Kami merekomendasikan konfigurasi ini untuk ketahanan yang lebih baik.
Azure Standard Load Balancer atau Azure Application Gateway
Standar Load Balancer
Untuk memahami pertimbangan yang terkait dengan sumber daya Load Balancer Standar, lihat Load Balancer dan Zona Ketersediaan.
Zona-redundan: Memilih zona-redundansi adalah cara yang disarankan untuk mengonfigurasi IP Frontend Anda dengan Load Balancer yang ada. Front-end zona-redundan sesuai dengan kumpulan back-end kluster AKS, yang didistribusikan di beberapa zona.
Zonal: Jika Anda menyematkan kumpulan simpul ke zona tertentu seperti zona 1 dan 2, Anda dapat memilih zona 1 dan 2 sebelumnya untuk IP Frontend Anda di Load Balancer yang ada. Alasan mengapa Anda mungkin ingin menyematkan kumpulan simpul Anda ke zona tertentu bisa disebabkan oleh ketersediaan seri SKU VM khusus seperti seri M.
Azure Application Gateway
Menggunakan add-on Pengontrol Ingress Application Gateway dengan kluster AKS Anda hanya didukung pada SKU Application Gateway v2 (Standar dan WAF). Untuk memahami pertimbangan lebih lanjut yang terkait dengan Azure Application Gateway, lihat Menskalakan Application Gateway v2 dan WAF v2.
Zonal: Untuk menggunakan manfaat zona ketersediaan, sebaiknya sumber daya Application Gateway dibuat di beberapa zona, seperti zona 1, 2, dan 3. Pilih ketiga zona untuk strategi ketahanan intra-wilayah terbaik. Namun, agar sesuai dengan kumpulan simpul backend, Anda dapat menyematkan kumpulan simpul ke zona tertentu dengan memilih zona 1 dan 2 sebelumnya selama pembuatan sumber daya App Gateway Anda. Alasan mengapa Anda mungkin ingin menyematkan kumpulan simpul Anda ke zona tertentu bisa disebabkan oleh ketersediaan seri SKU VM khusus seperti M-series.
Penyimpanan Redundan Zona (ZRS)
Sebaiknya kluster AKS Anda dikonfigurasi dengan disk ZRS terkelola karena merupakan sumber daya zona-redundan. Volume dapat dijadwalkan pada semua zona.
Kube mengetahui zona ketersediaan Azure sejak versi 1.12. Anda dapat menyebarkan objek yang
PersistentVolumeClaimmereferensikan Disk Terkelola Azure di kluster AKS multi-zona. Kubernetes akan mengurus penjadwalan pod apa pun yang mengklaim PVC ini di zona ketersediaan yang benar.Untuk Azure Database for SQL, sebaiknya file data dan log dihosting di penyimpanan zona redundan (ZRS). File-file ini direplikasi ke server siaga melalui replikasi tingkat penyimpanan yang tersedia dengan ZRS.
Azure Firewall
Zonal: Untuk menggunakan manfaat zona ketersediaan, sebaiknya sumber daya Azure Firewall dibuat di beberapa zona, seperti zona 1, 2, dan 3. Kami menyarankan agar Anda memilih ketiga zona untuk strategi ketahanan intra-wilayah terbaik.
Azure Bastion
Regional: Azure Bastion disebarkan dalam VNet atau VNet yang di-peering dan dikaitkan dengan wilayah Azure. Untuk informasi selengkapnya, se Keandalan di Azure Bastion.
Azure Container Registry (ACR)
Zona-redundan: Kami sarankan Anda membuat registri zona-redundan di tingkat layanan Premium. Anda juga dapat membuat replika registri zona-redundan dengan mengatur zoneRedundancy properti untuk replika. Untuk mempelajari cara mengaktifkan redundansi zona untuk ACR Anda, lihat Mengaktifkan redundansi zona di Azure Container Registry untuk ketahanan dan ketersediaan tinggi.
Azure Cache untuk Redis
Zona-redundan: Azure Cache for Redis mendukung konfigurasi redundansi zona di tingkat Premium dan Enterprise. Cache zona-redundan menempatkan simpulnya di berbagai zona ketersediaan di wilayah yang sama.
Microsoft Entra ID
Global: MICROSOFT Entra ID adalah layanan global dengan beberapa tingkat redundansi internal dan pemulihan otomatis. ID Microsoft Entra disebarkan di lebih dari 30 pusat data di seluruh dunia yang menyediakan zona ketersediaan di mana ada. Jumlah ini berkembang pesat saat lebih banyak wilayah disebarkan.
Azure Key Vault
Regional: Azure Key Vault disebarkan di suatu wilayah. Untuk mempertahankan durabilitas tinggi kunci dan rahasia Anda, konten brankas kunci Anda direplikasi dalam wilayah dan ke wilayah sekunder dalam geografi yang sama.
Zona-redundan: Untuk wilayah Azure dengan zona ketersediaan dan tanpa pasangan wilayah, Key Vault menggunakan penyimpanan redundan zona (ZRS) untuk mereplikasi konten brankas kunci Anda tiga kali dalam satu lokasi/wilayah.
Pertimbangan beban kerja
Azure Kubernetes Service (AKS)
Pod dapat berkomunikasi dengan pod lain, terlepas dari simpul mana atau zona ketersediaan tempat pod mendarat di simpul. Aplikasi Anda mungkin mengalami waktu respons yang lebih tinggi jika pod berada di zona ketersediaan yang berbeda. Meskipun latensi pulang pergi ekstra antar pod diperkirakan berada dalam rentang yang dapat diterima untuk sebagian besar aplikasi, ada skenario aplikasi yang membutuhkan latensi rendah, terutama untuk pola komunikasi yang cerewet antar pod.
Kami menyarankan agar Anda menguji aplikasi untuk memastikannya berkinerja baik di seluruh zona ketersediaan.
Untuk alasan performa latensi rendah tersebut, pod dapat ditempatkan bersama di pusat data yang sama dalam zona ketersediaan yang sama. Untuk menemukan pod bersama di pusat data yang sama dalam zona ketersediaan yang sama, Anda dapat membuat kumpulan simpul pengguna dengan zona unik dan grup penempatan kedekatan. Anda dapat menambahkan grup penempatan kedekatan (PPG) ke kluster AKS yang ada dengan membuat kumpulan simpul agen baru dan menentukan PPG. Gunakan Batasan Sebaran Topologi Pod untuk mengontrol bagaimana pod tersebar di kluster AKS Anda di seluruh zona ketersediaan, simpul, dan wilayah.
Setelah pod yang memerlukan komunikasi latensi rendah terletak bersama di zona ketersediaan yang sama, komunikasi antara pod tidak langsung. Sebaliknya, komunikasi pod disalurkan melalui layanan yang mendefinisikan serangkaian pod logis di kluster AKS Anda. Pod dapat dikonfigurasi untuk berbicara dengan AKS dan komunikasi ke layanan akan secara otomatis diseimbangkan beban ke semua pod yang merupakan anggota layanan.
Untuk memanfaatkan zona ketersediaan, kumpulan simpul berisi VM yang mendasar yang merupakan sumber daya zona. Untuk mendukung aplikasi yang memiliki permintaan komputasi atau penyimpanan yang berbeda, Anda dapat membuat kumpulan simpul pengguna dengan ukuran VM tertentu saat Membuat kumpulan simpul pengguna.
Misalnya, Anda dapat memutuskan untuk menggunakan
Standard_M32msdi bawahM-seriesuntuk simpul pengguna Anda karena layanan mikro dalam aplikasi Anda memerlukan throughput tinggi, latensi rendah, dan ukuran VM memori yang dioptimalkan yang memberikan jumlah vCPU tinggi dan memori dalam jumlah besar. Bergantung pada wilayah penyebaran, saat Anda memilih ukuran VM dalam portal Azure, Anda mungkin melihat bahwa ukuran VM ini hanya didukung di zona 1 dan 2. Anda dapat menerima konfigurasi ketahanan ini sebagai trade-off untuk performa tinggi.Anda tidak dapat mengubah ukuran VM dari kumpulan node setelah membuatnya. Untuk informasi selengkapnya tentang batasan kumpulan simpul, lihat Batasan.
Server Flexible Azure Database for MySQL
Implikasi penyebaran kumpulan simpul Anda di zona tertentu, seperti zona 1 dan 2, adalah bahwa semua dependensi layanan kluster AKS Anda juga harus mendukung zona 1 dan 2. Dalam arsitektur beban kerja ini, kluster AKS Anda memiliki dependensi layanan pada Server Fleksibel Azure Database for MySQL dengan ketahanan zona. Anda akan memilih zona 1 untuk server utama dan zona 2 agar server siaga Anda berada bersama dengan kumpulan simpul pengguna AKS Anda.
Azure Cache untuk Redis
Azure Cache for Redis mendistribusikan simpul dalam cache zona-redundan dengan cara round-robin di atas zona ketersediaan yang telah Anda pilih.
Anda tidak dapat memperbarui cache Premium yang ada untuk menggunakan redundansi zona. Untuk menggunakan redundansi zona, Anda harus membuat ulang Azure Cache for Redis.
Untuk mencapai ketahanan optimal, kami sarankan Anda membuat Azure Cache for Redis dengan tiga replika atau lebih sehingga Anda dapat mendistribusikan replika di tiga zona ketersediaan.
Pertimbangan Pemulihan Bencana
Zona ketersediaan digunakan untuk ketahanan yang lebih baik untuk mencapai ketersediaan beban kerja Anda yang tinggi dalam wilayah utama penyebaran Anda.
Pemulihan Bencana terdiri dari operasi pemulihan dan praktik yang ditentukan dalam rencana kelangsungan bisnis Anda. Rencana kelangsungan bisnis Anda membahas cara beban kerja Anda pulih selama peristiwa yang mengganggu dan bagaimana hal itu sepenuhnya pulih setelah peristiwa. Pertimbangkan untuk memperluas penyebaran Anda ke wilayah alternatif.
Untuk tingkat aplikasi Anda, harap tinjau kelangsungan bisnis dan pertimbangan pemulihan bencana untuk AKS dalam artikel ini.
Pertimbangkan untuk menjalankan beberapa kluster AKS di wilayah alternatif. Wilayah alternatif dapat menggunakan wilayah berpasangan sekunder. Atau, di mana tidak ada pasangan wilayah untuk wilayah utama Anda, Anda dapat memilih wilayah alternatif berdasarkan pertimbangan Anda untuk layanan, kapasitas, kedekatan geografis, dan kedaulatan data yang tersedia. Harap tinjau panduan keputusan wilayah Azure. Tinjau juga pola stempel penyebaran.
Anda memiliki opsi untuk mengonfigurasi active-active, active-standby, active-passive untuk kluster AKS Anda.
Untuk tingkat database Anda, fitur pemulihan bencana mencakup pencadangan geo-redundan dengan kemampuan untuk memulai pemulihan geografis dan menyebarkan replika baca di wilayah yang berbeda.
Selama pemadaman, Anda harus memutuskan apakah akan memulai pemulihan. Anda harus memulai operasi pemulihan hanya ketika pemadaman kemungkinan akan berlangsung lebih lama dari tujuan waktu pemulihan (RTO) beban kerja Anda. Jika tidak, Anda akan menunggu pemulihan layanan dengan memeriksa status layanan di Dasbor Azure Service Health. Pada bilah Service Health dari portal Azure, Anda dapat melihat pemberitahuan apa pun yang terkait dengan langganan Anda.
Saat Anda memulai pemulihan dengan fitur pemulihan geografis di Azure Database for MySQL, server database baru dibuat menggunakan data cadangan yang direplikasi dari wilayah lain.
Langkah berikutnya
Pelajari lebih lanjut tentang: