Re: [FRnOG] extension de Vlans

[Radu-Adrian Feurdean]

On Mon, 17 Oct 2011 22:02:11 +0200, "Guillaume Barrot"
 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: [FRnOG] extension de Vlans

[Guillaume Barrot]

>
>
>
> Hein ? moi pas comprendre . toi trouver le firewall 10Gbps
> wire-speed ? (deja le N x 1Gbps *wire-speed* pour un firewall .. )
>
>
Alors sur ce sujet particulier, j'ai eu l'occasion de tester reellement un
firewall N x 10G wirespeed avec des paquets de 64 ...
Donc, ca existe maintenant, en vrai de vrai ! :D

Re: [FRnOG] extension de Vlans

[Radu-Adrian Feurdean]

On Mon, 17 Oct 2011 16:03:34 +0200, "michel hostettler"
 said:

> 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).

Justement. Il n'est pas etendu au niveau transport pour des bons
raisons, et c'est un peu pour les meme raisons qu'il ne faut pas abuser
dans tous les sens des fonctionalites que le transport peut offrir.
Il y a certes des cas ou l'extension L2 prends tout son sens, voire meme
c'est un pre-requis, mais ces cas restent assez rares.
Ce que je suis en train de critiquer (et il semblerait que je ne suis
pas seul) c'est : un reseau plat de N00+ (N centaines, voire milles)
devices repartis de facon quasi aleatoire sur W sites (plusieurs,
parfois allant jusqu'a plus d'une dizaine).

OK, je peux comprendre qu'il y a reseau et reseau. Que chez certains ces
architectures delirantes servent uniquement pour les besoins internes.
Mais chez d'autres (et j'en fais partie), les services heberges sur ces
reseaux sont vendus aux clients (parfois/souvent avec un SLA) et que
"reseau down/titsup" = "no incoming $$$". J'ai un forte conviction que
les gens "allergiques" au L2 etendu travaillent sur ce dernier type de
reseaux.

> 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.

Mais c'est exactement ce que certains demandent ! Voir plus haut. Pas
seulement qu'on me demandait de joindre deux subnets se trouvant a ~1000
km / ~25-30 ms distance, mais en toute conaissance de cause on me
demandait de "joindre" deux VLANs ToIP !!!

> 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.

Resume : "ils" n'arrivent pas a comprendre le subnetting IP, et vous
etes en train de (leur) trouver des solutions encore moins evidentes a
comprendre.

> > ...la securite
> > s'approche de zero et les performances  
> Bigre ! quel doux mélange.

Hein ? moi pas comprendre . toi trouver le firewall 10Gbps
wire-speed ? (deja le N x 1Gbps *wire-speed* pour un firewall .. )
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] extension de Vlans

[michel hostettler]

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

[Alexis Savin]

Bonjour,

Je crois que ce débat est amené à être abordé de plus en plus souvent, et
que nous sommes tous plus ou moins mal armé face à lui. Je profite donc de
l’occasion pour échanger avec vous et avancer mon point de vu.

Je dois avouer que la première fois que j'ai entendu parler d'un réseau L2
étendu et de vlan multi-site, j'ai été pour le moins abasourdi. Mes
arguments contre n'étaient, et ne sont d'ailleurs toujours pas, les
meilleurs.

Mais au delà de l'aberration que cela peut représenter pour tout ingénieur
réseau, il faut bien discerner que cela correspond à un besoin des équipes
systèmes, besoin clairement résumé dans les emails précédents.

Alors, dans un premier temps, quelques arguments et réflexions plus ou moins
libres :

Oui, il est techniquement très simple et relativement peu couteux de
déployer une fibre noire entre 2 Data Centres Parisien. Oui, le DWDM et
uDWDM, c'est très sympathique et ça réduit considérablement le coût du Giga
de bande passante. Reste qu'en assurer la redondance, c'est déjà plus cher
et plus compliqué. Enfin, en termes de flux, je considère que c'est une
horreur. Gérer ne serait-ce que la passerelle par défaut et localiser les
flux sortant par Data Centre est compliqué et difficilement maintenable à
mon goût. Le trafic circulant sur le man L2 devient dès lors rapidement
important...

Par ailleurs, certains ont mis des années à concevoir des bonnes pratiques
réseau/infra. Notamment pour éviter la congestion. Sous prétexte que la
bande passante est plus importante, doit-on remettre en cause ce que la
pratique et l'expérience ont mis des années à faire évoluer et reproduire
dans quelques années les mêmes erreurs que part le passé pour rencontrer un
jour les mêmes problèmes ?

Et enfin, une réflexion peut être un peu plus construite :

Le besoin initiale : assurer la continuité d’un service.
Deux cas apparents : serveurs physiques/mainframes VS serveurs virtuels

Dans le premier, tout peut être dit, je vois mal en quoi un vlan étendu
apporte une solution. Déployer un cluster (restons simple, actif/passif)
nécessite bien de remettre les mains dans la configuration et/ou le code.
Dès lors, assurer une redondance avec des techniques classiques ne pose plus
de problème. Au pire, s’il en subsiste un, il existera toujours des
alternatives plus ou moins propres (IPV4 : DNS/NAT ; IPV6 : DNS/Anycast).
Dans tous les cas, l’argument qui est avancé : déplacer simplement le
serveur d’un site à l’autre m’amuse terriblement. J’imagine tout à fait 2
techniciens déplacer à la volée une quarantaine de serveurs en pleine nuit
tout en assurant le RTO souhaité.

Dans le deuxième cas, celui des VMs, je suis désolé, mais des logiciels
comme SRM et les scripts adaptés répondent parfaitement au besoin initial
d’assurer la continuité du service en mode PRA.

Le seul cas où je trouve un réel intérêt au VLAN étendu relève du
metro-cluster. Qui est manifestement tellement or de prix pour la plus part
de nos clients que la solution n’est évoquée que du bout des lèvres. Dans ce
cas cependant, des solutions existent bien pour ne pas impacter le cœur de
réseau avec un vlan étendu. Elles consistent à isoler ces vlans un peu «
batards » sur des infrastructures dédiées pour ne les propager ensuite qu’à
travers des environnements cloisonnés VPLS ou bien 802.1q tunneling.

Bref, si vous avez réussi à trouver la "killer" réponse qui clos le sujet,
je suis preneur.

Bien cordialement.


2011/10/17 Radu-Adrian Feurdean 

>
> On Sat, 15 Oct 2011 20:55:05 +0100 (BST), "Surya ARBY"
>  said:
>
> > 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
>
> Pour commencer avec le commencement parce-que L2 = Link layer.
> Ce n'est pas le role du L2 de gerer un reseau etendu.
> Et ce n'est pas parce-que c'est possible qu'il faut le faire ou que
> c'est une bonne idee.
>
> J'entends d'un cote des gens qui doivent faire tourner que des
> "systemes" et dont le reseau les emmerde plus qu'autre chose. J'ai
> l'impression que c'est souvent eux qui revent a l'extension L2. Et ca va
> parfois *BEAUCOUP* trop loin. 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.
>
> Et apres il y a les autres, qui doivent construire les reseaux, les
> garder en etat de marche, assurer les performances, et pour c

Re: [FRnOG] extension de Vlans

[Radu-Adrian Feurdean]

On Sat, 15 Oct 2011 20:55:05 +0100 (BST), "Surya ARBY"
 said:

> 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

Pour commencer avec le commencement parce-que L2 = Link layer.
Ce n'est pas le role du L2 de gerer un reseau etendu.
Et ce n'est pas parce-que c'est possible qu'il faut le faire ou que
c'est une bonne idee.

J'entends d'un cote des gens qui doivent faire tourner que des
"systemes" et dont le reseau les emmerde plus qu'autre chose. J'ai
l'impression que c'est souvent eux qui revent a l'extension L2. Et ca va
parfois *BEAUCOUP* trop loin. 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.

Et apres il y a les autres, qui doivent construire les reseaux, les
garder en etat de marche, assurer les performances, et pour certains
pire encore, assurer la securite. Et la les choses commencent a mal
tourner. Le Grand Reseau Plat (c)(tm) se transforme en SPOF, la securite
s'approche de zero et les performances  bon disons qu'avoir
plusieurs liens a l'interieur d'un site n'est pas exactement le meme
chose qu'avoir plusieurs liens entre sites distants

> Pas mal de constructeur poussent le L2 suite à la pression des applis.

Ahhh, les applis et leurs developpeurs... il y en a certains (pas tous,
probablement meme pas tres nombreux) qui devait avoir interdiction de
toucher du materiel IT. Faire des suppositions sur comment le reseau
marche en ayant uniquement une vision de son reseau chez lui (3 PC et un
switch type netgear), puis appliquer ca sur un reseau geographiquement
disperse, je vois tres bien comment on est arrives a des choses
foireuses

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: Re : [FRnOG] extension de Vlans

[Guillaume Barrot]

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 
wikisur
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  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

Re : [FRnOG] extension de Vlans

[Surya ARBY]

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épo

Re: [FRnOG] extension de Vlans

[Guillaume Barrot]

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  a écrit :

> Salut la ML.
>
> Je souhaite rebondir sur

[FRnOG] extension de Vlans

[Surya ARBY]

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 ?