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 >
