몇 개의 웹 서버가로드 밸런싱되는 설정이 있습니다. 모든 웹 서버가 액세스 할 수있는 일종의 네트워크 공유 스토리지를 원합니다. 사용자가 업로드 한 파일을 저장하는 장소로 사용됩니다. 모든 것이 리눅스를 실행하고 있습니다.
NFS, CIFS, SMB, fuse + sftp, fuse + ftp를 사용해야합니까? 네트워크 파일 공유 프로토콜에 대한 선택이 너무 많아서 선택하기가 매우 어렵습니다. 기본적으로이 공유를 여러 머신에 영구적으로 마운트하려고합니다. 보안 기능은 마운트하는 서버 이외의 다른 곳에서는 네트워크에 액세스 할 수 없으므로 걱정할 필요가 없습니다. 우리는 그것이 안정적이고 빠르게 작동하기를 원합니다.
어느 것을 사용해야합니까?
답변
NFS에 투표합니다.
NFSv4.1에는 Parallel NFS pNFS 기능이 추가되어 병렬 데이터 액세스가 가능합니다. 유닉스와 같은 경우에만 성능 수치를 기반으로 NFS를 사용하려는 경우 어떤 종류의 클라이언트가 스토리지를 사용하는지 궁금합니다.
답변
짧은 대답은 NFS를 사용하는 것입니다. 이 총격전 과 내 경험 에 따르면 더 빠릅니다.
그러나 더 많은 옵션이 있습니다! 여러 컴퓨터가 한 번에 액세스 할 수있는 파일 시스템 인 GFS와 같은 클러스터 FS를 고려해야합니다. 기본적으로 GFS 파일 시스템 인 iSCSI를 통해 블록 장치를 공유합니다. 모든 클라이언트 (iSCSI 용어의 초 기자)는 읽고 쓸 수 있습니다. Redhat에는 백서가 있습니다. oracle의 클러스터 FS OCFS 를 사용하여 동일한 것을 관리 할 수도 있습니다 .
Redhat 백서는 클러스터 FS와 NFS의 장단점을 잘 정리 한 것입니다. 기본적으로 확장 가능한 공간을 많이 원한다면 GFS가 노력할 가치가 있습니다. 또한 GFS 예제는 파이버 채널 SAN을 예로 사용하지만 RAID, DAS 또는 iSCSI SAN과 마찬가지로 간단합니다.
마지막으로 점보 프레임을 살펴보고 데이터 무결성이 중요한 경우 점보 프레임에 iSCSI를 사용하는 경우 CRC32 체크섬을 사용하십시오.
답변
우리는 2 개의 서버로드 밸런싱 웹 클러스터를 보유하고 있으며 서버간에 컨텐츠를 동기화하기 위해 다음 방법을 시도했습니다.
- 각 서버의 로컬 드라이브는 10 분마다 RSYNC 와 동기화
- 중앙 CIFS (SAMBA) 가 두 서버와 공유
- 두 서버에 대한 중앙 NFS 공유
- OCFS2를 실행하는 공유 SAN 드라이브는 두 서버를 모두 마운트했습니다.
RSYNC의 해결책은 간단했지만, 변경 표시하고 RSYNC 우리가 그것을 초마다 일시 정지 사용자 정의 스크립트를 스로틀했다 서버에 너무 많은 부하가 걸릴 것이 10 분 걸렸다. 또한 소스 드라이브에만 쓰는 것으로 제한되었습니다.
가장 빠른 성능의 공유 드라이브는 OCFS2 클러스터 드라이브 가 제자리에 들어가 클러스터를 손상시킬 때까지 바로 작동했습니다. 우리는 OCFS2로 안정성을 유지할 수 없었습니다. 둘 이상의 서버가 동일한 파일에 액세스하자마자로드가 지붕을 통해 올라가고 서버가 재부팅되기 시작합니다. 이것은 우리의 훈련 실패 일 수 있습니다.
다음 최고는 NFS 였습니다 . 매우 안정적이며 내결함성이 있습니다. 이것이 현재 설정입니다.
SMB (CIFS)에 잠금 문제가있었습니다. 특히 웹 서버에서 SMB 서버의 파일 변경 사항을 볼 수 없었습니다. SMB 서버를 장애 조치 할 때 SMB도 중단되는 경향이 있음
우리의 결론 은 OCFS2가 가장 잠재력이 있지만 생산에 사용하기 전에 많은 분석이 필요하다는 것이 었습니다. 간단하고 안정적인 것을 원한다면 장애 조치를 위해 하트 비트가있는 NFS 서버 클러스터를 사용하는 것이 좋습니다.
답변
나는 당신에게 POHMELFS를 제안합니다-그것은 러시아 프로그래머 Evgeniy Polyakov에 의해 만들어졌으며 정말 빠릅니다.
답변
신뢰성과 보안 측면에서 CIFS (일명 Samba)이지만 NFS는 훨씬 더 가벼우 며 신중하게 구성하면 귀중한 데이터를 네트워크의 다른 모든 시스템에 완전히 노출시킬 수는 없습니다.
FUSE에 대한 모욕은 없지만, 내가 무슨 뜻인지 알면 여전히 … 신선 해 보입니다. 아직 그것을 신뢰하는지는 모르겠지만, 그것은 단지 오래된 포모 일 수도 있지만, 오래된 포모 니즘은 귀중한 엔터프라이즈 데이터와 관련하여 때로는 보증됩니다.
여러 머신에 하나의 공유를 영구적으로 마운트하고 이상한 점 (대부분 UID / GID 문제)과 함께 재생할 수 있으려면 NFS를 사용하십시오. 나는 그것을 사용하고 몇 년 동안 가지고 있습니다.
답변
NFS. 그것은 시도되고 사실이며, 견고한 설정을 할 수 있습니다. GFS 성능은 일반적으로 특히 작은 파일 수가 많은 파일 시스템에서 끔찍합니다. OCFS를 사용하지는 않았지만 일반적으로 클러스터 파일 시스템 개념에 눈살을 찌푸립니다. 그런 다음 Lustre가 있지만 다른 웜 캔일 수도 있습니다.
답변
NFS에 대해서는 조언하지 않겠습니다. 간단히 말해 우리는 JBoss, Apache, Tomcat 및 Oracle이 모두 공통 구성 파일 및 로깅을 위해 NFS 공유를 사용하는 웹 서버 팜을 가지고있었습니다.
NFS 공유가 사라지면 (드물게 발생하지만) 실제로 모든 것이 무너졌습니다 (실제로 예측 가능 하며이 구성 시간 단축에 대해 ‘개발자’에게 조언했습니다).
우리가 사용하는 NFS 버전에 문제가있는 것 같습니다. 쓰기 중에 대상이 사라지면 클라이언트는 결코 끝나지 않는 대기 루프에 빠지고 NFS 대상이 돌아 오기를 기다립니다. NFS 상자가 다시 연결 되더라도 루프는 여전히 종료되지 않았습니다.
우리는 RHEL 3,4,5의 혼합을 사용하고있었습니다. 스토리지는 RHEL4에 있었고 서버는 RHEL5에 있었고 스토리지 네트워크는 별도의 LAN이며 VLAN에서 실행되지 않았습니다.
로드 밸런싱 된 프런트 엔드가있는 경우 단일 스토리지를 확인하면 시스템에 병목 현상이 발생하지 않습니까?
파일이 업로드 될 때 업로드 된 파일을 ftp / scp를 통해 스토리지로 이동하는 이벤트 중심 스크립트를 사용하여 스토리지에 대한 읽기 전용 iSCSI 연결을 고려 했습니까?
여러 개의 읽기 헤드에 대해 중앙 집중식 스토리지를 성공적으로 구현 한 유일한 시간은 EMC 스토리지 시스템이었습니다. 다른 모든 비용 효과적인 시도에는 단점이있었습니다.