다음과 같이 Nexenta의 권장 아키텍처를 기반으로 고 가용성 클러스터 공유 스토리지를 위해 듀얼 헤드 ZFS 기반 NAS를 사용하고 있습니다.
1 JBOD의 디스크는 단일 4TB Postgres 데이터베이스의 데이터베이스 파일을 저장하고 다른 JBOD의 디스크는 20TB의 큰 원시 이진 플랫 파일을 저장합니다 (대형 객체 충돌 시뮬레이션의 클러스터 결과). 다시 말해 Postgres 파일을 백업하는 JBOD는 주로 임의의 워크로드를 처리하고 시뮬레이션 결과를 백업하는 JBOD는 주로 직렬 워크로드를 처리합니다. 두 헤드 노드에는 256GB의 메모리와 16 개의 코어가 있습니다. 클러스터에는 각각 약 200 개의 코어가 있으며 Postgres 세션을 유지 관리하므로 약 200 개의 동시 세션이 필요합니다.
ZFS 헤드 노드가 클러스터의 미러 된 Postgres 데이터베이스 서버 쌍으로 동시에 작동하도록 설정하는 것이 현명한 지 궁금합니다. 내가 볼 수있는 유일한 단점은 다음과 같습니다.
- 인프라 확장을위한 유연성이 떨어집니다.
- 약간 낮은 수준의 중복성.
- Postgres의 제한된 메모리 및 CPU 리소스.
그러나 ZFS는 어쨌든 자동 장애 조치에 대해 꽤 바보이며 헤드 노드와 함께 실패하기 때문에 헤드 노드가 실패했는지 파악하기 위해 각 Postgres 데이터베이스 서버를 얻는 데 많은 작업을 할 필요가 없다는 것입니다. 마디.
답변
동일한 물리적 파일에 대해 두 개의 Postgres 인스턴스 (Postgres 용어의 “클러스터”)를 사용할 수 없습니다.
성능을 원한다면 샤딩이 도움이 될 수 있습니다 (각각 다른 데이터를 전달하는 두 개의 인스턴스가 있음)
고 가용성을 원한다면 STONITH의 장애 조치가 해결책이 될 수 있습니다. 그런 다음 하드웨어가 복구되었는지 확인해야합니다. 두 번째 노드가 서비스를 제공하는 동안 데이터베이스를 열지 마십시오.