네트워크 파일 시스템은 로컬 파일 시스템과 비슷한 방식으로 네트워크를 통해 원격 클라이언트에게 액세스를 허용하는 파일 시스템에 대한 네트워크 추상화이다. 이러한 시스템 중 최초는 아니지만 NFS는 UNIX®에서 가상 강력하고 광범위하게 사용되는 네트워크 파일 시스템으로 발전했다. NFS는 다수의 사용자 사이에서 공통 파일 시스템의 공유를 허용하며 데이터를 중앙 집중화하여 필요한 스토리지를 최소화하는 혜택을 제공한다.

이 기사는 NFS의 간단한 이력과 기원 및 발전 과정을 살펴보는 것에서부터 시작한다. 그런 다음 이 기사에서는 NFS 아키텍처와 NFS의 발전 방향에 대해 살펴본다.

NFS의 간단한 이력

첫 번째 네트워크 파일 시스템(파일 액세스 리스너라고 함)은 DEC(Digital Equipment Corporation)에서 1976년에 개발했다. DAP(Data Access Protocol)의 구현과 함께 DECnet 프로토콜 제품군의 일부가 되었다. TCP/IP와 마찬가지로 DEC는 네트워크 프로토콜에 대한 프로토콜 스펙을 공개했다(DAP가 포함됨).

NFS는 IP 프로토콜을 통해 빌드된 최초의 현대적인 네트워크 파일 시스템이었다. NFS는 1980년대 초기 Sun Microsystems에서 내부적으로 개발한 실험적인 파일 시스템으로 시작했다. 그 접근 방식이 유행함에 따라 NFS 프로토콜은 RFC(Request for Comments) 스펙으로 문서화되고 NFSv2로 진화했다. 표준으로서 NFS는 다른 클라이언트 및 서버와의 상호 운용성으로 인해 급속하게 성장했다.

이러한 표준은 꾸준히 진화하여 RFC 1813에 의해 정의된 NFSv3로 발전했다. 이러한 프로토콜의 반복은 이전 버전보다 확장성이 훨씬 더 커서 2GB를 초과하는 대용량 파일 및 비동기 쓰기를 지원하고 TCP를 전송 프로토콜로 지원하여 광역 네트워크에 필요한 파일 시스템의 기반을 만들었다. 2000년에 RFC 3010(RFC 3530에 의해 개정됨)을 통해 NFS는 기업 환경에 적용되었다. Sun은 stateful 프로토콜과 함께 강력한 보안이 제공되는 NFSv4를 소개했다(이전 버전의 NFS는 stateless였음). 지금의 NFS는 RFC 5661에 의해 정의된 대로 버전 4.1이며 이 버전은 분산된 서버에서의 병렬 액세스에 대한 프로토콜 지원을 추가한다(pNFS 확장이라고 함).

동작에 대해 기술하는 특정 RFC를 포함한 NFS의 타임라인이 그림 1에 표시되어 있다.

놀랍게도 NFS는 거의 30년 동안 개발이 계속 진행되어 왔다. NFS는 확장 가능하고 성능이 뛰어나며 기업에도 적합한 품질을 가진 매우 안정적이고 이식 가능한 네트워크 파일 시스템을 나타낸다. 네트워크 속도가 증가하고 대기 시간이 줄어듬에 따라 NFS는 여전히 네트워크를 통한 파일 시스템 서비스의 매력적인 옵션이 될 것이다. 로컬 네트워크 설정에서도 가상화는 가상 시스템의 이동성을 높이기 위해 스토리지를 네트워크 쪽으로 이끌고 있다. 또한 NFS는 최신 컴퓨팅 모델을 지원하여 가상화된 인프라를 최적화한다.

위로

NFS 아키텍처

NFS는 클라이언트-서버 모델 컴퓨팅을 따른다(그림 2 참조). 서버는 클라이언트가 접속하는 공유 파일 시스템 및 스토리지를 구현한다. 클라이언트는 클라이언트의 로컬 파일 공간 내에 마운트된 공유 파일 시스템에 사용자 인터페이스를 구현한다.

Linux®에서 가상 파일 시스템(VFS)은 하나의 호스트에서 동시에 여러 파일 시스템을 지원하는 수단을 제공한다(예: Cd-ROM의 ISO(International Organization for Standardization) 9660 및 로컬 하드 디스크의 ext3fs). VFS는 요청이 의도한 스토리지를 판별한 후 요청을 충족하기 위해 사용해야 하는 파일 시스템을 판별한다. 이 때문에 NFS는 다른 파일 시스템과 마찬가지로 플러그 가능한 파일 시스템이다. NFS와의 유일한 차이점은 입/출력(I/O) 요청이 로컬로 충족되지 않을 수 있어 완료하려면 네트워크를 탐색해야 한다는 것이다.

요청이 NFS에 대한 것으로 판명되면 VFS는 요청을 커널 내의 NFS 인스턴스에 전달한다. NFS는 I/O 요청을 해석하여 NFS 프로시저로 변환한다(OPEN, ACCESS, CREATE, READ, CLOSE, REMOVE 등). 특정 NFS RFC에 문서화되어 있는 이러한 프로시저는 NFS 프로토콜 내에서의 동작을 지정한다. I/O 요청에서 프로시저가 선택되면 해당 프로시저는 원격 프로시저 호출(RPC) 계층에서 수행된다. 이름의 의미하듯이 RPC는 시스템 간 프로시저 호출을 수행하는 수단을 제공한다. RPC는 NFS 요청과 동반되는 인수를 함께 마샬링하고 이들을 해당 원격 피어에 전송하는 것을 관리한 후 응답을 관리 및 추적하여 적절한 요청자에게 응답을 제공한다.

또한 RPC는 데이터 유형의 경우 모든 NFS 참여자가 동일한 언어를 사용하게 하는 외부 데이터 표시(XDR)라는 중요한 상호 운용성 계층을 포함하고 있다. 지정된 아키텍처가 요청을 수행할 때 데이터 유형 표시가 요청을 충족하는 대상 호스트와 다를 수 있다. XDR은 모든 아키텍처가 파일 시스템을 상호 운용하고 공유할 수 있도록 공통 표시(XDR)로의 유형 변환을 처리한다. XDR은 float과 같은 유형의 비트 형식과 고정 및 가변 길이 배열과 같은 유형의 바이트 순서를 지정한다. XDR은 NFS에서의 사용으로 잘 알려져 있지만 일반적인 애플리케이션 설정에서 여러 아키텍처를 처리할 때마다 유용한 스펙이다.

XDR이 데이터를 공통 표시로 변환하고 나면 요청은 전송 계층 프로토콜이 제공된 네트워크를 통해 전송된다. 초기 NFS는 UDP(Universal Datagram Protocol)를 사용했지만 지금은 신뢰성 향상을 위해 TCP가 일반적으로 사용된다.

서버에서 NFS는 비슷한 방식으로 작동한다. 요청은 네트워크 스택에서 RPC/XDR(데이터 유형을 서버의 아키텍처로 변환)을 거쳐 NFS 서버로 이동한다. NFS 서버는 요청을 충족하는 역할을 수행한다. 요청은 요청에 필요한 대상 파일 시스템 트리를 식별하는 NFS 디먼까지 전달되며 로컬 스토리지의 해당 파일 시스템에 도달하기 위해 VFS가 다시 사용된다. 이 전체 프로세스가 그림 3에 표시되어 있다. 여기서 서버에 있는 로컬 파일 시스템은 일반적인 Linux 파일 시스템(예: ext4fs)이다. 이와 같이 NFS는 일반적인 의미의 파일 시스템이 아니라 파일 시스템에 원격으로 액세스하는 데 필요한 프로토콜이다.

대기 시간이 긴 네트워크의 경우 NFSv4는 복합 프로시저라는 항목을 구현한다. 이 프로시저는 네트워크를 통한 요청의 전송 비용을 최소화하기 위해 반드시 여러 RPC 호출이 단일 요청 내에 포함될 수 있도록 한다. 또한 이 프로시저는 응답에 대한 콜백 스키마를 구현한다.

위로

NFS 프로토콜

클라이언트의 관점에서 NFS에서 발생하는 첫 번째 조작을 마운트라고 부른다. 마운트는 로컬 파일 시스템 공간에 원격 파일 시스템을 마운트하는 것을 나타낸다. 이 프로세스는 mount에 대한 호출(Linux 시스템 호출)로 시작하며 이는 VFS를 통해 NFS 컴포넌트로 라우트된다. 원격 서버에 대한 get_port 요청 RPC 호출을 통해 마운트를 위한 포트 번호를 설정한 후 클라이언트는 RPC mount 요청을 수행한다. 이 요청은 mount 프로토콜을 담당하는 특수 디먼(rpc.mountd)과 클라이언트 사이에서 발생한다. 이 디먼은 현재 내보낸 파일 시스템의 서버 목록에 대해 클라이언트 요청을 검사한다. 요청된 파일 시스템이 존재하고 클라이언트에 액세스 권한이 있는 경우 RPC mount 응답은 파일 시스템에 대한 파일 핸들을 설정한다. 클라이언트측에서는 원격 마운트 정보를 로컬 마운트 지점과 함께 저장하고 I/O 요청을 수행하는 기능을 설정한다. 이 프로토콜은 잠재적인 보안 문제를 나타낸다. 따라서 NFSv4는 마운트 지점 관리를 위해 이 보조 mount 프로토콜을 내부 RPC 호출로 대체한다.

파일을 읽으려면 먼저 파일을 열어야 한다. RPC에는 OPEN 프로시저가 없다. 대신 클라이언트는 단순히 마운트된 파일 시스템에 디렉토리 및 파일이 존재하는지 확인한다. 클라이언트는 디렉토리에 대한 GETATTR RPC 요청으로 시작하며 이를 수행하면 디렉토리의 속성이 포함된 응답이 발생하거나 디렉토리가 존재하지 않는다는 내용이 표시된다. 다음으로 클라이언트는 LOOKUP RPC 요청을 발행하여 요청된 파일이 존재하는지 확인한다. 해당 파일이 존재하는 경우 파일의 속성을 리턴하는 요청된 파일에 대해 GETATTR RPC 요청이 발행된다. GETATTR 및 LOOKUP이 성공하면 클라이언트는 향후 요청을 위해 사용자에게 제공되는 파일 핸들을 작성한다.

원격 파일 시스템에서 식별된 파일을 사용하여 클라이언트는 READ RPC 요청을 발행할 수 있다. READ는 읽기를 위한 파일 핸들, 상태, 오프셋 및 개수로 구성된다. 클라이언트는 상태를 사용하여 조작이 수행될 수 있는지(파일이 잠겨 있는지) 여부를 판별한다. 오프셋은 읽기를 시작할 위치를 표시하고 개수는 읽을 바이트 수를 식별한다. 서버는 요청된 바이트 수를 리턴하거나 리턴하지 않을 수 있지만 READ RPC 응답 내에 데이터와 함께 리턴되는 바이트 수를 식별한다.

위로

NFS의 혁신

NFS의 마지막 두 버전(4와 4.1)은 NFS에 있어 가장 흥미롭고 중요한 버전이다. NFS의 발전에 있어 가장 중요한 측면 중 몇 가지에 대해 살펴보자.

NFSv4 이전에는 마운트, 잠금 및 파일 관리의 기타 요소를 위한 다수의 보조 프로토콜이 존재했다. NFSv4는 이 프로세스를 하나의 프로토콜로 단순화하고 전송 프로토콜로서 UDP에 대한 지원을 제거한다. 또한 NFSv4는 UNIX 및 Windows® 기반 파일 액세스 시맨틱에 대한 지원을 통합하여 다른 운영 체제로의 원시 통합을 위해 NFS를 확장한다.

NFSv4.1에서는 확장성과 성능 향상을 위해 병렬 NFS(pNFS)라는 개념을 도입했다. 확장성을 더 높이기 위해 NFSv4.1에서는 클러스터된 파일 시스템과 비슷한 방식으로 스트라이핑이 포함된 분할 데이터/메타 데이터 아키텍처를 구현한다. 그림 4와 같이 pNFS는 환경을 세 가지 부분(클라이언트, 서버 및 스토리지)으로 나눈다. 두 가지 경로가 존재하는 것을 알 수 있다. 하나는 데이터를 위한 것이고 다른 하나는 제어를 위한 것이다. pNFS는 데이터의 레이아웃을 데이터 자체로부터 분리하여 이중 경로 아키텍처를 허용한다. 클라이언트가 파일에 액세스를 원하는 경우 서버는 레이아웃을 사용하여 응답한다. 레이아웃은 스토리지 디바이스에 대한 파일의 맵핑을 보여 준다. 클라이언트에게 레이아웃이 있는 경우 클라이언트는 서버를 통해 작업할 필요 없이 스토리지에 직접 액세스할 수 있다(확장성 및 성능이 향상됨). 클라이언트가 파일에 대한 작업을 완료하면 데이터(변경사항) 및 레이아웃을 커미트한다. 필요한 경우 서버는 클라이언트로부터 다시 레이아웃을 요청할 수 있다.

pNFS는 다수의 새로운 프로토콜 조작을 구현하여 이 동작을 지원한다. LayoutGet과 LayoutReturn은 각각 서버로부터 레이아웃을 가져오고 릴리스하지만 LayoutCommit는 클라이언트의 데이터를 스토리지에 대해 커미트하므로 다른 사용자가 해당 데이터를 사용할 수 있다. 서버는 LayoutRecall을 사용하여 클라이언트로부터 레이아웃을 재호출한다. 레이아웃은 병렬 액세스 및 성능 향상을 위해 일정 수의 스토리지 디바이스에 퍼져 있다.

데이터와 메타 데이터는 모두 스토리지 영역에 저장된다. 클라이언트는 레이아웃의 직접 I/O 제공 수신을 수행할 수 있으며 NFSv4.1 서버는 메타 데이터 관리 및 저장을 처리한다. 이 동작이 새로운 것은 아니지만 pNFS는 저장을 위한 복수의 액세스 메소드를 지원하는 기능을 추가한다. 현재 pNFS는 블록 기반 프로토콜(Fibre Channel), 오브젝트 기반 프로토콜 및 NFS 자체(pNFS 형식이 아닌 경우에도)의 사용을 지원한다.

NFS에 대한 작업이 계속 진행되고 있으며 2010년 9월에 NFSv2에 대한 요구사항이 공개되었다. 새로운 발전사항 중 일부는 가상화 환경에서의 스토리지 변화에 대처한다. 예를 들어, 데이터의 중복은 하이퍼바이저 환경(다수의 운영 체제가 동일한 데이터를 읽고 쓰고 캐싱함)에서 자주 발생할 수 있다. 이 때문에 스토리지 시스템이 전반적으로 중복이 발생하는 위치를 이해하는 것이 바람직하다. 이를 통해 클라이언트의 캐시 공간과 스토리지의 용량이 유지된다. NFSv4.2는 이 문제점을 처리하기 위해 공유 블록의 블록 맵을 제안한다. 스토리지 시스템이 백엔드에서 처리 기능을 통합하기 시작했기 때문에 스토리지 백엔드 자체에서 효율적으로 수행될 수 있을 때 데이터 사본의 내부 스토리지 네트워크를 오프로드하기 위해 서버측 사본이 도입되었다. 잠재적으로 mapadvise를 경로로 사용하는 I/O에 대한 클라이언트측 힌트와 플래시 메모리에 대한 서브 파일 캐싱을 포함한 기타 혁신사항도 나타나고 있다.

위로

NFS의 대안

NFS는 UNIX 및 Linux 시스템에서 가장 유명한 네트워크 파일 시스템 시스템이지만 확실히 유일한 선택사항은 아니다. Windows® 시스템에서는 SMB(Server Message Block)(CIFS로도 알려져 있음)가 가장 광범위하게 사용되는 옵션이다(Linux가 SMB를 지원하는 것처럼 Windows도 NFS를 지원함).

Linux에서도 지원되는 최신 분산 파일 시스템 중 하나는 Ceph이다. Ceph는 처음부터 POSIX(Portable Operating System Interface for UNIX)와 호환 가능한 결함 허용 분산 파일 시스템으로 설계되었다. 참고자료에서 Ceph에 대해 자세히 살펴볼 수 있다.

다른 예로는 Carnegie Mellon과 IBM에서 제공되는 Andrew 분산 파일 시스템의 오픈 소스 버전인 OpenAFS, 확장 가능한 스토리지를 위해 범용 분산 파일 시스템에 초점을 두는 GlusterFS, 클러스터 컴퓨팅에 초점을 두는 대량 병렬 분산 파일 시스템인 Lustre가 있다. 모두 분산 스토리지를 위한 오픈 소스 소프트웨어 솔루션이다.

위로

추가 정보

NFS는 계속 발전하고 있으며 Linux의 발전과 비슷하게(로우 엔드, 임베디드 및 하이 엔드 성능 지원) NFS는 이용자 및 엔터프라이즈를 위한 확장 가능한 스토리지 솔루션을 구현한다. NFS 앞에 무엇이 있는지 알아보는 것도 흥미롭지만 NFS의 이력과 단기적인 시각으로 볼 때 NFS는 우리가 파일 스토리지를 보고 사용하는 방식을 변경할 것이다.

참고자료

교육

• NFS는 이식 가능하고 멀티 플랫폼인 네트워크 파일 시스템에 대한 표준 스펙이다. NFS는 첫 번째 표준 스펙 NFSv2, NFSv3, NFSv4 및 마지막 NFSv4.1을 포함하여 다수의 스펙에 문서화되어 있다. NFSv4.2 요구사항 문서에서 NFS의 미래에 대해 자세히 살펴볼 수도 있다.
  
  
• Yet Another NFS(YANFS)는 Sun 프로젝트이며 이전에는 WebNFS로 불렸다. YANFS는 Java 애플리케이션으로부터 NFS 액세스를 허용하는 NFSv3 및 RPC/XDR의 Java™ 구현이다.
  
  
• XDR은 여러 아키텍처의 호스트가 공통 데이터 유형을 사용하여 네트워크를 통해 통신할 수 있도록 하는 데이터의 표준화된 인코딩이다.
  
  
• Linux는 다수의 스토리지 매체에서 다양한 파일 시스템을 지원한다. Linux는 다수의 파일 시스템, 다양한 스토리지 하드웨어 유형에 대한 드라이버 및 VFS의 통합을 통해 이를 가능하게 만든다. "리눅스 파일 시스템 분석"(developerWorks, 2007년 10월)에서 VFS에 대해 자세히 살펴볼 수 있다.
  
  
• NFS는 네트워크 스토리지 시스템을 빌드하는 유일한 방법은 확실히 아니다. 다른 예로는 OpenAFS, GlusterFS, Lustre 및 Ceph가 있다. "Ceph: 페타바이트 규모의 Linux 분산 파일 시스템"(developerWorks, 2010년 5월)에서 Ceph에 대해 자세히 살펴볼 수 있다.
  
  
• Linux에서는 수백 개의 기술자료 목록과 함께, Linux 개발자와 관리자를 위한 다양한 다운로드, 토론 포럼 및 다른 참고자료를 찾을 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트를 통해 다양한 IBM 제품 및 IT 산업 주제에 대한 최신 정보를 얻을 수 있다.
  
  
• 무료 developerWorks Live! briefing을 통해 최신 IBM 제품 및 도구에 대한 정보뿐만 아니라 IT 업계의 최신 경향까지도 빠르게 확인할 수 있다.
  
  
• developerWorks on-demand demos에서는 입문자를 위한 제품 설치 및 설정부터 숙련된 개발자를 위한 고급 기능까지 망라된 다양한 데모를 제공한다.
  
  
• Twitter의 developerWorks를 팔로우(follow)하거나 developerWorks에 대한 Linux 트윗(tweet)의 피드를 구독하자.
  
  

제품 및 기술 얻기

• 자신에게 가장한 적합한 방법으로 IBM 제품을 평가해 보자. 시험판 제품을 다운로드하거나, 온라인으로 제품을 사용해 보거나, 클라우드 환경에서 제품을 사용하거나, SOA Sandbox에서 SOA(Service Oriented Architecture)를 효과적으로 구현하는 방법을 배울 수 있다.
  
  

토론

• developerWorks community에 참여한다. 개발자가 운영하고 있는 블로그, 포럼, 그룹 및 위키를 살펴보면서 다른 developerWorks 사용자와 의견을 나눌 수 있다.
  
  

필자소개

아티클 순위

의견

위로

목차

• NFS의 간단한 이력
• NFS 아키텍처
• NFS 프로토콜
• NFS의 혁신
• NFS의 대안
• 추가 정보
• 참고자료
• 필자소개
• 의견