Re: [FRnOG] extension de Vlans
Bonjour, Pour quoi la plupart des gens détestent-ils l'extension L2 ? Faites attention au vocabulaire. Le niveau L2 n'est pas du tout étendu au réseau de transport. Dans le réseau de transport, il est possible de créer des connectivités de niveau 3 (par transmission IP), des connectivités de niveau 2 (par transmission ATM, Ethernet avec niveau ETH, MPLS), ou des connectivités de niveau 1 (par transmission OTN, SDH avec niveau OSn, Ethernet avec niveau ETYn). J'entendais il y a qeulques semaines un qui me demandait si c'est possible d'avoir un VLAN de Barcelone dans les bureaux de Paris - WOW, certains n'ont peur de rien. La connectivité de niveau 2 de bout en bout existe depuis quelques années. Non pas avec des VLAN, mais avec des numéros S-VLAN, B-VLAN, et surtout BSI. Une remarque de taille, il faut que les sites soient prédéfinis. Nous sommes en VPN, pas question de surfer de bout en bout. Sinon, il existe aussi des connectivités de niveau 2 partielles. Par exemple, un îlot Ethernet entre 2 réseaux MPLS qui assurent une connectivité de niveau 3. Dans ce cas, les unités MPLS sont encapsulées sur des unités Ethernet, avec recopie des éléments de qualité de l'une sur l'autre. ...la securite s'approche de zero et les performances Bigre ! quel doux mélange. Cordialement, Michel Hostettler --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] extension de Vlans
On Mon, 17 Oct 2011 22:02:11 +0200, Guillaume Barrot guillaume.bar...@gmail.com said: Alors sur ce sujet particulier, j'ai eu l'occasion de tester reellement un firewall N x 10G wirespeed avec des paquets de 64 ... N = ? Et pour combien de ports ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Re : [FRnOG] extension de Vlans
Je ne comprends pas l’adhérence aux DNS. Si c'est le cache DNS qui t'ennuie (et vu de l’hébergeur, c'est le problème du SP ou du client plutôt, pas de l’hébergeur, non ?), Dieu a invente l'anycast et il vit que c’était bien bon parce que c'est du pur routage, donc tu peux même avoir deux sites actifs si tu joues avec les métriques etc. Cf. RHI sur carte ACE, et sur F5 c'est encore plus facile puisque tu tournes Zebos. Sur des serveurs recents c'est meme supporte en natif (ex : Dns/Dhcp Infoblox pour les amateurs de boiboites). Apres pour des frontaux web, si tu ne maîtrises pas le caching sur les clients, je ne vois pas bien ce que tu peux y faire. Même avec la meilleure volonté du monde, tu as toujours des clients sous Win95/IE3, donc est-ce que tu veux gérer ton site web en nivelant par le bas ? Pour le reste, c'est plus philosophique que franchement technique : - est ce que le niveau 2 étendu fonctionne ? Oui. - est ce que c'est stable ? Avec toutes les possibilités de maîtriser ça (EoMPLS, VPLS, OTV, etc.), de plus en plus. - est ce que c'est propre ? Et le c'est philosophique :D Parfois c'est simplement pas possible (mainframe adressé en ip statique il y a des années, scripts non maîtrisé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 !!) C'est toujours faisable, c'est juste complique, donc cher. Au final, tout en revient a comparer financièrement une action et un risque. Je ne sais pas si quelqu'un a une réelle étude financière d'un risque liée au L2 étendu, mais je pense que le coeur du sujet est la : investir dans le système et le dev (refonte d'une archi existante) ou dans l'infra (vlan étendu) ? Et y ajouter les risques associes. Perso je suis convaincu que, a part dans de rares cas (déménagement, sécurisation d'un vieux cluster de BDD existant), le L2 étendu est une fausse bonne idée, et n'est plus obligatoire grâce aux technos récentes. Exemple sur les bases de données. La majorité des gens que je connais et qui utilise postgre ne déploie cette BDD qu'avec un seul mode : slony. Voir le wikihttp://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Poolingsur les différentes méthodes de réplication postgre... il y en a 8, uniquement dans les modes les plus connus. Je ne compte pas le logshipping, ou le clustering type hadoop ! Bref, les solutions existent, elles ne sont juste pas utilises parce que c'est chiant de déployer un truc nouveau, alors que Slony on connait ça depuis 10 ans, ça marche, pourquoi s'emmerder ? Guillaume Le 16 octobre 2011 07:48, Surya ARBY arbysu...@yahoo.fr a écrit : 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
Re: [FRnOG] extension de Vlans
Aaaah 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
