우리는 rsync를 사용하여 두 NFS 서버 간의 데이터를 동기화합니다. NFS 서버 하나는 동부 해안에 있고 다른 하나는 서부 해안에 있습니다. RTT는 약 110ms입니다.
East Coast NFS 서버에 West Coast NFS 서버 마운트 지점을 설치했습니다.
<server>:/home/backups on /mnt/backups type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5,clientaddr=x.x.x.x,local_lock=none,addr=y.y.y.y).
데이터는 데이터를 확인하기 위해(예: 폴더 동기화 및 변경 사항이 필요하지 않은 경우) 이미 두 서버에 모두 있습니다. 7GB 폴더가 있는 East Coast 서버가 West Coast 서버와 동일한지 확인하는 데 걸리는 시간은 다음과 같습니다.
다음 작업은 7GB 이상의 데이터로 완료하는 데 약 8분이 소요됩니다.
rsync -r -vvvv --info=progress2 --size-only /<local_path>/ /<remote_path>/
다음(NFS 마운트 사용 방지)은 7GB가 넘는 데이터를 완료하는 데 약 15초가 걸립니다(동일).
rsync -r -vvvv --info=progress2 --size-only /<local_path>/ <user>@<west_cost_NFS>:/<remote_path>/
다시 말하지만, 폴더가 이미 동기화되었으므로 위의 방법은 데이터를 이동하지 않고 파일 크기를 기준으로 데이터가 동일한지 확인합니다.
-o async클라이언트와 서버 모두에서 사용을 시도했지만 클라이언트에서 "mount"를 실행하면 /etc/exports async클라이언트가 전혀 나타나지 않습니다. async나는 async그것이 기본값이라고 생각합니다. rsize, wsize도 더 큰 값으로 변경해 보았으나 성능이 좋아지지 않았습니다. NFS에서 더 나은 성능을 얻을 수 있습니까?
답변1
제 생각에는 rsync를 사용하려는 시도가 잘못되었습니다. Rsync의 프로토콜은 두 개의 별도 서버에서 대용량 파일 시스템을 비교/동기화하는 정확한 시나리오를 위해 설계되었습니다. 가능한 한 로컬에서 실행됩니다.둘 다중간에서 비교되기 전의 로컬 및 원격 시스템입니다.
해당 프로토콜은 한 시스템의 rsync 에이전트가 다른 시스템의 rsync 에이전트와 통신하도록 설계되었으며, 프로토콜은 작업을 완료하는 데 필요한 왕복 횟수(및 총 데이터)를 크게 줄이도록 설계되었습니다.
rsync는 다음을 위해 설계되었습니다.
[fast] [slow SSH] [fast]
File system <----> rsync <----------> rsync <----> File system
Rsync는 두 에이전트 간의 네트워크 성능에 최적화되어 있지만 디스크 액세스에 사용되는 프로토콜을 제어할 수는 없습니다. 따라서 원격 NFS 파일 시스템을 마운트할 때 네트워크 액세스 프로필을 변경합니다.
[fast] [fast] [slow NFS]
File system <----> rsync <------> rsync <---------> File system
Rsync는 NFS 프로토콜을 전혀 제어할 수 없기 때문에 이에 대해 아무 것도 할 수 없습니다.
여기서 한 가지 구체적인 차이점은 NFS의 경우 각 파일이 다음과 같아야 한다는 것입니다.개별적으로묻다. 포함된 파일 트리를 탐색하려면 [wait]를 요청한 다음 [wait]를 요청하고 [wait]를 요청한 다음 마지막으로 를 요청해야 /foo/bar/baz합니다 . 요청당 대기 시간은 110ms입니다. 즉, 대기 시간은 330ms이고 파일은 하나만 가져옵니다.//foo/foo/bar/foo/bar/baz
브로커 간 Rsync 프로토콜에는 이러한 제한이 없습니다. 원격 시스템에서 실행되는 에이전트는 동기화 중인 원격 파일 시스템의 모든 파일 및 디렉터리 목록을 열심히 컴파일하여 모든 것을 보냅니다. 전체 파일 트리에 대한 요청은 단 하나입니다!
바라보다rsync 작동 방식
답변2
당신의 전제가 잘못되었습니다. NFS를 통해 파일 시스템 비교를 수행하면 대량의 데이터(파일에 대한 메타데이터)가 이동됩니다. 큰 트리의 경우 각각 지연 시간이 있는 개별 요청이 많이 있습니다.
SSH 연결을 통해 rsync를 사용하면 확인을 위해 원격 측에 대한 파일 이름 및 메타데이터 스트림을 보냅니다. 파일 수와 메타데이터 양이 동일할 수 있지만 스트리밍되므로 전체 대기 시간이 매우 낮습니다.
110밀리초의 RTT를 사용하면 8분이 아닌 15초를 쉽게 얻을 수 있습니다.
아, 그리고 시작할 때 플래그를 ( 이상) 또는 (충분) rsync으로 바꾸세요. 파일 타임스탬프가 포함되지 않으면 연결 양쪽 끝에 있는 파일은 궁극적으로 서로에 비해 오래된 것으로 간주됩니다.-r-a-rtrsync
답변3
이전에 RHEL 7.9를 사용하고 현재(2023년 2월) RHEL 8.7을 사용하고 있는데, RHEL 7.9에서 NFS vers=4.2를 작동할 수 없었다고 말씀드릴 수 있습니다. vers=4.1일 때 최대값에 도달합니다. 그리고 원래 설치 상태에서 /etc/nfs/nfs.conf파일을 수정하지 않은 경우에만 가능합니다./etc/sysconfig/nfs
이 기사에서 언급한NFSv4 및 NFSv4.1에 대한 일부 리뷰에 따르면 이러한 버전에는 대역폭과 확장성이 제한되어 있으며 네트워크 트래픽이 많을 때 NFS 속도가 느려질 수 있습니다. NFSv4.2는 대역폭과 확장성 문제를 개선한 것으로 알려졌습니다. 2022년 4월에 최종 업데이트되었습니다.
https://www.techtarget.com/searchenterprisedesktop/definition/Network-File-System
저도 최근에 이런 질문을 했어요
4.2 버전 대신 NFS 3을 사용하는 이유가 있나요?
그래서내 생각에는최근 NFS를 플레이한 경험에 따르면 NFS를 구해 vers=4.2사용할 proto=rdma수 없다면아마도nfs v3를 UDP로 사용하면 최상의 성능을 제공할 수 있습니다. 특히 nfs 서버 async에 지정됩니다. /etc/exportfs네 말이 맞아, 넌 볼 수 없을 거야비동기식nfs 클라이언트에서 마운트 옵션으로 언급되었으며, 이를 테스트한 후 rsync -P test_60gb.tar /nfsmount 수정을 사용하면 즉시 /etc/exports50MB/sec에서 100MB/sec로 변경되는 것을 관찰했습니다 exportfs -arv. 가지다proto=tcp 그리고 syncNFS 성능에는 확실히 좋지 않습니다.
아직 시도해 볼 기회가 없었고 proto=udp, 사실 하기가 힘들어요.