Drupal er et Content Management System (CMS) designet til at skabe alt fra små til store virksomhedswebsteder. Over 1.000.000 websteder kører på Drupal, og det bruges til at lave mange af de websteder og applikationer, du bruger hver dag (inklusive denne). Drupal har et fantastisk sæt standardfunktioner såsom nem oprettelse af indhold, pålidelig ydeevne og fremragende sikkerhed. Det, der adskiller Drupal, er dets fleksibilitet, da modularitet er et af dets kerneprincipper.
Drupal er også et godt valg til at skabe integrerede digitale rammer. Du kan udvide det med de tusindvis af tilgængelige tilføjelser. Disse moduler udvider Drupals funktionalitet. Temaer lader dig tilpasse dit indholds præsentation og distributioner (Drupal bundles) er bundter, som du kan bruge som startsæt. Du kan bruge alle disse funktioner til at mixe og matche for at forbedre Drupals kerneevner eller til at integrere Drupal med eksterne tjenester. Det er indholdsstyringssoftware, der er kraftfuld og skalerbar.
Drupal bruger databaser til at gemme sit webindhold. Når din Drupal-baserede hjemmeside eller applikation oplever en stor mængde trafik, kan det have en indvirkning på din databaseserver. Når du er i denne situation, har du brug for belastningsbalancering, høj tilgængelighed og en redundant arkitektur for at holde din database online.
Da jeg begyndte at undersøge denne blog, indså jeg, at der er mange svar på dette problem online, men de anbefalede løsninger var meget forældede. Dette kan være et resultat af stigningen i markedsandele fra WordPress, hvilket resulterer i et mindre open source-fællesskab. Hvad jeg fandt, var nogle eksempler på implementering af høj tilgængelighed ved at bruge Master/Master (High Availability) eller Master/Master/Slave (High Availability/High Performance).
Drupal tilbyder understøttelse af en bred vifte af databaser, men den blev oprindeligt designet med MySQL-varianter. Selvom brug af MySQL er fuldt understøttet, er der bedre tilgange, du kan implementere. Implementering af disse andre tilgange kan dog, hvis det ikke gøres korrekt, få dit websted til at opleve store mængder nedetid, få din applikation til at lide af ydeevneproblemer og kan resultere i skriveproblemer til dine slaver. Det ville også være vanskeligt at udføre vedligeholdelse, da du har brug for failover for at anvende serveropgraderingerne eller patches (hardware eller software) uden nedetid. Dette gælder især, hvis du har en stor mængde data, hvilket forårsager en potentiel stor indvirkning på din virksomhed.
Dette er situationer, du ikke ønsker skal ske, og derfor vil vi i denne blog diskutere, hvordan du kan implementere database-failover for dine MySQL- eller PostgreSQL-databaser.
Hvorfor har dit Drupal-websted brug for databasefailover?
Fra Wikipedia “failover er at skifte til en redundant eller standby computerserver, system, hardwarekomponent eller netværk ved fejl eller unormal afslutning af den tidligere aktive applikation, server, system, hardwarekomponent eller netværk. Failover og switchover er i det væsentlige den samme operation, bortset fra at failover er automatisk og normalt fungerer uden varsel, mens switchover kræver menneskelig indgriben."
I databaseoperationer er omskiftning også et udtryk, der bruges for manuel failover, hvilket betyder, at det kræver en person at betjene failover. Failover er praktisk for enhver administrator, da det isolerer uønskede problemer såsom utilsigtet sletning/sletning af tabeller, lange timers nedetid, der forårsager forretningspåvirkning, databasekorruption eller korruption på systemniveau.
Database-failover består af mere end en enkelt databaseknude, enten fysisk eller virtuelt. Ideelt set, da failover kræver, at du skifter til en anden node, kan du lige så godt skifte til en anden databaseserver, hvis en vært kører flere databaseforekomster på en enkelt vært. Det kan stadig være enten switchover eller failover, men typisk er det mere redundans og høj tilgængelighed i tilfælde af, at en katastrofe opstår på den aktuelle vært.
MySQL-failover for Drupal
Udførelse af en failover for din Drupal-baserede applikation kræver, at de data, der håndteres af databasen, ikke adskiller sig eller adskilles. Der er flere tilgængelige løsninger, og vi har allerede diskuteret nogle af dem i tidligere Severalnines blogs. Du vil sandsynligvis gerne læse vores Introduktion til Failover for MySQL-replikering - 101-bloggen.
Master-slave-omstillingen
De mest almindelige tilgange til MySQL Failover er at bruge master-slave switch over eller den manuelle failover. Der er to tilgange, du kan gøre her:
- Du kan implementere din database med en typisk asynkron master-slave-replikering.
- eller kan implementere med asynkron master-slave-replikering ved hjælp af GTID-baseret replikering.
At skifte til en anden master kunne være hurtigere og nemmere. Dette kan gøres med følgende MySQL-syntaks:
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 */eller med GTID, kan du ganske enkelt gøre,
...
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_AUTO_POSITION = 1; /* master information to connect */
...
WitBrug af ikke-GTID-tilgangen kræver, at du først bestemmer masterens logfil og masterens logpos. Du kan bestemme dette ved at se på masterens status i masterknudepunktet, før du skifter.
mysql> MASTER STATUS;Du kan også overveje at hærde din server ved at tilføje sync_binlog =1 og innodb_flush_log_at_trx_commit =1, da du, i tilfælde af at din master går ned, vil have større chance for, at transaktioner fra master vil være usynkroniserede med din slave( s). I et sådant tilfælde har den promoverede master en større chance for at være en konsekvent datakildeknude.
Dette er dog muligvis ikke den bedste tilgang til din Drupal-database, da det kan medføre lange nedetider, hvis det ikke udføres korrekt, såsom at blive fjernet brat. Hvis din masterdatabaseknude oplever en fejl, der resulterer i, at en database går ned, skal du have dit program til at pege på en anden database, der venter på standby som din nye master eller ved at få din slave forfremmet til at være master. Du bliver nødt til at specificere præcis, hvilken node der skal overtage og derefter bestemme forsinkelsen og konsistensen af den node. At opnå dette er ikke så let som bare at gøre SET GLOBAL read_only=1; SKIFT MASTER TIL... (osv.), der er visse situationer, som kræver dybere analyse, idet man ser på de levedygtige transaktioner, der kræves for at være til stede på den standby-server eller forfremmede master for at få det gjort.
Drupal-failover ved hjælp af MHA
Et af de mest almindelige værktøjer til automatisk og manuel failover er MHA. Det har eksisteret i lang tid nu og bruges stadig af mange organisationer. Du kan tjekke disse tidligere blogs, vi har om emnet, top almindelige problemer med MHA og hvordan du løser dem eller MySQL High Availability Tools - Sammenligning af MHA, MRM og ClusterControl.
Drupal-failover ved hjælp af Orchestrator
Orchestrator er blevet bredt brugt nu og bliver brugt af store organisationer som Github og Booking.com. Det giver dig ikke kun mulighed for at administrere en failover, men også topologistyring, værtsopdagelse, refactoring og gendannelse. Der er en fin ekstern blog her, som jeg fandt det meget nyttigt at lære om dens failover-mekanisme med Orchestrator. Det er en blogserie i to dele; del et og del to.
Drupal-failover ved hjælp af MaxScale
MaxScale er ikke kun en belastningsbalancer designet til MariaDB-serveren, den udvider også høj tilgængelighed, skalerbarhed og sikkerhed for MariaDB, mens den på samme tid forenkler applikationsudviklingen ved at afkoble den fra den underliggende databaseinfrastruktur. Hvis du bruger MariaDB, så kan MaxScale være en relevant teknologi for dig. Tjek vores tidligere blogs om, hvordan du kan bruge MaxScale failover-mekanismen.
Drupal-failover ved hjælp af ClusterControl
Severalnines' ClusterControl tilbyder en bred vifte af databasestyrings- og overvågningsløsninger. En del af de løsninger, vi tilbyder, er automatisk failover, manuel failover og cluster/node recovery. Dette er meget nyttigt, som om det fungerer som din virtuelle databaseadministrator og giver dig besked i realtid, hvis din klynge er i "paniktilstand", alt imens gendannelsen styres af systemet. Du kan tjekke denne blog Sådan automatiseres databasefailover med ClusterControl for at lære mere om ClusterControl-failover.
Andre MySQL-løsninger
Nogle af de gamle tilgange er stadig anvendelige, når du vil failover. Der er MMM, MRM, eller du kan tjekke Group Replication eller Galera (bemærk:Galera bruger ikke asynkron, snarere synkron replikering). Failover i en Galera-klynge fungerer ikke på samme måde, som den gør med asynkron replikering. Med Galera kan du bare skrive til en hvilken som helst node, eller hvis du implementerer en master-slave-tilgang, kan du dirigere din ansøgning til en anden node, der vil være den aktive skribent for klyngen.
Drupal PostgreSQL-failover
Da Drupal understøtter PostgreSQL, vil vi også tjekke værktøjerne til at implementere en failover- eller switchover-proces for PostgreSQL. PostgreSQL bruger indbygget streamingreplikering, men du kan også indstille det til at bruge en logisk replikering (tilføjet som et kerneelement i PostgreSQL i version 10).
Drupal-failover ved hjælp af pg_ctlcluster
Hvis dit miljø er Ubuntu, er brug af pg_ctlcluster en enkel og nem måde at opnå failover. For eksempel kan du bare køre følgende kommando:
$ pg_ctlcluster 9.6 pg_7653 promoteeller med RHEL/Centos kan du bruge kommandoen pg_ctl ligesom,
$ sudo -iu postgres /usr/lib/postgresql/9.6/bin/pg_ctl promote -D /data/pgsql/slave/data
server promotingDu kan også udløse failover af en standby-server for logforsendelse ved at oprette en triggerfil med det filnavn og den sti, der er angivet af trigger_filen i recovery.conf.
Du skal være forsigtig med standby-promovering eller slavepromovering her, da du måske skal sikre dig, at kun én master accepterer læse-skriveanmodningen. Dette betyder, at mens du skifter, skal du muligvis sikre dig, at den tidligere master er blevet slækket eller stoppet.
At tage sig af switchover eller manuel failover fra primær til standby-server kan være hurtigt, men det kræver noget tid at genforberede failover-klyngen. Regelmæssig skift fra primær til standby er en nyttig praksis, da det giver mulighed for regelmæssig nedetid på hvert system til vedligeholdelse. Dette tjener også som en test af failover-mekanismen for at sikre, at den virkelig vil fungere, når du har brug for den. Skriftlige administrationsprocedurer anbefales altid.
Drupal PostgreSQL Automatisk Failover
I stedet for en manuel tilgang kan du kræve automatisk failover. Dette er især nødvendigt, når en server går ned på grund af hardwarefejl eller virtuel maskine korruption. Du kan også kræve, at et program automatisk udfører failover for at mindske nedetiden for din Drupal-applikation. Vi vil nu gennemgå nogle af disse værktøjer, som kan bruges til automatisk failover.
Drupal-failover ved hjælp af Patroni
Patroni er en skabelon, hvor du kan skabe din egen tilpassede, højtilgængelige løsning ved hjælp af Python og - for maksimal tilgængelighed - en distribueret konfigurationsbutik som ZooKeeper, etcd, Consul eller Kubernetes. Databaseingeniører, DBA'er, DevOps-ingeniører og SRE'er, der søger hurtigt at implementere HA PostgreSQL i datacentret - eller andre steder - vil forhåbentlig finde det nyttigt
Drupal-failover ved hjælp af Pgpool
Pgpool-II er en proxy-software, der sidder mellem PostgreSQL-serverne og en PostgreSQL-databaseklient. Bortset fra at have en automatisk failover, har den flere funktioner, der inkluderer forbindelsespooling, belastningsbalancering, replikering og begrænsning af de overskridende forbindelser. Du kan læse mere om dette værktøj er vores tredelte blog; del et, del to, del tre.
Drupal-failover ved hjælp af pglookout
pglookout er en PostgreSQL-replikeringsovervågning og failover-dæmon. pglookout overvåger databasenoderne, deres replikeringsstatus og handler i henhold til denne status. For eksempel at kalde en foruddefineret failover-kommando for at promovere en ny master i tilfælde af, at den forrige forsvinder.
pglookout understøtter to forskellige nodetyper, dem der er installeret på selve db noderne og observer noder der kan installeres hvor som helst. Formålet med at have pglookout på PostgreSQL DB-knuderne er at overvåge klyngens replikeringsstatus og handle i overensstemmelse hermed, observatørerne har et mere begrænset ansvar:de observerer blot klyngestatus for at give et andet synspunkt til klyngetilstanden.
Drupal-failover ved hjælp af repmgr
repmgr er en open source-værktøjspakke til styring af replikering og failover i en klynge af PostgreSQL-servere. Det forbedrer PostgreSQL's indbyggede hot-standby-funktioner med værktøjer til at konfigurere standby-servere, overvåge replikering og udføre administrative opgaver såsom failover eller manuelle switchover-operationer.
repmgr har leveret avanceret support til PostgreSQL's indbyggede replikeringsmekanismer, siden de blev introduceret i 9.0. Den nuværende repmgr-serie, repmgr 4, understøtter den seneste udvikling inden for replikeringsfunktionalitet introduceret fra PostgreSQL 9.3, såsom cascading-replikering, tidslinjeskift og basebackups via replikeringsprotokollen.
Drupal-failover ved hjælp af ClusterControl
ClusterControl understøtter automatisk failover for PostgreSQL. Hvis du har en hændelse, kan din slave automatisk blive forfremmet til masterstatus. Med ClusterControl kan du også implementere selvstændig, replikeret eller klynget PostgreSQL-database. Du kan også nemt tilføje eller fjerne en node med en enkelt handling.
Andre PostgreSQL Drupal Failover-løsninger
Der er helt sikkert automatiske failover-løsninger, som jeg måske er gået glip af på denne blog. Hvis jeg gjorde det, bedes du tilføje dine kommentarer nedenfor, så vi kan kende dine tanker og erfaringer med din implementering og opsætning til failover, især for Drupal-websteder eller -applikationer.
Yderligere løsninger til Drupal-failover
Mens de værktøjer, jeg har nævnt tidligere, helt sikkert håndterer løsningen på dine problemer med failover, kan tilføjelse af nogle værktøjer, der gør failoveren ret nemmere, sikrere og har en total isolation mellem dit databaselag, være tilfredsstillende.
Drupal-failover ved hjælp af ProxySQL
Med ProxySQL kan du bare pege dine Drupal-websteder eller applikationer til ProxySQL-serverværten, og den vil udpege, hvilken node der vil modtage skrivninger, og hvilke noder der vil modtage læsningerne. Magien sker gennemsigtigt i TCP-laget, og der kræves ingen ændringer til din applikation/website-konfiguration. Ud over det fungerer ProxySQL også som din load balancer for dine skrive- og læseanmodninger til din databasetrafik. Dette gælder kun, hvis du bruger MySQL-databasevarianter.
Drupal-failover ved hjælp af HAProxy med Keepalived
Brug af HAProxy og Keepalved tilføjer mere høj tilgængelighed og redundans i din Drupals database. Hvis du ønsker at failover, kan det gøres, uden at din applikation ved, hvad der sker i dit databaselag. Bare peg din applikation til den vrrp-IP, som du opsætter i din Keepalived, og alt vil blive håndteret med total isolation fra din applikation. At have en automatisk failover vil blive håndteret gennemsigtigt og ubevidst af din applikation, så der skal ikke ske ændringer, når f.eks. en katastrofe er opstået, og en gendannelse eller failover er blevet anvendt. Det gode ved denne opsætning er, at den er anvendelig til både MySQL- og PostgreSQL-databaser. Jeg foreslår, at du tjekker vores blog PostgreSQL Load Balancing ved hjælp af HAProxy &Keepalved for at lære mere om, hvordan du gør dette.
Alle ovenstående muligheder understøttes af ClusterControl. Du kan implementere eller importere databasen og derefter implementere ProxySQL, MaxScale eller HAProxy &Keepalved. Alt vil blive administreret, overvåget og vil blive sat op automatisk, uden at du behøver yderligere konfiguration. Det hele sker i baggrunden og skaber automatisk en klar til produktion.
Konklusion
Det kan være kompliceret at oprette et Drupal-websted eller -program, der altid er tændt, især hvis du forventer en stor mængde trafik. Hvis du har de rigtige værktøjer, den rigtige opsætning og den rigtige teknologistak, er det dog muligt at opnå høj tilgængelighed og redundans.
Og hvis du ikke gør det? Så vil ClusterControl konfigurere det og vedligeholde det for dig. Alternativt kan du oprette en opsætning ved hjælp af de teknologier, der er nævnt i denne blog, hvoraf de fleste er open source, gratis værktøjer, der imødekommer dine behov.