☰

NFS(중간)가 귀하의 사용 사례에 적합한 이유는 무엇입니까?

tag-icon • tag-icon nfs
NFS(중간)가 귀하의 사용 사례에 적합한 이유는 무엇입니까?

여러 Linux 시스템 간에 파일을 공유하려고 합니다. NFS는 2023년에 이를 달성할 수 있는 좋은 방법입니까?

저는 NFS에 대해 잘 모릅니다. 내 생각에 NFS는 오래되고, 버그가 많고, 신뢰할 수 없고, 설계가 잘못되고, 구식이며, 이전 시스템과의 하위 호환성을 위해서만 사용해야 한다는 것입니다. 이 말이 어느 정도 맞나요? 새로운 배포에 NFS를 사용하는 것이 현명한가요? 더 좋은 것을 사용할 수 있을까요?

답변1

요약: 아니요. NFS는 여전히 관련성이 높고 활발하며 많은 상황에서 좋은 선택입니다.

NFS(중간)가 귀하의 사용 사례에 적합한 이유는 무엇입니까?

실제로 사용 사례에 따라 다릅니다. 나는 NFS가 일반적으로 오래되었거나 일반적으로 잘못 설계되었다는 데 동의하지 않습니다. 최신 요구 사항을 충족하도록 업데이트되지 않았기 때문에 확실히 "오래된" 것은 아닙니다. NFS 4.2는 2016년에, SMB 3.1.1도 2016년에 출시되었으며, 각 프로토콜 개정판에 이미 몇 개의 기능이 포함되어 있는지 모르겠습니다. Linux 커널 서버와 클라이언트는 각각 Samba에서 구현됩니다.

NFS 상태

그것예하나원격 프로시저 호출(RPC) 프로토콜: 클라이언트가 이를 통해 수행하는 작업은 호출입니다.기능서버에서 서버는 결과를 보냅니다. 그런 다음 클라이언트는 이 메커니즘을 사용하여 파일 시스템을 로컬로 제공합니다.

이것은 매우 깔끔한 디자인입니다. 국가의 "소유자"가 누구인지 분명하므로 일반적으로 분산 시스템을 어렵게 만듭니다. 그러나 이는 다양한 네트워크 지연 등의 측면에서 전체 시스템이 더 스마트해져야 함을 의미합니다. 일부 기능을 사용하려면 최신 버전의 NFS가 필요합니다. 글쎄요, 이 기능적 접근 방식은 훌륭합니다. 서버에서 파일을 복사하는 것은 단지 서버에 대한 함수 호출일 뿐입니다. 대용량 파일의 중간에서 일부 파일 내용을 요청하는 것과 소프트웨어에 일부 파일 내용이 필요할 수 있음을 서버에 알리는 것 사이의 것입니다. CIFS와 같은 기능은 잘 작동할 것이며 기본적으로 UNIX 파일 시스템의 작동 방식과 일치하며 CIFS보다 약간 더 좋습니다.

슬프게도,많은NFS 설정 방법에 대한 웹 자료는 23년 전에 끝날 것으로 예상되었던 NFSv3 시대의 것입니다. 그러나 네트워크 프로토콜을 최적화하는 것은 어렵기 때문에 사람들은 모범 사례를 복사합니다. 일부는 여전히 적용되고 일부는 단지 구식입니다. 솔직히 NFS에는 가장 중요한 문서화 문제가 있습니다. 즉, 일반적인 최신 하드웨어와 다양한 네트워크 크기 및 속도에 대한 일반적인 지침이 없습니다. 많은 사람들은 설정을 시작하기 전에 한두 권의 책을 읽어도 괜찮다고 생각합니다.

그러나 솔직히 말해서 Fedora-oid OS의 기본 구성은 아마도 괜찮을 것입니다(다른 OS에서는 NFS에 대한 경험이 없습니다). 그러나 가능하다면 모든 내보내기에서 확실히 "zip root"를 원하며 진정한 Kerberos 인증이 필요합니다. 이는 매우 안전한 "엔터프라이즈급"이며 Microsoft Active Directory의 기반입니다. 하지만 그것은예진입 장벽이 없으면 서버가 파일에 액세스하고 있다고 주장하는 사용자가 실제로 해당 사용자라는 클라이언트를 신뢰합니다.

대안

여러 가지 옵션이 있습니다. 여기에 모든 대안을 나열하는 것은 불가능하지만(저는 해당 분야에 속하지 않습니다) 소규모 네트워크 관리자가 직면하게 될 주요 문제는 다음과 같습니다.

  • SMB/CIFS, Samba 사용: "Windows World Compatible" 접근 방식. 올바르게 설정하면 NFS 속도에 거의 근접할 수 있습니다. 암호화 시 성능 문제가 발생할 수 있으며, 설치 프로그램은 사용자 관리의 기반으로 별도의 사용자 데이터베이스(일반적으로) 또는 NFS(유사)와 동일한 기업 수준의 "Active Directory"를 유지해야 합니다.대개NFS보다 더 완화되었습니다. 즉, 두 개의 서로 다른 시스템이 동일한 파일에 액세스하는 상황이 있지만 이는 서로 다릅니다.
  • iSCSI: 읽기 전용 파일 시스템(예: 정적 부팅 이미지 아카이브)을 내보내야 하는 경우 다른 운영 체제에서 미리 부팅할 수도 있습니다. "내 파일 공유"보다 "내 디스크 장치 공유"에 더 가깝습니다.
  • SSHFS: 한 명의 사용자만 동일한 파일에 액세스하는 사용 사례에 적합하며 최근 성능과 안정성이 크게 향상되었습니다. 하지만 이제(2023년 7월) 2022년 5월부터 더 이상 유지되지 않습니다. 장기적으로 확신할 수 있을지 확실하지 않으며, 일관성 프로토콜이 없으면 파일 x가 열려 있는 클라이언트 A가 클라이언트 B의 파일 요청을 볼 수 없기 때문에 여러 사용자가 동일한 파일에 액세스하기를 원하는 경우는 확실히 아닙니다. x 관련 부품이 로컬로 전송된 경우(일반적으로 그렇습니다) 어떻게 됩니까?
  • Lustere, Ceph 파일 시스템...: 일반적으로 컴퓨터가 자체 공간을 채울 수 없다면 이를 처리하기에는 너무 작은 것입니다 :)

따라서 실제로 이러한 모든 대안 중에서 Samba 서버가 유일하게 실행 가능한 옵션인 것 같습니다. Windows와 상호 운용이 필요한 경우 Samba는 올바른 선택이고, 성능의 마지막 30%를 중요하게 생각하고 시간을 투자할 의향이 있는 경우에는 잘못된 선택입니다.

관련 정보