Dans Nous avons parlé des tentatives d'utilisation de Watcher et présenté un rapport de tests. Nous effectuons régulièrement de tels tests pour l'équilibrage et d'autres fonctions critiques dans un grand cloud d'entreprise ou d'opérateur.
La complexité élevée de la tâche à résoudre nécessitera probablement plusieurs articles pour décrire notre projet. Aujourd'hui, nous publions le deuxième article de la série, consacré à l'équilibrage des machines virtuelles dans le cloud.
Un peu de terminologie
La société VmWare a introduit l'utilitaire DRS (Distributed Resource Scheduler) pour l'équilibrage de la charge dans l'environnement de virtualisation qu'elle a développé et proposé.
Comme l'indique
« VMware DRS (Planificateur de ressources distribuées) est un utilitaire qui équilibre les charges de calcul avec les ressources disponibles dans un environnement virtuel. Cet utilitaire fait partie du package de virtualisation appelé VMware Infrastructure.
Avec VMware DRS, les utilisateurs définissent des règles pour la distribution des ressources physiques entre les machines virtuelles (VM). L'utilitaire peut être configuré pour une gestion manuelle ou automatique. Les pools de ressources VMware peuvent être facilement ajoutés, supprimés ou réorganisés. Si désiré, les pools de ressources peuvent être isolés entre différentes unités commerciales. Si la charge de travail d'une ou plusieurs machines virtuelles varie fortement, VMware DRS redistribue les machines virtuelles entre les serveurs physiques. Si la charge de travail globale diminue, certains serveurs physiques peuvent être temporairement désactivés, et la charge de travail consolidée.
Pourquoi l'équilibrage est-il nécessaire?
À notre avis, DRS est une fonction essentielle du cloud, bien que cela ne signifie pas qu'il faille toujours et partout utiliser DRS. En fonction de la destination et des besoins du cloud, il peut y avoir différentes exigences pour DRS et les méthodes d'équilibrage. Il peut exister des situations où l'équilibrage n'est pas nécessaire du tout, voire nuisible.
Pour mieux comprendre où et pour quels clients DRS est nécessaire, examinons leurs objectifs et tâches. Les clouds peuvent être divisés en publics et privés. Voici les principales différences entre ces clouds et les objectifs des clients.
Clouds privés / Grands clients d'entreprise
Clouds publics / Petites et moyennes entreprises, particuliers
Critère principal et objectifs de l'opérateur
Fournir un service ou un produit fiable
Réduction des coûts des services dans la lutte sur un marché concurrentiel
Exigences du service
Fiabilité à tous les niveaux et dans tous les éléments du système
Performance garantie
Priorisation des machines virtuelles en plusieurs catégories
Sécurité informationnelle et physique des données
SLA et support 24/7
Simplicité maximale d'obtention du service
Services relativement simples
La responsabilité des données revient au client
La priorisation des VM n'est pas requise
Sécurité de l'information au niveau des services standards, responsabilité au client
Des pannes peuvent survenir
Pas de SLA, qualité non garantie
Support par e-mail
La sauvegarde n'est pas obligatoire
Particularités du client
Une très large gamme d'applications.
Applications héritées dans l'entreprise.
Architectures personnalisées complexes pour chaque client.
Règles d'affinité.
Fonctionnement du logiciel sans interruption en mode 7x24.
Outils de sauvegarde « à la volée ».
Charge client prévisible et cyclique.
Applications standard - répartition de charge, Apache, WEB, VPN, SQL
Une interruption de l'application peut survenir pendant un certain temps
Une répartition arbitraire des VM dans le cloud est autorisée
Sauvegarde réalisée par le client
Charge prévisible statistiquement moyennée avec un grand nombre de clients.
Conséquences pour l'architecture
Géoclustérisation
Stockage centralisé ou distribué
Système de stockage redondant
Stockage local des données sur les nœuds de calcul
Objectifs de répartition de charge
Répartition uniforme de la charge
Maximum de réactivité des applications
Temps de latence minimal pour l'équilibrage
Équilibrage uniquement en cas de nécessité explicite
Sortie d'une partie du matériel pour maintenance préventive
Réduction des coûts du service et des dépenses de l'opérateur
Désactivation d'une partie des ressources en cas de faible charge
Économie d'énergie
Réduction des coûts de personnel
Nous tirons les conclusions suivantes:
Pour les clouds privés, fournis à de grands clients d'entreprise, DRS peut être appliqué sous réserve de certaines limitations :
- sécurité de l'information et prise en compte des règles d'affinité lors de l'équilibrage;
- disponibilité en réserve d'un volume de ressources suffisant en cas d'accident;
- les données des machines virtuelles se trouvent sur un système de stockage centralisé ou distribué.
- répartition dans le temps des procédures d'administration, de sauvegarde et d'équilibrage ;
- équilibrage uniquement au sein du groupe d'hôtes du client ;
- équilibrage seulement en cas de déséquilibre important, migrations de VM les plus efficaces et sécurisées (car la migration peut échouer) ;
- équilibrage par rapport aux machines virtuelles « au repos » (la migration des machines virtuelles « bruyantes » peut prendre beaucoup de temps) ;
- équilibrage en tenant compte du « coût » — charge sur le stockage partagé et le réseau (pour des architectures personnalisées pour de grands clients) ;
- équilibrage en prenant en compte les particularités de comportement de chaque VM ;
- préférablement en dehors des heures de travail (nuit, week-ends, jours fériés).
Pour les clouds publics, fournissant des services à de petits clients, DRS peut être appliqué beaucoup plus fréquemment, avec des capacités étendues :
- absence de restrictions de sécurité de l'information et de règles d'affinité ;
- équilibrage au sein du cloud ;
- équilibrage à tout moment raisonnable ;
- équilibrage de n'importe quelle VM ;
- équilibrage des machines virtuelles « bruyantes » (pour ne pas déranger les autres) ;
- les données des machines virtuelles se trouvent souvent sur des disques locaux ;
- prise en compte de la performance moyenne du stockage partagé et du réseau (architecture du cloud unifiée) ;
- équilibrage selon des règles généralisées et les statistiques de comportement du data center.
Complexité du problème
La complexité de l'équilibrage réside dans le fait que DRS doit fonctionner avec un grand nombre de facteurs indéterminés :
- comportement des utilisateurs de chacun des systèmes d'information des clients ;
- algorithmes de fonctionnement des serveurs des systèmes d'information ;
- comportement des serveurs de bases de données ;
- charge sur les ressources de calcul, le stockage partagé, le réseau ;
- interactions entre serveurs dans la lutte pour les ressources du cloud.
La charge d'un grand nombre de serveurs virtuels d'applications et de bases de données sur les ressources du cloud se manifeste dans le temps, avec des conséquences qui peuvent apparaître et se superposer de manière imprévisible à des moments imprévisibles. Même pour la gestion de processus relativement simples (par exemple, la gestion d'un moteur, le système de chauffage à eau d'une maison), les systèmes de régulation automatique doivent utiliser des avec rétroaction.
Notre tâche est de plusieurs ordres de complexité supérieure, et il existe un risque que le système ne parvienne pas à rétablir l'équilibre de la charge dans un temps raisonnable, même en l'absence d'interférences externes de la part des utilisateurs.
L'histoire de nos développements
Pour résoudre ce problème, nous avons décidé de ne pas partir de zéro, mais de nous appuyer sur l'expérience existante, et nous avons commencé à collaborer avec des spécialistes disposant d'une expertise dans ce domaine. Heureusement, notre compréhension des enjeux était entièrement alignée.
Étape 1
Nous avons utilisé un système basé sur une technologie de réseaux de neurones et avons tenté d'optimiser nos ressources sur cette base.
L'intérêt de cette étape résidait dans l'expérimentation d'une nouvelle technologie, et sa signification résidait dans l'application d'une approche non conventionnelle à la résolution du problème, où, dans d'autres cas similaires, les approches standard avaient pratiquement épuisé leurs possibilités.
Nous avons lancé le système, et la répartition a effectivement commencé. L'échelle de notre cloud ne nous a pas permis d'obtenir des résultats optimistes comme promis par les développeurs, mais il était clair que la répartition fonctionnait.
Cependant, nous avions des limitations assez sérieuses :
- Pour entraîner le réseau de neurones, il est nécessaire que les machines virtuelles fonctionnent sans modifications significatives pendant des semaines ou des mois.
- L'algorithme est conçu pour optimiser sur la base de l'analyse de données « historiques » antérieures.
- Un volume suffisamment important de données et de ressources de calcul est nécessaire pour entraîner le réseau de neurones.
- L'optimisation et la répartition peuvent être effectuées relativement rarement – toutes les quelques heures, ce qui est clairement insuffisant.
Étape 2
Comme la situation ne nous satisfaisait pas, nous avons décidé de modifier le système, et pour cela, il fallait répondre à la question principale – pour qui le faisons-nous ?
D'abord – pour les clients d'entreprise. Cela signifie que nous avons besoin d'un système fonctionnant rapidement, avec les contraintes d'entreprise qui simplifient uniquement la mise en œuvre.
Deuxième question – que devons-nous comprendre par le mot « rapidement » ? Suite à de brèves discussions, nous avons décidé que nous pouvions partir d'un temps de réponse de 5 à 10 minutes, afin que des pics temporaires ne mettent pas le système en résonance.
Troisième question – quelle taille du nombre de serveurs à équilibrer choisir ?
Cette question s'est résolue d'elle-même. En général, les clients ne rendent pas les agrégats de serveurs très grands, et cela correspond aux recommandations de l'article de limiter les agrégats à 30-40 serveurs.
De plus, en segmentant le pool de serveurs, nous simplifions la tâche de l'algorithme d'équilibrage.
Quatrième question – dans quelle mesure un réseau de neurones avec son long processus d'apprentissage et ses rares équilibrages est-il adapté pour nous ? Nous avons décidé de nous en passer au profit d'algorithmes opérationnels plus simples, afin d'obtenir des résultats en quelques secondes.
Vous pouvez consulter la description du système utilisant de tels algorithmes et ses inconvénients
Nous avons mis en œuvre et lancé ce système et obtenu des résultats prometteurs – il analyse régulièrement la charge du cloud et fournit des recommandations pour le déplacement des machines virtuelles, qui sont largement correctes. Même maintenant, il est clair que nous pouvons atteindre une libération de ressources de 10 à 15 % pour de nouvelles machines virtuelles, tout en améliorant la qualité de fonctionnement des machines existantes.
Lorsqu'un déséquilibre est détecté au niveau de la RAM ou du CPU, le système donne des instructions au planificateur Tionix pour effectuer la migration en direct des machines virtuelles requises. Comme le montre le système de surveillance, la machine virtuelle a déménagé d'un hôte (supérieur) à un autre (inférieur) et a libéré de la mémoire sur l'hôte supérieur (indiqué dans des cercles jaunes), occupant celle-ci respectivement sur l'hôte inférieur (indiqué dans des cercles blancs).
Maintenant, nous nous efforçons d'évaluer plus précisément l'efficacité de l'algorithme en cours et tentons d'y trouver d'éventuelles erreurs.
Étape 3
On pourrait penser qu'il serait alors judicieux d'attendre une efficacité prouvée et de clore le sujet.
Mais nous sommes poussés vers une nouvelle étape par les possibilités évidentes d'optimisation suivantes
- Les statistiques, par exemple, et montrent que les systèmes à deux et quatre processeurs ont une performance nettement inférieure à celle des systèmes à un seul processeur. Cela signifie que tous les utilisateurs bénéficient de CPU, RAM, SSD, LAN, FC achetés dans des systèmes multiprocesseurs avec un rendement bien inférieur par rapport aux systèmes à un seul processeur.
- Les planificateurs de ressources eux-mêmes peuvent travailler avec des erreurs significatives, à ce sujet.
- Les technologies de surveillance de la RAM et du cache proposées par les entreprises Intel et AMD permettent d'étudier le comportement des machines virtuelles et de les positionner de manière à ce que les voisins « bruyants » n'entravent pas le fonctionnement des machines virtuelles « tranquilles ».
- L'expansion de l'ensemble des paramètres (réseau, stockage, priorité de la machine virtuelle, coût de migration, sa préparation à la migration).
Au total
Le résultat de notre travail sur l'amélioration des algorithmes d'équilibrage a été une conclusion claire : grâce aux algorithmes modernes, il est possible d'optimiser considérablement les ressources (25-30 %) des centres de données tout en améliorant la qualité du service client.
L'algorithme basé sur des réseaux neuronaux est sans aucun doute intéressant, mais nécessite un développement ultérieur et, compte tenu des limitations existantes, ne convient pas à ce type de tâches pour des volumes caractéristiques des clouds privés. En revanche, dans les clouds publics de grande taille, l'algorithme a montré de bons résultats.
Nous parlerons plus en détail des capacités des processeurs, des planificateurs et de l'équilibrage de haut niveau dans les prochains articles.
Source : habr.com
