공유 디스크용 파일 시스템 선택(GFS와 같은 클러스터 파일 시스템 아님)

공유 디스크용 파일 시스템 선택(GFS와 같은 클러스터 파일 시스템 아님)

SAN에 많은 서버가 연결되어 있습니다. 한 서버는 운영 데이터베이스 서버를 호스팅하고 모든 서버로 내보낸 LUN에서 파일 시스템의 전체 데이터베이스 백업을 수행합니다.

"소유자"(프로덕션 서버)만이 이 파일 시스템을 읽기-쓰기로 마운트할 수 있습니다. 소유자가 전체 백업을 수행할 때 sync호출됩니다 .

다른 호스트는 나중에 백업에 빠르게 액세스하고 복사본을 마운트하기 위해 이 파일 시스템을 읽기 전용으로 마운트합니다. 이렇게 하면 네트워크가 백업 전송에 병목 현상을 일으키지 않게 됩니다.

나는 오랫동안 아무런 결함 없이 Solaris의 일반 UFS 파일 시스템에서 이 설정을 사용해 왔습니다.

이제 Linux(RHEL6)에서 동일한 설정을 설정하고 있으며 어떤 파일 시스템을 선택할지에 대한 조언을 받고 싶습니다. 소유자 이외의 다른 호스트가 변경하는 것을 절대 원하지 않기 때문에 단순한 것이 더 좋다고 생각합니다. 디스크의 구조가 커널이 "알고 있는" 것과 더 이상 일치하지 않으면 소유자 커널을 혼란스럽게 하는 로그 재생이나 기타 이상한 작업이 없습니다.

내 질문을 이해할 수 있기를 바랍니다. Linux에서 읽기 전용 파일 시스템(예: 로그 재생)을 마운트할 때 어떤 일이 발생하는지 본 적이 있는데, 이것이 약간 걱정스럽습니다.

나는 간단한 것을 찾고 있습니다. 핸드셰이크와 하트비트가 필요한 클러스터형 파일 시스템이 아닙니다. 하나의 노드에만 써야 합니다.

답변1

리눅스에 따르면매뉴얼 페이지마운트하려면 ext3/ext4 파일 시스템에 "-o ro,noload"를 사용할 수 있습니다(이것이 제가 선택한 FS입니다).

답변2

이전에 이 문제가 발생하지 않은 것이 행운이라고 생각합니다.

물론 대부분의 파일 시스템에서 문제 없이 여러 상자를 읽기 전용으로 읽을 수 있어야 합니다. 그리고 예방할 수 있어요모두장치를 읽기 전용으로 설정(예:블록 개발자).

하지만 쓰기 호스트가 파일 시스템이 다른 곳에 마운트되어 있는 동안 파일 시스템을 fsck하기로 결정하면 현재 아키텍처에서는 어떤 일이 일어날 것이라고 생각하십니까?

저라면 두 RAID1 세트 사이에 디스크를 이동하여 SAN의 스냅샷 시설을 통해 데이터를 마이그레이션하는 것이 더 나은 접근 방식이라고 생각합니다. 아니면 네트워크 파일 시스템이나 클러스터 파일 시스템을 사용하세요.

관련 정보