- Queue Manager Availability - *Reallocation:* If a queue manager goes down, the service behind it also becomes unavailable due to the disconnection. However, the client queue manager that sent/received the message still has the information, and will be able to reroute/reallocate it (unless it was bound to the failed service instance) - *Restart/Reconnect:* You may have messages locked on the failed queue manager, in which case you need to restart the queue manager and reconnect it to its service to make sure they become available again.
- Service Application Availability - If a service goes down, its connected queue manager may still be up, meaning other queue managers don't know that the service has gone down. This leads to a build up of messages in the queue because they are not being processed by the service - *Sample* *Monitor* *Service:* checks if the queue manager is connected to its service. In the case when a service goes down, the monitor detects it and it will 1. modify the queue manager config to have a lower priority 2. move the messages from the disconnected queue manager to a healthy one (Suited for *steady* *state* service apps) - Client Failures - Client Queue manager may also go down - To ensure Client availability, multiple locations to service client connections should be available (2 layers of queue managers)
*Avoiding* *Interference* - You could have different categories of clients and services sharing a cluster (and therefore same comm channels), how do you avoid interference? - define multiple clusters with different channels over the same queue managers - define which channel to send message through for each cluster definition However, with this setup, because the load balancing is done at the *channel* *level*, if you have an unbalanced setup of services, you may not have an equal split of messages if a queue manager has more responsibility than others (My interpretation, avoid this setup)
*Cluster* *Transmit* *Queue* *(CTQ)* Analyzing potential problems with a single transmission queue from the sending queue manager: 1. *Separation* *of* *Message* *Traffic:* different channels can interfere 2. *Management* *of* *messages:* some queue concepts become inapplicable 3. *Monitoring:* single queue can be difficult 4. *Performance:* not usually the bottleneck New versions (IBM MQ V7.5 and V8 support multiple CTQs) (See video at 33:50 set up details for Automatic/Manual mode)
*Disaster* *Recovery* - Synchronous Replication: - state and data at Datacenter 1 is replicated in Datacenter 2 for fast recovery (I think the replication happens for each operation so Datacenter 2 is always at most 1 operation behind Datacenter 1)
- Asynchronous Replication: - Datacenter 2 in this case can be several steps behind Datacenter 1, so you need to refresh cluster state, but if your datacenter contains a Full Repository Queue Manager, it can be too invasive. - Solution: 42:20 (don't replicate the Full Repository Queue Manager)
- No Replication: - "warm standby", you use priority/ranking for services to automatically reroute traffic on failed connection to Datacenter 1 to Datacenter 2
*Timestamps*
0:11 Agenda
0:45 1. *Why* *a* *Cluster?*
5:17 2. *Availability*
12:12 2.1 Service Application Availability
17:41 2.2 Client Availability
18:56 3. *Location* *Dependency*
25:18 4. *Avoiding* *Interference*
37:00 5. *Disaster* *Recovery*
I've also taken notes below, please point mistakes out and I'll edit, thx.
*Different* *Cluster* *Usecases:*
- Load Balancing
- Queue Manager Availability
- *Reallocation:* If a queue manager goes down, the service behind it also becomes unavailable due to the disconnection. However, the client queue manager that sent/received the message still has the information, and will be able to reroute/reallocate it (unless it was bound to the failed service instance)
- *Restart/Reconnect:* You may have messages locked on the failed queue manager, in which case you need to restart the queue manager and reconnect it to its service to make sure they become available again.
- Service Application Availability
- If a service goes down, its connected queue manager may still be up, meaning other queue managers don't know that the service has gone down. This leads to a build up of messages in the queue because they are not being processed by the service
- *Sample* *Monitor* *Service:* checks if the queue manager is connected to its service. In the case when a service goes down, the monitor detects it and it will
1. modify the queue manager config to have a lower priority
2. move the messages from the disconnected queue manager to a healthy one
(Suited for *steady* *state* service apps)
- Client Failures
- Client Queue manager may also go down
- To ensure Client availability, multiple locations to service client connections should be available (2 layers of queue managers)
*Avoiding* *Interference*
- You could have different categories of clients and services sharing a cluster (and therefore same comm channels), how do you avoid interference?
- define multiple clusters with different channels over the same queue managers
- define which channel to send message through for each cluster definition
However, with this setup, because the load balancing is done at the *channel* *level*, if you have an unbalanced setup of services, you may not have an equal split of messages if a queue manager has more responsibility than others (My interpretation, avoid this setup)
*Cluster* *Transmit* *Queue* *(CTQ)*
Analyzing potential problems with a single transmission queue from the sending queue manager:
1. *Separation* *of* *Message* *Traffic:* different channels can interfere
2. *Management* *of* *messages:* some queue concepts become inapplicable
3. *Monitoring:* single queue can be difficult
4. *Performance:* not usually the bottleneck
New versions (IBM MQ V7.5 and V8 support multiple CTQs)
(See video at 33:50 set up details for Automatic/Manual mode)
*Disaster* *Recovery*
- Synchronous Replication:
- state and data at Datacenter 1 is replicated in Datacenter 2 for fast recovery (I think the replication happens for each operation so Datacenter 2 is always at most 1 operation behind Datacenter 1)
- Asynchronous Replication:
- Datacenter 2 in this case can be several steps behind Datacenter 1, so you need to refresh cluster state, but if your datacenter contains a Full Repository Queue Manager, it can be too invasive.
- Solution: 42:20 (don't replicate the Full Repository Queue Manager)
- No Replication:
- "warm standby", you use priority/ranking for services to automatically reroute traffic on failed connection to Datacenter 1 to Datacenter 2
Excellent explanation!! Very useful.
Thank you Mr.David.
Really very nice. thank you very much. GREAT EXPLANATION. keepit up.
U r videos are perfect
Hi David, are you going to post your Think2019 presentation about "Uniform Cluster" as well. I enjoyed your talk at NYNJMQ on that subject.
Hi David, do you have any vídeo teaching how to troubleshooting daily bases issues ? Thank you for sharing with us your knowlodge.
Good Video.
Thank you
Good One