In this pattern we connect gateway workers to two traffic managers. If one goes down then other can act as traffic manager for gateway. So we need to configure gateway to push throttle events to both traffic managers. Please see the diagram below to understand how this deployment works. As you can see gateway node will push events to both traffic manager node01 and node02. And also gateway receiver's throttle decision updates from both traffic managers using failover data receiver pattern.
Traffic Managers are fronted with load balancer as shown in the diagram.
Traffic Managers are fronted with load balancer as shown in the diagram.
Then admin dashboard/publisher server will communicate with traffic manager through load balancer. When user creates new policy from admin dashboard that policy will be stored in database and publish to one traffic manager node through load balancer. Since we do have deployment synchronize mechanism for traffic managers one traffic manager can update other one with latest changes. So it's sufficient to publish throttle policy to one node in active/passive pattern(if one node is active keep sending requests to it and if it's not available send to other node). If we are planning to use svn based deployment synchronizer then created throttle policies should always publish to manager node(traffic manager instance) and workers need to synchronize with it.
TopicConnectionFactory
topic
org.wso2.andes.jndi.PropertiesFileInitialContextFactory
The idea behind failover data receiver endpoint is stopping single-point-of-failure in a system. As the broker deployed in each traffic manager and storing and forwarding the messages, if that server goes down entire message flowing of the system will go down no matter what other servers and functions are involved. Thus in order to make a robust messaging system it is mandatory to have a fail-over mechanism.
When we have few instances of Traffic Manager servers up and running in the system generally each of these server is having broker. If one broker goes down then gateway automatically switch to the other broker and continue throttle message receiving. If that one also fails it will try next and so on. Thus as a whole system will not have a downtime.
So in order to achieve high availability for data receiving side we need to configure JMSConnectionParameters to connect multiple borocker running within each traffic manager. So for that we need add following configuration to each gateway. If single gateway is communicating with multiple traffic manager this is the easiest way to configure gateway to communicate with multiple traffic managers.
Thanks for the detail information.
ReplyDeleteI have few questions.
- Do you have any additional information wrt to (1) Configuration details for the svn based deployment synchronizer
(2) Configuration to implement the portion marked in BLUE in the above diagram in the blog post.
FYI:
Although the configuration for svn based deployment synchronizer in GW Manager works fine,
if same configuration is done in Traffic Manager, the svn based deployment synchronizer functionality does not work.
The traffic manager is configured as per the procedure mentioned in the following link
https://docs.wso2.com/display/CLUSTER44x/Clustering+API+Manager+2.0.0
Thanks in advance.
Appreciate your prompt help and support.
Regards,
Hi,
DeleteIt should be same as gateway deployment synchronization. Because we need to share repository/deployment/server directory. If you have multiple traffic managers then have separate svn location for that and configure it in same way we do for gateway. If you see any errors please let us know. Thank You.
Thanks a lot Sanjeewa!!
DeleteLet me check. I will let you know if there are any issues.
Regards