Nâng cao tính khả dụng của các dịch vụ lưu trữ với Hệ thống lưu trữ NFS (3)

Để đánh giá hiệu suất cho các ứng dụng HPC trong đó nhiều nút truy cập tệp đồng thời với các mẫu IO ngẫu nhiên, IOzone phiên bản 3.492 được sử dụng ở chế độ ngẫu nhiên. Các thử nghiệm được tiến hành trên số lượng luồng bắt đầu từ 1 đến 64 tăng dần theo lũy thừa của hai.

Kích thước bản ghi được chọn là 4KB để có các lần truyền phù hợp với kích thước trang của hệ điều hành, đây thường là kích thước truyền nhỏ tối ưu cho hệ điều hành. Trước tiên, mỗi khách hàng đọc và sau đó ghi ngẫu nhiên 4GiB dữ liệu vào một tệp được tạo trước để mô phỏng các truy cập dữ liệu ngẫu nhiên nhỏ đồng thời bằng cách sử dụng các tệp lớn vừa phải khác nhau. Hình dưới đây cho thấy sự so sánh về hiệu năng ghi và đọc I/O ngẫu nhiên của Thiết kế đã được xác thực cho Bộ lưu trữ NFS và phiên bản trước đó có tên là NSS7.4-HA.

Từ hình này, có thể thấy rằng Thiết kế được xác thực cho Bộ lưu trữ HPC NFS có hiệu suất ghi ngẫu nhiên tương tự như phiên bản trước của giải pháp cho hầu hết các điểm dữ liệu, đạt tối đa 7281 IOps ở 32 luồng trên giải pháp mới. Số lượng luồng là 1 và 2, Bộ lưu trữ NFS mới có hiệu suất cao hơn 69,5% và 49% so với NSS7.4-HA. Những mức tăng hiệu suất đó, ở những khu vực mà bộ điều khiển PowerVault ME4084 chưa đạt đến giới hạn, đặc biệt là với 1 hoặc 2 luồng, là do các thành phần máy chủ nhanh hơn, bao gồm bộ nhớ 3200 MT/s, CPU có nhiều LLC hơn, tốc độ nhắn tin HDR cao hơn và các yếu tố khác cải tiến hệ điều hành. Sau thời điểm đó, hiệu suất của cả hai giải pháp gần như giống nhau khi chúng đạt được hiệu suất duy trì tối đa, vì các thao tác phải được ghi vào đĩa trước khi hoàn thành (do NFSv4 sử dụng giá treo đồng bộ hóa theo mặc định),

Mặt khác, hiệu suất đọc ngẫu nhiên có sự khác biệt lớn giữa các kết quả đối với hai giải pháp — hầu hết cho thấy IOps thấp hơn trên hệ thống mới, ngoại trừ trường hợp 2 luồng, trong đó có sự cải thiện 73,7%. Giải pháp này dường như có một cao nguyên đọc ở số lượng luồng thấp, sau đó tăng từ 8 lên số lượng luồng cao hơn, đạt hiệu suất cao nhất là 11.405 IOps ở 64 luồng. Trong bản phát hành trước NSS7.4-HA, hiệu suất cao nhất là 16.607 IOps cũng đạt được ở 64 luồng, cao hơn 31,3%% so với giải pháp hiện tại.

Điều đó có thể một phần là do bộ nhớ đệm phía máy chủ sau khi tạo tệp, cần nỗ lực đáng kể để giảm bớt hoặc loại bỏ và việc lạm dụng nó có thể dễ dàng ngăn cản mọi hoạt động tối ưu hóa hệ điều hành, ngăn cản việc đạt được hiệu suất bền vững đáng tin cậy.

Một cách để tránh vấn đề đó là sử dụng tổng dữ liệu đủ lớn gấp đôi dung lượng RAM trong máy chủ (hoặc 512 GiB), nhưng vì IOps do ổ cứng cung cấp tương đối thấp nên việc thực hiện đo điểm chuẩn như vậy có thể mất vài tuần. Hơn nữa, vì IOzone không trả về bất kỳ giá trị nào cho đến khi hoàn thành giai đoạn ghi hoặc đọc, nên quá trình kiểm tra không thể bị gián đoạn hoặc thất bại mà không cần phải bắt đầu lại quá trình kiểm tra đã thất bại mà không có bất kỳ kết quả nào. Kiểu đầu tư thời gian đó không phải lúc nào cũng là một lựa chọn khả thi.

Do tính năng ghi ngẫu nhiên yêu cầu bộ điều khiển ME4 tính toán hai bộ chẵn lẻ trên mỗi ổ đĩa nên hiệu suất đọc ngẫu nhiên dự kiến ​​sẽ cao hơn hiệu suất ghi, nhưng chỉ ở một mức độ nào đó do phương tiện quay IOps ngẫu nhiên có thể cung cấp có giới hạn. Cũng ảnh hưởng đến hiệu suất, đọc trước là một tối ưu hóa thường được thực hiện bởi lớp IO của Khối hệ điều hành có thể giúp đọc hiệu suất tỷ lệ thuận với số lần truy cập bộ đệm. Tuy nhiên, số lần truy cập bộ đệm sẽ giảm khi tổng kích thước dữ liệu tăng lên (giảm xác suất các khối ngẫu nhiên cần thiết đã có trong bộ nhớ), tạo ra sự phân bổ bộ đệm thừa và lãng phí thời gian cũng như tài nguyên để đọc dữ liệu mà rất có thể sẽ không được sử dụng.

Dựa trên nghiên cứu quan hệ nhân quả sơ bộ với Iozone và FIO (không có trong báo cáo này), kết quả với IOPS 4KiB đặc biệt lớn trên các kết quả đọc ngẫu nhiên một phần là do máy chủ đọc dữ liệu từ bộ đệm, tránh thao tác đọc đĩa. Tuy nhiên, việc ngăn chặn hoàn toàn bất kỳ bộ nhớ đệm nào của máy chủ (ví dụ: sử dụng một quy trình chiếm hầu hết bộ nhớ máy chủ và giữ nó được ghim trong quá trình kiểm tra) sẽ dẫn đến hiệu suất cực kỳ thấp, do Hệ điều hành không thể tối ưu hóa bất kỳ thứ gì trên tất cả các lớp Hệ điều hành khác nhau, và một số thành phần của hệ điều hành thậm chí có thể ngừng hoạt động (ví dụ: nếu OS Out of Memory Killer -OOMK được kích hoạt, sẽ chấm dứt một số daemon HA và các quy trình thiết yếu khác). Ngoài ra, bộ điều khiển ME4 yêu cầu áp suất IO cao (yêu cầu được xếp hàng đợi) để đạt được hiệu suất đọc ngẫu nhiên thô tối đa. Vì nó được thiết lập bằng cách sử dụng FIO trên các thiết bị thô (để loại bỏ ảnh hưởng của hệ thống tệp), với quyền truy cập IO trực tiếp vào LUN (để loại bỏ bộ đệm) và cài đặt đọc trước thành 0 (để chỉ chuyển các khối 4KiB được yêu cầu và không có dữ liệu bổ sung ). IOzone dường như không phải là điểm chuẩn lý tưởng để đạt được hiệu suất đọc duy trì tối đa của tải IO ngẫu nhiên 4KiB. FIO có thể là một ứng cử viên phù hợp vì nó có nhiều quyền kiểm soát hơn đối với một số khía cạnh của tải IO và theo thời gian thực hiện (ví dụ: dừng khi đạt được hiệu suất bền vững, tốc độ thay đổi sẽ nhỏ hơn một số ngưỡng), nhưng cần phải điều tra sâu hơn. IOzone dường như không phải là điểm chuẩn lý tưởng để đạt được hiệu suất đọc duy trì tối đa của tải IO ngẫu nhiên 4KiB. FIO có thể là một ứng cử viên phù hợp vì nó có nhiều quyền kiểm soát hơn đối với một số khía cạnh của tải IO và theo thời gian thực hiện (ví dụ: dừng khi đạt được hiệu suất bền vững, tốc độ thay đổi sẽ nhỏ hơn một số ngưỡng), nhưng cần phải điều tra sâu hơn. IOzone dường như không phải là điểm chuẩn lý tưởng để đạt được hiệu suất đọc duy trì tối đa của tải IO ngẫu nhiên 4KiB. FIO có thể là một ứng cử viên phù hợp vì nó có nhiều quyền kiểm soát hơn đối với một số khía cạnh của tải IO và theo thời gian thực hiện (ví dụ: dừng khi đạt được hiệu suất bền vững, tốc độ thay đổi sẽ nhỏ hơn một số ngưỡng), nhưng cần phải điều tra sâu hơn.