Drupal to system zarządzania treścią (CMS) zaprojektowany do tworzenia wszystkiego, od małych do dużych witryn korporacyjnych. Na Drupalu działa ponad 1 000 000 stron internetowych i jest on używany do tworzenia wielu stron internetowych i aplikacji, z których korzystasz na co dzień (w tym tej). Drupal ma świetny zestaw standardowych funkcji, takich jak łatwe tworzenie treści, niezawodna wydajność i doskonałe zabezpieczenia. Tym, co wyróżnia Drupala, jest jego elastyczność, ponieważ modułowość jest jedną z jego podstawowych zasad.
Drupal to także świetny wybór do tworzenia zintegrowanych ram cyfrowych. Możesz go rozszerzyć za pomocą tysięcy dostępnych dodatków. Moduły te rozszerzają funkcjonalność Drupala. Motywy pozwalają dostosować prezentację i dystrybucję treści (pakiety Drupala) to pakiety, których można używać jako zestawów startowych. Możesz użyć wszystkich tych funkcji, aby mieszać i dopasowywać, aby wzmocnić podstawowe możliwości Drupala lub zintegrować Drupala z usługami zewnętrznymi. Jest to potężne i skalowalne oprogramowanie do zarządzania treścią.
Drupal używa baz danych do przechowywania treści internetowych. Duży ruch na stronie lub aplikacji opartej na Drupalu może mieć wpływ na serwer bazy danych. W takiej sytuacji będziesz potrzebować równoważenia obciążenia, wysokiej dostępności i nadmiarowej architektury, aby utrzymać bazę danych w trybie online.
Kiedy zacząłem szukać informacji na tym blogu, zdałem sobie sprawę, że w Internecie jest wiele odpowiedzi na ten problem, ale zalecane rozwiązania były bardzo przestarzałe. Może to wynikać ze wzrostu udziału WordPressa w rynku, co skutkuje mniejszą społecznością open source. To, co znalazłem, to kilka przykładów implementacji wysokiej dostępności przy użyciu Master/Master (High Availability) lub Master/Master/Slave (High Availability/High Performance).
Drupal oferuje obsługę szerokiej gamy baz danych, ale początkowo został zaprojektowany przy użyciu wariantów MySQL. Chociaż korzystanie z MySQL jest w pełni obsługiwane, istnieją lepsze metody, które można wdrożyć. Jednak wdrożenie tych innych podejść, jeśli nie zostanie wykonane prawidłowo, może spowodować duże przestoje w witrynie, problemy z wydajnością aplikacji i problemy z zapisem na urządzeniach podrzędnych. Wykonywanie konserwacji byłoby również trudne, ponieważ konieczne jest przełączanie awaryjne, aby zastosować aktualizacje lub poprawki serwera (sprzęt lub oprogramowanie) bez przestojów. Jest to szczególnie ważne, jeśli masz dużą ilość danych, co może mieć potencjalny duży wpływ na Twoją firmę.
Są to sytuacje, których nie chcesz, aby miały miejsce, dlatego w tym blogu omówimy, jak zaimplementować przełączanie awaryjne baz danych dla baz danych MySQL lub PostgreSQL.
Dlaczego Twoja witryna Drupal potrzebuje przełączania awaryjnego bazy danych?
Z Wikipedii „przełączenie awaryjne polega na przełączeniu na nadmiarowy lub rezerwowy serwer komputerowy, system, składnik sprzętowy lub sieć po awarii lub nieprawidłowym zakończeniu poprzednio aktywnej aplikacji, serwera, systemu, składnika sprzętowego lub sieci. Przełączanie awaryjne i przełączanie to zasadniczo ta sama operacja, z wyjątkiem tego, że przełączanie awaryjne jest automatyczne i zwykle działa bez ostrzeżenia, podczas gdy przełączanie wymaga interwencji człowieka”.
W operacjach na bazach danych przełączanie jest również terminem używanym do ręcznego przełączania awaryjnego, co oznacza, że wymaga to osoby do obsługi przełączania awaryjnego. Przełączanie awaryjne przydaje się każdemu administratorowi, ponieważ izoluje niepożądane problemy, takie jak przypadkowe usunięcie/upuszczenie tabel, długie godziny przestoju powodujące wpływ na działalność firmy, uszkodzenie bazy danych lub uszkodzenie na poziomie systemu.
Przełączanie awaryjne bazy danych składa się z więcej niż jednego węzła bazy danych, fizycznie lub wirtualnie. W idealnym przypadku, ponieważ przełączanie awaryjne wymaga przełączenia na inny węzeł, równie dobrze można przełączyć się na inny serwer bazy danych, jeśli na hoście działa wiele instancji bazy danych na jednym hoście. Nadal może to być przełączanie lub przełączanie awaryjne, ale zazwyczaj jest to bardziej nadmiarowość i wysoka dostępność na wypadek katastrofy na tym bieżącym hoście.
Przełączanie awaryjne MySQL dla Drupala
Wykonywanie przełączania awaryjnego aplikacji opartej na Drupalu wymaga, aby dane obsługiwane przez bazę danych nie były różnicowane ani rozdzielane. Dostępnych jest kilka rozwiązań, a niektóre z nich omówiliśmy już w poprzednich blogach Manynines. Być może zechcesz przeczytać nasze wprowadzenie do przełączania awaryjnego dla replikacji MySQL — blog 101.
Przełączanie master-slave
Najczęstszym podejściem do MySQL Failover jest użycie przełączania master-slave lub ręcznego przełączania awaryjnego. Możesz tutaj zrobić dwa podejścia:
- Możesz zaimplementować swoją bazę danych z typową asynchroniczną replikacją master-slave.
- lub można zaimplementować z asynchroniczną replikacją master-slave przy użyciu replikacji opartej na GTID.
Przełączanie na inny master może być szybsze i łatwiejsze. Można to zrobić za pomocą następującej składni MySQL:
mysql> SET GLOBAL read_only = 1; /* enable read-only */
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_LOG_FILE = '<master-log-file>', MASTER_LOG_POS=<master_log_position>; /* master information to connect */
mysql> START SLAVE; /* start replication */
mysql> SHOW SLAVE STATUS\G /* check replication status */lub z GTID, możesz po prostu zrobić,
...
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_AUTO_POSITION = 1; /* master information to connect */
...
WitKorzystanie z podejścia innego niż GTID wymaga określenia najpierw pliku dziennika mastera i pozycji logu mastera. Możesz to określić, patrząc na status mastera w węźle master przed przełączeniem.
mysql> MASTER STATUS;Możesz również rozważyć wzmocnienie serwera, dodając sync_binlog =1 i innodb_flush_log_at_trx_commit =1, ponieważ w przypadku awarii głównego urządzenia masz większą szansę, że transakcje z mastera nie będą zsynchronizowane z twoim slave ( s). W takim przypadku promowany master ma większą szansę na bycie spójnym węzłem źródła danych.
Może to jednak nie być najlepsze podejście do bazy danych Drupala, ponieważ może powodować długie przestoje, jeśli nie zostanie wykonane poprawnie, na przykład nagłe wyłączenie. Jeśli w węźle głównej bazy danych wystąpi błąd powodujący awarię bazy danych, aplikacja będzie musiała wskazywać inną bazę danych oczekującą w stanie gotowości jako nowy master lub poprzez promocję slave'a na mastera. Będziesz musiał dokładnie określić, który węzeł powinien przejąć, a następnie określić opóźnienie i spójność tego węzła. Osiągnięcie tego nie jest tak proste, jak wykonanie SET GLOBAL read_only=1; ZMIEŃ MASTER NA… (itd.), są pewne sytuacje, które wymagają głębszej analizy, przyjrzenia się realnym transakcjom, które muszą być obecne na tym serwerze rezerwowym lub promowanym serwerze głównym, aby to zrobić.
Przełączanie awaryjne Drupala przy użyciu MHA
Jednym z najpopularniejszych narzędzi do automatycznego i ręcznego przełączania awaryjnego jest MHA. Jest już od dłuższego czasu i nadal jest używany przez wiele organizacji. Możesz sprawdzić te poprzednie blogi na ten temat:Najczęstsze problemy z MHA i sposoby ich rozwiązywania lub MySQL High Availability Tools – Porównanie MHA, MRM i ClusterControl.
Przełączanie awaryjne Drupala za pomocą programu Orchestrator
Orchestrator jest obecnie szeroko stosowany i jest używany przez duże organizacje, takie jak Github i Booking.com. Umożliwia nie tylko zarządzanie przełączaniem awaryjnym, ale także zarządzanie topologią, wykrywanie hostów, refaktoryzację i odzyskiwanie. Jest tutaj fajny zewnętrzny blog, który uznałem za bardzo przydatny, aby dowiedzieć się o mechanizmie przełączania awaryjnego w programie Orchestrator. To dwuczęściowa seria blogów; część pierwsza i część druga.
Przełączanie awaryjne Drupala przy użyciu MaxScale
MaxScale to nie tylko moduł równoważenia obciążenia zaprojektowany dla serwera MariaDB, ale także rozszerza wysoką dostępność, skalowalność i bezpieczeństwo dla MariaDB, jednocześnie upraszczając tworzenie aplikacji poprzez oddzielenie jej od podstawowej infrastruktury bazy danych. Jeśli korzystasz z MariaDB, MaxScale może być odpowiednią technologią dla Ciebie. Sprawdź nasze poprzednie blogi na temat korzystania z mechanizmu przełączania awaryjnego MaxScale.
Przełączanie awaryjne Drupala za pomocą ClusterControl
ClusterControl firmy Severalnines oferuje szeroką gamę rozwiązań do zarządzania i monitorowania baz danych. Częścią oferowanych przez nas rozwiązań jest automatyczne przełączanie awaryjne, ręczne przełączanie awaryjne oraz odzyskiwanie klastrów/węzłów. Jest to bardzo pomocne, ponieważ działa jako administrator wirtualnej bazy danych, powiadamiając Cię w czasie rzeczywistym, jeśli klaster jest w „trybie paniki”, podczas gdy odzyskiwanie jest zarządzane przez system. Możesz sprawdzić ten blog Jak zautomatyzować przełączanie awaryjne bazy danych za pomocą ClusterControl, aby dowiedzieć się więcej o przełączaniu awaryjnym ClusterControl.
Inne rozwiązania MySQL
Niektóre ze starych podejść nadal mają zastosowanie, gdy zachodzi potrzeba przełączenia awaryjnego. Jest MMM, MRM lub możesz skorzystać z replikacji grupowej lub Galera (uwaga:Galera nie używa replikacji asynchronicznej, raczej synchronicznej). Przełączanie awaryjne w klastrze Galera nie działa w taki sam sposób, jak w przypadku replikacji asynchronicznej. Dzięki Galera możesz po prostu pisać do dowolnego węzła lub, jeśli zaimplementujesz podejście master-slave, możesz skierować swoją aplikację do innego węzła, który będzie aktywnym zapisem dla klastra.
Przełączanie awaryjne PostgreSQL w Drupalu
Ponieważ Drupal obsługuje PostgreSQL, sprawdzimy również narzędzia do wdrożenia procesu przełączania awaryjnego lub przełączania PostgreSQL. PostgreSQL wykorzystuje wbudowaną replikację strumieniową, jednak można ją również ustawić tak, aby korzystała z replikacji logicznej (dodanej jako podstawowy element PostgreSQL w wersji 10).
Przełączanie awaryjne Drupala przy użyciu pg_ctlcluster
Jeśli Twoim środowiskiem jest Ubuntu, użycie pg_ctlcluster jest prostym i łatwym sposobem na przełączenie awaryjne. Na przykład możesz po prostu uruchomić następujące polecenie:
$ pg_ctlcluster 9.6 pg_7653 promotelub z RHEL/Centos, możesz użyć polecenia pg_ctl, tak jak,
$ sudo -iu postgres /usr/lib/postgresql/9.6/bin/pg_ctl promote -D /data/pgsql/slave/data
server promotingMożna również wyzwolić przełączenie awaryjne serwera rezerwowego przesyłania dziennika, tworząc plik wyzwalacza z nazwą pliku i ścieżką określoną przez plik_wyzwalacza w pliku recovery.conf.
Musisz być ostrożny z promocją w trybie gotowości lub podrzędną, ponieważ może być konieczne upewnienie się, że tylko jeden master akceptuje żądanie odczytu-zapisu. Oznacza to, że podczas przełączania może być konieczne upewnienie się, że poprzedni master został rozluźniony lub zatrzymany.
Zapewnienie przełączenia lub ręcznego przełączenia awaryjnego z serwera podstawowego na rezerwowy może być szybkie, ale ponowne przygotowanie klastra pracy awaryjnej wymaga trochę czasu. Regularne przełączanie z trybu podstawowego na tryb gotowości jest przydatną praktyką, ponieważ umożliwia regularne przestoje każdego systemu w celu konserwacji. Służy to również jako test mechanizmu przełączania awaryjnego, aby upewnić się, że naprawdę zadziała, gdy tego potrzebujesz. Zawsze zalecane są pisemne procedury administracyjne.
Automatyczne przełączanie awaryjne PostgreSQL w Drupalu
Zamiast podejścia ręcznego możesz wymagać automatycznego przełączania awaryjnego. Jest to szczególnie potrzebne, gdy serwer ulegnie awarii z powodu awarii sprzętu lub uszkodzenia maszyny wirtualnej. Możesz również wymagać, aby aplikacja automatycznie wykonała przełączanie awaryjne, aby skrócić czas przestoju aplikacji Drupal. Omówimy teraz niektóre z tych narzędzi, które można wykorzystać do automatycznego przełączania awaryjnego.
Przełączanie awaryjne Drupala przy użyciu Patroni
Patroni to szablon umożliwiający tworzenie własnego, dostosowanego rozwiązania o wysokiej dostępności przy użyciu języka Python oraz — dla maksymalnej dostępności — rozproszonego magazynu konfiguracji, takiego jak ZooKeeper, etcd, Consul lub Kubernetes. Inżynierowie baz danych, administratorzy baz danych, inżynierowie DevOps i SRE, którzy chcą szybko wdrożyć HA PostgreSQL w centrum danych – lub gdziekolwiek indziej – miejmy nadzieję, że uznają to za przydatne
Przełączanie awaryjne Drupala przy użyciu Pgpool
Pgpool-II to oprogramowanie proxy, które znajduje się pomiędzy serwerami PostgreSQL a klientem bazy danych PostgreSQL. Oprócz automatycznego przełączania awaryjnego ma wiele funkcji, w tym łączenie połączeń, równoważenie obciążenia, replikację i ograniczanie przekraczania połączeń. Możesz przeczytać więcej o tym narzędziu w naszym trzyczęściowym blogu; część pierwsza, część druga, część trzecia.
Przełączanie awaryjne Drupala za pomocą pglookout
pglookout to demon do monitorowania replikacji PostgreSQL i przełączania awaryjnego. pglookout monitoruje węzły bazy danych, ich stan replikacji i działa zgodnie z tym stanem. Na przykład wywołanie predefiniowanego polecenia przełączania awaryjnego w celu promowania nowego mastera w przypadku zaginięcia poprzedniego.
pglookout obsługuje dwa różne typy węzłów, te, które są instalowane na samych węzłach bazy danych i węzły obserwatorów, które można zainstalować w dowolnym miejscu. Celem posiadania pglookout na węzłach PostgreSQL DB jest monitorowanie stanu replikacji klastra i odpowiednie działanie. Obserwatorzy mają bardziej ograniczone uprawnienia:po prostu obserwują stan klastra, aby dać inny punkt widzenia na stan klastra.
Przełączanie awaryjne Drupala za pomocą repmgr
repmgr to pakiet narzędzi typu open source do zarządzania replikacją i przełączaniem awaryjnym w klastrze serwerów PostgreSQL. Rozszerza wbudowane możliwości PostgreSQL w trybie gorącej gotowości o narzędzia do konfigurowania serwerów w trybie gotowości, monitorowania replikacji i wykonywania zadań administracyjnych, takich jak przełączanie awaryjne lub ręczne operacje przełączania.
repmgr zapewnia zaawansowane wsparcie dla wbudowanych mechanizmów replikacji PostgreSQL od czasu ich wprowadzenia w wersji 9.0. Obecna seria repmgr, repmgr 4, obsługuje najnowsze osiągnięcia w funkcjonalności replikacji wprowadzone z PostgreSQL 9.3, takie jak replikacja kaskadowa, przełączanie osi czasu i podstawowe kopie zapasowe za pośrednictwem protokołu replikacji.
Przełączanie awaryjne Drupala za pomocą ClusterControl
ClusterControl obsługuje automatyczne przełączanie awaryjne PostgreSQL. Jeśli masz incydent, twój niewolnik może zostać automatycznie awansowany do statusu mistrza. Dzięki ClusterControl możesz również wdrożyć samodzielną, replikowaną lub sklastrowaną bazę danych PostgreSQL. Możesz także łatwo dodać lub usunąć węzeł za pomocą jednej akcji.
Inne rozwiązania PostgreSQL Drupal do przełączania awaryjnego
Istnieją z pewnością rozwiązania do automatycznego przełączania awaryjnego, których mogłem przeoczyć na tym blogu. Jeśli tak, dodaj swoje komentarze poniżej, abyśmy mogli poznać Twoje przemyślenia i doświadczenia związane z implementacją i konfiguracją przełączania awaryjnego, szczególnie w przypadku witryn lub aplikacji Drupal.
Dodatkowe rozwiązania dla przełączania awaryjnego Drupala
Podczas gdy narzędzia, o których wspomniałem wcześniej, zdecydowanie radzą sobie z rozwiązaniem problemów z przełączaniem awaryjnym, dodanie kilku narzędzi, które sprawiają, że przełączanie awaryjne jest łatwiejsze, bezpieczniejsze i zapewnia całkowitą izolację między warstwą bazy danych, może być zadowalające.
Przełączanie awaryjne Drupala przy użyciu ProxySQL
Dzięki ProxySQL możesz po prostu skierować swoje witryny lub aplikacje Drupal do hosta serwera ProxySQL, a on wskaże, który węzeł otrzyma zapisy, a które odczyty. Magia dzieje się w sposób przezroczysty w warstwie TCP i nie są potrzebne żadne zmiany w konfiguracji aplikacji/strony internetowej. Oprócz tego ProxySQL działa również jako system równoważenia obciążenia dla żądań zapisu i odczytu dla ruchu bazy danych. Ma to zastosowanie tylko wtedy, gdy używasz wariantów bazy danych MySQL.
Przełączanie awaryjne Drupala przy użyciu HAProxy z Keepalived
Korzystanie z HAProxy i Keepalived zwiększa dostępność i redundancję w bazie danych Drupala. Jeśli chcesz przełączyć się w tryb failover, możesz to zrobić bez wiedzy aplikacji o tym, co dzieje się w warstwie bazy danych. Po prostu skieruj swoją aplikację na adres IP vrrp, który ustawiłeś w swoim Keepalived, a wszystko będzie obsługiwane z całkowitą izolacją od Twojej aplikacji. Automatyczne przełączanie awaryjne będzie obsługiwane przez aplikację w sposób przejrzysty i nieświadomy, więc żadne zmiany nie muszą być raz wprowadzane, na przykład po wystąpieniu awarii i zastosowaniu przywracania lub przełączania awaryjnego. Dobrą rzeczą w tej konfiguracji jest to, że ma ona zastosowanie zarówno do baz danych MySQL, jak i PostgreSQL. Proponuję zajrzeć do naszego bloga równoważenia obciążenia PostgreSQL za pomocą HAProxy i Keepalived, aby dowiedzieć się więcej o tym, jak to zrobić.
Wszystkie powyższe opcje są obsługiwane przez ClusterControl. Możesz wdrożyć lub zaimportować bazę danych, a następnie wdrożyć ProxySQL, MaxScale lub HAProxy &Keepalived. Wszystko będzie zarządzane, monitorowane i konfigurowane automatycznie, bez potrzeby dalszej konfiguracji. Wszystko dzieje się w tle i automatycznie tworzy gotowy do produkcji.
Wnioski
Utrzymywanie zawsze aktywnej strony internetowej lub aplikacji Drupal, zwłaszcza jeśli spodziewasz się dużego ruchu, może być trudne do stworzenia. Jeśli jednak dysponujesz odpowiednimi narzędziami, odpowiednią konfiguracją i odpowiednim stosem technologii, możliwe jest osiągnięcie wysokiej dostępności i nadmiarowości.
A jeśli nie? No cóż, ClusterControl skonfiguruje go i będzie go obsługiwał za Ciebie. Alternatywnie możesz utworzyć konfigurację, korzystając z technologii wymienionych na tym blogu, z których większość to bezpłatne narzędzia typu open source, które zaspokoją Twoje potrzeby.
