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.safemodulo 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 / Requisito | Motivo e impatto | Alternativa consigliata |
|---|---|---|
| Dimensione di replica: Alcuni TB | Tempo 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.
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.
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
admincome 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.

2. Configurare gli indirizzi dei nodi
- Immettere gli indirizzi del nodo IP, premere
Tab keyper 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 applyper 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.

3. Selezionare un modulo
- In
New module, fare clic sul modulopostgresql.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.

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
Checkerssarai 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 inMonitored 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).

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.ps1avvia tutti i servizi nell’ordine specificato nell’elencoSERVICES, mentrestop_prim.ps1arresta tutti i servizi nell’ordine inverso.- Inoltre,
start_prim.ps1controlla l’avvio di ciascun servizio e arresta il modulo se un servizio non si avvia correttamente.

6. Crittografia della comunicazione (opzionale)
- Mantieni la crittografia della comunicazione tra i nodi.

7. Salva e applica
Save and applyla configurazione e gli script su entrambi i nodi.

8. Verificare la corretta configurazione
- Controlla il messaggio
Success✅ su entrambi i nodi e clicca suMonitor 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.

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.

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
node1per 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_primnel 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 🖼️.

11. Avviare il nodo 2
- ⋯
Startnodo 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.

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).

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_prime avviato sul nodo 2 nello scriptstart_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
node2per 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_primnel 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.

14. Supporto
- Per ottenere supporto, prendi 2 SafeKit
Snapshots(2 file .zip), uno per ciascun nodo.
ℹ️ Maggiori informazioni sul supporto qui.

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
- 🎬 2 nodi con SQL Server (0:32)
- 🎬 Configurare il cluster e il modulo mirror.safe (3:58)
- 🎬 Avvia e testa la replica SQL, la migrazione e il failover in caso di arresto anomalo (4:17)
Implementazione passo dopo passo
- 🛠️ Leggi la guida sulla configurazione di un cluster con mirroring su Windows
- 🛠️ Leggi la guida sulla configurazione di un cluster mirrorato su Linux
🔍 Hub di Navigazione SafeKit High Availability
Esplora SafeKit: Funzionalità, video tecnici, documentazione e prova gratuita
| Tipo di Risorsa | Descrizione | Link Diretto |
|---|---|---|
| Funzionalità Chiave | Perché scegliere SafeKit per un’alta disponibilità semplice ed economica? | Perché scegliere SafeKit per l’High Availability |
| Casi d’uso | Scopri come SafeKit garantisce l’alta affidabilità delle infrastrutture critiche | Vedi tutti i casi d’uso (Software OEM, Server Edge, SCADA e altro) |
| Modello di Distribuzione | HA SANless All-in-One: Clustering Software Shared-Nothing | Scopri SafeKit All-in-One SANless HA |
| Strategie HA | SafeKit: Alta disponibilità a livello di Infrastruttura (VM) vs. Applicazione | SafeKit HA e ridondanza: Livello VM vs. Applicativo |
| Specifiche Tecniche | Limitazioni tecniche per il Clustering SafeKit | Limitazioni SafeKit High Availability |
| Video | SafeKit: Demo di configurazione e failover in Alta Disponibilità | Tutorial Failover SafeKit |
| Architettura | Come funziona il Mirror Cluster SafeKit (Replica in tempo reale e Failover) | SafeKit Mirror Cluster: Replica in tempo reale e Failover |
| Architettura | Come funziona il Farm Cluster SafeKit (Bilanciamento del carico di rete e Failover) | SafeKit Farm Cluster: Bilanciamento del carico e Failover |
| Vantaggi Competitivi | Confronto: SafeKit vs. Cluster High Availability (HA) Tradizionali | Confronto SafeKit vs. Cluster HA Tradizionali |
| Risorse Tecniche | SafeKit High Availability: Documentazione, Download e Prova | Prova gratuita SafeKit HA e Documentazione Tecnica |
| Soluzioni Pre-configurate | Libreria Moduli Applicativi SafeKit: Soluzioni HA pronte all’uso | Moduli Applicativi SafeKit High Availability |