Bagikan melalui


Praktik terbaik Azure Batch

Artikel ini membahas praktik terbaik dan tips berguna untuk menggunakan layanan Azure Batch secara efektif. Tips ini dapat membantu Anda meningkatkan performa dan menghindari kekeliruan desain dalam solusi Azure Batch Anda.

Tip

Untuk panduan tentang keamanan di Azure Batch, lihat Praktik terbaik keamanan dan kepatuhan Batch.

Kumpulan

Kumpulan adalah sumber daya komputasi untuk menjalankan pekerjaan pada layanan Batch. Bagian berikut memberikan rekomendasi untuk bekerja dengan kumpulan Batch.

Konfigurasi dan penamaan kumpulan

  • Mode alokasi kumpulan: Saat membuat akun Batch, Anda dapat memilih antara dua mode alokasi kumpulan: Layanan batch atau langganan pengguna. Untuk sebagian besar kasus, Anda harus menggunakan mode layanan Batch default, tempat kumpulan dialokasikan di belakang layar dalam langganan yang dikelola Batch. Dalam mode langganan pengguna alternatif, komputer virtual Batch dan sumber daya lain dibuat langsung di langganan Anda saat kumpulan dibuat. Akun langganan pengguna terutama digunakan untuk mengaktifkan subset skenario yang kecil tapi penting. Untuk informasi selengkapnya, lihat konfigurasi untuk mode langganan pengguna.

  • classic atau simplified mode komunikasi simpul: Kumpulan dapat dikonfigurasi dalam salah satu dari dua mode komunikasi simpul, klasik atau disederhanakan. Dalam model komunikasi simpul klasik, layanan Batch memulai komunikasi ke simpul komputasi, dan simpul komputasi juga memerlukan komunikasi ke Azure Storage. Dalam model komunikasi simpul yang disederhanakan, simpul komputasi memulai komunikasi dengan layanan Batch. Karena berkurangnya cakupan koneksi masuk/keluar yang diperlukan, dan tidak memerlukan akses keluar Azure Storage untuk operasi garis besar, rekomendasinya adalah menggunakan model komunikasi simpul yang disederhanakan. Beberapa peningkatan di masa mendatang pada layanan Batch juga akan memerlukan model komunikasi simpul yang disederhanakan. Model komunikasi node klasik akan dihentikan pada 31 Maret 2026.

  • Pertimbangan waktu proses pekerjaan dan tugas: Jika Anda memiliki pekerjaan yang terutama terdiri dari tugas yang berjalan singkat, dan jumlah total tugas yang diharapkan kecil, sehingga durasi pekerjaan yang diharapkan secara keseluruhan tidak lama, jangan alokasikan kumpulan baru untuk setiap pekerjaan. Waktu alokasi simpul akan mengurangi durasi pekerjaan.

  • Beberapa simpul komputasi: Simpul individual tidak dijamin selalu tersedia. Meskipun jarang terjadi, kegagalan perangkat keras, pembaruan sistem operasi, dan sejumlah masalah lainnya dapat menyebabkan simpul individual offline. Jika beban kerja Batch Anda memerlukan kemajuan deterministik dan terjamin, Anda harus mengalokasikan kumpulan dengan beberapa simpul.

  • Gambar dengan tanggal akhir masa pakai (EOL) yang akan datang: Sangat disarankan untuk menghindari gambar dengan tanggal akhir masa pakai (EOL) dukungan Batch yang akan datang. Tanggal ini dapat ditemukan melalui ListSupportedImages API, PowerShell, atau Azure CLI. Anda bertanggung jawab untuk secara berkala me-refresh tampilan Tanggal EOL yang berkaitan dengan kumpulan Anda dan memigrasikan beban kerja Anda sebelum tanggal EOL terjadi. Jika Anda menggunakan gambar kustom dengan agen simpul tertentu, pastikan bahwa Anda mengikuti tanggal akhir masa pakai dukungan Batch untuk gambar dari mana gambar kustom Anda berasal atau disejajarkan. Gambar tanpa tanggal yang ditentukan batchSupportEndOfLife menunjukkan bahwa tanggal seperti itu belum ditentukan oleh layanan Batch. Tidak adanya tanggal tidak menunjukkan bahwa gambar masing-masing akan didukung tanpa batas waktu. Tanggal EOL dapat ditambahkan atau diperbarui di masa mendatang kapan saja.

  • SKU VM dengan tanggal akhir masa pakai (EOL) yang akan datang: Seperti halnya gambar VM, SKU VM atau keluarga juga dapat mencapai akhir masa pakai dukungan Batch (EOL). Tanggal ini dapat ditemukan melalui ListSupportedVirtualMachineSkus API, PowerShell, atau Azure CLI. Rencanakan migrasi beban kerja Anda ke SKU VM non-EOL dengan membuat kumpulan baru dengan SKU VM yang didukung yang sesuai. Tidak adanya tanggal terkait batchSupportEndOfLife untuk SKU VM tidak menunjukkan bahwa SKU VM tertentu akan didukung tanpa batas waktu. Tanggal EOL dapat ditambahkan atau diperbarui di masa mendatang kapan saja.

  • Nama sumber daya unik: Sumber daya Batch (pekerjaan, kumpulan, dll.) sering datang dan pergi dari waktu ke waktu. Misalnya, Anda dapat membuat kumpulan pada hari Senin, menghapusnya pada hari Selasa, dan kemudian membuat kumpulan lain yang mirip pada hari Kamis. Setiap sumber daya baru yang Anda buat harus diberi nama unik yang belum pernah Anda gunakan sebelumnya. Anda dapat membuat keunikan dengan menggunakan GUID (baik sebagai seluruh nama sumber daya, atau sebagai bagian darinya) atau dengan menyematkan tanggal dan waktu sumber daya dibuat dalam nama sumber daya. Batch mendukung DisplayName, yang dapat memberikan sumber daya nama yang lebih mudah dibaca bahkan jika ID sumber daya yang sebenarnya adalah sesuatu yang tidak ramah manusia. Menggunakan nama unik memudahkan Anda untuk membedakan sumber daya tertentu yang melakukan sesuatu di log dan metrik. Ini juga menghapus ambiguitas jika Anda harus mengajukan kasus dukungan untuk sumber daya.

  • Kontinuitas selama pemeliharaan dan kegagalan kumpulan: Sebaiknya tugas Anda menggunakan kumpulan secara dinamis. Jika pekerjaan Anda menggunakan kumpulan yang sama untuk semuanya, ada kemungkinan pekerjaan Anda tidak akan berjalan jika ada yang salah dengan kumpulan. Prinsip ini sangat penting untuk beban kerja yang sensitif terhadap waktu. Misalnya, pilih atau buat kumpulan secara dinamis saat Anda menjadwalkan setiap pekerjaan, atau memiliki cara untuk mengambil alih nama kumpulan sehingga Anda dapat melewati kumpulan yang tidak sehat.

  • Kelangsungan bisnis selama pemeliharaan dan kegagalan kumpulan: Ada banyak alasan mengapa kumpulan mungkin tidak tumbuh sesuai ukuran yang Anda inginkan, seperti kesalahan internal atau kendala kapasitas. Pastikan Anda dapat menargetkan ulang pekerjaan di kumpulan yang berbeda (mungkin dengan ukuran VM yang berbeda menggunakan UpdateJob) jika perlu. Hindari mengandalkan ID kumpulan statik dengan harapan bahwa ia tidak akan pernah dihapus dan tidak pernah berubah.

Keamanan kumpulan

Batas isolasi

Untuk tujuan isolasi, apabila skenario Anda mengharuskan pengisolasian pekerjaan atau tugas dari satu sama lain, lakukan dengan menempatkannya di kumpulan terpisah. Kumpulan adalah batas isolasi keamanan di Batch, dan secara default, dua kumpulan tidak terlihat atau dapat berkomunikasi satu sama lain. Hindari menggunakan akun Batch terpisah sebagai sarana isolasi keamanan, kecuali lingkungan yang lebih besar tempat akun Batch beroperasi memerlukan isolasi.

Pembaruan Agen Node Batch

Agen simpul batch tidak ditingkatkan secara otomatis untuk kumpulan yang memiliki simpul komputasi nonzero. Untuk memastikan kumpulan Batch Anda menerima perbaikan keamanan terbaru dan pembaruan untuk agen simpul Batch, Anda perlu mengubah ukuran kumpulan menjadi nol simpul komputasi atau membuat ulang kumpulan. Disarankan untuk memantau catatan rilis Agen Simpul Batch untuk memahami perubahan pada versi agen simpul Batch baru. Memeriksa pembaruan secara teratur saat dirilis memungkinkan Anda merencanakan peningkatan ke versi agen terbaru.

Sebelum membuat ulang atau mengubah ukuran kumpulan, Anda harus mengunduh log agen simpul apa pun untuk tujuan penelusuran kesalahan jika Anda mengalami masalah dengan kumpulan Batch atau simpul komputasi Anda. Proses ini dibahas lebih lanjut di bagian Simpul .

Catatan

Untuk panduan umum mengenai keamanan di Azure Batch, lihat Praktik terbaik keamanan dan kepatuhan Batch.

Pembaruan sistem operasi

Disarankan agar gambar VM yang dipilih untuk kumpulan Batch harus diperbarui dengan penerbit terbaru yang menyediakan pembaruan keamanan. Beberapa gambar dapat melakukan pembaruan paket otomatis saat boot (atau segera setelahnya), yang dapat mengganggu tindakan tertentu yang diarahkan pengguna seperti mengambil pembaruan repositori paket (misalnya, apt update) atau menginstal paket selama tindakan seperti StartTask.

Disarankan untuk mengaktifkan peningkatan OS Otomatis untuk kumpulan Batch, yang memungkinkan infrastruktur Azure yang mendasar untuk mengoordinasikan pembaruan di seluruh kumpulan. Opsi ini dapat dikonfigurasi agar tidak mengganggu eksekusi tugas. Peningkatan OS otomatis tidak mendukung semua sistem operasi yang didukung Batch. Untuk informasi selengkapnya, lihat Matriks Dukungan peningkatan OS Otomatis Virtual Machine Scale Sets. Untuk sistem operasi Windows, pastikan Anda tidak mengaktifkan properti virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates saat menggunakan peningkatan OS Otomatis pada kumpulan Batch.

Azure Batch tidak memverifikasi atau menjamin bahwa gambar yang diizinkan untuk digunakan dengan layanan memiliki pembaruan keamanan terbaru. Pembaruan pada gambar berada di bawah ringkasan penerbit gambar, dan bukan azure Batch. Untuk gambar tertentu yang diterbitkan di bawah microsoft-azure-batch, tidak ada jaminan bahwa gambar-gambar ini tetap diperbarui dengan gambar turunan upstream mereka.

Masa pakai dan tagihan kumpulan

Masa pakai kumpulan dapat bervariasi tergantung pada metode alokasi dan opsi yang diterapkan pada konfigurasi kumpulan. Kumpulan dapat memiliki masa pakai yang berubah-ubah dan jumlah simpul komputasi yang berbeda-beda kapan saja. Anda bertanggung jawab untuk mengelola simpul komputasi di kumpulan baik secara eksplisit, atau melalui fitur yang disediakan oleh layanan (autoscale atau autopool).

  • Pembuatan ulang kumpulan: Hindari menghapus dan membuat ulang kumpulan setiap hari. Sebagai gantinya, buat kumpulan baru, kemudian perbarui pekerjaan Anda yang sudah ada agar mengarah ke kumpulan baru. Setelah semua tugas dipindahkan ke kumpulan baru, lalu hapus kumpulan lama.

  • Efisiensi dan penagihan kumpulan: Batch itu sendiri tidak dikenakan biaya tambahan. Namun, Anda dikenakan biaya untuk sumber daya Azure yang digunakan, seperti komputasi, penyimpanan, jaringan, dan sumber daya lain yang mungkin diperlukan untuk beban kerja Batch Anda. Anda ditagih untuk setiap simpul komputasi di kumpulan, terlepas dari statusnya. Untuk informasi selengkapnya, lihat Analisis biaya dan anggaran untuk Azure Batch.

  • Disk OS sementara: Kumpulan Konfigurasi Mesin Virtual dapat menggunakan disk OS sementara, yang membuat disk OS pada cache mesin virtual atau SSD sementara, untuk menghindari biaya tambahan terkait dengan disk terkelola.

Kegagalan alokasi kumpulan

Kegagalan alokasi kumpulan dapat terjadi kapan saja selama alokasi pertama atau perubahan ukuran berikutnya. Kegagalan ini dapat disebabkan oleh kelelahan kapasitas sementara di suatu wilayah atau kegagalan di layanan Azure lainnya yang diandalkan Batch. Kuota inti Anda bukan jaminan melainkan batas.

Waktu henti yang tidak direncanakan

Mungkin saja kumpulan Batch mengalami kejadian waktu henti di Azure. Memahami bahwa masalah dapat muncul dan Anda harus mengembangkan alur kerja Anda agar tahan terhadap eksekusi ulang. Jika simpul gagal, Batch secara otomatis mencoba memulihkan simpul komputasi ini atas nama Anda. Pemulihan ini dapat memicu penjadwalan ulang tugas yang sedang berjalan pada simpul yang dipulihkan atau pada simpul lain yang tersedia. Untuk mempelajari selengkapnya tentang tugas yang terputus, lihat Mendesain percobaan ulang.

Kumpulan gambar kustom

Saat membuat kumpulan Azure Batch menggunakan Konfigurasi Komputer Virtual, Anda menentukan gambar komputer virtual yang menyediakan sistem operasi untuk setiap simpul komputasi di kumpulan. Anda dapat membuat kumpulan dengan gambar Azure Marketplace yang didukung, atau Anda dapat membuat gambar kustom dengan gambar Azure Compute Gallery. Meskipun Anda juga dapat menggunakan gambar terkelola untuk membuat kumpulan gambar kustom, sebaiknya buat gambar khusus menggunakan Azure Compute Gallery jika memungkinkan. Menggunakan Azure Compute Gallery membantu Anda menyediakan kumpulan lebih cepat, menskalakan jumlah VM yang lebih besar, dan meningkatkan keandalan saat menyediakan VM.

Gambar pihak ketiga

Kumpulan dapat dibuat menggunakan gambar pihak ketiga yang diterbitkan ke Marketplace Azure. Dengan akun Batch mode langganan pengguna, Anda mungkin melihat kesalahan "Alokasi gagal karena pemeriksaan kelayakan pembelian pasar" saat membuat kumpulan dengan gambar pihak ketiga tertentu. Untuk mengatasi kesalahan ini, terima ketentuan yang ditetapkan oleh penerbit gambar. Anda bisa melakukannya dengan menggunakan Azure PowerShell atau Azure CLI.

Kumpulan kontainer

Saat Anda membuat kumpulan Batch dengan jaringan virtual, mungkin ada efek samping interaksi antara jaringan virtual yang ditentukan dan jembatan Docker default. Docker, secara default, akan membuat jembatan jaringan dengan spesifikasi subnet .172.17.0.0/16 Pastikan bahwa tidak ada rentang IP yang bertentangan antara jembatan jaringan Docker dan jaringan virtual Anda.

Docker Hub membatasi jumlah penarikan gambar. Pastikan beban kerja Anda tidak melebihi batas tarif yang diterbitkan untuk gambar berbasis Docker Hub. Disarankan untuk menggunakan Azure Container Registry secara langsung atau memanfaatkan cache Artefak di ACR.

Dependensi wilayah Azure

Anda tidak boleh mengandalkan satu wilayah Azure jika Anda memiliki beban kerja yang sensitif terhadap waktu atau produksi. Meskipun jarang terjadi, ada masalah yang dapat memengaruhi seluruh wilayah. Misalnya, jika pemrosesan Anda perlu dimulai pada waktu tertentu, pertimbangkan untuk menaikkan skala kumpulan di wilayah utama Anda jauh sebelum waktu mulai Anda. Jika skala kumpulan tersebut gagal, Anda dapat kembali untuk menaikkan skala kumpulan di wilayah cadangan (atau beberapa wilayah).

Kumpulan di beberapa akun di wilayah berbeda menyediakan cadangan yang siap dan mudah diakses jika terjadi kesalahan dengan kumpulan lain. Untuk informasi selengkapnya, lihat Mendesain aplikasi Anda untuk ketersediaan tinggi.

Pekerjaan

Pekerjaan adalah kontainer yang dirancang untuk menampung ratusan, ribuan, atau bahkan jutaan tugas. Ikuti panduan berikut saat membuat pekerjaan.

Lebih sedikit pekerjaan, lebih banyak tugas

Menggunakan tugas untuk menjalankan satu tugas tidaklah efisien. Misalnya, lebih efisien untuk menggunakan satu pekerjaan yang berisi 1.000 tugas daripada membuat 100 pekerjaan yang masing-masing berisi 10 tugas. Jika Anda menggunakan 1.000 pekerjaan, masing-masing dengan satu tugas yang akan menjadi pendekatan paling tidak efisien, paling lambat, dan paling mahal untuk diambil.

Hindari merancang solusi Batch yang membutuhkan ribuan pekerjaan yang aktif secara bersamaan. Tidak ada kuota untuk tugas, jadi menjalankan banyak tugas di bawah pekerjaan sesekali secara efisien menggunakan kuota jadwal pekerjaan dan pekerjaan Anda.

Masa pakai pekerjaan

Pekerjaan Batch memiliki masa pakai yang tidak terbatas sampai dihapus dari sistem. Statusnya menunjukkan apakah ia dapat menerima lebih banyak tugas untuk penjadwalan atau tidak.

Pekerjaan tidak secara otomatis berpindah ke status selesai kecuali dihentikan secara eksplisit. Tindakan ini dapat dipicu secara otomatis melalui properti onAllTasksComplete atau maxWallClockTime.

Ada pekerjaan aktif default dan kuota jadwal pekerjaan. Pekerjaan dan jadwal pekerjaan dalam status selesai tidak dihitung dalam kuota ini.

Hapus pekerjaan saat tidak lagi diperlukan, bahkan jika dalam status selesai. Meskipun pekerjaan yang selesai tidak dihitung dalam kuota pekerjaan aktif, akan bermanfaat untuk membersihkan pekerjaan yang telah selesai secara berkala. Misalnya, mencantumkan pekerjaan akan lebih efisien ketika jumlah total pekerjaan adalah set yang lebih kecil (bahkan jika filter yang tepat diterapkan pada permintaan).

Tugas

Tugas adalah unit kerja individu yang terdiri dari pekerjaan. Tugas dikirimkan oleh pengguna dan dijadwalkan oleh Batch ke simpul komputasi. Bagian berikut ini menyediakan saran untuk mendesain tugas Anda untuk menangani masalah dan berkinerja efisien.

Menyimpan data tugas

Simpul komputasi pada dasarnya bersifat sementara. Fitur Batch seperti autopool dan autoscale dapat memudahkan simpul untuk menghilang. Ketika simpul meninggalkan kumpulan (karena perubahan ukuran atau penghapusan kumpulan), semua file di simpul tersebut juga dihapus. Karena perilaku ini, tugas harus memindahkan outputnya dari simpul yang dijalankannya, dan ke penyimpanan tahan lama sebelum selesai. Demikian pula, jika suatu tugas gagal, tugas tersebut harus memindahkan log yang diperlukan untuk mendiagnosis kegagalan tersebut ke penyimpanan tahan lama.

Batch telah mengintegrasikan dukungan Azure Storage untuk mengunggah data melalui OutputFiles, dan dengan berbagai sistem file bersama, atau Anda dapat melakukan unggahan sendiri dalam tugas Anda.

Mengelola masa pakai tugas

Hapus tugas saat tidak lagi diperlukan, atau atur batasan tugas retentionTime . Jika retentionTime diatur, Batch secara otomatis membersihkan ruang disk yang digunakan oleh tugas ketika retentionTime kedaluwarsa.

Menghapus tugas menyelesaikan dua hal:

  • Memastikan bahwa Anda tidak memiliki build-up tugas dalam pekerjaan. Tindakan ini akan membantu menghindari kesulitan dalam menemukan tugas yang Anda minati karena Anda harus memfilter melalui tugas Selesai.
  • Membersihkan data tugas yang sesuai pada simpul (yang disediakan retentionTime belum terpukul). Tindakan ini membantu memastikan bahwa simpul Anda tidak terisi dengan data tugas dan kehabisan ruang disk.

Catatan

Untuk tugas yang baru saja dikirimkan ke Batch, panggilan API DeleteTask membutuhkan waktu hingga 10 menit untuk diterapkan. Sebelum berlaku, tugas lain mungkin dicegah agar tidak dijadwalkan. Ini karena Batch Scheduler masih mencoba menjadwalkan tugas yang baru saja dihapus. Jika Anda ingin menghapus satu tugas segera setelah dikirimkan, silakan hentikan tugas sebagai gantinya (karena permintaan tugas penghentian akan segera berlaku). Lalu hapus tugas 10 menit kemudian.

Kirimkan banyak tugas dalam koleksi

Tugas dapat dikirimkan secara individual atau dalam koleksi. Kirim tugas dalam koleksi hingga 100 sekaligus saat melakukan pengiriman tugas secara massal untuk mengurangi overhead dan waktu pengiriman.

Atur tugas maksimal per simpul dengan tepat

Batch mendukung tugas oversubscribing pada simpul (menjalankan lebih banyak tugas daripada simpul memiliki inti). Terserah Anda untuk memastikan bahwa tugas Anda berukuran tepat untuk simpul di kumpulan Anda. Misalnya, Anda mungkin mengalami penurunan pengalaman jika mencoba menjadwalkan delapan tugas yang masing-masing mengonsumsi penggunaan CPU 25% ke satu simpul (dalam satu kumpulan dengan taskSlotsPerNode = 8).

Desain untuk percobaan ulang dan eksekusi ulang

Tugas dapat dicoba secara otomatis oleh Batch. Ada dua jenis percobaan ulang: dikontrol oleh pengguna dan internal. Percobaan ulang yang dikontrol pengguna ditentukan oleh maxTaskRetryCount tugas. Ketika program yang ditentukan dalam tugas keluar dengan kode keluar bukan nol, tugas dicoba kembali hingga nilai maxTaskRetryCount.

Meskipun jarang, tugas dapat dicoba ulang secara internal karena kegagalan pada simpul komputasi, seperti tidak dapat memperbarui status internal atau kegagalan pada simpul saat tugas sedang berjalan. Tugas akan dicoba ulang pada simpul komputasi yang sama, jika memungkinkan, hingga batas internal sebelum menyerah pada tugas dan menunda tugas untuk dijadwalkan ulang oleh Batch, berpotensi pada simpul komputasi yang berbeda.

Tidak ada perbedaan desain saat menjalankan tugas Anda pada node khusus atau node Spot. Apakah tugas didahulukan saat berjalan pada node Spot atau terganggu karena kegagalan pada node khusus, kedua situasi tersebut dimitigasi dengan merancang tugas untuk menahan kegagalan.

Membangun tugas yang tahan lama

Tugas harus dirancang untuk menahan kegagalan dan mengakomodasi percobaan kembali. Prinsip ini sangat penting untuk tugas yang berjalan lama. Pastikan tugas Anda menghasilkan hasil tunggal yang sama meskipun dijalankan lebih dari sekali. Salah satu cara untuk mencapai hasil ini adalah dengan membuat tugas Anda "pencarian tujuan." Cara lain adalah memastikan tugas Anda idempogen (tugas akan memiliki hasil yang sama tidak peduli berapa kali tugas dijalankan).

Contoh umum adalah tugas untuk menyalin file ke simpul komputasi. Pendekatan sederhana adalah tugas yang menyalin semua file yang ditentukan setiap kali dijalankan, yang tidak efisien dan tidak dibangun untuk menahan kegagalan. Sebagai gantinya, buat tugas untuk memastikan file berada di simpul komputasi; tugas yang tidak menyalin ulang file yang sudah ada. Dengan cara ini, tugas melanjutkan dari bagian yang ditinggalkannya jika terputus.

Hindari waktu eksekusi yang singkat

Tugas yang hanya berjalan selama satu hingga dua detik tidak ideal. Cobalah untuk melakukan banyak pekerjaan dalam tugas individu (minimal 10 detik, hingga berjam-jam atau berhari-hari). Jika setiap tugas dijalankan selama satu menit (atau lebih), maka biaya tambahan penjadwalan sebagai bagian dari waktu komputasi keseluruhan kecil.

Gunakan cakupan kumpulan untuk tugas-tugas singkat pada simpul Windows

Saat menjadwalkan tugas di simpul Batch, Anda dapat memilih apakah akan menjalankannya dengan cakupan tugas atau cakupan kumpulan. Jika tugas hanya akan berjalan untuk waktu yang singkat, cakupan tugas bisa tidak efisien karena sumber daya yang diperlukan untuk membuat akun autouser untuk tugas tersebut. Untuk efisiensi yang lebih besar, pertimbangkan untuk mengatur tugas-tugas ini ke cakupan kumpulan. Untuk informasi selengkapnya, lihat Menjalankan tugas sebagai autouser dengan cakupan kumpulan.

Simpul

Simpul komputasi adalah komputer virtual (VM) Azure atau VM layanan awan yang didedikasikan untuk memproses sebagian beban kerja aplikasi Anda. Ikuti panduan ini saat bekerja dengan simpul.

Memulai tugas: masa pakai dan idempotency

Seperti halnya tugas lain, tugas mulai simpul harus idempotoen. Tugas mulai dijalankan ulang saat simpul komputasi dimulai ulang atau saat agen Batch dimulai ulang. Tugas idempoten hanyalah tugas yang menghasilkan hasil yang konsisten saat dijalankan beberapa kali.

Tugas mulai tidak boleh berjalan lama atau digabungkan dengan masa pakai simpul komputasi. Jika Anda perlu memulai program yang bersifat layanan atau seperti layanan, buat tugas mulai yang memungkinkan program ini dimulai dan dikelola oleh fasilitas sistem operasi seperti systemd di Linux atau Windows Services. Tugas mulai masih harus dibangun sebagai idempotomatis sehingga eksekusi tugas mulai berikutnya ditangani dengan benar jika program ini sebelumnya diinstal sebagai layanan.

Tip

Ketika Batch menjalankan ulang tugas mulai Anda, Batch akan mencoba menghapus direktori tugas mulai dan membuatnya lagi. Jika Batch gagal membuat ulang direktori tugas mulai, maka simpul komputasi akan gagal meluncurkan tugas mulai.

Layanan ini tidak boleh mengambil kunci file pada file apa pun di direktori yang dikelola Batch pada simpul, karena jika tidak, Batch tidak dapat menghapus direktori tersebut karena kunci file. Misalnya, alih-alih mengonfigurasi peluncuran layanan langsung dari direktori kerja tugas awal, salin file di tempat lain dengan cara yang idempotik. Kemudian pasang layanan dari lokasi tersebut menggunakan fasilitas sistem operasi.

Simpul terisolasi

Pertimbangkan untuk menggunakan ukuran komputer virtual yang terisolasi untuk beban kerja dengan persyaratan kepatuhan atau peraturan. Ukuran terisolasi yang didukung dalam mode konfigurasi komputer virtual meliputi Standard_E80ids_v4, Standard_M128ms, Standard_F72s_v2, Standard_G5, Standard_GS5, dan Standard_E64i_v3. Untuk informasi selengkapnya tentang ukuran komputer virtual yang terisolasi, lihat Isolasi komputer virtual di Azure.

Hindari membuat persimpangan direktori di Windows

Persimpangan direktori, kadang-kadang disebut direktori tautan keras, sulit untuk ditangani selama pembersihan tugas dan pekerjaan. Gunakan symlink (tautan lunak) daripada tautan keras.

Disk sementara dan AZ_BATCH_NODE_ROOT_DIR

Batch bergantung pada disk sementara VM, untuk ukuran VM yang kompatibel dengan Batch, untuk menyimpan metadata yang terkait dengan eksekusi tugas bersama dengan artefak dari setiap eksekusi tugas pada disk sementara ini. Contoh titik atau direktori pemasangan disk sementara ini adalah: /mnt/batch, , /mnt/resource/batchdan D:\batch\tasks. Mengganti, melepas, menyimpulkan, symlinking, atau mengalihkan titik pemasangan dan direktori ini atau direktori induk mana pun tidak didukung dan dapat menyebabkan ketidakstabilan. Jika Anda memerlukan lebih banyak ruang disk, pertimbangkan untuk menggunakan ukuran VM atau keluarga yang memiliki ruang disk sementara yang memenuhi kebutuhan Anda atau melampirkan disk data. Untuk informasi selengkapnya, lihat bagian berikutnya tentang melampirkan dan menyiapkan disk data untuk simpul komputasi.

Melampirkan dan menyiapkan disk data

Setiap simpul komputasi individu memiliki spesifikasi disk data yang sama persis yang dilampirkan jika ditentukan sebagai bagian dari instans kumpulan Batch. Hanya disk data baru yang dapat dilampirkan ke kumpulan Batch. Disk data yang dilampirkan ke simpul komputasi ini tidak dipartisi, diformat, atau dipasang secara otomatis. Anda bertanggung jawab untuk melakukan operasi ini sebagai bagian dari tugas mulai Anda. Tugas mulai ini harus dibuat agar idempogen. Eksekusi ulang tugas mulai pada simpul komputasi dimungkinkan. Jika tugas mulai tidak idempotensi, potensi kehilangan data dapat terjadi pada disk data.

Tip

Saat memasang disk data di Linux, jika menyarangkan titik pemasangan disk di bawah titik pemasangan sementara Azure seperti /mnt atau /mnt/resource, perawatan harus dilakukan sedih sehingga tidak ada balapan dependensi yang diperkenalkan. Misalnya, jika pemasangan ini secara otomatis dilakukan oleh OS, mungkin ada perlombaan antara disk sementara yang dipasang dan disk data Anda dipasang di bawah induk. Langkah-langkah harus diambil untuk memastikan bahwa dependensi yang sesuai diberlakukan oleh fasilitas yang tersedia seperti systemd atau menukar pemasangan disk data ke tugas mulai sebagai bagian dari skrip persiapan disk data idempogen Anda.

Menyiapkan disk data di kumpulan Linux Batch

Disk data Azure di Linux disajikan sebagai perangkat blok dan diberi pengidentifikasi umum sd[X] . Anda tidak boleh mengandalkan penugasan statis sd[X] karena label ini ditetapkan secara dinamis pada waktu boot dan tidak dijamin konsisten antara boot pertama dan berikutnya. Anda harus mengidentifikasi disk terlampir Anda melalui pemetaan yang disajikan di /dev/disk/azure/scsi1/. Misalnya, jika Anda menentukan LUN 0 untuk disk data Anda di ADDPool API, maka disk ini akan bermanifestasi sebagai /dev/disk/azure/scsi1/lun0. Sebagai contoh, jika Anda mencantumkan direktori ini, Anda berpotensi melihat:

user@host:~$ ls -l /dev/disk/azure/scsi1/
total 0
lrwxrwxrwx 1 root root 12 Oct 31 15:16 lun0 -> ../../../sdc

Tidak perlu menerjemahkan referensi kembali ke sd[X] pemetaan dalam skrip persiapan Anda, sebagai gantinya, lihat perangkat secara langsung. Dalam contoh ini, perangkat ini adalah /dev/disk/azure/scsi1/lun0. Anda dapat memberikan ID ini langsung ke fdisk, mkfs, dan alat lain yang diperlukan untuk alur kerja Anda. Atau, Anda dapat menggunakan lsblk dengan blkid untuk memetakan UUID untuk disk.

Untuk informasi selengkapnya tentang disk data Azure di Linux, termasuk metode alternatif untuk menemukan disk dan /etc/fstab opsi data, lihat artikel ini. Pastikan bahwa tidak ada dependensi atau balapan seperti yang dijelaskan oleh catatan Tip sebelum mempromosikan metode Anda ke dalam penggunaan produksi.

Menyiapkan disk data di kumpulan Windows Batch

Disk data Azure yang dilampirkan ke simpul komputasi Batch Windows disajikan tanpa partisi dan tidak diformat. Anda perlu menghitung disk dengan RAW partisi untuk bertindak sebagai bagian dari tugas mulai Anda. Informasi ini dapat diambil menggunakan Get-Disk cmdlet PowerShell. Sebagai contoh, Anda berpotensi melihat:

PS C:\Windows\system32> Get-Disk

Number Friendly Name Serial Number                    HealthStatus         OperationalStatus      Total Size Partition
                                                                                                             Style
------ ------------- -------------                    ------------         -----------------      ---------- ----------
0      Virtual HD                                     Healthy              Online                      30 GB MBR
1      Virtual HD                                     Healthy              Online                      32 GB MBR
2      Msft Virtu...                                  Healthy              Online                      64 GB RAW

Di mana disk nomor 2 adalah disk data yang tidak diinisialisasi yang terpasang pada simpul komputasi ini. Disk ini kemudian dapat diinisialisasi, dipartisi, dan diformat sesuai kebutuhan untuk alur kerja Anda.

Untuk informasi selengkapnya tentang disk data Azure di Windows, termasuk contoh skrip PowerShell, lihat artikel ini. Pastikan sampel skrip divalidasi untuk idempotensi sebelum promosi ke dalam penggunaan produksi.

Mengumpulkan log agen Batch

Jika Anda melihat masalah yang melibatkan perilaku simpul atau tugas yang berjalan pada simpul, kumpulkan log agen Batch sebelum membatalkan alokasi simpul yang dimaksud. Log agen Batch dapat dikumpulkan menggunakan API log layanan Upload Batch. Log ini dapat disediakan sebagai bagian dari tiket dukungan ke Microsoft dan akan membantu pemecahan masalah dan resolusi masalah.

Batch API

Kegagalan Waktu Habis

Kegagalan waktu habis tidak selalu menunjukkan bahwa layanan gagal memproses permintaan. Ketika kegagalan waktu habis terjadi, Anda harus mencoba kembali operasi atau mengambil status sumber daya, sebagaimana mestinya untuk situasi tersebut, untuk memverifikasi status apakah operasi berhasil atau gagal.

Konektivitas

Tinjau panduan berikut terkait konektivitas di solusi Batch Anda.

Kelompok Keamanan Jaringan (NSG) dan Rute yang Ditentukan Pengguna (UDR)

Saat menyediakan kumpulan Batch di jaringan virtual, pastikan Anda mengikuti pedoman dengan cermat mengenai penggunaan BatchNodeManagement.tag layanan wilayah , port, protokol, dan arah aturan. Penggunaan tag layanan sangat disarankan; jangan gunakan alamat IP layanan Batch yang mendasar karena dapat berubah dari waktu ke waktu. Menggunakan alamat IP layanan Batch secara langsung dapat menyebabkan ketidakstabilan, gangguan, atau pemadaman untuk kumpulan Batch Anda.

Untuk Rute yang Ditentukan Pengguna (UDR), disarankan untuk menggunakan BatchNodeManagement.tag layanan wilayah alih-alih alamat IP layanan Batch karena dapat berubah dari waktu ke waktu.

Mematuhi DNS

Pastikan sistem Anda menghormati DNS Time-to-Live (TTL) untuk URL layanan akun Batch Anda. Selain itu, pastikan bahwa klien layanan Batch Anda dan mekanisme konektivitas lainnya ke layanan Batch tidak bergantung pada alamat IP.

Setiap permintaan HTTP dengan kode status tingkat 5xx bersama dengan header "Koneksi: tutup" dalam respons memerlukan penyesuaian perilaku klien layanan Batch Anda. Klien layanan Batch Anda harus mengamati rekomendasi dengan menutup koneksi yang ada, menyelesaikan ulang DNS untuk URL layanan akun Batch, dan mencoba mengikuti permintaan pada koneksi baru.

Percobaan kembali permintaan secara otomatis

Pastikan klien layanan Batch Anda memiliki kebijakan percobaan kembali yang sesuai untuk secara otomatis mencoba ulang permintaan Anda, bahkan selama operasi normal dan tidak secara eksklusif selama periode waktu pemeliharaan layanan. Kebijakan percobaan kembali ini harus berlangsung dalam interval setidaknya 5 menit. Kemampuan percobaan kembali otomatis disediakan dengan berbagai SDK Batch, seperti kelas .NET RetryPolicyProvider.

Alamat IP publik statik

Biasanya, mesin virtual di kumpulan Batch diakses melalui alamat IP publik yang dapat berubah selama masa pakai kumpulan. Sifat dinamis ini dapat menyulitkan untuk berinteraksi dengan database atau layanan eksternal lainnya yang membatasi akses ke alamat IP tertentu. Untuk mengatasi masalah ini, Anda dapat membuat kumpulan menggunakan sekumpulan alamat IP publik statis yang Anda kontrol. Untuk informasi selengkapnya, lihat Membuat kumpulan Azure Batch dengan alamat IP publik tertentu.

Dependensi yang mendasari simpul Batch

Pertimbangkan dependensi dan batasan berikut saat mendesain solusi Batch Anda.

Sumber daya yang dibuat sistem

Azure Batch membuat dan mengelola sekumpulan pengguna dan grup pada VM, yang seharusnya tidak diubah:

Windows:

  • Pengguna bernama PoolNonAdmin
  • Grup pengguna bernama WATaskCommon

Linux:

  • Pengguna bernama _azbatch

Tip

Penamaan pengguna atau grup ini adalah artefak implementasi dan dapat berubah kapan saja.

Pembersihan file

Batch secara aktif mencoba membersihkan direktori kerja tempat tugas dijalankan, setelah waktu retensinya berakhir. Setiap file yang ditulis di luar direktori ini adalah tanggung jawab Anda untuk membersihkannya untuk menghindari pengisian ruang disk.

Pembersihan otomatis untuk direktori kerja akan diblokir jika Anda menjalankan layanan di Windows dari direktori kerja tugas awal, karena folder masih digunakan. Tindakan ini akan menyebabkan penurunan performa. Untuk memperbaiki masalah ini, ubah direktori untuk layanan tersebut ke direktori terpisah yang tidak dikelola oleh Batch.

Langkah berikutnya