Khắc phục sự cố tăng vọt độ trễ trên kho dữ liệu ESXi NFS

44

Tôi đang gặp độ trễ fsync khoảng năm giây trên kho dữ liệu NFS trong ESXi, được kích hoạt bởi một số máy ảo nhất định. Tôi nghi ngờ điều này có thể do VM sử dụng NCQ / TCQ, vì điều này không xảy ra với các ổ đĩa IDE ảo.

Điều này có thể được sao chép bằng fsync-test (của Ted Ts'o) và ioping . Ví dụ: sử dụng hệ thống trực tiếp Grml với đĩa 8GB:

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 ...]

Đó là 5 giây, không phải mili giây. Điều này thậm chí còn tạo độ trễ IO trên một VM khác đang chạy trên cùng một máy chủ và kho dữ liệu :

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

Khi tôi chuyển VM đầu tiên sang bộ nhớ cục bộ, nó trông hoàn toàn bình thường:

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 ...]

Những điều tôi đã thử không có sự khác biệt:

Đã thử nghiệm một số bản dựng ESXi: 381591, 348481, 260247
Đã thử nghiệm trên các phần cứng khác nhau, các hộp Intel và AMD khác nhau
Đã thử nghiệm với các máy chủ NFS khác nhau, tất cả đều cho thấy cùng một hành vi:
- OpenIndiana b147 (Đồng bộ hóa ZFS luôn luôn hoặc bị tắt: không có sự khác biệt)
- OpenIndiana b148 (Đồng bộ hóa ZFS luôn luôn hoặc bị tắt: không có sự khác biệt)
- Linux 2.6.32 (đồng bộ hóa hoặc không đồng bộ: không có sự khác biệt)
- Sẽ không có gì khác biệt nếu máy chủ NFS ở trên cùng một máy (như một thiết bị lưu trữ ảo) hoặc trên một máy chủ khác

Hệ điều hành khách đã thử nghiệm, hiển thị sự cố:

Windows 7 64 Bit (sử dụng CrystalDiskMark, độ trễ tăng đột biến xảy ra chủ yếu trong giai đoạn chuẩn bị)
Linux 2.6.32 (fsync-test + ioping)
Linux 2.6,38 (fsync-test + ioping)

Tôi không thể tái tạo vấn đề này trên máy ảo Linux 2.6,18.

Một cách giải quyết khác là sử dụng các đĩa IDE ảo (so với SCSI / SAS), nhưng điều đó làm hạn chế hiệu năng và số lượng ổ đĩa trên mỗi VM.

Cập nhật 2011-06-30:

Sự tăng đột biến dường như xảy ra thường xuyên hơn nếu ứng dụng ghi thành nhiều khối nhỏ trước fsync. Ví dụ: fsync-test thực hiện điều này (đầu ra strace):

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

ioping làm điều này trong khi chuẩn bị các tập tin:

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

Giai đoạn thiết lập ioping hầu như luôn bị treo, trong khi fsync-test đôi khi hoạt động tốt. Có ai đó có khả năng cập nhật fsync-test để viết nhiều khối nhỏ không? Kỹ năng C của tôi hút;)

Cập nhật 2011/07/02:

Vấn đề này không xảy ra với iSCSI. Tôi đã thử điều này với máy chủ OpenSTiana COMSTAR iSCSI. Nhưng iSCSI không cung cấp cho bạn quyền truy cập dễ dàng vào các tệp VMDK để bạn có thể di chuyển chúng giữa các máy chủ với ảnh chụp nhanh và rsync.

Cập nhật 2011 / 07-06:

Đây là một phần của một bản ghi wireshark, được chụp bởi một VM thứ ba trên cùng một vSwitch. Tất cả điều này xảy ra trên cùng một máy chủ, không có mạng vật lý liên quan.

Tôi đã bắt đầu ioping khoảng thời gian 20. Không có gói nào được gửi cho đến khi hết năm giây:

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

Cập nhật lần 2 năm 2011 / 07-06:

Dường như có một số ảnh hưởng từ kích thước cửa sổ TCP. Tôi không thể tái tạo vấn đề này bằng FreeNAS (dựa trên FreeBSD) dưới dạng máy chủ NFS. Các ảnh chụp của wireshark cho thấy các cập nhật cửa sổ TCP lên 29127 byte theo chu kỳ. Tôi không thấy chúng với OpenIndiana, mặc định sử dụng kích thước cửa sổ lớn hơn.

Tôi không còn có thể tái tạo vấn đề này nếu tôi đặt các tùy chọn sau trong OpenIndiana và khởi động lại máy chủ NFS:

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

Nhưng điều này giết chết hiệu suất: Viết từ / dev / zero vào một tệp có dd_resTHER đi từ 170MB / s đến 80MB / s.

Cập nhật 2011/07/07:

Tôi đã tải lên bản chụp tcpdump này (có thể được phân tích bằng wireshark). Trong trường hợp này 192.168.250.2 là máy chủ NFS (OpenIndiana b148) và 192.168.250.10 là máy chủ ESXi.

Những điều tôi đã thử nghiệm trong lần chụp này:

Bắt đầu "ioping -w 5 -i 0.2." tại thời điểm 30, 5 giây treo trong thiết lập, hoàn thành tại thời điểm 40.

Bắt đầu "ioping -w 5 -i 0.2." tại thời điểm 60, 5 giây treo trong thiết lập, hoàn thành tại thời điểm 70.

Bắt đầu "fsync-test" tại thời điểm 90, với đầu ra sau, dừng tại thời điểm 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

Cập nhật lần 2 năm 2011/07/07:

Đã thử nghiệm một VM máy chủ NFS khác, lần này NexentaStor 3.0.5 phiên bản cộng đồng: Hiển thị các vấn đề tương tự.

Cập nhật 2011-07-31:

Tôi cũng có thể tái tạo vấn đề này trên ESXi build 4.1.0.433742 mới.

vmware-esxi nfs latency

— exo_cw
nguồn

12

Tôi phải nói rằng đã được một thời gian kể từ khi một người dùng hoàn toàn mới đến hội đồng quản trị với một câu hỏi được suy nghĩ kỹ lưỡng và nghiêm túc như vậy - nghiêm túc, hãy ngả mũ với bạn. Nó thực sự thú vị quá, tôi đã không bắt gặp fsync-test trước khi cảm ơn bạn. Điều đó nói rằng tôi không chắc chắn tôi có bất cứ điều gì để thêm vào, bạn đã thử rất nhiều thứ tôi đã có - Tôi nói rằng hãy tự nói với VMWare, họ rất giỏi trong việc sử dụng loại này của 'đuôi dài' / 'không phải là một sự cố ngừng dịch vụ thực tế' một cách nghiêm túc. Dù sao chỉ muốn nói tốt về những gì bạn đã làm cho đến nay :)

— Chopper3

Thật không may, trang web VMware sẽ không cho phép tôi liên hệ với họ: "Hiện tại bạn không có quyền lợi hỗ trợ tích cực"

— exo_cw

à, vâng, đó có thể là một vấn đề tất nhiên ...

— Chopper3

3

Thời gian chờ 5 giây với NFS nghe có vẻ quen thuộc. Trong NFS linux, có thời gian chờ là 0,7 giây cho RPC tăng gấp đôi sau mỗi lần thất bại và rút một điểm chính sau 3 lần thất bại (cài đặt mặc định). .7 + 1.4 + 2.8 = 4.9 giây. Có rất nhiều vấn đề xác thực RPC có thể gây ra điều này.

— Đánh dấu

2

@Ryan: Tôi đã tải lên tệp chụp. Tôi cũng đã tải lên đầu ra nfsstat .

— exo_cw

5

Vấn đề này dường như đã được khắc phục trong ESXi 5. Tôi đã thử nghiệm bản dựng 469512 thành công.

— exo_cw
nguồn

3

Cảm ơn, nfsstat có vẻ tốt. Tôi đã xem lại việc chụp. Không tìm thấy bất cứ điều gì kết luận, nhưng đã tìm thấy một cái gì đó thú vị. Tôi đã lọc trên tcp.time_delta> 5. Điều tôi tìm thấy trong mọi trường hợp trì hoãn là bắt đầu chính xác của một cuộc gọi RPC. Không phải tất cả các cuộc gọi RPC mới đều chậm, nhưng tất cả các sự chậm lại xảy ra khi bắt đầu chính xác một cuộc gọi RPC. Ngoài ra, từ khi chụp, có vẻ như 192.168.250.10 chứa tất cả độ trễ. 192.168.250.2 đáp ứng ngay lập tức tất cả các yêu cầu.

Kết quả:

Sự chậm trễ luôn xảy ra trong gói đầu tiên của cuộc gọi RPC
Các loại lệnh NFS không tương quan với các trường hợp trì hoãn
Phân mảnh = chỉ trì hoãn gói đầu tiên

Một cuộc gọi ghi lớn có thể chia thành 300 gói TCP riêng lẻ và chỉ có gói đầu tiên bị trì hoãn, nhưng tất cả phần còn lại đều bay qua. Không bao giờ sự chậm trễ xảy ra ở giữa. Tôi không chắc làm thế nào kích thước cửa sổ có thể ảnh hưởng đến sự bắt đầu của kết nối mạnh mẽ như vậy.

Các bước tiếp theo: Tôi sẽ bắt đầu điều chỉnh các tùy chọn NFS như NFSSVC_MAXBLKSIZE xuống dưới thay vì cửa sổ TCP. Ngoài ra, tôi nhận thấy rằng 2.6,18 hoạt động trong khi 2.6,38 thì không. Tôi biết rằng hỗ trợ đã được thêm cho trình điều khiển VMXnet3 trong khung thời gian đó. Bạn đang sử dụng trình điều khiển NIC nào trên máy chủ? TCP giảm tải có / không? Xung quanh mốc 95 giây có hơn 500 gói TCP cho một cuộc gọi NFS Write. Bất cứ điều gì chịu trách nhiệm về TCP và phá vỡ PDU lớn đều có thể là thứ ngăn chặn.

— Ryan
nguồn

Tôi đã thử đặt nfs: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots và nfs: nfs3_bsize tất cả xuống còn 8192: Không có sự khác biệt, cùng một vấn đề. Các khách linux chỉ sử dụng các đĩa SCSI / SAS của họ, không có NFS - ESXi là máy khách NFS, do đó không có vấn đề về trình điều khiển mạng trên máy khách linux. Về phía máy chủ NFS, tôi đã thử cả e1000 ảo và vmxnet3: Không có sự khác biệt. Theo tôi biết ESXi chỉ sử dụng giảm tải TCP cho iSCSI.

— exo_cw

Lớn nhất ? Tôi có lý do tại sao việc điều chỉnh cửa sổ TCP sẽ tạo ra sự khác biệt ... Ruột của tôi nói với tôi rằng đó là việc cần làm để phân chia các PDU lớn đó qua TCP. Một cái gì đó trong ngăn xếp mạng đang nghẹt thở trên đó. Chỉ không thể nghĩ bất cứ điều gì sẽ phù hợp với hành vi chúng ta đang thấy. Nếu kích thước cửa sổ là một vấn đề, chúng ta sẽ thấy băng thông hạn chế độ trễ ở giữa một lần chuyển lớn, không phải lúc bắt đầu, nhưng nó luôn là gói đầu tiên của cuộc gọi RPC ... khó khăn.

— Ryan

2

Tôi có vấn đề giống như khi sử dụng ESXi4.1U1 và CentOS VM. Các máy chủ lưu trữ là Dell R610s, lưu trữ là cụm EMC2 Isilon.

Bạn có từng sử dụng VLans không? Tôi đã tìm thấy bằng cách sử dụng Vlan trên cổng VMkernel để lưu trữ, gây ra 4000-5000ms 'treo' cho tất cả lưu lượng lưu trữ trên VMhost. Tuy nhiên, nếu tôi di chuyển cổng VMkernel khỏi Vlan để nó nhận được các gói không được mã hóa thì tôi không thấy vấn đề gì.

Thiết lập đơn giản dưới đây sẽ gây ra sự cố trên mạng của tôi:

1) Cài đặt ESXi 4.1U1 trên máy chủ hoặc máy trạm (cả hai đều thể hiện sự cố khi tôi thử)

2) Thêm cổng VMkernel trên Vlan.

3) Thêm một Kho dữ liệu NFS (của tôi nằm trên cùng một Vlan, tức là Isilon nhận các gói được gắn thẻ)

4) Cài đặt 2 CentOS 5.5 VM, một với ioping.

5) Khởi động VM vào chế độ người dùng đơn (nghĩa là không có mạng, dịch vụ tối thiểu)

6) Chạy ioping trên một máy để nó ghi vào đĩa ảo

7) Chạy dd hoặc somesuch trên máy khác để ghi 100MB dữ liệu vào / tmp hoặc tương tự

Thường xuyên hơn không tôi thấy cả hai VM đều đóng băng trong 4-5 giây.

Hãy thực sự quan tâm để xem nếu có ai khác đã nhìn thấy tương tự.

— Nick
nguồn

Chào mừng bạn đến với Lỗi Máy chủ! Đây là một câu hỏi cũ. Nếu câu trả lời không giúp bạn trực tiếp thì bạn nên hỏi một câu hỏi MỚI mới bằng cách nhấp vào nút Hỏi .

— user9517 hỗ trợ GoFundMonica

Vâng, tất nhiên tôi đang sử dụng Vlan được gắn thẻ. Khi tôi sử dụng chúng ở mọi nơi, tôi thậm chí không nghĩ chúng là một nguồn tiềm năng của vấn đề này. Tôi sẽ cố gắng tái tạo điều này trên một cổng không có thẻ.

— exo_cw

Tôi cũng có thể tái tạo vấn đề này trên một cổng không có thẻ, không có Vlan nào liên quan đến máy chủ đó cả.

— exo_cw

Tôi chỉ đang thử lại và thấy vấn đề trên cổng chưa được xử lý, nó ít thường xuyên hơn, có lẽ đó là lý do tại sao tôi bỏ lỡ nó. Xin lỗi cho bum-steer. Tôi không thể thấy sự cố trên Win7 64 bit khi sử dụng iometer, ngoài ra có vẻ như tôi có thể duyệt ổ đĩa c: trong khi các vms linux khác bị treo. Tôi sẽ thử với Crystaldiskmark

— Nick

Trên thực tế, tôi rất muốn thấy kết quả của bạn với iometer trên win7 x64. Nó đo độ trễ nhưng con số tổng thể cao nhất tôi nhận được là 300ms khi sử dụng bài kiểm tra đọc 4k, chứ không phải 4000 + ms

— Nick

2

Chúng tôi đã có chính xác cùng một vấn đề hai tuần trước. ESX41 U1 và Netapp FAS3170 + NFS Kho dữ liệu. Máy ảo RHEL5 bị treo trong 2 hoặc 4 giây và chúng tôi đã thấy các đột biến rất cao từ bảng điều khiển hiệu suất Trung tâm ảo.

Tôi yêu cầu anh chàng mạng kiểm tra cấu hình và vấn đề nằm ở công tắc cisco. Chúng tôi có hai liên kết ethernet được cấu hình trên Etherchannel ở phía Netapp chứ không phải ở phía cisco. Anh ta tạo ra một Ethechannel tĩnh trên cisco và bây giờ nó hoạt động tốt. Để xác định loại sự cố này, hãy tắt tất cả cổng ngoại trừ một cổng giữa bộ lọc và công tắc. Chỉ để lại một cổng còn sống và xem mọi thứ diễn ra như thế nào.

Điều thứ hai chúng tôi làm là loại bỏ Điều khiển luồng trên switcj và trình quay phim vì chúng tôi nghi ngờ nó sẽ gửi khung tạm dừng.

— Laurent
nguồn

1

DNS của bạn trông như thế nào? Là /etc/resolv.confchính xác của bạn ? Thời gian chờ mặc định là 5 giây.

Từ 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>).

Hãy thử phụ thêm timeout:3để bạn /etc/resolv.confvà sau đó chạy thử nghiệm fsync bạn một lần nữa.

— Joseph Kern
nguồn

Tôi đã thử thêm cái này trên máy chủ NFS (trong trường hợp này là OpenIndiana) và trên máy chủ ESXi. Thật không may, điều này không làm cho một sự khác biệt. Tôi có thể giải quyết IP máy chủ và khách tốt.

— exo_cw

có vẻ như bạn đã lọc tất cả lưu lượng truy cập không liên quan đến luồng nfs, chúng tôi có thể cần xem thêm!

— tony roth

@tony roth: Thật ra đó là toàn bộ lưu lượng tại thời điểm đó. Tôi đã thử nghiệm điều đó trên một vSwitch riêng biệt chỉ với máy chủ và máy chủ NFS trên đó.

— exo_cw

Bạn có thể kết xuất DNS với wireshark không?

— Joseph Kern

@Joseph Kern: Tôi vừa phân tích lại các tệp chụp: Không có lưu lượng DNS nào trong các lần chụp của tôi. Kho dữ liệu NFS được ánh xạ bởi IP trên máy chủ ESXi. DNS hoạt động tốt trên ESXi và máy chủ NFS, tôi đã thử nghiệm tra cứu chuyển tiếp & đảo ngược tất cả các IP liên quan. Ngay bây giờ tôi không có lý do để tin rằng DNS là nguyên nhân của việc này.

— exo_cw

1

Nắm bắt các ống hút ở đây, nhưng bạn đang sử dụng các máy ảo nào trong các máy chủ này? Các sysadins Stack Overflow đã gặp sự cố mạng kỳ lạ với các Broadcom đã biến mất khi chúng chuyển sang Intel NIC: http://blog.serverfault.com/post/broadcom-die-mutha/

— nhanh
nguồn

Các thử nghiệm cuối cùng chỉ được thực hiện trên vSwitch, không có mạng vật lý nào liên quan (e1000 và vmxnet3: không có sự khác biệt). Nhưng tôi cũng đã thử nghiệm điều này trên Intel 82574L, Intel 82576 và Intel 82567LF-3, tất cả đều cho thấy vấn đề. Tôi không tìm thấy bất kỳ phần cứng nào mà tôi không thể tái tạo nó.

— exo_cw

1

Đây là một phỏng đoán khác ... IPv6 của bạn có được bật trên máy chủ EXS không? Nếu có, sau đó thử tắt nó đi? Theo kinh nghiệm của tôi nếu toàn bộ mạng của bạn không được cấu hình đúng cho IPv6 (ví dụ RADV, DHCP6, DNS, DNS ngược) thì đó có thể là một vấn đề đối với một số dịch vụ. Ngoài ra, hãy chắc chắn rằng nó đã tắt trên máy chủ NFS.

— dtoubelis
nguồn

IPv6 đã bị vô hiệu hóa trên máy chủ ESXi. Tôi đã tắt IPv6 trên máy chủ NFS (ifconfig -a6 hiện đang trống), nhưng nó không tạo ra sự khác biệt: Nó cho thấy các vấn đề tương tự.

— exo_cw