You have probably seen by now that software version 6.4 has been released for Storwize V7000 and SAN Volume Controller. The full release notes are available here.
Barry Whyte has provided a brief overview of the new features available in this release. I would suggest you reference his post here.
Undoubtedly the key new feature in this software version is Real-time Compression. Real-time Compression (abbreviated as RtC henceforth) is a technology IBM gained as part of the Storwize acquisition. Previous to this SVC/V7000 release, RtC was only available in the RtC Appliance. The development teams in Hursley (Primary site of SVC/V7000 development) and Israel (Primary site of RtC development) managed to embed this technology as a software only feature in existing SVC and V7000s. I think this demonstrates the capability of the hardware and software stack in SVC/V7000, which Barry has alluded to in a previous post.
This blog is not the place to go into great detail about how this new feature works. There is a great resource available now which provides all of the gritty details:
However if you are unwilling or don’t have the time to read a Redbook here is my very high level overview of RtC in the V7000/SVC:
RtC is a new type of thin provisioned volume. The major difference is a RtC volume uses an additional caching layer in the software stack to compress the data in “real-time” before it is written to disk. The compression uses a standard algorithm, but the secret sauce is really in how the data is compressed (review the Redbook). The key thing I recommend remembering is like so many of the advanced SVC/V7000 functions, RtC is seamless to implement and hosts are insulated from the changes happening to the data behind the virtualization layer. Compressibility and performance mileage of data will vary, however lab testing has shown the RtC can be deployed on primary data types (email, databases, etc.) with great compression ratios and minimal performance overhead…and in many cases performance improvement.
Enough back-ground information, now to share some screenshots…
New volumes can be deployed from the GUI or CLI as Compressed. Creating a new compressed volume is the same as creating any other volume type.
Existing volumes can be converted to compressed by using Volume Mirroring. I select a volume, add a Mirrored Copy, and select the new type to be compressed. Once my volume is in sync I can remove the original copy.
The GUI has been updated in a few places. For example we now show two separate CPU graphs, one for system and another for compression. Compression can impact the CPU resources on a system so we want to provide a way to view the CPU usage.
If you are using RtC we obviously want to provide you a way to view how much space you are saving! Several of the GUI capacity views have been updated. This is an example of a compressed volume with a Jetstress database on it. Key items to look at are “Before Compression” which is the capacity that would have been consumed if this was a thin provisioned volume., and the “Used” metric which is the capacity that is actually being used. In this case the compression savings are 75%.
I purposefully excluded any mention of VMware in this post because I wanted to dedicated an entire post to that topic. So tune in later for a comprehensive overview of Real-time Compression with VMware.
One other thing I forgot to mention. IBM is offering a 45 day trial of RtC. This allows you to kick the tires on the feature, see how it works with your environment. Details of this program and also some very valuable info on evaluating RtC can be found here.