Wysoka dostępność i odzyskiwanie po awarii za pomocą usługi Azure Managed Redis (wersja zapoznawcza)
Podobnie jak w przypadku wszystkich systemów w chmurze, mogą wystąpić nieplanowane awarie powodujące wyłączenie wystąpienia maszyn wirtualnych, strefy dostępności lub całego regionu świadczenia platformy Azure. Zalecamy, aby klienci mieli plan obsługi awarii strefowych lub regionalnych.
W tym artykule przedstawiono informacje dla klientów dotyczące tworzenia planu ciągłości działania i odzyskiwania po awarii dla implementacji usługi Azure Managed Redis (wersja zapoznawcza).
Opcje wysokiej dostępności:
| Opcja | Opis | Dostępność |
|---|---|---|
| Replikacja w warstwie Standardowa | Konfiguracja z replikacją z dwoma węzłami w jednym centrum danych z automatycznym trybem failover | 99,9% (zobacz szczegóły) |
| Nadmiarowość strefy | Konfiguracja z replikacją z wieloma węzłami w Strefy dostępności z automatycznym trybem failover | 99,99% (zobacz szczegóły) |
| Geo-replication (Replikacja geograficzna) | Wystąpienia połączonej pamięci podręcznej w dwóch regionach z kontrolowanym przez użytkownika trybem failover | Aktywne (zobacz szczegóły) |
| Import/Export | Migawka danych w pamięci podręcznej do punktu w czasie. | 99,9% (zobacz szczegóły) |
| Trwałość | Okresowe zapisywanie danych na koncie magazynu. | 99,9% (zobacz szczegóły) |
Replikacja w warstwie Standardowa w celu zapewnienia wysokiej dostępności
Zalecane w przypadku: wysoka dostępność
Usługa Azure Managed Redis ma architekturę wysokiej dostępności, która zapewnia działanie wystąpienia zarządzanego, nawet jeśli awarie wpływają na bazowe maszyny wirtualne. Niezależnie od tego, czy awaria jest planowana, czy nieplanowana awaria, usługa Azure Managed Redis zapewnia większe procentowe stawki dostępności niż to, co jest osiągalne przez hostowanie usługi Redis na jednej maszynie wirtualnej. Konfiguracja usługi Azure Managed Redis jest uruchamiana domyślnie na dwóch serwerach Redis. Dwa serwery są hostowane na dedykowanych maszynach wirtualnych.
W przypadku usługi Azure Managed Redis jeden serwer jest węzłem podstawowym, a drugi jest repliką. Po aprowizować węzły serwera usługa Azure Managed Redis przypisuje do nich role podstawowe i repliki. Węzeł podstawowy jest zwykle odpowiedzialny za obsługę żądań zapisu i odczytu od klientów. Podczas operacji zapisu zatwierdza nowy klucz i aktualizację klucza do pamięci wewnętrznej i natychmiast odpowiada klientowi. Przekazuje operację do repliki asynchronicznie.
Jeśli węzeł podstawowy w pamięci podręcznej jest niedostępny, replika automatycznie podwyższa poziom, aby stała się nowym podstawowym. Ten proces jest nazywany trybem failover. Tryb failover to tylko dwa węzły, podstawowy/replika, role handlowe, replika/podstawowy, z jednym z węzłów, które prawdopodobnie przechodzą w tryb offline przez kilka minut. W większości trybów failover węzły podstawowe i repliki koordynują przekazywanie, dzięki czemu masz niemal zerowy czas bez podstawowego.
Były podstawowy przechodzi w tryb offline krótko, aby otrzymywać aktualizacje z nowego podstawowego. Następnie replika wraca do trybu online i ponownie dołącza pamięć podręczną do pełnej synchronizacji. Kluczem jest to, że gdy węzeł jest niedostępny, jest to warunek tymczasowy i wraca do trybu online.
Typowa sekwencja trybu failover wygląda następująco, gdy podstawowa potrzeba przejścia w dół na potrzeby konserwacji:
- Węzły podstawowe i repliki negocjują skoordynowane role pracy w trybie failover i handlu.
- Replika (dawniej podstawowa) przechodzi w tryb offline na potrzeby ponownego rozruchu.
- Kilka sekund lub minut później replika wróci do trybu online.
- Replika synchronizuje dane z serwera podstawowego.
Węzeł podstawowy może wyjść z usługi w ramach zaplanowanego działania konserwacji, takiego jak aktualizacja oprogramowania Redis lub systemu operacyjnego. Może również przestać działać z powodu nieplanowanych zdarzeń, takich jak awarie bazowego sprzętu, oprogramowania lub sieci. Tryb failover i stosowanie poprawek dla usługi Azure Managed Redis zawiera szczegółowe wyjaśnienie typów trybu failover. Usługa Azure Managed Redis przechodzi przez wiele trybów failover w okresie jego istnienia. Projekt architektury wysokiej dostępności wprowadza te zmiany w pamięci podręcznej tak niewidoczne dla klientów, jak to możliwe.
Nadmiarowość stref
Zalecane w przypadku: wysoka dostępność, odzyskiwanie po awarii — wewnątrz regionu
Usługa Azure Managed Redis domyślnie obsługuje konfigurację strefowo nadmiarową. Strefowo nadmiarowa pamięć podręczna automatycznie umieszcza swoje węzły w różnych Strefy dostępności platformy Azure w tym samym regionie. Gdy strefa ulegnie awarii, węzły pamięci podręcznej w innych strefach będą dostępne, aby pamięć podręczna działała jak zwykle. Eliminuje awarię centrum danych lub strefy dostępności jako pojedynczy punkt awarii i zwiększa ogólną dostępność pamięci podręcznej.
Środowisko strefowe w dół
Gdy węzeł danych stanie się niedostępny lub nastąpi podział sieci, odbywa się przejście w tryb failover podobny do opisanego w temacie Replikacja w warstwie Standardowa. Klaster używa modelu opartego na kworum, aby określić, które ocalałe węzły uczestniczą w nowym kworum. Promuje również partycje replik w tych węzłach do prawyborów zgodnie z potrzebami.
Dostępność w regionach
Pamięci podręczne strefowo nadmiarowe są dostępne w następujących regionach:
| Ameryka Północna i Południowa | Europa | Bliski Wschód | Afryka | Azja i Pacyfik |
|---|---|---|---|---|
| Kanada Środkowa* | Europa Północna | Australia Wschodnia | ||
| Środkowe stany USA* | Południowe Zjednoczone Królestwo | Indie Środkowe | ||
| East US | West Europe | Southeast Asia | ||
| Wschodnie stany USA 2 | Japonia Wschodnia* | |||
| South Central US | Azja Wschodnia* | |||
| Zachodnie stany USA 2 | ||||
| Zachodnie stany USA 3 | ||||
| Brazylia Południowa |
Trwałość
Zalecane w przypadku: trwałość danych
Ponieważ dane pamięci podręcznej są przechowywane w pamięci, rzadki i nieplanowany błąd wielu węzłów może spowodować usunięcie wszystkich danych. Aby całkowicie uniknąć utraty danych, trwałość usługi Redis umożliwia wykonywanie okresowych migawek danych w pamięci i przechowywanie ich na dysku zarządzanym dołączonym bezpośrednio do wystąpienia pamięci podręcznej. W przypadku utraty danych dane pamięci podręcznej są przywracane automatycznie przy użyciu migawki na dysku zarządzanym. Aby uzyskać więcej informacji, zobacz Konfigurowanie trwałości danych dla wystąpienia usługi Azure Managed Redis.
Import/Export
Zalecane w przypadku: odzyskiwanie po awarii
Usługa Azure Managed Redis obsługuje opcję importowania i eksportowania plików bazy danych Redis Database (RDB) w celu zapewnienia przenośności danych. Umożliwia importowanie danych do usługi Azure Managed Redis lub eksportowanie danych z usługi Azure Managed Redis przy użyciu migawki bazy danych RDB. Migawka bazy danych RDB z pamięci podręcznej jest eksportowana do obiektu blob na koncie usługi Azure Storage. Możesz utworzyć skrypt w celu okresowego wyzwalania eksportu na konto magazynu. Aby uzyskać więcej informacji, zobacz Importowanie i eksportowanie danych w usłudze Azure Managed Redis.
Konto magazynu do eksportowania
Rozważ wybranie konta magazynu geograficznie nadmiarowego, aby zapewnić wysoką dostępność wyeksportowanych danych. Aby uzyskać więcej informacji, zobacz Nadmiarowość usługi Azure Storage.
Aktywna replikacja geograficzna
Zalecane w przypadku: wysoka dostępność, odzyskiwanie po awarii — wiele regionów
Replikacja geograficzna to mechanizm łączenia wystąpień usługi Azure Managed Redis w wielu regionach świadczenia usługi Azure. Usługa Azure Managed Redis obsługuje zaawansowaną formę replikacji geograficznej o nazwie aktywna replikacja geograficzna, która oferuje zarówno wyższą dostępność, jak i odzyskiwanie po awarii między regionami w wielu regionach. Oprogramowanie Azure Managed Redis używa zreplikowanych typów danych bez konfliktów do obsługi zapisów w wielu wystąpieniach pamięci podręcznej, scala zmiany i rozwiązuje konflikty. Możesz dołączyć do pięciu wystąpień pamięci podręcznej w różnych regionach świadczenia usługi Azure, aby utworzyć grupę replikacji geograficznej.
Aplikacja korzystająca z takiej pamięci podręcznej może odczytywać i zapisywać w dowolnym z wystąpień rozproszonej geograficznie pamięci podręcznej za pośrednictwem odpowiednich punktów końcowych. Aplikacja powinna używać wartości najbliższej każdemu wystąpieniu aplikacji, co zapewnia najmniejsze opóźnienie. Aby uzyskać więcej informacji, zobacz Konfigurowanie aktywnej replikacji geograficznej dla wystąpień usługi Azure Managed Redis.
Jeśli region jednej z pamięci podręcznych w grupie replikacji ulegnie awarii, aplikacja musi przełączyć się do innego dostępnego regionu.
Gdy pamięć podręczna w grupie replikacji jest niedostępna, zalecamy monitorowanie użycia pamięci dla innych pamięci podręcznych w tej samej grupie replikacji. Chociaż jedna z pamięci podręcznych nie działa, wszystkie pozostałe pamięci podręczne w grupie replikacji zaczynają zapisywać metadane, których nie można udostępnić pamięci podręcznej, która nie działa. Jeśli użycie pamięci dla dostępnych pamięci podręcznych zacznie rosnąć z dużą szybkością po wyłączeniu jednej z pamięci podręcznych, rozważ odłączenie pamięci podręcznej, która jest niedostępna z grupy replikacji.
Aby uzyskać więcej informacji na temat wymuszania odłączania, zobacz Force-Unlink if there's region awarii.
Usuwanie i ponowne tworzenie pamięci podręcznej
Jeśli wystąpi awaria regionalna, rozważ ponowne utworzenie pamięci podręcznej w innym regionie i zaktualizowanie aplikacji w celu nawiązania połączenia z nową pamięcią podręczną. Ważne jest, aby zrozumieć, że dane są tracone podczas awarii regionalnej, chyba że używasz aktywnej replikacji geograficznej. Kod aplikacji powinien być odporny na utratę danych.
Po przywróceniu objętego regionu niedostępna usługa Azure Managed Redis zostanie automatycznie przywrócona i będzie dostępna do ponownego użycia. Aby uzyskać więcej strategii przenoszenia pamięci podręcznej do innego regionu, zobacz Przenoszenie wystąpień usługi Azure Managed Redis do różnych regionów.