Once in a while a new technology comes along and despite all your best efforts, it is a challenge to put a measure on the value. So it is with Seagate’s Kinetic announcement, which has been covered across the media recently. In case you missed it, here’s the press release. Seagate are claiming it as a breakthrough in hard drive usage as the devices use Ethernet for connectivity and store data as objects (more on that in a moment). However, I have to say I’m not fully convinced.
Drive & Interface
First of all let’s look at the drive itself. Generation 1 of the Kinetic HDD is a 4TB device spinning at 5900RPM in a standard 3.5″ form factor. Rather than use SATA or SAS interfaces, Kinetic uses two 1Gb/s Ethernet connectors, with a standard Serial Gigabit Media Independent Interface (SGMII) connector that looks like the ones found on standard SAS HDDs. However today we already have 6Gb/s SAS and SATA interfaces with the promise of 12GB/s around the corner. SAS has plenty of additional features like tagged command queuing, multi-path I/O, multiple SAS initiators and is used across the industry as the back-end protocol in most high-end storage arrays. Other than peer to peer replication, I don’t see any of these features in the Kinetic specification. Based on their interface alone, a Kinetic drive will never be able to move more than approximately 100MB/s of data (assuming one active interface and one for redundancy). For a completely full 4TB drive, that’s a transfer time of around 11 hours at best to replicate the content elsewhere. However the current range of Constellation drives can already perform a sustained 175MB/s throughput, which means SAS/SATA is essential to get best performance.
Seagate cite an example configuration that stores 60 drives in a 4U chassis (or 1U per 15 drives). This in itself presents problems of maintenance as all of the drives will be extremely closely located. As an example, take HP’s MSA2040 storage array. This supports 12 drives in 2U, all at the front of the unit, based on drive size. Imagine a Kinetic chassis that uses this same layout. In 4U this could support 24 drives, with an additional 24 at the rear. This still leaves 12 drives to be located somewhere inside the chassis and no space for power, the chassis controller or Ethernet connectors, meaning some drives will have to be physically moved to service others. Seagate’s rack configuration shows ten of these chassis in a single rack – 600 drives. At current specifications, these drives would weigh around 420kg (excluding the controllers) and require a minimum of 7.2kW of power. They would also be extremely difficult to cool, requiring significant airflow. We saw a few years back how Copan Systems had issues with floor loading in such dense configurations.
One of the main selling points of Kinetic is the use of object-based data storage to and from disk. Currently, disk drives commit data as either 512 byte or 4KB blocks, accessible using logical block address or LBA. Kinetic uses a key-value system that stores objects based on a user defined key (limited to 4KB) and a maximum 1MB object size. The object size limit is too small to be of useful value, as many objects being stored on disk will be larger than 1MB (imagine each object is a PowerPoint presentation). This means additional metadata needs to be stored elsewhere to track objects that have to be sharded or subdivided into multiple chunks. So there is a management overhead.
By the way, object storage on disk isn’t a new phenomenon. If we look back at the way mainframe data was stored on disk, we find a similar architecture called Count-Key-Data or CKD, which allowed data to be stored on disk in key/value pairs. Admittedly, most of the time disks were formatted with consistent standard sized blocks, but the principle already exists. Welcome to the 1960’s…
Seagate implies in their description of The Ecosystem that all drives will be accessible to all “nodes” in a configuration (presumably meaning servers or hosts here) and that storage servers are no longer required. They say “a whole layer of processors, memory & associated power/cooling…. go away”. Unfortunately this isn’t the case. There still needs to be some process or system to handle failed drives and do capacity management. Imagine having no central point of control; all nodes could store data across all drives. This seems like a useful concept, but what algorithm will those nodes use to choose the best and most appropriate drive? Will they use performance, capacity? Will they know the physical architecture in order to place data replicas across controllers and power boundaries? Imagine a multi-tenant scenario, where tenants are all creating data based on capacity. Without a central repository, each tenant would have to poll every device regularly just to see the status of space available. Imagine if a tenant had a software bug and didn’t commit or save the details of a stored object. It would be easy to end up with hundreds of orphan objects without any easy way of tracing them back to an owner. Centralised management is still needed.
Enough of the Negativity
OK, so I’m be overly negative. There are scenarios where this technology could be implemented and used within distributed databases or object stores and perhaps over time, the limitations on object size will be removed. I understand that and can see those use cases. However I don’t think Seagate’s positioning on efficiency is fair or balanced. There’s a large amount of management overhead still required to keep track of data stored on any disk format. The ability to store data as an object doesn’t solve all our problems. This is definitely a version 1.0 product, but with more work, I expect we may see version 2.0 or probably 3.0 delivering on what’s been initially promised.
- Kinetic Open Storage Documentation Wiki (Seagate Developers Site)
Comments are always welcome; please indicate if you work for a vendor as it’s only fair. If you have any related links of interest, please feel free to add them as a comment for consideration.
Subscribe to the newsletter! – simply follow this link and enter your basic details (email addresses not shared with any other site).
Copyright (c) 2013 – Brookend Ltd, first published on http://architecting.it, do not reproduce without permission.