Boot storms, cron storms et autres antivirus storms

La virtualisation s’est démocratisée à très grande vitesse ces trois dernières années. Il nous arrive d’auditer des PME ayant moins de 50 postes utilisateurs en un site unique et qui sont dotées d’un cluster VMware bien musclé pouvant facilement virtualiser une trentaine de serveurs. Presque un serveur par utilisateur ! Dans certains cas c’est justifié, dans d’autres cas, un revendeur de matériel s’est fait plaisir au passage, ce n’est pas la crise pour tout le monde.

Avec l’utilisation de plus en plus fréquente de la virtualisation, les personnels techniques sont confrontés à des problématiques de ralentissement généralisés, souvent par intermittence, voire à des horaires très précis. En creusant, on découvre que c’est lié aux démarrages des postes virtuels, les fameux Boot Storms, ou bien à des tâches planifiées au sein de plusieurs serveurs virtualisés, tâches qui démarrent au même moment. On parle alors de Cron Storms. Enfin, il existe aussi un risque, celui que nous avons le plus fréquemment constaté sur le terrain, qui est lié aux stratégies et tâches planifiées pour les antivirus des serveurs virtuels Windows. On parle alors d’Antivirus Storm.
Imaginez en effet, un cluster de virtualisation utilisant une baie SAN sur laquelle une centaine de serveurs virtuels lanceraient leur mise à jour antivirale, voire pire, un scan antiviral programmé au même moment. C’est l’écroulement du SAN et des CPU du cluster qui est assuré !
 
On peut bien évidemment travailler en amont sur le dimensionnement des équipements pour acheter un SAN qui supportera les IOPS estimées (Input / Output Per Second, à prononcer « Eye-ops » si vous voulez être tendance) et des serveurs bien musclés en processeurs multi-coeurs. Mais ça c’est dans le meilleur des mondes, quand on sait exactement ce qui sera fait sur ces hyperviseurs dans les mois et années à venir. Que l’on connait la qualité des équipes techniques qui géreront le changement et le maintien en conditions opérationnelles lorsque ce n’est pas nous qui le ferons.
Revenons-en à nos moutons ou plutôt, devrais-je dire, nos IOPS. C’est la principale cause d’écroulement des performances dans un environnement virtualisé. Pour commencer il faut savoir ce qu’est une IOPS et bien comprendre ce que cela veut dire sur les équipements de stockage.
Je ne vais pas vous faire un grand cours technique, il y a tout ce qu’il faut, si vous lisez l’anglais, sur Internet et des sites comme Wikipedia. Je vous invite pour cela à lire cet article :
http://en.wikipedia.org/wiki/IOPS
En quelques mots, pour ceux qui n’auraient pas le temps d’aller sur Wikipedia, il y a plusieurs méthodes de mesure pour les IOPS, celle qui nous intéresse généralement c’est la capacité maximale, dite « IOPS Total ». C’est une mesure qui donne une vision assez juste de l’aptitude d’un volume de stockage composé d’un ou plusieurs disques durs, à servir des opérations d’accès en lecture et écriture.
On comprend très vite que ce qui va jouer en faveur d’un IOPS total, c’est la vitesse de rotation des disques, le temps de recherche moyen d’un secteur en lecture ou en écriture et enfin la latence moyenne pour positionner la tête de lecture / écriture sur le bon secteur. D’autres éléments peuvent entrer en jeu sur certains disques comme le TCQ (Tagged Command Queue) ou encore le NCQ (Native Command Queue).
 

 
La formule couramment utilisée pour calculer cet IOPS sera : IOPS = 1/((temps de recherche moyen en ms / 1000) + (latence en ms/1000))
Avec,
● Temps de recherche moyen en ms : faire la moyenne du « Random Read seek time » et du « Random Write time » fournis par le fabricant.
● Latence en ms : prendre le « Average Latency » fourni par le fabricant.
 
Et l’on retrouvera en général et en 2012, un résultat qui devrait rester dans les plages du tableau suivant :
 

 
On vient de voir qu’il est assez simple de savoir combien d’IOPS nous aurons sur un disque unique, sauf que dans le monde de l’entreprise, on a rarement une baie de stockage ne contenant qu’un unique disque ! Pas réaliste non plus de faire du RAID 0 en se disant qu’on recherche la performance sans un minimum de sécurité pour la disponibilité. On doit donc composer entre IOPS total d’un disque et choix d’un volume RAID plutôt qu’un autre. Et chaque type de RAID à partir du niveau RAID 1 va avoir une pénalité en écriture pour nos IOPS. Pénalité due aux opérations que le contrôleur RAID doit assurer lorsqu’il répartie les écritures sur ses membres.●
 

 
Comment utiliser ces pénalités ?
 
C’est simple, pour chaque IOPS nécessaire pour le système, le volume RAID va multiplier cette IOPS par son facteur de pénalité. Par exemple pour une IOPS que le système envoi vers un volume RAID 5, cela se traduit en 4 IOPS pour le volume.
Maintenant nous allons voir comment estimer ces IOPS sur un volume RAID plutôt qu’un autre. Une formule est communément admise depuis 2009 pour cela :
 
IOPS sur le volume RAID = (IOPS Total x % en lecture) + ((IOPS total x % en écriture) x pénalité en écriture du RAID choisi)
Voici un calculateur en ligne qui permet d’estimer le nombre de disques durs classiques ou SSD en fonction de ses besoins en IOPS et en volumétrie :
http://www.wmarow.com/strcalc/goals.html
 
Et pour calculer la capacité d’un volume RAID en fonction du niveau et des disques :
http://www.wmarow.com/strcalc/strcalc.html
 
Reste le plus dur, comment estimer ses besoins en IOPS ?
 
Là il n’y a pas une seule et unique réponse. Pour éviter les tempêtes de boot, de tâches planifiées ou d’antivirus, il faut se baser sur ses expériences, sur les calculateurs fournis par certains éditeurs comme Microsoft pour les serveurs Exchange par exemple et ne pas oublier une petite réserve de sécurité de 20 % et le fait que les utilisateurs démarrent tous à peu près en même temps leur session chaque matin !
 
Si vous convertissez des machines physiques vers la virtualisation, cas le plus fréquent depuis quelques années, alors il « suffit » de suivre la démarche suivante :
 
1. On mesure pour chacun des serveurs la mémoire RAM consommée pendant plusieurs heures voire jours pour noter les pics et la moyenne.
2. On mesure les IOPS, là aussi pendant plusieurs heures ou jours.
3. On mesure la consommation réseau.
4. Et on mesure la consommation sur les CPU.
 
Plusieurs outils peuvent vous servir à réaliser ces opérations de monitoring. Certains, excellents, sont payants, d’autres gratuits.
 
● 5 Nine pour les migrations vers Hyper-V ou VMware (environ 500 US $ quelque soit le nombre de serveurs physiques à mesurer et il proposent une version gratuite limitée sur les rapports fournis) :
http://www.5nine.com/p2v-hyper-v-vmware.aspx
● Lanamark : http://www.lanamark.com/
● VMware Capacity Planner (en passant par un partenaire VMware) :
http://www.vmware.com/products/capacity-planner/
● MAP (Microsoft Assessment and Planning Toolkit) si vous n’avez que des serveurs Microsoft et que vous souhaitez migrer vers HyperV : http://technet.microsoft.com/en-us/solutionaccelerators/dd537566
 
Et si vous ne vous en sortez pas seul, que vous avez besoin de dimensionner un environnement de virtualisation ou de stockage ? Que vous rencontrez des problèmes de performances sur votre infrastructure IT et ne trouvez pas la cause ? Contactez nos équipes, nous nous ferons un plaisir de vous venir en aide.