Re: [FRnOG] Switch en stack ou pas?
Bonjour, Stack ou pas Stack ? Tout dépend de l'application et de ce que l'on souhaite faire. Que ce soit Chez le constructeur X ou Y, il y aura toujours des avantages ou inconvénients. Mis à part les bugs qui arrivent sur tous les constructeurs, les limites que nous avons pu voir sur ce système est la coupure (une partie ou l'intégralité) de trafic lorsque l'on doit mettre à jour le stack avec une release majeure. Cependant, le day2day, le stack / virtual-chassis permet de vraiment gagner du temps et éviter le problème du spanning-tree. Le vrai stack / virtual-chassis partage la table de routage, les règles par défaut, tout comme un chassis, ce qui facilite le boulot de l'admin et la croissance est plus aisée qu'un châssis. Le pay-as-you-grow est selon moi l'élément de décision, le problème de disponibilité est celui qui porte à réfléchir, mais depuis les derniers releases que ce soit chez C ou J, le NSR ( non-stop-forwarding) permet de passer vers une release majeure sans impacter l'intégralité du stack Me corriger si je me trompe, mais C semble etre plus en avance de 2 ou 3 releases que J sur la mise à jour sans coupure. Le gros chassis c'est bien ( on fait les deux chez Neo donc pas de jaloux), mais pas adapté à tout le monde surtout avec le Claude qui est maintenant présent dans toutes les conversations :) -- Raphaël Maunier NEO TELECOMS CTO / Responsable Ingénierie AS8218 On Mar 18, 2011, at 4:16 AM, Nicolas MICHEL wrote: Les stacks en environnement DC je trouve pas ça tip-top. 4500 ou 6500 avec les arguments qui vont bien (non on parle pas du prix ;) ) Un client m'a remonté un problème sur un 3750 stack-pas-tres-Wise et j'ai testé ça en lab: Sur le master tu configure ip vrf forwarding X , tu sauvegardes la config, tu perds le courant sur ton master. Le slave passe Master et le Master passe slave a son retour. Maintenant tu fais un show run et tu t’aperçois que t'as perdu la commande qui attribue une VRF a ton port . fun isnt it ? Pour ceux qui veulent tester et jeter un oeil : CSCtn46230 Une nouvelle version devrait corriger le bug assez rapidement. Le 18 mars 2011 00:21, Thery clement.th...@aciernet.com a écrit : Sans aucune hesitation, deux n5k en tete en 10g les n2k en dessous, il existe meme des bundles cisco 2x n5k 20 port plus 6x n2k pour 4€ remisé. Dans les bundles tu as meme 40 FET inclus pour tes interco, As tu besoin des ref de ces bundles ? Il y en 3-4 differents. Salut Envoyé de mon iPhone Le 17 mars 2011 à 23:33, Rachid Zitouni rachid.zito...@gmail.com a écrit : Hello, Assez d'accord sur la solution virtuel châssis. Chez cisco il y a la gamme nexus 5k avec les modules nexus 2 k qui offre une bonne densité de ports et une couverture assez large pour les besoins de connectivité serveurs avec un upgrade a chaud possible ( issu) Pour simplifier ta distribution cuivre tu peux partir sur une distrib cuivre en top of rack et y placer tes nexus 2k. Pour la scalabilite, c'est 500 vlan en mst et 250 en pvst, 480 ports serveurs en lacp dans une certaine configuration sinon ce sera du teaming. Cote prix : bien remplit (480 ports) un virtuel châssis redonde coûte moins cher que 2 stack de la gamme 3750g et maintenant 3750x. Cote management les deux solutions se valent sauf pour la supervision et le monitoring (XML vs snmp). Autre point : issu est en roadmap je crois sur la gamme 3750x a vérifier ... A+ Rachid Le 17 mars 2011 à 22:04, Fregate84 fregat...@free.fr a écrit : Les virtuals chassis c’est pas mal. 2 gros switch indépendant mais vu comme un seul. Comme ca pas de spanning tree, tout en LACP …. Et une bonne redondance. Bon par contre ca coute un peu plus chère que des swich en stack … De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de Raymond Caracatamatere Envoyé : jeudi 17 mars 2011 21:54 À : frnog@frnog.org Objet : [FRnOG] Switch en stack ou pas? Bonjour à tous, Je dois réfléchir à une architecture réseau très haute-disponibilité, et je me pose des questions sur ce qu'il est mieux de faire au niveau des switchs. Il est indispensable de double attacher les serveurs pour la redondance (utilisation aussi de bladecenter DELL M1000e), et j'aimerai avoir vos avis sur les stack de switch. Avec 2x5 baies, je peux faire 2 stacks de 5 switchs par rangé de baie. Les stacks c'est sexy car l'administration est sympa et simplifiée, et surtout on peut utiliser le Pvlan (ou similaire) j'en suis fan et le LACP, par contre les mises à jour de firmware c'est triste quand il faut couper tout le stack ... ou bien quand tout ton stack à un soucis. D'après vos expériences, plutôt le stack ou plutôt les switchs seuls ? Et le double attachement des serveurs plutôt en spanning-tree (cela me semble très très moche) ou plutôt en teaming ? Il existe une solution miracle? Si vous avez des idées pour faire balancer mon
Re: [FRnOG] Switch en stack ou pas?
Hello Pascal, J'ai vu la présentation de Greg, alors si tu parle de Trill vs 802.1aq, je suis certain que dans pas longtemps cela risque d'être vraiment très intéressant. En attendant, le stack reste selon moi la techno la plus sure pour le PAG ( chez certain on aime bien faire des acronymes :) ) :) -- Raphaël Maunier NEO TELECOMS CTO / Responsable Ingénierie AS8218 21 rue La Boétie 75008 Paris Tel : +33 1.49.97.07.44 Mob : +33 6.86.86.81.76 rmaun...@neotelecoms.com skype : rmaunier On Mar 18, 2011, at 8:03 AM, Pascal Gay wrote: Bonjour il existe de nouvelles solutions pour les serveurs comme des clusters de switches ou fabrique Ethernet... Ni stacks ni châssis..du pay as you grow sans les inconvénients du stack et moins cher que les châssis ... Pascal Gay Mobile +33648755759 Le 18 mars 2011 à 07:29, Raphael Maunier rmaun...@neotelecoms.com a écrit : Bonjour, Stack ou pas Stack ? Tout dépend de l'application et de ce que l'on souhaite faire. Que ce soit Chez le constructeur X ou Y, il y aura toujours des avantages ou inconvénients. Mis à part les bugs qui arrivent sur tous les constructeurs, les limites que nous avons pu voir sur ce système est la coupure (une partie ou l'intégralité) de trafic lorsque l'on doit mettre à jour le stack avec une release majeure. Cependant, le day2day, le stack / virtual-chassis permet de vraiment gagner du temps et éviter le problème du spanning-tree. Le vrai stack / virtual-chassis partage la table de routage, les règles par défaut, tout comme un chassis, ce qui facilite le boulot de l'admin et la croissance est plus aisée qu'un châssis. Le pay-as-you-grow est selon moi l'élément de décision, le problème de disponibilité est celui qui porte à réfléchir, mais depuis les derniers releases que ce soit chez C ou J, le NSR ( non-stop-forwarding) permet de passer vers une release majeure sans impacter l'intégralité du stack Me corriger si je me trompe, mais C semble etre plus en avance de 2 ou 3 releases que J sur la mise à jour sans coupure. Le gros chassis c'est bien ( on fait les deux chez Neo donc pas de jaloux), mais pas adapté à tout le monde surtout avec le Claude qui est maintenant présent dans toutes les conversations :) -- Raphaël Maunier NEO TELECOMS CTO / Responsable Ingénierie AS8218 On Mar 18, 2011, at 4:16 AM, Nicolas MICHEL wrote: Les stacks en environnement DC je trouve pas ça tip-top. 4500 ou 6500 avec les arguments qui vont bien (non on parle pas du prix ;) ) Un client m'a remonté un problème sur un 3750 stack-pas-tres-Wise et j'ai testé ça en lab: Sur le master tu configure ip vrf forwarding X , tu sauvegardes la config, tu perds le courant sur ton master. Le slave passe Master et le Master passe slave a son retour. Maintenant tu fais un show run et tu t’aperçois que t'as perdu la commande qui attribue une VRF a ton port . fun isnt it ? Pour ceux qui veulent tester et jeter un oeil : CSCtn46230 Une nouvelle version devrait corriger le bug assez rapidement. Le 18 mars 2011 00:21, Thery clement.th...@aciernet.com a écrit : Sans aucune hesitation, deux n5k en tete en 10g les n2k en dessous, il existe meme des bundles cisco 2x n5k 20 port plus 6x n2k pour 4€ remisé. Dans les bundles tu as meme 40 FET inclus pour tes interco, As tu besoin des ref de ces bundles ? Il y en 3-4 differents. Salut Envoyé de mon iPhone Le 17 mars 2011 à 23:33, Rachid Zitouni rachid.zito...@gmail.com a écrit : Hello, Assez d'accord sur la solution virtuel châssis. Chez cisco il y a la gamme nexus 5k avec les modules nexus 2 k qui offre une bonne densité de ports et une couverture assez large pour les besoins de connectivité serveurs avec un upgrade a chaud possible ( issu) Pour simplifier ta distribution cuivre tu peux partir sur une distrib cuivre en top of rack et y placer tes nexus 2k. Pour la scalabilite, c'est 500 vlan en mst et 250 en pvst, 480 ports serveurs en lacp dans une certaine configuration sinon ce sera du teaming. Cote prix : bien remplit (480 ports) un virtuel châssis redonde coûte moins cher que 2 stack de la gamme 3750g et maintenant 3750x. Cote management les deux solutions se valent sauf pour la supervision et le monitoring (XML vs snmp). Autre point : issu est en roadmap je crois sur la gamme 3750x a vérifier ... A+ Rachid Le 17 mars 2011 à 22:04, Fregate84 fregat...@free.fr a écrit : Les virtuals chassis c’est pas mal. 2 gros switch indépendant mais vu comme un seul. Comme ca pas de spanning tree, tout en LACP …. Et une bonne redondance. Bon par contre ca coute un peu plus chère que des swich en stack … De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de Raymond Caracatamatere Envoyé : jeudi 17 mars 2011 21:54 À : frnog@frnog.org Objet : [FRnOG] Switch en stack ou pas? Bonjour à tous, Je dois réfléchir à une
Re: [FRnOG] Switch en stack ou pas?
Raphael Oui c'est ça basé sur du trill.. Techno jeune mais super prometteuse et innovatrice et déjà dispo chez qui tu sais :) pas de limite de taille ni de bande passante dans une pile ni de problème d'equilibrage de charges entre liens LACP... et produits prêts pour transporter des flux de stockage type FCOE ou ISCSI sur DCB (autres acronymes :)) sans parler de la gestion automatique des mouvements de VM.. Et il y a encore pleins d'autres avantages comme la possibilité d'inserer un service type firewall encryption ou autre load balancing par exemple a chaud dans le cluster sans arrêt du reseau !! Pour moi cette technologie va remplacer le stack dans les années qui viennent (avis personnel) dans les datacenters voire ailleurs Pascal Gay Mobile +33648755759 Le 18 mars 2011 à 08:12, Raphael Maunier rmaun...@neotelecoms.commailto:rmaun...@neotelecoms.com a écrit : Hello Pascal, J'ai vu la présentation de Greg, alors si tu parle de Trill vs 802.1aq, je suis certain que dans pas longtemps cela risque d'être vraiment très intéressant. En attendant, le stack reste selon moi la techno la plus sure pour le PAG ( chez certain on aime bien faire des acronymes :) ) :) -- Raphaël Maunier NEO TELECOMS CTO / Responsable Ingénierie AS8218 21 rue La Boétie 75008 Paris Tel : +33 1.49.97.07.44 Mob : +33 6.86.86.81.76 mailto:rmaun...@neotelecoms.comrmaun...@neotelecoms.commailto:rmaun...@neotelecoms.com skype : rmaunier On Mar 18, 2011, at 8:03 AM, Pascal Gay wrote: Bonjour il existe de nouvelles solutions pour les serveurs comme des clusters de switches ou fabrique Ethernet... Ni stacks ni châssis..du pay as you grow sans les inconvénients du stack et moins cher que les châssis ... Pascal Gay Mobile +33648755759 Le 18 mars 2011 à 07:29, Raphael Maunier mailto:rmaun...@neotelecoms.comrmaun...@neotelecoms.commailto:rmaun...@neotelecoms.com a écrit : Bonjour, Stack ou pas Stack ? Tout dépend de l'application et de ce que l'on souhaite faire. Que ce soit Chez le constructeur X ou Y, il y aura toujours des avantages ou inconvénients. Mis à part les bugs qui arrivent sur tous les constructeurs, les limites que nous avons pu voir sur ce système est la coupure (une partie ou l'intégralité) de trafic lorsque l'on doit mettre à jour le stack avec une release majeure. Cependant, le day2day, le stack / virtual-chassis permet de vraiment gagner du temps et éviter le problème du spanning-tree. Le vrai stack / virtual-chassis partage la table de routage, les règles par défaut, tout comme un chassis, ce qui facilite le boulot de l'admin et la croissance est plus aisée qu'un châssis. Le pay-as-you-grow est selon moi l'élément de décision, le problème de disponibilité est celui qui porte à réfléchir, mais depuis les derniers releases que ce soit chez C ou J, le NSR ( non-stop-forwarding) permet de passer vers une release majeure sans impacter l'intégralité du stack Me corriger si je me trompe, mais C semble etre plus en avance de 2 ou 3 releases que J sur la mise à jour sans coupure. Le gros chassis c'est bien ( on fait les deux chez Neo donc pas de jaloux), mais pas adapté à tout le monde surtout avec le Claude qui est maintenant présent dans toutes les conversations :) -- Raphaël Maunier NEO TELECOMS CTO / Responsable Ingénierie AS8218 On Mar 18, 2011, at 4:16 AM, Nicolas MICHEL wrote: Les stacks en environnement DC je trouve pas ça tip-top. 4500 ou 6500 avec les arguments qui vont bien (non on parle pas du prix ;) ) Un client m'a remonté un problème sur un 3750 stack-pas-tres-Wise et j'ai testé ça en lab: Sur le master tu configure ip vrf forwarding X , tu sauvegardes la config, tu perds le courant sur ton master. Le slave passe Master et le Master passe slave a son retour. Maintenant tu fais un show run et tu t’aperçois que t'as perdu la commande qui attribue une VRF a ton port . fun isnt it ? Pour ceux qui veulent tester et jeter un oeil : CSCtn46230 Une nouvelle version devrait corriger le bug assez rapidement. Le 18 mars 2011 00:21, Thery mailto:clement.th...@aciernet.commailto:clement.th...@aciernet.comclement.th...@aciernet.commailto:clement.th...@aciernet.com a écrit : Sans aucune hesitation, deux n5k en tete en 10g les n2k en dessous, il existe meme des bundles cisco 2x n5k 20 port plus 6x n2k pour 4€ remisé. Dans les bundles tu as meme 40 FET inclus pour tes interco, As tu besoin des ref de ces bundles ? Il y en 3-4 differents. Salut Envoyé de mon iPhone Le 17 mars 2011 à 23:33, Rachid Zitouni mailto:rachid.zito...@gmail.commailto:rachid.zito...@gmail.comrachid.zito...@gmail.commailto:rachid.zito...@gmail.com a écrit : Hello, Assez d'accord sur la solution virtuel châssis. Chez cisco il y a la gamme nexus 5k avec les modules nexus 2 k qui offre une bonne densité de ports et une couverture assez large pour les besoins de connectivité serveurs avec un upgrade a chaud possible ( issu) Pour simplifier ta distribution cuivre tu peux
Re: [FRnOG] Switch en stack ou pas?
Bonjour il existe de nouvelles solutions pour les serveurs comme des clusters de switches ou fabrique Ethernet... Ni stacks ni châssis..du pay as you grow sans les inconvénients du stack et moins cher que les châssis ... Pascal Gay Mobile +33648755759 Le 18 mars 2011 à 07:29, Raphael Maunier rmaun...@neotelecoms.commailto:rmaun...@neotelecoms.com a écrit : Bonjour, Stack ou pas Stack ? Tout dépend de l'application et de ce que l'on souhaite faire. Que ce soit Chez le constructeur X ou Y, il y aura toujours des avantages ou inconvénients. Mis à part les bugs qui arrivent sur tous les constructeurs, les limites que nous avons pu voir sur ce système est la coupure (une partie ou l'intégralité) de trafic lorsque l'on doit mettre à jour le stack avec une release majeure. Cependant, le day2day, le stack / virtual-chassis permet de vraiment gagner du temps et éviter le problème du spanning-tree. Le vrai stack / virtual-chassis partage la table de routage, les règles par défaut, tout comme un chassis, ce qui facilite le boulot de l'admin et la croissance est plus aisée qu'un châssis. Le pay-as-you-grow est selon moi l'élément de décision, le problème de disponibilité est celui qui porte à réfléchir, mais depuis les derniers releases que ce soit chez C ou J, le NSR ( non-stop-forwarding) permet de passer vers une release majeure sans impacter l'intégralité du stack Me corriger si je me trompe, mais C semble etre plus en avance de 2 ou 3 releases que J sur la mise à jour sans coupure. Le gros chassis c'est bien ( on fait les deux chez Neo donc pas de jaloux), mais pas adapté à tout le monde surtout avec le Claude qui est maintenant présent dans toutes les conversations :) -- Raphaël Maunier NEO TELECOMS CTO / Responsable Ingénierie AS8218 On Mar 18, 2011, at 4:16 AM, Nicolas MICHEL wrote: Les stacks en environnement DC je trouve pas ça tip-top. 4500 ou 6500 avec les arguments qui vont bien (non on parle pas du prix ;) ) Un client m'a remonté un problème sur un 3750 stack-pas-tres-Wise et j'ai testé ça en lab: Sur le master tu configure ip vrf forwarding X , tu sauvegardes la config, tu perds le courant sur ton master. Le slave passe Master et le Master passe slave a son retour. Maintenant tu fais un show run et tu t’aperçois que t'as perdu la commande qui attribue une VRF a ton port . fun isnt it ? Pour ceux qui veulent tester et jeter un oeil : CSCtn46230 Une nouvelle version devrait corriger le bug assez rapidement. Le 18 mars 2011 00:21, Thery mailto:clement.th...@aciernet.comclement.th...@aciernet.commailto:clement.th...@aciernet.com a écrit : Sans aucune hesitation, deux n5k en tete en 10g les n2k en dessous, il existe meme des bundles cisco 2x n5k 20 port plus 6x n2k pour 4€ remisé. Dans les bundles tu as meme 40 FET inclus pour tes interco, As tu besoin des ref de ces bundles ? Il y en 3-4 differents. Salut Envoyé de mon iPhone Le 17 mars 2011 à 23:33, Rachid Zitouni mailto:rachid.zito...@gmail.comrachid.zito...@gmail.commailto:rachid.zito...@gmail.com a écrit : Hello, Assez d'accord sur la solution virtuel châssis. Chez cisco il y a la gamme nexus 5k avec les modules nexus 2 k qui offre une bonne densité de ports et une couverture assez large pour les besoins de connectivité serveurs avec un upgrade a chaud possible ( issu) Pour simplifier ta distribution cuivre tu peux partir sur une distrib cuivre en top of rack et y placer tes nexus 2k. Pour la scalabilite, c'est 500 vlan en mst et 250 en pvst, 480 ports serveurs en lacp dans une certaine configuration sinon ce sera du teaming. Cote prix : bien remplit (480 ports) un virtuel châssis redonde coûte moins cher que 2 stack de la gamme 3750g et maintenant 3750x. Cote management les deux solutions se valent sauf pour la supervision et le monitoring (XML vs snmp). Autre point : issu est en roadmap je crois sur la gamme 3750x a vérifier ... A+ Rachid Le 17 mars 2011 à 22:04, Fregate84 mailto:fregat...@free.frmailto:fregat...@free.frfregat...@free.frmailto:fregat...@free.fr a écrit : Les virtuals chassis c’est pas mal. 2 gros switch indépendant mais vu comme un seul. Comme ca pas de spanning tree, tout en LACP …. Et une bonne redondance. Bon par contre ca coute un peu plus chère que des swich en stack … De : mailto:owner-fr...@frnog.org mailto:owner-fr...@frnog.org owner-fr...@frnog.orgmailto:owner-fr...@frnog.org [mailto:mailto:owner-fr...@frnog.orgowner-fr...@frnog.orgmailto:owner-fr...@frnog.org] De la part de Raymond Caracatamatere Envoyé : jeudi 17 mars 2011 21:54 À : mailto:frnog@frnog.org mailto:frnog@frnog.org mailto:frnog@frnog.org frnog@frnog.orgmailto:frnog@frnog.org Objet : [FRnOG] Switch en stack ou pas? Bonjour à tous, Je dois réfléchir à une architecture réseau très haute-disponibilité, et je me pose des questions sur ce qu'il est mieux de faire au niveau des switchs. Il est indispensable de double attacher les
[FRnOG] Offre d'emploi
Bonjour à tous et à toutes. Premier poste pour moi sur la liste. Désolé d'avance si cela ne correspond pas à la charte (mais bon, après tout, on est trolldi). Voilà, l'entreprise où je travaille recherche un architecte réseau et il nous est possible de coopter. Je vous copie-colle l'annonce (pas de commentaires dessus svp, elle n'est pas de moi mais des RH). Si vous êtes intéressés ou si vous voulez plus de précisions, n'hésitez pas à demander. Cordialement, Florent Menot, Développeur Logiciel IsaPaye Isagri L'annonce : Architecte Réseau Pour son équipe Infrastructure Réseaux Clients, composée de 12 personnes, l'entreprise recherche 1 Architecte Réseaux (H/F) Vos missions : Au sein de l'équipe Infrastructure Réseaux Clients, vous aurez en charge les études d’avant-projet, la conception d’architectures réseau et la gestion de projets d’intégration. Vous aurez notamment les missions suivantes : Collecte et analyse des besoins clients (audit de l’existant, propositions d’évolutions) Conduite des études d’avant-projet (solutions techniques, business case…) Définition des architectures réseau et des configurations associées en fonction des besoins exprimés Rédaction des livrables associés et conduite de présentations (équipe, management…) Votre profil : Diplôme de niveau Bac+5 ou équivalent Bonnes capacités rédactionnelles et de formalisation Expérience minimale de 3 ans dans le domaine du réseau Vous avez un goût prononcé pour les réseaux, vous souhaitez mettre à profit votre expérience et vos compétences dans des environnements challengeants tout en continuant à évoluer dans votre expertise, Vous êtes autonome, mobile, avez de bonnes capacités rédactionnelles, souhaitez rejoindre un environnement dynamique et formateur, n'hésitez pas à nous contacter. Conditions proposées : CDI basé à Beauvais, à pourvoir dès que possible. Rémunération selon expérience (fixe + prime + intéressement + participation).
Re: [FRnOG] Switch en stack ou pas?
J'aurais tendance à te dire que la tolérence doit être applicative et capable d'être répartie et distribuée. Les techno d'ajourd'hui le permettent largement, mais je ne sais pas ce que tu comptes faire tourner derriere. Chez moi on a effectivement systématiquement des stack pour chaque baie, pour nos 4 dc et env 40 baies dans chaque. Sachant qu'on brasse l'impair d'un membre et le pair de l'autre et que chaque port non brassé est recopié automatiquement (j'ai un script python qui s'en occupe si ça t'intéresse). D'expérience, en plus de 10 ans, on n'a jamais eu besoin du stack, même si c'est en prévision (c'est arrivé une fois mais sur un stack dédié user), le fait est qu'aujourd'hui les techno qu'on tend à utiliser saurait très bien se débrouiller si un switch tombait. Même pour automatiser la montée en charge. Tout dépend donc de ton budget... après en cas de pépin, le remplacement est assez transparent car la conf reste en provisioning. En résumé : Si tu as des applis un peu moderne, investi plutôt en RAM :) sinon casse la tirelire La réflexion pour le double attachement est un peu la même. Maintenant en terme de perf, il faut savoir qu'un stack c'est un anneau (type token ring), donc tu as des latences assez élevé plus tu rajoutes de membre) et tu divises ta capacité par le nombre de membre dans le stack. Si pour la plupart des applis c'est transparent, pour des applis temps réel critique ça peut avoir une incidence. 2011/3/17 Raymond Caracatamatere raymond.caracatamat...@gmail.com Bonjour à tous, Je dois réfléchir à une architecture réseau très haute-disponibilité, et je me pose des questions sur ce qu'il est mieux de faire au niveau des switchs. Il est indispensable de double attacher les serveurs pour la redondance (utilisation aussi de bladecenter DELL M1000e), et j'aimerai avoir vos avis sur les stack de switch. Avec 2x5 baies, je peux faire 2 stacks de 5 switchs par rangé de baie. Les stacks c'est sexy car l'administration est sympa et simplifiée, et surtout on peut utiliser le Pvlan (ou similaire) j'en suis fan et le LACP, par contre les mises à jour de firmware c'est triste quand il faut couper tout le stack ... ou bien quand tout ton stack à un soucis. D'après vos expériences, plutôt le stack ou plutôt les switchs seuls ? Et le double attachement des serveurs plutôt en spanning-tree (cela me semble très très moche) ou plutôt en teaming ? Il existe une solution miracle? Si vous avez des idées pour faire balancer mon cœur :) Merci beaucoup Ray -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB ste...@le-roux.info 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
[FRnOG] Operateurs en Afrique ?.
Bonjour, Je recherche des opérateurs capable de livrer de l'IP entre Paris et les principales villes du Gabon/Congo/Cameroun (pas de satellite). Merci de vos infos. Cordialement. PM.
Re: [FRnOG] Switch en stack ou pas?
Ouais Sympa !! tout ça, merci à tous pour vos réponses (en privée et en public), Steven je veux bien ton script python :) On est d'accord que le stack est super pratique mais les mises à jour sont trop dangereuses, et les coupures de service ne seront pas admises. Je suis surpris que si peu de monde apprécie le stack, cela évite beaucoup de brassage vis à vis des gros chassis. Après peut-être que les cluster de switch (idée de Pascal) peuvent aussi être une solution, mais cela me semble un peu jeune, et je préfère travailler sur des choses éprouvées (du qui marche plutôt que du qui va marcher) Après il me reste ma problématique de pvlan, sans les stack, c'est pénible. Et sans parler de stack donc plutôt top-of-the-rack ou plutôt gros chassis + brassage ? moi j'étais plus parti sur du top-of-the-rack, vous savez si les constructeurs propose du pvlan (ou similaire) au travers de plusieurs switchs non stackés? vous avez un retour d'expérience sur ce genre d'archi ? Merci beaucoup pour votre aide. Ray Le 18 mars 2011 09:59, Steven Le Roux ste...@le-roux.info a écrit : J'aurais tendance à te dire que la tolérence doit être applicative et capable d'être répartie et distribuée. Les techno d'ajourd'hui le permettent largement, mais je ne sais pas ce que tu comptes faire tourner derriere. Chez moi on a effectivement systématiquement des stack pour chaque baie, pour nos 4 dc et env 40 baies dans chaque. Sachant qu'on brasse l'impair d'un membre et le pair de l'autre et que chaque port non brassé est recopié automatiquement (j'ai un script python qui s'en occupe si ça t'intéresse). D'expérience, en plus de 10 ans, on n'a jamais eu besoin du stack, même si c'est en prévision (c'est arrivé une fois mais sur un stack dédié user), le fait est qu'aujourd'hui les techno qu'on tend à utiliser saurait très bien se débrouiller si un switch tombait. Même pour automatiser la montée en charge. Tout dépend donc de ton budget... après en cas de pépin, le remplacement est assez transparent car la conf reste en provisioning. En résumé : Si tu as des applis un peu moderne, investi plutôt en RAM :) sinon casse la tirelire La réflexion pour le double attachement est un peu la même. Maintenant en terme de perf, il faut savoir qu'un stack c'est un anneau (type token ring), donc tu as des latences assez élevé plus tu rajoutes de membre) et tu divises ta capacité par le nombre de membre dans le stack. Si pour la plupart des applis c'est transparent, pour des applis temps réel critique ça peut avoir une incidence. 2011/3/17 Raymond Caracatamatere raymond.caracatamat...@gmail.com Bonjour à tous, Je dois réfléchir à une architecture réseau très haute-disponibilité, et je me pose des questions sur ce qu'il est mieux de faire au niveau des switchs. Il est indispensable de double attacher les serveurs pour la redondance (utilisation aussi de bladecenter DELL M1000e), et j'aimerai avoir vos avis sur les stack de switch. Avec 2x5 baies, je peux faire 2 stacks de 5 switchs par rangé de baie. Les stacks c'est sexy car l'administration est sympa et simplifiée, et surtout on peut utiliser le Pvlan (ou similaire) j'en suis fan et le LACP, par contre les mises à jour de firmware c'est triste quand il faut couper tout le stack ... ou bien quand tout ton stack à un soucis. D'après vos expériences, plutôt le stack ou plutôt les switchs seuls ? Et le double attachement des serveurs plutôt en spanning-tree (cela me semble très très moche) ou plutôt en teaming ? Il existe une solution miracle? Si vous avez des idées pour faire balancer mon cœur :) Merci beaucoup Ray -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB ste...@le-roux.info 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
[FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo
Bonjour, C'est la journée green avec Ikoula qui nous sort ses serveurs Greenfish XL et surtout OVH qui lance un communiqué de presse pour parler d'éoliennes et de transport de serveurs par péniches. OVH : http://www.romandie.com/infos/news2/110316121337.ci7c43ru.asp Ikoula : http://www.ikoula.com/portals/0/images/newsletter/mars11_express/index.html Je ne me permet pas de juger pas de la qualité des prestations mais seulement la communication (je suis client OVH et j'apprécie beaucoup Ikoula). Dans les deux cas on nous parle de serveurs dédiés écolo-vert-green alors qu'un serveur dédié est intrinsèquement non écologique. C'est pareil pour les voitures, une voiture électrique ne sera jamais écologique. Ces deux hébergeurs, comme beaucoup d'autres, proposent des machines dédiés qui consomment peu à des tarifs très intéressants. Sauf que, qui a besoin d'un serveur dédié ?! normalement pas grand monde. L'hébergement réellement écologique c'est le mutualisé, sur les architectures actuelles on peut faire tenir des gros sites. Malheureusement pour les clients ces hébergements sont souvent très limités (connexions mysql, envoi de mails, performances, espace disque ...) et pour un peu plus cher ils peuvent avoir leur dédié à eux tout seul. Pour l'hébergeur un dédié fait plus de chiffre d'affaire et c'est pourquoi il va pousser ses clients mutualisés un peu trop consommateurs vers un dédié. Donc, OVH, Ikoula et les autres, si vous voulez vraiment faire de l'écologique, proposez de l'hébergement mutualisé qui tienne vraiment la route et réservez les serveurs dédiés aux clients qui en ont vraiment besoin. Fred. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo
Le 18 mars 2011 à 13:30, Frédéric VANNIÈRE a écrit : Donc, OVH, Ikoula et les autres, si vous voulez vraiment faire de l'écologique, proposez de l'hébergement mutualisé qui tienne vraiment la route et réservez les serveurs dédiés aux clients qui en ont vraiment besoin. Fred salut Fred, ce que les marketeux appelle bidule Cloud tralala c'est d'une certain façon du mutu pour pro ? Après, sur l'initiative d'OVH (dont je suis aussi client satisfait), c'est tjs mieux que rien que d'installer 10MW d'éoliennes, non ? Pareil pour le transport, je prefere la péniche au semi ! niveau trollage du dredi, la vrai prochaine étape pour rendre l'utilisation des serveurs plus vert, c'est d'abord et avant tout de développer les soft pour qu'ils consomment le moins possible (moins de ressources, moins de cpu, moins de chaleur, moins d'usure ... == moins d'edf, moins de renouvellement de parc, ... ;) had--- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo
trollons trollons ;-) On va vraiment devoir se passer de la sur-couche JAVA qui bouffe des ressources pour masquer l'incompétence de quelques devs ? si seulement c'était envisagé je signerai pour le Green-IT tout de suite. Le 18/03/11 13:43, hadrien a écrit : Le 18 mars 2011 à 13:30, Frédéric VANNIÈRE a écrit : Donc, OVH, Ikoula et les autres, si vous voulez vraiment faire de l'écologique, proposez de l'hébergement mutualisé qui tienne vraiment la route et réservez les serveurs dédiés aux clients qui en ont vraiment besoin. Fred salut Fred, ce que les marketeux appelle bidule Cloud tralala c'est d'une certain façon du mutu pour pro ? Après, sur l'initiative d'OVH (dont je suis aussi client satisfait), c'est tjs mieux que rien que d'installer 10MW d'éoliennes, non ? Pareil pour le transport, je prefere la péniche au semi ! niveau trollage du dredi, la vrai prochaine étape pour rendre l'utilisation des serveurs plus vert, c'est d'abord et avant tout de développer les soft pour qu'ils consomment le moins possible (moins de ressources, moins de cpu, moins de chaleur, moins d'usure ... == moins d'edf, moins de renouvellement de parc, ... ;) had--- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l 'écolo pipo
Sans voiloir lancer un troll, je me suis toujours demandé si on pouvait aller jusqu'à l'OS, peux t'on dire que linux est plus green que windows parcequ'il consomme moins de watts ? Damien, hadrien writes: Le 18 mars 2011 à 13:30, Frédéric VANNIÈRE a écrit : Donc, OVH, Ikoula et les autres, si vous voulez vraiment faire de l'écologique, proposez de l'hébergement mutualisé qui tienne vraiment la route et réservez les serveurs dédiés aux clients qui en ont vraiment besoin. Fred salut Fred, ce que les marketeux appelle bidule Cloud tralala c'est d'une certain façon du mutu pour pro ? Après, sur l'initiative d'OVH (dont je suis aussi client satisfait), c'est tjs mieux que rien que d'installer 10MW d'éoliennes, non ? Pareil pour le transport, je prefere la péniche au semi ! niveau trollage du dredi, la vrai prochaine étape pour rendre l'utilisation des serveurs plus vert, c'est d'abord et avant tout de développer les soft pour qu'ils consomment le moins possible (moins de ressources, moins de cpu, moins de chaleur, moins d'usure ... == moins d'edf, moins de renouvellement de parc, ... ;) had--- Liste de diffusion du FRnOG http://www.frnog.org/ -- ~~ Damien WETZEL (ATANAR TECHNOLOGIES)(`-/)_.-'``-._ http://www.atanar.com . . `; -._)-;-,_`) (v_,)' _ )`-.\ ``-' Phone:+33 6 62 29 61 77 _.- _..-_/ / ((.' - So much to do, so little time - ((,.-' ((,/ ~ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l 'écolo pipo
On Fri, 2011-03-18 at 14:17 +0100, Damien Wetzel wrote: Sans voiloir lancer un troll, je me suis toujours demandé si on pouvait aller jusqu'à l'OS, peux t'on dire que linux est plus green que windows parcequ'il consomme moins de watts ? Damien, tout dépends des niveaux de documentation des chipsets... si ton chipset est documenté correctement, y'a des chances pour que ce soit vrai ;) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo
Bonjour, Je pense que la première chose à faire sur ces grosses infra, c'est d'avoir des arrivées électriques en courant continu avec les bons voltages vers les serveurs. 1 alims pour 1 serveurs (si ce n'est pas 2 avec les alims redondantes) - ça fait une sacré déperdition. Ce genre de chose est tout à fait envisageable vu l'échelle d'OVH par exemple (ils ont déjà du matériel custom, pourquoi ne pas pousser plus loin ?) De mémoire, OVH a ce genre de pratique, avec d'autres techniques, pour diminuer les consos dans leurs DC. Je salue en tout cas les efforts de ces deux entreprises (OVH étant précurseur, notamment au niveau du refroidissement). Mieux vaut de petits gestes, même si il y a du marketing derrière, que rien du tout comme beaucoup le font. Sachant que tout ceci coûte en prime moins de sous, pourquoi s'en priver ? Mathieu Le 18 mars 2011 à 13:43, hadrien a écrit : niveau trollage du dredi, la vrai prochaine étape pour rendre l'utilisation des serveurs plus vert, c'est d'abord et avant tout de développer les soft pour qu'ils consomment le moins possible (moins de ressources, moins de cpu, moins de chaleur, moins d'usure ... == moins d'edf, moins de renouvellement de parc, ... ;) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo
Le Fri, Mar 18, 2011 at 01:43:31PM +0100, hadrien [hadr...@cap270.com] a écrit: ce que les marketeux appelle bidule Cloud tralala c'est d'une certain façon du mutu pour pro ? C'est généralement juste de la plateforme de virtualisation avec tout le bastringue qui va bien pour faire du provisioning automatisé, et tout. (et c'est après tout une forme de mutualisation) En plateforme mutualisée très cloud, et qui se résume pas à ce que je décris, c'est l'AppEngine de Google et les trucs qui y ressemblent vraiment. -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 50, rue Riolan 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] RE: [FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo
Bonjour a tous, J'ai récemment déployé des infra Nexus/serveur blade Cisco chez un hébergeur internet, ce client possédait 40 Baies, avec les consos énergétiques qui vont bien, aujourd'hui, sont infra tient sur 3 baies, il a diminué sa facture électrique par 4, ce qui lui paie sa plate forme complète sur 18 mois (en comptant les économies de location de baies chez sont hébergeurs) Green IT pourquoi pas, mais surtout IT haute densité et mutualisé ! THERY -Message d'origine- De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de MM Envoyé : vendredi 18 mars 2011 14:26 À : hadrien Cc : frnog@frnog.org Objet : [FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo Bonjour, Je pense que la première chose à faire sur ces grosses infra, c'est d'avoir des arrivées électriques en courant continu avec les bons voltages vers les serveurs. 1 alims pour 1 serveurs (si ce n'est pas 2 avec les alims redondantes) - ça fait une sacré déperdition. Ce genre de chose est tout à fait envisageable vu l'échelle d'OVH par exemple (ils ont déjà du matériel custom, pourquoi ne pas pousser plus loin ?) De mémoire, OVH a ce genre de pratique, avec d'autres techniques, pour diminuer les consos dans leurs DC. Je salue en tout cas les efforts de ces deux entreprises (OVH étant précurseur, notamment au niveau du refroidissement). Mieux vaut de petits gestes, même si il y a du marketing derrière, que rien du tout comme beaucoup le font. Sachant que tout ceci coûte en prime moins de sous, pourquoi s'en priver ? Mathieu Le 18 mars 2011 à 13:43, hadrien a écrit : niveau trollage du dredi, la vrai prochaine étape pour rendre l'utilisation des serveurs plus vert, c'est d'abord et avant tout de développer les soft pour qu'ils consomment le moins possible (moins de ressources, moins de cpu, moins de chaleur, moins d'usure ... == moins d'edf, moins de renouvellement de parc, ... ;) --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] DC-DC ATX (was: Trolldi : OVH, Ikoula et l'écolo pipo)
On Fri, 2011-03-18 at 14:25 +0100, MM wrote: Je pense que la première chose à faire sur ces grosses infra, c'est d'avoir des arrivées électriques en courant continu avec les bons voltages vers les serveurs. 1 alims pour 1 serveurs (si ce n'est pas 2 avec les alims redondantes) - ça fait une sacré déperdition. Bonjour, A part les picoPSU en DC vers ATX j'ai pas trouvé grand chose, si quelqu'un a des references pour faire une chaine bien propre EDF / controleur de charge / pack de batterie / DC-DC ATX je suis preneur. 48V telco mais dans le monde PC ATX. Je précise que je parle de quelques kW maximum, pas en MW :). Merci a tous, Laurent --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo
Le 18/03/2011 14:25, MM a écrit : Bonjour, Je pense que la première chose à faire sur ces grosses infra, c'est d'avoir des arrivées électriques en courant continu avec les bons voltages vers les serveurs. 1 alims pour 1 serveurs (si ce n'est pas 2 avec les alims redondantes) - ça fait une sacré déperdition. Ce genre de chose est tout à fait envisageable vu l'échelle d'OVH par exemple (ils ont déjà du matériel custom, pourquoi ne pas pousser plus loin ?) De mémoire, OVH a ce genre de pratique, avec d'autres techniques, pour diminuer les consos dans leurs DC. Je salue en tout cas les efforts de ces deux entreprises (OVH étant précurseur, notamment au niveau du refroidissement). Mieux vaut de petits gestes, même si il y a du marketing derrière, que rien du tout comme beaucoup le font. Sachant que tout ceci coûte en prime moins de sous, pourquoi s'en priver ? Mathieu Et en plus, le marketing c'est tellement du vent que ça refroidit indirectement les serveurs. Pour un système de clim efficace, mettez tout ce qui brasse de l'air devant et tout ceux qui nous les pompe derrière. -- Jean-Dominique --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Switch en stack ou pas?
Pascal, Tu parles de l'implémentation TRILL de B ou de J ou de XYZ, Il me semble que pour un standard les implémentations sont pour le moins incompatible :) Fabien Le 18 mars 2011 à 08:25, Pascal Gay a écrit : Raphael Oui c'est ça basé sur du trill.. Techno jeune mais super prometteuse et innovatrice et déjà dispo chez qui tu sais :) pas de limite de taille ni de bande passante dans une pile ni de problème d'equilibrage de charges entre liens LACP... et produits prêts pour transporter des flux de stockage type FCOE ou ISCSI sur DCB (autres acronymes :)) sans parler de la gestion automatique des mouvements de VM.. Et il y a encore pleins d'autres avantages comme la possibilité d'inserer un service type firewall encryption ou autre load balancing par exemple a chaud dans le cluster sans arrêt du reseau !! Pour moi cette technologie va remplacer le stack dans les années qui viennent (avis personnel) dans les datacenters voire ailleurs Pascal Gay Mobile +33648755759 Le 18 mars 2011 à 08:12, Raphael Maunier rmaun...@neotelecoms.com a écrit : Hello Pascal, J'ai vu la présentation de Greg, alors si tu parle de Trill vs 802.1aq, je suis certain que dans pas longtemps cela risque d'être vraiment très intéressant. En attendant, le stack reste selon moi la techno la plus sure pour le PAG ( chez certain on aime bien faire des acronymes :) ) :) -- Raphaël Maunier NEO TELECOMS CTO / Responsable Ingénierie AS8218 21 rue La Boétie 75008 Paris Tel : +33 1.49.97.07.44 Mob : +33 6.86.86.81.76 rmaun...@neotelecoms.com skype : rmaunier On Mar 18, 2011, at 8:03 AM, Pascal Gay wrote: Bonjour il existe de nouvelles solutions pour les serveurs comme des clusters de switches ou fabrique Ethernet... Ni stacks ni châssis..du pay as you grow sans les inconvénients du stack et moins cher que les châssis ... Pascal Gay Mobile +33648755759 Le 18 mars 2011 à 07:29, Raphael Maunier rmaun...@neotelecoms.com a écrit : Bonjour, Stack ou pas Stack ? Tout dépend de l'application et de ce que l'on souhaite faire. Que ce soit Chez le constructeur X ou Y, il y aura toujours des avantages ou inconvénients. Mis à part les bugs qui arrivent sur tous les constructeurs, les limites que nous avons pu voir sur ce système est la coupure (une partie ou l'intégralité) de trafic lorsque l'on doit mettre à jour le stack avec une release majeure. Cependant, le day2day, le stack / virtual-chassis permet de vraiment gagner du temps et éviter le problème du spanning-tree. Le vrai stack / virtual-chassis partage la table de routage, les règles par défaut, tout comme un chassis, ce qui facilite le boulot de l'admin et la croissance est plus aisée qu'un châssis. Le pay-as-you-grow est selon moi l'élément de décision, le problème de disponibilité est celui qui porte à réfléchir, mais depuis les derniers releases que ce soit chez C ou J, le NSR ( non-stop-forwarding) permet de passer vers une release majeure sans impacter l'intégralité du stack Me corriger si je me trompe, mais C semble etre plus en avance de 2 ou 3 releases que J sur la mise à jour sans coupure. Le gros chassis c'est bien ( on fait les deux chez Neo donc pas de jaloux), mais pas adapté à tout le monde surtout avec le Claude qui est maintenant présent dans toutes les conversations :) -- Raphaël Maunier NEO TELECOMS CTO / Responsable Ingénierie AS8218 On Mar 18, 2011, at 4:16 AM, Nicolas MICHEL wrote: Les stacks en environnement DC je trouve pas ça tip-top. 4500 ou 6500 avec les arguments qui vont bien (non on parle pas du prix ;) ) Un client m'a remonté un problème sur un 3750 stack-pas-tres-Wise et j'ai testé ça en lab: Sur le master tu configure ip vrf forwarding X , tu sauvegardes la config, tu perds le courant sur ton master. Le slave passe Master et le Master passe slave a son retour. Maintenant tu fais un show run et tu t’aperçois que t'as perdu la commande qui attribue une VRF a ton port . fun isnt it ? Pour ceux qui veulent tester et jeter un oeil : CSCtn46230 Une nouvelle version devrait corriger le bug assez rapidement. Le 18 mars 2011 00:21, Thery clement.th...@aciernet.com a écrit : Sans aucune hesitation, deux n5k en tete en 10g les n2k en dessous, il existe meme des bundles cisco 2x n5k 20 port plus 6x n2k pour 4€ remisé. Dans les bundles tu as meme 40 FET inclus pour tes interco, As tu besoin des ref de ces bundles ? Il y en 3-4 differents. Salut Envoyé de mon iPhone Le 17 mars 2011 à 23:33, Rachid Zitouni rachid.zito...@gmail.com a écrit : Hello, Assez d'accord sur la solution virtuel châssis. Chez cisco il y a la gamme nexus 5k avec les modules nexus 2 k qui offre une bonne densité de ports et une couverture assez large pour les besoins de connectivité serveurs avec un upgrade a chaud possible ( issu) Pour simplifier ta distribution cuivre
Re: [FRnOG] DC-DC ATX
Bonjour, Laurent GUERBY wrote: On Fri, 2011-03-18 at 14:25 +0100, MM wrote: Je pense que la première chose à faire sur ces grosses infra, c'est d'avoir des arrivées électriques en courant continu avec les bons voltages vers les serveurs. 1 alims pour 1 serveurs (si ce n'est pas 2 avec les alims redondantes) - ça fait une sacré déperdition. A part les picoPSU en DC vers ATX j'ai pas trouvé grand chose, si quelqu'un a des references pour faire une chaine bien propre EDF / controleur de charge / pack de batterie / DC-DC ATX je suis preneur. 48V telco mais dans le monde PC ATX. Supermicro a quelques modèles de boitiers avec alims DC Pwr qui sont censées fonctionner en 48V. Il faut fouiller dans leur site web; voici quelques liens: http://www.supermicro.com/products/chassis/1U/811/SC811T-410.cfm http://www.supermicro.com/products/chassis/1U/812/SC812L-410.cfm http://www.supermicro.com/products/chassis/1U/812/SC812S-410.cfm http://www.supermicro.com/products/chassis/1U/813/SC813MT-410C.cfm C'est loin d'être quelque-chose de très répandu; la grande mode en ce moment c'est plutôt des alims classiques en 80+ Gold ou Platinum. D'ailleurs, les boitiers DC ont l'air d'être tous des modèles assez anciens (SCSI U-320). Ils ont peut-être été faits sur mesure pour un gros client il y a quelques années ? -- Francois Tigeot --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] La convergence voix / données sur un réseau IP unique
AFTER WORK OCEALIS le jeudi 24 mars 2011 À 18h00 Musée des Arts Décoratifs - Paris I La convergence voix / données sur un réseau IP unique est à l'origine de bénéfices significatifs : réduction des coûts, simplification de gestion, amélioration de la productivité, continuité d'activité. 18h00 La convergence voix / donnée Brocade et Shoretel se sont réunis pour fournir une solution fiable, transparente et interopérable pour répondre aux besoins des entreprises de façon transparente à moindre coût et sans complexification du réseau. 19h00 Visite privée du musée 20h30 Cocktail Le GROUPE OCEALIS est partenaire Elite Brocade. Brocade a sélectionné le GROUPE OCEALIS pour ses connaissances approfondies, ses compétences et son expertise pointue dans les solutions réseaux. Ce partenariat nous permet d'offrir les meilleures solutions réseau du marché qui délivrent de véritables avantages aux entreprises. Grâce à cela et à la possibilité de profiter des formations, du support et des actions marketing Brocade, le GROUPE OCEALIS bénéficie d'une proposition très attractive sur le marché. Les secteurs de la Santé, de l'Education et de l'Industrie nous font confiance depuis plus de 15 ans. Inscription gratuite et obligatoire, réservées au professionnels, au 04.26.72.91.61 ou par mail à cont...@groupe-ocealis.com Musée des Arts Décoratifs « Le Saut du Loup » 107, rue de Rivoli 75001 Paris Métro : Palais Royal, Pyramides, Tuileries - Bus : 21, 27, 39, 48, 68, 72, 81, 95 - Parking : Carrousel du Louvre
Re: [FRnOG] La convergence voix / données sur un réseau IP unique
Le 18/03/2011 15:58, Julie MOISSON-LAJOU a écrit : AFTER WORK OCEALIS le jeudi 24 mars 2011 À 18h00 Musée des Arts Décoratifs -- Paris I Spam commercial detected !
[FRnOG] Re: [FRnOG] La convergence voix / données sur un réseau IP unique
Non c'est un Troll qui sent mauvais :) Le 18 mars 2011 à 16:20, Fabien Dedenon a écrit : Le 18/03/2011 15:58, Julie MOISSON-LAJOU a écrit : AFTER WORK OCEALIS le jeudi 24 mars 2011 À 18h00 Musée des Arts Décoratifs – Paris I Spam commercial detected !
Re: [FRnOG] La convergence voix / données sur un réseau IP unique
Marketing, marketing :) Sent from my iPhone On Mar 18, 2011, at 16:20, Fabien Dedenon daf-l...@internet-fr.net wrote: Le 18/03/2011 15:58, Julie MOISSON-LAJOU a écrit : AFTER WORK OCEALIS le jeudi 24 mars 2011 À 18h00 Musée des Arts Décoratifs – Paris I Spam commercial detected !
Re: [FRnOG] DC-DC ATX
C'est loin d'être quelque-chose de très répandu; la grande mode en ce moment c'est plutôt des alims classiques en 80+ Gold ou Platinum. D'ailleurs, les boitiers DC ont l'air d'être tous des modèles assez anciens (SCSI U-320). Ils ont peut-être été faits sur mesure pour un gros client il y a quelques années ? C'est beau sur le papier, mais comment tu distribues 4kW par baie en 48VDC? Ca fait à vue de nez 83Amp à se trimballer par baie, sur une petite salle de 100 baies dans les 8300Amp, vu le prix du cuivre en ce moment, c'est plutôt une très mauvaise idée :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] DC-DC ATX
C'est ce qui arrive quand des non spécialistes parlent d'un sujet ;) (moi en l'occurrence - qui ai déjà du mal avec mes conversions kva/ampco) Une petite visite intéressante chez Google, avec de bon concepts : http://www.youtubevideos1.com/google-container-data-center-tour/ Mathieu Le 18 mars 2011 à 16:33, Arnaud a écrit : C'est loin d'être quelque-chose de très répandu; la grande mode en ce moment c'est plutôt des alims classiques en 80+ Gold ou Platinum. D'ailleurs, les boitiers DC ont l'air d'être tous des modèles assez anciens (SCSI U-320). Ils ont peut-être été faits sur mesure pour un gros client il y a quelques années ? C'est beau sur le papier, mais comment tu distribues 4kW par baie en 48VDC? Ca fait à vue de nez 83Amp à se trimballer par baie, sur une petite salle de 100 baies dans les 8300Amp, vu le prix du cuivre en ce moment, c'est plutôt une très mauvaise idée :) --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] DC-DC ATX
On Fri, 2011-03-18 at 16:33 +0100, Arnaud wrote: C'est loin d'être quelque-chose de très répandu; la grande mode en ce moment c'est plutôt des alims classiques en 80+ Gold ou Platinum. D'ailleurs, les boitiers DC ont l'air d'être tous des modèles assez anciens (SCSI U-320). Ils ont peut-être été faits sur mesure pour un gros client il y a quelques années ? C'est beau sur le papier, mais comment tu distribues 4kW par baie en 48VDC? Ca fait à vue de nez 83Amp à se trimballer par baie, sur une petite salle de 100 baies dans les 8300Amp, vu le prix du cuivre en ce moment, c'est plutôt une très mauvaise idée :) D'ou ma precision sur le wattage :), usage pour quelques equipements critiques et peu concentrés. Laurent --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] La convergence voix / données sur un réseau IP unique
Ouais mais alors c'est un bon troll/spam : ils offrent un cocktail ! :) Le 18/03/2011 16:21, Fabien Delmotte a écrit : Non c'est un Troll qui sent mauvais :) Le 18 mars 2011 à 16:20, Fabien Dedenon a écrit : Le 18/03/2011 15:58, Julie MOISSON-LAJOU a écrit : AFTER WORK OCEALIS le jeudi 24 mars 2011 À 18h00 Musée des Arts Décoratifs – Paris I Spam commercial detected ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] DC-DC ATX
Arnaud aberming...@corp.free.fr a écrit : C'est loin d'être quelque-chose de très répandu; la grande mode en ce moment c'est plutôt des alims classiques en 80+ Gold ou Platinum. D'ailleurs, les boitiers DC ont l'air d'être tous des modèles assez anciens (SCSI U-320). Ils ont peut-être été faits sur mesure pour un gros client il y a quelques années ? C'est beau sur le papier, mais comment tu distribues 4kW par baie en 48VDC? Ca fait à vue de nez 83Amp à se trimballer par baie, sur une petite salle de 100 baies dans les 8300Amp, vu le prix du cuivre en ce moment, c'est plutôt une très mauvaise idée :) Peut être en mettant un transfo/alim par baie pour convertir le 220V en +12V, - 12V, +5V, -5V et 0V et servir directement les composants de chaque serveur avec les connecteurs normalisés qu'on connait bien ou un bus d'alim en fond de baie. Fred --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] DC-DC ATX
Le 18/03/2011 17:29, frede...@perrod.org a écrit : Arnaud aberming...@corp.free.fr a écrit : C'est loin d'être quelque-chose de très répandu; la grande mode en ce moment c'est plutôt des alims classiques en 80+ Gold ou Platinum. D'ailleurs, les boitiers DC ont l'air d'être tous des modèles assez anciens (SCSI U-320). Ils ont peut-être été faits sur mesure pour un gros client il y a quelques années ? C'est beau sur le papier, mais comment tu distribues 4kW par baie en 48VDC? Ca fait à vue de nez 83Amp à se trimballer par baie, sur une petite salle de 100 baies dans les 8300Amp, vu le prix du cuivre en ce moment, c'est plutôt une très mauvaise idée :) Peut être en mettant un transfo/alim par baie pour convertir le 220V en +12V, - 12V, +5V, -5V et 0V et servir directement les composants de chaque serveur avec les connecteurs normalisés qu'on connait bien ou un bus d'alim en fond de baie. Intérêt ? Tu crois vraiment que tu va consommer moins comme ca? :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] DC-DC ATX
On Fri, 2011-03-18 at 18:07 +0100, Arnaud wrote: Intérêt ? Tu crois vraiment que tu va consommer moins comme ca? :) si c'est pour alimenter un cluster d'alix http://gallery.sxpert.org/v/reseaux/GrenobleWireless/hardware/20090324239.jpg.html ca peut etre pratique ;) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] DC-DC ATX
- Mail original - Le 18/03/2011 17:29, frede...@perrod.org a écrit : Arnaud aberming...@corp.free.fr a écrit : Peut être en mettant un transfo/alim par baie pour convertir le 220V en +12V, - 12V, +5V, -5V et 0V et servir directement les composants de chaque serveur avec les connecteurs normalisés qu'on connait bien ou un bus d'alim en fond de baie. Intérêt ? Tu crois vraiment que tu va consommer moins comme ca? :) Ca se fait chez des gros (en 12V) : http://perspectives.mvdirona.com/2011/02/20/DileepBhandarkarOnDatacenterEnergyEfficiency.aspx David. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo
;-) ça me fait rire, mais en même temps, je suis très sérieux le greenIT (whaou, du marketing ?) à mon sens, c'est réellement de consommer le moins de ressources possibles (software) pour utiliser le moins de matos possible, et avoir moins de factures. C'est écolo et économe, bref, c'est logique. Coté hardware, pareil. ça optimise un max du coté mobile (arm), il est temps *de faire mieux* coté server co. dans la situation actuelle, on peux raisonnablement imaginer que l'énergie coutera de plus en plus cher. l'économiser, c'est green et économe. c'est stratégique pour DC ! had Le 18 mars 2011 à 14:02, Yohann QUINTON a écrit : trollons trollons ;-) On va vraiment devoir se passer de la sur-couche JAVA qui bouffe des ressources pour masquer l'incompétence de quelques devs ? si seulement c'était envisagé je signerai pour le Green-IT tout de suite. Le 18/03/11 13:43, hadrien a écrit : Le 18 mars 2011 à 13:30, Frédéric VANNIÈRE a écrit : Donc, OVH, Ikoula et les autres, si vous voulez vraiment faire de l'écologique, proposez de l'hébergement mutualisé qui tienne vraiment la route et réservez les serveurs dédiés aux clients qui en ont vraiment besoin. Fred salut Fred, ce que les marketeux appelle bidule Cloud tralala c'est d'une certain façon du mutu pour pro ? Après, sur l'initiative d'OVH (dont je suis aussi client satisfait), c'est tjs mieux que rien que d'installer 10MW d'éoliennes, non ? Pareil pour le transport, je prefere la péniche au semi ! niveau trollage du dredi, la vrai prochaine étape pour rendre l'utilisation des serveurs plus vert, c'est d'abord et avant tout de développer les soft pour qu'ils consomment le moins possible (moins de ressources, moins de cpu, moins de chaleur, moins d'usure ... == moins d'edf, moins de renouvellement de parc, ... ;) had--- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] DC-DC ATX
Le 18/03/2011 18:31, David Touitou a écrit : - Mail original - Le 18/03/2011 17:29, frede...@perrod.org a écrit : Arnaudaberming...@corp.free.fr a écrit : Peut être en mettant un transfo/alim par baie pour convertir le 220V en +12V, - 12V, +5V, -5V et 0V et servir directement les composants de chaque serveur avec les connecteurs normalisés qu'on connait bien ou un bus d'alim en fond de baie. Intérêt ? Tu crois vraiment que tu va consommer moins comme ca? :) Ca se fait chez des gros (en 12V) : http://perspectives.mvdirona.com/2011/02/20/DileepBhandarkarOnDatacenterEnergyEfficiency.aspx C'est bien ce que je dis :) Syndrome du Demain, j'fais pareil sans trop réfléchir :) --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re : [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo
De toute façon, si on conjugue le côté écolo-et-c'est-bien-pour-la-planète-et-pour-nous-par-la même-occasion et l'argent que l'on peut économiser et mettre ailleurs, forcément on s'y intéresse ! C'est la seule façon envisageable pour faire adhérer les entreprises et particuliers. http://router-ecologique.blogspot.com/ L'écologie appliquée aux Réseaux et Télécommunications De : hadrien hadr...@cap270.com À : Yohann QUINTON yoh...@live9.fr Cc : frnog@frnog.org frnog@FRnOG.org Envoyé le : Ven 18 mars 2011, 20h 24min 04s Objet : [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Trolldi : OVH, Ikoula et l'écolo pipo ;-) ça me fait rire, mais en même temps, je suis très sérieux le greenIT (whaou, du marketing ?) à mon sens, c'est réellement de consommer le moins de ressources possibles (software) pour utiliser le moins de matos possible, et avoir moins de factures. C'est écolo et économe, bref, c'est logique. Coté hardware, pareil. ça optimise un max du coté mobile (arm), il est temps *de faire mieux* coté server co. dans la situation actuelle, on peux raisonnablement imaginer que l'énergie coutera de plus en plus cher. l'économiser, c'est green et économe. c'est stratégique pour DC ! had Le 18 mars 2011 à 14:02, Yohann QUINTON a écrit : trollons trollons ;-) On va vraiment devoir se passer de la sur-couche JAVA qui bouffe des ressources pour masquer l'incompétence de quelques devs ? si seulement c'était envisagé je signerai pour le Green-IT tout de suite. Le 18/03/11 13:43, hadrien a écrit : Le 18 mars 2011 à 13:30, Frédéric VANNIÈRE a écrit : Donc, OVH, Ikoula et les autres, si vous voulez vraiment faire de l'écologique, proposez de l'hébergement mutualisé qui tienne vraiment la route et réservez les serveurs dédiés aux clients qui en ont vraiment besoin. Fred salut Fred, ce que les marketeux appelle bidule Cloud tralala c'est d'une certain façon du mutu pour pro ? Après, sur l'initiative d'OVH (dont je suis aussi client satisfait), c'est tjs mieux que rien que d'installer 10MW d'éoliennes, non ? Pareil pour le transport, je prefere la péniche au semi ! niveau trollage du dredi, la vrai prochaine étape pour rendre l'utilisation des serveurs plus vert, c'est d'abord et avant tout de développer les soft pour qu'ils consomment le moins possible (moins de ressources, moins de cpu, moins de chaleur, moins d'usure ... == moins d'edf, moins de renouvellement de parc, ... ;) had--- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
