Subscribe

Help define SMVI application-consistent B/R

I’ve gotten a whole lot of requests for “application-consistent” B/R support in SMVI and SMVI/SnapManager integration.  Let me explain what I understand application-consistent B/R to mean and what SMVI provides today, and then I’d love to hear your feedback about what else is required.

Applications can be divided into 2 basic types:

(1)   Infrastructure applications, or those applications – actually any data – that don’t require “special handling”.  SMVI can backup up these today using VMware snapshots “underneath” NetApp Snapshots.

(2)   Mission-critical applications, or those applications – like SQL, Exchange or Oracle – that do require “special handling”.  There are 2 ways to handle mission-critical applications, and each has its advantages and disadvantages.

a.    SMVI working through the VMware guest VSS stack

Leo Yaroslavsky has created a wiki page that discusses this method in detail, with all of its advantages and disadvantages (http://wikid/w/User:Leoy/SMVI%2BVSS%2BSDW). 

b.    Application SnapManagers

Advantage:

1.    Fine-grained recovery versus full VM restore only.

Disadvantages:

2.    Only the application data is backed up, not the system data.

3.    No coordinated scheduling for system data (SMVI) and application data (SnapManagers).

4.    More expensive. 

A few questions for you … 

1.    Is the VI Admin responsible for backup and/or restore of mission-critical applications today?

2.    Will the VI Admin be responsible for backup and/or restore of mission-critical applications in the future?

3.    Is there a need for the DBA/App Admin to backup the entire mission-critical application environment (system and application data)?

4.    Is there a need for the DBA/App Admin to restore the entire mission-critical application environment (system and application data)?

5.    Will the DBA/App Admin use vCenter for mission-critical application backup and/or restore?

6.    Is the VSS method acceptable for backup and restore of mission-critical applications, or is fine-grained recovery required?

7.    Should both the VI Admin and DBA/App Admin be able to use the same UI, although their roles/responsibilities are different?

Your input/feedback would be greatly appreciated! 

Re: Help define SMVI application-consistent B/R

One note (before a further reply) -- the "wikid" link above doesn't resolve (either as it is above or when changing it to wikid.netapp.com).

Re: Help define SMVI application-consistent B/R

I apologize to all of you ... I realize that the wiki link I referred to is for an internal wiki page.  I am in the process of getting a document with the same content approved for external consumption.  Stay tuned ... I'll post as soon as I get the go-ahead.

Re: Help define SMVI application-consistent B/R

1. Yes - This is currently the case within my organization.

2. Yes - I believe that this is becoming all the more prevalent, especially in environments where SnapMirror and VMware SRM are deployed.

3. Yes - Again, especially in environments where Snapmirror is used to replicate VMs to a remote DR site. It is essential that both the VM itself and the application data is consistent before it gets snapmirrored to the DR site. At present there seems to be a disconnect between the Snapmanager products as my understanding is that taking quiesced VMware snapshots of virtual machines which have internally connected LUNs using the MS iSCSI initiator is not supported, and being that currently iSCSI is the only way to go when using SME/SMSQL in virtual environments it means that SMVI cannot be used to take a quiesced snapshot of a VM when used in conjunction with SME/SMSQL. This is something that I am currently struggling to figure out how to mitigate.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009073

4. Yes – Maybe not for the DBA/App admin in the live environment, but certainly for a VI Admin when failing over machines in a DR situation.

5. I believe that in the majority of environments the responsibility will fall to the VI Admin, however if it were an option I am sure that it would be utilized.

6. Both are required, preferably at the same time and under management of a single application.

7. Yes

Re: Help define SMVI application-consistent B/R

Speaking as a partner systems engineer, what I've seen so far is...

  1. Sometimes -- really depends on the distribution of responsibilities within the organization.
  2. Likely so given capabilities that only the VM admin would be familiar with....but again, not always.
  3. Yes.
  4. No.
  5. Possibly -- vCenter access can often be quite a thorny issue (often organizations stay away from it so as to avoid all the permissions complexity in vCenter).
  6. VSS seems sufficient so far.
  7. Preferably same UI so when the DB Admin needs help he can have someone else internally semi-familiar with what it looks like.

Hopefully helpful...

Re: Help define SMVI application-consistent B/R

Just a side note on the VSS requirements. This is a selling point of SME, SMSQL and so on as they don't just integrate with VSS, but they integrate at the backup level. Using VSS alone isn't enough for Exchange or SQL to understand that a full backup has been performed and so they won't truncate their logs. There needs to be full application integration to get full consistency of mission critical applications. So no, VSS is not sufficient for these. And we also have to take into account the mission critical applications that aren't VSS aware, or at least not functionally advanced in VSS respects, like Oracle and SAP! I would position these as much more mission critical than say SharePoint.

But what if the SMAI tools had their own VSS writer, then a SMAI job could be triggered from a VSS call, which could be part of the VMware tools process of taking a snapshot. Maybe?

Re: Help define SMVI application-consistent B/R

I can't believe I forgot to mention that.....total agreement.

We have already run into multiple situations where having some degree of coordination between SMVI, SME & SMSQL would be invaluable (realizing that SME & SMSQL need RDM's in VM environments).

What Chris is suggesting sounds ideal.