Niezawodność w usłudze Azure Traffic Manager

Ten artykuł zawiera wsparcie dla odzyskiwania po awarii między regionami oraz ciągłości działalności biznesowej w usłudze Azure Traffic Manager.

Odzyskiwanie po awarii między regionami i ciągłość działania

Odzyskiwanie po awarii (DR) odnosi się do praktyk używanych przez organizacje do odzyskiwania po wystąpieniu zdarzeń o dużym wpływie, takich jak klęski żywiołowe lub nieudane wdrożenia, które powodują przestoje i utratę danych. Niezależnie od przyczyny najlepszym rozwiązaniem dla awarii jest dobrze zdefiniowany i przetestowany plan odzyskiwania po awarii oraz projekt aplikacji, który aktywnie obsługuje odzyskiwanie po awarii. Przed rozpoczęciem tworzenia planu odzyskiwania po awarii zobacz Zalecenia dotyczące projektowania strategii odzyskiwania po awarii.

W przypadku DR firma Microsoft używa modelu wspólnej odpowiedzialności . W tym modelu firma Microsoft zapewnia dostępność podstawowej infrastruktury i usług platformy. Jednak wiele usług platformy Azure nie replikuje automatycznie danych ani nie wraca z regionu, w którym wystąpił błąd, aby przeprowadzić replikację krzyżową do innego włączonego regionu. W przypadku tych usług odpowiadasz za skonfigurowanie planu odzyskiwania danych po awarii, który jest dostosowany do Twojego obciążenia. Większość usług oferty platformy Azure jako usługa (PaaS) udostępnia funkcje i wskazówki wspierające DR. Możesz użyć funkcji specyficznych dla usługi, aby wspierać szybkie odzyskiwanie i ułatwić opracowanie planu odzyskiwania po awarii.

Usługa Azure Traffic Manager to oparty na systemie DNS moduł równoważenia obciążenia ruchu, który umożliwia dystrybucję ruchu do publicznych aplikacji w globalnych regionach świadczenia usługi Azure. Usługa Traffic Manager zapewnia również publiczne punkty końcowe o wysokiej dostępności i szybkiej reakcji.

Usługa Traffic Manager używa systemu DNS do kierowania żądań klientów do odpowiedniego punktu końcowego usługi na podstawie metody routingu ruchu. Usługa Traffic Manager zapewnia również monitorowanie kondycji każdego punktu końcowego. Punkt końcowy może być dowolną usługą dostępną z Internetu hostowaną wewnątrz platformy Azure lub poza platformą Azure. Usługa Traffic Manager udostępnia szereg metod routingu ruchu oraz opcji monitorowania punktów końcowych, które zaspokoją potrzeby różnych aplikacji i modeli automatycznej pracy w trybie failover. Usługa Traffic Manager jest odporna na awarie, w tym awarię całego regionu platformy Azure.

Odzyskiwanie po awarii w lokalizacji geograficznej obejmującej wiele regionów

DNS to jeden z najbardziej wydajnych mechanizmów przekierowywania ruchu sieciowego. System DNS jest wydajny, ponieważ usługa DNS jest często globalna i zewnętrzna dla centrum danych. System DNS jest również odizolowany od błędów poziomu regionalnego lub strefy dostępności (AZ).

Istnieją dwa aspekty techniczne dotyczące konfigurowania architektury odzyskiwania po awarii:

• Używanie mechanizmu wdrażania do replikowania wystąpień, danych i konfiguracji między środowiskami podstawowymi i rezerwowymi. Tego typu odzyskiwanie po awarii można wykonać natywnie za pośrednictwem usługiAzure Site Recovery. Zobacz dokumentację usługi Azure Site Recovery za pośrednictwem urządzeń/usług partnerskich platformy Microsoft Azure, takich jak Veritas lub NetApp.

• Opracowanie rozwiązania do przekierowywania ruchu sieciowego/internetowego z lokacji głównej do lokacji rezerwowej. Ten typ odzyskiwania po awarii można osiągnąć za pośrednictwem usług Azure DNS, Azure Traffic Manager (DNS) lub globalnych modułów równoważenia obciążenia innych firm.

Ten artykuł koncentruje się specjalnie na planowaniu odzyskiwania po awarii usługi Azure Traffic Manager.

Wykrywanie, powiadamianie i zarządzanie awariami

Podczas awarii podstawowy punkt końcowy jest sprawdzany, a jego stan zmienia się na w stanie obniżonej wydajności, a lokalizacja odzyskiwania po awarii pozostaje online. Domyślnie usługa Traffic Manager wysyła cały ruch do podstawowego punktu końcowego (najwyższego priorytetu). Jeśli podstawowy endpoint się pogorszy, usługa Traffic Manager kieruje ruch do drugiego endpointu, jeśli pozostanie zdrowy. Można skonfigurować więcej punktów końcowych w usłudze Traffic Manager, które mogą służyć jako dodatkowe zapasowe punkty końcowe trybu awaryjnego lub jako mechanizmy równoważenia obciążenia, które współdzielą obciążenie między punktami końcowymi.

Konfigurowanie odzyskiwania po awarii i wykrywania awarii

Jeśli masz złożone architektury i wiele zestawów zasobów, które mogą wykonywać tę samą funkcję, możesz skonfigurować usługę Azure Traffic Manager (opartą na systemie DNS), aby sprawdzić kondycję zasobów i kierować ruch z zasobu niebędącego w dobrej kondycji do zasobu w dobrej kondycji.

W poniższym przykładzie zarówno region podstawowy, jak i region pomocniczy mają pełne wdrożenie. To wdrożenie obejmuje usługi w chmurze i zsynchronizowaną bazę danych.

Rysunek — automatyczne przechodzenie w tryb failover przy użyciu usługi Azure Traffic Manager

Jednak tylko region podstawowy aktywnie obsługuje żądania sieciowe od użytkowników. Region pomocniczy staje się aktywny tylko wtedy, gdy region podstawowy doświadcza przerwy w działaniu usługi. W takim przypadku wszystkie nowe żądania sieciowe są kierowane do regionu pomocniczego. Ponieważ kopiowanie zapasowe bazy danych odbywa się niemal natychmiast, oba moduły równoważenia obciążenia mają adresy IP, które mogą być monitorowane pod kątem kondycji, a instancje są ciągle aktywne, ta topologia zapewnia możliwość przejścia na niskie planowane czasy odzyskiwania i przełączenie awaryjne bez konieczności jakiejkolwiek interwencji ręcznej. Wtórny region awaryjnego przełączenia musi być gotowy do uruchomienia natychmiast po awarii regionu podstawowego.

Ten scenariusz jest idealny do użycia usługi Azure Traffic Manager, która ma wbudowane sondy dla różnych typów kontroli kondycji, w tym http/https i TCP. Usługa Azure Traffic Manager ma również aparat reguł, który można skonfigurować do przełączania w tryb failover, gdy wystąpi awaria zgodnie z poniższym opisem. Rozważmy następujące rozwiązanie przy użyciu usługi Traffic Manager:

• Klient ma punkt końcowy Region #1 znany jako prod.contoso.com ze statycznym adresem IP jako 100.168.124.44 i punktem końcowym Region #2 znanym jako dr.contoso.com ze statycznym adresem IP jako 100.168.124.43.
• Każde z tych środowisk jest frontowane za pośrednictwem właściwości publicznej, takiej jak moduł równoważenia obciążenia. Moduł równoważenia obciążenia można skonfigurować tak, aby miał punkt końcowy oparty na systemie DNS lub w pełni kwalifikowaną nazwę domeny (FQDN), jak pokazano powyżej.
• Wszystkie wystąpienia w regionie 2 są replikowane niemal w czasie rzeczywistym z regionem 1. Ponadto obrazy systemów są aktualne, a wszystkie dane oprogramowania/konfiguracji są zaktualizowane do zgodności z Regionem 1.
• Skalowanie automatyczne jest wstępnie skonfigurowane z wyprzedzeniem.

Aby skonfigurować tryb failover za pomocą usługi Azure Traffic Manager:

1. Utwórz nowy profil usługi Azure Traffic Manager Utwórz nowy profil usługi Azure Traffic Manager o nazwie contoso123 i wybierz metodę routingu jako Priorytet. Jeśli masz istniejącą grupę zasobów, z którą chcesz skojarzyć, możesz wybrać istniejącą grupę zasobów, w przeciwnym razie utworzyć nową grupę zasobów.

   

   Rysunek — tworzenie profilu usługi Traffic Manager

2. Tworzenie punktów końcowych w profilu usługi Traffic Manager

   W tym kroku utworzysz punkty końcowe wskazujące lokacje produkcyjne i odzyskiwania po awarii. W tym miejscu wybierz typ jako zewnętrzny punkt końcowy, ale jeśli zasób jest hostowany na platformie Azure, możesz również wybrać punkt końcowy platformy Azure . Jeśli wybierzesz punkt końcowy platformy Azure, wybierz zasób docelowy , który jest usługą App Service lub publicznym adresem IP przydzielonym przez platformę Azure. Priorytet jest ustawiany jako 1 , ponieważ jest to usługa podstawowa dla regionu 1. Podobnie utwórz punkt końcowy odzyskiwania po awarii w usłudze Traffic Manager.

   

   Rysunek — tworzenie punktów końcowych odzyskiwania po awarii

3. Konfigurowanie kontroli kondycji i konfiguracji trybu failover

   W tym kroku ustawisz czas życia rekordu DNS na 10 sekund, który jest honorowany przez większość rekursywnych resolverów, które mają dostęp do Internetu. Ta konfiguracja oznacza, że żaden program rozpoznawania nazw DNS nie buforuje informacji przez ponad 10 sekund.

   W przypadku ustawień monitora punktu końcowego ścieżka jest obecnie ustawiona na / lub katalog główny, ale możesz dostosować ustawienia końcowe, aby ocenić konkretną ścieżkę, na przykład prod.contoso.com/index.

   W poniższym przykładzie pokazano protokół https jako protokół sondowania. Można jednak również wybrać protokół HTTP lub tcp . Wybór protokołu zależy od aplikacji końcowej. Interwał sondowania jest ustawiony na 10 sekund, co umożliwia szybkie sondowanie, a ponowna próba jest ustawiona na 3. W związku z tym, usługa Traffic Manager przełączy się na drugi punkt końcowy, jeśli trzy kolejne interwały zarejestrują błąd.

   Poniższa formuła definiuje całkowity czas automatycznego przejścia w tryb failover:

   Time for failover = TTL + Retry * Probing interval

   W tym przypadku wartość to 10 + 3 * 10 = 40 sekund (maks.).

   Jeśli ponawianie jest ustawione na 1, a czas wygaśnięcia (TTL) jest ustawiony na 10 sekund, wówczas czas przełączenia awaryjnego będzie równy 10 + 1 * 10 = 20 sekund.

   Ustaw wartość Ponów próbę na wartość większą niż 1 , aby wyeliminować prawdopodobieństwo przejścia w tryb failover z powodu wyników fałszywie dodatnich lub drobnych blipów sieci.

   

   Rysunek — Konfigurowanie kontroli stanu zdrowia i konfiguracji awaryjnej

Dalsze kroki

• Niezawodność na platformie Azure

• Dowiedz się więcej o usłudze Azure Traffic Manager.

• Dowiedz się więcej o usłudze Azure DNS.