Cut RHEL Patch Times Up to 36% with Smart Ansible Tuning

Authors:
Lori Meyer, Cloud Systems Administrator (Linux), apiphani
Victor Forsythe, Senior Systems Developer, apiphani

For organizations running Red Hat Enterprise Linux (RHEL), regular patching cycles—monthly or quarterly—are essential for maintaining security, performance, and compliance. 

In large-scale environments, however, this routine task can escalate into a serious operational challenge. At scale (100+ servers), a single patching window can stretch beyond 6 hours, especially when kernel upgrades, STIG hardening, and point-in-time data collection are involved. 

These extended maintenance windows can introduce tool-availability issues and even trigger downtime, potentially affecting business continuity. Minimize or avoid these challenges with smart tuning of Ansible – our open-source automation tool of choice.

The Objective: Fast, Scalable, and Secure Patching

Meeting SLAs across a diverse infrastructure, while minimizing downtime, requires a smarter approach to orchestration. We implemented targeted Ansible performance parameters to streamline operations without compromising control or security.

The results were compelling: A 20–36% reduction in patch duration across customer environments.

Key Ansible Tuning Parameters and Their Impact

These are the specific configurations we adopted, including performance insights from real-world use.

1. strategy = free

What it does: Enables hosts to execute tasks independently rather than synchronizing, step-by-step, across all nodes.

Why it matters: Slower hosts won’t impede or hold back faster ones. This asynchronous execution shortens overall job duration in mixed-performance environments.

2. pipelining = true

What it does: Consolidates SSH operations to reduce connection overhead.

Why it matters: Reuses existing SSH sessions instead of opening new ones for each task, saving time and resources.

Important: Ensure that /etc/sudoers does not include requiretty; otherwise, pipelining will fail. Note that some enterprise environments may restrict pipelining due to security policies.

3. ansible_ssh_common_args = ‘-o ServerAliveInterval=60 -o ServerAliveCountMax=10’

What it does: Maintains SSH session persistence during long or idle operations.

Why it matters: Helps maintain stable connections during long-running tasks—such as kernel upgrades or log collection—particularly in high-latency or low-activity environments.

• ServerAliveInterval=60: Sends a keep-alive every 60 seconds
• ServerAliveCountMax=10: Drops the connection after 10 failed attempts (i.e., ~10 minutes)

4. ansible_forks = 20

What it does: Sets the number of parallel worker processes that Ansible uses to execute tasks.

Why it matters: Dramatically accelerates throughput in large environments because more forks equal more tasks running concurrently. 

Tuning Tip: Start with 10 –20 forks. Scale based on your control node’s CPU and RAM. Over-provisioning may degrade performance on under-powered systems.

5. ansible_ssh_args = ‘-o ControlMaster=auto -o ControlPersist=60s’

What it does: Enables SSH multiplexing to reuse a single connection for multiple tasks.

Why it matters: Reduces the cost of repeatedly opening and closing SSH sessions, which is especially beneficial for task-heavy playbooks targeting the same hosts.

• ControlPersist=60s: Keeps connections alive for reuse within a 60-second window
• Configurable: For playbooks with longer gaps between tasks, consider increasing to 120 – 300 seconds.

Key Results

After optimizing these Ansible parameters, our clients experienced the following benefits:

• 20–36% reduction in patching duration
• Fewer service interruptions during maintenance windows
• No SSH timeouts during long-running tasks
• More predictable and reliable compliance processes

Final Thoughts

Automation is powerful, but only when properly tuned to fit your scale and operational needs. These simple Ansible optimizations deliver measurable value in mission-critical RHEL environments.

If you are wrestling with long patch windows or irregular automation behavior, implement these tuning parameters. Your servers – and your SLAs – will thank you.

About The Authors

Lori Meyer is a Cloud Systems Administrator at apiphani and a military veteran. Her 10 years of IT experience include roles at Intel and VMware, as well as multiple certifications in AI, Cloud Computing, Cloud-Native Linux Administration, ITIL, Security, and SysOps.

Victor Forsythe is a Senior Systems Developer at apiphani. He is a certified AWS Solution Architect and Linux Foundation Certified SysAdmin. He is known for his deep experience in Linux, cloud infrastructure (AWS), automation (Ansible), Bash, Docker, and Git.