Monitoring Services in a Redundancy Environment

The following describes the recommended solution for using the Service Monitor Service (SVCMON) to collect and monitor system, service, and site statistics on all the domains (active/live, local standby, data-center standby) in your redundancy environment.

The live or primary domain will have its own SVCMON that will replicate everywhere, collecting data on the single live domain. It will collect data on all the services except the RSM (since the name is different per each host).

Best practice recommends that each data center has a bastion host with a SVCMON service collecting data for the other domains running in that data center.

The bastion host SVCMON service will also collect data for every RSM running in that data center. Since the RSMs are running on all possible domains, the bastion host SVCMON service will just have to pick one domain on which to talk to each RSM.

For the data-center standby domain, since it can run in either data center, one of the bastion host services will be appointed to collect its statistics. Presumably this will be the service it is most often running in. When running in the other data center, the SVCMON info will go across the WAN, which is deemed acceptable.

Machine specific statistics will be collected by the bastion SVCMON service via the RSM. This is how you can review the health of your data center.

Machine specific statistics will also be collected by the live domain via a different service (you can decide which). This will allow you to easily align machine statistics (regardless of the host the live domain is running on) with the statistics of the live system for the purpose of troubleshooting issues.

Services on the Bastion Host

The following services should be running on the bastion host for all redundant RSMs to report to. At this time, only the ARS is required. The others are recommended.

Service	Required	Purpose
ARS	Yes	An active running ARS for each domain running in each data center. The purpose of the bastion ARS is to make sure that clients can always connect to services on the domain, even during a failover. This ensures that if there is a failover, there will never be a domain without an active running ARS.
AUD	No	An active running AUD that can be used to receive change records during failover. This ensures that a complete failover history is stored in one place since audit records would be lost on most redundant domains. Note: Best practice recommends configuring a single AUD service for all redundant RSMs in all data centers to report to as the RSM moves between domains during local and data-center failover. It is also recommended that it run on a different domain than all the domains that are part of the redundancy set.
BSS	No	An active BSS can be used to host your Redundancy Dashboard screens. If these documents were hosted in a redundant BSS, you couldn't load the screens during a failover.
ELS	No	An active running ELS where system-generated and user-defined events can be logged during failover. This ensures that a complete failover history is stored in one place since event records would be lost on most redundant domains. Note: Best practice recommends configuring a single ELS for all redundant RSMs in all data centers to report to as the RSM moves between domains during local and data-center failover. It is also recommended that it run on a different domain than all the domains that are part of the redundancy set. All RSMs would report to the ELS, so the service would include more than just events during a failover, but all events by those RSMs.
GNS	No	An active running GNS that can be used to send notifications during failover. You can’t send notifications from a redundant GNS that is failing over. See Sending Failover Notifications for more information.
SVCMON	No	An active running SVCMON service collecting data for the other domains running in that data center. Highly recommended. Note: You must have a Bastion SVCMON configured to run the Failover status (SVMFOSTATU) point and retrieve values.