Guide: Horisontell skalning i City Cloud

Özgür Bal Prestanda Leave a Comment

Ett “angenämt” men ack så jobbigt problem för dig som sajtägare är när du fått så pass många besökare att din sida slutar att fungera. Om du har läst våra tidigare artiklar i ämnet Skalning så kanske du har gjort vissa förbättringar och skaffat dig lite andrum men i det långa loppet är det kanske inte tillräckligt.

Det finns fler sätt att säkerställa din tillväxt utan att markant öka vare sig kostnaderna eller slöseriet av resurser.

Skalning

Med vertikal skalning ökar du serverkraften på din befintliga server för att kunna leverera en tjänst eller en sida till fler personer samtidigt. Med City Cloud, precis som med andra IaaS plattformar, är det väldigt enkelt att skala både upp och ned. De negativa sidorna med vertikal skalning är att kostnaderna i vissa fall stiger orimligt mycket sett till vad du får ut i prestanda.

Horisontell skalning, å andra sidan, går ut på att addera flera servrar och distribuera lasten mellan dem. Naturligtvis medför även detta ökade kostnader men den stora skillnaden är att resurserna utnyttjas mer effektivt i det långa loppet. Utöver det är gränsvärdena för horisontell skalning vanligtvis högre, det vill säga att man kan lägga till fler servrar och fördela last än vad man kan öka på en enskild servers kapacitet. I verkligheten använder vi vanligtvis en kombination av dessa tillvägagångssätt. När vi får trafiktoppar börjar vi med att öka på de enskilda servrarnas kapacitet (vertikal skalning) och lägger på fler servrar (horisontell skalning) för att sedan kunna skala ned till normal-läge.

Nyckeln till det hela är Cloud Computing i allmänhet och City Cloud i synnerhet. Att fysiskt byta ut processorer och addera minne på en server och koppla in fler servrar i ett rack är förstås fullt möjligt och görs fortfarande av mångaa företag där ute. Men med Cloud Computing kan även mindre företag och privatpersoner göra precis samma sak – virtuellt. Nu för tiden har dock fler och fler företag och stora organisationer insett hur effektivt Cloud Computing är, jämfört med att fysiskt hantera hårdvara och Cloud Computing används flitigt runt om i världen.

 

Vårt experiment

För att påvisa fördelen med att skala i City Cloud tänkte vi guida dig igenom ett exempel. Vi kommer att ta en server som har en WordPress installation, separera databasen till en egen server (del1), implementera en enkel lastbalanseringslösning (del2).

Innan vi börjar har vi alltså en enskild, virtuell maskin som är både en databasserver, webserver och kör WordPress. WordPress är en perfekt försökskanin då den används av miljontals användare världen över, och i allmänhet är enkel att installera och testa.

Låt oss köra igång

Vi utgår från att du har ett konto hos oss, om inte kan du följa den här guiden för att komma igång. Ni andra, häng på!

Logga in i City Cloud och skapa en ny virtuell maskin med imagen “Debian 6.0.2 64-bit – WordPress (Nginx)” från vår App Center. Välj hårdvaruprofilen “small”, det här enkla testet kräver inte mer kraft än så. När installationen av den virtuella maskinen är klar slutför du installationen av WordPress. Genom att använda ett slumpat domännamn (eller ett riktigt, du väljer), bör det se ut såhär i din webbläsare:

 

Nu ska vi gå tillbaka till City Cloud och skapa en ny server. Den här gången använder vi imagen: “Debian 6.0.2.1 64-bit” som bara innehåller Operativsystemet, inte wordpress. När installationen är klar startar du terminalen och installerar MySQL server med följande kommandon:

# Let’s make sure we have the listing up-to-date
apt-get update

# Now we use apt to install the MySQL server
apt-get -y install mysql-server

Några sekunder senare har du en MySQL server redo att användas, glöm inte att använda ett säkert root-lösenord. Nu är det dags att koppla ihop de båda servrarna. För att få ett privat närverk mellan dina virtuella servrar behöver vi lägga till ett nätverk till ditt konto. Kontakta oss så hjälper vi dig vidare.

När du har lagt til ett sekundärt virtuellt nätverkskort till båda servrarna går vi vidare och sätter upp ett internt IP-spann (typ: 192.168.x.x). Testa och se så att båda servrna kan pinga varandra innan du går vidare. Felsökning i det här läget innebär i regel att se till att båda NIC:arna är uppe och att båda har rätt IP-adresser.

Separera databasen

Nu tar vi oss in på den första servern och dumpar databasen till en fil. Du kan använda SSH eller VNC, vilket som går lika bra. När du är inne behöver vi stoppa webservern för att undvika problem (egentligen inte nödvändigt men det är rätt väg att gå)

# Switch to root first
/etc/init.d/nginx stop

Sen går vi vidare med exportering av databasen. Med följande kommando (se till att du använder namnet på din egen databas)

mysqldump -u root -p databasename > databasename_dump.sql
Password: [insert your root mysql password here]

Detta bör gå relativt snabbt. När du har en färdig fil, kopiera över den till den andra servern:

scp databasename_dump.sql adminuser@[internal_ip_of_the_new_db_server]:/home/adminuser

Nu går vi in på den andra servern, skapar en databas och importerar från filen vi skapade.

# First, connect to MySQL
mysql -u root -p
# Then, we create the database
mysql> create database wordpress;
# Afterwards, we assign a user to it
mysql> grant all privileges on wordpress.* to 'username_here'@'192.168.1.1' identified by 'password_here';
# Let's make sure privileges are reloaded
mysql> flush privileges;
# We switch to the database and import the dump into it
mysql> use wordpress;
mysql> . databasename_dump.sql

Sist men inte minst måste vi se till att webbservern har tillgång till databasen. Eftersom att vi skapade ett internt nätverk har vi viss säkerhet i själva lösningen. Redigera MySQL server config filen (finns vanligtvis under /etc/my.cnf på Debian). Ändra följande rad:

bind-address = 127.0.0.1

to:

bind-address = [your_internal_database_server_ip]

Nu är vi snart klara. Det som kvarstår är att tala om för WordPress vad den nya servern finns någonstans. Gå tillbaka till webbservern och redigera följande fil: [wordpress config file path] med korrekt host (den interna IP-adressen till den nya databasservern) användarnamn, lösenord och databasnamn.

Kör igång webservern

# Again, as root.
/etc/init.d/nginx start

Då ska allt vara klart. Om du går till webbläsare och laddar upp sidan bör allt se ut precis som innan. För att bekräfta att servern kör den nya, distribuerade uppsättningen, kan du gå in på webbservern och radera MySQL-databasen. Allt bör fortsätta och fungera precis som vanligt.

Andra former av horisontell skalning

Det vi har gått igenom här riktar sig främst till sidor som har överbelastade webservrar. Det här är bara en lösning och man ska vara på det klara med att flaskhalsen/halsarna kan finnas på andra platser än just på webbservern. Exempelvis kan du ha en snabb webbserver men en slö databas. I ett sådant läge finns det olika sätt att skala databasen horisontellt men det blir också mer komplext då man måste räkna in faktorer som replikering, fail-over och andra utmaningar.

Det kan även finnas situationer där du har ett skräddarsytt system som inte kan utnyttja den kraft du adderar och då spelar det ingen roll hur mycket du skalar ut. Det blir än mer komplext om vi tar in faktorer som geografisk redundans och skalning över flera datacenter.

Poängen här är att skalning i praktiken kan vara mycket mer än vad vi visat här idag även om detta tar dig en bit på vägen. Underskatta aldrig tiden och investeringen som ett redundant system kostar.

Slutsats

Just nu har du två servrar. En som innehåller själva WordPress-sidan med all PHP, Javascript, HTML och alla andra filer och en som enbart innehåller databasen.

Den omedelbara fördelen med detta är prestanda. Du har inte längre en webbserver som kämpar MOT databasen över RAM-minnet och processorkraften. Den andra fördelen är säkerhet, din databas är isolerad på en separat server som kan ha en högre säkerhet (Glöm inte att stänga av standard-nätverkskortet som har en publik IP-adress associerad). Det är i alla fall ett steg i rätt riktning.

Vi hoppas att den här guiden varit till hjälp och kanske har gett dig lite tips på hur du kan experimentera vidare.