| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| HACMP, MSCS, VCS - How does that "floating" IP Add |
View previous topic :: View next topic |
| Author |
Message
|
| PeterPotkay |
 Posted: Fri Feb 05, 2016 8:34 am Post subject: HACMP, MSCS, VCS - How does that "floating" IP Add |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
OK, here goes exposing my lack of knowledge with basic networking.
Server #1 with IP Address #1
Server #2 with IP Address #2
Both servers added into a hardware cluster (say Veritas) where along with the MQ Queue Manager and disk groups, a virtual IP address and virtual DNS name are added as resources in the cluster group that can be active on either Server #1 or Server #2, but never both concurrently. Let’s call this IP Address #3 and DNS name #3
So the cluster group is started up on Server #1.
An application on my desktop starts up, and tries to connect to DNS name #3. It works, the call to DNS #3 gets routed to Server #1.
Now the cluster group is swung from Server #1 to Server #2.
As soon as the cluster resources are all online on Server #2, the very next call from my desktop to DNS #3 immediately gets routed to Server #2.
How? How is it that one minute DNS name #3 is sending TCP IP packets to Server #1, and the next minute DNS #3 is getting my TCP IP packets to Server #2? Just saying “Its simple, the cluster resources for IP Address #3 and DNS #3 became active on Server #2” is not good enough. How? How does the network know to send TCP IP packets for DNS#3 and IP Address #3 to Server #1 one minute, and the very next minute the exact same DNS name #3 and IP Address #3 starts routing to another server instead?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Feb 05, 2016 8:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Not that I'm an expert, but I think it is kinda as simple as that the address is now responding on the other machine.
The DNS entry doesn't change - it still resolves to the same value.
It's just that the network adapter accepting connections on that IP is now on the other system...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 05, 2016 8:39 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
Not that I'm an expert, but I think it is kinda as simple as that the address is now responding on the other machine.
The DNS entry doesn't change - it still resolves to the same value.
It's just that the network adapter accepting connections on that IP is now on the other system... |
So does that mean TCP IP packets are rattling around like crazy here, there and everywhere, eligible to be "caught" by a valid target? Again, I readily admit I am a network noob! But nobody has been able to explain this to me to the level where I feel I could explain it to somebody else.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 05, 2016 8:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
Not that I'm an expert, but I think it is kinda as simple as that the address is now responding on the other machine.
The DNS entry doesn't change - it still resolves to the same value.
It's just that the network adapter accepting connections on that IP is now on the other system... |
The assigned IP address #3 is the same for DNS #3 no matter which machine is actually servicing it. So the network traffic is still being routed to the same destination, it's just that the destination has moved.
I can't speak for MSCS but on HACMP, VCS & RHCS you can clearly see this at work because all 3 DNS & IP combinations are active so you can telnet into all 3 machines; you simply end up at the same place for 2 of them, and the 3rd one has no cluster controlled resources available.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 05, 2016 8:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
each TCP/IP packet is routed based on it's address. Switches usually form a tree structure, to avoid having one giant switch that handles everything, and to provide short paths between servers.
So address 3 is on a particular subnet - which means it's handled by a single switch. Ideally this is the same switch that handles addresses 1 and 2, but it's not a strict requirement.
All of the other switches in the network know to route packets for address 3 to the right switch. The switch then knows which port(on the switch) to send packets to.
So when the address moves from switch port 1 to switch port 2, the only thing that really changes is the routing table on the switch.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 05, 2016 8:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| So does that mean TCP IP packets are rattling around like crazy here, there and everywhere, eligible to be "caught" by a valid target? |
Probably, but the network people claim that it's all very scientific and the network hardware is actually sending stuff quite deliberately. There's a whole infrastructure of subnets, gateways and routing tables down in the metal.
Poor network performance is often caused by the network rattling IP packets down an inappropriate wire on their way to their destination. Using a tracert on 2 boxes which are physically adjacent often leads to a surprising number of entries, and you're legally allowed to start laughing when a tracert on a badly performing link goes past 6 entries if the network guy is able to hear you.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 05, 2016 8:54 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
each TCP/IP packet is routed based on it's address. Switches usually form a tree structure, to avoid having one giant switch that handles everything, and to provide short paths between servers.
So address 3 is on a particular subnet - which means it's handled by a single switch. Ideally this is the same switch that handles addresses 1 and 2, but it's not a strict requirement.
All of the other switches in the network know to route packets for address 3 to the right switch. The switch then knows which port(on the switch) to send packets to.
So when the address moves from switch port 1 to switch port 2, the only thing that really changes is the routing table on the switch. |
OK, so perhaps the network knows that a packet for IP Address #3 must always go to a particular switch, and that switch is trying both Server #1 and Server #2 all the time to see which one is advertising itself as a valid target for IP Address #3 at any given time?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 05, 2016 8:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| So address 3 is on a particular subnet - which means it's handled by a single switch. Ideally this is the same switch that handles addresses 1 and 2, but it's not a strict requirement. |
still.
If you want to verify this, look at the subnet mask for the cluster by doing an ipconfig from either machine. Typically it's 255.255.255.0 indicating that the first 3 octets are the subnet.
(It's a bit mask - anyone with a different set of numbers can work it out for themselves).
For the reasons my most worthy associate gives, all 3 addresses will typically be on the same subnet and covered by the same switch.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 05, 2016 8:57 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
| mqjeff wrote: |
Not that I'm an expert, but I think it is kinda as simple as that the address is now responding on the other machine.
The DNS entry doesn't change - it still resolves to the same value.
It's just that the network adapter accepting connections on that IP is now on the other system... |
The assigned IP address #3 is the same for DNS #3 no matter which machine is actually servicing it. So the network traffic is still being routed to the same destination, it's just that the destination has moved.
I can't speak for MSCS but on HACMP, VCS & RHCS you can clearly see this at work because all 3 DNS & IP combinations are active so you can telnet into all 3 machines; you simply end up at the same place for 2 of them, and the 3rd one has no cluster controlled resources available. |
Take DNS and DNS Name #3 out of the equation, since clearly the cluster is not updating DNS and everyone's DNS cache every time. DNS#3 always means IP Address #3.
Just focusing on IP Address #3, how? How does the network know to send a packet for IP #3 to Server #1 this time, Server #2 the next time, and never to Server #99?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 05, 2016 8:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| OK, so perhaps the network knows that a packet for IP Address #3 must always go to a particular switch, and that switch is trying both Server #1 and Server #2 all the time to see which one is advertising itself as a valid target for IP Address #3 at any given time? |
No. Remember that the network is sending to IP address #3. It has no interest in which server happens to be under that at any given moment. So the traffic goes to whichever port happens to be IP address #3.
Also remember that in the modern world, a lot of the switches, routers and other network bits are virtual and all of this is just in-memory transfers.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 05, 2016 9:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
| OK, so perhaps the network knows that a packet for IP Address #3 must always go to a particular switch, and that switch is trying both Server #1 and Server #2 all the time to see which one is advertising itself as a valid target for IP Address #3 at any given time? |
It might be polling, at a very very low level (an ICMP echo packet or an ack request). Or it might be that the interface on server2 notifies the switch that it's now supporting address 3. I think the second is more likely.
In either case, the switch updates it's own routing table to point to the new switch port (the port on the switch, not the server) so it doesn't try each packet at both switch ports.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 05, 2016 9:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| Just focusing on IP Address #3, how? How does the network know to send a packet for IP #3 to Server #1 this time, Server #2 the next time, and never to Server #99? |
Because, as I said, it never sends to Server #1, Server #2 or Server #99. It always sends to IP address #3.
Take HA out of the equation. How does the switch know which port Server #1 is connected to, and is thus the correct place to send IP packets addressed to IP address #1? The exact same mechanism is used to route packets for IP address #3, because the network doesn't know IP address #3 is a virtual address floating between servers. It can't know.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 05, 2016 9:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| PeterPotkay wrote: |
| Just focusing on IP Address #3, how? How does the network know to send a packet for IP #3 to Server #1 this time, Server #2 the next time, and never to Server #99? |
Because, as I said, it never sends to Server #1, Server #2 or Server #99. It always sends to IP address #3. |
It always sends to the port on the switch (physical or wireless) that it's internal routing table says is using IP Address 3. Or address 1 or address 100, or whatever.
As my estimatable colleague says, the switch doesn't know anything about servers. It simply knows which IP addresses belong to which switch ports.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 05, 2016 9:07 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
Because, as I said, it never sends to Server #1, Server #2 or Server #99. It always sends to IP address #3.
|
It most certainly does. When the cluster is active on Server #1, packets to IP Address #3 go to Server #1. And then automatically, when the cluster is active on Server #2, packets to IP Address #3 go to Server #2. And they never go to Server #99.
How?
| Vitor wrote: |
Take HA out of the equation. How does the switch know which port Server #1 is connected to, and is thus the correct place to send IP packets addressed to IP address #1? The exact same mechanism is used to route packets for IP address #3, because the network doesn't know IP address #3 is a virtual address floating between servers. It can't know. |
How does the switch know? I don't know. I want to know how the switch knows to go to Server #1, but other times without human intervention, go to Server #2 if the cluster moved to #2? Does the cluster send commands to the network? Probably not. So how does it work?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 05, 2016 9:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
| How does the switch know? I don't know. I want to know how the switch knows to go to Server #1, but other times without human intervention, go to Server #2 if the cluster moved to #2? Does the cluster send commands to the network? Probably not. So how does it work? |
Again. The switch itself has a table. Let's pretend it's an 8 port ethernet cable switch. That means that it has 8 cables that connect to 8 servers.
Server 1 on that switch is connected to port #5. Server 2 is connected to port #8.
The table in the switch says "IP Address #1 goes to port 5. IP Address 2 goes to port 8".
Ok so far?
There's also an entry in the table that says "IP Address 3 goes to port 5." Port 5 happens to be connected to server 1, but the switch doesn't care about that.
When IP Address #3 moves from Server 1 to server 2, the table in the switch gets changed to say "IP Address 3 goes to port 8".
The switch knows to make this change through one of two mechanisms (or maybe a third that I don't know). Method 1: The server sends out periodic ACK messages, and the switch knows that IP Address #3 is live on port 5. When port 5 stops sending ACKs and port 8 strts sending ACKS for Address #3, the switch changes it's table.
More likely, it's method 2. The network interface on Server 2 notifies the switch that it is now the owner of IP Address #3. This happens on port #8, so the switch adjusts it's table.
_________________
chmod -R ugo-wx /
Last edited by mqjeff on Fri Feb 05, 2016 9:26 am; edited 1 time in total |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2, 3, 4 Next |
Page 1 of 4 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
