NFS 버전 4의 기능

이 절에서는 NFS 버전 4에서 도입된 기능에 대해 설명합니다.

• NFS 버전 4에서 파일 시스템 공유 해제 및 다시 공유

• NFS 버전 4의 파일 시스템 이름 공간

• NFS 버전 4의 휘발성 파일 핸들

• NFS 버전 4의 클라이언트 복구

• NFS 버전 4의 OPEN 공유 지원

• NFS 버전 4의 위임

• NFS 버전 4의 ACL 및 nfsmapid

NFS 서비스 설정에 대한 자세한 내용은 NFS 서비스 설정을 참조하십시오.

NFS 버전 4에서 파일 시스템 공유 해제 및 다시 공유

NFS 버전 3 및 NFS 버전 4가 모두 있는 경우 클라이언트가 공유 해제된 파일 시스템에 액세스하려고 하면 서버가 오류 코드로 응답을 보냅니다. 그러나 NFS 버전 3에서는 파일 시스템 공유를 해제하기 전에 클라이언트가 얻은 잠금을 서버에서 유지 관리합니다. 따라서 파일 시스템을 다시 공유하면 NFS 버전 3 클라이언트는 파일 시스템 공유를 해제한 적이 없었던 것처럼 파일 시스템에 액세스할 수 있습니다.

NFS 버전 4를 사용하는 경우 파일 시스템 공유를 해제하면 해당 파일 시스템의 파일 잠금 또는 열린 파일에 대한 모든 상태 정보가 삭제됩니다. 클라이언트가 이러한 파일 또는 잠금에 액세스하려고 하면 오류가 표시됩니다. 이 오류는 보통 응용 프로그램에 대한 I/O 오류로 보고됩니다. 그러나 옵션을 변경하기 위해 현재 공유된 파일 시스템을 다시 공유해도 서버의 상태 정보가 삭제되지는 않습니다.

NFS 버전 4의 클라이언트 복구에 대한 자세한 내용은 NFS 버전 4의 클라이언트 복구를 참조하십시오. unshare 명령의 사용 가능한 옵션에 대한 자세한 내용은 unshare_nfs(1M) 매뉴얼 페이지를 참조하십시오.

NFS 버전 4의 파일 시스템 이름 공간

NFS 버전 4 서버는 의사 파일 시스템을 만들고 유지 관리합니다. 따라서 클라이언트가 서버의 모든 내보낸 객체에 원활하게 액세스할 수 있습니다. NFS 버전 4 이전에는 의사 파일 시스템이 없었습니다. 즉, 클라이언트는 액세스할 각 공유 서버 파일 시스템을 강제로 마운트해야 했습니다.

의사 파일 시스템은 디렉토리만 포함하는 구조로, 서버에서 만들어집니다. 의사 파일 시스템에서는 클라이언트가 내보낸 파일 시스템의 계층을 찾아볼 수 있도록 합니다. 따라서, 클라이언트의 의사 파일 시스템 보기는 내보낸 파일 시스템에 포함되는 경로로 한정됩니다.

이전 NFS 버전에서는 각 파일 시스템을 마운트하지 않으면 클라이언트가 서버 파일 시스템을 순회할 수 없습니다. 그러나 NFS 버전 4에서는 서버 이름 공간이 다음을 수행합니다.

• 클라이언트의 파일 시스템 보기를 서버 내보내기에 포함되는 디렉토리로 제한합니다.

• 클라이언트가 각 기본 파일 시스템을 마운트하지 않고도 서버 내보내기에 원활하게 액세스할 수 있도록 합니다. 그러나 각 운영 체제에 따라 클라이언트가 각 서버 파일 시스템을 마운트해야 할 수도 있습니다.

그림 2-2  NFS 버전 4의 서버 파일 시스템 및 클라이언트 파일 시스템 보기

그림에 표시된 예에서 클라이언트는 payroll 디렉토리 및 nfs4x 디렉토리를 볼 수 없습니다. 이러한 디렉토리는 내보내지지 않으므로 내보낸 디렉토리에 포함되지 않기 때문입니다. 그러나 local 디렉토리는 클라이언트에 표시됩니다. local은 내보낸 디렉토리이기 때문입니다. projects 디렉토리는 클라이언트에 표시됩니다. projects는 내보낸 디렉토리(nfs4)에 포함되기 때문입니다. 따라서 명시적으로 내보내지 않은 서버 이름 공간 부분은 내보낸 디렉토리 및 서버 내보내기에 포함되는 디렉토리만 표시되는 의사 파일 시스템에 브리지됩니다.

NFS 버전 4의 휘발성 파일 핸들

파일 핸들은 서버에서 만들어지며 파일 및 디렉토리를 고유하게 식별하는 정보를 포함합니다. NFS 버전 2 및 NFS 버전 3에서는 서버에서 영구 파일 핸들을 반환했습니다. 그러므로 클라이언트는 서버가 항상 동일 파일을 참조하는 파일 핸들을 생성하도록 보장할 수 있습니다. 예를 들면 다음과 같습니다.

• 파일을 삭제한 다음 이름이 같은 파일로 교체하는 경우네는 서버에서 새 파일에 대해 새 파일 핸들을 생성합니다. 클라이언트가 이전 파일 핸들을 사용한 경우에는 서버에서 파일 핸들이 사용되지 않는다는 오류를 반환합니다.

• 파일 이름을 바꾼 경우에도 파일 핸들이 동일하게 유지됩니다.

• 서버가 재부트된 경우에도 파일 핸들은 동일하게 유지됩니다.

그러므로 서버에서 파일 핸들을 포함하는 클라이언트로부터의 요청을 받은 경우 파일이 즉시 확인되며 파일 핸들이 항상 올바른 파일을 참조합니다.

대부분 UNIX 기반 서버에서는 영구 파일 핸들을 사용하여 NFS 작업에 대한 파일 및 디렉토리 식별하는 방법으로 충분합니다. 그러나 파일 경로 이름 등의 다른 식별 방법을 사용했던 서버에서는 이 방법을 구현할 수 없습니다. 이 문제를 해결하려면 NFS 버전 4 프로토콜에서는 서버가 해당 파일 핸들이 휘발성임을 선언하도록 허용합니다. 파일 핸들이 변경되면 클라이언트는 새 파일 핸들을 찾아야 합니다.

NFS 버전 2 및 NFS 버전 3 서버 같은 Oracle Solaris NFS 버전 4 서버에서는 항상 영구 파일 핸들을 제공합니다. 그러나 Oracle Solaris NFS 버전 4 이외의 서버에 액세스하는 Oracle Solaris NFS 버전 4 클라이언트는 휘발성 파일 핸들(서버에서 사용하는 경우)을 지원해야 합니다. 구체적으로, 서버에서 파일 핸들이 휘발성임을 클라이언트에 알리면 클라이언트는 경로 이름과 파일 핸들 간 매핑을 캐시해야 합니다. 클라이언트는 휘발성 파일 핸들을 만료될 때까지 사용합니다. 핸들 만료 시에는 클라이언트가 다음을 수행합니다.

• 해당 파일 핸들을 참조하는 캐시된 정보를 비웁니다.

• 해당 파일의 새 파일 핸들을 검색합니다.

• 작업을 재시도합니다.

휘발성 파일 핸들은 다음과 같은 상황에서 만료될 수 있습니다.

• 파일을 닫을 때

• 파일 핸들의 파일 시스템을 마이그레이션할 때

• 클라이언트가 파일 이름을 바꿀 때

• 서버를 재부트할 때

클라이언트가 새 파일 핸들을 찾을 수 없으면 syslog 파일에 오류 메시지가 기록됩니다. 이 파일에 액세스하려는 추가 시도는 실패하고 I/O 오류가 발생합니다.

NFS 버전 4의 클라이언트 복구

NFS 버전 4 프로토콜은 stateful 프로토콜입니다. 클라이언트와 서버에서 둘 다 열린 파일과 파일 잠금에 대한 현재 정보를 유지 관리합니다.

서버가 충돌하여 재부트되면 서버 상태가 손실됩니다. 클라이언트는 서버가 재부트되었음을 감지하고 서버에서 오류 이전에 종료된 열기 및 잠금 상태를 재설정하도록 도와주는 프로세스를 시작합니다. 클라이언트가 프로세스를 진행하므로 이 프로세스를 클라이언트 복구라고 합니다.

클라이언트는 서버가 재부트되었음을 감지하면 현재 작업을 즉시 일시 중지하고 클라이언트 복구 프로세스를 시작합니다. 복구 프로세스가 시작되면 다음과 같은 메시지가 시스템 오류 로그 /var/adm/messages에 표시됩니다.

NOTICE: Starting recovery server server-name

복구 프로세스 중에 클라이언트는 이전 클라이언트 상태에 대한 정보를 서버로 보냅니다. 그러나 이 기간 중에 클라이언트는 서버로 새 요청을 보내지 않습니다. 파일을 열거나 파일 잠금을 설정하는 새 요청은 서버의 복구 프로세스가 완료될 때까지 기다린 후에 진행됩니다.

클라이언트 복구 프로세스가 완료되면 다음 메시지가 시스템 오류 로그 /var/adm/messages에 표시됩니다.

NOTICE: Recovery done for server server-name

그러면 상태 메시지를 서버로 보내는 클라이언트의 작업이 정상적으로 완료된 것입니다. 그러나 클라이언트가 이 프로세스를 완료했더라도 다른 클라이언트가 프로세스를 완료하지 않았을 수 있습니다. 따라서 유예 기간이라는 일정 기간에 서버는 모든 클라이언트가 복구를 완료할 수 있도록 열기 또는 잠금 요청을 허용하지 않습니다.

유예 기간 동안 클라이언트가 새 파일을 열거나 새 잠금을 설정하려고 시도하면 서버에서 요청을 거부하고 GRACE 오류 코드를 표시합니다. 이 오류를 받으면 클라이언트는 유예 기간이 종료될 때까지 기다렸다가 서버로 요청을 다시 보내야 합니다. 유예 기간에는 다음 메시지가 표시됩니다.

NFS server recovering

유예 기간에도 파일을 열지 않거나 파일 잠금을 설정하지 않는 명령은 계속 실행할 수 있습니다. 예를 들어 ls 및 cd 명령은 파일을 열거나 파일 잠금을 설정하지 않고 일시 중지되지 않습니다. 그러나 파일을 여는 cat 등의 명령은 유예 기간이 종료될 때까지 일시 중지됩니다.

유예 기간이 종료되면 다음 메시지가 표시됩니다.

NFS server recovery ok.

그러면 클라이언트는 새 열기 및 잠금 요청을 서버로 보낼 수 있습니다.

클라이언트 복구는 여러 가지 이유로 실패할 수 있습니다. 예를 들어 서버 재부트 후 네트워크 분할 영역이 있는 경우 클라이언트가 유예 기간 종료 전에 서버와의 상태를 재설정하지 못할 수 있습니다. 유예 기간이 종료되어도 서버는 클라이언트가 상태를 재설정하도록 허용하지 않습니다. 새 상태 작업으로 인해 충돌이 발생할 수 있기 때문입니다. 예를 들어 새 파일 잠금이 클라이언트에서 복구하려고 하는 이전 파일 잠금과 충돌할 수 있습니다. 이러한 상황이 발생하면 서버에서는 NO_GRACE 오류 코드를 클라이언트로 반환합니다.

파일에 대한 열기 작업 복구가 실패하면 클라이언트는 해당 파일을 사용할 수 없는 것으로 표시하며, 다음 메시지가 표시됩니다.

WARNING: The following NFS file could not be recovered and was marked dead 
(can't reopen:  NFS status n):  file :  filename

복구하는 동안 파일 잠금 재설정에 실패하면 다음 오류 메시지가 표시됩니다.

NOTICE: nfs4_send_siglost:  pid process-ID lost
lock on server server-name

이 경우 SIGLOST 신호가 프로세스에 게시됩니다. SIGLOST 신호의 기본 작업은 프로세스를 종료하는 것입니다.

이 상태에서 복구하려면 오류 시 파일을 열고 있던 응용 프로그램을 다시 시작해야 합니다. 파일을 다시 열지 않은 일부 프로세스에서 I/O 오류가 발생할 수 있습니다. 파일을 다시 열었거나 복구 실패 후 열기 작업을 수행한 다른 프로세스에서는 문제 없이 파일에 액세스할 수 있습니다.

따라서 일부 프로세스는 특정 파일에 액세스할 수 있는 반면 다른 프로세스는 액세스할 수 없습니다.

NFS 버전 4의 OPEN 공유 지원

NFS 버전 4 프로토콜에서는 클라이언트가 다른 클라이언트의 파일 액세스를 제어하는 데 사용할 수 있는 다양한 파일 공유 모드를 제공합니다. 클라이언트는 다음을 지정할 수 있습니다.

• DENY_NONE 모드는 다른 클라이언트의 파일 읽기 및 쓰기 액세스를 허용합니다.

• DENY_READ 모드는 다른 클라이언트의 파일 읽기 액세스를 거부합니다.

• DENY_WRITE 모드는 다른 클라이언트의 파일 쓰기 액세스를 거부합니다.

• DENY_BOTH 모드는 다른 클라이언트의 파일 읽기 및 쓰기 액세스를 거부합니다.

Oracle Solaris NFS 버전 4 서버에서는 이러한 파일 공유 모드를 완전하게 구현합니다. 따라서 클라이언트가 현재 공유 모드와 충돌하는 방식으로 파일을 열려고 하면 서버에서 작업이 실패하도록 하여 해당 시도를 거부합니다. 열기 또는 만들기 작업을 시작할 때 이러한 시도가 실패하면 NFS 버전 4 클라이언트는 프로토콜 오류를 받게 됩니다. 이 오류는 응용 프로그램 오류 EACCES에 매핑됩니다.

프로토콜에서 여러 공유 모드를 제공하기는 하지만, Oracle Solaris에서 열기 작업을 수행하는 경우 여러 공유 모드가 제공되지 않습니다. 파일을 열 때 Oracle Solaris NFS 버전 4 클라이언트는 DENY_NONE 모드만 사용할 수 있습니다.

NFS 버전 4의 위임

NFS 버전 4에서는 위임을 위한 클라이언트 지원과 서버 지원을 모두 제공합니다. 위임은 서버에서 파일 관리를 클라이언트에 위임하는 기술입니다. 예를 들어 서버에서 읽기 위임 또는 쓰기 위임을 클라이언트에 부여할 수 있습니다. 읽기 위임은 서로 충돌하지 않으므로 여러 클라이언트에 동시에 부여할 수 있습니다. 쓰기 위임은 다른 클라이언트의 파일 액세스와 충돌하므로 한 클라이언트에만 부여할 수 있습니다. 쓰기 위임을 보유한 클라이언트는 파일에 배타적으로 액세스할 수 있기 때문에 서버로 여러 작업을 보내지 않습니다. 마찬가지로, 읽기 위임을 보유한 클라이언트도 서버로 여러 작업을 보내지 않습니다. 서버에서 어떤 클라이언트도 쓰기 모드로 파일을 열지 못하도록 보장하기 때문입니다.

위임을 사용하는 경우 위임된 파일에 대해 서버와 클라이언트의 상호 작용이 크게 줄어듭니다. 따라서 네트워크 트래픽이 감소하고 클라이언트와 서버의 성능이 개선됩니다. 그러나 성능 개선 정도는 응용 프로그램에서 사용하는 파일 상호 작용의 종류와 네트워크 및 서버 혼잡 정도에 따라 달라집니다.

클라이언트는 위임을 요청하지 않습니다. 위임을 부여할지 여부는 파일의 액세스 패턴에 따라 전적으로 서버에서 결정합니다. 최근에 여러 클라이언트가 쓰기 모드에서 파일에 액세스한 경우 이 액세스 패턴은 향후 충돌 가능성을 나타내므로 서버는 위임을 부여할 수 없습니다.

클라이언트가 현재 파일에 대해 부여된 위임과 일치하지 않는 방식으로 해당 파일에 액세스하면 충돌이 발생합니다. 예를 들어 클라이언트가 파일에 대한 쓰기 위임을 보유하고 있는데 두번째 클라이언트가 읽기 또는 쓰기 액세스를 위해 해당 파일을 열면 서버에서 첫번째 클라이언트의 쓰기 위임을 회수합니다. 마찬가지로, 클라이언트에서 읽기 위임을 보유하고 있는데 다른 클라이언트가 쓰기를 위해 같은 파일을 열면 서버가 읽기 위임을 회수합니다. 두 상황에서 모두 충돌이 발생하므로 두번째 클라이언트에는 위임이 부여되지 않습니다.

충돌이 발생하면 서버에서는 콜백 방식을 사용하여 현재 위임을 보유한 클라이언트에 연결합니다. 이 콜백을 받으면 클라이언트는 파일의 업데이트된 상태를 서버로 보내고 위임을 반환합니다. 클라이언트가 회수에 응답하지 못하면 서버에서 위임을 해지합니다. 이 경우 서버는 해당 파일에 대한 클라이언트의 모든 작업을 거부하며 클라이언트는 요청한 작업을 실패로 보고합니다. 일반적으로 이러한 실패는 응용 프로그램에 I/O 오류로 보고됩니다. 이 오류에서 복구하려면 파일을 닫았다가 다시 열어야 합니다. 클라이언트가 위임을 보유한 상태에서 클라이언트와 서버 간에 네트워크 파티션이 있으면 해지된 위임에서 오류가 발생할 수 있습니다.

서버는 다른 서버에 저장된 파일에 대한 액세스 충돌을 해결할 수 없습니다. 따라서 NFS 서버는 서버에 저장된 파일에 대해서만 충돌을 해결합니다. 또한, 여러 NFS 버전을 실행하는 클라이언트에서 발생하는 충돌에 대해 NFS 서버는 NFS 버전 4를 실행하는 클라이언트에 대한 회수만 시작할 수 있습니다. NFS 서버는 이전 NFS 버전을 실행 중인 클라이언트에 대해 회수를 시작할 수 없습니다.

충돌 감지 프로세스는 상황에 따라 다릅니다. 예를 들어, NFS 버전 4와는 달리 NFS 버전 2와 NFS 버전 3에는 열기 절차가 없기 때문에 충돌은 클라이언트가 파일을 읽거나 쓰거나 잠그려고 시도한 후에만 감지됩니다. 이러한 충돌에 대한 서버의 응답도 다릅니다. 예를 들면 다음과 같습니다.

• NFS 버전 3의 경우에는 서버에서 JUKEBOX 오류를 반환하며, 그러면 클라이언트가 액세스 요청을 정지했다가 나중에 다시 시도합니다. 클라이언트는 File unavailable 메시지를 표시합니다.

• NFS 버전 2의 경우에는 JUKEBOX 오류에 해당하는 항목이 없기 때문에 서버에서 응답을 하지 않으며, 클라이언트는 기다렸다가 다시 시도합니다. 클라이언트는 NFS server not responding 메시지를 표시합니다.

위임 충돌이 해결되면 오류 메시지가 제거됩니다.

기본적으로 서버 위임은 사용으로 설정됩니다. server_delegation 매개변수를 off로 설정하여 위임을 사용 안함으로 설정할 수 있습니다.

# sharectl set -p server_delegation=off nfs

클라이언트 위임에는 키워드가 필요하지 않습니다. NFS 버전 4 콜백 데몬 nfs4cbd는 클라이언트에서 콜백 서비스를 제공합니다. 이 데몬은 NFS 버전 4에 대한 마운트를 사용으로 설정할 때마다 자동으로 시작됩니다. 기본적으로 클라이언트는 /etc/netconfig 시스템 파일에 나와 있는 모든 인터넷 전송에 대해 필요한 콜백 정보를 서버에 제공합니다. IPv6에 대해 클라이언트를 사용으로 설정하는 경우 클라이언트 이름의 IPv6 주소를 확인할 수 있으면 콜백 데몬은 IPv6 연결을 수락합니다.

콜백 데몬은 일시 프로그램 번호와 동적으로 지정된 포트 번호를 사용합니다. 이 정보는 서버에 제공되며, 서버는 위임을 부여하기 전에 콜백 경로를 테스트합니다. 콜백 경로 테스트가 실패하면 서버에서 위임을 부여하지 않습니다. 외부에서 확인 가능한 동작은 이 동작뿐입니다.

콜백 정보는 NFS 버전 4 요청 내에 내장되므로, 서버는 NAT(Network Address Translation)를 사용하는 장치를 통해 클라이언트에 연결할 수 없습니다. 또한 콜백 데몬은 동적 포트 번호를 사용합니다. 따라서 방화벽이 포트 2049에서 일반 NFS 트래픽을 사용으로 설정해도 서버가 방화벽을 순회하지 못할 수 있습니다. 이 경우에는 서버에서 위임을 할당하지 않습니다.

NFS 버전 4의 ACL 및 nfsmapid

ACL(액세스 제어 목록)은 파일 소유자가 파일 소유자, 그룹 및 기타 특정 사용자/그룹의 파일 권한을 정의할 수 있도록 하여 파일 보안을 제공합니다. ZFS 파일 시스템에서 chmod 명령을 사용하여 서버와 클라이언트에서 ACL을 설정할 수 있습니다. UFS 파일 시스템에서는 setfacl 명령을 사용할 수 있습니다. 자세한 내용은 chmod(1) 및 setfacl(1) 매뉴얼 페이지를 참조하십시오. NFS 버전 4에서는 ID 매퍼 nfsmapid를 사용하여 서버의 ACL 항목에 있는 사용자 ID 또는 그룹 ID를 클라이언트의 ACL 항목에 있는 사용자 ID 또는 그룹 ID로 매핑합니다. 그 반대의 경우도 마찬가지입니다. ACL 항목의 사용자 및 그룹 ID는 클라이언트와 서버에 모두 있어야 합니다.

ACL 및 nfsmapid에 대한 자세한 내용은 다음을 참조하십시오.

• Oracle Solaris 11.2의 ZFS 파일 시스템 관리 의 7 장, ACL 및 속성을 사용하여 Oracle Solaris ZFS 파일 보호

• NFS 데몬

ID 매핑 문제

다음과 같은 상황에서 ID 매핑이 실패할 수 있습니다.

• 서버의 ACL 항목에 있는 사용자 또는 그룹을 클라이언트의 유효한 사용자 또는 그룹에 매핑할 수 없는 경우 사용자가 ACL을 읽을 수는 있지만 일부 사용자 또는 그룹이 unknown으로 표시됩니다.

  예를 들어 이 상황에서 ls –lv 또는 ls –lV 명령을 실행하면 일부 ACL 항목의 그룹 또는 사용자가 unknown으로 표시됩니다.

• 클라이언트에 설정되어 있는 ACL 항목의 사용자 ID 또는 그룹 ID를 서버의 유효한 사용자 ID 또는 그룹 ID에 매핑할 수 없는 경우 setfacl 및 chmod 명령이 실패할 수 있으며 Permission denied 오류 메시지가 반환됩니다.

• 클라이언트와 서버의 nfsmapid_domain 값이 일치하지 않으면 ID 매핑에 실패합니다. 자세한 내용은 NFS 데몬을 참조하십시오.

ID 매핑 문제를 방지하려면 다음을 수행합니다.

• nfsmapid_domain의 값이 올바르게 설정되어 있는지 확인합니다. 현재 선택된 NFSv4 도메인은 /var/run/nfs4_domain 파일에서 사용할 수 있습니다.

• ACL 항목의 모든 사용자 ID 및 그룹 ID가 NFS 버전 4 클라이언트와 서버에 모두 있는지 확인합니다.

매핑되지 않은 사용자 ID 또는 그룹 ID 확인

사용자 또는 그룹을 서버나 클라이언트에서 매핑할 수 없는지 확인하려면 다음 스크립트를 사용합니다.

#! /usr/sbin/dtrace -Fs

sdt:::nfs4-acl-nobody
{
     printf("validate_idmapping: (%s) in the ACL could not be mapped!", 
stringof(arg0));
}