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.
- 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.
- 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.
- 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.
- 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.
- 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.