:: 전산쟁이의 카피질

출처 : http://sharkynara.egloos.com/1471693

방문객은 아래글을 참고하지 마시고 출처의 원문을 참고하시기 바랍니다.

Abstract:: 지역 네트웍이 보급됨에 따라 분산된 환경에서 파일을 공유해야할 필요성이 날로 커지고 있다. 그러나 모든 컴퓨터가 동일 기종에 동일 운영체제가 아닌 다음에야 플랫포옴의 차이로 인한 파일 공유의 문제점이 사라질 수 없다. 더구나 최근에는 지역 네트웍을 넘어선 인터넷 상에서의 파일 공유 문제까지 논의되는 상황이므로 분산 파일 시스템에 대한 관심은 그 어느 때보다 높아지고 있다. 이 글에서는 파일 공유의 역사를 시작으로 Samba, NFS를 이용한 지역 네트웍에서의 파일 공유 방안 및 WebNFS, CIFS, AFS등으로 대표되는 인터넷에서의 파일 공유 표준화 동향에 대해 살펴본다. 이러한 현존하는 최신 기술의 소개를 통해 지역 네트웍이나 인터넷에서의 파일 공유 전략에 대한 새로운 시각을 가질 수 있을 것이다.
Keywords:: 파일 공유, 인터넷, Samba, SMB protocol, CIFS, Dfs, NFS, AFS, WebNFS, UNIX, Windows 95/NT (1)

1. 서론

80년대 초반 컴퓨터들이 네트웍으로 연결되어 있지 않았던 시절, 카세트 테이프나 플로피 디스켓을 가지고 다니면서 필요한 파일을 주고 받으면서 공동 작업을 하던 때가 있었다. 그 당시 하드웨어 및 소프트웨어의 빈약함으로 인해 상이한 기종 사이의 파일 변환은 둘째치고서라도 동일 기종 사이에서의 파일 전송시에도 여러 불편한 문제점을 참고 견뎌야 했다. 하지만 세월이 바뀌어 90년대 중반도 이미 넘어간 현재 "네트웍이 바로 컴퓨터이다.^등록상표" (2) 라는 표어를 유행시키면서 본격적으로 확산된 네트웍의 열기는 인터넷의 대중화와 더불어 자료의 검색, 전달, 저장 방법에 있어 획기적인 전환점을 가져왔다.

하지만 단순히 네트웍으로 컴퓨터들이 상호 연결되었다고 자료 공유가 저절로 이루어지는 것은 아니다. 주제와 관련없는 다른 분야를 잠시 접어두고, 자료 공유에 있어 핵심이 되는 파일 시스템과 관련해서 고려할 사항을 기술하면 다음과 같다:

운영체제 종류
- 지역 파일 시스템의 차이: DOS (FAT -- File Allocation Table), WIndows 95 (확장 FAT), Windows NT (NTFS -- NT File System), OS/2 (HPFS -- High Performance File System), UNIX (UFS -- UNIX File System)
- 네트웍 파일 시스템의 차이: PC (SMB -- Server Message Block, Netware, CIFS -- Common Internet File System), UNIX (NFS -- Network File System, AFS -- Andrew File System, WebNFS)
- 네트웍 프로토콜의 차이: UNIX (TCP/IP), PC (NetBEUI -- NetBIOS Extended User Interface, IPX/SPX -- Internetwork Packet Exchange/Sequenced Packet Exchange)
네트웍 파일 서버의 이름 결정 (name resolution): UNIX (DNS -- Domain Name Service, DHCP -- Dynamic Host Configuration Protocol, LDAP -- Lightweight Directory Access Protocol), PC (WINS -- Windows Internet Naming Service, NDS -- Novell Directory Services)
네트웍 파일 시스템의 기능: 결함 포용 (fault tolerance), 복제 (replication), 클러스터링 (clustering), 보안 (security)

어렵게 네트웍을 구축하고 나서도 여러 서버에 분산된 파일을 공유하기가 쉽지않은 이유는 바로 관리자 및 사용자가 이상에서 설명된 파일 시스템을 운영하는 환경에 따라 달라지는 각종 차이점을 인식하고 이를 충분히 고려할 수 있어야 하기 때문이다. 따라서, 이 글에서는 이러한 난처한 상황을 극복하는데 약간이라도 도움을 주기 위해 주로 UNIX와 PC를 대상으로 네트웍 환경에서 파일을 공유하는 각종 기법을 소개하기로 한다. 본격적으로 내용을 전개하기 전에 먼저 파일 공유의 역사를 살펴보도록 한다.

2. 파일 공유의 역사

보조 기억장치가 존재하는 한, 파일도 역시 그 생명을 꾸준히 유지해나갈 것이다. 초창기 대부분의 운영체제는 파일 시스템을 기반으로 나머지 부가적인 기능을 추가한 듯한 인상이 짙다 (3). 하지만 운영체제가 차츰 복잡해지고, 네트웍 기능이 기본적으로 탑재되기 시작하면서 점차로 복잡한 파일 시스템이 등장하며, 네트웍 분산 환경에서의 파일 공유 기능을 갖게 된다.

2.1 단순 파일 복사

컴퓨터에 아무런 통신 장비 (모뎀, 네트웍)가 갖추어져 있지 않을 경우에는 플로피 디스크나 이동 가능한 하드디스크에 파일을 복사하여 공유하는 방법을 예전부터 계속 써왔다. 윈도즈 95에도 서류 가방이라는 특수한 폴더를 이용하여 이동가능한 매체에 담긴 파일을 동기화시키는 방법을 제공하고 있을 정도니까, 이 기법이 어느 정도로 대중화된 방법이라는 사실은 굳이 여기서 강조할 필요가 없다.

모뎀을 이용하여 전화선을 이용한 통신이 가능해지면서 야간 전화 요금이 절약되는 시점을 이용해 uucp (unix to unix copy)를 통해 파일을 주고 받으며 USENET의 뉴스를 여러 분산된 서버에 피딩 (feeding)하기 시작했다. PC를 사용하는 사람들은 BBS (Bulletin Board System)에서 kermit과 zmodem을 사용하여 파일을 주고받는 일에 익숙해졌으며, 직렬 포트를 통한 파일 전송 프로그램이 유행하기 시작했다.

그러나 이러한 방법들은 어디까지나 단순 파일 복사의 의미 이상을 부여하기 힘들다. 실시간으로 파일의 수정된 상황을 그대로 반영하고, 여러 명이 동시에 파일에 접근하기 위해서는 이후 설명할 네트웍 환경의 구축이 필수적인 요소로 부각되게 된다.

2.2 소규모 (지역) 네트웍에서의 파일 공유

단순 파일 복사는 개인이 사용하기는 적합할지 몰라도 연구실이나 사무실의 복잡한 업무를 지원하기에는 부족한 점이 많았다. 이를 극복하기 위해 (당시로서는 가격이 비싼 편이었던) 디스크, 프린트를 위시한 각종 자원의 공유 목적으로 소규모의 지역적 네트웍이 구축되기 시작하였다. Novell에서는 Netware로 유명해진 IPX/SPX 프로토콜을 정의했으며, IBM에서 NetBEUI 프로토콜을 정의하여, 마이크로소프트와 함께 SMB (Server Message Block) 프로토콜을 따르는 LAN Manager를 자사의 운영체제에 포함시켰다. 또한 매킨토시로 유명한 애플사는 근거리 네트웍 프로토콜인 AppleTalk를 정의하여 파일 공유뿐만 아니라 값비싼 포스트스크립트 엔진을 장착한 네트웍 프린터를 여러 사용자가 공유할 수 있도록 하였다. 여러 회사들의 이러한 활발한 움직임은 NOS (Network Operating System)이라는 신조어를 낳기에 이른다.

UNIX의 경우 이더넷을 기반으로 하는 TCP/IP 프로토콜의 성공적인 표준화의 결과로 PC의 경우와는 달리 네트웍 관련 프로토콜의 난립을 초기부터 막을 수 있었다. 이와 더불어 공학용 워크스테이션으로 유명한 선 마이크로시스템사에서 UNIX에서 파일 및 각종 시스템 관련 데이터베이스를 공유할 수 있는 기술인 NFS (Network File System) 및 NIS (Network Information Service) (4)를 개발하여, 여러 워크스테이션을 한데 묶어 관리하고 자원을 공유할 수 있도록 하였다. 처음에는 이 기술을 선사의 워크스테이션에서만 사용할 수 있었으나 이후 여러 업체에서 라이선스 계약을 체결하여 UNIX를 사용하는 거의 모든 워크스테이션간의 연동이 가능해짐으로서, 현재는 NFS가 명실상부한 업계 표준규격 (de facto standard) 및 표준화단체 표준규격 (de jure standard)으로 자리잡게 되었다.

네트웍 구축이 일반화됨에 따라 PC, 워크스테이션, 매킨토시가 동일 네트웍에 물려있는 사이트가 늘어났으며, 이러한 결과로 다양한 종류의 하드웨어에 설치된 상이한 운영체제 사이의 파일 공유 문제가 대두되게 되었다. 비교적 보급율이 낮은 매킨토시를 제외하고서라도, WfW (Workgroup for Windows)/95/NT를 쓰는 PC와 UNIX 운영체제에서 파일을 공유하기 위해서는 PC 쪽에 별도의 NFS 클라이언트를 설치하거나, UNIX 쪽에 SMB 프로토콜을 지원하는 LAN Manager 흉내내기 프로그램인 Samba를 설치하는 방법을 택해야 한다. 하지만 비교적 최근까지도 이러한 방법이 잘 알려져 있지 않았기 때문에, 기종과 운영체제에 따라 사용할 수 있는 파일 시스템을 별도로 분리시켜 작업 환경에 따라 여기저기 번거롭게 옮겨다녀야 하는 불편함을 호소하는 사용자 계층이 의외로 많았다 (5).

2.3 대규모 (인터넷) 네트웍에서의 파일 공유

이상에서 설명한 소규모 지역 네트웍에서 운영하는 기술을 확장하여 (scale up), 대규모 네트웍에서 파일을 공유할 수는 있다. 그러나 소규모 네트웍에서 사용되던 기술에는 한계가 있으므로 본격적인 인터넷 상에서의 파일 공유를 위해서는 보다 발전된 기술이 요구된다.

PC 진영에서는 마이크로소프트 사를 중심으로 여러 UNIX 업체들이 모여 SMB 규약을 완전히 공개하는 동시에 LAN Manager가 가진 제약을 극복하여 인터넷에서 사용가능한 표준 파일 시스템인 CIFS (Common Internet File System)를 IETF (Internet Engineering Task Force) 팀에 드래프트 형식으로 제안해둔 상황이다. 그리고 1998년 발매될 NT 5.0부터는 CIFS 위에서 여러 개의 물리적 디스크를 하나의 논리적 디스크로 취급할 수 있는 분산 파일 시스템 (Dfs -- Distributed File System)을 표준으로 장착한다고 발표하였으며, 직후 NT 4.0 커널에 탑재할 수 있는 Dfs 플러그 인 베타버전을 공개하였다.

선 마이크로 시스템사의 NFS 초기 버전은 지역 네트웍에 연결된 시스템의 부하를 최소화시키기 위해 연결지향성이 아닌 (connectionless) 프로토콜인 UDP (User Datagram Protocol)를 사용하였다. 하지만 UDP를 이용한 응용 프로그램은 대규모 네트웍에서 심각한 효율 저하를 불러일으킨다. 따라서 선과 디지털 사 (Digital Equipment Corporation)의 공학자들은 공동으로 NFS의 효율을 올리는 방법을 고안하여 TCP (Transmission Control Protocol)를 사용하는 향상된 NFS3 버전을 공표하기에 이른다. NFS3를 이용하게 되면 어느 정도 규모 이상의 네트웍에서도 파일 공유가 가능해진다.

최근 기업의 컴퓨터 관리 비용을 줄이기 위해 디스크가 없는 NC (Network Computer)가 확산됨에 따라 WWW 상에서 파일을 주고받아야할 경우가 많아졌다. 현재까지는 WWW 표준 전송 프로토콜인 HTTP 또는 인터넷 표준 프로토골인 FTP를 사용하고 있으나, 능률이 떨어지고 네트웍 파일 공유와는 달리 실시간으로 자료를 갱신할 수 없는 문제점이 지적되고 있다. 이러한 문제점을 해결하기 위해, 선 마이크로 시스템사에서는 앞서 소개한 NFS3 기술을 기반으로 하는 새로운 WWW 표준 파일 전송 규약인 WebNFS를 제안하여, IETF에서 NFS URL 표준안을 RFC {2054, 2055}로 확정한 상황이다.

다른 한편으로 카네기 멜론 대학교 (Carnegie-Mellon University)에서 교육 환경 구축을 목표로 시작한 AFS (Andrew File System) 프로젝트를 IBM의 자회사인 Transarc에서 상용화시켰다. AFS는 기존에 소개한 파일 공유 시스템과는 달리 전세계에 흩어진 파일 시스템을 하나의 유일한 계층 구조로 표현할 수 있도록 하는 확장 가능한 유연한 기능을 제공한다. UNIX 운영체제를 탑재한 워크스테이션 사용자는 운영체제에 내재된 AFS 커널을 사용하여 (외견상 일반 UFS와 다를 바 없는) 파일 시스템을 그대로 사용하고, PC 쪽 사용자는 AFS 파일 서버에 설치된 Samba를 이용하여 AFS 파일 시스템에 접근할 수 있으므로, 운영체제에 따른 파일 공유 문제를 해결할 수 있다.

3. 지역 네트웍에서의 파일 공유 방안

앞서 파일 시스템의 역사를 다루면서 지역 네트웍에서 파일을 공유하는 전략을 간단히 소개한 바와 같이, 상이한 운영체제 사이에서 파일 공유를 위해서는 운영체제에서 지원하는 네트웍 파일 공유 프로토콜을 특정한 하나로 일치시켜야 한다. 지역 네트웍 환경을 구축할때 싼 맛에 NT를 서버의 운영체제로 사용하는 경우가 점차로 늘어나는 추세이지만 아직도 UNIX를 서버의 운영체제로 쓰면서 클라이언트로 Windows를 사용하는 경우가 많으므로, UNIX와 Windows 사이의 파일 공유는 온 세상이 NT로 뒤덮이기 전까지 계속해서 골치거리로 남아있을 것이다.

이어지는 글에서는 상이한 운영체제 사이에서 윈도즈 진영의 프로토콜인 SMB를 이용하여 파일을 공유하는 방법과 UNIX 진영의 프로토콜인 NFS를 이용하여 파일을 공유하는 방법을 차례로 살펴본다. 글의 성격상 세부적인 설치방법이나 관리방법을 되도록이면 과감히 건너뛰고, 각 기술에 대한 핵심 아이디어와 특질을 상위단계에서 조감하도록 한다 (6).

3.1 Samba

현재까지 나온 Samba 메뉴얼들은 Samba의 설치법과 Samba 패키지에 포함된 유틸리티들의 사용법에 치중하는 면이 적지 않다. 본문에서는 이러한 기존의 서술 방법에서 탈피하여 Samba 패키지 소개 이외에 SMB 프로토콜 (이후 CIFS 까지도 포괄하여)까지도 함께 다루도록 한다.

3.1.1 Samba란?

Samba는 표준 TCP/IP를 장착한 UNIX 기계에서 동작하는, SMB 프로토콜을 흉내내는 서버 소프트웨어이다. 그러므로, SMB를 지원하는 클라이언트는 Samba를 구동시키는 서버 쪽의 파일 시스템과 프린터등의 각종 자원에 쉽게 접근할 수 있다. 다른 네트웍 파일 공유 소프트웨어에 비해 Samba의 명성이 높은데는 다 이유가 있다. 호주에서 개발된 Samba는 현재 GPL (GNU General Public License)에 의거하여 원시코드까지 무료로 보급되고 있다. 이런 정책으로 인해 회사 입장에서는 기술지원을 제대로 받을 수 없다는 단점이 있지만, 그 반면에 연구소나 대학 입장에서는 누구나 가져와서 사용할 수 있다는 쉽게 뿌리칠 수 없는 장점이 존재한다. 국내에서도 이러한 기술적인 조류를 쫓아 윈도즈 95등을 탑재한 PC와 UNIX 서버가 혼재한 환경에서 상당수 Samba를 운영하는 것으로 알려져있다.

1997년 현재 나온 1.9.16p11 버전은 거의 대부분의 UNIX 플랫포옴 및 VMS 운영체제를 지원하고 있다. 여기서 대표적인 것들만 소개하면 다음과 같다 (Samba의 버전이 올라가면서 지원 운영체제의 범위가 다소간 변경될 수 있음을 밝혀둔다.):

SunOS, Linux, Solaris, SVR4, Ultrix, Digital UNIX aka OSF1 (alpha only), AIX, BSDI, NetBSD, Sequent, HP-UX, IRIX, FreeBSD, NeXT, ISC SVR3V4, A/UX, SCO UNIX, intergraph, DGUX, Apollo Domain/OS (BSD 4.3) [Blackman 97]

Samba를 단순히 UNIX 서버 쪽의 파일 시스템에 접근하는데만 사용할 수도 있다. 그러나 잘만 활용한다면 의외로 세련된 응용 방법이 존재하는데, [Park 96]에서 발췌한 내용을 간략하게 소개하면 다음과 같다:

PC 클라이언트에서 UNIX 파일 시스템 사용
PC 클라이언트에서 UNIX 네트웍 프린터 사용
UNIX 서버에서 PC 쪽의 파일 시스템 사용
UNIX 서버에서 PC 쪽의 네트웍 프린터 사용
PC 클라이언트에 속한 파일을 UNIX 서버에 달린 테이프 장치에 백업

마지막 두가지 응용 방법은 의외로 그 활용성이 매우 높으므로, 눈여겨 볼만하다.

3.1.2 SMB란?

SMB는 Sever Message Block의 약어로 윈텔 (Microsoft/Intel) 진영에서 1987년부터 꾸준히 밀어붙이고 있는, 삼바의 핵심이 되는 프로토콜이다. SMB는 이미 IETF에 의해 CIFS라는 이름으로 표준화 직전까지 온 상황이다 [CIFS White Paper].

SMB는 전형적인 클라이언트/서버, 요청/응답 프로토콜 구조를 지니며, 파일 시스템 뿐이 아니라, 프린터, 직렬 포트, named pipes, mailslots 등의 각종 자원을 공유할 수 있도록 한다. 바로 이러한 SMB의 특성 때문에 Samba를 이용한 파일 시스템 공유 이외의 여러 응용 방법이 존재가능한 셈이다. 또 다른 SMB의 특징은 바로 이종의 네트웍 프로토콜 위에서 동작한다는 점이다. [그림 1]을 살펴보면 알 수 있듯이, SMB는 TCP/IP, NetBEUI, IPX/SPX등의 상이한 다중 네트웍 위에서 원활하게 동작할 수 있다. 그러나, 만일 SMB가 TCP/IP나 NetBEUI 프로토콜 위에서 동작하려면 반드시 NetBIOS 이름 서어비스를 사용해야 한다 (7).

그림 1: SMB를 포함하는 네트웍 프로토콜 다이어그램 [Sharpe 96]

첫번째로 개선된 SMB의 후손인 Core Protocol은 다음의 기본적인 서어비스 목록을 정의하고 있다 [Sharpe 96]:

파일과 프린터 공유의 연결 및 해제
파일의 열고 닫음
프린터 파일의 열고 닫음
파일을 읽고 씀
파일과 디렉토리를 생성하고 삭제함
디렉토리 검색
파일 속성 설정 및 검사
바이트 단위의 파일 잠금 및 해제

Core Protocol 이후, 하드웨어 및 소프트웨어가 발전함에 따라 요구되는 다양한 서어비스의 제공을 위해 SMB 프로토콜도 확장되어 나가기 시작하였다. [표 1]은 SMB 프로토콜 지원 응용과 이를 수용하는 프로토콜 이름을 순서대로 나열하고 있다.

SMB Protocol Variant	Protocol Name	Comments
PC NETWORK PROGRAM 1.0	Core Protocol	Some versions were called PCLAN1.0
MICROSOFT NETWORKS 1.03	Core Plus Protocol	Included Lock&Read and Write&Unlock SMBs with different versions of raw read and raw write SMBs
MICROSOFT NETWORKS 3.0	DOS LAN Manager 1.0	The same as LANMAN1.0, but OS/2 errors must be translated to DOS errors.
LANMAN1.0	LAN Manager 1.0	The full LANMAN1.0 protocol.
DOS LM1.2X002	LAN Manager 2.0	The same as LM1.2X002, but errors must be translated to DOS errors.
LM1.2X002	LAN Manager 2.0	The full LANMAN2.0 protocol.
DOS LANMAN2.1	LAN Manager 2.1	The same as LANMAN2.1, but errors must be translated to DOS errors.
LANMAN2.1	LAN Manager 2.1	The full LANMAN2.1 protocol.
Windows for Workgroups 3.1a	LAN Manager 2.1?	Windows for Workgroups 1.0?
NT LM 0.12	NT LAN Manager 1.0?	Contains special SMBs for NT
Samba	NT LAN Manager 1.0?	Samba's version of NT LM 0.12?
CIFS 1.0	NT LAN Manager 1.0	Really NT LM 0.12 plus a bit?

표 1: SMB 프로토콜의 변천사 [Sharpe 96]

Microsoft사의 영향력이 커짐에 따라 SMB는 광범위하게 그 지지 세력을 확보하게 되었다. SMB를 지원하는 익히 잘 알려진 서버의 목록을 소개하면 다음과 같다:

Samba (클라이언트 포함), Microsoft Windows for Workgroup 3.x (클라이언트 포함), Microsoft Windows 95 (클라이언트 포함), Microsoft Windows NT (클라이언트 포함), LAN Server for OS/2, LAN Manager for OS/2, SCO (클라이언트 포함), Digital PATHWORKS (클라이언트 포함)

참고로 Linux는 다른 UNIX 시스템과는 달리 smbfs라는 SMB 지원 파일 시스템 타입을 기본으로 제공하고 있다.

3.1.3 Samba의 보안 문제

Samba의 보안 문제는 여러 번에 걸쳐 많은 사용자들을 긴장의 도가니로 몰아넣은 전력이 있다. 최근에 벌어진 Windows 95/NT 암호 유출 사건을 제외하고라도, 보안에 있어서 거의 철옹성을 자랑하는 AFS 조차 Samba를 이용한 서어비스 제공시 IP 도용과 같은 공격에 취약한 것으로 판명된 사실을 염두에 둘 때 중요한 정보를 다루는 민감한 사이트에서는 Samba 사용을 재고해 보아야 할 것이다. 외부 공격자 입장에서는 네트웍 파일 공유를 위해 설치한 Samba가 바로 주요 공격 목표인 아킬레스 건이 되는 셈이다.

SMB에는 크게 두가지 보안 레벨이 존재한다. 각 레벨이 가지는 특성은 다음과 같다:

공유 레벨: WfW 및 Windows 95와 같이 공유 자원 단위로 암호를 설정하여, 한번만 공유 자원에 대한 접근 허가만 얻으면 이후 공유 자원에 속한 모든 파일에 접근 가능하도록 하는 정책이다. 따지고 보면 이렇게 간단한 공유 레벨 정책으로 인해 각종 보안에 관련된 문제가 여기저기서 터져나오는 것이다.
사용자 레벨: 공유 레벨과는 달리 사용자의 접근 권한에 따라 공유 자원의 파일 단위로 보안을 유지하는 정책이다. 각 사용자는 반드시 서버에 로그인하여 서버로부터의 인증을 받아야 한다. 공유 자원을 사용하기 위해서는 항상 서버로부터 인증을 받아 파일 접근에 필요한 UID를 얻어낸 다음, 이를 통해 서버에 접근해야 하므로 공유 레벨보다는 높은 수준의 보안 요소를 제공한다고 볼 수 있다.

Samba의 환경 설정을 잘못할 경우 중요한 공유 자원까지 외부에 유출시킬 가능성이 있으므로, 시스템 관리자는 메뉴얼 페이지를 충실히 읽고나서 Samba 환경 파일을 작성해야 한다. 지금 당장 "host allow"등의 설정만 제대로 하더라도 상당수의 외부 공격을 막아낼 수 있다 (8).

3.2 NFS (Network File System)

유닉스를 사용하는 사용자라면 NFS라는 이름을 적어도 한번 정도는 들어보았을 것이다. NFS는 이렇게 대중에게 널리 알려져있는 기술이지만, 의외로 그 실체에 대해서는 간과되고 있는 면도 사실이다. 따라서 아래에서는 NFS의 핵심 사항을 설명하여 이해를 돕도록 한다.

3.2.1 NFS란?

NFS는 Network File System의 약자로서 1985년 Sun Microsystems 사에서 개발된 네트웍을 통한 분산 파일 시스템이다. Samba가 무료 개방 정책을 이용해서 널리 보급된 상황과 정반대로 NFS는 300 개가 넘은 회사에서 라이선스 계약을 체결함으로 인해 저절로 업계 표준 규약으로 자리잡은 사실이 특이하다. 최근에는 문서화된 NFS 규약이 공개됨에 따라 IETF, X/Open 표준화 단체의 표준 규약으로도 통용되고 있으며, 이러한 개방 정책에 발맞추어 이미 몇몇 공짜 유닉스에는 NFS를 기본으로 탑재하고 있는 상황이다.

NFS는 버전 2부터 여러 플랫포옴에 본격적으로 구현되기 시작하여 (아쉽게도 버전 1은 빛을 보지 못했다.), 최근에는 버전 3이 Digital과 SunSoft에 의해 본격적으로 출시되고 있다.

NFS를 지원하는 대표적인 운영체제를 소개하면 다음과 같다:

A/UX, BSDI, Ultrix, VMS, Digital UNIX, HP/UX, MVS, AIX, Netware, SCO UNIX, Unixware, SunOS, Solaris, IRIX, DOS, WIndows, WIndows 95, WIndows NT, SVR4

Samba와는 달리 NFS의 기능은 파일 시스템의 공유에 국한되어 있다. 그러나 NFS는 Samba에 비해 클라이언트나 서버의 운영에 있어 보다 유연한 특질을 제공하며, NIS와 연동하여 사용할 경우 시스템 관리의 편의성을 극대화시킬 수 있다.

3.2.2 NFS 프로토콜

NFS는 클라이언트/서버 구조를 가지고 있으며, UDP 프로토콜을 이용한 전형적인 stateless (9) 파일 시스템이다. NFS 프로토콜은 UDP를 이용하기 때문에 시스템의 부하를 줄일 수 있으며, stateless 성질을 가지고 있으므로 파일 전송시에 발생할지도 모르는 자료의 손실을 최소화시키는 특성이 있다.

NFS 서버의 직능은 다른 클라이언트로 하여금 네트웍을 통하여 디스크 자원을 공유하도록 하는 것이다. 서버가 파일 시스템을 외부에 공개하는 것을 export라고 하며, 이렇게 공개된 파일 시스템을 export 된 파일 시스템이라는 용어로 표현한다. 시스템 관리자가 파일 시스템을 공개하기 위해서는

공개할 파일의 절대 경로
공개를 허용하는 워크스테이션의 지정
공개할 파일의 접근 허가

를 정확하게 설정하여야 한다. NFS에서는 Samba와는 달리 공개를 허용하는 워크스테이션을 개별 적으로 지정하거나 한번에 그룹으로 묶어 지정할 수 있다.

NFS 클라이언트의 직능은 서버 측에서 공개한 export 된 파일 시스템을 마운트하여 서버 쪽의 파일에 접근 가능하도록 만드는 것이다. [그림 2]는 server1의 /export/home/sallyb exported 파일 시스템을 클라이언트 쪽의 파일 시스템에 위치할 지점 -- 마운트 포인트 --인 /home/sallyb 에 마운트시킨 것을 나타낸다. 예제에서 본 것과 같이, 반드시 별도의 네트웍 드라이브 (D:, E;, F:, 등)를 마운트 포인트로 삼아야 하는 Samba와는 달리, NFS에서는 클라이언트 쪽에서 임의의 마운트 포인트를 지정한 다음 이 경로를 이용하여 원거리 파일 시스템을 투명하게 (transparent) 사용할 수 있다. 다시 말해서, (비록 수작업이 요구되지만) NFS 클라이언트 기계들의 마운트 포인트를 적절히 잘 잡아두면, 최종 사용자 입장에서 서로 다른 기계에 로그인해서 작업을 할 경우라도 동일한 경로에 위치한 파일 시스템을 사용할 수 있게 된다. 그러나 PC 쪽의 NFS 클라이언트를 설치했을 경우에는 사정이 달라진다. 즉, PC NFS에서는 Samba와 마찬가지로 별도의 네트웍 드라이브가 마운트 포인트가 되어야 한다.

그림 2: NFS의 마운트 포인트 설정 [NFS White Paper]

NFS 프로토콜은 클라이언트 쪽에서 서버 쪽의 원거리 파일과 디렉토리를 마치 지역 디스크에 있는 것 처럼 다룰 수 있도록 하는 몇가지 원거리 프로시져로 구성되어 있다. NFS 프로토콜을 사용하여, 클라이언트는 서버 쪽에 파일에 관련된 각종 연산을 요청하고, 서버는 접근 허가 허용 범위안에서 연산을 수행하며 그 결과를 반환한다. NFS가 UDP 프로토콜에 밀접히 물려있어 발생하는 제한점을 극복하기 위해 Sun에서는 TI-RPC (Transport Independence Remote Procedure Call)을 정의하고 이를 이용하여 NFS를 구현함으로써 수송 계층의 프로토콜에 무관하게 동작가능하도록 정책을 바꾸었다.

앞서 언급한 바와 같이 대부분의 UNIX 운영체제는 Sun으로부터 라이선스 받아 NFS 패키지를 기본으로 탑재하고 있는 반면에, Windows 운영체제 쪽으로 가게되면 NFS의 지원이 미약하다. 그러나 최근 Windows 95/NT가 보급되면서 TCP/IP 스택을 기본으로 장착하고 있으므로, NFS 클라이언트만 구입하면 별 어려움 없이 UNIX 서버의 파일 시스템을 사용할 수 있다. 무료로 보급되는 Samba와 비교해볼때, NFS 구축 문제는 결국 돈으로 귀착되는 셈이다.

3.2.3 NFS의 보안 문제

Sun Microsystems 사의 운영체제 패키징 및 메뉴얼 상의 오류로 인해 초창기 NFS에는 몇몇 심각한 보안 문제가 존재하고 있었다 (8). 물론 이러한 사실을 제외하고서라도 네트웍으로 파일 자원을 공유함으로 생길 수 있는 위험성은 여전히 꺼지지 않는 불씨로 남아있다.

시스템 관리자가 NFS를 사용하여 외부로 export할 호스트 대상을 잘못 설정할 경우, 파일의 내용 뿐만이 아니라 시스템 관리자 권한까지도 타인에게 넘겨줄 가능성이 있으므로, 각별히 주의해야 한다. NFS를 이용한 파일 공유에서 한번쯤 생각해볼만한 사항들을 정리하였다.

만일 파일 시스템이 읽기 전용 목적이라면 반드시 읽기 전용으로 외부에 공개한다. 파일 시스템에 내용을 쓸 수 없다면 그 만큼 위험성이 줄어든다.
너무 당연한 이야기같지만, 특별한 경우를 제외하고는 외부에 공개하는 파일 시스템에 시스템 관리자 권한을 주지않는다.
sh을 이용한 공격을 방어하기 위해 마운트된 파일 시스템에서 setuid 프로그램을 수행할 수 없도록 export 시에 nosetuid 선택사양을 명시적으로 지정한다.
게이트웨이 (gateway)로 사용하는 기계에서 anonymous ftp 목적이외의 NFS 서어비스는 삼가한다.

4. 인터넷에서의 파일 공유 표준화 동향

인터넷의 대중화와 NC의 등장은 지역 네트웍을 뛰어넘어 인터넷 상에서의 파일 공유에 대한 필요성을 날로 증가시키고 있다. 현재 인터넷을 통하여 자료를 주고받을 경우 SMTP (Simple Mail Transfer Protocol), NNTP (Network News Transfer Protocol), HTTP (HyperText Transfer Protocol), FTP (File Transfer Protocol)등의 표준 규약을 사용하고 있는데, 막상 가장 중요한 파일 시스템의 표준 규약은 아직도 제대로 정비되지 않은 상황이다.

디스크가 없는 NC 및 X 터미날은 두말할 나위도 없고, Windows를 사용하는 PC 클라이언트나 심지어는 UNIX 워크스테이션에서도 인터넷을 통한 파일 공유가 자유로와질 경우 다음과 같은 유리한 점이 있다:

자료의 중복 저장을 방지할 수 있다. 여기저기 흩어진 자료가 많을수록 버전 관리가 힘들어지고 보안상의 헛점도 커진다. 또한, 중복된 자료의 저장 공간도 결코 무시할 수 없는 상황에 이르게 된다.
읽고 쓰기가 실시간에 이루어지며 락을 통한 교착 상황 방지가 가능해지므로 파일 내용의 동기화 문제에 신경쓸 필요가 없다. 읽기 전용의 검색에서 읽고/쓰기가 동시에 가능한 환경을 제공할 수 있다.
파일 은유 (metaphore)를 이용하여 사용자에게 친밀감을 줄 수 있다. 일례로 ftp등을 이용하여 자료를 가져오는 경우와 비교하면 파일을 복사하는 편이 훨씬 직관적이다.
파일을 주고받때의 능률(전송 시간, 전송 품질)이 향상될 수 있다. 잘 만들어진 파일 시스템을 이용하면 보통의 특화된 프로토콜 이상의 효과를 볼 수 있다.

물론 보통의 파일 공유에서도 얼마든지 이상의 장점이 통용되지만, 파일 공유의 기반 플랫포옴이 인터넷이라고 가정할 경우 그 파급 효과는 상상을 초월한다. 여러 단체에서 분산 파일 시스템을 표준화시키기 위해 상호 경쟁하고 있는 사실이 이를 입증한다. 이어지는 내용에서는 인터넷에서의 파일 공유 표준화 동향을 살펴본다. 아직 시작 단계인 기술도 있고, 이미 성숙된 기술도 있지만 어느 쪽으로 발전하게 될지는 아직 예측 불허인 상황이다.

4.1 CIFS와 Dfs

최근 인터넷 기술 개발에 사운을 걸고 투자를 계속하고 있는 Microsoft 사에서 제안한 두가지 인터넷 표준 파일 공유 기술에 대해서 살펴본다.

4.1.1 CIFS (Common Internet File System)

운영체제 전쟁에서 압승을 거둔 Microsoft 사에서는 이미 다음 공격 목표인 인터넷 시장을 대상으로 자사의 각종 핵심 기술을 표준화시키는 작업에 착수한 바 있다. 이러한 기술 가운데 IETF에 제안하여 드래프트 문서로 통용되고 있는 CIFS는 지역 네트웍에서 이미 충분히 검증받은 SMB 프로토콜 위에 DNS (Domain Name Service)를 이용한 확장성, 느린 전화 접속 네트워킹을 위한 최적화, 유니코드를 따르는 파일 이름 지원을 덧붙여, Windows와 UNIX 환경을 동시에 지원하는, 인터넷 상의 표준 파일 규약으로의 자리 매김을 서두르고 있다.

한가지 중요한 사실은 이전의 폐쇄적인 SMB 프로토콜의 경우와는 달리 CIFS 규약 정의에 여러 UNIX 업체들이 대거 참여했다는 점이다. 앞서 소개한 Samba도 버전이 올라감에 따라 점차로 CIFS 규약을 완성시켜가고 있으므로, 조만간 CIFS의 입지가 더욱 강화될 전망이다.

앞서 3.1.2 절에서 이미 SMB 프로토콜을 설명한 바 있으므로 중복된 내용은 생략하고 CIFS에서 제공하는 향상된 특질들만 간략하게 언급하고 넘어가도록 한다.

DNS를 이용한 서버 이름 결정: 원래 SMB 규약에 따르면 15자의 NetBIOS 이름 제약이 존재하였다. 하지만 인터넷에서 파일 시스템 서버 위치를 결정하기 위해서는 이러한 제약에서 반드시 벗어나야 하므로, CIFS에서는 다음의 방식으로 서버 이름을 지정할 수 있도록 그 정책이 변경되었다:
- DNS
- NetBIOS
- IPX
- IPv4 address
분산 파일 시스템 제공: 특히 이 항목에 관련해 다루어야 할 내용이 많으므로, 4.1.2 절에 별도로 설명하도록 한다.
유니코드를 따르는 파일 이름: DOS의 제약인 8.3 이름 규약에서 벗어나 255자 까지의 이름을 쓸 수 있다. 또한 파일 이름을 명명할때 유니코드를 사용할 수 있다.

4.1.2 Dfs (Distributed File System)

Microsoft에서 NT 5.0부터 기본으로 장착할 계획인 Dfs는 별도의 프로토콜 스펙이 존재하는 것이 아니라 CIFS에 포함된 규약 중 분산 환경을 지원하는 특성을 강조하기 위해 별도로 분리시켜 부르는 이름이다. 만일 NT 4.0을 사용하고 있다면 Microsoft에서 제공하는 플러그인을 사용하여 Dfs 서어비스를 바로 사용할 수 있다. Dfs는 네트웍으로 연결된 여러 서버에 존재하는 여러 공유 볼륨을 하나의 논리적인 트리 구조로 나타낼 수 있는 기능을 제공하므로 관리자와 사용자의 편의성을 극대화시킬 수 있다.

Dfs를 이용하여 공유 볼륨을 트리 구조로 관리하면, 사용자는 더 이상 어느 서버에 공유 볼륨이 존재하는지 쫓아다니면서 신경 쓸 필요가 없다. 다시 말해, Dfs의 트리의 root에 한번 접속하면 그때부터 모든 하위 계층의 디렉토리와 파일을 물리적 위치와 무관하게 사용할 수 있다. 이후 문제가 생겨 공유 볼륨을 담은 서버가 교체/변경되더라도 사용자는 이러한 사실과 무관하게 작업을 계속할 수 있다.

하나의 네트웍에 여러 Dfs 트리를 생성시킬 수 있으므로, 사용자 타입 별로 다른 뷰를 제공하는 상이한 Dfs 트리를 구축할 수 있다. 만일 기술 개발팀이 하나 이상이 존재한다고 가정하면, 모든 팀이 같이 공유해야할 자료가 있는 반면에 팀 단위로 공유해야할 자료가 있을 것이다. 이럴 경우 Dfs 트리를 팀 개수만큼 생성시키고 모든 팀이 같이 공유해야할 자료를 하나의 서버에 두고 이를 모든 Dfs 트리에 동시에 포함하는 방법을 쓸 수 있게 된다. 물론 나머지 팀별로 필요한 자료는 각자 팀의 Dfs에만 추가시키면 관리가 쉬워진다.

[그림 3]을 보면 알 수 있듯이 Dfs는 트리 구조를 가지고 있다. Dfs 트리는 하나의 root 트리를 가지며 이 root 트리 아래에 leaf 볼륨들을 가진다. leaf 볼륨은 여러 물리적 서버의 공유 볼륨이 될 수 있다 (Dfs에서는 2 단계의 볼륨만 제공). 여기서 유의할 점은 Dfs root 트리는 반드시 Dfs를 지원하는 서버에 위치해야 한다는 사실이다. SMB에 친숙한 사용자는 별도의 부가적인 과정을 거치지 않고 평상시와 다름없이 Dfs 볼륨을 마운트해서 사용할 수 있다. Dfs 트리에 추가시킬 수 있는 볼륨은 SMB, Netware, NFS 등이 될 수 있다.

Dfs에서는 하나의 볼륨을 위해 둘 이상의 물리적 공유 볼륨을 중첩시켜 할당할 수 있다. [그림 3]에서 \\human_resources\dfs\benefits 디렉토리의 예를 보면 하나의 볼륨이 둘 이상의 공유 폴더를 사용하고 있음을 알 수 있다. 이럴 경우 볼륨이 교체 경로 (alternate path)를 가지고 있다고 표현한다. 교체 경로는 부하를 분산시키며, 심지어 하나의 서버가 다운되더라도 결함 포용 방식을 이용하여 사용 가능한 서버를 자동으로 연결하는 기능을 제공한다. 그러나 결정적으로 교체 경로에 속한 서버들의 내용을 동기화시키는 기능이 빠져있으므로, 읽기 전용으로 교체 경로를 사용하거나 별도의 다른 수단을 이용하여 볼륨 내용을 동기화시켜야 한다.

그림 3: DFS 계층 구조 [DFS White Paper]

4.2 NFS3와 WebNFS

Microsoft 사의 표준 동향 설명에 이어 초창기부터 네트웍 표준을 주도해나가고 있는 Sun Microsystems 사에서 제안한 인터넷 표준 파일 공유 기술에 대해 살펴본다.

4.2.1 NFS3

NIS 및 NFS로 UNIX 환경에서의 네트웍 서어비스 표준을 주도한 Sun Microsystems 사는 여러 업체와 공동으로 NFS2의 단점을 개선한 NFS3 규약을 발표하여 Digital UNIX와 Solaris 운영체제에 탑재하여 출하하기 시작했다. 효율이 떨어지는 기계와 소규모의 네트웍 환경에서 운영의 목표로 삼은 NFS2와는 달리 시작부터 NFS3는 빠른 기계와 대규모의 네트웍 환경에 적합하도록 설계되었다.

NFS2와 비교하여 물리적인 측면에서 바로 들어나는 NFS3의 특징은 다음과 같다:

파일 오프셋이 32비트에서 64비트로 늘어났다. 따라서, 기존 NFS2에서 문제로 들어난 4.2G의 최대 파일 크기의 제약을 벗어날 수 있다.
파일 전송 크기가 증가되었다. 기존 NFS2에서는 서버와 클라이언트가 주고받을 수 있는 최대의 파일 전송 단위가 8kb로 고정되어 한번에 이 이상을 넘는 읽기/쓰기가 불가능하였다. NFS3에서는 서버와 클라이언트의 협상에 의해 파일 전송 크기가 얼마든지 바뀔 수 있다. 이러한 가변적인 파일 전송 크기 결정을 통하여 네트웍 및 I/O 대역폭을 최대로 활용할 수 있다. 특히 FDDI나 FastEthernet과 같은 고속의 네트웍을 이용할 경우에는 파일 전송 크기가 증가할 수록 효율이 올라간다.
디스크에 적는 각종 연산시의 효율을 올렸다. 기존 NFS2에서는 자료가 안전한 매체에 기록된 이후에야 반드시 자료를 commit 하도록 정해져 있으므로, 효율이 떨어졌다. 하지만 NFS3에서는 이러한 조건을 완화시킨 새로운 방식의 commit 규정 (safe asynchronous writes)을 도입함으로써 훨씬 높은 쓰기 효율을 발휘한다 ([그림 4], [그림 5] 참조).

(1, 2, 3의 연속적인 자료가 지역 캐쉬에 저장된 다음 서버쪽의 디스크로 바로 저장되는 과정을 볼 수 있다. 따라서 commit 속력은 디스크의 latency에 크게 의존한다.)

그림 4: NFS2 파일 쓰기 정책 [NFS White Paper]

(1, 2, 3의 연속적인 자료가 지역 캐쉬에 저장된 다음 서버쪽의 캐쉬로 저장되는 과정을 볼 수 있다. 이때 비록 디스크의 latency가 늦더라도 commit이 즉각적으로 일어난다.)

그림 5: NFS3 파일 쓰기 정책 [NFS White Paper]

NFS3는 기존 NFS2에서 사용하던 UDP를 대신하여 TCP를 사용한다. 초창기 NFS2에서 UDP를 사용한 이유는 TCP보다 빠르다는 한가지 이유 때문이었다. 하지만 최근 들어와서 TCP 스택의 구현 기술이 발달하면서 UDP와의 속력 격차를 점차로 줄여가고 있기 때문에, 굳이 UDP를 고집할 이유가 없어졌다. TCP는 UDP와는 달리 신뢰성있는 프로토콜이므로 NFS 클라이언트쪽의 구현을 대폭적으로 간소화시킬 수 있다. 그 결과 NFS 클라이언트의 속력을 향상시킬 수 있다. UDP와는 달리 값비싼 TCP 초기화 비용을 줄이기 위해 클라이언트는 하나의 TCP 연결을 이용하여 multiplexing 기법으로 통신을 한다.

[그림 6]은 NFS3가 TCP와 UDP를 모두 지원하므로, 기존 지역 네트웍 뿐만 아니라 인터넷에서도 파일을 효과적으로 공유할 수 있음을 보여준다. NFS3는 NFS2와 호환성이 있게 설계되어 있으므로 기존의 NFS2 서버나 클라이언트를 변경하지 않고 그대로 사용할 수 있다.

그림 6: TCP를 사용한 인터넷 상에서의 NFS3 파일 공유 [NFS White Paper]

4.2.2 WebNFS

WebNFS는 인터넷 상의 WWW 검색기, Java 애플릿에서 NFS 규약을 바탕으로 파일을 공유하도록 하는 표준 규약이다. WebNFS는 현재 IETF의 RFC로 규정되어 있으며, Solaris 2.5에 따라오는 웹서버에 구현되어 있다. WebNFS는 http나 ftp와는 달리 운영체제 레벨의 서어비스 (NFS)를 사용하여 동작하기 때문에 효율적인 동시에 높은 부하에 견딜 수 있는 장점이 있다. WebNFS는 특히 새롭게 정의된 NFS3 기술에 크게 의존하고 있으며, 여기에 두가지 특성이 부가된다.

방화벽 (firewall)과 프록시 (proxy)를 위해 잘 알려진 포트 번호 (2049번)를 이용한다. 방화벽이나 프록시를 이용하는 경우 보안을 위해 UDP를 지원하지 않으며, TCP의 경우에도 정해진 특정 포트 번호에만 접근을 허용하는 경우가 많다. 따라서 2049번이라는 업계 표준의 알려진 포트 번호를 사용하기로 미리 약속되어 있다.
경로 이름을 검사하는데 MCL (Multi-Component Lookup) 기법을 이용하여 NFS 서버로부터 파일 핸들을 얻어내는 회수를 최소로 줄인다. [그림 7]에서 알 수 있듯이, MCL을 이용할 경우 pub, foo, bar 세가지 컴포넌트를 얻어내는데 단 한번의 LOOKUP 연산이 필요하지만, MCL을 이용하지 않을 경우 각 컴포넌트 별로 LOOKUP을 해야하므로 전체 세번의 LOOKUP 연산이 필요하다. WebNFS에서는 이러한 MCL 기법을 사용하여 네트웍 접근 회수를 줄임으로서 속력을 향상시킨다.

그림 7: MCL을 이용한 경로 이름 검사 [Callaghan 97]

WebNFS 클라이언트는 인터넷을 통하여 NFS 파일 시스템에 담긴 문서를 읽는 표준적인 WWW 검색기가 될 수 있다. 이 때 문서의 위치를 지정하기 위해 URL [RFC 1738] 을 사용하게 되는데, 그 형식은 다음과 같다:

nfs://server:port/path

port 번호는 별도로 지정되지 않았을 경우 2049번이 되며, path에는 별도의 / (슬래쉬)를 붙일 필요가 없다. NFS URL을 이용하여 파일을 가져올 경우 MIME 헤더가 첨부되어 오지 않으므로 클라이언트 쪽의 확장자 및 MIME 타입 정보를 이용하여 암묵적인 방법으로 파일 타입을 알아내어야 한다.

WebNFS에서 제공하는 기능을 Java^TM에서 사용하려면 URL 클래스를 사용해야 한다. 하지만 아직 보안 때문에 URL 클래스의 제약점이 많으므로, NFS에서 제공하는 완벽한 서어비스를 모두 이용할 수 없다. NFS 서버에 담긴 파일을 열기위한 자바 코드의 예는 다음과 같다:

f = new File(new URL("nfs://myserver/file.txt"))

위의 코드를 사용하면 지역에 있던 원거리에 있던 상관없이 파일을 열 수 있다. 기존 "file" URL과 한번 비교해보기 바란다.

4.3 AFS (Andrew File System)

앞서 설명한 NFS3, WebNFS, Dfs의 경우 원래 지역 네트웍에서 사용하기 위한 목적으로 개발된 기술을 확장하여 인터넷에 적용 가능하도록 변경한 흔적이 여기저기 남아있다. 그러나 본문에서 마지막으로 소개할 AFS의 경우 초창기부터 전 세계 파일 시스템을 하나로 묶는다는 야심찬 목표로 출발한 결과, 대규모 네트웍에서 운영 가능한, 현재까지 유일하게 검증된 시스템으로 자리를 굳혔다.

4.3.1 AFS의 역사

AFS는 카네기-멜론 대학에서 대학 캠퍼스 전체의 정보화 증진 목적으로 출발한 앤드류 (Andrew) 프로젝트의 일부로서 그 개발이 시작되었다. 앤드류 프로젝트는 단순한 파일 시스템만의 개발이 아닌, 사용자 인터페이스 툴 킷, 대학 전역에서 사용할 응용 프로그램, 응용 프로그램 위에서 동작하는 각종 코스웨어 개발에 이르는 대규모의 교육 프로젝트이다. MIT의 프로젝트 아데나 (Athena)를 위해 기반 기술로 개발된 X 윈도 시스템이 커다란 반향을 불러일으킨 것과 마찬가지로, 앤드류 프로젝트를 위해 기반 기술로 개발된 AFS도 분산 파일 시스템 역사에 한 획을 그었다.

AFS는 앤드류 프로젝트의 주요 후원 업체인 IBM의 자회사로 편입된 Transarc에서 상품화하여 계속 기능이 향상되어 버전이 올라가고 있으며, OSF (Open Software Foundation)에서 만든 DFS (Distributed File System) 표준의 근간이 되었다.

1997년 현재 국내에서 AFS가 운영되는 곳은 포항공과대학교 한 곳 뿐으로 전 대학교에 퍼져 있는 300여대의 워크스테이션에서 2000 명 이상의 사용자 그룹 (교수, 학생, 연구원, 직원)이 AFS 서어비스를 이용하고 있다 [HEMOS]. 해외에서는 미국, 유럽, 일본에 분산되어 있는 대학, 연구소, 회사, 정부 기관을 포함하는 130군데 사이트에서 AFS를 운영 중이다 [AFS-FAQ].

4.3.2 AFS의 특성

AFS는 분산 파일 시스템의 정의를 내릴 수 있을만큼 복잡한 여러 특성을 지니고 있다. AFS에 대한 내용을 본격적으로 설명하자면 별도의 책이 필요하므로 여기서는 주로 상위 단계에서의 특징만을 간략하게 다룬다. AFS의 설치법이나 사용자 및 관리자 명령 소개는 이 글의 목적에서 벗어나므로 별도의 문서 [AFS-FAQ]를 참고하기 바란다.

향상된 캐쉬 관리: 파일 시스템을 관리하는 서버 쪽이외에 클라이언트 쪽에도 메모리 캐쉬와 디스크 캐쉬 (디스크가 있을 경우)를 설정할 수 있다. 이러한 캐쉬 기능을 이용하여 네트웍 부하를 줄이는 동시에 속력을 개선한다.
파일 시스템의 위치 투명성: NFS와는 달리 워크스테이션에서 마운트 된 위치에 따라 파일 시스템 계층 구조가 변화되지 않는다. 따라서 사용자는 원하는 파일이 어느 서버에 위치하고 어느 디렉토리에 존재하는지 무관하게 일관된 파일 경로를 이용하여 접근할 수 있다.
확장성: 워크스테이션의 관리 단위인 cell에 속한 서버와 클라이언트의 비율이 이론적으로는 1:200 까지도 버틸 수 있도록 설계되어 있다. 평균 1:50의 비율에서 최적의 조건이 형성되는데 기존의 분산 파일 시스템으로 이러한 확장을 시도하기는 어렵다. 또한 파일 시스템의 위치 투명성을 이용하여 서버를 추가하고 옮기고 클라이언트를 늘이고 줄이는데 제약사항이 없다.
뛰어난 보안: 암호가 네트웍을 타고 평문으로 전달되지 않으며, 클라이언트와 서버 사이의 상호 인증이 가능하도록 설계되어 있다. 또한 ACL을 이용하여 여러 부류의 사용자에 대해 다양한 권한을 부여할 수 있다.
단일한 시스템 이미지: 특정 지역의 AFS cell에서 다른 특정 지역의 AFS cell에 속한 파일 시스템을 사용할 수 있다. telnet이나 ftp 같은 방식이 아니라 AFS 클라이언트 자체의 기능을 이용한 원거리 파일 공유가 가능한 것이다.
AFS 볼륨 복제: 자주 사용되는 파일이 담긴 볼륨은 읽기 전용으로 여러 서버에 분산 배치할 수 있다. 하나의 서버가 동작을 멈추더라도 자동으로 다른 서버에 자료를 요청하므로 결함 포용 능력을 향상시킬 수 있다. 또한 AFS 클라이언트는 가장 가까운 복제 서버에 접속을 시도하므로 네트웍 혼잡을 피할 수 있다.
서버 다운시의 대처 능력: 서버가 다운되면 캐쉬에 남은 파일이 서버가 복구될때까지 읽기 전용으로 열리게 되며, 서버가 복원되면 이 때 저장된다. 그리고 볼륨 복제를 이용한 읽기 전용 파일은 다른 가용 서버를 이용하여 가져오게 된다.
사용 편의성: ftp 명령 필요없이 표준 cp(1)를 이용하여 afs 트리에 널려있는 파일들을 복사할 수 있다. 네트웍으로 연결된 AFS를 사용한다면 특별한 경우를 제외하고서 굳이 파일을 복사할 필요도 없다.
시스템 관리 능력 향상: 관리자는 어느 AFS 클라이언트에서도 AFS 서버에 접근할 수 있으며, 시스템을 멈추지 않고서도 볼륨을 생성하고 옮기고 백업받을 수 있다.

현재의 AFS 3.4 버전은 TCP/IP 상에서만 동작하도록 설계되어 있으며, 지원하는 플랫포옴은 다음과 같다:

Windows 3.1, Windows 95, WIndows NT, Macintosh, Digital UNIX 2.x/3.x, HP/UX 9.0.x, Ultrix 4.x, AIX 3.2.x/4.1.x, SunOS 4.1.x, Solaris 2.x, IRIX 5.x

4.3.3 AFS와 타 파일 시스템과의 비교

AFS는 다른 파일 시스템에 비해서 아직 보급률이 낮으므로, 이를 접해본 사용자 수가 상대적으로 적을 것이다. 따라서 AFS의 복잡한 특성을 보다 쉽게 설명하기 위해, 시중에 많이 보급되어 있는 타 파일 시스템과 비교하여 도식화시켜 보았다.

먼저 사용자 관점에서 AFS와 UFS (Unix File System)를 [표 2]에 정리하였다. AFS를 FAT등과 비교하는 것은 무의미할 것으로 생각되어 여기에 기술하지 않았다. [표 2]에 정리된 몇가지 특이한 사항을 제외하고는 UFS에 익숙한 일반 사용자가 AFS를 사용할 경우 아무런 불편을 느낄 수 없다. 또한 프로그래머 입장에서 byte 단위의 파일 잠금이 불가능하다는 사실만 제외하고는 거의 모든 UNIX의 시스템 호출 및 표준 파일 관련 함수를 그대로 사용할 수 있으므로, 기존의 프로그램을 별도로 포팅하는 번잡함을 피할 수 있다.

특성	AFS	UFS
사용자 인증 (최종 사용자)	토큰을 이용한 인증 (보안 서버가 별도로 존재하므로 중앙집중식 관리가 가능)	uid를 이용한 인증 (지역 기계별로 관리하거나 NIS등을 통하여 소규모 환경에서 중앙집중식으로 관리)
파일 접근 허가 (최종 사용자)	디렉토리 단위로 접근허가 부여	파일 단위로 접근허가 부여
ACL (Access Control List) (최종 사용자)	완벽한 ACL 지원	IBM의 AIX에서 ACL 지원, 나머지 표준 유닉스에서는 지원하지 않음
보호 그룹 설정 (최종 사용자)	사용자가 임의의 사용자를 지정하여 보호 그룹의 설정 가능	시스템 관리자에 의해서 미리 정의된 그룹에 대한 접근 허가 지정
하드 링크 (최종 사용자)	디렉토리 내에서만 가능	마운트된 파일 시스템을 벗어나지 않는 범위에서 가능
파일 이동에 따른 접근 허가 변경 (최종 사용자)	이동한 디렉토리의 ACL을 따름	이동하기 전의 파일 접근 허가를 따름
byte 단위의 파일 잠금 (프로그래머)	불가능	가능
전체 파일 잠금 (프로그래머)	flock()을 통하여 가능	flock()을 통하여 가능
character 및 block 파일 생성 (관리자)	불가능	가능
fsck (관리자)	AFS 버전 fsck 사용	기존 fsck 사용

표 2: AFS와 UFS와의 비교 [AFS-FAQ]

[표 2]에서는 일반적인 파일 시스템의 특성을 다루었다. 이제 [표 3]에서 AFS와 기존의 분산 파일 시스템을 비교하여 설명한다. 비교 대상은 앞서 이미 설명한 바 있는 NFS와 Dfs (OSF의 DSF가 아니라 Microsoft 사의 Dfs임에 유의하라.)로서 분산 파일 시스템에서 중요시되는 몇가지 비교 기준을 이용하여 각각을 평가하였다. [표 3]에 나타난 바와 같이 AFS는 다른 분산 파일 시스템에 비해 대규모 네트웍에서 운영하기 편리하도록 설계된 여러 좋은 특성을 가지고 있다.

비교 기준	AFS	NFS	Dfs
파일 접근	모든 워크스테이션에 동일한 이름 스페이스	워크스테이션마다 제각기 다른 이름	워크스테이션마다 제각기 다른 이름
파일 위치 추적	파일 시스템 프로세스와 데이터베이스를 이용한 자동 추적	관리자와 사용자에 의해 설정된 마운트 포인트에 의해 추적	관리자에 의해 설정된 Dfs 트리 구조에 의해 추적
효율	네트웍 부하를 줄이기 위한 클라이언트 쪽의 캐슁, 캐쉬 일관성을 위한 콜백, 메모리 캐쉬 지원	캐쉬 기능 부족	캐쉬 기능 부족
확장성	대규모 네트웍에 적합	지역 네트웍에 적합	지역 네트웍에 적합
보안	MIT Kerberos를 이용한 사용자 인증, 사용자와 그룹에 대한 ACL (Access Control List) 지원	암호화 되지 않은 사용자 ID를 통한 인증, Kerberos를 사용하기도 함	암호화 되지 않은 사용자 ID를 통한 인증, Kerberos를 사용하기도 함
가용성	많이 읽은 자료에 대한 복제 기능	복제 기능 없음	교체 경로 지원 (동기화는 지원하지 않음)
백업	시스템 무정지 백업 가능	일반적인 UNIX 백업	일반적인 Windows 백업
환경 조정	볼륨 단위로 조정	파일 단위의 이동	파일 단위의 이동
시스템 관리	어느 워크스테이션에서도 가능	다른 워크스테이션으로의 telnet이 요구됨	콘솔에서만 작업 가능
자치 구조	파일 서버, 클라이언트, 셀 (cell) 단위	파일 서버, 클라이언트 단위	파일 서버, 클라이언트 단위

표 3: AFS와 NFS/Dfs와의 비교 ([AFS-FAQ]를 토대로 Dfs 항목 추가)

5. 결론

이상으로 파일 공유의 역사, 지역 네트웍에서의 파일 공유 방안, 인터넷에서의 파일 공유 표준화 동향에 대한 각종 기술을 살펴보았다. 물론 이 글에서 설명한 이러한 역사, 배경, 이론을 모르고서도 얼마든지 경험에 의거하여 분산 파일 시스템을 운영할 수 있을 것이다. 하지만 보다 효과적인 운영을 위해서는 다소간 따분한 내용을 이해하고 적용할 수 있어야 하는 것도 사실이다.

원래 Samba 및 NFS를 이용한 상이한 기종 간의 파일 공유라는 주제를 놓고 운영 측면에서 문서를 기술할 생각이었다. 하지만, 인터넷 상의 파일 공유 표준안이 차례로 확정되는 지금과 같은 숨가쁜 상황에서, 차라리 약간 추상적이더라도 이러한 조류를 설명하는 편이 나을 것 같아 기획 초기부터 글의 방향을 대폭적으로 수정하였다.

아무쪼록 부족한 점이 많은 이 문서가 지역 네트웍에서의 파일 공유 및 더 나아가 인터넷에서의 파일 공유 전략을 수립하는데 도움이 되었기를 바란다. 조만간 인터넷에서의 파일 공유가 활성화되는 상황을 보아가며, 각 기술에 대해 보다 상세한 내용을 담은 문서를 선보일 것을 남아있는 지면을 빌어 약속한다.

참고문헌 (References)

[AFS-FAQ] "AFS distributed filesystem FAQ,": URL: http://www.cis.ohio-state.edu/hypertext/faq/usenet/afs-faq/faq.html
[Blackman 97] Paul Blackman, "Samba FAQ," Cooperative Research Centre for Freshwater Ecology, Australia, 1997,: URL: http://samba.canberra.edu.au/pub/samba/docs/faq/sambafaq.html
[Callaghan 97] Brent Callaghan, "WebNFS^TM -- The Filesystem for the Internet," Sun Microsystems, Inc., April 1997,: URL: http://www.sun.com/sunsoft/solaris/networking/webnfs/webnfs.html
[CIFS White Paper] "Common Internet File System (CIFS)," Microsoft Corporation, 1997,: URL: http://www.microsoft.com/intdev/cifs/
[Cohen 93] David L. Cohen, "AFS: NFS on steroids," LAN Technology, March 1993, v9 n3 p51(9), M&T Publishing,: URL: ftp://ftp.transarc.com/pub/afs-contrib/doc/faq/NFS_on_steroids
[DFS White Paper] "Microsoft Distributed File System for Microsoft Windows NT Server 4.0 Administrator's Guide," Microsoft Corporation, 1997,: URL: http://www.microsoft.com/ntserver/dfs/dfsdocdl.htm
[HEMOS] "POSTECH HEMOS Home Page," POSTECH 1995 - 1997: URL: http://www.postech.ac.kr/hemos
[Heizer 96] I. Heizer, P. Leach and D. Perry, "Common Internet File System Protocol (CIFS/1.0)," Microsoft Corporation, 1996
[Jaegermann 96] Michal Jaegermann, "Samba Server HOWTO," University of Alberta, Canada, 1996,: URL: http://lake.canberra.edu.au/pub/samba/docs/smb_serv/html/smb_se.html
[NFS White Paper] "The NFS^TM Distributed File Service," Sun Microsystems, Inc., March 1995,: URL: http://www.sun.com/sunsoft/solaris/desktop/nfs.html
[Raymond 96] Eric S. Raymond, "The New Hacker's Dictionary 3rd Edition," MIT Press 1996,: URL: http://www.ccil.org/jargon/jargon_toc.html
[RFC 1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource Locators (URL),": URL: http://www.internic.net/rfc/rfc1738.txt
[RFC 2054] Callaghan, B., "WebNFS Client Specification,": URL: http://www.internic.net/rfc/rfc2054.txt
[RFC 2055] Callaghan, B., "WebNFS Server Specification,": URL: http://www.internic.net/rfc/rfc2055.txt
[Park 97] JaeHo Park, "Samba Quick Installation Guide (7th revision, 2nd minor revision)," KIES , 1997,: URL: http://www.kies.co.kr/~jhpark/Samba/samba/samba.html
[Sharpe 96] Richard Sharpe, "Just what is SMB?," NS Computer Software and Services Pty Ltd., 1996,: URL: http://samba.anu.edu.au/cifs/docs/what-is-smb.html

각주 (Footnotes)

(1) SMB, CIFS, Vfs, 및 Windows 95/NT는 Microsoft 사의 등록 상표, NFS 및 WebNFS 는 Sun Microsystems 사의 등록 상표, AFS는 Transarc 사의 등록 상표, UNIX는 SCO 사의 등록 상표이다.
(2) "THE NETWORK IS THE COMPUTER.^TM"는 Sun Microsystem 사의 등록 상표이다.
(3) 초창기 운영체제인 CP/M, Apple DOS, Disk Basic, MS-DOS 등의 예를 들면 무슨 말인지 이해가 갈 것이다.
(4) NIS의 원래 이름은 YP (Yellow Page)였다. 하지만 YP가 이미 영국 전화 회사 (the United Kingdom of British Telecommunications plc.)에 의해 상표등록이 되어있어서 이후에 명칭이 변경되는 불운을 겪었다. 하지만 NIS 관련 명령어의 접두어가 여전히 yp로 남아있어 아직도 개명의 흔적이 사라지지 않고 있다.
(5) [Park 96]을 인터넷에 공개한 이후에 조사한 ftp 및 http를 통한 문서의 접근 횟수 및 Samba와 관련하여 받은 전자 편지의 양으로 어렵지 않게 추측할 수 있다.
(6) Samba에 대한 설치 및 운영 방법은 [Jaegermann 96] 또는 [Park 96]을 참조하기 바란다. NFS에 대한 설치 및 운영 방법은 서버 쪽은 메뉴얼 페이지를, 클라이언트 쪽은 각 제품에 포함된 사용 설명서를 참조하기 바란다.
(7) Samba에서 smbd(8)와 nmbd(8)를