Cvičení – rozšíření návrhu do více oblastí

  • 30 min

Contoso Shoes potřebuje způsob, jak odolat oblastním výpadkům. Aktuální razítko chcete nasadit do topologie aktivní-aktivní, sdílené a víceregionové topologie. V případě selhání oblasti musí být architektura navržená tak, aby přesměrovává provoz do jiné oblasti.

Aktuální stav a problém

Pro aplikaci stačí jedna oblast. Nedávný výpadek oblasti, který ovlivnil sítě, však způsobil, že systém z pohledu koncového uživatele přešel do režimu offline. Horizontální škálování v rámci oblasti nebo dokonce nasazení nového razítka v této oblasti by neobnovilo aplikaci ze stavu selhání.

DNS je uložen existujícím registrátorem pro api.contososhoes.com. Záznam DNS se přeloží na koncový bod služby App Services back-endu (apicontososhoes.azurewebsites.net) s časovým intervalem TTL (Time to Live) dvěma dny. Když je řešení nasazené do několika oblastí, je potřeba migrovat DNS.

Specifikace

  • Rozšiřte architekturu tak, aby fungovala v topologii s více oblastmi aktivní-aktivní.
  • Upravte model razítka nasazení, který umožňuje dynamicky přidávat a odebírat oblasti podle potřeby místo seznamu pevně zakódovaných prostředků ve dvou oblastech.
  • Pokud dojde k selhání oblasti, je potřeba provoz směrovat do oblasti, která není chybná, aniž by to mělo vliv na klienty, kteří už jsou v oblasti, která není chybná.
  • Klienti by neměli být připnuti do oblasti.
  • Klienti by pro kontaktování rozhraní API nemuseli měnit adresy URL. DNS by se měl migrovat do globálního směrovače.

Pokud chcete začít s návrhem, doporučujeme postupovat následovně:

1–Víceregionová topologie

Architektura musí být distribuovaná do dvou nebo více oblastí Azure, aby se chránila před oblastmi výpadky. Při výběru oblasti zvažte tyto faktory:

  • Oblast musí být schopná odolat výpadkům datacentra v této oblasti.
  • Služby Azure a možnosti používané v architektuře musí být v dané oblasti podporované.
  • Oblast a prostředky nasazené v dané oblasti musí mít blízkost koncových uživatelů a závislých systémů, aby se minimalizovala latence sítě.

Promyslete si scénář selhání. Předpokládejme, že region 1 získá 75 % provozu a nově přidaná oblast 2 získá zbývající provoz. Obě se škálují odpovídajícím způsobem, aby zvládly toto zatížení. Oblastní výpadek je v oblasti 1 a veškerý provoz je teď směrován do oblasti 2. Můžete udělat tento přechod hladce? Může region 2 podporovat zvýšené zatížení provozu?

Kontrola průběhu: Globální distribuce

2– globální směrování

Aby se klienti transparentně směrovali do některé pracovní oblasti, přidejte globální nástroj pro vyrovnávání zatížení. Nástroj pro vyrovnávání zatížení by měl použít kontroly stavu, které jste přidali v předchozím cvičení, a zjistit, jestli je razítko v pořádku. Můžete si představit způsoby, jak obsluhovat časté a podobné žádosti, které se dají splnit, aniž by se dostaly k back-endu?

  • Zvolte nativní službu Azure, která se integruje se stávající architekturou a dokáže rychle převzít služby při selhání.
  • Ujistěte se, že cesta příchozího přenosu dat v síti má ovládací prvky pro odepření neoprávněného provozu.
  • Minimalizujte latenci sítě tím, že koncovým uživatelům slouží z hraniční mezipaměti.
  • Migrujte existující DNS bez ovlivnění stávajících klientů.
  • Máte automatizovaný způsob, jak indikovat selhání oblasti, aby se zajistilo, že provoz není směrován do vadné oblasti. Také se můžete upozornit, až bude oblast opět dostupná, aby nástroj pro vyrovnávání zatížení mohl pokračovat ve směrování do této oblasti.

Kontrola průběhu: Globální směrování provozu

3. Změny razítka nasazení

Ideální stav je konfigurace aktivní-aktivní, která nevyžaduje ruční převzetí služeb při selhání a žádosti klientů je možné obsluhovat z libovolné oblasti. Zamyslete se nad tím, co znamená pro vaši architekturu. Máte například nějaký stav, který je uložený v regionálním razítku?

Některé služby v aktuální architektuře mají možnosti geografické replikace. Zvažte oddělení služeb na různá razítka: jedno razítko, které obsahuje globální prostředky, a další regionální razítko, které sdílí prostředky s globálním razítkem. Jedním z rozhodovacích faktorů by měl být životní cyklus těchto prostředků. Jaká je očekávaná životnost prostředku vzhledem k jiným prostředkům v architektuře? Měl by prostředek přežívat nebo sdílet životnost s celým systémem nebo oblastí, nebo by měl být dočasný?

Prozkoumejte funkce spolehlivosti služeb Azure používaných v architektuře. S těmito funkcemi můžete začít a prozkoumat ho podrobněji, abyste maximalizovali spolehlivost.

Služba Azure Funkce
Azure Cosmos DB Zápis do více oblastí
Azure Container Registry Geografická replikace
Plán Azure App Service Podpora zón dostupnosti

Kontrola průběhu: Datová platforma aplikací |

Kontrola práce

Tady jsou volby návrhu aplikací a dat pro podobnou architekturu. Pokryli jste všechny aspekty návrhu?

  • Kterou další oblast Azure jste vybrali pro topologii s více oblastmi a proč?
  • Povolili jste v každé oblasti Azure dvě nebo více Zóny dostupnosti Azure, abyste ochránili před výpadky datacenter?
  • Zahrnuli jste bránu Firewall webových aplikací pro řízení příchozího přenosu dat? Jaká pravidla směrování jste zavedli a proč?
  • Jak nástroj pro vyrovnávání zatížení podporuje váš existující záznam DNS?
  • Jak jste použili rozhraní API pro kontrolu stavu z předchozího cvičení?
  • Ochránili jste aplikaci před útoky DDoS, zejména bráníte škodlivým klientům v obejití nástroje pro vyrovnávání zatížení a dosažení regionálních instancí?
  • Jak jste přistupovali k migraci DNS?
  • Provedli jste u stávající komponenty nějaké změny skladové položky, které podporují topologii s více oblastmi?
  • Které služby Azure jste opustili jako singletony? Jak jste svůj výběr odůvodnili pro každou službu? Provedli jste nějaké změny konfigurace?
  • Protokolujete prostředky? Myslíte si, že to ovlivní vaši schopnost kontrolovat protokoly pro celkový systém?