Drupal je systém pro správu obsahu (CMS) navržený k vytváření všeho, od malých až po velké firemní webové stránky. Na Drupalu běží více než 1 000 000 webů a používá se k vytváření mnoha webů a aplikací, které používáte každý den (včetně této). Drupal má skvělou sadu standardních funkcí, jako je snadné vytváření obsahu, spolehlivý výkon a vynikající zabezpečení. Co odlišuje Drupal od ostatních, je jeho flexibilita, protože modularita je jedním z jeho hlavních principů.
Drupal je také skvělá volba pro vytváření integrovaných digitálních rámců. Můžete jej rozšířit o tisíce dostupných doplňků. Tyto moduly rozšiřují funkčnost Drupalu. Motivy vám umožňují přizpůsobit prezentaci vašeho obsahu a distribuce (balíčky Drupal) jsou balíčky, které můžete použít jako startovací sady. Všechny tyto funkce můžete použít ke vzájemnému kombinování za účelem vylepšení základních schopností Drupalu nebo k integraci Drupalu s externími službami. Jedná se o software pro správu obsahu, který je výkonný a škálovatelný.
Drupal používá k ukládání svého webového obsahu databáze. Když váš web nebo aplikace založená na Drupalu zažívá velký provoz, může to mít dopad na váš databázový server. V této situaci budete potřebovat vyvažování zátěže, vysokou dostupnost a redundantní architekturu, aby byla databáze online.
Když jsem začal zkoumat tento blog, uvědomil jsem si, že na tento problém existuje mnoho odpovědí online, ale doporučená řešení byla velmi zastaralá. To by mohlo být důsledkem nárůstu tržního podílu WordPress, což má za následek menší open source komunitu. Našel jsem několik příkladů implementace vysoké dostupnosti pomocí Master/Master (vysoká dostupnost) nebo Master/Master/Slave (vysoká dostupnost/vysoký výkon).
Drupal nabízí podporu pro širokou škálu databází, ale původně byl navržen s použitím variant MySQL. Ačkoli je používání MySQL plně podporováno, existují lepší přístupy, které můžete implementovat. Implementace těchto dalších přístupů, pokud však není provedena správně, může způsobit, že váš web bude mít velké množství výpadků, vaše aplikace bude trpět problémy s výkonem a může mít za následek problémy se zápisem do vašich podřízených zařízení. Provádění údržby by také bylo obtížné, protože k použití upgradů nebo oprav serveru (hardwaru nebo softwaru) bez prostojů potřebujete převzetí služeb při selhání. To platí zejména v případě, že máte velké množství dat, což může mít velký dopad na vaše podnikání.
Toto jsou situace, ke kterým nechcete, aby se stávaly, a proto v tomto blogu probereme, jak můžete implementovat převzetí služeb při selhání databáze pro databáze MySQL nebo PostgreSQL.
Proč váš web Drupal potřebuje selhání databáze?
Z Wikipedie „failover je přepnutí na redundantní nebo pohotovostní počítačový server, systém, hardwarovou komponentu nebo síť při selhání nebo abnormálním ukončení dříve aktivní aplikace, serveru, systému, hardwarové komponenty nebo sítě. Přepnutí při selhání a přepnutí jsou v podstatě stejné operace, kromě toho, že přepnutí při selhání je automatické a obvykle funguje bez varování, zatímco přepnutí vyžaduje lidský zásah.“
V databázových operacích je přepnutí také termín používaný pro ruční převzetí služeb při selhání, což znamená, že přepnutí při selhání vyžaduje osoba. Failover přijde vhod pro každého administrátora, protože izoluje nechtěné problémy, jako je náhodné smazání/upuštění tabulek, dlouhé hodiny prostojů způsobující dopad na podnikání, poškození databáze nebo poškození na úrovni systému.
Přepnutí při selhání databáze sestává z více než jednoho databázového uzlu, ať už fyzicky nebo virtuálně. V ideálním případě, protože převzetí služeb při selhání vyžaduje, abyste provedli přepnutí na jiný uzel, můžete také přejít na jiný databázový server, pokud hostitel provozuje více instancí databáze na jednom hostiteli. Stále to může být buď přepnutí, nebo převzetí služeb při selhání, ale obvykle se jedná spíše o redundanci a vysokou dostupnost pro případ, že na aktuálním hostiteli dojde ke katastrofě.
Přepnutí při selhání MySQL pro Drupal
Provedení převzetí služeb při selhání pro vaši aplikaci založenou na Drupalu vyžaduje, aby se data zpracovávaná databází nerozlišovala ani neoddělovala. Existuje několik dostupných řešení a o některých z nich jsme již hovořili v předchozích blozích Somenines. Možná si budete chtít přečíst náš Úvod do Failover pro replikaci MySQL – blog 101.
Přepnutí Master-Slave
Nejběžnějším přístupem k přepnutí při selhání MySQL je použití přepnutí master-slave nebo ručního převzetí služeb při selhání. Zde můžete provést dva přístupy:
- Svou databázi můžete implementovat pomocí typické asynchronní replikace master-slave.
- nebo lze implementovat asynchronní replikaci master-slave pomocí replikace založené na GTID.
Přechod na jiný master by mohl být rychlejší a jednodušší. To lze provést pomocí následující syntaxe 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 */nebo s GTID, můžete to jednoduše udělat,
...
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_AUTO_POSITION = 1; /* master information to connect */
...
WitPoužití přístupu bez GTID vyžaduje, abyste nejprve určili hlavní soubor protokolu a pozici protokolu hlavního serveru. Můžete to určit tak, že se před přepnutím podíváte na stav hlavního uzlu v hlavním uzlu.
mysql> MASTER STATUS;Můžete také zvážit posílení serveru přidáním sync_binlog =1 a innodb_flush_log_at_trx_commit =1, protože v případě selhání hlavního serveru budete mít vyšší šanci, že transakce z hlavního serveru nebudou synchronizovány s vaším podřízeným ( s). V takovém případě má povýšený hlavní uzel vyšší šanci stát se konzistentním uzlem zdroje dat.
To však nemusí být nejlepší přístup pro vaši databázi Drupal, protože by to mohlo způsobit dlouhé prostoje, pokud by nebylo provedeno správně, například by bylo náhle odstraněno. Pokud váš hlavní databázový uzel zaznamená chybu, která má za následek zhroucení databáze, budete potřebovat, aby vaše aplikace ukazovala na jinou databázi čekající v pohotovostním režimu jako váš nový master nebo tím, že váš slave bude povýšen na master. Budete muset přesně určit, který uzel by měl převzít, a poté určit zpoždění a konzistenci tohoto uzlu. Dosažení toho není tak snadné, jako jednoduše provést SET GLOBAL read_only=1; ZMĚŇTE MASTER NA... (atd.), existují určité situace, které vyžadují hlubší analýzu, sledování životaschopných transakcí, které musí být přítomny na tomto pohotovostním serveru nebo povýšeném hlavním serveru, aby to bylo možné provést.
Přepnutí při selhání Drupal pomocí MHA
Jedním z nejběžnějších nástrojů pro automatické a manuální převzetí služeb při selhání je MHA. Existuje již dlouhou dobu a stále je používán mnoha organizacemi. Můžete si prohlédnout tyto předchozí blogy, které máme na toto téma, Nejčastější problémy s MHA a jak je opravit nebo MySQL High Availability Tools – porovnání MHA, MRM a ClusterControl.
Přepnutí při selhání Drupal pomocí nástroje Orchestrator
Orchestrator je nyní široce přijat a používají jej velké organizace, jako je Github a Booking.com. Umožňuje nejen spravovat převzetí služeb při selhání, ale také správu topologie, zjišťování hostitelů, refaktorování a obnovu. Je zde pěkný externí blog, který jsem považoval za velmi užitečné dozvědět se o jeho mechanismu převzetí služeb při selhání s Orchestratorem. Je to dvoudílná blogová série; část jedna a část druhá.
Přepnutí při selhání Drupal pomocí MaxScale
MaxScale není jen nástroj pro vyrovnávání zatížení určený pro server MariaDB, ale také rozšiřuje vysokou dostupnost, škálovatelnost a zabezpečení pro MariaDB a zároveň zjednodušuje vývoj aplikací tím, že je odděluje od základní databázové infrastruktury. Pokud používáte MariaDB, MaxScale by pro vás mohla být relevantní technologie. Podívejte se na naše předchozí blogy o tom, jak můžete využít mechanismus převzetí služeb při selhání MaxScale.
Přepnutí při selhání Drupal pomocí ClusterControl
ClusterControl od několika společností nabízí širokou škálu řešení pro správu databází a monitorování. Součástí řešení, která nabízíme, je automatické převzetí služeb při selhání, manuální převzetí služeb při selhání a obnovení clusteru/uzlu. To je velmi užitečné, protože funguje jako váš virtuální správce databáze a v reálném čase vás upozorní v případě, že je váš cluster v „panickém režimu“, a to vše během doby, kdy systém spravuje obnovu. Můžete se podívat na tento blog How to Automate Database Failover with ClusterControl, kde se dozvíte více o převzetí služeb při selhání ClusterControl.
Další řešení MySQL
Některé ze starých přístupů jsou stále použitelné, když chcete provést převzetí služeb při selhání. Existuje MMM, MRM, nebo si můžete rezervovat Group Replication nebo Galera (poznámka:Galera nepoužívá asynchronní, spíše synchronní replikaci). Převzetí služeb při selhání v clusteru Galera nefunguje stejným způsobem jako u asynchronní replikace. S Galerou můžete pouze zapisovat do libovolného uzlu, nebo pokud implementujete přístup master-slave, můžete svou aplikaci nasměrovat na jiný uzel, který bude aktivním zapisovatelem clusteru.
Přepnutí při selhání Drupal PostgreSQL
Vzhledem k tomu, že Drupal podporuje PostgreSQL, vyzkoušíme také nástroje pro implementaci procesu převzetí služeb při selhání nebo přepnutí pro PostgreSQL. PostgreSQL používá vestavěnou replikaci streamování, můžete ji však také nastavit tak, aby používala logickou replikaci (přidaná jako základní prvek PostgreSQL ve verzi 10).
Přepnutí při selhání Drupal pomocí pg_ctlcluster
Pokud je vaším prostředím Ubuntu, je použití pg_ctlcluster jednoduchým a snadným způsobem, jak dosáhnout převzetí služeb při selhání. Můžete například spustit následující příkaz:
$ pg_ctlcluster 9.6 pg_7653 promotenebo s RHEL/Centos můžete použít příkaz pg_ctl stejně jako,
$ sudo -iu postgres /usr/lib/postgresql/9.6/bin/pg_ctl promote -D /data/pgsql/slave/data
server promotingMůžete také spustit převzetí služeb při selhání záložního serveru pro odesílání protokolů vytvořením spouštěcího souboru s názvem souboru a cestou zadanou v souboru trigger_file v recovery.conf.
Musíte být opatrní s povýšením v pohotovostním režimu nebo podřízeným povýšením, protože možná budete muset zajistit, aby požadavek čtení a zápisu přijímal pouze jeden nadřízený. To znamená, že při přepínání možná budete muset zajistit, aby byl předchozí master uvolněný nebo zastavený.
Péče o přepnutí nebo ruční převzetí služeb při selhání z primárního na záložní server může být rychlé, ale opětovná příprava clusteru s podporou převzetí služeb při selhání vyžaduje určitou dobu. Pravidelné přepínání z primárního do pohotovostního režimu je užitečná praxe, protože umožňuje pravidelné odstávky každého systému z důvodu údržby. Slouží také jako test mechanismu převzetí služeb při selhání, aby bylo zajištěno, že bude skutečně fungovat, když jej budete potřebovat. Vždy se doporučuje písemný postup administrace.
Automatické převzetí služeb při selhání Drupal PostgreSQL
Místo ručního přístupu můžete vyžadovat automatické převzetí služeb při selhání. To je zvláště potřeba, když dojde k výpadku serveru v důsledku selhání hardwaru nebo poškození virtuálního počítače. Můžete také vyžadovat, aby aplikace automaticky provedla převzetí služeb při selhání, aby se zkrátily prostoje vaší aplikace Drupal. Nyní si projdeme některé z těchto nástrojů, které lze použít pro automatické převzetí služeb při selhání.
Přepnutí při selhání Drupal pomocí Patroni
Patroni je šablona, pomocí které si můžete vytvořit vlastní přizpůsobené řešení s vysokou dostupností pomocí Pythonu a – pro maximální dostupnost – distribuovaného úložiště konfigurací, jako je ZooKeeper, etcd, Consul nebo Kubernetes. Databázoví inženýři, správci databází, inženýři DevOps a SRE, kteří chtějí rychle nasadit HA PostgreSQL v datovém centru nebo kdekoli jinde, to snad shledají užitečným
Přepnutí při selhání Drupal pomocí Pgpool
Pgpool-II je proxy software, který je umístěn mezi servery PostgreSQL a databázovým klientem PostgreSQL. Kromě automatického převzetí služeb při selhání má několik funkcí, které zahrnují sdružování připojení, vyvažování zátěže, replikaci a omezení nadměrného počtu připojení. Více o tomto nástroji si můžete přečíst v našem třídílném blogu; část jedna, část druhá, část třetí.
Přepnutí při selhání Drupal pomocí pglookout
pglookout je démon pro monitorování replikace PostgreSQL a překonání selhání. pglookout monitoruje databázové uzly, jejich stav replikace a jedná podle tohoto stavu. Například volání předdefinovaného příkazu pro přepnutí při selhání pro podporu nového hlavního serveru v případě, že předchozí zmizí.
pglookout podporuje dva různé typy uzlů, ty, které jsou nainstalovány na samotných db uzlech, a pozorovatelské uzly, které lze nainstalovat kdekoli. Účelem pglookoutu na PostgreSQL DB uzlech je monitorovat stav replikace clusteru a podle toho jednat, pozorovatelé mají omezenější pravomoci:pouze sledují stav clusteru, aby poskytli jiný úhel pohledu na stav clusteru.
Přepnutí při selhání Drupal pomocí repmgr
repmgr je sada nástrojů s otevřeným zdrojovým kódem pro správu replikace a převzetí služeb při selhání v clusteru serverů PostgreSQL. Vylepšuje vestavěné funkce Hot-standby PostgreSQL s nástroji pro nastavení záložních serverů, monitorování replikace a provádění administrativních úloh, jako je převzetí služeb při selhání nebo ruční přepnutí.
repmgr poskytuje pokročilou podporu pro vestavěné replikační mechanismy PostgreSQL od jejich zavedení v 9.0. Aktuální řada repmgr, repmgr 4, podporuje nejnovější vývoj replikačních funkcí zavedených z PostgreSQL 9.3, jako je kaskádová replikace, přepínání časové osy a základní zálohy prostřednictvím replikačního protokolu.
Přepnutí při selhání Drupal pomocí ClusterControl
ClusterControl podporuje automatické převzetí služeb při selhání pro PostgreSQL. Pokud dojde k incidentu, může být váš otrok automaticky povýšen do stavu pána. S ClusterControl můžete také nasadit samostatnou, replikovanou nebo clusterovou databázi PostgreSQL. Uzel můžete také snadno přidat nebo odebrat jedinou akcí.
Další řešení pro překonání selhání PostgreSQL Drupal
Určitě existují řešení automatického převzetí služeb při selhání, která jsem na tomto blogu možná přehlédl. Pokud ano, přidejte prosím své komentáře níže, abychom mohli znát vaše myšlenky a zkušenosti s vaší implementací a nastavením pro převzetí služeb při selhání, zejména pro weby nebo aplikace Drupal.
Další řešení pro selhání Drupal
I když nástroje, které jsem zmínil dříve, rozhodně zvládnou řešení vašich problémů s převzetím služeb při selhání, přidání některých nástrojů, díky nimž je přepnutí při selhání docela jednodušší, bezpečnější a mají úplnou izolaci mezi vaší databázovou vrstvou, může být uspokojivé.
Přepnutí při selhání Drupal pomocí ProxySQL
S ProxySQL můžete své weby nebo aplikace Drupal nasměrovat na hostitele serveru ProxySQL a ten určí, který uzel bude přijímat zápisy a které uzly budou přijímat čtení. Kouzlo se děje transparentně ve vrstvě TCP a nejsou potřeba žádné změny konfigurace vaší aplikace/webu. Kromě toho funguje ProxySQL také jako váš vyvažovač zatížení pro vaše požadavky na zápis a čtení pro váš databázový provoz. To platí pouze v případě, že používáte varianty databáze MySQL.
Drupal Failover pomocí HAProxy s Keepalived
Použití HAProxy a Keepalived zvyšuje dostupnost a redundanci v databázi vašeho Drupalu. Pokud chcete převzetí služeb při selhání, lze to provést, aniž by vaše aplikace věděla, co se děje ve vaší databázové vrstvě. Stačí nasměrovat vaši aplikaci na vrrp IP, kterou nastavíte v Keepalived, a vše bude řešeno zcela izolovaně od vaší aplikace. Automatické převzetí služeb při selhání bude vaší aplikací řešeno transparentně a nevědomě, takže pokud například dojde k havárii a dojde k obnově nebo převzetí služeb při selhání, nemusí dojít k žádným změnám. Dobrá věc na tomto nastavení je, že je použitelná pro databáze MySQL i PostgreSQL. Doporučuji, abyste se podívali na náš blog PostgreSQL Load Balancing Using HAProxy &Keepalived, kde se dozvíte více o tom, jak to udělat.
Všechny výše uvedené možnosti jsou podporovány ClusterControl. Můžete nasadit nebo importovat databázi a poté nasadit ProxySQL, MaxScale nebo HAProxy &Keepalived. Vše bude řízeno, monitorováno a nastavováno automaticky, aniž by bylo nutné provádět další konfiguraci. Vše se děje na pozadí a automaticky se vytvoří připravený k výrobě.
Závěr
Mít web nebo aplikaci Drupal, která je neustále k dispozici, zejména pokud očekáváte velký provoz, může být komplikované. Pokud však máte správné nástroje, správné nastavení a správnou sadu technologií, je možné dosáhnout vysoké dostupnosti a redundance.
A pokud ne? ClusterControl to za vás nastaví a bude udržovat. Případně můžete vytvořit nastavení pomocí technologií uvedených v tomto blogu, z nichž většina jsou open source, bezplatné nástroje, které uspokojí vaše potřeby.