Databasestoring legt registratiesysteem SIDN plat

De SIDN kampt met diverse storingen waardoor geen domeinnamen kunnen worden aangevraagd. De stichting zag zich maandag genoodzaakt over te stappen op zijn fail-over-locatie, maar ook daar deden zich problemen voor.

Sinds half acht vanochtend kunnen registrars geen nieuwe .nl-domeinnamen registreren of wijzigingen in bestaande domeinnamen doorvoeren. Ook whois-opvragen zijn onmogelijk. De problemen bij de SIDN ontstonden maandag door haperingen die met de database in combinatie met de switch in het datacenter in Ede te maken hadden. Na een herstart van de database hield de switch er helemaal mee op, maar door de sneeuwval en de als gevolg daarvan ontstane files konden medewerkers niet snel bij het datacenter komen om de hardware te vervangen. Daarop werd besloten naar de fail-over-locatie over te schakelen.

"In eerste instantie ging dat goed en vannacht konden mensen weer domeinnamen registreren", vertelt Lycke Hoogeveen, woordvoerster van de SIDN. "Daarna trad Murphy's law echter in werking." De database van de backupsite raakte ontregeld door een kapotte harddisk. "We hebben helaas moeten constateren dat de monitoring ook niet goed werkte", aldus Hoogeveen.

De SIDN is momenteel de problemen aan het herstellen, waarna er een intaketest zal plaatsvinden. "Door de combinatie van problemen kunnen we nog niet zeggen wanneer alles weer naar behoren draait", zegt de woordvoerster. Er zou in ieder geval geen verlies van data zijn opgetreden.

Reacties (70)

[feuniks]

Het vervelende in dit soort situaties is ook dat je alleen maar er iets over hoort als daadwerkelijk alles mis gaat. Was de fail-over gewoon goed gegaan, dan had niemand er ooit iets over gehoord, dat er iets mis was. Daardoor kun je het idee krijgen dat men zijn zaakjes niet op orde heeft. IK vraag me af wat dit soort statistieken zijn bij inderdaad bedrijven als ProRail.

[Maestro]

Hoe graag ik ook mopper op de SIDN, het is niet zo dat er pas gecommuniceerd werd toen ze over wilden stappen naar de fail-over locatie:

29-11 16:17: Omdat er problemen zijn met het bijwerken van de physical standby database waardoor het ook niet mogelijk is een zonfile te genereren, zijn wij genoodzaakt onze primaire databaseprocessen te herstarten. Hierdoor zijn tijdelijk alle services niet beschikbaar. Wij verwachten dat alle services binnen 45 tot 60 minuten weer beschikbaar zijn.

29-11 17:14: De onderhoudswerkzaamheden vergen meer tijd dan vooraf is berekend. Hierdoor zijn wij genoodzaakt het onderhoudsvenster te verlengen. Wij informeren u via de registrarssite en per e-mail wanneer het onderhoudsvenster is afgerond.

29-11 18:54: Na het rebooten van de primaire database is er helaas een hardwareprobleem opgetreden. Deze hardware bevindt zich op een externe locatie, waardoor het in verband met de weersomstandigheden niet mogelijk is deze direct te vervangen. Wij zijn daarom parallel daaraan de procedure gestart om over te schakelen naar onze fail-over locatie. Op dit moment wordt gecontroleerd of de situatie stabiel is alvorens we naar de fail-over locatie overschakelen.
Binnen een uur zullen wij een update geven.

Er is dus wel duidelijk gecommuniceerd over de problemen, wat in het verleden nooit gebeurde (in de tijd van DRS3/4). Langzaam maar zeker leren ze dus wel iets

[YopY]

Was de fail-over gewoon goed gegaan, dan had niemand er ooit iets over gehoord, dat er iets mis was.

Nee inderdaad, omdat er, vanuit de gebruiker gezien, ook niks mis zou zijn. Storingen komen gewoon voor, daar kun je niks aan doen. Het afvangen van die storingen wel (meestal), zodat de klant gewoon zijn ding kan blijven doen.

[Keiichi]

Het blijkt dat geen enkel systeem bestand is tegen murphy's law. Maar dat is ook de aard van de wet

[Xirt]

Ja, maar ik ben wel heel benieuwd of die kapotte harddik al langer in het systeem zat (dan lok je Murphy's Law ook wel uit) of dat die heel toevallig ook vandaag kapot is gegaan. Daarnaast hoort ook een backupserver in mijn ogen redundant uitgevoerd te zijn. Ik neem aan dat ze een soort wachtrij opzetten voor de aanvragen en dat alles nog steeds volgens 'First Come, First Get' wordt afgehandeld?

[Reactie gewijzigd door Xirt op 2 augustus 2024 11:31]

[TJVB]

Ze melden zelf al dat hun monitoring niet werkte dus de kans is heel groot dat die al kapot was.

[Verwijderd]

LOL inderdaad, "de harddisk was kapot en de monitoring werkte niet". De hele SIDN database met domeinnamen op 1 harddiskje?!?

What's next? Straks alle domeinnamen weer vrij omdat de enige backup per ongeluk werd overschreven met de eruit geklapte versie?

[Yalopa]

Ik vermoed dat de meeste infra IT'ers hier al ergere dingen gezien hebben dan dat

[azior]

Murphy's Law: "If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it."
Finagle's Law: "Anything that can go wrong, will"

[Smht]

Murphy's Law: Je kiest de verkeerde rij bij de supermarkt, waardoor iedereen om je heen eerder weg is dan jij
Finagle's Law: Je kiest de verkeerde rij bij de supermarkt, de kassa juffrouw ontdekt dat de kassa niet goed bliept, vervolgens scheurt je tas met boodschappen en kom je eindelijk buiten rijdt er net iemand met zijn auto tegen de jouwe...

Even een duidelijk vertaling

[Verwijderd]

Dit klinkt mij niet als Murph's law in de oren...

Wel héél erg toevallig dat de fail-over in zo'n kort tijdbestek ook kapot ging. En dan blijkbaar ook geen redundantie had voor een simpele kapotte harddisk? Uiterst twijfelachtig.

Klinkt eerder als gewoon heel erg slecht beheer. Failover die gewoon niet goed onderhouden wordt, en nooit getest wordt om te kijken of die zijn taak wel kan uitvoeren.

[Myrdhin]

Ook Murphy's Law hoort wel eens te falen.. Anders klopt zijn eigen wet niet.. ;-)

[Beaves]

SIDN heeft helemaal geen problemen met een hard disk, kan me niet voorstellen dat SIDN geen monitoring doet op hun SAN's en dus een defecte disk een dergelijke impact kan hebben. Waarschijnlijk zijn de problemen dusdanig knullig of geheim dat ze de oorzaak wijten aan een defecte disk.

[LinuX-TUX]

Doen ze wel, maar

@sberm N combinatie van 2 zaken: n probleem met de hard disk en de monitoring die niet goed werkte waardoor we t probleem niet constateerden
about 3 hours ago via web in reply to sberm

Al met al, ronduit slordig. Sorry.

Peperdure redundancy neer pletteren zonder te testen, zo zie je maar weer, test altijd alles. (inclusief backup -> restore & failovers. Trek gewoon de netwerk kabel bwvs eruit en kijk hoe het systeem reageerd)

[Rolfie]

Dan heb je nog geen garantie, dat die op het moment dat je het nodig hebt ook werkelijk doet.
Je hebt alleen de garantie dat die het deed op dat moment.

[LinuX-TUX]

Touche, maar testen is testen, inclusief de logs openen om te kijken of je monitoring tools naar behoren functioneren.

Als die in orde was had je naast de 'op die tijd en dat tijdstip werkte het nog' ook nog eens een betrouwbare monitor gehad die je erop had gewezen zodra deze "staat" veranderde.

Hier ook dikwijls failovers getest. Gewoon bruut de kabels er tussenuit trekken. Zabbix monitors goed configureren en je kan bijna t/m SMART data uit een disk array trekken. Gewoon secuur en punctueel zo'n configuratie opbouwen en weer aflopen om te testen.

[Reactie gewijzigd door LinuX-TUX op 2 augustus 2024 11:31]

[Verwijderd]

Lijkt me überhaupt raar dat een HD crash ervoor zorgt.
We hebben hier een vrij simpel netwerk, en ook al de nodige dode schijven gehad. Gewoon nieuwe inprikken en klaar. Hooguit wat trager als de controller alle data weer op de verse HD zet.

Lijkt me ook dat je niet alleen naar je software zit te staren en af en toe ook door je datacenter loopt en gaat kijken wat de leds op je servers aan het doen zijn. Redundancy of niet.

[Reactie gewijzigd door Verwijderd op 2 augustus 2024 11:31]

[Guru Evi]

Het is altijd mogelijk dat er een schijf random data zit te spuiten en hiermee de bus platlegt. Schijven gaan niet altijd kapot in de zin dat hij uit gaat. We hebben hier een schijf gehad die geen enkel probleem aangaf in de monitoring maar toch enorm traag. Bleek dat er soft errors waren die juist op tijd hersteld werden om niet als een hard error aangemerkt te worden. Of een schijf met een reservation conflict die net op tijd wordt opgelost.

[Verwijderd]

Lastig, maar geen ramp dit. Registraties lopen simpelweg wat vertragingen op. En het is bekend, als het nodig is werkt je backup bijna nooit zoals je verwachtte. Je zou wekelijks moeten schakelen, maar welk bedrijf doet dat?

Welk datacenter zitten ze trouwens in Ede? Ik ken alleen Bit daar, maar dat is nou ook niet echt een hele grote?

-Edit- Wel Bit dus. Grappig, kom ik dus regelmatig langs de SIDN servers

[Reactie gewijzigd door Verwijderd op 2 augustus 2024 11:31]

[Derky]

Ze zitten bij Bit ja.

[Peter Huizenga]

Ik weet dat evoswitch elke woensdag middag om 12 uur overdag overschakeld op hun backup stroom via diesel generatoren.
Er zijn wel bedrijven die het doen alleen niet zo veel

[Verwijderd]

Stroom is ook wel een stukje makkelijker dan overschakelen van productie naar backup op een gescheiden geografische lokatie. Dat heeft iets meer voeten in aarde dan een handel overhalen

Wat niet wegneemt dat het goed is dat het getest wordt!

[Reactie gewijzigd door Verwijderd op 2 augustus 2024 11:31]

[eborn]

Tja, liever één keer down in deze situatie dan stelselmatig elke maand een keer down vanwege een mislukte failover test. Op een gegeven moment wordt je dat als gebruiker ook zat

[Craven]

Opzich wel nette verslaggeving. Meestal komen ze niet verder dan: "We zijn de oorzaak van de problemen nog aan het onderzoeken. Maar we doen er alles aan om het te fixen."

Maar ze staan toch wel flink te prutsen vind ik. Switches en databaseservers zijn goed redundant uit te voeren. Dat ze er dan voor kiezen om dat niet te doen maar een 2e locatie als redundantie te hebben is op zich een goed idee. Maar dat die eruit dondert door een kapotte disk is simpelweg prutswerk.

[Rolfie]

Een SAN kan ook onderuit gaan door een harddisk failere. Het mag niet, maar het kan wel.

[Proxx]

wanneer gaan ze die wet eigenlijk afschaffen ik begin er een beetje genoeg van te krijgen.

[CherandarGuard]

Ik zou zeggen, schrijf je favoriete partij om te vragen of ze een wetsvoorstel in willen dienen. Wie weet, misschien krijg je nog wel iemand zo ver.

Wat betreft het SIDN, het ziet er naar uit dat ze hun uiterste best hebben gedaan om de boel zsm op de rails te krijgen. Ze hadden gewoon pech.

Ik vermoed wel dat er wat beter getest zal worden in de nabije toekomst, maar te vermijden zal dit waarschijnlijk toch niet zijn geweest.

[Stoney3K]

Ik zou zeggen, schrijf je favoriete partij om te vragen of ze een wetsvoorstel in willen dienen. Wie weet, misschien krijg je nog wel iemand zo ver.

Ik zie de PVV er nog wel toe in staat.

Laten we dan gelijk stemmen voor het afschaffen van de wet van behoud van energie en de zwaartekracht, scheelt weet 2 keer parlementaire rompslomp.

[ATS]

Dat zou wel een leuke 1 april grap zijn trouwens...

[Xantis]

Ah vandaar dat de wijzigingen die ik vannochtend heb doorgevoerd zo lang duren. Dat is mooi vervelend zo'n storing. Wel typisch dat alles tegelijkertijd stuk gaat. Jammer maar helaas, ik wacht wel een tijdje langer. Het heeft toch geen haast.

[mphilipp]

Murphy weer, en hij nam zijn hele familie mee. Zo zie je maar, het ongeluk komt zelden alleen. Op zich weer een leuk leermoment voor de beheerders.

[cariolive23]

Oracle staat hiermee ook aardig voor schut:

While restarting our database we have encountered an Oracle bug. Therefore the database crashes immediately. We're working on a work around.

Al zijn dit soort storingen altijd een combinatie van problemen, hoogst persoonlijk uitgevoerd door Murphy

[airell]

Ligt eraan... misschien was de bug gefixt in een patch die nog niet uitgerold is?!

[Verwijderd]

"Unfortunately the patch for the Oracle bug didn't help. We're currently testing a work around and will know within 30 minutes if that works."
http://twitter.com/SIDN/status/9561953521369088

[Verwijderd]

Hardwarefalen valt weinig aan te doen, maar het feit dat de failsafes en de monitoring niet in orde bleken is weer knullig. Maar het zal niet de eerste keer zijn dat SIDN knullig in het nieuws komt.