Aaaaaaaah le niveau 2 étendu... D’expérience l’idée arrive dans une réflexion type PRA/PCI dont le déclencheur serait (au choix) : - l'avion qui s’écrase sur le Datacenter a Roger Gicquel - le tremblement de terre en région Parisienne - la crue centennale de la Seine qui inonderait le Datacenter situe a 50m en dénivelé. 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.
Mais la, deux problèmes : - d’expérience encore, la première cause d'outage de Datacenter, c'est l'erreur humaine. Et celle qui fait le plus de dégât sur Ethernet, c'est bien entendu la connerie qui plante le niveau 2 - c'est mignon d'essayer de parer au cas de panne majeur avec un système qui fait qu'un problème sur le site 1 se propage instantanément sur le site 2. 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"). Sur le second point, ça va plus loin que le simple vlan étendu. 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. Je connais une superbe solution de réplication de données synchrone sur SAN, qui permet d'assurer d'avoir exactement la même donnée sur deux stockage distant, grâce a un jeu d’écriture en cascade. Sur les slides c'est super. Si un avion vient a s’écraser sur mon site 1, mon site 2 reprend directement la main, sans perte de données. Bien entendu, aux latences, ouvertures de flux, bascule DNS près sur le frontal. 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. Le vlan étendu, c'est le rêve de tout inge système, car finalement il est utilisateur de la couche IP, mais sans forcement bien la comprendre. Quel ingénieur réseau ferait un backbone avec un seul gros vlan de routage ? Pourtant ça marcherait ! Et le problème avec ça, c'est qu'on arrive très vite avec des concepts fumeux de "datacenter virtuel", ou "datacenter étendu" avec la possibilité de cramer deux ou trois sites d'un coup. 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. 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). 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. 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) 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). 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), et que non, tu ne peux pas gérer une véritable continuité de services avec du vlan étendu. 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) 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 ? > -- Cordialement, Guillaume BARROT
