In my environment, we’re running DSA servers on three nodes. Two nodes are at our local site, and a third node geographically distributed halfway across the US. Our operations concept is that console operators may log on to any of the three to issue actions.
Any given client only reports to one of the three servers, based on how the Relays and firewalls are configured. These are intended such that in the case of serious outage or hack affecting our public-facing network, we can sever our links and operate independently on each of the three DSA servers (with each servicing a separate set of clients), or operate out of our backup center in case of a regional event such as hurricane. Actions and content replicate across the DSA servers and can take effect on clients regardless of the server to which they are reporting (but as expected there is a delay in reporting results across the DSAs)
This has been working great for several years, but now we are interested in automating some of our processes (such as Scheduled Wake-on-LAN and moving in to Server Automation), that require configuring the BES Server Plug-in Service. I’m not sure the best way to set that up -
-
Should I configure the BES Server Plug-In Service independently on each of the three DSA servers, such that all three are running the service (and polling their local Web Reports server)? Would that result in duplicate actions issued by the BES Server Plug-In Service (for instance each of the three DSAs creating their own WoL actions)? Or is the action created on the DSA server that’s currently connected by the console operator?
-
Or should I configure only on one of the three DSA servers?
-
Do actions issued by the Wake-on-LAN wizard, the Action Regenerator, and anything else using the Plug-In Service, behave like regular actions (in that the action would replicate between the DSAs and flow down to the Relays)?