Keandalan di Azure Batch
Artikel ini menjelaskan dukungan keandalan di Azure Batch dan mencakup ketahanan intra-regional dengan zona ketersediaan dan tautan ke informasi tentang pemulihan lintas wilayah dan kelangsungan bisnis.
Dukungan zona ketersediaan
Zona ketersediaan Azure adalah setidaknya tiga grup pusat data yang terpisah secara fisik dalam setiap wilayah Azure. Pusat data dalam setiap zona dilengkapi dengan infrastruktur daya, pendinginan, dan jaringan independen. Dalam kasus kegagalan zona lokal, zona ketersediaan dirancang sehingga jika satu zona terpengaruh, layanan regional, kapasitas, dan ketersediaan tinggi didukung oleh dua zona yang tersisa.
Kegagalan dapat berkisar dari kegagalan perangkat lunak dan perangkat keras hingga peristiwa seperti gempa bumi, banjir, dan kebakaran. Toleransi terhadap kegagalan dicapai dengan redundansi dan isolasi logis layanan Azure. Untuk informasi selengkapnya tentang zona ketersediaan di Azure, lihat Wilayah dan zona ketersediaan.
Layanan berkemampuan zona ketersediaan Azure dirancang untuk memberikan tingkat keandalan dan fleksibilitas yang tepat. Mereka dapat dikonfigurasi dalam dua cara. Mereka dapat berupa zona redundan,dengan replikasi otomatis di seluruh zona, atau zonal, dengan instans yang disematkan ke zona tertentu. Anda juga dapat menggabungkan pendekatan ini. Untuk informasi selengkapnya tentang arsitektur zonal vs. zona-redundan, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.
Batch mempertahankan paritas dengan Azure pada zona ketersediaan pendukung.
Prasyarat
Untuk mode langganan pengguna akun Batch, pastikan langganan tempat Anda membuat kumpulan tidak memiliki batasan penawaran zona pada SKU VM yang diminta. Untuk melihat apakah langganan Anda tidak memiliki batasan apa pun, panggil RESOURCE Skus List API dan periksa
ResourceSkuRestrictions. Jika ada pembatasan zona, Anda dapat mengirimkan tiket dukungan untuk menghapus pembatasan zona.Karena InfiniBand tidak mendukung komunikasi antar-zona, Anda tidak dapat membuat kumpulan dengan kebijakan zona jika komunikasi antar-simpul diaktifkan dan menggunakan SKU VM yang mendukung InfiniBand.
Batch mempertahankan paritas dengan Azure pada zona ketersediaan pendukung. Untuk menggunakan opsi zonal, kumpulan Anda harus dibuat di wilayah Azure dengan dukungan zona ketersediaan.
Untuk mengalokasikan kumpulan Batch Anda di seluruh zona ketersediaan, wilayah Azure tempat kumpulan dibuat harus mendukung SKU VM yang diminta di lebih dari satu zona. Untuk memvalidasi bahwa wilayah mendukung SKU VM yang diminta di lebih dari satu zona, panggil RESOURCE Skus List API dan periksa
locationInfobidangresourceSku. Pastikan bahwa lebih dari satu zona didukung untuk SKU VM yang diminta. Anda juga dapat menggunakan Azure CLI untuk mencantumkan semua SKU Sumber Daya yang tersedia dengan perintah berikut:az vm list-skus
Membuat kumpulan Azure Batch di seluruh zona ketersediaan
Untuk contoh tentang cara membuat kumpulan Batch di seluruh zona ketersediaan, lihat Membuat kumpulan Azure Batch di seluruh zona ketersediaan.
Pelajari selengkapnya tentang membuat akun Batch dengan portal Microsoft Azure, Azure CLI, PowerShell, atau API manajemen Batch.
Pengalaman zona tidak berfungsi
Selama pemadaman zona tidak berfungsi, simpul dalam zona tersebut menjadi tidak tersedia. Simpul apa pun dalam kumpulan simpul yang sama dari zona lain tidak terpengaruh dan terus tersedia.
Akun Azure Batch tidak merealokasi atau membuat simpul baru untuk mengimbangi simpul yang telah turun karena pemadaman. Pengguna diharuskan untuk menambahkan lebih banyak simpul ke kumpulan simpul, yang kemudian dialokasikan dari zona sehat lainnya.
Toleransi kegagalan
Untuk mempersiapkan kemungkinan kegagalan zona ketersediaan, Anda harus menyediakan kapasitas layanan secara berlebihan untuk memastikan bahwa solusi dapat mentolerir kehilangan kapasitas 1/3 dan terus berfungsi tanpa performa yang menurun selama pemadaman di seluruh zona. Karena platform menyebarkan VM di tiga zona dan Anda harus memperhitungkan setidaknya kegagalan satu zona, kalikan jumlah instans beban kerja puncak dengan faktor zona/(zona-1), atau 3/2. Misalnya, jika beban kerja puncak umum Anda memerlukan empat instans, Anda harus menyediakan enam instans: (2/3 * 6 instans) = 4 instans.
Migrasi zona ketersediaan
Anda tidak dapat memigrasikan kumpulan Batch yang ada ke dukungan zona ketersediaan. Jika Anda ingin membuat ulang kumpulan Batch Anda di seluruh zona ketersediaan, lihat Membuat kumpulan Azure Batch di seluruh zona ketersediaan.
Pemulihan bencana lintas wilayah dan kelangsungan bisnis
Azure Batch tersedia di semua wilayah Azure. Namun, ketika akun Batch dibuat, akun tersebut harus dikaitkan dengan satu wilayah tertentu. Semua operasi berikutnya untuk akun Batch tersebut hanya berlaku untuk wilayah tersebut. Misalnya, kumpulan komputer virtual (VM) yang terhubung dibuat di wilayah yang sama dengan akun Batch.
Saat merancang aplikasi yang menggunakan Batch, Anda harus mempertimbangkan kemungkinan bahwa Batch mungkin tidak tersedia di suatu wilayah. Dimungkinkan untuk mengalami situasi langka di mana ada masalah dengan wilayah secara keseluruhan, seluruh layanan Batch di wilayah tersebut, atau akun Batch spesifik Anda.
Jika aplikasi atau solusi yang menggunakan Batch harus selalu tersedia, maka harus dirancang untuk failover ke wilayah lain atau selalu memiliki beban kerja yang dibagi antara dua wilayah atau lebih. Kedua pendekatan tersebut memerlukan setidaknya dua akun Batch dengan setiap akun yang terletak di wilayah yang berbeda.
Anda bertanggung jawab untuk menyiapkan pemulihan bencana lintas wilayah dengan Azure Batch. Jika Anda menjalankan beberapa akun Batch di seluruh wilayah tertentu dan memanfaatkan zona ketersediaan, aplikasi Anda dapat memenuhi tujuan pemulihan bencana Saat salah satu akun Batch Anda menjadi tidak tersedia.
Saat memberikan kemampuan untuk failover ke wilayah alternatif, semua komponen dalam solusi harus dipertimbangkan; tidak cukup hanya memiliki akun Batch kedua. Misalnya, di sebagian besar aplikasi Batch, akun penyimpanan Azure diperlukan. Akun penyimpanan dan akun Batch harus berada di wilayah yang sama untuk performa yang dapat diterima.
Pertimbangkan poin-poin berikut saat mendesain solusi yang dapat gagal:
Buat sebelumnya semua layanan yang diperlukan di setiap wilayah, seperti akun Batch dan akun penyimpanan. Seringkali tidak ada biaya untuk membuat akun, dan biaya bertambah hanya ketika akun digunakan atau saat data disimpan.
Pastikan sebelumnya bahwa kuota yang sesuai diatur untuk semua akun Batch langganan pengguna, untuk mengalokasikan jumlah inti yang diperlukan menggunakan akun Batch.
Gunakan templat dan/atau skrip untuk mengotomatisasi penyebaran aplikasi di suatu wilayah.
Tetap perbarui biner aplikasi dan data referensi di semua wilayah. Tetap up to date akan memastikan bahwa wilayah dapat dibawa online dengan cepat tanpa harus menunggu pengunggahan dan penyebaran file. Misalnya, pertimbangkan kasus di mana aplikasi kustom untuk diinstal pada simpul kumpulan disimpan dan dirujuk menggunakan paket aplikasi Batch. Ketika pembaruan aplikasi dirilis, itu harus diunggah ke setiap akun Batch dan direferensikan oleh konfigurasi kumpulan (atau membuat versi terbaru sebagai versi default).
Dalam aplikasi yang memanggil Batch, penyimpanan, dan layanan lainnya, akan memudahkan untuk beralih klien atau beban ke wilayah yang berbeda.
Pertimbangkan untuk sering beralih ke wilayah alternatif sebagai bagian dari operasi normal. Misalnya, dengan dua penyebaran di wilayah terpisah, beralihlah ke wilayah alternatif setiap bulan.
Durasi waktu untuk pulih dari bencana tergantung pada penyiapan yang Anda pilih. Batch itu sendiri bersifat agnostik mengenai apakah Anda menggunakan beberapa akun atau satu akun. Dalam konfigurasi aktif-aktif, di mana dua instans Batch menerima lalu lintas secara bersamaan, pemulihan bencana lebih cepat daripada untuk konfigurasi pasif aktif. Konfigurasi mana yang Anda pilih harus didasarkan pada kebutuhan bisnis (wilayah yang berbeda, persyaratan latensi) dan pertimbangan teknis.
Pemulihan bencana satu wilayah
Cara Anda menerapkan pemulihan bencana di Batch sama, baik Anda bekerja di geografi satu wilayah atau multi-wilayah. Satu-satunya perbedaan adalah SKU mana yang Anda gunakan untuk penyimpanan, dan apakah Anda berniat menggunakan akun penyimpanan yang sama atau berbeda di semua wilayah.
Pengujian pemulihan bencana
Anda harus melakukan pengujian pemulihan bencana Anda sendiri dari solusi yang diaktifkan Batch Anda. Ini dianggap sebagai praktik terbaik untuk memungkinkan peralihan yang mudah antara klien dan beban layanan di berbagai wilayah.
Menguji rencana pemulihan bencana Anda untuk Batch dapat sesederhana akun Batch alternatif. Misalnya, Anda dapat mengandalkan satu akun Batch di wilayah tertentu selama satu hari operasional. Kemudian, pada hari berikutnya, Anda dapat beralih ke akun Batch kedua di wilayah yang berbeda. Pemulihan bencana terutama dikelola di sisi klien. Pendekatan beberapa akun untuk pemulihan bencana ini mengurus ekspektasi RTO dan RPO baik di geografi wilayah tunggal atau beberapa wilayah.
Kapasitas dan ketahanan pemulihan bencana proaktif
Microsoft dan pelanggannya beroperasi di bawah model Tanggung Jawab Bersama. Microsoft bertanggung jawab atas ketahanan platform dan infrastructural. Anda bertanggung jawab untuk mengatasi pemulihan bencana untuk layanan tertentu yang Anda sebarkan dan kontrol. Untuk memastikan bahwa pemulihan proaktif:
Anda harus selalu mendahului sekunder. Predeployment sekunder diperlukan karena tidak ada jaminan kapasitas pada saat dampak bagi mereka yang belum mengalokasikan sumber daya tersebut.
Buat sebelumnya semua layanan yang diperlukan di setiap wilayah, seperti akun Batch Anda dan akun penyimpanan terkait. Tidak ada biaya untuk membuat akun baru; biaya bertambah hanya ketika akun digunakan atau saat data disimpan.
Pastikan kuota yang sesuai diatur pada semua langganan sebelumnya, sehingga Anda dapat mengalokasikan jumlah inti yang diperlukan menggunakan akun Batch. Seperti halnya layanan Azure lainnya, ada batasan pada sumber daya tertentu yang terkait dengan layanan Batch. Pembatasan ini banyak berupa kuota default yang diterapkan oleh Azure pada tingkat langganan atau akun. Ingatlah kuota ini saat Anda merancang dan meningkatkan beban kerja Batch Anda.
Catatan
Jika Anda berencana untuk menjalankan beban kerja produksi di Batch, Anda mungkin perlu menambahkan satu atau beberapa kuota di atas default. Untuk menaikkan kuota, Anda dapat meminta kenaikan kuota tanpa biaya. Untuk informasi selengkapnya, lihat Meminta penambahan kuota.
Penyimpanan
Anda harus mengonfigurasi penyimpanan Batch untuk memastikan data dicadangkan lintas wilayah; tanggung jawab pelanggan adalah default. Sebagian besar solusi Batch menggunakan Azure Storage untuk menyimpan file sumber daya dan file output. Misalnya, tugas Batch Anda (termasuk tugas standar, tugas mulai, tugas persiapan kerja, dan tugas pelepasan kerja) biasanya menentukan file sumber daya yang berada di akun penyimpanan. Akun penyimpanan juga menyimpan data yang diproses dan data output apa pun yang dihasilkan. Memahami kemungkinan kehilangan data di seluruh wilayah operasi layanan Anda adalah pertimbangan penting. Anda juga harus mengonfirmasi apakah data dapat ditulis ulang atau baca-saja.
Batch mendukung tipe akun Azure Storage berikut ini:
- Akun tujuan umum v2 (GPv2)
- Akun tujuan umum v1 (GPv1)
- Akun penyimpanan blob (saat ini didukung untuk kumpulan di konfigurasi Komputer Virtual)
Untuk informasi selengkapnya tentang jenis akun Azure Storage, lihat Gambaran umum akun penyimpanan.
Anda dapat mengaitkan akun penyimpanan dengan akun Batch saat membuat akun atau melakukan langkah ini nanti.
Jika Anda menyiapkan akun penyimpanan terpisah untuk setiap wilayah tempat layanan Anda tersedia, Anda harus menggunakan akun penyimpanan zona redundan (ZRS). Gunakan akun penyimpanan geo-zona-redundan (GZRS) jika Anda menggunakan akun penyimpanan yang sama di beberapa wilayah yang dipasangkan. Untuk geografi yang berisi satu wilayah, Anda harus membuat akun penyimpanan zona redundan (ZRS) karena GZRS tidak tersedia.
Perencanaan kapasitas adalah pertimbangan penting lainnya dengan penyimpanan dan harus ditangani secara proaktif. Pertimbangkan persyaratan biaya dan kinerja Anda saat memilih akun penyimpanan. Misalnya, opsi akun penyimpanan GPv2 dan blob mendukung batas kapasitas dan skalabilitas yang lebih besar dibandingkan dengan GPv1. (Hubungi Dukungan Azure untuk meminta peningkatan batas penyimpanan.) Opsi akun ini dapat meningkatkan kinerja solusi Batch yang berisi sejumlah besar tugas paralel yang dibaca dari atau menulis ke akun penyimpanan.
Saat akun penyimpanan ditautkan ke akun Batch, anggap saja sebagai akun autostorage. Akun autostorage diperlukan jika Anda berencana untuk menggunakan kemampuan paket aplikasi, karena digunakan untuk menyimpan paket aplikasi .zip file. Akun autostorage juga dapat digunakan untuk file sumber daya tugas; karena akun autostorage sudah ditautkan ke akun Batch, ini menghindari kebutuhan URL tanda tangan akses bersama (SAS) untuk mengakses file sumber daya.