Beïnvloed door de COVID-19-pandemie, stappen veel mkb's/kmo's over naar online platforms. Face-to-face of fysieke lessen worden ook getroffen door deze pandemie en veel scholen en universiteiten stappen ook over op online en zijn op zoek naar tools die beschikbaar zijn om de studenten of leerlingen van dienst te blijven, zoals het onderwijs heeft niet te belemmeren. Een van de bekende platforms die beschikbaar zijn voor educatieve online of online leerdoeleinden is Moodle.
Wat is Moodle?
Moodle is open source software voor online leerbeheersystemen, of LMS (ook bekend als Virtual Learning Environment of ELE) onder de GPL-licentie. Het stelt docenten in staat om hun eigen privéwebsite te maken vol met dynamische cursussen die het leren altijd en overal uitbreiden. Moodle heeft alle ondersteuning met gemakkelijke toegang en functies voor docenten, studenten of beheerders.
Omdat het een open source en een gratis softwareplatform is, kunt u deze software gratis en zonder royalty's gebruiken, net als andere open source-software. De kosten worden alleen gemaakt wanneer deze software wordt gehost op een betaald hostingplatform of als u deze host met hun Moodle Cloud. Moodle is ook beschikbaar voor draagbare apparaten zoals mobieltjes of tablets.
Waarom heb je een zeer beschikbare database nodig?
In de jaren negentig werd een zeer eenvoudige oplossing voor High Availability (HA) uitgevonden, namelijk Heartbeat. Een Heartbeat-cluster kon in principe twee dingen doen:het bewaakte twee knooppunten (en niet meer dan twee) en het was geconfigureerd om een of meer services op die twee knooppunten te starten. Als het knooppunt dat momenteel de resources host, uitvalt, zijn de clusterresources op het resterende knooppunt opnieuw gestart. Hoewel de eerste release van Heartbeat geen controle had over de bronnen zelf, verandert dit tot de release van Heartbeat 2.0 in de vroege jaren 2000, waar het mogelijk is om meer dan twee knooppunten naar het cluster te beheren. In wezen omvat dit de staat van Linux HA-clustering die grotendeels is gebaseerd op Heartbeat 2.0. Vanaf dit moment werden veel HA-oplossingen beïnvloed en zijn ontwikkeld en gecreëerd om de uitvaltijd te minimaliseren, met name voor kritieke bronnen.
In hoge mate beschikbaar zijn betekent niet alleen het minimaliseren van de downtime. Het dekt ook de mate van verantwoordelijkheid om de diensten die u aanbiedt en beloofd aan uw klanten continu te kunnen exploiteren en onderhouden. Beschikbaar zijn voor de klanten betekent niet dat u ook in staat bent om op hen te reageren als ze hulp nodig hebben. Het moet uw bedrijfsapplicatie en -systeem volledig functioneel maken alsof het altijd de normale bedrijfstoestand is, zelfs als er een ongekende ramp heeft plaatsgevonden.
U kunt uw ELO-toepassing niet bedienen met Moodle terwijl uw database in onderhoud is. Als u slechts één databaseserver heeft, wat heel gebruikelijk is voor een eenvoudige en lichtgewicht installatie van toepassingen, stopt uw toepassing zodra de server uitvalt. Als u een databasecluster hebt die master-slave-replicatie gebruikt en vervolgens een ongekend incident tegenkomt dat op zijn beurt uw applicatie na het incident op twee masters schrijft, dan kan dat een enorme puinhoop zijn die op zijn beurt datacorruptie veroorzaakt voor uw hele zakelijke applicatie en gegevens laag. Als er op dat moment lopende betalingen waren, zou dat een enorme ramp kunnen zijn en veel werk met zich meebrengen bij het uitvoeren van gegevensherstel.
Waarom moet uw database maximaal beschikbaar zijn? Het is omdat het moet,
- In staat om onderhoud of geplande uitval mogelijk en binnen de toegestane onderhoudsperiode uit te voeren
- Uptime is van vitaal belang en moet downtime voorkomen wanneer dat nodig is
- SLA is in hogere mate belangrijk om een hoogwaardige klantenservice te bereiken
- Zorg voor continue service en bruikbaarheid
- Geen enkel storingspunt
- In staat om failover uit te voeren wanneer master breekt of crasht
- Vermijd een split-brain-scenario waarbij meerdere meesters tegelijkertijd als actieve schrijvers optreden
Het databasecluster bouwen
Nu we het belang hebben benadrukt van het hebben van HA als plan en als oplossing voor uw databasecluster, vooral voor PostgreSQL, laten we ons concentreren op het bouwen van het cluster van boven naar beneden om een zeer beschikbare setup klaar voor setup van Moodle-applicatie.
PostgreSQL installeren
Ten eerste, waarom PostgreSQL? PostgreSQL heeft grote voordelen in vergelijking met andere databases die door Moodle worden ondersteund. Het is een kwestie van voorkeur als ik het moet samenvatten, aangezien alle databases die door Moodle worden ondersteund, allemaal in staat zijn om de gegevens te verwerken en ook onderhevig zijn aan optimalisatie. Het hangt af van hoe bekwaam en ervaren u de database gebruikt. Maar om samen te vatten waarom PostgreSQL wordt gebruikt, het is een betrouwbare database en zijn geavanceerde open source-software, vooral in databases die kunnen worden vergeleken met andere leveranciers die eigendom zijn, zoals Oracle en MS SQL. Het ondersteunt query-parallellisme, kan grote of enorme databases beheren, heeft brede ondersteuning voor JSON en nog veel meer. U kunt het hier bekijken om redenen waarom u voor PostgreSQL kiest. Laten we nu verder gaan met het installeren van de PostgreSQL
Voor deze blog gebruiken we PostgreSQL 12 met Ubuntu 18.04 (Bionic Beaver). Vervolgens moet u voor High Availability-configuratie een primair en ten minste een standby-knooppunt (replica) hebben waarvoor het het overneemt zodra de master uitvalt.
- Stel de repository en ondertekeningssleutel in
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 - - Installeer de PG 12-server
# Update the package lists: sudo apt-get update # Install server and client apt install postgresql-12 postgresql-client-12
Doe dit ook op de doelreplica, maar u moet deze configureren als stand-by of replica. Als alternatief raad ik u aan ClusterControl te gebruiken en het te downloaden omdat het gratis is. Het zou sneller en sneller zijn om een primaire/standby-configuratie te installeren en in te stellen. Voor mijn installatie met ClusterControl en het gebruik van het tabblad Topologieweergave, kreeg ik de volgende topologie:
Met een master/slave- of primaire/standby-configuratie is dat niet het geval betekent dat u volledig gedekt bent voor een databasecluster met hoge beschikbaarheid. Het is nog niet erg beschikbaar. Zodra de primaire of master uitvalt, is er geen failover die onvermijdelijk plaatsvindt. Een ander ding is dat er geen evenwicht is tussen verbindingen van clients die naar de master gaan tegen de slave. Hoewel load balancing tussen de master/slave niet betekent dat het moet worden ingesteld of dat het moet worden toegepast om te voldoen aan een zeer beschikbare configuratie. Het hebben van een taakverdeling tussen de master/primaire en een slave/stand-by helpt uw master-node om hoge belastingprestaties te belasten, vooral bij zeer hoge verkeersuren.
Taakverdeling instellen
Zoals eerder vermeld, helpt load balancing tussen de master en slave je master om de belasting te selecteren. Het is niet ideaal als je je stand-by alleen laat gebruiken voor replicatie of het overneemt als de master uitvalt. Hoewel dat kan werken, brengt dat downtime en handmatig werk met zich mee als de master uitvalt, omdat je de rol van je standby-knooppunt moet overschakelen naar een master. Dat is ook prima, maar nogmaals, het hebben van een load balancer kan helpen om de schrijfbewerkingen naar de master te leiden en vervolgens de leesbewerkingen tussen de master en de slave te sturen. Dit biedt u in feite een lees-/schrijfsplitsing. Om dit te doen, zijn er veel opties waaruit u kunt kiezen met PostgreSQL. Kortom, de meest gebruikelijke maar toch eenvoudige installatie en een lichtgewicht is het gebruik van HAProxy.
Hoewel er opties zijn zoals het gebruik van PgBouncer of pgpool-II. Laten we voor de eenvoud van deze blog HAProxy gebruiken. Om HAProxy te installeren, is het vrij eenvoudig als u ClusterControl gebruikt. Laten we dat doen via ClusterControl. Om dat te doen, gaat u gewoon naar het tabblad Beheren, selecteert u Load Balancer zoals hieronder weergegeven,
Omdat we een zeer beschikbare configuratie voor uw PostgreSQL-databasecluster nodig hebben, we zouden ten minste twee knooppunten moeten hebben. Dus als uw primaire HAProxy-knooppunt uitvalt, kan de passieve of stand-by HAProxy het overnemen. Eens kijken hoe het er bij mij uitziet,
Hoewel dat er goed uitziet. Deze opzet is nog onvoldoende. Als u denkt dat we goed zijn voor een zeer beschikbare setup met die topologie, is er geen failover voor het geval de HAProxy uitvalt op knooppunt 192.168.30.222 op poort 9600 of als 192.168.30.223:9600 uitvalt en als uw toepassing daarop is ingesteld host, is er nog steeds downtime als er geen proactieve setup is gemaakt. Op die manier heb je downtime als het handmatig moet worden ingesteld. In dit geval zullen we Keepalive gebruiken en instellen zodat de HAProxy-instanties nauwlettend worden gecontroleerd op hun gezondheid en failover voor het geval het andere knooppunt een probleem tegenkomt.
De load balancers zeer beschikbaar houden
Nu we load balancers bovenop onze databases hebben, hebben we toch onze HAProxy nodig om altijd actief te zijn voor het geval het primaire knooppunt voor het applicatie-eindpunt uitvalt. Kortom, wat HAProxy kan doen met de setup die we hebben vanaf het vorige gedeelte, de applicaties kunnen de 192.168.30.223 of 192.168.30.222 gebruiken met respectievelijk poorten 5433 (lees-schrijfpoort) en 5434 (alleen-lezen poort). Nu is er een probleem voor het geval u moet overschakelen voor het geval de andere knooppunten uitvalt, en het slechte is dat u het bedrijf schade toebrengt omdat het uitvaltijd dekt als er geen automatische failover is om het op te lossen. Downtime vermijden is hier de beste manier, tenzij je een zeer lage SLA en een hoge RTO en RPO hebt.
Om een dergelijke ramp of downtime te voorkomen, raden we aan om Keepalived bovenop HAProxy te installeren. Kortom, HAProxy laadt de balans tussen lezen en schrijven, op voorwaarde dat je lees-schrijfsplitsing hebt en Keepalived bewaakt alleen de gezondheid van de HAProxy-knooppunten en slaagt erin om het meest gezonde knooppunt op te halen volgens de gewenste configuratie. Keepalived is een hulpmiddel dat u kunt gebruiken om de HAProxy-knooppunten te bewaken, hoewel het niet zo ingewikkeld is om databases te beheren. Keepalived gebruikt VIP (Virtual IP) dat wordt toegewezen aan het standaard primaire HAProxy-knooppunt en vervolgens dat VIP opnieuw toewijst in het geval dat het primaire HAProxy-knooppunt faalt en het verwijst naar het volgende of stand-by HAProxy-knooppunt.
Laten we dit nu instellen met ClusterControl, aangezien het sneller en gemakkelijker te beheren is met ClusterControl. Om dit te doen, is het in principe dezelfde aanpak als hoe we de HAProxy instellen, maar in plaats daarvan selecteren we Keepalive zoals hieronder weergegeven,
Kortom, als u de Keepalive handmatig installeert, selecteren we de primaire tegen de secundaire in het geval dat de primaire HAPRoxy faalt. Laten we eens kijken hoe onze topologieweergave eruitziet,
Dit ziet er veelbelovend uit. Kortom, de Moodle-toepassingsclient maakt verbinding met de VIP, d.w.z. 192.168.30.201 onder poorten 5433 (lees-schrijfpoort) en 5434 (alleen-lezen poort). Bijvoorbeeld, het verifiëren op een externe host die ik heb,
[[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)waaruit blijkt dat alleen het schrijversknooppunt dat ik heb, naar mijn hoofdknooppunt verwijst, d.w.z. 192.168.30.22. Dan moet mijn alleen-lezen-poort zowel naar de master- als de slave-node gaan, zoals hieronder weergegeven,
[[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)Hieruit blijkt dat zowel mijn primaire als standby-knooppunten worden geïdentificeerd als "lees database"-knooppunten.
Dit ziet er veelbelovend uit, zoals ik eerder heb gezegd. Toch ontbreekt hier een onderdeel dat eigenlijk heel belangrijk is. Er is geen database-failovermechanisme dat klaar is voor dit type installatie. Toch hebben we Keepalive die HAProxy bewaakt en vervolgens een failover uitvoert door de VIP om te schakelen voor het geval de primaire HAProxy faalt of sterft. Toch is Keepalive niet ingesteld om de complexe instellingen van PostgreSQL aan te kunnen. Er is een zeer fatsoenlijke beschikbaar en gratis om dit in te stellen. U kunt Slony-I gebruiken, een replicatiesysteem van derden.
Failovermechanisme hebben voor uw PostgreSQL-cluster
Er zijn manieren om een failover-mechanisme voor uw PostgreSQL te bieden. Slony-I of gewoonlijk gewoon Slony genoemd, is een van de meest gebruikte tools. Hoewel Slony vereist dat uw setup een logische replicatie moet zijn omdat er een publisher/abonnee-configuratie voor nodig is, is het misschien niet ideaal voor andere setups die een standaard streaming-replicatie gebruiken. Het nadeel van het gebruik van Slony is dat het geen automatische detectie biedt voor defecte systemen of geen ondersteuning voor node-fencing. Daarom wordt een gewoonlijk STONITH genoemd (schiet het andere knooppunt in het hoofd of schiet het mislukte knooppunt in het hoofd) die in feite de mislukte niet te vermijden split-brain-scenario's uitschakelt waarbij meerdere hoofdknooppunten (actieve schrijversknooppunten) schrijfbewerkingen accepteren op de dezelfde tijd. Hoewel dit op de juiste manier kan worden ingesteld, kan het toch tijdrovend en gecompliceerd zijn als het is gemaakt met minder ervaring en inzicht in welke scenario's er zullen gebeuren voor PostgreSQL wanneer zich een ramp voordoet. Voor Slony is het opgeven van vastgelegde transacties een zakelijke beslissing die niet door een databasesysteem kan worden genomen. Als iemand de onderstaande commando's in een script wil plaatsen dat automatisch wordt uitgevoerd vanuit het netwerkbewakingssysteem, dan laat je het aan je over dat het jouw gegevens en jouw failover-beleid is.
Als alternatief, als u op zoek bent naar zakelijke opties en toch uw geld kunt nemen tegen een redelijke prijs, dan heeft ClusterControl automatisch herstel voor PostgreSQL-clusters. Kortom, het automatische herstel beantwoordt de hierboven genoemde problemen met Slony. Hoewel ons automatisch herstel het best wordt getest met streamingreplicatie en alleen wordt ondersteund voor het type streamingreplicatie van PostgreSQL-configuratie. Dus hoe werkt het? In principe hoeft u alleen de knoppen voor automatisch herstel aan te zetten, zoals hieronder,
Dit ondersteunt node fencing, wat betekent dat het de falende node zal uitschakelen voor het geval dat het knooppunt gaat levend terug om een of andere reden die niet wordt verwacht. Afgezien daarvan ondersteunt het automatische herstel door ClusterControl knooppunt- en clusterherstel. Als een master- of slave-knooppunt per ongeluk werd afgesloten of gedood, zal ClusterControl proberen om dat nieuw leven in te blazen, vooral als het plaatsvindt buiten een geplande uitval- of onderhoudsperiode. Deze functie zorgt ervoor dat u niet meer bang bent voor de database en biedt u tegelijkertijd proactieve monitoring die u op de hoogte stelt van een mogelijke ramp voordat het te laat is om te herstellen.
Conclusie
Zeer beschikbare instellingen voor je databasecluster, vooral voor Moodle, kunnen variëren, afhankelijk van het type configuratie en de vereisten die je nodig hebt. Of het nu puur afhankelijk is van gratis en open source-technologieën of er zijn andere opties die het geld waard zijn om te investeren voor uw bedrijfstoepassing, zolang het budget het toelaat, omdat het u een win-winsituatie kan bieden, vooral als u alleen meer focus wilt aan de zakelijke kant van dingen dan focussen op andere tools zoals administratie en devops soort werk.