Aspekty provozní kontinuity a zotavení po havárii (BCDR) se službou Azure OpenAI

Azure OpenAI je k dispozici ve více oblastech. Při vytváření prostředku Azure OpenAI zadáte oblast. Od tého dne zůstane váš prostředek a všechny jeho operace přidružené k dané oblasti serveru Azure.

Je vzácné, ale ne nemožné, aby se vyskytl problém se sítí, který zasáhne celou oblast. Pokud vaše služba musí být vždy dostupná, měli byste ji navrhnout tak, aby buď přebíslala do jiné oblasti, nebo rozdělte úlohu mezi dvě nebo více oblastí. Oba přístupy vyžadují alespoň dva prostředky Azure OpenAI v různých oblastech. Tento článek obsahuje obecná doporučení k implementaci provozní kontinuity a zotavení po havárii (BCDR) pro aplikace Azure OpenAI.

Ve výchozím nastavení poskytuje služba Azure OpenAI výchozí smlouvu SLA. I když výchozí odolnost může být dostatečná pro mnoho aplikací, aplikace vyžadující vysokou míru odolnosti a kontinuity podnikových procesů by měly podniknout další kroky k dalšímu posílení infrastruktury modelu.

Standardní nasazení

Poznámka:

Pokud můžete použít nasazení Global Standard, měli byste je použít. Nasazení zóny dat jsou další nejlepší volbou pro organizace, které vyžadují, aby se zpracování dat stalo zcela v rámci geografické hranice.

1. U standardních nasazení se ve výchozím nastavení nastaví nasazení zóny dat (možnosti USA/EU).

2. V předplatném Azure byste měli nasadit dva prostředky služby Azure OpenAI. Jeden prostředek by měl být nasazený ve vaší upřednostňované oblasti a druhý by se měl nasadit ve vaší sekundární oblasti nebo oblasti převzetí služeb při selhání. Služba Azure OpenAI přiděluje kvótu na úrovni předplatného + oblast, aby mohly žít ve stejném předplatném bez dopadu na kvótu.

3. Pro každý model, který plánujete použít, byste měli mít jedno nasazení nasazené do prostředku služby Azure OpenAI v upřednostňované oblasti Azure a měli byste tato nasazení modelu duplikovat v sekundární oblasti nebo v oblasti převzetí služeb při selhání. Každému z těchto koncových bodů přidělte úplnou kvótu dostupnou ve standardním nasazení. To poskytuje nejvyšší rychlost propustnosti v porovnání s rozdělením kvóty napříč několika nasazeními.

4. Vyberte oblast nasazení na základě topologie vaší sítě. Prostředek služby Azure OpenAI můžete nasadit do libovolné podporované oblasti a pak vytvořit privátní koncový bod pro tento prostředek ve vaší upřednostňované oblasti.

   • Jakmile se služba Azure OpenAI nachází v rámci hranice služby Azure OpenAI, služba Azure OpenAI optimalizuje směrování a zpracování napříč dostupnými výpočetními prostředky v zóně dat.
   • Použití datových zón je efektivnější a jednodušší než samoobslužné vyrovnávání zatížení napříč několika regionálními nasazeními.

5. Pokud dojde k oblastnímu výpadku, ve kterém je nasazení v nepoužitelném stavu, můžete použít druhé nasazení v sekundární/pasivní oblasti ve stejném předplatném.

   • Vzhledem k tomu, že primární i sekundární nasazení jsou nasazení zón, využívají stejný fond kapacity zóny, který využívá všechny dostupné oblasti v zóně. Sekundární nasazení chrání před nedostupným primárním koncovým bodem Azure OpenAI.
   • Použijte bránu Generative AI, která podporuje vyrovnávání zatížení a model jističe, jako je api Management před koncovými body služby Azure OpenAI, takže přerušení během regionálního výpadku je minimalizované na využívání aplikací.
   • Pokud se kvóta v rámci daného předplatného vyčerpá, můžete nové předplatné nasadit stejným způsobem jako výše a jeho koncový bod nasazený za bránou Generative AI.

Zřízená nasazení

Vytvoření fondu ptu organizace

1. Pro zřízená nasazení doporučujeme mít jedno nasazení PTU zóny dat (k dispozici 12. 4. 2024), které slouží jako fond PTU organizace. Pomocí služby API Management můžete spravovat provoz z více aplikací a nastavit limity propustnosti, protokolování, prioritu a logiku převzetí služeb při selhání.
   • Tento fond PTU organizace si představte jako prostředek "Privátní průběžné platby", který chrání před problémem hlučných sousedů, který může nastat u standardních nasazení, když je poptávka po službě vysoká. Vaše organizace bude mít zaručený vyhrazený přístup k fondu kapacity, který je k dispozici pouze vám, a proto nezávisle na špičkách poptávky od jiných zákazníků.
   • Díky tomu budete mít kontrolu nad tím, které aplikace se nejprve zvýší latence, což vám umožní určit prioritu provozu do důležitých aplikací.
   • Zřízená nasazení jsou zajištěná smlouvami SLA s latencí, díky kterým jsou vhodnější než standardní nasazení (průběžných plateb) pro úlohy citlivé na latenci.
   • Nasazení podnikového PTU také umožňuje vyšší míru využití, protože provoz je vyhlazený napříč úlohami aplikací, zatímco jednotlivé úlohy mají tendenci být náchylnější ke špičkám.
2. Primární nasazení ptu organizace by mělo být v jiné oblasti než vaše primární nasazení standardní zóny. To znamená, že pokud dojde k výpadku oblasti, nepřijdete o přístup ke svému nasazení PTU i k nasazení zón úrovně Standard současně.

Nasazení vyhrazeného PTU pro úlohy

1. Některé úlohy můžou potřebovat vlastní vyhrazené zřízené nasazení. Pokud ano, můžete pro tuto aplikaci vytvořit vyhrazené nasazení PTU.
2. Nasazení fondu úloh a podnikových fondů PTU by se měly chránit před regionálními selháními. Můžete to udělat tak, že umístíte fond PTU úloh do oblasti A a fondu PTU organizace v oblasti B.
3. Toto nasazení by mělo převzít služby při selhání nejprve do fondu podnikových PTU a pak do standardního nasazení. To znamená, že když využití nasazení PTU úlohy překročí 100 %, požadavky by stále obsluhovaly koncové body PTU, což pro danou aplikaci umožňuje smlouvu SLA s vyšší latencí.

Další výhodou této architektury je, že umožňuje naskládat standardní nasazení se zřízenými nasazeními, abyste mohli vytočit upřednostňovanou úroveň výkonu a odolnosti. To vám umožní používat PTU pro základní poptávku napříč úlohami a využívat průběžné platby za špičky v provozu.

Podpůrná infrastruktura

Infrastruktura, která podporuje architekturu Azure OpenAI, je potřeba zvážit v návrzích. Komponenty infrastruktury, které jsou součástí architektury, se liší v závislosti na tom, jestli aplikace využívají službu Azure OpenAI přes internet nebo přes privátní síť. Architektura probíraná v tomto článku předpokládá, že organizace implementovala službu Generative AI Gateway. Organizace s vyspělou stopou Azure a hybridním připojením by měly tuto službu využívat prostřednictvím privátní sítě, zatímco organizace bez hybridního připojení nebo s aplikacemi v jiném cloudu, jako je GCP nebo AWS, budou tuto službu využívat prostřednictvím veřejné páteřní sítě Microsoftu.

Navrhování pro spotřebu prostřednictvím veřejné páteřní sítě Microsoftu

Organizace, které službu využívají prostřednictvím veřejné páteřní sítě Microsoftu, by měly zvážit následující prvky návrhu:

1. Služba Generative AI Gateway by se měla nasadit způsobem, který zajistí dostupnost v případě výpadku v oblasti Azure. Pokud používáte APIM (Azure API Management), můžete to provést nasazením samostatných instancí APIM ve více oblastech nebo pomocí funkce brány pro více oblastí služby APIM.

2. Veřejný globální nástroj pro vyrovnávání zatížení serveru by se měl použít k vyrovnávání zatížení mezi několika instancemi brány Generative AI buď aktivním, aktivním, nebo aktivním nebo pasivním způsobem. Azure FrontDoor se dá použít ke splnění této role v závislosti na požadavcích organizace.

Navrhování pro spotřebu prostřednictvím privátních sítí

Organizace, které službu využívají prostřednictvím privátní sítě, by měly zvážit následující prvky návrhu:

1. Hybridní připojení by se mělo nasadit způsobem, který chrání před selháním oblasti Azure. Součásti podtržení podporující hybridní připojení se skládají z místní síťové infrastruktury organizace a microsoft ExpressRoute nebo VPN.
2. Služba Generative AI Gateway by se měla nasadit způsobem, který zajistí dostupnost v případě výpadku v oblasti Azure. Pokud používáte APIM (Azure API Management), můžete to provést nasazením samostatných instancí APIM ve více oblastech nebo pomocí funkce brány pro více oblastí služby APIM.
3. Privátní koncové body Azure Private Link by se měly nasadit pro každou instanci služby Azure OpenAI v každé oblasti Azure. V případě azure Privátní DNS je možné použít přístup DNS rozděleného mozku v případě, že se veškerý přístup aplikace ke službě Azure OpenAI provádí prostřednictvím brány Generative AI, která poskytuje další ochranu před regionálním selháním. Pokud ne, Privátní DNS záznamy se budou muset ručně upravit v případě ztráty oblasti Azure.
4. Nástroj pro vyrovnávání zatížení privátního globálního serveru by se měl použít k vyrovnávání zatížení mezi několika instancemi brány Generative AI Gateway buď aktivním, aktivním, nebo aktivním nebo pasivním způsobem. Azure nemá nativní službu pro globální nástroj pro vyrovnávání zatížení serveru pro úlohy, které vyžadují privátní překlad DNS. Další informace o tomto tématu najdete v tomto neoficiálním průvodci: https://github.com/adstuart/azure-crossregion-private-lb. Organizace můžou místo globálního nástroje pro vyrovnávání zatížení serveru dosáhnout aktivního/pasivního vzoru přepnutím záznamu DNS pro službu Generative AI Gateway.