(linux) Loadbalancer met Virtual MAC (VRRP)

[Exhar]

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:

code:

 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!

[CyBeR]

Je kunt dit op twee manieren doen:
• Bij het failoveren stuur je een zogenoemde Gratuitous ARP.
• Je gebruikt VRRP.

De eerste houdt in dat je bij het failoveren niet alleen het IP op brengt, maar ook een ARP stuurt voor je IP-adres. Dat is een vrij algemeen geaccepteerde techniek om routers op de hoogte te brengen van IP-adreswijzigingen.

De andere optie, VRRP, zou je gebruiken in plaats van keepalived. Met VRRP gebruik je een virtueel IP-adres én een virtueel MAC-adres. Op het moment dat VRRPd op je slave-server vervolgens door heeft dat de master kwijt is, zet 'ie zowel het IP-adres als het MAC-adres aan. Dat is precies zo bedacht om jouw probleem te voorkomen.

[Exhar]

Ah, dat had ik moeten vermelden!

Gratuitous ARP requests doen we al, maar met 1500 IP's die op deze 2 LB's gebind zijn kost dat de nodige tijd (anders gaat de SW-colo-1 bokken ivm. flooding). Overigens lijkt dit ook niet helemaal lekker te werken door de instellingen op sw-colo-1 / 2.

Keepalived bind op dit moment dus 1500 IP's, ik was in de veronderstelling dat VRRP meer iets als HSRP was, voornamelijk voor 1 IP/gateway oplossingen...

[jant]

Ik weet niet hoe 'vast' je aan linux zit, maar ik heb wel eens een test setupje gedraait met freebsd, pf, pfsync en CARP waarmee je van de ene lb naar de andere lb kunt overgaan zonder connectie verlies. Zie http://www.countersiege.com/doc/pfsync-carp/ . Misschien het onderzoeken waard.

[Kabouterplop01]

Waarom vraag je dat niet aan de beheerder van die 6500's? Die kunnen voor jou hrsp bouwen; kost je voor de in jouw tek 11 ip adressen + de vlan/L3 routering. (Heb je niet zo'n last met flooding en werkt het naadloos,
Overigens wat voor een type failover is dat? ( je kunt ook een interface down zetten, of een draadje trekken)

[CyBeR]

Exhar schreef op maandag 18 oktober 2010 @ 22:08:
Ah, dat had ik moeten vermelden!

Gratuitous ARP requests doen we al, maar met 1500 IP's die op deze 2 LB's gebind zijn kost dat de nodige tijd (anders gaat de SW-colo-1 bokken ivm. flooding). Overigens lijkt dit ook niet helemaal lekker te werken door de instellingen op sw-colo-1 / 2.

Keepalived bind op dit moment dus 1500 IP's, ik was in de veronderstelling dat VRRP meer iets als HSRP was, voornamelijk voor 1 IP/gateway oplossingen...

Ja, dat klopt ook wel redelijk maar je zei er in het begin ook niet bij dat je 't over 1500 ip's had

Maar ja, dan is 't waarschijnlijk het simpelst om gewoon het MAC-adres ook virtueel te maken (a la vrrp) en dat mee te nemen bij een failover.

[Exhar]

jant schreef op maandag 18 oktober 2010 @ 22:21:
Ik weet niet hoe 'vast' je aan linux zit, maar ik heb wel eens een test setupje gedraait met freebsd, pf, pfsync en CARP waarmee je van de ene lb naar de andere lb kunt overgaan zonder connectie verlies. Zie http://www.countersiege.com/doc/pfsync-carp/ . Misschien het onderzoeken waard.

Redelijk vast, er zit heel wat tooling om keepalived en ipvs. Ik zou natuurlijk 2 bakken voor de LB's kunnen plaatsen die CARP doen...

Kabouterplop01 schreef op maandag 18 oktober 2010 @ 22:36:
Waarom vraag je dat niet aan de beheerder van die 6500's? Die kunnen voor jou hrsp bouwen; kost je voor de in jouw tek 11 ip adressen + de vlan/L3 routering. (Heb je niet zo'n last met flooding en werkt het naadloos,
Overigens wat voor een type failover is dat? ( je kunt ook een interface down zetten, of een draadje trekken)

En dan? HSRP aan de 6500 kant zorgt er alleen voor dat er bij een failover van de 6500's er aan mijn kant niets gebeurd (uitgaande gateway IP blijft hetzelfde). Of zit ik fout?

CyBeR schreef op maandag 18 oktober 2010 @ 22:53:
[...]
Ja, dat klopt ook wel redelijk maar je zei er in het begin ook niet bij dat je 't over 1500 ip's had

Maar ja, dan is 't waarschijnlijk het simpelst om gewoon het MAC-adres ook virtueel te maken (a la vrrp) en dat mee te nemen bij een failover.

Sorry, had ik moeten melden ja

My idea, alleen loop ik dus tegen een linux kernel limitatie aan: VMacs aren't supported... Ik ga eens ruiken aan CARP

[Bloodshot]

Helaas kan ik je hier niet mee helpen. Ik kan je slechts het advies geven om, als er budget is, over te stappen naar een dedicated loadbalancer-oplossing zoals een Cisco 11500-series of opvolger (ASA meen ik) of een F5 Big-IP opstelling. Succes

[Exhar]

Budget is er wel voor 'n oplossing. Echter, de loadbalancers die we nu hebben kosten op jaar basis qua licenties niets.

Onderhoudtechnisch is geautomatiseerd. Om naar een dedicated loadbalancer appliance over te stappen gaat dus niet werken. Overigens, als ASA's dit kunnen is dat absoluut een oplossing.

Punt is dat ik niet kan vinden op de ASA's 't kunnen en 'ff' testen lukt niet zomaar

[Bloodshot]

Wij gebruiken Cisco 11500's en die kunnen zelfs statefull failover tussen de loadbalancers aan.
Let wel: Ik heb alleen ervaring met ~50 services, geen 1500. Maar wellicht dat een ASA-expert je hier meer over kan vertellen.

F5 Big-IP's heb je van klein tot groot. Ik verwacht dat die het zeker kunnen. Echter ben ik nog bezig met de opleiding, en heb nog niet genoeg kennis om dit uit ervaring te kunnen bevestigen.

[DGTL_Magician]

Een Cisco ASA is geen loadbalancer en kan dit dus niet. Ik heb zelf veel met Citrix gedaan en doe tegenwoordig veel met Radware AppDirectors. Deze kunnen allebei HSRP/VRRP met virtual MAC en zouden je van je probleem af kunnen helpen.

[Exhar]

Een Radware AppDirectors is ook een loadbalancer. Op zich geen punt, maar de 2 LB's die we hebben staan draaien echt goed. Never change a winning team.

Ze kosten nu qua licenties 0,0 en 't zijn 2 'reguliere' servers. Als VRRP het enige + punt is van een dergelijke appliance (en dat is het, we missen nu niets op onze LB's behalve VRRP) zal ik daar natuurlijk geen budget voor loskrijgen.

De ontwikkel-uren die nodig zijn om een dergelijke setup opnieuw op te bouwen op basis van bijvoorbeeld Radware AppDirectors is zo hoog (we hebben 't over 1500 IP's, 25 clusters achter de LB's en vele duizenden sites) dat een setup met BGP, PI en 6504's goedkoper is. (hardware zit dan rond de 33K nieuw, maar daar kunnen dan veel meer dingen mee gerealiseerd worden zoals bijvoorbeeld HA over meerdere DC's).

Oftewel: er is zo'n 6K budget en 't moet relatief simpel te implementeren zijn. Een radicale wijziging zoals 2 Radware AppDirectors is dus niet echt te doen. 2 bakken met VRRP: geen punt. Een appliance die alleen dit doet voor 6K? No problemo...

Tot nu toe kom ik niet echt heel veel goede dingen tegen... Misschien 2 transparante firewalls die VRRP op de externe eth-poorten kunnen? (geen echte VRRP dus..) Anders zie ik als optie een 'arp proxy', maar dat maakt het relatief moeilijk qua beheersbaarheid ben ik bang.

[Rolfie]

Exhar schreef op dinsdag 19 oktober 2010 @ 22:35:

Oftewel: er is zo'n 6K budget en 't moet relatief simpel te implementeren zijn. Een radicale wijziging zoals 2 Radware AppDirectors is dus niet echt te doen. 2 bakken met VRRP: geen punt. Een appliance die alleen dit doet voor 6K? No problemo...

Tot nu toe kom ik niet echt heel veel goede dingen tegen... Misschien 2 transparante firewalls die VRRP op de externe eth-poorten kunnen? (geen echte VRRP dus..) Anders zie ik als optie een 'arp proxy', maar dat maakt het relatief moeilijk qua beheersbaarheid ben ik bang.

Volgens mij kan je met carp ongeveer precies wat je wilt. OpenBSD heeft een goede IP stack, dus zou voldoende performance moeten kunnen bieden. pf is ook niet heel erg lastig te leren dus dat zou ook niet heen heel groot probleem moeten zijn. Een test case / POC zou je snel en gemakkelijk moeten kunnen opbouwen. Op basis van 1500, is wel wat lastig te testen. En BSD is een volwassen systeem, en juist OpenBSD zit erg in de IP omgeving met hun eigen deamons voor OpenBGPD

PF: The OpenBSD Packet Filter
PF: Firewall Redundancy with CARP and pfsync

Of het precies iets is wat je zoek, tja dat kan ik niet beoordelen. Maar volgens mij is het zeker iets wat je zou kunnen onderzoeken. Het is een vorm van Linux, dus er is al een redelijke kennis. Kost niet veel behalve tijd. En 2 goede doosjes kosten ook niet zoveel meer. Voor 6K kan je daar wel een paar leuke machinejes voor aanschaffen die de load aan zouden moeten kunnen.

[Voor 19% gewijzigd door Rolfie op 19-10-2010 22:59]

[DGTL_Magician]

Exhar schreef op dinsdag 19 oktober 2010 @ 22:35:
Een Radware AppDirectors is ook een loadbalancer. Op zich geen punt, maar de 2 LB's die we hebben staan draaien echt goed. Never change a winning team.

Ze kosten nu qua licenties 0,0 en 't zijn 2 'reguliere' servers. Als VRRP het enige + punt is van een dergelijke appliance (en dat is het, we missen nu niets op onze LB's behalve VRRP) zal ik daar natuurlijk geen budget voor loskrijgen.

De ontwikkel-uren die nodig zijn om een dergelijke setup opnieuw op te bouwen op basis van bijvoorbeeld Radware AppDirectors is zo hoog (we hebben 't over 1500 IP's, 25 clusters achter de LB's en vele duizenden sites) dat een setup met BGP, PI en 6504's goedkoper is. (hardware zit dan rond de 33K nieuw, maar daar kunnen dan veel meer dingen mee gerealiseerd worden zoals bijvoorbeeld HA over meerdere DC's).

Oftewel: er is zo'n 6K budget en 't moet relatief simpel te implementeren zijn. Een radicale wijziging zoals 2 Radware AppDirectors is dus niet echt te doen. 2 bakken met VRRP: geen punt. Een appliance die alleen dit doet voor 6K? No problemo...

Tot nu toe kom ik niet echt heel veel goede dingen tegen... Misschien 2 transparante firewalls die VRRP op de externe eth-poorten kunnen? (geen echte VRRP dus..) Anders zie ik als optie een 'arp proxy', maar dat maakt het relatief moeilijk qua beheersbaarheid ben ik bang.

Een Citrix Netscaler is ook een loadbalancer. Ik heb veel gewerkt met zowel Loadbalance appliances als met software loadbalancers.

Als je je huidige setup niet wilt veranderen en alleen wilt uitbreiden met een VRRP achtige oplossing dan lijkt me CARP een prima oplossing. Transparante firewalls gaan je probleem niet oplossen, je blijft een ARP timeout houden bij failover.

[Bloodshot]

DGTL_Magician schreef op dinsdag 19 oktober 2010 @ 16:50:
Een Cisco ASA is geen loadbalancer en kan dit dus niet.

Je hebt gelijk. Ik heb het net even nagekeken: Ik bedoelde een Cisco ACE.

[TrailBlazer]

Bloodshot schreef op dinsdag 19 oktober 2010 @ 09:55:
Wij gebruiken Cisco 11500's en die kunnen zelfs statefull failover tussen de loadbalancers aan.
Let wel: Ik heb alleen ervaring met ~50 services, geen 1500. Maar wellicht dat een ASA-expert je hier meer over kan vertellen.

F5 Big-IP's heb je van klein tot groot. Ik verwacht dat die het zeker kunnen. Echter ben ik nog bezig met de opleiding, en heb nog niet genoeg kennis om dit uit ervaring te kunnen bevestigen.

En ACE appliance kan tot 1024 virtual servers aan. Mischien kan de ACE module er meer aan alleen dan heb je wel meteen een ander prijskaartje te pakken.

[Bl@ckbird]

Voornamelijk door de catalyst 6500 switch die er omheen gebouwd wordt.
Er zijn wel bundels verkrijgbaar van een 6500 switch met ACE module. ( WS-C6504E-ACE20-K9 )
Performance krijg je door de juiste licentie te nemen op de hardware. ( 0,5 tot 16 Gbps ) Dit zijn permanente, éénmalige licenties.

Datasheet ACE appliance / Config Guides.
Datasheet ACE module voor de Cat6500 / Config Guides.
http://www.cisco.com/go/ace

De ACE heeft geen jaarlijks terugkerende kosten, behalve misschien een Smartnet support contract.
Je zou naar een basic Smartnet kunnen kijken met Next Business Day replacement.
Je kan dan in ieder geval configuratie vragen / problemen escaleren bij Cisco TAC.

CSS11500 is de oude content switch en deze is opgevolgd door de ACE.
De ASA is een firewall / VPN platform en is de opvolger van de PIX / VPN Concentrator.

[Tomsworld]

Bl@ckbird schreef op woensdag 20 oktober 2010 @ 21:35:
Voornamelijk door de catalyst 6500 switch die er omheen gebouwd wordt.
Er zijn wel bundels verkrijgbaar van een 6500 switch met ACE module. ( WS-C6504E-ACE20-K9 )
Performance krijg je door de juiste licentie te nemen op de hardware. ( 0,5 tot 16 Gbps ) Dit zijn permanente, éénmalige licenties.

Datasheet ACE appliance / Config Guides.
Datasheet ACE module voor de Cat6500 / Config Guides.
http://www.cisco.com/go/ace

De ACE heeft geen jaarlijks terugkerende kosten, behalve misschien een Smartnet support contract.
Je zou naar een basic Smartnet kunnen kijken met Next Business Day replacement.
Je kan dan in ieder geval configuratie vragen / problemen escaleren bij Cisco TAC.

CSS11500 is de oude content switch en deze is opgevolgd door de ACE.
De ASA is een firewall / VPN platform en is de opvolger van de PIX / VPN Concentrator.

ACE licenties zijn basis 4 Gbit (upgrade naar 8 en 16 mogelijk en clustering tot 4x16Gbit)

[Bl@ckbird]

Dat is voor de ACE module i.s.m. de 6500.
Voor de ACE appliance zijn er ook licenties met een lagere throughput
( Standaard is 0,5 Gbps, 4Gbps is de max. )

[axis]

Post je vraag ook eens op pacemake mailing list. Er zitten daar een boel knappe koppen op het gebied van netwerkfailover die je wellicht wel wat inspiratie kunnen geven.

Ik ben zelf nu langzaam aan aan het overstappen van FreeBSD+Carp naar CentOS+pacemaker (op de corosync(=openais) cluster stack). Maar geen ervaring met meer dan 10 vip's