NFS 클라이언트 / 서버 스택 조정

디스크 이미지를 보유하는 NFS를 통해 OpenSolaris 2009.06 시스템에 연결하는 CentOS 5 VMWare 서버가 있습니다. 가상 컴퓨터가 느린 IO에 묶여있는 것처럼 보이므로 연결을 최적화하기 위해 가능한 모든 작업을 수행하고 싶습니다.

프로덕션 시스템에서 처리량을 측정하는 가장 좋은 방법은 확실하지 않지만 dd bs=1024k count=400~ 1.6GB / s의 로컬 (OpenSolaris) 쓰기와 ~ 50MB / s의 원격 (CentOS) 쓰기를 사용하는 일부 비과학적인 테스트가 있습니다. 7 개의 VM이 현재 연결을 통해 실행되고 있기 때문에 이것이 실제로 얻는 것보다 낮습니다.

현재 두 시스템은 두 NIC 모두에서 점보 프레임이 활성화 된 직접 연결된 gigE입니다 (MTU = 9000). 그 외에는 최적화가 이루어지지 않았습니다. NFS 마운트 / 내보내기가 기본값을 사용하고 있습니다.

성능 향상을 위해 노브를 어디에서 시작해야합니까?

명확히하기 위해 단일 Gb 이더넷 연결을 통해 NFS로 50MB / 초를 얻고 있습니까?

그리고 호스트 서버는 VMware 서버가 설치된 CentOS를 실행하고 있는데, 7 개의 VM이 실행됩니까? 고성능 솔루션 인 VMware ESXi가 아니라 CentOS와 VMware 서버를 결합한 특별한 이유가 있습니까?

초당 50MB는 크지 않지만 단일 Gb 네트워크 케이블에서 기대하는 것보다 훨씬 적지는 않습니다. 사람들이 위에서 언급 한 NFS 조정을하면 일단 70- 80MB / 초 라인에 따른 옵션 :

"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

아마도 시스템의 양쪽 끝에서 당신에게 합리적 일 것입니다.

그 이상을 달성하려면 네트워크 카드를 쌍으로 구성해야 처리량이 약 90 % 증가합니다. 링크 집계 에서 최상의 성능을 얻으려면 802.3ad를 지원하는 스위치가 필요할 수 있습니다 .

그래도 OpenSolaris 상자의 IO 처리량이 의심스럽고 12 개의 디스크가 1.6GB / 초의 처리량을 지원하지 않을 가능성이 높으며 Solaris + ZFS에 의해 캐시 될 수도 있습니다.

RHEL / CentOS 5 머신의 경우 다음 마운트 플래그를 사용합니다

nfsvers = 3, tcp, timeo = 600, retrans = 2, rsize = 32768, wsize = 32768, 하드, intr, noatime

최신 Linux 커널 버전은 더 큰 rsize / wsize 매개 변수를 지원하지만 EL5의 2.6.18 커널의 최대 값은 32k입니다.

NFS 서버에서 적어도 Linux의 경우 no_wdelay는 BBWC가있는 디스크 컨트롤러가 있으면 도움이 될 것입니다. 또한 클라이언트에서 noatime 플래그를 사용하는 경우 noatime을 사용하여 서버에 파일 시스템을 마운트하는 것이 좋습니다.

그리고 이미 언급했듯이 UDP를 귀찮게하지 마십시오. 고속 네트워크 (1GbE +)를 사용하면 시퀀스 번호가 줄어드는 작지만 0이 아닌 데이터 손상 가능성이 있습니다. 또한 패킷 손실 가능성이 있으면 TCP가 UDP보다 성능이 우수합니다.

데이터 무결성이 그다지 걱정되지 않으면 "비동기"내보내기 옵션이 성능을 크게 향상시킬 수 있습니다 (비동기의 문제는 서버가 충돌하면 데이터가 손실 될 수 있다는 것입니다).

또한 최소한 Linux 서버의 경우 충분한 NFS 서버 스레드가 실행 중인지 확인해야합니다. 기본 8은 너무 낮습니다.

나는 한 번 Dell r710, 1 CPU, 4 GB RAM, 6 SATA 디스크와 RAID-10으로 테스트를 수행했습니다. 클라이언트는 위에서 언급 한 것처럼 CentOS 5.3 및 nfs 매개 변수를 모두 갖춘 x2100이었습니다.

"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

noatime와 함께 양쪽에 장착.

또한 최대 nfsds를 256으로 높이고 perc6 RAID 컨트롤러에 noop 스케줄러를 사용했습니다. 내가 한 또 다른 일은 파티션을 RAID 컨트롤러의 64K 스트라이프 크기에 맞추는 것입니다.

그런 다음 dd로 nfs 성능을 측정했습니다. 읽기의 경우 gigE 파이프를 채울 수 있지만 쓰기의 경우 약간 더 나은 결과를 얻을 수 있습니다. 비동기를 사용하면 70 ~ 80MB / s를 얻을 수 있지만 비동기는 옵션이 아닙니다.

아마 당신은 gigE 링크에서 nfs로 더 많은 것을 얻을 수 없습니까?

다음을 수행하십시오. 다음 두 단계를 통해 OpenSolaris NFS 서버에서 ZIL (ZFS Intent Log)을 일시적으로 비활성화하십시오.

1. echo zil_disable/W0t1 | mdb -kw
2. 테스트 파티션을 다시 마운트

그런 다음 다시 테스트하십시오. zilstat 를 사용 하여 ZIL에 대한 IO가 더 이상 존재하지 않도록 할 수 있습니다 . 테스트가 더 빨리 실행되면 성능 문제가 ZIL과 관련이 있다는 것을 알 수 있습니다. 여전히 느리게 실행되면 ZIL이 범인이 아니며 ZIL에 SSD를 사용하는 것도 도움이되지 않습니다. 참고 항목 ZFS 악 튜닝 가이드를 ZIL에 대한 자세한 내용은.

다른 옵션은 네트워크 트래픽 (예 : Wireshark)을 캡처하고 점보 프레임과 같은 문제가 있는지 확인하는 것입니다. 와이어의 패킷이 구성에서 예상 한 것처럼 보이는지 확인하십시오. 나쁜 조각화가 진행되고 있습니까? 재전송이 있습니까?

읽기 및 쓰기 페이로드 크기를 늘리면 도움이 될 수 있습니다. 특히 점보 프레임과 함께.

32k가 최적이라고 생각합니다.

rsize=32768,wsize=32768

UDP 전송으로 전환하는 것은 물론 전송 제어의 오버 헤드를 절약하기 때문에 TCP보다 빠릅니다. 그러나 NFSv4를 사용하지 않는 안정적인 네트워크에만 적용 할 수 있습니다.

ZFS의 NFS 성능은 ZFS (ZFS 인 텐트 로그)에 SSD를 사용하여 작업 대기 시간을 줄임으로써 크게 향상되었습니다. OpenSolaris NFS 및 ZFS 메일 링리스트 에서 ZFS의 VMWare NFS 성능 에 대한이 스레드 에는 ZIL 성능이 병목 상태인지 확인하기위한 벤치 마크 도구를 포함하여 추가 정보가 있습니다.

참고로 dd 명령은 디스크에 캐시를 쓰지 않고 쓸 것입니다. Solaris에서는 디스크가 아닌 RAM에 쓰기 때문에 "-oflag = sync"를 사용하여 디스크에 쓰기를 강제 할 수 있기 때문에 1.6G / s와 같은 미친 숫자를 얻을 수 있습니다