[파일] 네트워크 파일 시스템 ( NFS )

이번에 소개할 내용은 네트워크 파일 시스템(NFS)이다. 유닉스의 강력함을 피

부로 느낄 수 있는 기회가 될 것이다.

양종윤 : 인하 대학교 전자 계산 공학과 전문가 시스템 연구실

97/01 TCP/IP

97/02 네트워크 하드웨어

97/03 도메인 네임 서비스

97/04 네트워크 파일 시스템

들어가며

NFS(Network File System)이란 한 마디로 컴퓨터사이의 파일 시스템 공유를

말한다.

원래 최초 개념은 1985년 썬 사에서 처음으로 소개되었다. 당시에는 하드 디스

크가 없는 클라이언트를 위해 개발한 것이었으나 다른 여러 시스템에도 이식됨

으로써 지금은 모든 유닉스가 채택하고 있다.

이러한 NFS는 마운팅 프로토콜과 서버 그리고 파일 록킹 프로토콜과 서버, 기

본적인 파일 서비스를 조절하는 데몬으로 구성된다.

NFS는 썬 사의 XDR과 RPC 기능 위에 구축되었는데 XDR은 시스템의 하드웨

어 구조에 독립적인 데이터를 표현하는 방법을 제공하며 RPC(Remote

Procedure Call)는 원격 프로시저 콜 인터페이스를 제공한다.

서버쪽의 NFS

BSD 계열은 다른 시스템에서 파일 시스템을 사용하도록 서버가 파일 시스템

을 ‘export’한다라고 이야기한다. 반면 ATT 계열은 ‘share’라는 용어를

사용한다. 앞으로 특별한 경우가 아니면 ‘export’라는 용어를 계속 사용하도

록 하겠다.

언제부터인가 클라이언트 서버 환경이 PC계의 핫 이슈가 되어 왔는데 사실 유

닉스의 입장에서 보면 이미 오래 전부터 이를 구현, 적용해 왔다고 말할 수 있

을 것이다.

지난 호에 공부했던 DNS도 그러하고 이번 호의 NFS도 그러하다. 물론 클라이

언트 서버 환경이라는 용어 자체가 그 범위가 불분명하기에 혹자는 이 말에 동

의하지 않을지도 모르지만 확실한 것은 우리가 배울 NFS는 분명히 서버와 클

라이언트로 구분되어진다는 것이다.

NFS 클라이언트는 네트워크 파일 시스템을 자신의 한 디렉터리로 사용하기

전에 반드시 명시적으로 해당 네트워크 파일 시스템을 마운트 해야 한다.

서버쪽에서는 일단 클라이언트의 마운트 요구가 적합한 것으로 인증되면

magic cookie를 부여하여 클라이언트가 이후에 접근하는 경우 인증 절차 없이

접근 가능하도록 한다.

일단 클라이언트가 magic cookie를 가지면 클라이언트는 서버쪽 데이터 블록

을 읽거나 파일을 생성하는 등의 작업을 하기 위해 RPC를 이용한다.

mountd 데몬

클라이언트 쪽의 마운트 요구는 서버의 mountd 데몬(혹은 rpc.mountd)이 처리

한다. BSD 계열의 시스템의 경우 mou ntd는 ‘/etc/exports’ 파일을 읽어 들

여 어떤 호스트에게 접근 권리가 주어져 있고 어떤 제한을 두는지 등에 대한

정보를 얻는다. export 파일은 접근이 허가되는 디렉터리 리스트를 가장 왼쪽

열에 가지며 연관된 옵션과 속성을 그 오른쪽에 지정한다. 다음은 export 파

일의 예이다.

/users/eslab -access=esrs:hp712, root=esrs

/users/eslab/yjy -access=essdt300:essdt500:hpapollo

제일 첫 라인은 호스트 esrs, hp712에 대해 마운트를 허가한다. 그리고 esrs에

대해서는 루트로 마운트를 하도록 지정한 것이다. 솔라리스는 ‘/etc/exports’

파일 대신에 share 명령어를 사용한다. 다음은 IRIX, HP-UX, SunOS 시스템에

서의 속성을 설명한 것이다.

—————————————————————

속 성 설 명

—————————————————————

-access= 파일 시스템을 마운트 할 수 있도록 허가되는 호스트 목록

호스트리스트

-ro 파일 시스템을 읽기 속성으로만 접근 허가시킴. 어떠한 클라이

어트도 파일시스템에 쓰기 동작을 수행 할 수 없다.

-rw= 지정된 호스트에게 파일 시스템에 쓸 수 있는

호스트리스트 권한을 부여한다. 지정된 호스트 외에는 파일 시스템을 읽기만

할 수 있다.

-root= 파일 시스템에 루트 권한으로 접근 가능한

호스트리스트 호스트의 목록을 지정한다. 이 옵션 지정이 없으면 클라이언트

의 루트로 접근하더라도 nobody 사용자(UID -2)로 접근하게

된다.

-anon= 알려지지 않은 사용자로부터의 요구를 처리하기

사용자ID 위한 UID지정. 디폴트는 nobody이다.

—————————————————————

속 성 설 명

—————————————————————

호스트명 파일 시스템을 마운트 할 수 있도록 허가되는 호스트명

-ro 파일 시스템을 읽기 속성으로만 접근 허가시킴. 어떠한 클라이어

트도 파일시스템에 쓰기 동작을 수행 할 수 없다.

-root= 클라이언트의 루트로부터의 접근 요구를 처리하기

사용자 ID 위한 UID지정. 디폴트는 nobody이다.

—————————————————————

위는 BSDI, OSF/1에서의 속성을 나타낸 것이다.

만약 exports 파일에 특정 호스트의 지정 없이 디렉터리만을 나열한 경우 모든

호스트에 대해 접근 허가를 내어주는 것이 된다.

이는 보안상 큰 문제가 될 수 있으므로 상당히 유의해야 할 부분이다.

‘/etc/exports’ 파일을 수정한 후에는 mountd 데몬이 이를 다시 읽도록 해야

하는데 이 방법이 시스템마다 다소 차이가 있어 다음에 표로 나타내었다.

—————————————————————

시스템 필요한 동작

—————————————————————

Solaris 본문 참고

HP-UX “/usr/etc/exportfs -a” 수행

IRIX {“/usr/etc/exportfs -a” 수행

SunOS “/usr/etc/exportfs -a” 수행

OSF/1 kill 명령으로 mountd 데몬에게 SIGHUP 시그널을 보냄

BSDI kill 명령으로 mountd 데몬에게 SIGHUP 시그널을 보냄

—————————————————————

솔라리스는 ‘/etc/exports’파일 대신 ‘/etc/dfs/dfstab’ 파일을 읽는다.

사실 이 파일은 share 명령을 수행하는 셸 스크립트로서 다음은 그 예를 하나

보인 것이다.

#!/bin/sh

share -F nfs -o rw=esrs:hp712, root=esrs /users/eslab

share -F nfs -o rw=essdt300:

essdt500:esapollo /users/eslab/yjy

다음은 share 명령에서 사용되는 속성을 나타낸 것이다.

—————————————————————

속 성 설 명

—————————————————————

-ro 파일 시스템을 읽기 속성으로만 접근 허가시킴. 만약 “-ro=호스

트리스트” 형태로 지정하면 특정 호스트에만 읽기 접근 권한을

줄 수도 있다.

-rw 지정된 호스트에게 파일 시스템에 쓸 수 있는 권한을 부여한다.

만약 ‘-rw=호스트리스트’ 형태로 지정하면 특정 호스트에만

쓰기 접근 권한을 줄 수도 있다.

-root= 파일 시스템에 루트 권한으로 접근 가능한 호스트의 목록을 지

호스트리스트 정한다. 이 옵션 지정이 없으면 클라이언트의 루트로 접근하더

라도 nobody 사용자(UID -2)로 접근하게 된다.

-anon= 알려지지 않은 사용자로부터의 요구를 처리하기 위한 UID지정.

사용자ID 디폴트는 nobody이다.

—————————————————————

nfsd – 클라이언트의 동작 처리

일단 클라이언트의 마운트 요구가 mountd 데몬에 의해 처리되면 클라이언트의

파일 시스템으로의 특정 작업에 대한 요구를 서버쪽에서 처리해야 되는데 이를

nfsd 데몬이 수행한다. nfsd는 수행시 한 개의 인자로 각 요구마다 fork할 자기

자신의 복사본의 개수를 지정한다.

이 개수는 시스템의 성능과 밀접한 관련을 가지게 되므로 매우 중요하다.

우선 최소 4개 이상은 지정해야 한다. 그래야 어느 정도 속도로 동작이 가능해

지기 때문이다. 반면 너무 많은 수는 시스템이 다른 작업을 수행하는데 큰 부

하가 걸리게 되는 것이다. 다음은 어느 정도 적당한 nfsd 수를 나타낸 것이다.

참조하기 바란다.

시스템 프로세서 nfsd 개수 시스템 프로세서 nfsd 개수

Solaris SPARK 10 HP-UX PA-RISC 8

superSPARK 12 IRIX MIPS R-4000 10

SunOS SPARK 10 OSF/1 DEC Alpha 8

SuperSPARK 12 BSDI 80486 8

클라이언트쪽의 NFS

어떤 시스템이 NFS를 지원한다면 우선 mount 명령이 다음의 형식을 이해할

수 있어야 한다.

▶ 호스트명:디렉터리

그리고 클라이언트는 서버쪽에 자신이 마운트하고자 하는 파일 시스템을 알려

주면 된다.

우리가 알아야 할 것은 클라이언트쪽이 자신이 마운트하고자 하는 파일 시스템

을 어떻게 지정하는지에 대해 알면 될 것이다. 원래 클라이언트쪽에는 따로 데

몬이 동작할 필요가 없는데 요즈음의 대부분 시스템에서는 NFS의 성능향상을

위해 biod(block I/O daemon)이라는 데몬을 구동시킨다. BSDI와 OSF/1에서는

nfsiod라 한다.

biod의 역할은 한마디로 ‘read-ahead, write-behind’로서 쉽게 이야기해서

디스크 캐싱과 같은 역할을 하는 것이다.

nfsd처럼 biod 또한 시작할 때 자신의 복사본의 개수를 지정하는데 nsfs와 거

의 마찬가지로 생각하면 된다.

원격 파일 시스템의 마운트

원격 파일 시스템의 마운트는 보통 ‘/etc/fstab’파일에 엔트리를 두어 자동으

로 부트될 때 마운트하도록 하거나 amd와 같은 자동 마운트 프로그램을 이용

하기도 한다.

다음은 ‘/etc/fstab’의 한 예이다.

nfsserver:/users/eslab /nfs/eslab nfs rw,bg,intr,hard 0 0

esrs:/usr/man /esrs/man nfs ro,bg,intr,soft 0 0

첫 번째 열은 마운트하고자 하는 호스트 서버와 그 디렉터리를 지정한다.

두 번째 열은 자신의 시스템에서의 마운트 포인트이다.

세 번째 열은 NFS로 마운트할 것을 지정한다.

네 번째 열은 기타 속성을 나타낸다.

수정된 ‘/etc/fstab’파일이 적용되도록 하려면 다음과 같은 명령을 수행한다.

mount -a -t nfs

다음은 네 번째 열에 쓰이는 속성에 대해 설명한 표이다.

일반적으로 soft와 intr 옵션은 NFS관련된 시스템의 성능저하를 상당히 감소시

킨다.

만약 마운트를 해제하려한다면 umount 명령을 사용한다.

—————————————————————

플래그 설 명

—————————————————————

rw 파일 시스템을 읽기, 쓰기로 마운트한다.

ro 파일 시스템을 읽기 모드로 마운트한다.

bg 만약 마운트가 실패하면 즉 서버가 응답이 없는 경우 백그라운

드 프로세스로 그 작업을 계속하면서 다른 마운트 요구를 계속

수행한다.

hard 만약 서버가 다운되면 서버가 다시 동작할 때까지 그 파일 시스

템 접근하려는 동작을 블록킹한다.

sof 만약 서버가 다운되면 서버가 그 파일 시스템 접근하려는 동작

에 대해 fail시키고 에러를 리턴한다. 이것은 불필요한 마운트에

대해 쓸데없는 프로세스의 생성을 피하는데 유용하다.

spongy hard 마운트와 유사하다. 차이는 stat, lookup, fsstat, readlink,

readdir동작에 대해서만은 soft 마운트와 같이 행동한다.

retrans=n soft 마운트된 파일 시스템에 대해 에러를 돌려주기 전까지 요

구를 반복할 횟수를 지정한다.

timeo=n 요구에 대한 timeout 시간을 지정한다.

intr 사용자가 블록된 작업에 대해 인터럽트를 걸어 그 작업들이 풀

려서 에러를 돌려주도록 한다.

resize=n 읽기 버퍼 크기를 n 바이트로 지정

wsize=n 쓰기 버퍼 크기를 n 바이트로 지

—————————————————————

NFS의 관리

NFS는 내부적으로 TCP/IP 구조에서 UDP를 사용한다.

이 말은 네트워크에서의 성능과 밀접한 관련이 있는 부하조절을 하지 못한다

는 이야기이다.

이러한 이유로 해서 BSDI나 OSF/1과 같은 시스템에서는 TCP-NFS를 구현

해 사용하고 있다.

사실 NFS의 가장 큰 문제는 성능에 관한 것이므로 NFS전용의 호스트를 운영

하는 것도 이를 만회하기 위한 한 방편일 수도 있다.

자동 마운트

‘/etc/fstab’파일에 NFS 마운팅 정보를 관리하는 것은 네트워크가 커질수록

그 어려움은 기하급수적으로 늘어난다.

또 한가지 문제는 그 중 한 호스트가 다운되었을 때이다. 만약 다운된 호스트

가 매우 중요한 호스트라면 그 문제는 더욱 심각해 진다.

자동 마운트 데몬은 NFS를 참조할 때 마운트해 주고 더 이상 필요가 없어지

면 자동으로 마운트 해제를 수행한다.

이러한 자동 마운트의 개념은 썬 사에서 처음 나왔다. 그래서 썬 시스템에서는

자동 마운트를 automount로 구현했는데 많은 버그와 디자인 오류로 amd 프로

그램이 더 널리 사용되고 있다.

amd는 런던의 Imperial College의 Jan-Simon Pendry라는 사람이 만들었는데

썬의 아이디어를 확장한 것이다. 또한 썬의 automount의 버그와 디자인 오류

를 대폭 수정하여 현재 많은 유닉스 시스템에서 사용되고 있다.

썬의 ‘automount’

automount는 여러 개의 컨피그 파일을 읽어들인다. 흔히 이 컨피그 파일들을

맵(Map)이라 부른다. 종류로는 직접(direct) 맵, 간접(indirect) 맵, 마스터 맵이

있다.

직접 맵과 간접 맵은 자동 마운트될 파일 시스템에 대한 정보를 제공한다. 마

스터 맵은 automount가 참조할 직접 맵과 간접 맵의 리스트이다.

마스터 맵 없이 직접 맵들을 지정해 수행시킬 수도 있다.

간접 맵

간접 맵은 공통의 디렉터리 밑에 존재하는 파일 시스템을 지정할 때 사용한다.

지정하는 형식은 다음과 같다.

users esrs:/users/eslab

devel esrs:/users/eslab/yjy

info -ro esrs:/users/eslab/info

첫 번째 열은 각 automount가 인스톨 되어야하는 서브 디렉터리를 지정한다.

두 번째 열은 마운트 옵션이고 세 번째 열은 마운트하고자 하는 파일 시스템의

경로이다.

직접 맵

직접 맵은 공통의 디렉터리가 존재하지 않아 전체 경로를 써 주어야 할 때 사

용한다.

지정하는 형식은 다음과 같다.

/usr/man esrs:/users/man

/cs/tool hp712:/users/eslab/cs/tool

마스터 맵

마스터 맵은 직접 맵과 간접 맵의 리스트를 가진다.

다음은 그 예이다.

#directory map

/esrs /etc/auto.esrs

/- /etc/auto.direct

첫 번째 열은 간접 맵에 대한 디렉터리 이름이다. ‘/-’이 쓰인 경우는 직접

맵을 의미한다. 두 번째 열은 각 맵의 파일명이다.

만약 마스터 맵이 ‘/etc/auto.master’라면 다음과 같이 automount를 수행한

다.

automount -f /etc/auto.master &

혹은 직접 맵을 지정할 수도 있다.

automount /- /etc/auto.direct /esrs /etc/auto.esrs

AMD – 더 낳은 자동 마운트 프로그램

amd는 앞에서 설명한 바와 같이 썬의 automount를 개량한 것이다.

무엇이 좋아졌는지 살펴보자

1. 원격 시스템이 죽어도 절대 아무일도 하지 않고 수행중인 상태로 떠 있지

않는다.

2. 수시로 원격 서버로 질의를 보내고 접근 가능한 서버 목록을 보관한다.

3. union과 같은 여러 타입을 지원한다.

4. 맵이 여러 데이터베이스 형태로 저장 가능하다.

5. amq라는 관리 툴을 포함하고 있다.

6. 맵 문법이 훨씬 일반적이다.

이 외에도 상당히 많은 부분이 보완되었다.

다음은 amd의 맵에서 사용되는 마운트 타입을 설명한 것이다.

타 입 설 명

nfs NFS 서버에 기본적인 접근을 허용

ufs 지역 파일 시스템에 기본적인 접근을 허용

host NFS 서버의 전체 export 트리에 대한 접근 허용(서버의 mountd에

게 export 리스트를 얻기 위해 질의 되어짐)

nfsx NFS서버의 파일 시스템 그룹의 접근 허용

program 마운트 혹은 마운트 해제가 요청될 때마다 프로그램을 수행

link 물리적 마운트 포인트를 가리키는 심볼릭 링크를 생성

auto 현재 있는 자동 마운트 포인트 밑에 새로 생성

direct automount의 직접(direct) 맵과 동일

union 하나의 디렉터리로 여러 디렉터리를 접근 가능

다음은 amd의 실렉터들에 대해 설명한 것이다.

실렉터 값

arch 현재 시스템의 구조

autodir 파일 시스템을 마운트할 디폴트 디렉터리

byte CPU의 바이트 배열순서(little, big)

cluster 시스템의 지역 클러스터 이름(디폴트는 domain)

domain 지역 NIS 도메인 이름

host 지역 호스트 이름

hostd 지역 도메인 이름과 결합된 호스트 이름

karch 커널 구조

map 현재 사용되는 마운트 맵의 이름

os 운영체계

wire 첫 번째 인터페이스가 부착될 네트워크 이름

다음은 amd 맵의 예이다.

/default opts:=rw,soft,timeo=10,retrans=5

/usr/eslab/man host==esrs;type:=ufs;dev:=/dev/sd1f

host!=esrs;rhost=esrs;rfs:=/${key};

type=nfs;fs:=${autodir}/${key}

/usr/eslab/cs/tool host==hp712;tpe:=ufs;dev:=/dev/sd3c

host!=hp712;rhost=anchor;rfs:=/${key};

type=nfs;fs:=${autodir}/${key}

‘이름:=값’의 형태는 마운트할 때의 옵션을 지정한다.

‘이름==값’ 혹은 ‘이름!=값’은 조건을 나타낸다.

${autodir}나 ${key}같은 표현은 적당한 실렉터의 추가를 나타낸다.

다음은 맵에서의 옵션을 설명한 것이다.

옵션 설 명 옵션 설 명

rhost volumn이 상주할 원격 호스트 rfs 원격 파일 시스템 이름

type 마운트 타입 fs 지역 마운트 포인트

amd를 수행시키고자 하는 경우는 다음과 같은 스크립트 파일을 작성하면 된

다.

#!/bin/csh -f

cd /usr/local/etc/amd

exec /usr/local/bin/amd -x fatal,error,user -r -l syslog

-a /tmp_mnt /amd amd.master.map >& /dev/console

다음은 명령행 옵션을 설명한 것이다.

옵 션 설 명

-x 수행시의 로깅 세트

-r 현재 마운트를 그대로 채택한다.

-l 로그 파일을 지정하거나 syslog을 지정

-a 부가적인 마운트 포인트를 지정

/amd 디렉터리 맵 이름을 지정

amd.master.map 마운트 옵션을 포함하는 파일을 지정

NFS의 튜닝과 모니터링

대부분의 시스템이 nfsstat명령을 제공한다. 이 명령을 이용하면 NFS를 모니터

링할 수 있는데 ‘nfsstat -s’ 명령은 NFS의 서버동작에 대한 통계를 보여준

다. ‘nfsstat -c’ 명령은 클라이언트쪽 동작에 대한 정보를 보여준다.

다음은 명령의 사용 예이다.

[eslab:/]# nfsstat -c

Client rpc:

calls badcalls retrans badxid timeout wait newcred timers

64235 1595 0 3 1592 0 0 886

Client nfs:

calls badcalls nclget nclsleep

62613 3 62643 0

null getattr setattr root lookup readlink

0% 34% 0% 21% 30% 0%

read wrcache write create remove rename

2% 3% 0% 0% 0% 0%

link symlink mkdir rmdir readdir fsstat

0% 0% 0% 60% 0% 0%

[eslab:/]# nfsstat -s

Server rpc:

calls badcalls nullrecv badlen xdrcall

725 0 0 0 0

Server nfs:

calls badcalls

725 0

위의 예는 상당히 좋은 상태의 NFS이다.

모니터링에서 중요한 항목은 우선 쓰기 퍼센트이다. 만약 이 정도가 10%를 넘

기면 전용의 NFS 호스트를 두어야할 필요가 있다. 그리고 타임아웃이 3% 이

상이면 NFS의 서버나 혹은 네트워크에 문제가 있는 것으로 보면 될 것이다.

이러한 문제들의 부분적인 해결책은 읽기, 쓰기 버퍼의 크기를 작게 낮추는 것

이다.

다른 파일 공유 시스템

RFS

System V.3와 그 이후 버전에서 사용되었던 파일 공유 시스템인데 NFS와 비

슷하나 성능도 떨어지고 그다지 많이 사용되지 않고 있다.

Andrew Filesystem

AFS는 카네기 멜론 대학(CMU)에서 개발한 것으로 Transarc Corp.에서 상업

화하였다. 현재는 미국 동부 해안의 대학들 사이에서 사용되고 있다.

어떤 면에서 NFS보다 나은 점을 가지는데 클라이언트쪽의 캐싱이 그렇고 공

통의 파일 시스템 namespace 등의 진보적 개념도 포함하고 있다.

하지만 상업적으로 널리 쓰이지 않고 있어 이기종간에서는 제대로 서비스되고

있지 않은 것이 흠이다.

마치며

이번 달에는 네트워크 파일 시스템에 대해서 다루었다.

NFS는 보안과 성능에 대한 문제만 제대로 해결된다면 사용자에게는 더 편리

한 환경을 제공하며 관리자 입장에서는 자원의 공유란 입장에서 매우 바람직하

다. 무엇보다도 중요한 것은 시스템 관리자의 일관된 정책이다.

처음에 시스템을 분석, 그 목적을 정한 후 이에 맞게 시스템을 튜닝해 놓으면

오랜 기간을 변경 없이 사용하다가 큰 변화가 있을 때 전체적으로 시스템을 재

분석하여 다시 튜닝하는 것이 사용자나 관리자 입장에서도 유지, 보수에 수월

할 것이다.

다음 호에는 시스템 파일의 공유에 대해 공부하기로 하겠다.

필자 연락처：HiTEL-huclons

천리안 – huclons

—

nirvana