Wysoka dostępność i odzyskiwanie po awarii
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 usługi Azure Cache for Redis lub implementacji usługi Azure Cache for Redis Enterprise.
Różne opcje wysokiej dostępności są dostępne w warstwach Standardowa, Premium i Enterprise:
| Opcja | Opis | Dostępność | Standardowa (Standard) | Premium | Przedsiębiorstwa |
|---|---|---|---|---|---|
| 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) | Tak | Tak | Tak |
| Nadmiarowość strefy | Konfiguracja z replikacją z wieloma węzłami w Strefy dostępności z automatycznym trybem failover | 99,9% w warstwie Premium; 99,99% w przedsiębiorstwie (zobacz szczegóły) | Tak (wersja zapoznawcza) | Tak | Tak |
| Replikacja geograficzna | Wystąpienia połączonej pamięci podręcznej w dwóch regionach z kontrolowanym przez użytkownika trybem failover | Premia; Przedsiębiorstwo (zobacz szczegóły) | Nie. | Bierny | Aktywne |
| Import/Export | Migawka danych w pamięci podręcznej do punktu w czasie. | 99,9% (zobacz szczegóły) | Nie. | Tak | Tak |
| Trwałość | Okresowe zapisywanie danych na koncie magazynu. | 99,9% (zobacz szczegóły) | Nie. | Tak | Podgląd |
Replikacja w warstwie Standardowa w celu zapewnienia wysokiej dostępności
Odpowiednie warstwy: Standardowa, Premium, Enterprise, Enterprise Flash
Zalecane w przypadku: wysoka dostępność
Usługa Azure Cache for 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 Cache for Redis zapewnia większe procentowe stawki dostępności niż to, co jest osiągalne przez hostowanie usługi Redis na jednej maszynie wirtualnej.
Usługa Azure Cache for Redis w odpowiednich warstwach jest domyślnie uruchamiana na dwóch serwerach Redis. Dwa serwery są hostowane na dedykowanych maszynach wirtualnych. Usługa Redis typu open source umożliwia tylko jednemu serwerowi obsługę żądań zapisu danych.
W przypadku usługi Azure Cache for Redis jeden serwer jest węzłem podstawowym, a drugi to replika. Po aprowizaniu węzłów serwera usługa Azure Cache for 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.
Uwaga
Zwykle aplikacja kliencka usługi Azure Cache for Redis komunikuje się z węzłem podstawowym w pamięci podręcznej dla wszystkich żądań odczytu i zapisu. Niektórych klientów można skonfigurować do odczytu z węzła repliki.
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 Cache for Redis zawiera szczegółowe wyjaśnienie typów trybu failover. Usługa Azure Cache for 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.
Ponadto usługa Azure Cache for Redis udostępnia więcej węzłów repliki w warstwie Premium. Pamięć podręczna z wieloma replikami można skonfigurować z maksymalnie trzema węzłami repliki. Posiadanie większej liczby replik zwykle zwiększa odporność, ponieważ masz węzły kopii zapasowej podstawowego. Nawet w przypadku większej liczby replik wystąpienie usługi Azure Cache for Redis nadal może mieć poważny wpływ na awarię centrum danych lub strefy dostępności. Dostępność pamięci podręcznej można zwiększyć przy użyciu wielu replik z nadmiarowością strefy.
Nadmiarowość stref
Odpowiednie warstwy: Standardowa (wersja zapoznawcza), Premium, Enterprise, Enterprise Flash
Zalecane w przypadku: wysoka dostępność, odzyskiwanie po awarii — wewnątrz regionu
Usługa Azure Cache for Redis obsługuje konfiguracje strefowo nadmiarowe w warstwach Standardowa (wersja zapoznawcza), Premium i Enterprise. Strefowo nadmiarowa pamięć podręczna może umieścić swoje węzły w różnych Strefy dostępności platformy Azure w tym samym regionie. Eliminuje awarię centrum danych lub strefy dostępności jako pojedynczy punkt awarii i zwiększa ogólną dostępność pamięci podręcznej.
Uwaga
W pamięciach podręcznych Premium tylko automatyczna alokacja strefy jest dostępna w publicznej wersji zapoznawczej. Ręczne wybieranie stref dostępności bez zmian. Wybór ręczny jest ogólnie dostępny (ogólna dostępność).
Jeśli pamięć podręczna jest skonfigurowana do używania co najmniej dwóch stref zgodnie z opisem we wcześniejszej sekcji artykułu, węzły pamięci podręcznej są tworzone w różnych strefach. 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.
Ważne
Teraz można włączyć automatyczną alokację strefy dla wszystkich pamięci podręcznych w odpowiednich warstwach i regionach. Aby uzyskać więcej informacji, zobacz Włączanie nadmiarowości stref dla usługi Azure Cache for Redis.
Warstwa Premium
Na poniższym diagramie przedstawiono konfigurację strefowo nadmiarową dla warstwy Premium:
Usługa Azure Cache for Redis dystrybuuje węzły w strefowo nadmiarowej pamięci podręcznej w sposób okrężny w wybranym Strefy dostępności. Określa również węzeł, który początkowo służy jako podstawowy.
Środowisko w dół strefy dla warstwy Premium
Strefowo nadmiarowa pamięć podręczna zapewnia automatyczną pracę w trybie failover. Gdy bieżący węzeł podstawowy jest niedostępny, jedna z replik przejmuje. Aplikacja może mieć większy czas odpowiedzi pamięci podręcznej, jeśli nowy węzeł podstawowy znajduje się w innym module AZ. Strefy dostępności są oddzielone geograficznie. Przełączenie z jednego modułu AZ na inną zmienia odległość fizyczną między miejscem, w którym aplikacja i pamięć podręczna są hostowane. Ta zmiana ma wpływ na opóźnienia sieci z aplikacji do pamięci podręcznej. Oczekuje się, że dodatkowe opóźnienie mieści się w dopuszczalnym zakresie dla większości aplikacji. Zalecamy przetestowanie aplikacji, aby upewnić się, że działa dobrze z strefowo nadmiarową pamięcią podręczną.
Warstwy Flash dla przedsiębiorstw i przedsiębiorstw
Pamięć podręczna w obu warstwach Enterprise jest uruchamiana w klastrze usługi Redis Enterprise. Zawsze wymaga to nieparzystej liczby węzłów serwera w celu utworzenia kworum. Domyślnie ma trzy węzły, z których każda jest hostowana na dedykowanej maszynie wirtualnej.
- Pamięć podręczna przedsiębiorstwa ma dwa węzły danych o tym samym rozmiarze i jeden mniejszy węzeł kworum.
- Pamięć podręczna Flash przedsiębiorstwa ma trzy węzły danych o tym samym rozmiarze.
Klaster przedsiębiorstwa dzieli dane usługi Azure Cache for Redis na partycje wewnętrznie. Każda partycja ma replikę podstawową i co najmniej jedną. Każdy węzeł danych zawiera co najmniej jedną partycję. Klaster przedsiębiorstwa zapewnia, że podstawowe i repliki dowolnej partycji nigdy nie są sortowane w tym samym węźle danych. Partycje replikują dane asynchronicznie z prawyborów do odpowiednich replik.
Środowisko strefowe w dół dla warstw przedsiębiorstwa
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 przedsiębiorstwa używa modelu opartego na kworum, aby określić, które z pozostałych węzłów 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 warstwy Premium strefowo nadmiarowej są dostępne w następujących regionach:
| Ameryka Północna i Południowa | Europa | Bliski Wschód | Afryka | Azja i Pacyfik |
|---|---|---|---|---|
| Brazylia Południowa | Francja Środkowa | Katar Środkowy | Północna Republika Południowej Afryki | Australia Wschodnia |
| Kanada Środkowa | Niemcy Środkowo-Zachodnie | Indie Środkowe | ||
| Central US | Europa Północna | Japonia Wschodnia | ||
| Wschodnie stany USA | Norwegia Wschodnia | Korea Środkowa | ||
| Wschodnie stany USA 2 | Południowe Zjednoczone Królestwo | Southeast Asia | ||
| South Central US | West Europe | Azja Wschodnia | ||
| US Gov Wirginia | Szwecja Środkowa | Chiny Północne 3 | ||
| Zachodnie stany USA 2 | Szwajcaria Północna | |||
| Zachodnie stany USA 3 | Polska Środkowa |
Pamięci podręczne warstwy Flash przedsiębiorstwa i przedsiębiorstwa 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 |
* Warstwa Flash przedsiębiorstwa jest niedostępna w tym regionie.
Ponowne wdrażanie strefy dostępności i migracja
Obecnie jedynym sposobem konwersji pamięci podręcznej z konfiguracji innej niż AZ na konfigurację az jest ponowne wdrożenie pamięci podręcznej. Aby dowiedzieć się, jak ponownie wdrożyć bieżącą pamięć podręczną, zobacz Migrowanie wystąpienia usługi Azure Cache for Redis do obsługi strefy dostępności.
Trwałość
Odpowiednie warstwy: Premium, Enterprise (wersja zapoznawcza), Enterprise Flash (wersja zapoznawcza)
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 okresowe tworzenie migawek danych w pamięci i przechowywanie ich na koncie magazynu. Jeśli wystąpi awaria w wielu węzłach powodujących utratę danych, pamięć podręczna ładuje migawkę z konta magazynu. Aby uzyskać więcej informacji, zobacz Konfigurowanie trwałości danych dla wystąpienia usługi Azure Cache for Redis w warstwie Premium.
Konto magazynu na potrzeby trwałości
Rozważ wybranie konta magazynu geograficznie nadmiarowego, aby zapewnić wysoką dostępność trwałych danych. Aby uzyskać więcej informacji, zobacz Nadmiarowość usługi Azure Storage.
Import/Export
Odpowiednie warstwy: Premium, Enterprise, Flash Enterprise
Zalecane w przypadku: odzyskiwanie po awarii
Usługa Azure Cache for 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 Cache for Redis lub eksportowanie danych z usługi Azure Cache for Redis przy użyciu migawki bazy danych RDB. Migawka bazy danych RDB z pamięci podręcznej w warstwie Premium 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 Cache for 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.
Pasywna replikacja geograficzna
Odpowiednie warstwy: Premium
Zalecane w przypadku: odzyskiwanie po awarii — pojedynczy region
Replikacja geograficzna to mechanizm łączenia co najmniej dwóch wystąpień usługi Azure Cache for Redis, zwykle obejmujących dwa regiony świadczenia usługi Azure. Replikacja geograficzna jest przeznaczona głównie do odzyskiwania po awarii między regionami. Dwa wystąpienia pamięci podręcznej w warstwie Premium są połączone za pośrednictwem replikacji geograficznej w sposób zapewniający odczyty i zapisy w podstawowej pamięci podręcznej, a dane są replikowane do pomocniczej pamięci podręcznej.
Aby uzyskać więcej informacji na temat sposobu jej konfigurowania, zobacz Konfigurowanie replikacji geograficznej dla wystąpień usługi Azure Cache for Redis w warstwie Premium.
Jeśli region hostujący podstawową pamięć podręczną ulegnie awarii, musisz uruchomić tryb failover przez: najpierw odłączyć pomocniczą pamięć podręczną, a następnie zaktualizować aplikację, aby wskazywała pomocniczą pamięć podręczną na potrzeby odczytu i zapisu.
Aktywna replikacja geograficzna
Odpowiednie warstwy: Enterprise, Enterprise Flash
Zalecane w przypadku: wysoka dostępność, odzyskiwanie po awarii — wiele regionów
Warstwy przedsiębiorstwa obsługują bardziej 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 Cache for Redis Enterprise 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 warstwy przedsiębiorstwa 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 Cache for Redis w przedsiębiorstwie.
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
Odpowiednie warstwy: Standardowa, Premium, Enterprise, Enterprise Flash
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. Kod aplikacji powinien być odporny na utratę danych.
Po przywróceniu objętego regionu niedostępna pamięć podręczna Azure Cache for 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 Cache for Redis do różnych regionów.
Następne kroki
Dowiedz się więcej na temat konfigurowania opcji wysokiej dostępności usługi Azure Cache for Redis.