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.