2015-03-01
Guide

Bygg ett webbkluster på två timmar

Kanske inte alla, eller ens många, men några av oss som ägnar sig åt lite fulhosting i källaren eller på någon server i ett rack någonstans har haft huvudvärken förmånen när den där lilla sajten som din kompis driver helt plötsligt blir våldsamt populär. Ett begrepp från förr är “slashdottad” från när webbsajten Slashdot länkade till dig. Numera kanske det skulle kallas “fireballed” efter effekten som en länk från John Grubers Daning Fireball kan ha på trafiken till ens webbsajt.

Servern som denna sajt drevs på var också hem för ett antal andra webbsajter, bland annat min gode vän Petters webbsajt Nordic Innovation.

Fram tills för häromveckan tuffade Petters lilla sajt på ganska bra. Sen hände det som gjorde att den inte tuffade på så bra längre: en amerikansk webbsajt av modell större länkade till en artikel på Nordic Innovation.

Sedan dess har mina kvällar delvis ägnats åt att skyffla om bland virtuella maskiner, hacka Apache, slå på fler virtuella processorer och mer minne till webbservern för att snart få ett SMS från Petter med orden: “Sajten är nere igen.”

Att Nordic Innovation körs med WordPress i botten är en stor del av problemet, men den största delen av problemet var att min infrastruktur i min källare inte var byggd för den här typen av belastning. Jag har testat att installera cachelösningar för WordPress, optimera bilder och det mesta som i övrigt finns att testa med WordPress men cachelösningar för WordPress tenderar ändå att köra en webbserver i botten då de precis som WordPress i sig arbetar genom PHP, och det är minnesanvändningen PHP genererar som sänker en webbserver när trafiken blir för intensiv.

Antingen ger man man då upp och ber vänligt men bestämt sin vän att packa sig iväg med sin sajt och hitta någon annans hårdvara att köra skiten ur, eller så löser man problemet.

Jag ska villigt erkänna att det fanns ögonblick, korta och få, där jag tänkte att Nordic Innovation gärna kunde få ta ett större webbhotell ned på knäna istället för min lilla fulhosting, men snart insåg jag att det inte vore rätt, och framförallt vore det också att backa från en intressant utmaning. Det var därmed dags att bygga sig ett webbkluster.

Vad är ett webbkluster

Enkelt uttryckt är ett webbkluster en bunt webbservrar (i detta exempel kallat webbnoder) som arbetar tillsammans för att servera en eller flera webbsajter (eller andra webbaserade resurser) till ett intranät eller Internet. Som standard går all trafik först till en lastbalanserare som därefter förmedlar trafiken till respektive webbnod baserat på vilken svarstid de olika webbnoderna presenterar tillbaka till lastbalanseraren. Går en nod i backen känner lastbalanseraren av detta och slutar omedelbart skicka trafik till just den webbnoden, så man kan om man vill se detta inte bara som en lastbalansering utan också som en redundanslösning. Det absolut roligaste med allt detta är att programvarorna som krävs är gratis. Det enda som krävs som faktiskt kostar något är tid och hårdvara.

Så byggde jag det

Mina utmaningar när det gällde att bygga ett webbkluster var flera. Dels skulle jag göra det utan att störa driften av de befintliga sajterna. Sen skulle det göras på enklast möjliga sätt så det är lätt att förstå och underhålla om några månader när jag får för mig att felsöka eller på annat sätt underhålla systemet.

Mitt system bygger i dagsläget på en bas av VMware ESXi och en iSCSI-baserad lagring i form av en Synology DS1511+ med 3,5TB lagringsutrymme. All iSCSI-trafik går via en separat gigabit-switch och resten av trafiken går över sin egna gigabitswitch. Jag har tre VMware-servrar och de allra flesta servrar jag har på dessa kör Linux. Min webbserver innan klusterbygget hade gradvis fått mer och mer minne och hade till slut åtta gigabyte minne och fyra processorkärnor till sitt förfogande. Det räckte inte.

Det första jag gjorde var att installera upp fem “nakna” CentOS-servrar på mina VMware-servrar. Jag tenderar att vara konservativ när det gäller vilken version av CentOS jag kör på mina maskiner ligger alltid ett par versioner efter. På den första servern installerade jag HAProxy, en lastbalanserare för TCP- och HTTP-anslutningar. Därefter installerade jag en NFS-server på nästa maskin och en MySQL-server på en tredje. På den fjärde och femte maskinen installerade jag Apache HTTPD-servern. Jag kör NginX som test på en separat webbserver för Macpro och min personliga blogg, och kommer sannolikt att dumpa Apache HTTPD helt och hållet i en nära framtid till förmån för just NginX. Jag är medveten om att NginX kan användas som lastbalanserare men HAProxy har jag arbetat med tidigare på bland annat filmtjänsten Voddler med mycket gott resultat.

systemskiss

På NFS-servern placerade jag alla webbsajter, SSL-certifikat samt loggar och konfigurationen för Apache HTTPD. På respektive webbnod såg jag sedan till att Apache HTTPD laddade sin konfiguration från NFS-servern. På MYSQL-servern importerade jag utdumpade databaser från den gamla webbservern och såg sedan till att MySQL kunde prata över nätverket med de båda webbnoderna.

Att konfigurera HAProxy

HAProxy är oerhört enkelt att komma igång med och det enda jag egentligen stötte på problem med var hur jag skulle kunna släppa igenom SSL-trafik till denna webbsajt och låta respektive webbnod hantera SSL-certifikatet istället för att låta NginX göra det.

Konfigurationen, utöver standardinställningarna som man i princip inte behöver röra om man inte har särskilda behov, blev således som följer:


#--------------------------
# pool of web servers
#---------------------------

frontend web
listen http :80
reqadd X-Forwarded-Proto:\ http
mode http
option tcplog
default_backend web_main

frontend web_ssl
listen https :443
mode tcp
option tcplog
default_backend web_ssl

backend web_main
mode http
balance roundrobin
server webserver01 1.2.3.4:80 check
server webserver02 1.2.3.5:80 check

backend web_ssl
mode tcp
balance roundrobin
option ssl-hello-chk
server webserver01 1.2.3.4:443 check
server webserver02 1.2.3.5:443 check

Har man webbsajter som kräver SSL så glömmer man lätt bort att HAProxy endast skickar vidare exakt de portar du säger åt den att skicka vidare, på samma sätt som att Apache HTTPD endast svarar på de portar du säger åt den att svara på.

Efter att jag testat lokalt med att ladda några sajter via HAProxy styrde jag om trafiken i brandväggen till lastbalanseraren och det fungerade omedelbart. I dagsläget kör jag med 1GB RAM vardera för HAProxy och NFS-server, 2GB RAM för MySQL-servern samt 3GB RAM och två processorkärnor för respektive webbnod. Det smidiga med den här uppsättningen är att jag relativt enkelt kan klona någon av de befintliga webbnoderna, byta IP-adress på den och sedan peta in den i HAProxy-konfigurationen och vips så har jag tre, fyra eller fem webbnoder. Blir trafiken för hård kommer HAProxy att behöva mer minne men än så länge har belastningen på lastbalanseraren varit i princip noll belastningen på respektive webbnod betydligt lägre vilket är intressant eftersom trafiken knappast minskat sedan jag körde allt på en enda webbserver som då aldrig låg under en belastning på 75-85%.

Vad tog då detta projekt i tid? Ett par timmar. Det krävdes lite funderande på hur jag skulle lägga upp själva arbetet men när det väl var bestämt gick det ganska snabbt att göra alla konfigurationer som krävdes. Värt att notera är också att HAProxy inte bryr sig om vilken webbserver du kör på webbnoderna – har du ett antal gamla Mac Mini går de utmärkt att använda för detta ändamål så länge mjukvaran på maskinen stödjer det du vill göra med den.


Macpro är annonsfri för att göra din läsupplevelse bättre.
Läs mer här

© 2004 - 2017 Joacim Melin