Niezawodność w usłudze Azure Managed Redis

Usługa Azure Managed Redis zapewnia w pełni zintegrowaną i zarządzaną usługę Redis Enterprise na platformie Azure, oferując magazyn danych w pamięci o wysokiej wydajności dla aplikacji. Ta usługa jest tworzona dla obciążeń przedsiębiorstwa wymagających bardzo małych opóźnień, wysokiej przepływności i zaawansowanych struktur danych.

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Firma Microsoft oferuje szereg możliwości wspierania odporności systemów i odzyskiwania. Odpowiadasz za zrozumienie, jak te możliwości działają w ramach wszystkich używanych usług oraz za wybór tych, które są potrzebne do osiągnięcia Twoich celów biznesowych i celów dotyczących niezawodności.

W tym artykule opisano niezawodność usługi Azure Managed Redis, w tym odporność na błędy przejściowe, awarie strefy dostępności i awarie całego regionu. W tym artykule opisano również strategie tworzenia kopii zapasowych i umowę dotyczącą poziomu usług (SLA).

Zalecenia dotyczące wdrażania produkcyjnego

Aby zapewnić wysoką niezawodność dla wystąpień usługi Azure Managed Redis w środowisku produkcyjnym, zalecamy:

Omówienie architektury niezawodności

W tej sekcji opisano niektóre ważne aspekty działania usługi, które są najbardziej istotne z perspektywy niezawodności. W sekcji przedstawiono architekturę logiczną, która zawiera niektóre z zasobów i funkcji wdrażanych i używanych. Omówiono również architekturę fizyczną, która zawiera szczegółowe informacje na temat działania usługi za kulisami.

Architektura logiczna

Usługa Azure Managed Redis jest oparta na usłudze Redis Enterprise i zapewnia niezawodność dzięki konfiguracjom wysokiej dostępności i możliwościom replikacji.

Wdrażasz wystąpienie usługi Azure Managed Redis, nazywane również wystąpieniem pamięci podręcznej lub pamięcią podręczną. Aplikacje klienckie przechowują dane w pamięci podręcznej i współdziałają z nimi przy użyciu interfejsów API usługi Redis.

Architektura fizyczna

Istnieją dwa kluczowe pojęcia, które należy zrozumieć podczas planowania odporności usługi Azure Managed Redis: węzłów i fragmentów.

• Węzły: Każde wystąpienie pamięci podręcznej składa się z węzłów, które są maszynami wirtualnymi. Każda maszyna wirtualna służy jako niezależna jednostka obliczeniowa w klastrze. Maszyny wirtualne nie są widoczne ani zarządzane bezpośrednio. Platforma automatycznie zarządza tworzeniem wystąpień, monitorowaniem kondycji i zastępowaniem wystąpień w złej kondycji. Zestaw maszyn wirtualnych, razem, jest również nazywany klastrem.

  Możesz skonfigurować wystąpienie w celu zapewnienia wysokiej dostępności. W takim przypadku usługa Azure Managed Redis gwarantuje, że istnieją co najmniej dwa węzły i automatycznie replikuje dane między węzłami. W regionach ze strefami dostępności węzły są umieszczane w różnych strefach dostępności. Aby uzyskać więcej informacji, zobacz Odporność na błędy strefy dostępności.

  Usługa abstrahuje konkretną liczbę węzłów używanych w każdej konfiguracji, aby uniknąć złożoności i zapewnić optymalną konfigurację.

• Odłamki: Każdy węzeł uruchamia wiele procesów serwera Redis nazywanych odłamkami, które zarządzają podzbiorem danych pamięci podręcznej. Gdy pamięć podręczna jest skonfigurowana pod kątem wysokiej dostępności, fragmenty są automatycznie dystrybuowane i replikowane między węzłami. Należy określić zasady klastra, które określają sposób dystrybucji fragmentów między węzłami.

Aby uzyskać więcej informacji, zobacz Architektura usługi Azure Managed Redis oraz przełączanie awaryjne i aktualizacja dla usługi Azure Managed Redis.

Odporność na błędy przejściowe

Błędy przejściowe to krótkotrwałe, sporadyczne awarie w komponentach. Występują one często w środowisku rozproszonym, takich jak chmura, i są one normalną częścią operacji. Błędy przejściowe naprawiają się po krótkim czasie. Ważne jest, aby aplikacje mogły obsługiwać błędy przejściowe, zwykle ponawiając próby żądań, których dotyczy problem.

Wszystkie aplikacje hostowane w chmurze powinny postępować zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych platformy Azure podczas komunikowania się z dowolnymi interfejsami API hostowanymi w chmurze, bazami danych i innymi składnikami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

Postępuj zgodnie z poniższymi zaleceniami dotyczącymi zarządzania błędami przejściowymi podczas korzystania z usługi Azure Managed Redis:

• Użyj konfiguracji zestawu SDK , które automatycznie ponawiają próby w przypadku wystąpienia przejściowych błędów i używają odpowiednich okresów wycofywania i limitu czasu. Rozważ użycie wzorca ponawiania i wzorca przerywacza w aplikacjach.
• Projektuj wzorce trybu cache-aside, w których aplikacja może nadal działać z obniżoną wydajnością, gdy Redis jest tymczasowo niedostępny, korzystając z podstawowego magazynu danych.

Odporność na błędy strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Wystąpienia usługi Azure Managed Redis Cache mogą być strefowo nadmiarowe, co automatycznie dystrybuuje węzły pamięci podręcznej w wielu strefach dostępności w regionie. Redundancja strefy zmniejsza ryzyko awarii centrum danych lub strefy dostępności, co mogłoby spowodować niedostępność pamięci podręcznej.

Aby zwolnić strefę pamięci podręcznej, należy wdrożyć ją w obsługiwanym regionie i włączyć konfigurację wysokiej dostępności. W regionach bez stref dostępności konfiguracja wysokiej dostępności nadal tworzy co najmniej dwa węzły, ale nie są w oddzielnych strefach.

Na poniższym diagramie przedstawiono pamięć podręczną o strefowej nadmiarowości z dwoma węzłami, z których każdy znajduje się w oddzielnej strefie.

Requirements

• Obsługa regionów: Strefowo nadmiarowe pamięci podręczne Azure Managed Redis Cache można wdrożyć w dowolnym regionie obsługującym strefy dostępności i miejscu, w którym usługa jest dostępna. Aby uzyskać najbardziej aktualną listę regionów obsługujących strefy dostępności, zobacz Regiony platformy Azure ze strefami dostępności. Aby uzyskać listę regionów obsługujących usługę Azure Managed Redis, zobacz Dostępność produktów według regionów.

• Konfiguracja wysokiej dostępności: Należy włączyć konfigurację wysokiej dostępności w pamięci podręcznej, aby była strefowo nadmiarowa.

• Warstwy: Wszystkie warstwy usługi Azure Managed Redis obsługują strefy dostępności.

Koszt

Redundancja strefowa wymaga skonfigurowania pamięci podręcznej pod kątem wysokiej dostępności, co oznacza wdrożenie co najmniej dwóch węzłów. Konfiguracja wysokiej dostępności jest rozliczana z wyższą stawką niż konfiguracja bez wysokiej dostępności. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Managed Redis

Konfiguruj obsługę stref dostępności

• Utwórz nowe wystąpienie z nadmiarowością strefową: Podczas tworzenia nowego wystąpienia usługi Azure Managed Redis, włącz konfigurację wysokiej dostępności i wdrożyć je w regionie ze strefami dostępności. Następnie domyślnie uwzględnia redundancję strefy automatycznie. Nie ma potrzeby wykonywania kolejnej konfiguracji.

  Aby uzyskać szczegółowe instrukcje, zobacz Szybki start: tworzenie wystąpienia usługi Azure Managed Redis.

• Włącz nadmiarowość strefową w istniejącym wystąpieniu: Aby skonfigurować istniejące wystąpienie usługi Azure Managed Redis jako strefowo nadmiarowe, upewnij się, że zostało wdrożone w regionie obsługującym strefy dostępności i włącz wysoką dostępność w pamięci podręcznej.

• Wyłącz nadmiarowość strefy: Nadmiarowość strefy nie może być wyłączona w istniejących wystąpieniach, ponieważ nie można wyłączyć wysokiej dostępności po włączeniu jej w wystąpieniu pamięci podręcznej.

Planowanie pojemności i zarządzanie nimi

Podczas zdarzenia związanego z obniżeniem dostępności strefy, twoje wystąpienie może mieć mniej zasobów dostępnych do obsługi twojego obciążenia. Jeśli twoja instancja jest często pod presją zasobów i musisz przygotować się na awarię strefy dostępności, rozważ jedną z następujących metod:

• Przydziel nadmiarowe zasoby dla instancji: Nadmiarowa aprowizacja polega na wybraniu wyższego poziomu wydajności, niż to konieczne. Dzięki niemu instancja może tolerować pewną utratę pojemności i nadal działać bez obniżonej wydajności. Aby uzyskać więcej informacji na temat zasady naddzielenia zasobów, zobacz Zarządzanie pojemnością przez naddzielenie zasobów (Manage capacity by overprovisioning). Aby dowiedzieć się, jak skalować wystąpienie, zajrzyj do Skalowanie wystąpienia usługi Azure Managed Redis.

• Użyj aktywnej replikacji geograficznej: Możesz wdrożyć wiele wystąpień w różnych regionach i skonfigurować aktywną replikację geograficzną w celu rozłożenia obciążenia między te oddzielne wystąpienia.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy zarządzana pamięć podręczna Redis cache jest strefowo nadmiarowa, a wszystkie strefy dostępności działają:

• Routing ruchu między strefami: Fragmenty są dystrybuowane między węzłami na podstawie polityki klastra. Zasady klastra określają również sposób kierowania ruchu do każdego węzła. Nadmiarowość strefy nie zmienia sposobu kierowania ruchu.

• Replikacja danych między strefami: Shardy są replikowane automatycznie między węzłami w trybie asynchronicznym. Zwykle opóźnienie replikacji między fragmentami jest mierzone w sekundach, ale może się to różnić w zależności od obciążenia pamięci podręcznej, a scenariusze z dużym obciążeniem zapisu i siecią zwykle widzą większe opóźnienie replikacji.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać, gdy zarządzana pamięć podręczna Redis cache jest strefowo nadmiarowa, a co najmniej jedna strefa dostępności jest niedostępna:

• Wykrywanie i reagowanie: Usługa Azure Managed Redis jest odpowiedzialna za wykrywanie awarii w strefie dostępności. Nie musisz nic robić, aby zainicjować tryb failover strefy.

• Powiadomienie: firma Microsoft nie powiadamia cię automatycznie, gdy strefa nie działa. Możesz jednak użyć usługi Azure Service Health , aby zrozumieć ogólną kondycję usługi, w tym wszelkie błędy strefy, i skonfigurować alerty usługi Service Health w celu powiadamiania o problemach.

• Aktywne żądania: Żądania w locie mogą zostać porzucone i należy je ponowić. Aplikacje powinny implementować logikę ponawiania prób w celu obsługi tych tymczasowych przerw.

• Oczekiwana utrata danych: Wszelkie dane, które nie zostały zreplikowane do fragmentów w innej strefie, mogą zostać utracone podczas awarii strefy. Zazwyczaj ilość utraty danych jest mierzona w sekundach, ale zależy od opóźnienia replikacji.

• Oczekiwany przestój: Niewielka ilość przestojów, zazwyczaj 10–15 sekund, może wystąpić podczas przechodzenia fragmentów w tryb failover do węzłów w strefach w dobrej kondycji. Aby uzyskać informacje na temat nieplanowanego procesu failover, zobacz Wyjaśnienie failover. Podczas projektowania aplikacji i postępuj zgodnie z praktykami dotyczącymi obsługi błędów przejściowych.

• Przekierowywanie ruchu: Usługa Azure Managed Redis automatycznie przekierowuje ruch do węzłów w strefach w dobrej kondycji.

Odzyskiwanie strefy

Po odzyskaniu strefy dostępności, której dotyczy problem, usługa Azure Managed Redis automatycznie przywraca operacje do tej strefy. Platforma Azure w pełni zarządza tym procesem i nie wymaga żadnej interwencji klienta.

Testowanie pod kątem niepowodzeń strefy

Ponieważ usługa Azure Managed Redis w pełni zarządza routingiem ruchu, trybem failover i przywracaniem funkcji po awarii strefy, nie musisz weryfikować procesów awarii strefy dostępności ani udostępniać żadnych dalszych danych wejściowych.

Odporność na awarie całego regionu

Usługa Azure Managed Redis zapewnia natywną obsługę wielu regionów za pośrednictwem aktywnej replikacji geograficznej, co umożliwia łączenie wielu wystąpień usługi Azure Managed Redis w różnych regionach świadczenia usługi Azure w jednej grupie replikacji. Następnie można skonfigurować własne podejście do trybu failover między wystąpieniami.

Aktywna replikacja geograficzna

Korzystając z aktywnej replikacji geograficznej, aplikacje mogą odczytywać i zapisywać w dowolnym wystąpieniu pamięci podręcznej w grupie, a zmiany są automatycznie synchronizowane we wszystkich regionach. Usługa obsługuje wzorce replikacji typu aktywne-aktywne, w których każdy region może obsługiwać operacje odczytu i pisania jednocześnie. Gdy konflikty występują z powodu współbieżnych zapisów w różnych regionach, usługa automatycznie rozwiązuje je przy użyciu wstępnie określonych algorytmów rozwiązywania konfliktów bez konieczności ręcznej interwencji. Takie podejście zapewnia odporność na awarie regionów przy zachowaniu dostępu o małych opóźnieniach dla aplikacji rozproszonych globalnie.

Na poniższym diagramie przedstawiono dwa wystąpienia pamięci podręcznej w różnych regionach w ramach tej samej aktywnej grupy replikacji geograficznej z aplikacjami klienckimi, które łączą się z każdym wystąpieniem pamięci podręcznej:

pl-PL: Odpowiadasz za konfigurowanie aplikacji klienckich, aby w przypadku awarii dowolnego wystąpienia regionalnego przekierować żądania do działającego wystąpienia. Na poniższym diagramie pokazano, jak aplikacja może przekierowywać swoje żądania do zdrowego wystąpienia pamięci podręcznej, gdy wystąpienie, z którego zwykle korzysta, ulega awarii.

Requirements

• Obsługa regionów Aktywna replikacja geograficzna usługi Azure Managed Redis można skonfigurować między dowolnymi regionami świadczenia usługi Azure, w których jest dostępna usługa.

• Konfiguracja wystąpienia: Aktywna replikacja geograficzna wymaga wystąpień usługi Azure Managed Redis tej samej warstwy i rozmiaru we wszystkich uczestniczących regionach. Wszystkie instancje pamięci podręcznej w grupie replikacji muszą być skonfigurowane z identycznymi ustawieniami, w tym opcjami trwałości, modułami i zasadami klastrowania.

• Inne wymagania: Wystąpienia pamięci podręcznej muszą spełniać inne wymagania, w tym te dotyczące używanych modułów, co wpływa na sposób, w jaki można je skalować. Aby uzyskać więcej informacji, zobacz Wymagania wstępne aktywnej replikacji geograficznej.

Rozważania

• Odpowiedzialność za failover: W przypadku korzystania z aktywnej replikacji geograficznej, odpowiadasz za failover między wystąpieniami pamięci podręcznej. Należy przygotować i skonfigurować aplikację do obsługi trybu failover. Tryb failover obejmuje przygotowanie i może wymagać wykonania wielu kroków. Aby uzyskać więcej informacji, zobacz Force-unlink w przypadku przerwy w działaniu regionu.

• Spójność ostateczna: Aplikacje powinny być zaprojektowane tak, aby obsługiwały scenariusze spójności ostatecznej, ponieważ propagowanie zmian we wszystkich regionach może zająć trochę czasu w zależności od warunków sieciowych i odległości geograficznej. Podczas przestojów w regionie może wystąpić więcej niespójności danych do czasu przywrócenia łączności i zakończenia synchronizacji.

Koszt

Po włączeniu aktywnej replikacji geograficznej są naliczane opłaty za każde wystąpienie usługi Azure Managed Redis w każdym regionie w grupie replikacji. Ponadto mogą być naliczane opłaty za transfer danych w związku z ruchem związanym z replikacją między regionami. Aby uzyskać więcej informacji na temat cen, zobacz Cennik usługi Azure Managed Redis i Szczegóły cennika przepustowości.

Konfigurowanie obsługi wielu regionów

• Utwórz nowe wystąpienie zreplikowanej geograficznie pamięci podręcznej: skonfiguruj aktywną replikację geograficzną podczas aprowizacji pamięci podręcznej, określając grupę replikacji i łącząc wiele wystąpień. Aby uzyskać więcej informacji, zobacz Tworzenie lub dołączanie aktywnej grupy replikacji geograficznej.

• Włącz istniejące wystąpienie pamięci podręcznej na potrzeby replikacji geograficznej: możesz dodać istniejące wystąpienie pamięci podręcznej do aktywnej grupy replikacji geograficznej.

  Jednak po dodaniu istniejącego wystąpienia do aktywnej grupy replikacji geograficznej dane w wystąpieniu muszą zostać opróżnione i występuje niewielki przestój. Jeśli to możliwe, zaplanuj włączenie aktywnej replikacji geograficznej podczas tworzenia instancji pamięci podręcznej.

  Aby uzyskać więcej informacji, zobacz Dodaj istniejące wystąpienie do aktywnej grupy replikacji geograficznej.

• Wyłącz replikację geograficzną w wystąpieniu pamięci podręcznej: usuń wystąpienie z grupy replikacji geograficznej, usuwając wystąpienie pamięci podręcznej. Pozostałe wystąpienia automatycznie ponownie konfigurują się.

Planowanie pojemności i zarządzanie nimi

Podczas zdarzenia w dół regionu inne wystąpienia mogą być pod większą presją. Jeśli wystąpienie często cierpi na niedobór zasobów i musisz się przygotować do zwiększonego zapotrzebowania na zasoby podczas awarii regionu, rozważ nadmiarowe zasoby dla wystąpienia. Aby dowiedzieć się, jak skalować wystąpienie, zobacz Skalowanie wystąpienia usługi Azure Managed Redis.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy wystąpienia są skonfigurowane do korzystania z aktywnej replikacji geograficznej, a wszystkie regiony działają.

• Routing ruchu między regionami: Jesteś odpowiedzialny za konfigurowanie aplikacji w celu połączenia z określoną instancją pamięci podręcznej. Aplikacje mogą łączyć się z dowolną instancją pamięci podręcznej w grupie replikacji i wykonywać operacje odczytu oraz zapisu. Routing ruchu jest obsługiwany przez aplikację, co umożliwia kierowanie klientów do najbliższego regionu w celu uzyskania minimalnych opóźnień. Usługa Azure Managed Redis nie zapewnia automatycznego routingu ruchu między regionami.

• Replikacja danych między regionami: usługa używa replikacji asynchronicznej między regionami w celu zachowania spójności ostatecznej. Operacje zapisu są natychmiast zatwierdzane w regionie lokalnym, a następnie w tle systemu propagowane do innych regionów. Typy danych replikowanych bez konfliktów (CRDT) zapewniają automatyczne scalanie współbieżnych zapisów w różnych regionach.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać, gdy wystąpienia są skonfigurowane do korzystania z aktywnej replikacji geograficznej i występuje awaria w jednym regionie:

• Wykrywanie i reagowanie: odpowiadasz za wykrywanie awarii wystąpienia pamięci podręcznej i podejmowanie decyzji o tym, kiedy należy przejść w tryb failover. Można monitorować stan klastra z replikacją geograficzną, co może pomóc w podjęciu decyzji o rozpoczęciu procedury failover. Aby uzyskać więcej informacji, zobacz Metryka replikacji geograficznej.

  Przejście w tryb failover wymaga wykonania wielu kroków. Aby uzyskać więcej szczegółów, zobacz Force-unlink jeśli wystąpi awaria regionu.

• Powiadomienie: Firma Microsoft nie powiadamia cię automatycznie, gdy region nie działa. Możesz jednak użyć usługi Azure Service Health , aby zrozumieć ogólną kondycję usługi, w tym wszelkie awarie regionów, i skonfigurować alerty usługi Service Health w celu powiadamiania o problemach.

  Można również monitorować kondycję każdego wystąpienia.

  Aby monitorować kondycję relacji replikacji geograficznej, możesz użyć metryki Replikacja geograficzna w dobrej kondycji . Metryka zawsze ma wartość 1 (w dobrej kondycji) lub 0 (w złej kondycji). Możesz skonfigurować alerty usługi Azure Monitor dla tej metryki, aby zrozumieć, kiedy wystąpienia mogą nie być zsynchronizowane.

• Aktywne żądania: żądania do regionu zakończonego niepowodzeniem są przerywane i muszą być obsługiwane przez logikę trybu failover aplikacji. Aplikacje powinny implementować zasady ponawiania prób, które mogą przekierowywać ruch do zdrowych pamięci podręcznych.

• Oczekiwana utrata danych: ze względu na asynchroniczną replikację między regionami niektóre ostatnie zapisy w regionie, które uległy awarii, mogą zostać utracone, jeśli nie zostały jeszcze zreplikowane do innych regionów. Ilość potencjalnej utraty danych zależy od opóźnienia replikacji w momencie awarii. Aby uzyskać więcej informacji, zobacz Active-Active rozproszony geograficznie Redis i zagadnienia dotyczące spójności i utraty danych w przypadku awarii regionalnej CRDB.

• Oczekiwany przestój: czas przestoju aplikacji potrzebny tylko do wykrycia awarii i przekierowania ruchu do regionów w dobrej kondycji. Zazwyczaj obejmuje to od kilku sekund do kilku minut, w zależności od sposobu skonfigurowania kontroli kondycji aplikacji i konfiguracji trybu failover.

• Przekierowywanie ruchu: odpowiadasz za implementowanie logiki w aplikacjach w celu wykrywania awarii regionów i kierowania ruchu do regionów w dobrej kondycji. Można to osiągnąć za pomocą kontroli kondycji, wzorców wyłączników przeciążenia lub rozwiązań do równoważenia obciążenia zewnętrznego.

Odzyskiwanie regionów

Po odzyskaniu regionu, w którym wystąpił błąd, usługa Azure Managed Redis automatycznie ponownie integruje wystąpienia w tym regionie z aktywną grupą replikacji geograficznej bez konieczności interwencji użytkownika. Usługa automatycznie synchronizuje dane z instancji w dobrej kondycji. W trakcie tego procesu odzyskane wystąpienie stopniowo nadrabia zaległości związane ze zmianami, które zaszły podczas awarii. Po zakończeniu synchronizacji odzyskane wystąpienia stają się w pełni aktywne i mogą obsługiwać operacje odczytu i zapisu.

Jesteś odpowiedzialny za ponowne skonfigurowanie aplikacji w celu przekierowania ruchu z powrotem do przywróconej instancji regionu.

Testowanie pod kątem błędów regionów

Należy regularnie testować procedury obsługi awarii aplikacji. Ważne jest, aby aplikacja mogła przechodzić w tryb awaryjny między instancjami i jednocześnie spełniać wymagania biznesowe dotyczące dopuszczalnych przestojów. Ważne jest również, aby przetestować ogólne procesy odpowiedzi, w tym wszelkie ponowne konfiguracje zapór i innej infrastruktury oraz proces odzyskiwania.

Odporność usługi na prace konserwacyjne

Usługa Azure Managed Redis wykonuje regularne uaktualnienia usług i inne zadania konserwacji.

Gdy trwa konserwacja, usługa Azure Managed Redis automatycznie wykonuje tworzenie nowych węzłów i automatycznie wykonuje tryb failover. Aplikacje klienckie mogą widzieć przerwy w połączeniu i inne błędy przejściowe. Aplikacje powinny implementować logikę ponawiania prób w celu obsługi tych tymczasowych przerw.

Aby dowiedzieć się więcej na temat procesów konserwacji usługi Azure Managed Redis, zobacz Tryb failover i stosowanie poprawek dla usługi Azure Managed Redis.

Tworzenie kopii zapasowej i przywracanie

Usługa Azure Managed Redis zapewnia zarówno trwałość danych, jak i możliwości tworzenia kopii zapasowych w celu ochrony przed scenariuszami utraty danych, których inne funkcje niezawodności mogą nie dotyczyć. Kopie zapasowe mogą zapewnić ochronę przed scenariuszami, takimi jak uszkodzenie danych, przypadkowe usunięcie lub błędy konfiguracji.

• Trwałość danych: Domyślnie usługa Azure Managed Redis przechowuje wszystkie dane pamięci podręcznej w pamięci. Opcjonalnie można zapisywać migawki danych na dysku przy użyciu trwałości danych. Jeśli wystąpi awaria sprzętowa, która ma wpływ na węzeł, usługa Azure Managed Redis automatycznie przywraca dane. Istnieją różne typy trwałości danych, z których można wybrać różne kompromisy między częstotliwością migawek a wpływem wydajności na pamięć podręczną.

  Nie można jednak przywrócić plików danych do innego wystąpienia i nie można uzyskać dostępu do plików. Trwałość danych nie chroni przed uszkodzeniem lub przypadkowym usunięciem danych.

• Importowanie i eksportowanie: Usługa Azure Managed Redis obsługuje tworzenie kopii zapasowych danych przy użyciu funkcji importowania i eksportowania, która zapisuje pliki kopii zapasowej w usłudze Azure Blob Storage. Można skonfigurować magazyn geograficznie nadmiarowy na swoim koncie usługi Azure Storage lub skopiować bądź przenieść bloby obiektów kopii zapasowej do innych lokalizacji w celu dalszej ochrony.

  Wyeksportowane pliki można przywrócić do tego samego wystąpienia pamięci podręcznej lub innego wystąpienia pamięci podręcznej.

  Nie ma wbudowanego harmonogramu importu lub eksportu, ale możesz opracowywać własne procesy automatyzacji, które używają interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell do inicjowania operacji eksportowania.

Umowa dotycząca poziomu usług

Umowa dotycząca poziomu usług (SLA) dla usług platformy Azure opisuje oczekiwaną dostępność każdej usługi oraz warunki, które rozwiązanie musi spełnić, aby osiągnąć te oczekiwania dotyczące dostępności. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące usług online.

Umowa SLA dla usługi Azure Managed Redis obejmuje łączność z punktami końcowymi pamięci podręcznej. Umowa SLA nie obejmuje ochrony przed utratą danych.

Aby kwalifikować się do umów SLA dotyczących dostępności dla usługi Azure Managed Redis:

• Należy włączyć konfigurację wysokiej dostępności.
• Nie można zainicjować żadnych funkcji produktu ani działań zarządczych, które zostały udokumentowane jako powodujące tymczasową niedostępność.

Umowy SLA o wyższej dostępności mają zastosowanie, gdy wystąpienie jest strefowo nadmiarowe. W niektórych warstwach można kwalifikować się do umowy SLA o wyższej dostępności, jeśli wdrożono wystąpienia strefowo nadmiarowe w co najmniej trzech regionach przy użyciu aktywnej replikacji geograficznej.