Leaseweb ondervindt storage-problemen sinds maandagavond

Leaseweb ondervindt sinds maandagavond problemen met zijn storage-platform wat heeft geleid tot prestatievermindering bij de Public Virtual Servers. Op moment van schrijven is de storing nog niet opgelost. Hoeveel klanten er getroffen zijn, is nog niet bekend.

Klanten kunnen ermee te maken krijgen dat Public Virtual Servers een readonly-status hebben. Onder andere onderzoekssite Follow the Money kampt met downtime. Op zijn eigen Network Operations Center houdt Leaseweb de status bij. Uit de eerste melding blijkt al dat het gaat om een hardwareprobleem. Na met de leverancier aan de slag gegaan te zijn om het probleem te ontrafelen, werd om negen uur dinsdagochtend een hardwarecomponent vervangen. Verwacht werd dat de load op de verschillende servers snel zou afnemen, maar was dat niet het geval.

In een reactie op ISPam.nl laat Leaseweb weten dat de storing is veroorzaakt door een 'defect cache-device in een van de frontend-systemen die de storage aanbieden aan de virtualisatie-nodes'. Leaseweb geeft verder in de reactie aan dat dit type storing nog nooit eerder voorgekomen is. Ook is het nog niet duidelijk wanneer de storing opgelost zal zijn.

Verder geeft de hoster aan dat het voornemen om de opslag-platformen te vervangen nu versneld zal worden, omdat de hardware niet voldoet aan de kwaliteitseisen. De laatste update van 12:15 uur dinsdagmiddag stelt dat de bandbreedte voor opslag tijdelijk zal worden verkleind op alle publieke virtuele servers. Als de situatie verandert, krijgt de NOC-site een update.

Reacties (56)

Hark 1 september 2015 17:33

Ja ik heb hier ook last van. Mijn site (webshop) is al de hele dag niet vooruit te branden. Dit is al de tweede (heel) grote storing sinds ik deze server heb. En dat is nog geen twee jaar...

Anonymoussaurus @Hark • 1 september 2015 17:42

Jep, zo ziet het er wel naar uit. http://i.imgur.com/oCS2zW2.jpg?1

"request timed out"

[Reactie gewijzigd door Anonymoussaurus op 24 juli 2024 21:07]

Hark @Anonymoussaurus • 1 september 2015 17:47

Nou, met het netwerk is juist niets mis. De storage is het probleem. Schrijfacties duren letterlijk seconden. En leesacties ook als de opgevraagde informatie niet in de cache staat.

Bender @Hark • 1 september 2015 17:53

Ik ken je business natuurlijk niet, maar waarom heb je vanmorgen niet even snel een verhuizing in gang gezet?
(desnoods tijdelijk)

mrAceT @Bender • 1 september 2015 17:59

Verhuizingen van een eenvoudige website is vaak nog wel vrij eenvoudig te realiseren, maar complexere sites (en in ons geval de mailserver) zijn niet 1-2-3 om te gooien.

Bovendien ontvang je een redelijk haalbaar tijdstip (eerst 12:00, daarna 17:00-18:00) waardoor je een afweging maakt..

Simpelweg gezegd verwacht je dit niet van een serieuze onderneming, nog 2 uren, dan is de storing het klokje rond.. drama..

johnkeates @mrAceT • 1 september 2015 19:55

Heb je voor een belangrijk systeem dan niet altijd een kopie ergens anders draaien? Afschuiven op een andere partij "om dat het hoort te werken" is leuk, maar behalve als je een of andere goede SLA afgenomen hebt is het altijd je eigen schuld als je bedrijf niet goed draait om dat je je IT niet goed afgedekt hebt.

Een van de enige relevante KPI's in dit geval is of je website het wel of niet doet. Of dat onderliggend dan door bedrijf XYZ komt of door een programmeerfout doet er dan al niet meer toe.

Hark @johnkeates • 1 september 2015 23:02

Wat een onzin. Dit is gewoon een kwestie van kosten-baten analyse. In veel gevallen wegen de extra kosten van redundantie niet op tegen de baten. In mijn geval niet in elk geval. Heb ik dan geen recht van klagen? Tuurlijk wel, Leaseweb heeft mij een bepaalde uptime gegarandeerd en die halen ze nu bij lange na niet. Dat gaan ze ook gewoon netjes vergoeden, hebben ze bij de vorige storing ook gedaan.

Uiteraard wordt het een ander verhaal als storingen vaker voorkomen, maar dan kies ik er eerder voor om te verhuizen naar een betrouwbaardere partij dan dat ik het dubbele ga betalen om storingen bij Leaseweb op te kunnen vangen.

johnkeates @Hark • 2 september 2015 13:12

Ja, maar als die uptime 1% is om dat je best-effort hebt, heb je dan ook een recht van klagen?

Los daar van: stel dat je 99% uptime hebt, mag je dan niet gewoon 3 dagen plat liggen?

Hark @johnkeates • 2 september 2015 13:50

Ja, maar als die uptime 1% is om dat je best-effort hebt, heb je dan ook een recht van klagen?

Los daar van: stel dat je 99% uptime hebt, mag je dan niet gewoon 3 dagen plat liggen?

Ja. Daarom moet je ook nooit voor een aanbieder kiezen die slechts 99% uptime garandeert ;-)

johnkeates @Hark • 2 september 2015 21:03

Of nooit voor een SLA gaan die dat biedt...

Hark @johnkeates • 1 september 2015 23:07

Een dure SLA vind ik trouwens ook weinig toevoegen. In de praktijk zorgt dit er alleen maar voor dat je een hogere vergoeding krijgt als het misgaat. Het zorgt er zelden voor dát het ook minder misgaat. Dan zou ik eerder voor redundantie kiezen. Liever twee goedkope SLA's bij twee partijen dan één dure SLA bij één partij.

Bender @mrAceT • 1 september 2015 18:28

Het gaat ook om de website, niet om e-mail want als dat vertraagd is met minuten lijkt me niet bepaald een drama.

Een website is omzetten moet geen probleem zijn, maar ik ging er van uit dat enkel schrijven een probleem zou zijn maar als lezen een probleem is zal het inderdaad lang duren.

Pro tip: Maak automatisch dagelijks een externe backup dat je in geval van nood snel kan schakelen.

SED @Bender • 2 september 2015 08:38

pro-tip: een backup is geen uitwijk.
Leuk dat je de data veilig gesteld hebt ( en ik ga ervan uit dat iedereen dat doet) maar je hebt er weinig aan als je server botertraag is geworden.
Wat je waarschijnlijk bedoelde is het regelen van een uitwijk mogelijkheid. Zoals hierboven al aangegeven is:.. dat is een kosten baten analyse die men kennelijk gemaakt heeft en uitgaat van de performance en continuiteitsgarantie van de aanbieder.
Ook een beter SLA lost een probleem niet op. Sla's voorkomen geen storingen en als de oplostijd niet behaald wordt. Zoals nu het geval is, dan heb je weinig aan een SLA. dat zorgt hooguit voor een stukje vergoeding maar geen oplossing!

Bender @SED • 2 september 2015 09:27

Natuurlijk heb je er niet weinig aan, je kunt je backup opzetten op een andere omgeving en binnen no-time heb je weer een werkende website.

SED @Bender • 2 september 2015 09:30

Je doelt dus meer op disaster recovery dan een backup.
Met alleen een backup heb je niet ""in no-time een werkende site"" namelijk.
Mogelijk dat een heel klein prive sitetje dat relatief snel laat doen maar een serieuze zakelijke site kost je toch echt wat meer tijd.
Nogmaals:
En iedereen heeft natuurlijk een backup, dat staat hier los van.

[Reactie gewijzigd door SED op 24 juli 2024 21:07]

Bender @SED • 2 september 2015 10:31

Nee, ik bedoel gewoon een backup. Bestandjes en database.

Data verplaatsen, eventueel config file aanpassen en je moet de gemiddelde webshop al weer werkend hebben.

Hark @Bender • 2 september 2015 11:11

Je zal toch op het laatst nog even een rsync willen doen van de live server. Met een serieuze webshop gaat dat écht wel lang duren als er storageproblemen zijn.

Even snel een backup van de vorige dag online gooien is echt niet voldoende.

Hark @Bender • 1 september 2015 18:25

Omdat dat enorm lang duurt met deze snelheden... Dan ben ik daar uren (of nog veel langer) mee bezig, terwijl het niet in de lijn der verwachting lag dat de storing zo lang zou duren.

daft_dutch @Hark • 1 september 2015 18:36

Ja maar als je het sessie beheer al opslaat ben je het haasje. Als je site readonly te benaderen is heb je dat expliciet gemaakt als een baas
of je bent klassiek 1.0 html only

Anonymoussaurus @Hark • 1 september 2015 17:49

Dan vind ik het raar waarom ik alsnog de site niet kan benaderen, en dat hij ook een time out geeft

[Reactie gewijzigd door Anonymoussaurus op 24 juli 2024 21:07]

pietermx @Anonymoussaurus • 1 september 2015 17:56

Als je goed kijkt zie je dat de eindbestemming helemaal geen timeout geeft, slechts een aantal tussenliggende hops / routers (waaronder je eigen router $_/-\o_$ @ hop 2).

aadje93 @pietermx • 1 september 2015 18:36

Is het niet zo dat de router juist een timeout krijgt bij de verbinding naar de server? Of lees ik hem dan verkeerd. De pc > router is namelijk <1ms wat logisch is

pietermx @aadje93 • 1 september 2015 20:23

Ik denk dat je dat verkeert leest. De router (hop 2) reageert niet op een ping vanaf de bron (cq. de PC van @AnonymousWP), het zegt niks over de verbinding tussen deze hop / router en de eindbestemming...

Naast dat sommige routers ping verzoeken (of ICMP verkeer in z'n geheel) negeren komt het ook vaak voor dat het wél wordt afgehandeld maar met een (zeer) lage prioriteit. Gevolg daarvan is dat de verbinding slecht lijkt, terwijl dat eigenlijk niet het geval is. Zo kan een antwoord op een tussenliggende hop / router lang op zich laten wachten (met soms een timeout) terwijl achterliggende hops én de eindbestemming zelf wél snel reageren (zoals het geval is in de screenshot van @AnonymousWP, tenminste met ~10 ms lijkt mij niks mis).

Óók kan het zo zijn dat verkeer vanaf de eindbestemming of iedere tussenliggende hop een andere route terug volgt (om dit te onderzoeken moet je een traceroute vanaf de eindbestemming of desbetreffende hop maken).

Daarnaast komt het soms voor dat een router / firewall ergens op de route ICMP verkeer in zijn geheel niet doorlaat, wat resulteert in een mooie traceroute zonder eind (maak eens een traceroute naar bol.com of yahoo.com).

Anonymoussaurus @pietermx • 1 september 2015 19:01

Zoals Aadje93 zegt, klopt het niet wat jij zegt.

servicedb @Anonymoussaurus • 1 september 2015 18:07

Zoals Yggdrasil aangeeft zegt de request time out in je traceroute niks. Enkel wanneer je target een time-out geeft zou het kunnen dat er iets met het netwerk aan de hand is, al zou het ook kunnen dat ergens op de route naar de server toe problemen zijn. Overigens is traceroute niet de tool om dit te meten, hiervoor kan je beter direct een ping naar de server doen. Traceroute is handig om te debuggen welke routes je neemt en relevant voor netwerkbeheerders om te kijken welke transits en of peerings je gebruikt om bij de server te komen.

Bij routers wordt vaak bewust niet op alle pings gereageerd. Redenen kunnen zijn om misbruik te voorkomen en voldoende router performance over te houden. Hierdoor kan je een ping naar een router (tenzij je er zeker van bent dat deze alle pings beantwoord) beter niet serieus nemen.

Anonymoussaurus @servicedb • 1 september 2015 19:04

Overigens is traceroute niet de tool om dit te meten, hiervoor kan je beter direct een ping naar de server doen.

Weet ik, ik had eerst gepingt, die gaf gewoon normale snelheden aan qua milliseconde. Het rare is dat ik de server/site alsnog niet kon benaderen. Dus deed ik een tracert om te kijken waar het mis ging.

SED @Anonymoussaurus • 2 september 2015 08:43

Gebruik dan pathping, de combinatie van Ping en traceroute met extra's

aadje93 @Anonymoussaurus • 1 september 2015 20:58

een ping naar de host is iets anders dan een http request, de ping word vaak door de router afgehandeld terwijl het http request door de daadwerkelijke server achter de router (met NAT) gedaan word. Ik kan pingen zoveel ik wil naar mijn mikrotik core router, maar poort 80 zit op slot

servicedb @Anonymoussaurus • 2 september 2015 11:13

Een ping kan ook werken als de server in read-only modus zit. Echter een http request heeft read/write modus nodig ivm het wegschrijven van je verzoek naar het logboek. Daarnaast kan performance ook een rol spelen, bij een hoge belasting kan je alsnog een reply krijgen op een ping maar bij http niet. Een http request is vele malen zwaarder ;-)

Anonymoussaurus @servicedb • 2 september 2015 11:40

Daarnaast kan performance ook een rol spelen, bij een hoge belasting kan je alsnog een reply krijgen op een ping maar bij http niet. Een http request is vele malen zwaarder ;-)

Weet ik, klinkt logisch

[Reactie gewijzigd door Anonymoussaurus op 24 juli 2024 21:07]

Yggdrasil

@Anonymoussaurus • 1 september 2015 17:52

Een "request timed out" tijdens een traceroute zegt niks over de performance van de server. Het betekend alleen maar dat die specifieke router geen ICMP error messages retourneert naar je PC, of dat de pakketten verloren zijn gegaan.

Verwijderd @Hark • 1 september 2015 17:41

Geen enkele last op mijn server, gelukkig...

mrAceT @Hark • 1 september 2015 18:00

Jou dienst doet het tenminste nog.. wij liggen er compleet uit..

CAPSLOCK2000 1 september 2015 20:08

"Public Virtual Server"
Wat is dat nu weer? Ik dacht al dat het een schrijffout van de redacteur was maar Leaseweb gebruikt die naam zelf ook in het persbericht.
Is dat een poging om "Virtual Private Server" wat op te leuken of betekent het iets anders?

[Reactie gewijzigd door CAPSLOCK2000 op 24 juli 2024 21:07]

job_h

@CAPSLOCK2000 • 1 september 2015 20:57

Leaseweb biedt twee VPS mogelijkheden: Virtual Server (public cloud-platform) en Private Cloud.

Edit:
Zojuist weer een update ontvangen. Ze zijn alle servers een voor een weer online aan het brengen.

[UPDATE 23:00 CEST]
This is an update about the earlier communication regarding an unexpected event on one of our storage platforms in the Netherlands, resulting in a serious degradation of the availability of your Public Virtual Server.

LeaseWeb engineers, together with our storage supplier are currently stabilizing the platform. Our engineers are bringing individual virtual servers back online in the next hours. To ensure platform stability during these operations, we have temporarily disabled start/stop and reboot functionality in the LeaseWeb Customer Portal. Please be assured that all our resources are determined and available to solve the incident adequately as soon as possible.

The current situation and the general stability of this platform does not meet our company standards and the reliability that you may expect from LeaseWeb. Parallel to the focus on this incident, we are therefore also rolling out the replacement of this platform. More information about this will follow.

[Reactie gewijzigd door job_h op 24 juli 2024 21:07]

Evianon @CAPSLOCK2000 • 1 september 2015 21:00

Ik denk een virtual server in hun public (shared) cloud en daar een leuke verbastering van, aangezien ze ook private clouds aanbieden.

pauldaytona 1 september 2015 22:19

Als je een server nodig hebt waar veel van afhangt, wil je die niet in een shared hosting omgeving hebben draaien. Ik beheer ook z'n server bij leaseweb, al 8 jaar geloof ik. En gemiddeld gaat het prima, maar er zijn wel eens tijden geweest, dat een andere server in dezelfde omgeving, zo hard aan de gesharede database server trok dat ik er last van had. Ik ben wel eens intern bij Leaseweb verhuisd daarom.
De support ben ik zeer tevreden mee, ze weten waar ze over praten daar.

Ik kan uit het bericht niet lezen dat het Nexenta zou zijn, zou ook Netapp kunnen zijn, hebben/hadden ze ook dacht ik.

Hark @pauldaytona • 2 september 2015 08:40

Het gaat niet om de shared hosting omgeving, maar om de virtuele servers. Die gebruiken echt geen gedeelde database hoor.

binbash. @Hark • 2 september 2015 11:57

Een virtuele server in een public cloud zit toch helemaal op gedeelde resources. Daarom ook het "Virtueel" kopje. Dat is gewoon nieuwe stijl shared hosting. Veel voor weinig met 150 man op een enkele fysieke server virtueel doen, en af en toe een storing. Wat kost zo'n Virtual server bij LSW tegenwoordig 5 euro ofzo ? Das voor niks. Als het zo belangrijk is gewoon wat meer geld spenderen voor private resources. Of failover scripten tussen een aantal goedkope cloud provider en automatich deployen wanneer er eentje down gaat.

Heb zelf zo'n private pakket bij LSW met 100 cores. Nooit een probleem gehad. Nu overigens ook niet. Kost wat meer, maar dan heb ik wel de rust dat alles ook blijft werken en de resources die ik koop ook gebruikt kunnen worden.

De alloude uitspraak in de ICT " do you want it FAST, CHEAP or WORKING, you can only choose two" Geldt ook gewoon voor cloud lol.

Hark @binbash. • 2 september 2015 13:47

Een private cloud met 100 cores kost minimaal 1600 euro per maand. Ga je dat nu serieus vergelijken met een server van een tientje per maand??

Ik reageerde overigens op je term "gesharede database server". Daar is geen sprake van.

mrAceT 1 september 2015 17:56

Laatste update, ook het tweede gestelde doel (voor 18:00, vorige was 12:00) wordt niet gehaald. De engineers gaan de avond/nacht in..

wica 1 september 2015 19:59

Vervelend voor leaseweb en de klanten. Dit storingen kunnen jammer genoeg bij de beste systemen voorkomen.

Zo te lezen gebruiken ze idd NexentaStor welke weer ZFS gebruikt.
Zoals ik lees, is het geen hardware storing (deze was nu wel gevonden) maar ergens in de software laag van NexentaStor.
Zelf heb ik, meerdere Nexenta servers beheerd, zaten toen der tijd (3+ jaar geleden) nog al wat vervelende zaken in. Welke elk opzich wel weer te verklaren waren. Maar vervelend niet te min.

Overigens voor de klanten met een readonly filesystem, hopelijk is een reboot voldoende. suc6

Hark 1 september 2015 21:28

De storing lijkt voorbij. Mijn server doet het tenminste weer goed. Na een uur of 30...

Edit: het is nog steeds te traag

[Reactie gewijzigd door Hark op 24 juli 2024 21:07]

xantos 2 september 2015 17:30

Problemen blijven zich nog steeds voordoen volgens hun netwerkstatus pagina. Ik denk dat sommige engineers inmiddels het zweet op het voorhoofd hebben staan.

Wilde gisteren eindelijk de private cloud dienst serieus in gebruik nemen maar schrikte me even af. Schijnt dat ze daarvoor een compleet andere storage systeem gebruiken (gelukkig).

[Reactie gewijzigd door xantos op 24 juli 2024 21:07]

Verwijderd 2 september 2015 20:02

Mijn virtuele server (public) is geen moment offline geweest. Dus niet alle klanten zijn hierdoor getroffen.

Verwijderd 1 september 2015 18:01

Drama

[Reactie gewijzigd door Verwijderd op 24 juli 2024 21:07]

PolarBear @Verwijderd • 1 september 2015 18:13

Nee, maar dit is een uitzonderlijke grote storing bij een van de (of de) grootste hostingprovider in Nederland.

i-chat @PolarBear • 1 september 2015 18:41

niet lang meer als ze dit niet snel oplossen, en als er idd gebruik gemaakt wordt van nexenta - dan brrrr. maar goed, of het nu nexenta is of iets anders, als het fout gaat en het wordt niet binnen 24uur opgelost dan ben je hoe dan ook de sjaak... die 99,99 uptime gaan ze niet meer halen .. ik ben benieuwd hoe ze dit gaan vergoeden naar klanten toe...

trouwens, webshops en voorraadsystemen zoals in het voorbeeld hierboven repliceren is niet triviaal tenzei je 100% clustering over verschillende nodes (bij verschillende leveranciers) gaat draaien maar een dergelijke failover cluster is vermoedelijk duurder dan een dag niet verkopen,

Verwijderd @i-chat • 1 september 2015 20:19

Nieuwsgierig, wat is er mis met Nexenta?

binbash. @Verwijderd • 2 september 2015 12:03

Nexenta was 5 jaar geleden een mooi idee. De uitwerking zuigt. Ze zijn te snel gegroeid. En nu hebben de Devvers en Engineers alleen nog maar tijd om adhoc problemen op te lossen voor klanten en niet om hun product door te ontwikkelen.
En dan krijg je uiteindelijk de problemen die LSW nu ondervindt. TransIP had het een aantal jaar geleden ook als ik me niet vergis. Al waren die met de community variant aan het rommelen lol.

Wim-Bart @Verwijderd • 1 september 2015 23:50

ZFS ;-)

Yggdrasil

@Wim-Bart • 2 september 2015 10:38

Ik gebruik zelf geen ZFS maar hoor er voornamelijk goede dingen over. Kun je aangeven wat je er slecht aan vindt?

Wim-Bart @Yggdrasil • 2 september 2015 20:22

Zie de knipoog :-)

Overigens tweede keer dat ik een ZFS Systeem onderuit zie gaan in de afgelopen weken met zulke gevolgen. Bij een klant ook een redelijk professioneel ZFS systeem waarbij de cacheing ook onderuit ging, ook gewoon voltallige kantoorpersoneel 2000+ mensen naar huis hier door. Snap nog steeds niet dat dit soort systemen geen Metrocluster achtige oplossingen hebben waarmee een uitwijk een kwestie van een OK knopje is of wat eenvoudige handelingen zoals vroeger met EMC, NetApp en HP EVA mogelijk was.

[Reactie gewijzigd door Wim-Bart op 24 juli 2024 21:07]

Verwijderd @Wim-Bart • 2 september 2015 14:46

Ja maar. Wat? Hoe is ZFS een slecht iets?

velenski @PolarBear • 1 september 2015 18:52

3e van de wereld en grootste van nederland (2e van europa na ovh)

wat veel mensen niet beseffen is dat hun netwerk ook heel groot is in Amerika (VS)

Op dit item kan niet meer gereageerd worden.

Lees meer

Reacties (56)

Sorteer op:

Weergave: