Elevating Commodity Storage with the SALSA Host Translation Layer
Total Page：16
File Type：pdf, Size：1020Kb
Elevating commodity storage with the SALSA host translation layer Nikolas Ioannou, Kornilios Kourtis, and Ioannis Koltsidas IBM Research, Zurich fnio, kou, [email protected] workload. To complicate things further, many applica- Abstract tions (e.g., media services [6, 62]) require multiple stor- age media to meet their requirements. To satisfy increasing storage demands in both capac- ity and performance, industry has turned to multiple stor- Storage devices are also frequently idiosyncratic. age technologies, including Flash SSDs and SMR disks. NAND Flash, for example, has a different access and These devices employ a translation layer that conceals erase granularity, while SMR disks preclude in-place up- the idiosyncrasies of their mediums and enables random dates, allowing only appends. Because upper layers (e.g., access. Device translation layers are, however, inher- databases and filesystems) are often not equipped to deal ently constrained: resources on the drive are scarce, they with these idiosyncrasies, translation layers [11] are in- cannot be adapted to application requirements, and lack troduced to enable applications to access idiosyncratic visibility across multiple devices. As a result, perfor- storage transparently. Translation layers (TLs) imple- mance and durability of many storage devices is severely ment an indirection between the logical space as seen degraded. by the application, and the physical storage as exposed In this paper, we present SALSA: a translation layer by the device. A TL can either be implemented on the that executes on the host and allows unmodified appli- host (host TL) or on the device controller (drive TL). cations to better utilize commodity storage. SALSA It is well established that, for many workloads, drive supports a wide range of single- and multi-device opti- TLs lead to sub-optimal use of the storage medium. mizations and, because is implemented in software, can Many works identify these performance problems, and adapt to specific workloads. We describe SALSA’s de- try to address them by improving the controller transla- sign, and demonstrate its significant benefits using mi- tion layer [19, 32], or adapting various layers of the I/O crobenchmarks and case studies based on three applica- software stack: filesystems [23, 29, 38], caches [24, 45], tions: MySQL, the Swift object store, and a video server. paging [49], and key-value stores [13, 14, 34, 46, 67]. In agreement with a number of recent works [5,30,43], 1 Introduction we argue that these shortcomings are inherent to drive The storage landscape is increasingly diverse. The mar- TLs, and advocate placing the TL on the host. While a arXiv:1801.05637v2 [cs.OS] 10 Jan 2019 ket is dominated by spinning magnetic disks (HDDs) host TL is not a new idea [17, 31], our approach is dif- and Solid State Drives (SSDs) based on NAND Flash. ferent from previous works in a number of ways. First, Broadly speaking, HDDs offer lower cost per GB, while we focus on commodity drives, without dependencies on SSDs offer better performance, especially for read- specific vendors. Our goal is to enable datacenter appli- dominated workloads. Furthermore, emerging technolo- cations to use cost-effective storage, while maintaining gies provide new tradeoffs: Shingled Magnetic Record- acceptable performance. Second, we propose a unified ing (SMR) disks [69] offer increased capacity compared TL framework that supports different storage technolo- to HDDs, while Non-Volatile Memories (NVM) [39] of- gies (e.g., SSDs, SMRs). Third, we argue for a host TL fer persistence with performance characteristics close to that can be adapted to different application requirements that of DRAM. At the same time, applications have dif- and realize different tradeoffs. Finally, we propose a TL ferent requirements and access patterns, and no one-size- that can virtualize multiple devices, potentially of differ- fits-all storage solution exists. Choosing between SSDs, ent types. The latter allows optimizing TL functions such HDDs, and SMRs, for example, depends on the capac- as load balancing and wear leveling across devices, while ity, performance and cost requirements, as well as on the also addressing storage diversity by enabling hybrid sys- 1 Published in 2018 IEEE 26th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS) tems that utilize different media. 2.1 Flash-based SSDs SALSA (SoftwAre Log Structured Array) implements Flash memory fits well in the gap between DRAM and the above ideas, following a log-structured architec- spinning disks: it offers low-latency random accesses ture [36, 47]. We envision SALSA as the backend of compared to disks at a significantly lower cost than a software-defined storage system, where it manages DRAM. As a result, its adoption is constantly increas- a shared storage pool, and can be configured to use ing in the data center [25, 51, 65], where it is primarily workload-specific policies for each application using the deployed in the form of SSDs. Nevertheless, Flash has storage. In this paper, we focus on the case where unique characteristics that complicate its use [3]. First, SALSA is used to run unmodified applications by expos- writes are significantly more involved than reads. NAND ing a Linux block device that can be either used directly, Flash memory is organized in pages, and a page needs or mounted by a traditional Linux filesystem. The con- to be erased before it can be programmed (i.e., set to tribution of our work is a novel host TL architecture and a new value). Not only programming a page is much implementation that supports different media and allows slower than reading it, but the erase operation needs to optimizing for different objectives. Specifically: be performed in blocks of (hundreds or even thousands of) pages. Therefore, writes cannot be done in-place, • SALSA achieves substantial performance and dura- and also involve a high cost as block erasures are two or- bility benefits by implementing the TL on the host ders of magnitude slower than reading or programming for single- and multi-device setups. When de- a page. Second, each Flash cell can only sustain a finite ploying MySQL database containers on commodity number of erase cycles before it wears out and becomes SSDs, SALSA outperforms the raw device by 1:7× unusable. on one SSD and by 35:4× on a software RAID-5 Flash translation layers (FTLs) [32] are introduced to array. address the above issues. In general, an FTL performs • SALSA makes efficient use of storage by allowing writes out-of-place, and maintains a mapping between application-specific policies. We present a SALSA logical and physical addresses. When space runs out, in- policy tailored to the Swift object store [59] on valid data are garbage collected, and valid data are re- SMRs that outperforms the raw device by up to a located to free blocks. To aid the garbage collection factor of 6:3×. (GC) process, controllers keep a part of the drive’s ca- • SALSA decouples space management from storage pacity hidden from the user (overprovisioning). The policy. This enables SALSA to accommodate dif- more space that is overprovisioned, the better the GC ferent applications, each with its own policy, using performs. the same storage pool. This allows running MySQL and Swift on the same storage with high perfor- 2.2 SMR disks mance and a low overhead. Magnetic disks remain the medium of choice for many • SALSA embraces storage diversity by supporting applications [6], mainly due to low cost. However, mag- multiple types of devices. We present how we com- netic recording is reaching its density scaling limits. To bine SMRs and SSDs to speedup file retrieval for a increase disk capacity, a number of techniques have been video server workload (where adding an SSD im- proposed, one of which, Shingled Magnetic Recording proves read performance by 19:1×), without modi- (SMR) [16, 69], has recently become widely available fying the application. [20, 52]. SMRs gain density by precluding random up- dates. The density improvement is achieved by reducing The remaining of the paper is organized as follows. the track width, thereby fitting more tracks on the surface We start with our a brief overview of idiosyncratic stor- of a platter, without reducing the write head size. As a age and our motivation behind SALSA (x2). We con- result, while a track can be read as in conventional disks, tinue with a description of the design of SALSA (x3), it cannot be re-written without damaging adjacent tracks. discuss how we satisfy specific application workload re- SMR disks are typically organized into zones. Zones quirements (x4), and evaluate our approach (x5). Finally, are isolated from each other by guards, so that writes to we discuss related work (x6) and conclude (x7). a zone do not interfere with tracks on other zones. All 2 Background and Motivation the writes within a zone must be done in strict sequential order; however, multiple zones can be written to indepen- In this section, we provide a brief background on Flash- dently. These zones are called sequential zones. Drives, based SSDs (x2.1) and Shingled Magnetic Recording also, typically include a small number of conventional (SMR) disks (x2.2), analyze the limitations of commod- zones, where random updates are allowed. ity drive TLs (x2.3), and argue for a unified host TL ar- Three categories of SMR drives exist based on where chitecture (x2.4). the TL is placed: drive-managed (DM), host-managed 2 patterns, only sustaining about 16MiB/s for 4KiB blocks, 500 439 10.6 and 33MiB/s for 1MiB blocks. Interestingly, a block size 400 10 of 1MiB is not large enough to bring the write perfor- 300 out - mance of the drive to its ideal level; block sizes closer to 4.8 200 5 the GiB level are required instead, which better reflects Wear the native block size of modern dense Flash SSDs [8].