Điểm chuẩn này được thực hiện trên cấu hình Lớn ban đầu cộng với bốn bản mở rộng ME484, tức là hai máy chủ PowerEdge R750 được kết nối với bốn mảng ME4084 và bốn bản mở rộng ME484 (một đằng sau mỗi mảng ME4084), với mô-đun HDMD tùy chọn (hai máy chủ PowerEdge R750) bằng cách sử dụng một mảng ME4024 đơn lẻ.

Hiệu suất IOzone tuần tự N máy khách đến N tệp

Hiệu suất của N máy khách liên tiếp đến N tệp được đo bằng IOzone phiên bản 3.492. Các thử nghiệm mà chúng tôi đã chạy đa dạng từ một luồng đơn lên đến 1024 luồng và kết quả của giải pháp dung lượng mở rộng (4 x mảng ME4084 cộng với 4 x ME484 mở rộng) tương phản với giải pháp kích thước lớn (4 x mảng ME4084). 

Chúng tôi đã sử dụng các tệp đủ lớn để giảm thiểu tác động của bộ nhớ đệm, với tổng kích thước dữ liệu là 8 TiB, nhiều hơn gấp đôi tổng kích thước bộ nhớ của máy chủ và máy khách. Lưu ý rằng GPFS đặt nhóm trang có thể điều chỉnh thành dung lượng bộ nhớ tối đa được sử dụng để lưu vào bộ đệm ẩn dữ liệu, bất kể dung lượng RAM được cài đặt và dung lượng trống (được đặt thành 32 GiB trên máy khách và 96 GiB trên máy chủ để cho phép tối ưu hóa I/O). Trong khi ở các giải pháp Dell HPC khác, trong đó kích thước khối cho các lần truyền tuần tự lớn là 1 MiB, thì GPFS được định dạng với kích thước khối là 8 MiB; do đó, hãy sử dụng giá trị đó hoặc bội số của nó trên điểm chuẩn để có hiệu suất tối ưu. Kích thước khối 8 MiB có vẻ quá lớn và lãng phí quá nhiều dung lượng khi sử dụng các tệp nhỏ, nhưng GPFS sử dụng phân bổ khối con để ngăn tình trạng đó. Trong cấu hình hiện tại, mỗi khối được chia thành 512 khối con, mỗi khối 16 KiB. 

Các lệnh sau được sử dụng để chạy điểm chuẩn cho thao tác ghi và thao tác đọc, trong đó  biến Chủ đề  là số lượng luồng được sử dụng (1 đến 512 tăng dần theo lũy thừa của 2) và  danh sách luồng  là tệp phân bổ mỗi luồng trên một nút khác nhau , sử dụng vòng tròn để trải đều chúng trên 16 nút điện toán. Biến  Kích thước tệp  có kết quả là 8192 (GiB)/Luồng để chia đều tổng kích thước dữ liệu cho tất cả các luồng được sử dụng. Kích thước truyền 16 MiB đã được sử dụng cho đặc tính hiệu suất này.

./iozone -i0 -c -e -w -r 16M -s ${FileSize}G -t $Threads -+n -+m ./threadlist

./iozone -i1 -c -e -w -r 16M -s ${FileSize}G -t $Threads -+n -+m ./threadlist

Hình 22.     Hiệu suất tuần tự từ N đến N

Từ kết quả, chúng tôi thấy rằng hiệu suất tăng lên nhanh chóng với số lượng máy khách được sử dụng và sau đó đạt đến mức ổn định cho đến khi đạt được số lượng luồng tối đa mà IOzone cho phép; do đó, hiệu suất tuần tự tệp lớn ổn định ngay cả đối với 1024 máy khách đồng thời. Lưu ý rằng cả hiệu suất đọc và ghi đều được hưởng lợi từ việc tăng gấp đôi số lượng ổ đĩa; hiệu suất ghi chỉ được hưởng lợi một chút và hiệu suất đọc được hưởng lợi đáng kể. Hiệu suất đọc tối đa bị giới hạn bởi băng thông của bộ điều khiển ME4084 được sử dụng trên các nút lưu trữ bắt đầu từ bốn luồng. Hiệu suất ghi tối đa tăng lên 21,6 GB/giây ở 8 luồng và 128 luồng và nó gần với thông số kỹ thuật tối đa của mảng ME4 (22 GB/giây).

Hãy nhớ rằng đối với GPFS, phương thức hoạt động ưa thích bị phân tán và giải pháp được định dạng để sử dụng nó. Trong chế độ này, các khối dữ liệu được phân bổ ngay sau khi tạo hệ thống tệp theo kiểu giả ngẫu nhiên, trải rộng dữ liệu trên toàn bộ bề mặt của mỗi ổ cứng. Mặc dù nhược điểm rõ ràng là hiệu suất tối đa ban đầu thấp hơn, nhưng hiệu suất đó vẫn không đổi bất kể bao nhiêu dung lượng được sử dụng trên hệ thống tệp. Kết quả này trái ngược với các hệ thống tệp song song khác ban đầu sử dụng các rãnh bên ngoài có thể chứa nhiều dữ liệu hơn (các cung) trên mỗi vòng quay của đĩa. Do đó, các hệ thống tệp này có hiệu suất cao nhất có thể mà ổ cứng có thể cung cấp. Khi hệ thống sử dụng nhiều không gian hơn, các rãnh bên trong có ít dữ liệu hơn trên mỗi vòng quay sẽ được sử dụng, dẫn đến giảm hiệu suất.

Hiệu suất IOR tuần tự N máy khách thành 1 tệp

Hiệu suất của N máy khách tuần tự cho một tệp được chia sẻ duy nhất được đo bằng IOR phiên bản 3.3.0 với  OpenMPI  v4.1.2A1 để chạy điểm chuẩn trên 16 nút điện toán. Các thử nghiệm mà chúng tôi đã chạy đa dạng từ một luồng đơn lên đến 512 luồng vì không có đủ lõi cho 1024 luồng (16 máy khách có tổng cộng 16 x 2 x 20 = 640 lõi). Ngoài ra, chi phí đăng ký quá mức dường như ảnh hưởng đến kết quả IOzone ở 1024 luồng.

Hiệu ứng bộ nhớ đệm được giảm thiểu bằng cách đặt nhóm trang GPFS có thể điều chỉnh thành 32 GiB trên máy khách và 96 GiB trên máy chủ, đồng thời sử dụng tổng kích thước dữ liệu là 8 TiB, nhiều hơn gấp đôi kích thước RAM từ máy chủ và máy khách cộng lại. Kích thước truyền 16 MiB đã được sử dụng cho đặc tính hiệu suất này. Phần kiểm tra hiệu suất trước đây cung cấp giải thích đầy đủ hơn. 

Các lệnh sau được sử dụng để chạy điểm chuẩn, trong đó  biến Chủ đề  là số lượng luồng được sử dụng (1 đến 512 tăng dần theo lũy thừa của 2) và  my_hosts.$Threads  là tệp tương ứng phân bổ mỗi luồng trên một nút khác nhau, sử dụng phương pháp quay vòng để trải chúng đồng nhất trên 16 nút tính toán. Biến  FileSize  có kết quả là 8192 (GiB)/Chủ đề để chia đều tổng kích thước dữ liệu cho tất cả các luồng được sử dụng. 

mpirun –allow-run-as-root -np $Threads –hostfile my_hosts.$Threads –mca btl_openib_allow_ib 1 –mca pml ^ucx –oversubscribe –prefix /usr/mpi/gcc/openmpi-4.1.2a1 /usr/local/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/ior/tst.file -w -s 1 -t 16m -b ${FileSize}G 

mpirun –allow-run-as-root -np $Threads –hostfile my_hosts.$Threads –mca btl_openib_allow_ib 1 –mca pml ^ucx –oversubscribe –prefix /usr/mpi/gcc/openmpi-4.1.2a1 / usr/local/bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/ior/tst.file -r -s 1 -t 16m -b ${FileSize}G

Hình 23.     Hiệu suất tuần tự từ N đến 1

Từ kết quả, một lần nữa chúng tôi thấy rằng các ổ đĩa bổ sung mang lại lợi ích rất lớn cho việc đọc và chỉ mang lại lợi ích nhỏ cho hiệu suất ghi. Hiệu suất tăng trở lại nhanh chóng với số lượng máy khách được sử dụng và sau đó đạt đến mức ổn định để đọc và ghi cho đến số lượng luồng tối đa được sử dụng trong thử nghiệm này. Lưu ý rằng hiệu suất đọc tối đa là 27,9 GB/giây ở 16 luồng và nút cổ chai là bộ điều khiển ME4. Hiệu suất ghi tối đa là 21,7 GB/giây đã đạt được ở 16 luồng và được giữ nguyên.

Các khối nhỏ ngẫu nhiên Hiệu suất IOzone N máy khách thành N tệp

Hiệu suất N máy khách ngẫu nhiên đến N tệp được đo bằng IOzone phiên bản 3.492. Các thử nghiệm mà chúng tôi đã chạy đa dạng từ 4 đến 512 luồng, sử dụng 4 khối KiB để mô phỏng lưu lượng khối nhỏ. Số lượng luồng thấp hơn không được sử dụng vì chúng cung cấp ít thông tin về hiệu suất duy trì tối đa và thời gian thực hiện có thể mất vài ngày cho một điểm dữ liệu (IOzone không cung cấp tùy chọn chạy riêng các thao tác đọc và ghi ngẫu nhiên). Lý do cho hiệu suất đọc ngẫu nhiên thấp là do không có đủ áp lực I/O để lập lịch hoạt động đọc do tác động kết hợp của hoạt động của bộ lập lịch I/O thời hạn mq trên hệ điều hành Linux và bộ điều khiển mảng ME4 bên trong phần mềm, trì hoãn hoạt động đọc cho đến khi đạt đến ngưỡng.

Chúng tôi đặt nhóm trang GPFS có thể điều chỉnh thành 16 GiB trên máy khách và 32 GiB trên máy chủ, đồng thời sử dụng các tệp có kích thước gấp đôi kích thước đó để giảm thiểu tác động của bộ nhớ đệm. Phần Sequential IOzone Performance cung cấp giải thích đầy đủ về lý do tại sao điều này lại hiệu quả trên GPFS. 

Lệnh sau được sử dụng để chạy điểm chuẩn ở chế độ IO ngẫu nhiên cho cả thao tác đọc và ghi, trong đó  biến Chủ đề  là số lượng luồng được sử dụng (4 đến 512 tăng dần theo lũy thừa của 2) và  danh sách luồng  là tệp đã phân bổ từng luồng trên một nút khác, sử dụng phương pháp vòng tròn để trải chúng đồng nhất trên 16 nút tính toán:

./iozone -i0 -c -e -w -r 16M -s ${Size}G -t $Threads -+n -+m ./threadlist

./iozone -i2 -O -w -r 4K -s ${Size}G -t $Threads -+n -+m ./threadlist

Hình 24.     Hiệu suất Ngẫu nhiên N đến N

Từ kết quả, chúng tôi thấy rằng hiệu suất ghi bắt đầu ở giá trị cao 23,1K IOps ở bốn luồng và duy trì ở mức đó cho đến khi đột ngột tăng lên ở 256 luồng và đạt mức cao nhất là 34,2K IOPS ở 512 luồng. Hành vi này không được mong đợi và cần thử nghiệm thêm để hiểu lý do. Cho đến lúc đó, tốt nhất là giả định rằng đỉnh từ pixstor 5 là giá trị an toàn hơn để sử dụng cho kích thước của giải pháp.

Hiệu suất đọc bắt đầu ở mức 322 IOPS ở bốn luồng và tăng hiệu suất gần như tuyến tính với số lượng máy khách được sử dụng (lưu ý rằng số lượng luồng được nhân đôi cho mỗi điểm dữ liệu) và đạt hiệu suất tối đa là 32,33K IOPS ở 512 luồng. Việc sử dụng nhiều luồng hơn số lượng lõi trên 16 nút tính toán hiện tại (640) có thể khiến bạn phải chuyển ngữ cảnh nhiều hơn.

Hiệu suất siêu dữ liệu 

Trong khi  mô tả giải pháp với pixstor 5, kết quả cho các tệp trống cho thấy rằng hiệu suất siêu dữ liệu được đo bằng MDtest phiên bản 3.3.0 và OpenMPI v4.0.1 gần như giống nhau đối với hệ thống có hoặc không có bản mở rộng ME484. Lý do là các tệp trống được tạo hoàn toàn bên trong các nút để các nút lưu trữ và mảng ME4084 hoàn toàn không được sử dụng. Hơn nữa, việc sử dụng các tệp nhỏ 4 KiB không vừa hoàn toàn bên trong các nút, cho thấy rằng kết quả có hoặc không có phần mở rộng sẽ khác nhau một chút. Do đó, chỉ có đặc tính trước đó được bao gồm trong hiệu suất siêu dữ liệu với MDtest mà không có phần mở rộng ME484 là có trong tài liệu này. Thay vì sao chép kết quả, siêu dữ liệu trên các thiết bị NVMe sử dụng một cặp máy chủ PowerEdge R650 với 10 thiết bị mỗi máy được mô tả. Mô-đun HDMD mới dày đặc hơn gấp ba lần, có hiệu suất cao hơn, và tiết kiệm chi phí hơn do giá cấp phép cho mỗi ổ đĩa (24 ổ đĩa trên mảng ME4024 so với 20 ổ đĩa trên mỗi cặp máy chủ PowerEdge R650). Thấy Bậc NVMe mới  để biết thông tin về đặc điểm này và phần còn lại của công việc NVMe.

Tóm lược

Giải pháp hiện tại mang lại hiệu suất tốt, dự kiến ​​sẽ ổn định bất kể dung lượng hệ thống tệp đã sử dụng (vì hệ thống được định dạng ở chế độ phân tán), như được hiển thị trong bảng sau. Giải pháp thay đổi quy mô về dung lượng và hiệu suất một cách tuyến tính khi thêm nhiều mô-đun nút lưu trữ và có thể mong đợi mức tăng hiệu suất tương tự từ HDMD tùy chọn.

Bảng 6.       Hiệu suất cao nhất và duy trì