Open edX är en plattform för utbildningsaktiviteter online. Med tanke på den situation världen befinner sig i, möter alla sådana plattformar högre belastning och deras betydelse har ökat avsevärt. Det är inte bara "hjälparplattformarna" utan de blir ofta det huvudsakliga sättet på vilket utbildningsaktiviteter utförs. Detta leder till högre krav på belastningen de kan hantera eller tillgängligheten på plattformen.
Open edX är en komplex produkt som består av flera element. En av dem är MySQL-databasen. I den här korta bloggen vill vi diskutera hur du kan förbättra den höga tillgängligheten för Open edX-plattformen.
Självklart är den enda MySQL-databasen en enda felpunkt och som sådan är det inte ett tillvägagångssätt som lämpar sig för produktionsinstallationer. Det finns flera sätt på vilka du kan förbättra tillgängligheten för MySQL-databasen.
Till att börja med kan du köra master - slav-installationen med asynkron eller semisynkron replikering. Fördelen med det är att när mastern inte är tillgänglig kan du marknadsföra en av slavarna och fortsätta med operationen. Den främsta nackdelen med en sådan installation är att failover måste utföras antingen manuellt, vilket ökar driftstoppen eller så måste du använda någon extern programvara (till exempel ClusterControl), men det kan ändå ta lite tid. Slutligen är varje form av asynkron eller semisynkron replikering föremål för replikeringsfördröjning. Detta kan allvarligt påverka läs-efter-skriv-scenarierna där applikationen kör en skrivning på mastern och sedan omedelbart försöker läsa denna data från slaven.
En annan metod skulle vara att använda ett Galera-kluster för att lagra data från Open edX-plattformen. Vi kan börja med tre nodkluster - sådana kluster kan automatiskt hantera fel på en enda nod. De återstående två noderna kommer att fortsätta att fungera och vara lyhörda för frågor som kommer från applikationen. En annan fördel med Galera är att även om den är "nästan" synkron (vilket i stort sett betyder att den är nästan synkron), så finns det ett sätt att genomdriva kausalitetskontroller och tvinga in kluster till synkront läge (även om du betalar för det med minskad prestanda).
Båda scenarierna skulle kräva någon form av lastbalanserare framför sig, som skulle hantera trafiken och omdirigera den till en riktig destination.
Låt oss se hur ClusterControl kan hjälpa dig att distribuera ett Galera-kluster med en uppsättning lastbalanserare som du kan använda för din Open edX-plattform.
Distribuera MariaDB Cluster
Den här gången ska vi försöka använda MariaDB Cluster som vår backend. Återigen, det första steget är detsamma, vi måste välja "Deploy" från guiden:
När du har gjort det måste vi definiera SSH-anslutning, lösenordslös, nyckel -baserad SSH-åtkomst är ett krav för ClusterControl, annars kommer den inte att kunna hantera databasinfrastruktur.
Då bör vi besluta om leverantör, version, lösenord, värdar och några ytterligare inställningar:
Med alla dessa uppgifter ifyllda är vi bra att fortsätta med distributionen.
Distribuera ProxySQL
Databasen i sig är inte det enda elementet som vi vill distribuera. Vi behöver också en lastbalanserare som vi kommer att använda för att styra trafiken till de noder som är tillgängliga i det givna ögonblicket. Vi kommer också att använda den för att tillhandahålla läs/skrivdelning, och dirigera alla skrivningar till en enda MariaDB Galera-nod. Detta kommer att hjälpa oss att undvika konflikter mellan skrivningar som körs på olika Galera-noder.
För ProxySQL ClusterControl kräver också att du fyller i viss information - du måste välja värd för att installera den på, besluta om ProxySQL-version, autentiseringsuppgifter för de administrativa och övervakande användarna. Dessa användare kommer att användas för att hantera ProxySQL och övervaka tillståndet för ditt Galera-kluster. Du bör också importera befintliga databasanvändare eller skapa en ny för din applikation. Slutligen är det upp till dig att bestämma vilka databasnoder du vill använda med ProxySQL och bestämma om du använder implicita transaktioner.
Distribuera Keepalived
Som nästa steg kommer vi att distribuera Keepalived. Tanken här är att ha en virtuell IP som pekar på den fungerande ProxySQL-instansen. Sådan VIP kan sedan användas i applikationen som slutpunkt för MySQL-databasens anslutning.
Efter att ha skickat detaljer som ProxySQL-instanser som bör övervakas, virtuell IP och gränssnitt VIP ska binda till vi är redo att distribuera. Efter några minuter bör allt vara klart och topologin bör se ut som nedan:
Det är i stort sett det när det kommer till distributionen. Du kan peka din Open edX-plattform mot VIP och port 6033, detta borde vara tillräckligt för att få anslutning till din backend-databas. Den sista kvarvarande biten, om du skulle finna det nödvändigt, skulle vara att konfigurera kausalitetskontroller. Det finns en wsrep_sync_wait-variabel som kan göra just det. Den kan möjliggöra tester på flera åtkomstmönster:läser, uppdaterar, infogar, tar bort, ersätter och SHOW-kommandon. Om vi bara är intresserade av SELECT-frågorna kommer vi att ställa in denna variabel till '1' med ClusterControl-konfigurationshantering.
Detta kommer att utföra denna ändring på alla MariaDB Cluster-noder.
Det är ungefär det. Om du vill dela med dig av dina erfarenheter av Open edX är du välkommen att lämna en kommentar till oss.