Bardzo często spotyka się bazy danych rozmieszczone w wielu lokalizacjach geograficznych. Jednym ze scenariuszy wykonania tego typu konfiguracji jest odzyskiwanie po awarii, w którym rezerwowe centrum danych znajduje się w innej lokalizacji niż główne centrum danych. Równie dobrze może być wymagane, aby bazy danych znajdowały się bliżej użytkowników.
Głównym wyzwaniem w osiągnięciu tej konfiguracji jest zaprojektowanie bazy danych w sposób, który zmniejsza ryzyko problemów związanych z partycjonowaniem sieci.
Klaster MariaDB może być dobrym wyborem do zbudowania takiego środowiska z kilku powodów. Chcielibyśmy omówić je tutaj, a także porozmawiać trochę o tym, jak takie środowisko może wyglądać.
Dlaczego warto korzystać z klastra MariaDB w środowiskach rozproszonych geograficznie?
Pierwszym powodem jest to, że MariaDB Cluster może obsługiwać wiele pisarzy. Ułatwia to zaprojektowanie routingu zapisu — po prostu piszesz do lokalnych węzłów MariaDB. Oczywiście, biorąc pod uwagę replikację synchroniczną, opóźnienie wpływa na wydajność zapisu i możesz zauważyć, że zapisy stają się wolniejsze, jeśli rozłożysz klaster zbyt daleko geograficznie. W końcu nie można ignorować praw fizyki i mówią, przynajmniej na razie, że nawet prędkość światła w połączeniach światłowodowych jest ograniczona. Wszelkie dodane routery również zwiększą opóźnienie, nawet jeśli tylko o kilka milisekund.
Po drugie, obsługa opóźnień w klastrze MariaDB. Replikacja asynchroniczna jest przedmiotem opóźnienia replikacji — jednostki podrzędne mogą nie być na bieżąco z danymi, jeśli mają trudności z zastosowaniem wszystkich zmian w czasie. W klastrze MariaDB jest inaczej — kontrola przepływu to mechanizm, który ma na celu utrzymanie synchronizacji klastra. No, prawie - w niektórych skrajnych przypadkach nadal można zaobserwować lagi. Mówimy tutaj zazwyczaj o milisekundach, najwyżej kilku sekundach, podczas gdy na niebie replikacji asynchronicznej obowiązuje limit.
Po trzecie, segmenty. Domyślnie MariaDB CLuster używa komunikacji „wszystko do wszystkich”, a każdy zestaw zapisów jest wysyłany przez węzeł do wszystkich innych węzłów w klastrze. To zachowanie można zmienić za pomocą segmentów. Segmenty umożliwiają użytkownikom dzielenie klastrów MariaDB na kilka części. Każdy segment może zawierać wiele węzłów i wybiera jeden z nich jako węzeł przekaźnikowy. Takie węzły odbierają zestawy zapisu z innych segmentów i redystrybuują je w węzłach MariaDB lokalnych w segmencie. W rezultacie, jak widać na powyższym diagramie, możliwe jest trzykrotne zmniejszenie ruchu replikacyjnego przechodzącego przez sieć WAN — tylko dwie „repliki” strumienia replikacji są przesyłane przez sieć WAN:jedna na centrum danych w porównaniu do jednej na urządzenie podrzędne w replikacji asynchronicznej.
Wreszcie, gdzie klaster MariaDB naprawdę błyszczy, jest obsługa partycjonowania sieci. Klaster MariaDB stale monitoruje stan węzłów w klastrze. Każdy węzeł próbuje połączyć się ze swoimi peerami i wymienić stan klastra. Jeśli podzbiór węzłów jest nieosiągalny, MariaDB próbuje przekazać komunikację, więc jeśli istnieje sposób na dotarcie do tych węzłów, zostaną one osiągnięte.
Przykład można zobaczyć na powyższym schemacie:DC 1 utracił łączność z DC2, ale DC2 i DC3 mogą się łączyć. W tym przypadku jeden z węzłów w DC3 będzie używany do przekazywania danych z DC1 do DC2, zapewniając utrzymanie komunikacji wewnątrz klastra.
MariaDB może podejmować działania na podstawie stanu klastra. Implementuje kworum — większość węzłów musi być dostępna, aby klaster mógł działać. Jeśli węzeł zostanie odłączony od klastra i nie może połączyć się z żadnym innym węzłem, przestanie działać.
Jak widać na powyższym diagramie, nastąpiła częściowa utrata komunikacji sieciowej w DC1, a dany węzeł jest usuwany z klastra, zapewniając, że aplikacja nie uzyska dostępu do nieaktualnych danych.
Odnosi się to również na większą skalę. DC1 został odcięty od całej komunikacji. W rezultacie całe centrum danych zostało usunięte z klastra i żaden z jego węzłów nie będzie obsługiwał ruchu. Pozostała część klastra zachowała większość (dostępnych jest 6 z 9 węzłów) i zrekonfigurowała się, aby utrzymać połączenie między DC 2 i DC3. Na powyższym diagramie założyliśmy, że program piszący trafia do węzła w DC2, ale pamiętaj, że MariaDB może działać z wieloma programami piszącymi.
Projektowanie rozproszonego geograficznie klastra MariaDB
Przejrzeliśmy niektóre funkcje, które sprawiają, że MariaDB Cluster dobrze pasuje do środowisk rozproszonych geograficznie, skupmy się teraz trochę na projekcie. Na początek wyjaśnijmy, z jakim środowiskiem pracujemy. Będziemy korzystać z trzech zdalnych centrów danych, połączonych siecią rozległą (WAN). Każde centrum danych będzie otrzymywać zapisy z lokalnych serwerów aplikacji. Odczyty będą również wyłącznie lokalne. Ma to na celu uniknięcie niepotrzebnego ruchu przechodzącego przez sieć WAN.
Aby uprościć ten blog, nie będziemy zagłębiać się w szczegóły, jak powinna wyglądać łączność. Zakładamy pewnego rodzaju prawidłowo skonfigurowane, bezpieczne połączenie we wszystkich centrach danych. Do tego celu można użyć VPN lub innych narzędzi.
Wykorzystamy MaxScale jako loadbalancer. MaxScale zostanie wdrożony lokalnie w każdym centrum danych. Będzie również kierować ruch tylko do węzłów lokalnych. Zdalne węzły zawsze można dodać ręcznie, a my wyjaśnimy przypadki, w których może to być dobre rozwiązanie. Aplikacje można skonfigurować tak, aby łączyły się z jednym z lokalnych węzłów MaxScale przy użyciu algorytmu round-robin. Równie dobrze możemy użyć Keepalived i Virtual IP do kierowania ruchu do pojedynczego węzła MaxScale, o ile pojedynczy węzeł MaxScale byłby w stanie obsłużyć cały ruch.
Innym możliwym rozwiązaniem jest kolokacja MaxScale z węzłami aplikacji i skonfigurowanie aplikacji do łączenia się z proxy na hoście lokalnym. To podejście działa całkiem dobrze przy założeniu, że jest mało prawdopodobne, aby MaxScale nie był dostępny, ale aplikacja działałaby dobrze na tym samym węźle. Zazwyczaj widzimy albo awarię węzła, albo awarię sieci, co wpłynie jednocześnie na MaxScale i aplikację.
Powyższy diagram przedstawia wersję środowiska, w którym MaxScale tworzy farmy proxy - wszystkie węzły proxy z tą samą konfiguracją, równoważenie obciążenia za pomocą Keepalive lub po prostu okrężne działanie aplikacji we wszystkich węzłach MaxScale. MaxScale jest skonfigurowany do dystrybucji obciążenia na wszystkie węzły MariaDB w lokalnym centrum danych. Jeden z tych węzłów zostanie wybrany jako węzeł do wysyłania zapisów, podczas gdy polecenia SELECT zostaną rozłożone na wszystkie węzły. Posiadanie jednego dedykowanego węzła zapisującego w centrum danych pomaga zmniejszyć liczbę możliwych konfliktów certyfikacji, co zwykle prowadzi do lepszej wydajności. Aby zmniejszyć to jeszcze bardziej, musielibyśmy zacząć przesyłać ruch przez połączenie WAN, co nie jest idealne, ponieważ wykorzystanie przepustowości znacznie wzrosłoby. W tej chwili, gdy segmenty są na miejscu, tylko dwie kopie zbioru zapisu są wysyłane przez centra danych — jedna na DC.
Wnioski
Jak widać, Klaster MariaDB można łatwo wykorzystać do tworzenia klastrów rozproszonych geograficznie, które mogą działać nawet na całym świecie. Czynnikiem ograniczającym będzie opóźnienie sieci. Jeśli jest zbyt wysoki, być może trzeba będzie rozważyć użycie oddzielnych klastrów MariaDB połączonych za pomocą replikacji asynchronicznej.
