Điểm chuẩn và giường thử nghiệm
-
Để mô tả các thành phần khác nhau của giải pháp pixstor, 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 2 , bao gồm cả HDMD tùy chọn. Để đánh giá hiệu suất của giải pháp, chúng tôi đã chọn các điểm chuẩn sau:
- IOzone N đến N tuần tự
- IOR N đến 1 tuần tự
- IOzone N đến N ngẫu nhiên
- MDtest cho siêu dữ liệu
Đối với các điểm chuẩn này, giường thử nghiệm bao gồm các máy khách được mô tả trong bảng sau, ngoại trừ việc thử nghiệm các nút cổng:
Thành phần
Sự miêu tả
Số nút máy khách
16
nút máy khách
C6420
Bộ xử lý trên mỗi nút máy khách
8 nút với 2 x Intel Xeon Gold 6230 20 lõi @ 2,1 GHz
8 nút với 2 x Intel Xeon Gold 6148 20 lõi @ 2,40 GHz
Bộ nhớ trên mỗi nút máy khách
8 nút (6230) với 12 x 16 GiB 2933 MT/s RDIMM
8 nút (6148) với 12 x 16 GiB 2666 MT/s RDIMM
BIOS
2.12.2
Hệ điều hành
CentOS 8.4
Nhân hệ điều hành
4.18.0-305.12.1.el8_4.x86_64
phần mềm pixstor
6.0.3
Thang đo phổ (GPFS)
5.1.3-1
phiên bản OFED
MLNX_OFED_LINUX-5.6-1.0.3.3
CX6 FW
8 nút (CPU 6230) với cổng đơn Mellanox CX6: 20.31.1014
8 nút (CPU 6148) với cổng đơn Dell OEM CX6: 20.28.4512
Do số lượng nút điện toán khả dụng để 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 (nghĩa 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 512 đã được sử dụng, dựa trên số lượng lõi của các nút máy khách (ngoại trừ máy khách IOzone N cho N tệp). Việc sử dụng nhiều luồng hơn số lõi có thể gây ra hiện tượng chuyển 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.
Giải pháp pixstor với HDMD (không mở rộng dung lượng ME484s)
-
Đố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
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
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
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%.
Bài viết mới cập nhật
LatentAI: Nâng cao trí thông minh biên với Dell và NVIDIA AI
Giàn khoan dầu, hoạt động quân sự và xe tự hành ...
Tăng tốc lưu trữ máy chủ lớn với các mô hình Dell Disk Library (DLm) mới
Dell công bố các mẫu lưu trữ băng ảo máy chủ ...
Giới thiệu Dell NativeEdge với Nokia Private Wireless
Dễ dàng quản lý và kết nối cơ sở hạ tầng ...
Dịch vụ bảo vệ APEX dành cho Microsoft Azure: Nâng cao bảo mật dữ liệu
Dịch vụ bảo vệ APEX dành cho Microsoft Azure giúp đơn ...