Prerequisites to Install a DR Solution

Before installing the DR solution, make sure the environment meets all the prerequisites shown in the following table.

LogRhythm SIEM

The LogRhythm SIEM must be deployed on both the Primary and Secondary sites using the same LogRhythm software version.

The Enable Password Policy option must be disabled on the LogRhythm SIEM user account or the SA and LRMirror_Login passwords will not synchronize between nodes. If Enable Password Policy is enforced, the passwords must be changed manually on the Secondary Node whenever they are changed on the primary. The Enable Password Policy option can be disabled by modifying the user account login on the People tab in the LogRhythm SIEM.

Operating System

LogRhythm Disaster Recovery is supported on Microsoft Windows Server 2012R2, 2016, 2019, and 2022. Primary and Secondary nodes in a Disaster Recovery pair must be patched to matching Operating System and .NET Patch levels prior to starting Disaster Recovery Installation. Mixing of Operating System versions within a Disaster Recovery pair is only supported as a function of inline OS Upgrades, as seen here. New installations of Disaster Recovery require both Primary and Secondary nodes in a Disaster Recovery pair to have matching OS Versions.

Hardware/Virtual Support

LogRhythm Disaster Recovery is supported in Physical, Virtual and on most public cloud provider virtualization platforms. Nodes in a Disaster Recovery pair should adhere to the following rules;

Nodes should be near-match in CPU and Memory resource allocations but do not have to be exact
Nodes should have matching drive letter layouts with SQL DBs/Logs in identical paths on both systems
Primary and Secondary Node storage amounts can be mis-matched but the environment will be limited to the amount of storage on the smallest node in the pair. (ex. PM1 has 10TB, PM2 has 2TB, the maximum size the DBs can be expanded to would be 2TB)
Storage types within the pair must match, if using SSD both nodes should use SSD. Avoid mixing HDD and SSD within the same pair
Clustering Physical and Virtual nodes together is supported assuming all other requirements are met
Clustering on-premise Physical/Virtual nodes with cloud hosted nodes (AWS/GCP/Azure/etc.) is supported assuming all other requirements are met

Service Account and Windows Domain Requirements

Configure the SQL Server, SQL Server Agent, and LogRhythm Service Registry services to run under the same Windows Domain Service Account on both the Primary and Secondary sites. This should be a named, privileged account with local admin rights on both the Primary and Secondary servers in the DR pair. This must be a domain account in the same domain on both systems.

Following Disaster Recovery Installation the SQL SPNs must be re-registered to the domain. This SPN registration requires a Domain Admin account, if you are using a Domain Admin account for the SQL Server Service Account this will register itself, if not you will need access to a domain account account and to run the Kerberos Configuration Manager for SQL Server following the Disaster Recovery installation. For more information and access to the Microsoft Kerberos Configuration Manager for SQL Server see this page. SPN registration must take place prior to a Disaster Recovery failover test and is required for Kerberos authentication to work into the LogRhythm application.

A LogRhythm Disaster Recovery cluster can only be created between member nodes joined to the same domain. Attempting to deploy LogRhythm Disaster Recovery between servers on separate domains using this guide will result in failure. If this configuration is a requirement on your deployment, contact LogRhythm Customer Support.

Network recommendations

Configure the network so that:

Each node should have 1 NIC connected to the network for normal data/management access with a static IP address which is always accessible
Each node will require an additional "secondary" IP address on the data/management NIC that will be used as the Failover Cluster IP. This should be in the same subnet as the static IP used to access the server but will not always be online.
A dedicated network interface port is recommended for data replication if the nodes are in the same site or replication traffic traverses over a dedicated circuit. If replication traffic routes over a shared link between the sites there is no benefit to configuring a dedicated data replication NIC as it introduces complexity with the routing table having multiple gateways and requiring the configuration of persistent routes.
If dedicated replication interfaces are used Static IP addresses are configured on the interfaces and need to be routable to each other, but they do not need to be on the same subnet.
Minimum bandwidth of 10 Mb/sec and a maximum latency of 100ms between the primary and secondary sites for small deployments. Larger LogRhythm deployments recommend 1Gb/s or higher, limitations in network throughput can cause outages.
Failover Cluster IP addresses should be presented on a NIC that has access to Active Directory. You must register this connection’s address in DNS (the NIC presenting the Failover cluster IP address).

To create a Failover Cluster, a Failover Cluster IP address is required on each node participating in the cluster. This IP is used for cluster creation, Failover Clustering node communication, and to determine which DR node in the cluster is online at any given time. Failover IP addresses should be unused IP addresses on the same network as the management NICs.

In a multi-subnet scenario, two distinct, unused IP addresses are needed in DR Setup, one in each respective subnet.
In a single-subnet DR scenario, only one unused IP address is needed for the Failover IP — it will be the same for Primary and Secondary.

The Failover Cluster IPs should be on the network adapter that has access to Active Directory in order to update the accompanying Cluster DNS record. The Failover Cluster IP address is a virtualized IP address that the underlying Windows Server Failover Cluster will use for facilitating cluster communications. This appears to the user as a "secondary" IP address and will only be active on 1 node at a time.

Ports/Firewall

Ensure that the following ports sites are open — not blocked by a firewall — at both sites. The DR setup automatically opens ports secured by Windows Firewall but not by other types of firewalls.

If network firewalls or Group Policy settings prevent this communication, the DR installation will fail. During installation, the DR setup tool configures these ports to only allow system to system communication.

Ports	Protocol	Application
135	TCP	RPC
137	UDP	Cluster Administrator
445	TCP	Windows Host (Windows Event Logs)
3343	TCP	Cluster Service
3343	UDP	Cluster Service
1024-65535	UDP	Ephemeral Ports
49152-65535	TCP	Ephemeral Ports
1433	TCP	MS SQL
5022 (default)	TCP	SQL Replication
Echo Request	ICMP	DR Installation
Echo Reply	ICMP	DR Installation

For additional information on the ports used by LogRhythm, see the Networking and Communication topic in the SIEM Help. Failing to open all ports will result in installation failure.

Domain Name Server (DNS) requirements

In this LogRhythm release, DR installations require the Platform Manager to be bound to an Active Directory domain and a Microsoft DNS server must be in the same Active Directory domain as the PM. The Platform Managers must have DNS entries for each server participating in the DR installation, and accompanying forward and reverse records should be in place.

A new DNS record named LogRhythmDR will be created during Failover Cluster formation. This record can automatically be updated during a failover event with the Failover IP address of the Active node in the cluster. To enable this functionality, the DNS zone hosting the LogRhythmDR record must be configured to allow secure updates from clients and the Machine Account "$servername" for the primary and secondary nodes must be given Full Control permissions on the DNS record.

In order for automatic updates to the Cluster DNS record to function, the network interface hosting the Failover Cluster IP must have the “Register this connection’s address in DNS” feature enabled.

If needed, manual configuration is still supported:

A common DNS record is configured so it can point to either the IP address of the Primary Platform Manager or the IP address of the Secondary Platform Manager.
The Data Indexers and AI Engines point to the Platform Manager using a DNS name rather than an IP address. The Data Indexers and AI Engines can optionally have a shared name, but it is not necessary.
DNS Zones should span the Primary and Secondary sites.
DNS Address records should be configured with a time to live (TTL) of two minutes so that failover occurs relatively quickly.

Disk space requirements on Platform Managers

During the DR setup, you must back up the Primary Platform Manager’s databases and copy them to the Secondary system. The DR installation program will check your database sizes and give you an estimate for the disk space requirements. You can also use a network drive for the backup, provided that the SQL Agent service account has write access to the share.

The database backup may take hours to complete, depending on the data size and the write-speed of the backup media. If there is enough available storage on the local disks for the backup its recommended you backup to the local disks.

Infrastructure Installer

During installation with the Install Wizard, the LogRhythm Deployment Tool needs to be configured as New Multi-Host Deployment, and the generated deployment package executed on the secondary node.

Data Processors, Data Indexers, the LogRhythm Configuration Manager, and AI Engines

These systems point to the Platform Manager using a DNS name rather than an IP address. Remote components should also support DNS for connecting to either a Primary or Secondary site.

Infoblox DNS for LogRhythm Disaster Recovery

This prerequisite is only for customers who use Infoblox DNS.

Infoblox requires configuration to allow updates from the domain controller to register and update DNS records used in the LogRhythm Disaster Recovery solution. This section describes the Infoblox configurations needed for dynamic DNS updates.

Infoblox DNS must have a zone for the domain on which the DR servers are located. This is typically present if Active Directory is being resolved through Infoblox. If not, a new zone must be created for the domain.
The zone must allow queries from the DR servers. In the settings of the zone, select the Queries tab and verify queries are allowed. By default, queries are allowed from “Any”, but this also works if the DR servers are included in a Named ACL or set of ACEs.
The zone must allow updates from the DR servers as well as from the Domain Controller. This is configured in the same way as the query permissions.
For InfoBlox DNS servers with no GSS-TSIG members or configuration, the zone must “Allow unsigned updates from these Domain Controllers”. This is configured within the Active Directory tab of the zone settings, where the IP of the Domain Controller can be added.
If a shared DNS record already exists for DR (“logrhythmdr”, by default), it must be available for updates and be set to a “dynamic record”. To do this, locate the A record for LogRhythm DR within the Domain’s zone. Edit the record’s settings and select the Updates tab. Set the Record Source to Dynamic and clear the Protected checkbox. Leave the Principal field blank.