Guide: Horisontell skalning i City Cloud – del2

Özgür Bal Molnet Leave a Comment

Det är dags för andra delen av vår artikelserie om horisontell skalning i City Cloud. I den första delen gick vi igenom lite övergripande fakta om vad horisontell skalning egentligen är. Vi gick även igenom ett exempel där vi delade upp en hemsida så att webbservern och databasen körs på två olika maskiner, allt för att få bättre prestanda.

I det här inlägget ska vi gå vidare och titta på hur man kan sätta upp lastbalansering genom att använda ett populärt verktyg som också kan användas som proxy server – Varnish.

Vad är det vi ska göra?

Vi åtegår till vårt tidigare exempel där vi separerade webbservern och databasen till två separata maskiner och nu är det dags att ta nästa steg för att bättra på prestandan genom att lastbalansera. Tanken med den här åtgärden är precis densamma som tidigare, att se till att sidan klarar fler samtidiga besökare. En tung och överbelastad sida är skillnaden mellan en återkommande besökare och en som går vidare till konkurrenten så det här är viktiga åtgärder.

Alltså: Vi har en webbsever som pratar med en databasserver som tillsammans levererar en sida till besökaren. Det vi ska göra nu är att lägga till ytterligare en webbserver och en lastbalanserare framför dessa. Lastbalanseraren är lite som spindeln i nätet som dirigerar om besökare till den webbserver som för tillfället är minst belastad. Resultatet blir att besökaren, som självklart inte ser vilka “krångliga” vägar den tar för att komma till din sida får en bättre upplevelse.

Det finns många fördelar med den här metoden. Lastbalanseraren agerar även som proxy mellan användaren och webbservern vilket ger oss möjligheten att använda cachning både på statiska och dynamiska sidor. Utöver det har vi en stor fördel vad gäller fail-over. Om den ena webbservern skulle gå ner helt så har vi alltid en kvar som besökaren automatiskt dirigeras om till.

Klona webbservern

Dags att sätta igång. Det första vi gör är att klona vår webbserver och eftersom att vi kör i City Cloud är detta lätt gjort.

  • Stäng av din VM
  • Klicka på Klona.

Den här processen tar olika lång tid beroende på hur stor lagringsyta du har på servern då allt kopieras. Så snart servern är klonad behöver vi åtgärda ett par saker direkt.

En kloning innebär att precis all data, information och inställningar kopieras. Detta medför att det krockar en aning i hanteringen av nätverksinterface. Detta åtgärdas enkelt genom att ändra lite kod på den nya, klonade maskinen.

# Use your own preferred text editor
vim /etc/udev/rules.d/70-persistent-net.rules

När du är inne i filen raderar du alla rader. Fälten fylls sedan i automatiskt när operativsystemet hittar ett nätverkskort med en ny MAC-adress. Genom att göra detta säkerställer vi att nya nätverkskort får korrekta IP-adresser. I vårt faktiska exempel behöver vi bara ett nätverkskort med en intern IP-adress. Därför behöver du ett nätverkskort med korrekt privat VLAN och en lokal adress precis som de andra två servrarna. I vårt exempel (läs gärna del 1) hade vår första webbserver 192.168.1.1 och vår databasserver 192.168.1.2 så den nya webbservern kan få 192.168.1.3.

Det sista steget är att tala om för databasservern (MySQL-servern) att vi vill ge den nya webbservern tillgång till databasen. Vi tar oss in på databasservern och gör följande:

# Remember to change the IP address to the new server private one.
mysql> grant all privileges on wordpress.* to 'username_here'@'192.168.1.3' identified by 'password_here';
# Let's make sure privileges are reloaded
mysql> flush privileges;

Hittills har vi alltså två webbservrar och en databasserver som alla pratar med varandra. Då är det dags att installera en lastbalanserare som kan fördela besökare över de två webbservrarna.

Installaion av lastbalanserare

I vårt exempel använder vi Varnish Cache, en mjukvarubaserad lösning för bland annat lastbalansering och cachning. Du kan läsa mer om Varnish på deras officiella sida. Andra lösningar som du kan använda är exempelvis nginx, haproxy och relayd (kör under OpenBSD).

Skapa en ny VM med den färdiga imagen “Debian 6.0.2.1 64-bit”, du kan använda hårdvaruprofilen “small”, vi behöver inte mer kraft än så.

När din VM är skapad går du igenom de vanliga stegen; Sätt ett lösenord för servern och lägg till ett nätverksinterface med det privata VLAN:et. Sätt upp lokala IP-adresser, det kan vara vad som helst så länge det är inom samma subnät som de andra tre servrarna. Vi har valt 192.168.1.4 men du kan förstås välja vilket IP du vill.

Nu är det dags att installera Varnish. Logga in på servern som root och gör följande:

wget http://repo.varnish-cache.org/debian/GPG-key.txt
apt-key add GPG-key.txt
echo "deb http://repo.varnish-cache.org/debian/ squeeze varnish-3.0" >> /etc/apt/sources.list
apt-get update
apt-get install varnish

Dessa kommandon kommer från den officiella guiden och ger oss en uppdaterad version av programvaran. Nu ska vi sätta upp ett simpelt lastbalanserings-schema. Det vi gör här är bara en liten del av all funktionalitet som finns i Varnish, läs gärna den officiella dokumentationen för fler alternativ.

I klartext ska vi nu göra följande: Vi ska tala om för Varnish att det finns två webbservrar som kan ta emot besökare i följd. Det innebär att den första besökaren kommer till den första servern, den andra besökaren till den andra servern, den tredje besökaren tillbaka till första servern osv. Fördelen med den här metoden är att du kan ha hur många webbservrar du vill och att prestandan på din sida förbättras. Om en av webbservrarna går ner kommer systemet automatiskt att skicka besökare till kvarvarande servrar tills den trasiga servern är uppe och snurrar igen.

Nu är det dags att redigera konfigurationsfilen.

vim /etc/varnish/default.vcl

Lägg till följande rader:

backend website1 {
        .host = "192.168.1.1";
        .port = "80";
        .probe = {
                .url = "/";
                .interval = 20s;
                .timeout = 3s;
                .window = 5;
                .threshold = 3;
        }
}

backend website2 {
        .host = "192.168.1.3";
        .port = "80";
        .probe = {
                .url = "/";
                .interval = 20s;
                .timeout = 3s;
                .window = 5;
                .threshold = 3;
        }
}

director test_round_robin round-robin {
        # Main website
        {
                .backend = website1;
        }
        # First mirror
        {
                .backend = website2;
        }
}

sub vcl_recv {

        set req.backend = test_round_robin;
}

Varnish använder ett flexibelt konfigurationsformat där du kan ställa in en rad olika regler baserat på dina behov. Varje konfiguration separeras vanligtvis med block som startar med {och slutar med}. Om du är en programmerare är du säkert redan bekant med den här metoden.

Det första blocket ovan, talar om för Varnish att det finns en server i bakgrunden som heter “website1” och att host:en är 192.168.1.1. Minns du den IP-adressen? Det är alltså IP-adressen till vår huvud-webbserver. I det här blocket har vi även annan information såsom portnummer (vi använder standardporten 80), hur ofta vi vill kolla om den här servern är uppe, timeout och andra parametrar.

Det andra blocket, som heter “website2” liknar det första men har en annan IP-adress (192.168.1.3, till vår klonade webbserver). Därefter använder vi ett annat fördefinierat block som kallas “director” och skapar ett sk. round-robin schema. Det är här vi talat om för Varnish att varje förfrågan ska gå till de tillgängliga servrarna i följd.

Sist men inte minst omdefinierar vi funktionen “vcl_recv” och ställer in en enkel instruktion: “set req.backend = test_round_robin;”. Det här är det schemat vi ställde in tidigare.

Nu är det dags att få Varnish att läsa den nya konfigurationen.

# Kill varnish process
pkill varnishd
# Instruct Varnish to start with a 392 Megabytes cache. Note that we can also change the configuration file if we want to.
varnishd -f /etc/varnish/default.vcl -s malloc,392M -T 127.0.0.1:2000

Då var det klart! Det finns definitivt fler och mer komplexa exempel på regler och tillvägagångssätt för att bygga lastbalansering. Se det här som en bra början och något att bygga vidare på.

Vi testar konfigurationen

Tack och lov är testning mycket enklare än att installera alla funktioner. Om du har en domän och har satt upp en virtuell host kan du gå till din domän som vanligt. Om du har följt vår guide till punkt och pricka bör du ändra i hosts-filen och redigera raden där du skrev in dummy-domänen wordpressite.com till Lastbalanserarens publika IP-adress.

Sen är det bara en fråga om att öppna webbläsaren och gå till din domän. Det som har hänt nu är helt enkelt att samma sida som vi satte upp i del 1 visas. Hur vet vi då att Varnish gör allt den ska i bakgrunden? Det finns flera sätt att ta reda på det, ett sätt är att gå in i de två webbservrarnas terminaler och hitta respektive loggfil.

Om du använder vår image hittar du loggfilen under /www/wordpresssite.com/logs/access.log. Du kan se de senaste loggarna i realtid genom följande kommando:

cd /www/wordpresssite.com/logs/access.log
tail -f access.log

Gör likadant med båda servrarna och gå tillbaka till din webbläsare. Uppdatera websidan upprepade gånger och titta sedan på webbservrarnas loggfiler. Där bör du se att anropen görs på varannan server varje gång du uppdaterar. Därmed är allting klart och du har nu en lastbalanserad wordpress-sida.

Om du vill gå vidare med den här uppsättningen kan du vidta vissa åtgärder för att säkra upp dina servrar. Ett sätt är att avaktivera de publika nätverksinterfacen till dina servrar. Allt bör fortsätta att fungera precis som vanligt då Varnish använder de interna IP-adresserna. Du kan göra detta permanent men då tvingas du gå via lastbalanseraren när du vill komma åt webbservrarna. Krångligare att komma åt servrarna men man eliminerar ett par känsliga punkter i systemet. Kontakta oss gärna om du har funderingar kring detta, vi hjälper dig.

Slutsatser

Vår enkla men ändå väldigt användbara guide är tänkt att ge lite inspiration och exempel på hur man kan bygga upp en miljö som både är säker och snabb. Med det här som utgångspunkt finns det alla möjligheter att bygga vidare med regelverk i Varnish. Ett exempel kan vara att man lastbalanserar på ett sådant sätt att vissa delar av din sida går till en webbserver och andra delar till en annan webbserver. Möjligheterna är oändliga. Slutmålet är tros allt detsamma; en snabb och säker sida.

I nästa del av vår arikelserie går vi in på hur man testar en sån här miljö, hur man tar sönder den med flit och får igång den igen med målet att förstå när saker går fel och varför. Vi går även in på fler alternativ i Varnish.