Sdílet prostřednictvím

Globální redundance směrování pro klíčové webové aplikace

Důležité

Návrh implementací redundance, které se zabývají výpadky globální platformy pro kritickou architekturu, může být složité a nákladné. Vzhledem k potenciálním problémům, které mohou vzniknout s tímto návrhem, pečlivě zvažte kompromisy.

Ve většině situací nebudete potřebovat architekturu popsanou v tomto článku.

Klíčové systémy se snaží co nejvíce minimalizovat kritické body selhání vytvořením redundance a možností samoopravení v řešení. Jakýkoli jednotný vstupní bod systému lze považovat za bod selhání. Pokud tato komponenta dojde k výpadku, celý systém přejde pro uživatele do režimu offline. Při výběru směrovací služby je důležité zvážit spolehlivost samotné služby.

V architektuře pro nepostradatelnou aplikaci se služba Azure Front Door vybírá z důvodu vysoké dostupnosti smlouvy o úrovni služeb (SLA) a bohaté sady funkcí:

  • Směrování provozu do několika oblastí v modelu aktivní-aktivní nebo aktivní-pasivní
  • Transparentní převzetí při selhání pomocí anycastu TCP
  • Obsluha statického obsahu z hraničních uzlů pomocí integrovaných sítí pro doručování obsahu (CDN)
  • Blokujte neoprávněný přístup pomocí integrovaného firewallu webových aplikací

Další informace o možnostech služby Azure Front Door najdete v tématu Zrychlení a zabezpečení webové aplikace pomocí služby Azure Front Door.

Služba Azure Front Door je navržená tak, aby poskytovala maximální odolnost a dostupnost nejen pro naše externí zákazníky, ale také pro více vlastností v rámci Microsoftu. Funkce služby Azure Front Door jsou více než dost, aby splňovaly většinu obchodních požadavků, ale u jakéhokoli distribuovaného systému očekávejte selhání. Žádná komponenta ani systém není neomylný. Microsoft nabízí špičkové smlouvy o úrovni služeb (SLA) pro Azure Front Door. I když jiný poskytovatel nabízí SLA s dostupností 100%, je důležité si uvědomit, že to není záruka nulového výpadku a že smlouvy SLA obvykle poskytují kredity na služby v případě výpadku.

Pokud obchodní požadavky vyžadují vyšší složené SLO nebo žádné přerušení v případě výpadku, musíte se spolehnout na několik alternativních příchozích cest pro přenos dat. Mnoho velkých organizací a webových stránek s vysokou prestiží tento přístup používá k zajištění nejvyšší možné dostupnosti a optimalizaci výkonnosti doručování. Snaha o vyšší SLO ale přináší významné náklady, provozní náklady a může neúmyslně snížit celkovou spolehlivost. Pečlivě zvažte kompromisy a potenciální problémy, které alternativní cesta může zavést v jiných komponentách, které jsou na kritické cestě. I když je dopad nedostupnosti významný, může složitost převažovat nad výhodou.

Jedním z přístupů je definovat sekundární cestu s alternativními službami, která se stane primární cestou, když Azure Front Door není dostupný. Parita funkcí se službou Azure Front Door by neměla být považována za pevný požadavek. Určete prioritu funkcí, které naprosto potřebujete pro účely provozní kontinuity, a to i v omezené kapacitě.

Existuje několik strategií pro dosažení vysoké dostupnosti ve webových úlohách. Zde popsaný přístup nabízí jednoduché ruční řešení pro nouzové situace, které vám umožní rychle převést provoz na záložní systém v případě výpadku a bezproblémově obnovit provoz ke službě Azure Front Door po ověření zdraví služby.

Tento článek popisuje některé strategie globálního směrování pomocí Azure Traffic Manageru pro směrování provozu do alternativního směrovače v situacích, kdy není služba Azure Front Door dostupná.

Přístup

Tento diagram architektury znázorňuje obecný přístup s několika redundantními cestami provozu.

Diagram znázorňující Traffic Manager, který směruje požadavky na Azure Front Door nebo jinou službu, a potom na původní server

S tímto přístupem představíme několik komponent a poskytneme pokyny, které budou provádět významné změny spojené s doručováním webových aplikací:

  1. Azure Traffic Manager směruje provoz do služby Azure Front Door nebo do alternativní služby, kterou jste vybrali.

    Azure Traffic Manager je globální nástroj pro vyrovnávání zatížení založený na DNS. Záznam CNAME vaší domény odkazuje na Traffic Manager, který určuje cíl podle toho, jak nakonfigurujete jeho metodu směrování. Pro kritickou architekturu doporučujeme použít metodu váženého směrování, která se dá snadno nakonfigurovat tak, aby odesílala některé nebo všechny přenosy do různých koncových bodů. V normálních operacích se obvykle přes Azure Front Door směruje 100% provozu.

    Doporučujeme zakázat monitorování koncových bodů Traffic Manageru. Měli byste mít postupy, které vám umožní zjistit, kdy primární cesta provozu není dostupná, a reagovat přepnutím provozu na použití sekundární cesty.

    Můžete také zvážit použití jiného globálního systému směrování provozu. Traffic Manager ale funguje dobře v mnoha situacích.

  2. Máte dva vstupní body:

    • Azure Front Door poskytuje primární cestu. V normálních operacích zpracovává a směruje veškerý nebo většinu provozu aplikace.

    • Azure Front Door používá jiný směrovač jako zálohu. Provoz prochází touto sekundární cestou, pokud není služba Front Door k dispozici.

    Konkrétní služba, kterou vyberete pro sekundární směrovač, závisí na mnoha faktorech. Můžete se rozhodnout používat nativní služby Azure nebo služby třetích stran. Ve těchto článcích poskytujeme možnosti nativní pro Azure, pokud je to možné, aby se předešlo dalším provozním složitostem řešení. Pokud používáte služby třetích stran, musíte ke správě řešení použít více řídicích rovin.

  3. Aplikační servery původu musí být připravené k přijetí provozu z obou služeb. Zvažte, jak zabezpečit provoz k vašemu zdroji a jaké povinnosti Azure Front Door a další upstreamové služby poskytují. Ujistěte se, že vaše aplikace dokáže zpracovávat provoz z jakékoli cesty, kterou provoz prochází.

Kompromisy

I když tato strategie zmírnění rizik může aplikaci zpřístupnit během výpadků platformy, existuje několik důležitých kompromisů. Měli byste zvážit potenciální výhody oproti známým nákladům a informovaně se rozhodnout, jestli tyto výhody stojí za tyto náklady.

  • Finanční náklady: Když do aplikace nasadíte více redundantních cest, musíte zvážit náklady na nasazení a spuštění prostředků. Nabízíme dva ukázkové scénáře pro různé případy použití, z nichž každý má jiný profil nákladů.

  • Provozní složitost: Pokaždé, když do řešení přidáte další komponenty, zvýšíte režii správy. Jakákoli změna jedné komponenty může mít vliv na jiné komponenty.

    Předpokládejme, že se rozhodnete používat nové funkce služby Azure Front Door. Musíte zkontrolovat, jestli alternativní cesta provozu také poskytuje ekvivalentní funkci, a pokud ne, musíte se rozhodnout, jak řešit rozdíl v chování mezi těmito dvěma cestami provozu. V reálných aplikacích můžou mít tyto složitosti vysoké náklady a můžou představovat velké riziko stability systému.

  • Výkon: Tento návrh vyžaduje další vyhledávání CNAME během překladu názvů. Ve většině aplikací to není zásadní problém, ale měli byste vyhodnotit, jestli je výkon vaší aplikace ovlivněn zavedením dalších vrstev do cesty příchozího přenosu dat.

  • Náklad ušlé příležitosti: Navrhování a implementace redundantních cest příchozího přenosu dat vyžaduje významnou technickou investici, což nakonec vede k ušlým příležitostem pro rozvoj funkcí a další vylepšení platformy.

Výstraha

Pokud nejste opatrní při návrhu a implementaci komplexního řešení s vysokou dostupností, můžete dostupnost skutečně zhoršovat. Zvýšení počtu komponent v architektuře zvyšuje počet bodů selhání. Také to znamená, že máte vyšší úroveň provozní složitosti. Když přidáte další komponenty, je potřeba pečlivě zkontrolovat každou změnu, abyste pochopili, jak ovlivňuje vaše celkové řešení.

Dostupnost Azure Traffic Manageru

Azure Traffic Manager je spolehlivá služba s špičkovou smlouvou SLA, ale správa provozu potřebuje další opatření k zajištění 100% dostupnosti. Pokud Traffic Manager není dostupný, vaši uživatelé nemusí mít přístup k vaší aplikaci, i když jsou k dispozici Azure Front Door a vaše alternativní služba. Za těchto okolností je důležité naplánovat, jak bude vaše řešení fungovat.

Traffic Manager vrací odpovědi DNS ke ukládání do mezipaměti. Pokud doba trvání (TTL) na záznamech DNS umožňuje ukládání do mezipaměti, nemusí být problém s krátkými výpadky Traffic Manageru. Důvodem je, že podřízené překladače DNS mohly mít uloženou předchozí odpověď uloženou v mezipaměti. Měli byste naplánovat dlouhodobé výpadky. Pokud traffic Manager není dostupný, můžete se rozhodnout ručně překonfigurovat servery DNS tak, aby uživatele směrovat na službu Azure Front Door.

Konzistence směrování provozu

Je důležité porozumět schopnostem a funkcím služby Azure Front Door, které využíváte a na které spoléháte, pokud budete používat i jinou službu. Když zvolíte alternativní službu, rozhodněte se o minimálních funkcích, které potřebujete, a ostatní funkce vynechejte, když je vaše řešení v degradovaném režimu.

Při plánování alternativní dopravní cesty byste měli zvážit některé klíčové otázky:

  • Používáte funkce ukládání do mezipaměti služby Azure Front Door? Pokud je ukládání do mezipaměti nedostupné, můžou vaše původní servery držet krok s provozem?
  • Používáte modul pravidel služby Azure Front Door k provádění vlastní logiky směrování nebo k přepsání požadavků?
  • Používáte k zabezpečení aplikací firewall webových aplikací (WAF) služby Azure Front Door?
  • Omezujete provoz na základě IP adresy nebo zeměpisné oblasti?
  • Kdo vydává a spravuje vaše certifikáty TLS?
  • Jak omezíte přístup k aplikačním serverům původu, abyste měli jistotu, že projde službou Azure Front Door? Používáte službu Private Link nebo spoléháte na veřejné IP adresy se značkami služeb a hlavičkami identifikátorů?
  • Přijímají aplikační servery provoz z jiného místa než Azure Front Door? Pokud ano, jaké protokoly přijmou?
  • Používají vaši klienti podporu HTTP/2 služby Azure Front Door?

Firewall webových aplikací (WAF)

Pokud k ochraně aplikace používáte WAF služby Azure Front Door, zvažte, co se stane, když provoz neprochází přes Azure Front Door.

Pokud alternativní cesta také poskytuje WAF, zvažte následující otázky:

  • Je možné ji nakonfigurovat stejným způsobem jako waf služby Azure Front Door?
  • Je potřeba ho ladit a testovat nezávisle, aby se snížila pravděpodobnost falešně pozitivních detekcí?

Výstraha

Pro alternativní cestu příchozího přenosu dat možná nebudete používat WAF. Tento přístup je možné považovat za podporu cíle spolehlivosti aplikace. Nejedná se ale o dobrý postup zabezpečení a nedoporučujeme ho.

Zvažte kompromis při přijímání provozu z internetu bez jakýchkoli kontrol. Pokud útočník zjistí nechráněnou sekundární cestu provozu do vaší aplikace, může přes sekundární cestu posílat škodlivý provoz i v případě, že primární cesta obsahuje WAF.

Nejlepší je zabezpečit všechny cesty k aplikačním serverům.

Další aspekty vysoké dostupnosti

Při navrhování klíčové webové architektury existuje mnoho faktorů, které můžou ovlivnit dostupnost a výkon vaší aplikace. Mnoho z těchto faktorů přesahuje konfiguraci a možnosti služby Azure Front Door a místo toho souvisí s celkovým návrhem ekosystému a řešení.

Názvy domén a DNS

Vaše důležitá aplikace by měla používat vlastní názvy domén k řízení toků provozu do vaší aplikace a omezení závislostí na jednom poskytovateli. Při plánování přístupu DNS zvažte následující body:

  • Služba DNS: Pro název domény, jako je Azure DNS, je vhodné použít vysoce kvalitní a odolnou službu DNS. Pokud jsou servery DNS vašeho názvu domény nedostupné, uživatelé se nemůžou spojit s vaší službou.

  • Překladače DNS: K dalšímu zvýšení celkové odolnosti doporučujeme použít více překladačů DNS.

  • Domény vrcholu: Pomocí CNAME nasměrujete název domény na název domény Traffic Manageru. Standardy DNS neumožňují vytvořit CNAME na vrcholu (nebo kořenovém adresáři) domény. Doporučujeme hostovat svoji doménu DNS v Azure DNS a pomocí záznamů aliasů odkazovat na váš profil Traffic Manageru.

  • Řetězení CNAME: Řešení, která kombinují Traffic Manager, Azure Front Door a další služby, používají proces překladu DNS CNAME s více vrstvami, označovaný také jako řetězení CNAME. Když například přeložíte vlastní doménu, může se vám před vrácením IP adresy zobrazit pět nebo více záznamů CNAME.

    Přidání dalších odkazů na řetěz CNAME může ovlivnit výkon překladu názvů DNS. Odpovědi DNS se ale obvykle ukládají do mezipaměti, což snižuje dopad na výkon.

Certifikáty TLS

Pro kritickou aplikaci se doporučuje zřídit a používat vlastní certifikáty TLS místo spravovaných certifikátů poskytovaných službou Azure Front Door. Snížíte počet potenciálních problémů s touto složitou architekturou.

Tady jsou některé výhody:

  • Pokud chcete vydávat a obnovovat spravované certifikáty TLS, Azure Front Door ověří vlastnictví domény. Proces ověření domény předpokládá, že záznamy CNAME vaší domény odkazují přímo na Azure Front Door. Ale tento předpoklad často není správný. Vydávání a obnovování spravovaných certifikátů TLS ve službě Azure Front Door nemusí fungovat hladce a zvyšujete riziko výpadků kvůli problémům s certifikátem TLS.

  • I když vaše ostatní služby poskytují spravované certifikáty TLS, nemusí být schopny ověřit vlastnictví domény.

  • Pokud každá služba získá své vlastní spravované certifikáty TLS nezávisle, může dojít k problémům. Uživatelé například nemusí očekávat, že uvidí různé certifikáty TLS vydané různými autoritami nebo s různými daty vypršení platnosti nebo kryptografickými otisky.

Existují ale další operace související s obnovením a aktualizací certifikátů před vypršením jejich platnosti.

Zabezpečení původu

Když nakonfigurujete původ tak, aby přijímal pouze provoz prostřednictvím služby Azure Front Door, získáte ochranu proti útokům DDoS vrstvy 3 a 4. Azure Front Door reaguje pouze na platný provoz HTTP, což také pomáhá snížit vaši expozici mnoha hrozbám založeným na protokolu. Pokud změníte architekturu tak, aby umožňovala alternativní příchozí přístupy, musíte vyhodnotit, jestli jste omylem zvýšili vystavení vašeho serveru hrozbám.

Pokud se ke službě Azure Front Door připojíte ke svému zdrojovému serveru pomocí služby Private Link, jak tok provozu prochází vaší alternativní cestou? Můžete použít privátní IP adresy pro přístup ke svému původu, nebo musíte použít veřejné IP adresy?

Pokud váš zdroj používá značku služby Azure Front Door a hlavičku X-Azure-FDID k ověření, že provoz protokoloval přes Azure Front Door, zvažte, jak je možné překonfigurovat vaše zdroje, aby se ověřilo, že provoz protokoloval přes kteroukoliv z vašich platných cest. Musíte otestovat, že jste omylem neotevřeli svůj původní server pro provoz prostřednictvím jiných cest vstupu, včetně vstupů z profilů Azure Front Door jiných zákazníků.

Při plánování zabezpečení původu zkontrolujte, jestli alternativní cesta provozu závisí na zřizování vyhrazených veřejných IP adres. To může vyžadovat ručně aktivovaný proces, aby se cesta zálohování přenesla do režimu online.

Pokud existují vyhrazené veřejné IP adresy, zvažte, jestli byste měli implementovat službu Azure DDoS Protection , abyste snížili riziko útoků na dostupnost služby vůči vašemu původu. Zvažte také, jestli potřebujete implementovat službu Azure Firewall nebo jinou bránu firewall, která vás dokáže chránit před různými síťovými hrozbami. Možná budete potřebovat i další strategie detekce neoprávněných vniknutí. Tyto ovládací prvky můžou být důležité prvky v složitější architektuře s více cestami.

Modelování stavu

Kritická metodologie návrhu vyžaduje model stavu systému, který vám poskytuje celkovou pozorovatelnost řešení a jejích součástí. Pokud používáte více cest příchozího přenosu dat, musíte monitorovat stav každé cesty. Pokud se provoz směruje na sekundární cestu příchozího přenosu dat, měl by model stavu odrážet skutečnost, že systém je stále funkční, ale že běží v degradovaném stavu.

Do návrhu modelu stavu můžete zahrnout tyto otázky:

  • Jak různé komponenty vašeho řešení monitorují stav podřízených komponent?
  • Kdy by monitorování stavu mělo zvážit, že podřízené komponenty nejsou v pořádku?
  • Jak dlouho trvá zjištění výpadku?
  • Jak dlouho po zjištění výpadku trvá směrování provozu přes alternativní cestu?

Monitorování stavu

Existuje několik řešení globálního vyrovnávání zatížení, která umožňují přepnout na sekundární platformu, pokud dojde k výpadku. Azure Traffic Manager je ve většině případů vhodný.

Pokud používáte Traffic Manager se službou Azure Front Door, měli byste mít vlastní monitorovací řešení třetích stran nebo vlastní řešení monitorování, abyste zjistili, kdy služba Azure Front Door není k dispozici, a zahájit procesy odezvy. Vzhledem k tomu, že Azure Front Door je globálně distribuovaný systém, který používá sítě libovolného vysílání, je důležité provádět kontroly připojení ze stejných geografických oblastí jako klienti.

Důležité

U globálních úloh vyžadujících ověření stavu z více zeměpisných umístění doporučujeme zakázat monitorování koncových bodů Traffic Manageru a místo toho použít ruční postupy převzetí služeb při selhání.

Také byste měli být připraveni aktivovat postupy reakce ručně, pokud je vaše systémy monitorování nezjistí.

Postupy odezvy

Pokud vaše systémy monitorování zjistí, že služba Azure Front Door není dostupná, je potřeba překonfigurovat Traffic Manager tak, aby směrovat veškerý provoz přes alternativní cestu pomocí některého z těchto přístupů:

Důležité

Přesměrování veškerého provozu přes sekundární cestu je krátkodobé řešení, které umožňuje provozní kontinuitu během probíhajícího výpadku. Po vyřešení výpadku proveďte obnovení normálních operací prostřednictvím služby Azure Front Door, jakmile to bude možné.

Více faktorů ovlivňuje dobu, po kterou výpadek ovlivňuje váš provoz, včetně těchto:

  • Doba života (TTL) u záznamů DNS.
  • Který monitorovací systém (Traffic Manager nebo vlastní monitorování) nejprve zjistí výpadek.
  • Jak často spouštíte kontroly stavu.
  • Kolik neúspěšných kontrol stavu musí být hlášeno, než dojde k přesměrování provozu.
  • Jak dlouho klienti a nadřazené servery DNS ukládají odpovědi DNS Traffic Manageru do mezipaměti.

Musíte také určit, které z těchto faktorů jsou v rámci vaší kontroly a jestli nadřazené služby nad rámec vašeho řízení můžou ovlivnit uživatelské prostředí. I když například u záznamů DNS použijete nízkou hodnotu TTL, můžou upstreamové mezipaměti DNS dál obsluhovat zastaralé odpovědi déle, než by měly. Toto chování může zhoršit účinky výpadku nebo se zdát, že vaše aplikace není dostupná, i když Traffic Manager už přepnul na odesílání požadavků na alternativní cestu provozu.

Návod

Kritická řešení vyžadují přístupy automatizovaného převzetí služeb při selhání, kdykoli je to možné. Procesy ručního převzetí služeb při selhání se považují za příliš pomalé, aby aplikace zůstala responzivní.

Projděte si: Oblast návrhu kritická pro zdravotnictví: Modelování stavu

Robustní procesy rekonfigurace

Pokud plánujete provozovat řešení s redundantní cestou příchozího přenosu dat, měli byste také naplánovat, jak nasadit nebo nakonfigurovat služby, když dojde ke snížení jejich výkonu. U většiny služeb Azure se smlouvy SLA vztahují na dobu provozu samotné služby, a ne na operace správy nebo nasazení. Zvažte, jestli vaše procesy nasazení a konfigurace musí být odolné vůči výpadkům služeb.

Když plánujete strategii převzetí služeb při selhání, nespoléhejte se na jeden nástroj, jako je portál Azure, v případě narušení připojení. Seznamte se s tím, jak používat nástroje, jako jsou Azure CLI, Azure PowerShell nebo rozhraní REST API, k provedení jakýchkoli kroků rekonfigurace, jako je přesměrování provozu. Ukázkové příkazy, které můžete zahrnout do skriptů pro převzetí služeb při selhání, najdete v Postupech reakce.

Měli byste také zvážit počet nezávislých řídicích rovin, se kterými potřebujete pracovat při správě řešení. Když používáte služby Azure, Azure Resource Manager poskytuje jednotnou a konzistentní řídicí rovinu. Pokud ale ke směrování provozu používáte službu třetí strany, možná budete muset ke konfiguraci služby použít samostatnou řídicí rovinu, která přináší další provozní složitost.

Výstraha

Použití více řídicích rovin představuje pro vaše řešení složitost a riziko. Každý bod rozdílu zvyšuje pravděpodobnost, že někdo omylem vynechá nastavení konfigurace nebo použije různé konfigurace pro redundantní komponenty. Ujistěte se, že provozní postupy toto riziko zmírňují.

Odkaz na: Kritická oblast návrhu: Nasazení bez výpadků

Průběžné ověřování

V případě klíčového řešení musí vaše testovací postupy ověřit, že vaše řešení splňuje vaše požadavky bez ohledu na cestu, kterou prochází provoz aplikace. Zvažte jednotlivé části řešení a způsob, jakým ho otestujete pro každý typ výpadku.

Ujistěte se, že vaše procesy testování obsahují tyto prvky:

  • Můžete ověřit, jestli je provoz správně přesměrovaný přes alternativní cestu, pokud primární cesta není k dispozici?
  • Můžou obě cesty podporovat úroveň produkčního provozu, který očekáváte? Je sekundární cesta připravená k příjmu produkčního provozu s minimálním nebo žádným upozorněním?
  • Jsou obě cesty dostatečně zabezpečené, aby se zabránilo otevření nebo odkrytí bezpečnostních zranitelností, když jste v degradačním stavu?

Přečtěte si: Oblast návrhu kritická pro klíčové úkoly: Průběžné ověřování

Obvyklé scénáře

Tady jsou běžné scénáře, ve kterých se dá tento návrh použít:

  • Globální doručování obsahu se běžně vztahuje na statické doručování obsahu, média a vysoce škálovatelné aplikace elektronického obchodování. V tomto scénáři je ukládání do mezipaměti důležitou součástí architektury řešení a selhání mezipaměti může vést k výrazně sníženému výkonu nebo spolehlivosti.

  • Globální příchozí přenos dat HTTP se běžně vztahuje na klíčové dynamické aplikace a rozhraní API. V tomto scénáři je základním požadavkem směrování provozu na původní server spolehlivě a efektivně. WaF je často důležitou bezpečnostní kontrolou používanou v těchto řešeních.

Výstraha

Pokud nejste opatrní při návrhu a implementaci složitého řešení vícero vstupů, může dokonce dojít ke zhoršení dostupnosti. Zvýšení počtu komponent v architektuře zvyšuje počet bodů selhání. Také to znamená, že máte vyšší úroveň provozní složitosti. Když přidáte další komponenty, je potřeba pečlivě zkontrolovat každou změnu, abyste pochopili, jak ovlivňuje vaše celkové řešení.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

Konkrétní pokyny k těmto scénářům najdete v dalších článcích v této sérii:

Globální kritický vstup HTTP

Klíčové globální doručování obsahu

  • Last updated on