How to build an HA SQL cluster

Where storage mirroring / replication is done over a SAN / Fibre Channel network, AAG does the same using a LAN. So I can imagine that the low latencies we have in SAN environments are now traded in for a little more latency when the "replication" is done over NICs, right? Now how's that better? Will it improve the performance of a single node if it has to wait for an ACK from the other node? When doing storage replication the ACK was very fast to begin with. Or is there a trick in the AAG way of doing things?

Wow! That's quite a nice answer you provided me. I'm sure a lot more people than just me will find this helpful .

I'm a storage guy, so my first thought in cluster challenges is using storage replication, but more and more customers are experimenting with AAG and I became interested.

Thanks again!

I like the discussion too. We should do an Ask the Expert one time.... Oh hey! I did three of them already and they're about storage!!! (Re: Ask The Expert: Discussing the challenges of Long Distance Links and Ask the Expert: Performance Calculations on Clariion/VNX).

But to get back to the replication methods of an AAG I can conclude that with synchronous replication it works about the same as the storage version of it. Talking about latency that is. An important pro for storage is the lower latency and the faster "network", but a pro for AAG would be in my opinion that the application itself is aware of the replication and could possibly failover faster. In my opinion it comes down to latency of the networks used. If you're on a 10Gbps network, I'm sure you can beat the latency of an 8Gbps SAN, but 16Gbps is around the corner and what are we talking about in terms of latency? Sub-millisecond? What exactly is that? 0.9, 0.2; When a windows (or Linux) CLI mentions <1ms it doesn't tell me much how many IOps I can perform over the LAN. Has anyone tested this?

Now that would be a good POC: testing an AAG with synchronous replication over a 1Gbps / 10Gbps LAN compared to a setup that uses an MSCS configuration and Mirrorview/s/ce or even RecoverPoint.

I like to add the other option would be to use the classic approach using Microsoft Failovercluster an to give this an extra provide the storage using an VPLEX to mirror to the other side. That will do the trick where AVG is not the option or would complicate the things.

regards

Behind the curtain Exchange DAG is exactly the same thing as AAG cause it was developed by the same team, only exchange adopted it earlier. Behind DAG and AAG are the basics from Microsoft Failover Cluster used so you configure a DAG or AAG an geht an MFC in background, which is configured from the applications not from the classic side approach . But i liked that you got an idea how to handle your DBAs .

regards

Those are indeed good questions, Tony. My case is entirely theoretical.

With AAG, Async and sync are possible and I like it that the DBA can configure this. If for some reason they want a temporary lower latency, they could switch to async and remain at sync afterwards, right? If this needs to be done in Unisphere / CLI towards a VNX, I know this is quite disruptive for the DR copy of the data.