Ansible Server Performance Assessment (role)

Understand how well your machine/container/droplet/linode is performing with Ansible.

When you run this on a new host, it will show you the basic performance level and if it meets your expectations.

Keep in mind that this project is focused on immediate needs identified by our operations team, but it should work for many common scenarios. We are open to expanding it with your assistance.

The Motivation

The motivation for this project came from unusual behavior of our cloud machines. To keep the details private, I’ll call our provider “the Sharky”.

The Sharky is good at launching new cloud machines, which we’ll refer to as krill. However, the performance of the krill isn’t clearly documented by the Sharky, particularly regarding IOPS for disks, RAM specifications, or the CPU family of the underlying hypervisors. Often, you might end up with a machine that offers lower performance than expected.

The Sharky focuses on creating many krill rather than ensuring all krill are equal. This means they often pack as many krill as possible onto a single hypervisor until performance drops significantly.

As a user, you expect that what you pay for (hourly) will have the same specifications and capabilities each time you provision a machine. This consistency is crucial for your application and business. Officially, there is little provided by Sharky that assures you otherwise, aside from noting potential volatility in shared CPU resources with certain shared krill types.

Use Case

This role allows for two types of checks:

1. Run it before any actual provisioning to ensure your baseline matches your expectations. If things are way off, consider recreating your krill.
2. Schedule this to run regularly or trigger it during specific events (like app response time drops) to check if your issues come from underperforming infrastructure. This can save you from blaming developers for unoptimized code. Of course, you might still do that anyway, as we believe in the “release early, optimize later” approach.

Basic Plan

The idea is to have a set of checks concerning the machine’s performance using minimal additional software. The final outcome may not be a definitive yes or no, but it should work well as an initial test.

Testing

./bootstrap_testing.sh
source testing_env/bin/activate
read -s PASS && ANSIBLE_BECOME_PASS=$PASS molecule verify -s lxd

The script will pause for you to enter your sudo password. Enter it and hit enter to continue.

Usage

After Cloning from the Git Repository

Add this role to your playbook.yml, and adjust the parameters to your desired baseline performance:

- name: Verify
  hosts: all
  become: true

  roles:
    - role: ansible-server-performance-assessment
      spa_disk_write_MB_per_s_assertion: 300  # Set to your preferred MB/s
      spa_disk_read_MB_per_s_assertion: 300   # Set to your preferred MB/s
      
      # NETWORK BENCHMARK
      spa_speedtest_tmp_file: /tmp/spa_speedtest.out
      spa_downlink_assertion: 100  # Value in Mb/s
      spa_uplink_assertion: 100      # Value in Mb/s
          
      # MEMORY BENCHMARK
      spa_memory_speed_assertion: 10000  # Value in MB/s
        
      # CPU BENCHMARK
      spa_cpu_event_per_second_assertion: 300  # Events per second

  tags:
    - benchmark
    - never

This sample will run only when the parameter --tags=benchmark is added to the Ansible command (to easily merge with existing playbooks).

Limitations

This role may not work well with non-English locales, as some benchmark software relies on specific phrases in their outputs. Improving this would require additional development by someone skilled with awk and regex.