IBM's knockout single file system benchmark
Single file system SONAS blows the rest away
Comment In a week that saw EMC announce its record NFS benchmark with a virtually all-flash VNX, IBM has blown everyone else away with an astounding single file system SONAS result.
SONAS is IBM's Scale-Out NAS product, based on its GPFS (General Parallel File System) and it achieved 403,326 SPECsfs2008 ops/sec with a system comprising 1,975 disk drives - 1,680 x 600GB, 15K rpm SAS and 240 x 450GB, 15K rpm SAS hard drives, with an additional 55 mirrored 300GB drives for operating system use and logging. There was a single file system and a total exported capacity of 903.8TB, damn near a petabyte; it is called a scale-out NAS system after all.
The EMC VNX result bounded past this in ops/sec terms, with 497,623 ops/sec and did so using 436 x 200GB SAS solid state drives and 21 x 300GB, 15K rpm hard disk drives. There were eight file systems and a total exported capacity of 60.243TB, a fifteenth of the SONAS system.
So what, we might say, both are extreme systems, like formula one Grands Prix racing cars according to some commentators, and benchmarks like this are unreal. IBM's view is that its benchmarked system is much more realistic than EMC's. An IBM SONAS benchmark paper we have seen says:
The benchmarked SONAS configuration is a realistic standard configuration that provides industry leading performance for a single file system NAS solution without any compromise on capacity or cost. There are no unnecessary complexities added to the configuration such as mandatory multiple file systems, aggregated racks, or exclusive use of SSD drives that are impractical and very costly in today’s environment. IBM benchmarked a typical SONAS system configuration that IBM customers are deploying today.
… IBM SONAS is the only clustered file system in the industry that can offer the performance to not only handle large files but also smaller random access file workloads, all under a single file system. The IBM SONAS system benchmarked contained 10 Interface nodes and 8 Storage pods leaving room for customers to grow to 30 Interface nodes and 30 Storage pods providing true scale-out capability.
The paper, not yet generally available, contains multiple graphs and we have extracted two to show here. The first one illustrates SONAS SPECsfs2008 performance compared to other single file system vendors:
The second shows SONAS as a single file system relative to all multiple file system vendors:
The message is that IBM's SONAS benchmark system is (1) a proper scale-out NAS system and (2) more realistic than EMC's extreme VNX configuration.
EMC's Barry Burke, chief strategy officer for the Symmetrix and virtualisation product group, points out the average response time differences in the two benchmarks. In IBM's case it was a 3.23msec overall response time whereas in EMC's it was 0.96. He says that, as the SONAS system had more than 1.4TB of DRAM cache, most of the ops/sec would have been serviced from this rather than the disk drives.
He asks in his blog which system was faster and says it's EMC's because it delivered 497,623 ops/sec at a 3.3msec response time while he calculates IBM"s only did 234,043 ops/sec at a 3.3msec response time.
NetApp, whose filers are now nowhere in top line SPECsfs2008 results, neither in multiple file system nor single file system terms, is exhibiting sour grapes of extreme acidity. Having submitted its own EMC benchmarks in the days when EMC didn't do such things, and trashed EMC with its FAS systems, it is now reduced to quoting EMC's Chuck Hollis's old anti-benchmark view back at EMC.
It cuts no ice guys: you lucked out, twice. Either step up to the mark with a single (and parallel) file system that beats IBM, a flash system that beats EMC, or just get off the pot. That's the rule of the benchmarking game you've been playing and there's no use bleating about it. ®
at first I had a giggle at PB capacity ...
... but then I thought: hang on a sec, if we were to store the logs from all the servers we have around here, and keep them for longer that a week, then capacity measured in PB would be probably needed. Also, services generating these logs can't afford to wait long times writing them and, when the fit hits the shan, we need to grep them fast, too.
Could just be a badly configured Windows 2008 server, because they can spit out tons of meaningless crap.
You talking of LHC ?
can't think of any other place which need a PB just for the logs...