[Clarence]

Ursprungligen postat av gregoff

Har gett mig tusan på att jag vill läsa på lite om hur det där med lastbalansering fungerar.

Tanken är att när jag kommer på den där briljanta idéen, så ska den vara skalbar. Har ingen idé än men den kommer ;-)

Låt säga att jag har följande förutsättningar:
- applikationen är skriven i PHP/MySQL
- webbservern är nginx
- operativet är *nix (ex debian)

Som nämnt innan har jag ingen större koll på hur just lastbalanseringen fungerar, men vad jag vill kunna göra är att snabbt "koppla på" en ny server som tar del av lasten. Samtidigt skall systemet kunna hantera att en server dyker (eller att mysql på en server inte svarar).

Vad har ni för tips om vart man kan börja läsa lite? Har provat att googla en del men hittar inget konkret. Hade jag fått bestämma själv så hade det hela kunnat styras av PHP (det jag kan bäst) men det kanske blir lite svårt...?

Lastbalansering ger olika möjligheter och svårigheter beroende på typ av applikation.

1.) Inkommande request/web
Det finns många alternativ här och svårigheterna är rätt begränsade.

För bäst prestanda använder du en hårdvaru-lastbalanserare. I princip ingen gör det utan att bli direkt tvingad till det. Anledningen är att det är både mycket dyrare och kräver specialkompetens för installation, konfiguration och underhåll.

Sedan kommer man till vanliga mjukvaru-lastbalanserare. Det vanligaste alternativen här är LVS och HAproxy. LVS är lite lite mindre resurskrävande och lite sämre feature-set.

Sedan kommer man till lastbalanserare med mer logik och ofta flera features. Varnish är en väldigt vanlig sådan. Den är dessutom extremt effektiv som en cache-server och kommer avlasta klustret bakom. Det finns inget som hindrar dig att börja här och sedan sätta LVS/HaProxy framför i framtiden.

Sedan är det många webbservrar som kan användas som reverse proxies. Nginx och Apache t ex. Du får en enkel konfiguration, prestanda som räcker en liten bit på vägen och lättare att hantera lite mer logik. Inget jag skulle rekommendera förutom som en lat eller akut lösning när man saknar kompetensen för ett annat val.


2.) Databas
För databasen är det lite mer komplicerat, som redan nämnts. Du har ett par val;

Använda en master/slave setup. Du skalar upp utan problem så länge du inte behöver mer än en databas-server till skrivningar. Man klarar sig väldigt långt på detta om man skriver effektiv SQL och inte har en ovanligt hög write ratio på sajten. Det är enkelt och effektivt, tills man når antingen för många writes eller så pass många slaves att replikeringen ger för mycket overhead.

Använda en master/master setup. Komplicerat och farligt med klassisk replikering. Går att få säkert genom extra logik i applikations-lagret eller via en query proxy så att viss data alltid skrivs till viss master.

Sharda din data. Genom att dela upp datan mellan databas-servrar så kan man nå en väldigt hög skalbarhet i de flesta system. Begränsningarna kan dock bli väldigt stora beroende på applikationsstruktur och databasstruktur då det kräver att du aldrig kör JOIN mellan olika shards. Detta är väldigt välanvänt av stora sajter oavsett vilken replikering de kör.

Använd galera replikation. Det finns färdiga lösningar med galera-implementationer; t ex Xtradb Cluster. Smidigt, men ger en viss overhead. Det absolut bästa valet om du vill ha en multi-master setup utan att ha minst en dedikerad DBA.