Azure Batch'te güvenilirlik

Azure Batch, Azure'de büyük ölçekli paralel ve yüksek performanslı bilgi işlem (HPC) toplu işleri çalıştırır. Batch işlem düğümlerinin havuzlarını oluşturur ve yönetir, çalıştırmak istediğiniz uygulamaları yükler ve düğümlerde çalışacak işleri zamanlar.

Azure'ı kullandığınızda güvenilirlik paylaşılan bir sorumluluktır. Microsoft, dayanıklılık ve kurtarmayı desteklemek için çeşitli özellikler sunar. Bu özelliklerin kullandığınız tüm hizmetler içinde nasıl çalıştığını anlamak ve iş hedeflerinize ve çalışma süresi hedeflerinize ulaşmak için ihtiyacınız olan özellikleri seçmek sizin sorumluluğunuzdadır.

Bu makalede, Azure Batch'in geçici hatalara, işlem düğümü hatalarına, kullanılabilirlik alanı hatalarına, bölge genelindeki hatalara ve hizmet bakımına karşı nasıl dayanıklı hale getirileceği açıklanır. Ayrıca üretim dağıtım önerilerini, Batch güvenilirlik mimarisini, yedekleme ve geri yüklemeyi ve Azure Batch hizmet düzeyi sözleşmesi (SLA) hakkındaki önemli bilgileri açıklar.

Üretim dağıtımı önerileri

Üretim iş yükleri için aşağıdaki güvenilirlik önerileri de dahil olmak üzere Azure Batch için en iyi yöntemleri izleyin:

  • Kesinti ve yeniden yürütmeyi tolere etmek için görevler tasarla. Görevleri idempotent yapın, uzun süren işlemler için denetim noktaları oluşturun ve gerekli çıktı ve tanılama verilerini dayanıklı depolamada kalıcı hale getirin. Daha fazla bilgi için bkz. Geçici hatalara dayanıklılık ve işlem düğümü hatalarına dayanıklılık.

  • Bir düğüm hatasından sonra iş yükünüzün devam etmesi gerektiğinde birden çok işlem düğümü kullanın. Tek tek işlem düğümlerinin kullanılabilir durumda kalacağı garanti değildir. Kalan kullanılabilir düğümlerin yeniden zamanlanmış görevleri çalıştırabilmesi için yeterli düğüm sağlayın.

  • Desteklendiğinde kullanılabilirlik alanı yerleşimini kullanın. Bölge, sanal makine (VM) SKU'su ve iş yükü yapılandırması tarafından desteklendiğinde kullanılabilirlik alanı yerleşimini yapılandırın. İyi durumdaki bölgelerdeki düğümler, bölge kesintisi sırasında görevleri çalıştırmaya devam edebilir, ancak değiştirme kapasitesi iyi durumdaki bölgelerde kotaya ve VM kullanılabilirliğine bağlı olduğundan daha düşük kapasiteyi hesaba katın. Daha fazla bilgi için bkz. Kullanılabilirlik alanı hatalarına dayanıklılık.

  • İşleri sabit havuz kimliği yerine dinamik olarak hedef havuzlara yönelecek şekilde tasarlayın. Bu tasarım, özgün havuz kullanılamaz duruma gelirse veya istenen kapasiteye ölçeklendirilemezse işi sağlıklı bir havuza yeniden hedeflemenizi sağlar. Havuz bakımı veya arızası sırasında iş sürekliliğini artırır.

  • Havuz yapılandırmalarını güncel tutun. VM görüntüleri ve SKU'ları için Batch desteği kullanım süresi sonu (EOL) tarihlerini izleyin ve havuzları EOL'den önce taşıyın. Batch düğümü aracısını güncel tutmak için hizmet bakım kılavuzunu izleyin.

Güvenilirlik mimarisine genel bakış

Bu bölümde, hizmetin nasıl çalıştığına ilişkin güvenilirlik açısından en uygun olan bazı önemli yönler açıklanmaktadır. bölümünde dağıttığınız ve kullandığınız bazı kaynak ve özellikleri içeren mantıksal mimari tanıtılır. Ayrıca, hizmetin kapaklar altında nasıl çalıştığına ilişkin ayrıntılar sağlayan fiziksel mimariyi de ele alır.

Mantıksal mimari

Azure Batch, toplu iş yüklerini çalıştırmak için çeşitli kaynak türlerinden yararlanır. Bu kaynakların yapılandırması, iş yükünüzün arızalara nasıl yanıt vereceğini belirler.

Tüm Batch işleme ve kaynakları bir Batch hesabıyla ilişkilendirilir. Batch çözümü aşağıdaki mantıksal bileşenleri kullanır:

  • Batch hesabı: Havuzların, işlerin, görevlerin ve diğer Batch kaynaklarının ilişkilendirildiği bölgesel bir kaynak. Hesabı oluşturursunuz ve bölgesini, havuz ayırma modunu ve kimlik doğrulama ayarlarını seçersiniz.

  • Havuz: Görevlerin üzerinde çalıştığı işlem düğümleri koleksiyonu. Havuzun yapılandırması vm görüntüsünü ve boyutunu, hedef düğüm sayısını, ölçeklendirme davranışını, ağ ve bölge yerleşimini tanımlar. Her havuzu, iş yükünüzün gerektirdiği kapasiteyi, yerleştirmeyi ve işletim ortamını sağlayacak şekilde yapılandırabilirsiniz. Hedef düğüm sayısı istenen kapasitedir, ancak kota sınırları, kapasite kısıtlamaları veya ayırma hataları nedeniyle ayrılan düğüm sayısı daha düşük olabilir.

  • İşler ve görevler: Bir iş, bir görev koleksiyonunu yönetir ve bir havuzla ilişkilendirilir. Görev, bir hesaplama düğümünde bir uygulama veya betik çalıştırır. İşleri, görevleri, kısıtlamaları, bağımlılıkları, yeniden deneme davranışını ve her işin çalıştığı havuzu tanımlarsınız.

  • İlişkili depolama hesabı: İsteğe bağlı olarak bir Batch hesabına bağladığınız bir Azure Depolama hesabı. Çoğu Batch çözümü uygulama dosyaları, görev kaynak dosyaları, giriş verileri ve çıkış verileri için ilişkili bir depolama hesabı kullanır.

    Bir depolama hesabını Batch hesabına bağladıktan sonra Batch, bunu autostorage hesabı olarak ifade eder. Uygulama paketleri için bir autostorage hesabı gereklidir ve görev kaynak dosyalarını da depolayabilir.

    Batch çözümünün güvenilirliği, depolama kaynaklarının güvenilirliğine bağlıdır. Depolama hesabını oluştururken kurtarma gereksinimlerinizi karşılayan bir depolama yedeklilik yapılandırması seçmek sizin sorumluluğunuzdadır. Görev çıkışını ve diğer dayanıklı verileri işlem düğümlerinden depolamaya taşıyın. Azure Depolama güvenilirlik seçenekleri hakkında bilgi için bkz. Reliability in Azure Blob Depolama.

Daha fazla bilgi için bkz. Batch hizmeti iş akışı ve kaynakları ile Batch hesapları ve Azure Depolama hesapları.

Fiziksel mimari

Azure Batch'in, Batch hesaplarına ve havuzlar, işler ve görevler gibi diğer Batch kaynaklarına yönelik yönetim işlemlerini işleyen bölgesel bir denetim düzlemi vardır. Görevleri çalıştıran işlem düğümlerinden ayrıdır.

Azure Batch havuzları Azure Sanal Makineler ve Sanal Makine Ölçek Kümeleri kullanır. İşlem düğümü, Batch iş yükünün bir bölümünü işleyen bir VM'dir. Her düğüm bir havuza aittir ve Batch hizmetinin kendisine atadığı görevleri yürütür. Batch düğüm aracısı her düğümde çalışır ve düğüm ile Batch hizmeti arasında komut ve denetim arabirimi sağlar. İşlem düğümleri ve yerel depolama alanları kısa ömürlü olur. Bir düğüm havuzdan ayrıldığında, işletim sisteminde ve dosyalarda yapılan değişiklikler kaybolur.

Batch hesabının havuz ayırma modu Batch'in işlem ve VM ile ilgili kaynakları nerede oluşturduğunu belirler:

  • Batch havuzu ayırma modu: Batch, Batch hizmeti tarafından yönetilen Azure aboneliklerinde kaynakları ayırır.
  • Kullanıcı abonelik havuzu ayırma modu: Batch, kaynakları doğrudan Batch hesabını içeren abonelikte oluşturur.

Fiziksel mimarinin sorumlulukları aşağıdaki gibi bölünür:

  • Microsoft: Microsoft bölgesel Batch denetim düzlemini ve hizmet altyapısını çalıştırır. Batch, işlem düğümlerini havuz yapılandırmasına ve kullanılabilir kapasiteye göre sağlar, görevleri zamanlar, düğüm durumunu izler ve altyapı hatalarından sonra düğümleri kurtarmaya çalışır. Batch, kesilen görevleri başka bir kullanılabilir düğümde yürütülmek üzere yeniden kuyruğa alabilir.

  • Siz: VM görüntüsünü ve boyutunu, düğüm türlerini, hedef düğüm sayısını, ölçeklendirme yapılandırmasını, ağ ve kullanılabilirlik alanı yerleşimini seçersiniz.

    Ayrıca düğüm hatalarını tolere etmek, düğüm ve görev durumlarını izlemek, konuk işletim sistemini ve düğüm aracısını güncel tutmak, yeniden yürütmeyi tolere edecek görevler tasarlamak ve dayanıklı verileri işlem düğümlerinden taşımak için yeterli kapasiteyi korumaktan da sorumlusunuz.

Batch düğümü kurtarma, bir iş yükünün kesintisiz devam etmesini garanti etmez. Daha fazla bilgi için bkz. İşlem düğümü hatalarına dayanıklılık.

Geçici hatalara dayanıklılık

Geçici hatalar, bileşenlerde kısa ve aralıklı hatalardır. Bunlar genellikle bulut gibi dağıtılmış bir ortamda gerçekleşir ve işlemlerin normal bir parçasıdır. Geçici hatalar kısa bir süre sonra kendilerini düzeltmektedir. Uygulamalarınızın genellikle etkilenen istekleri yeniden deneyerek geçici hataları işleyebileceği önemlidir.

Bulutta barındırılan tüm uygulamalar, bulutta barındırılan API'ler, veritabanları ve diğer bileşenlerle iletişim kurarken Azure geçici hata işleme yönergelerini izlemelidir. Daha fazla bilgi için bkz Geçici hataları ele alma önerileri.

Batch çözümünde, geçici hatalar hem görev olarak çalışan uygulamaları ve betikleri hem de Batch kaynaklarını yönetmek için Batch API'lerini çağıran uygulamaları etkileyebilir. Batch, görev düzeyinde yeniden deneme mekanizmaları sağlar. Görev kısıtlamalarını yapılandırmak, görevleri idempotent hale getirmek ve Batch hizmetine ve diğer bağımlılıklara yönelik çağrılar için yeniden deneme davranışını yapılandırmak sizin sorumluluğunuzdadır.

Görev yeniden denemeleri ve zaman sınırları

Batch'in işlemi sıfır olmayan bir çıkış koduyla çıktıktan sonra bir görevi kaç kez yeniden deneyeceğini denetlemek için maxTaskRetryCount öğesini yapılandırın:

  • Varsayılan değer olan 0, Batch'in sıfır olmayan bir çıkış kodundan sonra görevi yeniden denemediği anlamına gelir.
  • Pozitif bir tamsayı, ilk denemeden sonra en fazla yeniden deneme sayısını belirler.
  • -1 değeri sınırsız yeniden denemeye izin verir. Kalıcı bir hata görevin süresiz olarak çalışmasına neden olabileceğinden bu değer önerilmez.

Yeniden denemelerin veri bozulmasına veya yinelenen çıkışa neden olmayacak şekilde her görevi idempotent olacak şekilde tasarlayabilirsiniz. Uzun süre çalışan görevler için, yeniden denemenin kaydedilen ilerlemeden devam edebilmesi amacıyla denetim noktası kullanın. Daha fazla bilgi için bkz. Yeniden denemeler ve yeniden yürütme için tasarlama.

maxWallClockTime Kabul edilebilir bir süre içinde ilerleme kaydedemeyen çalışmayı sonlandırmak için görev veya iş üzerindeki kısıtı ayarlayın. Zaman sınırı, yinelenen hataların etkisini de sınırlar. İş yükünün kurtarma hedefleriyle uyumlu yeniden deneme sayılarını ve zaman sınırlarını seçin.

Görev bağımlılıklarındaki geçici hatalar

Batch görevleri olarak çalışan uygulamalar ve betikler genellikle Azure Depolama, veritabanları veya API'ler gibi diğer bileşenleri çağırır. Batch, görev kodunun bu bağımlılıklara gönderdiği istekleri tek tek yönetmez. Görev kodunda geçici hata işleme uygulayın veya bağımlılığın SDK'sı tarafından sağlanan yeniden deneme özelliklerini kullanın. Yeniden denenebilir hataları belirlemek, uygun geri çekilme ve zaman aşımı ayarlarını seçmek ve Retry-After üst bilgisi gibi yeniden deneme yönergelerine uymak için her bağımlılığın yönergelerini izleyin. Yalnızca tekrarlanması güvenli olan işlemleri yeniden deneyin.

Bağımlılık hatası görev işleminin sıfır olmayan bir çıkış koduyla çıkmasına neden olursa Batch, maxTaskRetryCount öğesine göre görevin tamamını yeniden deneyebilir. Ancak Batch, çalışan bir görev içindeki tek bir bağımlılık isteğini yeniden denemez.

Batch API isteği yeniden denemeleri

Hizmet dışında çalışan uygulamalarınız Havuzlar, işler, görevler, işlem düğümleri ve diğer Batch kaynaklarını oluşturmak ve yönetmek için Batch API'lerini çağırabilir. Bu istemcileri, geçici Batch hizmeti veya ağ hatalarını işlemek için en az beş dakikayı kapsayan yeniden deneme ilkeleriyle yapılandırın.

Kullanılabilir olduğunda yerleşik SDK yeniden deneme desteğini kullanın. Örneğin, .NET için Azure.Compute.Batch istemci kitaplığı, Azure.Core yeniden deneme seçenekleri aracılığıyla yeniden deneme davranışını kullanıma sunar.

Kodunuzdan Batch hizmetinin API'leriyle doğrudan etkileşimde bulunursanız, yeniden denemeden önce birkaç saniye bekleyin, eşzamanlı yeniden deneme isteklerini önlemek için rastgeleleştirme (jitter) ile üstel geri çekilme kullanın ve 503 Service Unavailable ve 429 Too Many Requests gibi hız sınırlama yanıtlarıyla döndürülen Retry-After başlığını dikkate alın.

İstek zaman aşımı, Batch'in isteği işleyemediği anlamına gelmez. Zaman aşımından sonra, güvenli olduğunda işlemi yeniden deneyin veya özgün işlemin başarılı olup olmadığını belirlemek için kaynak durumunu alın. Daha fazla bilgi için bkz. Azure Batch'de hata işleme ve algılama.

İşlem düğümü hatalarına dayanıklılık

Bir altyapı hatası, işletim sistemi sorunu veya yapılandırma sorunu nedeniyle işlem düğümü kullanılamaz duruma gelebilir. Batch, altyapı hatalarından etkilenen düğümleri geri yüklemeye çalışır, ancak yapılandırmayla ilgili her hatayı otomatik olarak kurtaramaz. Örneğin, bir uygulama paketi veya kapsayıcı yüklenemezse, temel sorunu düzeltmeniz gerekir ve etkilenen düğümü kaldırıp yenisiyle değiştirmeniz gerekebilir.

Bir düğüm hatası görevi kesintiye uğratırsa Batch, mümkünse bir iç sınıra kadar görevi aynı düğümde yeniden deneyebilir. Görev bu düğümde devam edemiyorsa Batch, başka bir kullanılabilir düğümde yürütülmek üzere onu yeniden kuyruğa alabilir. Bu hizmet temelli kurtarma yeniden denemeleri, maxTaskRetryCount değerinden bağımsızdır ve değeri 0 olduğunda bile oluşabilir.

Microsoft tarafından yönetilen düğüm kurtarma işlemi

Microsoft hizmet temelli düğüm kurtarma ve görevlerin yeniden kuyruğa alınması işlemlerini yönetir. Batch hizmeti, kurtarmayı tetikleyecek kadar uzun bir süre bir düğümden sinyal almazsa, Batch aşağıdaki eylemleri gerçekleştirebilir:

  1. Düğümü yalıtın: Batch düğümü sağlıksız olarak değerlendirir, durumunu unusable olarak ayarlar ve üzerinde yeni görevler zamanlamayı durdurur.
  2. Etkilenen görevleri tanımlama: Batch, düğümde çalışan görevleri yeniden zamanlama için aday olarak belirler.
  3. Uygun görevleri yeniden kuyruğa al: Etkilenen bir görev hâlâ running durumunda kalıcıysa, Batch bunu active durumuna sıfırlayabilir; böylece zamanlayıcı görevi başka bir düğüme atayabilir. Batch, zaten kalıcı olan completed durumundaki bir görevi sıfırlamaz veya yeniden çalıştırmaz.
  4. Düğümü kurtarın: Batch, düğümü iyi durumda bir duruma geri yüklemeyi veya temel alınan VM'yi değiştirmeyi dener.

Kurtarma işlemi anında gerçekleşmez. Batch düğüm hatasını algılarken ve görevi yeniden zamanlamaya çalışırken, bir görev running durumunda kalabilir. Başka bir işlem düğümü yoksa, Batch yeniden zamanlayabilene kadar görev bu durumda kalabilir. Daha fazla bilgi için bkz. Batch görevleri için bilinen sınırlamalar.

Değiştirme başlamadan önce özgün düğüm yeniden sağlıklı heartbeat sinyalleri göndermeye başlarsa Batch bunu kararlı bir duruma döndürebilir. Değiştirme işlemi zaten başladıysa, Batch bunun yerine özgün VM'yi kaldırabilir ve yerine geçecek bir VM sağlayabilir.

Sorumluluklarınız

Hizmet temelli kurtarma, kesintisiz görev yürütmeyi veya yeterli kalan kapasiteyi garanti etmez. Aşağıdaki eylemlerden siz sorumlusunuz:

  • Yeterli kapasiteyi koruyun: Bir düğüm kullanılamaz durumdayken iş yükünüz devam etmesi gerekiyorsa, kalan düğümlerin yeniden zamanlanmış görevleri çalıştırması için yeterli düğüm sağlayın. Başka bir kullanılabilir düğüm olmadan, kesintiye uğrayan görevlerin beklemesi gerekir.

  • Kullanılabilir kapasiteyi izleyin: Bir havuzun artık iş yükünüz için yeterli kullanılabilir düğüme sahip olmadığını algılayabileceğiniz toplam düğüm sayılarını ve durumlarını izleyin. startTaskFailed, unknown, preempted ve unusable durumları kapasitenin azaldığını gösterir. Daha fazla bilgi için Görevleri ve düğümleri duruma göre sayarak Batch çözümlerini izleme bölümüne bakın.

  • Sorun düğümlerini araştırma: Görevler tekrar tekrar başarısız olursa, yeniden kuyruğa alınırsa veya atanan düğüm kullanılamaz duruma geldikten ya da havuzdan ayrıldıktan sonra running durumunda kalırsa, sorunların belirli bir düğümle ilişkili olup olmadığını belirlemek için görev meta verilerini kullanın.

    Bir sorun düğümünü kaldırmadan önce Batch düğümü aracı günlüklerini karşıya yükleyin ve düğümün kaldırılması yerel dosyalarını sildiği için ilgili görev günlüklerini koruyun. Düğüm aracısı günlükleri, Microsoft Desteği'un Batch hizmeti veya düğüm sorunlarını tanılamasına yardımcı olabilirken, stdout ve stderr gibi görev günlükleri uygulama ve yapılandırma sorunlarını belirlemenize yardımcı olabilir. Daha fazla bilgi için bkz. Düğüm aracısı günlük dosyaları.

  • Görev ilerleme durumunu ve verilerini koruma: Kesinti ve yeniden yürütmeyi tolere etmek için görevler tasarla. Yerel depolama alanları kısa ömürlü olduğundan denetim noktalarını, çıkışı ve diğer kalıcı verileri hesaplama düğümlerinin dışına taşıyın.

Daha fazla bilgi için bkz. Azure Batch havuz ve düğüm hataları ve Azure Batch hata işleme ve algılama.

Kullanılabilirlik alanı hatalarına dayanıklılık

Kullanılabilirlik alanları , bir Azure bölgesi içindeki veri merkezlerinin fiziksel olarak ayrı gruplarıdır. Bir bölge başarısız olduğunda hizmetler kalan bölgelerden birine devredilebilir.

Batch kullanılabilirlik alanlarını iki ana yolla destekler:

  • Kontrol düzlemi: Batch denetim düzlemi birçok bölgede bölge hatalarına dayanıklıdır. Bu bölgelerde, Batch hesaplarına ve diğer Batch kaynaklarına yönelik yönetim işlemleri kullanılabilirlik alanı arızası sırasında devam edebilir. Microsoft bu denetim düzlemi dayanıklılığını sağlayan bölgeleri yayımlamaz.

  • Havuzlar:Kullanılabilirlik alanı yerleşimini kullanmak için bir Batch havuzu yapılandırabilirsiniz. Bir bölge kullanılamaz duruma gelirse, iyi durumdaki bölgelerdeki işlem düğümleri görev zamanlaması için kullanılabilir durumda kalır.

    İşlem düğümü yerleşimi için, bu destek modeli diğer Azure hizmetlerindeki alanlar arası yedekliliğe benzer çünkü tek bir havuz birden çok kullanılabilirlik alanında işlem düğümleri içerebilir. Ancak Batch, düğümleri bölgeler arasında en iyi çaba temelinde dağıtır. Bölgedeki tüm zone'ları kullanmayı dener, ancak her zone'a yerleştirmeyi veya eşit bir dağılımı garanti etmez. Belirli bölgeleri seçemez veya her bölgeye yerleştirilen düğüm sayısını denetleyemezsiniz.

Aşağıdaki diyagramda örnek bir Batch hesabı gösterilmektedir. Hesabın düğümlerinin üç kullanılabilirlik alanına dağıtıldığı tek bir havuzu vardır:

İşlem düğümlerinin üç kullanılabilirlik alanına dağıtıldığı batch havuzunu gösteren diyagram.

Depolama hesapları gibi diğer bağımlı kaynakları bölgeye dayanıklı hale getirmek sizin sorumluluğunuzdadır. Her hizmet için güvenilirlik kılavuzlarını gözden geçirin. Daha fazla bilgi için bkz. Azure hizmetleri için güvenilirlik kılavuzları.

Requirements

Bölgeler arasında örnek dağıtımı

Kullanılabilirlik alanı yerleşimini etkinleştirdiğinizde Batch, işlem düğümlerini seçilen bölgedeki tüm kullanılabilirlik alanları arasında ayırmayı dener. Bu ayırma eldeki imkanlar ölçüsünde gerçekleştirilir. Toplu işlem dağıtımı denetler ve her bölgedeki düğüm sayısı eşit olmayabilir.

Cost

Batch, kullanılabilirlik alanı yerleşimini etkinleştirmek için ücret eklemez. İş yükü tarafından kullanılan işlem, depolama, ağ ve diğer Azure kaynakları için faturalandırılırsınız. Bir bölgenin kaybını tolere etmek için ek düğümler yapılandırırsanız, bu düğümler normal ücrete tabi olur. Daha fazla bilgi için bkz. fiyatlandırma Azure Batch.

Kullanılabilirlik alanı desteğini yapılandırma

  • Kullanılabilirlik alanı yerleşimi ile yeni bir havuz oluşturun: Kullanılabilirlik alanı yerleşimi etkinleştirilmiş bir havuz oluşturmak için bkz. Kullanılabilirlik alanları arasında Batch havuzu oluşturma.

  • Mevcut bir havuzdaki kullanılabilirlik alanı yerleşimini değiştirin: Havuzu oluştururken kullanılabilirlik alanı yerleşimini seçmeniz gerekir. Kullanılabilirlik alanlarını kullanmak için mevcut havuzu değiştiremezsiniz.

    Aşağıdaki adımları kullanarak bir yedek havuz oluşturabilir ve işlerinizin her birini bu havuzu kullanacak şekilde güncelleştirebilirsiniz:

    1. İşi devre dışı bırakın:İşi Devre Dışı Bırak işlemini kullanın ve isteği gönderdiğinizde Batch'in çalışan görevleri nasıl işlediğini seçin:

      • Bekleyin: Batch, yeni görevleri başlatmayı durdurur ve mevcut havuzda çalışan görevlerin bitmesini sağlar. İş, çalışan görevler bitene kadar disabling durumunda kalır.
      • Yeniden kuyruğa al: Batch, çalışan görevleri kesintiye uğratır ve kuyruğa döndürür. Görevi etkinleştirdikten sonra görevler yeniden çalıştırılabilir.
      • Sonlandır: Batch, çalışan görevleri kesintiye uğratır ve sonlandırıldıklarını belirten başarısızlık bilgileriyle tamamlandı olarak işaretler. İşi etkinleştirdikten sonra görevler yeniden çalışmaz.

      Zaten active durumunda olan görevler, yani kuyruğa alınmış ancak çalıştırılmayan görevler, her seçenekte kuyruğa alınmış olarak kalır.

      Devam etmeden önce iş disabled durumuna ulaşana kadar bekleyin. Bu noktada, hiçbir görev çalışmıyor ve Batch yeni görevleri zamanlamıyor.

    2. İşin havuzunu düzenleyin: İşin poolInfo.poolId değerini yedek havuza ayarlamak için İşi Güncelleştir işlemini kullanın. Batch yalnızca iş disabled durumundayken bu özelliğin değişmesine izin verir. İşi etkinleştirmeden önce değiştirme havuzunun mevcut olduğundan ve kullanılabilir kapasiteye sahip olduğundan emin olun. Havuz yoksa Batch güncelleştirmeyi kabul eder, ancak siz havuzu oluşturana kadar görevleri zamanlayamaz.

    3. İşi etkinleştirin:İşi Etkinleştir işlemini kullanın. İş, enabling durumundan active durumuna geçer. Batch daha sonra, Yeniden Kuyruğa Al seçeneğiyle kuyruğa döndürülen görevler de dahil olmak üzere kuyruğa alınan görevleri yedek havuzda zamanlar. Batch'te Bekle seçeneği uygulanmışken tamamlanan görevler ve Sonlandır seçeneği tarafından tamamlanan görevler yeniden çalışmaz.

Kapasite planlaması ve yönetimi

Batch'in normal düğüm kurtarma işlemi , bölge hatası sırasında kullanılamaz duruma gelen düğümleri değiştirmeyi ve havuzu yapılandırılan hedef düğüm sayısına geri yüklemeyi dener. Bu hedefi artırmaz. Bir bölge kullanılamadığında iş yükünün devam etmesi için yeterli kapasiteyi korumak amacıyla, otomatik ölçeklendirme kullanarak veya el ile havuzun kapasitesine fazla kaynak ayırmayı göz önünde bulundurun:

  • Otomatik ölçeklendirme kullanıyorsanız: Kullanılabilir kapasitenin iş yükünüzün gerektirdiği temelin altına indiğini algılamak için havuzun otomatik ölçeklendirme formülünde $UsableNodeCount hizmet tanımlı değişkenine başvurun. $UsableNodeCountAzure İzleyici ölçümü değil, formülü değerlendirilen havuz için bir Batch otomatik ölçeklendirme değişkenidir. Azure İzleyici Batch hesabı kapsamında Batch düğüm sayısı ölçümlerini yayımlar ve bu ölçümlerin bir poolId boyutu yoktur.

  • Kapasiteyi el ile yönetiyorsanız: Her havuz için her durumda ayrılmış ve Spot düğüm sayılarını almak için List Pool Node Counts işlemini kullanın. İşlem tek bir kullanılabilir düğüm sayısı döndürmez. running ve idle gibi görev özellikli durumları, unknown, offline, startTaskFailed ve unusable gibi kullanılamayan veya sorunlu durumlara karşı değerlendirin. Döndürülen sayılar güncel olmayabilir, bu nedenle kesin düğüm sayısına ihtiyacınız olduğunda havuzun işlem düğümlerini listeleyin.

Batch, düğümleri bölgeler arasında en iyi çaba temelinde dağıtır, bu nedenle gerçek dağıtım eşit olmayabilir. Kapasiteyi planlarken düğümlerin bölgeler arasında eşit olarak dağıtıldığını varsaymayın. İş yükünüzün daha az havuz kapasitesiyle kurtarma hedeflerini karşılayabildiğini doğrulayın.

Tüm bölgeler sağlıklı olduğunda davranış

Bu bölümde, Batch havuzu kullanılabilirlik alanı yerleşimini kullandığında ve tüm bölgeler çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

  • Bölgeler arası işlem: Batch, her düğümü içeren bölgeden bağımsız olarak havuz genelindeki kullanılabilir işlem düğümlerindeki görevleri zamanlar.

  • Kullanılabilirlik alanları arası veri çoğaltma: Batch işlem düğümleri kısa ömürlüdür ve Batch görev dosyalarını kullanılabilirlik alanları arasında çoğaltmaz. Düğüm kaybından sonra da korunması gereken giriş, çıkış, denetim noktaları ve tanılama verilerini kalıcı depolamaya taşımak sizin sorumluluğunuzdadır. Kullanılabilirlik gereksinimlerinizi karşılamak için depolama hesabı yedekliliğini yapılandırın.

Bölge hatası sırasındaki davranış

Bu bölümde, Batch havuzu kullanılabilirlik alanı yerleşimini kullandığında ve bir kullanılabilirlik alanı kullanılamadığında neler bekleyebileceğiniz açıklanmaktadır.

  • Algılama ve yanıt: Microsoft, Batch hizmetini ve işlem düğümü durumunu izler. Bir bölge hatası sırasında Batch, etkilenen düğümlerden gelen süregelen heartbeat kaybını algılar ve normal düğüm kurtarma işlemini başlatır. İyi durumdaki bölgelerdeki düğümler kullanılabilir durumda kalır ve Batch bu düğümlerde görevleri zamanlamaya devam edebilir.

    Batch, havuzu normal kurtarma işlemi aracılığıyla yapılandırılmış hedef düğüm sayısına geri getirmeyi dener, ancak bu hedefi artırmaz. Hedef iş yükü için yeterli kapasite sağlamıyorsa ek kapasite istemek sizin sorumluluğundadır.

  • Notification: Microsoft bir bölge kapatıldığında sizi otomatik olarak bilgilendirmez. Bununla birlikte, bölge hataları dahil olmak üzere hizmetin genel durumunu anlamak için Azure Hizmet Durumu'nı kullanabilir ve sorunları size bildirmek için Hizmet Durumu uyarıları ayarlayabilirsiniz.

  • Etkin görevler: Etkilenen düğümlerde çalışan görevler kesintiye uğrar. Batch, iç kurtarma davranışının bir parçası olarak kullanılabilir düğümlerde görevleri yeniden zamanlayabilir. Geçici hatalara dayanıklılık ve İşlem düğümü hatalarına dayanıklılık bölümünde açıklandığı gibi, görevleri yeniden denemeleri ve yeniden yürütmeyi tolere edecek şekilde tasarlayın.

  • Beklenen veri kaybı: Etkilenen işlem düğümleri üzerindeki dosyalar kesinti sırasında kullanılamaz ve düğümler yeniden imajlanır veya havuzdan kaldırılırsa kaybolur. Batch bu dosyaları bölgeler arasında çoğaltmaz. Dayanıklı depolamada kalıcı olan veriler, depolama kaynağının yedeklilik yapılandırmasına göre kullanılabilir durumda kalır.

  • Beklenen kesinti süresi: Sağlıklı düğümlerde görevler çalışmaya devam eder. Kesintiye uğrayan görevler, Batch bunları kullanılabilir düğümlere yeniden zamanlayabilene kadar kapalı kalma süresi yaşar. Kullanılabilir düğüm yoksa, bir görev, Batch bunu yeniden zamanlayana kadar running durumunda kalabilir. Kurtarma süresi, kullanılabilir havuz kapasitesine ve kuyruğa alınan iş yüküne bağlıdır.

    Hesap, denetim düzleminin bölge dayanıklılığına sahip olduğu bir bölgedeyse Batch hesaplarına ve diğer Batch kaynaklarına karşı yönetim işlemleri devam eder. Diğer bölgelerde, etkilenen bölge kurtulana kadar yönetim işlemleri kullanılamayabilir.

  • Yeniden dağıtım: Sürekli sinyal kaybından sonra Batch, etkilenen düğümleri unusable olarak işaretler ve normal düğüm kurtarma işlemi aracılığıyla bunların değiştirilmesi için gönderir. Batch, havuzu yapılandırılmış hedef düğüm sayısına geri getirmeyi dener, ancak değiştirme kapasitesi iyi durumdaki bölgelerde kotaya ve VM kullanılabilirliğine bağlıdır.

    İşler bu işlem sırasında havuzla ilişkili kalır. Batch, iyi durumdaki bölgelerdeki kullanılabilir düğümlerde etkin işlerden görevleri zamanlamaya devam eder. Değiştirme düğümleri ayrılır ve kullanılabilir hale gelirse, Batch görevleri bu düğümlerde de zamanlayabilir.

    Bu kurtarma işlemi yapılandırılan hedef düğüm sayısını artırmaz. İş yükünüz bu hedefin ötesinde kapasite gerektiriyorsa, bunu el ile artırın veya havuzun otomatik ölçeklendirme formülünü bunu yapacak şekilde yapılandırın.

Bölge kurtarma

Batch, bir bölge bir hatadan sonra kurtulduğunda kurtarma işlemini yönetir. Batch, Hesaplama düğümü hatalarına dayanıklılık bölümünde tanımlanan işlemi izler.

Batch, kurtarma sonrasında kullanılabilirlik alanları arasında düğümlerin eşit olarak yeniden dengeleneceğini garanti etmez. Bölge yerleşimi mümkün olan en iyi çabayla sürdürülür.

Bölge hataları için test

Test için gerçek bir Azure kullanılabilirlik alanı kesintisi simülasyonu yapamazsınız. Bunun yerine, temsili görevleri kesintiye uğratmak ve beklenen kapasite kaybını yaklaşık olarak simüle etmek için yeterli işlem düğümlerini hizmet dışına çıkarmak üzere üretim dışı bir havuz kullanın. Aşağıdaki desteklenen düğüm işlemlerini kullanmayı göz önünde bulundurun:

  • Seçili düğümleri yeniden başlatın.
  • Seçili düğümlerde görev zamanlamasını devre dışı bırakın.
  • Seçili düğümleri havuzdan kaldırın.

Bir işlem çalışan görevlerin nasıl işleneceğini seçmenize izin verdiğinde, Batch'in kalan düğümlerde kesilen görevleri zamanlaması için Yeniden kuyruğa al seçeneğini belirleyin.

Test sırasında Batch'in kesintiye uğrayan görevleri yeniden zamanladığını ve yeniden yürütmenin yinelenen veya tutarsız çıkış üretmediğini doğrulayın. Denetim noktalarının ve çıkışın dayanıklı depolamadan kullanılabilir durumda kaldığını, izlemenin düğüm kaybını ve azaltılmış kapasiteyi algıladığını ve iş yükünün kalan kapasiteyle tamamlanabildiğini onaylayın.

Bu işlemler görev kesintisini ve yeniden zamanlamayı, idempotentliği, denetim noktası oluşturmayı ve kalıcı çıktı işlemeyi doğrular. Ancak, bölge genelindeki bir hatanın her etkisini yeniden oluşturmaz.

Bölge genelindeki hatalara dayanıklılık

Batch hesabı ve havuzları tek bir Azure bölgesiyle sınırlıdır. Bölgede bir arıza yaşanırsa Batch işleriniz ve havuzlarınız etkilenebilir.

Batch, hesapları, havuz yapılandırmasını, işleri, görevleri, uygulama paketlerini veya görev verilerini başka bir bölgeye çoğaltmaz ve yerleşik bölgeler arası yük devretme sağlamaz. İş yükünüzün bölge genelindeki bir hataya tolerans göstermesi gerektiğinde çok bölgeli Batch çözümünü dağıtmak ve çalıştırmak sizin sorumluluğunuzdadır.

Dayanıklılık için özel çok bölgeli çözümler

Çok bölgeli bir çözüm oluşturmak için kurtarma tasarımınızın kullandığı her bölgeye en az bir Batch hesabı dağıtın. Batch hesapları bölgeler arasında bağımsız olarak çalışır. Bölgeleri seçmek, her bölgedeki kaynakları dağıtmak ve çalıştırmak ve yapılandırma, çoğaltma, yük devri ve geri yük devri işlemlerini koordine etmek sizin sorumluluğunuzdadır.

Normal çalışma sırasında birden çok bölgede çalışma gönderen etkin-etkin bir yaklaşım veya ikincil dağıtımı yük devretme için hazır tutan etkin-pasif bir yaklaşım tasarlayabilirsiniz. Aktif-aktif tasarımlar kurtarma süresini kısaltabilir çünkü her iki dağıtım da normal işlemler sırasında çalışmayı işlerken, aktif-pasif tasarımlar kararlı durum işlem maliyetlerini azaltabilir.

Aşağıdaki liste, çözümü tasarlarken sorumluluklarınıza örnekler sunar:

  • Dağıtım: Batch hesaplarını, havuzlarını veya havuz dağıtım tanımlarını, depolama hesaplarını, ağ kaynaklarını ve her bölgedeki diğer bağımlılıkları önceden oluşturun. Seçilen her bölgenin iş yükünüzün gerektirdiği Batch özelliklerini, VM boyutlarını ve bağımlı hizmetleri desteklediğini doğrulayın. Gereksiz gecikmeyi önlemek için mümkün olduğunda her Batch hesabını ve görevleri tarafından kullanılan depolama kaynaklarını aynı bölgede tutun. Yapılandırmanın bölgeler arasında tutarlı bir şekilde yeniden oluşturulabilmesi için kod olarak altyapıyı kullanarak Batch hesaplarını, havuzlarını ve destekleyici kaynakları tanımlayın.

  • Kotalar ve kapasite: Her kurtarma bölgesinde geçerli Batch hesabı, abonelik ve VM ailesi kotalarını doğrulayın ve gerektiğinde kesintiden önce artış talep edin. Kota bir sınırdır, kapasite garantisi değildir. VM kullanılabilirliği bölgeye, VM ailesine ve zamana göre değişir. Daha fazla bilgi için bkz. Batch hesabı ve çekirdek kotaları.

  • Veri çoğaltma: Uygulama paketlerini, kapsayıcı görüntülerini, giriş verilerini ve başvuru verilerini her kurtarma bölgesinde kullanılabilir durumda tutun. Batch bu öğeleri sizin için çoğaltıp oluşturmaz.

  • Depolama çoğaltması: Kurtarma noktası hedefinize göre depolama yedekliliğini ve bölgeler arası veri çoğaltmayı yapılandırın. Çoğaltılan verilere her kurtarma bölgesinden erişilebildiğini doğrulayın. Depolama güvenilirliği seçenekleri için bkz. Azure Blob Depolama'da Güvenilirlik.

  • Bölge hedefleme: Uygulamalarınız Batch hesabınızla çalışıyorsa, kod dağıtımı gerektirmeden başka bir Batch hesabıyla ve ilişkili depolama kaynaklarıyla çalışabilecek şekilde tasarlayın.

  • Yük devretme: Batch, iş yükünüzü otomatik olarak başka bir bölgeye taşımaz. Bir kesintiyi algılamaktan, kesintinin iş yükünüzü nasıl etkilediğini belirlemekten, etkilenen Batch hesabına gönderimleri durdurmaktan, yeni çalışmayı iyi durumdaki bir bölgedeki bir Batch hesabına yönlendirmekten ve kesintiye uğrayan işleri yeniden gönderip göndermemeye karar vermekten sorumlusunuz. Etkilenen bölgenin dışında kopyalamadığınız iş veya görev çıktısı kullanılamayabilir veya kaybolabilir. Kurtarma süreniz dağıtım modelinize, kullanılabilir kapasitenize, veri çoğaltmanıza ve otomasyonunuza bağlıdır.

  • Bölge kurtarma: Etkilenen bölgede hizmet kullanılabilirliği geri yüklendikten sonra, işi bu bölgeye yönlendirmeden önce Batch hesabını, havuzlarını, depolama bağımlılıklarını ve iş durumunu doğrulayın. Yeniden gönderimden önce yinelenen veya kısmen tamamlanmış görevleri uzlaştırın. Batch bu işlemi koordine etmez veya bölgesel hesaplar arasındaki durumu uzlaştırmaz.

  • Test etme: Üretim dışı bir ortamda bölgesel kurtarma işleminin tamamını düzenli olarak test edin. Bir bölgesel dağıtımın kullanılamaz hale geldiğini simüle edin, gönderimleri başka bir bölgesel Batch hesabına yönlendirin, uygulama paketlerine ve giriş verilerine erişimi doğrulayın, temsili işler çalıştırın, çıktıları toplayın ve kurtarılan dağıtımı hizmete döndürme alıştırması yapın. Sonuçları kurtarma süresi hedefinize ve kurtarma noktası hedefinize göre ölçün.

Yedekleme ve geri yükleme

Azure Batch, iş yükü giriş ve çıkış verileri için dayanıklı bir depo değildir. Microsoft Batch hizmetini korur, ancak iş yükünüzü yeniden oluşturmak için gereken yapılandırmayı ve verileri korumak sizin sorumluluğunuzdadır:

  • Batch yapılandırması: Bicep ve sürüm denetimli iş tanımları gibi kod olarak altyapıyı kullanarak Batch hesaplarını, havuzlarını, işlerini ve destekleyici kaynakları tanımlayın. Bu artefaktlar, yapılandırmayı aynı bölgede veya başka bir bölgede yeniden oluşturmak için yinelenebilir bir yol sağlar. Tanımların düzenli olarak bir havuz oluşturup temsili bir iş çalıştırabildiğini test edin.

  • Batch meta verileri: Batch, ilişkili işi veya görevi silene kadar iş ve görev kayıtlarını korur, ancak bu kayıtlar yedek değildir. Bu geçmişi saklamanız gerekiyorsa, Batch dışında gerekli kayıtları koruyun.

  • İşlem düğümleri üzerindeki veriler: İşlem düğümleri kısa ömürlü olur ve dosya sistemleri bir yedekleme veya dayanıklı depo değildir. Düğüm yeniden oluşturulduğunda veya havuzdan ayrıldığında düğümdeki veriler kaybolur. Batch, saklama süreleri dolduktan sonra görev dosyalarını da silebilir. Görev tamamlanmadan önce gerekli çıkış ve tanılama günlüklerini dayanıklı depolamada kalıcı hale getirin Uzun süre çalışan görevler için yürütme sırasında kontrol noktalarını kalıcı hale getirin. Daha fazla bilgi için bkz. İş ve görev çıktısını kalıcı hale getirme ve Azure Batch'i izleme.

  • Autostorage hesaplarındaki veriler: İlişkili bir autostorage hesabı, uygulama paketlerini ve görev kaynak dosyalarını barındırabilir. Kurtarma hedeflerinizi karşılayan yedekliliği yapılandırmaya ek olarak, bu verileri yanlışlıkla silmeye veya bozulmaya karşı korumanız gerekip gerekmediğini göz önünde bulundurun. Daha fazla bilgi için bkz. Azure Blob Depolama'da yedekleme ve kurtarma.

Geri yükleme ve kurtarma testi

Kurtarmak için Batch ve destekleyici kaynak yapılandırmasını dağıtın, gerekli giriş verilerini ve uygulama yapıtlarını geri yükleyin veya yeniden bağlayın ve tamamlanmamış işleri yeniden gönderin. Yalıtılmış veya üretim dışı bir kurtarma ortamında hem kaynak yeniden yapılandırmayı hem de veri geri yüklemeyi düzenli aralıklarla test edin. Sürüm denetimli tanımları ve yedeklenen verileri kullanın, temsili bir iş çalıştırın, sonuçta elde edilen çıkışı ve bağımlılıklara erişimi doğrulayın ve elde edilen kurtarma süresini ve kurtarma noktasını hedeflerinize göre ölçün. Görevlerin idempotent olduğunu doğrulayın, böylece durumu belirsiz işi yeniden göndermek verileri bozmaz veya yinelenen çıktı oluşturmaz.

Hizmet bakımına dayanıklılık

Microsoft platform bakımı gerçekleştirir ve Azure Batch ve diğer hizmetler için altyapı güncelleştirmelerini koordine eder. Havuz güncelleştirme davranışını yapılandırmak ve kesintiyi tolere etmek için görevler tasarlamak sizin sorumluluğundadır.

  • Ana bilgisayar bakımı: Azure mümkün olduğunda canlı geçiş gibi bakım tekniklerini kullanır. Bakım, bir işlem düğümünün yeniden başlatılmasını veya taşınmasını gerektiriyorsa, çalışan görevler kesintiye uğrayabilir ve Batch bunları yeniden zamanlayabilir. Görevleri idempotent hale getirin ve denetim noktalarını ve çıkışı dayanıklı depolamaya kalıcı olarak yazın.

  • Konuk işletim sistemi: Konuk işletim sistemini ve Batch düğümü aracısını güncel tutmak sizin sorumluluğundadır. İşletim sistemi güncelleştirme davranışı, görüntüye ve güncelleştirme yapılandırmasına bağlıdır. Uygun yapılandırma ile Batch havuzları için otomatik işletim sistemi görüntüsü yükseltmeleri , çalışan görevleri kesintiye uğratmadan havuz düğümlerini güncelleştirebilir. Otomatik işletim sistemi görüntüsü yükseltmeleri her Batch işletim sistemi görüntüsünü desteklemez.

  • Düğüm aracısı güncelleştirmeleri: Otomatik işletim sistemi görüntü yükseltmeleri Batch düğümü aracısını otomatik olarak güncelleştirmez. Bir havuzda işlem düğümleri varken toplu düğüm aracıları otomatik olarak yükseltilmez. Daha yeni bir düğüm aracısı almak için havuzu sıfır düğüme yeniden boyutlandırın ve ölçeğini tekrar artırın veya havuzu değiştirin. Düğümleri kaldırmadan önce, gerekli görev çıktılarını ve tanılama günlüklerini koruyun. Daha fazla bilgi için bkz. Batch düğümü aracısı güncelleştirmeleri.

Bakım görevleri kestiğinde veya işlem düğümlerini kullanılamaz hale getirdiğinde iş yükünüzün devam etmesi veya kurtarılması için üretim dağıtımı önerilerini ve işlem düğümü hatası kılavuzunu izleyin.

Hizmet düzeyi sözleşmesi

Azure hizmetleri için hizmet düzeyi sözleşmesi (SLA), her hizmetin beklenen kullanılabilirliğini ve bu kullanılabilirlik beklentisini elde etmek için çözümünüzün karşılaması gereken koşulları açıklar. Daha fazla bilgi için, çevrimiçi hizmetlere yönelik SLA'lara bakın.

Azure Batch kullanılabilirlik SLA'sı Batch API'sinde gerçekleştirdiğiniz işlemler için geçerlidir. Dahil edilen işlem türleri hakkında ayrıntılı bilgi için SLA metnini gözden geçirin. Havuz boyutunuz, bölge dağıtımınız ve bağımlı hizmetleriniz iş yükünün uçtan uca kullanılabilirliğini etkiler ancak Batch SLA koşullarını değiştirmez.

İlgili içerik

  • Son güncelleştirme: