Exadata: Guide to Testing Compatibility of Third-Party Security Agents on Exadata

Introduction

Oracle Database is the world's leading converged, multi-model database management system, with its performance, scalability, and reliability significantly enhanced by Exadata. Exadata is an engineered system, preassembled and pre-integrated to reduce complexity and speed up application deployment. Due to its performance and reliability, Exadata is the platform many organizations choose for their most critical workloads. This often involves sensitive data that must be protected according to organizational standards.

Exadata’s shared responsibility model, both on-premises and in the cloud, grants customers privileged access (e.g., root, SYS) to the VMs and databases. Customers can use these credentials to secure the VM and database, addressing local policy and regulatory requirements. This includes installing agents, forwarding operating system and database audit logs to customer Security Information and Event Management (SIEM) systems, and controlling access and identity management for VMs and databases via tools compatible with the Exadata Compute VM operating system and Oracle Database.

Third-party security agents, referred to as security agents from here on, can have a significant impact on Exadata operations. Most of these security agents run at the root level on the Linux operating system, the highest privilege level, allowing them to see all processes running on the OS, including those used by Exadata and the database. Beyond viewing processes, more advanced security agents use pattern analysis to detect malicious activities like ransomware and stop them from occurring or spreading. While effective for end-user devices and general-purpose servers, this can sometimes negatively impact engineered systems like Exadata. These impacts can include performance degradation, kernel panics, file locks, interrupting Exadata upgrades, and blocking ksplice from applying kernel patches.

Targeted testing is essential when implementing any security agent that installs proprietary and/or externally built kernel modules or runs as root. Additionally, runbooks should be created to understand how to disable any third-party agents on Exadata during maintenance activities.

Testing Approaches

Real-World Workload Replication

Custom scripts that replicate the actual workloads encountered by the database can be used to accurately represent how the database would perform in a real-world scenario. This involves reproducing the query patterns, data access patterns, and concurrency levels seen in production environments.

Oracle provides a way to do this with Oracle Real Application Testing (RAT). Oracle RAT helps you thoroughly assess the effect of a security agent on a real-world application in a test environment before deploying the change in production. To test your workload, you first use RAT to capture the workload. During this process, all external client requests are directed to the Oracle server and stored in compact “capture” files on the database host file system with minimal overhead. These “capture” files can then be replayed on a test system running the security agent.

Benchmarking

Benchmarks can be used to measure the performance of specific database operations or features. These benchmarks consist of predefined queries or workloads that mimic typical database activities. Examples include OLTP (Online Transaction Processing) benchmarks like TPC-C and OLAP (Online Analytical Processing) benchmarks for decision support, like TPC-DS.

Various benchmarking tools are available to help measure database performance. These tools generate load and measure response time, CPU utilization, throughput, and I/O performance. Some benchmarking tools include HammerDB, Swingbench, and Benchmark Factory® for Databases.

Select the benchmarks that closely match your workloads running on Exadata, run those benchmarks without the agent, and then again with the agent installed to evaluate the differences. This will allow you to assess the impact the agent may have.

Conclusion

This guide provides a high-level overview for your organization to assess the impact a third-party agent may have on your Exadata environment. Third-party agent vendors can also follow this approach to determine if their agent will function on Exadata. With Oracle Cloud Infrastructure offering Exadata, this process is easier than ever.

Finally, while installing third-party agents is allowed, Oracle will not provide technical support for non-Oracle software. This includes installation, testing, certification, and error resolution. The supplier of the custom/third-party software is responsible for any technical support for it. Oracle recommends that all non-Oracle software be tested, validated, and certified by the vendor for use in an Oracle Linux and/or Exadata environment, and that thorough testing is performed in the target environment by the customer

Tags: Exadata
Previous Post Next post
article