김용우 academic@lily.yonsei.ac.kr
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
NFS(Network File System)는 파일시스템을 컴퓨터끼리 공유할 수 있게 해주는 서비스이다. 즉, 여러 대의 컴퓨터(NFS 클라이언트)가 큰 용량의 하드디스크를 가진 컴퓨터(NFS 서버)로부터 서버의 하드웨어나 운영체제에 관계없이 파일시스템을 가져다 마치 자신의 파일 시스템인 것처럼 사용할 수 있게 해주는 것이 NFS의 기본 개념이다. 네트웨어나 NT, 윈도우 95에서의 파일 공유를 접해본 일이 있는 사람은 쉽게 이해할 것이다. 이러한 NFS의 개념은 적은 용량의 디스크를 가진, 또는 아예 그것조차도 없는 클라이언트를 나타나게 하였다. 그리고 이들이 NFS 서버의 대용량 파일 시스템을 공유할 수 있게 됨으로써 아무런 불편 없이 저렴하게 시스템을 사용할 수 있도록 하는 파급 효과를 낳기도 하였다. NFS는 1985년 썬(Sun Microsystems)사가 도입했다. 원래는 하드디스크가 없는 클라이언트를 구현하기 위해 도입했었지만, 지금은 리눅스를 포함한 대부분의 유닉스가 어떤 형태로든지 NFS를 구현하고 있을 정도로 유닉스에서의 대표적인 파일 공유 방법이 되었다. 그리고, 이런 NFS의 유명함 때문에 유닉스만이 아니라 도스를 비롯한 거의 모든 OS에서도 NFS를 쓸 수 있다. 이 글은 물론 리눅스를 중심으로 설명하지만,
다른 유닉스의 시스템의 NFS도 간략하게나마 1장에서는 NFS 서버에 대해서 다룬다. 서버에서
NFS를 설치하는 방법, 그리고 NFS 서버가 이어서, 2장에서는 NFS 클라이언트에 대해서 다룬다. NFS클라이언트를 설치하는 방법, 그리고 클라이언트의 환경 설정 방법인 fstab 파일의 자세한 설정 방법을 다룬다. 3장에서는 fstab 파일의 단점을 보완하기 위해 나온 자동 마운터 중에서 가장 유명한 amd의 사용법을 다루고, 마지막 4장에서는 유닉스 관리자 입장에서 NFS를 다룰 때 알아두어야 할 UID와 GID의 통일, 표준적인 디렉토리 명명규칙의 필요성, 외부 네트워크와 NFS를 할 때의 문제점, 전용 NFS 파일서버, 보안, 모니터링과 튜닝 등의 문제를 다룬다.
1. NFS 서버 NFS는 파일시스템을 제공해주는 서버와 서버의 파일시스템을 이용하는 클라이언트의 협동작업으로 이루어진다. 여기서는 먼저 NFS 서버에 대해서 알아본다.
1.1 NFS 서버 프로그램 설치 모든 유닉스 시스템은 처음 설치할 때 NFS에
필요한 파일을 설치한다. 따라서 별도의 NFS 설치 과정은 필요 없다.
리눅스도 초기 설치 과정에서 NFS가 기본으로 선택되어 있으므로
대부분의 시스템에 설치되어있을 것이다. 그러나, NFS가 설치되지
않았더라도 크게 걱정할 필요는 없다. 쉽게 새로 설치할 수 있으니
말이다.
rpm -aqi |grep nfs 명령에 "no match"메시지가
뜨는 경우엔 새로 설치해주면 된다. 이미 잘 알고 있겠지만 다시
한번 반복한다면,
라고 입력한 후에 /etc/rc.d/init.d/nfs start 명령을 내려주면 그것으로 설치 과정은 끝이다.
1.2 NFS 서버 데몬 당연한 얘기지만 NFS 서버를 만들기 위해서는
관련되는 데몬 프로그램이 제대로 설정되어 실행되어야 한다. 이들
데몬 프로그램은 시스템의 rc 스크립트에 의해서 부팅할 때 자동으로
실행된다. AT&T 계열의 rc 스크립트를 쓰는 시스템에서는
/etc, 혹은 /etc/rc.d 디렉토리의 하위디렉토리인 rc2.d나 rc3.d
디렉토리 밑에 S??nfs과 같은 스크립트에 의해서 실행된다. 혹시
이런 스크립트가 없다면, S??nfs라는 이름의 심볼릭 링크를 /etc/init.d/
혹은 /etc/rc.d/init.d 디렉토리 안에 있는 NFS 실행 스크립트에
시키면 된다.
1.2.1. portmap: RPC 서비스를 TCP/UDP 포트에 연결 NFS는 썬의 XDR(아키텍쳐와 무관하게 데이터를 표현하는 방법)과 RPC(remote procedure call) 인터페이스를 기반으로 설계되었다. RPC를 이용하는 프로그램이 시작되면 그 프로그램은 자신이 제공하는 서비스와 자신이 사용하는 포트를 portmap에 등록한다. 그리고, 클라이언트는 portmap에 문의해 원하는 서버에 접근할 수 있는 방법을 알아내게 된다. 유닉스 시스템에 따라서는 portmap 대신에 rpc.portmap, 또는 rpcbind라고도 부른다.
1.2.2. rpc.mountd: 마운트 요청이 들어오면 응답 NFS 클라이언트가 서버의 파일시스템을 이용하기
위해서는 먼저 서버가 자신의 파일시스템을 NFS를 이용해 다른
호스트가 공유할 수 있도록 설정해야 한다. 이와 같은 작업을
BSD 계열 유닉스에서는 export라는 용어를, AT&T 계열 유닉스에서는
share라는 용어를 쓴다. 리눅스는 export라는 용어를 쓴다.
클라이언트가 서버 파일시스템을 마운트할
수 있는 권한을 획득한 이후에도 서버와 클라이언트간에 접속이
계속 유지되는 것은 아니라는 점은 알아둘 필요가 있다. 즉,
http처럼 요청이 들어오는 경우에만 접속이 이루어졌다가 더
이상 필요가 없으면 접속이 해제되는 (stateless) 방식을 취하게
된다.
1.2.3. rpc.nfsd: 파일을 클라이언트에 제공 rpc.mountd가 클라이언트의 마운트 요청을
받아들이면, 클라이언트는 마운트된 파일시스템에 대해 다양한
작업을 할 수 있다. 클라이언트가 작업을 수행하면서 서버 쪽
파일시스템에 무언가를 요구하게 되면 rpc.mountd와 마찬가지로
자기 자신이 NFS 서버로서의 역할도 동시에 수행하고 있지 않다면
NFS 클라이언트가 rpc.nfsd를 실행시킬 필요는 없다. 적어도 4개의 rpc.nfsd는 실행시키는 게
일반적이다. NFS를 자주 이용하지 않는다면 4개 정도면 충분하다.
이론적으론 수백, 수천 개의 rpc.nfsd를 실행하는 것도 가능하다.
그러나, 너무 많은 rpc.nfsd를 실행하는 것도 각각의 프로세스가
CPU를 두고 서로 경쟁하기 때문에 시스템 성능을 저하시킨다.
또 하나의 방법은 UDP 오버플로우의 개수를
파악하는 방법이다. 부하가 많이 걸리는 NFS 서버의 경우, 모든
rpc.nfsd가 사용중일 때 또다른 요청이 들어오면 UDP 소켓이
오버플로우를 일으킬 수 있다. 오버플로우의 개수는 netstat
-s 명령으로 알아볼 수 있는데, 이를 통해 UDP 소켓 오버플로우가
0으로 떨어지려면 대략 얼마나 많은 rpc.nfsd가 있어야 하는지
알아내는 것이다. 이렇게 알아낸 rpc.nfsd의 최적 값을 시스템의
rc 스크립트에 적용하면 된다.
1.2.4. rpc.lockd 파일 잠금(lock)을 통해 여러 명이 동시에 한 파일을 수정하는 것을 막는다. 리눅스에서는 실행되지 않는다.
1.2.5. rpc.statd 파일 잠금의 해제와 복구를 담당한다. 리눅스에서는 실행되지 않는다. 이들 데몬이 제대로 실행되었는지를 확인하고 싶다면, 우선 rpcinfo -p 명령을 통해서 rpc.mountd와 rpc.nfsd가 portmap에 제대로 등록되었는지를 확인해본다. 등록된 이름은 실제 데몬 이름과 약간 다를 수는 있다. 이를테면 rpc.mountd가 mountd로, rpc.nfsd가 nfs로 등록될 수 있다. Ps -aux(AT&T 계열에선 ps -ef) 명령을 통해서 해당 데몬이 실행되고 있는지 확인해보는 것도 유용하다. 때로는 해당 프로세스가 제대로 작동하지 않아도 portmap에 등록되어있을 수 있기 때문이다.
1.3 파일시스템 공유 설정 대부분의 유닉스에서는 /etc/exports 파일에 어느 디렉토리(또는 파일 시스템)를 어떤 제약을 두어 공유할 것인가 하는 내용을 담는다. 아무에게나 자신의 파일 시스템을 마구 사용할 수 있게 하는 것은 마치 대문을 활짝 열어두고 사는 것과 같은 일이기 때문이다. exports 파일의 형식은 공유하는 디렉토리를
왼쪽에 적고 그 디렉토리와 관련된 옵션이나 속성을 오른쪽에 적어
준다. 백문이 불여일견 이므로 리눅스의 exports 파일을 예로 들어보도록
하자.
이 export 파일은 /lily/users 디렉토리를 daisy라는 호스트가 읽고 쓸 수 있고 루트의 권한으로 접근하는 것도 허가한 것이며, rose라는 호스트는 읽기 전용으로 마운트할 수 있게 설정한 것이다. 그리고 /usr/share/man 디렉토리에 대해서는 freesia, clover, disy가 읽기 전용으로 마운트할 수 있게끔 설정한 것이다. 중요한 옵션은 표1과 같다. 표 1)exports 옵션(리눅스)
리눅스의 /etc/exports 파일 형식은 다른 유닉스
시스템에 비해 특이한 편이다. 일반적인 유닉스 시스템의 exports
파일은 옵션사이엔 쉽표(,)를 쓰고, 호스트를 나열할 때는 콜론(:)을
써서 다음과 같이 나타낸다.
exports 파일의 옵션도 유닉스마다 약간 다른데,
자주 쓰이는 옵션을 정리하면 다음 표 2,3과 같다.
이처럼 유닉스마다 export 옵션이 약간씩 다르므로
자세한 exports 파일 형식은 man exports 명령을 이용해 확인하는
것이 좋다. exports 파일에 아무런 호스트도 지정하지 안고
단순히 공유할 디렉토리만 적어주게 되면 그 디렉토리는 "모든"
호스트가 마운트할 수 있게 된다. 이 경우 보안상의 문제를 불러일으킬
수 있으므로 주의해야한다. Solaris의 경우 /etc/exports 대신 /etc/dfs/dfstab
파일을 쓴다. 이 파일은 환경설정파일이라기보다는 share 명령을
실행하는 쉘스크립트다. Share 명령에 쓰이는 옵션은 SunOs의 export
옵션과 유사하다. 예를 들자면,
/etc/exports 파일을 바꿔도 당장 그 변경이
효력을 발생하진 않는다. exports 파일을 바꾼 이후에는 rpc.mountd가
설정파일을 다시 읽도록 해줘야 한다. /etc/exports 파일을 수정한
다음 이를 반영하는 절차는 유닉스 시스템에 따라 다르다. 리눅스는
exportfs 명령이 없기 때문에 kill 명령으로 rpc.mountd와 rpc.nfsd에
SIGHUP 시그널을 보내야 한다. 다음과 같은 스크립트를 /usr/sbin/exportfs라는
이름으로 저장하는 것도 한가지 방법이다.
레드햇 리눅스의 경우 다음 명령을 실행시켜줘도
된다.
HP-UX, IRIX, SunOs 같은 경우는 /usr/etc/exportfs -a 명령을 실행시키면 된다. Exportfs 명령이 없는 OSF/1이나 BSDI는 kill 명령으로 mountd에 SIGHUP 시그널을 보내주어야 한다. Solaris의 경우는 특이한데, share 명령을 수행하면 mountd에게 변경된 내용을 알려주게 되므로, 수정한 /etc/dfs/dfstab 파일을 실행시켜주면 변경된 내용이 반영된게 된다.
2. NFS 클라이언트
2.2 커널 컴파일 NFS 클라이언트를 설정하기 위해서는 먼저 커널이
NFS를 지원하도록 컴파일되어 있어야 한다. 리눅스 커널은 디폴트로
NFS를 지원하도록 컴파일되어 있으므로 신경쓰지 않아도 된다. 만약
새로 커널을 컴파일할 경우에는 make config 명령을 내린 다음에,
이와 같은 부분이 나왔을 때 M 또는 Y를 선택해주면 된다. M을 선택한 경우는 모듈로 컴파일하게 된다. 별로 그럴 일은 없겠지만, 만약 하드디스크가 없는 클라이언트를 구성하고 싶다면 반드시 Y를 선택해야 한다. 다른 유닉스 시스템의 커널도 디폴트로 NFS를 지원하도록 컴파일되어 있다.
2.2 NFS 클라이언트 프로그램 설치 모든 유닉스 시스템은 설치 과정에서 NFS에 필요한 파일을 설치한다. 따라서 별도의 NFS 클라이언트 프로그램 설치는 필요 없다. 리눅스도 NFS 클라이언트로 동작하기 위해서 특별히 설치해줘야 하는 프로그램은 없다. 레드헷 리눅스의 경우, nfs-server-clients-???-?.rpm를 설치하면 한두가지 유틸리티가 설치되지만, 반드시 필요한 것은 아니다.
2.3 NFS 클라이언트 데몬 NFS 클라이언트가 실행시키는 데몬은 nfsiod 하나정도밖에 없다. 엄격히 말해 필수적인 데몬은 아니지만, 반드시 이 데몬을 실행하길 바란다. 하지만, 리눅스의 경우는 커널 차원에서 nfsiod를 지원하므로 이 데몬에 신경 쓰지 않아도 된다.
2.3.1 nfsiod: 클라이언트 쪽의 캐쉬를 담당 NFS의 성능을 전반적으로 향상시키기 위해서 대부분의 시스템은 자동으로 nfsiod를 실행하게끔 하고 있다. nfsiod 데몬은 기본적인 캐쉬 기능(read-ahead, write-behind)을 제공한다. 리눅스를 제외한 보통의 시스템에서는 rpc.nfsd처럼 nfsiod도 그 매개변수로 자기 복사본의 수를 몇 개로 할 것인가를 지정한다. Rpc.nfsd에 적용한 규칙을 그래도 nfsiod에 적용할 수 있다. 만약, NFS 서버와 클라이언트의 역할을 동시에 한다면 프로세스의 최적값을 rpc.nfsd와 nfsiod 사이에 적절하게 나누는 것이 좋다. 물론 적절한 값은 시스템에 따라, 그리고 어느 정도로 사용하느냐에 따라 다를 수 있다. 리눅스, BSDI, OSF/1을 제외한 다른 유닉스에서는 nfsiod라는 이름 대신에 biod(block I/O 데몬)라는 이름을 쓰는 것이 일반적이다.
2.4 파일시스템 마운트 설정 커널이 지원해주고 nfsiod 데몬이 실행된다면,
남은 일은 NFS 파일시스템을 마운트해서 쓰는 일 뿐이다. NFS 서버의
파일시스템을 마운트하기 위해서는 mount 명령의 장치(device) 이름을
적는 자리에 다음과 같은 방법으로 NFS서버의 파일시스템을 지정하면
된다.
이 의미는 lily라는 호스트의 /usr/share/man
디렉토리를 의미한다. 따라서, lily라는 호스트의 /usr/share/man
디렉토리를 /usr/share/man 디렉토리에 마운트하려면,
과 같은 명령을 주면 된다. 여기에서 soft,intr 등은 NFS 파일시스템을 마운트할 때 쓰이는 옵션이다. 유닉스 시스템간에 공통된 옵션은 표 4와 같다.
NFS 파티션은 umount 명령을 이용해서 없앨 수 있다.
2.4.1 /etc/fstab을 이용한 설정 mount 명령을 통해 NFS 파일시스템을 마운트
시켰을 경우, 시스템이 재부팅 되면 다시 원래 상태대로 돌아가므로
임시로 마운트 할 때밖에는 쓰이지 않는다. 그러나 보통의 경우
시스템의 영구적인 설정으로 마운트를 하려면 /etc/fstab 파일에
이를 정의하거나 아니면 자동으로 마운트를 관리해주는 자동마운터를
쓰는 게 일반적이다. 다음 /etc/fstab 파일은 lily 호스트의 /lily/users
디렉토리와 daisy 호스트의 /usr/share/man 디렉토리를 마운트하는
예를 보여주는 것이다.
위의 예에서 /etc/fstab 파일의 왼쪽 4번째 항목은 NFS 마운트를 위한 옵션을 지정하는 곳이다. 여기에 쓰이는 옵션은 mount 명령에 쓰였던 옵션(위의 표 ?)과 같다. hard 옵션으로 파일시스템을 마운트한 컴퓨터는 서버가 다운되었을 때 시스템의 프로세스를 더 이상 진행하지 못하고 정지해버린다. 즉, 서버가 다운되었을 때, 클라이언트 마저 멈춰버리는 것이다. 따라서, 일반적으로 soft 옵션과 intr 옵션을 쓰는 것이 NFS와 관련한 여러 골치 아픈 문제를 줄이는 방법이다. 그러나 이 옵션은 약간의 바람직하지 못한 측면도 있다. 이를테면 20시간이 걸리는 시뮬레이션을 돌리고 있는데 사소한 네트워크 장애 때문에 18시간이나 돌린 시뮬레이션이 종료되어버리는 일도 발생할 수 있다. /etc/fstab 파일이 바뀐 것을 즉각 반영해주기 위해서는 mount -a -t nfs 명령을 실행해주면 된다. 그리고, etc/fstab에 항목을 추가할 때는 마운트가 될 디렉토리(mount point)를 미리 만들어줘야 한다.
3. 자동마운터 대규모 네트워크에서는 많은 파일시스템을 마운트해야 하므로 /etc/fstab 파일의 내용이 상당히 복잡해진다. 이로 인해 한꺼번에 많은 파일시스템을 /etc/fstab 파일을 통해 마운트하는 것은 골치 아픈 문제를 불러일으킨다. 첫째, /etc/fstab 파일을 유지 보수하는데 상당한 시간과 노력이 들어간다. 수십 개의 NFS 클라이언트가 있고, 그 각각의 /etc/fstab 파일에 수십 개의 NFS 서버를 나열한다고 생각해보자. 각각의 컴퓨터마다 /etc/fstab 내용이 조금씩 달라야 하기 때문에 하나하나의 /etc/fstab 파일마다 주의를 기울여야 한다. 둘째, 클라이언트가 수십 개 혹은 그 이상의 NFS 파티션을 마운트했을 때, 이 중 하나의 서버만 다운되어도 클라이언트의 프로세스가 완전히 멈춰버릴 수 있다. 셋째, 중요한 서버가 다운되면, 설령 클라이언트까지 다운되지 않더라도, 사용자들이 중요한 파일시스템, 이를테면 /usr/share/man 등을 사용할 수 없게 된다. 이 경우 백업 서버로부터 임시로 파일시스템의 복사 본을 마운트할 수 있어야 하는데, /etc/fstab 파일을 가지고는 이런 경우 대처할 방안이 없다. 자동마운터는 파일시스템이 필요할 때 마운트하고
필요없을 때 마운트를 해제한다. 사용자는 /etc/fstab 파일을 이용한
방법과 아무런 차이를 느끼지 못하지만, 이 방법을 통해 실제 마운트된
파일 시스템의 수를 최소화되고 따라서 문제 발생 가능성 자체를
줄어든다. 대부분의 자동마운터는 중요한 파일서버가 다운되었을
때에도 자동으로 백업서버를 마운트해 계속 작업을 수행할 수 있도록
하는게 가능하다. 자동마운터에 대한 아이디어는 원래 썬에서 나왔다. 썬의 자동마운터인 automount는 대부분의 썬 호환 NFS 시스템에 탑재되어왔다. 그러나 불행하게도 automount는 버그와 디자인 오류 등으로 인해 amd에 비해 기술적으로 많이 떨어진다. 런던 임페리얼 칼리지의 Jan-Simon Pendry에 의해 만들어진 amd는 썬의 아이디어를 확장한 박사학위 논문의 결과이다. amd는 automount의 심각한 결점을 많이 고쳤고 공개이므로 많은 유닉스 버전에 포팅 되었다. 따라서 가능하다면 amd를 쓰는 것을 권장한다.
3.1. amd amd는 automount에 비해 다음과 같은 이점을 가진다. -> amd를 사용하는 클라이언트는 NFS 서버가 다운되는 경우에도 같이 다운되지 않는다. -> amd는 일정한 간격으로 NFS 서버가 살아있는지를
확인하는 메시지를 보내고, -> amd는 소스코드가 공개되어 있어 20개
이상의 유닉스버전에 포팅 되어 있다. -> amd는 텍스트 파일은 물론이고 NIS, Hesiod,
ndbm같은 여러 가지 유형의 데이터베이스 -> amd는 amd에 의한 마운트 상황을 알려주고
여러 가지 유용한 명령 (예를 들면 강제 -> amd 설정파일의 구조는 automount 설정파일의
구조보다 더 일반적이다. -> amd는 개념적으로 일관성 있는 파일시스템
개념을 사용하므로 automount보다
3.2. amd의 설치 amd가 설치되어있지 않은 유닉스 시스템은 인터넷에서
소스코드를 받아와서 컴파일해 설치할 수 있다. Amd를 받을 수 있는
ftp 서버는 ftp://ftp.cs.umn.edu/pub/AMD/나 ftp://ftp.eunet.fr/.01/network/amd/
등 여러 군데가 있다.
3.3 amd의 실행 및 종료 amd의 명령행 옵션은 다양하지만, 주로 다음과
같은 옵션을 써서 실행시킨다.
여기서 -a는 실제 마운트되는 디렉토리를 지정하는
옵션이고 디폴트값은 /a이다. 그리고 -l 다음에는 로그 파일 이름이나
syslog를 써주는데, 에러 메시지를 기록하기 위한 옵션이다. 그
다음 아무런 옵션없이 적어주는 디렉토리는 가상으로 마운트되는
디렉토리를 뜻하고, 마지막에 적어주는 파일 이름은 amd의 설정
파일 이름이 된다. 따라서, 위 명령은 실제 마운트되는 디렉토리가
/.automount이고, syslog에 의해서 로그를 기록하며, 가상으로 마운트되는
디렉토리는 /net, 그리고 amd 설정파일은 /etc/amd.conf로 한다는
뜻이다. 부팅될 때마다 자동으로 수행되게 하기 위해서는
BSD계열 유닉스의 경우 /etc/rc.local 파일에 위의 내용을 추가
하면 된다. AT&T 계열 유닉스에서는 위의 내용으로 /etc/init.d/amd
또는 /etc/rc.d/init.d/amd라는 스크립트를 만들고, 이 스크립트에
/etc, 혹은 /etc/rc.d 디렉토리의 하위디렉토리인 rc2.d나 rc3.d
디렉토리 밑에 S??amd라는 심볼릭 링크를 만들면 된다. 사용자가 amd 설정파일에 정의된 가상 마운트
디렉토리 밑의 파일시스템을 이용하려 하면, amd는 파일시스템을
마운트하고, 사용 상황을 계속적으로 모니터 한다. 마운트한 파일시스템을
일정한 시간이 지나도록 아무도 사용하지 않으면 amd는 마운트를
해제하고 다시 사용될 때를 기다린다.
3.4. amd의 설정 amd 설정파일의 구조는 매우 유연하여 하나의
설정을 가지고 여러 컴퓨터에 사용될 수 있다. amd 설정파일에 나열된
각 파일 시스템은 연관된 마운트 형식을 가지고 있어야 한다. 가장
흔한 마운트 형식이 표 5에 나열되어 있다.
특정한 조건, 이를테면 특정한 호스트나 하드웨어
형태에서만 실행되도록 설정파일을 구성할 수도 있다. 이런 조건은
변수를 사용해서 '{변수명}' 형식으로 표시한다. 이용 가능한 변수는
표 6에 나열되어 있다.
다음은 amd 설정파일의 전형적인 예이다. '이름=값' 같은 형식은 마운트의 다양한 속성을
정의하는데 쓰인다. 예를 들어 첫 번째 행은 디폴트 마운트 옵션을
"rw,soft,timeo=10,retrans=5"로 지정한 것이다. '이름=값' '이름=값' 같은 형식은 조건문을 나타낸다. 조건문의 오른쪽에 적힌 내용은 조건문이 참일 경우에만 쓰인다. ${autodir}이나 ${key} 자리에는 해당 변수값이 들어가게 된다. 이 amd 설정파일은 /usr/man, /cs/tools 두 가지
파일 시스템들에 대해 정의한 것이다. /default 항목은 명시적으로
옵션을 지정하지 않았을 경우 모든 항목에 적용되는 디폴트값을
지정한다. Mad 설정파일에서 쓰이는 옵션은 다음 표 7에 나와 있다.
3.5. 백업서버 지정 automount처럼 amd도 특정 파일시스템에 대해 복수의 서버를 지정하는 것이 가능하다. 그러나 amd는 대부분의 경우에 주서버가 사용중에 다운되더라도 파일시스템의 마운트를 해제하고 곧바로 백업 서버를 마운트할 수 있는 부가적인 능력이 있다. 다음 예제는 /usr/man 디렉토리를 lily와 daisy
두 개의 서버에서 마운트하도록 설정한 것이다.
3.6. 간단한 사용 예 아주 복잡한 마운트도 amd 설정파일을 정의하기에
따라 간단하게 할 수 있다. 한번 다양하게 마운트를 시도해보기
바란다. ls /net 명령을 내리면 /net 디렉토리에는
아무런 파일도
없다는 걸 알 수 있을 것이다. 그러나, ls /net/lily 명령을 내리면 amd가 lily의 파일시스템이 자동적으로 마운트하고, 이 파일시스템 내용을 보여준다. 마찬가지로 ls /net/daisy 명령을 내리면 daisy를 마운트할 수 있다. 그리고, 일정 시간동안 lily나 daisy의 파일시스템을 쓰지 않으면 amd는 자동적으로 마운트를 해제한다. 이런 아주 간단한 설정파일로도 쉽게 수백, 수천 대의 NFS 파일시템을 마운트할 수 있다. 어떤 호스트의 파일시스템을 마운트하고 싶다면, 단순히 /net/[호스트 이름] 디렉토리를 써주기만 하면 되는 것이다.
4. 관리자 관점에서의 NFS
4.1. UID와 GID 네트워크에 있는 NFS 서버에 접근하고자 하는 사용자는 로그인 이름이 반드시 passwd 파일에 있어야 한다. 그리고 더 나가 UID와 GID가 파일시스템을 공유하는 서버와 클라이언트간에 같아야 한다. 일정 규모 이상의 네트워크에서는 UID와 GID를 통일해야 하는 것만큼 머리 아픈 문제가 없다. 백 명의 사용자가 10대의 NFS 서버/클라이언트를 이용한다고 하면 도합 천 개의 passwd 파일 항목의 UID와 GID를 신경 써야 한다는 얘기가 된다. 따라서 이 같은 관리자의 쓸데없는 시간낭비를 줄이기 위해서는 NIS 등을 이용해 전체 사이트의 UID와 GID를 통일하도록 하는 게 좋다.
4.2. 디렉토리 명명 규칙 표준적인 디렉토리 명명규칙을 견지하고 있다면 NFS를 다루기는 조금 쉬워진다. 서버이름을 포함한 디렉토리 명은 좋은 예가 된다. 사용자들이 쉽게 이해할 수 있기 때문이다. 이를테면 lily가 주말에 다운될 것이라는 관리자의 공고를 들은 사용자는 '/lily/share/data라는 디렉토리를 사용할 수 없을 테니 주중에 작업을 끝내고 주말엔 잠이나 자야겠다' 라고 쉽게 생각할 수 있기 때문이다. 클라이언트가 여러 시스템에서 파일시스템을 마운트할 때, 루트 디렉토리에 너무 많은 디렉토리가 생겨 너저분해 보인다면, 좀 더 깊은 계층구조를 만들면 된다. 이를테면 /net/lily/share/man 디렉토리처럼.
4.3. 외부 네트워크와의 NFS 전통적인 NFS는 기반이 되는 트랜스포트 층의 프로토콜로 UDP를 이용한다. NFS가 패킷 정렬과 에러 확인 기능을 가지고 있다 해도 NFS와 UDP 모두 대규모의 IP 네트워크에서 좋은 성능을 보장하는데 필수적인 접속유지기능을 가지고 있진 않다. 이런 이유로 로컬 네트워크가 아닌 라우터를 경유한 컴퓨터끼리의 NFS 마운트, 혹은 WAN 링크를 통한 컴퓨터끼리의 NFS 마운트는 피해야 한다. 라우터나 WAN을 통한 NFS 마운트를 하기 위해서는 UDP 대신에 TCP를 써야 한다. 몇몇 유닉스에서는(OSF/1이나 BSDI를 포함해서) 이미 UDP 대신에 TCP의 위에 NFS의 기능을 구현한 "TCP-NFS"실려있다. 그러나 리눅스는 아직까지 TCP 기반의 NFS를 구현하지는 못하고 있다. 따라서 로컬 네트워크가 아닌 곳의 호스트와의 NFS는 삼갈 것을 권한다.
4.4. 전용 NFS 파일서버 NFS는 접속유지가 없도록(stateless) 설계되었기 때문에 발생하는 성능상의 많은 문제로 고생하고 있다. 보통의 경우 변경된 블록은 유닉스 버퍼 캐쉬에 저장했다가 나중에 한꺼번에 하드디스크에 기록을 하면 되는데 반해, NFS 서버는 쓰기 작업을 할 때마다 반드시 디스크에 변경된 내용을 기록해야 한다. 이런 이유 때문에 NFS 서버에 쓰기 작업을 할 때마다 심각한 지연현상이 발생한다. 그러나, NFS의 대중성에 힘입어 이를 해결하기 위한 많은 제품들이 시장에 나와있다. 어떤 캐쉬 보드는 기존 NFS 서버의 쓰기 지연현상을 해결하기 위해 램디스크 등을 이용해 변경된 블록을 저장하고 쓰기 완료 신호를 클라이언트로 즉시 보내준다. 그리고 변경된 블록은 시스템이 한가할 때 디스크에 기록한다. 이 외에도 전용 NFS 서버를 위한 특수한 하드웨으를 만들어 NFS의 성능을 극적으로 향상시킨 제품도 있다.
4.5. 보안과 NFS NFS는 네트워크 상의 파일에 접근하는 손쉬운
방법을 제공한다. 그래서 심각한 보안 문제를 일으킬 소지를 항상
가지고 있다. 대부분의 사이트에서는 /etc/exports(혹은 /etc/dfs/dfstab)
파일을 적절하게 설정하는 것만으로도 원하지 않는 접근에 대해서
통제할 수 있다. 여하튼, 클라이언트의 루트 사용자를 너무 신뢰하는 것은 좋지 않다. 사용자가 항상 불법으로 루트 권한을 얻을 가능성이 있기 때문이다. 정 안심이 되지 않는다면, 완전히 신뢰하지 못하는 호스트에는 파일을 공유하지 않는 것도 생각해볼 만 하다. 리눅스처럼, portmap에 대한 접근을 제한할 수 있는 시스템의 경우에는 /etc/hosts.deny와 /etc/hosts.allow 파일을 적절하게 설정해서 보안상의 위험을 줄일 수 있다. 예를 들어, 로컬 네트워크의 네트워크 어드레스가 xxx.xxx.xxx.0이고 서브넷 마스크가 255.255.255.0이라면, /etc/hosts.deny 파일의 내용을 'portmap:ALL'이라고 바꾸고 /etc/hosts.allow 파일의 내용을 'portmap:xxx.xxx.xxx.0/255.255.255.0'이라고 바꾸어서 로컬 네트워크 밖에서의 공격을 예방할 수 있다. 그 외에 몇 가지 더 추가한다면, 절대 파일시스템을
localhost나 127.0.0.1에 공유하지 말아야한다는 점, rpc.mountd
데몬에 뻨 옵션을 붙이지 말아야된다는 점을 상기시키고 싶다. 그리고
마지막으로 exports 파일의 옵션이 256자를 넘었을 때 보안에 구멍이
생기는 시스템이 있으므로 이를 주의하라는 점도 노파심에서 말해둔다.
4.6. NFS 모니터링과 튜닝 대부분의 유닉스는 nfsstat이라는 NFS 시스템에
의한 다양한 상태를 볼 수 있는 명령어를 제공한다. nfsstat -s는
NFS 서버 프로세스에 대한 통계치를 보여주고 nfsstat -c는 클라이언트
쪽의 정보를 보여준다. 그러나 아쉽게도 리눅스에는 아직까지 이에
해당하는 명령어가 없는 듯하다. NFS의 성능을 최적화 시키는 또다른
방법은 NFS 서버에서 읽기와 쓰기를 할 때의 버퍼 크기(rsize, wsize)를
조정
하는 방법이 있다. 일반적으로 SunOs와 Solaris의
경우 4096바이트로 정했을 때 가장 빠르다고 한다. 물론 다른 플랫폼에서의
최적 값은 이와 다르게 마련이다. 이 명령은 아무 내용 없는 64메가 파일을 /mnt/testfile이라는
이름으로 만들고 그 시간을 측정하는 명령이다. /mnt 파티션에 NFS
서버의 파일시스템을 마운트하고 실행시켜 보자. 이 때 버퍼사이즈는
1024 바이트의 배수로 변경시켜야 한다.
5. 추천할만한 자료 * Langfeldt, Nicolai, "NFS HOWTO", v0.5, 9 March 1997 * Nemeth, Evi, Snyder, Garth, Seebass, Scott, and Hein, Trent R., "Unix System Administration Handbook", 2nd Ed., Prentice Hall PTR., 1995. * Stem, Hal., "Managing NFS and NIS" O'Reily & Associates, 1992. * Pandry, Jan-Simon and Williams, Nick, AMD: The 4.4 BSD Automounter Reference Manual., "4.4BSD System Manager's Manual", Usenix and O'Reilly. 1994. |