La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => Scaleway => Discussion démarrée par: Leon le 25 octobre 2014 à 08:24:25
-
Voilà la nouvelle "innovation" de Online.
On compte 288 serveurs dans un chassis qui ressemble à du ATCA. 18 serveurs par carte, 16 cartes.
On peut donc imaginer ~600 serveurs dans un seul chassis.
(https://lafibre.info/images/datacenter/201410_online_cloud_serveurs_armv7_1.jpg)
(https://lafibre.info/images/datacenter/201410_online_cloud_serveurs_armv7_2.jpg)
Online Labs - Making the next generation of cloud - Fully hardware based (https://www.youtube.com/watch?v=XFhgSKNJP2s#ws)
https://doc.cloud.online.net/faq/server_faq.html (https://doc.cloud.online.net/faq/server_faq.html)
Personnellement, j'ai du mal à comprendre le concept. Les processeurs sont peu puissants.
Quel est l'intérêt de répartir autant la "puissance de calcul" sur autant de petits systèmes peu puissants? Est-ce que ça ne ressemble pas à du gaspillage de ressource?
Quels sont les clients visés? Uniquement des seedbox? Ou autre chose?
4 coeurs ARMv7, 2Go de RAM, c'est très peu pour un serveur.
Leon.
-
Alors précisèment il faut compter 864 serveurs / baie (soit 3 chassis). Si j'ai bien compris, l'idée est de faire du cloud hardware, pas d'utiliser juste une seule machine mais de pouvoir en utiliser autant que tu veux à la demande.
-
Alors précisèment il faut compter 864 serveurs / baie (soit 3 chassis). Si j'ai bien compris, l'idée est de faire du cloud hardware, pas d'utiliser juste une seule machine mais de pouvoir en utiliser autant que tu veux à la demande.
OK, j'ai bien compris que c'était du "cloud hardware". Mais quel est l'intérêt de déployer des serveurs aussi peu puissants? N'est-il pas plus intéressant d'utiliser, toujours "à la demande", des machines plus puissantes? Comme le propose "runabove" d'OVH? Quels peuvent être les clients/utilisations de machines aussi peu puissantes?
Leon.
-
runabove c'est du cloud hardware ? Là l'intérêt c'est d'avoir la main sur la totalité de la machine. Et si c'est peu puissant, la densité fait qu'au final sur une lame t'as quand même pas mal de puissance dispo. Tu peux décider de manière assez fine de la puissance dont tu as besoin.
-
Le look de ces serveurs ressemblent à un DSLAM Free v1 qui eut même sont identiques aux DSLAM de feu Lucent.
Au lieu de mettre des chips ADSL Broadcom, ce sont des CPU ARMv7 64bits
L’intérêt est de proposer une alternative à la virtualisation pour ne pas payer pour des logiciels évolués de virtualisation.
Cela me semble diablement intelligent.
Les ressources d'entrée/sortie sont mutualisés mais pas le processeur et la ram.
En virtualisation généralement ta achète des cœurs de Xeon. Donc si ta VM est inutilisée, la puissance CPU ne peut être utilisé par d’autres VM. Pour la RAM par contre VMware permet d’allouer dynamiquement de la RAM en fonction des besoins sous réserve d'avoir un système d’exploitation compatible.
-
En virtualisation généralement ta achète des cœurs de Xeon. Donc si ta VM est inutilisée, la puissance CPU ne peut être utilisé par d’autres VM.
Cela doit etre ta facon de le dire ou ma facon de le comprendre mais je ne suis pas d'accord avec ca.
Prenons un serveur 1 CPU physique 4 coeurs pour simplifier, ca fait 4 virtual CPU
avec 16 VM chacune utilisant un virtual CPU un coeur est utilise en moyenne par 4 VM (16/4) donc la puissance CPU est bien utilisee par d'autres VM
-
Tout à fait, un processeur n'est jamais dédié à une VM. Ce n'est qu'une ressource partagée comme la RAM et les I.O. Au mieux, on peut garantir des ressources CPU à une VM mais pas dédier un CPU.
Pour répondre à Léon, des ARMv7 peuvent etre suffisant pour faire tourner des services simples (DNS, relai SMTP) ou des services WEB pas trop lourd. On verra si Online en déploie à grande échelle auquel cas cela signifiera qu'ils en ont trouvé une utilisation :)
-
Mais un cluster d'ARMv7 ne peut pas faire tourner des trucs plus lourds ? Pour moi c'était ça l'idée...
-
Je suis allé jouer avec : c'est pas beaucoup plus puissant qu'un RPi sauf que t'as 4 coeurs. Donc quand t'arrives à t'en servir c'est pas mal.
Faut voir le prix : à 1 ou 2€ / mois, pourquoi pas pour gérer des applications simples.
-
@Nico : de la virtualisation avec des ressources garanties, 100% dédiées, ça existe. 1VM par core par exemple.
C'est ce que propose OVH (Runabove) et d'autre fournisseurs. Voir la partie "steadfast ressources" d'OVH Runabove.
A l'extrême, tu as les offres "1VM/Host" de Runabove.
Mais un cluster d'ARMv7 ne peut pas faire tourner des trucs plus lourds ? Pour moi c'était ça l'idée...
Quelle application aurait plus d'intérêt à tourner sur plusieurs machines peu puissantes plutôt que sur 1 seule puissante? J'ai vraiment du mal à voir.
A l'opposé, les processeur puissant et fortement multi-coeur me semblent quand même mieux adaptés aux offres Cloud, au partage de ressources réellement efficace, et à l'efficacité énergétique. Voir le partenariat d'OVH avec IBM sur les processeurs "power-8" (12 coeurs, jusqu'à 96 threads).
https://fr.wikipedia.org/wiki/POWER8 (https://fr.wikipedia.org/wiki/POWER8)
http://labs.runabove.com/power8/ (http://labs.runabove.com/power8/)
Leon.
-
Je ne comprends peut-être pas tout, mais je suppose que pour gérer de petits domaines avec petit site web, mails, cloud photo/vidéo, seedbox et vpn ça peut suffire pour beaucoup de petits clients.
Ensuite, il est probablement aisé de changer d'offre si les exigences/volumétries augmentent.
Je suppose que le client lambda de cloud google/apple et autres va commencer à comprendre que comme le mail au début des années 2000, il est parfois préférable de gérer son cloud en étant indépendant le plus possible. Je suppose que ça peut répondre à ça... Jusqu'au besoin des TPE (moins de 5 personnes avec usages "moyens")
-
Ca m'a l'air bien pour faire du Docker/LXC qui est la tendance du moment en infra Cloud. La virtualisation classique (VMware & les autres) c'est lourd et cher et rajoute une couche pour rien (ca m'étonnerai pas que ça disparaisse a terme d'ailleurs).
Pour l'instant ils n'ont pas d'offre a base de CoreOS ou Boot2Docker mais ils supportent l'image qu'on veut donc ca peut le faire.
Reste a voir le pricing.
-
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.
-
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é.
-
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.
-
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).
(http://patg.net/assets/container_vs_vm.jpg)
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 (https://www.docker.com/). 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).
-
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.
-
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.
-
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é.
-
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 ?
-
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
-
> À 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"
-
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.
-
> 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...
-
La parallélisation n'est pas si compliquée.
Par ex, j'ai des logiciels clients qui demandent les headers de 250.000 articles d'un newsgroup d'un coup. Bah au lieu de balancer de ce gros truc, je découpe en 50.000 et je fais une boucle qui exécute un new process avec le bon découpage. Du coup j'ai 5 CPU qui s'occupe de la demande en même temps + celui qui gère le socket avec le client qui reçoit les datas au fur et à mesure et ça envoie :)
C'est redoutable sur RunAbove avec le Power8 d'IBM ! (pour le portefeuille aussi ^^ )
Après c'est une question d'habitude dans le dev, c'est sûr.
-
Ton exemple est bon parce que ça tourne sur le meme environnement :)
Sur plusieurs machines, il faut donc prévoir un mécanisme pour lancer les exécutions à distance et récupérer les résultats. On peut éventuellement se débrouiller avec du NFS mais ça devient un peu plus compliqué.
Ou alors on fait tourner RunAbove sur les infras Online ? :D
-
Python te permet de distribuer tes process au-delà de ta seule machine avec ses "Managers" par ex. Tout est fourni de base.
Par contre je n'ai pas encore réussi à obtenir des infos depuis le process enfant, il faut que le parent fasse la requête pour ensuite tout refiler à l'enfant pour qu'il puisse bosser.
Du coup je préfère déployer mon logiciel serveur sur X machines et faire un gros haproxy devant :)
-
> 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...
Tout n'est pas parallélisable et tout n'as pas forcement besoin de la puissance maxi d'un seul CPU.
"1+1" une seul fois ca ne se parallélisme pas bien donc plus le cpu sera rapide puis vite ca se calcule.
Mais s'il faut faire "1+1" 200 fois.
Soit je prend un gros CPU a 4 coeurs et je fais '1+1' 50 fois de suite sur chaque coeur.
Soit je fais '1+1' une seul fois sur 200 mini-cpu en meme temps.
En temps, c'est pareil uniquement si un cœur du gros CPU est 50 fois plus rapide qu'un mini-cpu.
En coûts ramenés au temps ca n'est pas pareil non plus. Dans couts, on prend en compte le hardware, le software (licences, etc) , le volume occupé, le personnel nécessaire, la conso électrique, etc.
Apres il y aussi le probleme de 'générer' 200 fois le calcul de '1+1' sur 200 mini-cpu et de 'recuperer' les 200 resultats.
Pareil en mono CPU, si ce sont 200 programmes différents virtualisés sur 4 cœurs d'un seul CPU (donc 200 OS virtuels derrière) ou juste un seul programme (donc un seul OS). Car ca peut être 200 clients differents qui veulent faire '1+1' en meme temps par exemple ou le meme.
Et encore on ne fait qu’effleurer la complexité des 2 façons de faire et des cas possibles...
Certains traitements ou calculs n'ont pas besoin de puissance des gros CPU actuels car ils font surtout des transferts (réseau ou disque) et peu de calculs. D'autres font l'inverse, beaucoup de calcul CPU mais de transferts. D'autres les 2. etc
Il n'y a pas de hardware/plateforme idéale et universelle.
-
Certains traitements ou calculs n'ont pas besoin de puissance des gros CPU actuels car ils font surtout des transferts (réseau ou disque) et peu de calculs. D'autres font l'inverse, beaucoup de calcul CPU mais de transferts. D'autres les 2. etc
Il n'y a pas de hardware/plateforme idéale et universelle.
on est d'accord... apres on peut dedier des plateformes en fonction des besoins et faire varier le prix... c'est ce qui est
prévu par une société de mini DC dans un radiateur/chauffe-eau...
-
Tout les problèmes ne sont pas facilement parallélisable
Pour ce type de cas, la seule solution est de résoudre plusieurs problèmes en parallèle, chaque problème restant monolithique
Pour finir, je rajouterais que la parallélisation n'implique pas forcement un gain de performance: la synchronisation est drastiquement plus lente entre les machines
En fait, il faut s'assurer que le calcul qui est déporté est suffisamment long pour "valoir le coup" de le déporter
-
Une personne a une invitation, pour que je puisse tester le serveur d'Online ?
Par défaut on se connecte comment si il n'y a pas d'IP publique ?
Why do I have a private IP?
We chose to use NAT for IPv4 addresses.
The NAT is needed to get movable IP addresses and help us face the shortening of IPv4 addresses.
We implemented a custom solution to provide line-rate NAT.
-
Va sur http://labs.online.net (http://labs.online.net)
"Try It now"
T'as droit à seulement 15minutes :)
-
Je t'envoie ça sur quel mail vivien ?
-
Noyeau Linux 3.17 ?
C'est du customisé, Ubuntu 14.10 est livré avec le noyau 3.16 (en tout cas sur base Intel)
c1-10-1-15-25 login: ubuntu
Password:
Welcome to Ubuntu 14.10 (GNU/Linux 3.17.0-90 armv7l)
* Documentation: https://help.ubuntu.com/
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
ubuntu@c1-10-1-15-25:~$ uname -a
Linux c1-10-1-15-25 3.17.0-90 #7 SMP Mon Oct 20 13:54:37 CEST 2014 armv7l armv7l armv7l GNU/Linux
ubuntu@c1-10-1-15-25:~$ free -m
total used free shared buffers cached
Mem: 2020 493 1527 0 38 389
-/+ buffers/cache: 65 1955
Swap: 0 0 0
ubuntu@c1-10-1-15-25:~$ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 2 (v7l)
Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae
CPU implementer : 0x56
CPU architecture: 7
CPU variant : 0x2
CPU part : 0x584
CPU revision : 2
processor : 1
model name : ARMv7 Processor rev 2 (v7l)
Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae
CPU implementer : 0x56
CPU architecture: 7
CPU variant : 0x2
CPU part : 0x584
CPU revision : 2
processor : 2
model name : ARMv7 Processor rev 2 (v7l)
Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae
CPU implementer : 0x56
CPU architecture: 7
CPU variant : 0x2
CPU part : 0x584
CPU revision : 2
processor : 3
model name : ARMv7 Processor rev 2 (v7l)
Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae
CPU implementer : 0x56
CPU architecture: 7
CPU variant : 0x2
CPU part : 0x584
CPU revision : 2
Hardware : Marvell Armada 370/XP (Device Tree)
Revision : 0000
Serial : 0000000000000000
$ ifconfig
docker0 Link encap:Ethernet HWaddr 56:84:7a:fe:97:99
inet addr:172.17.42.1 Bcast:0.0.0.0 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth0 Link encap:Ethernet HWaddr 00:07:cb:03:3a:2d
inet addr:10.1.15.25 Bcast:10.1.15.255 Mask:255.255.254.0
inet6 addr: fe80::207:cbff:fe03:3a2d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:135680 errors:0 dropped:0 overruns:0 frame:0
TX packets:34671 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:125438138 (125.4 MB) TX bytes:523213621 (523.2 MB)
Interrupt:24
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
-
Pas d'IPv6 proposé dans le test mais la machine assure avec IPERF :
$ iperf -c 3.testdebit.info -i 2 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 3.testdebit.info, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 5] local 10.1.18.40 port 57802 connected with 89.84.127.55 port 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0- 2.0 sec 212 MBytes 890 Mbits/sec
[ 5] 2.0- 4.0 sec 181 MBytes 760 Mbits/sec
[ 5] 4.0- 6.0 sec 165 MBytes 691 Mbits/sec
[ 5] 6.0- 8.0 sec 164 MBytes 688 Mbits/sec
[ 5] 8.0-10.0 sec 164 MBytes 690 Mbits/sec
[ 5] 0.0-10.0 sec 887 MBytes 744 Mbits/sec
[ 4] local 10.1.18.40 port 5001 connected with 89.84.127.55 port 42827
[ 4] 0.0- 2.0 sec 128 MBytes 537 Mbits/sec
[ 4] 2.0- 4.0 sec 127 MBytes 531 Mbits/sec
[ 4] 4.0- 6.0 sec 93.9 MBytes 394 Mbits/sec
[ 4] 6.0- 8.0 sec 94.6 MBytes 397 Mbits/sec
[ 4] 8.0-10.0 sec 100 MBytes 421 Mbits/sec
[ 4] 0.0-10.0 sec 545 MBytes 456 Mbits/sec
$ iperf -c ipv4.intuxication.testdebit.info -i 2 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to ipv4.intuxication.testdebit.info, TCP port 5001
TCP window size: 48.1 KByte (default)
------------------------------------------------------------
[ 5] local 10.1.18.40 port 44321 connected with 62.210.156.12 port 5001
[ ID] Interval Transfer Bandwidth
[ 5] 0.0- 2.0 sec 222 MBytes 930 Mbits/sec
[ 5] 2.0- 4.0 sec 175 MBytes 734 Mbits/sec
[ 5] 4.0- 6.0 sec 166 MBytes 694 Mbits/sec
[ 5] 6.0- 8.0 sec 166 MBytes 696 Mbits/sec
[ 5] 8.0-10.0 sec 166 MBytes 698 Mbits/sec
[ 5] 0.0-10.0 sec 895 MBytes 751 Mbits/sec
[ 4] local 10.1.18.40 port 5001 connected with 62.210.156.12 port 52806
[ 4] 0.0- 2.0 sec 143 MBytes 599 Mbits/sec
[ 4] 2.0- 4.0 sec 124 MBytes 518 Mbits/sec
[ 4] 4.0- 6.0 sec 179 MBytes 750 Mbits/sec
[ 4] 6.0- 8.0 sec 175 MBytes 732 Mbits/sec
[ 4] 8.0-10.0 sec 125 MBytes 523 Mbits/sec
[ 4] 0.0-10.0 sec 746 MBytes 623 Mbits/sec
-
Va sur http://labs.online.net (http://labs.online.net)
T'as droit à seulement 15minutes :)
quel est le login ?
-
N'est-ce pas noté en dessous de la console ?
Server detail
Expiring in:14 minutes, 10 seconds.
IP Address: 212.47.235.178
Login: ubuntu
Password: 9eAmwS
-
N'est-ce pas noté en dessous de la console ?
oops :-X merci. je n'ai que cherché dans le haut et point en bas....
-
Un article sur les serveurs ARMv7 d'Online.
Personnellement, je n'y crois toujours pas, et je ne vois pas bien à quel besoin ça peut correspondre. Imaginez qu'il faut tout de même recompiler ses exécutables pour ARM, qui est incompatible avec x86.
http://techcrunch.com/2014/11/13/online-labs-designed-its-own-arm-servers-to-take-on-aws-digitalocean/
Online Labs Designed Its Own ARM Servers To Take On AWS, DigitalOcean
A couple of years ago, the team behind Online Labs started a long ambitious project — instead of building a virtual cloud hosting infrastructure that competes directly with Amazon Web Services, DigitalOcean and other VPS providers, it designed its own hardware for its cloud solution. Online Labs managed to squeeze 912 separate computers in a single server rack. But the best part is that the company also kept the best of both worlds — dedicated servers with the flexibility of virtualization.
“We started this project two and half years ago, and we designed our own hardware from scratch as we couldn’t find what we wanted on the market at the time,” VP of Product Yann Léger told me in a phone interview. “We used an ARM architecture because we wanted a scalable physical cloud.”
When you start a server on Online Labs, it takes about 30 seconds. Yet, the company isn’t just launching a virtual machine on an already running server, it is actually booting an ARM server just for you.
There are many advantages to using dedicated hardware. For example, you won’t share your CPU with other users and end up with disappointing performances. Behind the scene, Online Labs uses the same ARM v7 systems on a chip that you would find in your smartphone. On one chip, you will find four different cores that are very thermal efficient. It’s less powerful than a dedicated Xeon server, but it is also very appealing for many developers.
Each server comes with 2GB of RAM, a 20 GB SSD, and a 1 Gbit/s network interface. You can add more storage and integrate with Amazon S3. And of course, you can start multiple servers in a few minutes if you need more resources.
Now, there are some limitations. First, as these servers use an ARM architecture, you can’t use x86 binaries and operating systems. For now, the company provides the usual suspects when it comes to distributions, Ubuntu, Debian, Gentoo, etc. You can also run Docker. Popular runtimes already have an ARM variant, but more obscure binaries might need some work. Some of Online Labs’ engineers are porting these binaries themselves.
For now, there is only one type of server. If you want more computing power, the only solution is to start a new server and balance the load. It’s not ideal, and the team is already working on more powerful hardware with more RAM. All the servers are hosted in Iliad’s data center in Paris, but a second data center based in the U.S. is in the works.
The true innovation behind Online Labs is how flexible it is. Just like when you use a VPS, you can make a snapshot, load an image and more. You can even move your public IP address from one machine to another.
Another interesting part, Online Labs is not based on OpenStack, everything was developed internally. The team also developed an API to manage your servers.
There are countless of little details that show how polished Online Labs already is. It’s a new take on cloud hosting, and a very different one. The team recently launched a public preview to try the infrastructure. More than 100,000 servers are already running.
“When it comes to pricing, we should be competitive with other cloud hosting solutions providing the same performance,” Léger said.
There is still a long way to go to take care of every developer’s needs. For example, DigitalOcean now has many data centers around the world and a wide range of configurations. But Online Labs is definitely a promising alternative.
Leon.
-
A priori le châssis est repris des anciens DSLAM pré-VDSL2. Rien ne se perd :D
-
Pas besoin de compiler, les distributions Linux Ubuntu et Debian sont déjà adaptées. (Online donne le choix entre Ubuntu, Debian et Gentoo)
Voici une page pour faire des téléchargements sur un serveur Online ARM
Débit du serveur ARM, quand on télécharge un fichier du serveur ARM depuis Internet : 56,8 Mio/s soit 476,5 Mb/s (c'est le réseau qui limite, pas le SSD)
100%[========================================================================>] 5 000 000 000 58,7M/s ds 84s
2014-11-15 18:39:35 (56,8 MB/s) - «/dev/null» sauvegardé [5000000000/5000000000]
On a le même débit si le fichier est en cache en ram par contre j'ai réalisé le test avec un fichier plus petit, car un fichier de 5 Go ne tient donc pas dans les 2 Go de ram du serveur.
Le SSD a un très haut débit en lecture mais pas en écriture :
Écriture sur le SSD d'un fichier de 5Go : 13,5 Mio/s (c'est le SSD qui limite, pas le réseau)
# wget http://ipv4.intuxication.testdebit.info/fichiers/5000Mo.dat
--2014-11-15 17:14:22-- http://ipv4.intuxication.testdebit.info/fichiers/5000Mo.dat
Resolving ipv4.intuxication.testdebit.info (ipv4.intuxication.testdebit.info)... 62.210.156.12
Connecting to ipv4.intuxication.testdebit.info (ipv4.intuxication.testdebit.info)|62.210.156.12|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5000000000 (4.7G) [application/x-ns-proxy-autoconfig]
Saving to: ‘5000Mo.dat’
100%[=========================================================================================================================================================================>] 5,000,000,000 13.5MB/s in 4m 11s
2014-11-15 17:18:33 (19.0 MB/s) - ‘5000Mo.dat’ saved [5000000000/5000000000]
Récupération du même fichier sur Internet, sans l'écrire sur le SSD (vers /dev/null) : 43,8 Mio/s soit 367,4 Mb/s
# wget -O /dev/null http://ipv4.intuxication.testdebit.info/fichiers/5000Mo.dat
--2014-11-15 17:30:11-- http://ipv4.intuxication.testdebit.info/fichiers/5000Mo.dat
Resolving ipv4.intuxication.testdebit.info (ipv4.intuxication.testdebit.info)... 62.210.156.12
Connecting to ipv4.intuxication.testdebit.info (ipv4.intuxication.testdebit.info)|62.210.156.12|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5000000000 (4.7G) [application/x-ns-proxy-autoconfig]
Saving to: ‘/dev/null’
100%[=========================================================================================================================================================================>] 5,000,000,000 42.4MB/s in 1m 49s
2014-11-15 17:32:00 (43.8 MB/s) - ‘/dev/null’ saved [5000000000/5000000000]
Informations sur le CPU :
# uname -a
Linux c1-10-1-16-158 3.17.0-113 #1 SMP Tue Nov 4 15:43:28 CET 2014 armv7l armv7l armv7l GNU/Linux
# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 2 (v7l)
Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae
CPU implementer : 0x56
CPU architecture: 7
CPU variant : 0x2
CPU part : 0x584
CPU revision : 2
processor : 1
model name : ARMv7 Processor rev 2 (v7l)
Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae
CPU implementer : 0x56
CPU architecture: 7
CPU variant : 0x2
CPU part : 0x584
CPU revision : 2
processor : 2
model name : ARMv7 Processor rev 2 (v7l)
Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae
CPU implementer : 0x56
CPU architecture: 7
CPU variant : 0x2
CPU part : 0x584
CPU revision : 2
processor : 3
model name : ARMv7 Processor rev 2 (v7l)
Features : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae
CPU implementer : 0x56
CPU architecture: 7
CPU variant : 0x2
CPU part : 0x584
CPU revision : 2
Hardware : Marvell Armada 370/XP (Device Tree)
Revision : 0000
Serial : 0000000000000000
# free -m
total used free shared buffers cached
Mem: 2020 1838 182 0 1 1788
-/+ buffers/cache: 48 1972
Swap: 0 0 0
-
Plus dur : en HTTPS le serveur s'en sort bien en envoyant vers internet le fichier à près de 200 Mb/s en chiffrant le tout ! (21,3 Mio/s soit 178,7 Mb/s)
100%[=========================================================================================================================================================================>] 1 000 000 000 21,5M/s ds 45s
2014-11-15 18:55:38 (21,3 MB/s) - «/dev/null» sauvegardé [1000000000/1000000000]
-
Quelques slides d'Online pour présenter le concept :
(https://lafibre.info/images/datacenter/201410_online_cloud_serveurs_armv7_3.png)
(https://lafibre.info/images/datacenter/201410_online_cloud_serveurs_armv7_4.png)
(https://lafibre.info/images/datacenter/201410_online_cloud_serveurs_armv7_5.png)
(https://lafibre.info/images/datacenter/201410_online_cloud_serveurs_armv7_6.png)
-
L'interface d'administration :
(https://lafibre.info/images/datacenter/201410_online_cloud_serveurs_armv7_7.png)
-
C'est quoi cloud ?
Au debut je pensais que c'etait le terme marketing pour "VM en stack/cluster" mais la je vois pas, ce sont des serveurs dedies ARM. Peut-etre que maintenant ca signifie, pleins de serveurs dans 11U en location a la minute ?
-
$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:07:cb:03:3a:2d
inet addr:10.1.15.25 Bcast:10.1.15.255 Mask:255.255.254.0
inet6 addr: fe80::207:cbff:fe03:3a2d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:135680 errors:0 dropped:0 overruns:0 frame:0
TX packets:34671 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:125438138 (125.4 MB) TX bytes:523213621 (523.2 MB)
Interrupt:24
Coucou Freebox :D
-
Effectivement, les adresses mac qui comment par 00:07:CB et 00:24:D4 sont attribuées à "FreeBox", une société du groupe Iliad ;)
Mon serveur :
root@c1-10-1-22-161:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:07:cb:03:77:bd
inet addr:10.1.22.161 Bcast:10.1.23.255 Mask:255.255.254.0
inet6 addr: fe80::207:cbff:fe03:77bd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:246214 errors:0 dropped:0 overruns:0 frame:0
TX packets:135205 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:1107422822 (1.1 GB) TX bytes:1363690016 (1.3 GB)
Interrupt:24
De mon coté, le load-average ne semble pas pouvoir descendre sous 1 même quand le serveur est inutilisé.
# uptime
21:00:55 up 2:31, 1 user, load average: 1.13, 1.17, 1.17
Il y a une différence pour le calcul sur une architecture ARM ?
-
De mon coté, le load-average ne semble pas pouvoir descendre sous 1 même quand le serveur est inutilisé.
# uptime
21:00:55 up 2:31, 1 user, load average: 1.13, 1.17, 1.17
Il y a une différence pour le calcul sur une architecture ARM ?
Non non, le load average reste le nombre de processus dans la file d'attente du CPU. C'est indépendant de la plateforme.
J'ai aussi un load > 1 sur les miennes, mais c'est un thread du noyau.
-
Comment afficher la liste des processus "running" ?
Il me semble que c'est kworker mais il consomme peu de CPU :
-
Comment afficher la liste des processus "running" ?
Il me semble que c'est kworker mais il consomme peu de CPU :
Tu peux faire un backtrace pour voir ce est appele.
-
Tu peux utiliser htop et sortir les entrées en fonction de l'état (F6 -> state)
Il n'est pas nécessaire d'avoir des processus qui consomment du CPU pour avoir du load, ce peut également être des processus en attente d'IO
Tu peux aussi regarder du côté de dmesg et de /proc/interrupts, peut-être y a-t-il des choses intéressantes à voir
-
Le seul qui est "Running", c'est htop :-\
# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
16: 6446765 6784862 6554142 6661063 armada_370_xp_irq 5 armada_370_xp_per_cpu_tick
17: 0 0 0 0 armada_370_xp_irq 50 d0010300.rtc
18: 538 0 0 0 armada_370_xp_irq 41 serial
24: 726890 0 0 0 armada_370_xp_irq 8 mvneta
25: 2756093 0 0 0 armada_370_xp_irq 54 mvsdio
82: 0 0 0 0 d0018140.gpio 15 online-c1
102: 2 0 0 0 armada_370_xp_irq 51 d0060900.xor
103: 2 0 0 0 armada_370_xp_irq 52 d0060900.xor
104: 2 0 0 0 armada_370_xp_irq 94 d00f0900.xor
105: 2 0 0 0 armada_370_xp_irq 95 d00f0900.xor
IPI0: 0 0 0 0 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 5345 16946 63000 24493 Rescheduling interrupts
IPI3: 71 64 97 62 Function call interrupts
IPI4: 0 0 0 0 Single function call interrupts
IPI5: 0 0 0 0 CPU stop interrupts
IPI6: 0 0 0 0 IRQ work interrupts
IPI7: 0 0 0 0 completion interrupts
Err: 0
Pour comparer, sur le serveur Intel Xeon de LaFibre.info :
# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
0: 16 0 0 0 0 0 0 0 IR-IO-APIC-edge timer
8: 1 0 0 0 0 0 0 0 IR-IO-APIC-edge rtc0
9: 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi acpi
16: 70 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb1
23: 64 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi ehci_hcd:usb2
40: 0 0 0 0 0 0 0 0 DMAR_MSI-edge dmar0
41: 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge PCIe PME
42: 9601 0 36697731 0 0 0 0 0 IR-PCI-MSI-edge ahci
43: 10254950 3742631 130409412 2409919 67166131 190290 24809698 0 IR-PCI-MSI-edge eth0-0
44: 272719915 8678 68474276 25535596 249613050 0 0 1714 IR-PCI-MSI-edge eth0-1
45: 6 0 0 149609 0 0 0 626679525 IR-PCI-MSI-edge eth0-2
46: 166001320 219012802 36670 19328 63710247 84853092 69608636 0 IR-PCI-MSI-edge eth0-3
47: 61312350 210280352 303720 156004 72641823 481 254399345 142851 IR-PCI-MSI-edge eth0-4
48: 32906929 110798061 469033 27487842 218353 406703723 29413794 25144 IR-PCI-MSI-edge eth0-5
49: 64045735 25169193 98882521 48878564 97915294 87546765 173590866 2897423 IR-PCI-MSI-edge eth0-6
50: 126531042 22617500 237948405 61036194 103144603 13187860 88862323 4228402 IR-PCI-MSI-edge eth0-7
NMI: 7470 6691 5275 4769 6131 7259 6472 12952 Non-maskable interrupts
LOC: 109452611 96274988 83941357 65858792 91363334 100891743 95238795 193553173 Local timer interrupts
SPU: 0 0 0 0 0 0 0 0 Spurious interrupts
PMI: 7470 6691 5275 4769 6131 7259 6472 12952 Performance monitoring interrupts
IWI: 14652694 4791381 18497664 7915609 15766076 4619705 14685323 2072751 IRQ work interrupts
RTR: 0 0 0 0 0 0 0 0 APIC ICR read retries
RES: 14395748 7184155 6532117 4066226 7847045 6663671 7075323 12048860 Rescheduling interrupts
CAL: 4196 4112 4368 4458 4464 4423 4424 4267 Function call interrupts
TLB: 408641 1381169 338638 686892 339932 878058 399352 875350 TLB shootdowns
TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 0 0 0 0 Threshold APIC interrupts
MCE: 0 0 0 0 0 0 0 0 Machine check exceptions
MCP: 12482 12482 12482 12482 12482 12482 12482 12482 Machine check polls
ERR: 0
MIS: 0
-
L’intérêt est de proposer une alternative à la virtualisation pour ne pas payer pour des logiciels évolués de virtualisation.
Et donc d'éviter les failles de ces logiciels!
-
@Vivien : pour les interrupts, il faut comparer à intervalles réguliers pour vérifier qui en fait le plus. J'avais un script qui faisait ça mais je sais plus où il est...
-
A priori le châssis est repris des anciens DSLAM pré-VDSL2. Rien ne se perd :D
Négatif.
On utilises la norme ATCA, par contre le chassis n'est pas totalement standard, en particulier le fond de panier sur lequel nous devons gérer un bus interconnecté de 120Gbit/sec (Nous avons plusieurs brevets sur la chose), chose que la norme ATCA ne sait pas faire. C'est pas des chassis recyclés comme évoqué.
Arnaud
-
De mon coté, le load-average ne semble pas pouvoir descendre sous 1 même quand le serveur est inutilisé.
# uptime
21:00:55 up 2:31, 1 user, load average: 1.13, 1.17, 1.17
Il y a une différence pour le calcul sur une architecture ARM ?
Oui, c'est un bug "connus" du kernel sur les architectures armhf. En cours de correction
-
Négatif.
On utilises la norme ATCA, par contre le chassis n'est pas totalement standard, en particulier le fond de panier sur lequel nous devons gérer un bus interconnecté de 120Gbit/sec (Nous avons plusieurs brevets sur la chose), chose que la norme ATCA ne sait pas faire. C'est pas des chassis recyclés comme évoqué.
Arnaud
Oh, mille excuses.
Si on commence à mal m'informer ça va pas le faire :)
-
Deux petites vidéos d'Arnaud qui nous montre 8 baies de 3 chassis chacune, soit 24 chassis.
Ca fait un total de 7000 micro serveurs sur 8 baies. Il faut ajouter 2 baies d'alimentation.
Ca fait donc une moyenne de 700 micro serveur par baie; ou encore 16 serveurs par Rack-unit.
https://x.com/online_fr/status/660880303356059648
https://x.com/online_fr/status/660879377228562432
Je n'ai toujours pas compris l'intérêt par rapport à des serveurs classique, mais c'est sympa à regarder.
Leon.
-
Je n'ai toujours pas compris l'intérêt par rapport à des serveurs classique, mais c'est sympa à regarder.
le prix et la 'scalabilité'.
en serveurs classiques, on scale souvent par a coup (quand on peut scaler).
L'offre scaleway s'addresse a des applications "scalables" ( donc pas trop pour les grosses applis lourdingues d'antant).
Cette offre cible aussi les particuliers et les developpeurs. On peut facilement, rapidement et pour pas cher déployer un serveur pre-configuré avec une image (os+application(s)) prédéfinie.
Les devs peuvent déployer et tester des conteneurs (Docker), tout est facturer a l'heure d'usage avec un plafond mensuel (par exemple une instance C1 c'est €0,006 par heure mais pas plus de 3€ par mois, dont je peux pour des besoins de test en lancer 100 pendant 1 heure pour meme pas 1 €... voir https://www.scaleway.com/pricing/ )
y'a des exemples d'images ici: https://www.scaleway.com/docs/ (on notera des usages 'limites' comme les seedboxs et autres;)).
et le hub des images est la : https://www.scaleway.com/imagehub/.. par exemple en moins d'une minute je peux deployer 'owncloud' moi meme : https://www.scaleway.com/imagehub/owncloud/, difficile de faire plus rapide et simple en "serveur classique".
Le seul défaut de leur offre est l'archi ARM qui souvent nécessite de recompiler. En utilisant Docker aussi on n'a peu d'images ARM tout prêtres et c'est un peu galère la.
-
Le seul défaut de leur offre est l'archi ARM qui souvent nécessite de recompiler. En utilisant Docker aussi on n'a peu d'images ARM tout prêtres et c'est un peu galère la.
Ouaip mais pour obtenir cette densité, il y a juste pas le choix.
-
Ouaip mais pour obtenir cette densité, il y a juste pas le choix.
C'est vrai. et avec le temps l'offre d'images 'tout prêtes' pour ARM devrait s’étoffer, en théorie du moins.
En pratique y'a pas mal de souci de compatibilité vu le foultitude de variantes de cpu dit 'compatibles arm'.
Un binaire qui marche sur un raspberry pi peut planter sur un autre cpu arm ou l'inverse.
Dans le monde x86/x64 c'est nettement plus rare.
apres Intel va peut-etre aussi se lancer dans la très haute densité x86 si sa suprématie dans les DCs est menacée.
-
Ouaip mais pour obtenir cette densité, il y a juste pas le choix.
De ce que j'ai compris, plus que la densité, ce type d'architecture serait moins gourmand en énergie. Le rapport puissance de calcul / puissance électrique serait plus avantageux que sur une architecture x86. Mais je n'ai aucun élèment pour juger si c'est vrai ou non.
De plus, dans le cas d'Online, j'ai cru comprendre qu'ils arrêtaient les serveurs inutilisés, ce qui réduit encore la consommation électrique.
En fait, réduire la consommation électrique des "équipements IT" (à puissance de calcul identique) joue beaucoup plus que de réduire le PUE. C'est sans doute vers ça qu'Online veut aller.
C'est une solution assez osée, assez en rupture, je ne sais pas si ça va prendre. Mais visiblement, il manque pas mal de conditions pour que ça prenne bien, et avant tout il manque des logiciels!
Leon.
-
C'est une solution assez osée, assez en rupture, je ne sais pas si ça va prendre. Mais visiblement, il manque pas mal de conditions pour que ça prenne bien, et avant tout il manque des logiciels!
Leon.
quelles conditions et quelle logiciels il manque?
C'est pas Online qui invente ou ose, c'est juste qu'ils suivent la tendance du moment (Docker, containers, micro serveurs, cloud a la demande, etc) initié par Google notamment. OVH et les autres gros suivent aussi. Chacun a leur rythme. Ces choses bougent tout les mois en ce moment.
Ca prend bien dans certains milieux, notamment chez les développeurs et les gens en pointe dans le web (gros ou startups). Ne plus dépendre des 'emmerdeurs' du SI (sysadmin et assimilés) et des problèmes de versions d'OS/libraries/applis, c'est vraiment le paradis par rapport a avant.
Le probleme c'est que ca commence a inquiéter pas mal de pro de l'IT classique, notamment ces sysadmin locaux et assimilés qui voient leur existence menacée... Une résistance et un discours négatif peuvent s'entendre ici ou la mais le fondement n'est pas technique mais plutôt une question de survie/défense de son job.
Apres c'est sur que celui qui règne sur un gros SI avec un son bon gros ERP (style SAP) et sa grosse messagerie maison merdique (style Exchange) n'y verra aucun intérêt et ne s'en inquiétera pas plus que ça.
-
De ce que j'ai compris, plus que la densité, ce type d'architecture serait moins gourmand en énergie. Le rapport puissance de calcul / puissance électrique serait plus avantageux que sur une architecture x86. Mais je n'ai aucun élèment pour juger si c'est vrai ou non.
C'est tout à fait vrai mais c'est justement ça qui permet d'obtenir cette densité puisque le problème c'est de réussir à refroidir tout ça.
Globalement le x86 ça chauffe (même si on est plus à l'époque du Prescott "grille-pain"). J'ai eu l'occasion de voir un supercalculateur utilisant des processeurs Power PC par rapport à un supercalculateur basés sur des processeurs Intel, le supercalculateur basé sur les Power PC a 6 fois plus de cœurs que celui basé sur les Intel qui prend pourtant un peu plus de place... Évidemment chaque cœur Power PC est moins puissant qu'un cœur Intel mais sur le total, le ratio performance/watts est clairement en faveur du Power PC.
-
Je n'ai toujours pas compris l'intérêt par rapport à des serveurs classique, mais c'est sympa à regarder.
Chez moi, j'ai pris l'habitude de placer toutes les tâches à faire dans des files d'attentes.
De 0 à 10, je gère tout sur mon infra. Par contre, si je prends du retard et que la file dépasse 10, je démarre autant d'instances que de tâches "en trop". L'instance démarre sur un template que j'aurais préparé : elle démarre, récupère sa tâche, monte le volume en NFS, fait son taff et le dépose sur le NFS et s'éteint.
Avec des serveurs classiques, ils tourneraient 24/24h dans le "vide" alors que les ressources peuvent servir à qqn d'autre. Au final, ça fait diminuer ta facture :)
Le client, souvent "joueur", ne voit pas l'essoufflement, même s'il m'envoie plein de fichiers dans la tronche :)
-
Cette offre cible aussi les particuliers et les developpeurs. On peut facilement, rapidement et pour pas cher déployer un serveur pre-configuré avec une image (os+application(s)) prédéfinie.
Les devs peuvent déployer et tester des conteneurs (Docker), tout est facturer a l'heure d'usage avec un plafond mensuel (par exemple une instance C1 c'est €0,006 par heure mais pas plus de 3€ par mois, dont je peux pour des besoins de test en lancer 100 pendant 1 heure pour meme pas 1 €... voir https://www.scaleway.com/pricing/ )
y'a des exemples d'images ici: https://www.scaleway.com/docs/ (on notera des usages 'limites' comme les seedboxs et autres;)).
et le hub des images est la : https://www.scaleway.com/imagehub/.. par exemple en moins d'une minute je peux deployer 'owncloud' moi meme : https://www.scaleway.com/imagehub/owncloud/, difficile de faire plus rapide et simple en "serveur classique".
A condition de ne pas "oublier" de les arrêter ;) Vécu en entreprise sur la facturation à l'heure : "on s'en fout, c'est pas prélevé sur notre budget, donc comme c'est 'chiant' à gérér, on laisse tourner"...
-
A condition de ne pas "oublier" de les arrêter ;) Vécu en entreprise sur la facturation à l'heure : "on s'en fout, c'est pas prélevé sur notre budget, donc comme c'est 'chiant' à gérér, on laisse tourner"...
Le probleme est humain la et valable dans plein d'autres domaines.
Avec l'API de la plateforme (https://developer.scaleway.com/) , il est tres simple de mettre en place des automatismes pour surveiller et prévenir ce genre de probleme.
-
Le probleme est humain la et valable dans plein d'autres domaines.
Avec l'API de la plateforme (https://developer.scaleway.com/) , il est tres simple de mettre en place des automatismes pour surveiller et prévenir ce genre de probleme.
C'est aussi pour ça que j'apprécie le fait qu'il y a un maximum mensuel, cela limite le risque financier en cas "d'oubli" :)
-
Tiens, un truc m'avais échappé! Online utilise des chassis ATCA de 16 emplacements, donc de 21 pouces.
Ca veut dire qu'ils utilisent des baies de 21 pouces, plus rares que les 19 pouces en datacenter. On trouve les 21 pouces surtout dans le monde des télécoms.
Un chassis ATCA qui tiendrait dans 19 pouces n'aurait que 14 emplacements.
Leon.
-
C'est pas Online qui invente ou ose, c'est juste qu'ils suivent la tendance du moment (Docker, containers, micro serveurs, cloud a la demande, etc) initié par Google notamment.
Ah, il y aurait une tendance sur des micro serveurs, initié par Google? Tu peux nous en dire plus, stp? Tu parles de machines physiques ou virtuelles? J'avais l'impression que Google utilisait exclusivement des serveurs assez puissants : multi-processeurs, beaucoup de RAM.
Leon.
-
Ah, il y aurait une tendance sur des micro serveurs, initié par Google? Tu peux nous en dire plus, stp? Tu parles de machines physiques ou virtuelles? J'avais l'impression que Google utilisait exclusivement des serveurs assez puissants : multi-processeurs, beaucoup de RAM.
Leon.
non Google ne fait pas dans le micro-serveur a ma connaissance. La tendance qu'ils ont démocratisé ce sont les containers ce qui ensuite a amené d'autres a s’intéresser au micro-serveurs (pour d'autres usages aussi). Difficile de résumer ça en une phrase.
-
Est-ce que quelqu'un a eu l'occasion de tester une instance C1 récemment ? Je me demande si la limitation notée par Vivien au niveau du débit lors de l'écriture sur le disque existe toujours.
J'ai bien envie de m'en prendre un si ce problème est réglé (et qu'ils sont à nouveau disponibles un jour...).
-
wget depuis une instance C1 a l'instant:
root@ory-nspeed:~# wget http://1.testdebit.info/fichiers/1000Mo.dat
--2016-01-16 19:45:54-- http://1.testdebit.info/fichiers/1000Mo.dat
Resolving 1.testdebit.info (1.testdebit.info)... 194.158.102.114, 2001:860:f70b:100::114
Connecting to 1.testdebit.info (1.testdebit.info)|194.158.102.114|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1000000000 (954M)
Saving to: ‘1000Mo.dat’
1000Mo.dat 100%[==========================================================>] 953.67M 59.3MB/s in 15s
2016-01-16 19:46:10 (62.2 MB/s) - ‘1000Mo.dat’ saved [1000000000/1000000000]
sans écriture:
root@ory-nspeed:~# wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat
--2016-01-16 19:54:28-- http://1.testdebit.info/fichiers/1000Mo.dat
Resolving 1.testdebit.info (1.testdebit.info)... 194.158.102.114, 2001:860:f70b:100::114
Connecting to 1.testdebit.info (1.testdebit.info)|194.158.102.114|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1000000000 (954M)
Saving to: ‘/dev/null’
/dev/null 100%[==========================================================>] 953.67M 111MB/s in 9.2s
2016-01-16 19:54:37 (104 MB/s) - ‘/dev/null’ saved [1000000000/1000000000]
test du disque en direct:
root@ory-nspeed:~# dd if=/dev/zero of=/root/testfile bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 11.5374 s, 93.1 MB/s
par contre c'est très fluctuant si on fait le meme test plusieurs fois, donc sans doute très dépendant de ce que font les voisins.
-
Merci, visiblement ça marche plutôt pas mal. Par contre c'est bizarre, il me semblait avoir lu que le débit est limité à 200 Mbps.
Dommage qu'ils soient en rupture de stock depuis aussi longtemps.
-
C'était mon test, mais visiblement cela s'est amélioré :
Le SSD a un très haut débit en lecture mais pas en écriture :
Écriture sur le SSD d'un fichier de 5Go : 13,5 Mio/s (c'est le SSD qui limite, pas le réseau)
# wget http://ipv4.intuxication.testdebit.info/fichiers/5000Mo.dat
--2014-11-15 17:14:22-- http://ipv4.intuxication.testdebit.info/fichiers/5000Mo.dat
Resolving ipv4.intuxication.testdebit.info (ipv4.intuxication.testdebit.info)... 62.210.156.12
Connecting to ipv4.intuxication.testdebit.info (ipv4.intuxication.testdebit.info)|62.210.156.12|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5000000000 (4.7G) [application/x-ns-proxy-autoconfig]
Saving to: ‘5000Mo.dat’
100%[=========================================================================================================================================================================>] 5,000,000,000 13.5MB/s in 4m 11s
2014-11-15 17:18:33 (19.0 MB/s) - ‘5000Mo.dat’ saved [5000000000/5000000000]
Récupération du même fichier sur Internet, sans l'écrire sur le SSD (vers /dev/null) : 43,8 Mio/s soit 367,4 Mb/s
# wget -O /dev/null http://ipv4.intuxication.testdebit.info/fichiers/5000Mo.dat
--2014-11-15 17:30:11-- http://ipv4.intuxication.testdebit.info/fichiers/5000Mo.dat
Resolving ipv4.intuxication.testdebit.info (ipv4.intuxication.testdebit.info)... 62.210.156.12
Connecting to ipv4.intuxication.testdebit.info (ipv4.intuxication.testdebit.info)|62.210.156.12|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5000000000 (4.7G) [application/x-ns-proxy-autoconfig]
Saving to: ‘/dev/null’
100%[=========================================================================================================================================================================>] 5,000,000,000 42.4MB/s in 1m 49s
2014-11-15 17:32:00 (43.8 MB/s) - ‘/dev/null’ saved [5000000000/5000000000]
-
Bonsoir,
J'utilise énormèment ces petits serveurs C1, et je n'ai pas vraiment de problème de disponibilité. Des que je veux un serveur pour des tests, il est installé en moins de 30s. Très très pratique.
Les débits sont énormes au vu du prix de la machine, d'ailleurs ils ont deux types de stockage au choix. Aucun problème d'écriture de mon côté. Conforme aux tests juste au dessus.
C'est que du bonheur de mon côté.
Cdt,
DamienC
-
Quand je parle de la disponibilité c'est pour les gens pas encore clients qui ne peuvent justement pas le devenir jusqu'à nouvel ordre.
-
On a beaucoup mieux qui arrive :)
L'usine à Laval tourne à plein régime en ce moment
-
On a beaucoup mieux qui arrive :)
Moi faut être honnête c'est surtout le prix tout petit qui m'attire, j'ai pas forcèment besoin de plus. ;)
L'usine à Laval tourne à plein régime en ce moment
C'est une bonne nouvelle en tout cas !
En tout cas je suis curieux de voir si l'ARM va se démocratiser dans les serveurs. Je bosse dans le calcul haute performance pour des applications scientifiques et on se demande toujours si ça va arriver un jour jusqu'à chez nous. Si ça s’implante durablement dans les serveurs ça pourrait donner des idées à certains constructeurs.
-
On a beaucoup mieux qui arrive :)
L'usine à Laval tourne à plein régime en ce moment
L'usine produit des IPv6 en masse ? :P
-
Fabriquées à l'ancienne?
Moulée à la louche?
-
On a beaucoup mieux qui arrive :)
L'usine à Laval tourne à plein régime en ce moment
Vous devriez vendre des licences à OVH... ::)
-
On a beaucoup mieux qui arrive :)
L'usine à Laval tourne à plein régime en ce moment
Une petite date pour estimer l'arrivée et un petit teasing + bêta-test en vue? Si le prix reste bas et que l'IPv6 est de la partie, je crois que ça peut vraiment faire un carton...
-
La nouveauté sera avec un ARM-64bits, c'est à peu près certain, mais lequel?
Un AMD-Opteron A1100 ? Sans doute trop puissant pour le concept "scaleways", mais pourquoi pas.
http://www.amd.com/en-us/products/server/opteron-a-series
Leon.
-
La nouveauté sera avec un ARM-64bits, c'est à peu près certain, mais lequel?
pourquoi c'est a peu pres certain ?
perso je prefererai du x86/x64.
ARM en serveur pose pas mal de souci en pratique : il faut souvent compiler au lieu d'utiliser des binaires et meme parfois modifier le code source car y'a des erreurs/particularités d'implèmentation.
J'ai eu le cas avec Dart par exemple et les devs de Google ont du changer le code pour faire un test case spécial rien que pour le modele de cpu utilisé par Scaleway (Armada 370/XP): voir https://github.com/dart-lang/sdk/issues/24466 et le patch ici: https://github.com/dart-lang/sdk/commit/ccc7786362a17f3d80a22fe58ccd01e988f274bb . C'est quand meme assez degeu de devoir faire un test case pour des cpu en particulier quand meme...
En attendant que la plateforme ARM soit plus 'pro' et mature en serveur , peut-être que Scaleway va proposer du x86/x64 ...
-
Avec du x86 j'ai un peu un doute sur le fait que Scaleway puisse offrir un tarif aussi avantageux.
-
Ça m'étonnerait que s'il y a du x86 qui soit proposé, une solution arm 64 ne soit pas aussi proposée pour créer une gamme (avec instances x86 plus chères que les instances arm64 plus chères que les actuelles instances C1).
Pour ma part je crois vraiment en l'avenir des solutions arm en dehors des smartphones, à condition que l'universalité s'améliore (avec donc une sorte d'équivalent au BIOS pour proposer des OS non spécifiques à un matériel précis)
-
C'est l'absence de Bios qui fait qu'il est impossible de proposer aujourd'hui un ISO qui fonctionne sur tous les ARM64 ?
-
Pas a ma connaissance. Je ne vois pas trop ce que le BIOS vient faire la d'ailleurs. C'est un choix d'intégration (carte mere) pas de cpu.
en plus "tous les ARM64": y'en a pas des masses ... :P
Si on parle 'carte mere ARM', la plupart ont un bios UEFI comme les cartes meres x86/x64.
Pour les serveurs, ARM a publié un "Server Base Boot Requirements" (SBBR) qui recommande d'utiliser UEFI et de supporter ACPI et SMBios.
Si on parle juste de 'SoC ARM' c'est autre chose. En general y'a juste 'bootloader' en dur pour lancer le démarrage de l'OS (les smartphones, le Pi fonctionnent comme cela).
Les seuls "PC" du marché a base d'ARM, les Chromebooks sous ChromeOS, utilisent tous CoreBoot comme firmware. Ce dernier initialise le hardware puis charge dynamiquement un "payload" : un bout code en charge de démarrer l'OS. Pour Linux c'est FILO et pour ChromeOS c'est Depthcharge (et pour Windows c'est seaBIOS mais y'a pas de version ARM). Donc en théorie, un PC ARM sous CoreBoot peut booter n'importe quel OS si on lui fourni le payload qui correspond a l'OS.
Le probleme c'est le code des OS et des applications pas le Bios:
Une bonne lecture sur les raisons du lent démarrage d'arm en serveur: http://www.nextplatform.com/2015/10/06/why-are-we-still-waiting-for-arm-servers/
-
Perso je lis : Other variation of servers are coming, including x86-based CPUs.
https://www.scaleway.com/fr/faq/server/
-
Scaleway vient d'ouvrir des offres a Amsterdam.
https://blog.online.net/2016/10/27/scaleway-global-expansion-starts-in-amsterdam/
L'offre minimale est un VC1S (2 cores Intel 64 bit, 2GB RAM, 50 GB SDD, 200Mbps Internet, 1Gbps Intranet) pour 3€/mois + TVA.