La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => Scaleway => Discussion démarrée par: BadMax le 14 janvier 2016 à 19:47:03
-
Tweet d'Arnaud :
(https://lafibre.info/images/materiel/201601_online_switch_48x1g_2x40g_1.jpg)
-
Photo du switch Online en plus grand :
(https://lafibre.info/images/materiel/201601_online_switch_48x1g_2x40g_2.jpg)
C'est pour l'admin du switch, les deux ports Ethernet à l’extrême droite ?
Si il y a un uplink de 2x 40 Gb/s, j'imagine que le but est de chaîner plusieurs switch dans une boucle 40 Gb/s, sinon 10 Gb/s était largement suffisant.
-
Je suppose que classiquement les deux ports RJ45 à droite sont un port console et un port Out of Band ?
-
J'aime bien le nom de la bête. :P
Quel intérêt pour Online sinon ? Ça leur coûte moins cher ?
-
Je pense qu'il n'y a pas que l'argument économique (même si ce ne doit pas être l'un des moindre), il y a aussi l'assurance de maitriser à 100% le Firmware, d'éviter d'être dépendant des fabricants du marché (délais, politique commercial, partage d'informations ..)
et puis au dela d'Online, vu le nombre de sites (NRA, NRO, Antennes .. ), il doit y avoir un sacré paquet d'équipements de ce type à rationaliser d'un point de vue Iliad !!
-
C'est pour l'admin du switch, les deux ports Ethernet à l’extrême droite ?
Probablement. Mais pourquoi en avoir 2 ?
Si il y a un uplink de 2x 40 Gb/s, j'imagine que le but est de chaîner plusieurs switch dans une boucle 40 Gb/s, sinon 10 Gb/s était largement suffisant.
48x 1Gbits ça fait combien Vivien ? :)
2x 40Gb c'est à peine assez pour faire du non-bloquant (si on est en actif/passif ou routé, en LACP ça serait différent).
Je suppose que classiquement les deux ports RJ45 à droite sont un port console et un port Out of Band ?
On voit des diodes donc exit le port console en mode série. C'est deux Ethernet.
-
Apparemment, OVH est dans le même état d'esprit.
https://x.com/olesovhcom/status/678508667063373824
Je pense que Google, Facebook et les autres ont montré l'exemple, ouvert la voie.
Bref, ce sont sans doute les débuts de l'utilisation réelle de plus en plus massive de matériel réseau "ouvert", pour faire du vrai SDN (pas juste des trucs marketing).
Ce qu'ont Online et OVH à y gagner? Développer des solutions réseau spécifiques répondant spécifiquement à leurs besoins, sans passer par la case équipementier.
Leon.
-
On voit des diodes donc exit le port console en mode série. C'est deux Ethernet.
Et pourquoi les ports RJ45/console n'auraient pas de diode ? Voici l'exemple d'un switch Dell, avec les deux ports série (symbole |o|o|) et OOB à droite.
-
et puis au dela d'Online, vu le nombre de sites (NRA, NRO, Antennes .. ), il doit y avoir un sacré paquet d'équipements de ce type à rationaliser d'un point de vue Iliad !!
Ils en font déjà beaucoup eux-même. Sur ce produit en particulier, 48 ports ça me semble beaucoup pour intéresser Free.
-
Je suppose que classiquement les deux ports RJ45 à droite sont un port console et un port Out of Band ?
Oui, c'est pour le provisionning initial et l'administration out of band.
Photo plus détaillée de cette partie
(https://lafibre.info/images/materiel/201601_online_switch_48x1g_2x40g_3.jpg)
(https://lafibre.info/images/materiel/201601_online_switch_48x1g_2x40g_4.jpg)
-
Ils en font déjà beaucoup eux-même. Sur ce produit en particulier, 48 ports ça me semble beaucoup pour intéresser Free.
C'est indiqué sur le premier post, ce sont des ToR, donc des switchs Top of Rack, donc à priori pour data center, pour Online.
Ce sont 48 ports RJ45. Free aurait plus besoin de ports SFP pour ses NROs.
-
Pour être très précis ce sont 2 ports de management cascadables, sur la 2° photo on peut distinguer un petit switch 4 ports derrière les magnetics.
Il y a un peu plus de choses que sur un switch traditionnel :-X
-
C'est indiqué sur le premier post, ce sont des ToR, donc des switchs Top of Rack, donc à priori pour data center, pour Online.
Ce sont 48 ports RJ45.
C'est ce que je disais non ?
Free aurait plus besoin de ports SFP pour ses NROs.
Ils ont leurs OLT et leurs switchs pour la collecte des sites mobiles déjà. Entre autre.
-
Je pense qu'il n'y a pas que l'argument économique (même si ce ne doit pas être l'un des moindre), il y a aussi l'assurance de maitriser à 100% le Firmware, d'éviter d'être dépendant des fabricants du marché (délais, politique commercial, partage d'informations ..)
Il n'y a aucun argument financier qui peut tenir la route.
très clairement une solution maison (malgré le faite que nous avons notre propre R&D, une unité de production électronique à Laval et des achats consolidés avec d'autres produits internes comme Scaleway) coute sensiblement le même prix voir plus cher que des équipements standard du marché produits en masse.
Sans compter les nombreuses nouvelles emmerdes à gérer : production, logistique, approvisionnements, tests, développements bas niveau très spécifiques etc... le tout dans un environnement où la coupure est dramatique.
Le vrai gain est en terme de fonctionnalités (on ouvre un boulevard, et encore on exploite qu'une infime partie des possibilités offertes par le chip que nous utilisons), d'industrialisation/automatisation et les deux ports 40G dans le cadre de la montée en débit des offres.
-
C'est indiqué sur le premier post, ce sont des ToR, donc des switchs Top of Rack, donc à priori pour data center, pour Online.
Ce sont 48 ports RJ45. Free aurait plus besoin de ports SFP pour ses NROs.
Mettre des SFP à la place en reprenant une carte mère proche n'est pas forcèment impossible.
Ils utilisent aussi, à ma connaissance, des cages sur le switch qu'est la management des DSLAMs "Mini" : les cartes DSL peuvent être reliées dessus, de même que des antennes mobiles en fibre (on appelle alors ça des "mob"), et d'autres choses encore.
Free a donc déjà plusieurs milliers de switches maison en production.
-
Le vrai gain est en terme de fonctionnalités (on ouvre un boulevard, et encore on exploite qu'une infime partie des possibilités offertes par le chip que nous utilisons), d'industrialisation/automatisation et les deux ports 40G dans le cadre de la montée en débit des offres.
pourquoi 40G et pas 100G ? le gap de prix est trop important ?
quand aux possibilités, on parle de SDN ? d'autres choses ? il n'y a rien sur le marché d'équivalent ?
-
il y a aussi l'assurance de maitriser à 100% le Firmware, d'éviter d'être dépendant des fabricants du marché (délais, politique commercial, partage d'informations ..)
C'est pas parce qu'ils font un PCB qu'ils vont utiliser leur propre puce.
-
C'est pas parce qu'ils font un PCB qu'ils vont utiliser leur propre puce.
J'ai d'ailleurs une question, dans ce cadre on a accès à tout le code en entier ?
Plus rien n'est précompilé ?
Juste pour savoir à quel point on maîtrise le matériel dans un tel cas.
-
48x 1Gbits ça fait combien Vivien ? :)
2x 40Gb c'est à peine assez pour faire du non-bloquant (si on est en actif/passif ou routé, en LACP ça serait différent).
C'est un switch réalisé pour connecter des serveurs et donc il est aussi peu probable que les 48 serveurs saturent un lien 10 Gb/s que 64 clients Gpon saturent l'arbre à 2488 Mb/s.
Par contre, je pense que cela permet, en chaînant les switch, de partir directement vers le routeur, sans mettre de Cisco Nexus 9396PX Aujourd'hui, pour collecter chaque switch Top of Rack, il y a une baie réseau, tous les 45 baies, équipée d'un Cisco Nexus 9396PX => Il faut payer le Nexus 9396PX et on perdu une baie.
Baie de réseau de collecte de 45 switch Top of Rack via un Cisco Nexus 9396PX :
(https://lafibre.info/images/datacenter/201509_online_dc3_salle3_16.jpg)
-
J'ai d'ailleurs une question, dans ce cadre on a accès à tout le code en entier ?
Plus rien n'est précompilé ?
Juste pour savoir à quel point on maîtrise le matériel dans un tel cas.
On maîtrise clairement tout de A à Z, c'est possible d'affirmer qu'il n'y a pas de backdoor logicielle dans notre produit.
Quand à un backdoor matérielle, tant qu'on ne designera pas la puce nous même, ca me paraît impossible de pouvoir l'affirmer. C'est déjà beaucoup plus improbable comme type de backdoor, si je mettais une backdoor dans un hardware, je la mettrait dans les CPU de chez Intel, là au moins on est sûr d'avoir l'info en clair :-)
-
C'est un switch réalisé pour connecter des serveurs et donc il est aussi peu probable que les 48 serveurs saturent un lien 10 Gb/s
Avec le nombre de seedboxs qu'il y a chez Online, je dirais que c'est très probable. :)
-
Avec le nombre de seedboxs qu'il y a chez Online, je dirais que c'est très probable. :)
200Mb/s par machines en simultanés ? ça en fait du torrent......
-
Les bons jours franchement tu satures ça sans souci sur une seedbox.
Bon, après, sur toutes les seedboxes, c'est moins probable ouais.
-
200Mb/s par machines en simultanés ? ça en fait du torrent......
Eh oui, avec la montée de la colocation (plusieurs utilisateurs, plusieurs seedbox sur le même dédié) et la montée du THD en face pour leecher plus vite... En période de guerre (des étoiles) j'imagine sans mal que les équipements ont dû se prendre de belles douches :)
EDIT : pour montrer à quel point ça peut être "violent" (alors à l'échelle d'Online, pensez donc...) :
https://x.com/newsoo_fr/status/677804471250997248
-
En environnement Datacenter, saturer du Gigabit c'est de la rigolade et arrêtez de croire que tous les serveurs en DC servent à faire tourner un Apache, une base MySQL et une seedbox.
Il y a aussi des clients qui vont y mettre des hyperviseurs ou des applications un peu lourdes et là l'utilisation du Gigabit va aller très vite.
Donc avec 48 serveurs un peu bavard, un uplink 10G serait rapidement sous-dimensionné. Attention, un serveur bavard peut burster du Giga pendant plusieurs dizaines de secondes puis se taire pendant 3/4 minutes.
On est en 2016, vendre 48x 1Gb avec un uplink 10G c'est de la radinerie : c'est que ce j'avais en 2003 sur des Cisco 4500 ! Et déjà à l'époque j'avais des problèmes de gestion de burst Gb. Donc soyons sérieux, le 40G ça ne vaut plus rien et ça permet de voir un peu plus loin.
-
Enfin, on voit bien la réalité : Online utilise actuellement 2 x 20 Gb/s pour collecter le trafic de 45 baies de serveurs (pour d'autres bloc de 45 baies cela peut être un peu plus que 20 Gb/s, mais cela donne un ordre d'idée).
Donc je maintiens que pour un seul rack, il me semble difficile de saturer 10 Gb/s (hors attaque DDOS).
Un client qui trafic 900 Mb/s systématiquement le soir, il a intérêt à avoir une offre a au moins 600€/mois, sans quoi Online n'arriver même pas a être rentable sur le transit.
-
On maîtrise clairement tout de A à Z, c'est possible d'affirmer qu'il n'y a pas de backdoor logicielle dans notre produit.
Quand à un backdoor matérielle, tant qu'on ne designera pas la puce nous même, ca me paraît impossible de pouvoir l'affirmer. C'est déjà beaucoup plus improbable comme type de backdoor, si je mettais une backdoor dans un hardware, je la mettrait dans les CPU de chez Intel, là au moins on est sûr d'avoir l'info en clair :-)
Merci pour la réponse.
-
Donc je maintiens que pour un seul rack, il me semble difficile de saturer 10 Gb/s (hors attaque DDOS).
Si Online veut faire comme OVH, et faire grossir la partie "réseau privé" avec des serveurs de fichiers séparés, alors je pense réellement qu'une baie peut faire sans problème du 10Gb/s, mais sur la partie "réseau privé".
Que ce soient des baies de serveurs "frontaux" ou autre.
Je rappelle que Online propose des gros serveurs de fichiers raccordés en 10Gb/s à leur "RPN".
De même, avec des services type streaming ou équivalent, c'est très facile de monter en débit. Regardez l'installation de Netflix France, qui tient sur moins de 10 baies de serveurs! Pareil pour le stockage "cloud".
Leon.
-
apres rien ne dit que c'est le seul modele qu'ils ont en préparation et qu'ils vont utilisés ca partout...
on peut tres bien imaginer qu'ils ont prévu des versions plus péchu la ou il y a des gros interco?
-
Le vrai gain est en terme de fonctionnalités (on ouvre un boulevard, et encore on exploite qu'une infime partie des possibilités offertes par le chip que nous utilisons), d'industrialisation/automatisation et les deux ports 40G dans le cadre de la montée en débit des offres.
Tu peux nous en dire plus, s'il te plait ?
Est-ce que tu peux nous raconter des trucs sur les parties matériels et logiciels de chouchou ? Ou est-ce top secret ?
-
Tu peux nous en dire plus, s'il te plait ?
Est-ce que tu peux nous raconter des trucs sur les parties matériels et logiciels de chouchou ? Ou est-ce top secret ?
+1
au fait, il faut dire au gars qui a nommé ce truc comme ça de ne plus jamais recommencer.
et si un jour il a des enfants, il faudra qu'il laisse décider l'officier de l'état civil
-
Tu peux nous en dire plus, s'il te plait ?
Est-ce que tu peux nous raconter des trucs sur les parties matériels et logiciels de chouchou ? Ou est-ce top secret ?
Moi je parie sur du VxLAN et/ou des joyeusetés autour du changement du tag de Vlan Id à la volée.
-
Pareil, je suis certain qu'il y a des clients qui paieraient cher pour ce genre de fonctionnalités.
-
Vous pourriez développer/expliquer le besoin et le business qu'il y a derrière ?
-
Changement du Vlan Id à la volée (Vlan translation) : imagines t'as 2 clients qui veulent des flux privés avec les mêmes numéros de Vlan. Et bien sur le 2ème tu les "remap" vers des numéros à toi.
Exemple: Client A veut Vlans 3 et 4. Client B veut Vlans 3 et 4 aussi. On les remap en interne vers 5 et 6 sur chaque interface où ses serveurs sont raccordés. Ce "remapping" est manuel, à toi de gérer la correspondance. Pas sûr que ça soit la fonction la plus intéressante en ce moment à cause de VxLAN.
VxLAN: https://en.wikipedia.org/wiki/Virtual_Extensible_LAN
Permet l'encapsulation de trames Ethernet en UDP. Rapidement adopté par VMware puis depuis 2 ans accessible sur les switches orientés Datacenter. L'intérêt est d'étendre le domaine Ethernet d'un client à travers des routeurs donc de pouvoir traverser des topologies IP multi-salles ou multi-salles. Cerise sur le gateau t'as une étanchéité : un client A ne peut pas voir les flux VxLAN du client B. VxLAN peut aussi transporter des trames 802.1q ce qui permet une double encapsulation VLAN+VxLAN.
Point faible de VxLAN: au début on l'implèmentait en Multicast UDP, ce qui est peu pratique, maintenant on peut l'implèmenter en Unicast moyennant la création de tunnels entre équipements ce qui peut être fastidieux.
La techno SDN de Cisco (par exemple) est basée sur une combinaison de ces 2 fonctions.
Dans les deux cas le but est qu'un client puisse construire sa topologie réseau comme un réseau privé avec le nombre de vlans qu'il veut.
Autres features : pouvoir faire du routage à l'intérieur de flux VxLAN, gérer VxLAN via E-VPN (MP-BGP).
-
Changement du Vlan Id à la volée (Vlan translation) : imagines t'as 2 clients qui veulent des flux privés avec les mêmes numéros de Vlan. Et bien sur le 2ème tu les "remap" vers des numéros à toi.
Exemple: Client A veut Vlans 3 et 4. Client B veut Vlans 3 et 4 aussi. On les remap en interne vers 5 et 6 sur chaque interface où ses serveurs sont raccordés. Ce "remapping" est manuel, à toi de gérer la correspondance.
C'est pas dangereux, le "VLAN Translation"? C'est utilisé dans la vraie vie? Si on ne parle pas de VxLAN, ne vaut-il pas mieux faire du "Q-in-Q", plutôt que du "vlan translation"? Tout ça pour permettre à chaque client de garder sa propre architecture de VLAN.
Leon.
-
C'est pas dangereux, le "VLAN Translation"? C'est utilisé dans la vraie vie?
Pourquoi tu penses que ça serait dangereux ?
-
Pourquoi tu penses que ça serait dangereux ?
Dans le souvenir d'un truc que j'ai lu, ça disait que le "VLAN translation" était peu utilisé car c'était plus sensible aux erreurs de config, et plus complexe à configurer. Mais bon, c'était peut-être un article "orienté". Cette technique est-elle réellement utilisé dans la vraie vie? Le Q in Q et le VxLAN semblent largement utilisés, eux.
Leon.
-
Dans la "vraie vie" c'est utilisé par Cisco dans son SDN : il utilise sa propre base de Vlan Id (en fait elle est locale à chaque switch) et mappe le bon Vlan Id sur l'interface. C'est transparent par l'utilisateur.
L'autre cas plus courant est l'inter-connexion de 2 backbones : tu as 1 ou plusieurs Vlans à inter-connecter mais les numéros différent -> il suffit de les remapper d'un côté. Il y a aussi les opérateurs qui peuvent le faire sur des liaisons livrées en Ethernet avec support des Vlans : ils remappent les Vlans du client dans leurs bases. Maintenant c'est devenu un peu désuet en transportant les paquets Ethernet sur IP.
On peut aussi remapper un Vlan "Inner" d'un Q-in-Q vers un Vlan local : pratique pour extraire un Vlan et l'amener vers un équipement externe.
-
J'utilise aussi le vlan translation lorsque mon pair utilise un vlan que j'utilise déjà ailleurs
-
Oui, c'est pour le provisionning initial et l'administration out of band.
Photo plus détaillée de cette partie
Bonjour.
Les cages semblent large, vous utilisez des GBIC plutôt que des SFP ?
-
Ça ressemblerait plutôt à des ports QSFP.
(d'ailleurs, GBIC = Gigabit et la forme est plus allongée)
-
Oui, 2 QSFP
-
Pour le 40 Gb/s, un QSFP est effectivement nécessaire (pas de SFP+ pour du 40 Gb/s)
J'en profite pour poser une question : pourquoi les constructeurs continuent de vendre des équipements avec des ports 10Gb/s sous forme de cages XFP ? Le SFP+ prend bien moins de place !
En haut un SFP+ et en dessous un XFP (tous les deux du mono-mode 1310nm, LR 10 Gb/s sur 10Km)
(https://lafibre.info/images/routeur/201601_comparatif_sfp-plus_xfp_1.jpg)
(https://lafibre.info/images/routeur/201601_comparatif_sfp-plus_xfp_2.jpg)
Un switch récent avec ports XFP : (Huawei x8)
(https://lafibre.info/images/routeur/201601_switch_huawei_x8_port10g_xfp_1.jpg)
(https://lafibre.info/images/routeur/201601_switch_huawei_x8_port10g_xfp_2.jpg)
-
Le XFP est le premier format de connecteur 10Gb apparu sur le marché. Il a comme différence avec SFP+ d'embarquer tout le nécessaire pour sa gestion ce qui simplifie sa connexion avec des ASIC. Le SFP+ est plus simple et n'embarque pas de composants de re-timing ce qui impose que l'ASIC soit prévu pour.
Je n'ai pas vérifié les specs électriques, possible qu'on trouve aussi des écarts.
C'est avec le 100Gb où les différences se situent sur le bus, ou plutot le nombre de bus du connecteur : CPAK=10x10Gb, CFP=4x25Gb.
-
En ce qui concerne la taille des cages, n'y a-t-il pas également des différences de dissipation thermique maxi entre les différents formats?
Leon.
-
En résumé, les XFP sont moins cher pour les constructeurs, et plus cher pour le client
Hum
-
En ce qui concerne la taille des cages, n'y a-t-il pas également des différences de dissipation thermique maxi entre les différents formats?
Leon.
Vu que dans un SFP+ il y a moins de composants, il y a moins à dissiper :)
Sinon les VCSEL doivent être les mêmes à peu de choses près.
En 10Gb il y a aussi le format X2 permettant d'intégrer un radiateur sur le coupleur
(http://www.sfpopticaltransceiver.com/photo/pc1289422-10gbase_lr_x2_cisco_10g_x2_module_10_3g_for_smf_x2_10gb_lr.jpg)
-
Le XFP est le premier format de connecteur 10Gb apparu sur le marché.
Non, le premier transceiver 10Gb c'était le XENPAK, suivi des X2 et XPAK.
Ensuite est arrivé le XFP, puis le SFP+ (et qui sont les seuls encore vraiment sur le marché).
Ici, un XENPAK et un X2.
(https://supportforums.cisco.com/sites/default/files/legacy/0/9/3/83390-Cisco%2010GBASE%20X2%20and%20Xenpak%20Modules.jpg)
-
Photo du switch Online en plus grand :
(https://lafibre.info/images/materiel/201601_online_switch_48x1g_2x40g_2.jpg)
C'est pour l'admin du switch, les deux ports Ethernet à l’extrême droite ?
Si il y a un uplink de 2x 40 Gb/s, j'imagine que le but est de chaîner plusieurs switch dans une boucle 40 Gb/s, sinon 10 Gb/s était largement suffisant.
Et voici le résultat final :-)
-
Classe ! Du coup tu peux nous donner la vitesse des ports ? :p
-
Voir meme en vendre a vil prix aux geek du forum (mais je suppose qu'il faut un switch "maitre")
-
48x 1G + 2x40G, linerate sur tous les ports.
Pas besoin de switch "maître" c'est tout autonome, suffit de taper l'API et ça roule ;D
-
C'est quoi l'astuce pour mettre les dedibox avec 2.5Gb/s sur des ports 1Gbit ? ;)
-
C'est quoi l'astuce pour mettre les dedibox avec 2.5Gb/s sur des ports 1Gbit ? ;)
Les nouvelles dedibox sont dans des racks avec réseau intégré comme les Scaleway (d'ailleurs ce sont les mêmes serveurs non?) il me semble. Ces switchs doivent être pour les serveurs plus "classiques". En tout cas bravo pour ce beau développement, j'espère que les nouveaux serveurs derrière seront à leur hauteur !
PS: Du coup est-ce que vous prévoyez du stockage déporté pour les dedibox et scaleway mais en beaucoup moins cher que le RPN-SAN (argh les prix !), pour utiliser toute la bande passante disponible de ces switchs?
-
Le 2,5 Gb/s, c'était une supposition de ma part, suite aux annonces de Online qui arrivaient peu après l’annonce de switchs avec un uplink clairement sur-dimebnsionné.
Donc j'ai tout faux, même si je ne comprend pas pourquoi ne pas avoir mis 2 x 10 Gb/s en uplink, si ce sont des switchs avec 48 ports 1 Gb/s.
Ma seconde hypothèse serait de chaîner les switchs en boucle. 10 switchs chaînés entre eux, là le 40 gb/s est pertinent.
Hypothèse : 80 Mb/s consommé en moyenne par port 1 Gb/s au moment du pic de trafic sur l'infra.
=> 48 x 0.08 = 3,8 Gb/s
Si on applique cette formule :
Voici une formule qui s'approche de ce qu'il faut provisionner :
Le débit offert aux clients x2 + la consommation moyenne par client multiplié par le nombre de client.
Consommation moyenne typique par client au moment du pic de consommation (généralement le dimanche soir):
- ADSL (débit typique offert au client de 8 Mb/s) : 200 Kb/s hors TV
- Câble (débit typique offert au client de 50 Mb/s) : 300 Kb/s hors TV
- FTTH (débit typique offert au client de 300 Mb/s) : 400 Kb/s hors TV
Taille du tuyau nécessaire pour 100 clients à 10 Mb/s (hors flux TV multicast) : 10 x 2 + 0,2 x 100 = 40 Mb/s
Taille du tuyau nécessaire pour 100 clients à 50 Mb/s (hors flux TV multicast) : 50 x 2 + 0,3 x 100 = 130 Mb/s
Taille du tuyau nécessaire pour 100 clients à 100 Mb/s (hors flux TV multicast) : 100 x 2 + 0,4 x 100 = 240 Mb/s
Inversement, avec 1 Gb/s, tu mets :
- ( 1000 - (10 x 2) ) / 0,2 = 4900 clients à 10 Mb/s
- ( 1000 - (50 x 2) ) / 0,3 = 3000 clients à 50 Mb/s
- ( 1000 - (100 x 2) ) / 0,4 = 2000 clients à 100 Mb/s
C'est une estimation pour Internet, sans les flux TV.
Pour les flux TV, tout dépend de jusqu'à où tu descend tous les flux, le débit des flux et l'usage de tes clients.
Pour notre switch avec 48 ports 1G avec 80 Mb/s consommé en moyenne par port 1 Gb/s au moment du pic de trafic sur l'infra, il faut donc une capacité de 2 x 1 gb/s (le débit offert) + 3,8 Gb/s, le débit consommé => 5,8 Gb/s afin de ne jamais saturer, bref un port 10 Gb/s.
Le même calcul avec des ports 2,5 gb/s et une consommation de 160 Mb/s donne 2 x 2,5 + 7.6 = 12,6 Gb/s, là un port 40 Gb/s s'impose.
Si on prend 10 switchs de 48 ports 1 Gb/s chaînés avec une conso de 80 Mb/s par port, la consommation est de 0,08 * 480 = 38 Gb/s
Le dimensionnement est de 2x1 +38 = 40 Gb/s. Donc là aussi le port 40 Gb/s est pertinent.
Bref, pour moi ces switchs ont vocation a être chaînés.
-
Arnaud à dit que les rack de Dedibox SC/XC 2016 avaient des chouchou dedans hier sur IRC ;)
-
Arnaud à dit que les rack de Dedibox SC/XC 2016 avaient des chouchou dedans hier sur IRC ;)
Ce ne serait pas pour le réseau RPN ça ? (à 1gbps sur les dedibox XC)
-
Hm, c'est pas bête ! mais je pensais que c’était sur la même interface qu'internet pour le coup. à voir :)
-
Tu n'écoutes pas ce que je te dis sur IRC Hugues. :'(
-
Ah ? J'ai pas entendu alors.