Auteur Sujet: Online : 288 serveurs dans 1 chassis ATCA 21 pouces  (Lu 20247 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 28 626
    • Twitter LaFibre.info
Online : 288 serveurs dans 1 chassis ATCA
« Réponse #12 le: 25 octobre 2014 à 11:59:36 »
En fait j'ai fais un peu de virtualisation avec Xen + Libvirt puis kvm + Libvirt et dans les deux cas je n'ai jamais osé mettre en service plus de VM que je n'ai de cœur logiques dans la machine (et incluant un cœur pour le manager).

Une société que je connais fait de la virtualisation Xen avec des serveurs d'entrée de gamme (1 socket Xeon 4 cœurs 8 threads) et ils attribuent 3 VM (DomU) Windows Server par machine physique, chacun avec 2 VCPU et 1/4 de la RAM. Il reste donc 1/4 de la ram et 2 VCPU pour Xen (Dom0)

J'ai aussi loué une VM sous VMware et quand on m'a dit que j'avais 4VCPU, je pensais que ces 4 VCPU étaient dédiés.

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 340
  • Malissard (26)
Online : 288 serveurs dans 1 chassis ATCA
« Réponse #13 le: 25 octobre 2014 à 12:04:52 »
L'un des avantages de la virtualisation c'est de justement partager au maximum des ressources physiques. Le CPU, c'est très facile à partager lorsque tu as beaucoup d'idle sur tes VM.

Concrètement, pour des VM d'infra type AD, DNS, LDAP, DHCP, et j'en passe, tu peux en coller des dizaines sans problème, vu qu'elles passent leur temps à "glander" :)
Pour d'autres applications, ça va etre plus critique : on ne mettra pas plusieurs serveurs SQL si on n'a pas suffisamment de ressource à moins que plusieurs d'entre eux soit faiblement utilisé.

Nico

  • Modérateur
  • *
  • Messages: 31 214
  • FTTH 300Mbps sur Paris 15ème (75)
    • @_GaLaK_
Online : 288 serveurs dans 1 chassis ATCA
« Réponse #14 le: 25 octobre 2014 à 12:09:03 »
Sur mon ESXi j'ai 2 cœurs et 7 VM actives. Mais clairement c'est ni de la prod', ni des VM qui prennent beaucoup de ressources donc ça gène pas.

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 125
  • FTTH 1Gb/s sur Paris (75)
Online : 288 serveurs dans 1 chassis ATCA
« Réponse #15 le: 25 octobre 2014 à 13:18:45 »
Concrètement, pour des VM d'infra type AD, DNS, LDAP, DHCP, et j'en passe, tu peux en coller des dizaines sans problème, vu qu'elles passent leur temps à "glander" :)

oui c'est "l'ancienne" façon de faire avec plein de VMs mais il y  des inconvénients notamment de couts (licences) et le fait d'avoir plein d'OS a gérer (maj, secu, acces, etc) en plus des apps qui tournent dessus. Sans parler des problèmes de versions et dépendances entre apps et OS.

La tendance du moment, utilisé en interne par Google notamment (ils n'ont aucune VM sur leur millions de serveurs), est d'utiliser des LXC (Linux Container).


Au lieu d'avoir plusieurs "guest OS" et l'hyperviseur (type 2 la mais c'est idem en type 1) a gérer on n'a juste un 'host OS' minimum simplissime et des containers qui sont des instances d'images "toutes prêtes". La distribution et la configuration des containers s'automatise très facilement, notamment avec Docker. Les ressources sont aussi utilisées plus finement et ca se 'scale' très facilement sur plusieurs machines physiques.

On peut même mélanger les 2 technos (virtualization and containerization).

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 340
  • Malissard (26)
Online : 288 serveurs dans 1 chassis ATCA
« Réponse #16 le: 25 octobre 2014 à 13:28:15 »
Pour moi Google ce n'est pas "la vraie vie", c'est... Google :)

J'ai des fermes d'ESX, j'ai eu du Citrix XenServer et j'ai de l'OpenVZ qui est proche de ce que tu décris.

Et bien, en terme de souplesse d'utilisation, ESX est loin, très loin, devant. En terme de couts aussi ! :D

Bon on s'éloigne du sujet : quelles applications va-t-on faire tourner sur nos ARMv7 ? A priori, pas quelque chose qu'on sait virtualiser facilement.

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 125
  • FTTH 1Gb/s sur Paris (75)
Online : 288 serveurs dans 1 chassis ATCA
« Réponse #17 le: 25 octobre 2014 à 14:47:04 »
On est pile dans le sujet en fait et c'est indiqué sur leur site: ce sont des serveurs conçus pour ce qu'ils appellent de la 'physicalization':

Physicalization is the opposite of virtualization. It is a process where we increase the server density with energy efficient SoC to provide flexible computing.

With a density of 1000 (one thousand) servers per rack, we offer an hardware based alternative to virtualized services.

Si l'application se 'scale' facilement alors c'est moins cher d'avoir une solution comme ca , sans virtualisation. On a adapte le nombre de serveurs a la demande (scaling horizontal).

Au lieu d'avoir quelques gros serveurs x64 (xeon) faisant tourner plein de VMs et des gros paliers de croissance 'physiques', on a plein de petits serveurs ARM qui consomment moins et des petits paliers de croissance. La granularité physique correspond a la granularité applicative qu'on souhaite.

C'est vraiment dans la mouvance du moment des applications Cloud et de la façon dont on est les construit.

Apres c'est sur que c'est pas du tout adapté pour faire du Cloud a l'ancienne: aka virtualiser un SI 'Windows traditionnel' (AD, Exchange, serveurs de fichiers, etc) dans un DC (privé ou tiers) par exemple. On est pas dans le même sujet la.


remy74

  • Client K-Sys (Suisse)
  • *
  • Messages: 39
  • Saint-Sixt (74)
Online : 288 serveurs dans 1 chassis ATCA
« Réponse #18 le: 25 octobre 2014 à 22:40:05 »
L'idée n'est pas vraiment nouvelle. Elle avait été tenté par un projet (hardware) Calxeda, pour promouvoir les proc ARM. L'intérêt principal, pour moi, c'est la conso, et la clim (donc encore la conso.)
Pour exploiter des clusters Esxi, un des problèmes, c'est la consommation électrique. Parce qu'en virtualisation, il faut laisser les processeurs au max. Par exemple, le partage des ressources sur VMware, c'est le ralentissement des cores qui sont surchargés. Et donc de toutes les VM sur le même Esxi.D'ailleurs il n'y a qu'a voir les horloges des VM, s'il n'y a pas de synchro NTP externe.

Il existe du hardware, comme les serveurs Hp Moonshot qui sont dans le même esprit.
La question, c'est effectivement les applications (au delà, de l'OS). Mais c'est déjà possible, des frontaux web, même des bases de données.
Le gros avantage, c'est justement de pouvoir allumer ou éteindre le hardware inutilsé.
 

willemijns

  • Client Free adsl
  • *
  • Messages: 1 199
Online : 288 serveurs dans 1 chassis ATCA
« Réponse #19 le: 28 octobre 2014 à 21:26:54 »
Apres c'est sur que c'est pas du tout adapté pour faire du Cloud a l'ancienne: aka virtualiser un SI 'Windows traditionnel' (AD, Exchange, serveurs de fichiers, etc) dans un DC (privé ou tiers) par exemple. On est pas dans le même sujet la.

hum... ca revient pas au meme a la fin ?

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 529
  • La Madeleine (59)
Online : 288 serveurs dans 1 chassis ATCA
« Réponse #20 le: 28 octobre 2014 à 23:49:56 »
Hum, je suis plutôt dubitatif

Au niveau souplesse, je pense vraiment qu'un container est plus simple à gérer que plein de petite machines (d'ailleurs, comme les allume-t-on ?)
Au niveau énergie, un gros CPU inutilisé consomme peu (voir les notions de fréquences variables etc), et est bien plus réactif

Parmi les différentes hypothéses avancées :
- pour la parallèlisation: l'algorithmie distribuée est compliquée et est peut fréquente, j'imagine sans soucis que les clients préfèrent une grosse machine à dix petites
- la granularité de l'offre: à mon avis, le prix d'un serveur "classique" est négligeable face aux travaux de gestions (gérer deux serveurs est plus simple que gérer 20 serveurs, et coute donc moins cher)

À mon avis, c'est plutôt :
- pour faire la une!
- pour vendre du "dédié" à des petits besoins (avec la com qui va avec: matériel dédié, garanti etc etc etc)

Sinon, en vrac: BadMax, utilise Ganeti
Vivien: tu peux tout à fait mutualiser le CPU; sur l'un de mes serveurs (16 CPU), j'ai 10VM, avec un total de 30VCPU: au niveau de l'hôte (j'utilise kvm), chaque VM n'est qu'un groupe de n processus, n étant le nombre de VCPUS alloués à la VM: c'est le scheduler qui se charge de faire le reste, en repartissant les ressources parmis ceux qui en ont besoins. Ainsi, si chaque VM demande 100% des VCPUS, ils l'auront, mais la puissance nominale de chaque VCPUS ne sera plus qu'une portion de la puissance du CPU physique.
On peut voir cela comme une limite garantie et une limite "burst" : dans mon cas, une VM qui dispose de 3 VCPUS aura une puissance maximal de 3 CPU, et une puissance garantie de (16/30) * 3 = 1.6 CPU

willemijns

  • Client Free adsl
  • *
  • Messages: 1 199
Online : 288 serveurs dans 1 chassis ATCA
« Réponse #21 le: 29 octobre 2014 à 09:27:16 »
> À mon avis, c'est plutôt :
> - pour faire la une!
> - pour vendre du "dédié" à des petits besoins (avec la com qui va avec: matériel dédié, garanti etc etc etc)

ouep.... a savoir si un des nombreux composant d'un bloc non dominant est HS, ca permet peut etre à ne pas planter tout et on peut l'isoler... comme un secteur de dique dur....... nom de code "lissage des pannes"






kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 125
  • FTTH 1Gb/s sur Paris (75)
Online : 288 serveurs dans 1 chassis ATCA
« Réponse #22 le: 29 octobre 2014 à 09:29:42 »
hum... ca revient pas au meme a la fin ?

comment ca ?

Parmi les différentes hypothéses avancées :
- pour la parallèlisation: l'algorithmie distribuée est compliquée et est peut fréquente, j'imagine sans soucis que les clients préfèrent une grosse machine à dix petites

Il y beaucoup de progrès fait dans ce domaine.
C'est certain qui si on part sur une programmation traditionnelle ca va être complexe de faire tourner ca dans ce type de machines. Dans ce cas, il vaut mieux rester sur du hardware traditionnel.

- la granularité de l'offre: à mon avis, le prix d'un serveur "classique" est négligeable face aux travaux de gestions (gérer deux serveurs est plus simple que gérer 20 serveurs, et coute donc moins cher)
Le rack entier de 228 serveurs doit être vu comme une seul machine 'a gérer' et a comparer a un serveur 'classique'.

Ce qu'on voit actuellement est issue de 2 phénomènes:

- d'un coté les progrès énormes en terme de cout, puissance et conso des CPU pour mobiles (SoC). Ce marché est d'une telle masse (plusieurs milliards d'unité par an ?) que l'idée est d'essayer d'en profiter dans le "monde des serveurs et  DC'.

- d'un autre coté, l'évolution de la programmation distribuée et des langages et outils associés. Depuis un certains temps déjà, on a n'a plus l'habituelle 'loi de Moore' ou la puissance de unité de traitement de base (cpu) doublait tout les 18 mois. On a compenser avec du parallélisme, multi core et autres techniques, ce qui permet de garder 'la loi' mais il faut adapter le code pour exploiter ce parallélisme.
A partir du moment ou on commence a maîtriser ce parallélisme on n'a plus forcement besoin de CPU puissants, gros et complexes. L'évolution va donc vers des CPU plus simples mais nombreux: c'est pile poil ce que propose le monde des SoC mobiles.

Il y une synergie forte exploitable entre ces 2 mondes. Mais il faut les 2 ensemble. Donc pas de code traditionnel sur ces machines ni l'inverse.

willemijns

  • Client Free adsl
  • *
  • Messages: 1 199
Online : 288 serveurs dans 1 chassis ATCA
« Réponse #23 le: 29 octobre 2014 à 09:47:08 »
> comment ca ?

que si j'ai besoin de savoir 1+1, on me donnera 2 en réponse avec 1 gros CPU ou 200 mini-CPU ;) voila un peu la réponse noob que je fais...

 

Mobile View