Sdílet prostřednictvím

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.

Návod

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.

Bazény

Pools 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žiny scénářů. Další informace najdete v tématu Konfigurace pro režim předplatného uživatele.

  • 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 požadovaných příchozích a odchozích připojení a k tomu, že pro základní provoz není vyžadován odchozí přístup ke službě Azure Storage, 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. Čas přidělení uzlů zkrátí dobu trvání ú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 podpory pro dávkové zpracování (EOL). Tato data je možné zjistit prostřednictvím rozhraní API, ListSupportedImages nebo Azure CLI. Je vaší odpovědností pravidelně obnovovat přehled o datumech konce životnosti souvisejících s vašimi skupinami a migrovat úlohy před datem konce životnosti. Pokud používáte vlastní obrázek se zadaným agentem uzlu, ujistěte se, že dodržujete data ukončení podpory služby Batch pro obrázek, z něhož je váš vlastní obrázek odvozený nebo s nímž je zarovnaný. 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.

  • SKU virtuálních počítačů s blížícím se koncem životnosti (EOL): Stejně jako u imagí virtuálních počítačů, i SKU nebo rodiny virtuálních počítačů můžou dosáhnout konce podpory Batch (EOL). Tato data je možné zjistit prostřednictvím rozhraní API, ListSupportedVirtualMachineSkus nebo Azure CLI. Naplánujte migraci úlohy na SKU virtuálního počítače, která není na konci životnosti, vytvořením nového fondu s příslušnou podporovanou SKU virtuálního stroje. 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.) se často objevují a mizí 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žívání jedinečných názvů vám usnadňuje zjistit, který konkrétní prostředek něco udělal v protokolech a metrikách. Rovněž odstraní nejednoznačnost, pokud byste někdy museli podat žádost o podporu pro službu.

  • 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í stejný fond pro všechno, je možné, že se úlohy nespustí, pokud dojde k nějakému problému s fondem. 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. Ujistěte se, že v případě potřeby můžete přesměrovat úlohy do jiného fondu (případně s jinou velikostí virtuálního počítače pomocí UpdateJob). Vyhněte se spoléhat se na ID statického fondu s očekáváním, že nikdy nebude odstraněno a nikdy se nezmění.

Zabezpečení bazénu

Hranice izolace

Pro účely izolace, pokud váš scénář vyžaduje izolovat úlohy nebo úkoly od sebe navzájem, mějte je v samostatných poolech. Fond je hranicí bezpečnostní izolace ve službě Batch, a ve výchozím nastavení nejsou dva fondy viditelné ani schopné vzájemně komunikovat. 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.

V případě potřeby se na účet Batch a rozhraní API musí použít správné řízení přístupu, aby se zabránilo přístupu ke všem fondům v rámci účtu Batch. Doporučuje se zakázat přístup pomocí sdílených klíčů a povolit pouze ověřování založené na systému Entra pro umožnění řízení přístupu na základě role.

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 služby Batch, musíte nastavit velikost fondu na nula výpočetních uzlů nebo znovu vytvořit fond. Doporučujeme sledovat poznámky k vydání agenta uzlu Batch, abyste porozuměli změnám v nových verzích 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 obraz virtuálního počítače vybraný pro fond Batch byl aktuální s nejnovějšími bezpečnostními aktualizacemi poskytovanými vydavatelem. Některé image můžou při spuštění provádět automatické aktualizace balíčků (nebo krátce potom), které můžou narušit určité akce řízené uživatelem, jako je například načítání aktualizací úložiště balíčků (například apt update) nebo instalace balíčků během akcí, jako je startTask.

Doporučuje se povolit automatický upgrade operačního systému pro fondy Batch, což umožňuje základní infrastruktuře Azure koordinovat aktualizace napříč fondem. Tuto možnost je možné nakonfigurovat tak, aby neprobírala provádění úkolů. Automatický upgrade operačního systému nepodporuje všechny operační systémy, které Služba Batch podporuje. Další informace najdete v Matici podpory automatického upgradu OS pro škálovací sady virtuálních strojů. V případě operačních systémů Windows se ujistěte, že při použití automatického upgradu operačního systému ve fondu Batch nepovolujete vlastnost virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates .

Azure Batch neověřuje ani nezaručuje, že image povolené pro použití se službou mají nejnovější aktualizace zabezpečení. Aktualizace obrazů jsou v kompetenci vydavatele obrazů, a nikoliv pod pravomocí 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 poolu

Ž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. Pooly mohou mít libovolnou životnost a proměnlivý počet výpočetních uzlů v které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).

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

  • Efektivita a fakturace Batch: 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 jeho stav. 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 kdykoli během prvního přidělení nebo při 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á. Váš základní limit není zárukou, ale spíše limitem.

Neplánovaný výpadek

Ve fondech "Batch" mohou nastat 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í sady obrázků

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 podporovaným obrazem z Azure Marketplace, nebo můžete vytvořit vlastní obraz s použitím obrazu z Galerie Azure Compute. I když můžete ke vytvoření vlastního fondu obrazů použít spravovaný obraz, doporučujeme vytvářet vlastní obrazy 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

Pooly je možné vytvářet pomocí obrazů třetích stran publikovaných na Azure Marketplace. U účtů Batch v režimu uživatelského předplatného se může při vytváření fondu pomocí určitých obrázků třetích stran zobrazit chyba "Přidělení selhalo kvůli kontrole oprávnění k nákupu v tržišti". 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.

Skupiny kontejnerů

Při vytváření fondu Batch s virtuální sítí může dojít k vedlejším účinkům interakce mezi touto zadanou virtuální sítí a výchozím mostem Dockeru. Docker ve výchozím nastavení vytvoří most pro síť se specifikací podsítě 172.17.0.0/16. Ujistěte se, že mezi síťovým mostem Dockeru a vaší virtuální sítí nejsou žádné konfliktní rozsahy IP adres.

Docker Hub omezuje počet stažení obrazů. Ujistěte se, že vaše pracovní zatížení nepřekračuje publikované limity rychlosti pro image umístěné na Docker Hubu. Doporučuje se použít Službu Azure Container Registry přímo nebo využít mezipaměť Artefaktů v ACR.

Závislost regionů 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 navýšení kapacity zdrojů v primární oblasti ještě před časem zahájení. Pokud se škálování fondu nezdaří, můžete se vrátit k rozšíření kapacity fondu v záložní oblasti (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í jediného úkonu 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, z nichž každá měla jeden úkol, byl by to 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. Na úkoly neexistuje žádná kvóta, takže efektivní provádění mnoha úkolů pod co nejmenším počtem úloh efektivně využívá vaše kvóty pro úlohy a plány úloh.

Životnost úlohy

Úloha Batch má neomezenou dobu životnosti, dokud se ze systému nesmaže. 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 rozvrhu úloh. Úlohy a plány úloh v dokončeném stavu se do této kvóty nezapočítávají.

Odstraňte úlohy, pokud je již nepotřebujete, i když jsou ve hotové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 bude výpis úloh efektivnější, pokud je celkový počet úloh menší (dokonce 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í, mohou způsobit snadné zmizení uzlů. Pokud uzly opustí fond z důvodu změny velikosti nebo smazání fondu, odstraní se rovněž 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á, když retentionTime vyprší.

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

  • Zajišťuje, že nemáte nahromadění úkolů v pracovním úkolu. 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, pokud retentionTime ještě nebyla zasažena. Tato akce pomáhá zajistit, aby vaše uzly nebyly zaplněny daty úkolů a nevyčerpalo 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ůže být zabráněno naplánování ostatních úkolů. 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.

Odeslat velký počet úkolů v kolekci

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

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

Služba Batch podporuje přetěžování úkolů na uzlech (spouštění více úkolů, než kolik má uzel svých jader). 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é každá spotřebovává 25 % procesoru, na jeden uzel (v rámci fondu s taskSlotsPerNode = 8), může být váš zážitek zhoršený.

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

Úkoly může služba Batch automaticky opakovat. 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ě opakována kvůli selháním výpočetního uzlu, jako je nemožnost aktualizovat interní stav nebo selhání na uzlu během spuštění úlohy. Ú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, zda je úkol přerušen během běhu na Spot uzlu nebo kvůli selhání na vyhrazeném uzlu, lze obě situace řešit návrhem úlohy tak, aby odolala 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ému času 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), jsou režijní náklady na plánování ve zlomku celkové výpočetní doby malé.

Použijte rozsah fondů pro krátké úlohy na uzlech Windows

Při plánování úkolu na uzlech Batch můžete zvolit, zda ho spustit s rozsahem úkolu nebo rozsahem fondu. Pokud se úkol spustí jen krátce, může být rozsah úkolů neefektivní z důvodu prostředků potřebných k vytvoření účtu automatického uživatele pro danou úlohu. Pokud chcete dosáhnout větší efektivity, zvažte nastavení těchto úloh v rámci 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í.

Úvodní úkoly by neměly být dlouhotrvající nebo být svázány s životností výpočetního uzlu. Pokud potřebujete spustit programy, které jsou službami nebo mají povahu služeb, vytvořte spouštěcí úlohu, která těmto programům umožňuje být spouštěny a spravovány pomocí funkcí operačního systému, jako jsou Linux 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.

Návod

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 adresář spouštěcí úlohy, výpočetní uzel se nepodaří spustit tuto ú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 symbolické odkazy.

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ý výpočetní uzel má připojenou naprosto stejnou specifikaci datového disku, pokud je to určeno 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.

Návod

Pokud se při připojování datového disku v Linuxu vnořuje bod připojení disku pod dočasné přípojné body 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 prostřednictvím dostupných zařízení, jako například prostřednictvím systemd, nebo aby bylo odloženo připojení datového disku ke spouštěcí úloze jako součást vašeho skriptu pro přípravu idempotentního datového disku.

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 jsou dynamicky přiřazovány při spuštění a není zaručeno, že budou konzistentní mezi prvním a jakýmkoli následným spuštěním. Připojené disky byste měli identifikovat prostřednictvím mapování uvedeného v /dev/disk/azure/scsi1/. 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, odkazujte místo toho 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 fdisk, mkfs a všech dalších nástrojů, které jsou potřeba 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 nasazením metody do produkčního prostředí se ujistěte, že neexistují žádné závislosti ani časové závody, jak je uvedeno 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 nasazením do produkčního prostředí se ujistěte, že všechny ukázkové skripty byly ověřeny z hlediska idempotence.

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 mohou být zadány jako součást podpůrného lístku Microsoftu a pomohou s detekcí a řešením problémů.

Dávková 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í značky služby BatchNodeManagement.region, o porty, o protokoly a o 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. Přímé použití IP adres služby Batch může způsobit nestabilitu, přerušení nebo výpadky vašich 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.

Pocta DNS

Ujistěte se, že vaše systémy dodržují hodnotu TTL (Time-to-Live) v DNS pro URL adresu 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éhají na IP adresy.

Všechny požadavky HTTP se stavovými kódy úrovně 5xx a hlavičkou Connection: close v odpovědi vyžadují úpravu chování klienta služby Batch. Váš klient služby Batch by měl postupovat podle doporučení tím, že nejprve zavře stávající připojení, poté znovu přeloží DNS pro adresu URL služby účtu Batch, a nakonec se pokusí odeslat následující požadavky na nové připojení.

Automatické opakování žádostí.

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. K dispozici jsou automatické možnosti opětovného pokusu s různými sadami Batch SDK, jako je 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.

Podkladové závislosti uzlu služby Batch

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

Vytvořené systémem prostředky

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 PoolNonAdmin
  • Skupina uživatelů s názvem WATaskCommon

Linux:

  • Uživatel s názvem _azbatch

Návod

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ář, kde jsou úkoly spuštěny, jakmile vyprší jejich doba uchová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

  • Last updated on