ce que les marketeux appelle bidule Cloud tralala c'est d'une certain façon
du mutu pour pro ?
Bonjour,
à nous :)
tu as 3 manieres d'utiliser les resources hardware qui dependent
de ce que tu souhaites offrir comme qualité de service à tes
clients:
1.) tu prends de serveurs et tu les utilises à 30% de leur capa
pour garder les 70% en cas où il y en aurait besoins. que ça
soit en cluster ou en solo, on peut se prendre une attaque,
une aspiration, une annonce à la tv etc. et on espere toujours
que les 70% restantes vont suffir pour maintenir une qualité
de service correct.
les +
+ la qualité de service sauf les cas extreme
+ la capacité total utilisable en burst
les -
- les cas extreme
- la rentabilitée du serveur n'est pas terrible
- la complexité de l'infra avec plein de serveurs
qui ne font rien mais qu'il faut maintenir
2.) tu prends de serveurs et tu les utilises à 100% tout le temps.
on s'en fout la qualité de service. 100% du cpu, 100% de la
ram, 100% du reseau.
les +
+ la rentabilitée du serveur est parfait
+ peu de serveur pour assurer le service
les -
- aucune capacité de burst
- la qualité de service
3.) tu prends de serveurs très puissant (on parle de 48 cores
et donc 100GHz par boitier avec 256Go de RAM) et tu demarres
les machines virtuelles de capacité, allez 8 cores avec 64Go
de RAM. tu demarres 100 machines virtuelles sur une machine
physique. avec la mutualisation de cpu, ram, disque, les
machines virtuelles prennent en resources hardware du serveur
ce qu'elles ont besoins. l'administration consiste donc à
regarder combien de GHz, RAM et HD me reste non utilisé
sur le serveur physique. dés que tu utilises allez 90% des
resources, tu ajoutes un autre serveur physique dans le
cluster de la virtualisation, et les 100 machines virtuelles
se deplacent sans coupure sur les 2 serveurs physiques.
puis dans la journée à 17h tu vas peut etre tourner à 20
machines physiques pour 100 machines virtuelles. puis au
fur et à mesure de la soirée tu vas couper les machines
physique et ordonner de consolider toutes les machines
virtuelles sur le minimum de machines physiques.
les +
+ peu de serveur physique pour assurer le service
+ l'utilisation réelle de chaque serveur physique est
quazi parfaite et varie entre 50% à 100%
+ qualité de service parfait
+ consomation en energie proportionnelle à la charge
+ capacité de burst importante (mais depend du stock
de serveurs physique coupées electriquement et prêts
à demarrer)
+ administration simple à travers les interfaces ou api
+ possibilitée d'automatiser tout à 100%
les -
- le stockage doit être distant et ne doit pas se faire
sur le serveur physique (sinon pas de bascule de machine
virtuelles d'un serveur physique à un autre)
- le cout de licence par machine virtuelle qui augmente
si on veut faire de moins en moins de sysadmin, voir
plus du tout. on peut choisir une licence où il n'y a
plus rien à faire en sysadmin. l'infra se gere toute
seule.
dans tout ceci, la consomation electrique est un facteur important
si et seulement si tu geres l'infra chez toi. à partir du moment
où c'est hébergé chez un hébergeur avec une location mensuelle au
forfait, tout le monde s'en fout tous les arguments type vous
consommez moins, car c'est pas le client qui fait les économies
mais l'hébergeur.
la virtualisation est génial mais il y a 2 mais important:
- il faut savoir gerer le stockage sur le reseau et en haute
disponibilitée
- il faut créer le reseau haute disponibilitée et garantie
c'est à dire 40Gbps / baie d'uplink pour assurer le stockage
sur le reseau qui ne peut pas bien marcher avec les liens
saturés.
nous concernant:
le 1.) c'est notre cluster de l'hébergement mutualisé http et sql
on a prés de 1 serveurs web et 300 sql. tout en serveur physique.
le 3.) c'est le privateCloud (pcc),
le 1.) va passer en 3.) sous quelques mois avec la 1ere phase sql
qui demarre dans 2 semaines. l'idée est de remplacer 300 serveurs
2U (les serveurs sql bicpu/plein de ram) par l'équivant en machine
virtuelles en passant de 15 baies, 150KVA à 4 baies, 40KVA. on
ajoute à ceci le temps de mise en service d'un nouveau serveur
sql qui va passer de 5 jours à 3 minutes, les mises à jour soft
automatisé, haute disponibilitée du service, pas de sysadmin. même
s'il y a de licences à payer, le tout va couter plusieurs dizaines
fois moins chaque mois.
les syadmins n'aiment pas le cloud computing pour une raison très
simple: cela les oblige à changer/évoluer leur metier vers la
maitrise d'oeuvre et donc connaitre les technos sur les bouts de
doigts, puis savoir choisir la meilleur et donc faire pas mal de
RD pour être au courant de tout ce qui existe. c'est chiant. on
constate souvent le c'est bien comme c'est et la non remise en
cause. il n'y a qu'une chose qui
