[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...?

[Björklund]

Bäst prestanda ger en hårdvarulastbalanserare typ Cisco, Juniper, F5 m.m.

Mne eftersom du redan kör Nginx och kanske du inte har så hög last (jag gissar), använd lastdelaren som finns i Nginx. Den kostar ju inte så mycket.

http://wiki.nginx.org/LoadBalanceExample

Du har alltså minst tre servrar. Server #1 är endast lastdelare och de andra webbservrar.

Använd gärna någon form av failovermjukvara om server #1 slutar fungerar för lite bättre redundans.

[gregoff]

Än så länge har jag ingen last. Vill mest läsa på om hur det fungerar.

Tack för tipset om lastdelaren i nginx. Ska kika på det.

Tänkte att systemet ska kunna hantera en databas som balanseras. Både läsning och skrivning. Alla vettiga läsförslag tas tacksamt emot.

[patrikweb]

Ursprungligen postat av gregoff

Än så länge har jag ingen last. Vill mest läsa på om hur det fungerar.

Tack för tipset om lastdelaren i nginx. Ska kika på det.

Tänkte att systemet ska kunna hantera en databas som balanseras. Både läsning och skrivning. Alla vettiga läsförslag tas tacksamt emot.

Databas är lite mer avancerad och största problemen som kan uppstå där, använder du exempelvis MySQL som inte är en "Enterprise" på samma sätta som Oracle.

Du kan köra MySQL som MASTER/MASTER, jobbigaste och farligaste i filsystem cluster och DB cluster är "split brain". Du behöver minst 3-4 noder för minska dom problemen.

Ett tips är använda Galera om du vill köra Mysql.

http://www.codership.com/content/using-galera-cluster

[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.

[gregoff]

Jisses, lastbalansering är knappast för nybörjare...

Tack för alla tankar och tips. Nånstans måste man börja ;-)

[Clarence]

Normalt sätt klarar du dig väldigt långt på en databas-server. En slav blir som ett första steg väldigt bra för backups (oavsett om du kör throttled backup så ger backup en ordentlig last om den ska ske inom OK tid med hyfsad datamängd). Att sedan ha 2-3 slavar kan vara en effektiv fortsättning. Problemen handlar då i stort bara om att sätta upp och övervaka replikeringen, samt lastbalanseringen på applikationssidan (mysqlnd har en färdig lösning där, men senast jag tittade på den belastade den applikationsservrarna för mycket).

För webbservrarna (eller applikationsservrarna) är det enda problemet man normalt sätt får oavsett vilken lastbalansering du väljer att du inte ska spara någon state lokalt på disk. Vanligaste fallet där det görs i en icke-distribuerad miljö är för att sessions-filer och uppladdade filer. Vissa väljer en lat lösning där; att de alltid ger samma server till samma användare och får en mängd användare som loggas ut om en server dör och måste sedan ändå specialhantera uppladdningar. Alternativen är att använda en distribuerad lösning eller desto enklare, ändra session-handler till en egen som går antingen mot MySQL eller än hellre en lättare key-value-store (aka NoSQL, t ex redis).

Det kanske inte lät så nu, men lastbalansering är inte så svårt att komma igång med skulle ha varit min poäng

[Jim_Westergren]

Du klarar dig långt med en enkel VPS. Använd APC för att op-code cacha PHP och Redis eller annan NoSQL-lösning för att cacha mot MySQL. Lägg statiskt innehåll på en CDN. Vissa dagar kommer jag upp i över 150 tusen unika och det är inga problem.

Nästa steg för mig är att lägga DNS hos dnsmadeeasy.com och aktivera deras GEO-DNS mot olika VPS i olika kontinenter. Kommer då köra Redis Master/Slave som en cache mot MyQSL. Detta främst för att få ner latency men även som failover.

Men lägg inte för mycket tid på detta innan du har en populär sajt.

[gregoff]

Ska ta ditt råd Jim. Satt mest och funderade på hur man ska hantera en populär tjänst som växer. Ska nog ta och skaffa en populär tjänst först. Vad det nu skulle vara?

Time will tell...

[dAEk]

En populär tjänst behövs inte för du kan ju köra mot dina befintliga sajter. Har du tillgång till webbserverns loggar är de perfekt att ha som underlag för att simulera tyngre belastning.