Accueil > vCOps > Configuration du Capacity Planning dans vCenter Operations
Juil/14240

vCOps-CapIQ_settingsvCenter Operations Manager est un produit super puissant pour la gestion opérationnelle; de par ses tableaux de bord synthétiques, son approche drill-down, l’autoapprentissage, la proactivitée, la gestion de la capacité et de l’optimisation… Cependant malgré la facilité de mise en oeuvre et d’utilisation du produit (à partir du moment où l’on a compris la philosophie qui va avec), le produit nécessite que l’on modifie sa configuration pour en tirer la pleine puissance et qu’il soit en phase avec votre plateforme.
Le but de cet article est donc d’expliquer l’ensemble des paramètres de configuration qui influe sur la Capacity Planning de vC Ops afin de comprendre l’intérêt de ces paramètres. Dans le prochain article, je donnerai un exemple de paramétrage initial recommandé.

Quelques remarques avant toucher la configuration:

  • La configuration expliquée dans cet article s’applique à vC Ops version 5.7.x et 5.8.x. Il peut y avoir des différences pour les versions antérieures 5.0 et 5.6.
  • Les badges de capacité ne sont recalculés que tous les soirs à minuit. Après modification des paramètres, les badges n’en prendront compte que le lendemain, par contre les rapports sont modifiés dès validation des paramètres.
  • Le Capacity Planning de vC Ops est issu du produit CapacityIQ, qui a été intégré directement dans le moteur vC Ops depuis la version 5.0. Les concepts restent les mêmes et certains white-papers sur CapIQ sont encore d’actualité.

La configuration du Capacity Planning est disponible en haut à droite de l’interface « vsphere-vcops » (Standard). Pour y accéder cliquer sur Configuration > Manage Policies, sélectionner une policy (par exemple la Default Policy) et double-cliquer dessus ou cliquer sur l’icône « Edit« .

vCOps-configuration

3a Capacity and time remaining

Cette section permet de définir les critères à prendre en compte pour calculer la Capacité restante et le Temps restant.

Spikes and Peaks: prend en compte l’usage en pointe, ce qui donne une approche plus conservative sur la consommation de ressources, ce qui diminue le nombre de « remaining VMs ». Si la case n’est pas cochée, on prend l’usage moyen des ressources.
Capacity Remaining is based on: détermine la capacité de ressources utilisables

Physical or Configured Capacity correspond à la capacité maximale des ressources (100% des ressources).
Usable Capacity correspond à la capacité réellement utilisable en prenant en compte les réserves d’utilisation (ex: la réserve de panne HA). Voir section 3b pour configurer la capacité utilisable.

Dans le schéma ci-dessous, on retrouve la représentation de la capacité physique et virtuelle. Seule celle physique concerne le paramètre de capacité évoqué précédemment, mais l’ensemble est intéressant pour comprendre ce que l’on retrouve sur la page « Summary » de l’onglet « Planning ». La « Total Capacity » correspond au paramètre « Physical or Configured Capacity », la « Usable Capacity » qui correspond à la capacité utilisée et celle restante, et la « Unusable Capacity » à la réserve de capacité configurée dans la section 3b.vCOps-Capacity

Time remaining is based on: contient les paramètres utilisés pour calculer le score du badge « Time Remaining » et donc permet d’être alerté assez tôt pour réagir.
Le premier menu déroulant est la méthode à utiliser avec l’algorithme pour la projection.

Planning Cyclical utilise les données projetées et l’algorithme
Real Time utilise les données temps réel et l’algorithme

Le chiffre ensuite est le nombre de jours minimums de réactivité pour l’approvisionnement de ressources. C’est-à-dire le temps minimum nécessaire pour commander et mettre en place des ressources physiques supplémentaires.
Le score du badge « Time Remaining » est calculé d’après la formule suivante:

vCOps-TimeRemaining-score

Demand or Allocation by Compute Ressource: détermine quelle méthode utilisée dans le calcul du temps restant pour chacun des types de ressources (VM, Datastore et Containers) et les ressources (CPU, Mémoire, I/O disque, espace disque et I/O réseaux) à prendre en compte dans le calcul. Le World, les vCenters, DataCenters, Clusters et Hosts sont des Containers, mais pas les Custom Groups.
Le modèle « by Demand » utilise les ressources demandées comme ressources utilisées, alors que le modèle « by Allocation » considère les ressources allouées comme utilisées à 100% et le reste des ressources non allouées comme capacité restante. Le modèle par Allocation est beaucoup plus conservatif (par ex: un vDisk en Thin en alloué équivaut à sa taille en Thick).
NB: Si les 2 cases « Demand » et « Allocation » sont cochées, c’est la valeur la plus contraignante qui sera utilisée. De même, les réservations CPU et RAM sont toujours prises en considération.

 

3b Usable Capacity

Cette section définit les critères de réserve et de calcul pour fixer la capacité réellement utilisable.

Usable Capacity Rules: définit les règles à prendre en compte comme capacité de réserve et permet donc de déterminer la capacité de ressources réellement utilisable. N’est pris en compte que si activé dans la section 3a.

Use HA configuration prend en compte la quantité de CPU et de RAM réservée par l’Admission Control Policy dans le Cluster HA (à condition d’être activé).
% of capacity to reserve as buffer définit le pourcentage de capacité réservé comme marge de sécurité.

Capacity Calculation Rules: détermine si c’est la capacité courante ou historique qui est utilisée pour les calculs

Use last known capacity correspond à la valeur actuelle de la capacité
Use actual capacity correspond à la valeur moyenne de la capacité sur l’intervalle de données.

3c Usage calculation

Cette section définit les critères de calculs de l’utilisation et de surallocation.

Usage Work Week: détermine la période de temps dans la semaine pendant laquelle les métriques sont interprétées pour calcul la capacité moyenne. La capacité moyenne est ainsi calculée en se basant sur l’inventaire et les données de performances collectées par jours.

All hours on all days correspond à une activité continue (24 x 7)
Specific hours and days permet de définir les jours et la plage horaire d’activité de l’environnement

Le schéma ci-dessous à gauche représente le paramètre « All hours on all days », l’usage nominal de la plateforme est continu et l’analyse de capacité est faite par l’usage moyen par jour pour l’ensemble de la journée pour l’ensemble de la semaine. Alors que le schéma de droite représente le paramètre « Specific hours and days », l’usage nominal de la plateforme correspond aux heures ouvrées de l’entreprise et l’analyse de capacité est également faite par jour, mais sur une tranche horaire restreinte pour un nombre de jours restreint.
vCOps-usage-work-week

Allocation Overcommit Ratios: détermine les seuils de surallocation autorisés de ressources dans le cas d’une capacité et du temps restant basé sur l’allocation (section 3a). Ne s’applique qu’aux « Containers ».

 

4a Powered off and idle VMs

Cette section définit les critères pour considérer une VM comme éteinte ou inactive.

Powered-Off VM Detection Rules: correspond au pourcentage de temps où la VM est éteinte sur l’intervalle de temps.

Le schéma ci-dessous représente la proportion de temps éteint d’une VM, ici l’état est binaire. On considère l’ensemble du temps éteint par rapport à l’intervalle d’analyse.

vCOps-PowerOff-VMs

Idle VM Detection Rules: correspond au pourcentage de temps où la VM est considérée comme inactive sur l’intervalle de temps. Par VM inactive, il faut comprendre que la machine est allumée, mais non-utilisée car son activé est en dessous des seuils minimums d’activité définit ici. Cette zone d’inactivité peut correspondre à n’importe quel critère (« Any« ) équivalent à un OR, ou à l’ensemble des critères (« All« ) équivalent à un AND.

Le schéma ci-dessous représente la proportion de temps qu’une VM est considérée inactive. On prend l’ensemble du temps où l’activité est en dessous des seuils par rapport au temps total de l’intervalle d’analyse.

vCOps-Idle-VMs

4b Oversized and undersized VMs

Cette section définit les critères (seuils d’activité) pour considérer une VM comme surdimensionnée ou sous-dimensionnée.

VMs are oversized when: détermine les critères pour définir qu’une VM est surdimensionnée.
La VM est vue comme surdimensionnée (ou sous-utilisé) quand la quantité de CPU/RAM demandée est en dessous des seuils définis. Mais en plus de cela, il faut que cette quantité de sous-utilisation soit supérieure à X % de la zone totale de sous-utilisation (is more than X% for the entire range). Cette zone totale de sous-utilisation correspond aux seuils minimums de demande de ressources par l’intervalle de temps des vues « Non-Trend ».

Le schéma ci-dessous représente le degré (ou le pourcentage en multipliant par 100) de sous utilisation d’une VM. Elle est considérée sous-utilisé quand elle passe en dessous des seuils d’activité, par contre ce que l’on considère ici c’est la proportion entre la zone de sous-utilisation de la VM (zone bleue) par rapport à la zone totale possible de sous-utilisation (zone grise) et ce sur l’intervalle de temps total.

vCOps-Oversized-VMs

VMs are undersized when: détermine les critères pour définir qu’une VM est sous-dimensionnée.
Comme pour les critères de Oversized, mais à l’inverse, la VM est vue comme sous-dimensionnée quand la quantité de CPU/RAM demandée en pointe est au dessus des seuils définis et qu’elle dépasse une quantité de surutilisation. Comme pour les critères Oversized, la zone totale de surutilisation peut être basée sur l’intervalle de temps total (Entire range), mais en plus on peut choisir un échantillonnage plus court (Any X hour period) ce qui permet de mieux prendre en compte les pointes d’utilisation fugaces.

A l’inverse du schéma précédent, le schéma suivant représente le degré de sous dimensionnement d’une VM. On considère la proportion entre la zone de surutilisation (zone bleue) par rapport à la zone totale possible de surutilisation (zone grise) pour l’intervalle total de temps.

vCOps-Undersized-VMsLe schéma suivant montre le besoin éventuel d’un échantillonnage plus court pour détecter le sous-dimensionnement. En effet, avec cet exemple de charge de travail d’une VM, la méthode classique (« Entire Range ») consiste à analyser la somme des zones vertes par rapport à la zone grise (ici 4 semaines), ce qui représente un undersized de 0,01% (autant dire non-détectable). Alors qu’avec un échantillonnage plus court avec le paramètre « Any 4 hour périod », l’analyse est faite sur la plus grande zone verte par rapport à la zone rouge pour tout l’intervalle de temps d’analyse, ce qui représente ici un undersized de 10%. vCOps-Undersized-VMs-sampling

NB: Oversized VS Undersized: Il est important de bien définir les seuils de ces critères, car sinon il est possible d’avoir une VM qui soit à la fois Oversized et Undersized. Comme on peut le voir dans l’exemple ci-dessous, les courbes bleues et vertes représentent l’utilisation en capacité de 2 VMs. On voit clairement que la VM en bleu est sous-dimensionnée, par contre la VM en vert peut à la fois être sous-dimensionnée et surdimensionnée.

vCOps-2VMs-CapUsage

 

4c Underuse and stress

De la même manière que pour les VMs (section 4b) cette section s’applique aux Containers (World, vCenters, DataCenters, Clusters et Hosts) et définit les critères pour les considérer comme sous-utilisés ou stressés (saturé). Ce qui permettra facilement d’identifier la charge d’un cluster ou d’un host avant de déployer des VMs.

Containers are underused est la même méthode de calcul que le Oversized VMs.

Le « underused » des Datastores permet de définir au bout de combien de jours de leur création les Snapshots et les Templates sont considérés comme du Waste.

Containers have stress est la même méthode de calcul que le Undersized VMs. Il y a en plus l’option Consider allocation in stress calculation, qui permet d’utiliser un modèle l’allocation pour calculer le stress. C’est à dire de considérer les ressources allouées aux VMs (plutôt que la consommation réelle) pour calculer le stress au niveau Container (par ex: Host) dans la limite des seuils de surallocation autorisée (section 3c).

6 Configure forecast and trends

Cette section définit les critères et les fonctions mathématiques pour prédire une tendance (Trend) faire la projection (Forecast) de consommation de ressources de l’environnement. On est ici clairement dans le domaine des probabilités (moyenne, valeur pondérée, moyenne arithmétique/géométrique, variance…).

Le schéma ci-dessous permet d’illustrer ces concepts:

  • « Data Points » sont la valeur moyenne de capacité utilisée par intervalle. Ces points peuvent éventuellement être exclus (« outlier« ) ou être rapprochés (« smooth« ) de la tendance (ceci n’étant pas représenté sur ce schéma).
  • « Trend » est la courbe de tendance de capacité utilisée. Cette courbe est basée sur l’ensemble des « Data Points« .
  • « Forecast » est la projection dans le futur de cette tendance.
  • « Forecast Horizon » est la durée dans l’avenir de cette projection.
  • « Used Capacity » est la capacité moyenne actuellement utilisée.
  • « Remaining Capacity » est la différence entre la capacité utilisable et la capacité actuellement utilisée.
  • « Time Remaining » est le temps restant avant que la projection arrive à la capacité utilisable.

vCOps-Trend-Forecast

Dans Forecast Functions, Do not forecast answers beyond X% of the time range permet de limiter la projection dans le temps à X% de l’intervalle de temps utiliser pour l’analyse. S’il n’y a pas assez de données pour faire une projection, le « Time Remaining » sur le « Dashboard » affichera des (-) à la place des valeurs.

Forecast Method: définit la méthode mathématique utilisée pour faire la projection dans le temps par rapport à l’ensemble des valeurs analysées, soit automatiquement soit en la forçant.
Select Best Fit from all Forecasts Methods choisit automatiquement la meilleure méthode mathématique avec la possibilité de filtrer certaines valeurs:

Eliminate functions that have greater than X% curvature change beyond fitted data and prior to forecast limit: ne pas utiliser de fonctions mathématiques qui prédisent une tendance avec une trop forte croissance/décroissance (avec plus de X% de variation de la courbe).
Eliminate non-linear functions for data sets less than X points: force l’utilisation de la fonction linéaire pour les projections basées sur moins de X points.

Force Forecast Method permet de forcer l’utilisation d’une fonction mathématique pour réaliser les projections. Voici les fonctions disponibles et leur explication:

Fonctions Equation Notes
Linear y = mx + b m est la pente et b est l’ordonnée à l’origine
Logarithmic y = c ln(x) + b c et b sont des constantes et ln est la fonction logarithme naturel ou népérien
Power y = cxb c et b sont des constantes
Exponential y = c exp(bx) c et b sont des constants et exp est la fonction exponentielle
Polynormial y = b + c1x + c2x2 + … + c6x6 b et c1c6 sont des constantes

Trend and Forecast Data Filter: définit s’il faut filtrer certaines valeurs qui pourraient fausser la projection (par exemple des anormalités ou des changements soudains).
Trend collected data with no filtering pour ne pas appliquer de filtre des valeurs.
Apply one or more smoothing filters prior to trending pour appliquer des filtres de détection des valeurs aberrantes et de lissage des valeurs.

Smooth data prior to fit pour activer une fonction de lissage des valeurs. Voici les fonctions disponibles:

  • EWMA (Exponentially Weighted Moving Average) calcule chaque point comme une moyenne pondérée des points précédents de telle sorte que le poids ou l’importance est plus fort pour les points les plus récents.
  • GWMA (Geometrically Weighted Moving Average) applique une moyenne géométrique pondérée au lieu d’une moyenne arithmétique. GWMA est plus stable parmi les fluctuations que EWMA.
  • Lifetime Average calcule chaque point lissé comme une simple moyenne arithmétique des points précédents.

Detect outliers and plateaus using progressive fit analysis pour activer la détection de valeurs aberrantes

Outlier detection variance limit X% définit un seuil d’erreur contre les ajustements progressifs qui font partie de l’algorithme de détection des valeurs aberrantes, c’est-à-dire le seuil de variance autorisé avant d’exclure un point.
Outlier percentage of data allowed before giving up définit le pourcentage de points détectés comme aberrants qui peuvent être exclu pour définir la projection. Ce qui permet d’éviter de détecter trop de valeurs aberrantes et que l’ensemble des données devienne trop petit pour continuer la détection des valeurs aberrantes. Ce pourcentage de nombre de points est arrondi au nombre entier supérieur.

NB: Les méthodes de détection d’erreur et de lissage affectent la représentation des valeurs dans les rapports de capacity planning.

  • Les valeurs aberrantes sont affichées dans les rapports, mais sont entourées d’un cercle pour indiquer qu’elles ne sont pas prises en compte.
  • Les valeurs lissées sont affichées dans les rapports et non les valeurs d’origine. Dans la vue tableau de ces rapports, elles sont représentées avec un symbole (S).
  • En cas de combinaison des 2 méthodes, la détection est appliquée avant le lissage. C’est-à-dire que par exemple sur 10 points, 2 points sont exclus par la détection (affiché comme exclut avec un cercle), le lissage est appliqué sur les 8 points restants (affiché avec un (S)).

 

Summary, Views and Reports

L’édition des paramètres de l’intervalle d’analyse et de l’affichage du capacity planning se trouve dans Manage Display Settings de la Configuration.

NB: L’intervalle de temps « Daily » et « Weekly » dans les vues, dashboards et les paramètres globaux est basé sur l’heure local de l’appliance (définit lors de l’installation). Alors que pour l’intervalle de temps « Monthly » et « Quartely » est exprimé par rapport à l’heure universelle (UTC). Un écart important entre la TimeZone et l’UTC peut avoir un impact quand on passe, par exemple, d’un intervalle « Weekly » à « Monthly ».
Summary: définit l’intervalle de temps affiché dans la page « Summary » de l’onglet « Planning« , c’est par exemple l’intervalle représenté par chaque barre graphique. Ici l’intervalle a besoin d’une quantité minimum de valeurs collectées pour que la projection soit efficace (Cf. tableau ci-dessous).

Intervalle Période minimale de collecte de données
Daily 12 jours (∼ 2 semaines)
Weekly 12 semaines (∼ 3 mois)
Monthly 12 mois (1 an)
Quarterly 12 trimestre (3 ans)

Trend View définit l’intervalle de temps dans les vues de type « Trend »

Default interval est l’intervalle de temps entre chaque point
Default time windows est le nombre de points collecté à afficher (le passé)
Forecast horizon est le nombre de points de projection à afficher (le futur)

Non-Trend View définit l’intervalle de temps dans les vues de type « Summary » et « List ».

Interval to use est l’intervalle de temps entre les valeurs à considérer, même si l’affichage ne présente que ces valeurs combinées en une seule.
Number of interval to use est le nombre de valeurs à considérer dans les vues.

Distribution View: définit le nombre de regroupements de distribution à afficher dans les vues de type « Distribution ».

Trend & Forecast: définit le nombre de points à prendre en considération pour calculer la projection. En rapport direct avec la méthode de calcul et de filtrage (section 6).

Reports définit la période et l’intervalle pour les rapports CSV/PDF

Report Period est le périmètre de données à prendre en compte dans le rapport.
Interval Start est l’intervalle utilisé dans le rapport, soit le courant (Current Interval) soit X intervalles avant (Offset X Intervals ago)
Report Interval est l’intervalle de temps utilisé dans le rapport pour regrouper les données.

Et enfin, un peu de lecture pour continuer sur ce sujet:

  • une série d’articles « Tech Tips » pour vC Ops : Best Practices for vSphere Capacity Planning – part 1234 / 4
  • 2 articles sur le blog d’un consultant VMware: VMware vCenter Operation Manager in Real Life – Capacity Planning Models & Usable Capacity
  • une série de 5 articles sur le blog « Software Defined »: Tuning vC Ops for your environment – part 12345 / 5
  • un white-paper sur la gestion de la capacité avec CapacityIQ: « Managing Capacity using VMware vCenter CapacityIQ« 
  • et pas mal de choses intéressantes sur vC Ops sur ce blog: VirtualClouds.co.za