Andreas Bergman

IDG.se som kanske inte alltid levererar kvalitetsjournalistik publicerade idag en artikel om att Debian toppar som OS på linuxservrar, inte särskilt oväntat tycker jag. Debian har rykte om sig om att vara väldigt anala i vilka paket som släpps vidare till stable, och det är på gott och ont, visst paketversionerna kanske inte är dom senaste, men samtidigt så funkar det jävligt bra.

CentOS kommer som tvåa, och det är inte särskilt förvånande, om Debian är en liten och smidig F1 maskin så är CentOS mer som en jäkligt robust pansarvagn att jobba med, jag tycker att den känns enormt solid och paketformatet RPM är väldigt lättarbetat och tenderar att lösa dependencyproblem bättre än APT.

Vill du läsa artikeln finns den här: www.idg.se/2.1085/1.425993/debian-toppar-pa-linuxservrar

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?

Nginx och PHP-FPM har blivit något av en standard för högtrafikerade webbsidor, kombinationen en lättviktig webbserver och en vertikalt skalbar scriptmotor med relativt litet avtryck gör att det är ett prisvärt och smidigt sätt att driva sin webbsida.

Av någon anledning så kommer dom flesta linuxdistributioner, och de programpaket som skeppas med en minimal konfiguration, vilket gör att man ganska snabbt stöter på problem och flaskhalsar på grund av lågt satta begränsningar i operativsystemet.

En av de begränsningar man stöter på är att antalet tillåtna file descriptors (FD) för användaren som webbservern och eller PHP-FPM körs som är för lågt satta. Debian 6 skeppas med 1024 file descriptors / användare, och maxantalet i systemet brukar vara runt 3 miljoner. Exakt vilket antal FD man bör ha på användaren är svårt att säga, men förutsatt att servern inte kör fler applikationer än Nginx och PHP-FPM så kan man ta i ganska rejält, på en stor installation jag jobbar med så har användaren en gräns på runt 300 000, men jag kan inte se något fel i att öka den ännu mer.

Att felsöka filedescriptors

Till att börja med så vill man veta hur många FDs som systemet får ha som mest.

# sysctl fs.file-max
fs.file-max = 70000

Nu vet vi att systemet som mest kan ha 70 000 FDs. Hur många FDs används då?

#sysctl fs.file-nr
fs.file-nr = 1020 0 70000

Där 1020 är antalet aktiva filer (file handles), 0 antalet allokerade men inaktiva filer, och 70 000 är max antal. För att ta reda på max antal FDs för en specifik annvändare, logga in som användaren och kör:

#ulimit -Sn
1024
#ulimit -Hn
1024

ulimit talar om för dig hur många FDs som användaren får lov att ha öppna, 1024 är lagom för de flesta, men har du högt trafikerade servrar så kommer du behöva höja, det gör du genom att ändra gränsen i /etc/security/limits.conf

abergman                soft    nofile          65535
abergman                hard    no file          65535

Det gör att min användare, abergman får lov att ha 65535 file descriptors, för att ändringen ska slå igenom så måste webbservern och PHP-FPM startas om.

Referenser för dig som vill läsa mer, även ett stort tack till Tom för att han pekade mig i rätt riktning vad gäller mod_limits i PAM.
http://www.cs.uwaterloo.ca/~brecht/servers/openfiles.html
http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/
http://research.cs.wisc.edu/condor/condorg/linux_scalability.html

För att förhindra att PHP-filer i en mapp kan exekveras av Apache2s mod_php, lägg till följande i .htaccess

<Directory />
php_admin_flag engine off
</Directory>

Där sökvägen motsvarar sökvägen till mappen du vill förhindra exekvering i.

Att idag ha en webbserver som bara lyssnar på IPv6 är rent ut sagt korkat, för alldeles för få människor surfar i Ipv6 rymden. Dock så tycker jag att det är var mans skyldighet att stöjda IPv6 i sina tjänster, så därför bör din server lyssna både på IPv4 och IPv6.

För att uppnå detta i Apache2 så måste man skriva två olika Vhostar, en för IPv4 och en för IPv6, där den enda skillnaden är vilken adress vhosten lyssnar/binder på. Glöm inte att infoga IPv6 adressen i brackets.

Exempel:

<VirtualHost [2a02:750:5::5b2]>
ServerAdmin webmaster@example.com
ServerName www.example.com
ServerAlias example.com

Google, som försett internet med grymma tjänster som Gmail och adsense och det fenomenala verktyget Pagespeed. Som ett komplement till sistnämnda har det nu även släppts en modul för Apache2(2.2 och senare) som ska underlätta för administratören att få bra krut i siten. Personligen kan jag tycka att det är ännu ett bevis på att en snabb site bäst uppnås genom att optimera både kod och plattformen som siten körs på.

Än så länge så kan inte mod_pagespeed kontrolleras från en .htaccess-fil, men enligt det här länken så verkar det vara på gång vilket skulle vara ett stort steg i rätt riktning mot att göra användarupplevelsen på internet ännu bättre! Men som jag sa så måste det till mer än bara en servermodul för att det ska bli bättre, alla måste ta tag i sina siter också.

För att installera modulen så måste du manuellt installera en .deb fil med dpkg -i, men bra instruktioner finns på http://code.google.com/p/modpagespeed/

Behöver du hjälp med att konfigurera mod_pagespeed på din server så kan jag hjälpa dig!

Första utkastet till TrunkFish KVM Control är nu klart, det är inte mycket för världen, men ett steg i rätt riktning!

I forstsättningen av mitt test av en Oderland VPS, där det första intrycket var väldigt gott, fortsätter Oderland att leverera.

Kickstart

Den VPS jag fick var installerad med CentOS, inte någon personlig favorit efter mitt krossade hjärta i den här posten: http://www.abergman.se/oderland-vps/. Men som den vänliga själ jag är så gav jag det ett försök och kort sag: Det bara funkade. Inget meckande med VNC-sessioner för att få igång en SSH server eller annat trams. Apache2 var av någon anledning också installerat, men det kanske är en feature nu för tiden? För det var Apache2 installerat på Debianserver samt den Debian Testing jag installerade lokalt senare under kvällen. Varför man väljer att göra så fattar jag inte, men i sammanhanget så verkar det relativt logiskt.

Ominstallation

Som alla andra VPS-leverantörer med självrespekt så låter Oderland kunden själv installera om OSet om den vill, och det finns en hel del linuxdistar att välja på tex debian, fedora gentoo och en CentOS maskin anpassad för DNS med en cPanel installerat. Jag har inte testat den, men bra tänkt! Jag ominstallerade min maskin med Debian, och det gick fort, jösses va fort det gick! En feature jag inte riktigt bestämt mig för om jag gillar eller inte är att den nya maskinen fick samma rootlösen som min första maskin. Det finns en funktion i kontrollpanelen för att byta rootlösen, och jag antar att de sparar lösenordet för senare användning. Jag ser både för och nackdelar med det, vill jag verkligen att min VPS-leverantör ska spara mitt rootlösen?

Det enda jag direkt har att anmärka på var att apt-källorna inte var uppdaterade när maskinen startade, men det är att vara anal att kräva det.

Backup

Oderland har två backupmetoder, express och central. Expressmetoden gör en backup och placerar filen i din VPS och Central sparar kopian i Oderlands nas. Att göra en centralbackup tog mig inte mer än 5 min och det enda som krävdes var ett klick, som jag fattar det så ingår det även en (1) central backup i månadskostnaden. Att läsa tillbaka backupen efter en rm -rf / på maskinen var lika enkelt och gick lika snabbt.

Allmänt

Generellt så känns maskinen sjukt snabb, och linan in till maskinen är riktigt snabb, jag har inte kollat exakt men jag brukar vara ganska kräsen. Det verkar inte vara några problem med  responstiden eller något packetloss.

Jag har nu ett par dagar försökt få igång XEN på Debian och Ubuntu, men det har inte gått särskilt bra. Främst av det enkla skälet att Ubuntu uttalat sagt att man väljer att inte aktiva supporta XEN utan KVM. Varför det inte funkar i Debian kan jag inte svara på, men troligen för att XEN enligt rykten är väldigt svårt att underhålla i paketform, om det är sant eller inte låter jag förbli osagt.

Hur som helst så var det kalasenkelt att installera KVM i Ubuntu, så nu lirar det utan problem på laptopen. Visst det kanske inte är det ultimata att installera KVM på en laptop, men det funkar! Nu ska jag börja koda på någon form av webbgränssnitt för att styra KVM, tyvärr så verkar det inte finnas några riktigt bra PHP bindningar för libvirt, men jag har hittat det här (phplibvirt) som ser ut att supporta det jag vill ha.

Jag hade en nyfunnen kärlek för CentOS, allt bara funkade och det var så fantasiskt bra att arbeta med, tills jag skulle försöka få igång XenApi på min server.

Efter att ha försökt i evigheter att få igång det, jag provade ansluta lokalt,remote startade om server och allt annat jag kunde komma på. När jag i min irritation och förtvivlan hittade den här tråden: https://bugzilla.redhat.com/show_bug.cgi?id=310051 efter att ha kontrollerat paketversionen på XEN i min installation så insåg jag att det här var anledningen till att det inte funkade.

För att sammanfatta, det kommer inte finnas något XenApi i RHEL 5, då det är för mycket jobba att skriva om xen userspace som är baserat på XEN 3.0.3 och i den versionen finns inte XenApi med, och eftersom CentOS är RHEL fast i communityversion så lär knappast den funktioner implementeras.

Kvar stod jag med en klump i magen och en känsla av hopplöshet, men som en 16 årig pojke på rebound så installerade jag debian och som i en dröm så bara fungerade det.