Dell Validated Design cho HPC pixstor Storage—Giải pháp chung với Kalray (5)

Đối với điểm chuẩn này, chúng tôi đã sử dụng kết quả của cấu hình lớn (hai máy chủ PowerEdge R750 được kết nối với bốn mảng ME5084) với mô-đun HDMD tùy chọn (hai máy chủ PowerEdge R650, mỗi máy chủ có 10 ổ NVMe). Bảng 2 và Bảng 3 liệt kê các phiên bản phần mềm  được  sử  dụng  trên máy chủ và máy khách tương ứng.

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 bài kiểm tra mà chúng tôi đã chạy đa dạng từ một luồng đơn lẻ cho đến 1024 luồng.

Chúng tôi đã sử dụng các tệp đủ lớn để giảm thiểu tác động của bộ đệ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 (16 máy khách X 128 GiB RAM = 2 TiB và bao gồm cả máy chủ HDMD, 4 máy chủ X 256 GiB = 1 TiB, tổng cộng là 3 TiB). 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 16 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 HPC khác của Dell sử dụng 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 chặn tình trạng này. 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 các thao tác ghi và đọc, trong đó  Chủ đề  là biến có số lượng luồng được sử dụng (1 đến 1024 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 , sử dụng phương pháp vòng tròn để trải chúng đồng nhất trên 16 nút điện 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. 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 đọc cao hơn ở số lượng luồng thấp (>10 %) với mức cao nhất là 31,4 GB/giây ở tám luồng, cao hơn khoảng 36,7% so với hiệu suất cao nhất với mảng lưu trữ pixstor 6 và ME4. Hầu hết các điểm dữ liệu đều có sự cải thiện ít nhất 24 phần trăm và nhiều nhất là gần 43 phần trăm so với những gì chúng tôi quan sát được với mảng ME4 và một mức ổn định với hơn 27 GB/giây. Hiệu suất ghi gần như giống nhau đối với một và hai luồng. Ở tám luồng, hiệu suất ghi cao nhất là 28,5 GB/giây cao hơn 39% so với hiệu suất ghi cao nhất của ME4, đạt mức ổn định khoảng 27 GB/giây với các cải tiến từ 32% lên 46% so với mảng lưu trữ ME4.

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 được phân bổ ngay sau khi tạo hệ thống tệp theo kiểu giả ngẫu nhiên, truyền 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, nhưng khi hệ thống sử dụng nhiều dung lượng hơn, các rãnh bên trong có ít dữ liệu hơn trên mỗi vòng quay của ổ cứng 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.4.0, với  OpenMPI  v4.1 4RC1 để 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ả IOR ở 1024 luồng.

Hiệu ứng bộ nhớ đệm được giảm thiểu bằng cách đặt giá trị có thể điều chỉnh nhóm trang GPFS thành 16 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. Để có giải thích đầy đủ, hãy xem  Hiệu suất IOzone tuần tự N máy khách đến N tệp .

Các lệnh sau được sử dụng để chạy điểm chuẩn, trong đó  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 vòng -robin để phân tán chúng một cách đồng nhất trên 16 nút điện 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ả, chúng tôi thấy rằng hiệu suất đọc lại cao hơn ở số lượng luồng thấp (>13%) với mức cao nhất là 30,9 GB/giây ở 16 luồng, trong đó cao hơn khoảng 34,1% so với hiệu suất cao nhất với mảng pixstor 6 và ME4. Hầu hết các điểm dữ liệu đều có sự cải thiện từ 20% đến 38% so với những gì chúng tôi quan sát được với mảng ME4 và tốc độ ổn định khoảng 27 GB/giây (ngoại trừ trường hợp có 64 luồng, trong đó hiệu suất giảm liên tục khoảng 3 GB/giây, yêu cầu thêm cuộc điều tra). Hiệu suất ghi cho một và hai luồng cao so với mảng ME4, với 62 phần trăm và 53,6 phần trăm tương ứng. Ở 16 luồng, hiệu suất ghi cao nhất là 28,5 GB/giây, cao hơn 41,7% so với hiệu suất ghi cao nhất của ME4, đã đạt được tốc độ ổn định khoảng 27 GB/giây với các cải tiến từ 33 phần trăm lên gần 47 phần trăm so với mảng ME4. Hiệu suất ghi ở bốn luồng liên tục thấp hơn dự kiến, yêu cầu điều tra thêm về nguyên nhân có thể xảy ra.

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. Kết quả kiểm tra thay đổi từ 16 đế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ác lần đọc ngẫu nhiê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 ghi ngẫu nhiên riêng biệt từ các lần đọc). 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 mq-deadline trên hệ điều hành Linux và mảng ME5 nội bộ phần mềm điều khiển, trì hoãn hoạt động đọc cho đến khi đạt đến ngưỡ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 16 GiB trên máy khách và 32 GiB trên máy chủ và sử dụng ít nhất các tệp có kích thước gấp đôi kích thước đó. Hiệu suất IOzone tuần tự N máy khách đến N tệp  cung cấp lời giải thích đầy đủ về lý do tại sao phương pháp này có 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ả ghi và đọc, trong đó  Chủ đề  là biến có số lượng luồng được sử dụng (từ 16 đến 512 tăng theo lũy thừ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, 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.

./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 từ 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 gần 8K IOPS và đạt mức cao nhất là 15K IOPS ở hai luồng, giảm xuống mức ổn định khoảng 12K IOPS và đạt giá trị cao thứ hai là 14,4K IOPS ở 512 luồng . So với mảng ME4, hiệu suất ghi tương tự đối với số lượng luồng dưới 128 (trong phạm vi ±10 phần trăm); Mảng ME5 cho thấy sự cải thiện từ 12,2% ở 128 luồng lên 19,4% ở 512 luồng. Ngoài ra, hiệu suất đọc bắt đầu nhỏ ở 0,07K IOPS 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) cho đến khi đạt hiệu suất tối đa 21,3K IOPS ở 512 luồng có dấu hiệu của việc tiếp cận một mức tối đa. Tuy nhiên, việc sử dụng nhiều luồng hơn (1024) trên 16 nút tính toán hiện tại so với số lượng lõi (640) dường như gây ra chi phí hoạt động, điều này có thể hạn chế hiệu suất. Một thử nghiệm trong tương lai với nhiều nút tính toán hơn có thể kiểm tra hiệu suất đọc ngẫu nhiên có thể đạt được với 1024 luồng với IOzone. Ngoài ra, FIO hoặc IOR có thể được sử dụng để điều tra hành vi với hơn 1024 luồng. So với mảng ME4, hiệu suất đọc tương tự (trong phạm vi ± 5%), ngoại trừ ở 16 và 512 luồng, với mức cải thiện lần lượt là 50,7% và 15,4%.