Accueil > vCOps > Configuration recommandée pour vCenter Operations
Juil/1428

Comme expliqué dans le précédent article, il y a pas mal de paramètres de configuration du Capacity Planning dans vCenter Operations. Mais il n’y a pas de configuration standard pour tout le monde et justement les paramètres par défaut de la « default policy » ne correspondent pas forcément à votre environnement. Le but de cet article n’est donc pas de fournir le paramétrage idéal, mais de vous permettre de comprendre l’intérêt de ces paramètres et de proposer une configuration initiale recommandée.

La première chose importante est de comprendre que cela fonctionne comme une balance quand on joue sur les paramètres (voir ci-dessous). Il est donc important de savoir comment on utilise la plateforme dans sa globalité et ses sous-ensembles:

CapacityMangement-Balance

De plus, il est souvent utile de mettre en place plusieurs profils de configuration pour les différents types de workload (ex: Prod / Dev …) tournant sur la même plateforme ou dans un autre cluster, car les besoins sont souvent mixtes ou spécifiques.

Pour cela, vC Ops dispose d’ensemble de politiques prédéfini dans l’outil depuis la version 5.7. Voici les profils proposés dans vC Ops:

  • Default Policy: c’est la politique par défaut qui est associée avec tous les groupes pour lesquels il n’y a pas de politique sélectionnée.
  • Original Default: c’est la politique d’origine de vC Ops. Pour la politique par défaut d’origine, le stress est inclus dans la capacité et le temps restants (voir section 3a). Mais, l’allocation de ressources n’est pas incluse dans le calcul du stress (voir section 4c).
  • Optimized for 15-minute peak period: cette politique permet de détecter les ressources utilisant plus de 100% de leur capacité utilisable pendant plus de 15 minutes par heure, ce qui équivaut à une demande supérieure à 35% pour plus de 10% de la zone de stress de la période totale. Les alertes de type risks sont désactivées. La capacité est basée sur la capacité utilisable avec seulement prise en compte de la demande (par l’allocation).
  • Optimized for 30- minute peak period: cette politique permet de détecter les ressources utilisant plus de 100% de leur capacité utilisable pendant plus de 30 minutes par heure, ce qui équivaut à une demande supérieure à 60% pour plus de 10% de la zone de stress de la période totale. Les alertes de type risks sont désactivées. La capacité est basée sur la capacité utilisable avec seulement prise en compte de la demande (par l’allocation).
  • Excludes over-sized analysis: à utiliser si votre entreprise autorise l’existence de VM surdimensionné dans la plateforme. Par exemple, si vous fournissez certaines VMs avec assez de ressources pour couvrir avec la plus grosse puissance possible, ces machines peuvent être considérées comme surdimensionnées alors que leur charge est normale. Vous pouvez créer un groupe séparé pour ces machines hautement-provisionnées et assigner cette politique pour leur groupe, alors ces machines ne seront pas incluses dans le calcul de la valeur des badges en relation avec la capacité. Les spécificités de cette politique sont que le calcul des ressources est basé sur la demande et pas l’allocation; aucune surallocation n’est autorisée; le calcul de VMs surdimensionnées est désactivé.
  • Ignore these objects: à utiliser pour les environnements de test et développement. Cette politique désactive tous les paramètres d’alertes et les seuils des badges. En complément, cette politique est basée sur la capacité utilisable (avec une réserve de 30%); un calcul des ressources à la demande et non l’allocation; pas de surallocation; les seuils power-off, idle sont augmentés; les seuils undersized VM et Stress sont baissés; la projection linéaire est forcée avec filtrage des valeurs erronées.
  • Production environment: à utiliser pour la production dans le monde réel. Les modèles basés sur la demande et sur l’allocation sont configurés. Utilise une fenêtre glissant de 4 heures pour les mesures. Les seuils des objets Container pour le  CPU et la RAM sont définis pour une demande supérieure à 40% pour plus de 10% de la zone de stress de la période configurée (voir section4c). En plus, le calcul est basé sur la capacité utilisable (avec une réserve de 60%) et le calcul de ressource basé à la fois sur la demande et sur l’allocation; toutes les alertes sont activées; les projections linéaires sont préférées avec la détection des valeurs erronées.
  • Test and development environment: à utiliser pour les environnements de test et développement. Utilise les paramètres par défaut courant, et un modèle basé sur la demande (et non l’allocation, ni la surallocation), dans lequel les ressources demandées sont utilisées pour déterminer la capacité restante (voir section3a). Seules les alertes de type fault sont activées (voir section5). De plus, les 2 premiers seuils de badge fault sont désactivés et les sous-badges de Risk sont redescendus; les seuils de undersized et stress sont descendus; les projections linéaires sont préférées avec la détection des valeurs erronées.
  • Batch workloads: Similaire à la politique pour la production, mais optimisé pour le throughput. Utilise une fenêtre glissante de 8 heures pour les mesures et les alarmes Density sont désactivées. Cette politique correspond à des serveurs ayant une forte activité ponctuellement (par ex. serveur de sauvegarde).
  • Interactive workloads: Similaire à la politique pour la production, mais optimisé pour les temps de réponse. Utilise une fenêtre glissante de 1 heure pour les mesures et les alarmes Density sont désactivées. Cette politique correspond à des serveurs ayant en permanence une charge importante (par ex. des serveurs Web).

NB: depuis la version 5.8, ces règles sont toujours présentes, mais moins visibles, car elles ne sont disponibles que comme modèle à la création d’une nouvelle politique (« Clone from »).

Voici un exemple de configuration recommandée initiale pour la « Default Policy« :

Infrastructure badge thresholds

vCOps-defconf-2a
Descendre les seuils du badge « Health » pour qu’ils soient en correspondance à l’inverse des badges « Anomalies ». Pour que l’état du « Health » ne soit pas trop bruyant.

Augmenter les seuils du badge « Stress » pour que le Stress apparaisse sur des charges de travail plus importantes.

VM badge thresholds

vCOps-defconf-2b
Comme pour les badges Infrastructure, descendre les badges « Health » en concordance avec l’anormalité et augmenter les badges « Stress ».

Groups badge thresholds

vCOps-defconf-2c
Il n’y a pas besoin de modification pour les seuils de badges pour les groupes. Seulement faire des changements si vous souhaitez appliquer des pondérations différentes sur les populations, afin d’avoir une coloration des badges plus intuitive.

Capacity and time remaining

vCOps-defconf-3a
Laisser coché la case « Use stress to account for spikes and peaks ». Cela permet d’avoir une capacité basée sur l’usage en pointe à travers les tranches horaires (lié au Stress) plutôt qu’un usage moyen sur la journée.

Cocher la case « Usable Capacity » pour utiliser la capacité réelle qui prend en compte les réserves de puissance plutôt que la capacité absolue. Dans certains cas, on peut déjà voir apparaitre de la contention alors que l’on est seulement à 50% de la capacité absolue.

Ici on recommande (dans un premier temps) de ne pas utiliser la consommation basée sur l’allocation, mais plutôt de considérer toute la demande (sauf la demande en espace disque des containers). Et de manière générale, la gestion de l’espace de stockage est souvent gérée à un autre niveau que la virtualisation, car le stockage n’est pas dédié à la virtualisation.

Pour la mémoire, si la surallocation mémoire (0% de surallocation mémoire en section 3c) est interdite, il faut plutôt sélectionner la consommation mémoire à l’allocation pour les containers, la demande pour les VMs et pas la demande pour les containers. Alors que si vous autorisez la surallocation mémoire, il faut sélectionner la consommation mémoire à la demande pour les VMs et les containers, mais pour à l’allocation pour les containers.

Pour les I/O disques, ne pas prendre en compte la demande (Datastore et Containers), si la baie de stockage fait de l’autotiering.

Pour l’espace disques, ne pas prendre en compte l’allocation (Datastore et Containers) ni la demande des Datastore, si les volumes sont en Thin-Provisionning et que vC Ops ne voit pas l’espace réellement disponible.

Usable capacity

vCOps-defconf-3b
Ajouter la prise en compte réserve des ressources initialement de 20% (sauf pour l’espace disque de 10%) et l’augmente par la suite en fonction du besoin. Généralement, on constate du Stress avant d’arriver à saturation de la capacité. Il peut être intéressant de rajouter de la réserve pour les futurs projets inconnus et pour les serveurs ayant des pointes de fonctionnement.

Pour les charges de type interactive, on peut aller jusqu’à 65% de réserve.

Pour la charge serveur classique, on peut aller jusqu’à 45% de réserve.

Pour les charges de type batch, on n’ajoute pas de réserve (0%).

Baser la calcule de la capacité sur la capacité courante (« Use last known capacity »), car c’est la manière de penser de la majorité des gens.

Usage calculation

vCOps-defconf-3c
Affiner le calcul sur la période d’activité de l’entreprise pour un usage classique et éviter les périodes de maintenance ou de batchs. Mais cela dépendra de l’usage de la plateforme dans votre contexte. Même si la réduction de la fenêtre est une recommandation initiale, il peut être utile d’étendre à la semaine complète, car le produit en fait pour se focusser l’activité principalement en ayant une visibilité totale ce qui permet de voir aussi des comportements inattendus.

Les seuils de surallocation sont à prendre avec des pincettes, car le surprovisionning de ressources virtuelles peut la plateforme en risque même si la demande semble correcte. On voit généralement :

  • une surallocation CPU avec un ratio de 2:1 voir même 4:1, mais pas au-delà (à l’exception du VDI).
  • Une surallocation RAM de 100+20% voir même jusqu’à 100+50%, mais pas au-delà (sauf en utilisant du swap sur SSD). Certains besoins interdisent la surallocation mémoire (ex: serveur SAP ou Citrix) ou tout simplement l’entreprise refuse de prendre le risque.
  • Une surallocation d’espace disque à (100+)0% pour les disques en Thick. Pour le Thin on recommande 100+50%, mais on peut pousser jusqu’à 100+200%.

Powered off and idle VMs

vCOps-defconf-4a
Il est souvent plus pertinent de détecter les machines éteintes quand elles le sont en permanence (100%). Cependant, d’un point de vue visibilité, il peut être intéressant de descendre si l’on souhaite connaitre les machines rarement allumées en sachant qu’on a le pourcentage d’utilisation dans les rapports.

Pour l’inactivité, généralement on décoche l’usage des I/O disques, car pour certaines versions de vCenter ancienne ne remonte pas les I/O disques ainsi des VMs peuvent être vue comme faussement inactive en disque. On pousse rarement l’inactivité à 100%, car il y a souvent des antivirus ou des updates qui continuent de travailler dans les VMs inactives.

Oversized and undersized VMs

vCOps-defconf-4b
Pour les seuils de détection du dimensionnement, on baisse un peu le CPU, car il est traditionnellement moins sollicité que la mémoire.

Il est souvent plus fin d’utiliser une fenêtre glissante pour le calcul de la saturation. Pour des serveurs traditionnels, on utilise une fenêtre de 4h, pour les charges interactives, une fenêtre de 1h (pour mieux cibler les piques) et pour les charges batch une fenêtre de Xh (où X est la durée classique du traitement).

Underuse and stress

vCOps-defconf-4c
Pour le « Underuse & Stress » des hosts, on fonctionne de la même manière que pour les VMs, mais avec des seuils souvent plus bas. Vu le fonctionnement très dynamique des hyperviseurs, on utilise une fenêtre glissante d’une heure.

Alerts

vCOps-defconf-5
Initialement, on désactive toutes les alertes (à l’exception de celles pour la Workload et le Fault) puis remettre les alarmes Stress (pour les VMs et les Containers) et Time Remaining (Containters) après une période d’apprentisage. Cela évite d’être pollué d’alertes non pertinentes les premiers mois. Le reste des alarmes peut être réactivé plus tard avec une bonne maitrise de l’outil et l’ajustement des politiques et des groupes.

Le fait de désactiver les alarmes de certains badges n’empêche pas d’avoir l’information et de la prendre en compte lors du troubleshooting. Par exemple les badges Anormalites seuls ne sont pas l’évidence d’un problème, mais ils sont souvent un bon indicateur lors du troubleshooting.

Forecast and trends

vCOps-defconf-6
Sélectionner la forte préférence pour les fonctions linéaires dès qu’il n’y a pas assez de points ou une trop grande variation. En effet, la fonction linéaire est souvent plus pertinente sur un nombre plus restreint de collectes et il est rare d’avoir des variations brusques de la capacité.

Les méthodes de filtrages des valeurs erronées par défaut sont souvent bonnes et permettent d’éviter certains piques qui peuvent provoquer une projection plutôt «comique».

Display settings

vCOps-defconf-display
Il n’y a pas grand-chose à modifier à l’exception de l' »Horizon forecast » que l’on recommande à 1/3 ou 1/4 de la « Time Windows ».

  1. Alexandre HUGLA
    30/07/2014 à 15:19 | #1

    SUPERBE synthese !!
    AWESOME

  1. 29/07/2014 à 11:06 | #1