Évaluation des performances du serveur Ansible (rôle)

Comprenez les performances de votre machine/container/droplet/linode avec Ansible.

Lorsqu'il est exécuté sur un hôte frais, il vous donnera une idée des performances de base et si celles-ci répondent à vos objectifs.

Notez que le projet ne résout que les exigences immédiates telles que définies par notre équipe opérationnelle, mais devrait suffire pour de nombreux cas en général. Nous serons heureux d'étendre nos travaux à plus de systèmes et de cas avec votre aide.

Le catalyseur

Le catalyseur de ce projet était un comportement quelque peu aléatoire de nos machines cloud. Je garderai le détail de qui est le fournisseur en codant son nom avec un pseudonyme totalement non lié et cryptique : "le Sharky".

Le Sharky est bon pour créer de nouvelles machines cloud, que nous appellerons krill. Les performances des krill ne sont clairement spécifiées nulle part dans la documentation du Sharky, si ce n'est qu'ils ont des CPU partagés. Nulle part il est indiqué combien d'IOPS vous pouvez attendre des disques ou de la RAM, ou quel est le débit de la mémoire, ou quelle est la famille de CPU des hyperviseurs sous-jacents ; et il y a de fortes chances que vous receviez une machine qui se situe dans le bas de l'échelle des performances.

Le Sharky ne se soucie pas vraiment de créer des krill équivalents, il se soucie seulement d'en créer BEAUCOUP, et de ce fait, il essaiera de faire tenir autant de krill que possible sur un seul hyperviseur, jusqu'à ce qu'il soit impossible d'en ajouter davantage, à quel point la dégradation des performances devient flagrante.

En tant qu'utilisateur, cependant, tout ce que vous voulez, et tout ce que vous supposez, c'est que ce pour quoi vous payez (à l'heure) dispose des mêmes spécifications et capacités chaque fois que vous le lancez. Il est compréhensible que cela soit crucial pour votre application/entreprise, et officiellement il n'y a aucune information qui vous laisse penser autre chose de la part du Sharky (sauf pour la volatilité officiellement déclarée dans l'espace CPU partagé lorsque ce type de krill partagé est utilisé - mais c'est le seul CPU qu'ils mentionnent).

Cas d'utilisation

Ce rôle a été créé pour permettre des vérifications en deux étapes.

1. D'abord, vous souhaiterez l'exécuter avant tout provisionnement réel pour vous assurer que votre baseline est en accord avec vos hypothèses, et peut-être simplement jeter vos krill et les recréer s'ils sont trop éloignés de la réalité.
2. Ensuite, vous voudrez que cela s'exécute régulièrement ou soit déclenché par des événements spécifiques (comme lorsque vous remarquez une baisse des temps de réponse de l'application fournie par d'autres outils), pour voir si les problèmes que vous rencontrez ne sont pas liés à des performances insuffisantes de votre infrastructure. Au moins avant de commencer à blâmer les développeurs pour avoir poussé des codes non optimisés. Ou bien vous pouvez probablement faire le dernier acte de toute façon, car nous croyons fermement au concept de "lancer tôt, optimiser quand harcelé".

Principe de base

Le plan est d'avoir un ensemble d'assertions bloquantes sur les capacités de performance de la machine, en utilisant peu ou pas un minimum de logiciels supplémentaires. Ainsi, le résultat final pourrait être plus heuristique qu'une réponse définitive, mais il devrait être parfaitement adapté en tant que test préventif.

Tests

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

Cela deviendra silencieux afin que vous puissiez fournir votre mot de passe sudo. Faites-le, appuyez sur entrer et cela continuera.

Utilisation

lorsque cloné depuis le dépôt git

Augmentez votre playbook.yml avec ce rôle et ajustez les paramètres selon ce qui constitue la performance de base acceptable.

- name: Vérifier
  hosts: all
  become: true

  roles:
    - role: ansible-server-performance-assessment
      spa_disk_write_MB_per_s_assertion: 300 [en MB/s, ajustez selon vos besoins]
      spa_disk_read_MB_per_s_assertion: 300 [en MB/s, ajustez selon vos besoins]
    
      # TEST RÉSEAU
      # merci speedtest.net ! Je n'aurais jamais pensé que je t'utiliserais en production, mais nous y sommes.
      spa_speedtest_tmp_file: /tmp/spa_speedtest.out
      spa_downlink_assertion: 100  # Valeur en Mb/s (BITS par seconde)
      spa_uplink_assertion: 100  # Valeur en Mb/s (BITS par seconde)
        
      # TEST MÉMOIRE
      spa_memory_speed_assertion: 10000  # Valeur en MB/s (BYTES par seconde)
        
      # TEST CPU
      spa_cpu_event_per_second_assertion: 300  # Nombre d'événements par seconde rapporté par Sysbench

  tags:
    - benchmark
    - jamais

L'exemple ci-dessus s'exécutera uniquement lorsque le paramètre --tags=benchmark est donné à Ansible (pour une fusion plus facile avec des fichiers de playbook existants).

Limitations

Le rôle ne fonctionnera pas très bien ou pas du tout sur des locales non en, car une partie du logiciel de benchmark analyse les résultats à l'aide de phrases spécifiques dans leurs sorties. Cela pourrait être amélioré avec un second tour de développement par quelqu'un qui maîtrise mieux les awks et les regex que moi.