Spolehlivost v Azure Batch

Tento článek popisuje podporu spolehlivosti ve službě Azure Batch. Popisuje, jak zlepšit odolnost uvnitř oblastí pomocí zón dostupnosti, fondů dávek a výpočetních uzlů za účelem minimalizace výpadků a ztráty dat. Odkazuje také na informace o obnovení mezi oblastmi a kontinuitě podnikových procesů.

Podpora zón 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.

Služba Batch udržuje paritu s Azure při podpoře zón dostupnosti.

Požadavky

• U účtů Batch v režimu předplatného uživatele se ujistěte, že předplatné, ve kterém vytváříte fond, nemá omezení nabídky podle zón na požadované skladové číslo virtuálního počítače (VM SKU). Pokud chcete zjistit, jestli vaše předplatné nemá žádná omezení, zavolejte Resource Skus List API a zkontrolujte ResourceSkuRestrictions. Pokud omezení zóny existuje, můžete odeslat lístek podpory, který omezení zóny odebere.

• Protože InfiniBand nepodporuje komunikaci mezi zónami, nemůžete vytvořit fond se zónovou zásadou, pokud má povolenou komunikaci mezi uzly a používá SKU virtuálního počítače, které podporuje InfiniBand.

• Služba Batch udržuje paritu s Azure při podpoře zón dostupnosti. Pokud chcete použít zónovou možnost, musí být váš fond vytvořen v oblasti Azure s podporou zóny dostupnosti.

• Pokud chcete přidělit fond Batch napříč zónami dostupnosti, musí oblast Azure, ve které byl fond vytvořen, podporovat požadovanou skladovou položku virtuálního počítače ve více než jedné zóně. Pokud chcete ověřit, že oblast podporuje požadované SKU virtuálního počítače ve více než jedné zóně, použijte rozhraní API seznamu SKU prostředků a zkontrolujte locationInfo pole resourceSku. Ujistěte se, že pro požadovanou skladovou položku virtuálního počítače je podporováno více než jedna zóna. K zobrazení seznamu všech dostupných Resource SKUs můžete také použít Azure CLI pomocí následujícího příkazu:

  
      az vm list-skus
  
  

Vytvoření fondu Azure Batch napříč zónami dostupnosti

Příklady vytvoření fondu Batch napříč zónami dostupnosti najdete v tématu Vytvoření fondu Služby Azure Batch napříč zónami dostupnosti.

Přečtěte si další informace o vytváření účtů Batch pomocí webu Azure Portal, Azure CLI, PowerShellu nebo rozhraní API pro správu služby Batch.

Zklidňující zážitek

Během výpadku zóny se uzly v této zóně stanou nedostupnými. Všechny uzly v rámci stejného fondu uzlů z jiných zón nejsou ovlivněné a budou dál dostupné.

Účet Azure Batch nepřerozděluje ani nevytváří nové uzly, aby kompenzoval uzly, které jsou nedostupné kvůli výpadku. Uživatelé jsou povinni přidat do fondu uzlů další uzly, které se pak přidělují z jiných funkčních zón.

Odolnost proti chybám

Pokud se chcete připravit na možné selhání zóny dostupnosti, měli byste kapacitu služby předimenzovat, abyste zajistili, že řešení dokáže tolerovat ztrátu kapacity ve výši 1/3 a pokračovat v fungování bez degradace výkonu během výpadků v celé zóně. Vzhledem k tomu, že platforma rozloží virtuální počítače mezi tři zóny a potřebujete počítat s alespoň selháním jedné zóny, vynásobte počet instancí úloh ve špičce faktorem zón/(zóny-1) nebo 3/2. Pokud například typická úloha ve špičce vyžaduje čtyři instance, měli byste zřídit šest instancí: (2/3 × 6 instancí) = 4 instance.

Migrace zóny dostupnosti

Do podpory zóny dostupnosti nemůžete migrovat existující fond Batch. Pokud chcete znovu nastavit fond Batch napříč zónami dostupnosti, přečtěte si téma Vytvoření fondu služby Azure Batch v různých zónách dostupnosti.

Zotavení po havárii napříč oblastmi a provozní kontinuita

Azure Batch je k dispozici ve všech oblastech Azure. Když se ale účet Batch vytvoří, musí být přidružený k jedné konkrétní oblasti. Všechny následné operace pro tento účet Batch platí jenom pro danou oblast. Například fondy a přidružené virtuální počítače (VM) jsou vytvořeny ve stejné oblasti jako účet Batch.

Při návrhu aplikace, která používá službu Batch, musíte zvážit možnost, že služba Batch nemusí být dostupná v oblasti. Je možné narazit na vzácnou situaci, kdy je problém s oblastí jako celku, celou službou Batch v dané oblasti nebo konkrétním účtem Batch.

Pokud musí být aplikace nebo řešení používající službu Batch vždy k dispozici, měla by být navržena tak, aby buď provedla převzetí služeb při selhání do jiného regionu, nebo aby byl pracovní zátěž vždy rozdělena mezi dva nebo více regionů. Oba přístupy vyžadují alespoň dva účty Batch, přičemž každý účet se nachází v jiné oblasti.

Zodpovídáte za nastavení zotavení po havárii napříč oblastmi pomocí služby Azure Batch. Pokud spouštíte více účtů Batch v konkrétních oblastech a využíváte zóny dostupnosti, může vaše aplikace splnit cíle zotavení po havárii, když některý z vašich účtů Batch přestane být dostupný.

Při zajištění možnosti převzetí služeb při selhání do alternativní oblasti je nutné zvážit všechny komponenty v řešení; nestačí mít pouze další účet Batch. Ve většině aplikací Batch se například vyžaduje účet úložiště Azure. Pro přijatelný výkon musí být účet úložiště a účet Batch ve stejné oblasti.

Zvažte následující body při návrhu řešení, které může přepnout na záložní systém:

• Předem vytvořit všechny požadované služby v každé oblasti, jako je účet Batch a účet úložiště. Často se neúčtují žádné poplatky za vytvoření účtů a poplatky se účtují jenom v případě, že se účet použije nebo když jsou uložená data.

• Ujistěte se, že jsou předem nastavené příslušné kvóty pro všechny Batchové účty uživatelského předplatného, aby bylo možné přidělit požadovaný počet jader pomocí účtu Batch.

• Pomocí šablon a/nebo skriptů můžete automatizovat nasazení aplikace v oblasti.

• Udržujte binární soubory aplikací a referenční data aktuální ve všech oblastech. Udržování aktuálního stavu zajistí, že se oblast dá rychle převést do online režimu, aniž byste museli čekat na nahrání a nasazení souborů. Představte si například případ, kdy je vlastní aplikace určená k instalaci na uzly fondu uložená a odkazovaná prostřednictvím balíčků aplikací Batch. Při vydání aktualizace aplikace se musí nahrát do každého účtu Batch a být přidána do konfigurace fondu (nebo nastavit nejnovější verzi jako výchozí verzi).

• V aplikaci, která volá službu Batch, úložiště a všechny ostatní služby, zajistěte snadné přepnutí klientů nebo zatížení do různých oblastí.

• V rámci normálního provozu zvažte časté přepnutí na alternativní oblast. Například s dvěma nasazeními v samostatných oblastech přepněte každý měsíc na alternativní oblast.

Doba trvání zotavení po havárii závisí na zvoleném nastavení. Samotná služba Batch je nezávislá na tom, jestli používáte více účtů nebo jeden účet. V konfiguracích aktivní-aktivní, kde dvě instance služby Batch přijímají provoz současně, je zotavení po havárii rychlejší než u konfigurace typu aktivní-pasivní. Kterou konfiguraci zvolíte, by měla být založená na obchodních potřebách (různé oblasti, požadavky na latenci) a technických aspektech.

Zotavení po havárii v jedné oblasti

Způsob implementace zotavení po havárii ve službě Batch je stejný bez ohledu na to, jestli pracujete v jedné oblasti nebo v geografické oblasti s více oblastmi. Jedinými rozdíly jsou to, které SKU používáte pro úložiště, a zda máte v úmyslu použít stejný nebo jiný účet úložiště ve všech oblastech.

Testování zotavení po havárii

Měli byste provést vlastní testování zotavení po havárii vašeho řešení s podporou služby Batch. Považuje se za osvědčený postup, jak umožnit snadné přepínání mezi zatížením klienta a služby v různých oblastech.

Testování plánu zotavení po havárii pro službu Batch může být stejně jednoduché jako střídání různých účtů Batch. Můžete například spoléhat na jeden účet Batch v konkrétní oblasti po dobu jednoho provozního dne. Další den pak můžete přepnout na druhý účet Batch v jiné oblasti. Zotavení po havárii se primárně spravuje na straně klienta. Tento přístup s více účty k zotavení po havárii se postará o očekávání RTO a RPO v jedné oblasti nebo v několika geografických oblastech.

Odolnost proti zotavení po havárii a proaktivní kapacita

Společnost Microsoft a její zákazníci pracují v rámci modelu sdílené odpovědnosti. Microsoft zodpovídá za odolnost platformy a infrastruktury. Zodpovídáte za řešení zotavení po havárii pro jakoukoli konkrétní službu, kterou nasazujete a řídíte. Aby bylo zajištěno, že obnovení je proaktivní:

• Vždy byste měli nasadit předem sekundární jednotky. Předplnění sekundárních zdrojů je nezbytné, protože v době dopadu na ty, kteří tyto prostředky předem nepřidělili, neexistuje žádná záruka kapacity.

• Předem vytvořit všechny požadované služby v každé oblasti, jako jsou účty Batch a přidružené účty úložiště. Za vytváření nových účtů se neúčtují žádné poplatky; poplatky se účtují pouze v případech, kdy se účet používá nebo když jsou uložená data.

• Ujistěte se, že jsou příslušné kvóty nastavené pro všechna předplatná předem, abyste mohli přidělit požadovaný počet jader pomocí účtu Batch. Stejně jako u jiných služeb Azure platí omezení pro určité prostředky přidružené ke službě Batch. Mnohé z těchto omezení jsou výchozí kvóty, které Azure uplatňuje na úrovni předplatného nebo účtu. Mějte tyto kvóty na paměti při návrhu a vertikálním navýšení kapacity úloh služby Batch.

Poznámka:

Pokud plánujete spouštět produkční úlohy ve službě Batch, možná budete muset zvýšit jednu nebo více kvót nad výchozí hodnotu. Pokud chcete kvótu zvýšit, můžete požádat o navýšení kvóty bez poplatků. Další informace najdete v tématu Žádost o navýšení kvóty.

Storage

Abyste zajistili zálohování dat napříč regiony, musíte nakonfigurovat úložiště Batch; výchozí odpovědnost nese zákazník. Většina řešení Batch používá Azure Storage k ukládání souborů prostředků a výstupních souborů. Například úkoly služby Batch (včetně standardních úkolů, spouštěcích úkolů, úkolů přípravy úloh a úkolů uvolnění úloh) obvykle určují soubory prostředků, které jsou umístěné v účtu úložiště. Účty úložiště také ukládají data, která se zpracovávají, a všechna vygenerovaná výstupní data. Důležitým aspektem je pochopení možné ztráty dat napříč oblastmi operací služby. Musíte také ověřit, jestli jsou data přepisovatelná nebo jen pro čtení.

Batch podporuje následující typy účtů Azure Storage:

• Účty pro obecné účely verze 2 (GPv2)
• Účty pro obecné účely verze 1 (GPv1)
• Účty úložiště Blob (v současnosti podporuje fondy v konfiguraci virtuálního počítače)

Další informace o účtech úložiště najdete v přehledu účtu Azure Storage.

Účet úložiště můžete přidružit k účtu Batch, když účet vytvoříte nebo tento krok provedete později.

Pokud nastavujete samostatný účet úložiště pro každou oblast, ve které je vaše služba dostupná, musíte použít účty zónově redundantního úložiště (ZRS). Pokud používáte stejný účet úložiště ve více spárovaných oblastech, použijte účty geograficky zónově redundantního úložiště (GZRS). U geografických oblastí, které obsahují jednu oblast, musíte vytvořit účet zónově redundantního úložiště (ZRS), protože GZRS není k dispozici.

Plánování kapacity je dalším důležitým aspektem úložiště a mělo by se aktivně řešit. Při výběru účtu úložiště zvažte své požadavky na náklady a výkon. Například možnosti účtu úložiště GPv2 a účtu úložiště objektů blob podporují ve srovnání s účty GPv1 vyšší limity kapacity a škálovatelnosti. (Pokud chcete požádat o navýšení limitu úložiště, obraťte se na podporu Azure.) Tyto možnosti účtu můžou zlepšit výkon řešení Batch, která obsahují velký počet paralelních úloh, které čtou nebo zapisují do účtu úložiště.

Když je účet úložiště propojený s účtem Batch, představte si ho jako účet automatického úložiště. K používání funkce balíčků aplikací je vyžadován účet automatického úložiště, protože se používá k ukládání souborů balíčku aplikací .zip. Účet automatického úložiště lze použít také pro soubory prostředků úkolů; protože je účet automatického úložiště již propojen s účtem Batch, není potřeba používat adresy URL sdíleného přístupového podpisu (SAS) k přístupu k souborům prostředků.

Další kroky

• Spolehlivost v Azure