Vous ne parlez pas de la même situation je dirais.
Exemple avec chiffres pris au pif :
Si ton service courriel c'est 15% d'un serveur physique, que ton web c'est 25% et que ta base de données c'est 20%, alors tu vas te dire qu'un serveur c'est bien assez en ressources (en disponibilité c'est autre chose). Là on est dans le cas de services unix et du partage sur un système (ça ressemble au cas LinuxFr.org par exemple).
Si ton service courriel c'est 30 à 60% d'un serveur physique, que ton web c'est de 15 à 45% et que ta base de données c'est 20 à 40%, alors tu n'as pas envie de tout mettre sur un seul serveur physique de toute façon, donc plusieurs serveurs, et tu va commencer à avoir pas mal de gâchis de ressources pour éviter des pics de charge qui pourraient coïncider. Là on commence à avoir du mal à mettre plusieurs services par serveur (sans parler du cirque pour les déplacer en cas de besoin).
La promesse de la virtualisation, de Kubernetes, etc., c'est de pouvoir dire je veux des minimums de 30%/15%/20%, je veux un max de 60%/45%/40%, et de compter sur l'infra pour gérer.
Après la disponibilité et la répartition de charges font que mettre 10 instances d'un même service sur un même serveur, ça ne serait pas idéal, donc on met des règles de non-affinité, donc on a besoin de plein de serveurs différents, et puis on fait répartir à des endroits différents, donc on a besoin d'encore plus de serveurs différents. Et on compte sur l'hébergeur d'infra pour mutualiser et rationaliser tout ça (et il margera là-dessus).
[^] # Re: La description du passé est contestable
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche La virtualisation pour les nuls et autres enjeux autour des datacenters. Évalué à 5.
Vous ne parlez pas de la même situation je dirais.
Exemple avec chiffres pris au pif :
Si ton service courriel c'est 15% d'un serveur physique, que ton web c'est 25% et que ta base de données c'est 20%, alors tu vas te dire qu'un serveur c'est bien assez en ressources (en disponibilité c'est autre chose). Là on est dans le cas de services unix et du partage sur un système (ça ressemble au cas LinuxFr.org par exemple).
Si ton service courriel c'est 30 à 60% d'un serveur physique, que ton web c'est de 15 à 45% et que ta base de données c'est 20 à 40%, alors tu n'as pas envie de tout mettre sur un seul serveur physique de toute façon, donc plusieurs serveurs, et tu va commencer à avoir pas mal de gâchis de ressources pour éviter des pics de charge qui pourraient coïncider. Là on commence à avoir du mal à mettre plusieurs services par serveur (sans parler du cirque pour les déplacer en cas de besoin).
La promesse de la virtualisation, de Kubernetes, etc., c'est de pouvoir dire je veux des minimums de 30%/15%/20%, je veux un max de 60%/45%/40%, et de compter sur l'infra pour gérer.
Après la disponibilité et la répartition de charges font que mettre 10 instances d'un même service sur un même serveur, ça ne serait pas idéal, donc on met des règles de non-affinité, donc on a besoin de plein de serveurs différents, et puis on fait répartir à des endroits différents, donc on a besoin d'encore plus de serveurs différents. Et on compte sur l'hébergeur d'infra pour mutualiser et rationaliser tout ça (et il margera là-dessus).