Come configurare un cluster ad alta disponibilità Nextcloud con Galera DB

Un'implementazione ad alta disponibilità di Nextcloud con Galera è un sistema coordinato, non solo tre server di database. Sono necessari anche nodi applicativi Nextcloud ridondanti, un livello di dati condiviso e persistente, caching e blocco dei file distribuiti, bilanciamento del carico, monitoraggio e backup testati. Galera può mantenere il servizio di database disponibile dopo un guasto di un nodo di database, a condizione che il quorum sia ancora presente, ma non può garantire l'alta disponibilità di questi altri componenti.

Questa guida utilizza un'architettura Linux indipendente dal fornitore con MariaDB Galera e un proxy inverso o un bilanciatore di carico. I nomi dei pacchetti, i nomi dei servizi, i percorsi del provider Galera, i comandi di bootstrap e le integrazioni per il controllo dello stato del proxy variano a seconda della distribuzione e della versione di MariaDB. Prima della distribuzione, verificarli con la documentazione specifica della versione in uso. Il manuale di amministrazione stabile di Nextcloud elenca PostgreSQL e MariaDB come motori di database consigliati e avverte che le versioni supportate variano; verificare i requisiti di sistema di Nextcloud per la versione che si intende utilizzare. Questo articolo è stato verificato rispetto al manuale stabile di Nextcloud 35 il 6 ottobre 2026.

Scegli prima il modello di disponibilità più adatto

Galera è una replica sincrona multi-primaria per server compatibili con MySQL. Una transazione viene certificata a livello di cluster, il che contribuisce a mantenere la coerenza tra i membri, ma aggiunge un overhead di coordinamento e le transazioni in conflitto possono essere rifiutate. L'aggiunta di nodi di database non moltiplica automaticamente la velocità di trasmissione di Nextcloud. La guida per sviluppatori di Nextcloud sottolinea che i cluster comportano un costo in termini di prestazioni e che il database e lo storage rimangono risorse condivise critiche.

Per una nuova installazione, un cluster Galera a tre nodi dati distribuiti su host indipendenti è un punto di partenza comune, a condizione che il team operativo possa supportarlo. Il quorum di Galera richiede la maggioranza: un cluster a due nodi non può effettuare un failover automatico e sicuro dopo la perdita di un membro. Tre nodi possono tollerare un membro non disponibile mentre gli altri due rimangono connessi. È consigliabile posizionare i nodi su domini di errore laddove possibile, ma evitare di estendere la replica sincrona su collegamenti ad alta latenza senza averli prima testati. Per un ambiente meno complesso, è preferibile un singolo database supportato e un piano di backup e ripristino ben collaudato.

Prima dell'installazione: decidi cosa significa "alta disponibilità".

Annotate i guasti che intendete tollerare: un processo web, un server web, un server di database, un bilanciatore di carico, un endpoint di archiviazione, un percorso di rete o un sito completo. Definite gli obiettivi di ripristino per ciascuno di essi. Un'architettura con tre nodi di database e un bilanciatore di carico non è completamente ridondante. Lo stesso vale per un cluster di applicazioni i cui file utente risiedono solo sul disco locale di un server web.

Utilizzare la stessa versione di Nextcloud, lo stesso runtime PHP, lo stesso set di applicazioni e la stessa configurazione su ogni nodo dell'applicazione. Selezionare versioni di MariaDB e Galera compatibili tra loro e supportate dalla versione di Nextcloud scelta. I requisiti del database Nextcloud includono InnoDB, l'isolamento delle transazioni READ COMMITTED e la disabilitazione del logging binario o del formato ROW; non copiare i valori di ottimizzazione da una versione diversa senza aver prima verificato i requisiti correnti.

Configura il cluster in 12 fasi

1. Riservare nomi host, indirizzi e endpoint di servizio

Crea nomi DNS privati ​​o indirizzi stabili per ogni membro del database, ogni nodo web, il servizio di cache, lo storage condiviso e l'endpoint web pubblico. Riserva un endpoint di database stabile separato per i nodi PHP di Nextcloud. Mantieni il traffico dell'applicazione, della replica e pubblico su percorsi di rete opportunamente separati, laddove la tua infrastruttura lo consenta. Il nome di un nodo deve essere univoco e ogni membro del cluster deve risolvere i peer Galera in modo coerente.

2. Installa un database compatibile e una versione di Galera

Installa MariaDB Server e il provider Galera utilizzando il repository del fornitore consigliato per il tuo sistema operativo. Mantieni la stessa famiglia di server e provider principale su tutti i membri. Non combinare pacchetti della community arbitrari con una libreria del provider scaricata separatamente. Prima di procedere, verifica il percorso di aggiornamento supportato, il metodo SST, l'unità di servizio e la directory di inclusione della configurazione per quel set di pacchetti specifico.

3. Applicare i requisiti del database di Nextcloud

Configura il server per utilizzare InnoDB e il livello di isolamento delle transazioni READ COMMITTED. Utilizza la registrazione binaria ROW se è abilitata. Verifica i valori effettivi dopo il riavvio anziché presumere che sia stato incluso un file di configurazione. Nextcloud documenta questi requisiti nella sua guida alla configurazione del database e nei requisiti di sistema .

4. Configurare Galera in modo coerente su tutti e tre i membri

Utilizza la documentazione di configurazione del tuo fornitore per impostare il nome del cluster, l'elenco degli indirizzi peer, il nome e l'indirizzo univoci di ciascun nodo, la libreria del provider e il metodo di trasferimento dello snapshot di stato (SST). SST è il processo che fornisce a un nodo che si unisce al cluster lo stato del database. Una tipica configurazione di un cluster MariaDB contiene opzioni di questo tipo:

[mariadb]
wsrep_on=ON
wsrep_cluster_name=nextcloud-cluster
wsrep_cluster_address=gcomm://db1.example.net,db2.example.net,db3.example.net
wsrep_node_name=db1
wsrep_node_address=db1.example.net
wsrep_sst_method=mariabackup
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
transaction_isolation=READ-COMMITTED

Modifica i valori specifici del nodo su ciascun server. I percorsi del provider e i metodi SST supportati dipendono dai pacchetti installati; utilizza il metodo e le credenziali documentati per la tua versione. Proteggi le credenziali SST, i certificati e le password del database come segreti. Non utilizzare mai un indirizzo cluster vuoto come impostazione permanente: la documentazione di MariaDB indica che ciò può causare l'avvio di un nuovo cluster da parte di un server anziché il suo rientro in quello esistente.

5. Limitare l'accesso alla rete ai peer necessari

Consenti al livello web di raggiungere solo l'endpoint del servizio di database e permetti ai membri del database di comunicare tra loro sulle porte di replica e trasferimento dello stato di Galera richieste dal provider e dal metodo SST scelti. Le implementazioni Galera più comuni utilizzano TCP e, a seconda delle impostazioni del provider, UDP per la comunicazione di gruppo; le impostazioni predefinite più comuni includono la porta 4567 per la replica, la 4568 per il trasferimento incrementale dello stato e la 4444 per il trasferimento dello snapshot dello stato. Considera queste porte come una lista di controllo da verificare rispetto alla tua versione e configurazione, non come un motivo per aprire tutte le porte indiscriminatamente. Mantieni privata la porta SQL e nega l'accesso pubblico.

6. Avvia il primo nodo, poi unisci gli altri

Inizializza il cluster una sola volta utilizzando la procedura di bootstrap documentata dal pacchetto MariaDB della tua distribuzione. Dopo aver verificato che il primo membro costituisca il componente primario, avvia normalmente i membri rimanenti in modo che si uniscano ad esso e ricevano lo stato tramite IST o SST. IST trasferisce i set di scrittura mancanti quando disponibili; SST effettua un trasferimento di stato completo. Non eseguire il bootstrap di ciascun host in modo indipendente e non considerare un riavvio come un'azione di bootstrap.

Esegui questa query su ogni membro del database dopo la sua aggiunta:

SHOW GLOBAL STATUS WHERE Variable_name IN
('wsrep_cluster_status','wsrep_cluster_size','wsrep_ready',
 'wsrep_connected','wsrep_local_state_comment');

Verifica che ogni nodo sia connesso e pronto, appartenga al componente primario, riporti la dimensione prevista del cluster e abbia raggiunto uno stato sincronizzato. MariaDB illustra questi indicatori nella sua guida al monitoraggio di Galera .

7. Creare un database Nextcloud dedicato e un account con privilegi minimi.

Crea il database con il set di caratteri e la collazione richiesti dalla guida di installazione corrente di Nextcloud. Crea un utente di database dedicato, limitato alla rete dell'applicazione, e concedigli solo i privilegi necessari per la configurazione e il normale funzionamento di Nextcloud. Utilizza TLS per le connessioni che attraversano host o segmenti di rete non attendibili e convalida i certificati laddove la tua implementazione lo supporti. Non inserire le credenziali di root in config.php.

8. Distribuisci nodi applicativi Nextcloud identici

Installa la stessa versione del codice Nextcloud, le stesse estensioni PHP, le stesse app abilitate e la stessa configurazione del server su ogni nodo web. Configura un endpoint di database condiviso, anziché host di database diversi in file per nodo. Tutti i nodi devono utilizzare lo stesso ID istanza, segreto, salt, policy trusted-domain e altre impostazioni a livello di istanza. Archivia la configurazione in un processo di distribuzione condiviso controllato o distribuiscila in modo sicuro in modo che gli aggiornamenti rimangano identici.

Anche il livello dei dati dei file utente deve essere comune ai nodi dell'applicazione. Utilizza un filesystem condiviso supportato o un'architettura di archiviazione oggetti primaria supportata che corrisponda alla tua versione di Nextcloud e ai requisiti operativi. I dati utente presenti solo localmente su un host web impediscono il failover: una richiesta instradata a un altro host non visualizzerebbe gli stessi file. Mantieni distinti il ​​codice dell'applicazione e i percorsi dei dati scrivibili e convalida il blocco dei file e la semantica di archiviazione prima della produzione.

Nextcloud crea normalmente le impostazioni del database durante l'installazione. Una volta che l'endpoint del database e lo storage condiviso sono pronti, verifica che ogni nodo risolva gli stessi valori. Un frammento di configurazione rappresentativo è il seguente; conserva le credenziali reali in un flusso di lavoro di gestione dei segreti protetto e non incollare questo frammento su una configurazione di produzione esistente:

'dbtype' => 'mysql',
'dbname' => 'nextcloud',
'dbhost' => 'db-vip.internal:3306',
'dbuser' => 'nextcloud',
'dbpassword' => 'REPLACE_WITH_SECRET',
'datadirectory' => '/srv/nextcloud-data',
'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
  'host' => 'redis.internal',
  'port' => 6379,
  'password' => 'REPLACE_WITH_SECRET',
],

Adatta il backend della cache e la directory dei dati alle opzioni supportate dalla tua versione di Nextcloud. Installa e configura le estensioni PHP necessarie, ove applicabile.

9. Aggiungere un servizio di cache distribuita e di blocco dei file

Se necessario, utilizzare APCu per la memorizzazione nella cache locale per host e un servizio condiviso compatibile con Redis, come Redis o Valkey, per la memorizzazione nella cache distribuita e il blocco transazionale dei file. Tutti i nodi web devono fare riferimento allo stesso servizio di cache o cluster di cache supportato, non a localhost. Nextcloud documenta la configurazione del cluster Redis per le configurazioni cluster e precisa che, in caso contrario, il blocco transazionale dei file si basa sul database per impostazione predefinita. Proteggere la cache con restrizioni di rete, autenticazione e TLS, ove necessario; la disponibilità della cache e il comportamento di failover richiedono una progettazione specifica.

10. Posizionare un endpoint compatibile con il database davanti a Galera

Configura Nextcloud in modo che punti a un endpoint stabile fornito da un proxy di database o da un altro livello di routing supportato. Il proxy dovrebbe interrompere l'invio di nuove connessioni ai nodi che non fanno parte del componente primario, non sono sincronizzati o non sono pronti. Un semplice controllo della porta TCP dimostra solo che un socket accetta connessioni; non dimostra che Galera può servire l'applicazione in modo sicuro. Esamina il comportamento del controllo di integrità e le modalità di errore del proxy scelto. Se utilizzi un semplice bilanciatore di carico TCP, abbinalo a un controllo di prontezza di Galera affidabile e a regole di routing conservative.

Non aggiungere la suddivisione lettura/scrittura o il routing round-robin in modo casuale. Il manuale per sviluppatori di Nextcloud descrive il supporto per le connessioni primarie/replica e avverte che il routing delle letture attraverso un cluster può creare problemi di coerenza se i dati non sono stati propagati o se un proxy non è in grado di mantenere le letture transazionali sul nodo corretto. Inizia con un endpoint stabile in grado di scrivere, misurane le prestazioni e introduci il routing specializzato solo quando ne comprendi le implicazioni in termini di coerenza e supporto.

11. Aggiungere impostazioni ridondanti per il bilanciamento del carico web e per i proxy attendibili.

Posiziona almeno due nodi web dietro un bilanciatore di carico e utilizza un meccanismo di disponibilità separato per il bilanciatore di carico stesso, come un servizio gestito, una coppia ridondante o una configurazione IP virtuale testata. Configura la terminazione TLS, le dimensioni delle richieste, il comportamento del timeout e i requisiti di sessione persistente in base alla tua implementazione. Consulta la documentazione del reverse proxy di Nextcloud e imposta trusted_proxiesgli indirizzi proxy effettivi; affidarsi a intervalli di indirizzi IP client arbitrari indebolisce la gestione degli IP client.

12. Procedi con cautela nell'implementazione, quindi testa i guasti e il ripristino.

Prima di procedere, testate gli aggiornamenti su una copia di staging con la stessa topologia. Quando richiesto dalla procedura di aggiornamento, mettete Nextcloud in modalità di manutenzione, applicate la stessa release dell'applicazione a tutti i nodi e riattivate i nodi solo dopo che i controlli di integrità sono stati superati. Per la manutenzione ordinaria degli host, svuotate un nodo web alla volta e verificate che la capacità rimanente sia sufficiente. Applicate gli aggiornamenti del database utilizzando la procedura di aggiornamento progressivo di MariaDB/Galera supportata per le versioni esatte interessate; non create un ordine improvvisato basandovi su un tutorial generico.

Eseguire il backup del database e del livello dati dei file utente utilizzando una procedura documentata e coerente con l'applicazione. Mantenere la configurazione, il materiale di crittografia e i segreti a disposizione degli operatori di ripristino autorizzati. Una replica Galera non è un backup: la cancellazione accidentale e la corruzione logica possono replicarsi su ogni membro. Archiviare i backup al di fuori del dominio di errore del cluster ed eseguire regolarmente prove di ripristino. Galera documenta le considerazioni relative al trasferimento di stato e al backup nelle sue linee guida per il backup del cluster ; verificare che qualsiasi procedura adottata sia compatibile con la versione di MariaDB in uso.

Scegliete un modello in base al carico di lavoro e alla capacità del team.

Galera è una scelta pratica quando è necessaria la ridondanza dei nodi del database, si dispone di più domini di errore e si può monitorare il quorum e implementare un ripristino controllato. Potrebbe non essere la soluzione ideale quando l'obiettivo principale è semplificare le operazioni, quando il carico di lavoro del database è dominato da scritture in conflitto o quando il team non può reagire in modo sicuro alla perdita del quorum. In questi casi, una distribuzione di database più semplice con backup robusti o un servizio di database gestito potrebbero garantire una maggiore affidabilità operativa.

Per un servizio self-hosted di dimensioni ridotte, è consigliabile innanzitutto rendere intercambiabili i nodi dell'applicazione, spostare i file degli utenti su uno storage condiviso durevole, configurare il blocco Redis condiviso ed eseguire test di backup. Aggiungere Galera solo dopo che le misurazioni abbiano dimostrato che il rischio di guasto di un singolo nodo del database o di una finestra di manutenzione è inaccettabile e che l'organizzazione è in grado di gestire il livello aggiuntivo. Il test di successo significativo non è "tutti e tre i server di database sono in funzione", bensì che l'URL di Nextcloud rimanga utilizzabile durante una perdita pianificata di un nodo, che i caricamenti e i download funzionino correttamente tra i nodi web, che il database mantenga il quorum e che il team sia in grado di ripristinare sia i dati del database che i file dal backup.

Lista di controllo rapida per la convalida

• Le versioni di Nextcloud, MariaDB, PHP e Galera sono compatibili e supportate.
• Tutti i nodi del database segnalano l'appartenenza al nodo primario, la dimensione prevista del cluster, lo stato di prontezza e lo stato locale sincronizzato.
• I server applicativi utilizzano lo stesso endpoint del database, la stessa configurazione, la stessa cache e lo stesso sistema di dati dei file.
• Le porte del database, della replica, della cache e dell'archiviazione sono private e limitate ai peer necessari.
• I proxy web e di database rimuovono dal servizio i backend effettivamente non funzionanti.
• È stato testato un guasto pianificato del nodo web e del nodo del database in un intervallo di tempo controllato.
• Durante una prova, sia il backup del database che quello dei file sono stati ripristinati con successo.

Riferimenti ufficiali

• Nextcloud: Configurazione del database
• Nextcloud: caching della memoria
• Nextcloud: Blocco dei file transazionali
• Nextcloud: configurazione del proxy inverso
• Nextcloud: considerazioni su prestazioni e cluster di database
• MariaDB: Quorum, monitoraggio e ripristino
• MariaDB: Monitoraggio del cluster Galera