Skip to content
Advertisement
2014/02/17 / vpourchet

VMware vCloud Automation Center (vCac) 6.0 : Considérations d’optimisation

    Pour garantir l’optimisation de l’infrastructure vCloud Automation Center 6.0, VMware recommande de prendre en considération les recommandations suivantes lors du déploiement Initial de l’infrastructure, et ce, afin d’optimiser les performances en fonction de l’utilisation de la solution au fil du temps.

Composants vCloud Automation Center (vCac)

 

    Collecte des données

 

    Le temps nécessaire à la collecte des données dépend de plusieurs facteurs tels que la capacité de la ressource de calcul ou le nombre de machines sur le endpoint, la charge courante du système et celle du réseau (entre autre).

    Chaque type de collecte à un intervalle par défaut qui peut être modifié. Les administrateurs IaaS peuvent initier la collecte manuellement pour les endpoints et les Fabric admin peuvent initier manuellement la collecte pour les ressources de calcul. Le tableau suivant récapitule les valeurs des intervalles par défaut :

    Analyse des performances et optimisation

    Lorsque le volume de ressources sur lesquelles la collecte des données intervient augmente, le temps requis pour collecter les données augmente et peut devenir supérieur à l’intervalle par défaut, particulièrement pour la collecte des données d’état. Vérifier la page de Collecte des Données d’une ressource ou d’un endpoint pour déterminer si la collecte des données est complétée à temps ou si la collecte est mise en file d’attente (queued). Si le champ ‘Last Completed’ indique ‘In Queue’ ou ‘In Progress’ au lieu d’un date-time, alors il peut être nécessaire de diminuer la fréquence de collecte en augmentant l’intervalle entre les collectes.

    Une alternative peut-être d’augmenter la limite de collectes concurrentes par agent. Par défaut vCac limite les collectes concurrentes à deux collectes par agent et met en attente les requêtes qui dépassent cette limite. Ceci permet aux collectes de se terminer rapidement sans affecter les performances globales. Il est possible d’augmenter la limite pour prendre l’avantage des collectes concurrente mais ceci doit-être pesé au détriment d’une dégradation des performances.

    Si la limite de collectes par agent est augmentée, il peut être nécessaire d’augmenter un ou plusieurs des intervalles de timeout, la collecte étant intensive en consommation CPU pour le Manager Service, l’augmentation de la puissance de calcul du serveur hébergeant le Manager Service peut conduire à une réduction du temps nécessaire à la collecte.

    La collecte pour les endpoints Amazon EC2 est particulièrement consommatrice en CPU, spécialement lorsque la collecte est effectuées sur des régions multiples et lorsque qu’aucune collecte n’as été effectuée au préalable. Ceci conduit à une dégradation des performances du SiteWeb et VMware recommande de diminuer la fréquence de collecte sur les endpoints Amazon si elle conduit à une dégradation perceptible des performances.

Exécution de workflow

 

Le temps moyen d’exécution de workflow (entre l’instant ou le DEM Orchestrator démarre le Workflow et celui ou le Workflow se termine) augmente avec le nombre de Workflow concurrents. Le volume de Workflow est fonction de l’activité globale du système vCac incluant les requêtes de machines et les activités de collecte des données.

Analyse des performances et optimisation

    Utiliser le page ‘Distributed Execution Status’ pour voir le total de Workflow en cours ou en attente et utiliser la page ‘Workflow History’ pour déterminer la durée moyenne d’exécution d’un Workflow donné.

    Si le nombre de Workflows en attente est trop large ou si les workflows mettent plus de temps à s’éxécuter, alors il faut ajouter des instances de DEM Worker qui vont aller piocher dans la file d’attente. Chaque instance DEM Worker peut exécuter jusqu’à 15 workflows en parallèle.

    Additionnement, il est possible d’ajuster la planification des Workflows pour minimiser le nombre de workflows planifiés s’exécutant à un instant T. Par exemple, plutôt que de planifier plusieurs workflows s’exécutant toutes les heures à HH :00, il faudra étager leur exécution de manière à ce qu’ils ne consomment pas tous les ressources du DEM au même moment.

    Certains workflows, en particulier les Custom Workflows, peuvent être consommateurs de beaucoup de CPU. Si la charge CPU sur les machines hébergeant le DEM Worker est élevée, considérer l’augmentation de puissance de la machine ou l’ajout de machines supplémentaire hébergeant un DEM Worker.

 

Composants vCloud Application Director (AppDir)

 

    vCloud Application Director peut gérer jusqu’à 10 000 VMs et 2000 objets du catalogue. Il est possible éxécuter jusqu’à 40 déploiements concurrents et support 100 utilisateurs concurrents.

    La performance ne prend pas en compte la capacité du fournisseur de cloud ou les outils de déploiements externes sur lesquels AppDir repose. Une application nécessite un fournisseur de cloud pour provisionner une VM et d’autres ressources. Surcharcher un fournisseur de cloud peut conduire AppDir à ne plus répondre aux exigences minimums de charge.

    Configuration mémoire

    Il est possible d’ajuster la quantité de mémoire maximale disponible pour AppDir en configurant la taille maximale de la pile :

  • Naviguer sous /home/darwin/tcserver/bin/setenv.sh.
  • Ouvrir le fichier et trouver la variable JVM_OPS contenant les options d’éxécution de la JVM.
  • Changer la valeur de Xmx.
    • Par exemple pour allouer 3GB de mémoire à la JVM, assigner la valeur 3072m :
    • JVM_OPTS=”-Xms256m –Xmx3072m -XX:MaxPermSize=256m
  • Redémarrer le serveur AppDir
    • vmware-darwin-tcserver restart

Il est également possible de spécifier une taille initiale plus grande en changeant le paramètre Xms. Si la charge de travail est incertaine, il est possible de seter une valeur initiale moins importante pour conserver suffisemment de mémoire pour les autres processus. Si la charge est consistente, alors il est possible de seter une valeur initiale de mémoire plus large.

La valeur devra être ajustée en fonction de la charge. La quantité max devra être au moins égale à la moitié de la quantité de mémoire totale du serveur. Le reste de la mémoire devra être laissé libre pour les processus Postgre, RabbitMQ et les autres processus systèmes.

Il n’est pas nécessaire de toucher au paramètre XX :MaxPermSize sauf pour les opérations de troubleshooting.

Composants IT Business Management (ITBM)

 

    ITBM dans sa version standard peu gérer jusqu’à 20 000 VMs réparties dans 4 vCenter différents. La première synchronisation de l’inventaire prend environ 3 heures pour inventorier 20 000 VMs réparties sur 3 instances vCenter. La synchronisation des statistiques depuis les serveurs vCenter prend environ 1h pour 20 000 VMs. Par défaut le calcul du coût s’exécute de manière quotidienne en environ 2h pour 20 000 VMs.

    En version 1.0, la configuration par défaut de l’appliance Virtuelle ITBM peut supporter jusqu’à 20 000VMs. Augmenter les limites au-delà de la configuration par défaut n’augmente pas le nombre de VMs supportées.

Leave a Reply

Your email address will not be published.