yoked2000
asked on
How does the second instance in a SQL 2008 R2 cluster handle the virtual server and IP routing?
Ok - we are trying to clarify some questions we are having with our SQL cluster...
OS: Windows 2008 R2
SQL: 2008 R2 Ent
DNS: mosssql.mydomain.net
Virtual server name: net-moss
instance one: moss 192.168.1.2
instance wanted to add: dw 792.168.1.3
It is our assumption that each instance is assigned it's own IP and resource group. That part is fine with the first instance running on NODE 1. When you create the first instance it asks you for the virtual server name as it appears to the network as that IP addres of that instance.
What we want to do is add a second instance to run on NODE 2 but still be in the same virtual server. Basically going to an Active/Active situation( yes it's actually two active/passive instances).
1)Is this configuration possible and how is the routing done from DNS to virtual server through to the actual instance name itself since it has a different IP?
2) we are assuming that DNS will point to the instance we want.
3) IF we make DNS point the IP directly then what's the point of the Virtual Server appearing on the network? It woudln't be wise to use any virtual server name in a connection for the ability to move the instance to a new server whithout app recinfiguration. So if DNS points all the way to the instance what's the point of the instance name in the connection other than just more required info?
4) We are also assuming ecah instance can fail to the other server and allocated to the nodes independently.
Confused since the virtual server would point to only one instance IP???
Thanks to anyone who can clarify this process
OS: Windows 2008 R2
SQL: 2008 R2 Ent
DNS: mosssql.mydomain.net
Virtual server name: net-moss
instance one: moss 192.168.1.2
instance wanted to add: dw 792.168.1.3
It is our assumption that each instance is assigned it's own IP and resource group. That part is fine with the first instance running on NODE 1. When you create the first instance it asks you for the virtual server name as it appears to the network as that IP addres of that instance.
What we want to do is add a second instance to run on NODE 2 but still be in the same virtual server. Basically going to an Active/Active situation( yes it's actually two active/passive instances).
1)Is this configuration possible and how is the routing done from DNS to virtual server through to the actual instance name itself since it has a different IP?
2) we are assuming that DNS will point to the instance we want.
3) IF we make DNS point the IP directly then what's the point of the Virtual Server appearing on the network? It woudln't be wise to use any virtual server name in a connection for the ability to move the instance to a new server whithout app recinfiguration. So if DNS points all the way to the instance what's the point of the instance name in the connection other than just more required info?
4) We are also assuming ecah instance can fail to the other server and allocated to the nodes independently.
Confused since the virtual server would point to only one instance IP???
Thanks to anyone who can clarify this process
It is not possible to use the same virtual IP which would in turn point to two different machine at the same time.
You will have to choose a different Virtual Name and a separate Resource Group in order to run what you want. Two active-passive clusters are ultimately two exclusive setups and has to be treated as separate.
You will have to choose a different Virtual Name and a separate Resource Group in order to run what you want. Two active-passive clusters are ultimately two exclusive setups and has to be treated as separate.
yoked, I think you are confusing Virtual Server with Virtual Name.
In the same Virtual Server you can have more than one Virtual Name. Each SQL Server instance have only one Virtual Name and each Virtual Name have one Virtual IP.
Too much virtual huh? :)
In the same Virtual Server you can have more than one Virtual Name. Each SQL Server instance have only one Virtual Name and each Virtual Name have one Virtual IP.
Too much virtual huh? :)
Each instance is in it's own clustergroup.
The clustergroup has:
Ipaddress
DNS Name
SAN disk (or equivalent)
sql services
Shares if any is needed (they need to failover too if an application reads/writes files for sql proc)
So ip/name/disk/instance is one atomic unity. It will be hosted by one node at a time.
This node will respond to all cluster DNS names it hosts, using all clustergroups ip adresses and so forth.
Does this answer your question?
//Marten
The clustergroup has:
Ipaddress
DNS Name
SAN disk (or equivalent)
sql services
Shares if any is needed (they need to failover too if an application reads/writes files for sql proc)
So ip/name/disk/instance is one atomic unity. It will be hosted by one node at a time.
This node will respond to all cluster DNS names it hosts, using all clustergroups ip adresses and so forth.
Does this answer your question?
//Marten
ASKER
So scaling from a single machine with a server name with multiple instances isn't possible in a cluster and keeping the same server/instance naming heirarchy? Every instance has both a unique instance name AND a unique virtual srver name?
Everyone talks about adding instances and just running the installer - but I haven't seen anyone adress this part of it.
If the instance name is unique anyway why didn't they jsut make it so we could point ONE DNS record to the entire cluster since we have to specify the unique instance name anyway still???
It seems like it automatially creates a DNS pointer as the virtual server name anyway - but you can't just repoint it when you migrate a database. So from a DNS perspective it's duplicating that part.
But if that's the final rationale then it is what it is...
Everyone talks about adding instances and just running the installer - but I haven't seen anyone adress this part of it.
If the instance name is unique anyway why didn't they jsut make it so we could point ONE DNS record to the entire cluster since we have to specify the unique instance name anyway still???
It seems like it automatially creates a DNS pointer as the virtual server name anyway - but you can't just repoint it when you migrate a database. So from a DNS perspective it's duplicating that part.
But if that's the final rationale then it is what it is...
Youre correct, youre duplicating both virtual servername AND instance. A common naming convention is like:
sqlcluster1\instance1, sqlcluster2\instance2 etc etc
//Marten
sqlcluster1\instance1, sqlcluster2\instance2 etc etc
//Marten
Well, if you choose to run multiple instances in one Node of a cluster that is possible to configure within a servergroup and in that case all the instances failover together. In that case you can use SQLcluster1\instance1, sqlcluster1\instance2, etc.
avirups: Youre correct, but you cant divide them into different nodes. In this case there parts in the same cluster group.
So its not multiple clustered instances, since they can't failover one by one.
//Marten
So its not multiple clustered instances, since they can't failover one by one.
//Marten
ASKER
What I understand is that each instance has its own IP. So my confusion is how do you have two instances in the same server group? We already have SQLCluster1/instance1 - how do you create SQLCluster1/instance2??? If each instance needs it's own IP, Virtual Server name and instance name. When you specify the virtual server name it created the virtual server object on the network. How does that point to two seperate instance IPs?
That's where the confusion is coming in...
I appreciate everyone's input - it just seems there isn't very much documentation on HOW the technology actually works so we can make decisions and operate within the different options.
That's where the confusion is coming in...
I appreciate everyone's input - it just seems there isn't very much documentation on HOW the technology actually works so we can make decisions and operate within the different options.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
RIght - that's my understanding - I was refering to what AVIRUPS said above. I keep getting conflicting information all over the place. Once I get the reality of how the archicture works it's easy to implement. We keep staying in the land of unsure exactly what our options are.
It makes more and more sense as it goes on. Just the scale up process from standalone to cluster isn't what it appears to be - but that's ok once we know.
It makes more and more sense as it goes on. Just the scale up process from standalone to cluster isn't what it appears to be - but that's ok once we know.
AVIRUPS will have to answer for this one. I guess it cane be done by moving cluster resources from one cluster group to another, excluding ip and name. Then you'll have to run:
EXEC sp_dropserver '<old_name>'
GO
EXEC sp_addserver '<new_name>', 'local'
GO
to SQLServer1 from SQLServer2 in our example above. But all this is guesses out of my head. Lets see what AVIRUPS answer.
Regards Marten
EXEC sp_dropserver '<old_name>'
GO
EXEC sp_addserver '<new_name>', 'local'
GO
to SQLServer1 from SQLServer2 in our example above. But all this is guesses out of my head. Lets see what AVIRUPS answer.
Regards Marten
ASKER
Thanks martenrune -
That was the clarification i've been looking for. Beating my head against the wall going through so many differnt pieces of information all contradictory. It kind of makes sense since the entire cluster is basically one big SQL instnace - so we have to play by the rules like only one default instance in the entire cluster etc.
I think a lot of the confusion comes between the difference between a cluster group and the whole "cluster" of nodes. Then mix in the virtual name...
I appreciate all the info!
Brock
That was the clarification i've been looking for. Beating my head against the wall going through so many differnt pieces of information all contradictory. It kind of makes sense since the entire cluster is basically one big SQL instnace - so we have to play by the rules like only one default instance in the entire cluster etc.
I think a lot of the confusion comes between the difference between a cluster group and the whole "cluster" of nodes. Then mix in the virtual name...
I appreciate all the info!
Brock
ASKER
Thanks again.