Giải pháp Dell EMC Ready cho Bộ lưu trữ HPC PixStor – Mở rộng dung lượng

Giới thiệu

Các môi trường HPC ngày nay đã tăng nhu cầu lưu trữ tốc độ rất cao, điều này cũng thường yêu cầu dung lượng cao và truy cập phân tán thông qua một số giao thức tiêu chuẩn như NFS, SMB và các giao thức khá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 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ủ.

 

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

Blog này là giải pháp Hệ thống tệp song song (PFS) tiếp nối dành cho môi trường HPC, Giải pháp sẵn sàng của DellEMC cho Bộ lưu trữ HPC PixStor , trong đó các mảng PowerVault ME484 EBOD được sử dụng để tăng dung lượng của giải pháp. Hình 1 trình bày kiến ​​trúc tham chiếu mô tả các bổ sung SAS mở rộng dung lượng cho các mảng lưu trữ PowerVault ME4084 hiện có.
Giải pháp PixStor bao gồm Hệ thống tệp song song chung phổ biến còn được gọi là Quy mô quang phổ dưới dạng thành phần PFS, ngoài ra còn có nhiều thành phần phần mềm Arcastream khác như 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à nhiều thành phần khác.


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

 

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

Giải pháp này dự kiến ​​sẽ được phát hành cùng với CPU Xeon có khả năng 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à một số máy chủ sẽ sử dụng RAM nhanh nhất có sẵn cho chúng (2933 MT/s). Tuy nhiên, do phần cứng hiện tại có sẵn để hoạt động trên nguyên mẫu của giải pháp để mô tả hiệu năng, các máy chủ có CPU Xeon có thể mở rộng thế hệ thứ nhất của Intel Xeon hay còn gọi là bộ xử lý Skylake và trong một số trường hợp, RAM chậm hơn đã được sử dụng để mô tả hệ thống này. Do nút thắt cổ chai của giải pháp nằm ở bộ điều khiển SAS của mảng DellEMC PowerVault ME40x4, nên dự kiến ​​sẽ không có sự chênh lệch hiệu suất đáng kể nào sau khi CPU Skylake và RAM được thay thế bằng CPU Cascade Lake dự kiến ​​và RAM nhanh hơn. Ngoài ra, giải pháp đã được cập nhật lên phiên bản PixStor (5.1.1.4) mới nhất hỗ trợ RHEL 7.7 và OFED 4.

Do tình huống được mô tả trước đó, Bảng 1 có danh sách các thành phần chính của giải pháp, nhưng khi có sự khác biệt, cột mô tả đầu tiên có các thành phần được sử dụng tại thời điểm phát hành và do đó có sẵn cho khách hàng và cột cuối cùng là các thành phần thực sự được sử dụng để mô tả hiệu suất của giải pháp. Các ổ đĩa được liệt kê cho dữ liệu (12TB NLS) và siêu dữ liệu (SSD 960Gb) là những ổ đĩa được sử dụng để mô tả đặc tính hiệu suất và 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.

Cuối cùng, để đảm bảo tính đầy đủ, danh sách các ổ cứng HDD và SSD siêu dữ liệu có thể có đã được đưa vào, danh sách này dựa trên các ổ đĩa được hỗ trợ như được liệt kê trên ma trận hỗ trợ DellEMC PowerVault ME4, có sẵn trực tuyến.

Bảng 1 Các thành phần được sử dụng tại thời điểm phát hành 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ả Giải pháp sẵn sàng mới này, chúng tôi đã sử dụng phần cứng được chỉ định trong cột cuối cùng của Bảng 1, bao gồm Mô-đun siêu dữ liệu có nhu cầu cao tùy chọn. Để đánh giá hiệu suất của giải pháp, 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 2 bên 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 nút tính toán hạn chế. Do đ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 Khách hàng Giường thử nghiệm

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 khác nhau từ một luồng cho đến 1024 luồng và kết quả của giải pháp mở rộng dung lượng (4x ME4084s + 4x ME484s) tương phản với giải pháp kích thước lớn (4x ME4084s). 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 16GiB và sử dụng các tệp lớn hơn gấp 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 việ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 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 nhau, sử dụng vòng tròn để trải đều chúng trên 16 nút điện toán.

./iozone -i0 -c -e -w -r 8M -s 128G -t $Threads -+n -+m ./threadlist
./iozone -i1 -c -e -w -r 8M -s 128G -t $ Chủ đề -+n -+m ./threadlist

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

Từ kết quả, chúng tôi có thể quan sát thấy rằng hiệu suất tăng rất nhanh 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 đến số lượng luồng tối đa mà IOzone cho phép, và do đó, tệp tuần tự có dung lượng lớn hiệu suất ổn định ngay cả đối với 1024 khách hàng đồ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 đọc tối đa bị giới hạn bởi băng thông của hai liên kết IB EDR được sử dụng trên các nút lưu trữ bắt đầu từ 8 luồng và mảng ME4 có thể có sẵn một số hiệu suất bổ sung. Tương tự, lưu ý rằng hiệu suất ghi tối đa tăng từ tối đa 16,7 lên 20,4 GB/giây ở 64 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).

Ở đây, điều quan trọng cần nhớ là chế độ hoạt động ưa thích của GPFS bị phân tán và giải pháp được định dạng để sử dụng chế độ đó. Trong chế độ này, các khối được phân bổ ngay từ khi bắt đầu hoạt động 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 nhỏ hơn, nhưng hiệu suất đó được duy trì khá ổn định bất kể có bao nhiêu dung lượng được sử dụng trên hệ thống tệp. Điều đó 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 (khu vực) hơn trên mỗi vòng quay của đĩa và do đó 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 không gian hơn, các rãnh bên trong sẽ ít hơn. dữ liệu trên mỗi vòng quay được sử dụng, do đó làm 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 các ứng dụng khách N 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, đượ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 lên đến 512 luồng (vì không có đủ lõi cho 1024 luồng) và kết quả tương phản với giải pháp không có mở rộng dung lượ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 16GiB và sử dụng các tệp lớn hơn gấp hai lần kích thước đó. 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 cho những vấn đề đó.

Các lệnh sau đây được sử dụng để thực thi điểm chuẩn cho việc ghi và đọc, trong đó Chủ đề là biến có số lượng chủ đề đượ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ổ mỗi chủ đề trên một nút khác, sử dụng vòng tròn để trải chúng đồng nhất trên 16 nút tính 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 128G

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 128G

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

Từ kết quả, chúng ta có thể quan sát lại rằng các ổ đĩa bổ sung có lợi cho hiệu suất đọc và ghi. Hiệu suất tăng trở lại rất nhanh với số lượng máy khách được sử dụng và sau đó đạt đến mức ổn định khá ổ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à 24,8 GB/giây ở 16 luồng và nút thắt cổ chai là giao diện InfiniBand EDR, với mảng ME4 vẫn có sẵn một số hiệu suất bổ sung. Kể từ thời điểm đó, hiệu suất đọc giảm từ giá trị đó cho đến khi đạt đến mức cao nhất là khoảng 23,8 GB/giây. Tương tự, lưu ý rằng hiệu suất ghi tối đa là 19,3 đã đạt được ở 8 luồng và đạt đến mức ổn định.
 

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 của N máy khách ngẫu nhiên đến N tệp được đo bằng FIO phiên bản 3.7 thay vì Iozone truyền thống. Mục đích, như được liệt kê trong blog trước, là tận dụng Độ sâu hàng đợi lớn hơn để điều tra hiệu suất tối đa có thể mà mảng ME4084 có thể mang lại (các thử nghiệm trước đây cho các giải pháp ME4 khác nhau cho thấy mảng ME4084 cần nhiều áp suất IO hơn mà Iozone có thể cung cấp cho đạt đến giới hạn IO ngẫu nhiên của chúng).

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.

Các 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à sử dụng các tệp có kích thước gấp hai lần kích thước đó. Phần kiểm tra hiệu suất đầu tiên có giải thích đầy đủ hơn về lý do tại sao điều này lại hiệu quả trên GPFS.

 

Hình 4:  Hiệu suất ngẫu nhiên từ 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 29,1K IOps và tăng dần lên 64 luồng, nơi có vẻ như đạt đến mức ổn định ở khoảng 40K IOps. Mặt khác, hiệu suất đọc bắt đầu ở 1,4K 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 (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 25,6K IOPS ở 64 luồng trong đó dường như gần đạ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 cạn kiệt tài nguyên và hiệu suất rõ ràng thấp hơn, trong đó các mảng 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 các tệp trống

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.

Để đánh giá đúng giải pháp so với các giải pháp lưu trữ DellEMC HPC khác và các kết quả blog trước đó, 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 ME4024s. Mô-đun siêu dữ liệu có nhu cầu cao này có thể hỗ trợ tối đa bốn mảng ME4024 và nên tăng số lượng mảng ME4024 lên 4 trước khi thêm một mô-đun siêu dữ liệu khác. Các mảng ME4024 bổ sung dự kiến ​​sẽ tăng hiệu suất Siêu dữ liệu một cách tuyến tính với mỗi mảng bổ sung, ngoại trừ có thể đối với các hoạt động Stat (và Đọc đối với các tệp trống), vì các con số này rất cao, tại một số điểm, CPU sẽ trở thành nút cổ chai và hiệu suất sẽ không tiếp tục để tăng tuyến tính.

Lệnh sau được sử dụng để thực thi điểm chuẩn, trong đó Chủ đề là biến có số lượng chủ đề đượ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ổ từng 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. 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

Vì kết quả hiệu suất có thể bị ảnh hưởng bởi tổng số IOP, 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: MDtest Phân phối tệp trên các thư mục

Hình 5: Hiệu suất siêu dữ liệu – Các tập tin trống

Đầ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 bậc về độ lớn; nếu không, một số thao tác sẽ trông giống như một đường phẳng gần bằng 0 trên biểu đồ bình thường. Biểu đồ nhật ký với cơ số 2 có thể phù hợp hơn, vì số luồng được tăng lên 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 với các thao tác Stat và Read đạt giá trị cao nhất ở 64 luồng với gần 11 triệu thao tác/giây và 4,7 triệu thao tác/giây tương ứng. Hoạt động loại bỏ đạt mức tối đa 170,6K op/s ở 16 luồng và hoạt động Tạo đạt mức cao nhất ở 32 luồng với 222,1K op/s. Hoạt động Thống kê và Đọc có nhiều biến đổi hơn, nhưng khi chúng đạt đến giá trị cao nhất, hiệu suất sẽ không giảm xuống dưới 3 triệu thao tác/giây đối với Thống kê và 2 triệu thao tác/giây đối với Đọc. Tạo và Xóa sẽ ổn định hơn khi chúng đạt đến mức ổn định và duy trì trên 140K thao tác/giây đối với Xóa và 120K thao tác/giây đối với Tạo. Lưu ý rằng các ổ đĩa bổ sung không ảnh hưởng nhiều đến hầu hết các thao tác siêu dữ liệu trên các tệp trống như mong đợi.
 

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

Thử nghiệm này gần giống với thử nghiệm trước, ngoại trừ việc thay vì các tệp trống, các tệp nhỏ 4KiB đã được sử dụng. 
Lệnh sau được sử dụng để thực thi điểm chuẩn, trong đó Chủ đề là biến có số lượng chủ đề đượ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ổ từng 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.

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

Hình 6: Hiệu suất siêu dữ liệu – Tệp nhỏ (4K)

Hệ thống nhận được kết quả rất tốt cho các thao tác Thống kê và Loại bỏ đạt giá trị cao nhất ở 256 luồng với 8,2 triệu thao tác/giây và 400 nghìn thao tác/giây tương ứng. Hoạt động đọc đạt mức tối đa là 44,8K thao tác/giây và hoạt động Tạo đạt mức cao nhất với 68,1K thao tác/giây, cả hai đều ở 512 luồng. Hoạt động Thống kê và Loại bỏ có nhiều biến đổi hơn, nhưng khi chúng đạt đến giá trị cao nhất, hiệu suất sẽ không giảm xuống dưới 3 triệu hoạt động/giây đối với Chỉ số và 280 nghìn hoạt động/giây đối với Loại bỏ. Tạo và Đọc ít thay đổi hơn và tiếp tục tăng khi số lượng chuỗi tăng lên. Như có thể thấy, các ổ đĩa bổ sung của việc mở rộng dung lượng chỉ cung cấp những thay đổi nhỏ trong hiệu suất siêu dữ liệu.
Vì những con số này dành cho một mô-đun siêu dữ liệu với một ME4024 duy nhất, nên hiệu suất sẽ tăng đối với mỗi mảng ME4024 bổ sung, tuy nhiên, chúng tôi không thể chỉ giả định mức tăng tuyến tính cho mỗi thao tác. Trừ khi toàn bộ tệp vừa với inode của tệp đó, các mục tiêu dữ liệu trên ME4084 sẽ được sử dụng để lưu trữ tệp 4K, hạn chế hiệu suất ở một mức độ nào đó. Vì kích thước inode là 4KiB và nó vẫn cần lưu trữ siêu dữ liệu nên chỉ những tệp khoảng 3 KiB mới phù hợp bên trong và bất kỳ tệp nào lớn hơn sẽ sử dụng mục tiêu dữ liệu.

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

Giải pháp với dung lượng mở rộng có thể cải thiện hiệu suất, không chỉ đối với truy cập ngẫu nhiên mà còn đối với hiệu suất tuần tự. Điều đó đã được mong đợi vì chế độ phân tán hoạt động như các truy cập ngẫu nhiên và việc có nhiều đĩa hơn cho phép cải thiện. Hiệu suất đó, có thể được tổng quan trong Bảng 4, dự kiến ​​sẽ ổn định từ một hệ thống tệp trống cho đến khi gần đầy. Hơn nữa, giải pháp mở rộng tuyến tính về dung lượng và hiệu suất 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ừ mô-đun siêu dữ liệu có nhu cầu cao tùy chọn. 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,

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

Vì giải pháp dự kiến ​​sẽ được phát hành với CPU Cascade Lake và RAM nhanh hơn nên sau khi hệ thống có cấu hình cuối cùng, một số kiểm tra điểm hiệu suất sẽ được thực hiện. Và kiểm tra Mô-đun siêu dữ liệu nhu cầu cao tùy chọn với ít nhất 2 tệp ME4024 và tệp 4KiB là cần thiết để ghi lại chính xác hơn cách hiệu suất siêu dữ liệu thay đổi khi có liên quan đến các mục tiêu dữ liệu. Ngoài ra, hiệu suất của các nút cổng sẽ được đo lường và báo cáo cùng với bất kỳ kết quả liên quan nào từ việc kiểm tra tại chỗ trong blog mới hoặc sách trắng. Cuối cùng, nhiều thành phần giải pháp hơn đã được lên kế hoạch thử nghiệm và phát hành để cung cấp nhiều khả năng hơn nữa.