Dostępność bazy danych jest jednym z najważniejszych aspektów architektury aplikacji. Chociaż zapobieganie przestojom w centrum danych jest oczywiste, w końcu stanie się to dla każdego. Nawet najlepiej zarządzane centra danych od czasu do czasu ulegną całkowitej awarii. Na przykład awarie Amazon AWS w dniach 26.08.13 i 13.09.13. Ważnym pytaniem, które należy zadać, jest to, czy jest to akceptowalne dla twojej aplikacji? Większość aplikacji może tolerować pewne przestoje od czasu do czasu, jednak niektóre aplikacje wymagają prawie 100% czasu działania, a architektura baz danych tych aplikacji wymaga bardziej przemyślanego podejścia do projektowania. Opóźnienia między centrami danych są zwykle dość duże, dlatego należy dokładnie przemyśleć projekt wdrożenia hostingu MongoDB.
Cele dostępności MongoDB
- Twoja baza danych powinna działać i umożliwiać zapis, nawet jeśli całe centrum danych ulegnie awarii.
- Przełączanie awaryjne bazy danych powinno być automatyczne w przypadku awarii serwera/centrum danych.
- Awaria pojedynczego serwera nie powinna spowodować przełączenia podstawowego do innego centrum danych.
Projekt centrum danych
Aby spełnić nasze cele, opracowaliśmy trzy projekty centrów danych z wykorzystaniem zestawu replik 4+1:
- Centrum danych 1: Podstawowy (priorytet 10), drugorzędny 0 (główny 9)
- Centrum danych 2: Wtórny 1 (priorytet 8), Wtórny 2 (priorytet 7)
- Centrum danych 3: Arbiter
Umieszczamy dwóch pełnoprawnych członków w każdym z pierwszych dwóch centrów danych i arbitra w trzecim centrum danych. Skonfigurowaliśmy również priorytet dla każdego serwera, dzięki czemu możemy kontrolować, który członek staje się głównym w przypadku awarii serwera.
Jest kilka wad tego geo- architektura rozproszona:
- Jeśli masz aplikację wymagającą intensywnego zapisu, serwery pomocnicze w innym centrum danych zawsze będą opóźnione ze względu na większe opóźnienia. Jeśli niektóre dane są kluczowe, możesz użyć problemu zapisu MongoDB „Większość”, aby upewnić się, że wszystkie węzły zatwierdzą dane.
- Kompilacje społeczności MongoDB nie mają włączonej obsługi SSL. Możesz chcieć stworzyć kompilację z włączonym SSL lub użyć MongoDB DBaaS w ScaleGrid, aby dane przepływające przez regiony były szyfrowane.
Dostępność Amazon AWS/EC2
Jeśli wdrażasz MongoDB w AWS, każde centrum danych na tym zdjęciu odpowiada regionowi Amazon, a nie strefie dostępności. Amazon nie daje gwarancji dostępności w jednej strefie dostępności, SLA dotyczą całego regionu. Jeśli wdrażasz w strefach dostępności, Twoja umowa SLA wynosi 99,95%, co nadal jest świetną umową SLA – jednak, jeśli cały region ulegnie awarii, Twoja baza danych ulegnie awarii. Ponadto niektóre regiony AWS mają tylko dwie strefy dostępności, więc szczególną uwagę należy zwrócić na umieszczenie trzeciego węzła w innym regionie, aby przestój w jednym regionie nie spowodował awarii całej bazy danych.
Dostępność o niższych kosztach w różnych regionach geograficznych
Prostsza wersja tej samej architektury wykorzystuje tylko trzy serwery i umieszcza tylko jedną replikę w każdym centrum danych. Wadą tego podejścia jest to, że awaria pojedynczego serwera spowoduje, że serwer podstawowy będzie przemieszczał się między centrami danych. Jednak ta architektura kosztuje mniej niż pierwsza architektura. W zależności od scenariusza może Ci się to udać.
Istnieje wiele sposobów na osiągnięcie wysokiego czasu pracy bez przestojów dzięki MongoDB, a to tylko sposób, który spełnia nasze potrzeby. Jeśli masz inne ciekawe architektury, napisz do nas na adres [email protected]. Chętnie poznamy Twoje przemyślenia!
