ACS Forwarders and High Availability - Part 2
In Part 1 of this series, I discussed the scenario where we have only deployed one ACS Collector along with one ACS Database. No additional steps were taken to insure that the ACS Forwarder was able to continue to forward Security events in the event that the ACS Collector becomes unavailable. I would highly recommend that you read at least the first part of Part 1 for some background information if you have found yourself directly on this post.
Scenario #2: Multiple Collector / ACS Database pairs
In this scenario, we have deployed multiple ACS Collector and ACS Database pairs most likely due to performance or scalability concerns. As there are multiple “active” Collectors at one time then our ACS Forwarder has the ability to fail over automatically with no intervention required to a secondary Collector. The term “active” is important here as remember from Part 1 that an ACS Collector as a “one-to-one” relationship with an ACS Database.
In order for this to work we need to specify a comma-separated list of Collector servers when we enable our ACS Forwarders. This is done through the use of an override when we run the “Enable Audit Collection” task in the OpsMgr console.
Notice that our Primary Collector appears last in the last!
That’s all we need to do in this scenario to configure automatic failover but is it the perfect solution? As with everything it seems, the answer is “It Depends.” Read on for a list of reasons why this scenario may or may not be the best solution for your environment.
PROS
· Automatic failover! This is the only scenario where automatic failover occurs as part of the built-in functionality.
· No vulnerability to malicious intruders who manipulate the Security event log.
CONS
· Data for Forwarders ends up being spread across ACS databases and may become hard to query. The impact of this could be negligible if you are using some other tool for long-term ACS data archival.
· Data will be duplicated when the new Collector takes over as the ACSConfig.xml will not have a record of the Forwarders sequence number and will therefore retrieve the last 72 hours’ worth of events. Remember from Part 1 that the ACSConfig.xml helps to keep track of the last events recorded from the ACS Forwarder.
Additional Information:
If you want to see whether or not a Forwarder has more than one server defined then you can view this in the registry on the ACS Forwarder itself within the following key:
HKLM\Software\Policies\Microsoft\AdtAgent\Parameters\AdtServers
If you have specified multiple ACS Collectors then you will find that your ACS Forwarder will fail over automatically when the original Collector is unavailable. You can see this by looking for events like the following in the OperationsManager Event log on the Forwarder:
Log Name: Operations Manager
Source: AdtAgent
Date: 3/22/2011 2:13:54 PM
Event ID: 4368
Task Category: None
Level: Information
Keywords: Classic
User: NETWORK SERVICE
Computer: MYSERVER.MYDOMAIN
Description:
Forwarder successfully connected to the following collector:
COLLECTOR:51909, status: 0x0 (success), source: registry
addresses tried:
xxx.xxx.xxx.xxx:51909
In Part 3 of this series, I will discuss how to create a warm standby ACS Collector so that multiple Database installations are not necessary. This is a new feature for Operations Manager SP1.