Joined: Sun Jul 29, 2012 9:30 am
Posts: 576
|
|
I thought you mentioned physical bSQL? If you are VM this is a breeze we do it all day long, the only issue is we stopped doing VSS level DB snaps for DR because of the IO freeze and becasue how we split up our VMDKs. I have over 100 SQL VMs that we SRM all the time and just use crash consistent snaps. Works like a champ.
He is a typcial SQL VM:
Datastore 1 (replicated every 15 minutes)
C: for OS (VMDK) SCSI 0:0
E: for \program files\SQL (VMDK) SCSI 0:1
e:\sql\data (mount path to its own VMDK) SCSI 1:0
e:\sql\logs (mount path to its own VMDK) SCSI 2:0
e:\sql\backup (mount path to its own VMDK for tlog backups for full recovery) SCSI 0:3
Datastore 2 (replicated daily just to make sure volume size changes make it across)
Z: for OS page file (VMDK) SCSI 0:1
e:\sql\tempdb (mount path to its own vmdk) SCSI 3:0
We use the Paravirtual SCSI driver in all Windows 2008 R2 VMs and for optimal performance spread the mount paths across multiple logical SCSI adapters. We have been doing this for SQL for almost a year and just let the array do replication and it has worked every time we test it. The biggest issues that HP is releasing a fix for soon is in the above config the SRA takes forever to process a VM that is spread across 2 datastores. There is a pending SRA fix that will speed that up.
|
|
