Edelweiss - Fotolia
Maximize Ansible scalability, performance as IT deployments grow
There are several options to increase Ansible performance at scale -- a task that should move to the top of the to-do list as an IT deployment grows.
Ansible checks IT configurations, and remediates them as necessary, to enforce consistency. Organizations that run deployment steps through Ansible simplify administrative tasks and reduce the risk of configuration drift.
However, as IT environments scale, configuration tasks involve more connections and consume more resources. This growth can cause configuration management operations to slow down, which results in a domino effect across the environment and creates infrastructure scalability issues.
IT teams can mitigate these issues and ensure Ansible scalability and performance through several means: split up jobs, adjust default settings and partake in other practices. However, depending on which version of Ansible is in use, some of the actions discussed below might not work, so verify them against your version and options.
Set up the IT environment
A lag in infrastructure scaling can be due to a number of factors, including overloaded servers and file locations.
Appropriately split up Ansible jobs across servers to reduce the time necessary to complete tasks. Some companies split production and user acceptance testing environments, for example, to lessen the load on each portion of the IT environment's infrastructure. Ansible clusters also provide some redundancy and can schedule jobs more effectively than a single host -- although this task requires a subscription to Ansible Tower.
File location is another significant consideration for Ansible scalability and performance. The farther files reside from the managed hosts, the longer it takes Ansible to pull or push data across a network. As Ansible waits for data to be dragged across the network, significant delays and subpar performance can occur, and the issue scales with the size of the deployment. To avoid this latency, create local caches for files to decrease both the distance between files and managed hosts, as well as the time it takes to move data between them.
Adjust Ansible settings
To further ensure scalability, pair infrastructure configurations with features such as tags, and consider tweaks to Ansible's default settings.
Tags, which enable a system to run specific parts of a playbook, can provide ease of use for administrators building deployment configurations. As they modularize playbooks, tags can also boost Ansible scalability and performance.
Additionally, the Ansible pipelining system streamlines module execution on a server. Pipelining minimizes the number of Secure Socket Shell (SSH) operations and file transfers, which, in turn, reduces network connectivity demands and data pulling. To make use of it, users must disable requiretty for sudo operations on managed hosts. Add the following line to the ansible.cfg file to enable pipelining:
[ssh_connection]
Pipelining = True
By default, pipelining is disabled, as it requires some systems configuration. Also, create a backup of config files, if possible, for safety as you make changes.
The forks parameter is another default setting. This feature controls the number of simultaneous actions, or processes, that Ansible can use concurrently. Ansible's default setting limits the system to five simultaneous actions, but on high-performance hardware, this is equivalent to kneecapping the system in terms of execution capacity. Adjust the forks parameter's limit to be commensurate with the given hardware's capabilities.
Optimize configurations
An additional path to smoother scaling lies in playbooks, as well as a base deployment image.
The Ansible playbook can become a bottleneck at scale. Optimize playbooks with strategy plugins, which manage task and host scheduling to control the flow of play execution. This feature groups and executes commands more efficiently than the default approach in which tasks occur in a linear model.
An often-neglected step to improve Ansible scalability is to include as many items as possible in the base deployment image. This approach means fewer changes to implement or pull from Ansible for configuration updates.
Also, the less work done on each host, the more capacity is available in Ansible to configure other hosts. There is overhead to keep images up to date, but there's always a balancing act involved to maximize resource use. In all cases, it is better to break up processes and elements into smaller pieces.
Approach Ansible scalability one step at a time
Don't blindly apply all these settings at once. Take time, and research and implement changes sparingly -- only as needed. Smaller IT environments will not see as much improvement in Ansible performance as organizations that operate configuration management at a larger scale.
