﻿<?xml version='1.0' encoding='UTF-8'?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>SQLServerCentral / Article Discussions / Article Discussions by Author / Discuss content posted by Perry Whittle  / Combining AlwaysOn Groups With Failover Cluster Instances / Latest Posts</title><generator>InstantForum.NET v2.9.0</generator><description>SQLServerCentral</description><link>http://www.sqlservercentral.com/Forums/</link><webMaster>notifications@sqlservercentral.com</webMaster><lastBuildDate>Thu, 23 May 2013 17:18:37 GMT</lastBuildDate><ttl>20</ttl><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>how would you approach it if you need to install as follow:Prod site: FCI over 2 nodesDR: FCI over 2 (or single) nodesAlwaysOn between the two FCIsSo all 3 (or 4) nodes must be part of same WSFC. what if the were both already running prior to your AlwaysOn plans, how do you 'combine' the two separate WSFCs then ? then with shared storage, each FCI set has shared storage only between then, not between sites. how would you set this up in Cluster Manger / how do you validate the cluster and tell it to validate the storage only between 2 Prod nodes, and also validate the storage for the 2x DR nodes only, if all 4 nodes are in the same cluster now?</description><pubDate>Tue, 14 May 2013 17:58:59 GMT</pubDate><dc:creator>h_d_t</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>We are using a DNS alias for the virtual network name (VNN) of the sql instance on the FCI cluster to direct connectivity of our applications to the prod instance.Say the VNN is PRODSQLVS01 and the instance name is INST01. We can then connect to PRODSQLVS01\INST01 to get to the FCI instance hosted in nodes 1 or 2. If the DNS alias of the above VNN is BATMAN, then connecting to BATMAN\INST01 accomplishes the same thing. In the event of a disaster in the primary data center hosting nodes 1 and 2, we will then simply point the DNS alias to node 3, the DR node. Our applications will not "know" which server this is, as long as using BATMAN\INST01 will get them connected. But this plan will fail if the SQL instance on node 3 is not also named INST01.I know the AG listener is the proper way to address this DR scenario, but we will not be able to implement a listener until all our apps are upgraded to .net 4.0.I was recently able to implement availability groups on a multi-node cluster lab environment using the same instance name for the same AG on multiple nodes with no issues. In that setup I had no FCIs, just standalone instances. I don't see how the requirement for different instance names on different nodes fits into all this.</description><pubDate>Fri, 29 Mar 2013 21:51:17 GMT</pubDate><dc:creator>Marios Philippopoulos</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>[quote][b]Perry Whittle (3/29/2013)[/b][hr][quote][b]Marios Philippopoulos (3/26/2013)[/b][hr]Thank you for the article.[/quote]You're welcome.[quote][b]Marios Philippopoulos (3/26/2013)[/b][hr]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).[/quote]Since all 3 nodes are part of the same cluster (they have to be for AO), you could potentially install the FCI to the 3rd node. Since instance names are unique within the cluster, this is why you need separate instance names. Incidentally why do you feel that having your live and DR instances named differently will cause you issues??[/quote]</description><pubDate>Fri, 29 Mar 2013 21:24:49 GMT</pubDate><dc:creator>Marios Philippopoulos</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>[quote][b]Marios Philippopoulos (3/26/2013)[/b][hr]Thank you for the article.[/quote]You're welcome.[quote][b]Marios Philippopoulos (3/26/2013)[/b][hr]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).[/quote]Since all 3 nodes are part of the same cluster (they have to be for AO), you could potentially install the FCI to the 3rd node. Since instance names are unique within the cluster, this is why you need separate instance names. Incidentally why do you feel that having your live and DR instances named differently will cause you issues??</description><pubDate>Fri, 29 Mar 2013 03:39:55 GMT</pubDate><dc:creator>Perry Whittle</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>[quote][b]Perry Whittle (3/27/2013)[/b][hr][quote][b]Marios Philippopoulos (3/26/2013)[/b][hr]I was reading an article that described a similar scenario of a single WSFC comprised of 2 FCIs [/quote]Could you provide the article link please[/quote]Here it is:AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution by Using Failover Cluster Instances and Availability Groups[url]http://msdn.microsoft.com/en-us/library/jj215886[/url]Here is the excerpt I am talking about:"...Instance Naming and File PathThe two FCIs must use different instance names within the same WSFC, for example, using “INST_A” as the instance name for the primary FCI and “INST_B” as the instance name for the DR FCI. (In contrast to availability groups, database mirroring permits each FCI to use the same instance name if the FCIs are on separate WSFCs. In Figure 1, both FCIs used the same the same instance name, INST_A, with the FCI+DBM solution). ..."</description><pubDate>Wed, 27 Mar 2013 03:31:33 GMT</pubDate><dc:creator>Marios Philippopoulos</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>[quote][b]Marios Philippopoulos (3/26/2013)[/b][hr]I was reading an article that described a similar scenario of a single WSFC comprised of 2 FCIs [/quote]Could you provide the article link please</description><pubDate>Wed, 27 Mar 2013 00:14:52 GMT</pubDate><dc:creator>Perry Whittle</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>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).</description><pubDate>Tue, 26 Mar 2013 19:17:37 GMT</pubDate><dc:creator>Marios Philippopoulos</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>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.</description><pubDate>Tue, 12 Mar 2013 12:02:18 GMT</pubDate><dc:creator>Michael Carullo</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>[quote][b]Bert-701015 (2/26/2013)[/b][hr]but can a replica be clustered as well?[/quote]Yes that's what the article discusses ;-)</description><pubDate>Tue, 26 Feb 2013 12:13:43 GMT</pubDate><dc:creator>Perry Whittle</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>Doesn't really matter since you can have multiple replicas, but can a replica be clustered as well?</description><pubDate>Tue, 26 Feb 2013 11:26:43 GMT</pubDate><dc:creator>Bert-701015</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>[quote][b]Dustin W. Jones (11/19/2012)[/b][hr]is AONode2\CLMaint. Is this node necessary? Is this just another secondary replica?[/quote]That's exactly what it is, a secondary replica.</description><pubDate>Mon, 19 Nov 2012 14:07:33 GMT</pubDate><dc:creator>Perry Whittle</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>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?</description><pubDate>Mon, 19 Nov 2012 13:46:16 GMT</pubDate><dc:creator>Dustin W. Jones</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>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.</description><pubDate>Thu, 06 Sep 2012 12:37:12 GMT</pubDate><dc:creator>Eric Higgins</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>[quote][b]jheim (9/4/2012)[/b][hr]Good article. Covered the basic configurations that people are "thinking about". Thanks.[/quote]Please do not forget to rate the article if you found it useful[quote][b]jheim (9/4/2012)[/b][hr]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?[/quote]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.[quote][b]jheim (9/4/2012)[/b][hr]Secondly, it sounds like the replicas with separate disk have to be read-only at best....like mirroring? is that true?[/quote]Yes they're standby or read only[quote][b]jheim (9/4/2012)[/b][hr]Also, the AO is described as a collection of DBs, not instances....or do I have that wrong? [/quote]An AlwaysOn group is a collection of databases that are replicated out to a set of defined partners\replicas.[quote][b]jheim (9/4/2012)[/b][hr]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?[/quote]System databases are not replicated, check Books Online there are a whole host or pre reqs and restrictions around AlwaysOn.[quote][b]jheim (9/4/2012)[/b][hr]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.[/quote]At present contained databases are possible but there are still limitations, again check Books Online for the pre reqs and restrictions</description><pubDate>Wed, 05 Sep 2012 05:04:23 GMT</pubDate><dc:creator>Perry Whittle</dc:creator></item><item><title>RE: Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>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 [u]separated disk[/u]. 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.</description><pubDate>Tue, 04 Sep 2012 12:25:03 GMT</pubDate><dc:creator>jheim</dc:creator></item><item><title>Combining AlwaysOn Groups With Failover Cluster Instances</title><link>http://www.sqlservercentral.com/Forums/Topic1353688-1452-1.aspx</link><description>Comments posted to this topic are about the item [B]&lt;A HREF="/articles/FCI/92196/"&gt;Combining AlwaysOn Groups With Failover Cluster Instances&lt;/A&gt;[/B]</description><pubDate>Mon, 03 Sep 2012 21:18:13 GMT</pubDate><dc:creator>Perry Whittle</dc:creator></item></channel></rss>