March 8, 2010 at 1:32 pm
Here is our new setup.
We have a Veritas Cluster which supports SQL Server 2008 on Windows Server 2008. We have three servers in our local cluster. We also have Replication we need to set up.
In order to do this efficiently, we would want to use the Cluster name/SQL Instance name as we will never know which SQL Instance/server is up and active if we have local failover.
So we install SQL Server 2008 and include the SQL Replication piece to our newly Built Windows Server 2008 boxes. We are using Mount Points and Volumes which allow us to have our data and master, msdb, model follow our failover cluster wherever it is active. Our setup for this is as below
server 1\instance1 Server 2 \instance1 server 3\instance1
We ran an Addserver and Drop server to rename server 1 to Server. So in using this, we would call server 1\instance1 Server\instance1 now as this would also be the name of our Veritas Local Cluster name. (Note at this point we are not using Geo Clustering, that is our next phase).
Now, we have verified that new Virtual internal name of 'Server\Instance1' This works fine.
Issue with Setting up the SQL Server 2008 Distributor:
Go into the Server\instance1 name you want to , right click on Replication and click on 'Configure Distributor'. Start going through the prompts and at the point where you say use 'x' server for the Distributor. I go to the Veritas Cluster name (Keep in mind that works fine connecting through our web services, SQL Management Studio, etc. ) called 'Server\Instance1'. All of our Ports are totally opened up that need be where we need them. We are not going through a firewall so this is a non-issue.
We get the following error:
SQL Server replication requires the actual server name to make a connection to the server. Connections through a server alias, IP address, or any other alternate name are not supported. Specify the actual server name, 'HIMALAYA\KILLER'. (Replication.Utilities)
What this would mean is that we would have to use the physical harware server name\SQl Instance instead of our cluster name\instance, which would mean we would have to move the SQL Server 2008 distributor physically outside of our Cluster to a totally separate box. Our point was to centrally locate our SQL Server 2008 Distributor and do a push replication and not have to deal with if the server goes down, type of thing. (My thoughts are that this is isolated to physical harware and registry configurations for this reasoning?)
Now, we will never know what server this is up and running on at any point in time, except that the distributor would have been installed on the 'instance1' SQL Instance which is configured and installed on a Mount Point\Volume scenario which floats around our Local Cluster. So why is it that SQL Server 2008 Distributor\Replication cannot use this and still needs the physical server hardware name and our SQL instance?
This is very prohibitive for what we are attempting to do for a high availability environment whether Veritas cluster or Microsoft Clustering.
Can someone tell me if they have every experienced this before and if there are work arounds? Or just the one we have to do for the time being and that is to pull the SQl Server 2008 distributor out of our cluster and put on a separate server which defeats our purpose.
1. Keep in mind, we are NOT behind a firewall
2. All of our PORTS for SQL, etc to from servers are totally opened and we can telnet everywhere we need to
3. We can get to our Cluster via clustername\instance name through Windows services configuration files off other servers, SSMS utility, ping, nslookup and more.
If this is a Total issue? Microsoft should address in the next release of Replication this issue to work within a Cluster as this is becoming more common place with larger companies scaling out High Availability of their systems like us.
March 8, 2010 at 2:31 pm
I am not familiar with Veritas clustering, but it sounds like this is an issue with how that is working. On Microsoft clusters, you would reference the VIP instead of the physical server and it appears to all outside users as the actual host.
I use to work with PolyServe clustering which probably would have had the same kind of issues because of how they virtualize the instances.
I would talk to Veritas about this and see if they have encountered these kinds of issues and how they were resolved.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
March 9, 2010 at 6:03 am
thank you for your feedback, but part of the Error message trying to set up the SQL 2008 distributor is that the SQL server Replication does not support
VIPs, IPS or DNS
This was Microsoft's not error but information message telling us that it doesn't support it. We have Microsoft Clusters in our work place but they do not do replication ,they do log shipping. But due to our SLA with our customers they require no downtime and immediate access to real time data, so log shipping is not an option as it does not meet our SLA.
March 9, 2010 at 7:27 am
In order to do this efficiently, we would want to use the Cluster name/SQL Instance name as we will never know which SQL Instance/server is up and active if we have local failover.
I find this comment very confusing as this defeats one of the clustering feature which is not needing to know which node is hosting SQL Server.
Take the following senario:
Cluster is named Europe
Nodes are named France and Germany
SQL Servers are Paris\InstanceA and Berlin\InstanceB.
You can connect to SQL Server by specifying "Paris\InstanceA" and do not care about the node name.
If Addserver and Drop server occured to rename Paris to Europe, you have now created a problem and the solution is to rename the SQL Server back to Paris.
What this would mean is that we would have to use the physical harware server name\SQl Instance instead of our cluster name\instance
This not a correct statement as you refer to the SQL Server as Paris\InstanceA and not by any of the node names.
One thought is that you named the SQL Servers with the same names as a node (not sure if this is possible), in which case you will need to correct this so that the two names are different.
SQL = Scarcely Qualifies as a Language
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply