Påverkad av covid-19-pandemin går många små och medelstora företag över till onlineplattformar. Ansikte mot ansikte eller fysiska klasser påverkas också av denna pandemi och många skolor och universitet går också över till online och letar efter verktyg som är tillgängliga för att kunna användas för att fortsätta tjäna studenterna eller eleverna, eftersom utbildning har inte att hindras. En av de berömda plattformarna som är tillgängliga för utbildningsändamål online eller online är Moodle.
Vad är Moodle?
Moodle är en programvara med öppen källkod för hanteringssystem för onlineinlärning, eller LMS (även känd som Virtual Learning Environment eller VLE) under GPL-licensen. Det gör det möjligt för lärare att skapa sin egen privata webbplats fylld med dynamiska kurser som utökar lärandet, när som helst och var som helst. Moodle har all support med enkel åtkomst och funktioner för lärare, studenter eller administratörer.
Eftersom det är en öppen källkod och en gratis mjukvaruplattform kan du använda den här programvaran gratis och inga royaltyavgifter precis som annan programvara med öppen källkod. Kostnaderna uppstår endast när denna programvara är värd på en betald värdplattform, eller om du är värd för den med deras Moodle Cloud. Moodle är även tillgängligt för handhållna enheter som mobiler eller surfplattor.
Varför behöver du en mycket tillgänglig databas?
På 1990-talet uppfanns en mycket enkel lösning för High Availability (HA), nämligen Heartbeat. Ett Heartbeat-kluster kunde i princip göra två saker:det övervakade två noder (och inte fler än två), och det var konfigurerat att starta en eller flera tjänster på dessa två noder. Om noden som för närvarande var värd för resurserna gick ner, startade den om klusterresurserna på den återstående noden. Även om den initiala utgåvan av Heartbeat inte hade någon övervakning av själva resurserna förändras detta förrän Heartbeat 2.0 släpptes i början av 2000-talet där det tillåter att hantera mer än två noder till klustret. I grund och botten omfattar detta tillståndet för Linux HA-klustring som till stor del är baserat på Heartbeat 2.0. Från detta och framåt påverkades många HA-lösningar och har utvecklats och skapats för att minimera stilleståndstiden, särskilt för kritiska resurser.
Att vara mycket tillgänglig betyder inte bara att minimera stilleståndstiden. Det omfattar även graden av ansvar för att kontinuerligt kunna driva och underhålla de tjänster du erbjuder och utlovat till dina kunder. Att vara tillgänglig för kunderna betyder inte att du också kan svara dem om de behöver hjälp. Det måste sätta din affärsapplikation och ditt system till fullt fungerande som om det alltid är det normala tillståndet även om en aldrig tidigare skådad katastrof har inträffat.
Du kan inte använda din VLE-applikation med Moodle medan din databas är under underhåll. Om du bara har en enda databasserver, vilket är mycket vanligt för enkel och lätt applikationsinställning, så stannar din applikation när servern går ner. Om du har ett databaskluster som använder master-slave replikering då stöter på en aldrig tidigare skådad incident som i sin tur gör att din applikation skriver på två masters efter incidenten, då kan det vara en enorm röra som i sin tur orsakar datakorruption i hela din affärsapplikation och datalager. Om det fanns pågående betalningar som inträffade den gången, kan det bli en enorm katastrof och innebär mycket arbete när du utför dataåterställning.
Så varför måste din databas vara mycket tillgänglig? Det är för att det måste vara,
- Kan utföra underhåll eller planerat avbrott på ett praktiskt sätt och inom det tillåtna underhållsfönstret
- Drifttid är avgörande och måste undvika driftstopp vid behov
- SLA är viktigt för dess högre grad av grad för att uppnå högkvalitativ kundservice
- Ge kontinuerlig service och användbarhet
- Ingen enskild punkt av misslyckande
- Kan utföra failover när master går sönder eller kraschar
- Undvik scenarier med split-brain där flera mästare agerar som aktiva skribenter samtidigt
Bygga databasklustret
Nu när vi har betonat vikten av att ha HA som en plan och som en lösning för ditt databaskluster, speciellt för PostgreSQL, låt oss fokusera på att bygga klustret från topp till botten för att uppnå en mycket tillgänglig installation redo för Moodle-applikationsinstallation.
Installera PostgreSQL
För det första, varför PostgreSQL? PostgreSQL har stora fördelar jämfört med andra databaser som stöds av Moodle. Det är en fråga om preferens om jag måste sammanfatta eftersom alla databaser som stöds av Moodle alla är kapabla att hantera data och är föremål för optimering också. Det beror på hur skicklig och erfaren du använder databasen. Men för att sammanfatta varför man använder PostgreSQL, är det en pålitlig databas och dess sofistikerade programvara med öppen källkod, särskilt i databaser som kan jämföras med andra leverantörer som är proprietära, såsom Oracle och MS SQL. Det stöder frågeparallellism, kan hantera stora eller enorma databaser, har brett stöd för JSON och mycket mer. Du kan kolla in det här för skäl till varför du ska välja PostgreSQL. Låt oss nu fortsätta med att installera PostgreSQL
För den här bloggen kommer vi att använda PostgreSQL 12 med Ubuntu 18.04 (Bionic Beaver). Sedan, för hög tillgänglighetsinstallation, måste du ha en primär och åtminstone en standby-nod (replika) som den kommer att ta över när mastern går ner.
- Konfigurera arkivet och signeringsnyckeln
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 - - Installera PG 12-servern
# Update the package lists: sudo apt-get update # Install server and client apt install postgresql-12 postgresql-client-12
Gör detta på målrepliken också, men du måste konfigurera den som standby eller replik. Alternativt föreslår jag att du använder ClusterControl och laddar ner det eftersom det är gratis. Det skulle vara snabbare och snabbare att installera och ställa in en primär/standby-inställning. För min installation med ClusterControl och med fliken Topologivy fick jag följande topologi:
Om den har en master/slave eller primär/standby-inställning, har den inte innebär att du är helt täckt för ett högtillgängligt databaskluster. Det är ännu inte mycket tillgängligt. När den primära eller mastern går ner, finns det ingen failover som kommer att inträffa. En annan sak är att det inte finns någon balansering av anslutningar från klienter som går till mastern mot slaven. Även om lastbalansering mellan master/slav inte innebär att den måste ställas in eller så måste den tillämpas för att uppfylla en högt tillgänglig inställning. Att ha en lastbalansering mellan master/primär och en slav/standby hjälper din masternod från att stressa ut hög lastprestanda, särskilt under mycket höga trafiktimmar.
Ställa in lastbalansering
Som nämnts tidigare hjälper lastbalansering mellan master och slav din master från att särskilja lasten. Det är inte idealiskt om du låter din standby bara användas för replikering eller tar över om mastern går ner. Även om det kan fungera, innebär det dock driftstopp och manuellt arbete om master går ner, eftersom du måste byta över rollen som din standby-nod till en master. Det är också bra, men återigen, att ha en lastbalanserare kan hjälpa till att rikta skrivningarna till mastern och sedan rikta läsningarna mellan mastern och slaven. Detta ger dig i princip läs/skrivdelning. För att göra detta finns det många alternativ du kan välja mellan med PostgreSQL. I grund och botten är den vanligaste men enkla installationen och en lättviktare att använda HAProxy.
Även om det finns alternativ som att använda PgBouncer eller pgpool-II. För att förenkla den här bloggen, låt oss använda HAProxy. För att installera HAProxy är det ganska enkelt om du använder ClusterControl. Låt oss göra det via ClusterControl. För att göra det kan du bara gå till fliken Hantera, välj Load Balancer som visas nedan,
Eftersom vi behöver ha en mycket tillgänglig installation för ditt PostgreSQL-databaskluster, vi bör ha minst två noder. Så om din primära HAProxy-nod går ner, kan den passiva eller standby-HAProxyn ta över. Låt oss se hur det ser ut hos mig,
Även om det ser bra ut. Denna inställning är fortfarande otillräcklig. Om du tror att vi är bra för en mycket tillgänglig installation med den topologin, finns det ingen failover om HAProxy går ner på nod 192.168.30.222 vid port 9600 eller om 192.168.30.223:9600 går ner och om din applikation är inställd på det värd, det finns fortfarande driftstopp om ingen proaktiv installation har gjorts. På så sätt har du driftstopp om det måste ställas in manuellt. I det här fallet kommer vi att använda och ställa in Keepalived för att HAProxy-instanserna ska övervakas noggrant med avseende på dess hälsa och failover om den andra noden stöter på ett problem.
Hålla lastbalanserarna mycket tillgängliga
Nu när vi har lastbalanserare ovanpå våra databaser behöver vi ändå vår HAProxy för att alltid vara vid liv ifall den primära noden för applikationens slutpunkt går ner. I grund och botten, vad HAProxy kan göra med inställningarna vi har från föregående avsnitt, kan applikationerna använda 192.168.30.223 eller 192.168.30.222 med portarna 5433 (läs-skrivport) respektive 5434 (skrivskyddad port). Nu är det krångel om du behöver byta om de andra noderna går ner, plus det dåliga är att du skadar verksamheten eftersom det täcker driftstopp om det inte finns någon automatisk failover för att hantera det. Att undvika stillestånd är den bästa vägen hit om du inte har en mycket låg SLA och en hög RTO och RPO.
För att lindra en sådan katastrof eller driftstopp föreslår vi att du ställer in Keepalived ovanpå HAProxy. I grund och botten kommer HAProxy att ladda balansen mellan läsning och skrivning förutsatt att du läs-skriv-delning och Keepalved övervakar bara hälsan hos HAProxy-noderna och kommer att lyckas plocka upp den mest hälsosamma noden enligt dess önskade konfiguration. Keepalived är ett verktyg som du kan använda för att göra HAProxy-noderna som ska övervakas, även om det inte är lika komplicerat att hantera databaser. Keepalived använder VIP (Virtual IP) som tilldelar den primära HAProxy-noden som standard och sedan omtilldelar den VIP-enheten om den primära HAProxynoden misslyckas och pekar den till den efterföljande HAProxy-noden eller standby-noden.
Låt oss nu ställa in detta med ClusterControl eftersom det är snabbare och enklare att hantera med ClusterControl. För att göra detta är det i princip samma tillvägagångssätt som hur vi ställer in HAProxy men väljer istället Keepalived som visas nedan,
I grund och botten, om du installerar Keepalived manuellt, väljer vi den primära mot den sekundära om primär HAProxy misslyckas. Låt oss se hur vår topologivy ser ut,
Detta kan se mycket lovande ut. I princip kommer Moodle-applikationsklienten att ansluta till VIP, dvs. 192.168.30.201 under portarna 5433 (läs-skrivport) och 5434 (skrivskyddad port). Till exempel att verifiera det på en extern värd jag 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)som avslöjar att endast skribentnoden jag har pekar på min masternod, dvs 192.168.30.22. Sedan måste min skrivskyddade port gå till både master- och slavnoder som visas nedan,
[[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)Detta avslöjar att både mina primära noder och standbynoder identifieras som "läs databas"-noder.
Nu ser det här väldigt lovande ut som det jag har sagt tidigare. Ändå saknas det en del här som faktiskt är mycket viktig. Det finns ingen mekanism för failover för databasen som är redo för den här typen av installation. Ändå har vi Keepalived som övervakar HAProxy och sedan gör en failover genom att byta VIP om den primära HAProxyn misslyckas eller dör. Ändå är Keepalived inte inställt för att hantera den komplexa installationen som PostgreSQL har. Det finns en mycket anständig som är tillgänglig och gratis att ställa in den här. Du kan använda Slony-I, ett replikeringssystem från tredje part.
Att ha failover-mekanism för ditt PostgreSQL-kluster
Det finns sätt att tillhandahålla en failover-mekanism för din PostgreSQL. Slony-I eller vanligen kallad som bara Slony är ett av de vanligaste verktygen som används. Även om Slony kräver att din installation måste vara en logisk replikering eftersom den kräver en utgivare/prenumerantinstallation, kanske den inte är idealisk för andra installationer som använder en standard strömmande replikering. Nackdelen med att använda Slony är att det inte ger någon automatisk detektering för misslyckade system eller inget stöd för nodfäktning. Därför, en vanligen kallad STONITH (skjut den andra noden i huvudet eller skjut den misslyckade noden i huvudet) som i princip slår av den misslyckade att inte undvika scenarier med split-brain där flera masternoder (aktiva skribentnoder) accepterar skrivningar vid samma tid. Även om detta kan ställas in på rätt sätt, men det kan ändå vara tidskrävande och komplicerat om det skapas med mindre erfarenhet och insikter om vilka scenarier som kommer att hända för PostgreSQL när en katastrof inträffar. För Slony är att överge begångna transaktioner ett affärsbeslut som inte kan tas av ett databassystem. Om någon vill lägga in kommandona nedan i ett skript som körs automatiskt från nätverksövervakningssystemet, överlåter det bara till ditt eget förfogande att det är din data och det är din failover-policy.
Alternativt, om du letar efter företagsalternativ men ändå kan ta dina pengar till en rimlig kostnad, så har ClusterControl automatisk återställning för PostgreSQL-kluster. I grund och botten svarar den automatiska återställningen på problemen som anges ovan med Slony. Även om vår automatiska återställning testas bäst med strömmande replikering och endast stöds för strömmande replikering av typen PostgreSQL-installation. Så hur fungerar det? I grund och botten behöver du bara slå på knapparna för automatisk återställning precis som nedan,
Detta stöder nodstängsel, vilket betyder att det kommer att slå av den misslyckade noden i fall noden återgår till liv av någon anledning som inte är förutsedd. Bortsett från det stöder den automatiska återställningen av ClusterControl nod- och klusteråterställning. Om en master- eller slavnod av misstag stängdes av eller dödades, kommer ClusterControl att försöka återuppliva det, särskilt om det inträffar utanför ett planerat avbrott eller underhållsfönster. Den här funktionen skyddar dig från att ha utmattad databasrädsla och ger dig samtidigt proaktiv övervakning som kommer att meddela dig om en eventuell katastrof kan inträffa innan det är för sent att återhämta sig.
Slutsats
Mycket tillgängliga inställningar för ditt databaskluster, speciellt för Moodle, kan variera beroende på vilken typ av inställningar och krav du behöver. Oavsett om det är helt beroende av gratis och öppen källkodsteknik eller om det finns andra alternativ som är värda pengarna att investera för din företagsapplikation så länge budgeten rymmer eftersom det kan ge dig en win-win-situation, särskilt om du bara vill ha mer fokus på affärssidan än att fokusera på andra verktyg som administration och devops typ av arbete.