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 również zastępowanie konfiguracji w zależności od konkretnych 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 ze względu na rozproszoną architekturę i architekturę bez masterless — każdy węzeł w bazie danych może zapewnić dokładnie takie same funkcje jak każdy inny węzeł — przyczyniając 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 odzyskiwania i cel czasu odzyskiwania
Cel punktu odzyskiwania (cel punktu odzyskiwania) i cel czasu odzyskiwania (cel czasu odzyskiwania) będzie zwykle niski (blisko zera) dla usługi Apache Cassandra, o ile:
- Wdrożenie obejmujące wiele regionów z replikacją między regionami i współczynnik replikacji 3.
- Włączone strefy dostępności (wybierz opcję podczas tworzenia klastra w portalu lub za pośrednictwem interfejsu wiersza polecenia platformy Azure).
- Skonfigurowano tryb failover na poziomie aplikacji przy użyciu zasad równoważenia obciążenia w sterowniku klienta i/lub trybie failover na poziomie równoważenia obciążenia przy użyciu usługi Traffic Manager/azure front door.
Cel czasu odzyskiwania ("jak długo nie działa awaria"), będzie niski, ponieważ klaster będzie domyślnie odporny na awarie w obu strefach i regionach, a sam serwer Apache Cassandra jest wysoce odpornym na uszkodzenia systemem bezserwerowym (wszystkie węzły mogą zapisywać). Cel punktu odzyskiwania ("ilość danych, które można utracić w awarii"), będzie niski, ponieważ dane zostaną zsynchronizowane między wszystkimi węzłami i centrami danych, więc utrata danych w awarii będzie minimalna.
Uwaga
Teoretycznie nie można osiągnąć wartości RTO=0 i RPO=0 na twierdzenie cap. Należy ocenić kompromis między spójnością a dostępnością/optymalną wydajnością — będzie to wyglądać inaczej dla każdej aplikacji. Jeśli na przykład aplikacja jest duża liczba operacji odczytu, lepszym rozwiązaniem może być większe opóźnienie operacji zapisu między regionami w celu uniknięcia utraty danych (faworyzowanie spójności). Jeśli aplikacja jest duża, a budżet na duże opóźnienia, ryzyko utraty niektórych najnowszych zapisów w dużej regionalnej awarii może być akceptowalne (faworyzowanie dostępności).
Strefy dostępności
Architektura bezserwerowa rozwiązania Cassandra zapewnia odporność na uszkodzenia od podstaw, a wystąpienie zarządzane platformy Azure dla systemu Apache Cassandra zapewnia obsługę stref dostępności w wybranych regionach w celu zwiększenia odporności na poziomie infrastruktury. Biorąc pod uwagę współczynnik replikacji 3, obsługa strefy dostępności zapewnia, że każda replika znajduje się w innej strefie dostępności, uniemożliwiając w ten sposób awarię strefową przed wpływem bazy danych/aplikacji. Zalecamy włączenie stref dostępności tam, gdzie to możliwe.
Nadmiarowość w wielu regionach
Architektura rozwiązania Cassandra w połączeniu z obsługą stref dostępności platformy Azure zapewnia pewien poziom odporności na uszkodzenia i odporność. Ważne jest jednak, aby wziąć pod uwagę wpływ regionalnych awarii aplikacji. Zdecydowanie zalecamy wdrożenie klastrów z wieloma regionami w celu ochrony przed awariami na poziomie regionu. Chociaż są rzadkie, potencjalny wpływ jest poważny.
W przypadku ciągłości działania nie wystarczy, aby baza danych była w wielu regionach. Inne części aplikacji muszą być również wdrażane w ten sam sposób przez dystrybucję lub przy użyciu odpowiednich mechanizmów przełączania w tryb failover. Jeśli użytkownicy są rozproszeni w wielu lokalizacjach geograficznych, wdrożenie wieloregionowego centrum danych dla bazy danych ma dodatkową zaletę zmniejszenia opóźnienia, ponieważ wszystkie węzły we wszystkich centrach danych w klastrze mogą obsługiwać zarówno odczyty, jak i zapisy z regionu, który jest najbliżej nich. Jeśli jednak aplikacja jest skonfigurowana jako "aktywna-aktywna", należy rozważyć, w jaki sposób twierdzenie CAP ma zastosowanie do spójności danych między replikami (węzłami) i kompromisami wymaganymi do dostarczania wysokiej dostępności.
W warunkach twierdzenia CAP system bazy danych Cassandra jest domyślnie systemem bazy danych AP (dostępnym odpornym na partycje) o wysokiej spójności z możliwością dostosowania. W większości przypadków użycia zalecamy używanie local_quorum do odczytu.
- W przypadku zapisów 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 KWORUM jest dobrym kompromisem. Należy jednak pamiętać, że w przypadku awarii regionalnej niektóre zapisy mogą zostać utracone w LOCAL_QUORUM.
- W przypadku równoległego uruchamiania aplikacji QUORUM_EACH zapisy są preferowane w większości przypadków w celu zapewnienia spójności między dwoma centrami danych.
- Jeśli twoim celem jest faworyzowanie spójności (niższego celu punktu odzyskiwania), a nie opóźnienia lub dostępności (niższe celu punktu odzyskiwania), powinno to być odzwierciedlone w ustawieniach spójności i współczynniku replikacji. Jako reguła kciuka liczba węzłów kworum wymaganych dla odczytu i 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 zostanie wdrożony tylko w jednym regionie (region wybrany podczas początkowego 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. Nie ma to wpływu na umowę SLA dostępności usługi, ponieważ centra danych powinny nadal działać. Jednak w tym okresie może nie być możliwe wprowadzenie zmian w konfiguracji bazy danych z poziomu portalu lub narzędzi dostawcy zasobów.
Replikacja
Zalecamy inspekcję keyspaces i ich ustawienia replikacji od czasu do czasu, aby upewnić się, że skonfigurowano wymaganą replikację między centrami danych. We wczesnych etapach programowania zalecamy przetestowanie, czy wszystko działa zgodnie z oczekiwaniami, wykonując proste testy przy użyciu polecenia cqlsh. Na przykład wstawienie wartości połączonej z jednym centrum danych i odczytanie jej z drugiej.
W szczególności podczas konfigurowania drugiego centrum danych, w którym istniejące centrum danych ma już dane, ważne jest, aby ustalić, czy wszystkie dane zostały zreplikowane, a system jest gotowy. Zalecamy monitorowanie postępu replikacji za pomocą naszych poleceń administratora bazy danych za pomocą nodetool netstatspolecenia . Alternatywną metodą jest zliczanie wierszy w każdej tabeli, ale należy pamiętać, że w przypadku rozmiarów danych big data ze względu na rozproszony charakter bazy danych Cassandra może to dać 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, aby aplikacja mogła natychmiast przejść w tryb failover do "gorącego rezerwowego" centrum danych w regionie pomocniczym. Gwarantuje to brak obniżenia wydajności w przypadku awarii regionalnej. Większość sterowników klienta cassandra udostępnia opcje inicjowania trybu failover na poziomie aplikacji. Domyślnie zakładają awarię regionalną oznacza, że aplikacja również nie działa, w takim przypadku przejście w tryb failover powinno nastąpić na poziomie modułu równoważenia obciążenia.
Jednak aby zmniejszyć koszt aprowizacji drugiego centrum danych, możesz wolisz wdrożyć mniejszą jednostkę SKU i mniej węzłów w regionie pomocniczym. W przypadku wystąpienia awarii skalowanie w górę jest łatwiejsze w usłudze Azure Managed Instance dla usługi Apache Cassandra dzięki gotowej do użycia skalowaniu w pionie i w poziomie. Podczas przechodzenia 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. W takim przypadku pomocnicze centrum danych działa jako niższe koszty rezerwy ciepłej. Biorąc to podejście, należy zrównoważyć czas wymagany do przywrócenia systemu do pełnej pojemności w przypadku awarii. 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 górę. Należy pamiętać o tym, biorąc pod uwagę równowagę 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 bazy danych Apache Cassandra, ale 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 się zdarzyć w dowolnym momencie w przypadku rozwiązania Cassandra i zależy 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, a nawet jeśli były, odzyskanie bazy danych z kopii zapasowych może zająć bardzo dużo czasu. W związku z tym zdecydowanie zalecamy wdrożenia w wielu regionach, w połączeniu z włączaniem stref dostępności tam, gdzie to możliwe, w celu ograniczenia ryzyka w scenariuszach awarii i umożliwienia skutecznego odzyskiwania po nich. Jest to szczególnie ważne w rzadkich scenariuszach, w których nie można uwzględnić regionu, w którym bez replikacji obejmującej wiele regionów wszystkie dane mogą zostać utracone.
Następne kroki
W tym artykule przedstawiono najlepsze rozwiązania dotyczące tworzenia odpornych aplikacji za pomocą rozwiązania Cassandra.