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 wiki<http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling>sur 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 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 ? > > -- Cordialement, Guillaume BARROT
