Keandalan pada Azure Batch

Artikel ini menjelaskan dukungan keandalan di Azure Batch. Ini mencakup cara meningkatkan ketahanan intra-regional dengan menggunakan zona ketersediaan, kumpulan batch, dan simpul komputasi untuk meminimalkan waktu henti dan kehilangan data. Ini juga menautkan ke informasi tentang pemulihan lintas wilayah dan kelangsungan bisnis.

Dukungan zona ketersediaan

Zona ketersediaan adalah grup pusat data yang terpisah secara fisik dalam wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.

Batch mempertahankan paritas dengan Azure dalam mendukung zona ketersediaan.

Prasyarat

• Untuk akun Batch mode langganan pengguna, 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 dalam mendukung zona ketersediaan. 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 locationInfo bidang resourceSku. 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 saat zona tidak aktif

Selama pemadaman zona, simpul-simpul dalam zona tersebut menjadi tidak dapat diakses. 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 kesalahan

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 perlu memperhitungkan setidaknya kegagalan satu zona, kalikan jumlah instans beban kerja puncak dengan faktor zona/(zona-1), atau 3/2. Misalnya, jika beban kerja puncak khas 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 dan komputer virtual (VM) terkait 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 memerlukan setidaknya dua akun Batch, dengan setiap akun 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 merancang solusi yang dapat melakukan failover:

• 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 tepat telah diatur untuk semua akun Batch langganan pengguna, agar dapat mengalokasikan jumlah inti yang diperlukan menggunakan akun Batch.

• Gunakan templat dan/atau skrip untuk mengotomatiskan penyebaran aplikasi di suatu wilayah.

• Selalu perbarui biner aplikasi dan data referensi di semua wilayah. Menjaga agar tetap terkini akan memastikan bahwa wilayah dapat dihubungkan secara 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, pembaruan tersebut harus diunggah ke setiap akun Batch dan dihubungkan dengan pengaturan kumpulan (atau menjadikan versi terbaru sebagai versi default).

• Dalam aplikasi yang memanggil Batch, penyimpanan, dan layanan lainnya, 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 darurat lebih cepat dibandingkan konfigurasi aktif-pasif. 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 adalah sama, baik Anda bekerja di satu wilayah atau di lokasi 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 secara mandiri untuk solusi Anda yang telah diaktifkan Batch. 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 dengan bergantian menggunakan akun Batch. 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 multi-akun untuk pemulihan bencana ini menangani ekspektasi RTO dan RPO baik di wilayah tunggal maupun 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 infrastruktur. Anda bertanggung jawab untuk mengatasi pemulihan bencana untuk layanan tertentu yang Anda sebarkan dan kontrol. Untuk memastikan bahwa pemulihan proaktif:

• Anda harus selalu menyiapkan cadangan terlebih dahulu. Pradeployment sumber daya sekunder diperlukan karena tidak ada jaminan kapasitas pada saat terjadi dampak bagi mereka yang belum mengalokasikan sumber daya semacam itu.

• 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. Banyak dari batas ini adalah kuota default yang diterapkan oleh Azure di tingkat langganan atau akun. Ingatlah kuota ini saat Anda merancang dan meningkatkan beban kerja Batch Anda.

Nota

Jika Anda berencana untuk menjalankan beban kerja produksi di Batch, Anda mungkin perlu meningkatkan satu atau beberapa kuota di atas default. Untuk menaikkan kuota, Anda dapat meminta penambahan kuota tanpa biaya. Untuk informasi selengkapnya, lihat Meminta penambahan kuota.

Storage

Anda harus mengonfigurasi penyimpanan Batch agar data dicadangkan antar wilayah; tanggung jawab ini adalah bawaan pelanggan. Sebagian besar solusi Batch menggunakan Azure Storage untuk menyimpan file sumber daya dan file keluaran. Misalnya, tugas Batch Anda (termasuk tugas standar, tugas awal, tugas persiapan pekerjaan, dan tugas pelepasan pekerjaan) biasanya menentukan file sumber daya yang berada di dalam 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-tipe akun Penyimpanan Azure berikut:

• Akun tujuan umum v2 (GPv2)
• Akun tujuan umum v1 (GPv1)
• Akun penyimpanan Blob (saat ini didukung untuk kumpulan dalam konfigurasi Mesin Virtual)

Untuk informasi lebih lanjut tentang akun penyimpanan, lihat Ikhtisar akun penyimpanan Azure.

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 kapasitas dan batas skalabilitas yang lebih besar dibandingkan dengan GPv1. (Hubungi Dukungan Azure untuk meminta peningkatan batas penyimpanan.) Opsi akun ini dapat meningkatkan performa solusi Batch yang berisi sejumlah besar tugas paralel yang membaca 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.

Langkah selanjutnya

• Keandalan di Azure