October 27, 2011 at 10:46 am
I have installed Integration Services 2008 R2 on two clustered nodes, 'NODE1' and 'NODE2', part of an active/passive cluster named 'SQLCLUSTER'. Now SSIS is installed (and patched up to the same level as the DB engine). I can run BIDS on the nodes, build and execute packages.
My problem is that I cannot connect to SSIS in Management Studio using the cluster name 'SQLCLUSTER'. I receive the following error:
Connecting to the Integration Services service on the computer "SQLCLUSTER" failed with the following error: "The RPC server is unavailable."
I know RPC is running on the node currently owning the cluster, and I can connect just fine in SSMS if I use the node name instead.
I have updated the <ServerName> element in msdtssrvr.ini.xml to "SQLCLUSTER" as indicated in http://msdn.microsoft.com/en-us/library/ms137789.aspx.
If anyone has any clues I'd be grateful. Thank you!
October 27, 2011 at 10:29 pm
Have you tried to restart to SSIS services on both nodes? Also remember, the modification needs to happen on both nodes in some cases that I've seen.
October 28, 2011 at 12:19 am
I don't install SSIS on clusters as its not recommended and isnt cluster aware. Have you read this article?
October 28, 2011 at 12:47 am
The article doesn't state that it is not recommended on a cluster, the article states that it is not recommended to configure SSIS as cluster resource.
To install SSIS on a cluster is perfectly fine as the SSIS engines will run independently of one another on each node.
October 31, 2011 at 9:41 am
MysteryJimbo (10/28/2011)
I don't install SSIS on clusters as its not recommended and isnt cluster aware. Have you read this article?
Thanks for your help. SQLArcher is correct - Installing SSIS on a clustered node does not necessarily make it a clustered service. A clustered service fails over between nodes. What I have done is installed SSIS as a service on each node of the cluster, without failover. See the third paragraph of the MSDN article. It just means that SSIS is available on every node of the cluster, which is why it is preferable that it can be reached by cluster name, not just node name.
SQLArcher - thanks for your advice. I was working on just the active node's configuration. I'll try updating both nodes and restarting the service this afternoon and see what that does.
October 31, 2011 at 10:43 am
SQLArcher (10/28/2011)
The article doesn't state that it is not recommended on a cluster, the article states that it is not recommended to configure SSIS as cluster resource.To install SSIS on a cluster is perfectly fine as the SSIS engines will run independently of one another on each node.
Not quite what I said/meant as I know this
MysteryJimbo (10/28/2011)
I don't install SSIS on clusters as its not recommended and isnt cluster aware. Have you read this article?
Clustering Integration Services is not recommended because the Integration Services service is not a clustered or cluster-aware service
Why have it on a cluster if you cannot cluster the service unless its licence cost implications? Its an extra memory hog which is most likely better off running on another server. You'll also experience fewer issues.
October 31, 2011 at 12:01 pm
Thank you for your input. Your point has been taken into consideration. You are indeed correct regarding licensing as a serious consideration, in addition to other factors.
My original question is regarding why I cannot connect to SSIS using the cluster name. I'd appreciate any feedback on that.
October 31, 2011 at 1:56 pm
Have you changed the service account of the SSIS services on any of the nodes? This can have an effect, especially if you are using domain authentication instead of the default accounts.
You have also net yet commented if you did the modification on both of the nodes, and if you restarted both of the services...
October 31, 2011 at 1:59 pm
I'm in a position where I cannot make changes until later in the day. I'll let you know what I find when I try later.
November 3, 2011 at 3:05 pm
It turned out to be the result of Windows Server 2008 R2's firewall rules. After adjusting the firewall settings I am now able to connect using the cluster name.
February 6, 2013 at 12:21 pm
joffwilliams (11/3/2011)
It turned out to be the result of Windows Server 2008 R2's firewall rules. After adjusting the firewall settings I am now able to connect using the cluster name.
What were the necessary changes to the firewall?
February 6, 2013 at 12:29 pm
Oh dear... you're testing my memory with that one...
If I recall correctly, you'll need to allow an inbound rule for either the msdtssrvr.exe executable or the port SSIS listens for DCOM on: 135 I think? I'd avoid opening 135 and allow for the executable if I were you.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply