Colpite dalla pandemia di COVID-19, molte PMI/PMI stanno passando alle piattaforme online. Anche le lezioni in presenza o fisiche sono colpite da questa pandemia e anche molte scuole e università stanno passando all'online e sono alla ricerca di strumenti disponibili da utilizzare per continuare a servire gli studenti o gli alunni, poiché l'istruzione ha per non essere ostacolato. Una delle famose piattaforme disponibili per scopi educativi online o di apprendimento online è Moodle.
Cos'è Moodle?
Moodle è un software open source per il sistema di gestione dell'apprendimento online, o LMS (noto anche come Virtual Learning Environment o VLE) con licenza GPL. Consente agli educatori di creare il proprio sito Web privato pieno di corsi dinamici che estendono l'apprendimento, sempre e ovunque. Moodle ha un supporto completo con facile accesso e funzionalità per insegnanti, studenti o amministratori.
Dato che si tratta di una piattaforma software open source e gratuita, puoi utilizzare questo software gratuitamente e senza costi di royalty, proprio come altri software open source. I costi vengono sostenuti solo quando questo software è ospitato su una piattaforma di hosting a pagamento o se lo stai ospitando con il loro Moodle Cloud. Moodle è disponibile anche per dispositivi palmari come cellulari o tablet.
Perché hai bisogno di un database ad alta disponibilità?
Negli anni '90 è stata inventata una soluzione molto semplice per l'alta disponibilità (HA), ovvero Heartbeat. Un cluster Heartbeat sostanzialmente può fare due cose:monitora due nodi (e non più di due) ed è configurato per avviare uno o più servizi su quei due nodi. Se il nodo che ospitava attualmente le risorse si è interrotto, ha riavviato le risorse del cluster sul nodo rimanente. Sebbene la versione iniziale di Heartbeat non prevedesse il monitoraggio delle risorse stesse, ciò cambia fino al rilascio di Heartbeat 2.0 all'inizio degli anni 2000, dove consente di gestire più di due nodi nel cluster. Fondamentalmente, questo comprende lo stato del clustering HA di Linux che si basa in gran parte su Heartbeat 2.0. Da questo momento in poi, molte soluzioni HA sono state interessate e sono state sviluppate e create per ridurre al minimo i tempi di inattività, soprattutto per le risorse critiche.
Essere altamente disponibili non significa solo ridurre al minimo i tempi di inattività. Copre anche il grado di responsabilità di essere in grado di operare e mantenere continuamente i servizi che offri e prometti ai tuoi clienti. Essere a disposizione dei clienti non significa anche essere in grado di rispondere a loro nel caso abbiano bisogno di aiuto. Deve mettere l'applicazione e il sistema aziendali in piena funzionalità come se fosse sempre il normale stato delle operazioni anche se si è verificato un disastro senza precedenti.
Non puoi utilizzare la tua applicazione VLE utilizzando Moodle mentre il tuo database è in manutenzione. Se si dispone di un solo server di database, che è molto comune per la configurazione di applicazioni semplice e leggera, una volta che il server si arresta, l'applicazione si interrompe. Se si dispone di un cluster di database che utilizza la replica master-slave si verifica un incidente senza precedenti che, a sua volta, l'applicazione sta scrivendo su due master dopo l'incidente, potrebbe essere un enorme pasticcio che a sua volta causa il danneggiamento dei dati dell'intera applicazione aziendale e livello dati. Se ci fossero dei pagamenti in corso che si sono verificati in quel momento, potrebbe essere un enorme disastro e comportare una grande quantità di lavoro durante l'esecuzione del ripristino dei dati.
Allora perché il tuo database deve essere altamente disponibile? È perché deve essere,
- In grado di eseguire la manutenzione o l'interruzione pianificata in modo fattibile e nella finestra di manutenzione consentita
- Il tempo di attività è fondamentale e deve evitare tempi di inattività quando necessario
- SLA è importante per il suo grado più elevato per ottenere un servizio clienti di alta qualità
- Fornire servizio e usabilità continui
- Nessun singolo punto di errore
- In grado di eseguire il failover quando il master si interrompe o si arresta in modo anomalo
- Evita lo scenario del cervello diviso in cui più maestri agiscono come scrittori attivi contemporaneamente
Costruzione del cluster di database
Ora che abbiamo sottolineato l'importanza di avere l'HA come piano e come soluzione per il tuo cluster di database, in particolare per PostgreSQL, concentriamoci sulla creazione del cluster dall'alto verso il basso per ottenere un configurazione disponibile pronta per la configurazione dell'applicazione Moodle.
Installazione di PostgreSQL
Prima di tutto, perché PostgreSQL? PostgreSQL ha grandi vantaggi rispetto ad altri database supportati da Moodle. È una questione di preferenza se devo riassumere poiché tutti i database supportati da Moodle sono tutti in grado di gestire i dati e sono anche soggetti a ottimizzazione. Dipende da quanto abile ed esperto stai usando il database. Anche se per riassumere il motivo dell'utilizzo di PostgreSQL, è un database affidabile e il suo sofisticato software open source soprattutto nei database che può essere paragonato ad altri fornitori proprietari, come Oracle e MS SQL. Supporta il parallelismo delle query, è in grado di gestire database grandi o enormi, ha un ampio supporto per JSON e molto altro. Puoi verificarlo qui per i motivi per cui scegliere PostgreSQL. Ora procediamo con l'installazione di PostgreSQL
Per questo blog, useremo PostgreSQL 12 usando Ubuntu 18.04 (Bionic Beaver). Quindi, per la configurazione ad alta disponibilità, devi disporre di un nodo primario e almeno di uno standby (replica) per il quale subentrerà una volta che il master si interrompe.
- Imposta il repository e la chiave di firma
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 - - Installa il server PG 12
# Update the package lists: sudo apt-get update # Install server and client apt install postgresql-12 postgresql-client-12
Esegui questa operazione anche sulla replica di destinazione, ma devi configurarla come standby o replica. In alternativa, ti consiglio di utilizzare ClusterControl e di scaricarlo in quanto è gratuito. Sarebbe sempre più veloce installare e configurare una configurazione primaria/standby. Per la mia configurazione utilizzando ClusterControl e utilizzando la scheda Visualizzazione topologia, ho ottenuto la seguente topologia:
Avendo una configurazione master/slave o primaria/standby, non significa che sei completamente coperto per un cluster di database ad alta disponibilità. Non è ancora altamente disponibile. Una volta che il primario o il master si interrompe, non è necessario che si verifichi alcun failover. Un'altra cosa è che non c'è bilanciamento delle connessioni dai client che vanno al master contro lo slave. Sebbene il bilanciamento del carico tra master/slave non implichi che debba essere configurato o applicato per soddisfare una configurazione ad alta disponibilità. Avere un bilanciamento del carico tra il master/primario e uno slave/standby aiuta il tuo nodo master a non stressare le prestazioni di carico elevato, specialmente nelle ore di traffico molto elevate.
Impostazione del bilanciamento del carico
Come accennato in precedenza, il bilanciamento del carico tra master e slave aiuta il master a individuare il carico. Non è l'ideale se si lascia che il proprio standby venga utilizzato solo per la replica o subentrerà nel caso in cui il master si interrompa. Sebbene ciò possa funzionare, tuttavia, ciò comporta tempi di inattività e lavoro manuale se il master si interrompe, poiché è necessario passare dal ruolo del nodo di standby a un master. Anche questo va bene, ma ancora una volta, avere un bilanciamento del carico può aiutare a dirigere le scritture al master, quindi dirigere le letture tra il master e lo slave. Questo sostanzialmente fornisce la divisione in lettura/scrittura. Per fare questo, ci sono molte opzioni tra cui puoi scegliere con PostgreSQL. Fondamentalmente, la configurazione più comune ma semplice ed è leggera utilizza HAProxy.
Sebbene ci siano opzioni come l'utilizzo di PgBouncer o pgpool-II. Per semplicità di questo blog, utilizziamo HAProxy. Installare HAProxy, è piuttosto semplice se si utilizza ClusterControl. Facciamolo tramite ClusterControl. Per farlo, puoi semplicemente andare alla scheda Gestisci, selezionare Load Balancer come mostrato di seguito,
Dato che abbiamo bisogno di una configurazione altamente disponibile per il tuo cluster di database PostgreSQL, dovremmo avere almeno due nodi. Quindi, se il tuo nodo HAProxy primario si interrompe, l'HAProxy passivo o standby può subentrare. Vediamo come appare dalla mia parte,
Anche se sembra buono. Questa configurazione è ancora insufficiente. Se ritieni che siamo adatti per una configurazione ad alta disponibilità con quella topologia, non c'è failover nel caso in cui HAProxy si interrompa sul nodo 192.168.30.222 alla porta 9600 o se 192.168.30.223:9600 si interrompa e se la tua applicazione è configurata su quello host, c'è ancora tempo di inattività se non è stata effettuata alcuna configurazione proattiva. Ciò significa che hai tempi di inattività se deve essere impostato manualmente. In questo caso, utilizzeremo e configureremo Keepalived in modo che le istanze HAProxy siano monitorate da vicino per verificarne l'integrità e il failover nel caso in cui l'altro nodo incontri un problema.
Mantenere i bilanciatori del carico altamente disponibili
Ora che abbiamo i bilanciatori del carico in cima ai nostri database, abbiamo bisogno che il nostro HAProxy sia sempre attivo nel caso in cui il nodo primario per l'endpoint dell'applicazione si interrompa. Fondamentalmente, ciò che HAProxy può fare con la configurazione che abbiamo come nella sezione precedente, le applicazioni possono utilizzare rispettivamente 192.168.30.223 o 192.168.30.222 con le porte 5433 (porta di lettura-scrittura) e 5434 (porta di sola lettura). Ora c'è una seccatura nel caso in cui sia necessario cambiare nel caso in cui gli altri nodi si interrompano, inoltre la cosa negativa è che stai danneggiando l'azienda poiché copre i tempi di inattività se non c'è un failover automatico per gestirlo. Evitare i tempi di inattività è la strada migliore qui a meno che tu non abbia uno SLA molto basso e un RTO e RPO alti.
Per alleviare tali disastri o tempi di inattività, suggeriamo di configurare Keepalived su HAProxy. Fondamentalmente, HAProxy caricherà il bilanciamento tra lettura e scrittura fornendo la suddivisione in lettura e scrittura e Keepalived monitorerà solo lo stato dei nodi HAProxy e riuscirà a raccogliere il nodo più sano in base alla configurazione desiderata. Keepalived è uno strumento che puoi utilizzare per fare in modo che i nodi HAProxy vengano monitorati, sebbene non sia così complesso da gestire i database. Keepalived utilizza VIP (Virtual IP) che assegna al nodo HAProxy primario predefinito e quindi riassegna quel VIP in caso di guasto del nodo HAProxy primario e lo indirizza al nodo HAProxy successivo o di standby.
Ora configuriamolo utilizzando ClusterControl poiché è più veloce e facile da gestire con ClusterControl. Per fare ciò, è fondamentalmente lo stesso approccio di come configuriamo HAProxy ma invece selezioniamo Keepalived come mostrato di seguito,
Fondamentalmente, se installi Keepalived manualmente, selezioniamo il primario contro il secondario nel caso in cui HAProxy primario si guasta. Vediamo come appare la nostra vista Topologia,
Potrebbe sembrare molto promettente. Fondamentalmente, il client dell'applicazione Moodle si collegherà al VIP, ovvero 192.168.30.201 sotto le porte 5433 (porta di lettura-scrittura) e 5434 (porta di sola lettura). Ad esempio, verificandolo su un host esterno in mio possesso,
[[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)che rivela che solo il nodo writer che ho punta al mio nodo master, ovvero 192.168.30.22. Quindi, la mia porta di sola lettura deve passare ai nodi master e slave come mostrato di seguito,
[[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)Questo rivela che entrambi i miei nodi primari e standby sono identificati come nodi di "lettura database".
Ora questo sembra molto promettente come ho detto prima. Tuttavia, qui manca una parte che in realtà è molto importante. Non esiste alcun meccanismo di failover del database pronto per questo tipo di installazione. Tuttavia, abbiamo Keepalived che monitora HAProxy e quindi esegue un failover cambiando il VIP nel caso in cui l'HAProxy primario si guasta o muore. Tuttavia, Keepalived non è configurato per gestire la complessa configurazione di PostgreSQL. Ce n'è uno molto decente che è disponibile e gratuito per configurarlo. Puoi usare Slony-I, un sistema di replica di terze parti.
Meccanismo di failover per il cluster PostgreSQL
Ci sono modi per fornire un meccanismo di failover per PostgreSQL. Slony-I o comunemente chiamato semplicemente Slony è uno degli strumenti comuni utilizzati. Sebbene Slony richieda che la tua configurazione debba essere una replica logica poiché richiede una configurazione di editore/abbonato, potrebbe non essere l'ideale per altre configurazioni che utilizzano una replica di streaming standard. Lo svantaggio dell'utilizzo di Slony è che non fornisce alcun rilevamento automatico per sistemi guasti o nessun supporto per il fencing dei nodi. Pertanto, uno STONITH comunemente chiamato (spara all'altro nodo nella testa o spara al nodo guasto nella testa) che fondamentalmente elimina gli scenari non riusciti per evitare il cervello diviso in cui più nodi master (nodi writer attivi) accettano scritture al contemporaneamente. Sebbene questo possa essere configurato in modo appropriato, può comunque richiedere tempo e essere complicato se viene creato con meno esperienza e informazioni dettagliate su quali scenari sono destinati a verificarsi per PostgreSQL quando si verifica un disastro. Per Slony, l'abbandono delle transazioni impegnate è una decisione aziendale che non può essere presa da un sistema di database. Se qualcuno vuole inserire i comandi seguenti in uno script eseguito automaticamente dal sistema di monitoraggio della rete, lascia a tua disposizione che sono i tuoi dati e la tua politica di failover.
In alternativa, se stai cercando opzioni aziendali ma puoi prendere i tuoi soldi a una spesa ragionevole, ClusterControl ha il ripristino automatico per i cluster PostgreSQL. Fondamentalmente, il ripristino automatico risponde ai problemi sopra indicati con Slony. Sebbene il nostro ripristino automatico sia testato al meglio con la replica in streaming ed è supportato solo per il tipo di replica in streaming della configurazione di PostgreSQL. Quindi, come funziona? Fondamentalmente devi solo attivare i pulsanti di ripristino automatico proprio come di seguito,
Questo supporta il node fencing, il che significa che eliminerà il nodo in errore nel caso il nodo torna in vita per qualche motivo non previsto. A parte questo, il ripristino automatico di ClusterControl supporta il ripristino di nodi e cluster che, se un nodo master o slave è stato arrestato o ucciso accidentalmente, ClusterControl tenterà di ripristinarlo, specialmente se si verifica al di fuori di un'interruzione pianificata o di una finestra di manutenzione. Questa funzione ti protegge dall'esaurimento delle paure del database e allo stesso tempo ti fornisce anche un monitoraggio proattivo che ti avviserà di un possibile disastro prima che sia troppo tardi per il ripristino.
Conclusione
Le configurazioni altamente disponibili per il tuo cluster di database, in particolare per Moodle, possono variare a seconda del tipo di configurazione e dei requisiti di cui hai bisogno. Che si tratti esclusivamente di tecnologie gratuite e open source o che ci siano altre opzioni che valgono i soldi da investire per la tua applicazione aziendale purché il budget possa adattarsi in quanto può fornirti una situazione vantaggiosa per tutti, soprattutto se desideri solo maggiore concentrazione sul lato commerciale delle cose piuttosto che concentrarsi su altri strumenti come l'amministrazione e il tipo di lavoro devops.
