SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Combining AlwaysOn Groups With Failover Cluster Instances


Combining AlwaysOn Groups With Failover Cluster Instances

Author
Message
Perry Whittle
Perry Whittle
SSC Guru
SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)

Group: General Forum Members
Points: 55287 Visits: 17709
Comments posted to this topic are about the item Combining AlwaysOn Groups With Failover Cluster Instances

-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs" ;-)
jheim
jheim
SSC-Enthusiastic
SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)SSC-Enthusiastic (125 reputation)

Group: General Forum Members
Points: 125 Visits: 169
Good article. Covered the basic configurations that people are "thinking about". Thanks.

I've set up multi-node Oracle RAC that uses a private interconnect for very quick block movement needed to keep the nodes consistent. This limits the distance nodes can be from one-another. (side note: I wonder how fast the interconnect really needs to be since once we accidently had the private traffic going over the slower public network for a time and it worked ok.).

So my SQL Server questions have to do with the new feature of separated disk.

To keep the nodes consistent...is it simply relying on mirror like transaction shipping from DB to DB? Are there issues with speed if non-shared disk instances are far away?

Secondly, it sounds like the replicas with separate disk have to be read-only at best....like mirroring? is that true?

Also, the AO is described as a collection of DBs, not instances....or do I have that wrong? That would make it on a par with mirroring.....mirroring doesn't deal with the system DBs and all they contain (authentication, sql agent stuff, etc.. etc...). Does AO deal with replicating system DBs to instances using separate disks?

My biggest desire is to have something that looks like a cluster (with all its failover wonderfulness) across a long distance with separate disk. I don't mean something that does it halfway like mirroring on a database level....I want the whole instance to be replicated including system dbs. I don't want to script off pieces of the sql server instance and restore them to really get the failover up to speed....like logins and agent jobs and other stuff that changes over time.

I dont need the failover to be updatable....just to be "complete".

P.S. I have read about partial isolation for DB users and its only a halfway fix for that particular issue.

comments please, thanks.
Perry Whittle
Perry Whittle
SSC Guru
SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)

Group: General Forum Members
Points: 55287 Visits: 17709
jheim (9/4/2012)
Good article. Covered the basic configurations that people are "thinking about". Thanks.

Please do not forget to rate the article if you found it useful



jheim (9/4/2012)
To keep the nodes consistent...is it simply relying on mirror like transaction shipping from DB to DB? Are there issues with speed if non-shared disk instances are far away?

It uses mirroring endpoints to communicate between the replicas and operates in the traditional mirroring synch or asynch modes. It's basically mirroring on steroids.
The non shared disks are irrelevant to an extent its the comms between the replicas (sql instances) that are important, same with mirroring.



jheim (9/4/2012)
Secondly, it sounds like the replicas with separate disk have to be read-only at best....like mirroring? is that true?

Yes they're standby or read only


jheim (9/4/2012)
Also, the AO is described as a collection of DBs, not instances....or do I have that wrong?

An AlwaysOn group is a collection of databases that are replicated out to a set of defined partners\replicas.


jheim (9/4/2012)
That would make it on a par with mirroring.....mirroring doesn't deal with the system DBs and all they contain (authentication, sql agent stuff, etc.. etc...). Does AO deal with replicating system DBs to instances using separate disks?

System databases are not replicated, check Books Online there are a whole host or pre reqs and restrictions around AlwaysOn.


jheim (9/4/2012)
My biggest desire is to have something that looks like a cluster (with all its failover wonderfulness) across a long distance with separate disk. I don't mean something that does it halfway like mirroring on a database level....I want the whole instance to be replicated including system dbs. I don't want to script off pieces of the sql server instance and restore them to really get the failover up to speed....like logins and agent jobs and other stuff that changes over time.

I dont need the failover to be updatable....just to be "complete".

P.S. I have read about partial isolation for DB users and its only a halfway fix for that particular issue.

comments please, thanks.


At present contained databases are possible but there are still limitations, again check Books Online for the pre reqs and restrictions

-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs" ;-)
Eric Higgins
Eric Higgins
SSC Journeyman
SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)SSC Journeyman (97 reputation)

Group: General Forum Members
Points: 97 Visits: 91
4 *, nice explanation.

Only thing I would suggest adding is explanation on how the data from the clustered instance gets to the AO instance. Since this article takes a ground-up approach in explaining the concepts, I think that this would help your readers.
Dustin W. Jones
Dustin W. Jones
Old Hand
Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)Old Hand (331 reputation)

Group: General Forum Members
Points: 331 Visits: 548
This is a great article (I have rated it excellent), I have been looking for this exact information. One thing I'm not clear about (maybe its just the name of the instance that is throwing me off) is AONode2\CLMaint. Is this node necessary? Is this just another secondary replica?

Dustin W. Jones - Database Tech.
Perry Whittle
Perry Whittle
SSC Guru
SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)

Group: General Forum Members
Points: 55287 Visits: 17709
Dustin W. Jones (11/19/2012)
is AONode2\CLMaint. Is this node necessary? Is this just another secondary replica?

That's exactly what it is, a secondary replica.

-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs" ;-)
Bert-701015
Bert-701015
SSC Veteran
SSC Veteran (251 reputation)SSC Veteran (251 reputation)SSC Veteran (251 reputation)SSC Veteran (251 reputation)SSC Veteran (251 reputation)SSC Veteran (251 reputation)SSC Veteran (251 reputation)SSC Veteran (251 reputation)

Group: General Forum Members
Points: 251 Visits: 654
Doesn't really matter since you can have multiple replicas, but can a replica be clustered as well?
Perry Whittle
Perry Whittle
SSC Guru
SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)

Group: General Forum Members
Points: 55287 Visits: 17709
Bert-701015 (2/26/2013)
but can a replica be clustered as well?

Yes that's what the article discusses ;-)

-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs" ;-)
Michael Carullo
Michael Carullo
Grasshopper
Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)Grasshopper (23 reputation)

Group: General Forum Members
Points: 23 Visits: 73
with the 4 node example, what are the possible synchronization/failover options? Can the AO group be synchronously replicated from SQL-CL-INST\SiteLive 192.168.1.51 to the secondaries - AONode1\DRRepl and AONode2\CLMaint? Only synchronous replicas can be automatically failed to so this becomes important.
Marios Philippopoulos
Marios Philippopoulos
SSChampion
SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)SSChampion (12K reputation)

Group: General Forum Members
Points: 12992 Visits: 3766
Thank you for the article.

I have a question about the instance names: do they *have* to be different? If anything, for DR purposes, they instance names should ideally be the same in prod and DR (if we are not using the AG listener).

We are building a 3-node WSFC cluster that includes a 2-node FCI (active-passive configuration) coupled with a standalone AlwaysOn-AG instance on the 3rd node. Will we run into trouble if we name the instance the same on the FCI and AG nodes?

(I was reading an article that described a similar scenario of a single WSFC comprised of 2 FCIs on 2 different subnets; in that article they mention that instance names should be different; I'm not clear why).

__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables
Persisting SQL Server Index-Usage Statistics with MERGE
Turbocharge Your Database Maintenance With Service Broker: Part 2
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search