Używasz węzła głównego ZFS jako serwera bazy danych?

Używam dwugłowicowego NAS wspieranego przez ZFS do współdzielonej pamięci masowej klastra o wysokiej dostępności, w oparciu o architekturę zalecaną przez Nexenta, jak pokazano tutaj:

Dyski w 1 JBOD będą przechowywać pliki bazy danych dla pojedynczej bazy danych Postgres o wielkości 4 TB, a dyski w drugim JBOD przechowują 20 TB dużych surowych plików binarnych płaskich (wyniki klastrów dla symulacji kolizji dużych obiektów gwiazdowych). Innymi słowy, JBOD wspierający pliki Postgres będzie obsługiwał głównie losowe obciążenia, podczas gdy JBOD wspierający wyniki symulacji będzie obsługiwał głównie obciążenia szeregowe. Oba węzły główne mają 256 GB pamięci i 16 rdzeni. Klaster ma około 200 rdzeni, z których każdy utrzymuje sesję Postgres, więc oczekuję około 200 równoczesnych sesji.

Zastanawiam się, czy mądrze jest w mojej konfiguracji, aby węzły główne ZFS działały jednocześnie jako dublowana para serwerów bazy danych Postgres dla mojego klastra? Jedyne wady, które widzę to:

Mniejsza elastyczność skalowania mojej infrastruktury.
Nieco niższy poziom redundancji.
Ograniczona pamięć i zasoby procesora dla Postgres.

Widzę jednak tę zaletę, że ZFS jest dość głupi, jeśli chodzi o automatyczne przełączanie awaryjne i nie muszę poświęcać dużo pracy na to, aby każdy serwer bazy danych Postgres zorientował się, czy wystąpił awaria węzła głównego, ponieważ ulegnie awarii wraz z głową węzeł.

— elleciel
źródło

PostgreSQL nie może być uruchamiany w żadnej formie trybu pamięci współdzielonej. Próby tego nie powiodą się. Próby ominięcia zabezpieczeń uniemożliwiających wykonanie tej czynności (np. Przenoszenie / ukrywanie postmaster.pid) spowodują poważne uszkodzenie danych.

— Craig Ringer

@CraigRinger Hm, czy jest to sprzeczne z wiki.postgresql.org/wiki/Shared_Storage ?

— elleciel

Możesz go uruchomić, jeśli absolutnie gwarantujesz, że tylko jeden postmaster może uzyskiwać dostęp do katalogu danych w tym samym czasie. Dobra STONITH / ogrodzenie jest absolutnym wymogiem, aby uniknąć poważnego uszkodzenia danych. Osobiście nie ma mowy, żebym to zrobił. Eliminuje to także korzyści, o których mówisz - automatyczne ustalanie, który jest głównym serwerem / serwerem na żywo itp. - ponieważ musisz zarządzać przełączaniem awaryjnym.

— Craig Ringer

Poprawiłem stronę wiki, aby była bardziej przejrzysta; dzięki za zwrócenie na to uwagi.

— Craig Ringer

To nie ma sensu. Rozwiązanie HA firmy Nexenta wykorzystuje klastrowanie RSF-1 . Wygląda na to, że robisz to z ZFS na Linuksie bez elementu RSF-1. Pamiętaj, że ZFS w systemie Linux tak naprawdę nie ma opcji klastrowania, więc odwołanie do Nexenta nie ma zastosowania. Co musisz zyskać, mając dwa główne węzły?

— ewwhite

Nie można mieć dwóch instancji Postgres („klastrów” w terminologii Postgres) działających na tych samych plikach fizycznych.

jeśli chcesz wydajności, dzielenie na fragmenty może ci pomóc (mieć dwa wystąpienia przenoszące różne dane)

Jeśli chcesz wysokiej dostępności, rozwiązaniem może być przełączenie awaryjne za pomocą STONITH. musisz upewnić się, że następnie sprzęt zostanie naprawiony, nie będzie próbował otworzyć bazy danych, gdy drugi węzeł ją obsługuje.

— Jasen
źródło