Iværksætterforum kiksede opgradering: »Vi er nogle impotente grødbønder«

Iværksætterhjemmesiden Amino.dk blev onsdag ramt af nedetid, da en serveropgradering gik galt. Udviklingsafdelingen valgte den forkerte SQL Server-installation.

»Som Egon Olsen ville have sagt er vi nogle hundehoveder og hængerøve, lusede amatører, elendige klamphuggere, latterlige skidesprællere, talentløse skiderikker, impotente grødbønder, småbørnspædagoger og socialdemokrater.«

Der er tilsyneladende intet galt med evnen til at indrømme egne fejl hos folkene bag iværksætterforummet Amino.dk, hvor danskere med startup-planer kan mødes og diskutere.

En serveropgradering gik natten til onsdag galt, og derfor er hjemmesiden, der har flere end 100.000 brugere om måneden, lige nu nede. I stedet mødes brugerne af ovenstående meddelelse.

Amino.dk er sat i verden af iværksætteren Martin Thorborg. Han fortæller til Version2, at den nye server er indkøbt, så hjemmesiden bedre kan klare presset fra et stigende antal brugere. Men den fik en kikset debut:

»Vi har planlagt opgraderingen i et stykke tid sammen med vores filippinske udviklingsafdeling (webfirmaet 1902, red.), og alt så ud til at gå glimrende i går, så folk gik glade i seng,« siger Martin Thorborg.

Den nye server er en 64-bit Intel Xeon-server med 64 gigabyte ram, hvilket er dobbelt så meget som forgængeren. Samtidig har Amino-folkene valgt at opgradere databasen fra Microsoft SQL Server 2008 til SQL Server 2012 Professional.

Kom til at vælge 32-bit

Og det var her, det gik galt, for udviklingsafdelingen kom til at vælge installationsmediet med 32-bit-versionen af softwaren.

Dermed ramte serveren hurtigt et loft på fire gigabyte allokeret hukommelse, da den gik i luften, og brugerne begyndte at tikke ind.

»Normalt er vores svartider på 2-3 sekunder, og her var de på et tidspunkt oppe på 40 sekunder. Så vi kunne enten køre videre og lade folk blive rasende eller tage sitet ned, og så lave arbejdet færdigt« siger Martin Thorborg til Version2.

Sådan så Amino.dk ud tidligere onsdag. Sitet kvitterede for brøleren ved at lægge en video, der normal er for medlemmer, gratis ud. (Skærmbillede)

Arbejdet med at installere 64-bit-versionen af SQL Server 2012 er senest færdigt klokken 18 i dag, forklarer Martin Thorborg, og sandsynligvis noget før.

Dermed skulle Amino.dk være tilbage til sit vante jeg - omend i en hurtigere version - senere onsdag.

Hvad siger brugerne? Har I fået nogen klager?

»Vi har fået en smule, men folk tager det generelt stille og roligt. De ved, at vi gør en hæderlig indsats. Vi har kvajet os og gør, hvad vi kan for at rette det op,« siger Martin Thorborg til Version2.

Opdatering klokken 14.54: Amino.dk er nu oppe igen.

Kommentarer (24)

Jens Jönsson

I sådan en situation med noget så kritisk, så havde jeg valgt at lave øvelsen i et lukket miljø. Her ville virtualisering være oplagt. Eksisterende system kunne nemt P2V ind som virtuelle maskiner man kunne opgradere på og lave drejebog efter, før man begyndte på produktionsmiljøet.

Virtualisering har reddet mig rigtigt mange gange i tilsvarende øvelser, hvor produktionsmiljø skal opgraderes...

Ronny Jakobsen

Ja og en virtualiseret SQL server har så tit gjort mit arbejde ulideligt.... En SQL server lader sig bare ikke lige virtualisere, på grund af det forholdshvis høje krav til diskene.

Jens Jönsson

Ja og en virtualiseret SQL server har så tit gjort mit arbejde ulideligt.... En SQL server lader sig bare ikke lige virtualisere, på grund af det forholdshvis høje krav til diskene.


Som med alle løsninger, så hænger det sammen med hvordan det skrues sammen. Jeg har lavet flere virtualiserede SQL servere, som performer rigtigt godt (Set ifht. at lave løsningen ikke virtualiseret).
Nu har diskene som sådan ikke noget med virtualiseringsdelen at gøre. Men det er klart at hvis diskene ikke matcher den performance du ønsker, ja så vil du få et problem.

Men hvis du ved hvad du gør er der ikke de store problemer med at virtualisere SQL. F.eks. har Microsoft masser af gode whitepapers med råd til at virtualisere deres SQL Server.
Jeg vil tro at andre SQL server producenter har nogle tilsvarende....

Mht. til denne artikel, så var det nu heller ikke fordi at Amino skulle virtualisere deres SQL server i produktion. Det var kun for at få en kopi af produktionsmiljøet, som de kunne øve opgraderingen på.
(Her er snapshot funktionen rigtig brugbar)....

Peter Nilsson

MS SQL server kører fint på en virtuel server, men alt kører selvfølgelig bedre hvis det ikke er virtualiseret, dog er det altid mere fleksibelt med et virtuelt miljø, så det vil jeg altid foretrække og så leve med det performancetab der er. Hændelsen med at vælge en 32bit SQL på en 64bit server er såmænd bare en tanketorsk som vi alle kunne have lavet når man arbejder sent og bliver træt, så sker der bare sådan nogle fejl og nogle gange så har det store konsekvenser, det er sådan man lærer ;-) fedt nok at Martin står frem med den egentlige årsag, det er bedre at være ærlig om sine fejl end at pakke dem ind i lange søforklaringer for at lyde klog....resultatet kan jo alligevel ikke være anderledes og hvorfor så ikke bare være lidt pragmatisk og grine lidt af det hele...og så lære af den fejl så det ikke sker igen.

Thomas Rasmussen

Som jeg ser det, så har virtualisering ikke en døjt at gøre med dette problem... Når man bygger en server med den forkerte udgave af softwaren og migrere over på denne uden at opdage fejlen, så er det fuldstændig ligegyldigt om det havde været virtualiseret eller ej, opgaven med at genopbygge serveren på korrekt software er ligeså stor, måske spare man en smule tid ved at have en template i sit virtualiseret miljø som har base-OS installeret.

Der hvor amatørerne kommer ind i billedet er at man lade en udviklingsafdeling stå for driftsmæssige ting! Når man er så fancy at have en udviklingsafdeling så bør man sgi også have lavet en driftsafdeling som står for idriftsættelse af produktionsændringer... Risikoen for at en driftsafdeling ville have begået samme fejl er naturligvis stadig til stede, men lur mig om ikke den ville være fanget... der er hvert fald noget processmæssig arbejde der er blevet håndteret helt forkert

Morten Borg

Spørgsmålet som artiklen efterlader mig med, er hvorfor hulen Microsoft overhovedet laver en 32-bit udgave af SQL Server 2012? Windows Server 2012 er jo eksempelvis gået 64-bit only.

Nej, vent, jeg er også efterladt med spørgsmålet om hvorfor Version2 laver en så tynd artikel. Kan vi forvente artikler om alle nedbrud på alle mindre sites?

Peter Anker

Det lyder som om Amino er klar til at komme i skyen, f.eks. på Microsoft Azure. Slut med alt det pjat med selv at installere og vedligeholde servere og software. Og så skalerer det i takt med antallet af brugere - win-win? ;)

Michael Mortensen

Jeg tror faktisk ikke Windows Azure ville være en hjælp for Amino.dk - grundlæggende er det min vurdering at dette website bruger SQL serveren rigtig meget; hertil er Windows Azure ikke en hjælp - tværtimod.

Der hvor Windows Azure kommer til sin ret er på moderne websites, hvor antallet af SQL forespørgsler er holdt på et minimum .. med mindre du vil ud i SQL Azure Federations hvor du efter min mening ganske voldsomt komplicere din datamodel og fordyre din løsning unødigt.

Når det er sagt så har Windows Azure mine varmeste anbefalinger .. det virker og oppetiden er i en klasse for sig .. altså så længe du ikke har mange opdateringer eller skrivninger af data grundet multi-tenant modellen i SQL Azure; her vil en dedikeret, rigtig opsat SQL server altid kunne vippe Azure af pinden.

Sidst men ikke mindst; Windows Azure skalere ikke automatisk .. det kræver en del kodning for at opnå dette og i Amino's tilfælde tror jeg igen ikke det vil gavne grundet det antaget store SQL server brug (det nytter jo ikke noget at have 10 frontends der belaster SQL serveren - det kan hurtigt ende med throttling issues hvor SQL Azure serveren simpelthen lukkes ned midlertidigt for at beskytte de andre "lejere" (been there - done that) .. det giver en lidt lun fornemmelse i kroppen :-)

Dertil skal det endeligt siges at SQL Azure handson er godt og vel en faktor 4 langsommere end on-premise SQL Server.

Pelle Söderling

Angående Windows Azure så var jeg også varm fortaler for det før i tiden, men efter at have lanceret en større løsning på platformen er jeg mindre imponeret. Først og fremmest havde vi dårligere oppetid end hvis løsningen havde været hosted på et alm. setup, hvorved en del af ideen ryger. Vi oplevede 3 nedbrud indenfor 3 måneder hvor der var tale om driftproblemer i Microsofts servercenter (Dublin) - den ene gang var det så alvorligt at det var et af deres 3 SANs der stod af hvilket var nok til at vi havde næsten et døgns nedetid før de fik styr på det igen. Det er ikke godt nok når oppetid er et af de væsentligste argumenter for at drifte løsninger i skyen.

Derudover kørte vi med instrumentering på vores server og kunne konstatere store spikes på SQL Azure kald, ofte ville den svare på forespørgsler på 10ms (hvilket i sig selv er forholdsvis højt), men jævnligt ville vi se spikes helt op omkring 2+ sekunder hvilket rent faktisk påvirkede brugernes oplevelse af løsningen.

Vi endte med at rykke hele løsningen til et normalt setup hosted i Tyskland og alt kører som det skal nu uden spikes, så problemet var ikke i vores løsning, men i Windows Azure's setup - derudover er de servere vi har købt til færre penge om måneden end vi brugte hos Windows Azure, så kraftige at vi faktisk performer næsten 10 gange bedre på alt end vi gjorde med den største instans-type på Azure (hvor bl.a. I/O burde være højere prioriteret). Vi brugte 6000 kr/mnd på Azure, nu har vi det hele hosted for 3500 kr/mnd istedet.

Jeg ville enormt gerne se Windows Azure virke, jeg synes konceptet er super fedt, men det virker desværre ikke til at være helt modent endnu.

Michael Mortensen

Angående Windows Azure så var jeg også varm fortaler for det før i tiden, men efter at have lanceret en større løsning på platformen er jeg mindre imponeret. Først og fremmest havde vi dårligere oppetid end hvis løsningen havde været hosted på et alm. setup, hvorved en del af ideen ryger. Vi oplevede 3 nedbrud indenfor 3 måneder hvor der var tale om driftproblemer i Microsofts servercenter (Dublin) - den ene gang var det så alvorligt at det var et af deres 3 SANs der stod af hvilket var nok til at vi havde næsten et døgns nedetid før de fik styr på det igen. Det er ikke godt nok når oppetid er et af de væsentligste argumenter for at drifte løsninger i skyen.

Med undtagelse af oppetiden så kan jeg sagtens nikke genkendende til dine udfordringer .. og når helvedet så er løs, ja, så har du altså ikke lige en driftmand du kan ringe til, så det forudsætter du selv har driftsmæssige egenskaber og kan klare dig via logs og interfacet til løsningen.

I fht. pris så er Azure dog noget billigere end vores nuværende leverandør .. men det siger nok mere om vores nuværende leverandør end Azure :-)

Mht. dine referede spikes så sker disse desværre hyppigt .. og det kræver du har et framework som understøtter transient fault handling da din applikation ellers kan risikere at kvæles til døde .. igen gode lærepenge.

Din løsning i Tyskland - minder den "driftmæssigt" om Azure, eller?

Pelle Söderling

Angående hosting så består vores primære servere af sådan et par stykker her http://www.hetzner.de/en/hosting/produkte_rootserver/ex8s konfigureret med SAS diske i RAID 10 - jeg mener det er lige omkring 1400 kr/mnd med alle nødvendige moduler pr. server og så har vi en lidt mindre server derudover.

Der er altså tale om dedikerede servere istedetfor virtualiserede som sælges på abonnementsform, så på den måde er modellen ikke så langt fra sky-modellen rent økonomisk.

Vi forventer at kunne håndtere omkring 10 gange så mange brugere på dette setup end på vores setup i skyen så skalering er reelt heller ikke et stort problem for os - derudover så fordi vores løsning er udviklet til Azure i første omgang er skalering tænkt ind i fra start og vi ville uproblematisk kunne udvide med flere servere skulle vi få behovet, men det er nok ikke helt så simpelt som at trykke på en knap i Azure. Leveringstiden på serveren er dog ret god, jeg mener der gik under et døgn.

Kan iøvrigt oplyse at vi har kørt på dette setup i over 3 måneder nu uden et eneste driftproblem.

Ang. Spikes så var en fault handling ikke en løsning for os, da det primære problem for os var at kunden sad og ventede i den anden ende, ikke at handlingen ikke blev gennemført - der er tale om et mobil-spil hvor kravene til latency ikke er i den helt høje ende, men 2+ sekunder er dog uacceptabelt.

En del af problemet tror jeg skyldes at SQL Azure reelt også køres i virtuelle instancer og jeg tror det giver nogle I/O flaskehalse, jeg har generelt dårlig erfaring med at køre SQL Server virtualiseret.

Lars Hansen

En del af problemet tror jeg skyldes at SQL Azure reelt også køres i virtuelle instancer og jeg tror det giver nogle I/O flaskehalse, jeg har generelt dårlig erfaring med at køre SQL Server virtualiseret.

Hvor mange IOPS er der tale om der skal serveres?

Rigtig meget afhænger af det underliggende disk system, man kan have nok så meget RAM og CPU, men hvis det hele skal trækkes igennem et 1GB link til et allerede belastet disk array/SAN er det jo lige fedt.

Tit når du sidder med en VM, kan du kun se den VMs IOPS, men ikke alle de andre der trækker ressourcer samme sted fra. Derfor er man overladt til at stole på dem der hoster / administrerer enten SANet eller virtualiseringslaget.

Pelle Söderling

Lars: IOPS svingede meget alt efter tidspunktet af døgnet (og antal brugere online), men selv ved lav belastning oplevede vi spikes imellem vores worker instans og SQL Azure instancen. Vi havde tilmed købt os til en større worker-instans for at få prioriteret I/O, men uden at dette hjalp på det.

Et af problemerne ved et sådant setup er at man er helt og aldeles afhængig af Microsofts teknikere - du har ingen kontrol med din SQL Azure instans og der er ingen mulighed for at pille i konfigurationen eller lign. (ihvertfald ikke vi har været bekendt med). Det er også så godt som umuligt at sætte noget logging op eller få noget information ud af disse instancer - grundlæggende køber du en sort boks, som du kan håbe på virker.

Troubleshooting var derfor meget problematisk og kræver en masse bøvl from og tilbage med Microsoft teknikere - i vores nuværende løsning hvor vi blot hoster en normal SQL Server kan vi pille, logge og troubleshoote lige så tosset vi vil, det har jeg det personligt meget bedre med :-)

Lars Hansen

Lars: IOPS svingede meget alt efter tidspunktet af døgnet (og antal brugere online), men selv ved lav belastning oplevede vi spikes imellem vores worker instans og SQL Azure instancen. Vi havde tilmed købt os til en større worker-instans for at få prioriteret I/O, men uden at dette hjalp på det.

Lige netop det, at problemerne også var der ved lav belastning, kunne indikere en flaskehals på storagesystemet. Fordi, så virker det jo mindre afhængigt netop af Jeres workload, om der er spikes eller ej.

Et eksempel fra min verden. Vi drifter hos os nogle ERP løsninger, en af disse havde en clean up service der skulle rydde op efter nogle kørsler. Denne gik "amok", og afstedkom 2200 IOPS, hvilket var nok til at vores SAN begyndte at svede. Resultatet var, at andre services, og navnlig andre SQL databaser i samme SAN oplevede stærkt nedsat performance.

Havde vi ikke selv kunnet aflæse IOPS i SAN eller graferne i Vsphere, ville vi, hvis vi kun havde adgang til en VM, ikke umiddelbart kunne se hvorfor performance var så skidt.

Kunne have været interessant, hvis i havde målt hvor mange IOPS Jeres instans fik. Jeg har kigget lidt på Azure, og umiddelbart prissætter den jo bare efter båndbredde.

Men, en google søgning frembringer et link, hvor der tilkøbes adgang til flere VHD´er for flere IOPS. Det lyder ikke på dig som om, at det er det i har gjort - I linket nævnes op til 5.000 IOPS.

http://tk.azurewebsites.net/2012/06/18/windows-azure-iaas-performance-sq...

Ellers et fint eksempel på problematikken omkring Microsofts cloud, og hvorfor man måske ville vælge en anden løsning.

Pelle Söderling

Vi anvendte et federated setup i SQL Azure og havde adskillige instancer, men når selv lav belastning forårsager spikes og vi intet oplever til dette efter at have flyttet løsningen ud af Azure (det var altså ikke relateret til at vores løsning lavede åndsvage ting) - så fortæller det mig at Microsoft har nogle grundlæggende infrastruktur-problemer.

At der yderligere gik næsten 8 timer fra deres SAN startede med at få problemer (hvilket vi først bagefter opdagede at vores instrumentering afslørede) og til de opdagede problemet og startede fejlretning (vi ringede desværre selv ret sent ind da vi reelt troede det var os der havde problemet) tyder også på at deres overvågning af infrastrukturen lader en del tilbage at ønske - det er ganske enkelt ikke professionelt nok.

Vi målte ikke IOPS, men vi havde meget detaljeret logning på svartider som var det der gjorde at vi kunne se det ikke kørte så smooth som vi havde håbet på. Hvis jeg blot testede vores applikation ville jeg ikke selv bemærke noget, så uden denne instrumentering havde vi aldrig opdaget at der var kunder hvor svartiderne ikke var acceptable. Hvis folk ikke benytter instrumentering i deres Azure løsning vil de formentlig aldrig opdage at der er et problem, derfor slipper Microsoft formentlig afsted med det.

Jacob Nordfalk

Angående hosting så består vores primære servere af sådan et par stykker her http://www.hetzner.de/en/hosting/produkte_rootserver/ex8s

Jeg ender også stort set altid hos Hetzner når jeg skal lave en hostingløsning, og jeg ender stort set altid på http://www.hetzner.de/en/hosting/produkte_vserver/vq12 .

100 kr/måned for en 1GB RAM server med Ubuntu på, det er svinebilligt i forhold til alternativerne, og jeg har i løbet af de to år jeg har brugt dem (http://javabog.dk + en række andre sites) kun oplevet nedetid en enkelt gang (SVJH var det et problem med skudsekunder der gjorde en genstart nødvendig).
Uden at det er noget jeg har forstand på har jeg ikke oplevet bøvl med sløve svartider eller at processer blev slået ihjel med Hetzner (det har jeg oplevet andre steder), og de har svaret de par gange jeg har skrevet til dem.

Pelle Söderling

Helt enig Jacob, Hetzner har indtil videre kun været en positiv oplevelse.
Jeg foretrækker dog de lidt større serverløsninger med remote KVM adgang, det er en super fed løsning :)

Jon Bendtsen

Ja og en virtualiseret SQL server har så tit gjort mit arbejde ulideligt.... En SQL server lader sig bare ikke lige virtualisere, på grund af det forholdshvis høje krav til diskene.


Hvis man vælger den rigtige type virtualisering, kerne-virtualisering, hvor man deler den samme kerne (men userland er forskellig), så kan man (på Linux) få den samme performance som en fysisk maskine. Jeg ved ikke om windows kan kerne-virtualisering, men FreeBSD og Solaris kan. Sikkert også AIX, mainframes, ...

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen

TDC skifter koncernchef efter faldende mobilomsætning

Jesper Stein Sandal Mobil og tele 14. aug 2015

Nyeste job

KurserStyrk dine evner med et kursus

Stærkstrømsbekendtgørelsens regler for elektriske installationer

Hvornår: Hvor: Østjylland Pris: kr. 3180.00

Visio kursus grundlæggende

Hvornår: 2015-11-06 Hvor: Storkøbenhavn Pris: kr. 2950.00

Temadag: Smukke, funktionelle og tilgængelige udearealer

Hvornår: 2015-09-24 Hvor: Storkøbenhavn Pris: kr. 995.00

Word 2013 Grundlæggende

Hvornår: 2015-09-08 Hvor: Østjylland Pris: kr. 2950.00

MIKE 21/3 OS FM

Hvornår: 2015-09-09 Hvor: Nordsjælland Pris: kr. 7800.00