Udostępnij za pośrednictwem

Tryb failover i stosowanie poprawek dla usługi Azure Managed Redis (wersja zapoznawcza)

  • Artykuł

Aby tworzyć odporne i pomyślne aplikacje klienckie, ważne jest zrozumienie trybu failover w usłudze Azure Managed Redis (wersja zapoznawcza). Tryb failover może być częścią planowanych operacji zarządzania lub może być spowodowany przez nieplanowane awarie sprzętu lub sieci. Typowym zastosowaniem trybu failover pamięci podręcznej jest zastosowanie, gdy usługa zarządzania poprawia pliki binarne usługi Azure Managed Redis.

W tym artykule znajdują się następujące informacje:

  • Co to jest tryb failover?
  • Jak odbywa się tryb failover podczas stosowania poprawek.
  • Jak utworzyć odporną aplikację kliencką.

Co to jest tryb failover?

Zacznijmy od omówienia trybu failover dla usługi Azure Managed Redis.

Krótkie podsumowanie architektury pamięci podręcznej

Diagram przedstawiający architekturę oferty Azure Managed Redis.

Pamięć podręczna jest tworzona z wielu maszyn wirtualnych z oddzielnymi i prywatnymi adresami IP. Każda maszyna wirtualna (lub "węzeł") uruchamia wiele procesów serwera Redis (nazywanych "fragmentami") równolegle. Wiele fragmentów umożliwia bardziej wydajne wykorzystanie procesorów wirtualnych na każdej maszynie wirtualnej i wyższą wydajność. Nie wszystkie podstawowe fragmenty usługi Redis znajdują się na tej samej maszynie wirtualnej/węźle. Zamiast tego fragmenty podstawowe i repliki są rozproszone w obu węzłach. Ponieważ podstawowe fragmenty korzystają z większej liczby zasobów procesora NIŻ fragmenty repliki, takie podejście umożliwia równoległe uruchamianie większej liczby podstawowych fragmentów. Każdy węzeł ma proces serwera proxy o wysokiej wydajności do zarządzania fragmentami, obsługi zarządzania połączeniami i wyzwalania samonaprawiania. Jeden fragment może być wyłączony, podczas gdy pozostałe pozostają dostępne.

Szczegółowe informacje na temat architektury usługi Azure Managed Redis można znaleźć tutaj.

Wyjaśnienie trybu failover

Tryb failover występuje, gdy co najmniej jeden fragment repliki promuje się, aby stać się podstawowymi fragmentami, a stare fragmenty podstawowe zamykają istniejące połączenia. Przejście w tryb failover może być planowane lub nieplanowane.

Planowane przejście w tryb failover odbywa się w dwóch różnych okresach:

  • Aktualizacje systemu, takie jak poprawki usługi Redis lub uaktualnienia systemu operacyjnego.
  • Operacje zarządzania, takie jak skalowanie i ponowne uruchamianie.

Ponieważ węzły otrzymują powiadomienie o aktualizacji z wyprzedzeniem, mogą wspólnie zamieniać role i szybko aktualizować moduł równoważenia obciążenia zmiany. Planowane przejście w tryb failover zwykle kończy się w mniej niż 1 sekundę.

Nieplanowane przejście w tryb failover może wystąpić z powodu awarii sprzętu, awarii sieci lub innych nieoczekiwanych awarii co najmniej jednego węzła w klastrze. Fragmenty repliki w pozostałych węzłach będą podwyższać poziom do podstawowego w celu zachowania dostępności, ale proces trwa dłużej. Fragment repliki musi najpierw wykryć, że jego podstawowy fragment nie jest dostępny, zanim będzie mógł rozpocząć proces pracy w trybie failover. Fragment repliki musi również sprawdzić, czy ten nieplanowany błąd nie jest przejściowy ani lokalny, aby uniknąć niepotrzebnego przejścia w tryb failover. To opóźnienie w wykrywaniu oznacza, że nieplanowane przejście w tryb failover zwykle kończy się w ciągu 10 do 15 sekund.

Jak występuje stosowanie poprawek?

Usługa Azure Managed Redis regularnie aktualizuje pamięć podręczną za pomocą najnowszych funkcji i poprawek platformy. Aby zastosować poprawkę pamięci podręcznej, usługa wykonuje następujące kroki:

  1. Usługa tworzy nowe aktualne maszyny wirtualne, aby zastąpić wszystkie poprawki maszyn wirtualnych.
  2. Następnie promuje jedną z nowych maszyn wirtualnych jako lidera klastra.
  3. Jeden po drugim, wszystkie węzły, które są poprawiane, są usuwane z klastra. Wszystkie fragmenty tych maszyn wirtualnych zostaną zdegradowane i zmigrowane do jednej z nowych maszyn wirtualnych.
  4. Na koniec wszystkie zastąpione maszyny wirtualne zostaną usunięte.

Każdy fragment klastrowanej pamięci podręcznej jest poprawiany oddzielnie i nie zamyka połączeń z innym fragmentem.

Wiele pamięci podręcznych w tej samej grupie zasobów i regionie jest również poprawianych pojedynczo. Pamięci podręczne, które znajdują się w różnych grupach zasobów lub w różnych regionach, mogą być poprawiane jednocześnie.

Ponieważ pełna synchronizacja danych odbywa się przed powtórzeniu procesu, utrata danych jest mało prawdopodobna dla pamięci podręcznej. Możesz dodatkowo chronić przed utratą danych, eksportując dane i włączając trwałość.

Dodatkowe ładowanie pamięci podręcznej

Za każdym razem, gdy nastąpi przejście w tryb failover, pamięci podręczne muszą replikować dane z jednego węzła do drugiego. Ta replikacja powoduje wzrost obciążenia zarówno pamięci serwera, jak i procesora CPU. Jeśli wystąpienie pamięci podręcznej jest już mocno załadowane, aplikacje klienckie mogą mieć zwiększone opóźnienie. W skrajnych przypadkach aplikacje klienckie mogą otrzymywać wyjątki przekroczenia limitu czasu.

Jak tryb failover wpływa na moją aplikację kliencką?

Aplikacje klienckie mogą otrzymywać błędy z wystąpienia usługi Azure Managed Redis. Liczba błędów widocznych przez aplikację kliencką zależy od liczby operacji oczekujących na to połączenie w czasie przejścia w tryb failover. Każde połączenie kierowane przez węzeł, który zamknął jego połączenia, widzi błędy.

Wiele bibliotek klienckich może zgłaszać różne typy błędów w przypadku przerwania połączeń, w tym:

  • Wyjątki przekroczenia limitu czasu
  • Wyjątki połączeń
  • Wyjątki gniazd

Liczba i typ wyjątków zależą od tego, gdzie żądanie znajduje się w ścieżce kodu, gdy pamięć podręczna zamyka jego połączenia. Na przykład operacja, która wysyła żądanie, ale nie otrzymała odpowiedzi, gdy nastąpi przejście w tryb failover, może uzyskać wyjątek przekroczenia limitu czasu. Nowe żądania w obiekcie zamkniętego połączenia odbierają wyjątki połączeń do momentu pomyślnego ponownego nawiązania połączenia.

Większość bibliotek klienckich próbuje ponownie nawiązać połączenie z pamięcią podręczną, jeśli są one skonfigurowane do tego celu. Jednak nieprzewidziane usterki mogą czasami umieszczać obiekty biblioteki w stanie nieodwracalnym. Jeśli błędy będą się powtarzać przez dłuższy niż wstępnie skonfigurowany czas, obiekt połączenia powinien zostać ponownie utworzony. W Microsoft.NET i innych językach obiektowych ponowne tworzenie połączenia bez ponownego uruchamiania aplikacji można wykonać przy użyciu wzorca ForceReconnect.

Jakie aktualizacje są objęte konserwacją?

Konserwacja obejmuje następujące aktualizacje:

  • Aktualizacje serwera Redis: każda aktualizacja lub poprawka plików binarnych serwera Redis.
  • Aktualizacje maszyny wirtualnej: wszystkie aktualizacje maszyny wirtualnej hostująca usługę Redis. Aktualizacje maszyn wirtualnych obejmują stosowanie poprawek składników oprogramowania w środowisku hostingu w celu uaktualniania składników sieciowych lub likwidowania.

Czy konserwacja jest wyświetlana w kondycji usługi w witrynie Azure Portal przed poprawką?

Nie, konserwacja nie jest wyświetlana w obszarze kondycji usługi w portalu ani w żadnym innym miejscu.

Zmiany konfiguracji sieci klienta

Niektóre zmiany konfiguracji sieci po stronie klienta mogą wyzwalać brak dostępnych błędów połączenia. Takie zmiany mogą obejmować:

  • Zamiana wirtualnego adresu IP aplikacji klienckiej między miejscami przejściowymi i produkcyjnymi.
  • Skalowanie rozmiaru lub liczby wystąpień aplikacji.

Takie zmiany mogą powodować problem z łącznością, który zwykle trwa mniej niż minutę. Aplikacja kliencka prawdopodobnie utraci połączenie z innymi zasobami sieci zewnętrznej, ale także z usługą Azure Managed Redis.

Kompilowanie w odporności

Nie można całkowicie uniknąć przechodzenia w tryb failover. Zamiast tego napisz aplikacje klienckie, aby były odporne na przerwy połączeń i żądania, które zakończyły się niepowodzeniem. Większość bibliotek klienckich automatycznie łączy się ponownie z punktem końcowym pamięci podręcznej, ale niewiele z nich próbuje ponowić nieudane żądania. W zależności od scenariusza aplikacji warto użyć logiki ponawiania prób z wycofywaniem.

Jak mogę uczynić moją aplikację odporną?

Zapoznaj się z tymi wzorcami projektowymi, aby utworzyć odpornych klientów, zwłaszcza wyłącznik i wzorce ponawiania prób:

Powiązana zawartość