Påvirket af COVID-19-pandemien går mange SMB'er/SMV'er over til onlineplatforme. Ansigt til ansigt eller fysiske klasser er også berørt af denne pandemi, og mange skoler og universiteter går også over til online og leder efter værktøjer, der er tilgængelige til at blive brugt, så de kan fortsætte med at tjene de studerende eller eleverne, som uddannelse har ikke at blive hæmmet. En af de berømte platforme, der er tilgængelige til pædagogisk online eller online læringsformål, er Moodle.
Hvad er Moodle?
Moodle er en open source-software til online læringsstyringssystem eller LMS (også kendt som Virtual Learning Environment eller VLE) under GPL-licensen. Det gør det muligt for undervisere at skabe deres egen private hjemmeside fyldt med dynamiske kurser, der udvider læring, når som helst og hvor som helst. Moodle har en komplet support med nem adgang og funktioner for lærere, studerende eller administratorer.
Da det er en open source og en gratis softwareplatform, kan du bruge denne software gratis og uden royaltygebyrer ligesom anden open source-software. Omkostningerne påløber kun, når denne software hostes på en betalt hostingplatform, eller hvis du hoster den med deres Moodle Cloud. Moodle er også tilgængelig til håndholdte enheder såsom mobil eller tablets.
Hvorfor har du brug for en meget tilgængelig database?
I 1990'erne blev en meget simpel løsning til High Availability (HA) opfundet, nemlig Heartbeat. En Heartbeat-klynge kunne grundlæggende gøre to ting:den overvågede to noder (og ikke mere end to), og den var konfigureret til at starte en eller flere tjenester på disse to noder. Hvis den node, der i øjeblikket var vært for ressourcerne, gik ned, genstartede den klyngressourcerne på den resterende node. Selvom den første udgivelse af Heartbeat ikke havde nogen overvågning af selve ressourcerne, ændrede dette sig indtil udgivelsen af Heartbeat 2.0 i begyndelsen af 2000'erne, hvor det tillader at administrere mere end to noder til klyngen. Grundlæggende omfatter dette tilstanden af Linux HA-klynger, som i vid udstrækning er baseret på Heartbeat 2.0. Fra dette og fremefter blev en masse HA-løsninger påvirket og er blevet udviklet og skabt for at minimere nedetiden, især for kritiske ressourcer.
At være yderst tilgængelig betyder ikke kun at minimere nedetiden. Det dækker også graden af ansvar for løbende at kunne drive og vedligeholde de services, du tilbyder og lovede dine kunder. At være tilgængelig for kunderne betyder ikke, at du også er i stand til at reagere på dem, hvis de har brug for hjælp. Det skal sætte din virksomhedsapplikation og dit system til at fungere fuldt ud, som om det altid er den normale driftstilstand, selvom der er sket en hidtil uset katastrofe.
Du kan ikke betjene dit VLE-program ved hjælp af Moodle, mens din database er under vedligeholdelse. Hvis du kun har en enkelt databaseserver, hvilket er meget almindeligt for enkel og let applikationsopsætning, stopper din applikation, når serveren går ned. Hvis du har en databaseklynge, der bruger master-slave-replikering, så støder på en hidtil uset hændelse, som igen viser, at din applikation skriver på to mastere efter hændelsen, så kan det være et stort rod, som igen forårsager datakorruption i hele din forretningsapplikation og datalag. Hvis der var løbende betalinger, der fandt sted dengang, kunne det være en kæmpe katastrofe og involverer en stor mængde arbejde, når du udfører datagendannelse.
Så hvorfor skal din database være meget tilgængelig? Det er fordi det skal være,
- I stand til at udføre vedligeholdelse eller planlagt afbrydelse gennemførligt og på det tilladte vedligeholdelsesvindue
- Opetid er afgørende og skal undgå nedetid, når det er nødvendigt
- SLA er vigtigt for dets højere grad af grad for at opnå kundeservice af høj kvalitet
- Lyd kontinuerlig service og brugervenlighed
- Intet enkelt fejlpunkt
- I stand til at udføre failover, når master går i stykker eller går ned
- Undgå scenarier med split-brain, hvor flere mestre optræder som aktive forfattere på samme tid
Opbygning af databaseklyngen
Nu hvor vi har understreget vigtigheden af at have HA som en plan og som en løsning for din databaseklynge, især for PostgreSQL, så lad os fokusere på at bygge klyngen fra top til bund for at opnå en høj tilgængelig opsætning klar til opsætning af Moodle-applikationen.
Installation af PostgreSQL
For det første, hvorfor PostgreSQL? PostgreSQL har store fordele sammenlignet med andre databaser understøttet af Moodle. Det er et spørgsmål om præference, hvis jeg skal opsummere, da alle databaser understøttet af Moodle alle er i stand til at håndtere dataene og også er genstand for optimering. Det afhænger af, hvor dygtig og erfaren du bruger databasen. Selvom for at opsummere, hvorfor man bruger PostgreSQL, er det en pålidelig database og dens sofistikerede open source-software, især i databaser, som kan sammenlignes med andre leverandører, der er proprietære, såsom Oracle og MS SQL. Det understøtter forespørgselsparallelisme, er i stand til at administrere store eller enorme databaser, har bred understøttelse af JSON og meget mere. Du kan tjekke det ud her for grunde til at vælge PostgreSQL. Lad os nu fortsætte med at installere PostgreSQL
Til denne blog bruger vi PostgreSQL 12 ved hjælp af Ubuntu 18.04 (Bionic Beaver). Derefter skal du til opsætning af høj tilgængelighed have en primær og mindst en standby-node (replika), som den vil tage over, når masteren går ned.
- Opsæt lageret og signeringsnøglen
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/postgresql.list' wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - - Installer PG 12-serveren
# Update the package lists: sudo apt-get update # Install server and client apt install postgresql-12 postgresql-client-12
Gør dette også på målreplikaen, men du skal konfigurere den som en standby eller en replika. Alternativt foreslår jeg, at du bruger ClusterControl og downloader det, da det er gratis. Det ville være hurtigere og hurtigere at installere og konfigurere en primær/standby-opsætning. Til min opsætning ved hjælp af ClusterControl og ved at bruge fanen Topologivisning, fik jeg følgende topologi:
Med en master/slave eller primær/standby-opsætning, har den ikke betyder, at du er fuldt ud dækket af en høj tilgængelig databaseklynge. Det er endnu ikke meget tilgængeligt. Når den primære eller master går ned, er der ingen failover, der er bundet til at forekomme. En anden ting er, at der ikke er nogen balancering af forbindelser fra klienter, der går til masteren mod slaven. Selvom belastningsbalancering mellem master/slave ikke medfører, at den skal konfigureres, eller den skal anvendes for at opfylde en høj tilgængelig opsætning. At have en belastningsbalancering mellem master/primær og en slave/standby hjælper din masterknude med at stresse høj belastningsydelse, især på meget høje trafiktimer.
Opsætning af belastningsbalancering
Som tidligere nævnt hjælper belastningsbalancering mellem masteren og slaven din master med at udskille belastningen. Det er ikke ideelt, hvis du lader din standby kun bruges til replikering eller vil tage over, hvis masteren går ned. Selvom det kan fungere, medfører det dog nedetid og manuelt arbejde, hvis master går ned, da du skal skifte rollen som din standby node til en master. Det er også fint, men igen, at have en load balancer kan hjælpe med at dirigere skrivningerne til masteren og derefter dirigere læsningerne mellem masteren og slaven. Dette giver dig grundlæggende læse/skrive-opdeling. For at gøre dette er der en masse muligheder, du kan vælge imellem med PostgreSQL. Dybest set er den mest almindelige, men enkle opsætning og en letvægter ved at bruge HAProxy.
Selvom der er muligheder såsom at bruge PgBouncer eller pgpool-II. For at gøre denne blog nemmere, lad os bruge HAProxy. For at installere HAProxy er det ret ligetil, hvis du bruger ClusterControl. Lad os gøre det via ClusterControl. For at gøre det kan du bare gå til fanen Administrer, vælg Load Balancer som vist nedenfor,
Da vi skal have en meget tilgængelig opsætning til din PostgreSQL-databaseklynge, vi skal have mindst to noder. Så hvis din primære HAProxy-knude går ned, så kan den passive eller standby-HAProxy tage over. Lad os se, hvordan det ser ud hos mig,
Selvom det ser godt ud. Denne opsætning er stadig utilstrækkelig. Hvis du mener, vi er gode til en meget tilgængelig opsætning med den topologi, er der ingen failover i tilfælde af, at HAProxy går ned på node 192.168.30.222 ved port 9600, eller hvis 192.168.30.223:9600 går ned, og hvis din applikation er sat op til det vært, er der stadig nedetid, hvis der ikke er foretaget en proaktiv opsætning. På den måde har du nedetid, hvis det skal konfigureres manuelt. I dette tilfælde vil vi bruge og konfigurere Keepalived, så HAProxy-forekomsterne bliver nøje overvåget for deres helbred og failover, hvis den anden node støder på et problem.
Sådan holdes belastningsbalancererne yderst tilgængelige
Nu hvor vi har belastningsbalancere oven på vores databaser, har vi alligevel brug for, at vores HAProxy altid er i live, hvis den primære node for applikationens slutpunkt går ned. Grundlæggende, hvad HAProxy kan gøre med den opsætning, vi har fra det foregående afsnit, kan applikationerne bruge 192.168.30.223 eller 192.168.30.222 med henholdsvis portene 5433 (læse-skriveport) og 5434 (skrivebeskyttet port). Nu er der et besvær, hvis du skal skifte, hvis de andre noder går ned, plus den dårlige ting er, at du skader virksomheden, da det dækker nedetid, hvis der ikke er nogen automatisk failover til at håndtere det. At undgå nedetid er den bedste rute her, medmindre du har en meget lav SLA og en høj RTO og RPO.
For at afhjælpe en sådan katastrofe eller nedetid foreslår vi at konfigurere Keepalived oven på HAProxy. Grundlæggende vil HAProxy indlæse balance mellem læsning og skrivning, forudsat at du læser-skriver opdeling, og Keepalved overvåger kun HAProxy-knudernes sundhed og vil formår at opfange den mest sunde knude i henhold til dens ønskede konfiguration. Keepalived er et værktøj, du kan bruge til at få HAProxy-noder til at blive overvåget, selvom det ikke er så kompliceret at administrere databaser. Keepalved bruger VIP (Virtual IP), som tildeler den primære HAProxy-knude som standard og derefter gentildeler denne VIP, hvis den primære HAProxy-knude svigter og peger den til den efterfølgende eller standby-HAProxy-knude.
Lad os nu sætte dette op ved hjælp af ClusterControl, da det er hurtigere og nemmere at administrere med ClusterControl. For at gøre dette er det grundlæggende den samme tilgang, som vi konfigurerer HAProxy, men vælger i stedet Keepalived som vist nedenfor,
Grundlæggende, hvis du installerer Keepalived manuelt, vælger vi den primære mod den sekundære, hvis primær HAProxy fejler. Lad os se, hvordan vores Topologi-visning ser ud,
Dette ser måske meget lovende ud. Grundlæggende vil Moodle-applikationsklienten oprette forbindelse til VIP, dvs. 192.168.30.201 under portene 5433 (læse-skriveport) og 5434 (skrivebeskyttet port). For eksempel at verificere det på en ekstern vært, jeg har,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5433
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)hvilket afslører, at kun den forfatterknude, jeg har, peger på min masterknude, dvs. 192.168.30.22. Så skal min skrivebeskyttede port gå til både master og slave noder som vist nedenfor,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)
postgres=# \q
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.222
(1 row)Dette afslører, at både mine primære og standby noder er identificeret som "læse database" noder.
Nu ser dette meget lovende ud, som det jeg har sagt tidligere. Alligevel mangler der en del her, som faktisk er meget vigtig. Der er ingen database-failover-mekanisme, der er klar til denne type opsætning. Alligevel har vi Keepalved, der overvåger HAProxy og derefter laver en failover ved at skifte VIP, hvis den primære HAProxy fejler eller dør. Keepalived er dog ikke sat op til at håndtere den komplekse opsætning, som PostgreSQL har. Der er en meget anstændig en, der er tilgængelig og gratis at sætte dette op. Du kan bruge Slony-I, et tredjepartsreplikeringssystem.
At have failover-mekanisme til din PostgreSQL-klynge
Der er måder at give en failover-mekanisme til din PostgreSQL. Slony-I eller almindeligvis kaldet som bare Slony er et af de almindelige værktøjer, der bruges. Selvom Slony kræver, at din opsætning skal være en logisk replikering, da den kræver en udgiver-/abonnentopsætning, er den muligvis ikke ideel til andre opsætninger, der bruger en standard streamingreplikering. Ulempen ved at bruge Slony er, at det ikke giver nogen automatisk detektion af fejlbehæftede systemer eller ingen støtte til knudehegn. Derfor er en almindeligvis kaldet STONITH (skyd den anden knude i hovedet eller skyd den mislykkede knude i hovedet), som dybest set slår den mislykkede for ikke at undgå split-brain scenarier, hvor flere masterknuder (aktive forfatterknudepunkter) accepterer skrivninger ved samme tid. Selvom dette kan konfigureres korrekt, men det kan stadig være tidskrævende og kompliceret, hvis det er skabt med mindre erfaring og indsigt i, hvilke scenarier der er bundet til at ske for PostgreSQL, når en katastrofe opstår. For Slony er det at opgive forpligtede transaktioner en forretningsbeslutning, der ikke kan træffes af et databasesystem. Hvis nogen ønsker at indsætte kommandoerne nedenfor i et script, der udføres automatisk fra netværksovervågningssystemet, så overlader det bare til din egen rådighed, at det er dine data, og det er din failover-politik.
Alternativt, hvis du leder efter virksomhedsmuligheder og alligevel kan tage dine penge til en rimelig udgift, så har ClusterControl automatisk gendannelse til PostgreSQL-klynger. Grundlæggende besvarer den automatiske gendannelse de problemer, der er nævnt ovenfor med Slony. Selvom vores automatiske gendannelse bedst testes med streaming-replikering og kun understøttes for streaming-replikeringstypen PostgreSQL-opsætning. Så hvordan virker det? Dybest set skal du bare tænde for autogendannelsesknapperne ligesom nedenfor,
Dette understøtter nodehegn, hvilket betyder, at det vil slå den fejlende node af i tilfælde af knudepunktet bliver levende igen af en eller anden grund, der ikke er forventet. Bortset fra det understøtter den automatiske gendannelse af ClusterControl node- og klyngendannelse, at hvis en master- eller slaveknude ved et uheld blev lukket eller dræbt, vil ClusterControl forsøge at genoplive det, især hvis det sker uden for et planlagt udfald eller vedligeholdelsesvindue. Denne funktion beskytter dig mod at have slidt op af databasefrygt og giver dig samtidig proaktiv overvågning, som vil give dig besked om en mulig katastrofe, før det er for sent at komme sig.
Konklusion
Højt tilgængelige opsætninger til din databaseklynge, især til Moodle, kan variere afhængigt af hvilken type opsætning og krav du har brug for. Uanset om det udelukkende er afhængigt af gratis og open source-teknologier, eller der er andre muligheder, der er pengene værd at investere i din virksomhedsapplikation, så længe budgettet kan rumme, da det kan give dig en win-win situation, især hvis du kun ønsker mere fokus på den forretningsmæssige side af tingene end at fokusere på andre værktøjer såsom administration og devops type arbejde.