NFS 캐시가 예기치 않게 만료됩니다.

NFS 캐시가 예기치 않게 만료됩니다.

로컬 캐시가 만료되지 않는 높은 대기 시간, 낮은 처리량 링크에서 NFS4 + CacheFilesd 설정을 구축해야 합니다. 유일한 무효화 의미는 무언가가 업데이트될 때 NFS 서버 콜백이어야 합니다(그런데, 이것은 잘 작동하며 서버 파일의 변경 사항은 즉시 클라이언트에 전달됩니다). 이 설치는 읽기 전용이므로 잠금이 없습니다.

질문:로컬 캐시에서 요청된 파일을 항상 올바르게 읽지만 지난 60초 동안 파일에 액세스하지 않은 경우 actimeo=86400 설정 여부에 관계없이 계속해서 파일 속성을 가져옵니다. 이는 파일이 열리는 빈도와 관련된 것으로 보입니다. 50초 이하마다 파일을 열어두는 한 잘 작동하기 때문입니다.

개념의 증거:

(서버 네트워크 지연시간은 인위적으로 2000밀리초로 설정되어 있어 언제 속성 체크가 수행되는지 명확하게 알 수 있습니다.)

각 요청이 예상대로 100% 캐시 적중을 생성한 후 50초를 기다립니다. 이는 무기한으로 계속됩니다.

root@client:~# while : ; do /usr/bin/time -f%e cat /nfs-mount/2bytes-file > /dev/null ; sleep 50 ; done
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00

이제 요청 간 지연을 70초로 설정하고 결과가 얼마나 일관성이 없는지 확인하세요.

root@client:~# while : ; do /usr/bin/time -f%e cat /nfs-mount/2bytes-file > /dev/null ; sleep 70 ; done
0.00
0.00
0.00
0.00
0.00
0.00
6.00 # <- Attributes fetched. Debug log recorded "NFS: nfs_update_inode(0:69/68697599 fh_crc=0xb9b7a69e ct=2 info=0x26040)" 
4.00 # <- Attributes fetched. Debug log recorded "NFS: nfs_update_inode(0:69/68697599 fh_crc=0xb9b7a69e ct=2 info=0x26040)" 
0.00
0.00
0.00
6.00 # <- Attributes fetched. Debug log recorded "NFS: nfs_update_inode(0:69/68697599 fh_crc=0xb9b7a69e ct=2 info=0x26040)" 
4.00 # <- Attributes fetched. Debug log recorded "NFS: nfs_update_inode(0:69/68697599 fh_crc=0xb9b7a69e ct=2 info=0x26040)" 
0.00
0.00
0.00

또한 nfsstats는 이러한 지연이 발생할 때 추가적인 "getattr"을 추가합니다.

create       delegpurge   delegreturn  getattr      getfh        link         
2         0% 0         0% 82        0% 177063   10% 87644     5% 0         0%

마지막으로 지연이 110초 이상으로 설정되면 어떤 이유로든 모든 요청이 서버에서 확인됩니다.

root@client:~# while : ; do /usr/bin/time -f%e cat /nfs-mount/2bytes-file > /dev/null ; sleep 110 ; done                                            
6.00
6.00
6.00
6.00
6.00
6.00
6.00

"cat" 대신 nginx를 사용하고 "ioping"을 통해 HTTP를 통해 이 2바이트 길이의 파일을 제공하여 똑같은 동작을 성공적으로 재현했습니다.

Cachefiled는 파티션에 충분한 공간이 있기 때문에 자체적으로 아무것도 지우지 않습니다.

/dev/vdb                20G  3,0G   16G  17% /disk2/fscache

2GB 파일(클라이언트의 물리적 메모리 크기보다 큼)에 대해 동일한 테스트를 수행하면 2초(네트워크 설정 지연) 동안 중단되고 그 다음에는 콘텐츠 자체가 아닌 파일의 메타데이터에만 액세스한다는 것을 알고 있습니다. 디스크에서 읽을 것으로 예상되는 Cachefilesd 로컬 캐시 파일을 누르기 시작합니다.

클라이언트가 업데이트를 위해 서버를 다시 확인하도록 하는 이 1~2분 동안 무슨 일이 일어나고 있는지 정말 이해가 되지 않습니다. 이는 내 설정의 목적을 무너뜨립니다.

/etc/export:

/cache 192.168.122.234(ro,async,no_subtree_check)

클라이언트 마운트:

root@client:~# mount -t nfs4 -o lookupcache=all,actimeo=86400,nocto,ro,intr,soft,proto=tcp,async,fsc 192.168.122.1:/cache /nfs-mount
root@client:~# cat /proc/mounts | grep nfs
192.168.122.1:/cache /nfs-mount nfs4 ro,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,acregmin=86400,acregmax=86400,acdirmin=86400,acdirmax=86400,soft,nocto,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.234,fsc,local_lock=none,addr=192.168.122.1 0 0

서버는 Centos 7이고 클라이언트는 Ubuntu 16.04입니다. 패키지는 배포판 저장소에서 가져옵니다.

root@client:~# dpkg -l | grep nfs ii libnfsidmap2:amd64 0.25-5 amd64 NFS idmapping 라이브러리 ii nfs-common 1:1.2.8-9ubuntu12 amd64 클라이언트 및 서버에 공통된 NFS 지원 파일 ii nfs4-acl-tools 0.3 .3-3 NFSv4 클라이언트용 amd64 명령줄 및 GUI ACL 유틸리티

또한 Ubuntu를 서버로 사용하고 CentOS 7을 클라이언트로 사용하려고 시도했지만 성공하지 못했습니다.

관련 정보