Chamilo er, ligesom Open edX eller Moodle, en platform, der gør det muligt for uddannelsesinstitutioner at overføre deres uddannelsesaktiviteter til internettet. I betragtning af, at størstedelen af uddannelsesaktiviteten er flyttet online i det sidste år, er det ikke overraskende, at vi ser flere og flere mennesker, der kæmper for at skalere deres uddannelsesplatforme ud og sikre bedre tilgængelighed.
Chamilo er en platform bygget på *AMP-stakken, som består af Apache, MySQL og PHP. Som sædvanlig er databasen det sværeste element at migrere til et meget tilgængeligt miljø. I denne korte blog vil vi gerne diskutere, hvordan du kan forbedre den høje tilgængelighed af Chamilo-databasen.
Som du kan forestille dig, er den enkelte MySQL-database et enkelt fejlpunkt, og som sådan bør det undgås i produktionsinstallationerne. Heldigvis er der et par måder, hvorpå du kan forbedre tilgængeligheden af MySQL-databasen.
En af måderne du kan gribe problemet an på er at bruge en Galera Cluster. Den minimale udrulning bør bestå af tre noder - sådanne klynger kan automatisk håndtere svigt af en enkelt node. De resterende to noder vil fortsætte med at arbejde og reagere på forespørgsler, der kommer fra applikationen.
Denne opsætning ville kræve en slags belastningsbalancer foran Galera-klyngen. Dens opgave ville være at håndtere trafikken og omdirigere den til en rigtig destination.
Lad os se, hvordan ClusterControl kan hjælpe dig med at implementere en Galera Cluster med et sæt belastningsbalancere, som du kan bruge til din Chamilo-platform.
Implementering af MariaDB Cluster
Denne gang vil vi prøve at bruge MariaDB Cluster som vores backend. Chamilo understøtter MySQL 5.6 og nyere eller MariaDB 5.5 og nyere. Som det første trin skal vi vælge "Deploy" fra guiden:
Når vi har gjort det, skal vi definere SSH-forbindelse, adgangskodeløs, nøgle -baseret SSH-adgang er et krav for ClusterControl, ellers vil den ikke være i stand til at administrere databaseinfrastrukturen:den er afhængig af SSH-forbindelse til at udføre kommandoer for at starte eller stoppe tjenester, installere software og så videre.
Så bør vi beslutte os for leverandør, version, adgangskode, værter og nogle yderligere indstillinger:
Med alle disse detaljer udfyldt er vi gode til at fortsætte med implementeringen.
Implementering af ProxySQL
Som vi nævnte tidligere, er databasen i sig selv ikke det eneste element, vi ønsker at implementere. Vi kunne bruge en load balancer, som vi vil bruge til at flytte trafikken rundt, hvis en af knudepunkterne fejler. Vi vil også bruge det til at give læse/skrive-split, dirigere alle skrivninger til en enkelt MariaDB Galera-knude og opdele læsninger på tværs af resterende MariaDB Galera-noder. Dette vil hjælpe os med at undgå konflikter mellem skrivninger udført på forskellige Galera-knuder.
For ProxySQL ClusterControl kræver også at udfylde nogle oplysninger - du skal vælge vært for at installere det på, beslut dig for ProxySQL-version, legitimationsoplysninger til de administrative og overvågningsbrugere. Disse brugere vil blive brugt til at administrere ProxySQL og overvåge status for din Galera-klynge. Du bør også importere eksisterende databasebrugere eller oprette en ny til din applikation. Endelig er det op til dig at beslutte, hvilke databasenoder du vil bruge med ProxySQL og beslutte, om du bruger implicitte transaktioner.
Implementering af Keepalived
ProxySQL'en vil fungere godt ved at fordele vores trafik på tværs af klynge noder. På den anden side vil en enkelt ProxySQL-node fungere som et enkelt fejlpunkt. Derfor ønsker vi at implementere mindst to af dem. Så er spørgsmålet, hvordan man opdager fejlen i ProxySQL-knuden, og hvordan man flytter trafikken til en sund ProxySQL. Her kommer Keepalved. Ideen her er at have en virtuel IP, der peger på den fungerende ProxySQL-instans. En sådan VIP kan derefter bruges i applikationen som slutpunktet for MySQL-databaseforbindelsen, hvilket sikrer, at applikationen altid vil ramme sund ProxySQL, som igen vil sikre, at trafikken rammer den sunde klynge node.
Efter videregivelse af detaljer som ProxySQL-forekomster, der skal overvåges, Virtual IP og interface VIP skal binde til, vi er klar til at implementere. Efter et par minutter skulle alt være klar, og topologien skulle se ud som nedenfor:
Det er det, når det kommer til det miljø, vi byggede. Du kan pege din Chamilo mod VIP og port 6033, dette burde være nok til at få forbindelsen til din backend-database. Hvis du støder på problemer relateret til forældede læsninger (når skrivning rammer én knude, og derefter Chamilo forsøger at læse fra en anden knude, kan du undersøge aktivering af kausalitetstjek på Galera-klyngen. Der er en wsrep_sync_wait-variabel, der kan aktivere test på flere adgange mønstre:læser, opdaterer, indsætter, sletter, erstatter og VIS kommandoer. Hvis vi kun er interesseret i SELECT-forespørgslerne, sætter vi denne variabel til '1' ved hjælp af ClusterControl-konfigurationsstyring.
Dette vil udføre denne ændring på alle MariaDB Cluster-noder.
Det er stort set det. Hvis du gerne vil dele noget af din oplevelse med Chamilo, er du velkommen til at efterlade os en kommentar.