Le 04/01/2011 10:00, Baptiste Malguy a écrit :
Je virtualise des pare-feux et des load-balancers, et le client, c'est
moi :). C'est un choix architectural qui peut plaire ou pas.
Testé (enfin en prod quand je suis arrivé) et retour arrière :^p. (par
exemple des lvs + heartbeat virtualisé sur vmware = échec complet, du
notamment au fait qu'en virtualisé tu as une clock matérielle nettement
moins fiable). D'une manière générale j'eviterais de virtualiser tout ce
qui a besoin d'IO. Bon mais je ne suis pas complétement objectif car je
suis contre la virtualisation logicielle en production pour un tas de
raisons.
Déjà répondu par Thomas.
Non thomas a dit qu'il ne comprenais pas non plus. Explique.
C'est ucarp qui comble l'incapacité à pouvoir vraiment utilisé une
@mac virtuelle sous Linux (à moins que ça n'ait changé depuis la
dernière fois que j'ai regardé). Le concept d'un couple VIP + VMAC me
semble plus propre qu'un flood ARP. C'est au niveau des tables des
équipements L2 que le changement se voit et non dans les tables ARP de
tous les équipements/serveurs L3 présents sur les mêmes segments. Ca
me semble moins "sale", mais on peut avoir des visions différentes.
Je connais pas de solution d'@Mac virtuelle sous linux. Tu fais comment
? après que ce soit plus propre ou pas je ne sais pas. C'est juste
choisir la technologie qui va poser le moins de problème, et converger
le plus rapidement. En l'occurence effectivement avec une @Mac virtuelle
c'est théoriquement plus rapide. En pratique...
C'est au programme ;-)
Merci.
--
Raphael Mazelier
