Archive for December, 2016

Le capacity planning pour les nuls

Monday, December 12th, 2016

Ou encore comment "faire un capacity planning simplement et facilement"

Définition

Faire un capacity planning c’est se projeter dans le futur et s’assurer qu’on aura la capacité de répondre à la demande.

Pour n’importe quelle ressource informatique, cela revient basiquement à multiplier 3 nombres ensembles : l’utilisation, un facteur d’échelle et une marge d’erreur et de comparer le résultat avec l’utilisation maximum de notre ressource

Voyons un peu plus précisément comment définir ces différents éléments.

taux d’utilisation

La première étape dans la réalisation, c’est de choisir un valeur pour le taux d’utilisation.

L’idéal est de prendre un créneau horaire où on a une charge stable et normale et où les utilisateurs sont contents de leur temps de réponse. Le pic journalier est ainsi, souvent, un bon point de départ de cette recherche.

Si vous ne savez pas quoi prendre comme indicateur, le premier et le plus simple, c’est évidemment l’utilisation CPU, car la plupart des transactions en utilisent.
Il faut aussi faire attention à ne pas avoir de trop grande moyenne, car elles pourraient cacher des pics significatif.
Une fois le choix fait, il est important de définir pourquoi on a choisi ce point, quelles en sont les conditions (quels en sont les limites).
Au bout du compte vous devez arriver avec une plage horaire et une valeur de CPU pour votre système. N’oubliez pas de regarder sur les systèmes autours pour être sûr que le comportement est homogène et que ce n’est pas un cas isolé.

facteur d’échelle

Le facteur d’échelle représente ce que sera l’évolution futur. Dans l’idéal, ce facteur doit être fournit le demandeur qui est le mieux à même de savoir quelle doit être l’évolution de l’usage des clients.

Il faut noter, qu’en général, hélas, on obtient un nombre aléatoire plutôt suspect !

Il est à noter qu’un capacity planning assume que la demande en ressources sera majoritairement linéaire. Toutefois, il existe quelques exceptions comme :
* lorsque les applications démarrent
* quand il y a un bottleneck applicatif
* il y a des erreurs qui arrivent (souvent cause de réessaie par exemple)

Tous ces cas là ne seront évidemment pas à prendre en compte dans le calcul, car on ne fait, bien évidemment, pas un capacity planning d’une application qui redémarre !
Toutefois, dans certaines conditions, il peut être judicieux de faire un capacity planning prenant en compte les système qui tombent en erreur, pour, par exemple, savoir si nous serions toujours en mesure de tenir la charge dans ce cas.

la marge d’erreur

La marge d’erreur va être là pour compenser tous ce que vous ne pouvez pas prédire, les choses qui arrivent et que vous ne savez pas expliqué, voir les évolutions logiciels, les changements réseaux, etc…
Il faut noter qu’un capacity planning répond à la question :

est-ce qu'on a les resources suffisantes ?
et non pas
est-ce que le temps de réponse sera bon ?

La marge d’erreur représente ainsi la qualité de votre estimation. Ou encore la confiance que vous avez dans cette estimation.

On l’exprime souvent en pourcentage et généralement, elle varie entre 10 et 50 % avec une valeur très courante de 20%.

usage maximum

L’usage maximum est le seuil à partir du quel on va considérer qu’une ressource qui fournit un service va devenir trop utilisé pour le fournir correctement. C’est cette valeur qui va nous servir de référence pour notre capacity planning.

Quand est-ce que trop c’est trop ?

Dans le cas de ressources qui fournissent un service, on comprend facilement qu’il y a une limite au delà de laquelle le résultat sera inacceptable causant souvent de l’empilement. Si on s’en réfère à la théorie des queues, on apprend qu’un équipement chargé à 50% aura un temps de réponse deux fois plus élevé que si il y avait un seul travail en cours !

Il faudra aussi faire attention à l’exclusivité d’une ressource. Par exemple, un disque ou une connexion. Si un processus a besoin de CPU, on peut dire que n’importe lequel fera l’affaire, par contre si le même processus à besoin d’accéder à une BDD, seule la connexion ou la lecture disque marchera et de facto limitera votre linéarité. En effet, si vous avez le choix pour avoir votre donnée, il y a toute les chances que se soit disponible et ne limite pas le temps de réponse, au contraire, si l’accès à votre donnée est limité, il est probable que votre temps de réponse se dégrade malgré une utilisation de votre ressource faible.

Dans le choix de la valeur il faudra aussi se concentrer sur la transaction principale et non pas sur toutes les transactions possibles et imaginables.

Un moyen expérimental d’estimer cette valeur maximum pour une ressource peut aussi venir de test en charge ou l’on augmente celle-ci jusqu’à obtenir un temps de réponse inacceptable ce qui nous donne notre valeur maximum admissible.

note : logiquement vous devriez obtenir une valeur supérieur à 50% et de l’ordre de 80%-90% dans le meilleur des cas

On peut aussi remarquer que la consommation CPU n’est pas le seul indicateur, ni le seul critère à regarder dans la recherche de l’utilisation maximale, beaucoup d’autres éléments peuvent interférer dans son usage.

les calculs ?

Une fois ces élément réunis, le calcul est facile à faire on l’a vu :

projection = utilisation x facteur d'échelle x marge

L’idéal est alors de présenter ces chiffres sous forme d’un joli graphe avec l’utilisation maximale et éventuellement l’utilisation actuelle, et bien évidemment de faire cela pour chacune des ressources utiles.

img ex

quelques exemples

Prenons quelques cas pratiques, afin de voir comment cela s’applique et quels sont les limites de ce modèle simplifié.

un exemple basique

Supposons que l’on ai un service qui fasse un million transaction, et que je voudrait passer à 4 millions. Soit, une augmentation de 400 %.
Mon facteur d’échelle sera donc 4 et je vais me prendre une marge d’erreur de 20 %.

1M -> 4M : 400% (soit 4 )
CPU : 10% (soit 0.1 )
marge : 20% (soit 1.2 )
projection = 0.1 * 1.2 * 4 = 0.48 ( soit 48 % )
si notre "max usage" est à 70% on à de la marge.

Comme évoqué il faudra toutefois quand même faire attention à ce qui se passe au niveau des informations depuis lorsque l’on détermine le cas d’utilisation maximale. Dans notre cas, si on imagine que notre serveur est un Apache, il faudrait faire attention à la partie AJP qui est, comme on l’a évoqué dans la notion d’usage maximal, une ressource unique et dont le remplissage impliquera un blocage !

si mon AJP pool est remplis à 80%, le passage à 400% donnerais un remplissage à 384% !

Le sens commun nous fait comprendre facilement que mon CPU sera bloqué bien avant cela et qu’il ne sera pas la vraie ressource importante.

exemple avec une panne

On l’a évoqué précédemment, certains cas d’erreur peuvent (et doivent) être intégré dans une étude de capacity planning. Imaginons pour cela, un cas où on aurait plusieurs serveurs et que l’on veuille savoir ce qui se passe si l’un d’eux tombe en panne. Partons du principe que l’on a 3 serveurs, chacun utilisé à 10%. Que se passe-t-il si l’un d’eux tombe ?

3 serveur à 10% CPU, 1 panne -> 3 * 10 = 30
soit 15 % CPU par serveur restant, on est bon

mais appliquons notre capa planning :

notre estimation est de 48 % par serveur, soit 144 %
ce qui donnerait 72% par serveur en cas de panne

On se retrouverais au dessus de notre maximum, il y aura donc une réflexion à avoir :

  • prend-on le risque ?
  • ajoute-t-on un serveur ?

ce sera là, toute la difficulté de l’interprétation de ce capacity planning.