Le protocole PCoIP (PC-over-IP) a été développé par la société Teradici et il est inclus en OEM dans la solution VMware View depuis la version 4.0. Cette technologie a la particularité d’être auto-adaptative en fonction du besoin du contenu et de la quantité de bande passante disponible. En pratique, PCoIP ajuste la bande passante en fonction des besoins des utilisateurs et, en cas de connexion dégradée ou limitée, envoie progressivement les données nécessaires à l’affichage d’un document. Une construction progressive donc avec le texte pour commencer et les images pour finir.

La particularité que cela peut provoquer est que si l’on essaye de mesurer la bande passante consommée par une session PCoIP on n’obtiendra pas le même résultat en fonction de la bande passante disponible ou pas. Si le tuyau est assez gros, il n’applique pas de compression. Alors que si le tuyau est en cours d’utilisation ou s’il y a plusieurs sessions en simultanée, il compresse le flux en fonction du besoin et de la bande passante.

Cette technologie fonctionne en mode « Server Side Rendering » (à la différence de l’HDX), ce qui veut dire que l’on a un overhead sur la partie serveur, mais il ne nécessite pas de codec côté client et est compatible avec le client léger de tye Zero-Client. On a une bien meilleure bande passante qu’en RDP mais l’overhead est supérieur de l’ordre de 14% sur les processeurs (voir page 13 de cette étude).

Même si le PCoIP s’adapte au lien, il est possible de forcer les valeurs pour optimiser le protocole pour le WAN. Une doc très intéressante est disponible sur le site du support de Teradici, dans Downloads > PCoIP Documentation > Implementation Notes > PCoIP Client to VMware View 4 LAN and WAN Optimization Guide

Lire la suite…

Pour une administration en centrale sur une infra séparée géographiquement, il se pose souvent la question sur la bande-passante qu’il faut pour administrer des serveurs ESX à travers le WAN. Il y a bien une solution évidente: déporter le vCenter en Linked-Mode mais encore faut-il avoir plus de 3 ESXs sur ce site pour que ca soit intéressant au niveau des licences ou avoir plus de 10 sites déporté pour partir sur des packs Essentials ROBO. Sinon, on garde un seul vCenter en central et là, il faut avoir assez de bande passante.

Recommandations pour administrer des ESXs à travers le WAN:

• Ne pas utiliser des liens inférieur 56 kbps. A partir de 128 kbps cela devient utilisable
• Upgrader manuellement l’agent vCenter(vpxa) sur les serveurs ESX avant de les ajouter dans l’inventaire du vCenter
• Augmenter la valeur du heartbeat TimeOut pour diminuer les pertes de connexion avec les ESXs (voir plus bas)
• Réduire la résolution et le nombre de couleurs de toutes les VMs des sites déportés
• Utiliser RDP pour se connecter aux VMs Windows (plutôt que la Console VM)
• Utiliser ssh ou putty pour se connecter aux VMs Linux
• Etre vigilant à la configuration des Firewalls entre le vCenter et les ESXs
• Sur le site distant, utiliser VI Client en direct vers les ESXs ou du RDP vers le vCenter pour utiliser le VI Client

La bande passante et la latence peuvent provoquer quelques problèmes d’affichage pour la majorité des actions. Par contre pour les taches suivantes, cela peut provoquer des TimeOuts ou des figeages du VI Client:

• Ajouter un serveur ESX à l’inventaire, si la bande passante est inférieure à 128 Kbps
• Ouvrir la Console VM, si la bande passante est inférieure à 256 Kbps et la latence supérieur à 100 ms
• Se positionner sur un ESX dans l’inventaire, si la bande passante est inférieure à 128 Kbps et la latence supérieur à 150 ms

Grosso modo, il faut compter:

• 80 à 100 Kbps / ESX, pour l’administration entre un serveur ESX et le vCenter
• 1 Mbps, pour la communication entre le VI Client et le vCenter

Lire la suite…