Sdílet prostřednictvím

Spolehlivost v Azure Spring Apps

  • Článek

Tento článek obsahuje podrobné informace o regionální odolnosti se zónami dostupnosti a zotavením po havárii mezi oblastmi a podporou provozní kontinuity pro Azure Spring Apps.

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í.

Azure Spring Apps podporuje zónovou redundanci. Když vytvoříte instanci služby Azure Spring Apps s povolenou zónovou redundancí, Azure Spring Apps automaticky distribuuje základní prostředky napříč logickými oddíly základní infrastruktury Azure. Základní výpočetní prostředek distribuuje virtuální počítače napříč všemi zónami dostupnosti, aby se zajistila možnost výpočtu. Základní prostředek úložiště replikuje data napříč zónami dostupnosti, aby byla dostupná i v případě selhání datacentra. Tato distribuce poskytuje vyšší úroveň dostupnosti a chrání před selháním hardwaru nebo událostmi plánované údržby.

Požadavky

  • Redundance zón není v plánu Basic dostupná.

  • Azure Spring Apps podporuje zóny dostupnosti v následujících oblastech:

    • Austrálie – východ
    • Brazílie – jih
    • Střední Kanada
    • USA – střed
    • Východní Asie
    • East US
    • USA – východ 2
    • Francie – střed
    • Německo – středozápad
    • Severní Evropa
    • Japonsko – východ
    • Jižní Korea – střed
    • Jižní Afrika – sever
    • Středojižní USA
    • Southeast Asia
    • Velká Británie – jih
    • Západní Evropa
    • Západní USA 2
    • USA – západ 3

Vytvoření instance Azure Spring Apps s povolenými zónami dostupnosti

Poznámka:

Redundanci zón můžete povolit jenom při vytváření instance služby Azure Spring Apps. Po vytvoření nelze změnit vlastnost redundance zóny.

V Azure Spring Apps můžete povolit zónovou redundanci pomocí Azure CLI nebo webu Azure Portal.

Pokud chcete vytvořit službu v Azure Spring Apps s povolenou zónovou redundancí pomocí Azure CLI, při vytváření služby zahrňte --zone-redundant parametr, jak je znázorněno v následujícím příkladu:

az spring create \
    --resource-group <your-resource-group-name> \
    --name <your-Azure-Spring-Apps-instance-name> \
    --location <location> \
    --zone-redundant true

Povolení vlastního prostředku s povolenými zónami dostupnosti

Ve službě Azure Spring Apps můžete povolit vlastní prostředek, například vlastní trvalé úložiště. Musíte ale povolit zónovou redundanci pro váš prostředek. Další informace najdete v tématu Povolení vlastního trvalého úložiště v Azure Spring Apps.

Prostředí pro zónu dolů

Když instance aplikace selže, protože je umístěná v uzlu virtuálního počítače v zóně selhání, Azure Spring Apps vytvoří novou instanci aplikace pro neúspěšnou aplikaci na jiném uzlu virtuálního počítače v jiné zóně dostupnosti. Uživatelé můžou během této doby zaznamenat krátké přerušení. Služba nevyžaduje žádnou akci uživatele a ovlivněná instance Azure Spring Apps se obnoví.

Ceny

S povolením zónové redundance nejsou spojené žádné další náklady. Platíte jenom za plán Standard nebo Enterprise, který je nutný k povolení redundance zón.

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

Zotavení po havárii (DR) se týká zotavení z událostí s vysokým dopadem, jako jsou přírodní katastrofy nebo neúspěšná nasazení, která vedou k výpadkům a ztrátě dat. Bez ohledu na příčinu je nejlepším řešením havárie dobře definovaný a otestovaný plán zotavení po havárii a návrh aplikace, který aktivně podporuje zotavení po havárii. Než začnete přemýšlet o vytvoření plánu zotavení po havárii, přečtěte si doporučení pro návrh strategie zotavení po havárii.

Pokud jde o zotavení po havárii, Microsoft používá model sdílené odpovědnosti. V modelu sdílené odpovědnosti Microsoft zajišťuje, aby byly dostupné základní služby infrastruktury a platformy. Současně mnoho služeb Azure automaticky nereplikuje data nebo se vrátí z oblasti, která selhala, aby se křížově replikovala do jiné povolené oblasti. Za tyto služby zodpovídáte za nastavení plánu zotavení po havárii, který funguje pro vaši úlohu. Většina služeb, které běží na nabídkách PaaS (Platforma jako služba) Azure, poskytuje funkce a pokyny pro podporu zotavení po havárii a pomocí funkcí specifických pro služby můžete podporovat rychlé obnovení , které vám pomůže s vývojem plánu zotavení po havárii.

Služba Azure Spring Apps neposkytuje geografické zotavení po havárii, ale pečlivé plánování vám může pomoct chránit před výpadky.

Pokud chcete zajistit vysokou dostupnost a ochranu před haváriemi, nasaďte aplikace hostované v Azure Spring Apps do několika oblastí. Azure poskytuje seznam spárovaných oblastí , abyste mohli odpovídajícím způsobem naplánovat nasazení aplikací.

Při návrhu architektury zvažte následující klíčové faktory:

  • Dostupnost v oblastech: Pokud chcete minimalizovat prodlevu sítě a dobu přenosu, zvolte oblast, která podporuje zónovou redundanci Azure Spring Apps nebo geografickou oblast blízko uživatelům.
  • Spárované oblasti Azure Pokud chcete zajistit koordinované aktualizace platformy a v případě potřeby určit prioritu úsilí o obnovení, zvolte spárované oblasti v rámci zvolené geografické oblasti.
  • Dostupnost služby. Rozhodněte se, jestli vaše spárované oblasti mají běžet za tepla, horká, teplá nebo studená nebo studená.

Použití Azure Traffic Manageru ke směrování provozu

Azure Traffic Manager poskytuje vyrovnávání zatížení provozu založeného na DNS a může distribuovat síťový provoz napříč několika oblastmi. Pomocí Azure Traffic Manageru nasměrujte zákazníky na nejbližší instanci služby Azure Spring Apps. Pokud chcete dosáhnout co nejlepšího výkonu a redundance, nasměrujte veškerý provoz aplikací přes Azure Traffic Manager před odesláním do instance služby Azure Spring Apps. Další informace najdete v tématu Co je Traffic Manager?

Pokud máte aplikace v Azure Spring Apps spuštěné ve více oblastech, může Azure Traffic Manager řídit tok provozu do vašich aplikací v každé oblasti. Definujte koncový bod Azure Traffic Manageru pro každou instanci služby pomocí IP adresy instance. Měli byste se připojit k názvu DNS Azure Traffic Manageru odkazujícího na instanci služby Azure Spring Apps. Azure Traffic Manager vyrovnává zatížení provozu napříč definovanými koncovými body. Pokud dojde k havárii datového centra, Azure Traffic Manager směruje provoz z této oblasti na jeho pár a zajišťuje kontinuitu služeb.

Pomocí následujících kroků vytvořte instanci Azure Traffic Manageru pro instance Azure Spring Apps:

  1. Vytvořte instance Azure Spring Apps ve dvou různých oblastech. Například vytvořte instance služeb v oblasti USA – východ a Západní Evropa, jak je znázorněno v následující tabulce. Každá instance slouží jako primární koncový bod pro přenos a převzetí služeb při selhání.

    Service name Umístění Aplikace
    service-sample-a USA – východ brána / auth-service / account-service
    service-sample-b Západní Evropa brána / auth-service / account-service

  2. Nastavte vlastní doménu pro instance služby. Další informace najdete v tématu Kurz: Mapování existující vlastní domény na Azure Spring Apps. Po úspěšném nastavení budou obě instance služby svázané se stejnou vlastní doménou, například bcdr-test.contoso.com.

  3. Vytvořte Traffic Manager a dva koncové body. Pokyny najdete v tématu Rychlý start: Vytvoření profilu Traffic Manageru pomocí webu Azure Portal, který vytvoří následující profil Traffic Manageru:

    • Název DNS Traffic Manageru: http://asa-bcdr.trafficmanager.net
    • Profily koncových bodů:
    Profil Typ Cíl Priorita Vlastní nastavení záhlaví
    Koncový bod profilu A Externí koncový bod service-sample-a.azuremicroservices.io 0 host: bcdr-test.contoso.com
    Profil koncového bodu B Externí koncový bod service-sample-b.azuremicroservices.io 2 host: bcdr-test.contoso.com

  4. Vytvořte záznam CNAME v zóně DNS podobně jako v následujícím příkladu: bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net.

Prostředí je teď nastavené. Pokud jste použili ukázkové hodnoty v odkazovaných článcích, měli byste mít přístup k aplikaci pomocí https://bcdr-test.contoso.com.

Použití služby Azure Front Door a Aplikace Azure Gateway ke směrování provozu

Azure Front Door je globální škálovatelný vstupní bod, který používá globální hraniční síť Microsoftu k vytváření rychlých, zabezpečených a široce škálovatelných webových aplikací. Azure Front Door poskytuje stejnou geografickou redundanci a směrování do nejbližší oblasti jako Azure Traffic Manager. Azure Front Door také poskytuje pokročilé funkce, jako je ukončení protokolu TLS, zpracování aplikační vrstvy a firewall webových aplikací (WAF). Další informace najdete v tématu Co je Azure Front Door?

Následující diagram znázorňuje architekturu redundance více oblastí integrované instance služby Azure Spring Apps s více oblastmi. Diagram znázorňuje správnou konfiguraci reverzního proxy serveru pro službu Application Gateway a front Door s vlastní doménou. Tato architektura je založená na scénáři popsaném v tématu Zveřejnění aplikací s kompletním protokolem TLS ve virtuální síti. Tento přístup kombinuje dvě instance injektáže virtuální sítě Azure Spring Apps integrované službou Application Gateway do geograficky redundantní instance.

Diagram showing the architecture of a multi-region Azure Spring Apps service instance.

Další kroky