{"id":1023,"date":"2023-04-23T19:52:20","date_gmt":"2023-04-23T17:52:20","guid":{"rendered":"https:\/\/kdslabs.fr\/?p=1023"},"modified":"2023-05-01T01:59:53","modified_gmt":"2023-04-30T23:59:53","slug":"article-comment-un-cloud-provider-optimise-les-workloads-de-ses-clients-sur-vcd","status":"publish","type":"post","link":"https:\/\/kdslabs.fr\/index.php\/2023\/04\/23\/article-comment-un-cloud-provider-optimise-les-workloads-de-ses-clients-sur-vcd\/","title":{"rendered":"[GUIDE] Comment un cloud provider optimise les workloads de ses clients sur vCD"},"content":{"rendered":"\n

[GUIDE] Comment un cloud provider optimise les workloads de ses clients ?<\/u><\/h4>\n\n\n\n

Cet article a \u00e9t\u00e9 r\u00e9dig\u00e9 pour Metanext vous pouvez le retrouver, ainsi que d’autres articles techniques sur Blog – Metanext<\/a><\/strong> <\/p>\n\n\n\n

Chapitre 1: Qu\u2019est-ce que vCloud Director et ses optimisations.
Chapitre 2 : D\u00e9tail technique concernant les optimisations de vCD
vCPU Speed sur les \u00ab OrgVDC \u00bb
vCPU Speed sur les \u00ab VM Sizing \u00bb
Storage sizing des \u00ab Storage Policy\u00bb
Network quota
Sizing des \u00ab vGPU Policy \u00bb
Chapitre 3: vNUMA sur des workload GPU NVIDIA
Conclusion<\/em><\/p>\n\n\n\n

Chapitre 1: Qu\u2019est-ce que vCloud Director et ses optimisations.<\/u><\/h4>\n\n\n\n

Fleuron de VMware, vCloud Director (vCD) est la solution d\u00e9velopp\u00e9e par VMware pour le Cloud Public permettant ainsi aux clouds providers de proposer une offre IaaS, Longtemps, vCD \u00e9t\u00e9 utilis\u00e9 par les clients comme du Cloud priv\u00e9, ce n’est qu’\u00e0 partir de la version 10 o\u00f9 vCloud Director a pris un tout autre tournant.

Aujourd’hui VMware investi une grande partie sur la branche technologique Cloud pour en faire une solution stable et fiable. D’ailleurs cela a donn\u00e9 naissance \u00e0 plusieurs Cloud Provider sur le march\u00e9, et c’est sans compter l’enjeu grandissant des “Sovereign Cloud Provider” qui ont pu na\u00eetre gr\u00e2ce \u00e0 cette solution.

A ce sujet VMware d\u00e9livre des homologations aux Cloud Provider respectant le cahier des charges VMware<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Chapitre 2 : D\u00e9tail technique concernant les optimisations de vCD<\/u><\/h4>\n\n\n\n

\n vCD a plusieurs param\u00e8tres d\u2019optimisations pour permettre aux cloud provider d\u2019optimiser leur capacity planning en trouvant le meilleur rapport performance\/consommation des workloads.\n<\/p>\n\n\n\n

    \n
  • \n vCPU Speed sur les \u00ab OrgVDC \u00bb\n <\/li>\n\n\n\n
  • \n vCPU Speed sur les \u00ab VM Sizing \u00bb\n <\/li>\n\n\n\n
  • \n Storage sizing des \u00ab Storage Policy\u00bb.\n <\/li>\n\n\n\n
  • \n Network quota\n <\/li>\n\n\n\n
  • \n Sizing des \u00ab vGPU Policy\u201d\n <\/li>\n<\/ul>\n\n\n\n

    vCPU Speed sur les \u00ab OrgVDC \u00bb<\/u><\/h4>\n\n\n\n

    Ce param\u00e8tre permet de limiter la consommation en \u00ab\u00a0Ghz\u00a0\u00bb sur chaque VM de l\u2019OrgVDC, il est semblable au param\u00e8tre \u00ab\u00a0CPU Limit\u00a0\u00bb sur les VM c\u00f4t\u00e9 vCenter. <\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Exemple concret, en prenant notre ESXi de l\u2019article pr\u00e9c\u00e9dent qui est un Intel(R) Xeon(R) Gold 6354 CPU @ 3.00GHz avec 18 c\u0153urs par socket il faut comprendre que chaque c\u0153ur physique aura\/pourra consommer 3Ghz.<\/p>\n\n\n\n

    Si nous prenons un cluster constitu\u00e9 de 3 n\u0153uds Intel Xeon Gold 6354 nous aurons au total ~162 Ghz consommables.
    (18 c\u0153urs * 3 Ghz * 3 ESXi) <\/p>\n\n\n\n

    Dans le cas o\u00f9 ce param\u00e8tre n\u2019\u00e9tait pas pr\u00e9sent, m\u00eame une VM de 18vCPU pourraient consommer l\u2019ensemble de la fr\u00e9quence du cluster.
    N.B\u00a0: Etant donn\u00e9 que l\u2019hyperthreading est activ\u00e9 il faut multiplier le nombre de c\u0153ur par 2 (18 c\u0153urs * 2 = 36 c\u0153urs = 108 Ghz) <\/p>\n\n\n\n

    Voici la configuration de la VM sur le vCenter :<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Exemple d\u2019une VM avec un benchmark OCCT : <\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Consommation en Ghz de la VM <\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Consommation de la VM sous OCCT sur le vCenter<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    C\u00f4t\u00e9 vCD, au niveau OrgVDC, si le vCPU Speed est configur\u00e9 \u00e0 1 Ghz cela veut dire que chaque workload pr\u00e9sent sur cette OrgVDC se verra affecter une limite de 1Ghz par c\u0153ur, et peu importe que la VM ait 1 ou X vCPU.<\/p>\n\n\n\n

    Ici nous avons donc une VM avec 16 vCPU qui consomme 16 Ghz d\u2019allocations sur le cluster <\/p>\n\n\n\n

    \"Graphical<\/figure>\n\n\n\n

    Nous pouvons aussi le v\u00e9rifier sur la vue \u00ab\u00a0provider\u00a0\u00bb vCD. Vue, qui permet l’administration de l\u2019infrastructure. <\/p>\n\n\n\n

    \"Graphical<\/figure>\n\n\n\n

    Deuxi\u00e8me exemple avec le m\u00eame param\u00e8tre mais cette fois-ci \u00e0 10Ghz : <\/p>\n\n\n\n

    Nous configurons donc la m\u00eame VM mais avec le \u00ab\u00a0vCPU Speed Limit\u00a0\u00bb \u00e0 10 Ghz. Ce qui, dans ce cas nous donne automatiquement 160 Ghz d\u2019allou\u00e9s sur le cluster mais qui n\u2019est pas adapt\u00e9 parce qu\u2019un ESXi peut contenir une VM ayant maximum 107.71 Ghz comme vu pr\u00e9c\u00e9demment.<\/p>\n\n\n\n

    \"Graphical<\/figure>\n\n\n\n
    \"Graphical<\/figure>\n\n\n\n

    Nous pouvons affirmer que ce param\u00e8tre est indispensable, et encore plus dans le cas d\u2019une infrastructure mutualis\u00e9e comme un cloud provider o\u00f9 chaque mauvaise configuration peut vite devenir un gros probl\u00e8me (rem\u00e9diation avec planification et arr\u00eat des workloads dans certain cas) . Si nous prenons l\u2019exemple de la VM ci-dessus avec une limite \u00e0 10Ghz la VM pourra consommer plus de CPU\/Ghz que ce que propose le cluster, imaginez-vous quelques minutes que cette VM se fasse compromettre. C\u2019est une infrastructure de production qui peut \u00eatre perturb\u00e9e par une mauvaise configuration complexe \u00e0 identifier, dans le sens o\u00f9 tr\u00e8s peu de workload consomme autant, sauf les outils de benchmarks qui eux n\u2019ont pas de limite \u00e0 par celle du physique. <\/p>\n\n\n\n

    vCPU Speed sur les \u00ab VM Sizing \u00bb<\/u><\/h4>\n\n\n\n

    Le param\u00e8tre \u00ab\u00a0vCPU Speed\u00a0\u00bb a le m\u00eame effet que le \u00ab\u00a0vCPU Speed\u00a0\u00bb mais au niveau des VM Sizing directement li\u00e9 au gabarit de la VM.
    L\u2019id\u00e9e de ce param\u00e8tre est de pouvoir dimensionner la consommation en fr\u00e9quence (Ghz) en fonction de la taille du profil (meilleure rapport peformance\/capacity planning). <\/p>\n\n\n\n

    NB : sur la version vCD 10.3.2 il y a un bug d\u2019affichage sur \u00ab CPU allocation used \u00bb il faut \u00e9teindre puis rallumer la VM pour que l\u2019ancienne valeur d\u2019allocation soit remise \u00e0 z\u00e9ro et que la nouvelle s\u2019affiche<\/p>\n\n\n\n

      \n
    • \n Si par exemple une VM tourne avec 8 vCPU sans vCPU Speed sur son VM Sizing et qu\u2019on l\u2019\u00e9teint cette VM puis qu\u2019on change son gabarit par un 16 vCPU c\u2019est toujours la valeur de 8 Ghz (8vCPU) qui est affich\u00e9e. Il faut allumer la VM une premi\u00e8re fois puis l\u2019\u00e9teindre pour que cette valeur \u00ab CPU allocation used \u00bb soit mise \u00e0 jour.\n <\/li>\n<\/ul>\n\n\n\n

      Storage sizing des \u00ab Storage Policy\u00bb.<\/u><\/h4>\n\n\n\n

      Ce param\u00e8tre permet quant \u00e0 lui de limiter les ressources de stockage qu\u2019une OrgVDC peut consommer sur le cluster.
      Exemple\u00a0:
      Si nous avons un cluster vSAN de 700To nous avons possibilit\u00e9 de limiter tous les workloads de l\u2019OrgVDC \u00e0 20To maximum. (Evidemment pour les exemples ci-dessous je ne prends pas en compte les limitations OS sur le storage sizing) <\/p>\n\n\n\n

        \n
      • \n Une VM Windows de 10To\n <\/li>\n\n\n\n
      • \n Une VM Linux de 5To\n <\/li>\n<\/ul>\n\n\n\n
        \"\"<\/figure>\n\n\n\n

        M\u00eame principe avec une VM qui se ferait compromettre, et auquel aucune limitation sur l\u2019OrgVDC n’a \u00e9t\u00e9 pos\u00e9e, elle pourrait donc tr\u00e8s bien consommer l\u2019ensemble des ressources stockage du cluster. <\/p>\n\n\n\n

        Network quota<\/u><\/h4>\n\n\n\n

        Nous avons \u00e9videmment la possibilit\u00e9 de limiter les ressources c\u00f4t\u00e9 network. <\/p>\n\n\n\n

        \"\"<\/figure>\n\n\n\n

        N.B : sur la version 10.3.2 de vCD il y a un bug qui fait que le compteur network ne fonctionne plus lorsqu\u2019un DCGroup est configur\u00e9 au niveau du tenant.
        <\/p>\n\n\n\n

        Sizing des \u00ab vGPU Policy \u00bb<\/u><\/h4>\n\n\n\n

        Les vGPU policy ont les m\u00eames effets que les VM Sizing \u00e0 la diff\u00e9rence que sur les vGPU Policies il y a un VM Group \u00e0 d\u00e9finir (VM\/Host group c\u00f4t\u00e9 vCenter) afin de regrouper les VMs au sein d\u2019un ESXi. <\/p>\n\n\n\n

        \"\"<\/figure>\n\n\n\n

        \n N.B : Les VM ayant un profil vGPU ont obligatoirement une r\u00e9servation c\u00f4t\u00e9 RAM ESXi et RAM GPU.\n
        \n Si une VM a un profil 8Q qui correspond \u00e0 8Go de RAM elle aura 8Go r\u00e9serv\u00e9e sur l\u2019ESXi\/Carte graphique qui porte ce workload\n<\/p>\n\n\n\n

        Chapitre 3: vNUMA sur des workload GPU NVIDIA<\/u><\/h4>\n\n\n\n

        Il existe tr\u00e8s peu de litt\u00e9rature sur le sujet, autour de la topologie vNUMA et GPU Nvidia. Dans la continuit\u00e9 des tests, nous allons d\u00e9couvrir dans cet article le lien entre les deux

        Pour rappel l’infrastructure pour nos benchmark est la suivante :
        – Intel(R) Xeon(R) Gold 6354 CPU @ 3.00GHz (2x CPU physique)
        – Cores per socket : 18
        – Logical Processors: 72
        – Hyperthreading enabled
        – RAM: 1024Go (\u00e0 diviser par deux, 512Go par socket) <\/p>\n\n\n\n

        Comparaison des benchmarks : <\/p>\n\n\n\n

        \"\"<\/figure>\n\n\n\n

        Ces variations sont tr\u00e8s certainement dues \u00e0 une charge c\u00f4t\u00e9 VM ou ESXi, nous pouvons donc en conclure qu\u2019il n\u2019y a aucune diff\u00e9rence de performance sur une VM ayant un profil GPU attach\u00e9 ou non mais il est aussi \u00e0 noter que cela va d\u00e9pendre des softwares qui vont \u00eatre utilis\u00e9s par la carte vGPU. <\/p>\n\n\n\n

        N.B : Ces tests ont \u00e9t\u00e9 effectu\u00e9s \u00e0 travers vCD mais le concept reste le m\u00eame s\u2019ils avaient \u00e9t\u00e9 effectu\u00e9s sur le vCenter (la diff\u00e9rence entre un workload GPU et non GPU est l\u2019association d\u2019un device PCIe). <\/p>\n\n\n\n

        Conclusion<\/u><\/h4>\n\n\n\n

        Il est \u00e0 noter que l’ensemble de ces benchmark couvre une grande partie des use cases\/workloads que peuvent avoir des clients de Cloud Provider et \u00e9galement des infrastructures on-premise (CPU, chiffrement, traitement vid\u00e9o avec ou sans CUDA,..) mais ils ne peuvent repr\u00e9senter la r\u00e9alit\u00e9 en tout point \u00e9tant donn\u00e9 qu’une infrastructure est majoritairement compos\u00e9e de workload h\u00e9t\u00e9rog\u00e8ne, cet article est donc l\u00e0 pour vous aider \u00e0 trouver le bon compromis entre performance et optimisation de votre infrastructure mais des tests sont indispensables sur l\u2019infrastructure en question. <\/p>\n\n\n\n

        A vos tests ! ^^ <\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"

        Optimisation des workloads sur vCD dans un contexte cloud provider<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15,18],"tags":[25,23,21],"class_list":["post-1023","post","type-post","status-publish","format-standard","hentry","category-vmware","category-vsphere-7-0","tag-article","tag-guide","tag-vmware"],"_links":{"self":[{"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/posts\/1023","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/comments?post=1023"}],"version-history":[{"count":0,"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/posts\/1023\/revisions"}],"wp:attachment":[{"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/media?parent=1023"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/categories?post=1023"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kdslabs.fr\/index.php\/wp-json\/wp\/v2\/tags?post=1023"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}