Vícevrstvé webové aplikace vytvořené pro zajištění vysoké dostupnosti a zotavení po havárii

Azure
Azure Arc
SQL Server
Windows

Tento ukázkový scénář se vztahuje na libovolné odvětví, které potřebuje nasadit spolehlivé vícevrstvé aplikace vytvořené pro zajištění vysoké dostupnosti a zotavení po havárii (DR). V tomto scénáři se aplikace skládá ze tří vrstev.

  • Webová vrstva je horní vrstva, která zahrnuje uživatelské rozhraní. Tato vrstva analyzuje interakce uživatelů a předává akce do další vrstvy pro zpracování.

  • Obchodní vrstva zpracovává interakce uživatelů a provádí logická rozhodnutí o dalších krocích. Tato vrstva propojuje webovou vrstvu a datovou vrstvu.

  • Datová vrstva ukládá data aplikace pomocí databáze, úložiště objektů nebo úložiště souborů.

Mezi běžné scénáře aplikací patří libovolná důležitá aplikace, která běží ve Windows nebo Linuxu, například předem připravená aplikace, jako je SAP nebo vlastní obchodní aplikace.

Architektura

Diagram znázorňující přehled architektury vysoce odolné vícevrstvé webové aplikace

Stáhněte si soubor aplikace Visio s touto architekturou.

Workflow

Následující pracovní postup odpovídá předchozímu diagramu:

  1. Uživatelé přistupují k webové vrstvě front-endu ASP.NET prostřednictvím koncového bodu Azure Traffic Manageru. Traffic Manager přesměruje provoz na primární veřejnou IP adresu v primární zdrojové oblasti. Veřejná IP adresa přesměruje volání na jednu z instancí virtuálního počítače webové vrstvy prostřednictvím veřejného nástroje pro vyrovnávání zatížení.

  2. Všechny instance virtuálních počítačů webové vrstvy se nacházejí v jedné podsíti. Interní nástroj pro vyrovnávání zatížení směruje každé volání z webové vrstvy do instance virtuálního počítače obchodní vrstvy pro zpracování.

    Všechny virtuální počítače na úrovni business se nacházejí v samostatné podsíti. Obchodní vrstva zpracuje operaci a aplikace ASP.NET se připojí ke clusteru SQL Serveru v back-endové vrstvě prostřednictvím interního nástroje pro vyrovnávání zatížení. Tyto back-endové instance SQL Serveru se nacházejí v samostatné podsíti.

  3. Distribuujte virtuální počítače v každé vrstvě do dvou zón dostupnosti v regionech, které zóny podporují.

  4. V jiných oblastech nasaďte virtuální počítače v každé vrstvě v rámci jedné skupiny dostupnosti.

  5. Můžete nastavit databázovou vrstvu tak, aby používala skupiny dostupnosti AlwaysOn. Tato konfigurace SQL Serveru používá jednu primární repliku pro čtení a zápis v rámci skupiny dostupnosti a až osm sekundárních replik jen pro čtení. Pokud primární replika selže, skupina dostupnosti povýší sekundární repliku na primární. Sekundární replika provádí aktivitu čtení a zápisu a udržuje aplikaci k dispozici. Další informace najdete v tématu Přehled skupin dostupnosti AlwaysOn pro SQL Server.

  6. Ve scénářích zotavení po havárii můžete nastavit asynchronní nativní replikaci SQL AlwaysOn do cílové oblasti, kterou používáte pro zotavení po havárii. Replikaci Azure Site Recovery do cílové oblasti můžete nastavit také v případě, že rychlost změn dat spadá do podporovaných limitů Site Recovery.

    Sekundární koncový bod Traffic Manageru je nastaven na veřejnou IP adresu v cílovém regionu, který používáte pro DR. Když dojde k přerušení v primární oblasti, vyvoláte převzetí služeb při selhání Site Recovery a aplikace se aktivuje v cílové oblasti. Koncový bod Traffic Manageru automaticky přesměruje provoz klienta na veřejnou IP adresu v cílové oblasti.

Komponenty

  • Skupiny dostupnosti jsou funkce odolnosti proti chybám, kterou můžete použít k distribuci virtuálních počítačů mezi několik izolovaných hardwarových uzlů v clusteru. V této architektuře skupiny dostupnosti chrání před selháním hardwaru a softwaru tím, že zajišťují, aby výpadky ovlivnily pouze podmnožinu virtuálních počítačů. Tento přístup udržuje dostupnost aplikací a provozní kontinuitu v rámci vícevrstvé aplikace.

  • Zóny dostupnosti jsou samostatná fyzická umístění v rámci oblasti Azure, která chrání aplikace a data před selháním datacentra. V této architektuře zóny dostupnosti poskytují vyšší odolnost tím, že distribuují virtuální počítače napříč několika datovými centry, které mají nezávislou infrastrukturu napájení, chlazení a sítě.

  • Azure Load Balancer je nástroj pro vyrovnávání zatížení vrstvy 4, který distribuuje příchozí provoz podle definovaných pravidel a sond stavu pro vysokou propustnost a nízkou latenci. V této architektuře veřejný nástroj pro vyrovnávání zatížení distribuuje příchozí klientský provoz mezi virtuální počítače webové vrstvy. Interní nástroje pro vyrovnávání zatížení směrují provoz z webové vrstvy do obchodní vrstvy a z obchodní vrstvy do back-endového clusteru SQL Serveru.

  • Traffic Manager je nástroj pro vyrovnávání zatížení provozu založený na DNS (Domain Name System), který distribuuje provoz mezi globální oblasti Azure. V této architektuře traffic Manager poskytuje globální vyrovnávání zatížení. Během normálních operací směruje uživatelský provoz do primární oblasti a během výpadků automaticky přesměruje provoz do DR regionu.

  • Site Recovery je služba zotavení po havárii, která replikuje virtuální počítače do jiné oblasti Azure pro provozní kontinuitu a zotavení po havárii (BC/DR). V této architektuře Site Recovery replikuje virtuální počítače do cílové oblasti. Tato replikace obnoví aplikace během výpadků zdrojové oblasti a podporuje požadavky na vyhovění předpisům prostřednictvím pravidelných cvičení pro obnovu po havárii.

Alternativy

  • Místo Windows můžete použít jiné operační systémy. Infrastruktura nezávisí na konkrétním operačním systému.

  • Back-endové úložiště dat můžete nahradit SQL Serverem pro Linux.

  • Úložiště dat můžete nahradit libovolnou standardní databázovou aplikací.

Podrobnosti scénáře

Tento scénář ukazuje vícevrstvé aplikace, která používá ASP.NET a SQL Server. V oblastech Azure, které podporují zóny dostupnosti, můžete virtuální počítače nasadit ve zdrojové oblasti napříč zónami dostupnosti a replikovat virtuální počítače do cílové oblasti, kterou používáte pro zotavení po havárii. V oblastech Azure, které nepodporují zóny dostupnosti, můžete virtuální počítače nasadit v rámci skupiny dostupnosti a replikovat virtuální počítače do cílové oblasti.

Ke směrování provozu mezi oblastmi potřebujete globální nástroj pro vyrovnávání zatížení. Mezi nabídky Azure patří:

  • Azure Front Door
  • Správce provozu

Při výběru nástroje pro vyrovnávání zatížení zvažte své požadavky a sadu funkcí těchto dvou nabídek. Zvažte rychlost převedení provozu, režii správy protokolu TLS (Transport Layer Security) a rozpočtová omezení organizace.

Azure Front Door má možnosti vrstvy 7, včetně SSL odlehčení (Secure Sockets Layer), směrování založeného na cestě, rychlého převzetí služeb při selhání a ukládání do mezipaměti. Tyto funkce zlepšují výkon a vysokou dostupnost vaší aplikace. Azure Front Door stojí více než Traffic Manager. Aby byly vyšší náklady oprávněné, využijte v Azure Front Door všechny funkce, nejen pouze funkci převzetí služeb při selhání. Azure Front Door směruje provoz přes síťovou infrastrukturu Azure dříve v cestě, což zkracuje dobu přenosu paketů.

Azure Front Door přidává síťový skok, který vyžaduje dodatečné bezpečnostní operace. Požadavky regulace mohou omezit ukončovací bod TLS kvůli nadměrnému provozu. Ověřte, že šifrovací sady protokolu TLS služby Azure Front Door splňují požadavky vaší organizace na zabezpečení. Ověřte také, že vaše back-endové služby používají certifikáty ze seznamu certifikační autority microsoftu (CA).

Traffic Manager je služba vyrovnávání zátěže založená na DNS, která vyrovnává zátěž a přepíná při selhání pouze na úrovni DNS. Traffic Manager přebírá služby při selhání pomaleji než Azure Front Door, protože ukládání do mezipaměti DNS a systémy, které nedodržují hodnoty TTL (Time to Live) DNS, způsobují zpoždění v šíření.

Oba nástroje pro vyrovnávání zatížení můžete kombinovat. Pro příklad převzetí služeb na základě DNS můžete použít Traffic Manager a přidat lokace POP (Point-of-Presence) služby Azure Front Door pro rychlejší směrování na okraji sítě.

Tato architektura využívá Traffic Manager pro jednoduchost a nižší náklady. Rychlost převzetí služeb při selhání splňuje požadavky pro tento příklad.

Potenciální případy použití

Tuto architekturu můžete použít k:

  • Nasaďte vysoce odolné aplikace, jako jsou SAP a další důležité obchodní aplikace.
  • Navrhnout plán BC/DR pro aplikační programy LOB
  • Nastavit DR a provádět příslušné cvičení pro účely souladu s předpisy.

Úvahy

Tyto aspekty implementují pilíře Dobře architektonického rámce Azure, což je sada hlavních principů, které můžete použít ke zlepšení kvality zátěže. Další informace najdete v tématu Well-Architected Framework.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v kontrolním seznamu pro kontrolu návrhu zabezpečení.

Skupiny zabezpečení sítě (NSG) chrání veškerý provoz virtuální sítě do front-endové aplikační vrstvy. Pravidla omezují tok provozu tak, aby k back-endové databázové vrstvě mohly přistupovat pouze instance virtuálních počítačů front-endové aplikační vrstvy. Obchodní vrstva a databázová vrstva blokují veškerý odchozí internetový provoz. Pokud chcete snížit nároky na útok, nejsou otevřené žádné přímé porty pro vzdálenou správu. Další informace najdete v tématu Skupiny zabezpečení sítě Azure.

Další informace o návrhu zabezpečených scénářů najdete v dokumentaci k zabezpečení Azure.

Optimalizace nákladů

Optimalizace nákladů se zaměřuje na způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro optimalizaci nákladů.

Při použití Site Recovery pro obnovení po havárii ve virtuálních počítačích Azure se účtují následující průběžné poplatky:

  • Licencování Site Recovery na virtuální počítač

  • Odchozí síťový přenos pro replikaci změn dat ze zdrojových disků virtuálních počítačů do jiného regionu Azure Site Recovery používá integrovanou kompresi ke snížení přenosu dat přibližně o 50%.

  • Úložiště v lokalitě pro obnovení Úložiště pro lokalitu obnovení obvykle zahrnuje úložiště zdrojové oblasti a navíc i další úložiště pro snímky bodů obnovení.

Použijte tento předkonfigurovaný odhad v cenové kalkulačce Azure k odhadu nákladů na zotavení po havárii pro třívrstvou aplikaci, která používá šest virtuálních počítačů. Upravte hodnoty tak, aby odpovídaly vašemu případu použití.

Efektivita výkonu

Efektivita výkonu odkazuje na schopnost vaší úlohy efektivně škálovat tak, aby splňovala požadavky uživatelů. Další informace najdete v kontrolním seznamu pro kontrolu návrhu týkajícího se efektivity výkonu.

Virtuální počítače můžete přidávat nebo odebírat v každé vrstvě na základě vašich požadavků na škálování. Tento scénář používá nástroje pro vyrovnávání zatížení, takže do vrstvy můžete přidat další virtuální počítače, aniž by to mělo vliv na dobu provozu aplikace.

Přispěvatelé

Společnost Microsoft udržuje tento článek. Tento článek napsali následující přispěvatelé.

Hlavní autor:

Pokud chcete zobrazit nepublikované profily LinkedIn, přihlaste se k LinkedIn.

Další kroky