Review the Requirements for a New LogRhythm Deployment

LogRhythm Licensing

The LogRhythm Solution requires a LogRhythm license file which contains a LogRhythm Master License and Component Licenses. The Master License is tied to an individual customer for a single deployment of LogRhythm (1 Platform Manager and 1 or more Data Processors). Component Licenses fall within the Master License and are used to license specific LogRhythm components within the same LogRhythm deployment.

A LogRhythm license file can contain the following component and subscription licenses:

• Platform Manager License (always included)
• Data Processor License(s)
  • Software License
  • Appliance License
• Log Message Source License(s)
  • Quantity License
  • Unlimited License
• System Monitor Lite License
• System Monitor Pro License
• System Monitor Collector license
• Advanced Intelligence Engine License (separate volume license)
• GeoIP Resolution Subscription License

To learn more about LogRhythm Licensing, see the Licensing topic in the Enterprise SIEM Help. The LogRhythm End User Licensing Agreement (EULA) contains specific details regarding licensing and is the legal agreement for the solution you purchased.

SQL Server Licensing

LogRhythm Appliances include a SQL Server license, whereas with LogRhythm Software purchases, the SQL license is optional. The LogRhythm Appliances are licensed for one (1) SQL Server instance and five (5) Client Access Licenses (CALs); should you require additional users, a CAL is required for every LogRhythm user, as outlined in the SQL Server End User License Agreement (EULA). To understand how many CALs you have purchased or to purchase additional CALs, contact LogRhythm Support or your sales representative. The SQL Server EULA contains specific details regarding licensing and the legal agreement between you and Microsoft. It serves as your proof of purchase.

LogRhythm Component Compatibility

All LogRhythm components in a deployment, except for System Monitor, must be versioned with the same major and minor number. System Monitor versions 6.x and 7.x are supported.

Database and SQL Server Versions

This LogRhythm version requires Microsoft SQL Server 2016 Standard SP1 (version 13.0.4001.0) or Microsoft SQL Server 2019 (version 15.0.2000.5). Higher cumulative updates and service packs within these versions are also supported. In this LogRhythm 7.x release, the schema version of all LogRhythm SQL databases is the same: 7.x.x.yyyy.

LogRhythm 7.9.0 introduced support for SQL Server 2019 on standard deployments. If you are running Microsoft SQL Server 2016 Standard on your appliance, there is no need to upgrade to Microsoft SQL Server 2019. If you want to upgrade to SQL Server 2019, see Upgrade SQL Server 2016 to SQL Server 2019.

Upgrades to existing High Availability (HA) and Disaster Recovery (DR) environments are not supported. The current version of LogRhythm SIEM supports SQL Server 2019 on new installations of HA and DR deployments only. 

System Monitor Component Support

Earlier versions of System Monitor are compatible with this version of LogRhythm. The table below lists the System Monitor versions that are compatible with LogRhythm 7.x.

Component Operating System Support

This section describes operating systems and LogRhythm component compatibility for the current version of LogRhythm SIEM. The following table defines the LogRhythm support levels used in subsequent tables.

LogRhythm 7.9.0 introduced support for Windows Server 2019 on standard deployments. If you are running Windows Server 2016 on your appliance, there is no need to upgrade to Windows Server 2019. For a guide on upgrading to Windows Server 2019, see Upgrade Windows Server 2016 to Windows Server 2019.

Upgrades to existing High Availability (HA) and Disaster Recovery (DR) environments are not supported. The current version of LogRhythm SIEM supports Windows Server 2019 on new installations of HA and DR deployments only.

The following table shows the support levels for LogRhythm components on various 64-bit operating systems. 

Any operating system not included in the following table is not supported.

¹ _{The Data Indexer is only supported on Windows operating systems for XMs and Gen3 appliances.}

Platform Requirements

Server Roles

Different LogRhythm server roles perform key tasks for log collection, analysis, and reporting in the LogRhythm SIEM. When you install LogRhythm on your own systems, you need the following server roles:

• Platform Manager. The Platform Manager provides the central event management and administration of the LogRhythm SIEM, including:
  • Configuration information for all agents, log sources, and log source types.
  • Knowledge Base, which includes all processing rules, built-in reports (for compliance), built-in alarms, and other processing-related information.
  • The Alarming and Response Manager, which is a Windows service responsible for processing alarm rules and taking appropriate response such as sending e-mails to those on a notification list or sending SNMP traps to an SNMP server.
  • The Job Manager, which is responsible for scheduled report job generation, Agent and Data Processor heartbeat monitoring, Active Directory synchronization, and health monitoring.
  You can install the Platform Manager on a dedicated appliance (recommended for large environments) or on the same system as the Data Processor and Data Indexer (called an XM appliance, if you need an all-in-one appliance). The Platform Manager also includes an embedded AI Engine license, which allows you to install AIE on the same system. There is only one Platform Manager in the SIEM environment.
• Data Processor. The Data Processor provides high-performance, distributed, and highly available processing of machine and forensic data. Data Processors receive machine and forensic data from Collectors and Forensic Sensors. The Data Processor archives data and distributes both the original copy and the structured copy to other LogRhythm components for indexing, machine based analytics, and alarming.
• Data Indexer. The Data Indexer provides high-performance, distributed, and highly scalable indexing and searching of machine and forensic data. Data Indexers store both the original and structured copies of data to enable search-based analytics. The Data Indexer can be installed in an XM configuration on Windows, or as a dedicated instance using Red Hat Enterprise Linux 9, or Rocky 9.x Minimal. We distribute a custom built Rocky 9.x ISO image which handles all OS install pre-requisites.
• AI Engine. The AI Engine is an optional component that detects conditions occurring over multiple data sources and time ranges. It provides real-time visibility into risks, threats, and critical operations issues. AI Engine includes more than 100 preconfigured rule sets that you can use in the wizard-based, drag-and-drop interface. You can install the AI Engine on the same system as the Platform Manager or you can install it on a dedicated system.

• Data Collector/System Monitor. The System Monitor Agent collects log, flow, and machine data, then flushes that data to the Data Processor. The System Monitor software can be installed on a shared system for local log collection or on a dedicated system for local and remote log collection (aka Data Collector). Dedicated Data Collector performance can vary significantly based on environmental conditions such as network speed/latency and which log source types are collected. LogRhythm provides minimum specs to be used for local log collection or in low volume environments and recommended specs when deploying as a dedicated Data Collector. When deploying a dedicated Data Collector, it is recommended to use the Windows version as it is most feature-rich and offers the greatest performance. 

• SecondLook Service. The SecondLook API Service was introduced in LogRhythm 7.13 and provides a mechanism for Secondlook Restorations to be processed on a dedicated machine. This presents an API function that will retrieve Inactive Archives, process them, and restore them into the Data Indexer. Secondlook API requests are made through the Web Console UI and results can be searched from either the Client Console or the Web Console.  

Volume/Disk Configurations

LogRhythm requires specific volume/disk configurations, which can consist of physical disks or virtual disks with logical volumes.

LogRhythm is not supported on systems that use shared disks. Installing on a system that uses shared disks can have a significant negative impact on performance.

• Physical Disks. One or more physical disks must exist on the dedicated hardware or virtual machine within a specific volume.
• Virtual Disks (usable space). Virtual disks are a collection of physical disks that deliver redundancy and performance improvements through hardware RAID technology. 
• Logical Volumes. A logical volume is a partition of a virtual disk addressed with a unique drive letter in Windows (for example, drive C or drive D). The logical volumes contain specific files and data related to the installation (see the following table for more information about the contents of each drive). Any LogRhythm server that contains a Platform Manager includes four logical volumes. The Windows Indexer should include at least two logical volumes, and the logical volume that contains log data should be on a dedicated virtual disk using dedicated physical disks.

You should configure and use the logical volumes as documented.

Performance Requirements

The specifications provided are minimum requirements for your dedicated virtual machine and dedicated hardware. Your system should be configured so that the end result has the minimum specification requirement value or greater. If your hardware or virtual machine does not fit into an existing appliance configuration, contact LogRhythm Professional Services to discuss a possible custom installation. Collection rates are listed as a guideline. The rates may vary given different hardware configurations and log types.

The performance specifications are based on the following assumptions:

• 100% of logs are from Syslog
• Average raw log message size = 400 Bytes
• Average online log row size (includes index) = 900 Bytes
• Average online event row size (includes index) = 1,035 Bytes
• Average archive entry size = 400 Bytes
• Average archive compression rate = 20:1
• 100% of logs are Indexed and Archived
• <2% of logs processed by the deployment that are considered an Event (data of interest)
• Logmart Disabled

Additional notes regarding performance specifications:

• Virtual Machines. Deploying on virtual machines incurs overhead and be subject to noisy neighbors. As a result, your actual performance will vary. A performance degradation is expected when compared to running on a dedicated physical machine.
• Dedicated drives. LogRhythm is an I/O-intensive solution that requires dedicated physical drives to achieve the published rates specified. LogRhythm makes no distinction between Direct Attached Storage (DAS) or Storage Area Network (SAN), but the disk volumes must be dedicated.

Power Supply/Mode

LogRhythm recommends that all LogRhythm systems be connected to an uninterruptible power supply. A power cut may cause an Elasticsearch failure that leads to a loss of indices.

All systems hosting LogRhythm Services (Virtual or Physical) must have their power mode configured for "High-Performance", this disables power saving features in order to ensure optimal CPU ready states. Negative performance impacts will be observed in a power-save mode profile. 

For example, for HP ProLiant servers:
1. Set the Power Regulator Mode to Static High Mode.
2. Disable Processor C-State Support.
3. Disable Processor C1E Support.
4. Disable QPI Power Management.
5. Enable Intel Turbo Boost.

For Dell PowerEdge servers:
1. Set the Power Management Mode to Maximum Performance.
2. Set the CPU Power and Performance Management Mode to Maximum Performance.
3. Processor Settings: set Turbo Mode to enabled.
4. Processor Settings: set C States to disabled.

Web Console Requirements

You can install the Web Console software on a server, virtual server, or LogRhythm appliance that meets the requirements listed at LogRhythm Reference Architecture.

LogRhythm currently supports up to three Web Console instances with 30 concurrent users per instance, 60 concurrent users in total

Virtualization Platform Considerations

The LogRhythm software can be deployed on physical, virtual or cloud environments. The LogRhythm Appliance Platforms are validated and tested using known resource quantities at specific log processing and indexing rates. When deploying LogRhythm on virtualized or cloud environments, it is important to adhere to performance best practices for the selected hypervisor for highly resource intensive workloads. 

• Data Collectors. Receive, collect and forward log data. Operating under a light footprint make these systems good candidates for virtualization.
• Data Processors. Handle processing, data enrichment, and data distribution to the other LogRhythm components. These systems rely heavily on CPU and Memory resources while also needing access to large disks for Inactive Archives.

• Data Indexers. Indexing and search of log data through Elasticsearch. These systems can be run in a clustered configuration with resource utilization focused on CPU and disk I/O.

  

  New installations of the Data Indexer on Windows are only supported in an XM configuration.
• Platform Manager. Centralized configuration management, knowledge base data, alarming and reporting, runs on a SQL backend. Standalone Platform Managers focus on memory and disk I/O utilization. In smaller environments, however, AIE and Web Console may be run on these systems, increasing the resource requirements
• AIE. Advanced real-time correlation engine requires CPU and memory resources for long term trend analysis.
• Web Console. User-friendly Web interface to the threat lifecycle, requires mostly CPU and memory resources.

Planning system resources for each of these components will depend on the data volume and use-cases for each component. LogRhythm Appliance Platforms provide known performance and resource allocations, allowing customers to scale using known quantities. In many cases, a customer will elect to split up LogRhythm roles onto their own individual systems rather than running a single, very large instance (XM).

Please refer to VMware Best Practices for Performance Tuning of Latency-Sensitive Workloads for best practices that should be followed if LogRhythm is hosted on a vSphere hypervisor

Please refer to Microsoft Performance Tuning for Hyper-V Servers if you are using Microsoft Hyper-V

Virtualization Resource Requirements

LogRhythm performs testing and validation of all components using physical hardware. However, the entire LogRhythm ecosystem can be run virtually or in the cloud when provided with adequate resourcing.

• CPU. When planning CPU resources in a shared environment, you must consider context switching and wait-times associated with CPU core availability through the hypervisor. For this reason, LogRhythm recommends using vCPU reservations through the hypervisor to ensure appliance specification rates can be met.
  • Considerations should be made when hyperthreading is being used — LogRhythm vCPU counts assume hyperthreaded cores.
  • CPU Ready time is a metric that records the amount of time a virtual machine is ready to use CPU but was unable to schedule time because all CPU resources are busy. It is important to observe percentage of CPU ready time on each hypervisor when under peak load. A value more than 10% of CPU ready time is an indication of vCPU oversubscription on the hypervisor which will negatively impact LogRhythm performance.
  • Reference Architecture vCPU accounts assume a minimum Ghz value. In some cases, a lower Ghz value may be acceptable if the core count is increased; however, lower frequency CPUs can directly impact performance of the application and should not be used (AI Engine and Data Processor are impacted the most by lower frequency CPUs).
  • vCPU allocation counts and speed are relative to the achieved performance of the platform. This does not directly linearly scale but is relative which should allow customers to reduce vCPU counts if the maximum performance requirement is below the stated appliance spec. 
  • Modern CPUs using combinations of P-Cores and E-Cores are supported, the Ghz values in the Reference Architecture should be aligned to base E-Core frequencies. Its strongly recommended P-Cores be enabled with maximum performance settings 
• Memory. Memory management within virtualized environments should always provide enough memory for all guests on the hypervisor with overhead available for the hypervisor itself. Overcommitting memory will result in poor performance and stability issues within the LogRhythm ecosystem. For LogRhythm Appliances requiring large memory footprints, non-uniform memory access (NUMA) boundaries should be considered. Guests should not be allocated CPU or memory resources beyond that which can be provided within a single NUMA boundary.
• Disk Performance Profiles. Defined on a per-virtual disk basis these performance profiles should be followed to achieve stated performance metrics for each disk within the virtual machine 
  • SSD - All disks serving this virtual disk must be flash/SSD based to achieve required performance for the application.
    • Minimum IOPS 10k/s Total assuming 50/50 R/W 64k Block Size
    • Minimum Throughput 10Gb/s
  • HDD/SSD - These disks can be served by High Performance HDD (10k+ RPM) or SSD
    • Minimum IOPS 1000/s Total assuming 50/50 R/W 64k Block Size
    • Minimum Throughput 1Gb/s
  • HDD - These disks have a low performance profile and store data which is rarely accessed, these would typically be served by Low Performance HDD (7200RPM)
    • Minimum IOPS 250/s Total assuming 50/50 R/W 64k Block Size
    • Minimum Throughput 500Mb/s
• Disk Volumes. Data Indexers and Platform Managers rely heavily on disk size, IOPS, random seek, and overall capacity.
  • The Data Indexer will use all disk resources available to the system and it requires a high baseline of resources based on the Appliance Platform. For this reason, LogRhythm requires dedicated disk resources be committed to the system.
  • Shared storage removes any benefit associated with Data Indexer clustering since all systems in the cluster participate in searching and indexing of data — the use of shared disks is not supported.
  • Many flash-optimized storage solutions provide IOPS rates based on optimized data, which is usually a small subset of the data on the SAN/blended storage. For this reason, it is recommended to use IOPS calculations for the disks where LogRhythm data stores exist, not the small flash-optimized data. This is particularly true of Data Indexers because data used for searching will most certainly exceed the flash optimized storage tier.
  • All Flash storage is recommended for any virtualization environment - see Disk Performance Profiles.
  • Each LogRhythm logical volume should be provisioned on its own logical unit number (LUN) and not shared with other virtual infrastructure or other LogRhythm components.
  • Storage Connectivity and Response Times should realize an average latency of 10ms or less. Higher latencies can cause unpredictable behavior, particularly with the Platform Manager and Data Indexer.
  • Use of built-in SAN storage compression and/or de-duplication is not recommended, LogRhythm has built-in compression within the application and any further compression applied will negatively impact performance.
• Networking. Communication between LogRhythm Core Components requires low latency and line-speed 1Gb/s links, at a minimum.
  • DX7500/7600 and DXW5120/6160 require 10Gb/s links to achieve full performance
  • PM7500/7600 and XM8500/6600 require 10Gb/s links when used in an HA configuration

Virtualization Deployment Best Practices

The following best practices will allow LogRhythm to make the most of the resources available in a virtualized environment. Note, however, that the performance and stability of the system relies 100% on the quality of the underlying hardware.

Virtual Host (Hypervisor) Requirements

• Intel or AMD server class x86-64-bit chip architecture with hyperthreading.
• Dedicated disk volumes following Disk Performance Profile specifications of the appliance platform.
• Disk Performance Profiles should be compared using disks that store LogRhythm data and using nonoptimized random seek — automated storage tiering solutions are strongly discouraged.

Virtual Machine System Requirements

Full reservations for vCPU and vMemory with no CPU or memory over-commitment on the physical hosts.

• Where applicable, install hypervisor integration services/tools on platform guest VMs (PM, DP, AIE, DX, DC, etc.).
• Where applicable, enhanced network controllers should be used.
• Provision virtual disks as Eager Zero Thick where applicable.
• Avoid NFS disks due to higher latency, network variations, and file locking issues.

Virtualization Redundancy and High Availability

There are a number of solutions native to hypervisors that are designed to provide high availability and dynamic resource migrations. While these solutions are not formally tested with the LogRhythm ecosystem, users should be aware of the additional overhead associated with these servers and the impact that they could have on LogRhythm

Virtualization Snapshots and Backups

LogRhythm provides native backup mechanisms for SQL databases on the PM and archives. When combined, these two can be used to restore a LogRhythm deployment back to 100% functionality and historical data. For this reason, and due to the disk I/O penalties associated with snapshots, customers are strongly discouraged from taking snapshots of their LogRhythm systems in a virtual environment. If needed, OS-level backups can be done using 3rd party software, but is not required for LogRhythm system restoration.

Networking and Communication

There are a large number of ports that need to be open for the different LogRhythm components to communicate. For more information, see the Networking and Communication topic in the Enterprise SIEM Help.