Le 03/01/2011 11:57, Baptiste Malguy a écrit :
Bonjour,
Bon aller, j'amorce (je crois) la première discussion technique de
l'année.
La version courte pour les pressés : j'aime bien la virtualisation
avec VMWare mais je rencontre quelques limitations côté réseau. le
Nexus V1000 semble être une partie de la solution et je suis à la
recherche de retours d'expérience.
La version un peu plus longue à présent. J'ai deux problèmes à ce jour.
1. J'ai des vSwitch avec le numéro de vlan 4095 (tous les VLANs,
taggués, arrivent jusqu'aux guests connecté à ces vSwitchs). En
revanche, je ne peux pas restreinte les vlans vus par les guests
connectés à ces vSwitch, il n'y a pas d'équivalent à un "switchport
trunk allowed vlan ....". Avoir une interface par vlan sur mes guests
n'est pas une option envisageable (besoin de rebooter pour ajouter une
interface, nombre limité, c'est chiant, etc). Du côté du switch
physique auquel est connecté l'ESX, j'ai bien évidemment déjà mis un
"switchport trunk allowed vlan ...", mais j'ai besoin d'être
granulaire par guest.
Quel est le besoin ? tu as tellement de vlan clients à gérer ? tu ne
peux pas segmenter un peu avec diffèrent vswitch / différentes classes
de vlan ?
D'ailleurs le rajout d'interface à chaud ca fonctionne (au moins sous
linux), et cela me semble gérable jusqu'à 4 interfaces par serveurs.
Après si tu as plus de quatre vlans par serveurs je penses que tu as un
problème d'architecture. (enfin déjà je comprends mal plus de deux).
2. J'ai deux serveurs ESX esx1 et esx2. Sur un esx1 j'ai un guest vm1,
sur esx2 un guest vm2. Ils partagent des VIPs, que ça soit par HSRP,
VRRP, CARP, ... Ce qui implique une adresse MAC virtuelle (ok, ok,
sous Linux, les implémentations VRRP font autrement, plus sale
d'ailleurs, selon moi). Ceci m'oblige à autoriser le mode promiscuous
pour les interfaces concernés sur ces guests. Ceci a un effet de bord
pas du tout désiré : les interfaces de ces guests reçoivent tout le
traffic des vSwitchs concernés. Deux fonctionnalités en une, moi ça
m'arrange vraiment pas.
Je comprends pas le besoin d'être en promiscuous pour faire du HA. Ni le
besoin d'une @Mac virtuelle. Ucarp par exemple fonctionne simplement en
multicast et en floodant d'arp quand ca change. D'ailleurs je vois pas
en quoi c'est sale.
D'expérience les @macs virtuelles (sur les Netscreen ou autres) ca m'a
plus foutu la zone qu'autre chose.
Il y a doit y avoir un point que je ne saisis pas la.
Par conséquent, j'ai :
- un double problème de sécurité ne pouvant pas restreinte les vlans
par guest et les serveurs en promiscuous recevant plein de trafic
qu'ils ne devraient pas ;
- un problème de charge des guests qui reçoivent du trafic qui leur
ait inutile qui remonte jusqu'au noyau de l'OS qui doit dropper les
paquets dont il n'a que faire.
Nexus V1000 semble apporter une réponse à mon premier problème. Je ne
sais pas s'il en apporte aussi une à mon second problème.
Les présentations que j'en ai eu ont effectivement de régler le point
numéro un. En gros tu as un vrai switch manageable sur
ton esx ce qui peut être un vrai plus.
Sinon apparemment tu peux aussi le faire avec le dvswitch (pas testé) =>
http://www.vi-tips.com/2009/07/vlan-trunking-grouping-in-distributed.html
Je suis donc très intéressé par un retour sur le Nexus V1000, et si
certains ont trouvé comment résoudre ces problèmes (j'imagine ne pas
être le premier à les avoir).
Teste la version d'essai 60 jours je suis intéressé par le retour :)
PS : je ne suis pas certain d'avoir été très clair, reformulation
possible sur demande ;-)
--
Baptiste MALGUY - www.malguy.net <http://www.malguy.net>
PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2
--
Raphaël Mazelier
