Główne cele konfiguracji z wieloma centrami danych (lub wieloma DC) — niezależnie od tego, czy ekosystem baz danych to SQL (PostgreSQL, MySQL), czy NoSQL (MongoDB, Cassandra), żeby wymienić tylko kilka — to niskie opóźnienia dla użytkowników końcowych, Wysoka dostępność i odzyskiwanie po awarii. U podstaw takiego środowiska leży możliwość replikacji danych w sposób zapewniający ich trwałość (na marginesie, parametry konfiguracyjne trwałości Cassandry są podobne do tych, których używa PostgreSQL). Różne wymagania dotyczące replikacji zostaną omówione poniżej, jednak skrajne przypadki zostaną pozostawione ciekawskim do dalszych badań.
Replikacja za pomocą asynchronicznego przesyłania dzienników jest dostępna w PostgreSQL od dłuższego czasu, a synchroniczna replikacja wprowadzona w wersji 9.1 otworzyła zupełnie nowy zestaw opcji dla twórców narzędzi do zarządzania PostgreSQL.
Rzeczy do rozważenia
Jednym ze sposobów zrozumienia złożoności implementacji multi-DC PostgreSQL jest uczenie się na podstawie rozwiązań zaimplementowanych dla innych systemów baz danych, pamiętając jednocześnie, że PostgreSQL nalega na zgodność z ACID.
Konfiguracja multi-DC obejmuje w większości przypadków co najmniej jedno centrum danych w chmurze. Chociaż dostawcy chmury biorą na siebie ciężar zarządzania replikacją bazy danych w imieniu swoich klientów, zazwyczaj nie dorównują one funkcjom dostępnym w wyspecjalizowanych narzędziach do zarządzania. Na przykład w przypadku wielu przedsiębiorstw korzystających z chmury hybrydowej i/lub rozwiązań wielochmurowych, oprócz istniejącej infrastruktury lokalnej, narzędzie multi-DC powinno być w stanie obsłużyć tak mieszane środowisko.
Ponadto, aby zminimalizować przestoje podczas przełączania awaryjnego, system zarządzania PostgreSQL powinien mieć możliwość żądania (poprzez wywołanie API) aktualizacji DNS, dzięki czemu żądania bazy danych są kierowane do nowego klastra głównego.
Sieci obejmujące duże obszary geograficzne są połączeniami o dużych opóźnieniach i wszystkie rozwiązania muszą iść na kompromis:zapomnij o replikacji synchronicznej i używaj jednego podstawowego z wieloma replikami do odczytu. Zobacz badania AWS MongoDB i Manynines/Galera Cluster, aby uzyskać dogłębną analizę wpływu sieci na replikację. W związku z tym, sprytnym narzędziem do testowania opóźnień między lokalizacjami jest Wonder Network Ping Statistics.
Chociaż nie można zmienić charakteru sieci WAN o wysokim opóźnieniu, wrażenia użytkownika można znacznie poprawić, zapewniając obsługę odczytów z repliki odczytu znajdującej się w pobliżu lokalizacji użytkownika, jednak z pewnymi zastrzeżeniami. Przenosząc repliki z bazy podstawowej, zapisy są opóźnione, a zatem musimy zrezygnować z replikacji synchronicznej. Rozwiązanie musi również być w stanie obejść inne problemy, takie jak spójność odczytu po zapisie i nieaktualne odczyty wtórne z powodu utraty połączenia.
Aby zminimalizować RTO, dane muszą zostać zreplikowane do trwałej pamięci masowej, która jest również w stanie zapewnić wysoką przepustowość odczytu, a według Citus Data jedną z opcji spełniających te wymagania jest AWS S3.
Samo pojęcie wielu centrów danych oznacza, że system zarządzania bazami danych musi być w stanie przedstawić administratorowi DBA globalny widok wszystkich centrów danych i różnych klastrów PostgreSQL w nich, zarządzać wieloma wersjami PostgreSQL i konfigurować replikację między nimi. /P>
Podczas replikacji zapisów do regionalnych centrów danych należy monitorować opóźnienie propagacji. Jeśli opóźnienie przekroczy próg, powinien zostać wyzwolony alarm wskazujący, że replika zawiera nieaktualne dane. Ta sama zasada dotyczy asynchronicznej replikacji z wieloma wzorcami.
W konfiguracji synchronicznej duże opóźnienia lub zakłócenia sieci mogą prowadzić do opóźnień w obsłudze żądań klientów podczas oczekiwania na zakończenie zatwierdzenia, podczas gdy w konfiguracjach asynchronicznych istnieje ryzyko rozdwojenia mózgu lub obniżenia wydajności przez dłuższy czas. Podział mózgu i opóźnienia w zatwierdzeniach synchronicznych są nieuniknione nawet w przypadku dobrze ugruntowanych rozwiązań replikacji, jak wyjaśniono w artykule Geo-Distributed Database Clusters with Galera.
Inną kwestią jest wsparcie dostawcy — w chwili pisania tego tekstu AWS nie obsługuje replik międzyregionalnych PostgreSQL.
Inteligentne systemy zarządzania powinny monitorować opóźnienia sieciowe między centrami danych i zalecać lub dostosowywać zmiany m.in. replikacja synchroniczna doskonale sprawdza się między strefami dostępności AWS, w których centra danych są połączone za pomocą sieci światłowodowych. W ten sposób rozwiązanie może osiągnąć zerową utratę danych, a także może wdrożyć replikację master-master wraz z równoważeniem obciążenia. Zauważ, że AWS Aurora PostgreSQL nie zapewnia obecnie opcji replikacji master-master.
Zdecyduj o poziomie replikacji:klaster, baza danych, tabela. Kryteria decyzyjne powinny obejmować koszty przepustowości.
Zaimplementuj replikację kaskadową, aby obejść zakłócenia w sieci, które mogą uniemożliwić replikom otrzymywanie aktualizacji z urządzenia głównego ze względu na odległość geograficzną.
Rozwiązania
Biorąc pod uwagę wszystkie wymagania, zidentyfikuj produkty, które najlepiej nadają się do pracy. Uwaga:każde rozwiązanie ma swoje własne zastrzeżenia, z którymi należy postępować zgodnie z zaleceniami zawartymi w dokumentacji produktu. Zobacz na przykład wymóg monitorowania BDR.
Oficjalna dokumentacja PostgreSQL zawiera listę niekomercyjnych aplikacji open source, a rozszerzoną listę zawierającą komercyjne rozwiązania o zamkniętym kodzie źródłowym można znaleźć na stronie wiki Replication, Clustering i Connection Pooling. Kilka z tych narzędzi zostało szczegółowo omówionych w artykule Top PG Clustering HA Solutions for PostgreSQL.
Nie ma gotowego rozwiązania, ale niektóre produkty mogą zapewnić większość funkcji, zwłaszcza podczas współpracy ze sprzedawcą.
Oto niewyczerpująca lista:
- Citus Data zapewnia własną wersję PostgreSQL, wzbogaconą o imponujące funkcje korporacyjne i głęboką integrację z AWS.
- EnterpriseDB oferuje duży zestaw usług, które można łączyć w celu spełnienia większości wymagań. Większość informacji znajduje się w dokumentacji produktu.
- Postgres-BDR to potężne narzędzie do replikacji zaprojektowane specjalnie dla klastrów rozproszonych geograficznie, jednak nie integruje się z żadnym dostawcą chmury.
- ClusterControl posiada imponujący zestaw funkcji do zarządzania PostgreSQL. Ma również ograniczoną integrację z chmurą.
- ElephantSQL działa u wielu dostawców chmury. Jednak nie ma opcji konfiguracji lokalnej.
- Crunchy PostgreSQL dla Kubernetes to produkt niezależny od chmury, zbudowany na pierwotnym PostgreSQL.
Wniosek
Jak widzieliśmy, jeśli chodzi o wybór rozwiązania dla wielu centrów danych PostgreSQL, nie ma jednego uniwersalnego rozwiązania. Często kompromis jest koniecznością. Jednak dobre zrozumienie wymagań i implikacji może znacznie pomóc w podjęciu świadomej decyzji.
W porównaniu z danymi statycznymi (tylko do odczytu), rozwiązanie dla baz danych musi uwzględniać replikację aktualizacji (zapisów). Literatura opisująca rozwiązania replikacji zarówno SQL, jak i NoSQL nalega na używanie jednego źródła prawdy do zapisów z wieloma replikami, aby uniknąć problemów, takich jak rozszczepienie mózgu i spójność odczytu po zapisie.
Wreszcie, interoperacyjność jest kluczowym wymogiem, biorąc pod uwagę, że konfiguracje multi-DC mogą obejmować centra danych zlokalizowane na miejscu oraz różnych dostawców chmury.
