Cerca in SafeKit

PostgreSQL ad alta disponibilità con SafeKit: installa il modulo postgresql.safe per il failover

Guida all’installazione rapida ad alta disponibilità per PostgreSQL

Questa guida spiega come impostare a gruppo di specchi per PostgreSQL utilizzando SafeKit, garantendo il failover automatico e la replica sincrona senza la necessità di storage condiviso.

Per aiuto, puoi usare SafeKit AI🤖.

1. Panoramica

  • Architettura: Utilizza un sistema a due nodi (primario/secondario).
  • Protezione dei dati: Implementa la replica sincrona in tempo reale per perdita di dati pari a zero (RPO=0).

2. Installazione

  • Software: Installa il motore SafeKit su entrambi i server.
  • Modulo: Scarica il preconfigurato postgresql.safe.safe modulo applicativo.

3. Configurazione

  • Console Web: Configura le cartelle specifiche contenenti i file PostgreSQL.
  • Monitoraggio: Inizia a monitorare e proteggere l’applicazione PostgreSQL.

Limitazioni dell’alta affidabilità SafeKit

Limite / RequisitoMotivo e impattoAlternativa consigliata
Dimensione di replica: Alcuni TBTempo di risincronizzazione dopo un guasto (passo 3):
• Rete a 1 Gb/s ≈ 3 ore / TB
• Rete a 10 Gb/s ≈ 1 ora / TB (a seconda delle prestazioni di scrittura su disco)
• Utilizzare uno storage condiviso esterno (più costoso, più complesso).
Numero di file: < 1.000.000 di file• Prestazioni del tempo di risincronizzazione dopo un guasto (passo 3).
• Tempo necessario per verificare ciascun file tra i due nodi.
• Inserire i numerosi file da replicare in un disco rigido virtuale / macchina virtuale.
• In questo caso, verranno replicati e risincronizzati solo i file che rappresentano il disco rigido virtuale / la macchina virtuale.
Capacità di failover: ≤ 32 VM• Ogni VM viene eseguita in un modulo mirror indipendente.
• Massimo 32 moduli mirror in esecuzione sullo stesso cluster.
• Utilizzare uno storage condiviso esterno e un’altra soluzione di clustering per VM (più costoso, più complesso).
Architettura di rete: Rete LAN/VLAN tra siti remoti• Failover automatico dell’indirizzo IP virtuale con 2 nodi nella stessa sottorete.
• Buona larghezza di banda per la risincronizzazione (passo 3).
• Bassa latenza per la replica sincrona: tipicamente < 5 ms di RTT; i valori superiori devono essere validati in base alla velocità di scrittura dell’applicazione.
• Utilizzare un bilanciatore del carico per l’indirizzo IP virtuale se i 2 nodi si trovano in 2 sottoreti diverse (supportato da SafeKit, in particolare nel cloud).
• Utilizzare soluzioni di backup con replica asincrona per reti ad alta latenza.

Panoramica della soluzione SafeKit / PostgreSQL

La soluzione è descritta qui: 💡La più semplice disponibilità elevata PostgreSQL: replica sincrona a 2 nodi e failover.

Installazione della soluzione SafeKit / PostgreSQL su Windows e Linux (postgresql.safe)

Prerequisiti

  • È necessario che PostgreSQL sia installato su 2 nodi (macchine virtuali o server fisici).

Installazione del pacchetto su Windows

  • Scarica e installa la versione gratuita di SafeKit su 2 nodi Windows.
    Nota: la versione gratuita include tutte le funzionalità di SafeKit. Al termine del periodo di prova sarà possibile attivare le chiavi di licenza permanenti senza disinstallare il pacchetto.
  • Una volta completata l’installazione del pacchetto, seleziona Set console credentials and firewall rules now e configurare una password per il admin utente della console SafeKit.
    Imposta la stessa password su tutti i nodi.
  • Escludi dalle scansioni antivirus C:/safekit/ (la directory di installazione predefinita) e tutte le cartelle replicate che andrai a definire.
    Gli antivirus potrebbero dover affrontare problemi di rilevamento con SafeKit a causa della sua stretta integrazione con il sistema operativo, i meccanismi IP virtuali, la replica in tempo reale e il riavvio dei servizi critici.

Scarica SafeKit (Windows) >

Installazione del modulo su Windows

  • Scarica il modulo postgresql.safe. Il modulo è gratuito. Contiene i file userconfig.xml e gli script di riavvio.
  • Metti postgresql.safe sotto C:/safekit/Application_Modules/generic.

Scarica postgresql.safe (Windows) >

Installazione del pacchetto su Linux

  • Installa la versione gratuita di SafeKit su 2 nodi Linux. Nota: la prova gratuita include tutte le funzionalità di SafeKit. Al termine del periodo di prova sarà possibile attivare le chiavi di licenza permanenti senza disinstallare il pacchetto.
  • Dopo aver scaricato il pacchetto safekit_xx.bin, eseguilo per estrarre lo script rpm e safekitinstall, quindi esegui il safekitinstall sceneggiatura
  • Rispondi sì alla configurazione automatica del firewall
  • Imposta la password per la console web e l’utente predefinito admin. Imposta la stessa password su tutti i nodi.

Scarica SafeKit (Linux) >

Installazione del modulo su Linux

  • Scarica il modulo postgresql.safe.
    Il modulo è gratuito. Contiene i file userconfig.xml e gli script di riavvio.
  • Metti postgresql.safe sotto /opt/safekit/Application_Modules/generic/.

Scarica postgresql.safe (Linux) >

Configurazione passo passo della soluzione SafeKit / PostgreSQL

Prerequisiti

  • Applicazione PostgreSQL installata su 2 nodi.
  • Il totale dei dati replicati è limitato a pochi terabyte: oltre questo limite, il tempo di risincronizzazione diventa significativo.
  • Interconnessione minima di 1 Gb/s tra i nodi (10 Gb/s consigliati per una risincronizzazione più rapida).
  • Il failover IP richiede entrambi i nodi sullo stesso LAN o LAN esteso (L2): le reti L3 instradate non sono supportate (eccetto con 🛠️ bilanciatori di carico cloud).

1. Avvia la console SafeKit

  • Avvia la console Web in un browser su un nodo del cluster connettendoti a http://localhost:9010.
  • Immettere admin come nome utente e la password definita durante l’installazione.

È inoltre possibile eseguire la console in un browser su una workstation esterna al cluster.

⚠️ La configurazione di SafeKit viene effettuata su entrambi i nodi da un unico browser.

ℹ️ Per proteggere la console web, vedere 🛠️ 11. Protezione del servizio Web SafeKit nella Guida dell’utente.

Avviare la console Web SafeKit per configurare il cluster PostgreSQL

2. Configurare gli indirizzi dei nodi

  • Immettere gli indirizzi del nodo IP, premere Tab key per verificare la connettività e inserire i nomi dei nodi. Se node1 o node2 hanno un colore rosso, controlla la connettività del browser su entrambi i nodi e controlla il firewall su entrambi i nodi per 🛠️ risoluzione dei problemi.
  • Quindi, fare clic su Save and apply per salvare la configurazione.
  • Controlla il messaggio Success ✅ su entrambi i nodi.
  • Se la configurazione Failure ❌ si verifica su un nodo, aprire la fisarmonica ▼ per quel nodo e rivedere i messaggi. Tieni presente che puoi utilizzare SafeKit AI 🤖 per assistenza.

ℹ️ Se lo desideri, puoi aggiungere un nuovo LAN and nodes ( primo ➕) per creare un secondo heartbeat e una rete di replica dedicata.

ℹ️ Se si fa clic su Advanced configuration, viene visualizzato il file cluster.xml. Questo file viene popolato automaticamente dalla console e distribuito sui nodi.

Inserisci i nodi del cluster PostgreSQL

3. Selezionare un modulo

  • In New module, fare clic sul modulo postgresql.safe.

ℹ️ Nel banner blu in alto, 🛜 node1 rappresenta il nodo di connessione della console. Questo nodo inoltra le richieste a node2 quando richiesto.

ℹ️ La console cerca xxx.safe nella directory Application_Modules/generic/ sul nodo di connessione (node1) se hai posizionato un modulo lì durante l’installazione.

Scegli il modulo per PostgreSQL

4. Configurare il modulo

  • In Module startup at boot, scegli l’avvio automatico del modulo all’avvio senza ritardi.
  • In Macros / SERVICES, inserisci i nomi dei servizi della tua applicazione, nell’ordine di avvio, separati da virgole. Guarda questo screenshot per un esempio visivo dei servizi Milestone XProtect 🖼️.
  • In Heartbeat networks, dovresti avere una singola rete heartbeat su cui viene effettuata la replica. Se hai aggiunto uno LAN privato al passaggio 2, puoi configurare due heartbeat con il flusso di replica sullo LAN privato.
  • In Virtual IP addresses, inserisci un indirizzo IP virtuale. Un indirizzo IP virtuale è un indirizzo IP standard nella stessa rete IP (stessa sottorete) degli indirizzi IP di entrambi i nodi.
    I client dell’applicazione devono essere configurati con l’indirizzo virtuale IP (o il nome DNS associato all’indirizzo virtuale IP).
    L’indirizzo virtuale IP viene commutato automaticamente in caso di guasto.
  • In Replicated directories, imposta i percorsi delle directory da replicare. Verificare che esistano su entrambi i nodi e contengano i dati dell’applicazione.
    La replica dei dati e dei log è essenziale per un database.
    È possibile creare directory replicate aggiuntive secondo necessità.
    Guarda questo screenshot per un esempio visivo della replica di Milestone XProtect SQL 🖼️.
  • In Checkers sarai in grado di configurare i controllori, se necessario, come il monitoraggio dei processi, i controllori personalizzati, TCP, il ping o i controlli split-brain.
    Ad esempio, se il nome di un processo viene visualizzato in Monitored processes/services, verrà monitorato con un’azione di riavvio in caso di errore. La configurazione di un nome di processo errato causerà l’arresto del modulo subito dopo il suo avvio.

ℹ️ Se si fa clic su Advanced configuration, viene visualizzato il file userconfig.xml. Questo file viene popolato automaticamente dalla console e distribuito sui nodi con gli script di riavvio.

ℹ️ In una distribuzione cloud, non è necessario configurare un indirizzo IP virtuale in SafeKit. Lo IP virtuale è gestito a livello di bilanciamento del carico 🛠️ cloud.

ℹ️ Quando applichi la configurazione SafeKit, i servizi startup type vengono automaticamente impostati su Manual nei servizi Windows. Ciò garantisce che i servizi non si avviino automaticamente all’avvio del sistema, ma vengano invece avviati solo all’avvio del modulo stesso (lo stesso vale per Linux).

Immettere le impostazioni del modulo PostgreSQL

5. Modifica script (facoltativo)

  • Questo passaggio è facoltativo e può essere ignorato nella maggior parte dei casi, poiché gli script di riavvio sono già preconfigurati per riavviare i servizi definiti nel passaggio precedente.
  • Quindi, fai clic direttamente su Next step.
  • start_prim.ps1 avvia tutti i servizi nell’ordine specificato nell’elenco SERVICES, mentre stop_prim.ps1 arresta tutti i servizi nell’ordine inverso.
  • Inoltre, start_prim.ps1 controlla l’avvio di ciascun servizio e arresta il modulo se un servizio non si avvia correttamente.

Immettere le impostazioni del modulo PostgreSQL

6. Crittografia della comunicazione (opzionale)

  • Mantieni la crittografia della comunicazione tra i nodi.

Crittografia della comunicazione del modulo PostgreSQL

7. Salva e applica

  • Save and apply la configurazione e gli script su entrambi i nodi.

Salvare e applicare la configurazione del modulo PostgreSQL

8. Verificare la corretta configurazione

  • Controlla il messaggio Success ✅ su entrambi i nodi e clicca su Monitor modules.
  • Se la configurazione Failure ❌ si verifica su un nodo, aprire la fisarmonica ▼ per quel nodo e rivedere i messaggi. Tieni presente che puoi utilizzare SafeKit AI 🤖 per assistenza.

⚠️ Su Linux, potresti ricevere un errore in questo passaggio se le directory replicate sono punti di montaggio. 🛠️ Vedi SK-0030 per risolvere il problema.

Verificare la riuscita della configurazione del modulo PostgreSQL

9. Avviare il nodo con dati aggiornati

  • Se il nodo 1 ha le directory replicate aggiornate, selezionalo e ⋯ Force start ▶ As primary.

Quando verrà avviato il nodo 2, tutti i dati verranno copiati dal nodo 1 al nodo 2.

⚠️ Se fai la scelta sbagliata, corri il rischio di sincronizzare dati obsoleti su entrambi i nodi.

⚠️ Si presuppone inoltre che l’applicazione PostgreSQL venga arrestata sul nodo 1 in modo che SafeKit installi i meccanismi di replica e quindi avvii l’applicazione nello script start_prim.

⚠️ Utilizza Start per gli avvii successivi: SafeKit conserva il server più aggiornato. L’avvio di As primary è un avviamento speciale la prima volta o durante operazioni eccezionali.

Avvia come primario il nodo PostgreSQL con i dati aggiornati

10. Attendi il passaggio a ALONE (verde)

  • Il nodo 1 dovrebbe raggiungere lo stato ALONE (verde), il che significa che lo IP virtuale è impostato e che lo script start_prim è stato eseguito sul nodo 1.

⚠️ Se ALONE (verde) non viene raggiunto o se l’applicazione non viene avviata, analizza il motivo con il log del modulo 🖼️ del nodo 1.

  • Fare clic sull’icona 🔍 log di node1 per aprire il registro del modulo e cercare messaggi di errore come un controllo che rileva un errore e arresta il modulo.
  • Fare clic su start_prim nel registro: i messaggi di output dello script vengono visualizzati a destra e possono essere rilevati errori come ad esempio un servizio avviato in modo errato.
  • Utilizza SafeKit AI 🤖 per assistenza con i messaggi di registro.

⚠️ Se il cluster è nello stato WAIT (red) not uptodate, STOP (red) not uptodate, arresta il nodo WAIT e forza il suo avvio come primario 🖼️.

Il primo nodo PostgreSQL inizia come primario e diventa ALONE

11. Avviare il nodo 2

  • ⋯ Start nodo 2 con relativo menù contestuale.
  • Attendi lo stato SECOND (verde).

ℹ️ Il nodo 2 rimane nello stato SECOND (arancione) durante la risincronizzazione delle directory replicate (copia dal nodo 1 al nodo 2).

  • Questa operazione potrebbe richiedere del tempo a seconda della dimensione dei file da risincronizzare nelle directory replicate e della larghezza di banda della rete.
  • Per vedere l’avanzamento della copia, vedere il registro del modulo 🖼️ e le risorse di replica 🖼️ del nodo 2. Utilizzare SafeKit AI 🤖 per assistenza con i messaggi di registro.

Avviare il nodo PostgreSQL 2

12. Verificare che il cluster sia operativo

  • Verifica che il cluster sia verde/verde con i servizi PostgreSQL in esecuzione sul nodo PRIM e non in esecuzione sul nodo SECOND.

Solo le modifiche all’interno dei file vengono replicate in tempo reale in questo stato.

⚠️ I componenti che sono client dei servizi PostgreSQL devono essere configurati con l’indirizzo virtuale IP. La configurazione può essere effettuata con un nome DNS (se è stato creato un nome DNS e associato all’indirizzo virtuale IP).

Il nodo 2 PostgreSQL è SECOND (verde)

13. Test

  • Arrestare il nodo PRIM scorrendo il menu contestuale e facendo clic su Stop.
  • Verificare che sia presente un failover sul nodo SECOND che dovrebbe diventare ALONE (verde).
  • Inoltre, con Microsoft Management Console (MMC) su Windows o con righe di comando su Linux, controlla il failover dei servizi PostgreSQL (interrotto sul nodo 1 nello script stop_prim e avviato sul nodo 2 nello script start_prim).

⚠️ Se ALONE (verde) non viene raggiunto su node2 o se l’applicazione non viene avviata, analizza il motivo con il log del modulo 🖼️ del nodo 2.

  • Fare clic sull’icona 🔍 log di node2 per aprire il registro del modulo e cercare messaggi di errore come un controllo che rileva un errore e arresta il modulo.
  • Fare clic su start_prim nel registro: i messaggi di output dello script vengono visualizzati a destra e possono essere rilevati errori come ad esempio un servizio avviato in modo errato.
  • Utilizza SafeKit AI 🤖 per assistenza con i messaggi di registro.

⚠️

  • Se tutto è a posto, avviare un avvio su node1, che risincronizzerà le directory replicate da node2.
  • Se le cose vanno male, ferma node2 e forza l’avvio come primario 🖼️ di node1, che si riavvierà con i suoi dati localmente integri al momento dell’arresto.

ℹ️ Trovi maggiori dettagli, insieme ai video, nel SafeKit Formazione online.

Arrestare il modulo PostgreSQL sul server PRIM

14. Supporto

  • Per ottenere supporto, prendi 2 SafeKit Snapshots (2 file .zip), uno per ciascun nodo.

ℹ️ Maggiori informazioni sul supporto qui.

Scatta le istantanee di PostgreSQL per supporto

Dimostrazione della soluzione specchio SafeKit

Video SafeKit: clustering a livello di applicazione (8:47)

In questo video, scopri come SafeKit implementa un cluster HA mirror senza la complessità di una SAN. Sebbene questa dimostrazione utilizzi Microsoft SQL Server, la soluzione funziona in modo identico per altri database e applicazioni.

Capitoli

  1. 🎬 2 nodi con SQL Server (0:32)
  2. 🎬 Configurare il cluster e il modulo mirror.safe (3:58)
  3. 🎬 Avvia e testa la replica SQL, la migrazione e il failover in caso di arresto anomalo (4:17)

Implementazione passo dopo passo

🔍 Hub di Navigazione SafeKit High Availability

Esplora SafeKit: Funzionalità, video tecnici, documentazione e prova gratuita

Tipo di RisorsaDescrizioneLink Diretto
Funzionalità ChiavePerché scegliere SafeKit per un’alta disponibilità semplice ed economica?Perché scegliere SafeKit per l’High Availability
Casi d’usoScopri come SafeKit garantisce l’alta affidabilità delle infrastrutture criticheVedi tutti i casi d’uso (Software OEM, Server Edge, SCADA e altro)
Modello di DistribuzioneHA SANless All-in-One: Clustering Software Shared-NothingScopri SafeKit All-in-One SANless HA
Strategie HASafeKit: Alta disponibilità a livello di Infrastruttura (VM) vs. ApplicazioneSafeKit HA e ridondanza: Livello VM vs. Applicativo
Specifiche TecnicheLimitazioni tecniche per il Clustering SafeKitLimitazioni SafeKit High Availability
VideoSafeKit: Demo di configurazione e failover in Alta DisponibilitàTutorial Failover SafeKit
ArchitetturaCome funziona il Mirror Cluster SafeKit (Replica in tempo reale e Failover)SafeKit Mirror Cluster: Replica in tempo reale e Failover
ArchitetturaCome funziona il Farm Cluster SafeKit (Bilanciamento del carico di rete e Failover)SafeKit Farm Cluster: Bilanciamento del carico e Failover
Vantaggi CompetitiviConfronto: SafeKit vs. Cluster High Availability (HA) TradizionaliConfronto SafeKit vs. Cluster HA Tradizionali
Risorse TecnicheSafeKit High Availability: Documentazione, Download e ProvaProva gratuita SafeKit HA e Documentazione Tecnica
Soluzioni Pre-configurateLibreria Moduli Applicativi SafeKit: Soluzioni HA pronte all’usoModuli Applicativi SafeKit High Availability
SafeKit AI Chat SafeKit AI