En iyi Azure Batch uygulamalarAzure Batch best practices

Bu makalede, Azure Batch hizmetini etkili ve verimli bir şekilde kullanmaya yönelik en iyi yöntemler koleksiyonu ele alınmaktadır.This article discusses a collection of best practices for using the Azure Batch service effectively and efficiently. Bu en iyi yöntemler Batch ve Batch müşterilerinin deneyimleri ile deneyimimizden türetilir.These best practices are derived from our experience with Batch and the experiences of Batch customers. , Toplu Iş için geliştirme ve kullanma sırasında tasarım engellerini, olası performans sorunlarını ve daha fazla Işlem desenlerini önlemek için bu makalenin anlaşılması önemlidir.It's important to understand this article to avoid design pitfalls, potential performance issues, and anti-patterns while developing for, and using, Batch.

Bu makalede şunları öğreneceksiniz:In this article, you'll learn:

  • En iyi uygulamalar nelerdir?What are the best practices
  • Neden en iyi uygulamaları kullanmalısınız?Why you should use best practices
  • En iyi yöntemleri takip edemezseniz ne olur?What might happen if you fail to follow the best practices
  • En iyi yöntemleri takip etmeHow to follow the best practices

HavuzlarPools

Batch havuzları, Batch hizmetinde işlerin yürütülmesi için işlem kaynaklarıdır.Batch pools are the compute resources for executing jobs on the Batch service. Aşağıdaki bölümlerde, toplu Iş havuzlarıyla çalışırken izlenecek en iyi uygulamalar hakkında rehberlik sağlanmaktadır.The following sections provide guidance on the top best practices to follow when working with Batch pools.

Havuz yapılandırması ve adlandırmaPool configuration and naming

  • Havuz ayırma moduPool allocation mode
    Batch hesabı oluştururken iki havuz ayırma modu arasından seçim yapabilirsiniz: Batch hizmeti veya Kullanıcı aboneliği.When creating a Batch account, you can choose between two pool allocation modes: Batch service or user subscription. Çoğu durumda, toplu yönetilen aboneliklerde havuzların arkasında ayrıldığı varsayılan Batch hizmeti modunu kullanmanız gerekir.For most cases, you should use the default Batch service mode, in which pools are allocated behind the scenes in Batch-managed subscriptions. Alternatif Kullanıcı aboneliği modunda, bir havuz oluşturulduğunda Batch VM'leri ve diğer kaynaklar doğrudan aboneliğinizde oluşturulur.In the alternative user subscription mode, Batch VMs and other resources are created directly in your subscription when a pool is created. Kullanıcı aboneliği hesapları, önemli, ancak küçük bir senaryo alt kümesini etkinleştirmek için öncelikli olarak kullanılır.User subscription accounts are primarily used to enable an important, but small subset of scenarios. Kullanıcı aboneliği modu hakkında daha fazla bilgi için kullanıcı aboneliği modu Için ek yapılandırmamakalesini okuyun.You can read more about user subscription mode at Additional configuration for user subscription mode.

  • İş ve görev çalışma süresini, havuzdan eşleme işi belirlenirken göz önünde bulundurun.Consider job and task run time when determining job to pool mapping.
    Öncelikle kısa süreli görevlerden oluşan işleriniz varsa ve beklenen toplam görev sayısı küçük olduğundan, işin genel beklenen çalışma zamanının uzun olmaması ve her iş için yeni bir havuz ayrılmaması gerekir.If you have jobs comprised primarily of short-running tasks, and the expected total task counts are small, so that the overall expected run time of the job is not long, do not allocate a new pool for each job. Düğümlerin ayırma süresi, işin çalışma süresini azaledecektir.The allocation time of the nodes will diminish the run time of the job.

  • Havuzlar birden çok işlem düğümüne sahip olmalıdır.Pools should have more than one compute node.
    Bağımsız düğümlerin her zaman kullanılabilir olması garanti edilmez.Individual nodes are not guaranteed to always be available. Yaygın olarak, donanım hataları, işletim sistemi güncelleştirmeleri ve diğer sorunların bir konağı, tek tek düğümlerin çevrimdışı olmasına neden olabilir.While uncommon, hardware failures, operating system updates, and a host of other issues can cause individual nodes to be offline. Batch iş yükünüz belirleyici gerektiriyorsa, garantili ilerleme durumunda birden çok düğüm içeren havuzlar ayırmanız gerekir.If your Batch workload requires deterministic, guaranteed progress, you should allocate pools with multiple nodes.

  • Kaynak adlarını yeniden kullanmayın.Do not reuse resource names.
    Batch kaynakları (işler, havuzlar vb.) genellikle zaman içinde gelir ve zaman içinde gider.Batch resources (jobs, pools, etc.) often come and go over time. Örneğin, Pazartesi günü bir havuz oluşturabilir, Salı günü silebilir ve ardından Perşembe üzerinde başka bir havuz oluşturabilirsiniz.For example, you may create a pool on Monday, delete it on Tuesday, and then create another pool on Thursday. Oluşturduğunuz her yeni kaynağa, daha önce kullanmadığınız benzersiz bir ad verilmelidir.Each new resource you create should be given a unique name that you haven't used before. Bu, bir GUID kullanılarak (tüm kaynak adı olarak veya bunun bir parçası olarak) ya da kaynağın kaynak adında oluşturulduğu zamanı katıştırarak yapılabilir.This can be done by using a GUID (either as the entire resource name, or as a part of it) or embedding the time the resource was created in the resource name. Batch, gerçek kaynak KIMLIĞI insana sahip olmayan bir şey olsa da kaynağa okunabilir bir ad vermek için kullanılabilen DisplayName'i destekler.Batch supports DisplayName, which can be used to give a resource a human readable name even if the actual resource ID is something that isn't that human friendly. Benzersiz adların kullanılması, hangi belirli kaynağın günlüklerde ve ölçümlerde bir şeyler olduğunu ayırt etmenize daha kolay hale getirir.Using unique names makes it easier for you to differentiate which particular resource did something in logs and metrics. Ayrıca, bir kaynak için bir destek durumu dosyası oluşturmanız gerekiyorsa belirsizlik kaldırılır.It also removes ambiguity if you ever have to file a support case for a resource.

  • Havuz bakımı ve başarısızlık sırasında süreklilik.Continuity during pool maintenance and failure.
    İşlerinizin havuzları dinamik olarak kullanması en iyisidir.It's best to have your jobs use pools dynamically. İşleriniz her şey için aynı havuzu kullanıyorsa, havuzda bir sorun oluşursa işlerin çalıştırılmayabileceği bir şansınız vardır.If your jobs use the same pool for everything, there's a chance that your jobs won't run if something goes wrong with the pool. Bu, özellikle zamana duyarlı iş yükleri için önemlidir.This is especially important for time-sensitive workloads. Bunu çözmek için, her bir işi zamanlarken bir havuzu dinamik olarak seçin veya oluşturun veya uygun olmayan bir havuzu atlayabilmeniz için havuz adını geçersiz kılmak üzere bir yol belirtin.To fix this, select or create a pool dynamically when you schedule each job, or have a way to override the pool name so that you can bypass an unhealthy pool.

  • Havuz bakımı ve başarısızlığı sırasında iş sürekliliğiBusiness continuity during pool maintenance and failure
    Bir havuzun, dahili hatalar, kapasite kısıtlamaları vb. gibi gerekli boyuta büyümesini engelleyebilen birçok nedeni vardır. Bu nedenle, işleri farklı bir havuzda yeniden hedeflemeniz (muhtemelen farklı bir VM boyutu ile) gerekirse bu Işlemi Updatejobaracılığıyla destekler.There are many possible causes that may prevent a pool from growing to the required size you desire, such as internal errors, capacity constraints, etc. For this reason, you should be ready to retarget jobs at a different pool (possibly with a different VM size - Batch supports this via UpdateJob) if necessary. Bir statik havuz KIMLIĞI kullanmaktan kaçının hiçbir şekilde silinmeyeceğinden ve hiçbir şekilde değişmeyeceğinden, beklenmez.Avoid using a static pool ID with the expectation that it will never be deleted and never change.

Havuz ömrü ve faturalamaPool lifetime and billing

Havuz ömrü, havuz yapılandırmasına uygulanan ayırma ve seçenekler yöntemine bağlı olarak farklılık gösterebilir.Pool lifetime can vary depending upon the method of allocation and options applied to the pool configuration. Havuzlar, zaman içinde herhangi bir zamanda, havuzda rastgele bir yaşam süresine ve farklı sayıda işlem düğümüne sahip olabilir.Pools can have an arbitrary lifetime and a varying number of compute nodes in the pool at any point in time. Havuzdaki işlem düğümlerini açıkça veya hizmet tarafından sunulan özellikler aracılığıyla (otomatik ölçeklendirme veya otomatik havuz) yönetmek sizin sorumluluğunuzdadır.It's your responsibility to manage the compute nodes in the pool either explicitly, or through features provided by the service (autoscale or autopool).

  • Havuzları güncel tutun.Keep pools fresh.
    En son düğüm Aracısı güncelleştirmelerini ve hata düzeltmelerini aldığınızdan emin olmak için havuzlarınızı her birkaç ayda bir sıfır olacak şekilde yeniden boyutlandırmalısınız.You should resize your pools to zero every few months to ensure you get the latest node agent updates and bug fixes. Havuzunuz, yeniden oluşturulup 0 işlem düğümlerine yeniden boyutlandırılana kadar düğüm Aracısı güncelleştirmeleri almaz.Your pool won't receive node agent updates unless it's recreated, or resized to 0 compute nodes. Havuzunuzu yeniden oluşturmadan veya yeniden boyutlandırabilmeniz için, düğümler bölümünde anlatıldığı gibi, hata ayıklama amacıyla herhangi bir düğüm Aracısı günlüğünü indirmeniz önerilir.Before you recreate or resize your pool, it's recommended to download any node agent logs for debugging purposes, as discussed in the Nodes section.

  • Havuz yeniden oluşturmaPool re-creation
    Benzer bir notta havuzlarınızın günlük olarak silinmesi ve yeniden oluşturulması önerilmez.On a similar note, it's not recommended to delete and re-create your pools on a daily basis. Bunun yerine, yeni bir havuz oluşturun, mevcut işlerinizi yeni havuza işaret etmek üzere güncelleştirin.Instead, create a new pool, update your existing jobs to point to the new pool. Tüm görevler yeni havuza taşındıktan sonra eski havuzu silin.Once all of the tasks have been moved to the new pool, then delete the old pool.

  • Havuz verimliliği ve faturalamaPool efficiency and billing
    Batch 'in kendisi ek ücret vermez, ancak kullanılan işlem kaynakları için ücret ödemeniz gerekir.Batch itself incurs no extra charges, but you do incur charges for the compute resources used. İçindeki durum ne olursa olsun, havuzdaki her işlem düğümü için faturalandırılırsınız.You're billed for every compute node in the pool, regardless of the state it's in. Bu, düğüm için gereken depolama ve ağ maliyetleri gibi tüm ücretleri içerir.This includes any charges required for the node to run such as storage and networking costs. En iyi uygulamalar hakkında daha fazla bilgi edinmek için bkz. Azure Batch Için maliyet analizi ve bütçeleri.To learn more best practices, see Cost analysis and budgets for Azure Batch.

Havuz ayırma sorunlarıPool allocation failures

Havuz ayırma arızaları, ilk ayırma veya sonraki yeniden boyutlandırmalarda herhangi bir noktada gerçekleşebilir.Pool allocation failures can happen at any point during first allocation or subsequent resizes. Bunun nedeni, bir bölgedeki geçici kapasiteden veya toplu Işin bağımlı olduğu diğer Azure hizmetlerindeki hatalardan kaynaklanabilir.This can be due to temporary capacity exhaustion in a region or failures in other Azure services that Batch relies on. Çekirdek kotanızın garantisi, ancak bunun yerine bir sınır değildir.Your core quota is not a guarantee but rather a limit.

Planlanmamış kapalı kalma süresiUnplanned downtime

Toplu Iş havuzlarının Azure 'da kesinti süresi olaylarıyla karşılaşması mümkündür.It's possible for Batch pools to experience downtime events in Azure. Bu, senaryonuzu veya Batch için iş akışınızı planlarken ve geliştirirken göz önünde bulundurmanız önemlidir.This is important to keep in mind when planning and developing your scenario or workflow for Batch.

Bir düğümün başarısız olması durumunda, Batch otomatik olarak bu işlem düğümlerini sizin adınıza kurtarmaya çalışır.In the case that a node fails, Batch automatically attempts to recover these compute nodes on your behalf. Bu, kurtarılan düğüm üzerinde çalışan herhangi bir görevin yeniden çizelgelenmesi tetiklenebilir.This may trigger rescheduling any running task on the node that is recovered. Kesilen görevler hakkında daha fazla bilgi edinmek için bkz. yeniden denemeler tasarlama .See Designing for retries to learn more about interrupted tasks.

  • Azure bölge bağımlılığıAzure region dependency
    Zamana duyarlı veya üretim iş yükünüz varsa, tek bir Azure bölgesine bağlı olmaması önerilir.It's advised to not depend on a single Azure region if you have a time-sensitive or production workload. Nadir olarak, bir bölgenin tamamını etkileyebilecek sorunlar vardır.While rare, there are issues that can affect an entire region. Örneğin, işlemelerinizin belirli bir zamanda başlaması gerekiyorsa, birincil bölgenizdeki havuzun ölçeğini başlangıç zamanından önce daölçeklendirin.For example, if your processing needs to start at a specific time, consider scaling up the pool in your primary region well before your start time. Havuz ölçeği başarısız olursa, bir yedekleme bölgesindeki (veya bölgelerde) bir havuzu ölçeklendirmeye geri dönebilirsiniz.If that pool scale fails, you can fall back to scaling up a pool in a backup region (or regions). Farklı bölgelerdeki birden çok hesap genelinde havuzlar, başka bir havuz ile yanlış bir sorun varsa, daha kolay erişilebilir bir yedekleme sağlar.Pools across multiple accounts in different regions provide a ready, easily accessible backup if something goes wrong with another pool. Daha fazla bilgi için bkz. uygulamanızı yüksek kullanılabilirlik Için tasarlama.For more information, see Design your application for high availability.

İşJobs

İş, yüzlerce, binlerce veya hatta milyonlarca görevi içerecek şekilde tasarlanan bir kapsayıcıdır.A job is a container designed to contain hundreds, thousands, or even millions of tasks.

  • Bir işe birçok görev yerleştirmePut many tasks in a job
    Tek bir görevi çalıştırmak için bir iş kullanmak verimsiz değildir.Using a job to run a single task is inefficient. Örneğin, her biri 10 görev içeren 100 iş oluşturmak yerine 1000 görevi içeren tek bir işi kullanmak daha etkilidir.For example, it's more efficient to use a single job containing 1000 tasks rather than creating 100 jobs that contain 10 tasks each. Her biri tek bir görev içeren 1000 iş çalıştırmak, en az verimli, en yavaş ve en pahalı yaklaşım olacaktır.Running 1000 jobs, each with a single task, would be the least efficient, slowest, and most expensive approach to take.

    Aynı anda binlerce etkin işi gerektiren bir Batch çözümü tasarlamayın.Do not design a Batch solution that requires thousands simultaneously of active jobs. Görevler için kota yoktur, bu nedenle çok sayıda iş altında çok sayıda görev yürütülerek iş ve iş zamanlama kotalarınızıverimli bir şekilde kullanır.There is no quota for tasks, so executing as many tasks under as few jobs as possible efficiently uses your job and job schedule quotas.

  • İş ömrüJob lifetime
    Toplu işin, sistemden silinene kadar sınırsız bir ömrü vardır.A Batch job has an indefinite lifetime until it's deleted from the system. Bir işin durumu, zamanlama için daha fazla görevi kabul edip edemeyeceğini belirler.A job’s state designates whether it can accept more tasks for scheduling or not. Açık olarak sonlandırılmadığı takdirde bir iş otomatik olarak tamamlandı durumuna taşınamaz.A job does not automatically move to completed state unless explicitly terminated. Bu, Onalltasksall özelliği veya Maxduvara Clocktimearacılığıyla otomatik olarak tetiklenebilir.This can be automatically triggered through the onAllTasksComplete property or maxWallClockTime.

Varsayılan bir etkin iş ve iş zamanlaması kotasıvardır.There is a default active job and job schedule quota. İşlerin ve iş zamanlamalarının tamamlandı durumunda bu kotaya dahil sayılmaz.Jobs and job schedules in completed state do not count towards this quota.

GörevlerTasks

Görevler, bir işi oluşturan bireysel iş birimleridir.Tasks are individual units of work that comprise a job. Görevler kullanıcı tarafından gönderilir ve işlem düğümleri için toplu Iş tarafından zamanlanır.Tasks are submitted by the user and scheduled by Batch on to compute nodes. Görevleri oluştururken ve yürütürken yapmanız gereken çeşitli tasarım konuları vardır.There are several design considerations to make when creating and executing tasks. Aşağıdaki bölümlerde, sorunları ele almak ve verimli bir şekilde gerçekleştirmek için genel senaryolar ve görevlerinizi tasarlamak açıklanmaktadır.The following sections explain common scenarios and how to design your tasks to handle issues and perform efficiently.

  • Görev verilerini görevin bir parçası olarak kaydedin.Save task data as part of the task.
    İşlem düğümleri doğası gereği daha kısa.Compute nodes are by their nature ephemeral. Yığın içinde otomatik havuz ve otomatik ölçeklendirme gibi birçok özellik vardır ve bu da düğümlerin kaybolmasını kolaylaştırır.There are many features in Batch such as autopool and autoscale that make it easy for nodes disappear. Düğümler havuzdan ayrıldığında (bir yeniden boyutlandırma veya havuz silme nedeniyle), bu düğümlerdeki tüm dosyalar da silinir.When nodes leave pool (due to a resize, or a pool delete) all the files on those nodes are also deleted. Bu nedenle, bir görev tamamlanmadan önce, bir görev başarısız olduğunda, bir görevin başarısız olması durumunda, bir görevin arızalandığı düğümü dayanıklı bir depoya taşımalıdır.Because of this, it's recommended that before a task completes, it moves its output off of the node it is running on and to a durable store, similarly if a task fails it should move logs required to diagnose the failure to a durable store. Toplu işlem, Azure depolama 'yı kullanarak verileri OutputFilesaracılığıyla karşıya yüklemeyi, ayrıca çeşitli paylaşılan dosya sistemlerini de veya kendi görevlerinizde karşıya yüklemeyi gerçekleştirmek için tümleşik destek içerir.Batch has integrated support Azure Storage to upload data via OutputFiles, as well as a variety of shared file systems, or you can perform the upload yourself in your tasks.

Görev ömrüTask lifetime

  • Görevleri tamamlandığında silin.Delete tasks when they're complete.
    Görevleri artık gerekli olmadığında silin veya bir retentionTime görev kısıtlaması ayarlayın.Delete tasks when they are no longer needed, or set a retentionTime task constraint. Bir retentionTime ayarlandıysa, toplu Işlem, retentionTime süresi dolarsa görev tarafından kullanılan disk alanını otomatik olarak temizler.If a retentionTime is set, Batch automatically cleans up the disk space used by the task when the retentionTime expires.

    Görevleri silme işlemi iki şeyi gerçekleştirir.Deleting tasks accomplishes two things. Bu, çalıştığınız görevi daha zor bir şekilde sorgulamayı/bulmayı (tamamlanan görevleri filtrelemeniz gerekecektir) sağlayan, iş içinde görev oluşturma işlemi yapılmasını sağlar.It ensures that you do not have a build-up of tasks in the job, making querying/finding the task you're interested in harder (because you'll have to filter through the Completed tasks). Ayrıca, düğümdeki karşılık gelen görev verilerini de temizler (belirtilen retentionTime zaten isabet aldıysa).It also cleans up the corresponding task data on the node (provided retentionTime has not already been hit). Bu, düğümlerinizin görev verileriyle doldurulmamasını ve disk alanı tükenmesini sağlar.This ensures that your nodes don't fill up with task data and run out of disk space.

Görev göndermeTask submission

  • Bir koleksiyonda çok sayıda görev gönderebilirsiniz.Submit a large number of tasks in a collection.
    Görevler ayrı ayrı veya koleksiyonlarda gönderilebilir.Tasks can be submitted on an individual basis or in collections. Ek yükü ve gönderim süresini azaltmak için görevler toplu gönderimi yaparken bir seferde en fazla 100 olan koleksiyonlara görev gönderebilirsiniz.Submit tasks in collections of up to 100 at a time when doing bulk submission of tasks to reduce overhead and submission time.

Görev yürütmeTask execution

  • Düğüm başına en fazla görevlerinizi seçmeChoosing your max tasks per node
    Batch, düğümlerde fazla abone olan görevleri destekler (bir düğümden daha fazla görev çalıştırmak çekirdekler vardır).Batch supports oversubscribing tasks on nodes (running more tasks than a node has cores). Görevlerinizin, havuzunuzdaki düğümlere "sığması" durumunda olduğundan emin olmanız gerekir.It's up to you to ensure that your tasks "fit" into the nodes in your pool. Örneğin, her birinin bir düğümde (maxTasksPerNode = 8sahip bir havuzda) %25 CPU kullanımı tükettiği sekiz görevi zamanlamaya çalışırsanız, düzeyi düşürülmüş bir deneyimle karşılaşabilirsiniz.For example, you may have a degraded experience if you attempt to schedule eight tasks that each consume 25% CPU usage onto one node (in a pool with maxTasksPerNode = 8).

Yeniden denemeler ve yeniden yürütme için tasarlamaDesigning for retries and re-execution

Görevler, toplu Işlem tarafından otomatik olarak yeniden denenebilir.Tasks can be automatically retried by Batch. İki tür yeniden deneme vardır: Kullanıcı denetimli ve dahili.There are two types of retries: user-controlled and internal. Kullanıcı denetimli yeniden denemeler, görevin Maxtaskretrycounttarafından belirtilir.User-controlled retries are specified by the task’s maxTaskRetryCount. Görevde belirtilen bir program sıfır dışında bir çıkış kodu ile çıktığında, görev maxTaskRetryCountdeğerine kadar yeniden denenir.When a program specified in the task exits with a non-zero exit code, the task is retried up to the value of the maxTaskRetryCount.

Nadir olarak bir görev, işlem düğümündeki hatalar nedeniyle, görev çalışırken düğüm üzerinde iç durumu veya bir başarısızlığı güncelleştirmeme gibi yeniden deneniyor olabilir.Although rare, a task can be retried internally due to failures on the compute node, such as not being able to update internal state or a failure on the node while the task is running. Görev, mümkünse aynı işlem düğümünde yeniden denenecektir, bu, görevde bir süre önce bir iç sınıra kadar ve bir toplu Işlem tarafından, potansiyel olarak farklı bir işlem düğümünde yeniden zamanlanmasını ertelenir.The task will be retried on the same compute node, if possible, up to an internal limit before giving up on the task and deferring the task to be rescheduled by Batch, potentially on a different compute node.

  • Dayanıklı Görevler oluşturunBuild durable tasks
    Görevler hatalı ve yeniden denemeye yetecek şekilde tasarlanmalıdır.Tasks should be designed to withstand failure and accommodate retry. Bu, özellikle uzun süre çalışan görevler için önemlidir.This is especially important for long running tasks. Bunu yapmak için, görevlerin aynı anda birden çok kez çalıştırılsa bile aynı, tek bir sonuç oluşturmasını sağlayın.To do this, ensure tasks generate the same, single result even if they are run more than once. Bunu başarmanın bir yolu, görevlerinizi "hedef arama" yapmak.One way to achieve this is to make your tasks “goal seeking”. Diğer bir yol da görevlerinizin ıdempotent olduğundan emin olmak (görevler kaç kez çalıştırıldıklarından bağımsız olarak aynı sonuca sahip olacaktır).Another way is to make sure your tasks are idempotent (tasks will have the same outcome no matter how many times they are run).

    Ortak bir örnek, dosyaları bir işlem düğümüne kopyalamak için kullanılan bir görevdir.A common example is a task to copy files to a compute node. Basit yaklaşım, her çalıştığında belirtilen her dosyayı kopyalayan, verimsiz olan ve geldiğinde hatası için oluşturulmamış bir görevdir.A simple approach is a task that copies all the specified files every time it runs, which is inefficient and isn't built to withstand failure. Bunun yerine, dosyaların işlem düğümünde olduğundan emin olmak için bir görev oluşturun; zaten mevcut olan dosyaları yeniden kopyalamamış bir görev.Instead, create a task to ensure the files are on the compute node; a task that doesn't recopy files that are already present. Bu şekilde, görev kesintiye uğratıldığında, görev ayrıldıktan sonra açılır.In this way, the task picks up where it left off if it was interrupted.

  • Düşük öncelikli düğümlerLow priority nodes
    Görevlerinizi adanmış veya düşük öncelikli düğümlerde yürütürken hiçbir tasarım farkı yoktur.There are no design differences when executing your tasks on dedicated or low-priority nodes. Bir görevin düşük öncelikli bir düğümde çalışırken geçersiz hale gelmiş veya ayrılmış bir düğümdeki bir hata nedeniyle kesintiye uğratıldığı, her iki durum da görevi withfailure hatası tasarlayarak azaltılmıştır.Whether a task is preempted while running on a low-priority node or interrupted due to a failure on a dedicated node, both situations are mitigated by designing the task to withstand failure.

  • Görev yürütme süresiTask execution time
    Kısa yürütme süresine sahip görevlerden kaçının.Avoid tasks with short execution time. Yalnızca bir ile iki saniye çalışan görevler ideal değildir.Tasks that only run for one to two seconds are not ideal. Tek bir görevde önemli miktarda iş yapmayı denemelisiniz (en az 10 saniye, saat veya güne kadar).You should try to do a significant amount of work in an individual task (10 second minimum, going up to hours or days). Her görev bir dakika (veya daha fazla) boyunca yürütülüyordur, genel işlem zamanının bir bölümü olarak zamanlama yükü küçüktür.If each task is executing for one minute (or more), then the scheduling overhead as a fraction of overall compute time is small.

DüğümlerNodes

  • Başlangıç görevleri ıdempotent olmalıdırStart tasks should be idempotent
    Diğer görevlere benzer şekilde, düğüm başlangıç görevi, düğüm her önyüklendiğinde yeniden çalıştırılacak şekilde ıdempotent olmalıdır.Similar to other tasks, the node start task should be idempotent as it will be rerun every time the node boots. Bir ıdempotent görevi, birden çok kez çalıştırıldığında tutarlı bir sonuç üreten bir görevdir.An idempotent task is simply one that produces a consistent result when run multiple times.

  • İşletim sistemi Hizmetleri arabirimi aracılığıyla uzun süre çalışan hizmetleri yönetin.Manage long running services via the operating system services interface.
    Bazen, düğümdeki verileri toplamak ve rapor etmek için, örneğin, düğümündeki Batch aracısının yanı sıra başka bir aracı da çalıştırmanız gerekir.Sometimes there is a need to run another agent alongside the Batch agent in the node, e.g., to gather data from the node and report it. Bu aracıların Windows hizmeti veya Linux systemd hizmeti gibi işletim sistemi hizmetleri olarak dağıtılmasını öneririz.We recommend that these agents be deployed as OS services, such as a Windows service or a Linux systemd service.

    Bu Hizmetleri çalıştırırken, düğüm üzerindeki toplu yönetilen dizinlerde bulunan dosyalarda dosya kilitleri almalıdır, aksi takdirde toplu Işlem dosya kilitleri nedeniyle bu dizinlerin silinmesine neden olur.When running these services, they must not take file locks on any files in Batch-managed directories on the node, because otherwise Batch will be unable to delete those directories due to the file locks. Örneğin, başlangıç görevinde bir Windows hizmeti yüklüyorsanız, hizmeti doğrudan başlangıç görevi çalışma dizininden başlatmak yerine, dosyaları başka bir yere kopyalayın (dosyalar varsa yalnızca kopyayı atlayın).For example, if installing a Windows service in a start task, instead of launching the service directly from the start task working directory, copy the files elsewhere (if the files exist just skip the copy). Hizmeti bu konumdan yükler.Install the service from that location. Batch, başlangıç görevinizi yeniden çalıştırdığınızda, başlangıç görevi çalışma dizinini siler ve yeniden oluşturur.When Batch reruns your start task, it will delete the start task working directory and create it again. Bu, hizmetin başlangıç görevi çalışma dizini değil diğer dizindeki dosya kilitleri olduğu için geçerlidir.This works because the service has file locks on the other directory not the start task working directory.

  • Windows 'da Dizin geçişlerini oluşturmaktan kaçınınAvoid creating directory junctions in Windows
    Bazen Dizin sabit bağlantıları olarak adlandırılan dizin junler, görev ve iş temizliği sırasında uğraşmak zordur.Directory junctions, sometimes called directory hard-links, are difficult to deal with during task and job cleanup. Sabit bağlantılar yerine çözümlemeyin (geçici bağlantılar) kullanın.Use symlinks (soft-links) rather than hard-links.

  • Bir sorun varsa Batch Aracısı günlüklerini toplayınCollect the Batch agent logs if there's an issue
    Düğüm üzerinde çalışan bir düğümün veya görevlerin davranışını içeren bir sorun fark ederseniz, söz konusu düğümlerin ayırmayı kaldırma işleminden önce Batch Aracısı günlüklerinin toplanması önerilir.If you notice a problem involving the behavior of a node or tasks running on a node, it's recommended to collect the Batch agent logs prior to deallocating the nodes in question. Batch Aracısı günlükleri, Batch Hizmeti günlüklerini karşıya yükle API 'SI kullanılarak toplanabilir.The Batch agent logs can be collected using the Upload Batch service logs API. Bu Günlükler, Microsoft 'a destek bileti kapsamında sağlanabilir ve sorun giderme ve çözümleme konularında yardımcı olur.These logs can be supplied as part of a support ticket to Microsoft and will help with issue troubleshooting and resolution.

GüvenlikSecurity

Güvenlik yalıtımıSecurity isolation

Yalıtım amaçları doğrultusunda, senaryonuzun işlerin yalıtılması gerekiyorsa, bu işleri ayrı havuzlarda bulundurarak yalıtabilirsiniz.For the purposes of isolation, if your scenario requires isolating jobs from each other, then you should isolate these jobs by having them in separate pools. Havuz, toplu Işteki güvenlik yalıtımı sınırıdır ve varsayılan olarak, iki havuz görünür değildir veya birbirleriyle iletişim kuramaz.A pool is the security isolation boundary in Batch, and by default, two pools are not visible or able to communicate with each other. Yalıtım yöntemi olarak ayrı Batch hesapları kullanmaktan kaçının.Avoid using separate Batch accounts as a means of isolation.