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

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

Questa impostazione predefinita cambia quando il nodo di storage offre un percorso di block storage progettato appositamente, latenza misurata, garanzie di durabilità corrette e un vantaggio in termini di ripristino che giustifica la dipendenza aggiuntiva. La decisione non riguarda semplicemente la capacità locale o di rete: log delle transazioni, file di dati, backup, caricamenti dell'applicazione e database di test temporanei hanno schemi di scrittura e conseguenze dei guasti diversi.

Separa lo stato del database da dump e backup

Mappa ogni percorso relativo al database prima di scegliere un nodo. La directory dei dati primaria e il log delle transazioni sono dati operativi; richiedono un ordine di scrittura coerente e una latenza prevedibile. I dump logici, i backup di base, i log archiviati, le esportazioni e i file caricati dall'applicazione hanno schemi di accesso diversi e spesso possono attraversare la rete senza rischi.

Non montare una singola condivisione NAS e metterci tutto dentro. Tieni il volume del database attivo separato dalle destinazioni di backup e dai dati applicativi in blocco. Così puoi configurare, monitorare, riempire, acquisire snapshot, ripristinare e migrare ogni ruolo senza fingere che tutti i dati persistenti richiedano lo stesso supporto.

Per i database temporanei delle branch o i test CI, il tempo di ricostruzione può contare più della durabilità. Mettili su uno storage locale veloce e ricreali a partire dalle migrazioni o da seed sanitizzati. Per il database di servizio quotidiano di uno sviluppatore, considera il guasto di un SSD locale come un evento di ripristino e mantieni aggiornata la copia remota quanto basta per rispettare l'obiettivo di ripristino dichiarato.

Misura il percorso di scrittura prima di scegliere un nodo

Le prestazioni di un database dipendono da più che dal throughput sequenziale. Misura la latenza dei commit sincroni, le letture e le scritture casuali, la profondità della coda durante il traffico di backup e il comportamento quando il percorso di rete si blocca. Un collegamento 10GbE può trasferire rapidamente file di grandi dimensioni, continuando però ad aggiungere latenza e un altro 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 di archiviazione connessa in rete testati, sottolineando al tempo stesso i vantaggi di elasticità e durabilità dell'archiviazione di rete. Questi benchmark di PostgreSQL con archiviazione locale e connessa in rete non garantiscono gli stessi risultati in un home lab, ma mostrano perché la collocazione del database va valutata misurando i carichi di lavoro, non basandosi solo sulla velocità dell'interfaccia.

Esegui un test rappresentativo con 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 archiviazione. Se la latenza di coda o il tempo di commit diventano irregolari, la capacità centralizzata non compensa i limiti del percorso condiviso.

Per impostazione predefinita, colloca i file del database primario vicino al nodo di calcolo

Per un singolo sviluppatore, un nodo di calcolo e database di dimensioni contenute, gli SSD locali in mirroring o un volume locale ripristinabile in genere offrono 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 archiviazione riceve i backup tramite un processo consapevole del database, anziché ospitare un filesystem remoto sempre accessibile.

La collocazione locale non significa usare un'unica unità di avvio senza protezione. Quando possibile, separa il volume del database da quello del sistema operativo, monitora lo spazio libero e lo stato dell'unità, riserva capacità per le operazioni di manutenzione ed esporta i backup prima degli aggiornamenti. Fissa il posizionamento di container o VM, così che uno scheduler non avvii il database su un altro nodo senza i relativi dati.

Usa l'archiviazione locale solo quando il percorso di ripristino è concreto. Se sostituire il nodo di calcolo richiedesse di affidarsi a una copia obsoleta, l'archiviazione centralizzata potrebbe mettere in luce un problema di backup già esistente, anziché crearlo. Correggi il flusso di lavoro per il backup e il ripristino prima di ottimizzare il percorso dei dati.

Featured

ZimaBoard 2 - Mini server domestico per le tue grandi idee

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Usa il nodo di archiviazione per backup, repliche e archivi

Un nodo di archiviazione è utile quando riceve dump coerenti con l'applicazione, backup di base, log delle transazioni archiviati, snapshot immutabili o una replica del database con una propria funzione di ripristino. Può anche ospitare allegati di grandi dimensioni o esportazioni per l'analisi, mentre il catalogo e i log del database, sensibili alla latenza, restano locali.

I test della community su PostgreSQL su NFS in un server di archiviazione hanno prodotto risultati controintuitivi e domande sulla configurazione, non una risposta valida per tutti. Per questo l’archiviazione remota primaria va considerata un’eccezione progettata appositamente: convalida il comportamento sincrono, la gestione degli errori, le opzioni di montaggio, la semantica della cache e il ripristino sullo stack esatto.

Convalida il ripristino in caso di errore e i criteri per la migrazione

Verifica quattro eventi: riavvia correttamente il database, arresta bruscamente il nodo di calcolo durante le scritture, interrompi il collegamento all’archiviazione durante un backup e ripristina i dati su un host vuoto. Verifica il punto di ripristino, il tempo di ripristino, i controlli di integrità del database e il comportamento di riconnessione dell’applicazione. Un benchmark veloce in condizioni normali non dimostra che il percorso di scrittura sia sicuro in caso di interruzione.

La configurazione è valida quando i dati attivi hanno una latenza prevedibile, i backup non possono sovrascrivere o bloccare il sistema primario e un nodo di calcolo sostitutivo può ripristinare i dati senza presupposti di archiviazione non documentati. Sposta i file primari su un servizio di archiviazione 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 causa di incidenti.

Per scegliere l’architettura generale, il confronto di ZimaSpace tra un NAS orientato all’archiviazione e un server domestico orientato al calcolo aiuta a decidere quale ruolo dovrebbe rimanere stabile mentre cambiano i carichi di lavoro di sviluppo.

Regola finale di configurazione

Imposta come predefinita l’archiviazione locale protetta su SSD per i file attivi del database e usa il nodo di archiviazione per backup verificati, archivi e repliche selezionate. Scegli l’archiviazione remota primaria solo dopo aver misurato le semantiche di scrittura, la latenza di coda, il comportamento durante le interruzioni e i vantaggi in termini di ripristino.