Commvault and Nimble Integration

[a_user57]

Hi All,

This question is not necessarily related directly to Nimble, but revolves around the integration of Nimble, Commvault IntelliSnap, and ESXi. We are in the process of revisiting our VMFS layout's and are looking at consolidating a number of current vmfs volumes that contain single vmdk's that are assigned to individual servers, to less, larger VMFS volumes, since the storage backing these volumes are all the same, I dont see there being a performance penalty. This is not for VMFS volumes hosting VM's, but for data volumes attached to individuals guest vm's.

We are not yet a Commvault customer but are seriously considering going this route. We will be beginning our evaluation in the new year. What I am trying to understand, is if there any best practices around Nimble and Commvault for VMFS volume sizes, when it comes to snapshotting a VMFS volume. Are 3 and 4tb VMFS volumes with anywhere  from 5-20 vmdk's per volume okay? I have been unable to find any best practices, and since I know Commvault and Nimble have worked on integration of their respective products, I was hoping some fellow Nimble customers might be able to provide some feedback, guidelines or point me in the right direction.

My contact at Commvault has been difficult to work with in coordinating time to get in touch with engineers, so I am turning to the community here.

Thanks

[wen35]

Hi C W, I have reached out to our engineering/support teams on specific recommendations on Commvault - will post back once i get such info.  Regarding consolidation of VMs into a larger VMFS volumes - my recommendation would be to start out small (say 5-10) # of VMs, let them run through VSS quiesced snapshots and see if things work okay.  You can then start adding more VMs in iterations.  Keep in mind that a backup job for a VMFS volume with multiple VMs means quiescing application, take VMW snapshot, then array snapshot + delete VMW snapshot for each VM. 

Are you looking to mix similar apps on the same VMFS volume?

[a_user57]

Thanks Wen, that is appreciated.

Just to clarify what I am doing, I am consolidating similar vmdk's on fewer but larger vmfs volumes. I am not worried about the VMFS volumes that contain only the OS vmdk's. The VMFS volumes that host the VM's OS drives (about 30) contain between 15-30 VM's each (for a total of 680 vm's or so). I am just focused on the VMFS volumes that house data drives. For example, we have 38 SQL servers in our environment. Each SQL server has 2 VMFS volumes associated with it. One VMFS volume contains a single VMDK that houses that servers database volume and another separate VMFS volume that contains just a single VMDK that contains the servers logs volume. No other servers share the VMFS. So two extra VMFS volumes per server, one log, one database. Obviously this means increased connection counts, increased management (space monitoring, setup, etc.) and increased load times in vCenter.

I want to consolidate SQL server databases volumes on a few VMFS volumes, for example DEV SQL server log volumes on a couple VMFS volumes, databases on a couple VMFS volumes, same for Prod, QA, UAT, etc. Same goes for file servers, and application servers where applicable. My biggest concern here was that these vmfs volumes will contain a considerable amount of data each. I do not suspect the change rate will be outside what a volume based snapshot will be able to handle efficiently, but I wanted to make sure there were no immediately published gotcha's I need to be aware of before I start down this path (storage vmotion'ing over 35tb of data)

Hopefully that makes a little bit more clear.

[wen35]

Thanks for the clarification C W - yes, it makes sense.  I could certainly see why you want to consolidate.  One thing to keep in mind  - the volume collection should contain the right combination of db & log VMFS volumes.  Definitely do this in progression with 5-10 VMs per volume first and see how things go. 

Will post back once i get more info from our support/eng folks.

[marktheblue45]

Hi,

    Surely having many Database/Log VMDK's on one volume breaks the best practice guidelines? Since only one SQL server can Quiesce the volume(s) then for this to work the SQL Server would need to "own" or be responsible for the DB's and Logs contained therein. Obviously I am assuming best practice guidelines. Obviously if you are using agent based backups then that's a different story but then the snapshots of these (fewer) volumes would need to use Vcentre (VCenter if USA) crash consisten snaps.

Regards,

               Mark

[a_user57]

Not necessarily. In fact commvault expects this. Their intellisnap solution allows you specify what disks/vm's to pull from the snapshot. In other words, you snapshot the entire volume, commvault indexes/identifies the contents of that snapshot, then will extract and backup only the machines out of that snapshot you specify as part of the actual backup job.

My concern was based around the data size of the volumes and processing time.

[rugby0134 · Accepted solution]

C W - make sure your keeping your Data and Log volumes separate.  SQL log volumes should have Nimble cache disabled.  Running backups on cached log volume can cause the cache to flush valid blocks of data and replace with log blocks.  So make sure what ever you decided, Data on cached volumes, and logs on un-cached.

Kevin

[marktheblue45]

There's a great guide on integration with commvault snap and replicate. Worth a read. The biggest pain is troublesome VM's that fail to quiesce and that's not a Nimble specific error. When digging deep into these issues you nearly always end up with the suggestion to disable vss by modifying the tools.conf file (if it exists) or creating one. This is missing the point somewhat and not app consistent. There's a certain elegance to having in-guest iSCSI volumes for DB's and then using the Commvault agents to snap and replicate, plus you can use SAN mode so it's very fast. Using this method negates the need for ESX host mounting of the snaps that can be a little clunky.