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

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

Tip

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

Skupiny

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í fondů: Při vytváření účtu Batch si můžete vybrat mezi dvěma režimy přidělování fondů: službou Batch nebo předplatným 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 předplatného uživatelů se primárně používají k povolení malé, ale důležité podmnožina scénářů. Další informace najdete v tématu Konfigurace pro režim předplatného uživatele.

  • virtualMachineConfiguration nebo cloudServiceConfiguration: I když aktuálně můžete vytvářet fondy pomocí konfigurace, nové fondy by měly být nakonfigurovány pomocí virtualMachineConfiguration , a ne cloudServiceConfiguration. Všechny aktuální a nové funkce batch budou podporovány fondy konfigurace virtuálních počítačů. Fondy konfigurace cloudových služeb nepodporují všechny funkce a neplánují se žádné nové funkce. Po 29. únoru 2024 nebudete moct vytvářet nové cloudServiceConfiguration fondy ani přidávat nové uzly do existujících fondů. Další informace najdete v tématu Migrace konfigurace fondu Batch z Cloud Services na virtuální počítač.

  • classic nebo simplified režim komunikace uzlu: Fondy lze konfigurovat v jednom ze dvou režimů komunikace uzlů, klasickém nebo zjednodušeném. V klasickém komunikačním modelu uzlu služba Batch zahájí komunikaci s výpočetními uzly a výpočetní uzly také vyžadují komunikaci se službou Azure Storage. Ve zjednodušeném komunikačním modelu uzlu inicializuje výpočetní uzly komunikaci se službou Batch. Vzhledem k omezenému rozsahu příchozích a odchozích připojení, která vyžadují odchozí přístup ke službě Azure Storage pro základní operaci, doporučujeme použít zjednodušený komunikační model uzlu. Některá budoucí vylepšení služby Batch budou také vyžadovat zjednodušený komunikační model uzlu. Klasický komunikační model uzlu bude vyřazen 31. března 2026.

  • Důležité informace o úloze a běhu úkolů: Pokud máte úlohy složené především z krátký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ělujte pro každou úlohu nový fond. Doba přidělení uzlů sníží dobu běhu úlohy.

  • Více 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 řada dalších problémů můžou způsobit, že jednotlivé uzly budou offline. Pokud vaše úloha Batch vyžaduje deterministický, zaručený průběh, měli byste přidělit fondy s více uzly.

  • Obrázky s blížícími se daty konce životnosti (EOL): Důrazně doporučujeme vyhnout se obrázkům s blížícími se daty konce životnosti (EOL). Tato data je možné zjistit prostřednictvím rozhraní API, PowerShellu ListSupportedImages nebo Azure CLI. Je vaší zodpovědností pravidelně aktualizovat zobrazení kalendářních dat EOL souvisejících s vašimi fondy a migrovat úlohy před datem EOL. Pokud používáte vlastní image se zadaným agentem uzlu, ujistěte se, že pro image, pro kterou je vaše vlastní image odvozená nebo zarovnaná, dodržujete data ukončení životnosti služby Batch. Obrázek bez zadaného batchSupportEndOfLife data označuje, že takové datum ještě služba Batch neurčovala. Absence data neznamená, že se příslušný obrázek bude podporovat na neomezenou dobu. Datum EOL může být kdykoli přidáno nebo aktualizováno v budoucnu.

  • Skladové položky virtuálních počítačů s blížícím se datem ukončení životnosti (EOL): Stejně jako u imagí virtuálních počítačů můžou skladové položky nebo rodiny virtuálních počítačů také dosáhnout konce životnosti (EOL). Tato data je možné zjistit prostřednictvím rozhraní API, PowerShellu ListSupportedVirtualMachineSkus nebo Azure CLI. Naplánujte migraci úlohy do skladové položky virtuálního počítače, která není EOL, vytvořením nového fondu s příslušnou podporovanou skladovou jednotkou virtuálního počítače. Absence přidruženého batchSupportEndOfLife data pro skladovou položku virtuálního počítače neznamená, že konkrétní skladová položka virtuálního počítače bude podporována neomezeně dlouho. Datum EOL může být kdykoli přidáno nebo aktualizováno v budoucnu.

  • Jedinečné názvy zdrojů: Prostředky služby Batch (úlohy, fondy atd.) často přicházejí a procházejí 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ý nový prostředek, který vytvoříte, by měl mít jedinečný název, který jste ještě nepoužili. Jedinečnost můžete vytvořit pomocí identifikátoru GUID (buď jako celého názvu prostředku, nebo jako jeho části) nebo vložením data a času vytvoření prostředku do názvu prostředku. Batch podporuje DisplayName, který může dát prostředku čitelnější název, i když je skutečné ID prostředku něco, co není pro člověka přívětivé. Použití jedinečných názvů usnadňuje rozlišení konkrétního prostředku v protokolech a metrikách. Odebere také nejednoznačnost, pokud byste někdy museli podat případ podpory pro prostředek.

  • Kontinuita během údržby a selhání fondu: Je nejlepší, aby vaše úlohy používaly fondy dynamicky. Pokud vaše úlohy používají pro všechno stejný fond, je možné, že se úlohy nespustí, pokud se s fondem něco nepovede. Tento princip je zvlášť důležitý pro časově citlivé úlohy. Pokud například plánujete každou úlohu, vyberte nebo vytvořte fond dynamicky, nebo máte způsob, jak přepsat název fondu, abyste mohli obejít fond, který není v pořádku.

  • Provozní kontinuita během údržby a selhání fondu: Existuje mnoho důvodů, proč se fond nemusí zvětšit na požadovanou velikost, například vnitřní chyby nebo omezení kapacity. V případě potřeby se ujistěte, že můžete úlohy změnit v jiném fondu (případně s jinou velikostí virtuálního počítače pomocí úlohy UpdateJob). Vyhněte se spoléhání na ID statického fondu s očekáváním, že se nikdy neodstraní a nikdy se nezmění.

Zabezpečení fondu

Hranice izolace

Pro účely izolace, pokud váš scénář vyžaduje izolování úloh nebo úkolů mezi sebou, udělejte to tak, že je budete mít v samostatných fondech. Fond je hranice izolace zabezpečení ve službě Batch a ve výchozím nastavení nejsou dva fondy viditelné ani vzájemně nekomunikují. Nepoužívejte samostatné účty Batch jako prostředek izolace zabezpečení, pokud větší prostředí, ze kterého účet Batch pracuje, nevyžaduje izolaci.

Aktualizace agenta uzlu Batch

Agenti uzlů služby Batch se automaticky neupgradují pro fondy, které mají nenulové výpočetní uzly. Abyste zajistili, že fondy Služby Batch obdrží nejnovější opravy zabezpečení a aktualizace agenta uzlu Batch, musíte změnit velikost fondu na nula výpočetních uzlů nebo znovu vytvořit fond. Doporučujeme monitorovat poznámky k verzi agenta uzlu Batch, abyste porozuměli změnám nových verzí agenta uzlu Batch. Pravidelná kontrola aktualizací při jejich vydání umožňuje naplánovat upgrady na nejnovější verzi agenta.

Před opětovným vytvořením nebo změnou velikosti fondu byste měli stáhnout všechny protokoly agenta uzlu pro účely ladění, pokud máte problémy s fondem Batch nebo výpočetními uzly. Tento proces je podrobněji popsán v části Uzly .

Poznámka:

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

Aktualizace operačního systému

Doporučujeme, aby image virtuálního počítače vybraná pro fond Batch byla aktuální s nejnovějším vydavatelem, který poskytuje aktualizace zabezpečení. Některé image můžou při spuštění provádět automatické aktualizace (nebo krátce potom), které můžou narušit určité akce řízené uživatelem, jako je načtení aktualizací úložiště balíčků (například apt update) nebo instalace balíčků během akcí, jako je startTask.

Azure Batch neověřuje ani nezaručuje, že image povolené pro použití se službou mají nejnovější aktualizace zabezpečení. Aktualizace k obrázkům jsou pod purview vydavatele image, a ne pod službou Azure Batch. U některých obrázků publikovaných v rámci microsoft-azure-batchnení zaručeno, že jsou tyto obrázky aktuální s jejich nadřazeným odvozeným obrázkem.

Životnost a fakturace fondu

Životnost fondu se může lišit v závislosti na metodě přidělování a možnostech použitých v konfiguraci fondu. Fondy můžou mít libovolnou životnost a různý počet výpočetních uzlů v jakémkoli okamžiku. 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ého fondu).

  • Rekreační bazén: Vyhněte se každodennímu odstraňování a opětovnému vytváření fondů. Místo toho vytvořte nový fond a aktualizujte stávající úlohy tak, aby odkazy na nový fond ukazovaly. Jakmile se všechny úkoly přesunou do nového fondu, odstraňte starý fond.

  • Efektivita a fakturace fondu: Samotná služba Batch neúčtuje žádné další poplatky. Za využité prostředky Azure, jako jsou výpočetní prostředky, úložiště, sítě a další prostředky, které se můžou vyžadovat pro vaši úlohu Batch, se vám ale účtují poplatky. Účtuje se vám každý výpočetní uzel ve fondu bez ohledu na stav, ve kterém je. Další informace najdete v tématu Analýza nákladů a rozpočty pro Službu Azure Batch.

  • Dočasné disky s operačním systémem: Fondy konfigurace virtuálních počítačů můžou používat dočasné disky operačního systému, které vytvoří disk s operačním systémem v mezipaměti virtuálního počítače nebo dočasném 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 v libovolném bodě při prvním přidělení nebo následné změně velikosti. Příčinou těchto selhání může být dočasné vyčerpání kapacity v oblasti nebo selhání v jiných službách Azure, na které služba Batch spoléhá. Kvóta jader není zárukou, ale spíše limitem.

Neplánovaný výpadek

Ve fondech Batch je možné zaznamenat události výpadků v Azure. Porozumějte tomu, že k problémům může dojít a měli byste vyvinout pracovní postup tak, aby byl odolný proti opětovnému spuštění. Pokud uzly selžou, služba Batch se automaticky pokusí tyto výpočetní uzly obnovit vaším jménem. Toto obnovení může aktivovat přeplánování všech spuštěných úloh na uzlu, který je obnovený nebo na jiném dostupném uzlu. Další informace o přerušených úkolech najdete v tématu Návrh opakování.

Vlastní fondy imagí

Při vytváření fondu 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 imagí Azure Marketplace nebo můžete vytvořit vlastní image s imagí Galerie výpočetních prostředků Azure. I když můžete ke vytvoření vlastního fondu imagí použít spravovanou image , doporučujeme vytvářet vlastní image pomocí Galerie výpočetních prostředků Azure, kdykoli je to možné. Použití Galerie výpočetních prostředků Azure pomáhá zřizovat fondy rychleji, škálovat větší množství virtuálních počítačů a zlepšit spolehlivost při zřizování virtuálních počítačů.

Obrázky třetích stran

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

Závislost oblastí Azure

Pokud máte časově citlivou nebo produkční úlohu, neměli byste se spoléhat na jednu oblast Azure. I když se jedná o vzácné problémy, které můžou mít vliv na celou oblast. Pokud například vaše zpracování potřebuje začít v konkrétní době, zvažte vertikální navýšení kapacity fondu v primární oblasti ještě před časem zahájení. Pokud se škálování fondu nezdaří, můžete se vrátit k vertikálnímu navýšení kapacity fondu v oblasti zálohování (nebo oblastech).

Fondy napříč několika účty v různých oblastech poskytují připravené a snadno přístupné zálohování, pokud se něco nepovede s jiným fondem. Další informace najdete v tématu Návrh aplikace pro zajištění vysoké dostupnosti.

Ú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í jedné úlohy 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ů. Pokud jste použili 1 000 úloh, každý z nich má jeden úkol, který by byl nejméně efektivní, nejpomalejší a nejnákladnější přístup.

Vyhněte se 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ětší míře využívá kvóty úloh a plánů úloh.

Životnost úlohy

Úloha Batch má neomezenou dobu životnosti, dokud se ze systému nesmadí. Jeho stav určuje, zda může přijímat více úkolů pro plánování, nebo ne.

Úloha se automaticky nepřesune do dokončeného stavu, pokud není explicitně ukončena. Tuto akci lze automaticky aktivovat prostřednictvím onAllTasksComplete vlastnost nebo maxWallClockTime.

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

Odstraňte úlohy, když už nejsou potřeba, i když jsou v dokončeném stavu. I když se dokončené úlohy nezapočítávají do aktivní kvóty úloh, je vhodné pravidelně vyčistit dokončené úlohy. Například výpis úloh bude efektivnější, když je celkový počet úloh menší sada (i když se na požadavek použijí správné filtry).

Úlohy

Úkoly jsou jednotlivé jednotky práce, které tvoří úlohu. Úkoly odesílají uživatel a služba Batch je naplánuje do výpočetních uzlů. V následujících částech najdete návrhy návrhu úloh pro zvládnutí problémů a efektivní provádění.

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í , můžou usnadnit mizení uzlů. Když uzly opustí fond (kvůli změně velikosti nebo odstranění fondu), odstraní se také všechny soubory na těchto uzlech. Kvůli tomuto chování by úkol měl před dokončením přesunout výstup z uzlu, na kterém běží, a do odolného úložiště. Podobně pokud úloha selže, měla by přesunout protokoly potřebné k diagnostice selhání do trvalého úložiště.

Služba Batch má integrovanou podporu služby Azure Storage k nahrávání dat prostřednictvím výstupních souborů a s různými sdílenými systémy souborů nebo můžete provádět nahrávání sami ve svých úkolech.

Správa doby života úkolu

Odstraňte úkoly, pokud už nejsou potřeba, nebo nastavte omezení úkolu retentionTime . Pokud je nastavená retentionTime , služba Batch automaticky vyčistí místo na disku, které úloha používá při retentionTime vypršení platnosti.

Odstranění úkolů provádí dvě věci:

  • Zajišťuje, že v úloze nemáte sestavení úkolů. Tato akce vám pomůže vyhnout se potížím při hledání úkolu, který vás zajímá, protože budete muset filtrovat dokončené úkoly.
  • Vyčistí odpovídající data úkolů v uzlu (za předpokladu retentionTime , že ještě nebyla nalezena). Tato akce pomáhá zajistit, aby uzly nezaplnily data úkolů a nevyčerchá se místo na disku.

Poznámka:

U úkolů odeslaných do služby Batch trvá volání rozhraní API DeleteTask až 10 minut, než se projeví. Než se projeví, můžou se ostatním úkolům zabránit v naplánování. Je to proto, že se Služba Batch Scheduler stále snaží naplánovat právě odstraněné úkoly. Pokud chcete krátce po odeslání odstranit jeden úkol, ukončete místo toho úkol (protože se žádost o ukončení úkolu projeví okamžitě). A pak úkol odstraňte o 10 minut později.

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

Úkoly lze odesílat jednotlivě nebo v kolekcích. Odešlete úkoly do kolekcí až 100 najednou při hromadném odesílání úkolů, abyste snížili režii a čas odeslání.

Nastavení maximálního počtu úkolů na uzel odpovídajícím způsobem

Služba Batch podporuje předplacení úkolů na uzlech (spouštění více úkolů, než má uzel jádra). Je na vás, abyste měli jistotu, že vaše úkoly mají správnou velikost pro uzly ve vašem fondu. Pokud se například pokusíte naplánovat osm úloh, které spotřebovávají 25% využití procesoru na jeden uzel (ve fondu s taskSlotsPerNode = 8).

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

Službu Batch může automaticky opakovat úkoly. Existují dva typy opakování: uživatelem řízené a interní. Opakování řízená uživatelem jsou určena parametrem maxTaskRetryCount úkolu. Pokud program zadaný v úloze ukončí s nenulovým ukončovacím kódem, bude úloha opakovat až do hodnoty maxTaskRetryCount.

I když je to vzácné, může být úloha interně opakovat kvůli selháním výpočetního uzlu, jako je nemožnost aktualizovat interní stav nebo selhání na uzlu, když je úloha spuštěná. Úkol se bude opakovat na stejném výpočetním uzlu, pokud je to možné, až do interního limitu, než se pustí do úkolu a odloží úkol, který má služba Batch přeplánovat, potenciálně na jiném výpočetním uzlu.

Při provádění úloh na vyhrazených nebo spotových uzlech nejsou žádné rozdíly v návrhu. Bez ohledu na to, jestli je úkol při spuštění na spotovém uzlu nebo přerušený kvůli selhání na vyhrazeném uzlu, jsou obě situace zmírnit návrhem úlohy tak, aby odolat selhání.

Vytváření trvalých úloh

Úkoly by měly být navrženy tak, aby vydržely selhání a vyhovovaly opakování. Tento princip je zvlášť důležitý pro dlouhotrvající úlohy. Ujistěte se, že vaše úkoly generují stejný, jediný výsledek i v případě, že jsou spuštěné více než jednou. Jedním ze způsobů, jak dosáhnout tohoto výsledku, je vytvořit úkoly "hledání cílů". 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 se spustí).

Běžným příkladem je úloha kopírování souborů do výpočetního uzlu. Jednoduchým přístupem 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 vydrželo selhání. Místo toho vytvořte úlohu, která zajistí, že jsou soubory na výpočetním uzlu; úloha, která nerepíruje soubory, které už existují. Tímto způsobem úkol převezme místo, kde skončil, pokud byl přerušen.

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

Úlohy, které běží jenom po dobu jedné až dvou sekund, nejsou ideální. Pokuste se provést značné množství práce v individuálním úkolu (minimálně 10 sekund, přechod do hodin nebo dnů). Pokud se každý úkol spouští po dobu jedné minuty (nebo více), je režijní náklady na plánování ve zlomku celkové výpočetní doby malé.

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

Při plánování úkolu na uzlech Batch můžete zvolit, jestli se má spustit s oborem úkolu nebo oborem fondu. Pokud se úkol spustí jenom na krátkou dobu, rozsah úkolů může být neefektivní z důvodu prostředků potřebných k vytvoření automatického uživatelského účtu pro daný úkol. Pokud chcete větší efektivitu, zvažte nastavení těchto úloh na obor 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, který je vyhrazený ke zpracování části úlohy vaší aplikace. Při práci s uzly postupujte podle těchto pokynů.

Zahájení úkolů: životnost a idempotence

Stejně jako u jiných úkolů by měl být spouštěcí úkol uzlu idempotentní. Spouštěcí úlohy se znovu spustí, když se výpočetní uzel restartuje nebo když se agent Batch restartuje. Idempotentní úloha je jednoduše ta, která vytváří konzistentní výsledek při vícenásobném spuštění.

Spouštění úkolů by nemělo být dlouhotrvající nebo se spojte s životností výpočetního uzlu. Pokud potřebujete spustit programy, které jsou službami nebo službami podobné v přírodě, vytvořte spouštěcí úlohu, která těmto programům umožňuje spouštět a spravovat pomocí zařízení operačního systému, jako systemd jsou linuxové nebo služby systému Windows. Spouštěcí úkol by měl být stále vytvořen jako idempotentní, aby následné spuštění spouštěcí úlohy bylo zpracováno správně, pokud byly tyto programy dříve nainstalovány jako služby.

Tip

Když služba Batch znovu spustí spouštěcí úkol, pokusí se odstranit spouštěcí adresář úkolů a znovu ho vytvořit. Pokud se službě Batch nepodaří znovu vytvořit spouštěcí adresář úloh, výpočetní uzel se nepodaří spustit spouštěcí úlohu.

Tyto služby nesmí zabírat zámky souborů u souborů v adresářích spravovaných službou Batch na uzlu, protože jinak služba Batch nemůže tyto adresáře odstranit kvůli zámkům souborů. Například místo konfigurace spuštění služby přímo z pracovního adresáře spouštěcí úlohy zkopírujte soubory jinam v idempotentním způsobem. Pak nainstalujte službu z daného umístění pomocí zařízení operačního systému.

Izolované uzly

Zvažte použití izolovaných velikostí virtuálních počítačů pro úlohy s dodržováním předpisů nebo zákonnými požadavky. Podporované izolované velikosti v režimu konfigurace virtuálního počítače zahrnují Standard_E80ids_v4, , Standard_M128msStandard_F72s_v2, , Standard_G5, Standard_GS5a Standard_E64i_v3. Další informace o velikostech izolovaných virtuálních počítačů najdete v tématu Izolace virtuálních počítačů v Azure.

Vyhněte se vytváření spojení adresářů ve Windows

Spojení adresářů, někdy označovaná jako pevné odkazy adresáře, se při čištění úkolů a úloh obtížně zpracovávají. Místo pevných odkazů používejte odkazy symlinky (soft-links).

Dočasné disky a AZ_BATCH_NODE_ROOT_DIR

Služba Batch spoléhá na dočasné disky virtuálních počítačů kompatibilních se službou Batch, aby ukládala metadata související se spouštěním úkolů spolu s artefakty jednotlivých spuštění úloh na tomto dočasném disku. Příklady těchto dočasných přípojných bodů disku nebo adresářů jsou: /mnt/batch, /mnt/resource/batcha D:\batch\tasks. Nahrazení, opětovné připojení, spojení, symlinkování nebo jiné přesměrování těchto přípojných bodů a adresářů nebo některého z nadřazených adresářů není podporováno a může vést k nestabilitě. Pokud potřebujete více místa na disku, zvažte použití velikosti virtuálního počítače nebo řady s dočasným místem na disku, které splňuje vaše požadavky, nebo připojení datových disků. Další informace najdete v další části věnované připojení a přípravě datových disků pro výpočetní uzly.

Připojení a příprava datových disků

Každý jednotlivý výpočetní uzel má připojenou přesně stejnou specifikaci datového disku, pokud je určená jako součást instance fondu Batch. K fondům služby Batch je možné připojit pouze nové datové disky. Tyto datové disky připojené k výpočetním uzlům nejsou automaticky dělené, formátované ani připojené. Je vaší zodpovědností provádět tyto operace jako součást spouštěcího úkolu. Tyto spouštěcí úkoly musí být vytvořené tak, aby byly idempotentní. Opětovné spuštění spouštěcích úloh na výpočetních uzlech je možné. Pokud spouštěcí úkol není idempotentní, může dojít ke ztrátě dat na datových discích.

Tip

Pokud se při připojování datového disku v Linuxu vnořuje bod připojení disku do dočasných přípojných bodů Azure, například /mnt nebo /mnt/resource, je třeba dbát na to, aby nebyly zavedeny žádné závody závislostí. Pokud jsou například tato připojení automaticky prováděna operačním systémem, může existovat závod mezi připojeným dočasným diskem a připojenými datovými disky pod nadřazenou položkou. Je třeba provést kroky, které zajistí, aby byly vynucovány odpovídající závislosti dostupnými zařízeními, jako systemd je připojení datového disku k spouštěcí úloze jako součást skriptu pro přípravu disku s idempotentními daty.

Příprava datových disků ve fondech služby Linux Batch

Datové disky Azure v Linuxu se zobrazují jako bloková zařízení a mají přiřazený typický sd[X] identifikátor. Neměli byste se spoléhat na statická sd[X] přiřazení, protože tyto popisky se dynamicky přiřazují při spuštění a nezaručuje, že budou konzistentní mezi prvním a následným spuštěním. Připojené disky byste měli identifikovat prostřednictvím mapování uvedených v /dev/disk/azure/scsi1/souboru . Pokud jste například zadali logickou jednotku 0 pro datový disk v rozhraní API AddPool, tento disk by se manifestoval jako /dev/disk/azure/scsi1/lun0. Pokud byste například tento adresář vypsali, mohli byste vidět:

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

Není nutné překládat odkaz zpět na sd[X] mapování ve vašem přípravném skriptu, místo toho odkazovat přímo na zařízení. V tomto příkladu by toto zařízení bylo /dev/disk/azure/scsi1/lun0. Toto ID můžete zadat přímo do fdisknástroje a mkfsjakékoli další nástroje potřebné pro váš pracovní postup. Alternativně můžete použít lsblkblkid k mapování UUID disku.

Další informace o datových discích Azure v Linuxu, včetně alternativních metod vyhledání datových disků a /etc/fstab možností, najdete v tomto článku. Před povýšením metody do produkčního prostředí se ujistěte, že neexistují žádné závislosti ani rasy, jak je popsáno v poznámce Tip.

Příprava datových disků ve fondech služby Windows Batch

Datové disky Azure připojené k výpočetním uzlům Služby Batch pro Windows se zobrazují jako nedílné a neformátované. Jako součást spouštěcího úkolu je potřeba vytvořit výčet disků s RAW oddíly. Tyto informace je možné načíst pomocí rutiny PowerShellu Get-Disk . Jako příklad můžete vidět:

PS C:\Windows\system32> Get-Disk

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

Kde disk číslo 2 je neinicializovaný datový disk připojený k tomuto výpočetnímu uzlu. Tyto disky se pak dají inicializovat, dělit a formátovat podle potřeby pro váš pracovní postup.

Další informace o datových discích Azure ve Windows, včetně ukázkových skriptů PowerShellu, najdete v tomto článku. Před povýšení do produkčního prostředí se ujistěte, že jsou ověřeny všechny ukázkové skripty pro idempotenci.

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, před uvolněním dotčených uzlů shromážděte protokoly agenta Batch. Protokoly agenta Batch je možné shromažďovat pomocí rozhraní API pro nahrání protokolů služby Batch. Tyto protokoly je možné zadat jako součást lístku podpory microsoftu a pomůžou vám s řešením potíží a řešením problémů.

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

U účtů Batch v režimu předplatného uživatele můžou automatizované upgrady operačního systému přerušit průběh úkolů, zejména pokud jsou úkoly dlouho spuštěné. Vytváření idempotentních úloh může pomoct snížit chyby způsobené těmito přerušeními. Doporučujeme také naplánovat upgrady imagí operačního systému pro časy, kdy se neočekává spuštění úloh.

Pro fondy enableAutomaticUpdates Windows je ve výchozím nastavení nastavená hodnota true . Povolení automatických aktualizací se doporučuje, ale tuto hodnotu můžete nastavit, false pokud potřebujete zajistit, aby aktualizace operačního systému neočekávaně neproběhla.

Batch API

Selhání časového limitu

Selhání časového limitu nemusí nutně znamenat, že se službě nepodařilo požadavek zpracovat. Pokud dojde k selhání časového limitu, měli byste operaci zopakovat nebo podle situace načíst stav prostředku, abyste ověřili stav úspěšné nebo neúspěšné operace.

Připojení

Projděte si následující doprovodné materiály 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ů Batch ve virtuální síti se ujistěte, že pečlivě sledujete pokyny týkající se použití BatchNodeManagement.značka služby oblasti , porty, protokoly a směr pravidla. Použití značky služby se důrazně doporučuje; nepoužívejte základní IP adresy služby Batch, protože se můžou v průběhu času měnit. Použití IP adres služby Batch může přímo způsobit nestabilitu, přerušení nebo výpadky fondů Batch.

Pro trasy definované uživatelem se doporučuje použít BatchNodeManagement.značky služeb oblastimísto IP adres služby Batch, protože se můžou v průběhu času měnit.

Ctihodnosti DNS

Ujistěte se, že vaše systémy dodržují hodnotu TTL (Time to Live) DNS pro adresu URL vaší služby účtu Batch. Kromě toho se ujistěte, že klienti služby Batch a další mechanismy připojení ke službě Batch nespoléhá na IP adresy.

Všechny požadavky HTTP se stavovými kódy úrovně 5xx a hlavičkou "Připojení ion: close" v odpovědi vyžadují úpravu chování klienta služby Batch. Váš klient služby Batch by měl sledovat doporučení zavřením stávajícího připojení, opětovným překladem DNS pro adresu URL služby účtu Batch a pokusem o provedení následujících požadavků na nové připojení.

Žádosti o opakování se automaticky opakují.

Ujistěte se, že vaši klienti služby Batch mají správné zásady opakování, které automaticky opakují 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 zahrnovat interval nejméně 5 minut. Funkce automatického opakování jsou k dispozici s různými sadami SDK služby Batch, 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 můžou v průběhu životnosti fondu měnit. Tato dynamická povaha může ztížit interakci s databází nebo jinou externí službou, která omezuje přístup k určitým IP adresům. Pokud chcete tento problém vyřešit, 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í pomocí konfigurace Cloud Services

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

Podkladové závislosti uzlu služby Batch

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

Systémové prostředky vytvořené

Azure Batch vytvoří a spravuje sadu uživatelů a skupin na virtuálním počítači, což by nemělo být změněno:

Windows:

  • Uživatel s názvem PoolNon Správa
  • Skupina uživatelů s názvem WATaskCommon

Linux:

  • Uživatel s názvem _azbatch

Tip

Pojmenování těchto uživatelů nebo skupin jsou artefakty implementace a můžou se kdykoli změnit.

Vyčištění souboru

Služba Batch se aktivně snaží vyčistit pracovní adresář, ve kterých jsou úkoly spuštěné, jakmile vyprší jejich doba uchovávání. Všechny soubory zapsané mimo tento adresář jsou vaší zodpovědností vyčistit , aby se zabránilo zaplnění místa na disku.

Automatizované vyčištění pracovního adresáře bude zablokováno, pokud ve Windows spustíte službu z pracovního adresáře spouštěcí úlohy, protože složka se stále používá. Tato akce povede ke snížení výkonu. Pokud chcete tento problém vyřešit, změňte adresář této služby na samostatný adresář, který není spravován službou Batch.

Další kroky