Udostępnij za pośrednictwem

Tryb failover i poprawianie — Azure Cache for Redis

  • Artykuł

Aby tworzyć odporne i pomyślne aplikacje klienckie, ważne jest zrozumienie trybu failover w usłudze Azure Cache for Redis. 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 Cache for 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 Cache for Redis.

Krótkie podsumowanie architektury pamięci podręcznej

Pamięć podręczna jest tworzona z wielu maszyn wirtualnych z oddzielnymi i prywatnymi adresami IP. Każda maszyna wirtualna, znana również jako węzeł, jest połączona z udostępnionym modułem równoważenia obciążenia z pojedynczym wirtualnym adresem IP. Każdy węzeł uruchamia proces serwera Redis i jest dostępny przy użyciu nazwy hosta i portów usługi Redis. Każdy węzeł jest uważany za węzeł podstawowy lub węzeł repliki. Gdy aplikacja kliencka łączy się z pamięcią podręczną, ruch przechodzi przez ten moduł równoważenia obciążenia i jest automatycznie kierowany do węzła podstawowego.

W podstawowej pamięci podręcznej pojedynczy węzeł jest zawsze podstawowym węzłem. W pamięci podręcznej w warstwie Standardowa lub Premium istnieją dwa węzły: jeden jest wybierany jako podstawowy, a drugi to replika. Ponieważ pamięci podręczne w warstwie Standardowa i Premium mają wiele węzłów, jeden węzeł może być niedostępny, podczas gdy drugi nadal przetwarza żądania. Klastrowane pamięci podręczne składają się z wielu fragmentów, z których każdy ma różne węzły podstawowe i repliki. Jeden fragment może być wyłączony, podczas gdy pozostałe pozostają dostępne.

Uwaga

Podstawowa pamięć podręczna nie ma wielu węzłów i nie oferuje umowy dotyczącej poziomu usług (SLA) dla jej dostępności. Pamięci podręczne w warstwie Podstawowa są zalecane tylko do celów programistycznych i testowych. Aby zwiększyć dostępność, użyj pamięci podręcznej w warstwie Standardowa lub Premium dla wdrożenia z wieloma węzłami.

Wyjaśnienie trybu failover

Przejście w tryb failover następuje, gdy węzeł repliki podwyższa poziom do węzła podstawowego, a stary węzeł podstawowy zamyka istniejące połączenia. Po utworzeniu kopii zapasowej węzła podstawowego zauważy zmianę ról i obniża się, aby stać się repliką. Następnie łączy się z nowym podstawowym i synchronizuje dane. 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ę.

Nieplanowana praca w trybie failover może wystąpić z powodu awarii sprzętu, awarii sieci lub innych nieoczekiwanych awarii węzła podstawowego. Węzeł repliki jest podwyższany do poziomu podstawowego, ale proces trwa dłużej. Węzeł repliki musi najpierw wykryć, że jego węzeł podstawowy nie jest dostępny, zanim będzie mógł rozpocząć proces pracy w trybie failover. Węzeł 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 Cache for Redis regularnie aktualizuje pamięć podręczną przy użyciu najnowszych funkcji i poprawek platformy. Aby zastosować poprawkę pamięci podręcznej, usługa wykonuje następujące kroki:

  1. Usługa najpierw poprawia węzeł repliki.
  2. Replika poprawna kooperacyjnie promuje się do podstawowej. Ta promocja jest traktowana jako planowana praca w trybie failover.
  3. Były węzeł podstawowy jest ponownie uruchamiany, aby wprowadzić nowe zmiany i jest zwracany jako węzeł repliki.
  4. Węzeł repliki łączy się z węzłem podstawowym i synchronizuje dane.
  5. Po zakończeniu synchronizacji danych proces stosowania poprawek jest powtarzany dla pozostałych węzłów.

Ponieważ stosowanie poprawek jest zaplanowanym trybem failover, węzeł repliki szybko promuje się jako podstawowy. Następnie węzeł rozpoczyna obsługę żądań i nowych połączeń. Pamięci podręczne w warstwie Podstawowa nie mają węzła repliki i są niedostępne do czasu ukończenia aktualizacji. Każdy fragment klastrowanej pamięci podręcznej jest poprawiany oddzielnie i nie zamyka połączeń z innym fragmentem.

Ważne

Węzły są poprawiane pojedynczo, aby zapobiec utracie danych. Pamięci podręczne w warstwie Podstawowa będą miały utratę danych. Bufory klastrowane są poprawiane po jednym fragmentie naraz.

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 w przypadku korzystania z pamięci podręcznej w warstwie Standardowa lub Premium. 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 w warstwie Standardowa i Premium 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. Aby zapobiec wpływowi większego obciążenia, skonfiguruj ustawienie pamięci podręcznej maxmemory-reserved .

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

Aplikacje klienckie mogą otrzymywać błędy z usługi Azure Cache for 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łączenie ion
  • 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.

Czy mogę otrzymywać powiadomienia z wyprzedzeniem o konserwacji?

Usługa Azure Cache for Redis publikuje powiadomienia o konserwacji środowiska uruchomieniowego w kanale publikowania/subskrybowania (pub/sub) o nazwie AzureRedisEvents. Wiele popularnych bibliotek klienckich usługi Redis obsługuje subskrybowanie kanałów pub/sub. Odbieranie powiadomień z kanału AzureRedisEvents jest zwykle prostym dodatkiem do aplikacji klienckiej. Aby uzyskać więcej informacji na temat zdarzeń konserwacji, zobacz AzureRedisEvents.

Uwaga

Kanał AzureRedisEvents nie jest mechanizmem, który może powiadomić Cię o dniach lub godzinach z wyprzedzeniem. Kanał może powiadamiać klientów o wszelkich nadchodzących zdarzeniach konserwacji serwera, które mogą mieć wpływ na dostępność serwera. AzureRedisEvents jest dostępna tylko dla warstw Podstawowa, Standardowa i Premium.

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 żadnym miejscu w obszarze kondycji usługi w portalu ani w żadnym innym miejscu.

Ile czasu mogę uzyskać powiadomienie przed planowaną konserwacją?

W przypadku korzystania z kanału AzureRedisEvents otrzymasz powiadomienie o 15 minutach przed konserwacją.

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 Cache for 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:

Aby przetestować odporność aplikacji klienckiej, użyj ponownego uruchomienia jako wyzwalacza ręcznego w przypadku przerw w połączeniach.

Ponadto zalecamy użycie zaplanowanych aktualizacji do wybrania kanału aktualizacji i okna obsługi pamięci podręcznej w celu zastosowania poprawek środowiska uruchomieniowego Redis w określonych cotygodniowych oknach. Te okna są zazwyczaj okresami, gdy ruch aplikacji klienckiej jest niski, aby uniknąć potencjalnych zdarzeń. Aby uzyskać więcej informacji, zobacz Aktualizowanie kanału i planowanie aktualizacji.

Aby uzyskać więcej informacji, zobacz odporność Połączenie ion.

Powiązana zawartość