[RedHat] NFS 서버 버전 관리 가이드

  

RHEL 기반 NFS 서버의 버전 설정 및 마운트 시 버전 지정 방법을 실습과 함께 상세히 설명합니다.

 

NFS 버전 관리: 서버와 클라이언트에서의 버전 지정 방법

이전 글에서는 RHEL에서 NFS 서버를 구성하고 클라이언트에서 디렉터리를 마운트하는 과정을 살펴봤습니다. 이번 글에서는 NFS의 버전 관리를 중심으로, 어떤 방식으로 버전이 협상되는지, 그리고 서버와 클라이언트에서 각각 버전을 어떻게 제어할 수 있는지 구체적으로 설명합니다.


NFS 버전 협상 방식

NFS를 사용할 때 특별한 버전 지정이 없으면, 클라이언트는 자신이 지원하는 가장 높은 버전부터 마운트를 시도합니다. 서버와 클라이언트 간에 호환 가능한 최고 버전이 자동으로 선택되며, 협상에 실패하면 차선 버전으로 재시도하게 됩니다.

예를 들어, RHEL 6.9 및 7.1의 man nfs 문서를 보면 다음과 같은 동작 방식을 확인할 수 있습니다.

== RHEL6.9 ==

nfsvers=n      The  NFS  protocol version number used to contact the server’s NFS service.  If the server does not support the requested ver-
sion, the mount request fails.  If this option is not specified, the client negotiates a suitable  version  with  the  server,
 trying version 4 first, version 3 second, and version 2 last.

== RHEL7.1 ==

nfsvers=n      The  NFS  protocol  version number used to contact the server's NFS service.  If the server
does not support the requested version, the mount request fails.  If  this  option  is  not
specified,  the  client  negotiates  a  suitable  version with the server, **trying version 4**
first, version 3 second, and version 2 last.

RHEL 6.9와 7.1 두 버전의 man 페이지를 확인해 보면, 두 버전 모두 NFS 4버전을 최신 지원 버전으로 채택하고 있으며, 이전 버전인 NFS 2와 3도 함께 지원하고 있습니다. 이 정보는 NFS 연결 시 중요한 의미를 갖습니다. 예를 들어, 클라이언트가 RHEL 7.1을 사용하고 있다고 가정해 봅시다. 이 경우, 서버에서 NFS 4.1과 같은 더 높은 버전을 지원하더라도 실제 연결은 이루어질 수 없습니다. 그 이유는 클라이언트의 최대 지원 버전이 NFS 4로 제한되어 있기 때문입니다.

결과적으로, NFS 연결 시 실제로 사용되는 버전은 항상 서버와 클라이언트가 공통으로 지원하는 버전 중 가장 높은 것으로 결정됩니다. 이러한 메커니즘은 시스템 간 호환성을 보장하면서도 가능한 최신 기능을 활용할 수 있게 해주는 중요한 역할을 합니다.

아래 RHEL 7.6 버전을 보면 NFS 4.1 버전 부터 협상을 시도한다는 내용이 확인됩니다.

== RHEL7.6 ==

nfsvers=n      The NFS protocol version number used to contact the server's NFS service.  If the server does not support the requested version, the mount
request fails.  If this option is not specified, 
the client tries version 4.1 first, then negotiates down until it finds  a  version  sup
ported by the server.

각 커널마다 지원하는 NFS 버전이 다르다는 점은 주목할 만한 사항입니다. NFS 마운트의 자동 협상 방식은 이러한 다양한 버전 환경에서 사용자들에게 큰 편의를 제공합니다. 마운트 시 버전을 일일이 신경 쓰지 않아도 되는 점입니다.

다만 이런 편리한 기능도 단점이 존재하기 마련인데요. NFS가 버전이 업데이트되면서 각종 버그 픽스 와 성능 향상이 이루어졌지만 어떤 제품이든 업데이트를 지속할수록 버전 간의 호환성 문제는 존재하게 됩니다. NFS v3과 v4  사이에서 종종 문제가 발생하곤 합니다. 예를 들어, v3만을 지원하던 프로그램이 시스템 업데이트나 마이그레이션 등 어떤 이유로 인해 v4로 마운트 되어 장애가 나는 경우를 가끔 볼 수 있습니다.

 

NFS 버전 지정

NFS를 사용할 때 가장 중요한 것은 현재 사용 중인 NFS가 어떤 버전으로 마운트 되어 있는지, 그리고 어떻게 버전을 변경할 수 있는지 확인하는 능력입니다.

NFS 버전은 마운트 시점에 결정되며, 서버와 클라이언트가 지원하는 최신 버전으로 선택된다고 앞서 설명드렸습니다. 따라서 버전을 지정하는 방법은 서버 측과 클라이언트 측 양쪽에서 모두 가능합니다. 예를 들어, v3 버전을 사용해야 하는 상황이라면 서버에서 v4를 비활성화하고 v3만 활성화하면 됩니다. 이 경우 클라이언트가 어떤 시도를 하더라도 v3만 사용할 수 있게 됩니다. 하지만 이 방법에는 단점이 있습니다. 서버에서 여러 디렉터리를 호스팅하고 있을 때, v4를 사용하고 싶은 다른 클라이언트에게는 문제가 될 수 있기 때문입니다. 이러한 이유로 대부분의 경우에는 클라이언트에서 마운트할 때 버전을 지정하는 방법을 많이 사용합니다. 이 방법이 더 유연하고 개별 클라이언트의 요구사항을 충족시키기 쉽기 때문입니다.

서버에서 특정 NFS 버전을 비활성화하는 방법과 클라이언트에서 버전을 지정하는 두 가지 방법을 자세히 살펴보도록 하겠습니다. 이 두 가지 방법을 이해하면 다양한 상황에서 NFS 버전을 효과적으로 관리할 수 있을 것입니다.

 

환경

Red Hat Enterprise Linux 7

Red Hat Enterprise Linux 8

Red Hat Enterprise Linux 9

 

NFS 서버에서 4버전 비활성화하기

서버 측에서 특정 NFS 버전을 제한하고자 할 경우, 설정 파일을 수정해 원하는 버전만 활성화할 수 있습니다. 아래는 RHEL에서 NFSv4를 비활성화하고 NFSv3만 허용하는 절차입니다.

# systemctl start nfs-server


1. 현재 NFS 서버 버전 확인하기

[root@server ~]# cat /proc/fs/nfsd/versions
-2 +3 +4 +4.1 +4.2

위 결과에서 "+" 기호는 지원되는 버전을, "-" 기호는 지원되지 않는 버전을 나타냅니다. 위 예시에서는 NFSv2를 제외한 모든 버전이 활성화되어 있습니다.

 

 

2. NFS 설정 파일 수정하기

NFSv4를 비활성화하려면 NFS 설정 파일을 수정해야 합니다

[root@server ~]# vim /etc/nfs.conf
...
[nfsd]
...
# vers3=y
# vers4=y
# vers4.0=y
# vers4.1=y
# vers4.2=y
 vers4=n
 vers4.0=n
 vers4.1=n
 vers4.2=n
...

[nfsd] 섹션에서 위와 같이 vers4 관련 항목을 모두 'n'으로 설정합니다.

 

 

3. NFS 서비스 재시작

변경사항을 적용하기 위해 NFS 서비스를 재시작합니다.

[root@server ~]# systemctl restart nfs-server

 

4. 변경 사항 확인하기

NFSv4가 비활성화되었는지 다시 확인합니다:

[root@server ~]# cat /proc/fs/nfsd/versions
-2 +3 -4 -4.0 -4.1 -4.2

이제 NFSv3만 활성화된 것을 확인할 수 있습니다.

 

5. 마운트 테스트

NFSv4버전을 비활성화 한 서버에 마운트를 진행해 봅니다.

[root@client ~]# mount -t nfs 192.168.155.145:/test /test

[root@client ~]# mount | grep test
192.168.155.145:/test on /test type nfs (rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.155.145,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=192.168.155.145)

마운트 상태를 확인하면 다음과 같이 NFSv3로 마운트 된 것을 볼 수 있습니다.

 

 

주의: 서버에서 NFSv4를 비활성화한 상태에서 클라이언트가 vers=4.1을 명시하면 마운트에 실패합니다.

# mount -t nfs -o vers=4.1 192.168.155.145:/test /test
mount.nfs: Protocol not supported

 


클라이언트에서 마운트 버전 변경

서버에서 모든 클라이언트에 대해 특정 NFS 버전을 강제하는 것은 제한적일 수 있습니다. 대신, 클라이언트 단에서 필요한 버전을 직접 지정하는 방식이 더 유연하게 사용됩니다. 이는 특히 서로 다른 애플리케이션 요구사항을 가진 환경에서 유용합니다.

 

방법 1:  mount 명령어 사용 (일시적)

  • NFSv4.1버전으로 마운트 하고 싶은 경우 아래와 같이 옵션에 버전을 지정합니다.
[root@client ~]# mount -t nfs -o vers=4.1 192.168.155.145:/test /test

[root@client ~]# mount | grep test
192.168.155.145:/test on /test type nfs (rw,relatime,vers=4.1,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.155.145,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=192.168.155.145,_netdev)
  • NFSv3버전 마운트 역시 마찬가지 입니다.
[root@client ~]# mount -t nfs -o vers=3 192.168.155.145:/test /test

[root@client ~]# mount | grep test
192.168.155.145:/test on /test type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.155.145,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=192.168.155.145,_netdev)

 

방법 2: /etc/fstab 사용 (영구적)

시스템 재부팅 후에도 마운트를 유지하려면 /etc/fstab에 버전을 명시합니다.

# man nfs
...
       vers=n         This option is an alternative to the nfsvers option.  It is included for compatibility
                      with other operating systems
...
  • fstab 설정에서는 vers 옵션을 이용해 원하는 버전을 지정합니다.
# vi /etc/fstab
...
192.168.155.145:/test   /test                   nfs     defaults,vers=3         0 0
...
  • 설정 후에는 마운트 테스트를 진행합니다.
[root@client ~]# mount /test
  • 확인
[root@client ~]# mount | grep test
192.168.155.145:/test on /test type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.155.145,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=192.168.155.145,_netdev)

이렇게 NFS 클라이언트에서 마운트 버전을 변경하는 방법을 알아봤습니다. 일시적으로 할 때는 mount 명령어를, 영구적으로 설정하고 싶을 때는 fstab을 사용하면 됩니다. 환경에 맞게 적절히 선택해서 사용할 수 있습니다.

 

마치며

RedHat 환경에서의 NFS 서버 버전 관리에 대해 자세히 살펴보았습니다. NFS 버전 할당 방식부터 시작해 각 커널 별 지원 버전, 그리고 실제 버전 지정 방법까지 다루었습니다. 특히 NFS v3와 v4 사이에서 발생할 수 있는 문제점들을 인지하고, 이를 해결하기 위한 방법들을 살펴보았습니다. 중요한 점은 우리가 사용하는 NFS의 버전을 정확히 알고, 필요에 따라 버전을 변경할 수 있는 능력입니다.

실무에서는 대부분 클라이언트에서 마운트 시 버전을 지정하는 방법을 선호합니다. 이는 서버의 다양한 클라이언트 요구사항을 충족시키면서도 유연성을 제공하기 때문입니다.


댓글

댓글 쓰기

이 블로그의 인기 게시물

[Linux] RHEL Local YUM Repository 구성

이미지
RHEL(Redhat Enterprise Linux)에 Local YUM Repository 구성하는 방법에 대하여 설명합니다. 레드햇 리눅스 같은 경우 기업환경의 인터넷이 되지 않는 환경에서 사용되는 경우가 많은데 Local YUM Repository를 구성하여 패키지를 쉽게 설치할 수 있습니다.   테스트 환경 • Red Hat Enterprise Linux (RHEL)   Local YUM Repository 구성 목적 Local YUM Repository를 구성하는 방법에 여러 가지가 있지만 가장 간단한 방법인 설치 CD를 이용해 구성하는 방법에 대해 소개합니다. 주로 이 방법은 OS 엔지니어가 RHEL을 설치 후 사용하며, local repo를 서버에 구성한 뒤 철수합니다. 그러면 애플리케이션 측에서 추가 패키지를 요청하여도 서버 관리자분들이 yum 명령어를 사용하여 쉽게 서버에 설치할 수 있습니다.   Local YUM Repository 설정 레드햇 설치 CD에는 기본 RHEL 서브스크립션에서 제공하는 RPM 패키지들이 모두 포함되어 있습니다. 따라서 RHEL을 설치한 버전과 동일한 ISO 파일 이 준비되어 있어야 하며, 이를 통해 로컬 저장소를 구성할 수 있습니다.   VMware Workstation을 기준으로 설명하자면, RHEL ISO 파일을 가상 머신에 마운트 하면 됩니다. ISO 파일이 마운트되면 시스템은 자동으로 /dev/sr0 장치를 생성하게 되며, 이는 udev 에 의해 처리됩니다.   CD가 삽입되면 시스템에서는 /dev/sr0 장치를 자동으로 생성합니다. 이 장치는 **광학 디스크 장치(CD/DVD)**로 인식되며, 이를 확인하는 가장 쉬운 방법은 lsblk 명령어를 사용하는 것입니다. # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 2G 0 disk └─mpatha ...
자세한 내용 보기

[Linux Command] sudo command 설명

이미지
  이번 글에서는 Linux 명령어 중 sudo 명령어에 대해 알아보겠습니다. 일반 사용자에게 "root" 권한을 부여하려면 보통 root 계정의 비밀번호를 제공해야 합니다. 이후 사용자는 su 명령어를 통해 root 계정으로 로그인할 수 있습니다. root 계정은 시스템 내 모든 명령을 실행할 수 있는 강력한 권한을 가지고 있기 때문에, 신중한 관리가 필요합니다. 리눅스에 익숙하지 않은 사용자가 root 권한을 사용할 경우, 시스템 운영에 필요한 핵심 파일이 삭제되거나 권한 설정이 변경되는 등의 사고가 발생할 수 있습니다. sudo 기능을 사용하면 root 전체 권한이 아닌 특정 명령어만 일반 사용자에게 허용할 수 있어 이러한 위험을 줄일 수 있습니다. 또한, 사용 권한은 부여하되 root 비밀번호를 공개하지 않아도 된다는 점도 sudo 의 중요한 장점 중 하나입니다.   환경 : Red Hat Enterprise Linux (RHEL)   sudo command 개념 명령어 사용법을 보기 전에, sudo 명령어로 어떤 작업이 가능한지 먼저 알아보겠습니다. 일반 사용자가 /etc/shadow 파일을 열려고 하면 권한 부족으로 인해 파일을 열 수 없습니다. 아래는 실제 출력 예시입니다. 일반유저로 shadow파일 오픈 실패 [user1@localhost ~]$ cat /etc/shadow cat: /etc/shadow: Permission denied 또한 mount 명령어도 일반 사용자 권한으로는 실행할 수 없습니다. 일반 유저로 mount 명령 실패 [user1@localhost sbin]$ mount /dev/sr0 /media mount: only root can do that 이제 일반 사용자에게 mount 명령어만 sudo 를 통해 root 권한으로 실행할 수 있도록 설정해보겠습니다. [user1@localhost ~]$ sudo mount /dev/...
자세한 내용 보기

[Ansible Modules] Fetch module 설명 및 활용

이미지
  Ansible modules 중 하나인 Fetch module에 대해 알아보겠습니다. Fetch는 관리 대상 노드에서 제어 노드로 파일을 복사해 오는 데 사용되는 모듈입니다 Fetch module 이란 Fetch는 영어로 "가져오다"라는 의미입니다. Ansible의 copy 모듈과 반대로 동작하는 기능으로, copy 가 제어 노드에서 관리 노드로 파일을 전송하는 데 사용된다면, fetch 는 그 반대 방향으로, 관리 대상 노드의 파일을 제어 노드로 복사해 오는 데 사용됩니다. 여기서 제어 노드(control node)는 Ansible을 실행하는 노드를, 관리 노드(managed node)는 Ansible로 관리되는 대상 시스템을 의미합니다. Ansible modules(fetch_module) Fetch module 옵션   fetch 모듈에서 주로 사용되는 주요 옵션은 다음과 같습니다: src : 관리 대상 노드에서 복사해 올 파일의 경로입니다. dest : 제어 노드에 파일을 저장할 경로입니다. flat (기본값: false ) false : {{ inventory_hostname }}/path/to/file 형태의 디렉토리 구조로 파일이 저장됩니다. 호스트별로 디렉토리가 생성되므로 여러 노드에서 같은 파일 경로를 가져올 때 유용합니다. true : 파일 경로 구조 없이 파일만 단순 복사됩니다. 이름이 같은 파일은 덮어써지기 때문에, 관리 노드가 하나이거나 파일명이 충돌하지 않는 경우에 적합합니다. 또한 디렉토리를 지정할 경우 dest 경로 끝에 슬래시( / )를 반드시 붙여야 합니다. Fetch module 사용 방법 예제에서는 다음과 같은 인벤토리 파일을 사용합니다. [test] rocky86.lab.example.com rocky84.lab.example.com   예제 1. 기본값( flat: false )으로 파일 가져오기 fetch  모듈을 이용해 관리 노드의...
자세한 내용 보기