Albert Widjaja
asked on
Unable to connect to the clustered SQL DB instance ?
Hi People,
I’ve created SQL Server 2008 R2 SP1 clustered virtual instance on top of my Windows Server 2008 R2 SP1 Enterprise MSCS, one instance is working fine and I can perform:
However with the other instance I cannot perform the above command and it is not accessible at all ? pinging the SQLClustername-instance2 is fine and reply back, when I do the following command:
I believe that the MSCS cluster can supports multiple SQL DB instance as long as the IP address is unique therefore port 1433 can be opened multiple times.
Any assistance would be greatly appreciated.
Thanks.
I’ve created SQL Server 2008 R2 SP1 clustered virtual instance on top of my Windows Server 2008 R2 SP1 Enterprise MSCS, one instance is working fine and I can perform:
C:\telnet SQLClustername-instance1 1433
--> successfullyHowever with the other instance I cannot perform the above command and it is not accessible at all ? pinging the SQLClustername-instance2 is fine and reply back, when I do the following command:
C:\netstat –ano | find /I “1433”
--> I cannot see the SQLClustername-instance2 IP address with port 1433 listening ?I believe that the MSCS cluster can supports multiple SQL DB instance as long as the IP address is unique therefore port 1433 can be opened multiple times.
Any assistance would be greatly appreciated.
Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You don't have to configure for a specific port - you can use the instance name, like "SERVER1\INSTANCENAME" (or "INSTANCEDNSNAME\INSTANCEN AME", in the case of your clustered instance), or you can use the port number like "SERVER1,1440" (or whatever port you assigned). By default, ports are assigned dynamically every time the SQL engine starts up, and assigning a port explicitly to your SQL Instance can cause problems if another application tries to grab that port on start-up.
With clustered instances, since you have a unique network name and IP address assigned to them, I've never understood why you need to specify the instance name in the connection - with a standard mutli-instance server, there are potentially two dozen instances listening on the same IP address, but with a cluster, each instance has its own IP. Connecting to "INSTANCEDNSNAME" has no confusion to it, and there should be no need to specify the instance name. To that point, I modify the TCP listener settings to allow this type of connection:
http://trycatchfinally.net/2009/05/accessing-a-clustered-sql-server-instance-without-the-instance-name/
Essentially, you tell SQL Server to listen on port 1433 of the cluster instance IP address, so requests to the IP directly (with no instance name) will still connect. Makes life a bit easier :)
With clustered instances, since you have a unique network name and IP address assigned to them, I've never understood why you need to specify the instance name in the connection - with a standard mutli-instance server, there are potentially two dozen instances listening on the same IP address, but with a cluster, each instance has its own IP. Connecting to "INSTANCEDNSNAME" has no confusion to it, and there should be no need to specify the instance name. To that point, I modify the TCP listener settings to allow this type of connection:
http://trycatchfinally.net/2009/05/accessing-a-clustered-sql-server-instance-without-the-instance-name/
Essentially, you tell SQL Server to listen on port 1433 of the cluster instance IP address, so requests to the IP directly (with no instance name) will still connect. Makes life a bit easier :)
ASKER
From the SQL configuration manager, the instance2 ip address it is set 0 as dynamic port.
My BiztalkServer 2010 cannot somehow talk to this instance2?
So should I make it explicitly 1433 instead of 0?