Binero 2.0, del 1.4 – Driftsäkerhet, lastbalansering

• Tweet

• PUSHA

• Tweet

I denna sista bloggpost i delen driftsäkerhet har vi något riktigt extra!

Något väldigt viktigt som säkert 98 procent av alla webbhotell saknar; lastbalansering.

» Lastbalansering, den enkla versionen
» Lastbalansering, tekniskt mumbojumbo

Lastbalansering, den enkla versionen

Lastbalansering är ett sätt att få din hemsida att vara oftare online på nätet. I en vanlig miljö, som vår gamla t ex, så är man beroende av en server, virtuell eller ej.

Om den här servern går sönder, blir överbelastad eller råkar ut för något annat fel som gör att den helt enkelt inte fungerar som den ska så kommer din webbsida inte kunna visas för besökarna. Och trasiga saker har vi diskuterat förut, det ogillar vi.

Vad vi gör då är att vi placerar din hemsida på flera servrar och besökaren hamnar på den servern som är minst belastad för närvarande och skulle något hända med den servern så hamnar den trevliga besökaren på en annan server. Upp till tio servrar ligger din hemsida på.

Vi tyckte inte detta var tillräckligt utan vi sa att webbservern ska inte göra något annat än att visa webbsidor, så vi satte upp tio servrar som bara hanterar FTP för din hemsida och ytterligare tio som hanterar e-posten ett antal databasservrar som kopierar all data kontinuerligt till en backup databasserver.

Krångligt? Ja det är det men sammanfattningen är att vi har slagit på stort i det nya systemet för att vara säkra på att vi kan leverera en världsbäst lösning för din hemsida.

Lastbalansering, tekniskt mumbojumbo

För lastbalanserarna har vi valt att använda OpenBSD tillsammans med relayd och carp (Common Address Redundancy Protocol). Relayd är en demon som är inkluderad i OpenBSD för att dynamiskt lastbalansera valfria tjänster i kombination med pf (packet-filter) och rdr .

Relayd är uppsatt för att flera gånger per minut kontrollera att bakomliggande noder fungerar som de ska och att om någon av noderna mot förmodan skulle gå ner tar relayd bort den ur klustret och trafiken omdirigeras till de andra noderna samt larmar vår driftavdelning. Vi har valt att köra denna typ av installation för samtliga tjänster, HTTP, FTP och e-post för att garantera högsta möjliga upptid.

För att vidare säkerställa full redundans nyttjar vi carp i active/passive mode mellan lastbalanserarna. Om en lastbalanserare går ner flyttar carp då över service-IP:t för tjänsten till den passiva lastbalanseraren som redan är redo att börja sända trafik till underliggande noder.

Då carp skapar ett virtuellt interface med en delad mac-address minimerar vi den nertid som uppstår vid en automatisk överlämning (failover) då noderna inte behöver uppdatera sin arp-cache (Address Resolution Protocol). Tester vi gjort har visat att överlämningen görs på mindre än tre sekunder.

Utöver detta delar bakomliggande noder samma lagring vilket säkerställer att din data finns tillgänglig oavsett vilken nod dina besökare hamnar på.

Relaterade inlägg:

1. Binero 2.0, del 1 – Driftsäkerhet, virtualisering
2. Binero 2.0, del 1.3 – Driftsäkerhet, nätverk och övervakning
3. Binero 2.0, del 1.2 – Driftssäkerhet, lagring
4. Binero 2.0, del 1.1 – Säkerhet, brandväggar
5. Uppgraderingen av BineroNet: lastbalansering