2009-12-23 08:25 AM
We have a customer who have a Netapp solution in a VMWare environment. It is smaller installation so they also have Exchange and SQL in VMWare servers. We will implement SMVI for backup but we are wondering when to use SM for Exchange and SM for SQL. We have follwoing concerns:
1. Can SME and SMSQL work with SMVI? Is there a need to use both solutions?
2. What advantages will bring for example SME if we are already using SMVI?
3. Will SME or SMSQL work on the same virtual machine as SMVI or those products do not work together?
4. Does SME and SMSQL work at all with VMDKs?
5. Is there any whitepaper how to use SME or SMSQL in VM environment?
Thanks for all your help, regards, Ales
Solved! SEE THE SOLUTION
2009-12-24 12:55 AM
Any backup (snapshot or traditional) needs to contain a complete set of related data to be useful for restore. So to properly back up your database application (Exchange, SQL, Oracle, etc.), you should always use some sort of agent to bring the database in a consistent state. Meaning that any data in the RAM is written to disk, the logfiles are up to date and the database is quiesced.
You use SME or SMSQL to bring your database in that consistent state. SMVI doesn't bring your application in a consistent state, only the OS (if you incorporate VMware snapshots). So SMVI is great for static data, such as application binaries, OS and webservers (without database), but not for databases. On the other hand, SME and SMSQL don't backup the OS and application binaries.
1 + 2) So in short: you'll need both solutions. :-)
3) They'll work perfectly together, but you might want to consider not scheduling snapshots with both solutions on the exact same time.
4) Nope. Think about it: you use SME/SMSQL to create consistent snapshots of your databases. You can't (storage)snapshot a single vmdk. You'll need RDM's for that.
5) Not sure here, but there really is hardly any difference with a physical environment.
Hope it helps.
2009-12-26 09:57 AM
Thanks for good explanation. We will try to install it and we will see.
It looks a bit complicated because there is SMVI and SMSQL. Hope it will not be too toug installation.
There is another question. We will run HA configuration.
Will SMSQL work in HA configuration also? Will secondary server automatically took over the primary configuration?
Lep pozdrav / Best regards, Aleš
2009-12-27 06:18 AM
Not sure what you mean exactly by 'HA configuration'. Are you talking about your SQL servers, your filers, your disks or perhaps you're talking about SnapMirror or such?
2009-12-27 01:58 PM
VMware HA operates on a different layer & both guest OS and application (SQL) are totally unaware of it - so there are no issues with running SMSQL in this environment.
Having said that, in theory you can backup SQL with SMVI only via VSS integration, but this arguably has some drawbacks (more details e.g. here: http://communities.netapp.com/message/8132#8132)
2010-01-06 03:59 AM
SMVI leverages vmware snapshots, and they can 'activate' VSS inside the vm guest. I have read (trying to find out where it was) that vss in this way actually leverages the vss writers - including the application writers present. So while it is true SMVI does not call VSS, the VMware triggering of a snapshot does do so. In that way SMVI gives us a consistent snapshot.
I find this point interesting but am not sure I am correct.
2010-01-06 04:06 AM
NetApp offers two solutions today for addressing application-consistent data protection in a VMware environment:
· SMVI, working through the VMware guest VSS stack, provides application-consistent backup and recovery for applications that have VSS writers and store their data on virtual disks (VMDKs). Recovery, in this scenario, is at the full VM level only.
· SnapDrive® and application-specific SnapManager products such as SnapManager for Exchange (SME) and SnapManager for SQL (SMSQL) running in the guest OS, provide application-consistent backup and fine-grained recovery for applications whose data is stored using Microsoft iSCSI Software Initiator LUNs or RDMs.
The critical difference in the level of protection provided by each of these solutions is in the granularity of recovery. To understand the significance of this, you need to understand the concept of roll-forward recovery. Roll-forward recovery replays information stored in transaction log files to return a database to the state it was in at an exact point in time. In order to perform a roll-forward recovery, archival logging must be enabled, a full backup image of the database must be available, and there must be access to all logged files created since the last successful backup.
Since the only recovery mode available today for applications backed up using SMVI (using the VMware built-in VSS support) is recovery to the point of the last backup, customers must use the relevant SnapManager application if more fine-grained, roll-forward recovery is required.
Today, both solutions can be used together—SMVI to back up/recover the system data and a SnapDrive and application SnapManager combination to back up/recover the mission-critical application data—to get the desired level of data protection required.
2010-01-06 04:39 AM
Since it`s already been debated about SMSQL on this site, can someone please clarify (I am an SQL newbie) how to configure db migration in the 4th step of a configuration wizard.
First of all: should all the system databases be migrated to lun? As I read tempdb is recreated everytime the server starts... So, should I move just master, model and msdb (besides the production databases) to the new lun?
And another thing: should I move the above mentioned system db all to the same lun (db+logs) or should db be on one lun and the logs on another? For production db it is clear they should be separated. Master db is required to be on one lun (wizard suggests that).
regards to all,
2010-01-06 01:38 PM
Thanks for your clarification. However, I'm definitely no DBA, but something tells me MS SQL or Oracle won't like it being restored when the backup was made using just VSS. I'd think an Oracle would have to be in a back-up state before a proper and consistent back-up can be made. Likewise, I imagine MS SQL would be even more difficult about it.
Does SMVI, when configured to make VMware snapshots, also snapshots the memory of the vm? If not, the SMVI-snapshot s not guaranteed to be application-consistent.
By the way, I never worked with SMVI 2.0, but previous releases had great difficulty created VMware snapshots, even resulting (in our case at least) in frozen vm's untill the process timed-out!