High CPU when running playbook to disable virtual servers

[Sharon Day]

I recently run an Ansible playbook to disable several virtual servers on the LTM F5.  I noticed that when I was running the playbook CPU on the F5 was up to about 97% while the playbook was running and it made the GUI interface almost unusable.  Any suggestions on how to make this run more efficiently?  Also, if I have a list of 25 VIPs is the Ansible host logging into the F5 25 times to make the change or is it logging in once and then running through all the virtual servers.

---

- name: Disable VIPs

  hosts:

    - xx.xx.xx.xx

  connection: local

  gather_facts: False

  vars_files:

   - /automation/ansible/playbooks/f5/virtuals.yml

  tasks:

    - name: Obtain Creds

      include_vars: /etc/ansible/group_vars/password.yml

      no_log: true

    - name: Disable VIP

      bigip_command:

       commands:

        - tmsh modify ltm virtual "{{ item.vip_name }}" disabled

       provider: "{{ cli }}"

      delegate_to: localhost

      with_items:

        - "{{ virtual1 }}"

      notify: Show VIP

  handlers:

    - name: Show VIP

      bigip_command:

       commands:

        - tmsh show ltm virtual | grep -E -A 4 "Server"

       provider: "{{ cli }}"

      delegate_to: localhost

      register: result

    - debug: msg="{{ result.stdout_lines }}"

    - name: Sync configuration from device to group

      bigip_configsync_action:

        device_group: "{{ device_group }}"

        sync_device_to_group: "{{ save_config }}"

        provider: "{{ cli }}"

[Jonathan Lozada De La Matta]

Its hard to tell without knowing the resources of the ansible controller, number of changes/hosts and forks but, networking tasks are more CPU related due to running on localhost and sending api calls.

Jonathan Lozada De La Matta on mobile

 

---

From: ansible...@googlegroups.com on behalf of Sharon Day <sday...@gmail.com>
Sent: Sunday, June 16, 2019 8:38 AM
To: Ansible Project
Subject: [ansible-project] High CPU when running playbook to disable virtual servers

 

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/dc717a6f-54ff-4567-8bbd-ed154a6cf092%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sharon Day]

I’m not really following your comment. The high CPU is on the F5 load balancer not the Ansible I controlled. Are you thinking that the Ansible controller is over running the F5 load balancer?

[Tim]

Hey Sharon,

I'm one of the original authors of these modules, so lets see if I can
offer any guidance.

It looks like you're using the SSH provider to connect to the F5, so I
would be curious to know what process is running on the box that is
consuming your CPU. Running a `top` command for a brief moment should
be informative. If it's the restjavad service, that would be curious
because the cli provider does not use the rest daemon to do its work.

When we were doing performance testing of the different methods of
controlling the BIGIP, we noticed that ssh is both the slowest as well
as the most prone to disconnects. If I remember correctly, on a loaded
device it would be reliable ~50% of the time. SOAP (not supported in
the F5 ansible modules) was reliable ~95% of the time, and REST was
reliable ~98% of the time.

SSH is, additionally, one of the services that is chosen for
termination first when the device is under load.

Other processes that I could guess might be at the top of the `top`
output might be mcpd or (depending on your activated modules) mysql or
postgres. Additionally, you might want to tail the /var/log/ltm file
when you run ansible, or one of the /var/log/restjava.* files to see
if either of them are raising lots of messages.

Finally, out of curiosity, if you have the option of trying similar
modules using the rest transport, that might help pinpoint the
culprit.

F5 has a Slack channel for support of these things too if you're
interested; f5cloudsolutions.slack.com. There is a #ansible channel in
there where myself and others lurk and may be able to assist further.

-tim

On Sun, Jun 16, 2019 at 7:33 PM Sharon Day <sday...@gmail.com> wrote:
>
> I’m not really following your comment. The high CPU is on the F5 load balancer not the Ansible I controlled. Are you thinking that the Ansible controller is over running the F5 load balancer?
>

> --
> You received this message because you are subscribed to the Google Groups "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
> To post to this group, send email to ansible...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/87fdbfa1-b43c-49fa-b300-953d52ef56b6%40googlegroups.com.