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<mailto: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 XXXXX , 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.com>clement.th...@aciernet.com<mailto: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 40000€ 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.com>rachid.zito...@gmail.com<mailto: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.fr><mailto:fregat...@free.fr>fregat...@free.fr<mailto: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.org<mailto:owner-fr...@frnog.org> [mailto:<mailto:owner-fr...@frnog.org>owner-fr...@frnog.org<mailto: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.org<mailto: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 cœur :) Merci beaucoup Ray
