Accelerating Enterprise Applications and Reducing TCO with SanDisk ZetaScale Software

Transcription

1 WHITEPAPER Accelerating Enterprise Applications and Reducing TCO with SanDisk ZetaScale Software SanDisk ZetaScale software unlocks the full benefits of flash for In-Memory Compute and NoSQL applications 91 SanDisk Drive, Milpitas, CA SanDisk Corporation. All rights reserved.

2 Table of Contents Introduction 3 ZetaScale Architecture 3 ZetaScale Functionality 4 ZetaScale Cost Savings Cassandra Case Study MongoDB Case Study 6 REDIS Case Study 7 GigaSpaces XAP Case Study 8 Server Consolidation 8 Conclusions 9

3 Introduction In order to support high-volume web sites, cloud computing, and new enterprise applications, data centers require more servers, more disks, more rack space, and additional power and cooling. Flash is growing explosively as a storage medium for these sites, because it alleviates these demands, providing more throughput, faster access speeds, and a smaller footprint, using less power Worldwide Enterprise Storage Market in Bln$ SSD However, simply replacing hard disk drives (HDDs) with solid state drives (SSDs) provides only about 3x improvement in performance and TCO. SanDisk introduced ZetaScale software to more fully utilize Source: IHS Technology flash, producing a total of x-1x improvement over HDDs and 2x-3x improvement over SSDs alone by intelligently and efficiently capitalizing on the unique properties of flash storage versus DRAM and HDDs. ZetaScale Architecture Treating flash as a hard disk through an operating system s block I/O calls results in a number of limitations in efficiently caching and writing application data objects, and in utilizing the full thread parallelism possible in flash hardware and in application I/O. Applications access ZetaScale through an API that can very efficiently fetch, cache, and store individual application objects, or records. ZetaScale selectively utilizes DRAM and flash for data most appropriate for each storage medium, caching frequently accessed objects in DRAM and efficiently buffering and aggregating flash writes to minimize flash wear. ZetaScale exploits the high capacity low-latency persistence, parallelism, and high throughput of flash storage. HDD

4 ZetaScale works with any vendor s flash with any flash supported storage interface, including SATA, SAS, PCIe, DDR3 and NVMe but can also utilize proprietary SanDisk flash features by calling upon SanDisk-specific SSD controller commands, producing a best of both solution. ZetaScale Functionality ZetaScale provides a key-value object API to customer applications. Applications can create, read, update, and delete their objects stored by ZetaScale. ZetaScale s API is similar to key-value APIs used in a number of popular systems we examine later in this paper, so it is easy to translate application calls into ZetaScale calls. An application-meaningful key is used to identify and access objects. ZetaScale supports key range queries as well as exact matches. Objects can also be partitioned into containers that provide object name spaces. ZetaScale automatically and efficiently maps object keys to DRAM and/or flash locations. DRAM can be used as a cache for flash, and flash can in turn be used as a cache for hard disk or remote storage, with automatic object eviction from the cache. Applications need not decide where objects are stored in DRAM or flash: objects are referenced by key rather than address, so ZetaScale can select the most efficient place to store objects, e.g. when erasing flash blocks. ZetaScale uses efficient indices to locate objects, and uses fine-grained locking for maximum concurrency and performance in object operations from multiple application threads. ZetaScale implements transactions with configurable durability guarantees: a commit on every update, a commit every N updates, or no persistence. Persisted data is automatically recovered after a crash.

5 Unlike hash indices, ZetaScale B-tree indices are capable of range queries and can order results by key, for applications that require that functionality. ZetaScale also provides consistent snapshot backups. All of this ZetaScale functionality simplifies application development as well as improving performance. ZetaScale Cost Savings By using both DRAM and flash memory efficiently, ZetaScale reduces the number of servers and the amount of DRAM required to support a customer s application load, thereby realizing substantial cost savings while increasing performance compared to existing solutions. SanDisk customers highly value the consolidation and TCO savings afforded by ZetaScale. The use of ZetaScale in applications often results in performance comparable to an in-memory solution, while replacing expensive DRAM with SSD storage. This can reduce costs as much as 1x. ZetaScale unlocks the full potential of the hardware by optimizing the use of all the available physical resources across a broad spectrum of workloads. It enables full utilization of multi-core processors, intelligently manages caching from DRAM to flash, and delivers highly parallel finegrained flash memory reads and writes. In order to see the advantages of ZetaScale, we now look at case studies using various software with ZetaScale. Cassandra Case Study Cassandra is an open source distributed key-value store used by hundreds of large-scale enterprises with thousands of concurrent users. Cassandra provides automatic fault-tolerance and recovery by replicating across data centers, and it is optimized for high write workloads. It supports rows with thousands of columns and multiple indices. Running the Yahoo Cloud Serving Benchmark (YCSB) on Cassandra 2.1.4, Cassandra achieves 2.6x better performance storing data on SSD instead of HDD. However, Cassandra running YCSB with ZetaScale achieves an additional 3x speedup on the same SSD, resulting in a 3x reduction in the number of servers required for the same transaction throughput load with ZetaScale. These results were obtained using a YCSB load of 9% reads and % writes on uniformly distributed keys, accessing a 128GB data set on a Dell R7 Xeon server with 64GB of DRAM and an 8x SanDisk GB Lightning write-intensive SSDs, with the YCSB client connected via 1GB Ethernet. Each row was 1KB, and 1 column was read or written on each transaction. ZetaScale Cassandra performs particularly well as the % reads vs writes increases. The performance of stock Cassandra on SSD does not match this performance increase. TPS per server in Thousands Cassandra with ZetaScale provides 9x performance improvement over HDD and more than 2x over SSD Bytes, 1 Cols, 128M Rows - 9% read / % write - Dell R7 dual socket Intel 2.6GHz CPU, 32 cores, 128GB DRAM (limited to 64GB for test) with 8x SanDisk x21 SATA SSDs - single node, Cassandra v1.2.2, ZetaScale v2. - YCSB (uniform distribution, 128 threads) measurements performed by SanDisk HDD stock SSD stock ZetaScale + SSD

6 Cassandra with ZetaScale-SSD provides increasing performance improvement at increasingly read intensive workloads ZetaScale-SSD (Short Rows) Stock SSD (Short Rows) Cassandra with ZetaScale-SSD provides increasing performance improvement at increasingly read intensive workloads ZetaScale-SSD (Long Rows) Stock SSD (Long Rows) % Read 7% Read 9% Read % Read 7% Read 9% Read - 1 Bytes, 1 Cols, 128M Rows - 9% read / % write - Dell R7 dual socket Intel 2.6GHz CPU, 32 cores, 128GB DRAM (limited to 64GB for test) with 8x SanDisk x21 SATA SSDs - single node, Cassandra v1.2.2, ZetaScale v2. - YCSB (uniform distribution, 128 threads) measurements performed by SanDisk - 1 Bytes, 1K Cols, 128K Rows - 9% read / % write - Dell R7 dual socket Intel 2.6GHz CPU, 32 cores, 128GB DRAM (limited to 64GB for test) with 8x SanDisk x21 SATA SSDs - single node, Cassandra v1.2.2, ZetaScale v2. - YCSB (uniform distribution, 128 threads) measurements performed by SanDisk MongoDB Case Study Another popular open source NoSQL data store is MongoDB. MongoDB stores JSON documents distributed (sharded) over multiple servers, with automatic re-sharding when adding or removing servers. It supports document-based queries with multiple indices. Running the YCSB benchmark on MongoDB achieves significant performance improvements with ZetaScale: x performance improvement over HDD and 3x over stock MongoDB on SSD. And on a 1% read load, the benefits of ZetaScale are even more striking MongoDB ZetaScale provides x performance improvement over HDD and 3x over SSD.7-128GB 1K data - 24 core Westmere, 96GB DRAM, 8 x OCZ and 128GB 1K data 16 HDD stock SSD stock ZetaScale + SSD MongoDB with ZetaScale-SSD provides increasing performance improvement at increasingly read intensive workloads ZetaScale-SSD Stock SSD % Read 1% Read - 128GB 1K data - 24 core Westmere, 96GB DRAM, 8 x OCZ and 128GB 1K data These results were achieved on a pair of 12 core CPU with 96GB of DRAM and a 128GB database, with 1KB objects. MongoDB on ZetaScale ran 3x-9x faster than stock MongoDB on SSD, even though more of memory was available as a database cache with stock MongoDB (a 4% DRAM cache miss rate vs 7% with ZetaScale).

7 REDIS Case Study REDIS (REmote Dictionary Server) is an open-source, distributed in-memory key-value store with persistence capabilities. It supports strings, hashes, lists, sets, and sorted sets. Running REDIS on an Intel Westmere server with 2 sockets, 24 cores, and 96GB of DRAM, we compare two cases with YCSB: REDIS with ZetaScale-SSD runs different types of out-of-memory datasets with the same or better speed as in-memory datasets 1. A data set that fits entirely in memory with stock REDIS. 2. A data set on SSD accessed via ZetaScale, with a % hit rate on a DRAM cache. In the chart to the right we see that REDIS with ZetaScale performed as well as REDIS in-memory on YCSB, even though % of the data did not fit in memory. ZetaScale achieves more throughput by utilizing multiple CPU threads, while stock REDIS is single-threaded ZetaScale REDIS (out-of-memory) Stock REDIS (in-memory) REDIS ZetaScale allows out-of-memory datasets to run at same or better speed as in-memory datasets Stock REDIS (DATA < DRAM) - 128GB 1K data, String Data Type - 24 core Westmere, 96GB DRAM, 8 x OCZ and 128GB 1K data REDIS with ZetaScale SSD (DATA > DRAM) These results are for YCSB running on 1KB objects (1 1 byte fields) and a random uniform key distribution with 9% reads, % updates. Similar results are obtained for different data types, including string, hash, list, set and sorted set. In each instance REDIS with ZetaScale provides similar or better performance for out-of-memory datasets. String Hash List Set Sorted Set - 128GB 1K data - 24 core Westmere, 96GB DRAM, 8 x OCZ and 128GB 1K data

8 GigaSpaces XAP Case Study GigaSpaces XAP is an in-memory compute platform designed for real-time big data analytics applications. GigaSpaces XAP can leverage distributed real-time computation libraries such as Storm and Apache Samza to process unbounded streams of data. GigaSpaces XAP with its ZetaScale integration can manage large amounts of data across a grid of high density capacity servers for high-frequency data produced as a result of the distributed computation. GigaSpaces XAP can model the data using Objects/SQL, documents, or relational, supporting a variety of programing interfaces such as Java. Net, C++, Scala and more. GigaSpaces XAP is used by top Fortune companies in many sectors including Finance, Retail, Transportation, Telecommunications, and Technology. GigaSpaces XAP manages data on RAM and SSD using an intelligent approach for optimizing data access for low-latency applications, while distributing data within the same data site or over multiple geographies in a transparent manner. Running the YCSB benchmark on GigaSpaces XAP demonstrates impressive performance with ZetaScale. The benchmark was run on a HP DL 38 server with two 2.8GHz CPUs with a total of 24 cores, 96G DRAM, CentOS.8, and 2 FusionIO SLC PCIe cards with software Raid. The payload was 1KB object size with uniform read distribution. With XAP running in pure RAM mode it delivered 1.2 Million read TPS. When XAP was configured to store data using ZetaScale it managed to perform 242K read TPS. The remarkable fact is the capacity difference XAP in a pure RAM-based configuration may store only 3GB per node, while XAP in an SSD- based configuration can store multiple TBs per node avoiding any garbage collection pauses. This translates into an impressive cost saving and price-performance ratio. Instead of running a large XAP cluster forming a RAM-based inmemory fabric, a few XAP nodes across a smaller number of servers with SSD may offer much larger storage capacity. TPS per dollar GigaSpaces XAP with ZetaScale has 2x-3.6x better TPS per dollar than stock GigaSpaces XAP ZetaScale GigaSpaces (memory + flash) Stock GigaSpaces (in-memory) Comparing XAP in pure RAM mode vs. ZetaScale storage mode, the numbers show that XAP running on ZetaScale in pure SSD mode delivers 3.6x better priceperformance than XAP running in pure RAM mode with write operations. With read operations, ZetaScale SSD mode delivered 2.1x better priceperformance when compared to RAM mode. (For the price-performance figures we assume 1TB SSD price of $2K, 1TB RAM price of $K.) 4 17 No Read / 1% Write 1 % Read / No Write - 1KB object size and uniform distribution - 2 sockets 2.8GHz CPU with total 24 cores, CentOS.8, 2 FusionIO SLC PCIe cards RAID Server Consolidation Clearly ZetaScale offers significant cost savings. With an average 3x performance improvement over stock software running on SSD, ZetaScale significantly reduces the number of servers required for most applications, along with associated costs such as power and cooling. For example, only 8 servers are needed to support our 6 KTPS 3TB YCSB application load with Cassandra running on ZetaScale, while 3 servers are required to achieve the same performance with stock Cassandra on SSD. This savings is in addition to the reduction from 4 servers needed to support the same application load with Cassandra on HDD. Furthermore, in addition to the savings in capital expenditures for servers, operating costs are greatly reduced for power, cooling, and server maintenance.

9 ZetaScale-Cassandra reduces the number of servers required to run Cassandra 4 3 HDD Stock SSD Stock ZetaScale with SSD With REDIS, we see a reduction from 24 servers required for REDIS on SSD to just 1 servers to support the same application load on REDIS with ZetaScale. Again, these savings are in both capital and operating costs. Over a period of 3 years on commodity hardware, this server consolidation would result in approximately 7x reduction in TCO. With Gigaspaces, we see similar server consolidation. Just 11 servers running Gigaspaces on ZetaScale can support the same YCSB transaction load as servers running stock Gigaspaces. We found analogous server consolidation with MongoDB and other systems. 8 ZetaScale reduces the number of servers required to run REDIS ZetaScale reduces the number of servers required to run GigaSpaces Stock SSD DRAM 1 ZetaScale with SSD 11 ZetaScale with GigaSpaces Conclusions ZetaScale is engineered to utilize the unique advantages of flash memory and to maximize parallelism in data access. Simply replacing HDDs with SSDs in servers provides some performance improvement, but ZetaScale provides 2x to 3x additional improvement, by optimizing software for efficient flash access. As we have shown for NoSQL databases, ZetaScale allows much fewer servers to support the same application load. TCO may be reduced as much as 7% -- potentially saving millions of dollars in servers, DRAM, power, and cooling over several years in a large installation. In the case of in-memory databases, ZetaScale allows much larger data sets to be supported at essentially the same performance level by optimizing the placement of objects in memory and on flash. This again drives server consolidation and provides a 2x-4x improvement in price/performance. 14 SanDisk Corporation. All rights reserved. SanDisk is a trademark of SanDisk Corporation, registered in the United States and other countries. ZetaScale is a trademark of SanDisk Enterprise IP LLC. Other brand names mentioned herein are for identification purposes only and may be the trademarks of their holder(s).