I would like to install a 2nd/mirrored Hub on the same Domain/network in case the Hub crashes. Is there any documention on how to set this up?
I did something fairly similar in an environment like that a while back. I am not sure if this was the right approach, but I installed the second hub using the infrastructure installer rather than the Nimsoft Server installer because I was not I was not setting up another database. Then I used the Archive to deploy the core probes to the other hub--data_engine, nas, etc. In the end, I compared the probe lists on the primary and secondary root hubs to make sure I had everything.
As far as configuring probes in the two hubs, there are several options. Your decisions should be guided by your goals. In my case, we wanted a redundant hub that could take over in the event of a disaster with the primary hub. We were not looking to load balance for extra capacity. We distributed the load on the two hubs, but it was important to us that a single hub be able to handle the full load because that is the situation we were planning for. Here is how we setup the main components:
- data_engine - Disabled on secondary hub.
- distsrv - Enabled on secondary hub. Primary hub configured to forward packages to secondary. (Distributed hubs did not run the distsrv.) Licences had to be maintained manually on both, although I think the distsrv might take care of this now as well. All packages had to be updated on the primary hub, but they could be deployed by users logged into either root hub.
- nas - Enabled on secondary hub and setup to mirror with primary hub. Auto-operator enabled on both because filtering was needed. AO pre-processing rules enbled on both. AO profiles enabled on primary only. AO scheduled jobs enabled on primary only. AO pre-processing rules had to be entered manually on both hubs (although this could be streamlined with a careful script).
- report_engine - Disabled on secondary hub.
- sla_engine - Disabled on secondary hub.
- hub - The local nas probe connected to the nas queue on the secondary hub. A get queue on the primary hub connected to the data_engine queue on the secondary hub. Tunnels were setup and active from both root hubs to the distributed hubs. Both root hubs had a queue configured to each distributed hub, but the queue was disabled on one of the two root hubs (so it could be enabled quickly when recovering from disaster).
I believe there were other probes that were disabled on the secondary root hub, but these are the really important ones.
That would make a great whitepaper or case study!
What kind of environment do you now? Just one hub, or one central hub that communicates with distributed hubs?
One central hub that communicates with multiple distributed hubs. The environment is growing which is why the need for a 2nd 'central' hub might be good idea
Hi Keith, thanks so much for your detailed response. I'll see about putting something in to place in the near future
Retrieving data ...