Uno sviluppatore dovrebbe mantenere i database sul nodo di calcolo o sul nodo di archiviazione?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Should a Developer Keep Databases on the Compute Node or the Storage Node? - Zima Store Online

Mantieni per impostazione predefinita i file attivi del database su uno storage a bassa latenza vicino alle risorse di calcolo, quindi usa il nodo di storage per backup, dump, repliche e archivi.

Questa impostazione cambia quando il nodo di storage offre un percorso di block storage progettato intenzionalmente, una latenza misurata, semantiche di durabilità corrette e un vantaggio in termini di ripristino che valga la dipendenza aggiuntiva. La decisione non riguarda semplicemente la capacità locale rispetto a quella di rete: log delle transazioni, file di dati, backup, caricamenti dell'applicazione e database di test temporanei hanno pattern di scrittura e conseguenze in caso di guasto differenti.

Separa lo stato del database da dump e backup

Mappa ogni percorso correlato al database prima di scegliere un nodo. La directory principale dei dati e il log delle transazioni rappresentano lo stato attivo; richiedono un ordinamento coerente delle scritture e una latenza prevedibile. I dump logici, i backup di base, i log archiviati, le esportazioni e i file caricati dall'applicazione hanno pattern di accesso diversi e spesso possono attraversare la rete in sicurezza.

Non montare una sola condivisione NAS e inserirvi tutto. Mantieni distinto il volume attivo del database dalle destinazioni dei backup e dai dati applicativi in blocco. In questo modo puoi configurare, monitorare, riempire, creare snapshot, ripristinare e migrare ogni ruolo senza fingere che tutti i byte persistenti abbiano bisogno dello stesso supporto.

Per i database di branch di breve durata o per i test CI, il tempo di ricreazione può essere più importante della durabilità. Collocali su uno storage locale rapido e ricreali a partire dalle migrazioni o da seed sanificati. Per il database del servizio quotidiano di uno sviluppatore, considera il guasto di un SSD locale come un evento di ripristino e mantieni la copia remota abbastanza aggiornata da soddisfare il punto di ripristino dichiarato.

Misura il percorso di scrittura prima di scegliere un nodo

Le prestazioni del database dipendono da più fattori della velocità di trasferimento sequenziale. Misura la latenza del commit sincrono, le letture e scritture casuali, la profondità della coda durante il traffico dei backup e il comportamento quando il percorso di rete si blocca. Un collegamento 10GbE può trasferire rapidamente file di grandi dimensioni, aggiungendo comunque latenza e un ulteriore punto di guasto a ogni transazione.

Un confronto pubblicato su PostgreSQL ha rilevato che l'NVMe locale offriva una latenza inferiore e più prevedibile rispetto ai servizi cloud con storage connesso in rete testati, evidenziando al contempo i vantaggi in termini di elasticità e durabilità dello storage di rete. Questi benchmark di PostgreSQL locale e connesso in rete non costituiscono una garanzia per un home lab, ma mostrano perché il posizionamento del database richieda misurazioni del carico di lavoro anziché basarsi soltanto sulla velocità dell'interfaccia.

Esegui un test rappresentativo usando lo stesso filesystem, le stesse impostazioni di sincronizzazione, la stessa versione del database, lo stesso dataset e la stessa concorrenza previsti per il servizio. Durante il test, avvia un backup di grandi dimensioni o un trasferimento di contenuti multimediali sulla rete di storage. Se la latenza di coda o il tempo di commit diventano irregolari, la capacità centralizzata non compensa il percorso condiviso.

Colloca per impostazione predefinita i file principali del database vicino alle risorse di calcolo

Per uno sviluppatore, un nodo di calcolo e database di dimensioni moderate, gli SSD locali in mirroring o un volume locale ripristinabile offrono generalmente la gestione più chiara. Il processo del database, i suoi file di dati e il suo log write-ahead si guastano insieme, mentre il nodo di storage riceve i backup tramite un processo consapevole del database invece di ospitare in remoto un filesystem sempre aperto.

Il posizionamento locale non significa usare un'unica unità di avvio non protetta. Se possibile, separa il volume del database dal sistema operativo, monitora lo spazio libero e lo stato delle unità, riserva capacità per le operazioni di manutenzione ed esporta i backup prima degli aggiornamenti. Fissa il posizionamento di container o macchine virtuali affinché uno scheduler non avvii il database su un altro nodo senza il relativo stato.

Usa lo storage locale solo quando il percorso di ripristino è reale. Se sostituire il nodo di calcolo richiederebbe di fare affidamento su una copia obsoleta, lo storage centralizzato potrebbe rivelare un problema di backup già esistente anziché crearne uno. Risolvi il flusso di backup e ripristino prima di ottimizzare il percorso dei dati.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Usa il nodo di storage per backup, repliche e archivi

Un nodo di storage è prezioso quando riceve dump coerenti con l'applicazione, backup di base, log delle transazioni archiviati, snapshot immutabili o una replica del database con un proprio scopo di ripristino. Può inoltre contenere allegati di grandi dimensioni o esportazioni analitiche, mentre il catalogo del database e i log sensibili alla latenza rimangono locali.

Ruolo dei dati	Posizione predefinita	Motivo	Test richiesto
Dati principali e log delle transazioni	SSD del nodo di calcolo	Percorso di scrittura più rapido e prevedibile	Latenza del commit e ripristino dopo un arresto anomalo
Dump logici	Nodo di storage	Origine di ripristino portabile e consapevole della versione	Ripristino in un database vuoto
Backup di base e log archiviati	Nodo di storage	Ripristino point-in-time	Ripristino a un timestamp specifico
Replica in lettura	Uno dei due nodi con il proprio volume	Scalabilità delle letture o opzione di ripristino	Ritardo e procedura di promozione
Caricamenti, esportazioni e analisi a freddo	Nodo di storage	La capacità conta più della latenza delle transazioni	Impatto dei trasferimenti simultanei

I test della community su PostgreSQL su NFS su un server di storage hanno prodotto risultati controintuitivi e domande sulla configurazione, non una risposta universale. Per questo lo storage primario remoto va trattato come un'eccezione progettata: verifica il comportamento della sincronizzazione, la gestione dei guasti, le opzioni di mount, la semantica della cache e il ripristino sull'intero stack effettivo.

Convalida il ripristino in caso di guasto e il criterio di migrazione

Testa quattro eventi: riavvia il database correttamente, arresta bruscamente il nodo di calcolo durante le scritture, interrompi il collegamento allo storage durante un backup e ripristina su un host vuoto. Conferma il punto di ripristino, il tempo di ripristino, i controlli di integrità del database e il comportamento della riconnessione dell'applicazione. Un benchmark normale e veloce non dimostra che il percorso di scrittura interrotto sia sicuro.

La configurazione è valida quando i dati attivi hanno una latenza prevedibile, i backup non possono sovrascrivere o bloccare il database primario e un nodo di calcolo sostitutivo può eseguire il ripristino senza presupposti di storage non documentati. Sposta i file principali su un servizio di storage progettato appositamente solo quando i vantaggi misurati in termini di ripristino o mobilità superano la dipendenza dalla rete; riportali in locale quando la latenza di coda o le interruzioni del collegamento diventano la principale fonte di incidenti.

Per una scelta architetturale più ampia, il confronto ZimaSpace tra un NAS incentrato sullo storage e home server incentrato sul calcolo aiuta a decidere quale ruolo debba rimanere stabile mentre cambiano i carichi di lavoro degli sviluppatori.

Regola finale di configurazione

Imposta come predefinito uno storage SSD locale e protetto per i file attivi del database e usa il nodo di storage per backup verificati, archivi e repliche selezionate. Scegli lo storage primario remoto solo dopo aver misurato la semantica delle scritture, la latenza di coda, il comportamento durante le interruzioni e il vantaggio in termini di ripristino.