Spolehlivost v Azure Batch

Azure Batch v Azure spouští rozsáhlé paralelní dávkové úlohy a úlohy vysokovýkonného počítání (HPC). Služba Batch vytváří a spravuje fondy výpočetních uzlů, instaluje aplikace, které chcete spustit, a plánuje spouštění úloh na uzlech.

Při používání Azure je spolehlivost sdílenou odpovědností. Microsoft nabízí celou řadu možností, které podporují odolnost a obnovení. Zodpovídáte za pochopení toho, jak tyto možnosti fungují ve všech službách, které používáte, a výběrem možností, které potřebujete ke splnění vašich obchodních cílů a cílů dostupnosti.

Tento článek popisuje, jak zajistit odolnost Azure Batch vůči přechodným chybám, selháním výpočetních uzlů, selháním zón dostupnosti, selháním celého regionu a údržbě služby. Popisuje také doporučení pro produkční nasazení, architekturu spolehlivosti služby Batch, zálohování a obnovení a klíčové informace o smlouvě o úrovni služeb (SLA) Azure Batch.

Doporučení pro nasazení do produkčního prostředí

V případě produkčních úloh postupujte podle osvědčených postupů pro Azure Batch, včetně těchto doporučení pro spolehlivost:

  • Navrhujte úkoly tak, aby tolerovaly přerušení a opětovné provedení. Vytvářejte idempotentní úkoly, vytvářejte kontrolní body u dlouhotrvajících úloh a ukládejte požadovaný výstup a diagnostická data do trvalého úložiště. Další informace najdete v tématech Odolnost proti přechodným chybám a Odolnost vůči selhání výpočetních uzlů.

  • Pokud vaše úloha musí pokračovat po selhání uzlu, použijte několik výpočetních uzlů. U jednotlivých výpočetních uzlů není zaručeno, že zůstanou dostupné. Zajistěte dostatek uzlů, aby zbývající použitelné uzly mohly spouštět přeplánované úlohy.

  • Pokud je to podporováno, použijte umístění v zóně dostupnosti. Nakonfigurujte umístění do zón dostupnosti, pokud je podporují oblast, SKU virtuálního počítače (VM) a konfigurace úloh. Uzly v zónách, které jsou v pořádku, můžou dál spouštět úlohy během výpadku zóny, ale počítejte se sníženou kapacitou, protože náhradní kapacita závisí na kvótě a dostupnosti virtuálních počítačů v zónách, které jsou v pořádku. Další informace najdete v tématu Odolnost proti chybám zóny dostupnosti.

  • Navrhujte úlohy tak, aby dynamicky cílily na fondy, místo na pevné ID fondu. Toto řešení umožňuje změnit cílení úlohy na fond, který je v pořádku, pokud původní fond přestane být dostupný nebo se nepodaří škálovat na požadovanou kapacitu. Zlepšuje provozní kontinuitu během údržby nebo selhání poolu.

  • Udržujte konfigurace poolu aktuální. Monitorujte data ukončení podpory (EOL) služby Batch pro image VM a SKU a migrujte fondy před EOL. Postupujte podle pokynů k údržbě služby a udržujte agenta uzlu Batch aktuální.

Přehled architektury spolehlivosti

Tato část popisuje některé důležité aspekty fungování služby, které jsou z hlediska spolehlivosti nejrelevantní. Tato část představuje logickou architekturu, která obsahuje některé prostředky a funkce, které nasazujete a používáte. Popisuje také fyzickou architekturu, která poskytuje podrobnosti o tom, jak služba funguje v zákulisí.

Logická architektura

Azure Batch ke spouštění dávkových úloh používá několik typů prostředků. Konfigurace těchto prostředků určuje, jak vaše úloha reaguje na selhání.

Veškeré zpracování Batch a prostředky jsou přidruženy k účtu Batch. Řešení Batch používá následující logické komponenty:

  • Účet Batch: Regionální zdroj, ke kterému jsou přidružené fondy, úlohy, úkoly a další zdroje služby Batch. Vytvoříte účet a vyberete jeho oblast, režim přidělování fondů a nastavení ověřování.

  • Pool: Kolekce výpočetních uzlů, na kterých běží úlohy. Konfigurace fondu uzlů definuje image a velikost virtuálního počítače, počet cílových uzlů, chování škálování, sítě a umístění zóny. Každý fond nakonfigurujete tak, aby poskytoval kapacitu, umístění a provozní prostředí, které vaše pracovní zátěž vyžaduje. Počet cílových uzlů je požadovaná kapacita, ale počet přidělených uzlů může být nižší kvůli limitům kvót, omezením kapacity nebo selháním přidělení.

  • Úloha a úkoly:Úloha spravuje kolekci úkolů a je přidružená k fondu. Úloha spouští aplikaci nebo skript na výpočetním uzlu. Definujete úlohy, úkoly, omezení, závislosti, chování opakování a fond prostředků, ve kterém se jednotlivé úlohy spouštějí.

  • Přidružený účet úložiště: Účet Azure Storage, který můžete volitelně propojit s účtem Batch. Většina řešení Batch používá přidružený účet úložiště pro soubory aplikací, soubory prostředků úkolů, vstupní data a výstupní data.

    Po propojení účtu úložiště s účtem Batch na něj služba Batch odkazuje jako na účet automatického úložiště. Pro balíčky aplikací se vyžaduje účet autostorage; ten může také ukládat soubory prostředků úloh.

    Spolehlivost řešení Batch závisí na prostředcích úložiště. Zodpovídáte za výběr konfigurace redundance úložiště, která splňuje vaše požadavky na obnovení při vytváření účtu úložiště. Přesuňte výstup úkolu a další odolná data z výpočetních uzlů do úložiště. Informace o možnostech spolehlivosti služby Azure Storage najdete v tématu Spolehlivost v Azure Blob Storage.

Další informace najdete v tématech Pracovní postup služby Batch a prostředky a účty Batch a účty Azure Storage.

Fyzická architektura

Azure Batch má regionální řídicí vrstvu, která zpracovává operace správy nad účty Batch a dalšími prostředky služby Batch, jako jsou fondy, úlohy a úkoly. Je oddělená od výpočetních uzlů, které spouští úlohy.

fondy prostředků Azure Batch používají Azure Virtual Machines a Virtual Machine Scale Sets. Výpočetní uzel je virtuální počítač, který zpracovává část úlohy Batch. Každý uzel patří do fondu a provádí úkoly, které mu služba Batch přiřadí. Agent uzlu Batch běží na každém uzlu a poskytuje rozhraní pro příkazy a řízení mezi uzlem a službou Batch. Výpočetní uzly a jejich místní úložiště jsou neperzistentní. Když uzel opustí fond, ztrácejí se změny v jeho operačním systému a souborech.

Režim přidělování fondů účtu Batch určuje, kde Služba Batch vytváří výpočetní prostředky a prostředky související s virtuálními počítači:

  • Režim přidělování fondů služby Batch: Služba Batch přidělí prostředky v předplatných Azure spravovaných službou Batch.
  • Režim přidělování fondu uživatelského předplatného: Služba Batch vytvoří prostředky přímo v předplatném, které obsahuje účet Batch.

Odpovědnosti za fyzickou architekturu jsou rozděleny takto:

  • Microsoft: Microsoft provozuje regionální control plane služby Batch a infrastrukturu služeb. Služba Batch zřídí výpočetní uzly podle konfigurace fondu a dostupné kapacity, naplánuje úlohy, monitoruje stav uzlu a pokusí se obnovit uzly po selhání infrastruktury. Služba Batch může znovu zařadit přerušené úlohy do fronty pro spuštění na jiném dostupném uzlu.

  • Vy: Vyberete image a velikost virtuálního počítače, typy uzlů, počet cílových uzlů, konfiguraci škálování, sítě a umístění zóny dostupnosti.

    Zodpovídáte také za udržování dostatečné kapacity pro tolerování selhání uzlů, monitorování stavu uzlů a úkolů, udržování operačního systému hosta a agenta uzlu v aktuálním stavu, navrhování úloh pro tolerování opětovného provedení a přesouvání trvalých dat z výpočetních uzlů.

Obnovení uzlu služby Batch nezaručuje, že zatížení pokračuje bez přerušení. Další informace najdete v tématu Odolnost proti selhání výpočetních uzlů.

Odolnost proti přechodným chybám

Přechodné chyby jsou krátká, přerušovaná selhání ve složkách. V distribuovaném prostředí, jako je cloud, se vyskytují často a jsou normální součástí provozu. Přechodné chyby se opravují po krátké době. Je důležité, aby vaše aplikace mohly zpracovávat přechodné chyby, obvykle opakováním ovlivněných požadavků.

Všechny aplikace hostované v cloudu by měly postupovat podle Azure pokynů pro zpracování přechodných chyb, když komunikují s libovolnými rozhraními API, databázemi a dalšími komponentami hostovanými v cloudu. Další informace viz Doporučení pro zpracování přechodných selhání.

V rámci řešení Batch můžou přechodné chyby ovlivnit aplikace i skripty, které běží jako úlohy, a všechny aplikace, které volají rozhraní API služby Batch ke správě prostředků Batch. Služba Batch poskytuje mechanismy opakovaných pokusů na úrovni úloh. Zodpovídáte za konfiguraci omezení úloh, zajištění idempotence úloh (bezpečných pro opakované spuštění) a konfiguraci chování opakování pro volání služby Batch a dalších závislostí.

Opakování úkolů a časové limity

Nakonfigurujte maxTaskRetryCount, abyste mohli řídit, kolikrát Batch opakuje úlohu poté, co proces skončí s nenulovým ukončovacím kódem:

  • Výchozí hodnota 0 znamená, že služba Batch neopakuje úkol po nenulovém ukončovacím kódu.
  • Kladné celé číslo nastaví maximální počet opakování po počátečním pokusu.
  • Hodnota -1 umožňuje neomezený počet opakovaných pokusů. Tato hodnota se nedoporučuje, protože trvalá chyba může způsobit, že úloha poběží neomezeně dlouho.

Navrhni každou úlohu tak, aby byla idempotentní, aby opakované pokusy nezpůsobily poškození dat nebo duplicitní výstup. U dlouhotrvajících úloh použijte vytváření kontrolních bodů, aby opakovaný pokus mohl pokračovat z uloženého stavu. Další informace najdete v tématu Návrh opakování a opětovného provedení.

maxWallClockTime Nastavte omezení úkolu nebo úlohy tak, aby ukončila práci, která nepostupuje v přijatelné době. Časový limit také omezuje účinek opakovaných selhání. Vyberte počty opakovaných pokusů a časové limity, které odpovídají cílům zotavení úlohy.

Přechodné chyby v závislostech úkolů

Aplikace a skripty, které běží jako úlohy služby Batch, často volají další komponenty, jako jsou Azure Storage, databáze nebo rozhraní API. Služba Batch nespravuje jednotlivé požadavky, které kód úkolu odesílá do těchto závislostí. Implementujte zpracování přechodných chyb v kódu úlohy nebo použijte funkce opakování poskytované sadou SDK závislosti. Postupujte podle pokynů jednotlivých závislostí a identifikujte chyby, u kterých lze opakovat pokus, vyberte odpovídající nastavení prodlevy a časového limitu a dodržujte pokyny pro opakované pokusy, jako je záhlaví Retry-After. Opakujte pouze operace, které jsou bezpečné k opakování.

Pokud selhání závislosti způsobí, že proces úkolu skončí s nenulovým ukončovacím kódem, může služba Batch opakovat celý úkol podle maxTaskRetryCount. Služba Batch ale v rámci spuštěné úlohy nezopakuje jednotlivý požadavek závislosti.

Opakování pokusů o požadavky rozhraní API služby Batch

Aplikace spuštěné mimo službu můžou volat rozhraní API služby Batch k vytváření a správě fondů, úloh, úkolů, výpočetních uzlů a dalších prostředků služby Batch. Nakonfigurujte tyto klienty pomocí zásad opakování s intervalem alespoň pět minut pro zpracování přechodných selhání služby Batch nebo sítě.

Pokud je k dispozici, použijte integrovanou podporu opakování pokusů v sadě SDK. Například klientská knihovna Azure.Compute.Batch pro .NET zpřístupňuje chování opakování prostřednictvím Azure.Core možností opakování.

Pokud pracujete přímo s rozhraními API služby Batch z vašeho kódu, počkejte několik sekund před dalším pokusem, použijte exponenciální prodlužování intervalu s randomizací (jitter), abyste se vyhnuli synchronizovaným žádostem o opakování, a respektujte hlavičku Retry-After vrácenou při odpovědích při omezení požadavků, například 429 Too Many Requests a 503 Service Unavailable.

Časový limit požadavku nemusí nutně znamenat, že se službě Batch nepodařilo požadavek zpracovat. Po vypršení časového limitu zkuste operaci zopakovat, pokud je to bezpečné, nebo načtěte stav prostředku, abyste zjistili, jestli původní operace proběhla úspěšně. Další informace najdete v tématu Zpracování a detekce chyb v Azure Batch.

Odolnost vůči selhání výpočetních uzlů

Výpočetní uzel se může stát nedostupným kvůli selhání infrastruktury, problému s operačním systémem nebo problému s konfigurací. Služba Batch se pokusí obnovit uzly ovlivněné selháními infrastruktury, ale nemůže automaticky vyřešit každé selhání související s konfigurací. Pokud se například balíček aplikace nebo kontejner nepodaří nainstalovat, musíte opravit základní problém a možná budete muset odebrat a nahradit ovlivněný uzel.

Pokud selhání uzlu přeruší úlohu, může služba Batch úlohu opakovat na stejném uzlu, pokud je to možné, až do interního limitu. Pokud úkol nemůže pokračovat v daném uzlu, služba Batch ho může znovu zařadit do fronty pro spuštění na jiném dostupném uzlu. Tyto pokusy o obnovení řízené službou jsou nezávislé na maxTaskRetryCount a mohou nastat i v případě, že je jeho hodnota 0.

proces obnovení uzlu spravovaného Microsoft

Microsoft spravuje obnovení uzlů řízené službami a opětovné zařazení úloh do fronty. Pokud služba Batch přestane přijímat signály životnosti z uzlu dostatečně dlouho, aby aktivovala obnovení, může služba Batch provést následující akce:

  1. Izolujte uzel: Služba Batch považuje uzel za nezdravý, nastaví jeho stav na unusable a zastaví plánování nových úkolů na něm.
  2. Identifikace ovlivněných úkolů: Služba Batch identifikuje úkoly spuštěné na uzlu jako kandidáty pro přeplánování.
  3. Znovu zařadit způsobilé úkoly do fronty: Pokud je ovlivněný úkol stále ve running stavu, může ho služba Batch resetovat active , aby ho plánovač mohl přiřadit jinému uzlu. Služba Batch neobnoví nebo znovu nespustí úlohu, která už je v perzistovaném stavu completed.
  4. Obnovte uzel: Služba Batch se pokusí obnovit uzel do stavu v pořádku nebo nahradit základní virtuální počítač.

Obnovení není okamžité. Úkol může zůstat ve running stavu, zatímco Služba Batch zjistí selhání uzlu a pokusí se úkol přeplánovat. Pokud není k dispozici žádný jiný výpočetní uzel, může úloha zůstat v daném stavu, dokud ji služba Batch nedokáže přeplánovat. Další informace najdete v tématu Známá omezení pro úlohy služby Batch.

Pokud původní uzel obnoví zdravé signály heartbeat před zahájením výměny, služba Batch jej může vrátit do stabilního stavu. Pokud už bylo nahrazení zahájeno, služba Batch místo toho může původní virtuální počítač odebrat a zřídit náhradu.

Vaše odpovědnosti

Obnovení řízené službou nezaručuje nepřerušené provádění úloh ani dostatečnou zbývající kapacitu. Zodpovídáte za následující akce:

  • Udržujte dostatečnou kapacitu: Pokud vaše pracovní zátěž musí pokračovat, i když je uzel nedostupný, zřiďte dostatek uzlů pro zbývající uzly, aby bylo možné spouštět přeplánované úlohy. Bez jiného použitelného uzlu musí přerušené úkoly čekat.

  • Monitorování využitelné kapacity: Sledujte počty a stavy agregovaných uzlů, abyste mohli zjistit, kdy už fond nemá dostatek využitelných uzlů pro vaši úlohu. Stavy jako unusable, startTaskFailed, unknown a preempted indikují sníženou kapacitu. Další informace najdete v tématu Monitorování řešení batch počítáním úkolů a uzlů podle stavu.

  • Prozkoumejte problémové uzly: Pokud úkoly opakovaně selžou, znovu se zařadí do fronty nebo zůstanou ve running stavu, jakmile se jejich přiřazený uzel stane nepoužitelným nebo opustí fond, použijte metadata úkolů k určení, jestli jsou problémy přidružené ke konkrétnímu uzlu.

    Než odeberete problémový uzel, nahrajte jeho protokoly agenta uzlu Batch a zachovejte relevantní protokoly úloh, protože odebráním uzlu se odstraní místní soubory. Protokoly agenta uzlu můžou pomoct podpora Microsoftu diagnostikovat problémy se službou Batch nebo s uzly, zatímco protokoly úloh, jako jsou stdout a stderr, vám můžou pomoct identifikovat problémy s aplikací a konfigurací. Další informace najdete v tématu Soubory protokolů agenta Node.

  • Ochrana průběhu úkolů a dat: Navrhujte úkoly tak, aby tolerovaly přerušení a opětovné provedení. Přesuňte kontrolní body, výstup a další trvalá data z výpočetních uzlů, protože jejich místní úložiště je dočasné.

Další informace najdete v tématu Chyby fondů a uzlů ve službě Azure Batch a v tématu Zpracování a zjišťování chyb v Azure Batch.

Odolnost proti chybám zóny dostupnosti

Zóny dostupnosti jsou fyzicky oddělené skupiny datacenter v rámci oblasti Azure. Když jedna zóna selže, mohou služby přejít na jednu ze zbývajících zón.

Batch podporuje zóny dostupnosti dvěma hlavními způsoby:

  • Řídicí vrstva: Řídicí vrstva Batch je v mnoha oblastech odolná vůči výpadku zóny. V těchto oblastech můžou operace správy účtů Batch a dalších prostředků služby Batch pokračovat během selhání zóny. Microsoft nepublikuje, které oblasti poskytují tuto odolnost řídicí roviny.

  • Pooly: Pool Batch můžete nakonfigurovat tak, aby používal umístění zóny dostupnosti. Pokud se zóna stane nedostupnou, výpočetní uzly v zónách, které jsou v pořádku, zůstanou dostupné pro plánování úkolů.

    U umístění výpočetních uzlů se tento model podpory podobá redundanci zón v jiných službách Azure, protože jeden fond může obsahovat výpočetní uzly v několika zónách dostupnosti. Služba Batch ale distribuuje uzly napříč zónami v rámci možností. Pokusí se použít všechny zóny v oblasti, ale nezaručuje umístění v každé zóně nebo rovnoměrné distribuci. Nemůžete vybrat konkrétní zóny ani řídit počet uzlů umístěných v každé zóně.

Následující diagram znázorňuje příklad účtu Batch. Účet má jeden pool se svými uzly distribuovanými napříč třemi zónami dostupnosti:

Diagram znázorňující fond Batch s výpočetními uzly distribuovanými napříč třemi zónami dostupnosti

Zodpovídáte za to, aby další závislé prostředky, jako jsou účty úložiště, byly zónově odolné. Projděte si příručky ke spolehlivosti jednotlivých služeb. Další informace najdete v průvodcích spolehlivosti pro služby Azure.

Requirements

Distribuce instancí napříč zónami

Když povolíte umístění do zón dostupnosti, služba Batch se pokusí přidělit výpočetní uzly napříč všemi zónami dostupnosti ve vybraném regionu. Toto přidělení se provádí bez záruky. Batch řídí distribuci a počet uzlů v každé zóně nemusí být stejný.

Cost

Služba Batch nepřidá poplatek za povolení umístění do zóny dostupnosti. Jsou vám účtovány náklady za výpočetní prostředky, úložiště, sítě a další prostředky Azure používané úlohou. Pokud zřídíte další uzly, aby bylo možné tolerovat výpadek zóny, za tyto uzly se účtují jejich běžné poplatky. Další informace najdete v tématu o cenách služby Azure Batch.

Konfigurujte podporu zón dostupnosti

  • Vytvořte nový fond s umístěním zóny dostupnosti: Pokud chcete vytvořit fond s povoleným umístěním zóny dostupnosti, přečtěte si téma Vytvoření fondu Batch napříč zónami dostupnosti.

  • Změňte umístění zóny dostupnosti ve stávajícím fondu: Při vytváření fondu musíte vybrat umístění zóny dostupnosti. Existující fond nemůžete změnit tak, aby používal zóny dostupnosti.

    Pomocí následujících kroků můžete vytvořit fond náhradních instancí a aktualizovat každou svou úlohu tak, aby ho používala:

    1. Zakažte úlohu: Použijte operaci Zakázat úlohu a vyberte, jak Služba Batch zpracovává úkoly, které jsou spuštěné při odeslání požadavku:

      • Čekání: Služba Batch přestane spouštět nové úkoly a umožní běžícím úkolům dokončit se ve stávajícím fondu. Úloha zůstane ve disabling stavu, dokud se spuštěné úkoly nedokončí.
      • Opětovné zařazení do fronty: Služba Batch přeruší spuštěné úlohy a vrátí je do fronty. Úkoly se můžou spustit znovu po povolení úlohy.
      • Ukončit: Služba Batch přeruší běžící úkoly a označí je jako dokončené s informacemi o selhání, které indikují, že byly ukončeny. Po povolení jobu se úkoly znovu nespustí.

      Úlohy, které už jsou ve active stavu, což znamená, že jsou ve frontě, ale nejsou spuštěné, zůstanou ve frontě bez ohledu na zvolenou možnost.

      Než budete pokračovat, počkejte, až úloha dosáhne disabled stavu. V tomto okamžiku nejsou spuštěné žádné úkoly a Služba Batch nebude plánovat nové úkoly.

    2. Upravte fond úlohy: Pomocí operace Aktualizovat úlohu nastavte poolInfo.poolId úlohy na náhradní fond. Služba Batch povoluje změnu této vlastnosti pouze tehdy, když je úloha ve stavu disabled. Před povolením úlohy se ujistěte, že replacement pool existuje a má použitelnou kapacitu. Pokud fond neexistuje, služba Batch tuto aktualizaci přijme, ale nemůže plánovat úkoly, dokud fond nevytvoříte.

    3. Povolte úlohu: Použijte operaci Povolit úlohu . Úloha přejde přes stav enabling do stavu active. Batch pak naplánuje úkoly zařazené do fronty, včetně úkolů vrácených do fronty pomocí možnosti Znovu zařadit do fronty, v náhradním fondu. Úkoly, které se dokončily, když služba Batch použila možnost Čekat, a úkoly dokončené možností Ukončit se znovu nespustí.

Plánování a řízení kapacit

Běžný proces obnovení uzlů služby Batch se pokusí nahradit uzly, které se během selhání zóny stanou nepoužitelnými, a obnovit fond na nakonfigurovaný cílový počet uzlů. Nezvyšuje tento cíl. Pokud chcete zachovat dostatečnou kapacitu pro úlohu, aby pokračovala v případě nedostupnosti jedné zóny, zvažte navýšení kapacity fondu pomocí automatického škálování nebo ručně:

  • Pokud používáte automatické škálování: Odkazujte ve vzorci automatického škálování fondu na $UsableNodeCount proměnnou definovanou službou, abyste zjistili, kdy použitelná kapacita klesne pod výchozí úroveň, kterou vaše úloha vyžaduje. $UsableNodeCount je proměnná automatického škálování služby Batch pro fond, jehož vzorec se vyhodnocuje, nikoli metrika služby Azure Monitor. Azure Monitor publikuje metriky počtu uzlů batch v rozsahu účtu Batch a tyto metriky nemají dimenzi poolId.

  • Pokud kapacitu spravujete ručně: Pomocí operace List Pool Node Counts načtěte počet vyhrazených a spotových uzlů v každém stavu pro každý fond. Operace nevrací jediný počet použitelných uzlů. Vyhodnoťte stavy schopné plnit úkoly, jako jsou idle a running, proti nedostupným nebo problémovým stavům, jako jsou unusable, unknown, offline a startTaskFailed. Vrácené počty nemusí být aktuální, proto spočítejte výpočetní uzly fondu v případě, že potřebujete přesný počet.

Služba Batch distribuuje uzly napříč zónami podle možností, takže skutečná distribuce nemusí být stejná. Nepředpokládejte při plánování kapacity, že uzly se rovnoměrně distribuují napříč zónami. Ověřte, že vaše pracovní zátěž může splňovat cíle obnovy s omezenou kapacitou fondu.

Chování, když jsou všechny zóny v pořádku

Tato část popisuje, co očekávat, když fond Batch používá umístění zóny dostupnosti a všechny zóny jsou funkční.

  • Operace napříč zónami: Služba Batch naplánuje úkoly na dostupných výpočetních uzlech v celém fondu bez ohledu na zónu, která obsahuje každý uzel.

  • Replikace dat mezi zónami: Výpočetní uzly batch jsou dočasné a Služba Batch nereplikuje soubory úkolů mezi zónami. Zodpovídáte za přesun vstupu, výstupu, kontrolních bodů a diagnostických dat, která musí přežít ztrátu uzlu do odolného úložiště. Nakonfigurujte redundanci účtu úložiště tak, aby splňovala vaše požadavky na dostupnost.

Chování při selhání zóny

Tato část popisuje, co očekávat, když fond Batch používá umístění zóny dostupnosti a jedna zóna dostupnosti není k dispozici.

  • Detekce a odpověď: Microsoft monitoruje stav služby Batch a výpočetních uzlů. Během selhání zóny služba Batch detekuje trvalou ztrátu signálu heartbeat z ovlivněných uzlů a spustí normální proces obnovení uzlu. Uzly v zónách, které jsou v pořádku, zůstanou dostupné a služba Batch může pokračovat v plánování úkolů.

    Služba Batch se pokusí obnovit fond na nakonfigurovaný cílový počet uzlů prostřednictvím normálního procesu obnovení, ale tento cílový počet nezvyšuje. Zodpovídáte za vyžádání další kapacity, pokud cílový prostředek neposkytuje dostatečnou kapacitu pro pracovní zátěž.

  • Oznámení: Microsoft vás při výpadku zóny automaticky neoznámí. Můžete ale použít Azure Service Health k pochopení celkového stavu služby, včetně jakýchkoli selhání zón, a můžete nastavit upozornění služby Service Health, která vás upozorní na problémy.

  • Aktivní úkoly: Úlohy spuštěné na ovlivněných uzlech jsou přerušeny. Služba Batch může přeplánovat úlohy na dostupných uzlech v rámci svého interního mechanismu obnovení. Navrhujte úkoly tak, aby tolerovaly opakování a opětovné provedení, jak je popsáno v tématu Odolnost vůči přechodným chybám a odolnosti vůči selhání výpočetních uzlů.

  • Očekávaná ztráta dat: Soubory na ovlivněných výpočetních uzlech nejsou během výpadku dostupné a soubory se ztratí, pokud jsou uzly přeimageovány nebo odebrány z fondu. Batch tyto soubory nereplikuje napříč zónami. Data uložená v trvalém úložišti zůstávají dostupná podle konfigurace redundance daného prostředku úložiště.

  • Očekávaný výpadek: Úlohy na uzlech, které jsou v pořádku, pokračují. Přerušené úlohy mají výpadek, dokud služba Batch nebude moct přeplánovat je na použitelné uzly. Pokud není k dispozici žádný použitelný uzel, může úloha zůstat ve running stavu, dokud ji služba Batch nedokáže přeplánovat. Doba obnovení závisí na dostupné kapacitě fondu a na zatížení ve frontě.

    Operace správy s účty Batch a dalšími prostředky služby Batch pokračují, pokud je účet v oblasti, kde je řídicí rovina odolná vůči zóně. V jiných oblastech můžou být operace správy nedostupné, dokud se ovlivněná zóna neobnoví.

  • Redistribuce: Po trvalé ztrátě signálu heartbeat služba Batch označí ovlivněné uzly jako unusable a odešle je k jejich nahrazení prostřednictvím normálního procesu obnovení uzlů. Služba Batch se pokusí obnovit fond do nakonfigurovaného počtu cílových uzlů, ale náhradní kapacita závisí na kvótě a dostupnosti virtuálních počítačů v zónách, které jsou v pořádku.

    Během tohoto procesu zůstanou úlohy přidružené k fondu. Služba Batch pokračuje v plánování úkolů z aktivních úloh na použitelných uzlech v zónách, které jsou v pořádku. Pokud jsou náhradní uzly přiděleny a použitelné, může služba Batch také plánovat úkoly na těchto uzlech.

    Tento proces obnovení nezvyšuje nakonfigurovaný počet cílových uzlů. Pokud vaše úloha vyžaduje kapacitu nad rámec tohoto cíle, zvyšte ji ručně nebo nakonfigurujte vzorec automatického škálování fondu tak, aby to provedl.

Obnovení zóny

Služba Batch spravuje proces obnovy po selhání, když se zóna obnoví po selhání. Batch se řídí stejným procesem, který je definovaný v Odolnost proti selhání výpočetních uzlů.

Služba Batch nezaručuje, že uzly jsou po obnovení rovnoměrně vyváženy napříč zónami dostupnosti. Umístění zóny se nadále provádí podle nejlepších možností.

Testování poruch zón

Pro účely testování nemůžete simulovat skutečný výpadek zóny dostupnosti Azure. Místo toho použijte neprodukční fond k přerušení reprezentativních úloh a vyřaďte z provozu dostatek výpočetních uzlů, aby se přiblížila očekávaná ztráta kapacity. Zvažte použití následujících podporovaných operací uzlů:

  • Restartujte vybrané uzly.
  • Zakažte plánování úkolů na vybraných uzlech.
  • Odeberte vybrané uzly z úložiště.

Když vám operace umožní zvolit způsob zpracování spuštěných úkolů, vyberte možnost Zařadit znovu do fronty, aby služba Batch na zbývajících uzlech naplánovala přerušené úkoly.

Během testu ověřte, že služba Batch přeplánovává přerušené úlohy a že opětovné spuštění nevygeneruje duplicitní nebo nekonzistentní výstup. Ověřte, že kontrolní body a výstup zůstávají dostupné z odolného úložiště, monitorování detekuje ztrátu uzlů a sníženou kapacitu a úlohu lze dokončit se zbývající kapacitou.

Tyto operace ověřují přerušení a přeplánování úloh, idempotenci, kontrolní body a odolné zpracování výstupu. Nereprodukují ale všechny účinky selhání v celé zóně.

Odolnost proti selháním v celé oblasti

Účet Batch a jeho fondy jsou omezeny na jeden region Azure. Pokud dojde k selhání oblasti, vaše úlohy a fondy Batch mohou být ovlivněny.

Služba Batch nereplikuje účty, konfiguraci fondu, úlohy, úkoly, balíčky aplikací ani data úkolů do jiné oblasti a neposkytuje integrované převzetí služeb při selhání mezi oblastmi. Zodpovídáte za nasazení a provoz řešení Batch ve více oblastech, když vaše úloha musí tolerovat výpadek celé oblasti.

Přizpůsobená multiregionální řešení pro odolnost

Pokud chcete vytvořit řešení ve více oblastech, nasaďte alespoň jeden účet Batch v každé oblasti, kterou návrh obnovení používá. účty Batch fungují nezávisle v jednotlivých oblastech. Zodpovídáte za výběr oblastí, nasazování a provoz prostředků v jednotlivých oblastech a koordinaci konfigurace, replikace, převzetí služeb při selhání a navrácení služeb po obnovení.

Můžete navrhnout přístup aktivní-aktivní , který odesílá práci v několika oblastech během normálního provozu, nebo přístup typu aktivní-pasivní , který udržuje sekundární nasazení připravené k převzetí služeb při selhání. Architektury active-active můžou zkrátit dobu obnovení, protože obě nasazení zpracovávají zátěž během běžného provozu, zatímco architektury active-passive můžou snížit náklady na výpočetní výkon v ustáleném stavu.

Následující seznam obsahuje příklady vašich zodpovědností při návrhu řešení:

  • Nasazení: Předem v každé oblasti vytvořte účty Batch, fondy nebo definice nasazení fondu, účty úložiště, síťové prostředky a další závislosti. Ověřte, že každá vybraná oblast podporuje funkce Batch, velikosti virtuálních počítačů a závislé služby, které vaše úloha vyžaduje. Pokud je to možné, udržujte každý účet Batch a prostředky úložiště používané svými úlohami ve stejné oblasti, abyste se vyhnuli zbytečné latenci. Definujte účty Batch, fondy a podpůrné prostředky pomocí infrastruktury jako kódu, aby bylo možné konzistentně reprodukovat konfiguraci napříč oblastmi.

  • Kvóty a kapacita: Ověřte příslušné kvóty účtu Batch, předplatného a řady virtuálních počítačů v každé oblasti obnovení a v případě potřeby před výpadkem požádejte o jejich navýšení. Kvóta je limit, nikoli záruka kapacity. Dostupnost virtuálních počítačů se liší podle oblastí, rodiny virtuálních počítačů a času. Další informace najdete v tématu Účet Batch a kvóty jader.

  • Replikace dat: Udržujte balíčky aplikací, image kontejnerů, vstupní data a referenční data dostupná v každé oblasti obnovení. Služba Batch tyto položky za vás nereplikuje.

  • Replikace úložiště: Nakonfigurujte redundanci úložiště a replikaci dat mezi oblastmi na základě cíle bodu obnovení (RPO). Ověřte, že replikovaná data jsou přístupná z každé oblasti obnovení. Možnosti spolehlivosti úložiště najdete v tématu Spolehlivost v Azure Blob Storage.

  • Cílení na oblast: Pokud vaše aplikace pracují s vaším účtem Batch, navrhněte je tak, aby mohly vybrat jiný účet Batch a jeho přidružené prostředky úložiště bez nutnosti nasazení kódu.

  • Převzetí služeb při selhání: Služba Batch nepřesune automaticky vaši úlohu do jiné oblasti. Zodpovídáte za zjištění výpadku, určení toho, jak výpadek ovlivňuje vaše pracovní zatížení, zastavení odesílání do ovlivněného účtu Batch, směrování nové práce na účet Batch v oblasti, ve které je vše v pořádku, a rozhodnutí, jestli se mají znovu odeslat přerušené úlohy. Výstup práce nebo úkolu, který jste nereplikoval(a) mimo ovlivněnou oblast, může být nedostupný nebo ztracený. Doba obnovení závisí na modelu nasazení, dostupné kapacitě, replikaci dat a automatizaci.

  • Obnovení oblasti: Po obnovení dostupnosti služby v ovlivněné oblasti ověřte účet Batch, fondy, závislosti úložiště a stav úlohy před nasměrováním práce do této oblasti. Před opětovnou odesláním odsouhlaste duplicitní nebo částečně dokončené úkoly. Služba Batch nekoordinuje tento proces ani neslaďuje stav mezi regionálními účty.

  • Testování: Pravidelně testujte kompletní proces regionálního obnovení v neprodukčním prostředí. Simulujte, že jedno regionální nasazení nebude dostupné, přesměrujte odesílání do jiného účtu Batch, ověřte přístup k balíčkům aplikací a vstupním datům, spusťte reprezentativní úlohy, shromážděte výstup a procvičte vrácení obnoveného nasazení do služby. Změřte výsledky podle cíle doby obnovy a cíle bodu obnovy.

Zálohování a obnovení

Azure Batch není trvalé úložiště pro vstupní a výstupní data úloh. Microsoft udržuje službu Batch, ale zodpovídáte za zachování konfigurace a dat potřebných k opětovnému vytvoření pracovní zátěže:

  • Konfigurace služby Batch: Definujte účty Batch, fondy, úlohy a podpůrné prostředky pomocí infrastruktury jako kódu, jako jsou Bicep a definice úloh řízené verzí. Tyto artefakty poskytují opakovatelný způsob opětovného vytvoření konfigurace ve stejné oblasti nebo jiné oblasti. Pravidelně testujte, zda definice můžou nasadit pool a spustit reprezentativní úlohu.

  • Dávková metadata: Služba Batch uchovává záznamy úloh a úkolů, dokud neodstraníte přidruženou úlohu nebo úkol, ale tyto záznamy nejsou zálohou. Pokud potřebujete zachovat tuto historii, zachovejte požadované záznamy mimo službu Batch.

  • Data na výpočetních uzlech: Výpočetní uzly jsou dočasné a jejich systémy souborů nejsou záložním ani trvalým úložištěm. Data na uzlu se ztratí, když je uzel znovu naimageován nebo opustí fond. Služba Batch může také odstranit soubory úkolů po vypršení jejich doby uchovávání. Uložte požadované výstupy a diagnostické logy do trvalého úložiště před dokončením úlohy. U dlouhotrvajících úloh zachovávejte kontrolní body během provádění. Další informace najdete v tématu Zachování výstupu úlohy a úkolu a monitorování Azure Batch.

  • Data v účtech autostorage: Přidružený účet autostorage může obsahovat balíčky aplikací a soubory prostředků úloh. Kromě konfigurace redundance, která splňuje vaše cíle obnovení, zvažte, jestli potřebujete chránit tato data před náhodným odstraněním nebo poškozením. Další informace najdete v tématu Zálohování a obnovení v Azure Blob Storage.

Obnovení a testování obnovy

Pokud chcete provést obnovení, nasaďte batch a podpůrnou konfiguraci prostředků, obnovte nebo znovu připojte požadovaná vstupní data a artefakty aplikace a znovu odešlete úlohy, které se nedokončily. Pravidelně testujte rekonstrukci prostředků i obnovení dat v izolovaném nebo neprodukčním prostředí pro obnovení. Použijte definice řízené verzí a zálohovaná data, spusťte reprezentativní úlohu, ověřte výsledný výstup a přístup k závislostem a změřte dosaženou dobu obnovení a bod obnovy podle svých cílů. Ověřte, že úkoly jsou idempotentní, aby opětovné odeslání nejisté práce nepoškodilo data ani nevytvořilo duplicitní výstup.

Odolnost vůči údržbě služeb

Microsoft provádí údržbu platformy a koordinuje aktualizace infrastruktury pro Azure Batch a další služby. Zodpovídáte za konfiguraci chování aktualizací fondu a navrhování úkolů tak, aby odolaly přerušení.

  • Údržba hostitele: Azure používá techniky údržby, jako je migrace za provozu, pokud je to možné. Pokud údržba vyžaduje restartování nebo přesunutí výpočetního uzlu, mohou být spuštěné úlohy přerušeny a služba Batch je může přeplánovat. Vytvářejte idempotentní úlohy a ukládejte kontrolní body a výstup do trvalého úložiště.

  • Hostovaný operační systém: Zodpovídáte za udržování hostovaného operačního systému a agenta uzlu Batch aktuální. Chování aktualizace operačního systému závisí na image a konfiguraci aktualizace. S odpovídající konfigurací můžou automatické upgrady imagí operačního systému pro fondy batch aktualizovat uzly fondu, aniž by přerušily spuštěné úlohy. Automatické upgrady bitových kopií operačního systému nepodporují každou bitovou kopii operačního systému Batch.

  • Aktualizace agenta uzlu: Automatické upgrady imagí operačního systému automaticky neaktualizují agenta uzlu Batch. Agenti uzlů služby Batch se neupgradují automaticky, když má fond výpočetní uzly. Pokud chcete získat novějšího agenta uzlu, změňte velikost fondu na nula uzlů a znovu ho navyšte nebo nahraďte fond. Před odebráním uzlů zachovejte veškerý požadovaný výstup úlohy a diagnostické protokoly. Další informace najdete v tématu Aktualizace agenta uzlu Batch.

Postupujte podle doporučení k produkčnímu nasazení a pokynů při selhání výpočetních uzlů, aby vaše úloha mohla pokračovat nebo se zotavit, když údržba přeruší úlohy nebo způsobí nedostupnost výpočetních uzlů.

Smlouva o úrovni služeb

Smlouva o úrovni služeb (SLA) pro služby Azure popisuje očekávanou dostupnost každé služby a podmínky, které musí vaše řešení splnit, aby bylo dosaženo očekávané dostupnosti. Další informace najdete v článku SLA pro online služby.

Smlouva SLA o dostupnosti Azure Batch se vztahuje na operace, které provádíte s rozhraním API služby Batch. Podrobné informace o typech zahrnutých operací si projděte ve znění SLA. Velikost fondu, distribuce zón a závislé služby ovlivňují komplexní dostupnost úlohy, ale nemění podmínky smlouvy SLA služby Batch.

Související obsah

  • Poslední aktualizace v