Udostępnij za pośrednictwem

Wysoka dostępność i odzyskiwanie po awarii

  • Dotyczy: ✅ Azure Cache for Redis

Podobnie jak w przypadku wszystkich systemów w chmurze, mogą wystąpić nieplanowane awarie, które powodują wyłączenie instancji maszyny wirtualnej (VM), strefy dostępności lub całego regionu 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 Premium Przedsiębiorstwa
Replikacja standardowa Konfiguracja z replikacją dwuwęzłową w jednym centrum danych z automatycznym przełączaniem awaryjnym 99,9% (zobacz szczegóły) Tak Tak Tak
Redundancja strefowa Konfiguracja z replikacją na wielu węzłach między Strefami dostępności z automatycznym przełączaniem awaryjnym 99,9% w warstwie Premium; 99,99% w przedsiębiorstwie (zobacz szczegóły) Tak Tak Tak
Replikacja geograficzna Wystąpienia połączonych pamięci podręcznych w dwóch regionach z mechanizmem przełączania awaryjnego kontrolowanym przez użytkownika Premia; Enterprise (zobacz szczegóły) Nie. Bierny Aktywne
Import/Export Migawka stanu danych w pamięci podręcznej z określonego punktu w czasie. 99,9% (zobacz szczegóły) Nie. Tak Tak
Trwałość Okresowe zapisywanie danych na koncie przechowywania. 99,9% (zobacz szczegóły) Nie. Tak Podgląd

Standardowa replikacja dla 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 przygotowaniu węzłów serwera usługa Azure Cache for Redis przypisuje im 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.

Konfiguracja replikacji danych

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 promuje się, aby stać się nowym węzłem podstawowym. Ten proces jest nazywany failover. Tryb failover to po prostu dwa węzły, podstawowy/replika, zamieniające się rolami, replika/podstawowy, przy czym jeden z węzłów może przejść w tryb offline na kilka minut. W większości przypadków przełączenia awaryjnego, węzły podstawowe i węzły replik koordynują przekazywanie roli, dzięki czemu jest niemalże zerowy czas bez węzła podstawowego.

Dotychczasowy serwer główny przechodzi w tryb offline na krótko, aby otrzymać aktualizacje od nowego serwera głównego. Następnie replika wraca online i ponownie dołącza do pamięci podręcznej, będąc w pełni zsynchronizowana. Kluczem jest to, że gdy węzeł jest niedostępny, jest to stan tymczasowy i zostaje ponownie połączony.

Typowa sekwencja przełączenia awaryjnego wygląda następująco, gdy podstawowy serwer musi zostać wyłączony na potrzeby konserwacji:

  1. Węzły podstawowe i węzły repliki negocjują skoordynowane przełączenie awaryjne i zamieniają się rolami.
  2. Replika (dawniej podstawowa) przechodzi w tryb offline na potrzeby ponownego rozruchu.
  3. Kilka sekund lub minut później replika wróci do trybu online.
  4. 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 doświadcza wielu awarii w okresie jej 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 replikacji w warstwie Premium. Pamięć podręczna z wieloma replikami może być skonfigurowana tak, aby mieć maksymalnie trzy węzły repliki. Posiadanie większej liczby replik zwykle zwiększa odporność, ponieważ masz węzły wspierające główny węzeł. Nawet przy większej liczbie replik instancja usługi Azure Cache for Redis nadal może być poważnie dotknięta awarią centrum danych lub strefy dostępności. Można zwiększyć dostępność pamięci podręcznej, stosując wiele replik z nadmiarowością strefową.

Redundancja strefowa

Odpowiednie warstwy: Standardowa, Premium, Enterprise, Enterprise Flash

Zalecane w przypadku: wysoka dostępność, odzyskiwanie po awarii — wewnątrz regionu

Usługa Azure Cache for Redis obsługuje redundantne konfiguracje strefowe w wersjach Standardowa, 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 to awarię centrum danych lub strefy dostępności jako pojedynczego punktu awarii i zwiększa ogólną dostępność pamięci podręcznej.

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 jedna strefa ulegnie awarii, węzły pamięci podręcznej w innych strefach pozostają dostępne, zapewniając prawidłowe działanie pamięci podręcznej.

Ważne

Usługa Azure Cache For Redis domyślnie tworzy strefowo nadmiarowe pamięci podręczne dla warstw Premium, Warstwy Standardowa przy użyciu Automatic_Zonal_Allocation w regionach obsługujących strefy. 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 redundantną konfigurację strefy dla warstwy Premium.

Konfiguracja strefowej redundancji

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 jego rolę. 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 jednej strefy dostępności (AZ) na inną strefę zmienia odległość fizyczną między miejscem, w którym aplikacja i pamięć podręczna są hostowane. Ta zmiana wpływa na czasy opóźnienia w sieci przy transmisji w obie strony 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 Enterprise i Flash dla przedsiębiorstw

Pamięć podręczna w obu warstwach Enterprise działa na 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 jednakowej wielkości węzły danych i jeden węzeł kworum o mniejszym rozmiarze.
  • 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 główną i co najmniej jedną replikę. Każdy węzeł danych zawiera co najmniej jedną partycję. Klaster Enterprise zapewnia, że partycja główna i jej repliki nigdy nie są umieszczane razem na tym samym węźle danych. Partycje replikują dane asynchronicznie z głównych do odpowiednich replik.

Doświadczenie redukcji strefy dla poziomów 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 Standardowa replikacja. 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 podstawowych baz danych według potrzeb.

Dostępność w regionach

Nadmiarowe w strefie pamięci podręczne w warstwie Premium i Standard są dostępne w następujących regionach:

Ameryki Europa Bliski Wschód Afryka Azja i Pacyfik
Brazylia Południowa Francja Środkowa Katar Środkowy Północna Afryka Południowa Australia Wschodnia
Kanada Środkowa Włochy Północne Północne Zjednoczone Emiraty Arabskie Indie Środkowe
Środkowe Stany Zjednoczone Niemcy Środkowo-Zachodnie Izrael Centralny Japonia Wschodnia
Wschodnie stany USA Norwegia Wschodnia
Wschodnie stany USA 2 Europa Północna Southeast Asia
Południowo-Centralna USA Południowe Zjednoczone Królestwo Azja Wschodnia
Rząd USA Wirginii Europa Zachodnia Chiny Północne 3
Zachodnie stany USA 2 Szwecja Środkowa Korea Środkowa
Zachodnie stany USA 3 Szwajcaria Północna Nowa Zelandia Północna
Meksyk Środkowy Polska Środkowa
Hiszpania Środkowa

Pamięci podręczne strefowo redundantnej warstwy Enterprise i Enterprise Flash są dostępne w następujących regionach:

Ameryki 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
Wschodnie stany USA Europa Zachodnia Southeast Asia
Wschodnie stany USA 2 Japonia Wschodnia*
Południowo-Centralna część USA Azja Wschodnia*
Zachodnie stany USA 2
Zachodnie stany USA 3
Brazylia Południowa

* Warstwa Enterprise Flash jest niedostępna w tym regionie.

Ponowne wdrażanie strefy dostępności i migracja

W warstwach Standardowa i Premium można uaktualnić istniejący zasób, aby użyć redundancji strefowej. Aby dowiedzieć się, jak uaktualnić swoją bieżącą pamięć podręczną, zobacz Migrowanie wystąpienia usługi Azure Cache for Redis w celu obsługi stref dostępności.

Trwałość

Odpowiednie warstwy: Premium, Enterprise (wersja zapoznawcza), Enterprise Flash (wersja zapoznawcza)

Zalecane dla: trwałości danych

Ponieważ dane pamięci podręcznej są przechowywane w pamięci, rzadki i nieplanowany błąd wielu węzłów może spowodować utratę wszystkich danych. Aby całkowicie uniknąć utraty danych, trwałość Redis umożliwia okresowe tworzenie migawek danych w pamięci i ich przechowywanie na koncie magazynowym. Jeśli wystąpi awaria w wielu węzłach, co prowadzi do utraty danych, pamięć podręczna ładuje migawkę z konta magazynowego. Aby uzyskać więcej informacji, zobacz Konfigurowanie trwałości danych dla wystąpienia Premium usługi Azure Cache for Redis.

Konto magazynu na potrzeby trwałości

Rozważ wybranie konta magazynu z georedundancją, aby zapewnić wysoką dostępność danych trwałych. Aby uzyskać więcej informacji, zobacz Nadmiarowość usługi Azure Storage.

Import/Eksport

Odpowiednie warstwy: Premium, Enterprise, Enterprise Flash

Zalecane w przypadku: odzyskiwania 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, aby regularnie uruchamiać eksport na swoje konto magazynowe. Aby uzyskać więcej informacji, zobacz Importowanie i eksportowanie danych w usłudze Azure Cache for Redis.

Konto magazynowe do eksportu

Rozważ wybranie konta magazynu z georedundancją, aby gwarantować wysoką dostępność wyeksportowanych danych. Aby uzyskać więcej informacji, zobacz Nadmiarowość usługi Azure Storage.

Pasywna replikacja geograficzna

Odpowiednie poziomy: Premium

Zalecane w przypadku: odzyskiwanie po awarii — pojedynczy region

Replikacja geograficzna to mechanizm łączenia 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, jak skonfigurować, zobacz Konfigurowanie replikacji geograficznej w warstwie Premium usługi Azure Cache for Redis.

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 międzyregionalne odzyskiwanie po awarii między różnymi regionami. Oprogramowanie Azure Cache for Redis Enterprise wykorzystuje replikowane typy danych bezkonfliktowych do obsługi zapisów w wielu instancjach pamięci podręcznej, scalania zmian i rozwiązywania konfliktów. 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 rozproszonych geograficznie wystąpień pamięci podręcznej za pośrednictwem odpowiednich interfejsó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 Wymuszone odłączenie w przypadku awarii regionu.

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.

Gdy objęty region zostanie przywrócony, niedostępny Azure Cache for Redis zostanie automatycznie przywrócony i dostępny do ponownego wykorzystania. Aby uzyskać więcej informacji o strategiach 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.