June 14, 2010 at 5:37 pm
I believe I am confused. How could it be? But it is there.
Does anyone know when we need this kind of configuration?
Any input will be greatly appreciated.
June 14, 2010 at 6:59 pm
What are you confused about?
Yes, you can use the virtual IP address for any cluster group that is currently hosted on the same node to access that node through RDP. If the cluster group is on the other group, and you use that virtual IP - you will be connected to that node.
Each resource group in a cluster will have an IP name and address. Each IP name and address is addressable through DNS and will direct the connection to the node hosting that resource group. So, if your SQL Group is hosted on node1 - and your cluster group is hosted on node 2, and your MSDTC group is hosted on node 3 you would then use the SQL VIP to access node 1, the cluster VIP to access node 2 and the MSDTC VIP to access node 3.
If all resources are hosted on the same node, it doesn't matter which one you access.
I always use the SQL Virtual IP to access the cluster through RDP. That will make sure I am always accessing the node that is currently hosting SQL Server.
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
June 14, 2010 at 7:39 pm
I believe that I might not explain it clearly.
The SQL instance differs from those of nodes. However, I could use the SQL instance IP to access the server box via RDP. How could it be?
June 14, 2010 at 7:56 pm
In a windows cluster, you have a Cluster Administrator. This cluster administrator manages the resource groups that have been defined for the cluster.
Each cluster group will be setup with the resources it manages, an IP address and an IP name. For example, you should have a cluster group that has a drive as a resource (quorom drive), and IP name and address. That cluster group will be hosted on one of the nodes in the cluster.
If you RDP to that cluster groups IP address or name, you will be connected to the node that is hosting that cluster group.
The next cluster group you should have will be the SQL Server Group. In this group, you are going to have the disk drives that support that instance, the SQL Server IP address and Name, the SQL Server Service, the SQL Server Agent Service and any other services associated with that instance of SQL Server.
If you RDP to this cluster groups IP address or name, you will be connected to the node that is hosting that cluster group. It may or may not be the same as the cluster group.
If you have more cluster groups, each one will have it's own IP address and name. If you RDP to those, you will be connected to the node that is hosting those groups.
A cluster group can only be hosted on a single node - when you move the group, it will be moved to one of the other nodes in the cluster that can host that group. If you then RDP to this cluster's group IP address or name, you will now be connected to the new node that is hosting that group.
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
June 14, 2010 at 8:30 pm
First of all, thank you for your time and kind explanation.
My cluster system has cluster IP, node IPs for the two nodes, and the SQL Server instance IP. There are 4 IPs in total. They are all different from each other.
My situation is that I could use the SQL Server instance IP to access the server box via RDP. Of course, I could also use the node IP to access the server box via RDP.
What confused me here is how I could use the IP used for SQL Server instance to access the server box?
June 14, 2010 at 11:34 pm
Yes, you have 4 IP addresses assigned. One for each node of the cluster, one for the cluster group and one for the SQL instance.
From the server, open up cluster administrator and connect to either the SQL instance or the cluster instance. Once connected, you'll see the defined cluster groups and which node is currently hosting that group.
On Windows clusters, the cluster administrator controls access to the actual node. When you access the SQL instances IP address, the cluster administrator redirects the call to the appropriate node. When the group is moved to the other node, all calls to the SQL instances IP address will now be redirected to that node.
The only time you should use the node specific IP addresses is when you need to connect to a specific node in the cluster. When you want to connect to the node hosting the SQL group, you use the SQL instances IP address and it will be redirected to the actual node hosting the group.
This is why it is called a virtual IP address - because it is not associated with a node and is used only to direct the connections to the actual node hosting that group. From the outside, you have no idea which node you are actually connecting to - nor should you. You let the system direct the connection to the appropriate node based upon which node happens to be hosting that group at this time.
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
October 14, 2010 at 9:35 am
These posts were pretty informational and I was able to solve my terminal service login limitation (2 users + 1 admin) by logging in directly to the node. Here is the other problem though, and if someone can post their solutions, I'd greatly appreciate it.
So we have 2 nodes, and 4 SQL server instances. Lets call the nodes:
Node1
Node2
and Lets call the SQL Server Clusters as:
SQLCLUSTER1 - This is always active on Node1
SQLCLUSTER2 - This is always active on Node2
SQLCLUSTER3 -
SQLCLUSTER4
So, basically at a given time, at least 1 SQL Server is active on both of these nodes, unless there is a failover scenario where all the clusters move to single node. I cannot see the same drive letters from the SAN boxes at the same time. And, when I do //Node1/R$ for my R:, I cannot access the same drive letter by doing a //Node2/R$ because R: is not active on Node2.
Problem is that some of my SSIS packages rely on these drives. But when my nodes flip, I cannot determine how to fetch the same data from another drive, and vice versa.
If someone can help me resolve the problem, that would be great.
October 14, 2010 at 2:01 pm
You are still trying to access nodes specifically - instead of using the virtual address for the resource you are accessing.
Which cluster group hosts the R:\ drive?
Let's say that your R:\ drive is hosted on the same cluster group as SQLCLUSTER1. In the cluster group, you have a defined IP address resource, a defined Name resource, one or more drive resources, the DB engine, SQL Server Agent, and possibly even full text.
The defined IP address and Name are what you need to be using to access any resource that is contained in that group. If the Name is SQLCLUSTER1, then you can access the R:\ drive using: \\SQLCLUSTER1\r$.
You can also create a file share resource in that group - so now, all you have to do is reference the file share as in: \\SQLCLUSTER1\Fileshare
Forget about using the specific nodes - you should always use the cluster groups IP address or name to reference any resources contained in that group.
The only time you want to reference a specific node is when you are applying patches, or you need to work specifically on that node. Normal operations should always be done through the virtual IP addresses.
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
October 14, 2010 at 10:38 pm
Thank you. That seems to be the exact solution that our data center people suggested. That seemed to work.
Thank you once again.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply