Andreas Bergman

När du idag installerar en linuxdist, tex Debian 6 eller CentOS 6 och väljer att installera det som en “server” då kommer installationsprogrammet installera det allra nödvändigaste och inte mycket mer, såvida du inte väljer en massa extra paket.

Sedan väljer du att installera dom applikationer du vill ha, tex MySQL, Nginx och PHP. Allt är frid och fröjd så länge din applikation bara har ett fåtal besökare, MEN när besöksantalet växer, applikationen blir mer krävande, du lägger till CPU, RAM och HDD men applikationen går ändå inte fortare, känns det igen?

Allt detta beror på att linux är helt felpaketerat, många av applikationerna, begränsningarna i hur många filer och processer en användare får använda och antalet databastabeller som får vara öppna samtidigt i databasen, är alla konfigurerade för att köras på en mobiltelefon, prestandamässigt åtminstone.

För att ta ett exempel: en större webbapplikation kanske har en 2000 databastabeller, är det en WordPress multisite så kan den mycket väl ha fler, vad sägs om några tusen tabeller? Som standard är den MySQL konfiguration som skeppas med Debian 6 satt med en table_open_cache till 256, det optimala för MySQL är antalet tabeller * max antal joins och i de flesta webbapplikationer gör man fler än 2 joins i en query, säg att man gör 3 joins som mest i en query det gör att table_open_cache borde vara någonstans runt 2000 * 3 dvs 6000. Så istället för att skeppa en liten konfig som standard, skeppa en konfig som låter mig nyttja servern till max.

Ett bättre och ett fel som många springer på och som jag avhandlar i det här blogginlägget är att användarkonton i linux av någon outgrundlig anledning har ett maxtak på 1024 öppna filer. Jag köper att man kanske har det på Ubuntu som är en desktopapplikation, men i Debian som installeras som en server? Hur har man tänkt där?

Det är två exempel på hur sned standardkonfigurationen är, det känns som att när man paketerar linuxdistributionerna så tänker man “Men vi vill ju inte att servern går omkull, så vi konfar allting lågt”. Jag vet att det är ofta är standardkonfigurationen för applikationen som skeppas, och det spelar ingen roll, det är precis lika skevt och det är inte intressant om det är applikationens konfiguration eller om det är en konfiguration gjord av teamet bakom distributionen, det som påverkas i slutändan är användaren och användarupplevelsen.

I min värld så är det helt snett, att nyttja en server till 50% av sin kapacitet är inte ekonomiskt. Säg att du köpt en server för 20 000, och lite tillbehör för 10 000 så din kostnad för servern är 30 000 och kanske 5 000 / månad (man brukar räkna 5500 som kostnaden för en server / månad med underhåll och patchar) om då bara nyttjar servern till 50% då slänger du ju bort 50% av din investering varje månad, och hur sjukt är inte det? I en ideal värld så vill man utnyttja servern så mycket som möjligt, säg att den ligger på 70% vid normal användning och 100% vid en peak, då nyttjar man både sin investering och den energi som går åt att driva och kyla servern maximalt. Här kan man applicera samma tänk som man använder när man pratar om fördelarna med virtualisering, högre utnyttjande av mindre hårdvara är bättre ekonomi och miljö.

I en del fall är det kanske inte hållbart att köra servern tills den kroknar och går ner, utan man vill försöka hålla maskinen online och vill då ha ett max utnyttjande på 90% vid en peak, oavsett så är nyckeln att se över konfigurationen. Om servern utnyttjas till sitt max, då är det också enklare att se vart i sin applikation man ska optimera, man kanske måste snygga till koden, databasen eller tänka över hela sin design, men det kan och ska man inte göra förrän man är säker på att man nyttjar servern till sitt max, eller åtminstone det max man satt upp som företagspolicy.

Det är irrelevant om servern är en VPS eller dedikerat stål, det är ändå i allas intresse att servern utnyttjas till fullo, eller det är åtminstone i kundens intresse, en VPS leverantör tycker nog inte att 100% nyttjande av 100% av maskinerna är sådär superkul. Men det ger kunden mer bang for the buck.

Kan vi inte enas om att se över våra konfigurationer och se till att vi nyttjar våra maskiner så mycket det går?

När jag kom på att jag skulle skriva det här inlägget så tänkte jag skriva det i en önskelista, “saker jag vill se under 2012″, och en av dom var “Vettigt stöd för delade sessioner i ett kluster”.

Men, allt eftersom jag började läsa så såg jag att det är ju redan löst, med funktionen session_set_save_handler eller direkt i php.ini med memcached, då är det session.save_handler som gäller. Som default så använder PHP files, men det finns inbyggt stöd för memcache och det är superenkelt att aktivera.

session.save_handler = memcache
session.save_path = "tcp://127.0.0.1:11211"

Klart! Nu sparar PHP alla sessioner till din lokala memcacheburk, skulle du vilja spara det på en extern instans så är det bara att ersätta IP-adressen. Memcache är kanske inte helt optimalt för att spara data in, då det har en tendens att crasha och första datan. Så en kombination av (No)SQL och Memcache hade varit ett bra alternativ, SQL för säkerheten och Memcache för hastigheten, med NoSQL som typ MongoDB så kan man skippa Memcache.

I dokumentationen för PHP finns det bra exempel på hur du själv kan anpassa session_set_save_handler för att använda den backend du vill använda. @ChristofferP påpekade att bland annat PHP ramverket Litihum har stöd för alternativa session stores.

Fördelen med att kunna spara sessionen i ett delat storage är att man kan skippa sticky sessions när man lastbalanserar, och balansera jämnare över klustret. Om det är någon som vet om det finns ett smidigt sätt att inkludera sin egen sessionsklass i WordPress, säg till!

Jag har precis haft en massa problem med att min site som är byggd i CodeIgniter slutar funka så fort jag laddar ett library, jag hann testa med Dx_Auth Tank_Auth och Ion_Auth innan jag kom på vad felet var.

Jag saknade paketet php-mysql på min CentOS maskin.

Det roliga i det hela var att varken PHP, Apache2 eller CodeIgniter sa att något var fel, vilket känns lite skumt faktiskt.

Jag har 2 teorier som jag just nu håller på att testa, de rör hur man borde bygga sitt webbkluster för att få maximal upptid och så liten påverkan som möjligt vid bortfall av en server.

Lösningarna ser i princip identiska ut, men skillnaden ligger i om PHP-hanteras av Apache2-modulen för PHP eller om man hanterar PHP via FastCGI. De bygger båda på öppenkällkod och är helt redundanta. I båda ingår också ett MySQL/MariaDB kluster men det finns inte detaljerat då det inte är mitt primära mål just nu.

Lösning 1, Lastbalanserare och X antal apache2maskiner.

I den schematiska bilden ovan är det 2 olika kluster som delar på samma databaskluster, i schemat är inte lastbalanserarna redundanta men det ska de vara. Om en webbserver faller bort i klustret kommer 50% av beräkningskraften att försvinna och vid ev. peak så kommer troligen ett stort antal av besökarna att lämna siten då den går väldigt långsamt, självklart förutsatt att besökarantalet är större än vad en enskild maskin klarar vid bortfallet. I övrigt så finns alla andra fördelar som ett kluster innebär, möjligheten till att ta ner en maskin för underhåll utan att driften av siten påverkas etc. Beräkningskapaciteten i det kluster som fortfarande har båda sina maskiner i drift påverkas inte.

Lösning 2, Lastbalanserare, X antal apache2maskiner och ett FastCGI kluster.

Fördelen med den här lösningen är att, förutsatt att det är likadan hårdvara som i Lösning 1, den presterar bättre på samma antal maskiner. Detta då alla krävande PHP-beräkningar skickas till ett eget kluster. Det innebär att bortfallet av en webbserver i något av klustret inte kommer att påverka prestandan lika mycket. Planerar man och dimensionerar FastCGI klustret rätt och låter två siter som har olika peakar och tider av hög belastning dela FastCGI kluster så kan de dela på samma kluster. Då kan vi överdimensionera klustret något utan att det har kapacitet som står oanvänd ofta.

Det tredje alternativet jag har är att ha ett enda superstort apache2kluster och låta det göra allt. Det kommer krävas väldigt många fler maskiner för det, och maskiner är som bekant en kostnad. Som komplement till både lösning 1 och 2 kan man dessutom ha en funktion som skapar maskiner on-demand i molnet, då behöver man bara ha igång de maskinerna vid peakar och högtrafik.

Mitt senaste projekt är att skriva ett enkelt bibliotek(library) i CodeIgniter för att generera iCalendar(http://en.wikipedia.org/wiki/ICalendar) filer. jag har ännu inte bestämt mig för om den ska generera riktiga filer, eller om jag ska låta den generera allt dynamiskt och bara skicka med lite headers. Det senare är det smartaste alternativet, men jag vet inte riktigt hur det är prestandamässigt. Det hade ju varit smidigt att kunna lagra all data i databasen istället för att hålla på och mecka med filer.

iCalendar är ett öppet och vedertaget sätt att dela kalenderposter, det används i både Outlook och iPhone samt Sunbird(kalender plugin/add-on) för Thunderbird, ett mozilla projekt med andra ord.

Återkommer med mer info när jag har det, planen är att släppa biblioteket som GPL så att alla kan ta del av det:)

När jag säger “data” så menar jag inte en Dator, utan jag menar information, värden, säljsiffror, svar på kundundersökningar, det är data. Data är livsviktig för alla företag, egentligen för alla sorters organisationer, det kan vara medlemsregister, produktlistor eller något så enkelt som träningstider. Vi kan ta ett mer personligtexempel, tänk när du blir av med din mobiltelefon och måste börja knappa in alla nummer från början, det är jävligt tungt, men det är genomförbart. Tänk då att ett företags säljsiffror för ett helt år försvinner, tänk hur mycket det kommer kosta att samla in den datan igen, från kvitton, avtal eller liknande. Det kan vara ett gigantiskt jobb som kostar tokigt mycket pengar.

I ditt eget fall ska du vara glad om du har alla dina kontakter sparade i din Outlook, så du kan synka hem dem via exchange eller liknande.Riktigt så enkelt är det sällan för ett företag, då deras data för det mesta finns sparad på  servern som dog, det kan jämföras med att både din mobiltelefon blir stulen samtidigt som hela företagets exchange exploderar. Det känns enormt långsökt, men det KAN hända, och när det händer vill man inte stå där med fingrarna i gylfen och inte fatta något.

Därför är det enormt viktigt att göra regelbundna backuper på alla sina prylar. På min egen dator använder jag dropbox för att backupa mina filer, det låter mig även komma åt alla filer överallt där jag har internet. På jobbet så sparar vi vår data i databaser, och det virtuella servrarna backas av hostingbolaget. Men vad händer om jag av någon anledning vill göra en återläsning av en databas, för att någon gjort fel någonstans, eller av någon annan anledning? Har jag då ingen backup så är det kört. Dessutom så litar jag aldrig på att backupen görs av hostingbolaget, tänk om deras backupmaskiner strular?

Därför har jag i min jakt på att hitta ett skönt sätt att backupa mina databaser, funnit AutoMysqlBackup ett enkelt script som med mysqldump backar och roterar mina databaser en gång om dygnet. Nu kan jag sova relativt gott om nätterna! Scriptet är väldigt enkelt och straight forward, så jag tror du själv kan klura ut hur det funkar.

Behöver du serverbackup, så rekomenderar jag Danska DmSave de har byggt en grym tjänst ovanpå Tivoli Storage Manager.

För att kunna ge mina användare tillgång till de webbmappar där de ska lagra sina statiska filer i mitt Content Delivery Network (http://www.abergman.se/bygg-ditt-eget-cdn-content-delivery-network/) projekt, behövde jag ett sätt för dem att enkelt ansluta till maskinen, det var tvunget att vara väldigt nedlåst och enkelt att använda.Valet föll på FTP, av den enkla anledningen att det är enkelt, många publiceringssystem har redan stöd för det och i princip alla webbadministratörer kan använda det.

Mitt första val av ftpserver var ProFtpd, då jag använt den i ett annat projekt där jag byggde en helautomatisk hostingplattform med One-Click installation, fakturering, DNS och Ftp-stöd. Dock så fick jag det inte att fungera den här gången, av någon knepig anledning. Hur som helst så hittade jag att vsftp kunde göra samma sak som ProFtpd, nämligen authensiera användare  mot en Mysqldatabas, Vsftp använder sig av tillägget till PAM som kör mot en mysqlserver(pam_sql).

Den här guiden förutsätter att du redan har en mysqlserver installerad.

Installera Vsftpd

apt-get install vsftp

Sedan är det bara att hacka i konfigurationen, som finns i /etc/vsftp.conf

listen=YES

anonymous_enable=NO

local_enable=YES

write_enable=YES

local_umask=022

dirmessage_enable=YES

xferlog_enable=YES

connect_from_port_20=YES

pasv_min_port=63200

pasv_max_port=63204

nopriv_user=cdnuser

chroot_local_user=YES

secure_chroot_dir=/var/run/vsftpd

pam_service_name=vsftpd

guest_enable=YES

guest_username=cdnuser

local_root=/var/cdn/$USER

user_sub_token=$USER

virtual_use_local_privs=YES

Jag valde att använda mig av användaren cdnuser för att köra FTP-servern, viktigt är också att notera raden: pam_service_name=vsftpd, det är det namn som pam kommer använda för att avgöra vilken konfigurationsfil den ska använda. Som synes på raden /var/cdn/$USER så finns alla användares hemkataloger under /var/cdn/$USER där $USER såklart är en variabel för användarnamnet, det gör att jag inte behöver ange vilken arbetsmapp användaren ska ha utan det sköts automatiskt. Av den enkla anledningen finns det bara två kolumner i tabellen som styr användarna.

Sätta upp databasen

Skapa en databas som heter “vsftpd” med en tabell som heter “accounts” med nedan kolumner:

+----------+-------------+------+-----+---------+----------------+

| Field    | Type        | Null | Key | Default | Extra          |

+----------+-------------+------+-----+---------+----------------+

| id       | int(11)     | NO   | PRI | NULL    | auto_increment |

| username | varchar(30) | NO   | UNI | NULL    |                |

| pass     | varchar(50) | NO   |     | NULL    |                |

+----------+-------------+------+-----+---------+----------------+

En ny användare skapar du med: INSERT INTO accounts (username, pass) VALUES(‘USERNAME’, PASSWORD(‘PASSWORD’));

Konfigurera PAM

Sista saken som ska konfigureras innan vi är klara, PAM. Glöm inte att backup:a orginalfilen innan du skapar den här konfigurationsfilen /etc/pam.d/vsftpd

auth required pam_mysql.so user=DBUSER passwd=DBPASSWORD host=DBHOST db=vsftpd table=accounts usercolumn=username passwdcolumn=pass crypt=2
account required pam_mysql.so user=DBUSER passwd=DBPASSWORD host=DBHOST db=vsftpd table=accounts usercolumn=username passwdcolumn=pass crypt=2

Glöm inte att ändra databasanvändarnamn, lösenord och host samt skapa en mapp i /var/cdn som motsvara användarens lösenord och som ägs av samma användare som FTP-servern körs som!

Den här guiden är löst baserad på en annan bloggares post, men jag kan inte hitta URL:en just nu, säg till om du hittar den!

Ligger du inne med en massa hemsidor? Eller har du många kompisar som bloggar? Eller vill du tjäna lite stålar?
Då kan det vara en idé att sätta upp ditt egen annonsnätverk och hjälpas åt att dra lite trafik, att göra det är inte helt enkelt men med hjälp av mjukvaran OpenX (http://www.openx.org/) så blir det hela mycket enklare.

OpenX är OpenSource och är byggt i php och kan köras på ett antal databaser, bland annat MySQL och PostgreSQL. Installationen är enkel och gå relativt fort, den sköter allt utom rättigheter på filsystemet åt dig, det enda du behöver är ett lösenord till databasen. Jag genomförde installationen på ca 10 min och efter ytterligare 10 hade jag fått igång min första kampanj och lagt upp två fula banners.

Något som förvirrade mig var att det tog tid innan själva bannern/zonen kom igång, men det visade sig efter att ha bytt till administrators-vy uppe i det högra hörnet att systemet har en cache på bildfilerna, därav fördröjningen.

Jag märkte medan jag testade systemet att det är lätt att maskinen blir belastad, då det kommer ett anrop till maskinen någon av siterna som har en banner laddas, så det kan bli potentiellt mycket trafik på maskinen, så jag rekomenderar rejält med ram i burken.

Värt att nämna är att OpenX har en market/auktion som man automatiskt kan publicera sina zoner på, så man kan tjäna pengar på att sälja pengar via deras market, utan att egentligen göra något själv, självklart så är det valfritt att släppa ut sina zoner på marknaden.

Jag kommer kika vidare på systemet och det kommer säkert komma upp något mer om det längre fram.