Data försvunnen efter driftavbrott hos Oderland
 

Jag flyttade nyligen min största sida till Oderland för att slippa kaoset hos binero. Men det verkar varit en stor miss. Man får acceptera ett driftavbrott då och då men döm av min förvåning när de senaste inläggen i min databas försvunnit efter driftavbrottet. Har dessutom företagskonto just för att hostingen är viktigt, men det verkar inte vara bättre för det.

Detta hände inte ens hos binero. Visst sidan gick ner titt som tätt, men att data försvinner?! Dessutom över 8 timmar gamal data. Nån som varit med om nått liknande.

Mejla eller ring supporten så får du säkert en förklaring.

Mailen är knuten till Oderland och har inte funkat på hela dan, och de svarar inte i telefon :( Antar att jag inte är den enda. Kan inte minnas att jag varit med om detta tidigare på någon hosting... Netland, Godaddy, Binero etc.. Kanske haft tur bara dock.

De har ingen rapporterad störning på sin sida, är du enda drabbade?
De har ju telefonsupport dygnet runt också, vad säger de?

Vet inte vart du kollar, men de verkar haft en betydande störning igår med följdproblem idag enligt deras driftsblogg.

Läste uppifrån och ner, sorry.
Dock är dagens enda inlägg:

"2011-03-09 14:40

Det har visat sig att ett problem återstår på Baku sedan i går. Den har därför oplanerat måsta startas om för en diskcheck. Inget fel på home utan några mindre partitioner så det bör inte ta allt för lång tid. Vi håller er uppdaterade här och på twitter!"

De svarade tillslut men tjejen på kundtjänst sa att det var stora problem och hon inte kunde ge mig någon mer info. De skulle lägga upp mer om detta senare idag på deras hemsida och twitter. Får acceptera att datan är borta som det ser ut nu och skriva in på nytt.

Läser man vidare efter blogginläggat vad de skrivit på twitter så ser det inte lika bra ut längre. Hoppas det löser sig smidigt och snabbt så alla blir glada. :)

Vi har sedan cirka en timme skapat ett helt eget inlägg för just denna störning. Tidigare förmedlades det mesta via Twitter och kommentarer på Disqus i gårdagens blogginlägg.

Ni kan läsa mer specifikt vad servern baku har råkat ut för här: http://www.oderland.se/driftbloggen/...driftinfo.html

Jag vill också påpeka att all gammal data inkl den i databaser finns kvar. Vi hjälper er att få tillbaka den om ni bara kontaktar oss på supporten. Det är tyvärr svårt för oss att stoppa tillbaka den i databasen då vi tvingades återställa en backup från tidigare natt kl 3.

Webbkontoservern baku är alltså en virtuell server?

Snacka om otur, här flyttar man från binero och så händer det igen..., kan murphy sluta följa efter!!!

Ja, det stämmer.

Det kanske är du som har en förbannelse över dig? ;)

Hela oderlands sida verkar vara nere nu

Nu är den igång igen tydligen...

Vi har två butiker liggandes på Oderland och första avbrottet kom på dagen vid 15.30 tiden. Detta höll i sig undefär 1,5 timma. Sedan kom ett nytt avbrott på en timma vid 19 på kvällen.

Jag e lite besviken på Oderland efter detta måste jag säga. Vi flyttade från en Dedikerad server på Ipeer till Oderland efter att ha fått begräftat att en VPS aldrig kan gå ner. Att man jobbar med system som hela tiden garanterar säker drift. Tydligen var så inte fallet...

Om du köper en redundant VPS med FT eller liknande så behöver du inte få något avbrott. Kräver även ett SAN som har lite redundans med.

Då kanske man ska lära sig att delade miljöer inte är någon hit!

Utan att man kanske ska lägga lite mera pengar en 1000 kr per år för att förlita sig på driften.

Uppdatering av mysql en kort stund på en egen maskin då vår nya system krävde lite andra inställningar.

Jag e lite kass på detta skall jag erkänna. Det framgår inget om detta i Specen
http://www.oderland.se/managedvps/ma...delta-vps.html

Däremot kan jag läsa:

✓ Er virtuella server hålls ständigt igång.
✓ Automatisk migrering i vår XenServer-miljö om den underliggande fysiska servern skulle få problem.

Du fick vad du betalade för i.a.f..

Det var ingen automatisk migrering som skedde då ingen host var nere.
Vi skulle manuellt migrera över baku till en annan host och det var i detta läge som en oväntad bugg visade sig. Baku kördes alltså samtidigt på två stycken hosts och det var med andra ord två maskiner som skrev till samma diskar på SANet, därför gick det inte alls starta servern baku då dess filer var korrupta på alldeles för många ställen.
Vi har aldrig tidigare upplevt detta och vi flyttar omkring servrarna ganska ofta av olika anledningar.

Vi har redan kontaktat både Citrix och vår leverantör av SANet för att undersöka hur en sådan sak kan hända.

Går den underliggande fysiska hårdvarunoden ner så kommer din virtuella server också gå ned tills den är uppstartad på en ny nod, detta gäller dock inte FT som förbygger detta, har dock ingen koll på om XenServer stödjer det, det är ju VMWARE som lanserat funktionen i deras ESXi.

Men nu är ju inte felet hårdvarurelaterat vad gäller noden (även kallas host) utan på lagringen, och då gällande filsystemet.

Felet var ju inte lagringen utan dom var klantiga och körde flera VM mot samma VM. Och det funkar inte så bra om man inte har ett kluster filsystem.

Så var ju mer en mänsklig miss.

Men var väl en webbhotell instans som var problemet? Det var väl inga VPS kunder det var frågan om? Så vad kom VPS in från första början?

Stämmer bra det, Xenserver stödjer ej FT än. Stödjer dock HA vilket dock betyder att VM automatiskt kommer upp på annan nod.

Två skilda fel som diskuteras.
1. Vi var inte klantiga och körde flera VM mot "samma VM" (du menar mot samma VDI:er?). Problemet (onsdag) uppstod vid en migrering av servern baku till en annan nod där xenpoolen drog upp den nya VM:en utan att ta ned den gamla. Detta syntes dock varken i xencenter eller via xe CLI utan upptäcktes först när vi tog ned baku och vårt larmsystem fortfarande visade den som igång.
Vi går fortfarande igenom loggfiler med citrix för att se hur något sådant kan vara möjligt över huvudtaget.

2. Tråden i fråga gällde haveriet i tisdags och ej det ovan. Där var vi tyvärr tvugna att till slut ta ned hela virtualiseringsmiljön och starta upp noderna en efter en. Därför påverkades ca: 95% av våra servrar.

Detta är det normala, men pga tekniska fel kan man aldrig garantera att det fungerar till 100%
Jag är övertygad om att Oderland har gjort sitt bästa och kan inte belastas för ett fel eller bug i Citrix eller i SAN, och fel som detta kan aldrig uteslutas. Vi som hostingföretag väljer noggrant våra system och leverantörer och gör vårt bästa, men fel kan alltid uppstå. Dock borde vi vara mer noggranna med att informera om systems brister och ge alternativ som ger högre driftssäkerhet, LB 2st vps:er på reduntanta plattformar på skilda SAN med klustrat filsystem osv.

Det är säkert som ni säger. Jag har en bra känsla för oderland så detta var första gången jag stött på något problem från deras sida. Jag får även ge dom eloge för supporten, även om tjejen som svarar i telefon är lite trött så brukar oftast personalen bakom vara desto mer allerta på att hjälpa till :)

Jag rekommenderar fortfarande mina kunder att använda oderland trots detta.

Datan finns säkert kvar hel ändå.

I ESX(I) går det ställa in om man ska kunna köra flera VM mot samma fs/diskfil.

Så har testat när man haft tråkigt, det funkar utmärkt köra igång samma VM på samma fysiska server. Dock om man inte kör något klusterfilsystem så skrivs index över av varandra.

Så om ena VM som var igång endast "idlade" så lär endast index blivit överskrivet man data är helt. Dock kan det vara lite jobbigt att återställa det, även tidskrävande.