IO500 - SSC-24 - Reproducibility

System Purpose

Question asked

Please describe the purpose and general usage of the submitted system. This would include the types of typical applications it supports (e.g., defense applications, molecular dynamics, benchmarking, system test, systems research), and the general use and purpose of the data generated by the applications running on it.

The submitted system, SSC24, is designed to support Samsung Electronics employees and affiliates in high-performance computing workloads such as fine-process simulation, composite materials modeling, and artificial intelligence training.
It is utilized across various domains including mechanical design, circuit design, materials engineering, and deep learning, providing compute and storage resources for both simulation and AI workloads.

Availability

Question asked

Please provide the deployment timeframe of the submitted system, or for on-demand cloud systems, the general period over which it is deployed and destroyed.

Please describe the availability of the system to users and who are its set of most regular users.

SSC24 was deployed in 2024 and is continuously available 24/7, except during scheduled preventive maintenance.
The system is accessible to authorized users across Samsung Electronics and affiliated organizations, serving a broad range of internal researchers and engineers.

Storage System Software

Question asked

How is this storage software available? (e.g., commercially, open-source, not publicly available) Note that if the storage software is not open-source or commercially available, then a general description would be requested, but this would limit the submission’s reproducibility score.

Can anyone download/purchase this software?

List either product webpage or open-source repo of the exact software used in IO500.

Give any and all additional details of this specific storage deployment: (e.g., type of storage server product such IBM ESS or DDN SFA400X2, use of Ext4 or some other file system on each storage node, dual connected storage media to storage servers).

The storage software used is WekaIO, a commercially available parallel file system optimized for NVMe storage and high-performance computing environments.
WekaIO is vendor-agnostic and can be deployed on any supported commodity hardware with NVMe drives and Mellanox-compatible networking.

More information is available at: https://www.weka.io/

- Storage Nodes: 40 Supermicro SSG-221E-NE324R servers

Runtime Environment

Question asked

State here that you provided all scripts/documentation that would allow someone else to reproduce your environment and attempt to achieve a similar IO500 score as the submitted system.

NOTE: provide all files/documentation/scripts that would enable a user to build your environment and deploy the custom scripts, software, or config files once they have obtained the appropriate storage system hardware and software. These may be included into the io500.tgz or into the extraCodes upload on the submission form.

Several examples include:

Commands used to set striping information (either for the entire system or for particular directories)
File system config and tuning information (or a reason why this is not available due to lack of root access, etc) on each node type (e.g., non-default config parameters on all three types of Lustre nodes: MDS, OSS, and client)
Any additional scripts utilized that impact IO500 execution beyond the io500 config file. For example, with IBM Spectrum Scale, the output of mmlsconfig, mmlscluster, mmlsfs, and mmlsfileset commands (and possibly even a dump of the configuration if possible). Each file system probably has similar type of config/tuning information that would need to be shared for a user to fully reproduce the environment.

The IO500 environment is fully reproducible.
The benchmark was compiled and executed using locally built OpenMPI version 4.1.7.
A total of 291 compute nodes were used, each running 55 MPI processes.
The pfind_queue_length was explicitly set to 17000.

All benchmark tasks were launched manually from a login node without using any resource manager or job scheduler (e.g., SLURM), allowing precise control over the MPI environment and system behavior.

Relevant tuning scripts and configuration files (e.g., io500.sh, MPI hostfile, mount options) can be shared upon request or included in the submission package.

Mount Options: mount -t wekafs -o num_cores=8,forcedirect,net:ha=$DEV2,net:ha=$DEV4 $Backend_ip/8gpufs /mnt/weka -o mgmt_ip=$IP2+$IP4

The WekaFS client was mounted with the following options: num_cores=8, forcedirect, net:ha, and dual management IPs for high availability. This configuration ensures full redundancy and direct storage access without client-side caching.

Fault Tolerance Mechanisms

Question asked

Does your system have a single point of failure as defined by “Definition 7” of a Production System? Please describe all mechanisms that provide fault tolerance for the submitted storage system. Be specific to your submission, not general storage system capabilities.

Power (For example, can power failure of a node or rack bring down the storage system?)
Networking (For example, can failure of a single NIC bring down the storage system? Remember that any networking failure that brings down multiple nodes is acceptable)
Inter storage data and metadata server (For example, what type of data protection mechanism does the storage system use to keep operating during node failures, e.g., active-active servers, client-directed RAID, declustered RAID, erasure-coding, 3-way replication)
Intra storage data and metadata server storage media (For example, how does the storage eysstem protect against fiailure of a single storage device within a node, e.g., raid5)

Please list any additional information needed to determine whether this system has a single point of failure.

Power:

All servers are connected to dual power feeds with UPS support, allowing tolerance for up to two simultaneous node or power circuit failures.

Network:

Each server is equipped with dual high-availability NICs, enabling tolerance to a single NIC or switch failure.
WekaIO’s HA fabric ensures continuous service through redundant InfiniBand paths.

Storage Protection:

WekaIO’s built-in distributed data protection is configured as 16+2p, tolerating the simultaneous failure of two nodes or storage devices without data loss.

Execution

Question asked

Please provide a description of how the IO500 benchmark was executed, e.g., via system scheduler (e.g., SLURM) to run a job on the compute cluster, which initially ran a setup process to configure the client and file system, and then started the full benchmark.

During the IO500 benchmark execution was the system entirely dedicated to running the benchmark or were there other jobs running in the same cluster and storage system?

The IO500 benchmark was executed with full system dedication.
All 291 compute nodes were exclusively allocated for the benchmark, with no competing workloads during execution.

Caching

Question asked

Please describe all caching mechanisms in client/server that were utilized during the IO500 run. This could include caching in any storage medium (e.g., SSD, RAM).

A few examples would include:

Client data/metadata caching (in Linux page cache or in other memory cache)
Client side NVMe read-only data cache
Storage server metadata/data caching in RAM
Storage controller caching
RAID card caching

Client-side caching was explicitly disabled using the forcedirect mount option.
This option bypasses the Linux page cache and disables both read and write caching mechanisms.
All I/O operations are sent directly to the WekaIO data path and persisted to physical NVMe media.
No additional caching layers (e.g., RAID controller cache or metadata caching) were used during the benchmark.

Data Source

Question asked

Is the submitted system a stand-alone storage system or an acceleration layer in front of another storage system that is the source of truth for all application data? This question relates to whether the submitted system is a burst buffer layered on primary storage or primary storage itself.

The submitted system is a stand-alone primary storage system and not a front-end cache or burst buffer for another backend storage solution.

Trust

Question asked

Please describe any steps taken to ensure that the results are trustworthy.

Did you run the benchmark multiple times and get similar scores?
Did you validate the score is below the physical capabilities of the deployed hardware?
How did you validate that the storage system follows the IO500 rules regarding persistence, which states, "All data must be written to persistent storage within the measured time for the individual benchmark, e.g. if a file system caches data, it must ensure that data is persistently stored before acknowledging the close"?

The benchmark was run multiple times under identical conditions, yielding consistent results with only minor deviations.
The final submitted result was selected from among these reproducible runs.

All observed IOPS and bandwidth remained within the physical limits of the deployed hardware.
Persistence was validated by verifying that benchmark output files were immediately accessible from nodes that were not involved in the benchmark, confirming data was flushed to persistent storage before closing.