Điều chỉnh ngăn xếp máy khách / máy chủ NFS

Tôi có máy chủ CentOS 5 VMWare kết nối với máy OpenSolaris 2009.06 qua NFS chứa hình ảnh đĩa. Các máy ảo của tôi dường như bị ràng buộc bởi IO chậm nên tôi muốn làm mọi thứ có thể để tối ưu hóa kết nối.

Tôi không chắc chắn về cách tốt nhất để đo thông lượng trên hệ thống sản xuất, nhưng một số thử nghiệm không khoa học bằng cách sử dụng ghi dd bs=1024k count=400cục bộ (OpenSolaris) ghi ~ 1.6GB / s và từ xa (CentOS) ghi ~ 50MB / s. Tôi tưởng tượng những thứ này thấp hơn những gì tôi thực sự nhận được vì 7 máy ảo hiện đang chạy qua kết nối.

Hiện tại, 2 máy được gigE kết nối trực tiếp với khung jumbo được bật trên cả hai NIC (MTU = 9000). Ngoài ra, không có tối ưu hóa đã được thực hiện. Gắn kết / xuất NFS đang sử dụng mặc định.

Tôi nên bắt đầu xoay núm ở đâu để cải thiện hiệu suất?

Chỉ cần làm rõ, bạn sẽ nhận được 50MB / giây với NFS qua một kết nối ethernet Gb?

Và máy chủ lưu trữ đang chạy CentOS với cài đặt VMware Server, lần lượt chạy 7 VM? Có một lý do cụ thể nào bạn đã kết hợp với CentOS và VMware Server, thay vì VMware ESXi, một giải pháp hiệu suất cao hơn?

Tốc độ 50 MB / giây không phải là tuyệt vời, nhưng nó không thấp hơn nhiều so với những gì bạn mong đợi qua một cáp mạng Gb duy nhất - một khi bạn đã đưa vào các tinh chỉnh NFS mà mọi người đã đề cập ở trên, bạn sẽ nhìn vào có thể 70- 80MB / giây. Các tùy chọn dọc theo dòng:

"ro, cứng, xâm nhập, truyền lại = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

có lẽ là hợp lý cho bạn ở cả hai đầu của hệ thống.

Để vượt lên trên, bạn sẽ cần phải xem xét việc ghép các card mạng thành các cặp, điều này sẽ giúp tăng thông lượng của bạn lên khoảng 90%. Bạn có thể cần một công tắc hỗ trợ 802.3ad để có hiệu suất tốt nhất với tập hợp liên kết .

Một điều tôi muốn đề xuất là thông lượng IO của bạn trên hộp OpenSolaris nghe có vẻ cao đáng ngờ, 12 đĩa không có khả năng hỗ trợ thông lượng 1.6GB / giây và có thể được Solaris + ZFS lưu trữ rất nhiều.

Đối với các máy RHEL / CentOS 5 của chúng tôi, chúng tôi sử dụng các cờ gắn kết sau đây

nfsvers = 3, tcp, timeo = 600, recans = 2, rsize = 32768, wsize = 32768, cứng, xâm nhập, không có thời gian

Phiên bản kernel Linux mới hơn hỗ trợ các tham số rsize / wsize lớn hơn, nhưng 32k là mức tối đa cho kernel 2.6,18 trong EL5.

Trên (các) máy chủ NFS, ít nhất là cho Linux no_wdelay được cho là sẽ giúp nếu bạn có bộ điều khiển đĩa với BBWC. Ngoài ra, nếu bạn sử dụng cờ noatime trên máy khách, có thể có ý nghĩa để gắn kết các hệ thống tập tin trên các máy chủ cũng như không có thời gian.

Và, như đã được đề cập, đừng bận tâm với UDP. Với các mạng tốc độ cao hơn (1GbE +), có một cơ hội nhỏ, nhưng khác không, có khả năng xảy ra sự cố số thứ tự gây ra hỏng dữ liệu. Ngoài ra, nếu có khả năng mất gói, TCP sẽ hoạt động tốt hơn UDP.

Nếu bạn không lo lắng về tính toàn vẹn dữ liệu, tùy chọn xuất "không đồng bộ" có thể là một cải tiến hiệu suất lớn (vấn đề với async là bạn có thể mất dữ liệu nếu máy chủ gặp sự cố).

Ngoài ra, ít nhất là đối với máy chủ Linux, bạn cần đảm bảo có đủ các luồng máy chủ NFS đang chạy. 8 mặc định là quá thấp.

Tôi đã từng thực hiện một thử nghiệm với dell r710, 1 cpu, RAM 4 GB, 6 đĩa SATA với RAID-10. Máy khách là một mặt trời x2100, cả với CentOS 5.3 và các thông số nfs như đã đề cập ở trên

"ro, cứng, xâm nhập, truyền lại = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

gắn trên cả hai mặt với noatime.

Tôi cũng đã tăng đến nfsds lên 256 và sử dụng bộ lập lịch noop cho bộ điều khiển đột kích perc6. Một điều khác tôi đã làm là căn chỉnh các phân vùng theo kích thước sọc 64K của bộ điều khiển đột kích.

sau đó tôi đo hiệu suất nfs bằng dd - để đọc tôi có thể điền vào ống gigE nhưng để viết tôi chỉ có thể nhận được kết quả tốt hơn một chút như bạn. Khi bật async, tôi có thể nhận được 70 đến 80 MB / s nhưng async không phải là tùy chọn cho tôi.

Có lẽ bạn không thể nhận được nhiều hơn với nfs từ một liên kết gigE?

Hãy thử điều này: Tạm thời vô hiệu hóa Nhật ký ý định ZFS (ZIL) trên máy chủ NFS OpenSolaris với hai bước sau

1. echo zil_disable/W0t1 | mdb -kw
2. gắn lại phân vùng thử nghiệm

Sau đó kiểm tra lại. Bạn có thể sử dụng z Whileat để đảm bảo rằng thực sự không còn IO cho ZIL. Nếu thử nghiệm chạy nhanh hơn, bạn biết rằng vấn đề về hiệu năng có liên quan đến ZIL. Nếu nó vẫn chạy chậm, bạn biết rằng ZIL không phải là thủ phạm và việc sử dụng SSD cho ZIL cũng không giúp được gì. Xem Hướng dẫn điều chỉnh ZFS Evil để biết thêm thông tin về ZIL.

Một tùy chọn khác là nắm bắt lưu lượng mạng (ví dụ với Wireshark) và xem liệu có bất kỳ vấn đề nào không, ví dụ như với các khung Jumbo. Xác minh rằng các gói trên dây trông giống như bạn mong đợi từ cấu hình của bạn. Có sự phân mảnh xấu nào đang diễn ra không? Có truyền lại không?

Tăng kích thước tải và đọc có thể giúp đỡ. Đặc biệt là kết hợp với khung jumbo.

Tôi có xu hướng tìm 32k là tối ưu.

rsize=32768,wsize=32768

Chuyển sang truyền tải UDP dĩ nhiên là nhanh hơn TCP, vì nó tiết kiệm chi phí điều khiển truyền dẫn. Nhưng nó chỉ áp dụng trên các mạng đáng tin cậy và nơi NFSv4 không được sử dụng.

Hiệu suất NFS trên ZFS được cải thiện đáng kể bằng cách sử dụng ổ SSD cho nhật ký mục đích ZFS (ZIL) vì điều này làm giảm độ trễ của hoạt động. Chủ đề này về VMWare NFS về hiệu suất ZFS trên danh sách gửi thư OpenSolaris NFS và ZFS có thêm thông tin, bao gồm một công cụ điểm chuẩn để xem hiệu suất ZIL có phải là nút cổ chai hay không.

FYI lệnh dd sẽ ghi vào bộ đệm và không có đĩa, điều này bạn có thể nhận được các số điên như 1.6G / s vì bạn đang ghi vào RAM và không phải đĩa trên Solaris, bạn có thể sử dụng "-oflag = sync" để buộc ghi vào đĩa