Giới thiệu

Môi trường HPC ngày nay có nhu cầu lưu trữ tốc độ rất cao ngày càng tăng và với số lượng CPU cao hơn, mạng nhanh hơn và bộ nhớ lớn hơn, lưu trữ đang trở thành nút cổ chai trong nhiều khối lượng công việc. Các yêu cầu HPC có nhu cầu cao đó thường được bao phủ bởi Hệ thống tệp song song (PFS) cung cấp quyền truy cập đồng thời vào một tệp hoặc một tập hợp tệp từ nhiều nút, phân phối dữ liệu rất hiệu quả và an toàn cho nhiều LUN trên một số máy chủ. Các hệ thống tệp đó thường dựa trên phương tiện quay để cung cấp dung lượng cao nhất với chi phí thấp nhất. Tuy nhiên, tốc độ và độ trễ của phương tiện kéo sợi ngày càng thường xuyên không thể theo kịp nhu cầu của nhiều khối lượng công việc HPC hiện đại, đòi hỏi phải sử dụng công nghệ flash dưới dạng bộ đệm liên tục, tầng nhanh hơn hoặc thậm chí là cào, cục bộ hoặc được phân phối. Các Giải pháp Sẵn sàng của DellEMC cho Bộ lưu trữ HPC PixStor sử dụng các nút NVMe làm thành phần để đáp ứng nhu cầu băng thông cao mới như vậy bên cạnh tính linh hoạt, khả năng mở rộng, hiệu quả và đáng tin cậy.

Giải pháp xây dựng

Blog này là một phần của chuỗi các giải pháp Hệ thống tệp song song (PFS) dành cho môi trường HPC, đặc biệt là Giải pháp sẵn sàng của DellEMC cho Bộ lưu trữ HPC PixStor , trong đó các máy chủ DellEMC PowerEdge R640 có ổ đĩa NVMe được sử dụng làm tầng dựa trên flash nhanh.
Giải pháp PixStor PFS bao gồm Hệ thống tệp song song chung phổ biến còn được gọi là Thang đo phổ. ArcaStream cũng bao gồm nhiều thành phần phần mềm khác để cung cấp phân tích nâng cao, quản trị và giám sát đơn giản hóa, tìm kiếm tệp hiệu quả, khả năng cổng nâng cao, v.v.

Các nút NVMe được trình bày trong blog này cung cấp một tầng dựa trên flash hiệu suất rất cao cho giải pháp PixStor. Hiệu suất và dung lượng cho tầng NVMe này có thể được mở rộng bằng các nút NVMe bổ sung. Dung lượng tăng lên được cung cấp bằng cách chọn các thiết bị NVMe thích hợp được hỗ trợ trong PowerEdge R640.

Hình 1 trình bày kiến ​​trúc tham chiếu mô tả một giải pháp với 4 nút NVMe sử dụng mô-đun siêu dữ liệu có nhu cầu cao, xử lý tất cả siêu dữ liệu trong cấu hình được thử nghiệm. Lý do là hiện tại các nút NVMe này được sử dụng làm mục tiêu Lưu trữ chỉ dành cho dữ liệu. Tuy nhiên, các nút NVMe cũng có thể được sử dụng để lưu trữ dữ liệu và siêu dữ liệu, hoặc thậm chí là một giải pháp thay thế flash nhanh hơn cho mô-đun siêu dữ liệu có nhu cầu cao, nếu yêu cầu siêu dữ liệu cao. Các cấu hình đó cho các nút NVMe chưa được thử nghiệm như một phần của công việc này, nhưng sẽ được thử nghiệm trong tương lai.

Hình 1 Kiến trúc tham khảo

Thành phần giải pháp

Giải pháp này sử dụng CPU Xeon có thể mở rộng thế hệ ^thứ 2 mới nhất của Intel Xeon , hay còn gọi là CPU Cascade Lake và RAM nhanh nhất hiện có (2933 MT/s), ngoại trừ các nút quản lý để giữ cho chúng tiết kiệm chi phí. Ngoài ra, giải pháp đã được cập nhật lên phiên bản PixStor mới nhất (5.1.3.1) hỗ trợ RHEL 7.7 và OFED 5.0, đây sẽ là các phiên bản phần mềm được hỗ trợ tại thời điểm phát hành.

Mỗi nút NVMe có tám thiết bị Dell P4610 được định cấu hình là tám thiết bị RAID 10 trên một cặp máy chủ, sử dụng giải pháp NVMe over Fabric để cho phép dự phòng dữ liệu không chỉ ở cấp thiết bị mà còn ở cấp máy chủ. Ngoài ra, khi bất kỳ dữ liệu nào đi vào hoặc ra khỏi một trong những thiết bị RAID10 đó, tất cả 16 ổ đĩa trong cả hai máy chủ đều được sử dụng, làm tăng băng thông truy cập băng thông của tất cả các ổ đĩa. Do đó, hạn chế duy nhất đối với các thành phần này là chúng phải được bán và sử dụng theo cặp. Tất cả các ổ NVMe được PowerEdge R640 hỗ trợ đều có thể được sử dụng trong giải pháp này, tuy nhiên, P4610 có băng thông tuần tự là 3200 MB/giây cho cả đọc và ghi, cũng như thông số kỹ thuật IOPS ngẫu nhiên cao, đây là những tính năng tuyệt vời khi cố gắng mở rộng quy mô ước tính số lượng cặp cần thiết để đáp ứng các yêu cầu của tầng flash này.

Mỗi máy chủ R640 có hai HCAs Mellanox ConnectX-6 Single Port VPI HDR100 được sử dụng làm kết nối IB EDR 100 Gb. Tuy nhiên, các nút NVMe sẵn sàng hỗ trợ tốc độ HDR100 khi được sử dụng với cáp và công tắc HDR. Thử nghiệm HDR100 trên các nút này được tạm hoãn như một phần của bản cập nhật HDR100 cho toàn bộ giải pháp PixStor. Cả hai giao diện CX6 đều được sử dụng để đồng bộ hóa dữ liệu cho RAID 10 (NVMe over fabric) và làm kết nối cho hệ thống tệp. Ngoài ra, chúng còn cung cấp dự phòng phần cứng ở bộ điều hợp, cổng và cáp. Để dự phòng ở cấp độ chuyển đổi, cần có bộ điều hợp CX6 VPI cổng kép, nhưng cần được mua dưới dạng các thành phần S&P.
Để mô tả hiệu suất của các nút NVMe, từ hệ thống được mô tả trong hình 1, chỉ mô-đun siêu dữ liệu có nhu cầu cao và các nút NVMe được sử dụng.

Bảng 1 có danh sách các thành phần chính cho giải pháp. Từ danh sách các ổ đĩa được hỗ trợ trong ME4024, SSD 960Gb được sử dụng cho siêu dữ liệu và là ổ đĩa được sử dụng để mô tả đặc tính hiệu suất, đồng thời các ổ đĩa nhanh hơn có thể cung cấp IOP ngẫu nhiên tốt hơn và có thể cải thiện hoạt động tạo/xóa siêu dữ liệu. Tất cả thiết bị NVMe được hỗ trợ trên PowerEdge R640 sẽ được hỗ trợ cho các nút NVMe.

Bảng 1 Các thành phần được sử dụng tại thời điểm xuất xưởng và những thành phần được sử dụng trên giường thử nghiệm

Đặc tính hiệu suất

Để mô tả thành phần Giải pháp sẵn sàng mới này , các điểm chuẩn sau đã được sử dụng:

•        IOzone N đến N tuần tự
  ·        IOR N đến 1 tuần tự
  ·        IOzone ngẫu nhiên
  ·        MDtest

Đối với tất cả các điểm chuẩn được liệt kê ở trên, giường thử nghiệm có các khách hàng như được mô tả trong Bảng 2phía dưới. Vì số lượng nút điện toán có sẵn để thử nghiệm chỉ là 16, nên khi cần số lượng luồng cao hơn, các luồng đó sẽ được phân bổ đồng đều trên các nút điện toán (tức là 32 luồng = 2 luồng trên mỗi nút, 64 luồng = 4 luồng trên mỗi nút, 128 luồng = 8 luồng trên mỗi nút, 256 luồng = 16 luồng trên mỗi nút, 512 luồng = 32 luồng trên mỗi nút, 1024 luồng = 64 luồng trên mỗi nút). Mục đích là để mô phỏng số lượng máy khách đồng thời cao hơn với số lượng hạn chế các nút điện toán có sẵn. Do một số điểm chuẩn hỗ trợ số lượng lớn luồng nên giá trị tối đa lên tới 1024 đã được sử dụng (được chỉ định cho từng thử nghiệm), đồng thời tránh chuyển đổi ngữ cảnh quá mức và các tác dụng phụ liên quan khác ảnh hưởng đến kết quả hoạt động.

Bảng 2 Giường thử nghiệm khách hà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.487. Các thử nghiệm được thực hiện đa dạng từ một luồng cho đến 1024 luồng theo lũy thừa của hai.

Hiệu ứng bộ nhớ đệm trên các máy chủ đã được giảm thiểu bằng cách đặt nhóm trang GPFS có thể điều chỉnh thành 16GiB và sử dụng các tệp lớn hơn hai lần kích thước đó. Điều quan trọng cần lưu ý là đối với GPFS, tính năng có thể điều chỉnh sẽ đặt dung lượng bộ nhớ tối đa được sử dụng để lưu vào bộ nhớ đệm dữ liệu, bất kể dung lượng RAM được cài đặt và dung lượng trống. Ngoài ra, điều quan trọng cần lưu ý là trong khi ở các giải pháp DellEMC HPC trước đây, 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 bằng các khối 8 MiB và do đó, giá trị đó được sử dụng trên điểm chuẩn để có hiệu suất tối ưu. Điều đó có thể trông quá lớn và dường như lãng phí quá nhiều không gian, nhưng GPFS sử dụng phân bổ khối con để ngăn chặn tình trạng đó. Trong cấu hình hiện tại, mỗi khối được chia thành 256 khối con với 32 KiB mỗi khối.

Các lệnh sau được sử dụng để thực thi điểm chuẩn cho ghi và đọc, trong đó $Threads 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 hai) 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 vòng tròn để trải đều chúng trên 16 nút điện toán.

Để tránh bất kỳ hiệu ứng lưu trữ dữ liệu nào có thể xảy ra từ các máy khách, tổng kích thước dữ liệu của các tệp gấp đôi tổng dung lượng RAM trong các máy khách được sử dụng. Nghĩa là, vì mỗi máy khách có 128 GiB RAM, đối với số lượng luồng bằng hoặc trên 16 luồng , kích thước tệp là 4096 GiB chia cho số lượng luồng (biến $Size bên dưới được sử dụng để quản lý giá trị đó). Đối với những trường hợp có ít hơn 16 luồng (có nghĩa là mỗi luồng đang chạy trên một máy khách khác nhau), kích thước tệp được cố định ở mức gấp đôi dung lượng bộ nhớ trên mỗi máy khách hoặc 256 GiB.

iozone -i0 -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./threadlist
iozone -i1 -c -e -w -r 8M -s $ G -t $Threads – +n -+m ./threadlist

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

Từ các kết quả, chúng tôi có thể quan sát thấy rằng hiệu suất ghi tăng theo số lượng luồng được sử dụng và sau đó đạt đến mức ổn định ở khoảng 64 luồng để ghi và 128 luồng để đọc. Sau đó, hiệu suất đọc cũng tăng nhanh theo số lượng luồng và sau đó duy trì ổn định cho đến khi đạt đến số lượng luồng tối đa mà IOzone cho phép và do đó, hiệu suất tuần tự của tệp lớn ổn định ngay cả đối với 1024 máy khách đồng thời. Hiệu suất ghi giảm khoảng 10% ở 1024 luồng. Tuy nhiên, vì cụm máy khách có ít hơn số lõi đó, nên không chắc liệu hiệu suất giảm có phải do hoán đổi và chi phí hoạt động tương tự không được quan sát thấy trong phương tiện quay (vì độ trễ NVMe rất thấp so với phương tiện quay) hay không Đồng bộ hóa dữ liệu RAID 10 đang trở thành nút cổ chai. Cần nhiều khách hàng hơn để làm rõ điểm đó. Một điểm bất thường trong số lần đọc đã được quan sát thấy ở 64 luồng, trong đó hiệu suất không mở rộng theo tốc độ được quan sát cho các điểm dữ liệu trước đó và sau đó, điểm dữ liệu tiếp theo di chuyển đến một giá trị rất gần với hiệu suất được duy trì. Cần thử nghiệm thêm để tìm ra lý do cho sự bất thường như vậy nhưng nằm ngoài phạm vi của blog này.

Hiệu suất đọc tối đa cho các lần đọc thấp hơn hiệu suất lý thuyết của thiết bị NVMe (~102 GB/giây) hoặc hiệu suất của các liên kết EDR, ngay cả khi giả sử rằng một liên kết được sử dụng chủ yếu cho lưu lượng truy cập vải của NVMe (4x EDR BW ~96 GB /S).
Tuy nhiên, điều này không có gì ngạc nhiên vì cấu hình phần cứng không cân bằng đối với các thiết bị NVMe và IB HCAs dưới mỗi ổ cắm CPU. Một bộ điều hợp CX6 nằm trong CPU1, trong khi CPU2 có tất cả các thiết bị NVMe và bộ điều hợp CX6 thứ hai. Bất kỳ lưu lượng lưu trữ nào sử dụng HCA đầu tiên đều phải sử dụng UPI để truy cập các thiết bị NVMe. Ngoài ra, bất kỳ lõi nào trong CPU1 được sử dụng đều phải truy cập vào thiết bị hoặc bộ nhớ được gán cho CPU2, do đó, vị trí dữ liệu bị ảnh hưởng và các liên kết UPI được sử dụng. Điều đó có thể giải thích cho việc giảm hiệu suất tối đa, so với hiệu suất tối đa của thiết bị NVMe hoặc tốc độ đường truyền cho CX6 HCAs.

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

Hiệu suất N máy khách tuần tự cho một tệp chia sẻ duy nhất được đo bằng IOR phiên bản 3.3.0, được hỗ trợ bởi OpenMPI v4.0.1 để chạy điểm chuẩn trên 16 nút điện toán. Các thử nghiệm được thực hiện đa dạng từ một luồng cho đến 512 luồng do không có đủ lõi cho 1024 luồng trở lên. Bài kiểm tra điểm chuẩn này đã sử dụng 8 khối MiB để có hiệu suất tối ưu. Phần kiểm tra hiệu suất trước đó có giải thích đầy đủ hơn về lý do tại sao điều đó lại quan trọng.

Hiệu ứng bộ nhớ đệm dữ liệu đã được giảm thiểu bằng cách đặt nhóm trang GPFS có thể điều chỉnh thành 16GiB và tổng kích thước tệp gấp đôi tổng dung lượng RAM trong các máy khách được sử dụng. Nghĩa là, vì mỗi máy khách có 128 GiB RAM, đối với số luồng bằng hoặc trên 16 luồng, kích thước tệp là 4096 GiB và một lượng bằng nhau của tổng đó được chia cho số luồng (biến $Size bên dưới được sử dụng để quản lý giá trị đó). Đối với những trường hợp có ít hơn 16 luồng (có nghĩa là mỗi luồng đang chạy trên một máy khách khác nhau), kích thước tệp gấp đôi dung lượng bộ nhớ mà mỗi máy khách đã sử dụng nhân với số luồng hoặc nói cách khác, mỗi luồng được yêu cầu sử dụng 256 GiB.

Các lệnh sau đây được sử dụng để thực thi điểm chuẩn cho ghi và đọc, trong đó $Threads 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 hai) và my_hosts.$Threads là tệp tương ứng đã phân bổ từng luồng trên một nút khác, sử dụng vòng tròn để trải đều chúng đồng nhất trên 16 nút điện toán.

mpirun –allow-run-as-root -np $Threads –hostfile my_hosts.$Threads –mca btl_openib_allow_ib 1 –mca pml ^ucx –oversubscribe –prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior /bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -w -s 1 -t 8m -b $ G

mpirun –allow-run-as-root -np $Threads –hostfile my_hosts.$Threads –mca btl_openib_allow_ib 1 –mca pml ^ucx –oversubscribe –prefix /mmfs1/perftest/ompi /mmfs1/perftest/lanl_ior /bin/ior -a POSIX -v -i 1 -d 3 -e -k -o /mmfs1/perftest/tst.file -r -s 1 -t 8m -b $ G

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

Từ các kết quả, chúng tôi có thể quan sát thấy hiệu suất đọc và ghi cao bất kể nhu cầu ẩn về cơ chế khóa do tất cả các luồng đều truy cập vào cùng một tệp. Hiệu suất tăng trở lại rất nhanh với số lượng luồng được sử dụng và sau đó đạt đến mức ổn định tương đối ổn định đối với các lần đọ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à 51,6 GB/giây ở 512 luồng, nhưng hiệu suất cao nhất đạt được ở khoảng 64 luồng. Tương tự, hãy lưu ý rằng hiệu suất ghi tối đa là 34,5 GB/giây đã đạt được ở 16 luồng và đạt đến mức ổn định có thể quan sát được cho đến khi sử dụng số lượng luồng tối đa.

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.487. Các thử nghiệm được thực hiện đa dạng từ một luồng cho đến 1024 luồng theo lũy thừa của hai.

Các thử nghiệm được thực hiện đa dạng từ một luồng cho đến 512 luồng do không có đủ lõi máy khách cho 1024 luồng. Mỗi luồng đang sử dụng một tệp khác nhau và các luồng được chỉ định luân phiên trên các nút máy khách. Bài kiểm tra điểm chuẩn này đã sử dụng 4 khối KiB để mô phỏng lưu lượng khối nhỏ và sử dụng độ sâu hàng đợi là 16. Kết quả từ giải pháp kích thước lớn và khả năng mở rộng dung lượng được so sánh.

Hiệu ứng bộ nhớ đệm một lần nữa được giảm thiểu bằng cách đặt nhóm trang GPFS có thể điều chỉnh thành 16GiB và để tránh bất kỳ hiệu ứng bộ đệm dữ liệu nào có thể xảy ra từ máy khách, tổng kích thước dữ liệu của tệp gấp đôi tổng dung lượng RAM trong máy khách được sử dụng. Nghĩa là, vì mỗi máy khách có 128 GiB RAM, đối với số lượng luồng bằng hoặc trên 16 luồng, kích thước tệp là 4096 GiB chia cho số lượng luồng (biến $Size bên dưới được sử dụng để quản lý giá trị đó). Đối với những trường hợp có ít hơn 16 luồng (có nghĩa là mỗi luồng đang chạy trên một máy khách khác nhau), kích thước tệp được cố định ở mức gấp đôi dung lượng bộ nhớ trên mỗi máy khách hoặc 256 GiB.

iozone -i0 -I -c -e -w -r 8M -s $ G -t $Threads -+n -+m ./nvme_threadlist <= Tạo các tệp tuần tự
iozone -i2 -I -c -O -w -r 4k -s $ G -t $Threads -+n -+m ./nvme_threadlist <= Thực hiện đọc và ghi ngẫu nhiên.

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

Từ kết quả, chúng tôi có thể quan sát thấy rằng hiệu suất ghi bắt đầu ở giá trị cao là 6K IOps và tăng dần lên đến 1024 luồng, nơi có vẻ như đạt đến mức ổn định với hơn 5M IOPS nếu có thể sử dụng nhiều luồng hơn. Mặt khác, hiệu suất đọc bắt đầu ở 5K IOPS và tăng hiệu suất đều đặn với số lượng luồng được sử dụng (hãy nhớ 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à 7,3M IOPS ở 1024 luồng mà không có dấu hiệu đạt đến một cao nguyên. Việc sử dụng nhiều luồng hơn sẽ yêu cầu nhiều hơn 16 nút tính toán để tránh tình trạng cạn kiệt tài nguyên và hoán đổi quá mức có thể làm giảm hiệu suất rõ ràng, trong đó các nút NVMe trên thực tế có thể duy trì hiệu suất.

Hiệu suất siêu dữ liệu với MDtest bằng 4 tệp KiB

Hiệu suất siêu dữ liệu được đo bằng MDtest phiên bản 3.3.0, được hỗ trợ bởi OpenMPI v4.0.1 để chạy điểm chuẩn trên 16 nút tính toán. Các thử nghiệm được thực hiện đa dạng từ một luồng cho đến 512 luồng. Điểm chuẩn chỉ được sử dụng cho các tệp (không có siêu dữ liệu thư mục), nhận số lần tạo, thống kê, đọc và xóa mà giải pháp có thể xử lý và kết quả tương phản với giải pháp Kích thước lớn.

Mô-đun siêu dữ liệu nhu cầu cao tùy chọn đã được sử dụng, nhưng với một mảng ME4024 duy nhất, ngay cả khi cấu hình lớn và được thử nghiệm trong công việc này được chỉ định là có hai ME4024. Lý do sử dụng mô-đun siêu dữ liệu đó là vì hiện tại các nút NVMe này chỉ được sử dụng làm mục tiêu Lưu trữ cho dữ liệu. Tuy nhiên, các nút có thể được sử dụng để lưu trữ dữ liệu và siêu dữ liệu, hoặc thậm chí như một giải pháp thay thế nhanh cho mô-đun siêu dữ liệu có nhu cầu cao, nếu nhu cầu siêu dữ liệu cực cao đòi hỏi. Những cấu hình đó không được kiểm tra như một phần của công việc này.

Vì cùng một mô-đun Siêu dữ liệu có nhu cầu cao đã được sử dụng để đo điểm chuẩn trước đây của Giải pháp DellEMC Sẵn sàng cho giải pháp Lưu trữ HPC PixStor, kết quả siêu dữ liệu sẽ rất giống với kết quả blog trước đó. Vì lý do đó, nghiên cứu với các tệp trống đã không được thực hiện mà thay vào đó, 4 tệp KiB đã được sử dụng. Vì các tệp 4KiB không thể vừa với một inode cùng với thông tin siêu dữ liệu, nên các nút NVMe sẽ được sử dụng để lưu trữ dữ liệu cho từng tệp. Do đó, MDtest có thể đưa ra ý tưởng sơ bộ về hiệu suất của các tệp nhỏ đối với các lần đọc và phần còn lại của hoạt động siêu dữ liệu.

Lệnh sau được sử dụng để thực thi điểm chuẩn, trong đó $Threads là biến có số lượng luồng được sử dụng (1 đến 512 tăng dần theo lũy thừa của hai) 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 , sử dụng vòng tròn để trải đều chúng trên 16 nút điện toán. Tương tự như điểm chuẩn IO ngẫu nhiên, số lượng luồng tối đa được giới hạn ở 512, do không có đủ lõi cho 1024 luồng và việc chuyển ngữ cảnh sẽ ảnh hưởng đến kết quả, báo cáo một con số thấp hơn hiệu suất thực của giải pháp.

mpirun –allow-run-as-root -np $Threads –hostfile my_hosts.$Threads –prefix /mmfs1/perftest/ompi –mca btl_openib_allow_ib 1 /mmfs1/perftest/lanl_ior/bin/mdtest -v -d / mmfs1/perftest/ -i 1 -b $Directories -z 1 -L -I 1024 -y -u -t -F -w 4K -e 4K

Vì kết quả hiệu suất có thể bị ảnh hưởng bởi tổng số IOPS, số lượng tệp trên mỗi thư mục và số lượng luồng, nên chúng tôi đã quyết định giữ cố định tổng số tệp thành 2 tệp MiB (2^21 = 2097152), số số tệp trên mỗi thư mục được cố định ở mức 1024 và số lượng thư mục thay đổi khi số lượng luồng thay đổi như trong Bảng 3 .

Bảng 3 Phân phối MDtest của các tệp trên các thư mục

Hình 5 Hiệu suất siêu dữ liệu – 4 tệp KiB

Đầu tiên, lưu ý rằng thang đo được chọn là logarit với cơ số 10, để cho phép so sánh các hoạt động có sự khác biệt với một số bậc độ lớn; nếu không, một số hoạt động sẽ trông giống như một đường thẳng gần bằng 0 trên thang tuyến tính. Biểu đồ nhật ký với cơ số 2 có thể phù hợp hơn, vì số luồng được tăng theo lũy thừa 2, nhưng biểu đồ sẽ trông rất giống nhau và mọi người có xu hướng xử lý và ghi nhớ các số tốt hơn dựa trên lũy thừa 10.

Hệ thống nhận được kết quả rất tốt như đã báo cáo trước đó với các thao tác Stat đạt giá trị cao nhất ở 64 luồng với gần 6,9 triệu thao tác/giây và sau đó được giảm xuống đối với số lượng luồng cao hơn đạt đến mức ổn định. Hoạt động tạo đạt tối đa 113K thao tác/giây ở 512 luồng, do đó dự kiến ​​sẽ tiếp tục tăng nếu sử dụng nhiều nút máy khách (và lõi). Hoạt động Đọc và Xóa đạt mức tối đa ở 128 luồng, đạt mức cao nhất ở gần 705 nghìn thao tác/giây đối với Đọc và 370 nghìn thao tác/giây đối với thao tác xóa, sau đó chúng đạt đến mức ổn định. Các hoạt động của Stat có nhiều biến đổi hơn, nhưng một khi chúng đạt đến giá trị cao nhất, hiệu suất không giảm xuống dưới 3,2 triệu thao tác/giây đối với Stat. Tạo và Xóa sẽ ổn định hơn khi chúng đạt đến mức ổn định và duy trì trên 265K thao tác/giây đối với Xóa và 113K thao tác/giây đối với Tạo. Cuối cùng, số lần đọc đạt đến mức ổn định với hiệu suất trên 265K thao tác/giây.

Kết luận và công việc tương lai

Các nút NVMe là một phần bổ sung quan trọng cho giải pháp lưu trữ HPC nhằm cung cấp một tầng hiệu suất rất cao, với mật độ tốt, hiệu suất truy cập ngẫu nhiên rất cao và hiệu suất tuần tự rất cao. Hơn nữa, giải pháp mở rộng quy mô về công suất và hiệu suất một cách tuyến tính khi thêm nhiều mô-đun nút NVMe. Hiệu suất từ ​​các nút NVMe có thể được tổng quan trong Bảng 4 , dự kiến ​​sẽ ổn định và các giá trị đó có thể được sử dụng để ước tính hiệu suất cho một số nút NVMe khác nhau.
Tuy nhiên, hãy nhớ rằng mỗi cặp nút NVMe sẽ cung cấp một nửa số bất kỳ được hiển thị trong Bảng 4 .
Giải pháp này cung cấp cho khách hàng HPC một hệ thống tệp song song rất đáng tin cậy được sử dụng bởi nhiều cụm 500 HPC hàng đầu. Ngoài ra, nó cung cấp khả năng tìm kiếm đặc biệt, giám sát và quản lý nâng cao, đồng thời bổ sung các cổng tùy chọn cho phép chia sẻ tệp qua các giao thức tiêu chuẩn phổ biến như NFS, SMB và các giao thức khác tới nhiều máy khách nếu cần.

Bảng 4   Hiệu suất cao nhất và duy trì cho 2 cặp nút NVMe

Vì các nút NVMe chỉ được sử dụng cho dữ liệu, công việc khả thi trong tương lai có thể bao gồm việc sử dụng chúng cho dữ liệu và siêu dữ liệu và có một tầng dựa trên flash độc lập với hiệu suất siêu dữ liệu tốt hơn do băng thông cao hơn và độ trễ thấp hơn của thiết bị NVMe so với SSD SAS3 phía sau bộ điều khiển RAID. Ngoài ra, nếu khách hàng có nhu cầu siêu dữ liệu cực cao và yêu cầu giải pháp dày đặc hơn những gì mô-đun siêu dữ liệu nhu cầu cao có thể cung cấp, thì một số hoặc tất cả các thiết bị RAID 10 phân tán có thể được sử dụng cho siêu dữ liệu giống như cách mà các thiết bị RAID 1 trên ME4024 được sử dụng ngay bây giờ.
Một blog khác sắp được phát hành sẽ mô tả các nút Cổng PixStor, cho phép kết nối giải pháp PixStor với các mạng khác bằng giao thức NFS hoặc SMB và có thể mở rộng hiệu suất. Ngoài ra, giải pháp sẽ sớm được cập nhật lên HDR100 và dự kiến ​​sẽ có một blog khác nói về công việc đó.