Byte && Keepalived – VMac support

Keepalived: High availability, clustering… ‘t Klinkt ons niet onbekend in de oren!

Loadbalancers

Om dat te bereiken, maken we gebruik van loadbalancers: centrale machines aan de rand van ons netwerk die inkomende verbindingen verdelen over de achterliggende servers. Webservers, mailservers, shellservers, databaseservers.. Bedenk het en ‘t loopt via onze loadbalancers.

‘t Is duidelijk: deze machines zijn essentieel voor ons netwerk en zorgen ervoor dat we zo min mogelijk downtime ervaren. Juist om die reden hebben we meerdere loadbalancers die elkaars maatje zijn. Mocht er een (de primary) uitvallen, neemt z’n buddy (secondary) de taken vlekkeloos over en merken onze klanten daar niets van.

Design flaw

Tot nu toe werkt dit perfect. Samen met XS4ALL (onze upstream provider) hebben we een oplossing gebouwd waarmee een failover zo geruisloos mogelijk gaat. In de software van onze loadbalancer (keepalived) zit echter wel een design flaw. Voor ik dat uitleg, even een stukje achtergrond informatie!
De TCP/IP stack is opgedeeld in meerdere lagen. Het OSI-model. Layer 1 is de fysieke laag: bekabeling, netwerkkaarten, et cetera. Layer 2 is de eerste communicatielaag welke gebruik maakt van unieke namen van een netwerkkaart: het MAC-adres. Pas op layer 3 komen IP-adressen in beeld.
By design is het zo dat een IP-adres gekoppeld is aan een MAC-adres; de fysieke aansluiting op het netwerk. Een layer 2 switch zal dus een pakketje ontvangen voor IP-adress 192.168.1.1 en dan in z’n geheugen op zoek gaan naar het bijbehorende MAC-adres. Eenmaal het MAC-adres gevonden, wordt er wederom in het geheugen gezocht om te bepalen waar dit MAC-adres te vinden is – op welke fysieke interface.

Layers

Byte heeft een layer 2 verbinding met XS4ALL. We routeren niets zelf, maar switchen alles. XS4ALL ontvangt die pakketten en zorgt ervoor dat deze verder ‘t internet op gestuurd worden. Hier zit meteen ons probleem. Om de routers van XS4ALL te ontzien, onthouden deze 5 minuten welk MAC-adres bij een IP-adres hoort. Dat heet arp-cache. Als dat er niet zou zijn, zou de XS4ALL router voor ieder pakket eerst moeten vragen aan ons “He, waar moeten pakketten voor IP 46.21.228.1 heen?”. Dat schiet niet op!
Onze loadbalancers staan in directe verbinding met XS4ALL en communiceren dus met de routers. De primary loadbalancer zegt tegen XS4ALL: IP 46.21.228.1 mag naar MAC 78:2b:cb:07:16:a6. De XS4ALL router onthoudt dat en maakt er gebruik van.
Onderling praten onze loadbalancers constant tegen elkaar en weten welk van de 2 verantwoordelijk is voor welk IP-adres. Zodra de primary wegvalt (om wat voor reden dan ook), merkt z’n maatje dat en grijpt in. Op dat moment zorgt de secondary ervoor dat hij verantwoordelijk is voor 46.21.228.1 en vraagt XS4ALL om de MAC-cache te legen.
Dit werkt bijna altijd goed, maar soms gebeurd het dat dit niet goed gaat en duurt het 5 minuten voor XS4ALL door heeft dat er een ander MAC-adres bij 46.21.228.1 hoort. Gedurende die 5 minuten, probeert XS4ALL de IPs nog aan de (niet bereikbare) primary loadbalancer te geven. Hier moest een oplossing voor komen!

MACVlan

De oplossing is simpel en heet ‘MACVlan’. Een virtual MAC-adres op een virtuele interface. Hierdoor kan het MAC-adres mee verhuizen naar de secondairy loadbalancer. Op die manier, blijft verkeer altijd naar ‘t zelfde MAC-adres gestuurd worden, maar niet naar dezelfde fysieke machine.
Ondanks dat ‘t principe niet nieuw is (Linux kernel support is er sinds 2007) heeft de ontwikkelaar van Keepalived (Alexandre Cassen) hier simpelweg geen tijd voor gehad om te implementeren.

Hogere uptime

Hoog tijd om dit te regelen. Een hogere uptime, dat is ons wel wat waard! Gezien het open source karakter van Keepalived zou iedereen de functionaliteit kunnen bouwen. Byte heeft Alexandre echter gevraagd VMac support in Keepalived in te bouwen. Alexandre heeft de opdracht geaccepteerd en heeft een ontwerp gemaakt voor VMac support. Hij is op dit moment druk bezig dit ontwerp te implementeren!
Om dit project voor zowel Alexandre als voor ons een succes te laten worden, hebben we vooraf de scope gedefinieerd. Welke functionaliteiten, eisen en wensen zijn er?

• The source code should be public available
• Proper documentation should be available. Preferred on the website, but at least it should be included in the source-code/package
• We’re using Debian Squeeze. Keepalived should work stable with VMac support on this distribution.
• Kernel 2.6.32 (Debian) should be fully supported
• Configuring the Virtual MAC option should be done using the keepalived.conf file
• Intel E1000 network interface cards should be supported. Additionally, support for broadcom NIC (bnx2) is preferred

Alexandre voegde hier zelf nog een mooie feature aan toe. Een macvlan per VRRP proces, in plaats van een macvlan per loadbalancer. Op deze manier kunnen we heel makkelijk schuiven met IP-adressen om zo de load op de loadbalancers beter te verdelen!
‘t Beste nieuws: ‘Mainly I will start working on this by this week end (well, I already started design last month) and I will produce the code over the week end. I expect to have a fully working shot by end of next week (April 3th), we can set the deadline for end of April but I really want to speed it up by now.’
April 3th hebben we niet gehaald. De code is nog niet stabiel genoeg, maar het begin is er! Op naar een downtime-loos Byte netwerk!

[widget id=”magereport_widget-4″ /]