Problemen hoster OVH kwamen door stroomstoring en softwarebug

Het Franse hostingbedrijf OVH is donderdag getroffen door een omvangrijke storing waardoor een groot aantal websites onbereikbaar waren en klanten niet bij hun servers konden. De oorzaak lag bij twee voorvallen, die volgens OVH ongerelateerd waren.

Bij de drie OVH-datacenters in Straatsburg ging het om een stroomstoring. De hoster wist die te herstellen waarna klanten weer online kwamen. Het bedrijf zegt te kunnen monitoren wie nog niet online is voor verdere ondersteuning. Niet duidelijk is waarom een noodstroomvoorziening de storing niet opving.

Een tweede probleem deed zich bij de locatie in Roubaix voor. De zeven datacenters die OVH hier heeft, waren niet bereikbaar door een softwarebug bij optische apparatuur. Deze netwerkapparatuur is verantwoordelijk voor de verbinding met de interconnectiepunten in onder andere Amsterdam, Brussel, London en Frankfurt. Ook deze storing is verholpen en klanten zouden grotendeels weer toegang moeten hebben. OVH werkt met de fabrikant van de optische apparatuur samen om herhaling te voorkomen. Het bedrijf belooft meer technische details over de storingen te verstrekken.

OVH is een Frans hostingbedrijf dat in 1999 is opgericht en inmiddels 27 datacenters in 19 landen, met zo'n 300.000 machines, beheert. Het bedrijf is een sponsor van Let's Encrypt en host onder andere Wikileaks.

OVH datacenters

Door Olaf van Miltenburg

Nieuwscoördinator

09-11-2017 • 15:08

93

Submitter: horstefan

Reacties (93)

93
84
45
6
0
34
Wijzig sortering
Het grootste probleem was dat de software van de (fiber) router crashte en de db hersteld moest worden ( pb RBX / GRA etc.. ) en ERDF (de electro boer in FR) een probleem had met de 2 20KV lijnen...

Hier de réctie van octave klaba (de baas daar) :

Hello, Two pieces of information. This morning we had 2 separate incidents that have nothing to do with each other. The first incident impacted our Strasbourg site (SBG) and the 2nd Roubaix (RBX). In SBG we have 3 datacentres in operation and 1 under construction. In RBX, we have 7 datacentres in operation. SBG: In SBG we had an electrical problem. Power has been restored and services are being restarted. Some customers are UP and others not yet. If your service is not UP yet, the recovery time is between 5 minutes and 3-4 hours. Our monitoring system allows us to know which customers are still impacted and we are working to fix it. RBX: We had a problem on the optical network that allows RBX to be connected with the interconnection points we have in Paris, Frankfurt, Amsterdam, London, Brussels. The origin of the problem is a software bug on the optical equipment, which caused the configuration to be lost of and the connection to be cut from our site in RBX. We handed over the backup of the software configuration as soon as we diagnosed the source of the problem and the DC can be reached again. The incident on RBX is fixed. With the manufacturer, we are looking for the origin of the software bug and also looking to avoid this kind of critical incident. We are in the process of retrieving the details to provide you with information on the SBG recovery time for all services / customers. Also, we will give all the technical details on the origin of these 2 incidents. We are sincerely sorry. We have just experienced 2 simultaneous and independent events that impacted all RBX customers between 8:15 am and 10:37 am and all SBG customers between 7:15 am and 11:15 am. We are still working on customers who are not UP yet in SBG. Best, Octave

Date: Thu, 09 Nov 2017 13:05:50 +0100

For all the details SBG: http://travaux.ovh.net/?do=details&id=28247

de twit van octave : https://twitter.com/olesovhcom
"This morning we had 2 separate incidents that have nothing to do with each other."

Daar geloof ik dus geen fluit van, hier moet wel een flinke relatie in zitten. :X
Het is niet zo dat er twee sites rond hetzelfde tijdstip offline gaan.

Update: waarom offtopic? Modereer even fatsoenlijk aub. Ongewenst inmiddels? Chapeau!

[Reactie gewijzigd door Devaqto op 23 juli 2024 21:21]

Ik vind het ook moeilijk te geloven, aan de andere kant. Hoe kan power outage in SBG nu voor internetoutage in RBX zorgen? Het lijkt me sterk dat de internetverbinding van RBX via SBG loopt, zou wel heel omslachtig zijn. Daarnaast laat een traceroute een directe verbinding tussen Amsterdam en RBX zien.

Ik heb zelf ook outage gehad op mijn ESXi bak in RBX 3, gelukkig alleen internet en was niet de hele machine uit. Kwam uit bed vanochtend met 534965256 mailtjes van monitoring.....
Het zal vermoedelijk iets zijn dat de poweroutage in SBG dit wel in RBX triggerde.
Ik lees iets over een sofware bug waardoor de config kwijt was, ik kan mij voorstellen dat het verliezen van de RBX-SBG connecties "iets" in gang zetten in die apparatuur, als vervolgens de hele management en operatie van die dingen stopt dan heb je wel een probleempje zoals dit.
Een power outage veroorzaakt waarschijnlijk een storm van netwerkverkeer door mislukte verbindingen, herroutering en of handover van verbindingen.
Ik kan me best voorstellen dat netwerkapparatuur daar van schrikt en bijvoorbeeld routeringstabellen overlopen.
Er zou dus best een, wat indirecte, relatie tussen de twee kunnen zijn.
Ovh is de laatste tijd druk bezig met het moderniseren van hun apparatuur. Zowel de PSU's als de Netwerk Apparatuur gaat volledig op de schop. Ik kan prima geloven dat de netwerk problemen niet in verband stonden mer de stroomstoring. Daarbij compenseert OVH alle klanten netjes voor de downtime. OVH is over het algemeen transparant over de oorzaak van problemen dus ik zie geen reden om het in twijfel te trekken.
Ik heb nog niks gehoord van een compensatie. Heb je daar toevallig een bron bij? :)
Zelf heb ik een ticket ingeschoten bij ze en hier hebben ze netjes op gereageerd dat ze nog werken op een tegemoetkoming en hier op terugkomen. Zal laten weten wanneer ik meer weet.
Jammer dat de details zo schaars zijn, ben wel erg benieuwd wat voor een bug dat precies was en in welke apparatuur.
Mocht je een beetje Frans kunnen, hier de reactie van de ceo/eigenaar van OVH met extra informatie:

Bonjour,
Ce matin, nous avons eu un incident sur le réseau optique qui interconnecte notre site de Roubaix (RBX) avec 6 des 33 points de présence (POP) de notre réseau : Paris (TH2 et GSW), Francfort (FRA), Amsterdam (AMS), London (LDN), Bruxelles (BRU).

Le site RBX est connecté à travers 6 fibres optiques à ces 6 POP : 2x RBX<>BRU, 2x RBX<>LDN, 2x RBX<>Paris (1x RBX<>TH2 et 1x RBX<>GSW). Ces 6 fibres optiques sont connectées aux systèmes de nœuds optiques qui permettent d’avoir 80 longueurs d’onde de 100Gbps sur chaque fibre optique.

Pour chaque 100G connectés aux routeurs, nous utilisons 2 chemins optiques qui sont géographiquement distincts. En cas de coupure de fibre optique, le fameux « coup de pelleteuse », le système se reconfigure en 50ms et tous les liens restent UP. Pour connecter RBX aux POP, nous avons 4.4Tbps de capacité, 44x100G : 12x 100G vers Paris, 8x100G vers London, 2x100G vers Bruxelles, 8x100G vers Amsterdam, 10x100G vers Frankfurt, 2x100G vers DC GRA et 2x100G vers DC SBG.

A 8h01, d’un coup, l’ensemble des liens 100G, les 44x 100G, ont été perdus. Étant donné le système de redondance que nous avons mis en place, l’origine du problème ne pouvait pas être la coupure physique de 6 fibres optiques simultanément. Nous n’avons pas pu faire les diagnostiques sur les châssis à distance car les interfaces de management étaient figées. Nous avons été obligés d’intervenir directement dans les salles de routage, pour faire les manipulations sur les châssis : déconnecter les câbles entre les châssis puis faire redémarrer le système et enfin seulement faire les diagnostiques avec l’équipementier. Les tentatives de redémarrage du système ont pris beaucoup de temps, car chaque châssis a besoin de 10 à 12 minutes pour démarrer. C’est la principale raison de la durée de l’incident.

Le diagnostique : Toutes les cartes transpondeurs que nous utilisons, ncs2k-400g-lk9, ncs2k-200g-cklc, sont passées en état « standby ». L’une des origines possible d’un tel état est la perte de configuration. Nous avons donc récupéré le backup et remis en place la configuration, ce qui a permis au système de reconfigurer toutes les cartes transpondeurs. Les 100G dans les routeurs sont revenus naturellement et la connexion de RBX vers les 6 POP a été rétablie à 10h34.

Il s’agit clairement d’un bug software sur les équipements optiques. La base de données avec la configuration est enregistrée 3 fois et copiée sur 2 cartes de supervision. Malgré toutes ces sécurités, la base a disparu. Nous allons travailler avec l’équipementier pour trouver l’origine du problème et les aider à fixer le bug. Nous ne remettons pas en cause la confiance avec l’équipementier, même si ce type de bug est particulièrement critique. L’uptime est une question de design qui prend en compte tous les cas de figure, y compris quand plus rien ne marche. Le mode parano chez Ovh doit être poussé encore plus loin dans l’ensemble de nos designs.

Les bugs ça peut exister, les incidents qui impactent nos clients non. Il y a forcement une erreur chez Ovh puisque malgré tous les investissements dans le réseau, dans les fibres, dans les technologies, nous venons d’avoir 2 heures de downtime sur l’ensemble de nos infrastructures à Roubaix.

L’une des solutions est de créer 2 systèmes de nœuds optiques au lieu d’un seul. 2 systèmes, cela veut dire 2 bases de données et donc en cas de perte de la configuration, un seul système est en panne. Si 50% des liens passent par l’un des systèmes, aujourd’hui, nous aurions perdu 50% de la capacité mais pas 100% de liens. C’est l’un des projets que nous avons commencé il y a 1 mois, les châssis ont été commandés et nous allons les recevoir dans les prochains jours. Nous pourrons commencer les travaux de configuration et migration sous 2 semaines. Vu l’incident d’aujourd’hui, ce projet devient prioritaire, pour l’ensemble de nos infrastructures, tous les DCs, tous les POPs.

Dans le métier de fournisseur des infrastructures Cloud, seul ceux qui sont paranos durent. La qualité de service est une conséquence de 2 éléments. Tous les incidents anticipés « by design ». Et les incidents où nous avons appris de nos erreurs. Cet incident là nous amène à mettre la barre encore plus haut pour s’approcher du risque zéro.

Nous sommes sincèrement désolés pour les 2H33 minutes de downtime sur le site RBX. Dans les prochains jours, les clients impactés vont recevoir un email pour déclencher l’application des engagements SLA.

Amicalement
Octave

https://twitter.com/olesovhcom/status/928622841561604096

[Reactie gewijzigd door Sp3dy op 23 juli 2024 21:21]

Voor de mensen die geen Frans kunnen of het gewoon niet in Frans willen lezen, vertaald met DeepL:

Goedemorgen, Hallo,
Vanochtend hebben we een incident gehad op het optische netwerk dat onze Roubaix-site (RBX) verbindt met 6 van de 33 aanwezigheidspunten (POP' s) op ons netwerk: Parijs (TH2 en GSW), Frankfurt (FRA), Amsterdam (AMS), Londen (LDN), Brussel (BRU).

Deze 6 optische vezels zijn aangesloten op de optische knoopsystemen die 80 golflengtes van 100Gbps per glasvezelvezel mogelijk maken.

Voor elke 100G die op de routers is aangesloten, gebruiken we 2 optische paden die geografisch van elkaar gescheiden zijn. In het geval van een glasvezelknipsel, de beroemde "schep klap", het systeem herconfigureert zichzelf in 50ms en alle schakels blijven UP. Voor de aansluiting van RBX op POP's hebben we 4,4Tbps capaciteit, 44x100G: 12x100G naar Parijs, 8x100G naar Londen, 2x100G naar Brussel, 8x100G naar Amsterdam, 10x100G naar Frankfurt, 2x100G naar DC GRA en 2x100G naar DC SBG.

Om 8:01 uur zijn alle 100G links, de 44x100G, plotseling verloren gegaan. Gezien het redundantiesysteem dat we hebben opgezet, kan de oorzaak van het probleem niet de fysieke onderbreking van 6 optische vezels tegelijk zijn. We konden de diagnoses op het remote chassis niet maken omdat de managementinterfaces bevroren waren. We moesten direct ingrijpen in de routeringskamers, om de manipulaties op het chassis uit te voeren: de kabels loskoppelen tussen het chassis, het systeem opnieuw opstarten en uiteindelijk alleen de diagnose stellen bij de fabrikant van de apparatuur. Pogingen om het systeem opnieuw op te starten hebben lang geduurd, aangezien elk chassis 10 tot 12 minuten nodig heeft om te starten. Dit is de belangrijkste reden voor de duur van het incident.

Diagnose: Alle transponderkaarten die we gebruiken, ncs2k-400g-lk9, ncs2k-200g-cklc, bevinden zich in de stand-bystand. Een van de mogelijke oorzaken van een dergelijke toestand is het verlies van de configuratie. Dus we hebben de back-up opgehaald en de configuratie weer op zijn plaats gezet, zodat het systeem alle transponderkaarten opnieuw kon configureren. De 100G in de routers keerde natuurlijk terug en de verbinding van RBX met de 6 POP's werd om 10.34 uur hersteld.

Dit is duidelijk een softwarefout op optische apparatuur. De database met de configuratie wordt 3 keer opgeslagen en gekopieerd naar 2 monitoring boards. Ondanks al deze waarborgen is de basis verdwenen. We zullen samen met de OEM de bron van het probleem zoeken en helpen de bug te verhelpen. We trekken het vertrouwen met de OEM niet in twijfel, ook al is dit soort bug bijzonder kritisch. Uptime is een ontwerpprobleem dat rekening houdt met alle situaties, ook wanneer niets werkt. Paranoïde mode bij Ovh moet in al onze ontwerpen nog verder worden uitgewerkt.

Bug bugs kunnen bestaan, incidenten die onze klanten niet treffen. Er is duidelijk een fout gemaakt bij Ovh, want ondanks alle investeringen in het netwerk, in vezels, in technologie, hebben we net 2 uur stilstand gehad op al onze infrastructuren in Roubaix.

Eén oplossing is het creëren van 2 optische knoopsystemen in plaats van één. 2 systemen, dat wil zeggen 2 databanken en dus bij verlies van configuratie is slechts één systeem uitgeschakeld. Als 50% van de verbindingen via een van de systemen zouden we vandaag de dag 50% van de capaciteit verloren hebben, maar niet 100% van de verbindingen. Dit is een van de projecten die we een maand geleden begonnen zijn, het chassis is besteld en we zullen ze de komende dagen ontvangen. Binnen 2 weken kunnen we starten met configuratie- en migratiewerkzaamheden. Gezien het incident van vandaag wordt dit project een prioriteit voor al onze infrastructuren, alle cd's en POP' s.

In de cloud infrastructuur provider business, alleen paranoïde laatste laatste. De kwaliteit van de dienstverlening is een gevolg van 2 elementen. Alle voorziene incidenten "naar ontwerp". En de incidenten waar we geleerd hebben van onze fouten. Dit incident brengt ons ertoe om de lat nog hoger te leggen tot een nihil-risico.

Wij betreuren de 2H33 minuten stilstand op de RBX site oprecht. In de komende dagen zullen getroffen klanten een e-mail ontvangen om de toepassing van SLA-toezeggingen te activeren.

Met vriendelijke groeten
Octaaf
https://twitter.com/olesovhcom/status/928622841561604096

[Reactie gewijzigd door mmjjb op 23 juli 2024 21:21]

Octave is niet de CEO, wel de eigenaar. De CEO heet Laurent. Detail.
Van zijn eigen Twitter account:

Octave Klaba (Verified account)
@olesovhcom

CEO/Chairman,Founder,Owner #Ovh.married.1+2 daughters.
Of korter gezegd: een single point of failure waarvan ze (naar bewering) al van op de hoogte waren en aan werkten.
Wow, dat is nog eens een gedetailleerde reactie.
Daar zouden meer bedrijven een voorbeeld aan kunnen nemen.
Het bedrijf zegt te kunnen monitoren wie nog niet online is voor verdere ondersteuning.
Hmm. Mijn 2 SBG-VPS'en zijn nochtans nog steeds down :(

Update:
Deze van het status bericht:
If your service is not UP yet, the recovery time is between 5 minutes and 3-4 hours
We moeten er toch een tijd op plakken, he?

[Reactie gewijzigd door JeroenED op 23 juli 2024 21:21]

Een aantal van mijn VPS'en waren offline van 8:00 tot precies 20:00.

OVH heeft EEN pluspunt. Het is goedkoop, veel IP's voor weinig geld. Maar absoluut niet geschikt voor kritische toepassingen.
Een kritische toepassing draai je doorgaans ook niet op een (goedkope) VPS maar op dedicated servers óf hun managed cloud. In beide gevallen zorg je er voor dat dingen redundant uitgevoerd worden en wanneer mogelijk zelfs ook bij verschillende partijen is ondergebracht (al is het maar een backup).

Als je OVH goedkoop vind, kijk dan eens naar Kimsufi (ook van OVH), dan heb je voor de prijs waar je nu een medium VPS voor hebt een dedicated server en voor een 10tje meer een wat steviger bakkie ;)
/offtopic
Zie het als een soort timebox in scrum :P
Een hele shitstorm aan negatieve berichten op Twitter (#ovhgate) maar ik vind het wat overdreven. In totaal 2.5h downtime gehad (RBX) en kort daarna kwam ook het bericht dat de rest ook snel online zou komen. Als je kijkt wat de schaal van de outage was dan vind ik dat erg netjes!

Verder al jaren een tevreden tevreden klant voor zowel cloud als dedicated servers. Als er incidenten zijn dan zijn ze van korte duur en wordt het vrijwel direct opgepikt. Gelukkig gebeurt dit zelden.
In totaal 2.5h downtime gehad (RBX)
Mijn VPS'en waren offline van 8:00 tot 20:00. Twaalf uur lang.

[Reactie gewijzigd door dimitrivisser op 23 juli 2024 21:21]

Ach OVH is geen Strato.
Die klagende mensen moeten maar naar Strato overstappen.
Of naar TransIP bij de een betaal je meer en heb je beter service.
En bij de ander is de service nog erger als bij OVH.
OVH is gewoon gemiddeld. Je moet het als backup zien. En niet alles bij hun onder brengen.
Als backup omgeving prima of niet super bedrijf kritische sites.
Vindt dat men hier gelijk OVH beging af te kraken.
Ik heb zelf ook een VPS bij OVH, deze was minimaal 5 uur offline en inmiddels weer bereikbaar. Ik vindt het wel slecht dat ik totaal geen bericht heb gehad van OVH dat de boel offline was.
Monitoring ben je alsnog zelf verantwoordelijk voor met bijv. Pingdom / StatusCake, noem maar op. Ga je me dan echt zeggen dat je niet door had dat alles er uit lag? :+ Via twitter werden op hun support kanalen en die van de CEO alles netjes bijgehouden wat de status was en ook precies uitgelegd wát er aan de hand was.
300.000 servers staan er alleen in Strasbough al... ik denk dat OVH meer richting de 1M servers heeft.
oh vandaar dat ik even wat minder Franstalige spam kreeg. OVH is volgens mij de grootste "bulletproof" hoster van west-europa.
OVH heeft wel regelmatig storingen, ik heb hier een aantal servers draaien. Daarnaast ook bij Leaseweb en een aantal kleinere hosting partijen.

Twee weken terug nog storing bij OVH in Montreal vanwege een defect in de stroomvoorziening voor een aantal switches. Daarnaast in het verleden weer bij Montreal storing gehad vanwege een defecte glasvezel kabel die niet redundant was uitgevoerd. (Alhoewel ze adverteren met redundante glasvezel kabels, die via meerdere routes lopen.)

In Roubaix nu deze storing, en daarvoor een storing omdat de VAC in Montreal offline was i.v.m. de defecte glasvezel kabel.

Bij de andere hosting partijen heb ik in de zelfde tijd geen storingen gehad.
Franse kwaliteit, ik weet dat je niet moet generaliseren, maar hosting in frankrijk viel mij altijd tegen, voornamelijk op het gebied van latencies, interconnect en vaak uitval door het 1 of ander.
In Nederland en Duitsland heb ik daar veel minder last van, 1 van mijn servers heeft nu 5 jaar uptime er op zitten in Duitsland, ongelofelijk.
5 jaar uptime is best een prestatie, maar zou je die machine niet af en toe moeten rebooten om de kernel te updaten? Volgensmij zijn er in de afgelopen 5 jaar best wat leuke exploits voorbij gekomen.
Als het een backup server is die niet direct aan het internet hangt en allen filesync doet over niet SMB shaers is dat niet direct nodig hoor.
Of gebruik van een tool als KernelCare zodat de kernel geüpdatet blijft zonder de machine te rebooten :)
Het is toch wel fijn om af en toe je machine te rebooten, dan weet je dat mocht de stroom ooit een keer helemaal weg vallen dat ie ook weer goed up komt na een reboot.
Wil je dan in geval van breach je backupserver "opgeven" en als entry point voor de rest van je netwerk cadeau doen, samen met de informatie die gebackupped werd? Ik denk dat je teveel vertrouwen hebt in "veilige" filetransfers.
In geval van breach is je main server ook al de sjaak anders kom je er niet bij. Dus ja neerhalen en direct afsluiten.
Je gaat ervan uit dat je (snel) weet dat er een breach is...
Better safe than sorry ;)
Latency van OVH naar Nederland is tegenwoordig prima hoor. Tot op heden beter dan alle grote jongens in Duitsland :9
Klopt, erg te vrede, mijn test server is niet down gegaan, enkel de manager van OVH zelf. Mijn server staat in Gravelines. Ben erg te spreken over kwaliteit, prijs en normale up time. Iets wat ik bij Strato niet het gevoel had.

Tja de bugs daar gelaten, want die zijn er zeker ook. Maar ben zelf meer een tester, dus mij maakt het niet uit. Gelukkig als ik wat meld word het wel opgelost, helaas geen reply terug :'(

Belangrijkste is voor mij weten wat je krijgt en ook echt geleverd krijgen.

[Reactie gewijzigd door KingHorse op 23 juli 2024 21:21]

Ik ben bij Strato begonnen, toen naar Hetzner en nu al enkele jaren bij OVH en ook erg tevreden.

Bij Strato kon in niet eens mijn eigen nameserver draaien (lekker als je webhost bent). Support was ook niet geweldig en liep steeds vaker tegen reclame aan van een product maar als ik het ging afnemen bleek het toch niet helemaal zo te werken als verwacht of voelde niet goed aan.

Bij Hetzner betaal je genoeg voor de servers maar dan krijg je ook exact wat je verwacht. Services draaien op hun netwerk is wel lastig, continue beveiligingsmelding via de mail en zelfs diensten blokkeren. Ook een keer een hardschijf kapot gehad en support was dramatisch.

Onze servers bij OVH in RBX6 (Roubiax) was down maar in Gravelines inderdaad gewoon up. We zijn aan het plannen om nieuwe infrastructuur op te zetten in nieuwe datacenter London en nog Canada (misschien 3de of eigenlijk 1de locatie nog in Frankrijk). De support is niet geweldig inderdaad MAAR wel eens goede service ontvangen van hun door een commando of 2 uit te voeren zodat mijn server goed opstartte. Hun beheerconsole heeft IPMI en dat is enige wat ik nodig heb + IP's routen voor mijn dedicated servers.
Vanmorgen was de communicatie echt 0, hun website was compleet down, telefoons lagen plat (UK en NL nummers) en status paginas waren overbelast. Tweets sturen zonder reactie totdat een andere gebruiker mijn hashtag waarschijnlijk had gezien en mij een retweet stuurde van @olesovhcom waarna ik meer info kreeg.

Bleek dus dat 2x 20kV power lines waren uitgevallen, electro-bedrijf was ermee bezig maar de 2 generators waren ook niet aan gegaan. Ongeveer rond het moment dat ze de eerste aan de loop hadden was ook 1 van de 20kV power lines herstelt
De "routing room" offline is wel dikke FAIL, wist niet dat deze niet redundant was maar gelukkig toezegging dat dit wel het geval is in 1-2 maand (hopelijk is die software bug, raar verhaal, er dan uit).

Maar 2,5 uur is te nemen op een jaar uptime, goede servers en snelle verbindingen (ik draai telefonie op via mijn servers) dus al met al tevreden klant.

[Reactie gewijzigd door ViperXL op 23 juli 2024 21:21]

Bij Hetzner ... support was dramatisch.
Ik heb een paar dedicated servers bij hetzner, en ben juist zo blij met hun support. Reageren snel, lijken alles redelijk op orde te hebben. Bestelde laatst een server om 2 uur 's nachts, kwartier later een mailtje dat hij was opgeleverd.

Mijn ervaringen met OVH zijn verschrikkelijk. Hun support slecht noemen is een understatement. Vaak krijg je gewoon compleet geen antwoord. En als je dan een antwoord krijgt is het afkomstig van iemand die compleet nergens verstand van heeft.

Ik heb een tiental VPS'en bij OVH vanwege de goedkope IP's. Bestel je een VPS met wat IP's, blijken er IPs gewoon niet te werken. Zelf alles getest, is een routing probleem bij hun.

Stuur je een mail, geen antwoord. Paar dagen later nog een keer, weer geen antwoord, paar dagen later weer een mail. En dan krijg je het verzoek om de output van een aantal linux commando's te mailen en een paar links over het configureren van IP's op een VPS. Dus in plaats van het probleem te onderzoeken gaan ze mij vertellen hoe ik een IP moet configureren op een VPS ? En dat terwijl de fout gewoon bij hun ligt.

Uiteindelijk ben je makkelijk 2 a 3 weken kwijt om ze te laten begrijpen dat ze zelf een fout maken.

En vwb snelheid... Zelfs de VPS'en met SSD zijn traag. Een Vultr.com VPS van $ 2,50 is sneller dan een VPS bij OVH die ruim 2 maal dat bedrag kost.

[Reactie gewijzigd door dimitrivisser op 23 juli 2024 21:21]

Ik moet erbij vermelden dat het 4-5 jaar geleden is dat ik bij Hetzner zat. Ik gebruik geen VPS met SSD, heb daarintegen wel gewone VPS's gehad en die waren snel alhoewel ik nooit full throttle heb gedraaid op die machines.
De IP's zijn lastig soms inderdaad, ze gebruiken een raar systeem waarbij het MAC-adres moet overeenkomen/gegenereerd worden en de gateway van de IP's is nooit in dezelfde range maar van je originele IP die bij de VPS/Dedicated server zat. Daarnaast komt het vaak voor dat je moet ARP'en om de switch een seintje te geven dat het IP op het netwerk zit.
Maar ... inderdaad zelf ook 1x meegemaakt met een IP-blok dat het niet deed, ik weet precies wat je bedoeld met support-afdeling die bezit wordt door kneuzen, compleet geen technische kennis en alleen links van manuals terug sturen. Zoals ik zei, ik hoef geen support, zolang me IPMI werkt ben ik happy.
Ik host al jaren bij OVH, eigenlijk nooit problemen en OVH is ook de enige hoster die iedere DDoS aanval zo'n beetje weet te pareren. Daarnaast zijn hun prijzen erg gunstig. Ik ben iets minder tevreden over de support van OVH.NL maar buiten dat hoef ik geen ander meer. En ze zijn sinds kort ook in Azie, Australie etc te vinden met data centers, voorheen was DDoS bescherming daar onbetaalbaar tenzij je bereidt was duizenden euros per maand op tafel te leggen.

Nu heb ik daar een dedicated game server met 4 tbps DDoS protectie met een dikke cpu, veel ram en NVME SSD voor 85 euro per maand.

Voor dat geld mogen ze van mij er best eens in de maand uitliggen, wat niet gebeurd :)
OVH: 3€/lifetime voor een IP, en de servers zijn ook spotgoedkoop en een goede DDoS protectie.
Aan die prijzen zou ik wel wat downtime erbij nemen ;)
Latency: (home(BE) -> server(RBX, GRA) ) is (nu) 20ms en normaal ~15 (heeft met mijn ISP temaken...).
Ook zijn ze met 200Gbps aangesloten op BN-IX (Altijd wel een pluspunt).
Hier een tevreden OVH-klant :-)

Net even mijn VPS in RBX gecheckt:

$ uptime
15:24:23 up 365 days, 3:06, 1 user, load average: 0.00, 0.01, 0.05

Kijkend naar mijn firewall-logging heb ik ieder uur van de dag wel binnenkomend netwerk-verkeer gehad.

Zeker mazzel gehad ;-)
Gefeliciteerd met het 1 jaar online zijn vandaag! :+
Thanks!
Online is 'ie al veer langer hoor :-)
Alleen een jaar geleden blijkbaar een reboot uitgevoerd.
De server heeft een uptime van 365 , maar was zijn connectiviteit dat ook ? :)
Al een jaar niet gepatched dus? 8-)
Anoniem: 317307 @Gijs0079 november 2017 15:22
Je betaalt dan ook wel weinig bij OVH ;)
Als je 115 euro exclusief BTW weinig vindt voor een server..
Voor het geld dat ik aan OVH betaal kan ik ook iedere 3 jaar een server met betere specificaties kopen en een colo contract afsluiten. Helaas hebben veel datacentra nog geen (goede) DDoS bescherming dus zit ik vooralsnog bij OVH.

[Reactie gewijzigd door Gijs007 op 23 juli 2024 21:21]

Het is al jaren bekend, OVH niet gebruiken voor bedrijfskritische zaken.

In hun prijsklasse zijn de uitschieter en bieden ze redelijke producten voor weinig geld. Maar de support is verschrikkelijk, het is altijd afschuiven op de gebruiker (die het meestal ook zelf gedaan zal hebben).

Een server boven de 100euro per maand zou ik niet snel afnemen bij OVH, vanwege de gebrekkige support. Ga dan voor Leaseweb of Worldstream
Leaseweb? Als je kinderachtige management zoekt waarin incompetentie normaal is.

Maar goed mensen die voor paar tientjes colo willen en of 135 euro voor dedicated server veel geld vinden.... moeten niet zeuren.

Er is een reden dat ze daarvoor kiezen en niet in cloud bij Amazon/Google/Microsoft zitten
..
Als ze het meestal zelf gedaanhebben is het toch logisch dat je het op de gebruiker afschuift als die het ook gedaan heeft?

Oke misschien niet bij voorbaat op de gebruiker afschuiven, maar zo te zien nemen ze netjes verantwoording op aps ze zelf eens iets kapot hebben door dit tijdig te melden en de details vrij te geven.
Je begon zo goed, toen eindigde je met Worldstream :+
Tsja, het is heel goedkoop om een server te huren maar de support en de management portal zijn ruk. De portal laadt vaak niet en toont Frans / Nederlands door elkaar.

Maar ja, je gebruikt hopelijk SSH, wat wel altijd werkt, en weet wat je doet, zodat je geen / weinig support nodig hebt. Eigenlijk kun je dus prima zonder die omgeving. Tenzij je server is gecrasht, maar dat komt hopelijk zelden voor.
Als je 115 euro exclusief BTW weinig vindt voor een server..
Ja dat kan heel goedkoop zijn, maar gezien je wel het bedrag specifiek noemt maar niet de server zelf valt er werkelijk niks over te zeggen of dat specifieke geval wel of niet duur is :)
Je hebt dan ook een aardig dikke bak draaien verwacht ik. OVH is goedkoop en qua downloadsnelheden prima de laatste jaren (routing naar Ziggo/UPC was niet altijd top).

Heb al jaren zo'n €3,5/maand server waarop ik een website heb draaien, maar voornamelijk gebruik als plaatjes host. Draait eigenlijk probleemloos, zeker als je kijk wat de kosten maandelijks zijn.

[Reactie gewijzigd door Tortelli op 23 juli 2024 21:21]

Tip: Serverius, zit daar al 7-8 jaar. Op een paar storigen na door overmacht en een keer een serverius eigen foutje, altijd goede uptime met goede DDOS protection.

[Reactie gewijzigd door rootpowered op 23 juli 2024 21:21]

Heb daar een tijdje gezeten voor dat ze DDoS bescherming hadden. Na de stroomstoring (ontwerp fout met een schakelaar) ben ik overgestapt naar Leaseweb voor colocatie. Nog steeds geen spijt van.

Prijs prestatie verhouding was prima bij Serverius, zeker als je veel bandbreedte verbruikt. Maar had vaak last van DDoS aanvallen en null routes.
Je kan ook colocaten bij OVH hoor incl DDoS protectie maar enkel in Frankrijk. Colocatie probeer ik persoonlijk te voorkomen omdat je dan zelf hardware moet gaan vervangen en upgraden en liefst alles dubbel redundant uit moet voeren omdat je vaak niet direct tijd hebt een component te vervangen bij een defect. Daarom heb ik alles dedicated bij OVH en tegenwoordig steeds meer OVH public cloud.
Maakt niet uit waar je co-locate doet, als je dedicated servers gebruikt moet je sowieso redundant uitgevoerd zijn. Het zal je overkomen dat het niet een hardware issue is maar een datacenter issue, dan ben je blij met je secondary site ;)
Www.hetzner.com

Toch al snel i7 met 32.gb geheugen en ssd.

Ze hebben ook oudere modellen servers voor weinig....
En i7 is ook echt een Enterprise cpu
En i7 is ook echt een Enterprise cpu
Denk.je dat je LAMP zo kritisch is...

Je moet eens weten wat Google gebruikt zonder behuizing.
google heeft vele duizenden machines die dezelfde applicatie verzorgen, als er 10 wegvallen is het niet erg.

Als jou lamp stack op 1 machine draait die wegvalt (zoals het gros van de OVH klanten) dan ben je dus meteen klaar. Daar zit een behoorlijk verschil in ;)
In beide gevallen maakt het niet uit wat voor hardware er in gebruik is voor je LAMP.

Ook goedkope servertjes hebben vaak RAID 1 of 10
Zelf tijden bij Hetzner gezeten, doen overal moeilijk over en de support is ook niet geweldig. Eigen DNS server kun je ook wel vergeten.
Uhm.... blokkeren ze 53 tcp & udp inbound/outbound?
OVH heeft zo nu en dan wel eens een storing, maar over het algemeen draait alles heel behoorlijk (voor unmanaged). Daarnaast, over het algemeen reageren ze op tickets binnen een paar uren, daar kunnen de meeste NL server boeren (i3d/LW) nog wat van leren. Bij i3d bijvoorbeeld moet je niet opkijken als je rond 1 dag moet wachten tot iemand reageert als de server niet bereikbaar is. Al een aantal keren gehad in ieder geval.
Ervaringen kunnen altijd verschillen natuurlijk, maar de weinige keren dat ik i3D ergens voor nodig had was de response altijd juist heel snel.

Uiteraard hangt het er wel van af wat de aard van het probleem is en het tijdstip van melden.
[Daarnaast, over het algemeen reageren ze op tickets binnen een paar uren
Paar uur ? Het is jammer dat ik hier geen screenposts kan plaatsen, maar die keren dat ik een ticket inistuurde voor support duurde het minimaal 8 dagen voordat ik antwoord kreeg. En dan schoven ze hun eigen fout ook nog eens af op mij.

Op dit item kan niet meer gereageerd worden.