Portable Volumes and SSD's Affinity for Small Block Sizes; Final Thoughts from C-Drive
I started this blog entry last week while I was in attendance at Compellent's C-Drive. However it was only last night as I was flying to Boston to attend EMC World that I had the opportunity to wrap it up. The specific items on my mind that I wanted to highlight in this blog were two emerging technology trends that came into sharper focus while I was in attendance at C-Drive.
The first technology or its application that I wanted to comment on was the topic of portable volumes. Portable volumes (for those unacquainted with the term) are copies of production data that are stored to portable media such as USB thumb drives, tape cartridges, RDX disk cartridges or USB attached HDDs by replication software.
However the purpose of portable volumes is not to serve as a backup copy of production data (though they can certainly be used in that way). Rather they are intended to be used as an initial copy of production data that are then taken to another site and used as the first copy of data when doing replication.
The reason these portable volumes are needed in the first place is that creating this first off-site copy of data can be both time consuming and bandwidth intensive. While portable volumes are probably not needed if an organization is only replicating a few GBs or tens of GBs of data, as the amount of data grows into the hundreds of GBs, TBs or tens of TBs, copying all of that data over a network link to get the first good copy of data at the target site becomes impractical.
This is why the concept of portable volumes is becoming a need. Rather than copying all of this data over a network link, the replication software creates a portable volume on a locally attached storage device.
This enables organizations to quickly make this initial copy of data locally and then carry, drive, fly or ship this volume to the offsite location. Once at the offsite location, an organization only needs to restore that portable volume to the target replication device. At that point, the replication software syncs up the data at the source and target site by the source sending over the changes since the portable volume was created and replication begins.
So why did portable volumes catch my attention at C-Drive? Just a few weeks ago I had talked about R1Soft's introduction of this feature into its new CDP Standard Edition software. Now Compellent was talking about the new ability of its native Storage Center replication software to do the same thing. In the case of both R1Soft and Compellent, users of both these companies replication software were requesting the same type of functionality. This would seem to suggest that if this portable volumes feature is not already found in the replication software that you use, expect to find it sometime in the near future.
The impact that SSDs are about to have on midrange arrays was also again brought to my attention at C-Drive. The 2008 C-Drive was when I saw first hand the high level of interest that users had in SSD and that has not changed in the last two years. If anything, the interest in SSDs has intensified.
While at C-Drive, I popped into a session being hosted by STEC's VP of Technical Marketing, Scott Stetzer, to find a room packed with end users. In listening to his presentation, one point he made that piqued my interest was how SSDs were not optimized for large block sequential reads or writes. Stetzer even went so far to say that under certain conditions, HDDs may actually be as fast as SSDs when doing large amounts of sequential block read or writes.
This was the first I had heard of SDDs struggling under these types of loads. While Stetzer did not imply that HDDs would perform better than SSDs, he merely pointed out that SSDs are optimized for random reads and writes and will achieve the highest throughput in those environments.
Followng the presentation, I stopped by STEC's booth at C-Drive and talked to Nathan Hicks, an STEC Field Applications Engineer. He did a few demos for me showing how throughput decreased as the block sizes of the read and write I/Os increased.
Though these demos should not necessarily be interpreted to reflect what would happen in real world situations, as he increased the block sizes from 1K to 4K and then 8K in the demo, you could see the I/O throughput drop by about 10,000 IOPS with each increase in block size. This is again substantially better than what HDDs can achieve but it served to demonstrate how the more that organizations use applications that use small block sizes (512 bytes is ideal for SSDs) the better the SSDs will perform.
Those are my final thoughts from last week's attendance at C-Drive. Look for additional blogs later this week that will coincide with some press releases as well as some insight into what is happening at EMC World in Boston.
The first technology or its application that I wanted to comment on was the topic of portable volumes. Portable volumes (for those unacquainted with the term) are copies of production data that are stored to portable media such as USB thumb drives, tape cartridges, RDX disk cartridges or USB attached HDDs by replication software.
However the purpose of portable volumes is not to serve as a backup copy of production data (though they can certainly be used in that way). Rather they are intended to be used as an initial copy of production data that are then taken to another site and used as the first copy of data when doing replication.
The reason these portable volumes are needed in the first place is that creating this first off-site copy of data can be both time consuming and bandwidth intensive. While portable volumes are probably not needed if an organization is only replicating a few GBs or tens of GBs of data, as the amount of data grows into the hundreds of GBs, TBs or tens of TBs, copying all of that data over a network link to get the first good copy of data at the target site becomes impractical.
This is why the concept of portable volumes is becoming a need. Rather than copying all of this data over a network link, the replication software creates a portable volume on a locally attached storage device.
This enables organizations to quickly make this initial copy of data locally and then carry, drive, fly or ship this volume to the offsite location. Once at the offsite location, an organization only needs to restore that portable volume to the target replication device. At that point, the replication software syncs up the data at the source and target site by the source sending over the changes since the portable volume was created and replication begins.
So why did portable volumes catch my attention at C-Drive? Just a few weeks ago I had talked about R1Soft's introduction of this feature into its new CDP Standard Edition software. Now Compellent was talking about the new ability of its native Storage Center replication software to do the same thing. In the case of both R1Soft and Compellent, users of both these companies replication software were requesting the same type of functionality. This would seem to suggest that if this portable volumes feature is not already found in the replication software that you use, expect to find it sometime in the near future.
The impact that SSDs are about to have on midrange arrays was also again brought to my attention at C-Drive. The 2008 C-Drive was when I saw first hand the high level of interest that users had in SSD and that has not changed in the last two years. If anything, the interest in SSDs has intensified.
While at C-Drive, I popped into a session being hosted by STEC's VP of Technical Marketing, Scott Stetzer, to find a room packed with end users. In listening to his presentation, one point he made that piqued my interest was how SSDs were not optimized for large block sequential reads or writes. Stetzer even went so far to say that under certain conditions, HDDs may actually be as fast as SSDs when doing large amounts of sequential block read or writes.
This was the first I had heard of SDDs struggling under these types of loads. While Stetzer did not imply that HDDs would perform better than SSDs, he merely pointed out that SSDs are optimized for random reads and writes and will achieve the highest throughput in those environments.
Followng the presentation, I stopped by STEC's booth at C-Drive and talked to Nathan Hicks, an STEC Field Applications Engineer. He did a few demos for me showing how throughput decreased as the block sizes of the read and write I/Os increased.
Though these demos should not necessarily be interpreted to reflect what would happen in real world situations, as he increased the block sizes from 1K to 4K and then 8K in the demo, you could see the I/O throughput drop by about 10,000 IOPS with each increase in block size. This is again substantially better than what HDDs can achieve but it served to demonstrate how the more that organizations use applications that use small block sizes (512 bytes is ideal for SSDs) the better the SSDs will perform.
Those are my final thoughts from last week's attendance at C-Drive. Look for additional blogs later this week that will coincide with some press releases as well as some insight into what is happening at EMC World in Boston.
Buyers Guide
Newsletter Signup
Leave a comment