ZFS 헤드 노드를 데이터베이스 서버로 사용합니까?

다음과 같이 Nexenta의 권장 아키텍처를 기반으로 고 가용성 클러스터 공유 스토리지를 위해 듀얼 헤드 ZFS 기반 NAS를 사용하고 있습니다.

1 JBOD의 디스크는 단일 4TB Postgres 데이터베이스의 데이터베이스 파일을 저장하고 다른 JBOD의 디스크는 20TB의 큰 원시 이진 플랫 파일을 저장합니다 (대형 객체 충돌 시뮬레이션의 클러스터 결과). 다시 말해 Postgres 파일을 백업하는 JBOD는 주로 임의의 워크로드를 처리하고 시뮬레이션 결과를 백업하는 JBOD는 주로 직렬 워크로드를 처리합니다. 두 헤드 노드에는 256GB의 메모리와 16 개의 코어가 있습니다. 클러스터에는 각각 약 200 개의 코어가 있으며 Postgres 세션을 유지 관리하므로 약 200 개의 동시 세션이 필요합니다.

ZFS 헤드 노드가 클러스터의 미러 된 Postgres 데이터베이스 서버 쌍으로 동시에 작동하도록 설정하는 것이 현명한 지 궁금합니다. 내가 볼 수있는 유일한 단점은 다음과 같습니다.

인프라 확장을위한 유연성이 떨어집니다.
약간 낮은 수준의 중복성.
Postgres의 제한된 메모리 및 CPU 리소스.

그러나 ZFS는 어쨌든 자동 장애 조치에 대해 꽤 바보이며 헤드 노드와 함께 실패하기 때문에 헤드 노드가 실패했는지 파악하기 위해 각 Postgres 데이터베이스 서버를 얻는 데 많은 작업을 할 필요가 없다는 것입니다. 마디.

— 엘레 시엘
소스

PostgreSQL 은 어떤 형태의 공유 저장 모드에서도 실행할 수 없습니다 . 그렇게하지 않으면 실패합니다. 이동 / 숨김과 같이 보호를 우회하면 postmaster.pid데이터가 심각하게 손상 될 수 있습니다.

— Craig Ringer

@CraigRinger 흠, 이것은 wiki.postgresql.org/wiki/Shared_Storage와 모순 됩니까 ?

— elleciel

하나의 포스트 마스터 만 동시에 데이터 디렉토리에 액세스 할 수 있다는 것을 절대적으로 보장하는 경우이를 실행할 수 있습니다. 좋은 STONITH / 펜싱은 큰 데이터 손상을 피하기위한 절대적인 요구 사항입니다. 개인적으로는 내가 할 방법이 없습니다. 또한 장애 조치 (failover)를 관리해야하므로 기본 / 라이브 서버를 자동으로 결정하는 등의 이점을 제거 할 수 있습니다.

— Craig Ringer

위키 페이지를보다 명확하게 수정했습니다. 지적 해 주셔서 감사합니다.

— Craig Ringer

이것은 말이되지 않습니다. Nexenta의 HA 솔루션은 RSF-1 클러스터링을 활용하고 있습니다. RSF-1이없는 Linux에서 ZFS를 사용하여이 작업을 수행하는 것 같습니다. Linux의 ZFS에는 실제로 클러스터링 옵션이 없으므로 Nexenta 참조가 적용되지 않습니다. 헤드 노드가 두 개 있으면 무엇을 얻을 수 있습니까?

— ewwhite 2016 년

동일한 물리적 파일에 대해 두 개의 Postgres 인스턴스 (Postgres 용어의 "클러스터")를 사용할 수 없습니다.

성능을 원한다면 샤딩이 도움이 될 수 있습니다 (각각 다른 데이터를 전달하는 두 개의 인스턴스가 있음)

고 가용성을 원한다면 STONITH의 장애 조치가 해결책이 될 수 있습니다. 그런 다음 하드웨어가 복구되었는지 확인해야합니다. 두 번째 노드가 서비스를 제공하는 동안 데이터베이스를 열지 마십시오.

— 야센
소스