Re: [PLUG] real-time data replication over highspeed WAN link

server hardware in each location HBA booting from the SAN. So the theoritical plan will be to replicate the entire SAN to the other side. If/when a failure occurs we will power-on the dormant servers from their SAN HBA image.

This should be workable. Just watch out for SQL data files with iffy availability. If the SAN drops out for any reason (lose connectivity, loose the SAN hardware, etc) and the instance marks your database "suspect", you may be in for a very bad experience. With iSCSI, just like with a fiber channel network, I would want to ensure that there are redundant network paths to my storage.

About five years ago, I had put a bunch of databases on a brand-new Clariion in a server room. The "UPS" for the Clariion was a battery and generator unit that fed the entire server room. The Clariion did not have individual protection. A hot August plus too much new gear in the server room tripped a circuit breaker which was between the Clariion and the UPS. When the Clariion went down, it took all of the drives for the user and tempdb databases. That would be expected, but when it came back up, all of the files were toasted. Luckily, this was a QA box and I could just re-restore what I had done the prior day. No one ever explained to my why my files were scrambled. That was four or five years ago and I'm still not convinced that SANs are more bulletproof than local disk.

It's also worth repeating that replication is not a substiute for backups, neither is RAID. You've probably heard this before..

I am also considering doing the whole thing with virtual machines if the performance is there. I've worked through my IO issues with VMware, so i think it may work for my need. I think replication will be more straight forward at that point.

From the SQL side, VMWare recommends using RDM for SQL data files (if I recall the acronym correctly (IIRTAC) rather than a regular disk image. (VMWare has a bunch of whitepapers/pdfs that talk about vm performance, including one or more on SQL Server.)

Note that certain database files (tempdb files, system database files) would likely wind up on the "boot drive" disk image (just because of where the installation process places files) unless they were explicitly moved. Depending on what you are doing, it might matter or it might not. My currently client has a couple of low-stress SQL servers that we are currently working on getting into VMs so that we can repurpose their hardware for a different task. We did the QA machine a week ago and no one really noticed. We are doing the production server on Friday.

I've also been warned about relying on metrics from Performance Monitor when running against windows machines in VMs. IOW, the numbers from inside the VM may not be reliable and only VMWare's tools should be employed. I can't prove or disprove that (yet) but I thought that I'd pass it on.

-- d