How to achieve High Availability in pega 7.1.8 agents.
We are looking to implement High availability in Agents to make the Prod to DR switch less painful. Currently during Prod - DR switches, we need to manaully stop agents on Prod and enable them on DR. Is it possible to use loadbalanced url somehow?
***Updated by moderator: Lochan to update Categories; added SR details***
Thanks for your quick response!! I did check the High Availability Admin guide. It mentions that Agents and listeners using URL's can use loadbalanced urls to achieve this. I can see the option of using load balanced url in listeners using "Host based startup" but I couldn't find anything in Agents.
I suppose there are tow environments one Prod and one DR. Are the two environments sharing a database? Is the requirement to disable agents in one environment and enable them in another. I believe in that case it needs to be done manually. We don’t have an automated way to switch over from one to the other in terms of running Agents.
Please let me know if I am reading the question incorrectly.
You understoood it correct. we are looking to implement high availability in Pega 7.1.8. I checked the high availability guide where Pega mentioned that "Listerners and agents using url's should replace it with loadbalanced url which is so good if possible. I think we can give loadbalance info in "Host based strartup" in listeners. BUT, I don't see anywhere in agents where we can use loadbalanced url. Is there a way for using loadbalance info for agents?
I had a look into the SR for you and found that the root cause was that the information in the document was creating a confusion.
The implication that any URI reference such as the Host Name in a file listener, can be replaced with a load balanced URI is incorrect. There is no inherent fail over possibility for the file listener.
Agents have no inherent way in their definition to specify a 'load-balanced' URL for redundancy in the Pega 7 cluster either.
What is meant is that any reference to an external URI can and should be a resource that has either fail over capability or redundancy behind it.
There is nothing in Listeners or Agents per se that cause them to be treated any differently than other references to external resources such as Connect Rules or other integration points to external resources.