Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

Combining AlwaysOn Groups With Failover Cluster Instances Expand / Collapse
Author
Message
Posted Monday, September 3, 2012 9:18 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 11:17 PM
Points: 6,490, Visits: 13,968
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"
Post #1353688
Posted Tuesday, September 4, 2012 12:25 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, October 15, 2014 10:24 AM
Points: 26, Visits: 97
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.

Post #1354117
Posted Wednesday, September 5, 2012 5:04 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 11:17 PM
Points: 6,490, Visits: 13,968
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"
Post #1354433
Posted Thursday, September 6, 2012 12:37 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, August 13, 2014 6:59 PM
Points: 7, Visits: 87
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.
Post #1355561
Posted Monday, November 19, 2012 1:46 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: 2 days ago @ 1:33 PM
Points: 119, Visits: 546
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.
Post #1386567
Posted Monday, November 19, 2012 2:07 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 11:17 PM
Points: 6,490, Visits: 13,968
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"
Post #1386579
Posted Tuesday, February 26, 2013 11:26 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, October 14, 2014 9:20 AM
Points: 148, Visits: 541
Doesn't really matter since you can have multiple replicas, but can a replica be clustered as well?
Post #1424195
Posted Tuesday, February 26, 2013 12:13 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 11:17 PM
Points: 6,490, Visits: 13,968
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"
Post #1424211
Posted Tuesday, March 12, 2013 12:02 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, November 19, 2013 10:45 AM
Points: 1, Visits: 70
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.
Post #1430023
Posted Tuesday, March 26, 2013 7:17 PM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Wednesday, October 8, 2014 12:34 PM
Points: 1,865, Visits: 3,615
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).


__________________________________________________________________________________

Turbocharge Your Database Maintenance With Service Broker: Part 2
Turbocharge Your Database Maintenance With Service Broker: Part 1
Real-Time Tracking of Tempdb Utilization Through Reporting Services
Monitoring Database Blocking Through SCOM 2007 Custom Rules and Alerts
Preparing for the Unthinkable - a Disaster/Recovery Implementation
Post #1435732
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse