Salut. Mes réponses inline.
> D’expérience l’idée arrive dans une réflexion type PRA/PCI dont > le déclencheur serait (au choix) :[...] > bref, on imagine le scénario du pire (probabilité 1/10E beaucoup), et on > essaye de trouver LA parade, et la, le VLAN étendu arrive au galop car la > finance s'en mêle, et qu'il est toujours plus facile d'avoir un cluster de > base de données sur deux sites, que deux clusters avec de la synchro de > stockage. Je pense plutôt à l'arrêt électrique complet sur un site, certains grands comptes ont eu le problème > Principe de base du coup, avant d'essayer de faire une architecture de > Datacenter résiliente au crash d'avion, commencer par faire un > Datacenter résilient a l'erreur humaine (le Datacenter "exploitation-proof"). Effectivement je suis assez d'accord qu'il y a pas mal de problèmes liés à l'exploitation via des contrats d'infogérance avec principalement des juniors envoyés au charbon et un turn over extrêmement important > Un cluster de base de données, par définition, partage la même donnée car il > voit un stockage cohérent ... a un certain temps de synchro prés.[...] > Par contre si je corromps ma donnée sur le site 1, elle > est instantanément corrompu sur le site 2. Et malheureusement, ça arrive > beaucoup plus souvent que l'avion sur le parking. Faut pas se tromper de débat, pour ça y a les sauvegardes :-) > Maintenant, y a l'existant, et des trucs aussi gros que des clusters de base > de données bancaires ne vont pas evoluer pour s'adapter a > l'architecture réseau, c'est au réseau de s'adapter. > Et la, financièrement, on pourra toujours te prouver qu'un vlan étendu c'est > moins cher qu'une refonte de code, ou que d'exploiter du LISP pour bouger des > VMs.... Jusqu'au premier crash. Parfois c'est simplement pas possible (mainframe adressé en ip statique il y a des années, scripts non maitrisés avec adresses en dur partout et le mec qui les a développé plus là depuis des mois, refonte de code sur système propriétaire nécessitant l'intervention de l'éditeur, voire code source perdu !!) > Personnellement, juste l’année dernière, j'ai vu des Datacenters dans le noir > a cause de boucle spanningtree, de serveurs pinguant la 224.0.0.2 avec un ttl > = 1 (IPMP chez Sun), ou d'interop Cisco = Alcatel qui marche pas aussi bien > que sur les slides... > Je suis juste content qu'on ait perdu qu'un Datacenter a chaque fois, ce qui > est déjà énorme, et qui aurait pu être évité avec un cloisonnement du > datacenter en plusieurs zones de niveau 2 (topologie core - distrib - access). Perso je crois assez aux technos émergentes sous réserve qu'elles soient maitrisées (on en revient aux problèmes d'exploitation) > Pour VMWare, problème résolu en discutant avec les premiers concernés : long > distance VMotion non supporte si tu n'es pas sur LA technologie du partenaire > (Cisco). > Et après en interne, tu apprends que ca, c'est du politique, et que les inge > VMWare te le déconseillent fortement. Perso j'ai jamais eu à traiter des distances de ce type là (150 / 200 kms) mais plutôt des distances de type MAN (région parisienne) > SRM est un outil de scripting pour du PRA/PCI pour le coup, base sur le > principe que lors de la perte d'un datacenter 1, tu redémarres une partie de > l'infra a distance, en modifiant les configurations a > la volée (ré-écriture du .vmx des VMs par exemple) SRM pour moi pose 2 problèmes : pas de support de tous les OS (windows uniquement en Vsphere 4 à ma connaissance) + changement d'IP donc adhérence à la configuration des DNS > Bref, si ton besoin est de faire un seul datacenter logique sur deux sites > physiques distants, alors bien sur, vlan étendu et autres joyeusetés (VPLS, > OTV, TRILL, ce que > tu veux, juste après tu essaieras de nous expliquer ou > se situe la gateway de ton vlan, et comment tu optimises ton > trafic inter-sites, qui en général n'est pas gratuit. A part > GLBP en v4, et > des annonces nd bien tunees en v6, je ne vois pas comment s'en sortir, et > encore c'est pas simple). Sur le niveau 2 étendu, au niveau des points de sortie des petites ACL qui interdisent la sortie des Hello de ton protocole de redondance (HSRP / VRRP) permettent de laisser l'élection de la gateway toujours sur le site local, ça évite les yoyo pour du trafic inter-site > Maintenant, sois juste bien conscient que tu n'as QU'UN site logique, et que > donc si tu veux gérer un PRA/PCI, il t'en faut un deuxième (voire > un deuxième couple de sites physiques) Je suis assez d'accord > non, tu ne peux pas gérer une véritable continuité de services avec du > vlan étendu. Là moins, réplication synchrone -> pas de perte de transaction, L2 étendu -> pas d'adhérence au DNS, c'est un fait pas une vue de l'esprit :) Autant l'adhérence au DNS ne me dérange pas plus que ça pour de l'interne, autant sur Internet aujourd'hui il y a un vrai problème avec des providers qui cachent les réponses, certains sans limite de durée. Après le truc intéressant serait de savoir quel est le taux de désastre du au L2 rapporté au nombre de clients qui pratique massivement l'extension de Vlans :) Est-ce plus l'exception que la règle ? :) Et pour répondre a la remarque évidente que "si le vlan étendu c'est mal, alors pourquoi les constructeurs s'acharnent a sortir des solutions d'extension de niveau 2 ?", je dirai juste : "quand y a un con qui est prêt a acheter, moi je vends, c'est un principe. Y a toujours deux solutions a un problème !" (de mémoire, Kaamelott) Finalement, est-ce le rôle du réseau de fournir des contraintes aux gens systèmes ou faut-il rendre le service demandé à tout prix ? Sachant qu'avec la première solution, le risque qu'ils aillent se faire héberger ailleurs est non négligeable... Le 15 octobre 2011 21:55, Surya ARBY <arbysu...@yahoo.fr> a écrit : Salut la ML. > >Je souhaite rebondir sur un point d'un message envoyé hier à propos de >l'extension de Vlan (dans le sujet LISP), pourquoi beaucoup de gens haïssent >l'extension de VLan ? > > >Perso je suis plutôt (voire même très) en faveur du L2 étendu dans les >environnements datacenters pour la souplesse que ça apporte : > > >- en cas de déménagement pas de réadressage des machines >- capacité à faire du Vmotion intersite (je dis pas que ce soit forcément >intelligent mais beaucoup de gens systèmes le demande, ils préfèrent utiliser >ça que VMWare SRM) > >- abstraction des problèmes DNS liés au GSLB (dans sa version DNS donc) : >problème de non respect des TTLs et cache négatif... >- clusters étendus divers pour le côté client - la VIP (IBM, HP, Veritas, >Oracle RAC, [rajouter ici les 50 fournisseurs de clusters applicatifs qui >nécessitent du L2 pour être stateful] même NLB soyons fous) aussi bien que >pour les liens privés pour les heartbeats qui parfois nécessitent des >adjacences L2 directes car le protocole de heartbeat n'est même pas basé sur IP > >- arrivée de FCoE en dehors des DCs (sur certaines plateformes FCoE est >supporté sur des distances de type MAN), FCoE est par définition non routable > >Certes à part dans le cas de déménagement, l'extension de Vlans longue >distance nécessite l'extension du stockage (pour les clusters / Vmotion), et >dans ce cas les distances se réduisent (une centaine de kms max) à cause des >contraintes dues au stockage. > >Pour quoi la plupart des gens détestent-ils l'extension L2 ? > >À cause de l'extension STP ? Y a plein de technos qui suppriment ce risque : >régions MSTP (sauf pour l'instance 0), etherchannel distribué (style Cat6500 >VSS ou équivalent en étoile qui supprime toute boucle logique intersite), >EoMPLS / VPLS etc... qui permettent de limiter le domaine STP à un site unique >sans l'étendre sur ses voisins > >Associé à ça y a du storm-control pour limiter les soucis, en plus y a pas mal >de technos émergentes qui permettent de venir sur des technos routées au >niveau 2 :Trill et son TTL, 802.1aq shortest path bridging qui est le >concurrent > >Pas mal de constructeur poussent le L2 suite à la pression des applis. > >Des idées là dessus ?
