Niezawodność w usłudze Azure Managed Redis

Azure Managed Redis to w pełni zarządzana usługa platformy Azure oparta na usłudze Redis Enterprise. Zapewnia ona magazyn danych w pamięci o wysokiej wydajności dla aplikacji i jest przeznaczony 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, jak zapewnić odporność usługi Azure Managed Redis na różne potencjalne awarie i problemy, w tym przejściowe błędy, awarie stref dostępności i awarie regionów. Opisuje 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:

• Użyj wysokiej dostępności, która wdraża wiele węzłów dla pamięci podręcznej.

• Nadmiarowość strefy umożliwia wdrożenie pamięci podręcznej o wysokiej dostępności w regionie, w którym są strefy dostępności.

• Rozważ zaimplementowanie aktywnej replikacji geograficznej dla obciążeń o krytycznym znaczeniu, które wymagają przejścia w tryb failover między regionami.

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

Jeśli planujesz odporność w usłudze Azure Managed Redis, musisz zrozumieć kluczowe pojęcia dotyczące 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 tworzy wystąpienia, monitoruje ich zdrowie i zastępuje te, które stają się niezdatne do użytku. Ten zestaw maszyn wirtualnych tworzy klaster.

  Możesz skonfigurować swoje wystąpienie pod kątem wysokiej dostępności. W przypadku korzystania z wysokiej dostępności usługa Azure Managed Redis gwarantuje, że wystąpienie ma co najmniej dwa węzły i automatycznie replikuje dane pomiędzy nimi. W regionach, w których istnieją strefy dostępności, usługa umieszcza węzły w różnych strefach dostępności. Aby uzyskać więcej informacji, zobacz Odporność na błędy strefy dostępności.

  Usługa abstrahuje określoną liczbę węzłów w każdej konfiguracji, aby uniknąć złożoności i zapewnić optymalne konfiguracje.

• Fragmenty: Każdy węzeł uruchamia wiele procesów serwera Redis, znanych jako fragmenty. Każdy shard zarządza podzbiorem danych pamięci podręcznej. Po ustawieniu pamięci podręcznej 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 ponowią próbę w przypadku wystąpienia przejściowych błędów i zastosuj odpowiednie okresy wycofywania i limitu czasu. Rozważ użycie wzorca ponawiania i wzorca przerywacza w aplikacjach.

• Zaprojektuj wzorce cache-aside, w których aplikacja może nadal działać z obniżoną wydajnością, wracając do podstawowego magazynu danych, gdy Redis tymczasowo stanie się niedostępny.

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.

Możesz uczynić wystąpienia usługi Azure Managed Redis Cache strefowo nadmiarowymi, co spowoduje automatyczne rozproszenie węzłów pamięci podręcznej w wielu strefach dostępności w ramach jednego regionu. Redundancja strefy zmniejsza ryzyko, że awaria centrum danych lub strefy dostępności uczyni pamięć podręczną niedostępną.

Aby zapewnić redundancję strefy pamięci podręcznej, należy wdrożyć ją w obsługiwanym regionie i skonfigurować w trybie 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ą one umieszczane w oddzielnych strefach.

Na poniższym diagramie przedstawiono strefowo nadmiarową pamięć podręczną z dwoma węzłami, z których każda jest w oddzielnej strefie.

Diagram przedstawiający wystąpienie usługi Azure Managed Redis o wysokiej dostępności w dwóch strefach dostępności. Sekcja wystąpienia usługi Azure Managed Redis obejmuje wszystkie trzy strefy. Strefy 1 i 2 mają jeden węzeł, a strefa 3 nie ma węzłów.

Requirements

• Obsługa regionów: Strefowo nadmiarowe pamięci podręczne Azure Managed Redis można wdrożyć w dowolnym regionie, który obsługuje strefy dostępności i w którym usługa jest dostępna. Aby uzyskać 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: Aby pamięć podręczna była strefowo nadmiarowa, należy zastosować konfigurację wysokiej dostępności.

• 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 poprzez wdrożenie co najmniej dwóch węzłów. Konfiguracja wysokiej dostępności kosztuje więcej 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 strefowo nadmiarowe. Podczas tworzenia nowego wystąpienia usługi Azure Managed Redis, skorzystaj z konfiguracji wysokiej dostępności i wdroż je w regionie, który obsługuje strefy dostępności. Wystąpienie domyślnie zawiera nadmiarowość strefową bez potrzeby dodatkowej konfiguracji.

  Aby uzyskać więcej informacji, zobacz Tworzenie instancji Azure Managed Redis.

• Spraw, aby istniejąca strefa wystąpienia była redundantna. Aby uczynić istniejącą instancję Azure Managed Redis odporną na awarie strefowe, wdroż ją w regionie obsługującym strefy dostępności i skonfiguruj wysoką dostępność dla pamięci podręcznej.

• Wyłącz strefową nadmiarowość. Nie można wyłączyć strefowej nadmiarowości w istniejących wystąpieniach, ponieważ nie można cofnąć wysokiej dostępności po jej zastosowaniu do 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 często napotyka obciążenie zasobów oraz musisz przygotować się na ewentualną awarię strefy dostępności, rozważ jedno z następujących podejść:

• Zaprojektuj wystąpienie z nadwyżką zasobów. Wybierz warstwę wydajności wyższą niż wymagana, aby instancja mogła tolerować utratę pojemności i nadal działać bez obniżonej wydajności. Aby uzyskać więcej informacji, zobacz Zarządzanie pojemnością przez nadmierne przydzielanie zasobów i Skalowanie wystąpienia 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ą normalnie:

• Trasowanie ruchu między strefami: Usługa Azure Managed Redis dystrybuuje fragmenty pomiędzy węzłami, opierając się na zasadach klastra. Zasady klastra określają również sposób kierowania ruchu do każdego węzła. Redundancja strefowa nie zmienia sposobu prowadzenia ruchu przez usługę.

• Replikacja danych między strefami: Usługa Azure Managed Redis automatycznie replikuje fragmenty między węzłami przy użyciu replikacji asynchronicznej. Zwykle mierzysz opóźnienie replikacji między fragmentami w sekundach, ale dokładny czas trwania zależy od obciążenia pamięci podręcznej. Scenariusze z dużym obciążeniem zapisem i siecią zwykle mają większe opóźnienie replikacji.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać, gdy zarządzana pamięć podręczna Redis jest strefowo nadmiarowa, a co najmniej jedna strefa dostępności stanie się 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: Usługa może utracić żądania w trakcie realizacji, a aplikacje powinny 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. Zwykle mierzy się ilość utraty danych w sekundach, ale zależy od opóźnienia replikacji.

• Oczekiwany przestój: Podczas przełączania fragmentów na inne węzły w zdrowych strefach może wystąpić niewielki przestój, zazwyczaj od 10 do 15 sekund. Aby uzyskać więcej informacji na temat nieplanowanego przejścia w tryb failover, zobacz Wyjaśnienie przejścia w tryb failover. Podczas projektowania aplikacji postępuj zgodnie z rozwiązaniami 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

Usługa Azure Managed Redis w pełni zarządza routingiem ruchu, trybem failover i powrotem po awarii strefy, dzięki czemu nie trzeba 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, która umożliwia łączenie wielu wystąpień usługi Azure Managed Redis w różnych regionach świadczenia usługi Azure w jednej grupie replikacji. Możesz wtedy skonfigurować własny mechanizm przełączania awaryjnego między wystąpieniami.

Aktywna replikacja geograficzna

W przypadku korzystania 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 je rozwiązuje 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 wraz z aplikacjami klienckimi, które łączą się z każdym wystąpieniem pamięci podręcznej.

Diagram przedstawiający dwa wystąpienia usługi Azure Managed Redis w różnych regionach w ramach tej samej aktywnej grupy replikacji geograficznej. Oba regiony zawierają wystąpienie usługi Azure Managed Redis i łączą się do sekcji aplikacji oznaczonej za pomocą strzałki. Replikacja asynchroniczna łączy dwa wystąpienia pamięci podręcznej dwukierunkowo.

Odpowiadasz za skonfigurowanie aplikacji klienckich w celu przekierowania żądań do zdrowego wystąpienia, jeśli jakiekolwiek wystąpienie regionalne ulegnie awarii. Na poniższym diagramie pokazano, jak aplikacja może przekierowywać żądania do wystąpienia pamięci podręcznej w dobrej kondycji, gdy wystąpienie, którego zwykle używa, kończy się niepowodzeniem.

Diagram przedstawiający dwa wystąpienia usługi Azure Managed Redis w różnych regionach w ramach tej samej aktywnej grupy replikacji geograficznej. Czerwony X w regionie A wskazuje błąd. Aplikacja w regionie A oraz w regionie B łączą się z wystąpieniem usługi Azure Managed Redis w regionie B.

Requirements

• Obsługa regionów: Możesz skonfigurować aktywną replikację geograficzną usługi Azure Managed Redis 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, które używają tej samej warstwy i rozmiaru w każdym regionie uczestniczącym. Wszystkie wystąpienia pamięci podręcznej w grupie replikacji muszą używać identycznych ustawień, w tym opcji trwałości, modułów i zasad klastrowania.

• Inne wymagania: Wystąpienia pamięci podręcznej muszą spełniać inne wymagania, w tym moduły, które używasz. Te wymagania mają wpływ na sposób skalowania instancji pamięci podręcznej. 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. Przygotuj aplikację do obsługi trybu failover. Proces failover wymaga przygotowania i może wiązać się z koniecznością wykonania wielu kroków. Aby uzyskać więcej informacji, zobacz Wymuszone rozłączenie podczas awarii regionu.

• Spójność ostateczna: Projektowanie aplikacji do obsługi scenariuszy 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 awarii regionów może wystąpić więcej niespójności danych do momentu przywrócenia łączności i zakończenia synchronizacji.

Koszt

Podczas konfigurowania aktywnej replikacji geograficznej płacisz za każde wystąpienie usługi Azure Managed Redis w każdym regionie w grupie replikacji. Mogą być również naliczane opłaty za transfer danych z tytułu ruchu replikacji między różnymi regionami. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Managed Redis i Szczegóły cennika przepustowości.

Konfigurowanie obsługi wielu regionów

• Utwórz nowe wystąpienie geograficznie zreplikowanej 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.

• Dodaj istniejące wystąpienie pamięci podręcznej do grupy replikacji geograficznej. Istniejące wystąpienie pamięci podręcznej można dodać do aktywnej grupy replikacji geograficznej.

  Po dodaniu istniejącego wystąpienia do aktywnej grupy replikacji geograficznej platforma musi wyczyścić dane w wystąpieniu, a Ty możesz doświadczyć niewielkiego przestoju. Jeśli to możliwe, zaplanuj skonfigurowanie 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ń instancję z grupy replikacji geograficznej, usuwając instancję pamięci podręcznej. Pozostałe instancje automatycznie dostosowują ustawienia.

Planowanie pojemności i zarządzanie nimi

Podczas zdarzenia w dół regionu inne wystąpienia mogą mieć większe obciążenie. Jeśli instancja często działa blisko swoich limitów zasobów i musisz przygotować się na zwiększone wymagania pojemności podczas awarii regionu, rozważ nadmiarowe przydzielenie zasobów dla instancji. Aby uzyskać więcej informacji, 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ć podczas konfigurowania wystąpień w celu korzystania z aktywnej replikacji geograficznej, a wszystkie regiony działają normalnie.

• Routing ruchu między regionami: Jesteś odpowiedzialny za skonfigurowanie aplikacji w celu nawiązania 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. Aplikacja obsługuje routing ruchu, który umożliwia kierowanie klientów do najbliższego regionu w celu uzyskania minimalnego opóźnienia. Usługa Azure Managed Redis nie kieruje automatycznie 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. Natychmiast zatwierdza operacje zapisu w lokalnym regionie, a następnie propaguje je w tle do innych regionów. Typy danych replikowanych bez konfliktów (CRDT) zapewniają, że usługa automatycznie scala współbieżne zapisy w różnych regionach.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać podczas konfigurowania wystąpień w celu korzystania z aktywnej replikacji geograficznej w przypadku awarii w jednym regionie.

• Wykrywanie i reagowanie: Odpowiadasz za wykrywanie awarii instancji pamięci podręcznej i podejmowanie decyzji o przełączeniu awaryjnym. Stan klastra replikowanego geograficznie można monitorować, co może pomóc w podjęciu decyzji o rozpoczęciu przełączenia awaryjnego. Aby uzyskać więcej informacji, zobacz Metryka replikacji geograficznej.

  Przejście w tryb failover wymaga wykonania wielu kroków. Aby uzyskać więcej informacji, zobacz Wymuszone rozłączenie podczas awarii 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ć stan relacji replikacji geograficznej, użyj metryki kondycji replikacji geograficznej. Metryka zawsze ma wartość 1 (w dobrej kondycji) lub 0 (w złej kondycji). Skonfiguruj alerty usługi Azure Monitor dla tej metryki, aby określić, kiedy wystąpienia mogą nie być zsynchronizowane.

• Aktywne żądania: Usługa kończy żądania do regionu zakończonego niepowodzeniem, a logika trybu failover aplikacji musi je obsługiwać. Aplikacje powinny implementować zasady ponawiania prób, które mogą przekierowywać ruch do zdrowych pamięci podręcznych.

• Oczekiwana utrata danych: Replikacja asynchroniczna między regionami może spowodować utratę ostatnich zapisów w regionie, w którym wystąpił błąd, jeśli te operacje zapisu nie zostały zreplikowane w innych regionach. Ilość potencjalnej utraty danych zależy od opóźnienia replikacji w momencie awarii. Aby uzyskać więcej informacji, zobacz Active-active geo-distributed Redis i Zagadnienia dotyczące spójności i utraty danych w bazie danych replikowanej bez konfliktów (CRDB) w przypadku awarii regionalnej.

• Oczekiwany przestój: Aplikacje doświadczają przestoju tylko przez czas potrzebny do wykrycia awarii i przekierowania ruchu do sprawnych regionów. Ten przestój zazwyczaj waha się od sekund do kilku minut i zależy od sposobu konfigurowania 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. Tę logikę można zaimplementować za pomocą kontroli kondycji, wzorców wyłącznika 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 do aktywnej grupy replikacji geograficznej bez interwencji użytkownika. Usługa automatycznie synchronizuje dane ze zdrowych wystąpień. Podczas tego procesu odzyskane wystąpienia stopniowo synchronizują zmiany, które wystąpił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

Regularnie testuj procedury "failover" aplikacji. Aplikacja musi mieć możliwość przełączania w tryb failover między wystąpieniami i spełniać wymagania biznesowe dotyczące przestojów podczas przejścia. Przetestuj również 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 obsługuje regularne uaktualnienia usług i inne zadania konserwacji.

Podczas konserwacji usługa Azure Managed Redis automatycznie tworzy nowe węzły i przełącza się. Aplikacje klienckie mogą napotkać 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 uzyskać więcej informacji na temat procesów konserwacji dla Azure Managed Redis, zobacz Failover oraz aktualizacje dla 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 chronią 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. Usługa może opcjonalnie zapisywać migawki danych na dysku przy użyciu trwałości danych. Jeśli awaria sprzętowa wpłynie na węzeł, usługa Azure Managed Redis automatycznie przywraca dane. Możesz wybrać spośród różnych typów trwałości danych, które zapewniają różne kompromisy między częstotliwością migawek a wpływem wydajności na pamięć podręczną.

  Nie można 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 podczas korzystania z funkcji importowania i eksportowania, która zapisuje pliki kopii zapasowej w usłudze Azure Blob Storage. Georedundantną pamięć masową (GRS) można skonfigurować na koncie usługi Azure Storage w obsługiwanych regionach lub skopiować bądź przenieść obiekty blob kopii zapasowej do innych lokalizacji, aby zapewnić dodatkową ochronę.

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

  Usługa nie obejmuje wbudowanego harmonogramu importu lub eksportu, ale możesz opracować własne procesy automatyzacji, które używają interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell do uruchamiania 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. Nie obejmuje ochrony przed utratą danych.

Aby kwalifikować się do umów SLA dotyczących dostępności dla usługi Azure Managed Redis, musisz spełnić następujące wymagania:

• Należy użyć konfiguracji 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 nadmiarowe w strefie. W niektórych warstwach można uzyskać dostęp do umowy SLA o wyższej dostępności podczas wdrażania wystąpień strefowo nadmiarowych w co najmniej trzech regionach przy użyciu aktywnej replikacji geograficznej.

Treści powiązane

• Niezawodność na platformie Azure