Note : Cet article s’inspire de l’excellent billet de The Lone Sysadmin.
La technologie “Transparent Page Sharing” est à la virtualisation ce que la déduplication est au stockage : un moyen, souvent très efficace, d’économiser de la mémoire vive sur vos ESXi, sans réelle baisse notable des performances de vos hyperviseurs. Cette fonctionnalité extrèmement intéressante existe depuis longtemps sur ESXi et elle était activée par défaut depuis au moins ESXi 5.0.
Malheureusement, VMWare vient de décider unilatéralement et en toute discretion, lors de la publication des derniers patchs de sécurité (ESXi 5.5, ESXi 5.1 et ESXi 5.0), de désactiver cette option. Autant dire que sur des environnements conséquents (plusieurs centaines de VM), la “facture” en terme de consommation mémoire peut être particulièrement salée : vous pouvez en effet gagner des centaines de Go de mémoire grâce au TPS et ce faisant, optimiser vos investissements serveurs. Sur le principe, l’intention est louable et répond à une volonté de l’éditeur de sécuriser au maximum et par défaut ses hyperviseurs. En effet, le transparent page sharing, sur le papier, peut poser des problèmes d’isolation entre VM (certaines parties de la mémoire de celle-ci étant partagées). Ceci étant, dans la pratique et au sein de nombreux environnements de production situés “en zone de confiance” et donc moins exposés à des tentatives constantes de hacking, les avantages de cette technologie l’emportent très largement sur le risque encouru.
Dans la pratique, un ESXi patché désactive donc le TPS et chaque VM va inévitablement consommer plus de RAM. Vous avez deux possibilités pour vous en sortir : soit réactiver la fonction globalement via la modification du paramètre “Mem.ShareForceSalting” dans la configuration avancée de chaque serveur APRES sa mise à jour :
… soit utiliser cette fonction de manière plus granulaire et ajouter, pour chaque VM, un paramètre “salt” (… quelle ironie, effectivement, la note est salée :) ). Celui-ci confirme la possibilité à toutes les machines ayant le même “salt” qu’elles peuvent partager leurs segments mémoire. Cette dernière méthode est particulièrement lourde, pour le moment, car vous êtes obligé d’arrêter la machine et d’ajouter votre pincée de sel dans les paramètres avancés, sched.mem.pshare.salt=CHAINE :
On le voit, cette dernière méthode a un intérêt certain en environnement protégé ou sensible, car elle permet de régler finement les partages de segments mémoire.
Cette modification “discrète” mais aux impacts potentiellement importants du comportement des hyperviseurs VMWare nous amène sans doute, en conclusion, a nous convaincre s’il en était encore besoin de bien lire les releases notes de chaque patch avant application. Enfin, ça c’est la théorie bien entendu ;) … dans la pratique, je suis globalement de l’avis de Lone Sysadmin : c’est tout de même un joli coup de dans le dos de la part de notre éditeur de virtualisation favori… pas sûr que tous les clients apprécient.
Sources :
Le billet inital de Lone Sysadmin : Latest ESXi turns off transparent page sharing, watch your RAM !
Le KB correspondant chez VMWare : KB #2097593
A propos du TPS et des risques associés (VMWare) : KB #2080735
Bonjour Cédric, on pourra en rediscuter plus en détail, mais pour faire bref:
Ce n’est pas un coup dans le dos de ses clients fait par VMware, mais une réaction avec application par défaut (par principe de précaution, comme le login SSH en root par exemple) à une faille de sécurité. Cela date de plusieurs mois et à l’époque avait fait beaucoup de buzz sur les Blogs. Pour l’utilisation des 2 paramètres la logique est simple:
Soit votre cluster est purement interne (faiblement exposé aux attaques) et vous pouvez réactivez le TPS avec le paramètres “Mem.ShareForceSalting” au niveau ESXi.
Soit votre cluster est plus sensible car publique et accessible de tous (exemple Service Provider avec offre de Cloud Publique mutualisé) et vous pouvez l’activer par zone de confiance (exemple par client) avec le paramètre “sched.mem.pshare.salt” au niveau des VMs (avec une chaine privé par client).
D’accord avec toi sur le pourquoi du comment et la justification de l’existence de cette option, d’ailleurs je l’indique dans mon billet. Maintenant, je pense toujours qu’il y avait sans doute une manière plus “officielle” de le faire en l’appliquant sur les nouvelles installs mais pas dans les patchs purs, par exemple. Je suis “tombé sur cette info” vraiment par hasard et pourtant, je passe du temps sur la blogosphere VMWare (peut-être pas suffisamment). Pour info, j’ai regardé cet après-midi sur nos quelques 1000 VM, cela nous fait gagner quasi 250 Go de RAM, ce n’est pas rien.
Je te conseil cet article:
http://www.hypervisor.fr/?p=5298