Azure Traffic Manager se službou Azure Site Recovery

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

Traffic Manager používá dns (Domain Name System) k směrování požadavků 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 nevidí přenosy mezi klientem a službou.

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

Převzetí služeb při selhání z místního prostředí do Azure

V prvním scénáři zvažte společnost A , která má veškerou infrastrukturu aplikací 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 k ochraně svých aplikací používat Azure Site Recovery.

Společnost A spouští aplikace s veřejnými koncovými body a chce mít možnost bezproblémově přesměrovat provoz do Azure v případě havárie. Metoda prioritního 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.
• Pomocí metody prioritního směrování 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í má přiřazenou prioritu 1 a převzetí služeb při selhání prioritu 2.
• Vzhledem k tomu, že je primární koncový bod hostovaný mimo Azure, vytvoří se jako externí koncový bod.
• S Azure Site Recovery web Azure nemá před převzetím služeb při selhání spuštěné žádné virtuální počítače ani aplikace. Koncový bod převzetí služeb při selhání se tedy vytvoří také jako externí koncový bod.
• Ve výchozím nastavení se provoz uživatelů směruje do místní aplikace, protože tento koncový bod má přiřazenou nejvyšší prioritu. Pokud je primární koncový bod v pořádku, nesměruje se do Azure žádný provoz.

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í pro přepnutí mezi místním prostředím do Azure v případě havárie a zajistit minimální prostoje pro uživatele.

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ž teď 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. Pomocí výkonných testovacích funkcí převzetí služeb při selhání Azure Site Recovery můžou zákazníci vyhodnotit výkon aplikací v Azure, aniž by to mělo vliv na jejich místní prostředí. A když jsou zákazníci připravení na migraci, můžou se rozhodnout migrovat celé úlohy společně nebo se rozhodnout migrovat a škálovat postupně.

Metoda váženého směrování Azure Traffic Manageru se dá použít k přesměrování části příchozího provozu do Azure a zároveň k přesměrování většiny do místního prostředí. Tento přístup může pomoct vyhodnotit výkon škálování, protože při migraci stále většího počtu ú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řesune část svého aplikačního prostředí a zbytek zachová místně. V počátečních fázích, kdy je většina prostředí v místním prostředí, se místnímu prostředí přiřadí větší váha. Traffic Manager vrátí koncový bod na základě vah přiřazených dostupným koncovým bodům.

Během migrace jsou oba koncové body aktivní a většina provozu se směruje do místního prostředí. S tím, jak migrace pokračuje, je možné 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 si představte 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žívat Azure Site Recovery k ochraně svých aplikací.

Společnost C spouští aplikace s veřejnými koncovými body a chce mít možnost bezproblémově přesměrovat provoz do jiné oblasti Azure v případě havárie. Metoda směrování provozu 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.
• Pomocí metody prioritního směrování vytvoří společnost C dva koncové body – primární pro zdrojovou oblast (Azure – východní Asie) a převzetí služeb při selhání pro oblast obnovení (Azure Jihovýchodní Asie). Primární má přiřazenou prioritu 1 a převzetí služeb při selhání 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 provoz uživatelů směruje do aplikace zdrojové oblasti (Východní Asie), protože tento koncový bod má přiřazenou nejvyšší prioritu. Pokud je primární koncový bod v pořádku, nesměruje se do oblasti obnovení žádný provoz.

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 obnovení. 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 pro 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í pro přepínání mezi oblastmi zdroje a obnovení a zajistit minimální výpadky pro uživatele.

Když dojde k havárii, může společnost C navrátit služby po obnovení z oblasti Azure pro obnovení do zdrojové oblasti Azure pomocí Azure Site Recovery. Když teď 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 zlepšují prostředí zákazníků přizpůsobením aplikací tak, aby vyhovovaly regionálním potřebám. Lokalizace a snížení latence může vést k rozdělení infrastruktury aplikací mezi oblasti. Podniky jsou také vázány regionálními zákony o datech 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, kdy společnost D rozdělila koncové body aplikace tak, aby samostatně obsluhovala Německo a zbytek světa. Společnost D k nastavení tohoto nastavení využívá metodu geografického směrování azure Traffic Manageru. Veškerý provoz pocházející z Německa se směruje do koncového bodu 1 a veškerý provoz pocházející mimo Německo se směruje do koncového bodu 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, nedojde k žádnému přesměrování provozu do koncového bodu 2. Provoz pocházející z Německa se dál směruje do koncového bodu 1 bez ohledu na stav koncového bodu, takže němečtí uživatelé nebudou mít přístup k aplikaci společnosti D. Podobně platí, že pokud koncový bod 2 přejde do režimu offline, nedojde k žádnému přesměrování provozu do koncového bodu 1.

Aby nedošlo k tomuto problému a zajistila odolnost aplikací, používá společnost Dvnořené profily Traffic Manageru s Azure Site Recovery. V nastavení vnořeného profilu se provoz nesměruje do jednotlivých koncových bodů, ale do jiných profilů Traffic Manageru. Toto nastavení funguje takto:

• Místo 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 koncovým bodem 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í, využívá každá distribuce úloh Azure Site Recovery k převzetí služeb při selhání do oblasti obnovení v případě havárie.
• Když nadřazený Traffic Manager obdrží dotaz DNS, směruje se na příslušný podřízený Traffic Manager, který na dotaz odpoví dostupným koncovým bodem.

Pokud například dojde k selhání koncového bodu v oblasti Německo – střed, je možné aplikaci rychle obnovit na severovýchod Německa. 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 vyřešit obnovením úlohy aplikace do severní Evropy, kdy Azure Traffic Manager zpracovává přesměrování DNS na dostupný koncový bod.

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

Aspekty cíle doby obnovení (RTO)

Ve většině organizací se o přidávání nebo úpravu záznamů DNS stará samostatný tým nebo někdo mimo organizaci. 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 od organizace 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í se nevyžaduje žádná ruční ani skriptovaná akce. Tento přístup pomáhá rychle přepínat (a tím snížit rto) a vyhnout se nákladným časově náročným chybám změn DNS v případě havárie. U Traffic Manageru je dokonce i krok navrácení služeb po obnovení automatizovaný, který by jinak musel být spravován samostatně.

Nastavení správného intervalu sondy prostřednictvím kontrol stavu základního nebo rychlého intervalu může výrazně snížit hodnotu RTO během převzetí služeb při selhání a snížit výpadky uživatelů.

Dále můžete optimalizovat hodnotu TTL (Time to Live) DNS pro profil Traffic Manageru. Hodnota TTL je hodnota, pro kterou klient uloží položku DNS do mezipaměti. U záznamu by se DNS v rámci rozsahu hodnoty TTL nevytádá dvakrát. Ke každému záznamu DNS je přidružená hodnota TTL. Snížení této hodnoty má za následek více dotazů DNS na Traffic Manager, ale může snížit rto rychlejší zjišťováním výpadků.

Hodnota TTL, ke které dochází 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í.