(Cet article fait partie de notre dossier HPC Dans Le Cloud)
 
A en croire les dirigeants d’Amazon Web Services les plus prolixes, le cloud est la solution miracle pour répondre à toutes les problématiques de charges du calcul HPC, dans tous les domaines. Entre autres exemples, David Pellerin évoque le cas d’un industriel européen qui met au point ses ASIC pour l’imagerie médicale avec des codes Monte Carlo exécutés sur 4.000 nœuds Amazon. Des nœuds loués à très bas pris lors des baisses de charge des datacenters (des instances “spot” dans le jargon Amazon). Pourtant, beaucoup doutent encore de la capacité d’un service Cloud, qui plus est virtualisé, à faire monter en charge un grand nombre de serveurs eux-mêmes virtualisés.

Une toute récente étude vient documenter le problème. Menée par des chercheurs de l’Université d’Illinois assistés (activement, on l’imagine) par des ingénieurs des HP Labs, elle montre de fortes disparités de performance entre trois clusters AMD Opteron, Intel Xeon X5650 et Intel Xeon X5450 d’une part, un cloud privé et des instances Amazon EC2. L’équipe a fait passer à ces cinq concurrents toutes une série de benchmarks correspondant à diverses charges de calcul sur un nombre de nœuds croissant, de un à 256. Si sur NQueens les configurations présentent dans l’ensemble des performances similaires, avec notamment une montée en charge linéaire, il n’en va pas de même avec les autres tests. Rapidement, la configuration cloud public (Amazon EC2) puis la configuration cloud privé divergent, avec des écarts de temps de calcul très significatifs au delà de 8, 16 et 32 cœurs.

L’équipe a cherché à identifier les raisons de telles différences de performance. Les hyperviseurs ont été significativement améliorés ces dernières années en termes d’efficacité. Ils accèdent mieux aux ressources processeur si bien que sur des applications moins exigeantes que la simulation numérique, le delta en performance est devenu minime sinon négligeable pour des applications classiques. Les chercheurs ont ainsi démontré que sur le benchmark Jacobi 2D, la charge processeur n’excède que rarement 50 % dans la configuration cloud privé 64 cœurs, ce qui tend à montrer que le goulet d’étranglement est ailleurs. C’est bien évidemment sur le volet réseau que les configurations virtualisées sont à la peine. Sans surprise, la latence des messages échangés entres nœuds est bien plus élevée en environnement Cloud, entre 4 à 64 fois, avec une bande passante très nettement inférieure. Ces piètres performances en communication expliquent pourquoi l’application n’arrive pas à exploiter les CPU de manière plus intensive. Logiquement, on peut en conclure que ce sont les applications nécessitant le moins de communications entre les nœuds qui sont les meilleures candidates au cloud.

S’il est possible d’optimiser le “rendement” des clusters virtualisés, s’il est possible de passer à des solutions de virtualisation plus légères pour améliorer les performances, la virtualisation serveur reste encore relativement immature pour beaucoup d’observateurs. C’est en tous cas l’opinion de Marc Levrier, qui précise que “pour l’instant, Bull virtualise uniquement les nœuds de service. Les nœuds de calcul, eux, restent sur des serveurs Bare Metal. C’est l’option la plus performante pour l’exécution de codes de simulation. Nous travaillons sur les hyperviseurs, notamment sur Open Stack, mais la question de l’exploitation d’InfiniBand en environnement virtualisé n’est pas encore réglée. Dans un futur proche, d’ici moins d’un an, nous proposerons une offre virtualisée, mais ce ne sera qu’un complément de notre offre actuelle, pour les applications non parallèles – sachant qu’à l’heure actuelle, 99 % des applications de nos clients sont parallèles.”
 
(Dossier HPC Dans Le Cloud : article précédent | suivant)