Azure Traffic Manager se službou Azure Site Recovery

Azure Traffic Manager umožňuje řídit distribuci provozu napříč koncovými body aplikace. Koncový bod je jakákoli internetová služba hostovaná v rámci nebo mimo Azure.

Traffic Manager pomocí dns (Domain Name System) směruje požadavky klientů na nejvhodnější koncový bod na základě metody směrování provozu a stavu koncových bodů. Traffic Manager poskytuje celou řadu metod směrování provozu a možností monitorování koncových bodů, takže vyhovuje různým požadavkům aplikací a modelům automatického převzetí služeb při selhání. Klienti se připojí k vybranému koncovému bodu přímo. Traffic Manager není proxy server ani brána a nezobrazuje provoz mezi klientem a službou.

Tento článek popisuje, jak můžete kombinovat inteligentní směrování služby Azure Traffic Monitor s výkonnými možnostmi zotavení po havárii a migrací služby Azure Site Recovery.

Místní převzetí služeb při selhání do Azure

Pro první scénář zvažte společnost A , která má veškerou svou aplikační infrastrukturu spuštěnou v místním prostředí. Z důvodů provozní kontinuity a dodržování předpisů se společnost A rozhodne používat Azure Site Recovery k ochraně svých aplikací.

Společnost A provozuje aplikace s veřejnými koncovými body a chce bezproblémově přesměrovat provoz do Azure v případě havárie. Metoda Prioritní směrování provozu v Azure Traffic Manageru umožňuje společnosti A snadno implementovat tento model převzetí služeb při selhání.

Nastavení je následující:

• Společnost A vytvoří profil Traffic Manageru.
• S využitím metody směrování priority vytvoří společnost A dva koncové body – primární pro místní prostředí a převzetí služeb při selhání pro Azure. Primární je přiřazena priorita 1 a převzetí služeb při selhání má přiřazenou prioritu 2.
• Vzhledem k tomu, že primární koncový bod je hostovaný mimo Azure, vytvoří se koncový bod jako externí koncový bod.
• S Azure Site Recovery nemá lokalita Azure žádné virtuální počítače ani aplikace spuštěné před převzetím služeb při selhání. Koncový bod převzetí služeb při selhání se tedy vytvoří také jako externí koncový bod.
• Ve výchozím nastavení se uživatelský provoz směruje do místní aplikace, protože k němu je přidružená nejvyšší priorita. Pokud je primární koncový bod v pořádku, žádný provoz se nesměruje do Azure.

V případě havárie může společnost A aktivovat převzetí služeb při selhání do Azure a obnovit své aplikace v Azure. Když Azure Traffic Manager zjistí, že primární koncový bod už není v pořádku, automaticky použije koncový bod převzetí služeb při selhání v odpovědi DNS a uživatelé se připojí k aplikaci obnovené v Azure.

V závislosti na obchodních požadavcích může společnost A zvolit vyšší nebo nižší frekvenci sondování, aby se v případě havárie přepnula mezi místním prostředím do Azure a zajistila minimální prostoje uživatelů.

Když dojde k havárii, může společnost A navrátit služby po obnovení z Azure do místního prostředí (VMware nebo Hyper-V) pomocí Azure Site Recovery. Když Traffic Manager zjistí, že primární koncový bod je znovu v pořádku, automaticky použije primární koncový bod v odpovědích DNS.

Migrace z místního prostředí do Azure

Kromě zotavení po havárii umožňuje Azure Site Recovery také migrace do Azure. Díky výkonným funkcím testovacího převzetí služeb při selhání azure Site Recovery můžou zákazníci posoudit výkon aplikací v Azure, aniž by to ovlivnilo místní prostředí. A když jsou zákazníci připravení k migraci, můžou se rozhodnout migrovat celé úlohy společně nebo se rozhodnout migrovat a škálovat postupně.

Metodu váženého směrování Azure Traffic Manageru je možné použít k směrování části příchozího provozu do Azure a zároveň směrovat většinu do místního prostředí. Tento přístup může pomoct vyhodnotit výkon škálování, protože při migraci dalších úloh do Azure můžete pokračovat ve zvyšování váhy přiřazené k Azure.

Například společnost B se rozhodne migrovat ve fázích, přesunout některé z jeho aplikačních prostředí a zachovat zbytek v místním prostředí. Během počátečních fází, kdy je většina prostředí místní, se k místnímu prostředí přiřadí větší váha. Traffic Manager vrátí koncový bod na základě váhy přiřazených dostupným koncovým bodům.

Během migrace jsou oba koncové body aktivní a většina provozu se přesměruje do místního prostředí. S tím, jak migrace pokračuje, je možné k koncovému bodu v Azure přiřadit větší váhu a nakonec je možné po migraci deaktivovat místní koncový bod.

Převzetí služeb při selhání z Azure do Azure

V tomto příkladu zvažte společnost C , která má veškerou aplikační infrastrukturu spuštěnou v Azure. Z důvodů provozní kontinuity a dodržování předpisů se společnost C rozhodne použít Azure Site Recovery k ochraně svých aplikací.

Společnost C spouští aplikace s veřejnými koncovými body a chce bezproblémově přesměrovat provoz do jiné oblasti Azure v případě havárie. Metoda Směrování provozu podle priority umožňuje společnosti C snadno implementovat tento model převzetí služeb při selhání.

Nastavení je následující:

• Společnost C vytvoří profil Traffic Manageru.
• S využitím metody směrování priority vytvoří společnost C dva koncové body – primární pro zdrojovou oblast (Azure East Asia) a převzetí služeb při selhání pro oblast obnovení (Azure Jihovýchodní Asie). Primární je přiřazena priorita 1 a převzetí služeb při selhání má přiřazenou prioritu 2.
• Vzhledem k tomu, že primární koncový bod je hostovaný v Azure, může být koncový bod jako koncový bod Azure.
• S Azure Site Recovery nemá lokalita Azure pro obnovení žádné virtuální počítače ani aplikace spuštěné před převzetím služeb při selhání. Koncový bod převzetí služeb při selhání je tedy možné vytvořit jako externí koncový bod.
• Ve výchozím nastavení se uživatelský provoz směruje do zdrojové aplikace (Východní Asie), protože k němu je přidružená nejvyšší priorita. Pokud je primární koncový bod v pořádku, žádný provoz se nesměruje do oblasti obnovení.

V případě havárie může společnost C aktivovat převzetí služeb při selhání a obnovit své aplikace v oblasti Azure pro zotavení. Když Azure Traffic Manager zjistí, že primární koncový bod už není v pořádku, automaticky použije koncový bod převzetí služeb při selhání v odpovědi DNS a uživatelé se připojí k aplikaci obnovené v oblasti Azure obnovení (Jihovýchodní Asie).

V závislosti na obchodních požadavcích může společnost C zvolit vyšší nebo nižší frekvenci sondování, která se má přepínat mezi zdrojovými oblastmi a oblastmi obnovení, a zajistit minimální prostoje pro uživatele.

Když dojde k havárii, může společnost C po obnovení po obnovení z oblasti Azure obnovení do zdrojové oblasti Azure použít Azure Site Recovery. Když Traffic Manager zjistí, že primární koncový bod je znovu v pořádku, automaticky použije primární koncový bod v odpovědích DNS.

Ochrana podnikových aplikací ve více oblastech

Globální podniky často vylepšují uživatelské prostředí přizpůsobením svých aplikací tak, aby vyhovovaly regionálním potřebám. Lokalizací a snížením latence může dojít k rozdělení infrastruktury aplikací mezi oblasti. Podniky jsou také vázány regionálními datovými zákony v určitých oblastech a rozhodnou se izolovat část své aplikační infrastruktury v rámci regionálních hranic.

Podívejme se na příklad, ve kterém společnost D rozdělila koncové body aplikace tak, aby samostatně sloužila Německu a zbytku světa. Společnost D k nastavení využívá metodu geografického směrování Azure Traffic Manageru. Veškerý provoz pocházející z Německa se směruje na koncový bod 1 a veškerý provoz pocházející mimo Německo se směruje na koncový bod 2.

Problém s tímto nastavením spočívá v tom, že pokud koncový bod 1 z nějakého důvodu přestane fungovat, neexistuje přesměrování provozu na koncový bod 2. Provoz pocházející z Německa se bude dál směrovat na koncový bod 1 bez ohledu na stav koncového bodu a nechat německé uživatele bez přístupu k aplikaci společnosti D. Podobně platí, že pokud koncový bod 2 přejde do offline režimu, neexistuje přesměrování provozu na koncový bod 1.

Aby se zabránilo tomuto problému a zajistilo odolnost aplikací, společnost D používá vnořené profily Traffic Manageru se službou Azure Site Recovery. V nastavení vnořeného profilu se provoz nesměruje na jednotlivé koncové body, ale na jiné profily Traffic Manageru. Toto nastavení funguje takto:

• Místo využití geografického směrování s jednotlivými koncovými body používá společnost D geografické směrování s profily Traffic Manageru.
• Každý podřízený profil Traffic Manageru využívá prioritní směrování s primárním a koncovým bodem obnovení, a proto vnořuje směrování priority v rámci geografického směrování.
• Aby se zajistila odolnost aplikací, každá distribuce úloh využívá Azure Site Recovery k převzetí služeb při selhání do oblasti obnovení v případě události havárie.
• Když nadřazený Traffic Manager obdrží dotaz DNS, je přesměrován na příslušný podřízený Traffic Manager, který reaguje na dotaz s dostupným koncovým bodem.

Pokud například koncový bod v Centru Německa selže, aplikace se dá rychle obnovit do Německa – severovýchod. Nový koncový bod zpracovává provoz pocházející z Německa s minimálními výpadky pro uživatele. Podobně je možné výpadek koncového bodu v oblasti Západní Evropa zpracovat obnovením úlohy aplikace do severní Evropy pomocí Azure Traffic Manageru, který zpracovává DNS přesměrovává na dostupný koncový bod.

Výše uvedené nastavení je možné rozšířit tak, aby zahrnovalo tolik kombinací oblastí a koncových bodů, kolik je potřeba. Traffic Manager umožňuje až 10 úrovní vnořených profilů a neumožňuje smyčky v rámci vnořené konfigurace.

Důležité informace o cíli doby obnovení (RTO)

Ve většiněorganizacích Díky tomu je úloha změny záznamů DNS velmi náročná. Doba potřebná k aktualizaci záznamů DNS jinými týmy nebo organizacemi, které spravují infrastrukturu DNS, se liší od organizace po organizaci a ovlivňuje RTO aplikace.

Pomocí Traffic Manageru můžete předem načíst práci potřebnou pro aktualizace DNS. V době skutečného převzetí služeb při selhání není nutná žádná ruční ani skriptovaná akce. Tento přístup pomáhá při rychlém přepínání (a snížení RTO) a také k tomu, aby se zabránilo nákladným časově náročným chybám změn DNS v případě havárie. S Traffic Managerem je dokonce i krok navrácení služeb po obnovení automatizovaný, což by jinak muselo být spravováno samostatně.

Nastavení správného intervalu probívání prostřednictvím základních nebo rychlých kontrol stavu intervalů může výrazně snížit plánovanou dobu obnovení během převzetí služeb při selhání a snížit prostoje pro uživatele.

Hodnotu TTL (Time to Live) DNS můžete navíc optimalizovat pro profil Traffic Manageru. Hodnota TTL je hodnota, pro kterou klient uloží položku DNS do mezipaměti. V případě záznamu by se DNS v rozsahu hodnoty TTL nezoznamenal dvakrát. Každý záznam DNS má přidruženou hodnotu TTL. Snížení této hodnoty vede k většímu počtu dotazů DNS na Traffic Manager, ale může snížit plánovanou dobu obnovení zjišťováním výpadků rychleji.

Hodnota TTL, ke které došlo u klienta, se také nezvyšuje, pokud se zvýší počet překladačů DNS mezi klientem a autoritativním serverem DNS. Překladače DNS odpočítávají hodnotu TTL a předávají pouze hodnotu TTL, která odráží uplynulý čas od uložení záznamu do mezipaměti. Tím se zajistí, že se záznam DNS aktualizuje v klientovi po hodnotě TTL bez ohledu na počet překladačů DNS v řetězu.

Další kroky

• Přečtěte si další informace o metodách směrování Traffic Manageru.
• Přečtěte si další informace o vnořených profilech Traffic Manageru.
• Přečtěte si další informace o monitorování koncových bodů.
• Přečtěte si další informace o plánech obnovení pro automatizaci převzetí služeb při selhání aplikací.