최고의 성능과 안정성을 제공하는 네트워크 파일 공유 프로토콜은 무엇입니까? [닫은]

몇 개의 웹 서버가로드 밸런싱되는 설정이 있습니다. 모든 웹 서버가 액세스 할 수있는 일종의 네트워크 공유 스토리지를 원합니다. 사용자가 업로드 한 파일을 저장하는 장소로 사용됩니다. 모든 것이 리눅스를 실행하고 있습니다.

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 스토리지 시스템이었습니다. 다른 모든 비용 효과적인 시도에는 단점이있었습니다.

GFS를 고려 했습니까? GFS는 클러스터 파일 시스템이며 필자의 경험으로는 상당히 안정적입니다. 하나 이상의 저널을 가질 수 있으며 꽤 잘 확장됩니다.

그러나 일부 클러스터 서비스를 설치해야하며 GFS는 그 속도를 정확히 알고 있지 않습니다. 오토, 그것은 항상 나를 위해 충분히 빠르지 만 ymmv.

GFS와 같은 분산 FS를 고려하는 것은 마음에 들지 않으며 iSCSI는 과도합니다.

NFS를 사용하여 간단하게 이동하십시오. 간단하고 빠르며 소프트 마운트는 상당히 견고합니다. 또한 함께 제공되는 모든 잠금 정크를 비활성화하십시오. NFS에서 모든 홈 디렉토리와 응용 프로그램을 가져 오는 Linux 데스크탑이 있는데 제대로 작동합니다.

Lustre로 터무니없는 속도를 원한다면 GFS보다 훨씬 쉽고 RAID NFS와 매우 비슷합니다. 클러스터에 Lustre를 사용합니다.

조금 늦을 수도 있습니다. 클러스터 이중 포트가있는 MD3220 Dell Storage를 사용합니다. 장치에 2 개의 컨트롤러가있어 1 초가 걸리면 문제가 해결 될 때까지 계속 실행됩니다. HDD, FAN, 전원 공급 장치 및 컨트롤러는 모두 핫스왑이므로 부품을 교체 할 수 있습니다. 포맷 기준으로 NFS를 사용합니다.

이미 모든 곳에 웹 서버가 있고이를 운영하는 데 능숙하다면 WebDAV를 고려해보십시오.

NFS에 대한 간단한 답변 +1. NFS 공유가 문제없이 몇 년 동안 마운트되어 있습니다.

뛰어난 안정성을 원한다면 분산 자동 장애 조치 NFS 파일 시스템뿐만 아니라 DRBD를 믹스에 넣는 것을 고려하십시오.

유일하게 다른 옵션 (내가 익숙한)은 iSCSI이지만 뒤쪽에서 구성하기가 어려울 수 있습니다 ...

다양한 비용으로 다양한 옵션이 있습니다. FC, iSCSI 또는 최신 추가 기능을 갖춘 공유 SAN 어쨌든 설정 비용이 많이 들며 여전히 클러스터 인식 파일 시스템을 실행해야합니다. 클러스터 파일 시스템은 고통의 세계입니다. 성공을 위해서는 클러스터 통신 및 데이터를위한 별도의 고속 저 지연 네트워크가 필요합니다. 그럼에도 불구하고 결함이 발생하여 노드가 링 펜스되고 죽을 수 있습니다.

번거 로움없이 작동하는 유일한 클러스터 파일 시스템은 VMFS입니다. 그러나 그것은 매우 전문화되어 있기 때문에 일반적인 용도로도 사용할 수 없습니다.

NFS는 아마도 설정을위한 방법 일 것입니다. 복원력이 걱정되는 경우 적절한 클러스터형 NFS 상자가 필요합니다. 홈 브루 설정을 할 수 있지만 위의 문제가 발생합니다. 가장 좋은 방법은 (돈이 있다면) 클러스터 된 NetApp 파일러입니다. 비용이 많이 드는 옵션이지만 클러스터링은 실제로 번거 로움없이 작동합니다. 뿐만 아니라 매우 빠릅니다.

NFS가 아마도 가장 좋은 방법이지만 (그 소리가 이상할지라도) NFS에 대해 경고 한 내용을 에코합니다.

NFS 서버가 사라져서 NFS 서버가 없어서 클라이언트가 커널에서 잠금 해제 또는 종료를 거부했기 때문에 AC에서 연결을 끊어야하는 NFS 클라이언트가있었습니다.

올바르게하려면 NFSv4를 통해 TCP 연결을 사용하고 점보 프레임을 사용하며 NFS 클러스터를 사용합니다. NFS 서버가 사라질 여유가 없습니다.

GFS는 매우 검은 부두입니다. 간단한 두 개의 클라이언트 클러스터 작업을 수행하는 데 필요한 작업량은 대안에 비해 엄청납니다. OCFS2는 배포가 훨씬 간단하지만 연결된 모든 서버에 포함 된 커널 모듈 버전과 관련하여 매우 까다 롭습니다. 이는 시작에 불과합니다.

클러스터 파일 시스템이 제공하는 일종의 저수준 액세스가 실제로 필요한 경우가 아니면 NFS 또는 CIFS 만 있으면됩니다.

대규모 서버 팜에는 수백만 명의 사용자가 HTML 페이지를 만들었습니다. NFS가 제대로 작동하지 않아 결국 mysql 테이블에 넣었습니다. 디렉토리 트리를 순회하는 것과 비교했을 때의 오버 헤드는 거의 같습니다.

SFTP를 사용했는데 목적에 따라 잘 작동했습니다. NFS는 나의 첫 번째 수단 이었지만 사용자 / 그룹 ID의 펑키로 인해 다소 빨리 떨어졌습니다.

공개 키 인증 만 설정하면 크게 설정됩니다. SSH 암호화에는 CPU 오버 헤드가 다소 클 수 있지만 장점으로는 데이터 손상 문제가 발생하지 않았습니다.

FTP는 더 가볍기 때문에 목적에 잘 맞을 수 있습니다. 아마도 당신은 웹 서버가 ssh 작업이 아닌 웹 서비스를 수행하기를 원할 것입니다.