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 bude uživateli offline. Při výběru směrovací služby je důležité zvážit spolehlivost samotné služby.

V základní architektuře pro kritickou aplikaci se služba Azure Front Door zvolila kvůli svým vysoce dostupným smlouvám o úrovni služeb (SLA) a bohaté sadě funkcí:

• Směrování provozu do více oblastí v modelu aktivní-aktivní
• Transparentní převzetí služeb při selhání pomocí libovolného vysílání PROTOKOLU TCP
• Obsluha statického obsahu z hraničních uzlů pomocí integrovaných sítí pro doručování obsahu (CDN)
• Blokování neoprávněného přístupu pomocí integrované brány firewall webových aplikací

Služba 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. Další informace o možnostech služby Front Door najdete v tématu Zrychlení a zabezpečení webové aplikace pomocí služby Azure Front Door.

Možnosti služby Front Door jsou více než dost pro splnění většiny obchodních požadavků, ale u jakéhokoli distribuovaného systému očekávají selhání. Pokud obchodní požadavky vyžadují v případě výpadku vyšší kombinovanou smlouvu SLA nebo nulový časový limit, budete se muset spolehnout na alternativní cestu příchozího přenosu dat. Výkon vyšší smlouvy SLA ale přináší značné náklady, provozní režii a může 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 zpřístupch Parita funkcí se službou 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ě.

Dalším přístupem je použití technologie třetích stran pro globální směrování. Tento přístup bude vyžadovat nasazení s vícecloudovými aktivními nasazeními s razítky hostovanými ve dvou nebo více poskytovatelích cloudu. I když Je možné efektivně integrovat Azure s jinými cloudovými platformami, tento přístup se nedoporučuje kvůli provozní složitosti napříč různými cloudovými platformami.

Tento článek popisuje některé strategie globálního směrování pomocí Azure Traffic Manageru jako 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.

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í. Použití prioritního směrování bude ve výchozím nastavení směrovat provoz přes Azure Front Door. Traffic Manager může automaticky přepnout provoz na alternativní cestu, pokud není služba Azure Front Door dostupná.

   Důležité

   Toto řešení snižuje rizika spojená s výpadky služby Azure Front Door, ale je náchylná k výpadkům Azure Traffic Manageru jako globální bod selhání.

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

2. Máte dvě cesty příchozího přenosu dat:

   • Azure Front Door poskytuje primární cestu a procesy a směruje veškerý provoz vaší aplikace.

   • Jako zálohu pro Azure Front Door se používá jiný směrovač. Provoz prochází pouze 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. V těchto článcích poskytujeme nativní možnosti Azure, abychom do řešení nemuseli přidávat další provozní složitost. 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 do vašeho původu a jaké povinnosti služba 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é součásti.

  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áklady na příležitosti: Navrhování a implementace redundantních cest příchozího přenosu dat vyžaduje významnou technickou investici, která nakonec přináší náklady na příležitosti k vývoji a dalším vylepšením platformy.

Upozorňující

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, ale smlouva o úrovni služeb nezaručuje 100% dostupnost. 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 použitelné v 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 možnostem a funkcím služby Azure Front Door, které používáte a na které spoléháte. Když zvolíte alternativní službu, rozhodněte se o minimálních funkcích, které potřebujete, a v případě, že je vaše řešení v degradovaném režimu, vynecháte.

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 problémy 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í?

Upozorňující

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. To ale není dobrý postup 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.

Názvy domén a DNS

Vaše nepostradatelná aplikace by měla používat vlastní název domény. Budete řídit tok provozu do vaší aplikace a snížíte závislosti na jednom poskytovateli.

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

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

Ř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á vlastní spravované certifikáty TLS nezávisle, můžou se zde vyskytovat problémy. 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.

Před vypršením platnosti však budou k dispozici další operace související s obnovením a aktualizací certifikátů.

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. Vzhledem k tomu, že Azure Front Door reaguje pouze na platný provoz HTTP, pomáhá také snížit riziko ohrožení na základě protokolu. Pokud změníte architekturu tak, aby umožňovala alternativní cesty příchozího přenosu dat, musíte vyhodnotit, jestli jste omylem zvýšili ohrožení původu.

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áš původ používá značku služby Azure Front Door a hlavičku X-Azure-FDID k ověření, že provoz protékal přes Azure Front Door, zvažte, jak je možné překonfigurovat vaše původy a ověřit, že provoz protékal některou z vašich platných cest. Musíte otestovat, že jste nechtěně neotevírali svůj původ pro provoz prostřednictvím jiných cest, včetně 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?

Existuje několik řešení globálního vyrovnávání zatížení, která umožňují monitorovat stav služby Azure Front Door a aktivovat automatické převzetí služeb při selhání na zálohovací platformu, pokud dojde k výpadku. Azure Traffic Manager je ve většině případů vhodný. Pomocí Traffic Manageru nakonfigurujete monitorování koncových bodů pro monitorování podřízených služeb tak, že určíte, kterou adresu URL chcete zkontrolovat, jak často se má tato adresa URL kontrolovat a kdy zvážit, jestli podřízená služba není v pořádku na základě odpovědí sondy. Obecně platí, že čím kratší je interval mezi kontrolami, tím méně času trvá, než Traffic Manager směruje provoz přes alternativní cestu k dosažení původního serveru.

Pokud služba Front Door není k dispozici, ovlivňuje několik faktorů dobu, po kterou výpadek ovlivňuje váš provoz, včetně:

• Doba života (TTL) u záznamů DNS.
• Jak často Traffic Manager spouští kontroly stavu.
• Kolik neúspěšných testů traffic Manageru je nakonfigurované tak, aby se zobrazilo před přesměrováním 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.

Tip

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 pomalé, aby aplikace zůstala responzivní.

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

Nasazení nulového výpadku

Pokud plánujete, jak 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.

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.

Upozorňující

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

Přečtěte si: Kritická oblast návrhu: Nasazení nulového výpadku

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?
• Jsou obě cesty dostatečně zabezpečené, aby se zabránilo otevření nebo zveřejnění ohrožení zabezpečení, když jste v degradované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.

Upozorňující

Pokud nejste opatrní při návrhu a implementaci komplexního řešení s více příchozími přenosy dat, můžete ve skutečnosti zhoršovat dostupnost. 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í.

Další kroky

Projděte si globální scénáře příchozího přenosu dat HTTP a globálního doručování obsahu a zjistěte, jestli se vztahují na vaše řešení.