Spolehlivost ve službě Azure Batch

Tento článek popisuje podporu spolehlivosti ve službě Azure Batch a zabývá se vnitřní odolností zón dostupnosti a odkazy na informace o obnovení mezi oblastmi a kontinuitě podnikových procesů.

Podpora zón dostupnosti

Zóny dostupnosti Azure jsou aspoň tři fyzicky oddělené skupiny datacenter v rámci každé oblasti Azure. Datová centra v každé zóně jsou vybavena nezávislou infrastrukturou napájení, chlazení a sítě. V případě selhání místní zóny jsou zóny dostupnosti navrženy tak, aby v případě ovlivnění jedné zóny, regionální služby, kapacity a vysoké dostupnosti podporovaly zbývající dvě zóny.

Selhání můžou být v rozsahu od selhání softwaru a hardwaru až po události, jako jsou zemětřesení, záplavy a požáry. Odolnost vůči selháním se dosahuje redundancí a logickou izolací služeb Azure. Podrobnější informace o zónách dostupnosti v Azure najdete v tématu Oblasti a zóny dostupnosti.

Služby s podporou zón dostupnosti Azure jsou navržené tak, aby poskytovaly správnou úroveň spolehlivosti a flexibility. Dají se nakonfigurovat dvěma způsoby. Můžou být buď zónově redundantní, s automatickou replikací napříč zónami, nebo zónově, s instancemi připnutými ke konkrétní zóně. Tyto přístupy můžete také kombinovat. Další informace o zónové a zónově redundantní architektuře najdete v tématu Doporučení pro použití zón dostupnosti a oblastí.

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 zóny na požadované skladové po straně virtuálního počítače. Pokud chcete zjistit, jestli vaše předplatné nemá žádná omezení, zavolejte rozhraní API seznamu skladových položek prostředků 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 s zónovými zásadami, pokud má povolenou komunikaci mezi uzly a používá skladovou položku 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žadovanou skladovou položku virtuálního počítače ve více než jedné zóně, zavolejte rozhraní API seznamu skladových položek 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. Pomocí Azure CLI můžete také zobrazit seznam všech dostupných skladových položek prostředků 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.

Prostředí pro zónu dolů

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 nespravuje ani nevytváří nové uzly, které by kompenzovaly uzly, které se kvůli výpadku ztratily. Uživatelé musí do fondu uzlů přidat další uzly, které se pak přidělují z jiných zón, které jsou v pořádku.

Odolnost proti chybám

Pokud se chcete připravit na možné selhání zóny dostupnosti, měli byste kapacitu služby nadříznout, abyste zajistili, že řešení dokáže tolerovat ztrátu kapacity 1/3 a pokračovat v fungování bez snížení 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 vytvořit fond Batch napříč zónami dostupnosti, přečtěte si téma Vytvoření fondu Služby Azure Batch napříč zónami 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 se vytvoří 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ď převzetí služeb při selhání do jiné oblasti, nebo vždy měla rozdělení úloh mezi dvě nebo více oblastí. 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 poskytová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čí, abyste měli jenom druhý úč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.

Při návrhu řešení, které může provést převzetí služeb při selhání, zvažte následující body:

• 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 účty Batch předplatného uživatelů, abyste přidělily 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 se vlastní aplikace, která se instaluje na uzly fondu, uložená a odkazovaná pomocí balíčků aplikací Batch. Při vydání aktualizace aplikace by se měla nahrát do každého účtu Batch a odkazovat na konfiguraci 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, usnadňuje přepínání 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 skladová položka, kterou používáte pro úložiště, a to, jestli 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řídavý účet 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 cíle bodu obnovení v jedné oblasti nebo v geografických oblastech s více oblastmi.

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 předplnět sekundární soubory. 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.

Úložiště

Abyste zajistili zálohování dat mezi oblastmi, musíte nakonfigurovat úložiště Batch. odpovědnost zákazníka je výchozí. 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ě. Pokud plánujete používat funkce balíčků aplikací, protože se používá k ukládání balíčků aplikace .zip souborů, je vyžadován účet automatického úložiště. Pro soubory prostředků úkolů se dá použít také účet automatického úložiště. Protože účet automatického úložiště je již propojený s účtem Batch, zabráníte tomu, aby se k souborům prostředků přistupovaly adresy URL sdíleného přístupového podpisu (SAS).

Další kroky

• Spolehlivost v Azure