Andreas Bergman

Igår fick jag ett offertunderlag på ett webbsystem, ett väldigt bra underlag faktiskt, tydligt och bra. Som så många andra underlag så finns det backup kravställt, offsitebackup såklart.

Men en sak man ofta missar när man kravställer backup, det är att kravställa återställningstid och att det faktiskt går att återställa backupen. Säg att du backar 100Gb data över internet, för det mesta så skickar du ju bara förändringar vilket gör att volymen på backupkontot bara ökar, vilket blir en flaskhals sen när du ska återställa det, hur lång tid tror du att det tar att återställa 100Gb över internet? Självklart så beror det på linan, men det tar sin lilla stund oavsett.

Så, en uppmaning till alla: Kravställ att din backup ska kunna återläsas och att det finns en högsta återställningstid, du kommer att tjäna på det när du väl vill göra en återställning.

Idag den 10/1 hade Mikroprojekt.se sina första minutes of fame, men självklart så är det något som ska strula.

Men i det här fallet så var det inte Microprojects fel, utan deras webhotell MelMac hade ett major breakdown, varför kan varken jag eller Mikroprojekt svara på, men klockan är nu 15.00 och Mikroprojekt.se går fortfarande inte att nå och inga noteringar syns MelMacs hemsida.

Lär av andras misstag, och välj en “stor” hostingleverantör som har gott rykte, det kanske är lite dyrare, men jag lovar att det kommer löna sig i längden!

Ser ju bra ut! Men det var nog lite för många sekunder sen som grejerna kollades..

Jag har i dagarna letat efter en ny mailtjänst till en kund, och när jag kollar på www.google.com/a så ser det ut som att Google Business blir en betaltjänst helt och hållet, har jag fel?

Edit.. nej så är det ju såklart inte, här finns info om gratisvarianten: http://www.google.com/apps/intl/en/group/index.html

Phew!

Men det jag egentligen ville komma till, det är att City Network inkluderar mailhosting i alla sina domänkonton, det ni!

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.

Ett stort aber för många företag att använda molnet är känslan av inlåsning, många leverantörer använder olika lösningar och de är allt som oftast inte kompatibla med varandra. En del dominerande tekniker på marknaden har stöd för att migrera ut och in ur liknande system, tex e-postlösningar som bygger på Microsoft Exchange, där är det relativt enkelt för kunden att begära ut sina brevlådor som .pst och sedan importera dessa i en annan exchangeserver, Gmail har även ett migreringsverktyg för de användare som använder Google Apps (Standard, Premium eller Education). Skulle det inte finnas färdiga verktyg så kan man relativt enkelt koppla upp sig mot de flesta e-posttjänster via POP eller IMAP och migrera mailen manuellt i en mailklient.

Hur är det då med server och VPS-lösningar? Går det att på ett enkelt sätt migrera sin maskin från en leverantör till en annan?

Read the rest of this entry »

Servermarknaden idag svämmar över av VPS-tjänster, en del är identiska med varandra och det enda som skiljer är stabilitet och driftbolag, andra är unika och erbjuder enkel skalning på alla håll och kanter. En del driftas i någons källare medans andra körs på cutting edge HA-teknik.

En sak har de dock gemensam: Fixa allt själv.

En VPS är i princip en GDS(Gör-Det-Själv)-hall fast för servrar, självklart så finns det en del VPS-tjänster som låter dig installera nya funktioner med ett klick eller två, men majoriteten har det inte. Det finns en aspekt till man måste ta med i beräkningen: säkerhet, både driftsäkerhet och säkerhet mot intrång. Hur många VPS-ägare har regelbundna servicefönster och gör sina uppdateringar regelbundet? Eller har tillräckligt säkra lösenord på ssh-demonen / RDP? Till det här kan vi också lägga frågan: Vem driftar din server när du sover eller dricker öl?

Enligt ovan domedagsresonemang så är alltså en VPS ett dåligt alternativ till vanlig shared hosting, men självklart så behöver det inte vara så. Många av de som levererar VPSer har en tjänst som heter “Managed VPS” det innebär att de låter sina egna systemtekniker utföra regelbundna uppdateringar av din server och andra saker du vill ha gjorda. Det finns två fördelar med det, företaget kan dra in pengar på personal som annars antingen käkat kakor eller gjort något annat när de hade lite tid över i sin tjänst, de erbjuder även kunden en säker och flexibel egen server.

Som jag tror att jag skrivit i några andra inlägg så är tid pengar, och för den som vill ha eller behöver en egen server men inte har tid att sätta sig in i hur det funkar, så rekomenderar jag alltid att ta en managedtjänst, antingen om man köper in det från en extern konsult som jag själv eller om man tar in det via driftsbolaget, det spelar ingen roll. Man får en säker och driftsäker server till ett vettigt pris och kan fokusera sig på sin kärnverksamhet. Hur mycket tycker du att din tid är värd?

En annan biprodukt är att du kan få din server uppdaterad på tider då det är lågtrafik, utan att du själv måste sitta uppe och göra det, kompletterat med en övervakningstjänst så får du samma driftstabilitet som med shared hosting.

Alltså: Sluta mecka med din server, köp in kompetensen och tjäna mer pengar.

Jag har i min jakt på bra och opensourceade monitoringsystem nu sprungit över ett projekt som heter shinken (http://www.shinken-monitoring.org/), jag har inte hunnit testa det än, men det står på min agenda och kommer att fixas efter att jag gett mig på CityCloud, Op5 och Centreon.

Vad jag kan se så är Shinken byggt helt från grunden i python, men man har valt att göra konfigurationen på samma sätt som i nagios och icinga, vilket på många sätt är perfekt för då blir det enkelt att byta plattform. Inte för att byta övervakningsplattform är något man gör i en handvändning, men produkter som underlättar jobbet är alltid välkomna.

När man har byggt Shinken så har man fokuserat på att göra det skalbart och distribuerat, och det ser ut att vara enkelt att  skala upp och ner vid behov. Precis hur enkelt det är får vi ser när jag bestämmer mig för att testa det. Tills dess finns det mer att läsa på  http://www.shinken-monitoring.org/ och http://en.wikipedia.org/wiki/Shinken_%28software%29

I flera år har det pratas om IPv6, mer eller mindre intensivt, men man pratar om det mer eller mindre. Enligt en artikel jag läste på nätet så har många företag slutat bli skrämda av ropen om att IPv4 adresserna ska ta slut, kanske inte så konstigt egentligen. En bidragande faktor till att det runnit ut i sanden kan också vara att det verkar dröja innan bredbandsleverantörerna får ut IPv6 till slutkunderna.

När man implementerat IPv6 så har man varit medvetna om problemen med migrationen, det finns gott om verktyg för att konfigurera en uppsjö av plattformar till att prata IPv4 och IPv6 parallellt, däribland 6to4. Dessutom så är 6to4 relativt enkelt att använda, för att göra det ännu enklare har Teredo utvecklats, för användaren är resultatet det samma som med 6to4 men konfigurationen och hur det fungerar bakom kulisserna är något annorlunda, för att använda teredo i linux så finns paketet Miredo tillgängligt, i bla Ubuntu finns det med i standardförråden.

Fler och fler tjänsteleverantörer har börjat erbjuda IPv6 för sina tjänster, det är ett stort steg i rätt riktning. Ju fler hemsidor och webbtjänster som ligger på IPv6 desto fortare kommer övergången på internet att gå. Så vill du vara en föregångare och framtidssäkrad så rekomenderar jag att du börjar fundera på att gå över till IPv6, behöver du hjälp så kan du skicka ett mail till mig.

Nackdelar

Självklart så finns det nackdelar med alla tekniker, en av dem som man pratat om i samband med IPv6 är att de blir större overhead eftersom en IPv6 adress innehåller mer data än en IPv4 adress. En branch som kan komma ha problem med det är svartlisteoperatörerna, deras lagrade datamängd kommer att öka.

Det kommer att kosta massvis med pengar att anpassa all infrastruktur till IPv6, tänkt bara för ett stort bolag som Coop, det är massvis med utrustning som måste ställas om.

Fördelar

DHCP-löst, IPv6 har tillståndslös autokonfiguration.

Multicast är en del av specifikationen, QoS finns det uttalat stöd för prioriterad trafik.

Testa IPv6

För att testa om en sida stödjer IPv6 kan du i linux använda ping6, och efter lite empiriska undersökningar så visar det sig att varken facebook,google eller DN stödjer IPv6, däremot så gör zfs.se det.

Vad finns det då för mening med att stödja IPv6 när ingen av giganterna gör det? Det är enkelt, genom att alla “mindre” siter börjar stödja IPv6 så ökar medvetenheten hos giganterna och det skapar ett tryck. Dessutom så  underlättar det när det väl är dags att fasa ut IPv4, då har man redan vant sig vid att jobba med IPv6 och det blir ingen gigantisk övergång, och arbetsinsatsen blir minimal.

Leverantörer som kan leverera IPv6 för sina tjänster

För att promota de leverantörer som kan leverera IPv6 till sina tjänster så bjuder jag här på namn och länk. Vill du också stå med? Skicka ett mail till andreas@abergman.se

CityCloud

Oderland Webhotell

Både CityCloud och Oderland jobbar på att implementera IPv6 för sina tjänster inom kort.

Loopia

Loopia har redan börjat köra sina kundportaler och www.loopia.se på IPv6, men om deras egna tjänster klarar IPv6 framgår inte.

Op5 är kanske den enda kommersiella uppstickaren på marknaden som bygger sin lösning kring Nagios, vilket är samma bas som Icinga bygger på.

Nu har Op5 släppt version 5.2.0 av Op5 Monitor, och ska man tro pressreleasen så är den helt fantastisk, men det är ju klart, den bygger ju på nagios! Man har bland annat utökat stödet för distribuerad övervakning och klustring.

Läs hela releasen här: http://blogs.op5.com/blog/2010/11/op5-monitor-5-2-0-released/

När jag skrev titeln till det här inlägget så blev jag så förbaskat nöjd att jag var tvungen att sno den och använda som tagline, för den sammafattar precis vad det här med internet det handlar om. Att ALLTID vara, inte nödvändigtvis att du personline är online, men din site, dina system, din blogg. Den ska och måste ALLTID vara online. Inte nog med det, den måste ALLTID ha en bra responstid. Det kan tyckas vara hårt att jag säger så starka ord som alltid och måste, men den bittra sanningen är att du måste ha nära på 100 % upptid och snabb responstid.

Varför är det så så?

Det är egentligen inte så konstigt att det är såhär, internet idag är översvämmat med skit, värdelösa siter och meningslöst dravel. Ett sätt att urskilja sig från dessa internets avskum, är att se till att alltid vara uppe och alltid ha en bra responstid. Självklart så kommer det i sig inte göra dig till internets härskare, men det kommer ta hjälpa dig en bit på traven. Du kommer automatiskt att tappa besökare om din site går långsamt. Framförallt kommer du att tappa dem som egentligen inte vill läsa din site.

Ett annat bra argument för att ha en vrålsnabb hemsida som alltid är online är helt enkelt för att dina besökare förväntar sig det, se bara på hur mycket väsen som fördes när dn.se låg nere pga systemfel? Det är tonvis med dålig publicitet, eller när polisens hemsida vara nere på grund av en DDos Attack, massor med dålig publicitet och badwill. Ett annat exempel som är bra är blocket.se där man är medvetna om att en långsam sida kommer att göra så att folk går någon annanstans. Det faktum att folk struntar i din sida bara för att det när långsam kan nog alla känna igen sig i, jag läser tex aldrig aftonbladet eller expressen, för att det går så sjukligt långsamt, sen om det beror på alla annonser eller inte, det spelar ingen roll.

Vad kan man göra åt det?

Vad kan du som enskild webbmaster göra åt att din sida går långsamt då? Det finns en uppsjö av grejer man kan göra, som man kan göra själv eller låta någon annan göra, det beror ju lite på budgeten.

* Optimera din sida
Optimera din kod, se över dina SQL-satser försök att hitta flaskhalsar där det går långsamt, kanske har du en annons som tar lång tid att ladda in som förstör användarupplevelsen?

* Håll koll på dina grejer
Håll koll på hur din hemsida presterar, det är det enda sättet att veta om dina åtgärder gör någon nytt, du får svart på vitt siffror på att det blir bättre, eller sämre. Tjänster som kan hjälpa dig med det listas längst ner på siten.

* Välj en leverantör som presterar bra
Välj en leverantör som är välansedd, som har bra avtal och garantier för din upptid och responstid, och som kan och vill hjälpa dig när du har gott om trafik, kanske din sida kommer med i tidningen?

Förekom istället för att förekommas.

Arbeta långsiktigt istället för att tänka kortsiktigt, välj bra leverantörer, håll koll på din avtal så att du en dag står där med en utgången domän eller SSL-certifikat. Övervaka dina servrar om du hostar / driftar dem själv, så du vet hur mycket diskutrymme du har kvar eller när minnet börjar tryta pga för hög last.

Tjänster och verktyg för att mäta din hemsidas prestanda.

www.pingdom.se - Pingdom skickar lite http-trafik med jämna mellanrum från olika delar av världen och visar snygga grafer på upptid och responstid.

Fiddler2 – Fiddler är en proxy som hjälper dig att debugga och mäta tiden det tar att ladda din sida på klienten.

Google Page Speed - Google Page Speed är ett Firefoxtillägg som precis som fiddler hjälper dig att analysera en sites prestanda på klienten.

Domainz.se - Domainz är ett verktyg för att hålla koll på dina domäner.