[GUIDE] [vCD] Piste d’optimisation du Transfer Server Storage

vCloud Director fonctionne sur la base d’un serveur NFS qui fait office de serveur « tampon » pour ses fichiers temporaires, c’est ce qu’on appelle le « Transfer Server Storage ».

Pour des questions de débits il faut que le serveur NFS soit optimisé tant sur la partie I/O disk que sur la partie network afin que l’ergonomie utilisateur ne soit pas entravé. Concrètement si la liaison entre vCD & le NFS est lente, l’utilisateur va le ressentir dès lors qu’il va importer ou exporter un fichier sur son tenant. En fait tout action qui fera appelle au Transfer Server dégradera l’expérience utilisateur.

Le Transfer Server Storage permet « for providing temporary storage for uploads, downloads, and catalog items that are published or subscribed externally. »

Check du point de montage du « Transfer Server Storage »

Dans un premier temps il faut vérifier le point de montage du NFS.

Structure du Transfer Server Storage :

• appliance-nodes
  • Ici vous trouverez les configurations de chaque cellule telle que le type d’appliance (primary, standby), l’adresse IP primaire,…
• backups
  • Comme son nom l’indique c’est ici que les backups vCD vont se trouver
• cells
  • Ce folder contient les Cells ID qui permet au vcd-support de générer le support-bundle
• pgdb-backup
  • Ce folder contient les backups de la database
• vmware-vcd-supports
  • Ensemble de logs générés pour le support (ou pour vos troubleshoot)

Exemple de download d’une VM : vue de la structure du « Transfer Server Storage »

Lorsque nous téléchargeons une VM à travers la GUI vCD va créer un dossier tampon sur le serveur NFS sur /opt/vmware/vcloud-director/data/transfer/nomdudossiertampon

Nous pouvons donc voir dans notre exemple que vCD a créé un dossier temporaire où se trouve le VMDK de la VM que nous voulons exporter. Jusque-là rien de bien compliqué.

Vérification des débits entre vCD/NFS

D’ailleurs pendant que nous téléchargeons notre VM nous pouvons vérifier le network speed directement sur le vCenter.

Un iPerf entre vCD et le serveur NFS aurait aussi fonctionné mais les débits finaux seront tronqués parce qu’un utilisateur/client vCD passe par internet, et donc il y a plusieurs couches de sécurités (WAF, Firewall, overlay NSX,…).

Les workflows vCD sont les suivants :

N.B : Je n’ai trouvé aucune documentation indiquant exactement les différents workflows, Ils sont donc issus de mes tests, et de ce que j’en ai déduis. Ils peuvent être erronés

Exemple d’une copie « Media & Other » d’un catalogue vers un autre :

Pour des questions de simplicité (bypass du délai de 24 heures sur le Transfer Server Storage lors de l’import) j’ai copié un fichier existant d’un « Catalogue » vers un autre, mais le workflow sera exactement le même pour un import.

Rentrons maintenant dans le vif du sujet.
L’Optimisation de vCD et du Transfer Server Storage.

Nous devons commencer par vérifier la carte NIC qui permet l’import/export des données, pour cela un simple ifconfig avec les valeurs RX/TX suffissent (si vous êtes sûr de ne pas avoir de traffic à l’instant T où vous faites vos tests). Dans notre cas les valeurs sont de 35.4GB pour le RX et 32.2GB pour le TX.

Aussi, pour confirmer que c’est bien « l’eth0 » nous pouvons lancer un import ou un export sur vCD et comparer les valeurs.

Avant export :

Après export :

Performance Chart vCenter :

Les valeurs qu’il faut vérifier sont « Data receive » et « Data transmit rate » (en fonction si c’est de l’import ou de l’export). Ici nous pouvons voir que la moyenne est de ~78 MBps pour le receive et de 125 MBps pour le transmit, globalement ce sont des valeurs qui restent très faibles par rapport à la taille de l’infrastructure sur laquelle vCD est hébergé (2x 25Gbps per VxRail host) où nous devrions à minima obtenir 1Gbps.

Piste d’optimisation des performances vCD :

Sur cet article malheureusement je ne peux pas vous montrer les optimisations avec des preuves l’appui mais si vous avez été attentif aux captures précédentes la piste la plus simple est évidemment le passage de la MTU de 1500 en Jumbo Frame surtout si vous avez une infrastructure VCF.

A ce sujet il y a un document très complet (page 13) sur l’avantage qu’à la partie Jumbo Frame sur les performances réseaux

• Passage des cellules vCD en « Large Size »
  • Les performances peuvent être limitées par le nombre de vCPU
• Passage à vSAN File Service (Pas de dépendance à un 3rd party)
  • vSAN FS a de nombreux avantages comme la possibilité de profiter de storage policy dédié sur du NFS
• Si vCD est rattaché à du NSX-T il faut vérifier si le fait de passer par l’overlay bride les performances
  • Ce sera peut être l’occasion d’en faire un article, mais sur 3 infrastructures différentes j’ai remarqué une perte de performances de l’ordre de 25% en passant par l’overlay sur du NSX-T en version 3.1.3 et 3.2.1
• Optimiser le chemin complet du client au backend de l’infra (notamment si les clients passent par des Firewall, des WAF, des LB,…).