Usi il nodo head ZFS come server database?

Sto usando un NAS dual-head con supporto ZFS per l'archiviazione condivisa del cluster ad alta disponibilità, basata sull'architettura consigliata di Nexenta come mostrato qui:

I dischi in 1 JBOD memorizzeranno i file del database per un singolo database Postgres da 4 TB e i dischi nell'altro JBOD memorizzeranno 20 TB di file flat binari grezzi di grandi dimensioni (i risultati del cluster per simulazioni di collisione di oggetti stellari di grandi dimensioni). In altre parole, il JBOD che supporta i file Postgres gestirà principalmente carichi di lavoro casuali mentre il JBOD che supporta i risultati della simulazione gestirà principalmente i carichi di lavoro seriali. Entrambi i nodi head hanno 256 GB di memoria e 16 core. Il cluster ha circa 200 core ciascuno che mantiene una sessione di Postgres, quindi mi aspetto circa 200 sessioni simultanee.

Mi chiedo se è saggio nella mia configurazione che i nodi head ZFS agiscano contemporaneamente come una coppia speculare di server di database Postgres per il mio cluster? Gli unici inconvenienti che posso vedere sono:

Meno flessibilità per ridimensionare la mia infrastruttura.
Livello di ridondanza leggermente più basso.
Memoria e risorse della CPU limitate per Postgres.

Tuttavia, il vantaggio che vedo è che ZFS è piuttosto stupido riguardo al failover automatico e non devo spendere molto lavoro per far sì che ciascun server di database Postgres capisca se un nodo head ha fallito poiché fallirà insieme alla testa nodo.

— elleciel
fonte

PostgreSQL non può essere eseguito in nessuna forma di modalità di archiviazione condivisa. I tentativi di farlo falliranno. I tentativi di bypassare le protezioni per impedirti di farlo (come spostare / nascondere postmaster.pid) comporteranno una grave corruzione dei dati.

— Craig Ringer,

@CraigRinger Hm, è contraddittorio per wiki.postgresql.org/wiki/Shared_Storage ?

— elleciel,

Puoi eseguirlo se garantisci assolutamente che un solo postmaster può mai accedere alla directory dei dati contemporaneamente. Una buona STONITH / scherma è un requisito assoluto per evitare la corruzione dei dati big-time. Personalmente non c'è modo di farlo. Questo elimina anche i vantaggi di cui stai parlando - capire quale è il server principale / live automaticamente, ecc. - perché devi gestire il failover.

— Craig Ringer,

Ho rivisto la pagina wiki per renderlo più chiaro; Grazie per segnalarlo.

— Craig Ringer,

Questo non ha senso. La soluzione HA di Nexenta sta sfruttando il clustering RSF-1 . Sembra che tu lo stia facendo con ZFS su Linux senza il pezzo RSF-1. Intendiamoci, ZFS su Linux non ha davvero un'opzione di clustering, quindi il riferimento Nexenta non si applica. Cosa devi guadagnare avendo due nodi principali?

— ewwhite,

Non puoi avere due istanze di Postgres ("cluster" nella terminologia di Postgres) che agiscono sugli stessi file fisici.

se vuoi prestazioni, lo sharding può aiutarti (avere due istanze ognuna con dati diversi)

Se si desidera l'alta disponibilità, la soluzione potrebbe essere il failover con STONITH. è necessario assicurarsi che l'hardware sia riparato e che non tenti di aprire il database mentre il secondo nodo lo sta servendo.

— Jasen
fonte