Flash + SMR = Storage Density and Performance

Shingled Magnetic Recording (SMR) hard disk drives do something remarkable. For the same basic bill of materials and occupying the same physical space as traditional hard disk drives (HDDs), they increase the amount of available capacity. For example, an 8TB SMR HDD uses the same amount of material as a regular 6TB HDD. Companies, such as Seagate, are confident that the technology can extend this capacity to 20TBs. However, the current 35 percent increase in capacity comes at a cost. SMR drives don’t perform as well with random writes and prefer to have data written to them sequentially. This limitation affects their applicable use cases and their adoption. If, however, flash storage is combined with the right software, it can act as a “cushion” to the SMR drives enabling data centers to rapidly adopt solidly performing, but highly-dense storage infrastructures, which will expand the use cases.

What are SMR Drives?

Increases in capacity for traditional HDDs have been obtained by decreasing the size of the write head. But manufacturers have now reached a point where they can’t make the write head any smaller without impacting data integrity. The read head, however, can be made smaller because it does not have to worry about data integrity. Since the 1990s, HDDs have used separate read and write heads, but the width of the write head defined the smallest width of the track. SMR drives are the first drives to record tracks which overwrite a portion of previously written tracks. The write stripes overlap across drive tracks like the shingles on a roof, hence, the term shingled recording. This permits a higher track-per-inch layout on the media. Because the read head is smaller than the write head, a read can detect the data in the exposed portion of the correct track.

When data is written to an empty drive, there is little performance impact from the use of SMR technology. When existing data is changed however, the drive must first read in the changing data, and because the write head is bigger, it also must read in the overlapping data on the next track. The SMR technology then writes the changed data and impacted data to both tracks as a complete set. Each data update requires additional reads and writes as well as more data organization than is necessary on a traditional HDD. While read performance is essentially unaffected by the technology, random write performance is an issue and steps should be taken to “sequentialize” (i.e., put in sequential order) data as much as possible. SMR drives include internal cache and logic to try to minimize this impact, but with larger datasets, the internal cache is not large enough to overcome all scenarios.

What is Random I/O?

Random I/O occurs when data is spread out in various locations across the HDD, requiring the heads to spend time constantly moving, losing performance as a result. Random writes occur when small changes are made to large files or large files are fragmented into many separate pieces. Common sources of random I/O are databases, documents, and file-system metadata. Because SMR drives are not positioned as primary storage for production databases, the performance concern is in their typical use case — environments that will store discrete files, like documents, images, and videos. SMR drives will have to deal with updates to these files and the metadata that the file-system, which stores these files, will create and update.

Flash to the Rescue

At the opposite end of the spectrum is flash. It is ideal for random I/O and could be the ideal cushion for SMR drives. With proper software, such as caching software, data could stay on the flash drive until it reaches a point of persistence or aggregated into a single sequential file and then it could be sent to the SMR HDD tier. The user will experience instant response to the data they are working on and fast response when accessing older data. At the same time, the overall cost of the combined storage system is incredibly inexpensive and its physical footprint in the data center is minuscule.

Optimize Flash Software

The standard caching software must be modified to fully compliment SMR drives. Vendors design most caching software to cache reads and to flush writes as quickly as possible. Read performance—although caching will help—is not the primary issue with SMR drives. Random write performance is the issue. The caching software will need to be tuned to hold active data for a longer period until it reaches a point of persistence. Again, in most cases, this will be a few minutes, and because flash storage maintains data through a power loss, the risk of data loss is slight. If data loss is a concern, the flash can be mirrored for redundancy.

The flash software should also detect random write patterns and focus its capacity toward caching that data. Sequentially written data should flow directly to the SMR drive. Finally, the software should also integrate into the file-system and automatically cache file-system metadata.

Impact of Density and Performance

Using SMR drives, IT professionals and storage integrators can develop highly dense storage architectures that can store more than 2PB of data in a rack at a cost of pennies per GB. That same system can be front-ended by a couple of TBs of flash storage to act as a cushion, so that random writes and file-system metadata operations happen at very high speeds. Achieving multiple PBs of capacity in a single rack requires that every drive bay be used for the SMR drives. The flash technology can be installed in a PCIe or M.2 slot, saving the traditional drive bays for the SMR drives.

Adding flash to SMR drive configurations also allows data centers to adopt SMR drive technology much sooner. Instead of waiting for applications and filesystems to be re-written to better control how data is written, the flash and its caching software can manage this for them.

Example of Flash/SMR vs. Traditional Storage in A Ceph Architecture

seagate pic

Conclusion

Two pressures are placed on both cloud and traditional data centers today. The first is to meet the ever-increasing demand for performance. Flash, in its various forms, can meet these requirements. On the other end of the spectrum is the increasing capacity demanded to manage unstructured data generated from users and machines. The answer to these environments has not been as simple. Flash, by itself, is not the answer due to its higher cost per byte, and SMR drives improve the capacity demands, but are limited with random write performance. By coupling SMR drives with flash, these two technologies can create a very practical solution and enables adoption without significant change to the existing infrastructure.

This independently developed document is sponsored by Seagate. The document may utilize publicly available material from various vendors, including Seagate, but it does not necessarily reflect the positions of such vendors on the issues addressed in this document.

About Seagate

Seagate creates space for the human experience by innovating how data is stored, shared and used. Learn more at www.seagate.com


Twelve years ago George Crump founded Storage Switzerland with one simple goal; to educate IT professionals about all aspects of data center storage. He is the primary contributor to Storage Switzerland and is a heavily sought after public speaker. With over 25 years of experience designing storage solutions for data centers across the US, he has seen the birth of such technologies as RAID, NAS and SAN, Virtualization, Cloud and Enterprise Flash. Prior to founding Storage Switzerland he was CTO at one of the nation's largest storage integrators where he was in charge of technology testing, integration and product selection.

Tagged with: , , , , , , ,
Posted in Article
One comment on “Flash + SMR = Storage Density and Performance
  1. Tim Wessels says:

    Well, SMR HDDs would seem to be ideal for capacity storage when using object-based storage software. The data being stored is usually warm, cold or archival in nature. Updates will be less frequent, so there will be a reduce requirement to re-write data. Object storage software typically disperses data using either replication, which makes complete copies of each object, or erasure coding, which shards each object into data pieces and creates parity pieces prior to dispersing them in the storage cluster. The CAP theorem (Eric Brewer) comes into play here because a distributed object-based storage cluster cannot satisfy the need for data consistency, availability and partition tolerance all at the same time. It would be interesting to see how the use of flash storage would affect the write operations under the constraints imposed by the CAP theorem.

Comments are closed.

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 22,238 other followers

Blog Stats
  • 1,551,535 views
%d bloggers like this: