Il test è un'attività che richiede tempo, ma è un must prima di qualsiasi processo di aggiornamento su qualsiasi tecnologia. A seconda del tipo di aggiornamento, potrebbe essere più difficile o più facile, ma è sempre necessario se vuoi assicurarti che i tuoi dati siano al sicuro. Esistono diversi approcci per l'aggiornamento, a seconda dell'attività e della tolleranza ai tempi di fermo. Ad esempio, il processo potrebbe testare la tua applicazione in un ambiente separato con la nuova versione, quindi dovrai creare un nuovo cluster per questo. Un'altra opzione è clonare il tuo attuale ambiente di produzione e aggiornarlo, il che potrebbe essere utile in quanto puoi emulare tutto il processo di aggiornamento ed evitare sorprese in futuro.
Eseguendo manualmente tutto questo processo di test, c'è una grande possibilità di errore umano e il processo sarà lento, il che potrebbe influire sull'obiettivo del tempo di recupero (RTO). In questo blog vedremo come automatizzare i test per l'aggiornamento dei database PostgreSQL utilizzando ClusterControl.
Tipo di aggiornamento del database
Esistono due tipi di potenziamenti:potenziamenti minori e potenziamenti maggiori.
Miglioramenti minori
È l'aggiornamento più comune e sicuro e, nella maggior parte dei casi, viene eseguito sul posto. Poiché nulla è sicuro al 100%, devi sempre disporre di backup e nodi standby, quindi nel caso in cui qualcosa vada storto con l'aggiornamento, puoi promuovere un nodo standby nella versione precedente e i tuoi sistemi continueranno a funzionare senza interruzioni.
Puoi eseguire questo tipo di aggiornamento utilizzando ClusterControl. Per questo, vai su ClusterControl -> Seleziona il tuo cluster PostgreSQL -> Gestisci -> Aggiornamenti.
Su ciascun nodo selezionato, la procedura di aggiornamento:
-
Arresta nodo
-
Aggiorna nodo
-
Avvia nodo
Il nodo master in una topologia PostgreSQL non verrà aggiornato. Per aggiornare il Master, è necessario prima promuovere un altro nodo per diventare il nuovo Master.
Miglioramenti principali
Per gli aggiornamenti principali, non è consigliabile l'aggiornamento sul posto, poiché il rischio che qualcosa vada storto è troppo alto per un ambiente di produzione. Invece di questo, ci sono diversi approcci per fare gli aggiornamenti.
Puoi clonare il tuo attuale cluster di database, aggiornarlo e testare la tua applicazione lì, e quando hai finito, se tutto è andato bene, puoi ricrearlo per ripetere il processo per fare il vero aggiornamento oppure puoi anche creare un nuovo cluster nella nuova versione, testare la tua applicazione e cambiare il traffico quando è pronto e ci sono più opzioni... L'utilizzo di Load Balancer è utile qui per migliorare l'alta disponibilità. L'approccio migliore dipende dalla tolleranza ai tempi di fermo e dal Recovery Time Objective (RTO).
Non puoi eseguire gli aggiornamenti principali direttamente con ClusterControl, perché, come accennato, devi prima testare tutto per assicurarti che l'aggiornamento sia sicuro, ma puoi utilizzare diverse funzionalità di ClusterControl per fare questo compito più facile. Vediamo quindi alcune di queste caratteristiche.
Distribuzione di un ambiente di test
Per questo, non è necessario creare tutto da zero. Invece di questo, puoi usare ClusterControl per farlo in modo manuale o automatizzato.
Ripristina backup su host autonomo
Nella sezione Backup, scegli un backup e vedrai l'opzione "Ripristina e verifica su host standalone" per ripristinare un backup in un nodo separato.
Qui puoi specificare se vuoi che ClusterControl installi il software nel nuovo nodo e disabilitare il firewall o AppArmor/SELinux (a seconda del sistema operativo). Per questo, è necessario un host (o VM) dedicato che non faccia parte del cluster.
Puoi mantenere il nodo attivo e funzionante oppure ClusterControl può arrestare il database servizio fino al prossimo lavoro di ripristino. Al termine, vedrai il backup ripristinato/verificato nell'elenco dei backup contrassegnato da un segno di spunta.
Se non si desidera eseguire questa attività manualmente, è possibile pianificare questo processo utilizzando la funzione Verifica backup, per ripetere periodicamente questo processo in un processo di backup. Vedremo come farlo nella prossima sezione.
Verifica automatica del backup di ClusterControl
Per automatizzare questa attività, vai su ClusterControl -> Seleziona il tuo cluster PostgreSQL -> Backup -> Crea backup e scegli l'opzione Backup pianificato. La funzione di verifica automatica del backup è disponibile solo per i backup pianificati.
Nel secondo passaggio, assicurati di aver abilitato l'opzione Verifica backup, e completare le informazioni richieste.
Al termine del lavoro, puoi vedere l'icona di verifica in ClusterControl Sezione di backup, la stessa che avrai effettuando la verifica in modo manuale, con la differenza che non devi preoccuparti dell'attività di ripristino. ClusterControl ripristinerà il backup ogni volta automaticamente e potrai testare la tua applicazione con i dati più recenti.
Crea cluster dal backup
Un altro modo per creare un ambiente di test consiste nel creare un nuovo cluster da un backup del tuo cluster primario. Per questo, vai su ClusterControl -> Seleziona il tuo cluster PostgreSQL -> Backup. Lì, scegli il backup da ripristinare dall'elenco e seleziona Ripristina -> Crea cluster da backup.
Questa opzione creerà un nuovo cluster PostgreSQL dal backup selezionato.
È necessario aggiungere le credenziali del sistema operativo e del database e le informazioni per distribuire il nuovo ammasso. Al termine di questo lavoro, vedrai il nuovo cluster nell'interfaccia utente di ClusterControl.
Replica da cluster a cluster
Da ClusterControl 1.7.4 è disponibile una funzionalità denominata Replica da cluster a cluster. Ti consente di avere una replica in esecuzione tra due cluster autonomi.
Creazione di una replica da cluster a cluster
Vai a ClusterControl -> Seleziona il tuo cluster PostgreSQL -> Azioni cluster -> Crea cluster slave.
Il cluster slave verrà creato tramite lo streaming dei dati dal cluster primario corrente.
Devi specificare le credenziali SSH e la porta, un nome per il tuo cluster slave, e se vuoi che ClusterControl installi per te il software e le configurazioni corrispondenti.
Dopo aver impostato le informazioni di accesso SSH, è necessario definire la versione del database, datadir, porta e credenziali di amministratore. Poiché utilizzerà la replica in streaming, assicurati di utilizzare la stessa versione del database e le credenziali devono essere le stesse utilizzate dal cluster primario.
In questo passaggio, è necessario aggiungere il server al nuovo cluster slave . Per questa attività, puoi inserire sia l'indirizzo IP che il nome host del nodo del database.
È possibile monitorare lo stato del lavoro nel monitoraggio attività di ClusterControl. Al termine dell'attività, puoi vedere il cluster nella schermata principale di ClusterControl.
Ripristino automatico e Failover
Avendo abilitata la funzione Autorecovery, in caso di errore ClusterControl promuoverà il nodo standby più avanzato a primario e ti avviserà del problema. Inoltre, esegue il failover sul resto dei nodi di standby per la replica dal nuovo server primario.
Se nella topologia sono presenti Load Balancer, ClusterControl li riconfigura per applicare le modifiche alla topologia.
Puoi anche eseguire un failover manualmente, se necessario. Vai su ClusterControl -> Seleziona il tuo cluster PostgreSQL -> Nodi -> Seleziona il nodo da promuovere -> Azioni nodo -> Promuovi slave.
In questo modo, se qualcosa va storto durante l'aggiornamento, puoi utilizzare ClusterControl per risolverlo il prima possibile.
Automatizzazione delle cose con ClusterControl CLI
ClusterControl CLI, noto anche come s9s, è uno strumento da riga di comando introdotto in ClusterControl versione 1.4.1 per interagire, controllare e gestire i cluster di database utilizzando il sistema ClusterControl. ClusterControl CLI apre una porta per l'automazione del cluster in cui puoi integrarla facilmente con gli strumenti di automazione della distribuzione esistenti come Ansible, Puppet, Chef, ecc. Vediamo ora alcuni esempi di questo strumento.
Aggiorna
$ s9s cluster --cluster-id=9 \
--check-pkg-upgrades \
--log
$ s9s cluster --cluster-id=9 \
--available-upgrades \
--nodes=10.10.10.122 \
--log \
--print-json
$ s9s cluster --cluster-id=9 \
--upgrade-cluster \
--nodes=10.10.10.122 \
--logVerifica backup
$ s9s backup --verify \
--backup-id=2 \
--test-server=10.10.10.124 \
--cluster-id=9 \
--logReplica da cluster a cluster
$ s9s cluster --create \
--cluster-name=PostgreSQL-c2c \
--cluster-type=postgresql \
--provider-version=13 \
--nodes=10.10.10.125 \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--db-admin=admin \
--db-admin-passwd=********* \
--vendor=postgres \
--remote-cluster-id=9 \
--logPromuove il nodo slave
$ s9s cluster --promote-slave \
--cluster-id=9 \
--nodes='10.10.10.122' \
--logConclusione
Gli aggiornamenti sono necessari ma richiedono molto tempo in quanto è necessario testare l'applicazione per evitare problemi durante il processo. Distribuire un ambiente di test ogni volta che è necessario aggiornare e mantenerlo aggiornato senza alcuno strumento di automazione potrebbe essere difficile.
ClusterControl consente di eseguire aggiornamenti minori dall'interfaccia utente o dalla CLI di ClusterControl o persino distribuire l'ambiente di test per rendere l'attività di aggiornamento più semplice e sicura. Puoi anche integrarlo con diversi strumenti di automazione come Ansible, Puppet e altri.
