Ik ben op zoek naar een oplossing voor het volgende probleem waar ik tegenaan loop.
De volgende setup draait er op dit moment:

LB1 MAC: 00:1E:C9:3E:72:7C
LB2 MAC: 00:1E:C9:3E:74:AC
Beide servers draaien Debian Etch (bezig met Squeeze, maar dat doet er nu niet toe) met IPVS en Keepalived (VRRP) voor de loadbalancing.
Zowel SW-COLO-1 als SW-COLO-2 zijn Cisco 6509's waar ik geen toegang toe heb (colo switches). De arp cache timeout staat op 5 minuten (minimum). Handmatig flushen van deze cache kan ik dus niet doen.
Het probleem waar ik last van heb ik het volgende: als ik een failover van LB1 naar LB2 doe blijven de SW-COLO-1 en SW-COLO-2 al het verkeer nog naar 00:1E:C9:3E:72:7C sturen: dat staat immers in de arp cache. Dit levert een downtime van 5 minuten op: acceptabel tijdens een maintenance window, maar onverwachts absoluut niet.
Op de keepalived mailinglists vind ik wat oude threads waar dit in behandeld wordt en duidelijk wordt dat Linux geen Virtual MAC-adressen support. Natuurlijk kan ik zelf een MAC adres instellen zodra een failover gedaan wordt:
Laten we eerlijk wezen: ontzettend vies en totaal niet handig, ik hoop dus op een andere oplossing.
Er bestaat iets als ARP PROXY wat hiervoor enigszins geschikt lijkt, maar dat zorgt er juist voor dat het geheel ook totaal niet meer managen is in mijn ogen.
Natuurlijk zou ik zelf routing kunnen gaan doen (PI space, BGP, 2 core routers met HSRP), maar voor het verkeer dat er nu over deze 2 loadbalancers gaat (200MBit) is dat nog niet geheel rendabel (+ investering is niet gering). Uiteindelijk zullen we gaan routeren maar liever nu nog niet.
Een andere software oplossing is http://sourceforge.net/apps/trac/vrrpd wat er leuk uit ziet, maar ik heb mijn vraagtekens of dit goed werkt samen met keepalived of dat ik weer 2 servers voor de LB's moet zetten die dit doen... (en: ik kan niet echt vinden of deze implementatie ook vmac doet. De claim dat 't RFC compliant is doet vermoeden van wel. Gelukkig is dat snel uit te vinden door te testen, maar heb ik nog niet gedaan).
Ik ben benieuwd wat voor slimme oplossingen jullie voor dit probleem bedacht hebben / kunnen bedenken!
Hoe lossen jullie dit op?
Meer info nodig: roep maar!
De volgende setup draait er op dit moment:

LB1 MAC: 00:1E:C9:3E:72:7C
LB2 MAC: 00:1E:C9:3E:74:AC
Beide servers draaien Debian Etch (bezig met Squeeze, maar dat doet er nu niet toe) met IPVS en Keepalived (VRRP) voor de loadbalancing.
Zowel SW-COLO-1 als SW-COLO-2 zijn Cisco 6509's waar ik geen toegang toe heb (colo switches). De arp cache timeout staat op 5 minuten (minimum). Handmatig flushen van deze cache kan ik dus niet doen.
Het probleem waar ik last van heb ik het volgende: als ik een failover van LB1 naar LB2 doe blijven de SW-COLO-1 en SW-COLO-2 al het verkeer nog naar 00:1E:C9:3E:72:7C sturen: dat staat immers in de arp cache. Dit levert een downtime van 5 minuten op: acceptabel tijdens een maintenance window, maar onverwachts absoluut niet.
Op de keepalived mailinglists vind ik wat oude threads waar dit in behandeld wordt en duidelijk wordt dat Linux geen Virtual MAC-adressen support. Natuurlijk kan ik zelf een MAC adres instellen zodra een failover gedaan wordt:
code:
1
| ifconfig eth0 down hw ether 00:00:00:00:00:01; ifconfig eth0 up |
Laten we eerlijk wezen: ontzettend vies en totaal niet handig, ik hoop dus op een andere oplossing.
Er bestaat iets als ARP PROXY wat hiervoor enigszins geschikt lijkt, maar dat zorgt er juist voor dat het geheel ook totaal niet meer managen is in mijn ogen.
Natuurlijk zou ik zelf routing kunnen gaan doen (PI space, BGP, 2 core routers met HSRP), maar voor het verkeer dat er nu over deze 2 loadbalancers gaat (200MBit) is dat nog niet geheel rendabel (+ investering is niet gering). Uiteindelijk zullen we gaan routeren maar liever nu nog niet.
Een andere software oplossing is http://sourceforge.net/apps/trac/vrrpd wat er leuk uit ziet, maar ik heb mijn vraagtekens of dit goed werkt samen met keepalived of dat ik weer 2 servers voor de LB's moet zetten die dit doen... (en: ik kan niet echt vinden of deze implementatie ook vmac doet. De claim dat 't RFC compliant is doet vermoeden van wel. Gelukkig is dat snel uit te vinden door te testen, maar heb ik nog niet gedaan).
Ik ben benieuwd wat voor slimme oplossingen jullie voor dit probleem bedacht hebben / kunnen bedenken!
Hoe lossen jullie dit op?
Meer info nodig: roep maar!