Osvědčené postupy pro službu Azure Batch

  • Článek
  • 16 min ke čtení

Tento článek popisuje osvědčené postupy a užitečné tipy pro efektivní Azure Batch služby. Tyto tipy vám můžou pomoct zvýšit výkon a vyhnout se nástrahám návrhu v řešeních Batch.

Tip

Pokyny k zabezpečení v Azure Batch najdete v tématu Osvědčené postupy pro zabezpečení a dodržování předpisů služby Batch.

Fondy

Fondy jsou výpočetní prostředky pro spouštění úloh ve službě Batch. Následující části obsahují doporučení pro práci s fondy služby Batch.

Konfigurace a pojmenování fondu

  • Režim přidělování fondu: Při vytváření účtu Batch si můžete vybrat mezi dvěma režimy přidělování fondu: služba Batch nebo předplatné uživatele. Ve většině případů byste měli použít výchozí režim služby Batch, ve kterém se fondy přidělují na pozadí v předplatných spravovaných službou Batch. V alternativním režimu Předplatné uživatele se virtuální počítače a další prostředky služby Batch vytvářejí přímo ve vašem předplatném při vytvoření fondu. Účty uživatelských předplatných se primárně používají k povolení malé, ale důležité podmnožiny scénářů. Další informace najdete v tématu Další konfigurace pro režim předplatného uživatele.

  • VirtualMachineConfiguration nebo cloudServiceConfiguration: V současné době můžete fondy vytvářet pomocí obou konfigurací, ale nové fondy by se měly konfigurovat pomocí virtualMachineConfiguration, a ne cloudServiceConfiguration. Všechny aktuální a nové funkce služby Batch budou podporované fondy konfigurace virtuálního počítače. Cloud Services konfigurace nepodporují všechny funkce a neplánují se žádné nové funkce. Po 29. únoru 2024nebudete moct vytvářet nové fondy cloudServiceConfiguration ani přidávat nové uzly do existujících fondů. Další informace najdete v tématu Migrace konfigurace fondu Batch z Cloud Services do virtuálního počítače.

  • Důležité informace o době běhu úlohy a úkolu: Pokud máte úlohy, které se skládají především z krátkodobých úkolů, a očekávané celkové počty úkolů jsou malé, takže celková očekávaná doba běhu úlohy není dlouhá, nepřidělte pro každou úlohu nový fond. Doba přidělení uzlů sníží dobu běhu úlohy.

  • Několik výpočetních uzlů: U jednotlivých uzlů není zaručeno, že budou vždy dostupné. I když je to neobvyklé, selhání hardwaru, aktualizace operačního systému a hostitel dalších problémů mohou způsobit, že jednotlivé uzly budou offline. Pokud vaše úloha Batch vyžaduje deterministický a zaručený průběh, měli byste přidělit fondy s více uzly.

  • Obrázky s daty blížící se konce životnosti (EOL): Důrazně doporučujeme vyhnout se obrázkům s blížící se koncem životnosti podpory batch (EOL). Tato data je možné zjistit pomocí rozhraní ListSupportedImages API, PowerShellunebo Azure CLI. Je na vás, abyste pravidelně obnovovat zobrazení dat EOL relevantních pro vaše fondy a migrovat úlohy před datem EOL. Pokud používáte vlastní image se zadaným agentem uzlu, ujistěte se, že dodržujete data konce životnosti podpory služby Batch pro image, pro kterou je vaše vlastní image odvozená nebo zarovnána.

  • Jedinečné názvy prostředků: Prostředky služby Batch (úlohy, fondy atd.) často přicházejí a odchýlují se v průběhu času. Můžete například vytvořit fond v pondělí, odstranit ho v úterý a pak vytvořit další podobný fond ve čtvrtek. Každému novému prostředku, který vytvoříte, byste měli dát jedinečný název, který jste ještě nepouží použili. Můžete to provést pomocí identifikátoru GUID (jako celého názvu prostředku nebo jeho části) nebo vložením data a času vytvoření prostředku v názvu prostředku. Batch podporuje DisplayName, který může dát prostředku čitelný název i v případě, že skutečné ID prostředku je něco, co není vhodné pro člověka. Použitím jedinečných názvů můžete snadněji rozlišit, který konkrétní prostředek něco udělal v protokolech a metrikách. Také se tím odstraní nejednoznačnost, pokud byste někdy měli pro prostředek použít případ podpory.

  • Kontinuita během údržby a selhání fondu: Je nejlepší, když vaše úlohy používají fondy dynamicky. Pokud vaše úlohy používají pro všechno stejný fond, existuje možnost, že se úlohy nespraví, pokud se s fondem něco pokazí. To je zvlášť důležité pro úlohy citlivé na čas. Pokud chcete tento problém vyřešit, vyberte nebo vytvořte fond dynamicky při plánování jednotlivých úloh nebo popište název fondu, abyste mohli obejít fond, který není v pořádku.

  • Kontinuita podnikových aplikací během údržby a selhání fondu: Existuje mnoho důvodů, proč se fond nemusí zvětšovat na takovou velikost, jako jsou interní chyby nebo omezení kapacity. Ujistěte se, že můžete znovu zacílet úlohy v jiném fondu (případně s jinou velikostí virtuálního počítače. Batch to v případě potřeby podporuje prostřednictvím úlohy UpdateJob). Nespoléhejte na statické ID fondu s očekáváním, že se nikdy neodstraní a nikdy se nezmění.

Doba života a fakturace fondu

Doba života fondu se může lišit v závislosti na metodě přidělení a možnostech použitých na konfiguraci fondu. Fondy můžou mít v libovolném okamžiku libovolnou životnost a různý počet výpočetních uzlů. Je vaší zodpovědností spravovat výpočetní uzly ve fondu buď explicitně, nebo prostřednictvím funkcí poskytovaných službou (automatické škálování nebo automatické zařazování).

  • Freshness fondu: Každých několik měsíců změňte velikost fondů na nulu, abyste měli zajištěné nejnovější aktualizace agenta uzlua opravy chyb . Váš fond neobdrží aktualizace agenta uzlu, pokud se znovu nevytvoře (nebo pokud se změní jeho velikost na 0 výpočetních uzlů). Než fond znovu vytvoříte nebo změníte jeho velikost, měli byste si stáhnout všechny protokoly agenta uzlu pro účely ladění, jak je popsáno v části Uzly.

  • Fond se sdružovat: Podobně se vyhněte každodennímu odstraňování a opětovnému vytvoření fondů. Místo toho vytvořte nový fond a pak aktualizujte existující úlohy tak, aby odkazovat na nový fond. Jakmile se všechny úkoly přesunou do nového fondu, odstraňte starý fond.

  • Efektivita fondu a fakturace: Za samotnou dávku se nepočítají žádné další poplatky, ale za použité výpočetní prostředky se vám nepočítají poplatky. Účtuje se vám každý výpočetní uzel ve fondu bez ohledu na jeho stav. To zahrnuje všechny poplatky vyžadované ke spuštění uzlu, například náklady na úložiště a sítě. Další informace najdete v tématu Analýza nákladů a rozpočty pro Azure Batch.

  • Dočasné disky s operačním systémem: Fondy konfigurace virtuálního počítače mohou používat dočasné disky s operačním systémem ,které vytvářejí disk s operačním systémem v mezipaměti virtuálního počítače nebo dočasném disku SSD, aby se zabránilo dodatečným nákladům spojeným se spravovanými disky.

Selhání přidělení fondu

K selhání přidělení fondu může dojít kdykoli během prvního přidělení nebo při následné změně velikosti. Může to být způsobené dočasným vyčerpáním kapacity v oblasti nebo selháním v jiných službách Azure, na které služba Batch spoléhá. Kvóta počtu jader není zárukou, ale spíše limitem.

Neplánovaný výpadek

Fondy služby Batch mohou zaznamenat výpadky v Azure. Mějte to na paměti při plánování a vývoji scénáře nebo pracovního postupu pro Batch. Pokud uzly selžou, Batch se automaticky pokusí tyto výpočetní uzly obnovit vaším jménem. To může aktivovat opětovné naplánování jakékoli spuštěné úlohy na uzlu, který je obnoven. Další informace o přerušených úlohách najdete v tématu Návrh pro opakování.

Vlastní fondy i image

Když vytvoříte fond virtuálních Azure Batch pomocí konfigurace virtuálního počítače, zadáte image virtuálního počítače, která poskytuje operační systém pro každý výpočetní uzel ve fondu. Fond můžete vytvořit s podporovanou Azure Marketplace image, nebo můžete vytvořit vlastní image s i Azure Compute Gallery. I když můžete k vytvoření vlastního fondu imagí použít také spravovanou image, doporučujeme vytvořit vlastní image pomocí Azure Compute Gallery. Použití galerie Azure Compute vám pomůže zřství fondů rychleji, škálovat větší množství virtuálních počítačů a zvýšit spolehlivost při zřizování virtuálních počítačů.

Image třetích stran

Fondy je možné vytvořit pomocí imagí třetích stran publikovaných Azure Marketplace. U účtů Batch v režimu předplatného uživatele se při vytváření fondu s určitými imagemi třetích stran může zobrazit chyba Přidělení selhalo kvůli kontrole způsobilosti při nákupu na marketplace. Pokud chcete tuto chybu vyřešit, přijměte podmínky nastavené vydavatelem image. Můžete to udělat pomocí příkazu Azure PowerShell nebo Azure CLI.

Závislost na oblasti Azure

Pokud máte úlohy náročné na čas nebo produkční úlohy, neměli byste spoléhat na jednu oblast Azure. I když jsou některé problémy vzácné, mohou mít vliv na celou oblast. Pokud například vaše zpracování potřebuje začít v určitou dobu, zvažte škálování fondu v primární oblasti těsně před počátečním časem. Pokud toto škálování fondu selže, můžete se vrátit k navýšení kapacity fondu v oblasti zálohování (nebo oblastech).

Fondy napříč několika účty v různých oblastech poskytují připravenou a snadno přístupnou zálohu, pokud se něco pokazí s jiným fondem. Další informace najdete v tématu Návrh aplikace pro vysokou dostupnost.

Úlohy

Úloha je kontejner navržený tak, aby obsahoval stovky, tisíce nebo dokonce miliony úkolů. Při vytváření úloh postupujte podle těchto pokynů.

Méně úloh, více úkolů

Použití úlohy ke spuštění jednoho úkolu je neefektivní. Je například efektivnější použít jednu úlohu obsahující 1 000 úkolů místo vytváření 100 úloh, které obsahují 10 úkolů. Spuštění 1 000 úloh, z nichž každá má jeden úkol, by byla nejméně efektivní, nejpomalejší a nejdražší přístup.

Proto se vyhněte návrhu řešení Batch, které vyžaduje tisíce současně aktivních úloh. Pro úkoly neexistuje žádná kvóta, takže provádění mnoha úkolů v co možná nejvíce úlohách efektivně využívá kvóty úloh a plánů úloh.

Doba života úlohy

Úloha batche má neurčitou životnost, dokud ji ze systému nevystraníte. Jeho stav určuje, jestli může přijmout více úkolů pro plánování, nebo ne.

Úloha se automaticky nepřesouná do dokončeného stavu, pokud není explicitně ukončena. To se může automaticky aktivovat prostřednictvím vlastnosti onAllTasksComplete nebo maxWallClockTime.

Existuje výchozí kvóta aktivní úlohy a plánu úlohy. Úlohy a plány úloh v dokončeném stavu se do této kvóty nezapočítáují.

Úkoly

Úkoly jsou jednotlivé jednotky práce, které tvoří úlohu. Úkoly se posílají uživatelem a batch je naplánuje na výpočetní uzly. Následující části obsahují návrhy pro navrhování úloh, které vám posouvá problémy a efektivně provádějí.

Uložení dat úkolu

Výpočetní uzly jsou ze své povahy dočasné. Funkce služby Batch, jako je automatické zařazování a automatické škálování, mohou uzlům snadno zmizet. Když uzly opustí fond (kvůli změně velikosti nebo odstranění fondu), odstraní se také všechny soubory na těchto uzlech. Z tohoto důvodu by měl úkol přesunout svůj výstup z uzlu, na který běží, a do trvalého úložiště před jeho dokončením. Podobně pokud úloha selže, měla by přesunout protokoly potřebné k diagnostice selhání do trvalého úložiště.

Batch má integrovanou podporu Azure Storage odesílání dat prostřednictvím OutputFilesa také různých sdílených systémů souborů, nebo můžete nahrát sami ve svých úlohách.

Správa doby života úlohy

Úlohy odstraňte, když už je nepotřebujete, nebo nastavte omezení úlohy retentionTime. Pokud je nastavený , Batch automaticky vyčistí místo na disku, které úloha retentionTime používá, když retentionTime vyprší platnost.

Odstranění úloh provádí dvě věci. Zajišťuje, že v rámci úlohy nemáte sestavení úkolů, což může ztížovat dotazování nebo hledání úkolu, který vás zajímá (protože budete muset filtrovat úkoly dokončené). Vyčistí také odpovídající data úkolu na uzlu (za retentionTime předpokladu, že ještě nebyl proveden). To pomáhá zajistit, aby se uzly nezaplnily daty úkolů a aby na disku došly volné místo.

Odesílání velkého počtu úkolů v kolekci

Úkoly je možné odeslat jednotlivě nebo v kolekcích. Odesílání úkolů v kolekcích až 100 najednou při hromadném odesílání úkolů za účelem snížení režie a času odeslání.

Vhodné nastavení maximálního maximálního uzlu na uzel

Batch podporuje úlohy před přihlášením k odběru na uzlech (spouštění více úkolů, než má uzel jádra). Je na vás, abyste zajistili, že vaše úkoly "zapadnou" do uzlů ve vašem fondu. Můžete mít například snížený výkon, pokud se pokusíte naplánovat osm úloh, z nichž každý spotřebovává 25 % využití procesoru na jeden uzel (ve fondu s taskSlotsPerNode = 8 ).

Návrh pro opakování a opětovné spuštění

Batch může úkoly automaticky zopakovat. Existují dva typy opakování: uživatelem řízené a interní. Uživatelem řízené opakování jsou určena hodnotou maxTaskRetryCount úkolu. Když program zadaný v úkolu ukončí s nenulový ukončovací kód, úloha se zopakuje až na hodnotu maxTaskRetryCount .

I když je úloha vzácná, může být opakována interně kvůli selhání na výpočetním uzlu, například kvůli tomu, že nemůže aktualizovat interní stav nebo chybu v uzlu, když je úloha spuštěná. Pokud je to možné, bude úkol opakován na stejném výpočetním uzlu až do interního limitu, než se úkolu zdržíte a odložíte úkol tak, aby se přeplánoval pomocí služby Batch, potenciálně na jiném výpočetním uzlu.

Při provádění úloh na vyhrazených uzlech nebo uzlech s nízkou prioritou nejsou žádné rozdíly v návrhu. Bez ohledu na to, jestli je úloha přerušena při spuštění na uzlu s nízkou prioritou nebo přerušena z důvodu selhání na vyhrazeném uzlu, jsou obě situace zmírněny navrženou úlohou, která odolá selhání.

Sestavení trvalých úloh

Úlohy by měly být navržené tak, aby odolávaly selhání a pohotové opakování. To je zvlášť důležité pro dlouho běžící úlohy. Pokud to chcete udělat, ujistěte se, že úkoly generují stejný jeden výsledek, i když se spustí více než jednou. Jedním ze způsob, jak toho dosáhnout, je udělat úkoly "cílem, které hledáte". Dalším způsobem je zajistit, aby vaše úkoly byly idempotentní (úkoly budou mít stejný výsledek bez ohledu na to, kolikrát jsou spuštěny).

Běžným příkladem je úloha kopírování souborů do výpočetního uzlu. Jednoduchý přístup je úloha, která kopíruje všechny zadané soubory při každém spuštění, což je neefektivní a není sestavené tak, aby odolávalo selhání. Místo toho vytvořte úlohu, která zajistí, že soubory budou ve výpočetním uzlu. Úloha, která znovu nezkopírovat soubory, které už existují. Tímto způsobem úkol vybere místo, kde se přerušilo.

Vyhněte se krátké době provádění

Úlohy, které se spouštěly jenom po dobu 1 až 2 sekund, nejsou ideální. Zkuste v individuálním úkolu provést značné množství práce (minimálně 10 sekund, doba trvání až hodin nebo dnů). Pokud se každý úkol spouští jednu minutu (nebo déle), je režie plánování zlomek celkového výpočetního času malá.

Použití oboru fondu pro krátké úlohy na Windows uzlech

Při plánování úlohy na uzlech Batch můžete zvolit, jestli se má spustit s oborem úlohy nebo oborem fondu. Pokud se úloha spustí jenom krátce, může být rozsah úlohy neefektivní kvůli prostředkům potřebným k vytvoření účtu automatického uživatele pro tento úkol. Pokud chcete zvýšit efektivitu, zvažte nastavení těchto úloh na rozsah fondu. Další informace najdete v tématu Spuštění úlohy jako automatického uživatele s oborem fondu.

Uzly

Výpočetní uzel je virtuální počítač Azure nebo virtuální počítač cloudové služby vyhrazený pro zpracování části úloh vaší aplikace. Při práci s uzly postupujte podle těchto pokynů.

Idempotentní úlohy spuštění

Stejně jako u jiných úloh by měl být spouštěcí úkol uzlu idempotentní, protože se bude znovu spustit při každém spuštění uzlu. Idempotentní úloha je jednoduše úloha, která při vícenásobné spuštění vytvoří konzistentní výsledek.

Izolované uzly

Zvažte použití izolovaných velikostí virtuálních počítačů pro úlohy s požadavky na dodržování předpisů nebo zákonné požadavky. Mezi podporované izolované velikosti v režimu konfigurace virtuálního počítače patří Standard_E80ids_v4 , , , , a Standard_M128ms Standard_F72s_v2 Standard_G5 Standard_GS5 Standard_E64i_v3 . Další informace o izolovaných velikostech virtuálních počítačů najdete v tématu Izolace virtuálních počítačů v Azure.

Správa dlouhodobých služeb prostřednictvím rozhraní služeb operačního systému

Někdy je potřeba spustit jiného agenta společně s agentem Batch v uzlu. Můžete například chtít shromáždit data z uzlu a ohlásit je. Doporučujeme, aby se tito agenti nasadili jako služby operačního systému, jako je Windows nebo linuxová systemd služba.

Při spouštění těchto služeb nesmí tyto služby zamykat soubory u žádných souborů v adresářích spravovaných službou Batch na uzlu, protože jinak služba Batch nebude moci tyto adresáře odstranit kvůli zámkům souborů. Pokud například instalujete službu Windows do spouštěcího úkolu místo spouštění služby přímo z pracovního adresáře spouštěcího úkolu, zkopírujte soubory na jiné místo (nebo pokud soubory existují, stačí přeskočit kopii). Pak službu nainstalujte z tohoto umístění. Když služba Batch znovu spustí váš úkol spuštění, odstraní pracovní adresář úkolu spuštění a znovu ho vytvoří. To funguje, protože služba má zámky souborů v druhém adresáři, nikoli v pracovním adresáři úkolu spuštění.

Vyhněte se vytváření adresářových Windows

Problémy s adresáři, někdy nazývané pevné odkazy adresáře, je obtížné řešit během čištění úkolů a úloh. Místo pevných odkazů používejte symlinky (soft-links).

Shromažďování protokolů agenta Batch

Pokud si všimnete problému souvisejícího s chováním uzlu nebo úloh spuštěných na uzlu, shromážděte protokoly agenta Batch před dohodu o uvolnění týkajících se uzlů. Protokoly agenta Batch je možné shromažďovat pomocí rozhraní API protokolů Upload batch. Tyto protokoly je možné vyřešit v rámci lístku podpory microsoftu a pomůžou vám s řešením potíží.

Správa upgradů operačního systému

V případě účtů Batch v režimu předplatného uživatele mohou automatizované upgrady operačního systému přerušit průběh úlohy, zejména pokud jsou úlohy dlouho běžící. Vytváření idempotentních úloh může pomoct omezit chyby způsobené těmito přerušeními. Doporučujeme také plánovat upgrady image operačního systému v době, kdy seneočekává spuštění úloh.

U Windows je enableAutomaticUpdates ve výchozím nastavení true nastavená hodnota . Doporučuje se povolit automatické aktualizace, ale pokud potřebujete zajistit, aby nedošlo k neočekávané aktualizaci operačního systému, můžete tuto hodnotu false nastavit na .

Zabezpečení izolace

Pokud váš scénář vyžaduje izolaci úloh od sebe navzájem, pro účely izolace to proveďte tak, že je budete mít v samostatných fondech. Fond je hranicí izolace zabezpečení ve službě Batch a ve výchozím nastavení nejsou dva fondy viditelné nebo spolu mohou komunikovat. Nepoužívejte samostatné účty Batch jako způsob izolace.

Připojení

Prohlédněte si následující pokyny týkající se připojení ve vašich řešeních Batch.

Skupiny zabezpečení sítě (NSG) a trasy definované uživatelem

Při zřizování fondů služby Batchve virtuální síti se ujistěte, že pečlivě postupuje podle pokynů týkajících se používání značky služby, portů, protokolů a směru BatchNodeManagement pravidla. Použití značky služby se důrazně doporučuje místo IP adres podkladové služby Batch. Je to proto, že se IP adresy mohou v průběhu času měnit. Přímé použití IP adres služby Batch může způsobit nestabilitu, přerušení nebo výpadky vašich fondů Batch.

V případě tras definovaných uživatelem se ujistěte, že ve směrovací tabulce pravidelně aktualizujete IP adresy služby Batch, protože tyto adresy se v průběhu času mění. Informace o tom, jak získat seznam IP adres služby Batch, najdete v tématu Místní značky služeb. IP adresy služby Batch budou přidružené ke značce služby (nebo k regionální variantě, která odpovídá BatchNodeManagement oblasti vašeho účtu Batch).

Ctít DNS

Ujistěte se, že vaše systémy pro adresu URL služby účtu Batch respektují TTL (Time to Live) DNS. Dále se ujistěte, že klienti služby Batch a další mechanismy připojení ke službě Batch nespoléhají na IP adresy (nebo vytvořte fond se statickými veřejnými IP adresami, jak je popsáno níže).

Pokud vaše požadavky obdrží odpovědi HTTP na úrovni 5xx a v odpovědi je hlavička Connection: close (Připojení: zavřít), měl by klient služby Batch toto doporučení sledovat zavřením existujícího připojení, překládáním DNS pro adresu URL služby účtu Batch a pokusem o sledování požadavků u nového připojení.

Automatické opakování požadavků

Ujistěte se, že klienti služby Batch mají vhodné zásady opakování, které automaticky zopakují vaše požadavky, a to i během normálního provozu, a ne výhradně během časových období údržby služeb. Tyto zásady opakování by měly být v intervalu nejméně 5 minut. Funkce automatického opakování jsou k dispozici s různými nástroji Batch SDK, jako je například třída .NET RetryPolicyProvider.

Statické veřejné IP adresy

K virtuálním počítačům ve fondu Batch se obvykle přistupuje prostřednictvím veřejných IP adres, které se po celou dobu životnosti fondu mohou měnit. Může být obtížné pracovat s databází nebo jinou externí službou, která omezuje přístup k určitým IP adresám. Abyste zajistili, že se veřejné IP adresy ve vašem fondu neočekávaně nezmění, můžete vytvořit fond pomocí sady statických veřejných IP adres, které řídíte. Další informace najdete v tématu Vytvoření fondu Azure Batch se zadanými veřejnými IP adresami.

Testování připojení s Cloud Services konfigurací

S cloudovými službami nemůžete používat normální protokol ping nebo ICMP, protože protokol ICMP není prostřednictvím nástroje pro vyrovnávání zatížení Azure povolený. Další informace najdete v tématu Připojení a sítě pro Azure Cloud Services.

Základní závislosti uzlu Batch

Při navrhování řešení Batch zvažte následující závislosti a omezení.

Prostředky vytvořené systémem

Azure Batch virtuálním počítači vytváří a spravuje sadu uživatelů a skupin, které by se neměly měnit. Jsou to tyto:

Windows:

  • Uživatel s názvem PoolNonAdmin
  • Skupina uživatelů s názvem WATaskCommon

Linux:

  • Uživatel s názvem _azbatch

Vyčištění souboru

Batch se aktivně pokouší vyčistit pracovní adresář, ve které jsou úkoly spuštěny, jakmile jejich doba uchovávání vyprší. Všechny soubory zapsané mimo tento adresář jsou vaší zodpovědností vyčistit, abyste nenaplňli místo na disku.

Automatické vyčištění pracovního adresáře bude zablokováno, pokud spustíte službu v Windows z pracovního adresáře startTask, protože složka se stále používá. Výsledkem bude snížený výkon. Pokud chcete tento problém vyřešit, změňte adresář pro tuto službu na samostatný adresář, který není spravovaný službou Batch.

Další kroky