Lastbalansering: Tips tankar och idéer
 

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

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.

Ä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

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.

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

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

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 :)

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.

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

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.

I skalbara system med hög last är det nästan alltid databasen som blir flaskhalsen och som segar ned. Det är tyvärr också databasen som är det knepigaste att skala up.

Som Jim var inne på kommer man väldigt långt med ganska enkla medel.

En hyfsat kraftfull VPS kommer man långt med om har bra queries och mycket cache av databasanrop samt OP-code cache.
I normala fall kan man se till att man nästan aldrig läser något alls ifrån databasen utan endast ifrån minnescachen(t.ex. memcached eller redis). Om man ser till att varje gång man gör någon ändring i databasen (INSERT, UPDATE, DELETE) också direkt uppdaterar cachen kommer man också kunna serva det senaste innehållet utan att röra databasen samtdigt som du har en lång(flera dagar, eller till och ned en månad går utmärkt) TTL(time to live, dvs hur länge cachen ska räknas som aktuell) på cachen. Databasen kommer därmed mer eller mindre endast hantera skrivningar och alla läsningar hanteras av cachesystemet. Detta gör systemet extremt snabbt och kräver väldigt lite CPU-resurser, men det kräver dock en del minne beroende vad det är för site.

Ett enkelt steg är sedan att gå ifrån en (VPS-)server till två är att separera databasen ifrån webbservern. Då är det bara att ändra MySQL-hostname i koden så fungerar det.

När inte detta räcker blir det ju som sagt mer komplicerat. För att lastbalansera HTTP-requests så tycker jag den klart bästa läsningen är Varnish. Varnish-servern ligger framför webbservrarna och cachar hela requests som skickas tillbaka direkt om sidan finnas cachad. Därmed behöver inte en request hanteras alls av webbservern om den redan finns cachad. Det är heller inga problem att sätta upp flera varnish-servrar som arbetar parallellt(det enklaste är round-robin DNS, men det finns mer avancerade alternativ för att hantera flera varnish-servrar). Bakom varnish-servrarna kan man sedan ha obegränsat antal webbservrar.

För databasen blir det någon klustrad lösning med replikring som redan nämnts och förklarats bra här.

Jo har också en känsla av att databasen är det som är bökigast, men en bra början är som du säger att man bryter ut databasen till egen dedicerad server.

Tack alla för era tankar och idéer. Jag återkommer när detta blir aktuellt (dvs när/om jag kommit på "the next big thing" ;-)

Gällande att ha flera varnish-servrar parallellt ta en titt på http://www.fastly.com/ och deras API. De gör just detta. Du får även geo-targetting och eventuellt redundans.

Du behöver inte "the next big thing". Ett befintligt projekt funkar gott och väl. Det är väldigt lärorikt att lasttesta och optimera utifrån resultaten. Det borde inte dröja länge förens du inser att mikrooptimeringar som if vs switch, for vs while eller allt vad det kan vara inte spelar någon roll i det stora hela. Dessutom är det riktigt kul! :)

Mitt nuvarande projekt har ca 100.000 sidvisningar den senaste månaden vilket inte ens är i närheten för att få min vps hos glesys att börja höja pulsen, så för tillfället är jag "all set" ett tag framöver. Gissningsvis kan servern hantera det 10-dubbla eller mer innan det är dags för seriös optimering. Problemet med optimering under last är just lasten. Jag antar att man får köra en sluten test-miljö där man laddar diverse funktioner/sidor ett antal tusen gånger och mäter tiden emellan optimeringarna.

Ja, vill du göra det ordentligt behöver du en labbmiljö som är så lik livemiljön som möjligt som du kör testerna mot. När den är på plats kan du sätta upp "agents" som belastar sajten om det inte räcker med en enskild maskin. Du kommer behöva sätta upp mål, t.ex. att sajten alltid ska svara inom n sekunder, att CPU-belastningen inte går över en viss gräns etc eftersom man inte kan optimera kod i all oändlighet; nånstans når man en gräns för vad ens hårdvara klarar av.

De flesta lasttestningsprogram kan spela in scenarion/användarfall som man sedan spelar upp men förstärkt (simulerade användare). Det går att fejka väntetider, bandbredd, ordningen på scenariona etc. Ganska flexibelt som borde återspegla verkligheten ganska bra med andra ord. Man hookar upp "lyssnare"/grafer på vad man är intresserad av, t.ex. minnesförbrukning, CPU-användning, request/sec, antal köade requests, felsidor etc. Ser du någon sida som presterar dåligt kör du igång en profiler och tar reda på vad tusan som faktiskt tar tid, vilka metodanrop som roffar åt sig all prestanda. Fokusera på de stora problemen först.

Att vänta tills du har nästa stora grej tror jag inte på. För det första kanske man aldrig hittar något sånt projekt, sen om/när man väl är där har man kniven på strupen och kan inte analysera resultaten i lugn och ro. Långsiktigt bra beslut tar man oftast inte när man är stressad.