Bonjour,
Il est possible de faire du double attachement de serveur sur deux TOR
distincts, la technologie type MLAG le permet.
Il est possible de faire du PVLAN distribué sur plusieurs équipements chez
certains constructeurs.
Par contre utiliser le parallèle entre token ring et le fonctionnement d'un
stack n'est pas généralisable à toute les techno de stacking.
Fabien
Le 18 mars 2011 à 13:16, Raymond Caracatamatere a écrit :
> 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
>
