Evaluación de Rendimiento del Servidor Ansible (rol)

Comprende el desempeño de tu máquina/contenedor/droplet/linode con Ansible.

Cuando se ejecuta en un host nuevo, te dará una idea de cuál es el rendimiento básico y si cumple con tus objetivos.

Ten en cuenta que el proyecto solo aborda requisitos inmediatos establecidos por nuestro equipo de operaciones en adelante, pero debería ser suficiente para muchos casos en general. Estaré encantado de expandirlo a más sistemas y casos con tu ayuda.

El catalizador

El catalizador para este proyecto fue el comportamiento un tanto aleatorio de nuestras máquinas en la nube. Para mantener el detalle del proveedor en el misterio, codificaremos su nombre en el apodo completamente no relacionado y críptico: "el Sharky".

El Sharky es bueno creando nuevas máquinas en la nube, que llamaremos krill. El rendimiento de los krill no se indica claramente en la documentación del Sharky, excepto que tiene cpus compartidos. Específicamente, en ninguna parte dice cuánto IOPS puedes esperar de los discos o la RAM, o cuál es el rendimiento de la memoria, o de qué familia de CPUs son los hipervisores subyacentes; y es probable que recibas una máquina que esté en el espectro inferior de rendimiento.

Al Sharky realmente no le importa crear krill iguales, solo le importa crear MUCHO de ello, y por eso intenta acomodar la mayor cantidad de krill posible en un solo hipervisor, hasta que sea imposible meter más, y en ese punto la degradación del rendimiento que los usuarios ven es bastante evidente.

Como usuario, sin embargo, lo único que te importa, y lo que asumes, es que lo que pagas (por hora) viene con las mismas especificaciones y capacidades cada vez que lo utilizas. Es comprensible que esto sea crucial para tu aplicación/negocio, y oficialmente no hay información que sugiera que debas esperar algo diferente de Sharky (excepto por la volatilidad en el espacio de cpus compartidas cuando se utiliza un tipo específico de krill compartido - pero eso es solo el cpu que mencionan).

Caso de Uso

Este rol fue creado para permitir verificaciones en dos direcciones.

1. Primero, deseas ejecutarlo antes de cualquier aprovisionamiento real para asegurarte de que tu rendimiento básico esté de acuerdo con tus suposiciones, y tal vez solo desechar tus krill y recrearlos si están muy fuera de lugar.
2. Luego deseas que esto se ejecute de manera programada o se active por eventos específicos (como cuando ves una caída en los tiempos de respuesta de la aplicación proporcionados por otras herramientas), para ver si los problemas que enfrentas no están relacionados con un bajo rendimiento de tu infraestructura. Al menos antes de empezar a culpar a los desarrolladores por enviar códigos no optimizados. O bien, probablemente puedas hacer esto último de todos modos, ya que creemos firmemente en la estrategia de "liberar temprano, optimizar cuando se siente la presión".

Premisa a Bajo Nivel

El plan es tener un conjunto de afirmaciones que bloqueen el aprovisionamiento sobre las capacidades de rendimiento de la máquina, utilizando poco o nada un mínimo de software adicional. Como tal, el resultado final puede ser más heurístico que una respuesta clara de sí/no, pero debería ser perfectamente adecuado como un canario de prueba.

Pruebas

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

Se hará silencio para que puedas proporcionar tu contraseña de sudo. Hazlo, presiona enter y continuará.

Uso

Cuando se clona desde el repositorio de git

Aumenta tu playbook.yml con este rol y ajusta los parámetros a cualquier rendimiento básico aceptable.

- name: Verificar
  hosts: all
  become: true

  roles:
    - role: ansible-server-performance-assessment
      spa_disk_write_MB_per_s_assertion: 300 [en MB/s, ajusta a tu gusto]
      spa_disk_read_MB_per_s_assertion: 300 [en MB/s, ajusta a tu gusto]
    
      # PRUEBA DE RED
      # ¡Gracias speedtest.net! Nunca pensé que te usaría en producción, pero aquí estamos.
      spa_speedtest_tmp_file: /tmp/spa_speedtest.out
      spa_downlink_assertion: 100  # Valor en Mb/s (BITS por segundo)
      spa_uplink_assertion: 100  # Valor en Mb/s (BITS por segundo)
        
      # PRUEBA DE MEMORIA
      spa_memory_speed_assertion: 10000  # Valor en MB/s (BYTES por segundo)
        
      # PRUEBA DE CPU
      spa_cpu_event_per_second_assertion: 300  # Número de eventos por segundo según lo informado por Sysbench

  tags:
    - benchmark
    - never

El ejemplo anterior se ejecutará felices sólo cuando se dé el parámetro --tags=benchmark a ansible (para facilitar la fusión con archivos de playbook existentes).

Limitaciones

El rol no funcionará bien o no funcionará en absoluto en locales que no sean en, ya que parte del software de benchmark analiza salidas usando frases específicas de sus resultados. Eso podría mejorarse con una segunda ronda de desarrollo por alguien que sepa manejar mejor awk y regex que yo.