Dans les grands systèmes cloud, le problème de l'équilibrage automatique ou du nivellement de la charge sur les ressources informatiques est particulièrement aigu. Tionix (développeur et opérateur de services cloud, faisant partie du groupe de sociétés Rostelecom) s'est également occupé de ce problème.
Et comme notre principale plate-forme de développement est Openstack et que nous, comme tout le monde, sommes paresseux, il a été décidé de sélectionner un module prêt à l'emploi déjà inclus dans la plate-forme. Notre choix s'est porté sur Watcher, que nous avons décidé d'utiliser pour nos besoins.
Examinons d’abord les termes et les définitions.
Termes et définitions
Objectif est un résultat final lisible, observable et mesurable qui doit être atteint. Il existe une ou plusieurs stratégies pour atteindre chaque objectif. Une stratégie est la mise en œuvre d’un algorithme capable de trouver une solution pour un objectif donné.
Action est une tâche élémentaire qui modifie l'état actuel de la ressource gérée cible du cluster OpenStack, telle que : migrer une machine virtuelle (migration), changer l'état d'alimentation d'un nœud (change_node_power_state), changer l'état du service nova (change_nova_service_state ), changement de saveur (redimensionnement), enregistrement des messages NOP (nop), absence d'action pendant un certain temps - pause (veille), transfert de disque (volume_migrate).
Plan d'action - un flux spécifique d'actions réalisées dans un certain ordre pour atteindre un objectif spécifique. Le plan d'action contient également des performances globales mesurées avec un ensemble d'indicateurs de performance. Un plan d'action est généré par Watcher lors d'un audit réussi, à la suite duquel la stratégie utilisée trouve une solution pour atteindre l'objectif. Un plan d'action consiste en une liste d'actions séquentielles.
Audit est une demande d’optimisation du cluster. L'optimisation est effectuée afin d'atteindre un objectif dans un cluster donné. Pour chaque audit réussi, Watcher génère un plan d'action.
Étendue de la vérification est un ensemble de ressources au sein duquel l'audit est effectué (zone(s) de disponibilité, agrégateurs de nœuds, nœuds de calcul ou nœuds de stockage individuels, etc.). La portée de l'audit est définie dans chaque modèle. Si aucune étendue d'audit n'est spécifiée, l'ensemble du cluster est audité.
Modèle de vérification — un ensemble de paramètres enregistrés pour lancer un audit. Des modèles sont nécessaires pour exécuter des audits plusieurs fois avec les mêmes paramètres. Le modèle doit nécessairement contenir l'objectif de l'audit ; si les stratégies ne sont pas spécifiées, alors les stratégies existantes les plus appropriées sont sélectionnées.
Grappe est un ensemble de machines physiques qui fournissent des ressources de calcul, de stockage et de réseau et sont gérées par le même nœud de gestion OpenStack.
Modèle de données de cluster (MDP) est une représentation logique de l'état actuel et de la topologie des ressources gérées par le cluster.
Indicateur d'efficacité - un indicateur qui indique comment est réalisée la solution créée à l'aide de cette stratégie. Les indicateurs de performance sont spécifiques à un objectif particulier et sont généralement utilisés pour calculer l'efficacité globale du plan d'action qui en résulte.
Spécification d'efficacité est un ensemble de fonctionnalités spécifiques associées à chaque objectif qui définit les différents indicateurs de performance qu'une stratégie pour atteindre l'objectif correspondant doit atteindre dans sa solution. En effet, chaque solution proposée par la stratégie sera vérifiée par rapport au cahier des charges avant de calculer son efficacité globale.
Moteur de notation est un fichier exécutable doté d'entrées et de sorties bien définies et qui exécute une tâche purement mathématique. De cette façon, le calcul est indépendant de l’environnement dans lequel il est effectué : il donnera le même résultat partout.
Planificateur d'observateurs - fait partie du moteur de décision Watcher. Ce module prend un ensemble d'actions générées par une stratégie et crée un plan de workflow qui précise comment planifier ces différentes actions dans le temps et pour chaque action, quelles sont les conditions préalables.
Objectifs et stratégies de l'observateur
Objectif
stratégie
Objectif factice
Stratégie factice
Stratégie factice utilisant des exemples de moteurs de notation
Stratégie factice avec redimensionnement
Économie d'énergie
Stratégie d'économie d'énergie
Regroupement de serveurs
Consolidation de base du serveur hors ligne
Stratégie de consolidation de la charge de travail des machines virtuelles
Équilibrage de la charge de travail
Stratégie de migration de l'équilibre de la charge de travail
Stratégie d’équilibre de la capacité de stockage
Stabilisation de la charge de travail
Voisin bruyant
Voisin bruyant
Optimisation thermique
Stratégie basée sur la température de sortie
Optimisation du flux d'air
Stratégie de migration du flux d'air uniforme
Maintenance du matériel
Migration de zones
Non classés
Actuateur
Objectif factice — objectif réservé utilisé à des fins de test.
Stratégies associées : stratégie factice, stratégie factice utilisant des exemples de moteurs de notation et stratégie factice avec redimensionnement. La stratégie factice est une stratégie factice utilisée pour les tests d'intégration via Tempest. Cette stratégie n'apporte aucune optimisation utile, son seul but est d'utiliser les tests Tempest.
Stratégie factice utilisant des exemples de moteurs de notation - la stratégie est similaire à la précédente, la seule différence est l'utilisation d'un exemple de « moteur de notation » qui effectue des calculs à l'aide de méthodes d'apprentissage automatique.
Stratégie factice avec redimensionnement - la stratégie est similaire à la précédente, la seule différence est l'utilisation du changement de saveur (migration et redimensionnement).
Non utilisé en production.
Économie d'énergie — minimiser la consommation d'énergie. La stratégie d'économie d'énergie de cet objectif, ainsi que la stratégie de consolidation de la charge de travail des VM (consolidation du serveur), sont capables de fonctionnalités de gestion dynamique de l'énergie (DPM) qui permettent d'économiser de l'énergie en consolidant dynamiquement les charges de travail, même pendant les périodes de faible utilisation des ressources : les machines virtuelles sont déplacées vers moins de nœuds. , et les nœuds inutiles sont désactivés. Après consolidation, la stratégie propose une décision d'activation/désactivation des nœuds conformément aux paramètres spécifiés : « min_free_hosts_num » - le nombre de nœuds activés libres qui attendent d'être chargés, et « free_used_percent » - le pourcentage d'hôtes activés gratuits sur le nombre de nœuds occupés par des machines. Pour que la stratégie fonctionne, il faut activé et configuré Ironic pour gérer le cycle d'alimentation sur les nœuds.
Paramètres de stratégie
paramètre
Тип
par défaut
description
free_used_percent
Numéro
10.0
rapport entre le nombre de nœuds de calcul libres et le nombre de nœuds de calcul avec machines virtuelles
min_free_hosts_num
Int
1
nombre minimum de nœuds de calcul libres
Le cloud doit avoir au moins deux nœuds. La méthode utilisée consiste à modifier l'état d'alimentation du nœud (change_node_power_state). La stratégie ne nécessite pas de collecter des métriques.
Consolidation de serveurs - minimisez le nombre de nœuds informatiques (consolidation). Il comporte deux stratégies : la consolidation de base des serveurs hors ligne et la stratégie de consolidation de la charge de travail des VM.
La stratégie de base de consolidation de serveurs hors ligne minimise le nombre total de serveurs utilisés ainsi que le nombre de migrations.
La stratégie de base nécessite les métriques suivantes :
métrique
service
plug-ins
commenter
calculate.node.cpu.percent
aucun
cpu_util
aucun
Paramètres de stratégie : migration_attempts - nombre de combinaisons pour rechercher des candidats potentiels à l'arrêt (par défaut, 0, aucune restriction), période - intervalle de temps en secondes pour obtenir une agrégation statique à partir de la source de données métriques (par défaut, 700).
Méthodes utilisées : migration, changement d'état du service nova (change_nova_service_state).
La stratégie de consolidation de la charge de travail des VM est basée sur une heuristique de premier ajustement qui se concentre sur la charge CPU mesurée et tente de minimiser les nœuds qui ont trop ou pas assez de charge compte tenu des contraintes de capacité des ressources. Cette stratégie fournit une solution qui aboutit à une utilisation plus efficace des ressources du cluster en suivant les quatre étapes suivantes :
- Phase de déchargement - traitement des ressources surutilisées ;
- Phase de consolidation - gestion des ressources sous-utilisées ;
- Optimisation de la solution - réduction du nombre de migrations ;
- Désactivation des nœuds de calcul inutilisés.
La stratégie nécessite les mesures suivantes :
métrique
service
plug-ins
commenter
Mémoire
aucun
disque.root.size
aucun
Les mesures suivantes sont facultatives mais amélioreront la précision de la stratégie si elles sont disponibles :
métrique
service
plug-ins
commenter
mémoire.résident
aucun
cpu_util
aucun
Paramètres de stratégie : période – intervalle de temps en secondes pour obtenir une agrégation statique à partir de la source de données métriques (par défaut, 3600 XNUMX).
Utilise les mêmes méthodes que la stratégie précédente. Plus de détails .
Équilibrage de la charge de travail — équilibrez la charge de travail entre les nœuds de calcul. L'objectif comporte trois stratégies : stratégie de migration d'équilibre de la charge de travail, stabilisation de la charge de travail et stratégie d'équilibrage de la capacité de stockage.
Workload Balance Migration Strategy exécute des migrations de machines virtuelles en fonction de la charge de travail de la machine virtuelle hôte. Une décision de migration est prise chaque fois que le % d'utilisation du processeur ou de la RAM d'un nœud dépasse le seuil spécifié. Dans ce cas, la machine virtuelle déplacée devrait rapprocher le nœud de la charge de travail moyenne de tous les nœuds.
Exigences
- Utilisation de processeurs physiques ;
- Au moins deux nœuds informatiques physiques ;
- Installation et configuration du composant Ceilometer - ceilometer-agent-compute, exécuté sur chaque nœud de calcul, et l'API Ceilometer, ainsi que collecte des métriques suivantes :
métrique
service
plug-ins
commenter
cpu_util
aucun
mémoire.résident
aucun
Paramètres de stratégie :
paramètre
Тип
par défaut
description
métrique
Chaîne
'cpu_util'
Les métriques sous-jacentes sont : 'cpu_util', 'memory.resident'.
порог
Numéro
25.0
Seuil de charge de travail pour la migration.
période
Numéro
300
Période de temps cumulée Ceilometer.
La méthode utilisée est la migration.
La stabilisation de la charge de travail est une stratégie visant à stabiliser la charge de travail à l'aide de la migration en direct. La stratégie est basée sur un algorithme d'écart type et détermine s'il y a une congestion dans le cluster et y répond en déclenchant la migration des machines pour stabiliser le cluster.
Exigences
- Utilisation de processeurs physiques ;
- Au moins deux nœuds informatiques physiques ;
- Installation et configuration du composant Ceilometer - ceilometer-agent-compute, exécuté sur chaque nœud de calcul, et l'API Ceilometer, ainsi que collecte des métriques suivantes :
métrique
service
plug-ins
commenter
cpu_util
aucun
mémoire.résident
aucun
Stratégie d'équilibrage de la capacité de stockage (stratégie mise en œuvre à partir de Queens) - la stratégie transfère les disques en fonction de la charge sur les pools Cinder. Une décision de transfert est prise chaque fois que le taux d'utilisation du pool dépasse un seuil spécifié. Le disque déplacé devrait rapprocher le pool de la charge moyenne de tous les pools Cinder.
Exigences et restrictions
- Minimum deux piscines Cinder ;
- Possibilité de migration de disque.
- Modèle de données de cluster - Collecteur de modèles de données de cluster Cinder.
Paramètres de stratégie :
paramètre
Тип
par défaut
description
volume_seuil
Numéro
80.0
Valeur seuil des disques pour l'équilibrage des volumes.
La méthode utilisée est la migration de disque (volume_migrate).
Voisin bruyant - Identifiez et migrez un «voisin bruyant» - une machine virtuelle de faible priorité qui a un impact négatif sur les performances d'une machine virtuelle de haute priorité en termes d'IPC en utilisant trop le cache de dernier niveau. Propre stratégie : Noisy Neighbor (le paramètre de stratégie utilisé est cache_threshold (la valeur par défaut est 35), lorsque les performances chutent à la valeur spécifiée, la migration est lancée. Pour que la stratégie fonctionne, activée Métriques LLC (Last Level Cache), dernier serveur Intel avec prise en charge CMT, ainsi que la collecte des métriques suivantes :
métrique
service
plug-ins
commenter
cpu_l3_cache
aucun
Intel requis .
Modèle de données de cluster (par défaut) : collecteur de modèles de données de cluster Nova. La méthode utilisée est la migration.
Travailler avec cet objectif via le tableau de bord n’est pas entièrement mis en œuvre dans le Queens.
Optimisation thermique — optimiser le régime de température. La température de sortie (air évacué) est l’un des systèmes de télémétrie thermique importants pour mesurer l’état thermique/de charge de travail d’un serveur. La cible dispose d'une stratégie, la stratégie basée sur la température de sortie, qui décide de migrer les charges de travail vers des hôtes thermiquement favorables (température de sortie la plus basse) lorsque la température de sortie des hôtes sources atteint un seuil configurable.
Pour que la stratégie fonctionne, vous avez besoin d'un serveur sur lequel Intel Power Node Manager est installé et configuré , ainsi que la collecte des métriques suivantes :
métrique
service
plug-ins
commenter
matériel.ipmi.node.outlet_temperature
IPMI
Paramètres de stratégie :
paramètre
Тип
par défaut
description
порог
Numéro
35.0
Seuil de température pour la migration.
période
Numéro
30
Intervalle de temps, en secondes, pour obtenir l'agrégation statistique à partir de la source de données métriques.
La méthode utilisée est la migration.
Optimisation du flux d'air — optimiser le mode de ventilation. Propre stratégie - Uniform Airflow utilisant la migration en direct. La stratégie déclenche la migration de la machine virtuelle chaque fois que le flux d'air du ventilateur du serveur dépasse un seuil spécifié.
Pour que la stratégie fonctionne, vous avez besoin de :
- Matériel : nœuds de calcul < prenant en charge NodeManager 3.0 ;
- Au moins deux nœuds informatiques ;
- Le composant ceilometer-agent-compute et l'API Ceilometer installés et configurés sur chaque nœud de calcul, qui peuvent rapporter avec succès des métriques telles que le débit d'air, la puissance du système, la température d'entrée :
métrique
service
plug-ins
commenter
matériel.ipmi.node.airflow
IPMI
matériel.ipmi.node.temperature
IPMI
matériel.ipmi.node.power
IPMI
Pour que la stratégie fonctionne, vous avez besoin d'un serveur sur lequel Intel Power Node Manager 3.0 ou version ultérieure est installé et configuré.
Limites : Le concept n'est pas destiné à la production.
Il est proposé d'utiliser cet algorithme avec des audits continus, puisqu'il est prévu qu'une seule machine virtuelle soit migrée par itération.
Les migrations en direct sont possibles.
Paramètres de stratégie :
paramètre
Тип
par défaut
description
seuil_airflow
Numéro
400.0
Le seuil de débit d'air pour l'unité de migration est de 0.1 CFM
seuil_inlet_t
Numéro
28.0
Seuil de température d'entrée pour la décision de migration
seuil_puissance
Numéro
350.0
Seuil de puissance du système pour la décision de migration
période
Numéro
30
Intervalle de temps, en secondes, pour obtenir l'agrégation statistique à partir de la source de données métriques.
La méthode utilisée est la migration.
Maintenance du matériel — maintenance du matériel. La stratégie liée à cet objectif est la migration de zone. La stratégie est un outil de migration automatique et minimale efficace des machines virtuelles et des disques en cas de besoin de maintenance matérielle. La stratégie construit un plan d'action en fonction de poids : un ensemble d'actions qui ont plus de poids seront planifiées avant les autres. Il existe deux options de configuration : action_weights et parallélisation.
Limitations : les pondérations d'action et la parallélisation doivent être configurées.
Paramètres de stratégie :
paramètre
Тип
par défaut
description
nœuds_de calcul
tableau
Aucun
Nœuds de calcul pour la migration.
pools_de stockage
tableau
Aucun
Nœuds de stockage pour la migration.
parallèle_total
entier
6
Le nombre total d'activités qui doivent être exécutées en parallèle.
parallèle_per_node
entier
2
Nombre d'actions effectuées en parallèle pour chaque nœud de calcul.
parallèle_per_pool
entier
2
Nombre d'actions effectuées en parallèle pour chaque pool de stockage.
priorité
objet
Aucun
Liste de priorités pour les machines virtuelles et les disques.
avec_attached_volume
booléen
Faux
Faux : les machines virtuelles seront migrées une fois que tous les disques auront été migrés. Vrai : les machines virtuelles seront migrées une fois que tous les disques connectés auront été migrés.
Éléments du réseau de nœuds de calcul :
paramètre
Тип
par défaut
description
nœud_src
un magnifique
Aucun
Le nœud de calcul à partir duquel les machines virtuelles sont migrées (obligatoire).
dst_node
un magnifique
Aucun
Calculez le nœud vers lequel les machines virtuelles migrent.
Éléments du tableau de nœuds de stockage :
paramètre
Тип
par défaut
description
src_pool
un magnifique
Aucun
Pool de stockage à partir duquel les disques sont migrés (obligatoire).
dst_pool
un magnifique
Aucun
Pool de stockage vers lequel les disques sont migrés.
type_src
un magnifique
Aucun
Type de disque d'origine (obligatoire).
type_dst
un magnifique
Aucun
Le type de disque résultant (obligatoire).
Éléments de priorité de l'objet :
paramètre
Тип
par défaut
description
Projet
tableau
Aucun
Noms des projets.
noeud_calcul
tableau
Aucun
Calculer les noms des nœuds.
pool_de stockage
tableau
Aucun
Noms des pools de stockage.
calcul
enum
Aucun
Paramètres de la machine virtuelle ["vcpu_num", "mem_size", "disk_size", "created_at"].
storage
enum
Aucun
Paramètres du disque ["size", "created_at"].
Les méthodes utilisées sont la migration de machine virtuelle, la migration de disque.
Non classés - un objectif auxiliaire utilisé pour faciliter le processus de développement de la stratégie. Ne contient aucune spécification et peut être utilisé chaque fois que la stratégie n'est pas encore associée à un objectif existant. Cet objectif peut également être utilisé comme point de transition. Une stratégie connexe à cet objectif est Actuator.
Créer un nouvel objectif
Moteur de décision Watcher dispose d’une interface plugin « objectif externe » qui permet d’intégrer un objectif externe pouvant être atteint grâce à une stratégie.
Avant de créer un nouvel objectif, vous devez vous assurer qu'aucun objectif existant ne répond à vos besoins.
Création d'un nouveau plugin
Pour créer une nouvelle cible, vous devez : étendre la classe cible, implémenter une méthode de classe obtenir_nom() pour renvoyer l'ID unique de la nouvelle cible que vous souhaitez créer. Cet identifiant unique doit correspondre au nom du point d'entrée que vous déclarerez ultérieurement.
Ensuite, vous devez implémenter la méthode de classe get_display_name() pour renvoyer le nom d'affichage traduit de la cible que vous souhaitez créer (n'utilisez pas de variable pour renvoyer la chaîne traduite afin qu'elle puisse être automatiquement collectée par l'outil de traduction.).
Implémenter une méthode de classe get_translatable_display_name()pour renvoyer la clé de traduction (en fait le nom d'affichage anglais) de votre nouvelle cible. La valeur de retour doit correspondre à la chaîne traduite dans get_display_name().
Mettre en œuvre sa méthode get_efficacy_spécification()pour renvoyer la spécification d'efficacité de votre cible. La méthode get_efficacy_spécification() renvoie l'instance Unclassified() fournie par Watcher. Cette spécification de performance est utile dans le processus d’élaboration de votre objectif car elle correspond à la spécification vide.
→
Architecture Watcher (plus de détails) ).
Composants
API de l'observateur - un composant qui implémente l'API REST fournie par Watcher. Mécanismes d'interaction : CLI, plugin Horizon, SDK Python.
Base de données de l'observateur — Base de données des observateurs.
Applicateur d'observateur — un composant qui implémente l'exécution d'un plan d'action créé par le composant Watcher Decision Engine.
Moteur de décision Watcher - Le composant responsable du calcul d'un ensemble d'actions d'optimisation potentielles pour atteindre l'objectif d'audit. Si aucune stratégie n’est spécifiée, le composant sélectionne indépendamment la plus appropriée.
Éditeur de métriques Watcher - Un composant qui collecte et calcule certaines métriques ou événements et les publie sur le point de terminaison CEP. La fonctionnalité du composant peut également être assurée par l'éditeur Ceilometer.
Moteur de traitement d'événements complexes (CEP) — moteur de traitement d'événements complexes. Pour des raisons de performances, plusieurs instances du moteur CEP peuvent s'exécuter simultanément, chacune traitant un type spécifique de métrique/d'événement. Dans le système Watcher, CEP déclenche deux types d'actions : - enregistrer les événements/métriques pertinents dans la base de données de séries chronologiques ; - envoyer des événements appropriés au Watcher Decision Engine lorsque cet événement peut affecter le résultat de la stratégie d'optimisation actuelle, puisque le cluster Openstack n'est pas un système statique.
Les composants interagissent grâce au protocole AMQP.
→
Schéma d'interaction avec Watcher
Résultats des tests d'observation
- Sur la page Optimisation - Plans d'action 500 (aussi bien sur pure Queens que sur stand avec modules Tionix), elle n'apparaît qu'après lancement de l'audit et génération d'un plan d'action ; celui vide s'ouvre normalement.
- Il y a des erreurs dans l'onglet Détails de l'action, il n'est pas possible d'obtenir l'objectif et la stratégie d'audit (aussi bien sur Pure Queens que sur stand avec modules Tionix).
- Les audits à finalité Dummy (test) sont créés et lancés normalement, des plans d'action sont générés.
- Les audits pour l'objectif Non classé ne sont pas créés car l'objectif n'est pas fonctionnel et est destiné à une configuration intermédiaire lors de la création de nouvelles stratégies.
- Les audits à des fins d'équilibrage de la charge de travail (stratégie d'équilibrage de la capacité de stockage) sont créés avec succès, mais aucun plan d'action n'est généré. Aucune optimisation du pool de stockage n’est requise.
- Les audits pour l'objectif d'équilibrage de la charge de travail (stratégie de migration de l'équilibre de la charge de travail) sont créés avec succès, mais aucun plan d'action n'est généré.
- Les audits pour l’équilibrage de la charge de travail (stratégie de stabilisation de la charge de travail) échouent.
- Les audits pour la cible Noisy Neighbour sont créés avec succès, mais aucun plan d'action n'est généré.
- Les audits à des fins de maintenance matérielle sont créés avec succès, le plan d'action n'est pas généré dans son intégralité (des indicateurs de performance sont générés, mais la liste des actions elle-même n'est pas générée).
- Les modifications dans les configurations nova.conf (dans la section par défaut computing_monitors = cpu.virt_driver) sur les nœuds de calcul et de contrôle ne corrigent pas les erreurs.
- Les audits ciblant la consolidation des serveurs (stratégie de base) échouent également.
- Les audits à des fins de consolidation de serveur (stratégie de consolidation de la charge de travail des machines virtuelles) échouent avec une erreur. Dans les journaux, il y a une erreur lors de l'obtention des données sources. Discussion de l'erreur, en particulier .
Nous avons essayé de spécifier Watcher dans le fichier de configuration (cela n'a pas aidé - en raison d'une erreur sur toutes les pages d'optimisation, le retour au contenu original du fichier de configuration ne corrige pas la situation) : [watcher_strategies.basic] source de données = ceilomètre, gnocchi - Les audits pour les économies d’énergie échouent. À en juger par les journaux, le problème est toujours l'absence d'Ironic : cela ne fonctionnera pas sans service baremetal.
- Les audits d’optimisation thermique échouent. Le traçage est le même que pour Server Consolidation (stratégie de consolidation de charge de travail VM) (erreur de données source)
- Les audits destinés à l'optimisation du flux d'air échouent avec une erreur.
Les erreurs d’achèvement d’audit suivantes sont également rencontrées. Traceback dans les journaux décision-engine.log (l'état du cluster n'est pas défini).
→ Discussion de l'erreur
Conclusion
Le résultat de nos deux mois de recherche a été la conclusion sans équivoque que pour obtenir un système d'équilibrage de charge à part entière et fonctionnel, nous devrons, dans cette partie, travailler en étroite collaboration pour affiner les outils de la plateforme Openstack.
Watcher s'est avéré être un produit sérieux et en développement rapide avec un potentiel énorme, dont la pleine utilisation nécessitera beaucoup de travail sérieux.
Mais nous en reparlerons dans les prochains articles de la série.
Source: habr.com