Avoir une installation OpenStack qui fonctionne, c’est bien ; mais être certain que son infrastructure tienne la charge, c’est encore mieux. Heureusement, il existe un outil qui permet de faire des tests de charge sur OpenStack facilement : Rally.
Présentation du module Rally
Rally est présenté comme un « Benchmark-as-a-Service » du projet OpenStack. Il permet de réaliser des tests simulant une réelle activité sur une infrastructure et d’en mesurer les performances. Ainsi, il est possible de tester les limites d’une installation et de faire des optimisations en fonction des résultats.
Rally apporte avec lui une multitude de scénarios de tests qui sont pour la plupart largement suffisants. Par exemple, il est possible de lancer facilement une instance pour un utilisateur et de faire exécuter ce test 100 fois de suite. Ou bien de créer 100 utilisateurs simultanément avec une instance par utilisateur. Rally supprimera automatiquement à la fin toutes les ressources créées sur l’OpenStack afin de retrouver son installation « propre » même si certains de ces tests sont en échec. Plusieurs exemples de scénarios sont disponibles dans le répertoire rally/tasks/scenarios de Rally sous forme de fichiers JSON ou YAML. On peut les utiliser directement ou s’en inspirer pour affiner ses tests.
Pour mettre en œuvre Rally, nul besoin de toucher à l’installation de son OpenStack. Il est tout à fait possible et même recommandé d’utiliser Rally sur une machine extérieure car celui-ci utilise les APIs d’OpenStack pour communiquer avec les autres modules. Pour l’exemple qui suit, on utilisera un simple DevStack.
Préparation de l’environnement de tests
Commençons par récupérer Rally en utilisant directement le dépôt GitHub. Il est aussi possible de l’installer automatiquement.
$ git clone https://github.com/openstack/rally.git
Il faut créer un script d’environnement client qui nous permettra de joindre l’OpenStack et de s’authentifier. Plus d’informations sont disponibles sur la documentation officielle. Il peut être judicieux de créer un environnement virtuel avant d’aller plus loin. À vous de voir en fonction de l’utilisation que vous avez de cette machine.
Voici un exemple :
$ vi devstack-openrc.sh
export OS_USERNAME=admin
export OS_PASSWORD=liced
export OS_TENANT_NAME=admin
export OS_AUTH_URL=http://192.168.1.13/identity
export OS_REGION_NAME=RegionOne
export OS_VOLUME_API_VERSION=2
export OS_IDENTITY_API_VERSION=3
export OS_USER_DOMAIN_NAME=${OS_USER_DOMAIN_NAME:-"Default"}
export OS_PROJECT_DOMAIN_NAME=${OS_PROJECT_DOMAIN_NAME:-"Default"}
Il ne reste plus qu’à le charger.
$ source ./devstack-openrc.sh
Il est indispensable d’installer la base de données Rally avant son utilisation.
$ rally db create
Il ne reste plus qu’à fournir à Rally les informations de votre environnement OpenStack pour créer un déploiement Rally qu’on appelle ici existing.
$ rally deployment create --fromenv –name=existing
2017-12-08 11:43:35.940 6942 INFO rally.deployment.engines.existing [-] Save deployment 'existing' (uuid=a9f94531-fed8-466b-974b-dbd77c0c133e) with 'openstack' platform.
+--------------------------------------+---------------------+----------+------------------+--------+
| uuid | created_at | name | status | active |
+--------------------------------------+---------------------+----------+------------------+--------+
| a9f94531-fed8-466b-974b-dbd77c0c133e | 2017-12-08T10:43:35 | existing | deploy->finished | |
+--------------------------------------+---------------------+----------+------------------+--------+
Using deployment: a9f94531-fed8-466b-974b-dbd77c0c133e
~/.rally/openrc was updated
HINTS:
* To use standard OpenStack clients, set up your env by running:
source ~/.rally/openrc
OpenStack clients are now configured, e.g run:
openstack image list
Normalement, la réponse devrait indiquer que le déploiement est fonctionnel. À ce stade, tout est prêt et il ne reste plus qu’à lancer des scénarios de tests qui utiliseront donc votre installation OpenStack.
Exécution de tests de performance
On va tout simplement utiliser un scénario déjà existant. Il s’agit du scénario boot_and_delete_server de Nova qui crée une instance et la supprime dans la foulée.
Les scénarios d’exemples sont disponibles en format JSON ou YAML.
Voici à quoi ce scénario ressemble :
cat samples/tasks/scenarios/nova/boot-and-delete.yaml
{% set flavor_name = flavor_name or "m1.tiny" %}
---
NovaServers.boot_and_delete_server:
-
args:
flavor:
name: "{{flavor_name}}" # nom du flavor à utiliser, par défaut m1.tiny
image:
name: "^cirros.*-disk$" # nom de l’image, ici on utilise une image cirros
force_delete: false
runner:
type: "constant"
times: 10 # le scénario est répété 10 fois
concurrency: 2 # on parallélise deux exécutions en même temps
context: # la partie context permet de créer des ressources avant le lancement du scénario
users:
tenants: 3 # 3 tenants sont créés à chaque boucle
users_per_tenant: 2 # et 2 utilisateurs par tenant
sla:
failure_rate:
max: 0 # s’il y a une seule erreur seulement le test est considéré en échec
- # on lance une deuxième fois le scénario mais avec des paramètres différents
args:
flavor:
name: "{{flavor_name}}"
image:
name: "^cirros.*-disk$"
auto_assign_nic: true # on assigne une IP à l’instance si un réseau existe (les réseaux sont créés dans la partie networks context)
runner:
type: "constant"
times: 10
concurrency: 2
context:
users:
tenants: 3
users_per_tenant: 2
network:
start_cidr: "10.2.0.0/24" # création du réseau
networks_per_tenant: 2 # il y aura deux réseaux par tenant
sla:
failure_rate:
max: 0
Dans ce fichier, il y a en fait la définition de deux tâches avec des paramètres différents. On peut spécifier dans un fichier, plusieurs exécutions d’un scénario de test avec des paramètres différents sans aucun problème. On peut alors faire des comparatifs sur les résultats obtenus.
Dans le fichier boot-and-delete.yaml, la première tâche lance de simples instances sans adresse IP. À chaque boucle, il y a trois tenants et deux utilisateurs par tenant qui sont créés.
La deuxième tâche est légèrement plus complexe. À chaque boucle on définit en plus deux réseaux privés dans la plage 10.2.0.0/24 pour le besoin de notre scénario. Puis une fois les réseaux en place, les instances sont lancées en créant pour chacune d’elle une interface réseau faisant partie d’un des réseaux privés (auto_assign_nic: true).
On obtient les résultats après l’exécution des tâches et cela peut prendre un certain temps selon votre infrastructure. Dans notre cas, on va obtenir deux résultats puisqu’on avait deux tâches.
+-----------------------------------------------------------------------------------------------------------------------+
| Response Times (sec) |
+--------------------+-----------+--------------+--------------+--------------+-----------+-----------+---------+-------+
| Action | Min (sec) | Median (sec) | 90%ile (sec) | 95%ile (sec) | Max (sec) | Avg (sec) | Success | Count |
+--------------------+-----------+--------------+--------------+--------------+-----------+-----------+---------+-------+
| nova.boot_server | 4.37 | 4.915 | 6.803 | 7.079 | 7.355 | 5.277 | 100.0% | 10 |
| nova.delete_server | 2.371 | 2.741 | 3.085 | 3.146 | 3.208 | 2.773 | 100.0% | 10 |
| total | 7.12 | 7.643 | 9.244 | 9.835 | 10.426 | 8.049 | 100.0% | 10 |
| -> duration | 6.12 | 6.643 | 8.244 | 8.835 | 9.426 | 7.049 | 100.0% | 10 |
| -> idle_duration | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 100.0% | 10 |
+--------------------+-----------+--------------+--------------+--------------+-----------+-----------+---------+-------+
Load duration: 41.60862
Full duration: 48.377965
+-----------------------------------------------------------------------------------------------------------------------+
| Response Times (sec) |
+--------------------+-----------+--------------+--------------+--------------+-----------+-----------+---------+-------+
| Action | Min (sec) | Median (sec) | 90%ile (sec) | 95%ile (sec) | Max (sec) | Avg (sec) | Success | Count |
+--------------------+-----------+--------------+--------------+--------------+-----------+-----------+---------+-------+
| nova.boot_server | 10.813 | 14.019 | 22.459 | 24.622 | 26.786 | 15.526 | 100.0% | 10 |
| nova.delete_server | 2.931 | 5.516 | 6.334 | 6.501 | 6.668 | 5.36 | 100.0% | 10 |
| total | 13.744 | 19.842 | 27.926 | 30.126 | 32.325 | 20.886 | 100.0% | 10 |
| -> duration | 12.744 | 18.842 | 26.926 | 29.126 | 31.325 | 19.886 | 100.0% | 10 |
| -> idle_duration | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 100.0% | 10 |
+--------------------+-----------+--------------+--------------+--------------+-----------+-----------+---------+-------+
Load duration: 106.729943
Full duration: 198.124346
La première tâche a duré 48 secondes tandis que la deuxième a duré 198 secondes. On observe que la fonction nova.boot_server est en moyenne beaucoup plus longue sur la deuxième tâche. C’est tout à fait normal, car dans le deuxième cas les serveurs avaient à gérer la création d’une interface réseau lors de leur démarrage.
Rally permet également la génération de rapports en HTML avec plusieurs niveaux de détails.
$ rally task report d970ec54-2492-4cf8-b869-01f5127966c1 --out output.html
Rally propose plusieurs dizaines de scénarios différents concernant la plupart des modules OpenStack les plus populaires. Pour affiner un scénario de tests, il faut alors créer vos propres tâches en spécifiant les attributs dont vous avez besoin. On peut donc créer des actions très spécifiques propres à votre infrastructure.
Pour aller plus loin
Il est possible de créer ses propres scénarios mais il va falloir mettre la main dans le cambouis et toucher un peu à du Python. Cela est nécessaire si vous avez besoin de tester un module qui n’est pas intégré dans Rally.
Par exemple, si vous souhaitez tester un plugin Neutron, c’est dans ce répertoire qu’il faut travailler : rally/plugins/openstack/scenarios/neutron/
Vous aurez besoin de créer un fichier relatif à votre module dans lequel se trouveront les différents scénarios. Les actions de votre plugin (créer_ressource, supprimer_ressource, update_ressource, etc) sont à créer dans le fichier utils. Enfin, il ne faudra pas non plus oublier de gérer la suppression automatique des ressources une fois les tests terminés en ajoutant le plugin dans ce fichier rally/plugins/openstack/cleanup/resources.py.