| |
|
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
|
| Vitor |
 Posted: Fri Feb 05, 2016 9:19 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| 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. |
It most certainly does not. Trust me (I know that's a stretch). It's transmitting to the IP address and has no clue what's on the back end.
| PeterPotkay wrote: |
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? |
If you want a full and detailed answer to that, take a network engineering course (which covers some of the items my most worthy associate mentioned further up). I'm going to stick with my previous answer - the same way it knows to direct packets for IP address #1 or IP address #2. Look at your router at home - it will have a number of ports. You can plug the Cat 5 from your PC into any of them and your PC will not only continue to work, it will not change IP address.
| PeterPotkay wrote: |
| How does the switch know? |
The same way it knows the interconnection between all addresses and ports (correctly referred to earlier as the routing table).
| PeterPotkay wrote: |
| 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? |
The same way it works for any other change of IP address. This is nothing to do with the cluster and everything to do with the network knowing how to route packets.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Feb 05, 2016 9:54 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
It's a little bit more complicated than that. The common IP is typically part of the cluster resources. So whenever the cluster decides it needs to switch sides, it will switch all resources to said side (host).
So imagine ip3 is in fact a software artifact that advertises itself to the nearest router... Obviously you still need the network engineers involved to avoid over-allocation and / or conflicting ips. So there is only 1 ip3 in the network. But it'ts presence is driven by the cluster...
Different analogy: imagine ip1 and ip2 are 2 computers. But only one of them can be on the net at a time. And they both advertise themselves under ip3...
Think about it, a little bit as like having a qmgr alias defined in an MQ cluster.
QM3 is defined as a multi-instance qmgr in cluster CL1.
It has a clustered qmgr Alias to allow traffic to an outside qmgr EQM (not in the cluster)... So how does your response know how to go to the outside qmgr?
The deciding algorithm on how the vip in the HA cluster moves, you will find is not so different from the MQ cluster question above.... even though the internal implementations are miles apart...
So this was the deterministic approach where the ip routing is decided by the cluster management software.
You also have the (don't know / don't care) approach where the vip is defined on a network appliance. The appliance will then scan for whichever of the participants responds and direct the traffic there. This is the basis for load balancing. Applied to HA this means that you would always have only one success condition and the rest would show failures... This network appliance will have to do some polling to determine which route is good ip1 or ip2...
Hope that helps a bit... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 05, 2016 10:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
A bit more...
| Vitor wrote: |
| PeterPotkay wrote: |
| 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. |
It most certainly does not. Trust me (I know that's a stretch). It's transmitting to the IP address and has no clue what's on the back end. |
|
 Vitor is correct. Ipaddresses are virtual, really.
I'm sitting at a PC known to my nearby router as 192.168.1.something - an ipaddress unknown to the real world. When I poke the Submit button, the resulting packets escape my router with the destination ipaddress of mqseries.net - whatever that was at the moment mqseries.net sent me the inbound packets.
At the destination, the router there will discover that the internal ipaddress is possibly some 192.168.1.something - or other.
It is possible or likely that a server failure will be discovered by a router there, and the packets will be rerouted to the next instance of the server. That instance can be in the same subnet, or it can be in an entirely different subnet - like a DR site.
This whole internet infrastructure was designed to tolerate packet loss, which implies delivery failure, which implies alternate routing, which implies virtual ipaddresses, which implies...
| PeterPotkay wrote: |
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? |
The routing protocols in the middle of all of this stuff recognize loss of the destination server ipaddress, and redirects those packets to the next instance of the server. Whether packets flow to #99 is up to the tables configured in router.
| PeterPotkay wrote: |
| How does the switch know? |
Switches are different from routers. Usually, all a switch knows is the MAC address of the device plugged into the switch port, and the ipaddress currently assigned to that port. The router determines to which switch port packets should flow.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 05, 2016 10:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There's a little more information in your thread on the listserv, from Dave Hinkle.
The interface on the server sends an ARP (address resolution packet?) to the switch when it assumes an IP address. The updates it's table to point to the new port/MAC.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 05, 2016 10:47 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
"ARP, ARP," said Sandy. "RARP," she growled.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 05, 2016 10:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| "ARP, ARP," said Sandy. |
Why did the clam go to the hardware store? She wanted to buy valves.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 05, 2016 10:49 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
| bruce2359 wrote: |
| "ARP, ARP," said Sandy. |
Why did the clam go to the hardware store? She wanted to buy valves. |
ACK!
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Feb 05, 2016 4:23 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| mqjeff wrote: |
There's a little more information in your thread on the listserv, from Dave Hinkle.
The interface on the server sends an ARP (address resolution packet?) to the switch when it assumes an IP address. The updates it's table to point to the new port/MAC. |
Yes, his answer finally gave me what I needed for the light bulb to go off.
| Quote: |
ARP (Address Resolution Protocol).
The network gear keeps a mapping of IP address to MAC address (an ARP table).
When server #2 'takes over' the IP #3, it sends out what is called a 'Gratuitous Arp'. This packet basically says 'Hey network gear, update your ARP table with my new IP to MAC mapping'.
At this point, with the network gear ARP table correctly updated, the packets now flow to the interface associated with the MAC of server #2.
|
Reading your answer again, Jeff, you said basically the same thing. I appreciate the other responses in the thread, but they still left me wondering - how?
The key concept to me was that the VCS or MSCS or HACAMP software/firmware had the ability to get the network gear to update their routing tables so that the packet looking for IP address #3 new at the network layer which router and switch and cable coming out of that switch and MAC address to use. You may say "Yeah, what I said!", but it was still magic to me until mqjeff's and dave's answer explained it to me in terms I could understand.
OK, so now my REAL question! 
why don't the MQ Appliances or Multi Instance QMs do this? Or if they do, how do we enable it?
Initial reactions may be: IBM took care of this by allowing the connecting MQ Clients and connecting Queue Managers to specify a comma separated list of hostnames in the CONNAME parameter. Fair enough, and for new implementations where all the connecting clients and QMs can support this, good.
But consider this use case. If we have a pair of non IBM servers using a non IBM O/S with a non IBM solution like MSCS or VCS, all those connecting clients and connecting QMs need to A.) be able to support multiple hostnames and B) switch to using multiple host names if and when we want to switch them to an MQ Appliance (a full IBM solution, $$$ for IBM) or a M.I. QMs.
If there are hundreds of clients and dozens of QMs connecting to that queue manager on the VCS cluster, all addressing it via DNS #3, it would be easier to migrate them to the MQ Appliance or the MI QM if we could at the DNS layer repoint DNS#3 to stop using IP #3 in the VCS cluster, but instead have DNS #3 now resolve to IP address #x, the new single floating IP address that the MQ Appliance or the MI QM handles the same way a VCS cluster handles it.
If VCS and HACAMP and MSCS can update the network gear to know which node of a 2 node VCS and HACAMP and MSCS cluster owns IP address #3, why can't a pair of IBM MQ Appliances or a MI QM do the same? I would open an RFE and ask for your votes if at the conclusion of this thread it still seems it would be a good idea.
Tsk, Tsk you say, all your clients should be at MQ 7.1 or newer, so just use comma separated CONNAMEs. Ha! I don't know what utopia you live in (any open positions?)
Tsk, Tsk you say, all your QMs should be at MQ 7.1 or newer. Ha! Yeah, we pay the extended support for the few pockets still forced to be at MQ 6
Come'on man, how difficult is it to ask an MQ Client to upgrade themselves, change their conname, change it from a single conname to 2 separate by a comma. Ha? No, no longer laughing, its just sad and frustrating. "We don't use MQ." "But there are connections from your app server to this queue, and 1,000 messages have gone thru it in the past hour." Pause. Pause. "OK, we will get back to you."
I gotta get off some old MCSC and VCS solutions. Hey IBM, if you beefed up the MQ Appliances and/or the M.I. QMs to allow them to manage a floating IP address the way VCS and HACAMP and MSCS having been doing forever, I think it would make it an easier sell to get customers to move off of VCS and HACAMP and MSCS over to an MQ Appliance. I think you would like it easier to sell a propriety solution like an MQ Appliance, yes?
Wouldn't life be just a little simpler if the MQ Appliance (or M.I. QMs) would support a floating IP like VCS and HACAMP and MSCS have forever?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Feb 06, 2016 5:46 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| PeterPotkay wrote: |
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? |
Well strictly speaking, within the same subnet, barring any bridge filters, and the use of ethernet (more common than token ring, these days), the packets reach all the computers in the subnet. It is the network card and low level protocols that then filter out the packets not addressed to the card. This is why on a subnet with high bandwidth utilization you talk about collision problems...
Think about the packets as a published message. The Nic Card then acts like a subscriber to the packets with its address on the header...
So strictly speaking the packets do go server #99, they are just never consumed by it...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Feb 06, 2016 5:52 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| PeterPotkay wrote: |
Wouldn't life be just a little simpler if the MQ Appliance (or M.I. QMs) would support a floating IP like VCS and HACAMP and MSCS have forever? |
There is nothing to prevent you from using a software solution that you could then start and stop using the MQ Services at qmgr start up and shut down.
This would then create the added ip endpoint and move with the MI QMGR...
Talk to your network engineers and see if that is possible...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 08, 2016 6:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I suspect that the reason that MQ doesn't do this is that MQ doesn't want to mess with anything outside of MQ. Like network adapters.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 08, 2016 7:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
| I suspect that the reason that MQ doesn't do this is that MQ doesn't want to mess with anything outside of MQ. Like network adapters. |
Or viewed another way, where appropriate, MQ makes use of services and protocols supported or provided by the o/s - SSL/TLS, TCP, OAM.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Feb 08, 2016 9:19 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| mqjeff wrote: |
| I suspect that the reason that MQ doesn't do this is that MQ doesn't want to mess with anything outside of MQ. Like network adapters. |
On the other hand, the MQ Appliance is dealing with and taking care of a lot more than just MQ. So the pure MQ bits in an MQ Appliance can stay squarely in the MQ realm. But all the other parts that deal with hardware, firmware, replication, network, (potential future) dealings with external storage....perhaps its not so much a stretch to consider that part dealing with virtual IPs, as an option, the same way MSCS, HACAMP and VCS have for years.
I have been made aware that there already is an RFE on this topic for the MQ Appliance
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=82204
Interesting, with only 1 vote it already has a status of Under Consideration. I added my vote. Please add yours if you think it would be good to have this as an option on the MQ Appliances. It would aid greatly in migrations to the MQ Appliance. And if its implemented optionally, no reason you have to use it in favor of multiple DNS names in the CONNAME of connecting MQ Clients and QMs.
Also, I think by having a virtual IP available per QM on the appliance, it could aid with firewall rules if used in conjunction with LOCLADDR.
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Wed Feb 10, 2016 4:26 am; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Feb 08, 2016 9:24 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| fjb_saper wrote: |
Think about the packets as a published message. The Nic Card then acts like a subscriber to the packets with its address on the header...
So strictly speaking the packets do go server #99, they are just never consumed by it...
|
I was diggin' your analogy till the last sentence. Those packets can't be going to #99. The router (pub sub engine) isn't sending a packet to every server it can for a packet looking for IP Address #3.
Perhaps the way to make the analogy is that Server #1 is subscribed to IP#3, so the router sends (pubslishes) IP#3 packets to Server #1. And then when the cluster fails over, Server #1 unsubscribes to packets for IP#3 and Server #2 subscribes to packets for IP #3?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 08, 2016 1:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| PeterPotkay wrote: |
| fjb_saper wrote: |
Think about the packets as a published message. The Nic Card then acts like a subscriber to the packets with its address on the header...
So strictly speaking the packets do go server #99, they are just never consumed by it...
|
I was diggin' your analogy till the last sentence. Those packets can't be going to #99. The router (pub sub engine) isn't sending a packet to every server it can for a packet looking for IP Address #3.
Perhaps the way to make the analogy is that Server #1 is subscribed to IP#3, so the router sends (pubslishes) IP#3 packets to Server #1. And then when the cluster fails over, Server #1 unsubscribes to packets for IP#3 and Server #2 subscribes to packets for IP #3? |
Depends on the router... However typically the packets hit the full subnet. So every computer on the subnet gets the packet (including #99). However the address header on the packet says it is for address #3. So only address #3 will effectively process the packet. But as the whole subnet gets it, you might be snooping on the subnet for content which is meant for a different computer; that is if you told your NIC to also look for packets addressed to #3...
At least that's what I remember from my very light networking classes...
This allows you to have splitters on the outbound connections of the router...
How else can you get 255 devices (including the router) on a subnet when the router only has 4 outbound ethernet outlets?
Think about MQ 7.5 and cluster publishing. Whether you subscribed or not the publication will go to each member of the cluster... but it will only show up in your queue if you subscribed the queue to the publication...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
