Unofficial Guide to Maintaining a Standby ArcSight Express 3.0 or 4.0 (CORR Engine) Version 0.4_1
- Pavan Raja
- Apr 9
- 7 min read
Summary:
To ensure that you're not losing any events and that your ArcSight setup remains functional even if one of your Express appliances fails, follow these steps for transitioning from a standby host (HostB) to the primary host in case of hardware failure on HostA:
### 1. **Restore Archives:** From HostA, use the command `/opt/arcsight/logger/current/arcsight/logger/bin/arcsight restorearchives -C` to confirm and execute the deletion of all existing event archives. Move the restored events onto the specified folder (`/opt/arcsight/logger/data/archives/`) on HostB.
### 2. **Verify Ownership:** Ensure that the ownership of the moved archive files is changed back to the 'arcsight' user using the command `chown -R arcsight:arcsight /opt/arcsight/logger/data/archives/`.
### 3. **Start Services:** Restart both the Logger and Manager services on HostB to ensure they are operational with the restored events.
### 4. **Web UI Activation:** Log into the ArcSight Web UI, navigate to the 'Administration' tab, select 'CORR-Engine Management', then go to 'Archives'. Activate the restored Events archive by selecting it and choosing 'activate'.
### 5. **Logger Service Start:** Begin the Logger service on HostB if not already running.
### 6. **Reconfigure SmartConnectors:** Adjust the SmartConnectors to point to HostB, updating their configurations as needed.
### 7. **Appendix - Test:** Perform a series of tests to ensure that all components are correctly reconfigured and functioning properly. This includes registering ConnectorA with HostA, sending test events for verification, and making necessary adjustments in configuration files and system properties.
### 8. **Stop/Start Services:** Stop all ArcSight services on the original (now failed) appliance (HostA). Restore the `/opt/manager` folder from HostA to HostB, ensuring that it overwrites any existing content. This mimics the setup of HostA as much as possible. Change ownership recursively to 'arcsight:arcsight' for this restored folder.
### 9. **Re-start Services:** Restart all ArcSight services on HostB after these changes have been made. You should now see events flowing into the cold standby host (HostB).
By following these detailed steps, you can significantly reduce the risk of event loss and ensure that your system maintains a high level of operational continuity even in the face of hardware or software failures.
Details:
To achieve a "standby" ArcSight Express solution for Disaster Recovery (DR), follow these steps:
1. **Understand the Requirement**: The primary ArcSight Express appliance does not support native High-Availability or Stateful High-Availabiliy, which is crucial for Business Continuity and DR planning according to customer needs.
2. **Implement Dual Feeds at Connector Level**: Configure connectors in a failover scenario where if one Logger/Express goes down, the connector redirects the event feed to the secondary Logger/Express. This ensures minimal downtime and maintains some level of redundancy.
3. **Options for Standby Implementation**:
**Option A – Hot Standby**: Set up two ArcSight Express (AE) boxes in a redundant configuration (HostA: Primary AE, HostB: Standby AE). Synchronize resources across the two instances using a scripted or manual process to maintain chain of custody.
**Pros**: Ensures no loss of events and maintains chain of custody.
**Cons**: Requires more network bandwidth due to dual configurations in downstream SmartConnectors/Logger, and higher CPU load on SmartConnectors as they handle data for two AE instances simultaneously.
**Option B – Cold Standby**: In this scenario, HostB does not receive any events until a DR scenario occurs. Reconfigure connectors when the primary host (HostA) goes down to avoid chain of custody breakage but risks potential event loss during the reconfiguration process.
**Pros**: Lower network bandwidth and CPU load since no dual configurations are required.
**Cons**: Chain of custody may be broken, leading to possible data loss between the last archived events and the first new events received on HostB.
In summary, Option A provides a fully redundant setup with minimal event loss but requires more resources, while Option B is simpler in terms of resource usage but risks losing some events during failover scenarios.
The provided text discusses two options for handling a disaster scenario involving ArcSight Express (AE) and its SmartConnectors, where HostA fails and needs to be replaced with HostB. Option A involves detailed steps to export system tables from HostA and transfer them to HostB, while Option B suggests making changes directly on HostB to mimic HostA without exporting data.
**Option A - Details:**
This option requires several steps:
1. Export all the system tables on HostA using a specific command.
2. Transfer the exported SQL file (arcsight_dump_system_tables.sql) from the temporary location (/opt/arcsight/manager/tmp) to HostB.
3. Ensure the destination folder on HostB does not have any in-use processes.
4. Import these tables onto HostB, which requires logging into the Web UI and performing necessary actions.
**Pros:**
Ensures that all data is preserved without loss of chain of custody if all SmartConnectors were initially feeding to Logger and ArcSight Express was only receiving from the Logger.
**Cons:**
A direct transfer of system tables might not fully mimic HostA's configuration, potentially leading to a break in the chain of custody and potential data loss during the transition period when events first appear on HostB.
**Option C - Cold Standby (reconfiguration of SmartConnectors is not required in a DR scenario):**
This option assumes that no reconfiguration of SmartConnectors is needed, which might be feasible if they are initially feeding to Logger and not directly to ArcSight Express.
However, the text does not detail this option further or discuss its pros and cons.
**Option B - Details (to mimic HostA):**
To mimic HostA on HostB:
1. Ensure HostA is offline.
2. Change HostB's hostname to match HostA's hostname.
3. Update the IP address of HostB to match that of HostA.
4. Modify /etc/hosts and /etc/hostname files accordingly.
5. Copy the entire ArcSight Express manager folder from HostA to HostB.
**Pros:**
Avoids reconfiguring SmartConnectors, saving bandwidth and CPU resources.
**Cons:**
Chain of custody is broken because there will be a gap between the last archived events and the first new event on HostB, which might lead to data loss.
Special Scenario: If all SmartConnectors were initially feeding to Logger and ArcSight Express was only receiving from the Logger, chain of custody would not break as Logger still holds the events.
In summary, Option A is more comprehensive but risks data loss due to the potential mismatch in configurations between HostA and HostB. Option B aims for a quicker setup by mimicking HostA's configuration but could lead to issues with the chain of custody if used directly without careful handling during the transition period.
To summarize the process described above for promoting a 'cold standby' ArcSight Express to a Primary Express when HostA experiences a physical hardware failure, follow these steps:
1. **Create an Event Archive on HostA:**
As the ArcSight admin, create an Events archive on HostA every night.
Copy this archive to HostB during non-busy hours over the network.
Ensure the destination folder `/home/arcsight/logger/databaseArchivedFromPrimaryAE/archives/` is empty and not in use by any process.
Change ownership of this folder and its subfolders to the 'arcsight' user:
```bash
chown -R arcsight:arcsight /home/arcsight/logger/EventsDBfromPrimaryAE/archives/
```
2. **Promote HostB to Primary:**
When HostA fails, initiate a manual fail-over by executing the following on HostB:
Ensure AE is reachable via WebUI and Console using the hostname: HostB.
Verify that the license is functional.
Copy the file `arcsight_dump_system_tables.sql` from `/home/arcsight/express/systemTables/` to `/opt/arcsight/manager/tmp`.
Stop the Manager service on HostB:
```bash
sudo systemctl stop arcsight-manager
```
Start the import process to restore all resources to HostB using the command:
```bash
./arcsight import_system_tables
# Example:
./arcsight import_system_tables arcsight arcsight arcsight arcsight_dump_system_tables.sql
```
Stop the logger service (which stops the manager service as well). This is necessary because restoring through Web UI is not possible in this state. Use `restorearchives` for command-line restoration:
```bash
restorearchives
# Example:
restorearchives arcsight arcsight
```
Clear the Events DB before importing the new data to avoid conflicts or redundant entries.
This summary captures the essential steps for transitioning from a standby host (HostB) to the primary host in case of a hardware failure on HostA, ensuring minimal downtime and smooth operation of the ArcSight system.
To ensure that you're not losing any events and that your ArcSight setup remains functional even if one of your Express appliances fails, follow these steps:
1. **Restore Archives**: From HostA, use the command `/opt/arcsight/logger/current/arcsight/logger/bin/arcsight restorearchives -C` to confirm and execute the deletion of all existing event archives. Move the restored events onto the specified folder (`/opt/arcsight/logger/data/archives/`) on HostB.
2. **Verify Ownership**: Ensure that the ownership of the moved archive files is changed back to the 'arcsight' user using the command `chown -R arcsight:arcsight /opt/arcsight/logger/data/archives/`.
3. **Start Services**: Restart both the Logger and Manager services on HostB to ensure they are operational with the restored events.
4. **Web UI Activation**: Log into the ArcSight Web UI, navigate to the 'Administration' tab, select 'CORR-Engine Management', then go to 'Archives'. Activate the restored Events archive by selecting it and choosing 'activate'.
5. **Logger Service Start**: Begin the Logger service on HostB if not already running.
6. **Reconfigure SmartConnectors**: Adjust the SmartConnectors to point to HostB, updating their configurations as needed.
7. **Appendix - Test**: Perform a series of tests to ensure that all components are correctly reconfigured and functioning properly. This includes registering ConnectorA with HostA, sending test events for verification, and making necessary adjustments in configuration files and system properties.
8. **Stop/Start Services**: Stop all ArcSight services on the original (now failed) appliance (HostA). Restore the `/opt/manager` folder from HostA to HostB, ensuring that it overwrites any existing content. This mimics the setup of HostA as much as possible. Change ownership recursively to 'arcsight:arcsight' for this restored folder.
9. **Re-start Services**: Restart all ArcSight services on HostB after these changes have been made. You should now see events flowing into the cold standby host (HostB).
By following these detailed steps, you can significantly reduce the risk of event loss and ensure that your system maintains a high level of operational continuity even in the face of hardware or software failures.
The statement "ceive events" appears to be a typographical error or unclear phrasing. However, if we assume the intended meaning is related to receiving or capturing events in a system, the summary could be: To avoid duplicating events and conserve bandwidth or WAN usage, it is important to implement efficient mechanisms for event capture within a system. This typically involves techniques such as deduplication of events to prevent redundant data transmission across a wide area network (WAN).
コメント