I spent two and a half days last week with a bunch of miscreants collected from around the globe (USA, Scotland, Australia, Nigeria, Holland, and — of all places — Ohio). We called it Seattle Tech Field Day, and it was organized by none other than my friend Stephen Foskett (and, of course, his right-hand, Claire Chaplais). For two exhausting days we experienced death-by-Powerpoint and listened to several vendor pitches, and we grilled said vendors about the strengths and weaknesses of their various approaches.
I was not paid to attend this event, but it did not cost me to attend it. I had free meals and drinks on these guys, and I got a few chotzkies, but I am under no obligation to blog about what I saw. So please consider the blogs I do write about this event to be products I found genuinely interesting.
This is the first of a few Tech Field Day blog posts that I will write, and it will cover Compellent and Nimble Storage. Both companies offer block-based arrays, which means they are SAN offerings, not NAS offerings. (Compellent does offer two NAS options by using a Windows Storage Server & CIFS or Nexenta and ZFS, but in the end that’s just a NAS head in front of a SAN array.) Both systems support thin provisioning, redirect-on-write snapshots (more on that later), and replication. Nimble is an iSCSI only array, and Compellent offers both iSCSI and Fibre Channel interfaces. Both companies believe that they are offering less expensive ways to store your data while increasing performance.
Compellent’s main emphasis is on automated storage tiering. They support SSD, SATA, SAS, and Fibre Channel drives natively within their enclosure, and they see each of these as a tier of storage to which they can move .5M, 2M, or 4M blocks of data depending on how much they are being used. The most-used blocks would be on SSD, the least-used blocks would be on SATA, etc. Their belief is that by automatically putting the appropriate blocks on the appropriate tiers of storage, you could store much more data for much longer periods of time for much less money – without having to worry about what to put where.
Nimble’s story is very different. They feel that the I/O requirements of all middle-enterprise customers can be met using SATA drives that are front-ended with an SSD cache. Where Compellent sees SSD as a tier on which to put the most recently used blocks, Nimble sees SSD as a place to store a copy of the most recently used blocks. Since they’re not using SSD as a tier, they can use less expensive versions of SSD drives and they do not have to put them in a RAID array and suffer the performance and capacity overhead associated with that. (If they lost an SSD drive, they have simple lost a cached copy of data and can reload it, as opposed to Compellent that would need to restore any data stored on a failed SSD volume.) While their competitors might argue that this means they’re storing two copies – which costs money – they argue that their second copy is on SATA disk – the cheapest of all disks.
The other thing that makes Nimble’s story different is that they support inline compression of all blocks before they’re even written to the flash cache. This increases performance as the blocks are written to cache, and even more when written to the SATA disks – and it saves capacity too.
Now let’s move on to the important stuff – backups! Anyone who reads this blog knows that I’m a fan of storage systems that offer snapshots and replication. I believe that, with proper management and reporting software, they can meet the backup and recovery needs of many (if not most) of today’s businesses – without requiring them to resort to traditional backup software. (I also call the combination of snapshots and replication “near-CDP,” but not everyone likes it when I do that.)
In order for snapshot-based backup to work, I thoroughly believe that the array vendor must not use copy-on-write snapshot technology. Copy-on-write is fine for creating a snapshot that you’re going to backup using other methods and then expire, but you cannot use a copy-on-write snapshot system to create hundreds of snapshots and keep them for multiple months, which is a requirement for snapshot-based backup to replace traditional backup software. If you were to do this with a copy-on-write array, you’d find your I/O performance significantly degraded over time. (One SE from a copy-on-write array vendor suggested that if a customer of mine kept 90 days of snapshots on their array, its performance would decrease by 50%.)
Redirect-on-write snapshots, however, do not have this performance issue, which is why they can keep hundreds of snapshots for hundreds of days and not suffer a performance penalty. This is why I was excited to hear that both the Compellent and Nimble Storage arrays use redirect-on-write snapshots, as this really fits into my way of thinking about backup. The snapshot systems of both are very similar, but Nimble is claiming that their snapshots are created with a much lower level of granularity that significantly reduces the amount of storage that their snapshots use. They had a use case where they compared 90 days of snapshots with their system to 90 days of snapshots with another “leading iSCSI vendor” (Gee, I wonder who that could be), and the difference was startling and resulted in a significant savings when compared to “the leading iSCSI vendor.”
Compellent is a four eight year old company with many customers. They said Gartner said that they were the 3rd fastest growing storage array vendor, but what that says to me is that they’re losing the “new storage array vendor” race. What I mean is that EMC, NetApp, HDS, IBM, and HP are not going to be going to be growing at the same rate as a storage array startup, and there’s not that many storage startups. So I think that being the 3rd fastest-growing storage array vendor means you’re towards the end of the pack, not in the front. (Update: That’s what I get for editing video while listening to a vendor pitch.)
Nimble, on the other hand, is a brand new company that announced its product at Tech Field Day last week. The product looks interesting, but we don’t know yet if anyone’s going to buy it.
I wish both products the best of luck!
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Architect at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.