Udostępnij za pośrednictwem

Najlepsze rozwiązania dotyczące wysokiej dostępności i odzyskiwania po awarii

Azure Managed Instance for Apache Cassandra to w pełni zarządzana usługa dla czystych klastrów Apache Cassandra typu open source. Usługa umożliwia zastępowanie konfiguracji w zależności od potrzeb każdego obciążenia, co pozwala na maksymalną elastyczność i kontrolę w razie potrzeby.

Apache Cassandra to doskonały wybór do tworzenia wysoce odpornych aplikacji dzięki jej rozproszonej charakterystyce i architekturze równorzędnej. Każdy węzeł w bazie danych może zapewnić taką samą funkcjonalność jak każdy inny węzeł. Ten projekt przyczynia się do niezawodności i odporności bazy danych Cassandra. Ten artykuł zawiera wskazówki dotyczące optymalizacji wysokiej dostępności i podejścia do odzyskiwania po awarii.

Cel punktu przywracania i cel czasu przywracania

Jeśli masz następujące elementy, cel punktu odzyskiwania (RPO) i cel czasu odzyskiwania (RTO) są zwykle niskie, zbliżone do zera:

RTO to czas, w którym system jest nieaktywny podczas awarii. Jest ona niska, ponieważ klaster jest odporny zarówno w strefach, jak i regionach. Ponadto sam system Apache Cassandra to wysoce odporny na uszkodzenia system peer-to-peer, w którym wszystkie węzły mogą domyślnie wykonywać operacje zapisu.

RPO to ilość danych, które można utracić w razie awarii. Jest niska, ponieważ dane są synchronizowane między wszystkimi węzłami i centrami danych. Utrata danych w awarii byłaby minimalna.

Uwaga

Nie jest możliwe osiągnięcie jednocześnie RTO=0 i RPO=0 zgodnie z twierdzeniem CAP. Oceń kompromis między spójnością a dostępnością lub optymalną wydajnością.

Ta równowaga wygląda inaczej dla każdej aplikacji. Na przykład, jeśli twoja aplikacja intensywnie przeprowadza operacje odczytu, lepszym rozwiązaniem może być zaakceptowanie zwiększonego opóźnienia przy operacjach zapisu między regionami w celu uniknięcia utraty danych, co sprzyja spójności. Jeśli aplikacja charakteryzuje się dużym obciążeniem zapisem i ma rygorystyczne wymagania dotyczące opóźnień, ryzyko utraty części najnowszych zapisów podczas poważnej awarii regionalnej może być akceptowalne, co sprzyja dostępności.

Strefy dostępności

Architektura peer-to-peer platformy Cassandra zapewnia odporność na uszkodzenia od podstaw. Wystąpienie zarządzane platformy Azure dla usługi Apache Cassandra zapewnia obsługę stref dostępności w wybranych regionach. Ta obsługa zwiększa odporność na poziomie infrastruktury. W przypadku współczynnika replikacji 3 obsługa strefy dostępności zapewnia, że każda replika znajduje się w innej strefie dostępności. Takie podejście zapobiega sytuacji, w której awaria strefowa wpływa na bazę danych lub aplikację. Zalecamy włączenie stref dostępności tam, gdzie to możliwe.

Nadmiarowość w wielu regionach

Architektura Cassandry w połączeniu z obsługą stref dostępności platformy Azure zapewnia poziom tolerancji błędów i odporności. Należy również wziąć pod uwagę wpływ regionalnych awarii aplikacji. Aby zapewnić ochronę przed awariami na poziomie regionu, zdecydowanie zalecamy wdrożenie wielu klastrów regionów. Chociaż są rzadkie, potencjalny wpływ jest poważny.

W przypadku ciągłości działania nie wystarczy użyć bazy danych w wielu regionach. Inne części aplikacji również muszą być dystrybuowane lub mieć odpowiednie mechanizmy przełączania w tryb awaryjny. Jeśli użytkownicy są rozproszeni w wielu lokalizacjach geograficznych, wdrożenie wielu regionów centrum danych dla bazy danych ma dodatkową zaletę zmniejszenia opóźnienia. Wszystkie węzły we wszystkich centrach danych w klastrze mogą obsługiwać odczyty i zapisy z regionu, który jest najbliżej nich.

Jeśli aplikacja jest skonfigurowana jako aktywna-aktywna, rozważ, jak twierdzenie CAP wpływa na spójność danych między replikami (węzłami) oraz jakie kompromisy są konieczne, aby zapewnić wysoką dostępność.

W terminologii twierdzenia CAP system Cassandra jest domyślnie systemem bazy danych dostępnym i odpornym na podziały (AP), z możliwością dostrajania spójności. W większości przypadków użycia zalecamy używanie LOCAL_QUORUM do odczytów.

  • W przypadku operacji zapisu aktywny-pasywny występuje kompromis między niezawodnością a wydajnością. W przypadku niezawodności zalecamy QUORUM_EACH, ale dla większości użytkowników LOCAL_QUORUM lub QUORUM jest dobrym kompromisem. Jeśli wystąpi awaria regionalna, niektóre zapisy mogą zostać utracone w LOCAL_QUORUM.

  • Jeśli aplikacja działa równolegle, preferuj zapisy QUORUM_EACH dla większości przypadków, aby zapewnić spójność między dwoma centrami danych.

  • Jeśli twoim celem jest faworyzowanie spójności lub niższego RPO, a nie opóźnienia lub dostępności lub niższego RTO, ustawienia spójności i współczynnik replikacji powinny to odzwierciedlać.

    Ogólnie rzecz biorąc, liczba węzłów kworum wymaganych dla odczytu oraz liczba węzłów kworum wymaganych do zapisu powinna być większa niż współczynnik replikacji. Jeśli na przykład masz współczynnik replikacji równy 3, a quorum_one odczytów (jeden węzeł), należy wykonać quorum_all na zapisach (trzech węzłach), aby suma 4 jest większa niż współczynnik replikacji wynoszący 3.

Uwaga

Operator płaszczyzny sterowania dla usługi Azure Managed Instance dla usługi Apache Cassandra jest wdrażany tylko w jednym regionie. Region jest wybrany podczas wdrażania pierwszego centrum danych. W mało prawdopodobnym przypadku całkowitej awarii regionu zobowiązujemy się do 3-godzinnego czasu odzyskiwania w celu przełączenia płaszczyzny sterowania w tryb failover do innego regionu.

Ponieważ centra danych powinny nadal działać, ten problem nie ma wpływu na umowę SLA dotyczącą dostępności usługi. W tym okresie może nie być możliwe wprowadzenie zmian w konfiguracji bazy danych z witryny Azure Portal lub narzędzi dostawcy zasobów.

Replikacja

Zalecamy przeprowadzanie inspekcji keyspaces i ich ustawień replikacji od czasu do czasu, aby upewnić się, że skonfigurowano wymaganą replikację między centrami danych. We wczesnych etapach programowania zalecamy wykonanie prostych testów przy użyciu polecenia cqlsh. Na przykład wstaw wartość połączoną z jednym centrum danych i odczytaj ją z drugiego.

W szczególności podczas konfigurowania drugiego centrum danych, w którym istniejące centrum danych ma już dane, należy określić, czy wszystkie dane zostały zreplikowane i czy system jest gotowy. Zalecamy monitorowanie postępu replikacji za pomocą poleceń administratora bazy danych za pomocą nodetool netstatspolecenia . Alternatywną metodą jest zliczenie wierszy w każdej tabeli. Należy pamiętać, że w przypadku rozmiarów danych big data ze względu na rozproszony charakter bazy danych Cassandra takie podejście może zapewnić jedynie przybliżone oszacowanie.

Równoważenie kosztów odzyskiwania po awarii

Jeśli aplikacja jest aktywna-pasywna, nadal zalecamy wdrożenie tej samej pojemności w każdym regionie. Takie podejście ułatwia natychmiastowe przełączenie aplikacji w tryb failover do aktywnego centrum danych rezerwowego w regionie zapasowym. Jeśli wystąpi awaria regionalna, takie podejście nie gwarantuje obniżenia wydajności. Większość sterowników klienta cassandra udostępnia opcje inicjowania trybu failover na poziomie aplikacji. Domyślnie zakładają, że awaria regionalna oznacza, że aplikacja również przestaje działać, więc przełączenie awaryjne powinno nastąpić na poziomie modułu równoważenia obciążenia.

Aby zmniejszyć koszt aprowizacji drugiego centrum danych, możesz chcieć wdrożyć mniejszą jednostkę SKU i mniej węzłów w regionie pomocniczym. Gdy wystąpi awaria, kluczowe skalowanie w pionie i poziomie ułatwia skalowanie w górę w usłudze Azure Managed Instance dla usługi Apache Cassandra. Podczas przełączania aplikacji w tryb failover do regionu pomocniczego można ręcznie skalować w poziomie i skalować węzły w górę w pomocniczym centrum danych. Twoje zapasowe centrum danych działa jako gorącą rezerwę niższym kosztem. Biorąc to podejście, należy zrównoważyć czas wymagany do przywrócenia systemu do pełnej pojemności, jeśli wystąpi awaria. Ważne jest, aby przetestować i przećwiczyć, co się stanie, gdy region zostanie utracony.

Uwaga

Skalowanie węzłów w górę jest znacznie szybsze niż skalowanie w dół. Należy to mieć na uwadze podczas rozważania równowagi między skalowaniem pionowym i poziomym oraz liczbą węzłów do wdrożenia w klastrze.

Harmonogramy tworzenia kopii zapasowych

Kopie zapasowe są automatyczne w usłudze Azure Managed Instance dla systemu Apache Cassandra. Możesz wybrać własny harmonogram codziennych kopii zapasowych. Zalecamy wybranie czasu z mniejszym obciążeniem. Chociaż kopie zapasowe są skonfigurowane tak, aby zużywały tylko bezczynne procesory CPU, mogą w pewnych okolicznościach wyzwalać kompaktowanie w systemie Cassandra, co może prowadzić do wzrostu użycia procesora CPU. Kompaktowanie może zachodzić w dowolnym momencie w Cassandra. Zależą one od obciążenia i wybranej strategii kompaktowania.

Ważne

Celem tworzenia kopii zapasowych jest wyłącznie ograniczenie przypadkowej utraty danych lub uszkodzenia danych. Nie zalecamy tworzenia kopii zapasowych jako strategii odzyskiwania po awarii.

Kopie zapasowe nie są geograficznie nadmiarowe. Nawet jeśli tak było, odzyskanie bazy danych z kopii zapasowych może zająć dużo czasu. W związku z tym zdecydowanie zalecamy wdrożenie w wielu regionach, w połączeniu z aktywacją stref dostępności tam, gdzie to możliwe, w celu łagodzenia skutków w sytuacjach katastrof i z możliwością skutecznego odzyskiwania. Takie podejście jest szczególnie ważne w rzadkich scenariuszach, w których nie można odzyskać regionu, który zakończył się niepowodzeniem. Bez replikacji obejmującej wiele regionów wszystkie dane mogą zostać utracone.

Zrzut ekranu przedstawiający stronę konfiguracji harmonogramu tworzenia kopii zapasowych.

Następny krok

Tworzenie klastra przy użyciu witryny Azure Portal