How About My Snapshots?

Our previous post included a link to Anil Gupta's blog and a piece he wrote about Gear6. A reader left an interesting question:

I'd be interested in knowing is how point in time copies are handled? I decide I want to take a snap or checkpoint of my production volumes; do I have to flush the cache appliances to ensure consistency? (full blog comment here)

To best address this question, and numerous others we expect to receive, we decided to preview the design philosophy behind our CACHEfx appliance. Please keep in mind that we have not publicly announced all of these product details. Stay tuned for that shortly. Hopefully these design guidelines will provide more clarity on where we see Gear6 in the market, and how we aim to solve users storage and application performance issues.

CENTRALIZED STORAGE CACHING DESIGN GUIDELINES

Gear6 used these basic principles when designing our product. We'll plan to expand on each of these in more detail, but this should get the ball rolling.

1. No new file system
   Gear6 believes that the industry has created plenty of great file systems and that there is no need to replicate that work. Our product is designed to retain and complement existing file systems.


2. No new persistent storage / no data movement
   Gear6 believes that existing storage systems are great at doing what they were designed to do: maintain storage persistence. We don't see these systems as necessarily having the performance capabilities for today's workloads, but that shouldn't mean a rip-and-replace requirement for customers. Further, customers shouldn't have to move data around in order to get a performance boost. That is typically a real pain and something users generally try to minimize and avoid.


3. Transparency in the data path
   Many products and solutions promoting performance increases are not transparent, meaning there is some change to the data or data placement compared to how it was handled previously. A good example of this is file virtualization engines. Place one of those in your environment and keep your fingers crossed because there is generally no other way out in case of emergency.
   Gear6 believes that customers should have the ability to get a massive performance boost via a caching appliance, but also have the option or ability to see and access their data directly, bypassing the cache if that is appropriate for a particular application.


4. Maximize use of existing application and storage software
   Gear6 addresses storage performance issues by applying caching as a shared network resource. This implies the use of all existing applications "as-is". Specifically, users should not have to change anything at the client/application layer and similarly, they should not have to change anything at the storage management layer. This greatly simplifies deployment, provides maximum investment protection, and focuses on adding concentrated value without diluting or disrupting an embedded ecosystem of existing software solutions.


5. Tune at the appliance level
   Data center systems are constantly evolving based on emerging workloads, changing user behavior, general data growth, and requirements for new applications. Gear6 addresses this shifting landscape by providing tools to tune at the appliance level. Specifically, Gear6 aims to deliver more user control and coordination at the network level so that users can avoid more costly and time consuming changes, upgrades, or modifications at the application or storage levels.

And now back to our question....

So if the question is "how do I handle my snapshots?" the answer is, "just like you always did." No change to user behavior and no change to software policies and procedures. Since the cache is designed to be transparent, the filer’s data is always consistent and there is never a need to manually flush the cache.

There will certainly be more questions about implementation and deployment of Gear6 products. But hopefully these guidelines will provide customers with room to sit back and consider how best to think about centralized storage caching for their environments.

Comments

[Storagezilla]

Your timing is impeccable, I was just blogging the fact that you said you'd answer the question when I went looking for your URL to find that you just finished answering the question :)

[Anil Gupta]

Awesome! leveraging the blog to discuss your design philosophy and being interactive with your readers. Looking forward to reading your product launch and company growth.

[kirby]

Best to get the facts straight before throwing stones.

"A good example of this is file virtualization engines. Place one of those in your environment and keep your fingers crossed because there is generally no other way out in case of emergency."

A good example of self serving corporate blog smarm.

The fact is that a well designed file virtualization engine doesn't modify or change the file in any way. In an emergency (what ever that means) the file is readily accesible, and if the user ever wants to 'de-virtualize' for some reason its a straightforward process.

There is no reason to target file virtualization as an alternative to caching, BTW. FAN encompasses performance teirs based on high speed memory, allowing them to be seamlessly managed along with general purpose storage, retention, and archival media. We would welcome Gear6 to the SNIA FAN Task Force and look forward to your contributions for moving FAN forward.

[Gary O]

Kirby,
Thanks for your comments. Your point is well taken. The intent was not to target file virtualization, but rather to show the difference in design approaches. You are right that a well-designed file virtualization engine doesn't modify or change the file, but by definition would require "de-virtualization" if the file virtualization capability was no longer needed. If I understand correctly, this is quite different from a solution that allows a simultaneous "direct-access" approach.
Gary

[gbush_byteandswitch]

I'm curious how this works, I know specs weren't released but if its transparent, that would mean I just "plug" in the device into my existing LAN (keeping it layer 2, since layer 3 adds latency in milliseconds) and voila my NFS clients will get accelerated? Or am I going to have to create mount/modify stuff in my automount maps to get this going? I can see how you can get some transparency with the assistance of IP (layer 3) technologies like wccp/pbr on routers to redirect NFS traffic but I guess you can answer that one Gary O.

Assuming you had to mount through this device, wouldn't it be done via NFS? so, in some ways, its a clustered/memory-based NFS file server or proxy of some kind?

My last thought is, currently this device supports 256GB of memory(assuming a 32GB mobo capacity) that would be 8 servers in a cluster, are files placed in a concatenated fashion? Or in a strip-wise fashion across the servers? Since NFS clients mount using one IP, is there a virtual IP it connects to that hides the real IP's the servers are configured with? If not, how's data returned who's data crosses multiple servers (assuming there are multiple servers)? via Private/data LANs?

Well, I'll wait for the product to launch and allow customers to have their comments and successes. I'd also like to know the applications used to drive the cachefx and how the data will be collected.

I don't know, microsecond response time would be great! Considering process overhead, compression/decompression schemes and other miscellaneous things usually happening inside any product. If someone can put an inline analyzer and generate a pcap file and get a SRT (server response time) data for NFS, that'd be an easy buy for me.

gbush

[garyo]

Great questions and comments. We'll be sharing more technical detail over the next few months. In the meantime, we are happy to provide any info required to prospective customers one-on-one. Thanks, Gary