ESXi NFS 데이터 스토어의 대기 시간 급증 문제 해결

ESXi의 NFS 데이터 저장소에서 특정 VM에 의해 트리거되는 약 5 초의 fsync 대기 시간이 발생합니다. 가상 IDE 드라이브에서는 발생하지 않기 때문에 NCQ / TCQ를 사용하는 VM으로 인한 것일 수 있습니다.

fsync-tester (Ted Ts'o 제작)와 ioping을 사용하여 재현 할 수 있습니다 . 예를 들어 8GB 디스크와 함께 Grml 라이브 시스템을 사용하는 경우 :

Linux 2.6.33-grml64:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 5.0391
fsync time: 5.0438
fsync time: 5.0300
fsync time: 0.0231
fsync time: 0.0243
fsync time: 5.0382
fsync time: 5.0400
[... goes on like this ...]

밀리 초가 아닌 5 초입니다. 이것은 동일한 호스트 및 데이터 저장소에서 실행되는 다른 VM에서 IO 대기 시간을 생성합니다 .

root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 .
4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms
4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms
4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms
4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms
4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms

첫 번째 VM을 로컬 스토리지로 옮기면 완벽하게 정상으로 보입니다.

root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 0.0191
fsync time: 0.0201
fsync time: 0.0203
fsync time: 0.0206
fsync time: 0.0192
fsync time: 0.0231
fsync time: 0.0201
[... tried that for one hour: no spike ...]

내가 시도한 것은 아무런 차이가 없었습니다.

• 여러 ESXi 빌드 테스트 : 381591, 348481, 260247
• 다른 하드웨어, 다른 Intel 및 AMD 박스에서 테스트
• 다른 NFS 서버로 테스트 한 결과 모두 동일한 동작을 보여줍니다.
  • OpenIndiana b147 (ZFS 동기화 항상 또는 비활성화 : 차이 없음)
  • OpenIndiana b148 (ZFS 동기화 항상 또는 비활성화 : 차이 없음)
  • Linux 2.6.32 (동기 또는 비동기 : 차이 없음)
  • NFS 서버가 동일한 시스템 (가상 스토리지 어플라이언스) 또는 다른 호스트에있는 경우에는 차이가 없습니다.

게스트 OS 테스트, 문제 표시 :

• Windows 7 64 비트 (CrystalDiskMark를 사용하면 대기 시간 스파이크가 대부분 준비 단계에서 발생 함)
• 리눅스 2.6.32 (fsync-tester + ioping)
• 리눅스 2.6.38 (fsync-tester + ioping)

Linux 2.6.18 VM에서이 문제를 재현 할 수 없습니다.

또 다른 해결 방법은 가상 IDE 디스크 (SCSI / SAS)를 사용하는 것이지만 성능과 VM 당 드라이브 수를 제한합니다.

2011-06-30 업데이트 :

응용 프로그램이 fsync 전에 여러 개의 작은 블록으로 쓰면 지연 시간이 더 자주 발생하는 것 같습니다. 예를 들어 fsync-tester는 다음을 수행합니다 (추적 출력).

pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3)                                = 0

ioping은 파일을 준비하는 동안이를 수행합니다.

[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3)                                = 0

ioping의 설정 단계는 거의 항상 중단되는 반면 fsync-tester는 정상적으로 작동합니다. fsync-tester를 업데이트하여 여러 개의 작은 블록을 쓸 수 있습니까? 내 C 기술은 빨아;)

2011-07-02 업데이트 :

iSCSI에서는이 문제가 발생하지 않습니다. OpenIndiana COMSTAR iSCSI 서버로 시도했습니다. 그러나 iSCSI를 사용하면 VMDK 파일에 쉽게 액세스 할 수 없으므로 스냅 샷과 rsync를 사용하여 호스트간에 파일을 이동할 수 있습니다.

2011-07-06 업데이트 :

이것은 동일한 vSwitch의 세 번째 VM에 의해 캡처 된 wireshark 캡처의 일부입니다. 이 모든 것은 물리적 호스트가없는 동일한 호스트에서 발생합니다.

20 시간 경에 아이오 핑을 시작했습니다. 5 초 지연이 끝날 때까지 패킷이 전송되지 않았습니다.

No.  Time        Source                Destination           Protocol Info
1082 16.164096   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC
1083 16.164112   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC
1084 16.166060   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110
1085 16.167678   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC
1086 16.168280   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC
1087 16.168417   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016
1088 23.163028   192.168.250.10        192.168.250.20        NFS      V3 GETATTR Call (Reply In 1089), FH:0x0bb04963
1089 23.164541   192.168.250.20        192.168.250.10        NFS      V3 GETATTR Reply (Call In 1088)  Directory mode:0777 uid:0 gid:0
1090 23.274252   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716
1091 24.924188   192.168.250.10        192.168.250.20        RPC      Continuation
1092 24.924210   192.168.250.10        192.168.250.20        RPC      Continuation
1093 24.924216   192.168.250.10        192.168.250.20        RPC      Continuation
1094 24.924225   192.168.250.10        192.168.250.20        RPC      Continuation
1095 24.924555   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986
1096 24.924626   192.168.250.10        192.168.250.20        RPC      Continuation
1097 24.924635   192.168.250.10        192.168.250.20        RPC      Continuation
1098 24.924643   192.168.250.10        192.168.250.20        RPC      Continuation
1099 24.924649   192.168.250.10        192.168.250.20        RPC      Continuation
1100 24.924653   192.168.250.10        192.168.250.20        RPC      Continuation

두 번째 업데이트 2011-07-06 :

TCP 창 크기에 영향을주는 것 같습니다. FreeBSD 기반 FreeNAS를 NFS 서버로 사용하여이 문제를 재현 할 수 없었습니다. wireshark 캡처는 정기적으로 29127 바이트로 TCP 창 업데이트를 보여주었습니다. OpenIndiana에서는 기본적으로 더 큰 창 크기를 사용하지 않습니다.

OpenIndiana에서 다음 옵션을 설정하고 NFS 서버를 다시 시작하면 더 이상이 문제를 재현 할 수 없습니다.

ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576

그러나 이것은 성능을 저하시킵니다. / dev / zero에서 dd_rescue가있는 파일에 쓰는 것은 170MB / s에서 80MB / s로 진행됩니다.

2011-07-07 업데이트 :

이 tcpdump 캡처를 업로드했습니다 (wireshark로 분석 가능). 이 경우 192.168.250.2는 NFS 서버 (OpenIndiana b148)이고 192.168.250.10은 ESXi 호스트입니다.

이 캡처 중에 테스트 한 사항 :

"ioping -w 5 -i 0.2"시작 시간 30, 설정에서 5 초 정지, 시간 40에서 완료.

"ioping -w 5 -i 0.2"시작 시간 60, 설정에서 5 초 정지, 시간 70에서 완료.

다음 출력과 함께 시간 90에서 "fsync-tester"가 시작되고 시간 120에서 중지되었습니다.

fsync time: 0.0248
fsync time: 5.0197
fsync time: 5.0287
fsync time: 5.0242
fsync time: 5.0225
fsync time: 0.0209

두 번째 업데이트 2011-07-07 :

다른 NFS 서버 VM을 테스트했는데 이번에는 NexentaStor 3.0.5 커뮤니티 에디션 : 동일한 문제를 보여줍니다.

2011-07-31 업데이트 :

새 ESXi 빌드 4.1.0.433742에서도이 문제를 재현 할 수 있습니다.

이 문제는 ESXi 5에서 수정 된 것으로 보입니다. 빌드 469512를 성공적으로 테스트했습니다.

고마워, nfsstat가 좋아 보인다. 캡처를 검토했습니다. 결정적인 것을 찾지 못했지만 흥미로운 것을 발견했습니다. tcp.time_delta> 5에서 필터링했습니다. 모든 지연 인스턴스 에서 찾은 것은 RPC 호출의 정확한 시작이었습니다. 모든 새로운 RPC 호출이 느리지는 않았지만 RPC 호출을 정확히 시작할 때 모든 느려짐이 발생했습니다. 또한 캡처에서 192.168.250.10에 모든 지연이 포함 된 것으로 보입니다. 192.168.250.2는 모든 요청에 ​​즉시 응답합니다.

결과:

• 지연은 항상 RPC 호출의 첫 번째 패킷에서 발생합니다
• NFS 명령 유형은 인스턴스 지연과 관련이 없습니다.
• 조각화 = 첫 번째 패킷 만 지연

큰 쓰기 호출은 300 개의 개별 TCP 패킷으로 나눌 수 있으며 첫 번째 패킷 만 지연되지만 나머지는 모두 통과합니다. 중간에 지연이 발생하지 않습니다. 창 크기가 연결 시작 에 그렇게 큰 영향을 줄 수 있는지 잘 모르겠습니다 .

다음 단계 : TCP 창 대신 NFSSVC_MAXBLKSIZE와 같은 NFS 옵션을 조정하기 시작했습니다. 또한 2.6.38은 작동하지만 2.6.38은 작동하지 않는 것으로 나타났습니다. 해당 기간 동안 VMXnet3 드라이버에 대한 지원이 추가되었음을 알고 있습니다. 호스트에서 어떤 NIC 드라이버를 사용하고 있습니까? TCP 오프 로딩 예 / 아니요? 95 초 정도에 단일 NFS 쓰기 호출에 대해 500 개가 넘는 TCP 패킷이 있습니다. TCP를 담당하고 큰 PDU를 해체하는 것이 무엇이든 차단할 수 있습니다.

ESXi4.1U1과 CentOS VM을 사용하는 것과 같은 문제가 있습니다. 호스트는 Dell R610이고 스토리지는 EMC2 Isilon 클러스터입니다.

VLANS를 사용했을 가능성이 있습니까? 스토리지에 VMkernel 포트에서 VLAN을 사용하면 VMHost의 모든 스토리지 트래픽에 대해 4000-5000ms의 '정지'가 발생했습니다. 그러나 VMkernel 포트를 VLAN 외부로 이동하여 태그가 지정되지 않은 패킷을 수신하면 문제가 표시되지 않습니다.

아래의 간단한 설정으로 네트워크에 문제가 발생할 수 있습니다.

1) 서버 또는 워크 스테이션에 ESXi 4.1U1을 설치합니다 (모두 시도했을 때 문제가 발생했습니다)

2) VLAN에 VMkernel 포트를 추가하십시오.

3) NFS 데이터 스토어 추가 (광산은 동일한 VLAN에 있습니다. 즉, Isilon은 태그가 지정된 패킷을 수신합니다)

4) 2 개의 CentOS 5.5 VM을 설치하십시오.

5) 부트 VM을 단일 사용자 모드로 (즉, 네트워크 없음, 최소 서비스)

6) 한 머신에서 ioping을 실행하여 가상 디스크에 기록합니다.

7) 다른 시스템에서 dd 등을 실행하여 100MB의 데이터를 / tmp 또는 이와 유사한 것으로 작성하십시오.

종종 두 개의 VM이 4-5 초 동안 멈추는 것을 볼 수 있습니다.

다른 사람이 비슷한 것을 보았는지 정말로 관심을 가져보십시오.

2 주 전에 정확히 같은 문제가있었습니다. ESX41 U1 및 Netapp FAS3170 + NFS 데이터 스토어. RHEL5 VM이 2 초 또는 4 초 동안 정지되었으며 Virtual Center 성능 콘솔에서 매우 높은 스파이크를 보았습니다.

네트워크 담당자에게 구성을 확인하도록 요청하면 문제는 시스코 스위치에 있습니다. 우리는 시스코 측이 아니라 Netapp 측의 Etherchannel에 구성된 두 개의 이더넷 링크가 있습니다. 그는 시스코에 정적 Ethechannel을 만들고 이제는 잘 작동합니다. 이러한 종류의 문제를 식별하려면 파일러와 스위치 사이의 포트를 제외한 모든 포트를 종료하십시오. 하나의 포트만 남겨두고 상황이 어떻게 진행되는지 확인하십시오.

우리가하는 두 번째 일은 switcj와 파일러에서 흐름 제어를 제거하는 것이 었습니다. 왜냐하면 우리는 이것이 일시 정지 프레임을 보내는 것으로 의심되기 때문입니다.

DNS는 어떻게 보입니까? 귀하가 /etc/resolv.conf맞습니까? 기본 시간 초과는 5 초입니다.

에서 man resolv.conf

timeout:n
                 sets the amount of time the  resolver  will  wait  for  a
                 response  from  a  remote name server before retrying the
                 query via a different name server.  Measured in  seconds,
                 the default is RES_TIMEOUT (currently 5, see <resolv.h>).

추가하십시오 timeout:3당신에게 /etc/resolv.conf다음 다시 fsync를 테스트를 실행합니다.

여기서 빨대를 잡고 있지만이 서버에서 어떤 NIC를 사용하고 있습니까? 스택 오버플로 시스템 관리자는 인텔 NIC로 전환했을 때 사라지는 Broadcom NIC에 이상한 네트워킹 문제가 발생했습니다. http://blog.serverfault.com/post/broadcom-die-mutha/

EXS 호스트에서 IPv6을 사용할 수 있습니까? 그렇다면, 끄시겠습니까? 내 경험상 전체 네트워크가 IPv6 (예 : RADV, DHCP6, DNS, 역방향 DNS)에 맞게 올바르게 구성되지 않은 경우 일부 서비스에 문제가있을 수 있습니다. 또한 NFS 서버에서 꺼져 있는지 확인하십시오.