Udostępnij za pomocą

Przechodzenie w tryb failover i stosowanie poprawek dla usługi Azure Cache for Redis

  • Dotyczy: ✅ Azure Cache for Redis

Ważne

Usługa Azure Cache for Redis ogłosiła harmonogram wycofania wszystkich SKU. Zalecamy przeniesienie istniejących wystąpień usługi Azure Cache for Redis do usługi Azure Managed Redis tak szybko, jak to możliwe.

Aby uzyskać więcej informacji na temat przejścia na emeryturę:

Aby tworzyć odporne i pomyślne aplikacje klienckie, ważne jest zrozumienie trybu failover w usłudze Azure Cache for Redis. Przełączanie awaryjne może być częścią planowanych operacji zarządzania lub może wynikać z nieplanowanych awarii sprzętu lub sieci. Typowym zastosowaniem trybu failover pamięci podręcznej jest to, gdy usługa zarządzania aktualizuje pliki binarne usługi Azure Cache for Redis.

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

  • Czym jest failover?
  • Jak przebiega proces awaryjnego przełączania podczas stosowania poprawek.
  • Jak utworzyć odporną aplikację kliencką.

Czym jest 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 podstawowy. W pamięci podręcznej Standardowej lub Premium są dwa węzły: jeden jest wybierany jako główny, a drugi jako 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 / Notatka

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 podstawowe są zalecane tylko do celów deweloperskich i testowych. Aby zwiększyć dostępność, użyj pamięci podręcznej Standard lub Premium dla wdrożenia z wieloma węzłami.

Wyjaśnienie trybu "failover"

Przejście do trybu awaryjnego (failover) następuje, gdy węzeł repliki awansuje się do roli węzła podstawowego, a poprzedni węzeł podstawowy zamyka istniejące połączenia. Gdy węzeł podstawowy wraca do działania, zauważa zmianę ról i obniża się, zostając repliką. Następnie łączy się z nowym węzłem głównym 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 zaktualizować równoważnik obciążenia, aby odzwierciedlić zmianę. 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 awansuje do roli 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 także zweryfikować, czy ten nieplanowany błąd nie jest tymczasowy 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 aktualizuje węzeł repliki jako pierwszy.
  2. Replika naprawiona współpracując awansuje do roli głównej. Ta promocja jest traktowana jako planowane przełączenie awaryjne.
  3. Były węzeł podstawowy jest ponownie uruchamiany, aby uwzględnić nowe zmiany i powraca jako węzeł replikacji.
  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 procesem przełączania awaryjnego, węzeł repliki szybko staje się węzłem podstawowym. Następnie węzeł rozpoczyna obsługę żądań i nowych połączeń. Podstawowe pamięci podręczne nie mają węzła replikacyjnego 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. Podstawowe pamięci podręczne będą powodować utratę danych. Bufory klastrowane są zmieniane po jednym fragmencie naraz.

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

Ponieważ pełna synchronizacja danych odbywa się przed powtórzeniem procesu, utrata danych jest mało prawdopodobna w przypadku korzystania z pamięci podręcznej typu Standard 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ż silnie obciążone, aplikacje klienckie mogą doświadczyć zwiększonego opóźnienia. W skrajnych przypadkach aplikacje klienckie mogą napotykać wyjątki czasowe. 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ął swoje połączenia, doświadcza błędów.

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 socketów

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 napotykają wyjątki, aż do pomyślnego przywrócenia 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 utworzenie połączenia bez ponownego uruchomienia 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 / Notatka

Kanał AzureRedisEvents nie jest mechanizmem, który może powiadomić Cię z kilkudniowym lub kilkugodzinnym 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 utrzymaniem?

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ą poprawki składników oprogramowania w środowisku hostującym, aktualizację składników sieciowych lub ich likwidację.

Czy konserwacja jest wyświetlana w stanie usługi w portalu Azure przed poprawką?

Nie, utrzymanie nie jest wyświetlane w sekcji stanu usługi w portalu ani nigdzie indziej.

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

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

Zmiany konfiguracji sieci klienta

Niektóre zmiany konfiguracji sieci po stronie klienta mogą wyzwalać błędy Brak dostępnego połączenia. Takie zmiany mogą obejmować:

  • Zamiana wirtualnego adresu IP aplikacji klienckiej między środowiskiem testowym a produkcyjnym.
  • 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.

Wbudować odporność

Nie można całkowicie uniknąć failoveru. 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ę zapewnić odporność aplikacji?

Zapoznaj się z tymi wzorcami projektowymi, aby utworzyć odporne aplikacje klienckie, szczególnie wzorce wyłącznika obwodu i 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żywanie zaplanowanych aktualizacji, aby wybrać kanał aktualizacji oraz ustalić okno konserwacji dla pamięci podręcznej, aby zastosować poprawki środowiska uruchomieniowego Redis w określonych cotygodniowych ramach czasowych. 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łączenia.

Treści powiązane

  • Last updated on